Data Meshと私

JDSCでの勉強会時のスライドです。

Transcript

1. Data と Mesh と私 株式会社JDSC エンジニア　秋山 悟志
2. 自己紹介 秋山　悟志 System Engineer（新卒）-> Web Application Engineer-> Data Scientist -> Data Engineer(今ここ) SEとWAEの間にイラストレータとかもやっていました。
3. 脳が溶けるようなデータパイプラインを設計することになっ た... - 週次運用 ×3(月曜と火曜水曜で処理違う）＋日次運用のコンボ - 数理最適モジュール+UI表示モジュール＋機械学習モジュール＋顧 客側のデータ基盤をそれぞれ連携させる をAirflowといったワークフローエンジンで管理しちゃおう！
4. 今はワンオペ体制なので逆に管理はできるけど.... （いやこれワンオペって...) - 人員や各モジュールをスケールした際に一元管理ってできるか？ - BigQueryやらGCSやらで扱うデータモデルが無限に増えると思う。 lake->warehouse->martと いったアーキテクチャで管理できるか？ - 複雑化、肥大化するほど、１元管理する人材の負担は計り知れなく増大するし、非効率 それぞれのモジュールは本当は性質が違うはず。 けど現在は Appと顧客データ基盤と私（弊データ基盤） というドメインの切り方でデータフロー図を作ってしまっている。
5. Data Meshという考え方 Data Meshとは：それぞれのデータ保持するモジュールをマイクロサービス（Service Mesh)とし て捉え、モノリス化したデータ基盤を切り崩していく。 Data Meshの四原則: 1. ドメイン志向で分散型のデータオーナシップとアーキテクチャ 2. プロダクトとしてのデータ 3. セルフサービス型データインフラストラクチャ・アズ・ア・プラットフォーム 4. 連合型(federate)の計算ガバナンス
6. サイロ化を許容してでもData Meshする？ そもそも、サイロ化とは？ 他者がデータへアクセスする際にとてつもなくコストがかかる、もしくは不可能である状態をさす。 しかし加工の段階(lake->warehouse->mart)によってドメインを分ける やり方こそが、それぞれの連携を希薄化させるのではないか？ 結論：自ドメインのデータをプロダクトとして、責任をもって提 供しよう。
7. やろうとしていること - datalake->datawarehouse->datamartのアーキからの脱却 - 今までwarehouseでの一元管理を行なった結果、どれだけ用途不明のテーブルが堆積していっただろう か... - 各データエンティティがどのドメインに所属しているか、はっきりさせていきたい。 - それぞれのドメインが提供するデータのバージョニング - 欲しいスキーマのデータを常に受け取れるように（GlaphQLのような仕組みがあればいいなぁ...) ただし、これらを初手で導入するとなると多分頓挫する。 標準のプロトコルや標準の規約などを実装した上で段階的にこなしていけばいいと考えて いる。 （普通のマイクロサービスだって、初手で導入するよりモノリスだったサービスをリアーキテククトする文脈で 使われることが多いですよね？）
8. Data Meshにベストプラクティスは（まだ）ない。 - 実ケースに基づくデータのパイプラインを管理するのなら、結局一元管理できた方が良いと思 う - データのガバナンスも含めてこの思想を反映したプラットフォームや実例はない。 俺がベスプラになってやるんだよ！！という気持ち
9. ご清聴ありがとうございました！ 参考： データメッシュの原則と論理アーキテクチャの定義： https://www.infoq.com/jp/news/2021/02/data-mesh-architecture/ Data Mesh Principles and Logical Architecture https://martinfowler.com/articles/data-mesh-principles.html メルカリが「マイクロサービス」に本気で取り組む理由（前編） https://www.sbbit.jp/article/cont1/35635