メダリオンアーキテクチャと Data Lakehouse Microsoft MVP for Data Platform 永田 亮磨 Twitter:@ryomaru0825 Linkedin:ryoma-nagata-0825 Qiita:qiita.com/ryoma-nagata

• DWH:データを集約し、保管するデータの倉庫 • データマート:分析に適した形式に整えられたデータ群(Curate Data) • ディメンショナルモデルや、ワイドテーブル、サマリーテーブルなど • データマートのためのBIサーバーで保持することもある 従来型BIシナリオにおけるDWH,データマート構成 *ETL : Extract・Transform・Load デ ー タ 抽 出 ・ 変 換 ・ 取 込 Data Warehouse Data Sources Data Marts (Curate) BI Dashboard Explorer 分 析 ETL*と呼ばれるプロセス

• ETL:DWHに保管する前に変換をかける • ELT:未加工のデータを保管した後で変換をかける • 未加工データをDWHで提供することで、より柔軟な分析ユースケースに対応 • 未加工データがあることで、後続データを再生成可能（壊滅的なロジック変更にも対応できる） ETLからELTへ Data Warehouse Data Marts (Curate) BI Dashboard Explorer 分 析 Staging(Raw) デ ー タ 変 換 Data Sources デ ー タ 抽 出 ・ 取 込

• ELT自体は新しい考えではないが、生データに対する柔軟性の欠如という問題がある • DWHはデータベースであるため、“テーブル”として、列、型を定義する必要がある • DWHでは、非構造化データの処理に無理がある（例：センサーデータのjson） DWHでのELTの限界 { "name" : "cat", "count" : 105, “owner”:{“name”:”abe”} } { "name" : "dog", "count" : 81 } abe, 95, 46, 85, 85 itoh, 89, 72, 46, 76, 34 5列のデータ 4列のDWHテーブル フラット構造、定型のDWHテーブル 不定形、ネスト構造のデータ 余分列の削除 ネスト構造の 排除など 改修コスト Json格納列など 無理のある実装

• スキーマの定義や、ファイル形式の制限なく、自由に低コストで多様データを保管可能に • 画像、音声などのAI分野においてはこうした非構造化データの処理能力が不可欠 • DWHの前段階としてのEL領域としてもデータレイクの利用が好まれた データレイクの登場とAIへの拡張 デ ー タ 抽 出 ・ 取 込 Data Warehouse Data Marts (Curate) BI Dashboard Explorer 分 析 Raw デ ー タ 抽 出 ・ 取 込 ・ 変 換 Data Lake ML Model 解 析 AI Data Sources

データレイクの考え方「Schema-on-Read」 abe, 95, 46, 85, 85 itoh, 89, 72, 46, 76, 34 ueda, 95, 13, 57, 63, 87 emoto, 50, 68, 38, 85, 98 otsuka, 13, 16, 67, 100, 7 katase, 42, 61, 90, 11, 33 {"name" : "cat", "count" : 105} {"name" : "dog", "count" : 81} {"name" : "rabbit", "count" : 2030} {"name" : "turtle", "count" : 1550} {"name" : "tiger", "count" : 300} {"name" : "lion", "count" : 533} {"name" : "whale", "count" : 2934} xxx.xxx.xxx.xxx - - [27/Jan/2018:14:2 0:17 +0000] "GET /item/giftcards/372 0 HTTP/1.1" 200 70 "-" "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.1) Gecko/20100101 Firefox/10.0.1" ネイティブフォーマットを、そのまま蓄積 SELECT ~~~ FROM ~~~ WHERE ~~~ ORDER BY ~~~; 利用時にスキーマ（データ構造）を定義 Schema-on- Write • あらかじめスキーマ （データ構造）を定義 した場所に書き込む Pros • 確実なデータ型 • ユーザー利便性 Cons • データ型に準拠しない データの埋没、柔軟性 欠如 Schema-on- Read • 保存時にはスキーマ （データ構造）を定義し ない • 利用時にはじめて スキーマ・データ構造を定 義し、Read を実施 Pros • 将来の分析需要への対 応 • 保持データの柔軟性 Cons • 利用の際にデータ型を定 義する必要があり、データ 利用のハードル増

• データレイクで、本当の意味での生データを保持できる一方で、型、列定義の適用されないデータは扱いづらい • →”ほぼ”未加工でありながらクレンジング済みとなる、利用可能データ（Enrich Data）を提供する仕組みも求められた • Enrich Dataでは、Curate同様、スキーマを定義することで利便性を向上する 生データ、未加工データに対する考え方 デ ー タ 抽 出 ・ 取 込 Data Warehouse Data Marts (Curate) BI Dashboard Explorer 分 析 Raw Data Lake ML Model AI Enrich デ ー タ 抽 出 ・ 変 換 ・ 取 込 デ ー タ 変 換 解 析 Data Sources

• ステージ毎のデータの役割を明確化する • Bronze (Raw)データ： • 後続を再生成可能にする生データ • 構造化の欠如、重複などの品質不足を受け入れるため、公開されるべきではない状態となる • Silver(Enrich)データ： • データ構造を適用し、品質チェックを適用された、公開すべき状態の利用可能データ（Single Source of Truth） • Gold(Curate)データ： • データマートとも呼ばれる状態。シナリオに適合した変換を加えた調整済みデータ メダリオンアーキテクチャ （別名：マルチホップアーキテクチャ Bronzeデータ （Raw） Goldデータ （ Curate ） Silverデータ （ Enrich ） データ品質を適用し、 利用可能データへ シナリオごとに 調整されたデータへ

