Microsoft Data Analytics trends : ”Lakehouse” , ”Data Mesh"

2nd Microsoft Data Analytics Day(Online)
https://sqlserver.connpass.com/event/251013/

発表資料

Transcript

1. Microsoft Data Analytics の注目キーワード
   「Lakehouse」「Data Mesh」について
   Microsoft MVP for Data Platform
   永田 亮磨
   Twitter:@ryomaru0825
   Linkedin:ryoma-nagata-0825
   Qiita:qiita.com/ryoma-nagata
   

   View Slide

2. • スピーカーおよびセッションの背景
   • Microsoft系のデータ分析領域を業務としている人間が、
   各クラウド上の分析基盤のトレンドや一般的な歴史などを追いかけて整理した内容です
   • 対象者
   • データ活用基盤の構築運用に関わる方々
   • ゴール
   • 従来型の基盤の課題とレイクハウスが達成することを理解する
   • データメッシュを含む新興概念が対処する問題、方向性を理解する
   • 【Stretch!】本日学んだ内容を皆様のデータ活用に活かせるようになる
   本セッションについて
   

   View Slide

3. 1. データレイクハウスについて
   ※前回のAnalytics Day の「データレイクとは」の内容のおさらいを含みます。説明を一部割愛しているのでデータレイク自体の詳細は以下参照
   What‘s Data Lake ? Azure Data Lake best practice - Speaker Deck
   2. データメッシュについて
   AGENDA
   

   View Slide

4. データレイクハウスについて
   What is Data Lakehouse ?
   

   View Slide

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

   View Slide

6. • データレイクによりスキーマの定義や、ファイル形式の制限なく、自由に低コストでデータを保管可能に
   • ELTというと、データレイクを前提とした構成を指すことが多い
   • Machine Learning分野においてもデータレイクの利用が好まれた
   データレイクの登場
   デ
   ー
   タ
   抽
   出
   ・
   取
   込
   Data
   Warehouse
   Data
   Sources
   Data Marts
   (Curated)
   BI
   Dashboard
   Explorer
   分
   析
   Raw
   デ
   ー
   タ
   抽
   出
   ・
   取
   込
   ・
   変
   換
   Data Lake
   ML Model
   解
   析
   ML
   記述的分析：今何が起こってい
   るか
   診断分析：なぜ起こったか
   予測分析：これから何が起こる
   のか
   規範的分析：どうすれば起こせ
   るのか
   

   View Slide

7. • 従来のDWH中心の世界＝ストレージとコンピューティングが一体化
   • 変換処理の性能限界＝DWHのエンジンの限界
   • データにアクセスするためにはDWHを介する必要がある→共有や多目的利用の難しいデータ
   • データレイクの世界＝ストレージとコンピューティングが分離
   • 単なるストレージのため拡張性に優れる。多用なエンジンを使用可能
   • データにアクセスする製品やエンジンは誰が所有していてもいい→共有や多目的しやすいデータ
   ストレージとコンピューティングエンジンの分離
   7
   エンジン
   ストレージ
   ストレージ
   エンジン エンジン
   製品A 製品B
   Data
   Lake
   Data
   Warehouse
   ユーザーとツール
   ユーザーとツール
   ユーザーとツール
   

   View Slide

8. • 強み
   • SQLでのアクセス利便性
   • スキーマ（テーブル、列、データ型、制約）が適用されて
   いることによる、データ品質の担保
   • 専用ストレージが担保する即答性
   • 弱み
   • 非構造化データ対応が困難
   • データべース専用ストレージに保管されることにより
   • コスト増
   • 処理性能はDWHのコンピューティング性能に依存する
   • SQLを発行するツールでしかアクセスできない
   DWH/データレイクの強み、弱み
   DWH
   • 強み
   • 非構造データへの対応による機械学習対応
   • 汎用的なストレージに保管されることにより、
   • 低コスト保管
   • 多用な製品からアクセス可能
   • 性能はアクセスする側のコンピューティング性能によって決まる
   • 弱み
   • スキーマを強制できないため、データの整理や、品質を
   担保することが難しい
   • ファイルでの運用となるため、DWH時代で実行できた
   SQLで更新削除するなどのメンテナンス作業が困難
   • 即答性を確保するのは難しい
   データレイク
   BIツールからのアクセスや、
   分析SQL処理に専念させる
   データサイエンスや、
   保管と事前の変換処理層
   として扱う
   

   View Slide

