Data Meshについての調査
この記事は？
Data Meshと呼ばれるデータアーキテクチャについて調査した記事です。
この記事のまとめです。 だいぶ意訳して、私の解釈が混じっているのでご注意ください。
現在の企業のデータアーキテクチャ
中央化された、モノシリックなアーキテクチャが一般的である。 著者がかかわってきたクライアントによると、データアーキテクチャには失敗してきた過去があるという。
第一世代：独自仕様のエンタープライズDHWとBIツール
高額で技術負債も多く、ビジネスに良い影響が与えられなかった。
例：メンテナンスできないETL、少数しか理解できないレポート第二世代：銀の弾丸としてのビックデータエコシステムとデータレイク
複雑なエコシステムを中央のスペシャリストが管理した。その結果、"データレイクモンスター"が発生した上に、PoC程度しか実現できなかった。
第三世代である今世代は、第二世代に似ているが、いくつか変更点がある。
- Kappaのようにリアルタイムデータへの対応
- Apache Beamのような統一化されたバッチ・ストリーミング処理フレームワーク
- クラウドベースドマネージサービス（ストレージ、パイプライン処理、ML）
これらは前世代のリアルタイムデータ分析のギャップを埋め、インフラコストを抑えた。しかし、前世代の失敗につながった根本的な特徴を引き継いでいる。
データアーキテクチャ失敗パターン
Spotify、SoundCloud、Apple iTunesのような仮想のインターネットメディアストリーミングビジネスのドメインを例として、失敗パターンを述べる。
一元化されモノシリック
このアーキテクチャは次のようなことが目的である。
企業のあらゆるデータを取り込む。運用データやトランザクション、または外部データまでに及ぶ。例えば、メディアストリーミングビジネス（spotify）では、ユーザがどの音楽を聴いたのか、どのアーティストをフォローしているのか、曲名とアーティスト、曲の購入履歴、外部のカスタマーデモグラフィックによる調査データなどである。
データを活用する人のために、データをクレンジングし, 充実させる。例えば、transformationの一つは、ユーザのクリックストリームをある特定のユーザーの詳細で充実した意味のあるセッションにすることである。これはそのユーザーのジャーニーを再構成することができる。
さまざまなニーズを持つさまざまな消費者にデータセットを提供する。 これは、分析的な消費から、洞察を探すデータの探索、機械学習ベースの意思決定、ビジネスのパフォーマンスを要約するビジネスインテリジェンスレポートにまで及ぶ。ディアストリーミングの例では、プラットフォームは、Kafkaなどの分散ログインターフェイスを介して世界中のメディアプレーヤーに関するほぼリアルタイムのエラーおよび品質情報を提供したりできる。
つまり、このデータプラットフォームはドメインの集合と見なることができる。
次のように、このアーキテクチャは2つのプレッシャーポイントがある。
データの急増：データの増加により単一のプラットフォームでコントロールできなくなる。例えば、「顧客情報」のドメインを考えると、顧客は増加しつつけるのでデータは膨らむ。それにより、分析者は膨大な（顧客情報以外のドメインすべてを含めた）データを取りまわさなければいけなくなる。
データのユースケースの急増：これにより、ETLパイプライン、そのテストが肥大化することを意味する。これは、データのに対する新しい要求を実装するレスポンスを悪化させる。
上記からわかることは、一元化されたチームが一元化されたプラットフォームですべてのドメインのデータをコントロールするのは難しいということである。
パイプラインの分割
2番目の問題はパイプラインの分割が難しいことである。一般的にデータの処理ステージに沿って分割されることが多い。例えば、収集、前処理、集約、サービングなどである。
しかし、このアーキテクチャは前段階の対応が終わらなければ行動できないので、ある程度しかスケールしない。なぜならば、ドメインに対して直行しているからである。
メディアストリーミングの例でいうと、”ポッドキャストの再生率”という特徴量を追加しようとすると、パイプラインのすべてを変更する必要がある。なぜならば、各ステージのチームから見ると新しいデータを取り込むならば影響範囲の特定などにより、そのステージ全体を確認する必要があるからである。このとき、構造的な最小単位(architectural quantum)は各ステージ全体である。これが、データに対して柔軟に反応することを阻害する。
分断されたオーナーシップ
3つ目の問題は、データのオーナーシップが分断されていることである。例えば、データエンジニアのグループは様々な場所で分断されている。例えば、データの発生する場所とデータが分析に活用される場所で。さらに、データツールなどの専門知識などによっても細分化されることもある。これらのエンジニアは、多くの場合ビジネスやドメインの知識はない。
メディアストリーミングの例でいうと、サービスを運営しているチームがあり、そこから伸びているデータパイプラインの端にKPIを使って意思決定するチームがある。その真ん中でデータプラットフォームチームがサービスチームと隔離され、KPIチームからは要求をぶつけられて苦しんでいる。
次世代のエンタープライズデータプラットフォームアーキテクチャ
パラダイムシフトが必要である。分散ドメインアーキテクチャ、セルフサービスプラットフォーム設計、データ分析を前提としたプロダクトシンキング。これらを掘り下げていく。
データと分散ドメイン駆動アーキテクチャの出会い
ドメインに基づくデータ分解とオーナーシップ
エリック・エバンスの「ドメイン駆動設計」
はビジネスドメイン機能を中心としたマイクロサービスアーキテクチャを世に知らしめた。
データアーキテクチャもドメインに基づいて考えてみよう。そうすると、逆の発想が生まれる。ドメインからデータレイクへデータを流すのではなく、ドメインがデータをホストして、提供するのである。 （ドメインがpushするのではなく、ドメインからpullする。）
メディアストリーミングの例を考えてみよう。ドメインが一元化されたデータレイクとそのチームにデータをながすのではなく、ホストとしてどのチームがどんな目的でも使用できるように提供する。つまり、オーナーシップはデータを生み出すドメイン自身が持つ。ドメイン同士のデータ連携も考えられる。”レコメンデーション”ドメインがあるデータベースを作成し、ほかのあるドメインがそのデータを使ってサービスを作り、新たにデータをホストすることもあるだろう。
これは伝統的なpush and ingestなETLから、ドメイン間のserving and pullへの発想の転換である。このとき、構造的な最小単位(architectural quantum)はドメインに基づくデータプラットフォームである。
ソース志向のドメインデータ
ソースドメインデータセットとは、ビジネスファクトを表す。ソースドメインデータセットは運用システムが生み出したものと密接にマッピングされたデータを捉える。例えば、”どのようにユーザがサービスとインタラクトするか”というビジネスの実態は、”ユーザクリックストリーム”というドメインデータセットを生み出す。これらの実態は、運用システムが最もよく理解している。例えば、メディアプレイヤーシステムは”ユーザークリックストリーム”について最もよく知っている。
理想的には、運用システムとそのチームはビジネスを提供するだけでなく、ソースドメインデータセットとして、ビジネスドメインの真実を提供する責任がある。企業レベルのスケールでは、システムとドメインは1対1で結びついているわけではなく、多対1で結びついており、レガシーなシステムもあれば、変更が容易なシステムもある。よって、このドメインに沿って、複数のシステムのデータが集計され、そのドメインのビジネスファクトを表す、ソースアラインドデータセット（またの名をリアリティデータセット） が存在するだろう。
ビジネスファクトはドメインイベントとして表現され、分析者がアクセスできる分散ログとしてストアされ提供される。
ソースドメインデータセットは最も基礎的で、変更されることは少ない。なぜならば、ビジネスファクトが変更されることは少ないからだ。これらのドメインデータセットは永遠にキャプチャされ、利用可能にされることが期待される。よって、いつでもビジネスファクトに戻って、新しい集計やプロジェクションを作成できる。
ソースドメインデータセットは生成された時点の生のデータを表し、分析向けに変換されたものではない。
分析者向けの共有されたドメインデータ
あるドメインで作成された分析データがほかのドメインで使われることもある。例えば、”ソーシャルレコメンドドメイン”は”ユーザのソーシャルネットワークのグラフ表現”というデータを作ったとする。このデータは”リスナーノーティフィケーション”ドメインで役に立つかもしれない。ソーシャルネットワークのユーザが何を聴いているか知らせる機能だ。つまり、”ユーザソーシャルネットワーク”は共有された具体的なドメインデータセットとして多数の分析者に使われる。”ユーザソーシャルネットワーク”ドメインチームは、自身のビジネスでこのデータを使っているので、自然とデータがメンテナンスされる。
このような分析者に沿ったドメインデータセットはソースドメインデータセットとはことなる性質を持つ。ソースドメインデータセットを変換し、特定のアクセスモデルに適合するようにビューを集約する。ドメイン志向データプラットフォームはこれらの分析者用データセットをソースから簡単に再構成できる。
ドメインの内部実装としての分散パイプライン
各ドメインそれぞれがETLパイプラインを持つ。これは、分散パイプラインとみさせる。
これにより、従来ではETLパイプラインの集約ステージで一元化されていたロジックが、各ドメイン内のパイプラインにうまく分解できる。
しかし、「分散することにより、同じ処理を各ドメインのパイプラインでそれぞれ開発してしまい努力の無駄になるのでは」、という懸念もあるだろうが、DataAndSelf-servePlatformDesignConvergenceの章で解説する。
データとプロダクトシンキングの出会い
データのオーナーシップとパイプラインをビジネスドメインの手に分散させることにより新たな懸念が生まれる。アクセシビリティ、ユーザビリティ、データ同士の調和などである。ここは、プロダクトシンキングが役に立つ。
製品としてのドメインデータ
運用ドメインは、機能をAPIとして提供することがある。そして、APIのドキュメントがまとめれ、テストされ、使用経過をKPIとして確認する。
分散データプラットフォームを成功させるには、ドメインデータを提供するときにも同じ思考を適用する必要がある。データ資産を製品とみなし、組織のほかのデータサイエンティスト、MLモデル、データエンジニアを消費者とみなす。
メディアストリーミングの例を考える。重要なドメインとして、”再生イベント”がある。だれが、いつ、どこで、どの曲を再生したかである。このドメインには、組織内の様々な消費者がいる。例えば、カスタマーサポートのためにリアルタイムにアクセスする消費者もいれば、日次や月次で分析するためにアクセスする消費者もいる。この場合、それぞれの要望に応えるため”再生イベント”ドメインは2つの異なるデータセットを提供する。
サービス運用の目的が、市場の消費者を喜ばせることであるように、ドメインデータを社内に公開することの目的は、社内の消費者、データエンジニア、MLエンジニア、データサイエンティストを喜ばせることである。このとき、ドメインデータプロダクトは次のような品質を備えている必要がある。
発見可能
データプロダクトは簡単に見つけられなければならない。一般的な実装は、データカタログを作ることである。所有者、ソース、リネージュ、サンプルデータセットが記載されている。この一元化されたカタログにより、組織内のデータ消費者は簡単にデータセットを見つけられる。すべてのドメインデータプロダクトは、このデータカタログに登録しなければならない。データリネージュをメタデータとして提供することも、消費者の信頼を得るのに役だつ。
アドレッサブル
データプロダクトは一意のアドレスを持つ必要がある。すべてのデータプロダクトに共通した命名規則を開発する必要がある。
信頼して使えるデータ
そのドメインデータがどれだけ信頼できるかをSLOで保証する。SLOを保証するため、データ作成時に、データクレンジングや自動データバリデーションを作成することは有効である。
自己記述型のセマンティクスと構文
相互運用可能であり、グローバルスタンダードに準拠
分散ドメインデータアーキテクチャの主な懸念事項の1つは、ドメイン間でデータをどうやって結合させるかである。これには、全社で一つの標準に従う必要がある。この標準化は、フォーマッティング、同音異義語の区別、データのアドレス規則、共通メタデータ、CloudEventsのイベントフォーマットなどである。
安全にアクセスできる
各ドメインデータプロダクトごとにアクセス制御される。SSOやロールベースアクセスコントロールポリシー定義はアクセス制御の実装として便利である。
ドメインデータのクロスファンクショナルチーム
ドメインは新しいスキルセットが必要である。データプロダクトオーナーとデータエンジニアである。データプロダクトオーナーは、データプロダクトのロードマップを決定し、消費者の満足度に関心を持ち、ドメインデータプロダクトのKPIを継続的に測定し改善する。ドメインデータセットのライフサイクル、データスキーマの変更、廃止を担当し、消費者のニーズに応じて優先度付けをする。
データプロダクトオーナーは、データプロダクトとビジネスそれぞれのKPIを定義する。例えば、消費者がデータを発見して使い始めることができるリードタイムは前者のKPIとして適当だろう。
分散パイプラインをドメインの内部に構築するため、チームはデータエンジニアを必要とする。素晴らしい副次効果として、エンジニア間のスキルの融合がある。例えば、データエンジニアはデータツールの使い方走っているが、CI/CDや自動テストには疎いことがある。逆にソフトウェアエンジニアはデータエンジニアツールを使ったことがないことがある。スキルセットのサイロを取り除くことにより、組織に深いエンジニアリングスキルセットが構築される。
データとセルフサービスプラットフォームデザインの出会い
データのオーナーシップをドメインに分散することの主な懸念点の1つに、各ドメインで作業が重複することである。解決策はドメイン横断で使えるインフラを作ることである。
このようなデータインフラストラクチャを構築するポイントは、次の点である。
データインフラストラクチャコンポーネントは次のようなものである。
- スケーラブルなポリグロットビッグデータストレージ
- 保存中および移動中のデータの暗号化
- データプロダクトのバージョン管理
- データプロダクトスキーマ
- Data product de-identification
- 統合されたデータアクセス制御とロギング
- データパイプラインの実装とオーケストレーション
- データプロダクトの発見、カタログの登録および公開
- データガバナンスと標準化
- データプロダクトリネージュ
- データプロダクトの監視/アラート/ログ
- データプロダクトの品質メトリクス（収集と共有）
- インメモリデータキャッシング
- フェデレーションID管理
- 計算とデータの局所性
データインフラストラクチャの目的は、新しいデータプロダクトを作成するためのリードタイムを短縮することである。このために、製品としてのドメインデータの章で説明されている、データプロダクトを実装するために必要な自動化を実現する。
データメッシュに向けたパラダイムシフト
データメッシュの全体像を以下に示す。
エンタープライズ規模の採用にはまだ長い道のりがあるだろうが、その原因はテクノロジーではないと思う。現在のツールで複数のチームによるオーナーシップと分散は可能である。特に、バッチの統一やストリーミングへのシフトとツール、Apache BeamやGoogle Cloud Dataflow、は簡単にaddressable polyglot datasetsを簡単に処理できる。
Google Cloud DataCatalogなどのデータカタログプラットフォームは、分散ドメインデータセットの一覧化、アクセスコントロール、ガバナンスを提供する。
パラダイムシフトの要点は次である。
- かき集めるのでなく、提供する（serving over ingesting）
- 抽出して読み込むのではなく、発見して使う（discovering and using over extracting and loading）
- 一元化されたパイプラインにデータを流すのではなく、ストリームとしてイベントを発行する
- 一元化されたデータプラットフォームではなく、データプロダクトのエコシステム
追記
データメッシュの企業採用の一例としてAirbnbの記事があります。
