Lakehouse_medallion

Openhack for Lakehouse用資料
202304 update

Transcript

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

   View Slide

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

   View Slide

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

   View Slide

4. • 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格納列など
   無理のある実装
   

   View Slide

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

   View Slide

6. データレイクの考え方「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
   • 利用の際にデータ型を定
   義する必要があり、データ
   利用のハードル増
   

   View Slide

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

   View Slide

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

   View Slide

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

   View Slide

10. 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アクセス、
    アクセス管理
    

    View Slide

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

    View Slide

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

    View Slide

13. レイクハウス構成による相互運用
    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
    

    View Slide

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

    View Slide

15. • ストレージアカウントの構成のベストプラクティス
    • 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
    

    View Slide

16. 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
    

    View Slide

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

    View Slide

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

    View Slide