①担当箇所の要約
【データアーキテクチャの例と種類】
自分にとって最適的なアーキテクチャを考える上でいくつかの例を見る。
【データウェアハウス】
<導入>
・一番有名なアーキテクチャ。
・Inmonによって考案された。
➡定義は青木峰郎著『10年戦えるデータ分析入門』を参照。
※勉強会では補足めもを参照
・技術は進歩しているが、中心的な概念は変わらない。
(The cloud data warehouseの部分で詳細)
・オンプレミスからクラウドに移行できるようになり、多くの企業で導入しやすくなった。
・ organizational データウェアハウスと technicalデータウェアハウスの2種類がある。
<organizational data warehouse>
organizational data warehouseの特徴
・データ分析基盤とビジネス向けのシステムの分離???
・データの集約と整理：具体的にはfigure3.10を参照。
データ元➡ETLツール➡(変換した上で格納)DWH➡DMの流れで処理される。
<technical data warehouse>
・一度ローデータを(変換せず)stagingに格納し、その後変換してDWHに格納するというELTの処理となっている(organizational data warehouseでは「ETL」で処理)。具体的にはfigure3.11を参照。
・この変換にクラウドの計算能力(MPP)の利用が意図されている。
<The cloud data warehouse>
・オンプレからクラウドへの移管が進んだ。その背景としてAWSによりスケーラブルなクラウド環境が提供され、追随したGCPやSnowflakeによりストレージと計算が分離されストレージの拡張するなど、クラウドを使ったデータ分析基盤が発展がある。
・(導入の通り、)技術面は発展したが、中心的な定義は変わらず、その範囲が拡張していると言える。
<Data marts>
・分析に特化した個別のデータセット。
・データマートには「ビジネスサイドでも利用しやすい」「パフォーマンスを上昇させる」といったメリットがある。
➡後者のイメージとしてダッシュボードツールのパフォーマンスがイメージされた。
【データレイク】
<導入>
・(DWHが構造化データを対象としていたのに対し、)データレイクは非構造化データと構造化データをまとめて保管する。
・データレイク1.0は少し欠陥があった。
_むやみにデータが格納された。また書き込み専用であり、(GDPR対応に必要な)データ削除に反する
_データの処理も苦手???
(以下文意が取れなかったため、私の解釈を記載)
～～～～～～～～～～～
①joinなどの簡単な処理も苦戦した。
②PigやHiveにより多少解決したが、data managementの問題は残った。
＝deleteやupdateといった処理はDMLでも苦手で、新しいテーブルを作ることでその場しのぎの対応をしている。
裏返すと、DWHは基本的なデータ保持向きでSQLは詳細なクエリを実行するのに有効なツールといえる。
～～～～～～～～～～～
➡文の繋がりと最終文の「the latter」が怪しい。最終的にData martをかばってる？
(解釈部分終了)
_技術やコスト要求もあり、データの民主化には程遠い状況だった。
_一部の企業(ネトフリやFB)ではうまくいくこともあった。
②不明点・確認点
・「Separates online analytical processing (OLAP) from production databases (online trans‐action processing)」が何を指すのか不明である。
・technical data warehouseの最後にある「virtuous cycle」が不明。
・organizationalDWHのstagingとData Lakeの違いは「構造化データを格納するかどうか」という点がメインか確認したい。
←日本の書籍では図3.11の形を「DataLake➡DWH➡DataMart」として紹介していることが多い印象。
・データマート中盤の「Processing data was also challenging.」から始まる段落がいまいち整理できなかった。特にどういった処理が苦手で、その内どの部分は解決したかがいまいち不明。