• Bronze/Silver: 汎用的な高品質データを消費者に届けるために、データエンジニアリングチームにより生成される • Gold : データ活用が具体化されたデータとして、ビジネス知識をもつチームにより生成される メダリオンアーキテクチャにより整理される責務 Bronzeデータ （Raw） Goldデータ （ Curate ） Silverデータ （ Enrich ） データ品質を適用し、 利用可能データへ シナリオごとに 調整されたデータへ 消費 BI アナリスト • 分析モデルの構築 • 経営層への報告 データエンジニア • データパイプラインの開発 • 新規データの取得 AI データサイエンティスト • 統計、仮説検証 • 機械学習モデルの開発

Data Lake＋DWHからData Lakehouseへ Data Lake ＋ DWH Data Lakehouse Data Warehouse Data Lake 消費 BI AI 消費 BI AI Data Lakehouse クエリ インポート クエリ Raw Enrich～Curate Raw～Enrich～Curate • BI、DWHを主役としたデータ基盤 • DWHの利用前に構造化とあわせて段階 的にデータロードを行う • AI領域は主にデータレイク上で消費される が、データ品質管理が難しく、ガバナンスは DWHと分断される • BI～AIの拡張的分析を目的としたデータ基 盤 • DWHのデータ品質管理の容易さとAIに不 可欠となる非構造化データの処理能力をあわ せもつ • すべてのデータはデータレイク上に存在し、ガバ ナンス（アクセス権、使用方法）が一元化さ れる SQL/Pythonアクセス データ定義、アクセス管理 API API API SQLアクセス データ定義、アクセス権 Pythonアクセス、 アクセス管理

Data Lakehouseを実現するストレージレイヤOSS Delta Lake 特徴 • オープンかつシンプル： • ベンダーロックインなく、あらゆるツールからアクセス可能 • SQL/Python 双方での共通データアクセス • 統一されたバッチ、ストリーミング • DWHとデータレイクのいいとこどり： • 高速なクエリ • タイムトラベル機能による過去データの遡り • スキーマの自動拡張 or 強制 • 構造化～非構造化データに対応しつつ高い圧縮率 • コンプライアンス対応： • 監査履歴 • UPDATE, DELETEによるデータ操作 https://delta.io/

• DELTA LAKEをインストールしたエンジンを通してレイクハウスを利用可能 • ストレージ上には実データと管理用のファイル群が保管される Data Lakehouse @DELTA LAKE Data Sources 12 ストレージ層 BI Dashboard Explorer SQL Data Lakehouse ML Model ML Pythn コンピューティングエンジン API Raw Enrich Curate

レイクハウス構成による相互運用 DELTA LAKEはOSSのため、サービス問でデータを相互運用可能 Databricks SQL Serve Serve Raw Enrich Curate Data Lake Storage Store Azure Databricks Process Ingest Process Ingest Event Hubs Event Hubs Data Factory Azure Machine Learning Power BI Store Azure Synapse Analytics Spark Pool Synapse Analytical Engines SQL Pool Data Explorer Pool Power BI Azure Machine Learning Raw Enrich Curate Data Lake Storage Pipelines Synapse Analytics Lakehouse Databricks Lakehouse

• より実践的には追加の３つのゾーンが考えられる • Ingest (アップロード)： • データソースからの取得方法にはPullか被Push型があり、被Pushの際にはこちらを利用してソースシステム主体でアップロードする。 • Landing（着陸）: • 取得したデータをそのままファイル配置する。バックアップ的な意味合いが強い。 • Workspace（分析サンドボックス）： • Curate の処理や分析を試行錯誤する作業環境 • 成熟した処理はCurateのために昇格される Appendix：さらに実践的なデータゾーン構成

• ストレージアカウントの構成のベストプラクティス • Ingest用：アップロードを行うデータソース側システムごとにRA-GRSのストレージアカウントを用意する • Landin / Raw用：データ損失を最高レベルにするため、RA-GRSを1つ用意する • Enrich/Curate用：データの可用性をある程度確保するため、ZRS以上を1つ用意する • Workspace用：LRSを1つ用意する • 一般的な懸念 • 複数のアカウントを利用することによるコスト →Azure Storageは完全な従量課金制となり、複数のアカウントを利用することは余分なコスト増にはつながらない。むしろ データの損失保護を全ステージで最高レベルにするコストのほうが危険 • データサイロの形成 →Azure上のデータサービスは権限さえ構成すればアカウントが異なっていても簡単にアクセスが可能。特にUnity Catalogで はストレージアカウントの物理構成は隠ぺいされる ※サイロの観点は重要なので、共有が難しい設計とならないように注意 • 複数構成が推奨される理由 • データのステージにより冗長構成を変えることでコストを最適化 • ACLの上限を回避しやすくなる Appendix： Data Lake Storage Gen 2の利用数について • データ管理と分析のシナリオに関してよく寄せられる質問 - Cloud Adoption Framework | Microsoft Docs

Appendix：ストレージアカウント構成例 Data Sources Landing Raw Enrich Curate Workspace Ingest Curate 化の検証開発 Data Lake Storage Gen2 Data Lake Storage Gen2 Data Lake Storage Gen2 Data Lake Storage Gen2 Pull Pull Push

• 利点： • DMZとしての役割： • 特定のソースシステムへのネットワーク開放が必要な場合、Ingestストレージ側でネットワーク開放をすることで、 Landing/Raw領域のセキュリティを維持する ことが可能 • 3rdパーティ対応： • blobストレージは一般的であり、3rdパーティ製品でのサポートされることが多い • 注意事項： • Blobストレージを用いた場合に階層空間ではない保持形式となるため、空フォルダは作成できない • Data LakeはBlob Storage互換APIを利用可能であるため、Data Lakeを利用するのも手 Appendix：データのIngest領域として 個別のストレージアカウントを構成する利点 • アップロードインジェストストレージ

• What's Data Lake ? Azure Data Lake best practice - Speaker Deck 参考