9. • データレイク上で変換用に分散処理フレームワーク（Hadoop,Spark）を利用することによるスケーラビリティ向上
   • 分析クエリ処理性能（DWH）とデータ変換処理性能（データレイク）で異なるリソースを利用して適材適所化
   • データレイク上にデータがあることで、複数種のシステムへの展開が可能＝ベンダーフリー
   データレイク×DWH構成
   Modern Data Warehouse
   デ
   ー
   タ
   抽
   出
   ・
   取
   込
   Data
   Warehouse
   Data
   Sources Data Marts
   (Curated)
   BI
   Dashboard
   Explorer
   分
   析
   Raw
   Data Lake
   ML Model
   ML
   Enriched
   Enriched Curated
   解
   析
   デ
   ー
   タ
   変
   換
   デ
   ー
   タ
   変
   換
   データ抽出・取込 データ抽出・取込
   

   View Slide

10. • 多様なユースケースには混合型のデータストアに対応した結果、
    同じ内容のデータであっても、異なる目的では異なるデータストアにアクセスする複雑さが生まれた
    データレイク×DWH構成
    Modern Data Warehouse
    デ
    ー
    タ
    抽
    出
    ・
    取
    込
    Data
    Warehouse
    Data
    Sources Data Marts
    (Curated)
    BI
    Dashboard
    Explorer
    分
    析
    Raw
    Data Lake
    ML Model
    ML
    Enriched
    Enriched Curated
    解
    析
    デ
    ー
    タ
    変
    換
    デ
    ー
    タ
    変
    換
    データ抽出・取込 データ抽出・取込
    シンプルな方式で
    実現できないのか？
    

    View Slide

11. ストレージ層
    アクセスしたい
    データ
    • Databricks社が提唱した名称（現在ではガートナーもハイプサイクル内に位置づけ）
    • 以下を実現することで、データ分析/サイエンス、MLを一つのプラットフォームで実現する
    • 異なる言語でも同じデータにアクセスができる
    • それぞれのデータアクセス、処理は分離されたコンピューティングエンジンが柔軟に性能を提供する
    データレイクハウス型の情報基盤
    • Lakehouse: A New Generation of Open Platforms that Unify Data
    Warehousing and Advanced Analytics (cidrdb.org) 11
    Data
    Sources
    BI
    Dashboard Explorer
    SQL
    Lakehouse
    ML Model
    ML
    Pythn
    コンピューティングエンジン
    (BI)
    API
    コンピューティングエンジン
    (ML)
    コンピューティング
    エンジン
    (ETL)
    

    View Slide

12. Delta Lakeによるデータレイクハウス
    12
    • ストレージ層にDWH機能＋αをSWレベルで構成し、DWHとデータレイクのいいとこどりを実現する
    • DWHライクなデータ管理性とデータレイク譲りのコスト効率、柔軟性
    • ストレージとコンピューティングの分離によるスケーラビリティ、オープンな共有
    • SQL / Python双方のAPIをもつことによる透過的なデータアクセス
    ストレージ層
    Data
    Sources
    BI
    Dashboard Explorer
    SQL
    Lakehouse
    ML Model
    ML
    Pythn
    コンピューティングエンジン
    API
    Raw Enrich Curate
    

    View Slide

13. • データ分析基盤における米ユニコーン企業であるDatabricks社が開発した、
    レイクハウスの中核を担うOSS
    補足）次世代データ基盤むけOSS Delta Lake
    メリット
    • オープン性：
    ベンダーロックインなく、あらゆるツールからアクセス可能
    • レイク上でのDWH機能の実現：
    • UPDATE,MERGEを含むトランザクション処理
    • SQL 、Python 双方での共通データアクセス
    • タイムトラベル機能による過去データの遡り
    • データレイクの長所を維持：
    • 実態はparquetファイルのため高圧縮率→コスト効率大
    • json、バイナリなどの非構造化データに対応
    https://delta.io/
    

    View Slide

