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

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

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

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

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

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

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

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

• データレイク上で変換用に分散処理フレームワーク（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 解 析 デ ー タ 変 換 デ ー タ 変 換 データ抽出・取込 データ抽出・取込

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

ストレージ層 アクセスしたい データ • 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)

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

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

成り立ちの違いで発展の道筋が異なるが、ビジョンはいずれも データ活用を一つのプラットフォームでシンプル化して実現すること • 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 発展 発展 早期に実現したコア部分 早期に実現したコア部分

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

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

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

• 社内の主要ユーザーの好みや、政治的な問題、あるいは法規制により、 同じ組織内で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

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

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

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

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

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

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

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

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

高度委任型メッシュ 代表的なドメイン分割パターン • 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: • ハブにオンボードするのでコラボレーションが遅 延し、負担が集中 • 統制を実現するうえで単一のプラットフォーム にロックインする必要がある 迅速 統制

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

• ★データ基盤の新たな潮流：データファブリック ～データと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

• ★データメッシュの概念について理解する - 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