/home/by-natures/dev*

データ界隈で働くエンジニアとしての技術的なメモと、たまに普通の日記。

2023/03/20 読んだ記事まとめ(データメッシュにおけるデータプロダクトの定義)

家の近くでも桜が咲き始めました。在宅が多いので季節が過ぎるのがあっという間ですが、先週日曜日は天気がよくて散歩日和でした。

今日はデータメッシュについて1つです。経験がないものの知識として蓄えないとと思い、少しずつ目を通しています。

データメッシュは言葉を見かけることは多いのですが、日本ではどの程度広まっているんでしょうか。データ組織のあり方自体を見直す必要があると思うので導入難易度は高そうですが、非中央集権的なデータ管理になるのでデータ提供までのリードタイムが短くなったり、各組織でオーナーシップを持ってデータ管理する分、データ品質の向上も狙えそうな気がします。導入されている組織があったら是非話を聞いてみたいです。

How to model Data Products

データメッシュ(Data Mesh)のデータプロダクトという考え方について深掘りしている記事で、Agile Lab というイタリアのテック系コンサル、およびデータ関連のソフトウェアサービスを提供している企業からの寄稿です。Agile Lab は Data Mesh に強いようで、会社ホームページにも多くの Data Mesh に関するブログが投稿され、witboost というデータプロダクトを管理するアプリケーションも開発しているようです。

medium.com

組織でデータを一元管理するのではなく、各組織がデータオーナーとなってその組織のデータプロダクトの提供を行うというのがデータメッシュですが、何をデータプロダクトにするかを上記記事では解説されています。

データプロダクトにはデータソースから生成されるプロデューサー側と、データ消費者側(ビジネス目的に沿ったもの)の2種類あります。その間に「データを集約したデータプロダクト」を作ることは、この筆者にとってはアンチパターンとされています。理由としてはそのデータプロダクトはビジネス価値をもたらさないことと、この考え方を推し進めるとデータを一元管理することになってしまい、データメッシュのデータオーナーの考え方に反するから、というものです。

記事内では以下のトピックについて詳しく解説されています:

  • 他のデータプロダクトからのデータを再配布しないこと
  • データ集約は、データが属するデータドメイン内で管理される場合にのみ、プロデューサ側で定義可能
  • 同一データプロダクト内で消費者向けの非正規化ビューを作ることは可能
  • ジョインは、意味的変換やビジネスロジックが適用される場合に限り、データ消費者側で定義すること
  • フィルタとプロジェクションはデータ消費者側によって定義すること
  • 技術的な理由やパフォーマンスのために新しいデータプロダクトを作成しないこと