14. 成り立ちの違いで発展の道筋が異なるが、ビジョンはいずれも
    データ活用を一つのプラットフォームでシンプル化して実現すること
    • Databricks：OSSでデータレイク技術を発展させたプラットフォーム
    • Snowflake：独自技術でDWH技術を発展させたプラットフォーム
    おまけ）先進データベンダーのビジョンと発展
    データ
    管理性
    コンピューティングの分離
    多様な言語と目的の対応
    DWH,
    可視化強化
    データ共有
    データ管理性
    可視化ニーズ
    対応
    データ共有と
    ガバナンス
    コンピューティングの分離
    容易な性能調整
    カタログと
    ガバナンス
    データレイク、Sparkの
    基本特性
    Delta
    Lake
    SQL WH、
    Redash
    Delta
    Sharing
    Unity
    Catalog
    MLOps
    MLflow
    HTAP拡張
    DWHの
    基本特性
    マイクロパーティション、
    マルチクラスタ仮想WH
    Snowgrid,
    Zero-clone
    copy
    Snowsight
    dashboard
    Unistore
    多様な言語
    と目的の対応
    Snowpark
    発展
    発展
    早期に実現したコア部分
    早期に実現したコア部分
    

    View Slide

15. データメッシュについて
    What is Data Mesh ?
    

    View Slide

16. • これまでのスコープ
    • データ活用システムをどう作るか
    これから話すことのスコープ
    • ここからのスコープ
    • 散在するデータシステムの現実を組織
    全体でどう扱うべきか
    全社データ活用基盤
    SCMシステム
    顧客分析システム
    組織内に散在するデータシステム
    

    View Slide

17. • 各種の観点で企業のデータはあらゆるところに分散し、その形式はさまざまとなっ
    ている
    • これらのデータに迅速にアクセスするには多用なプロセス、ツールを使いこなす必
    要があり、データ活用の難易度が上がっている
    今日の企業のデータの配置状態
    観点 選択肢
    場所 オンプレミス / クラウド
    ベンダー Azure / AWS / GCP / 他SaaS
    形式 SQL / NoSQL
    流入頻度 バッチ / ストリーム
    

    View Slide

18. • 社内の主要ユーザーの好みや、政治的な問題、あるいは法規制により、
    同じ組織内でN個のデータ基盤があるような場合もある
    • -> 一次データだけでなく二次的なデータについても所在が分散
    • こうした現実に目を向けながら企業は『データに迅速にアクセス』する仕組みについて考える必要がある
    データ活用基盤自体も散在している現状
    AWS Cloud
    Microsoft Azure SaaS
    On-premise
    BigQuery
    Cloud
    Storage
    SQL DB Synapse Analytics
    Blob Storage
    Amazon S3
    Amazon RDS
    Amazon Redshift
    SQL Server
    

    View Slide

19. モノリスなデータ基盤
    • How to Move Beyond a Monolithic Data Lake to a Distributed Data Mesh
    (martinfowler.com)
    • これまで、データのサイロを解消するために企業は分散したデータを
    一つの大きなデータ基盤に物理的に集約することでデータへのアクセスを実現してきた
    • この経験を経てモノリスな基盤の課題が指摘されているのが現状
    • データのユースケースは組織が成熟するにつれて増大し、
    モノリシックな構造ではユースケースの多様化に対応しにくい
    • ドメインエキスパートと中央のデータエンジニアが組織的に分離していることで、
    ユースケースを実現するスピードが低下し、お互いに不満をもつ対立的な構造となる
    モノリシックデータ基盤
    

    View Slide

20. 分散されたデータ 論理データ統合
    • 物理的に散在するデータを許容しながら多用なユースケースを迅速に実現するために大きく二つの観点を考える
    • 「データは水道のようにどこでも蛇口をひねれば出てくるし、そのまま使えるべき」
    • 『論理的な統合』
    • データの場所を意識せずにアクセスする
    • 『セルフサービス』：
    • 業務知識をもつ専門家自身（あるいはそのチーム内のエンジニア）が自身のスキルセットにあったツールでアクセスでき、必要なデータを信頼でき
    る状態で取り出す
    論理統合とセルフサービス
    物理的に散在したデータに一元的に
    アクセスできる仕組み（APIや連携ツール）
    セルフサービスデータ活用
    ニーズをもった専門家
    自身による使い慣れたツールや
    分析環境での自発的なデータ使用
    物理的な分散を受け入れる
    ＝アクセスが一極集中しないことでスケーラビリティが向上
    Web API
    仮想化
    アクセスポイント
    データ配信
    BIプロジェクト
    アドホック分析
    データサイエンス
    MLプロジェクト
    

    View Slide

