Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Lakehouse_medallion

Ryoma Nagata
November 21, 2022

 Lakehouse_medallion

Openhack for Lakehouse用資料
202304 update

Ryoma Nagata

November 21, 2022
Tweet

More Decks by Ryoma Nagata

Other Decks in Technology

Transcript

  1. メダリオンアーキテクチャと Data Lakehouse Microsoft MVP for Data Platform 永田 亮磨

    Twitter:@ryomaru0825 Linkedin:ryoma-nagata-0825 Qiita:qiita.com/ryoma-nagata
  2. • 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格納列など 無理のある実装
  3. データレイクの考え方「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 • 利用の際にデータ型を定 義する必要があり、データ 利用のハードル増
  4. • ステージ毎のデータの役割を明確化する • Bronze (Raw)データ: • 後続を再生成可能にする生データ • 構造化の欠如、重複などの品質不足を受け入れるため、公開されるべきではない状態となる •

    Silver(Enrich)データ: • データ構造を適用し、品質チェックを適用された、公開すべき状態の利用可能データ(Single Source of Truth) • Gold(Curate)データ: • データマートとも呼ばれる状態。シナリオに適合した変換を加えた調整済みデータ メダリオンアーキテクチャ (別名:マルチホップアーキテクチャ Bronzeデータ (Raw) Goldデータ ( Curate ) Silverデータ ( Enrich ) データ品質を適用し、 利用可能データへ シナリオごとに 調整されたデータへ
  5. • Bronze/Silver: 汎用的な高品質データを消費者に届けるために、データエンジニアリングチームにより生成される • Gold : データ活用が具体化されたデータとして、ビジネス知識をもつチームにより生成される メダリオンアーキテクチャにより整理される責務 Bronzeデータ (Raw)

    Goldデータ ( Curate ) Silverデータ ( Enrich ) データ品質を適用し、 利用可能データへ シナリオごとに 調整されたデータへ 消費 BI アナリスト • 分析モデルの構築 • 経営層への報告 データエンジニア • データパイプラインの開発 • 新規データの取得 AI データサイエンティスト • 統計、仮説検証 • 機械学習モデルの開発
  6. 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アクセス、 アクセス管理
  7. Data Lakehouseを実現するストレージレイヤOSS Delta Lake 特徴 • オープンかつシンプル: • ベンダーロックインなく、あらゆるツールからアクセス可能 •

    SQL/Python 双方での共通データアクセス • 統一されたバッチ、ストリーミング • DWHとデータレイクのいいとこどり: • 高速なクエリ • タイムトラベル機能による過去データの遡り • スキーマの自動拡張 or 強制 • 構造化~非構造化データに対応しつつ高い圧縮率 • コンプライアンス対応: • 監査履歴 • UPDATE, DELETEによるデータ操作 https://delta.io/
  8. • DELTA LAKEをインストールしたエンジンを通してレイクハウスを利用可能 • ストレージ上には実データと管理用のファイル群が保管される Data Lakehouse @DELTA LAKE Data

    Sources 12 ストレージ層 BI Dashboard Explorer SQL Data Lakehouse ML Model ML Pythn コンピューティングエンジン API Raw Enrich Curate
  9. レイクハウス構成による相互運用 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
  10. • より実践的には追加の3つのゾーンが考えられる • Ingest (アップロード): • データソースからの取得方法にはPullか被Push型があり、被Pushの際にはこちらを利用してソースシステム主体でアップロードする。 • Landing(着陸): •

    取得したデータをそのままファイル配置する。バックアップ的な意味合いが強い。 • Workspace(分析サンドボックス): • Curate の処理や分析を試行錯誤する作業環境 • 成熟した処理はCurateのために昇格される Appendix:さらに実践的なデータゾーン構成
  11. • ストレージアカウントの構成のベストプラクティス • 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
  12. 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
  13. • 利点: • DMZとしての役割: • 特定のソースシステムへのネットワーク開放が必要な場合、Ingestストレージ側でネットワーク開放をすることで、 Landing/Raw領域のセキュリティを維持する ことが可能 • 3rdパーティ対応:

    • blobストレージは一般的であり、3rdパーティ製品でのサポートされることが多い • 注意事項: • Blobストレージを用いた場合に階層空間ではない保持形式となるため、空フォルダは作成できない • Data LakeはBlob Storage互換APIを利用可能であるため、Data Lakeを利用するのも手 Appendix:データのIngest領域として 個別のストレージアカウントを構成する利点 • アップロードインジェストストレージ