【投票キャンペーン対象】Data Contract と Data Mesh で実現するサービス成長をリードするデータ基盤

アーキテクチャを選定した背景や意図

Data Contract を活用した Data Mesh 型基盤を構築することで、「データ品質の向上」と「データチームの管理負荷の軽減」を実現しました。主な利点は、データ連携の複雑性排除とドメイン知識を活用したデータ品質向上の 2 点です。

【背景と課題】

以前のプロダクトデータ連携では、DWH へのデータ取り込みにおいて、データチームがプロダクト DB へ直接クエリを作成し、データを保存・処理していました。しかし、プロダクトが成長しテーブル構成が頻繁に変化するにつれ、データチームがそれに対応して SQL を修正するには、コミュニケーションコストやプロダクトのドメイン知識不足が大きな課題となっていました。

【Data Contract による解決と効果】

そこで、プロダクトデータと DWH の境界に Data Contract を定義し、標準的なデータ連携インターフェースを設けました [1]。
このインターフェースの SQL 定義と管理は、プロダクトの変更に連動してプロダクトチームが責任を持つ形になりました。これにより、データチームはプロダクトの内部スキーマを詳細に把握することなく、定義されたインターフェースから必要なデータを簡単に参照できるようになり、データ連携の複雑性が大幅に排除されました。

また、ドメイン情報に最も詳しいプロダクトチームが、提供するデータの境界と粒度（例：販売・注文・商品情報など）を管理することで、データチームでは難しかったプロダクト固有のユースケースに最適化されたデータドメインを定義できるようになりました。これにより、データ全体の「質」が向上しています。

【具体的な実装】

このインターフェースは、プロダクト DB (Cloud SQL) と BigQuery 上の 同一スキーマの View により構成されており、BigQuery 上の View はプロダクト DB 上の View を Federated Query で参照しています。Cloud SQL 上に View を定義することで、プロダクトチームがインターフェースを直接メンテナンスしやすくなるだけでなく、 BigQuery からの SQL Pushdown [2] が可能になり、クエリパフォーマンスも向上するというメリットがあります。

【まとめ】

このように、データ連携インターフェースを抽象化して定義することで、データパイプラインがプロダクト開発におけるスキーマ変更の影響を受けるリスクを大幅に低減しています。

[1] https://belong-inc.notion.site/191c121f593e80279efdea742fe52998
[2] https://belonginc.dev/members/ttyfky/posts/bigquery-sql-pushdown

現在の課題や今後の改善予定

今後取り組みたい内容は、さらなるデータの収集と、活用のための利用性向上です。

【データ一元化による意思決定の迅速化】

社内ではデータチームが構築・管理する DWH に連携されず、各部署やシステムで個別に利用するデータが存在しています。
これらのデータを DWH へ一元的に集約し、データの一貫性と信頼性を高め、部門横断的な多角的な分析を可能にすることで、迅速かつ精度の高い意思決定へと繋がるデータ活用の促進が実現できると考えています。

【データ活用環境の整備によるセルフサービス文化の醸成】

また、「誰も」がデータにアクセスしやすい環境は整備しきれておらず、積極的にデータを利用し、ビジネスインサイトを導き出せているメンバーは BI をフル活用出来たり、 SQL スキルを持つ一部のメンバーに限られています。
この状況を改善するためには、Universal Catalog などを利用したデータカタログの整備を進め、社内に存在するデータの可視化と利用性向上を目指しています。
また、LLM の活用を推進し、SQL をユーザー自身で書かずとも自然言語で簡単にデータの抽出・分析をが可能な仕組みも整えたいと考えています。これにより、全社員がデータに触れ、そこから新たな価値を創造できるセルフサービス型のデータ活用文化を醸成し、組織全体の生産性と競争力の向上を実現できると期待しています。

◆執筆：小堀僚之　 @tomoyukikkk

【サービス公式サイト】

• にこスマ
• にこスマ買取
• Belong One