21. • 検出、説明性：たとえばECサイトのように
    • 製品は発見が可能な状態（市場化）で、製品を説明するドキュメントを設ける
    • データ契約：たとえばクラウドサービスのように
    • 製品の利用方法と品質の基準（SLA）を定義する
    • 所有者を定め、権限管理を運用し、使用先や品質を監視、統制する（データガバナンス）
    • 相互運用性：たとえばねじや工具のように
    • 別の場所でも同じように使えるための製品規格（フォーマットや列名称など）を定める
    • 例：顧客IDという論理的なビジネス用語は異なる製品であっても一貫して適用されているなど（物理名が異なっていても
    シノニムとして補完されるべき
    • ↑これらを実現するためのデータの可観測性（Data Observability）が注目されている
    ※製品＝データと読み替え可能
    セルフサービスを実現するための
    データ製品指向(Data as Product)
    

    View Slide

22. ガバナンス
    分散データに対し、AIや論理統合を用いてアクセスを抽象化し、大きな一枚の繊維のように企業内のデータを連携させる設計論（ガートナーやIBMなどが定義）
    データファブリック
    分散されたデータ データ統合
    物理的に散在したデータに一元的に
    アクセスできる仕組み（APIや連携ツール）
    セルフサービスデータ活用
    ニーズをもった専門家
    自身による使い慣れたツールや
    分析環境での自発的なデータ使用
    物理的な分散を受け入れ、スケーラビリティを確保
    Web API
    仮想化
    アクセスポイント
    データ配信
    BIプロジェクト
    アドホック分析
    データサイエンス
    MLプロジェクト
    拡張されたナレッジ
    データの発見支援 コンプライアンス適用
    • 拡張されたナレッジ（データカタログ）
    • AIによる自動化された継続的なメタデー
    タ付与とデータに対するナレッジ提供
    • 製品状態/消費状況の監視
    • データ統合
    • 仮想化 or 任意の方法による自動配信
    パイプラインを使用したデータへのアクセス
    • セルフサービスを支援するためのインター
    フェース
    データ観測 プライバシー
    強固な機能連携
    • ガバナンス
    • GDPRなどの準拠
    • アクセス制御などプライバシー保護
    

    View Slide

23. データ製品指向である点はデータファブリックと同様で、必要な機能は類似している。強調されている特徴は
    • データを組織にあわせてドメイン分割し、所有権を確実に定義すること
    • データ間を疎結合にし、ドメイン間のコラボレーションを重視していること（メッシュ生地のイメージ
    データメッシュ
    データメッシュ
    • 生成元に近く、知識のあるドメインエキスパート自身がエンジニアリングを行う
    • データの所有権はその生成元であるドメインオーナーに委任され、ドメインは
    製品としてデータを他ドメインに提供する
    モノリスデータ基盤
    • データの準備は中央データ基盤チームが実行
    • データのプライバシーや配信は中央基盤チームが制御する
    ドメインA
    ドメインB
    ドメインC
    ドメインD
    ドメインE
    ドメインG
    ドメインF
    データインフラ
    データガバナンス
    データ検出と説明（カタログ）
    標準化による相互運用性
    アクセス制御
    ストレージ、パイプライン
    品質保証
    

    View Slide

24. 補足）Zhamak Dehghani氏Data Mesh の代表文献
    24
    How to Move Beyond a Monolithic Data Lake to a Distributed Data Mesh
    (martinfowler.com)
    

    View Slide

25. 全体を横断するガバナンス
    • Microsoft docsではデータ活用シナリオに
    関するリファレンスアーキテクチャを公開
    • 【データランディングゾーン】
    • 【データ管理ランディングゾーン】
    • データメッシュパターンにも触れられており、リ
    ファレンスアーキテクチャはデータメッシュを意
    識したものとなっている
    • Data Mesh 関連のセッションも開催されて
    おり、今後の製品展開も
    レイクハウス、データメッシュ型の基盤をいかに
    スムーズに展開できるかに注力するものと考
    えられる
    Data Mesh @Microsoft
    25
    クラウド規模の分析 - Azure 向けの Microsoft Cloud 導入フレームワーク
    - Cloud Adoption Framework | Microsoft Docs
    複数の
    レイクハウスが
    相互にアクセス
    

    View Slide

26. • ドメイン分割する際に、中央集権：分散のバランスによってデータメッシュの様式
    は、いくつかの粒度が考えられる
    データメッシュスタイル
    • Data Mesh: Topologies and domain granularity | by Piethein Strengholt |
    Towards Data Science
    

    View Slide

27. 高度委任型メッシュ
    代表的なドメイン分割パターン
    • Unlocked: Cloud Scale Analytics
    ドメインA
    ドメインB
    ドメインC
    ドメインD
    ドメインE
    ドメインG
    協調型メッシュ 管理されたメッシュ
    データガバナンス
    データインフラ
    • 各ドメインがPeer-to-Peeにコラボレーションする
    • Pros:
    • ドメインが迅速にデータにアクセスし製品を生成可能
    • 疎結合性により柔軟性が向上
    • Cons:
    • 全ドメインからの協力とデータ活用人材の供給
    （データメッシュが実現しないと言われている原因
    • 分散によるインフラコスト増
    ドメインA
    ドメインB
    ドメインC
    ハブ
    ドメイン ドメインE
    ドメインG
    データガバナンス
    データインフラ
    ドメインD
    ドメインA
    ドメインB
    ドメインC
    ソースデータ
    配布ドメイン
    ドメインE
    ドメインG
    データガバナンス
    データインフラ
    ドメインD
    • ソースデータは専用の配布ドメインで準備、
    提供され、消費者は自由にコラボレーション
    をする（現実的な落としどころとされる
    • Pros:
    • ソースデータへの確実な統制、標準化
    • データ活用シナリオの柔軟性の維持
    • Cons:
    • 複雑なデータ利用パターンの混在
    • 配布ドメインに負担が集中することへの遅延
    • データはドメインに所有されているが、
    すべてハブ上で作業し、連携、消費される
    • Pros:
    • 完全なデータ統制
    • 集約によるコスト最適化
    • Cons:
    • ハブにオンボードするのでコラボレーションが遅
    延し、負担が集中
    • 統制を実現するうえで単一のプラットフォーム
    にロックインする必要がある
    迅速 統制
    

    View Slide

28. • データファブリックとデータメッシュは対立概念ではなく、補完的関係
    • データファブリックは技術革新であり、データメッシュは組織論にフォーカス
    • ファブリックの実現する技術要素はデータメッシュの実現を補助する
    • それぞれがこれまでのビッグデータ基盤の課題に対処しようとする概念である
    • まだまだ新興概念（特にデータメッシュ）であるため、今後もその名称や概念を変えること
    が予想される
    • データ管理の主題である『データを資産としてその価値を高める営み』により、
    企業活動をインテリジェントなものにするという軸は同じ。
    漫然と先進企業と同じ課題にぶちあたるのではなく、色々な概念を通じて適した
    アプローチを選択できるようになりましょう
    まとめ ＠筆者の考え
    

    View Slide

29. • ★データ基盤の新たな潮流：データファブリック ～データとAIの活用を加速させる新たなアプローチ ｜前編 データファブリッ
    クの概要 - アイマガジン｜i Magazine｜IS magazine
    • Data Fabric vs Data Mesh: 3 Key Differences, How They Help and Proven Benefits
    • データメッシュとデータファブリックを実現させるデータガバナンス
    • 拡張データ管理: データ ファブリックとデータ メッシュ (ibm.com)
    • データ・ファブリックとは|アイビーエム (ibm.com)
    • ガートナーの2021年のトップデータと分析トレンド (gartner.com)
    • Using Data Fabric Architecture to Modernize Data Integration (gartner.com)
    • データファブリック:ナレッジグラフのキラーユースケース (datanami.com)
    • ★データファブリックとデータメッシュ：どこが違うのか？｜北原 祐司 / 「データとAIの民主化」を目指すDatabricks｜note
    • データファブリックとは最新のエンタープライズデータアーキテクチャ (k2view.com)
    • James Serra's Blog
    • データ メッシュ: トポロジとドメインの粒度|ピエテイン・ストレングホルト・|データサイエンスに向けて
    (towardsdatascience.com)
    参考リンク集1
    

    View Slide

30. • ★データメッシュの概念について理解する - connecting the dots
    (hatenablog.com)
    • Data Mesh: Centralized ownership vs decentralized ownership |
    James Serra's Blog
    • 成功するデータメッシュの構築 – 単なるテクノロジーイニシアチブ以上のもの|リン
    クトイン (linkedin.com)
    • Data Trends: Comparing Data Fabrics, Data Meshes, And
    Knowledge Graphs – Diffblog (diffbot.com)
    • Data Mesh: The Balancing Act of Centralization and
    Decentralization | by Piethein Strengholt | Mar, 2022 | Towards
    Data Science
    参考リンク集2
    

    View Slide