data vaultを用いたマルチプロダクトのためのデータ基盤開発

10X, Inc. ALL RIGHTS RESERVED data vault を用いたマルチプロダクトのためのデータ基盤開発 2025/09/24
みんなの考えた最強のデータ基盤アーキテクチャ第5回水谷優斗

10X, Inc. ALL RIGHTS RESERVED data vault どういうイメージですか？ 3 •
なんかすごいっぽい

なんかすごいっぽい • ハードル高そう

なんかすごいっぽい • ハードル高そう • 一時期よく聞いたけど最近そんなに聞かない...?

なんかすごいっぽい • ハードル高そう • 一時期よく聞いたけど最近そんなに聞かない...? • 実例が少なくて生の声を聞く機会が少ないから採用しづらい

10X, Inc. ALL RIGHTS RESERVED 生の声やってきました 8 • データ分析基盤として3年以上運用してきました ◦
並行運用期間もあるが、 data vault 1本でも1年以上経過した ◦ 機を見計らったかのようなブログもでました (心より感謝) ▪ 今日も京都から駆けつけてくれてます

並行運用期間もあるが、 data vault 1本でも1年以上経過した ◦ 機を見計らったかのようなブログもでました (心より感謝) ▪ 今日も京都から駆けつけてくれてます • 新規事業のデータ基盤(データパイプライン)としても採用しました

並行運用期間もあるが、 data vault 1本でも1年以上経過した ◦ 機を見計らったかのようなブログもでました (心より感謝) ▪ 今日も京都から駆けつけてくれてます • 新規事業のデータ基盤(データパイプライン)としても採用しました • 教科書には載っていないリアルな運用体験談もたくさんあるので懇親会で聞いてくれ！

10X, Inc. ALL RIGHTS RESERVED 自己紹介 • 水谷優斗 ◦
idは @tenajima ◦ テナジマって呼んでね • 株式会社 10X でデータエンジニア ◦ 2023/02 入社 ◦ データパイプラインの開発をメインに仕事をしています ◦ 直近の仕事内容や、働き方はこちら • 来年頭に滋賀県に移住予定なので、残り少ない関東生活で顔を売りにきました 11

10X, Inc. ALL RIGHTS RESERVED ネットスーパーを利用いただいているパートナー 12 10Xについて食品スーパー食品スーパー
ドラッグストアライフ近畿・関東地方フレスタ中国地方アルビス北陸地方デリシア中部地方平和堂近畿地方オギノ中部地方丸久中国地方フジ中国・四国地方マミーマート関東地方とりせん関東地方薬王堂東北地方スギ薬局関東・中部・関西地方準備中 Comming Soon リリース準備中

10X, Inc. ALL RIGHTS RESERVED こんなデータパイプラインじゃスムーズに提供できない 22 (パートナー数) × (プロダクト数)
のパイプラインを作らなきゃいけない ↓ 10X のデータエンジニアがボトルネックになる

10X, Inc. ALL RIGHTS RESERVED なぜ data vault を採用したか •
複数のデータソースが絡む履歴管理を一定のルールに従って管理できる ◦ 履歴が絡むデータの扱いを data vault が体系化してくれている ◦ 複数の load_timestamp から1つの load_timestamp を決定しなければならない時など ◦ 創意工夫を凝らして乗り越えるリソースを他に回せる 24

複数のデータソースが絡む履歴管理を一定のルールに従って管理できる ◦ 履歴が絡むデータの扱いを data vault が体系化してくれている ◦ 複数の load_timestamp から1つの load_timestamp を決定しなければならない時など ◦ 創意工夫を凝らして乗り越えるリソースを他に回せる • 全件更新でも差分更新でも統一的な考え方でデータを管理できる ◦ マスタの最新の状態を共有されるものもあれば、変更があった時のみ変更区分とともにレコードが送られてくることもある ◦ パートナーごとに決まってるわけでもなく、パートナーの中でも両方存在し得る 25

複数のデータソースが絡む履歴管理を一定のルールに従って管理できる ◦ 履歴が絡むデータの扱いを data vault が体系化してくれている ◦ 複数の load_timestamp から1つの load_timestamp を決定しなければならない時など ◦ 創意工夫を凝らして乗り越えるリソースを他に回せる • 全件更新でも差分更新でも統一的な考え方でデータを管理できる ◦ マスタの最新の状態を共有されるものもあれば、変更があった時のみ変更区分とともにレコードが送られてくることもある ◦ パートナーごとに決まってるわけでもなく、パートナーの中でも両方存在し得る • 新しく連携されるデータが出てきた時に、既存のデータに影響なくデータを追加できる ◦ satellite を生やしてあげれば良い 26

10X, Inc. ALL RIGHTS RESERVED なぜ data vault を採用したか(ここも重要) •
チームとして3年以上運用してきた経験があるので、data vault の「型」に従って実装・コミュニケーションした方が、より早くより良いものが提供できると判断した • データ量がそれほど大きくない 27

10X, Inc. ALL RIGHTS RESERVED 現在の設計(adaptor vault) 29 • パートナー別に
data vault で作られる部分 • パートナーごとの個別性を吸収する責務を持っている • 実体化されるのは adaptor vault の raw vault のみ • SQL の自由度があるのは raw stage と business vault の部分のみ • raw stage でハードビジネスルールが意図通りに処理されているかのテストを行う • business vault で作られたモデルは data vault の制約を満たしているかのテストを行う ◦ hub の pk が守られているか ◦ sat は同じ load timestamp に対して pk が重複していないか

10X, Inc. ALL RIGHTS RESERVED 現在の設計(domain vault と output port)
30 • adaptor vault でパートナー別に処理したものをraw vault として集約する • パートナーを横断して小売に共通するロジックを集約するのが domain vault の責務 • domain vault 内の business vault でロジックを実装し、テストも business vault に対して行う • output port はアプリケーションとやり取りするためのレイヤーになる ◦ data contract を結ぶ層 ◦ ここでは履歴を保持したままにする

10X, Inc. ALL RIGHTS RESERVED 運用時に特に意識していること • できるだけ実体化しない ◦ 究極
adaptor vault の raw vault 以外は実体化したくない ◦ 実体化するものが増えるだけオペレーションが増えうる ▪ 最後の砦としてデータマイグレーションもすることを厭わないが、その際できるだけオペレーションミスを減らせるようにしたい • 実行の再現性を担保する ◦ データ分析基盤では full-refresh すると過去の履歴を一気に吹き飛ばす必要があるということがあった (参照) ◦ パートナーからもらったデータが日別で残る設計なので、そこから履歴を復元できるようにしている ◦ 考慮漏れがあった際に安心して履歴をやり直せることが今後運用していく点でも、精神衛生上もとても大切 31

10X, Inc. ALL RIGHTS RESERVED 今後の展望 • data vault と
LLM の相性の良さ ◦ レイヤーごとのルールが厳密なので LLM にも理解してもらいやすい ◦ raw vault の書き方に自由度がなく機械的なので LLM も生成しやすい • パートナーの個別性吸収は LLM に丸っとお願いしたい ◦ 「パートナーにどのようにデータをもらうか」という入口と「パートナー共通ロジックに必要な要素」という出口が決まっているので LLM にコードを丸投げできるはず ◦ パートナーが増えてもデータパイプラインの実装がスケールするにはとても重要な要素になる ◦ この部分の探索が今後の鍵になる 32

LLM の相性の良さ ◦ レイヤーごとのルールが厳密なので LLM にも理解してもらいやすい ◦ raw vault の書き方に自由度がなく機械的なので LLM も生成しやすい • パートナーの個別性吸収は LLM に丸っとお願いしたい ◦ 「パートナーにどのようにデータをもらうか」という入口と「パートナー共通ロジックに必要な要素」という出口が決まっているので LLM にコードを丸投げできるはず ◦ パートナーが増えてもデータパイプラインの実装がスケールするにはとても重要な要素になる ◦ この部分の探索が今後の鍵になる • とはいえ domain vault 以降のプロダクトが増えるごとに作っていかなければならない部分はまだ始まったばかり & ここは人間がモデリングすることがたくさんある 33

LLM の相性の良さ ◦ レイヤーごとのルールが厳密なので LLM にも理解してもらいやすい ◦ raw vault の書き方に自由度がなく機械的なので LLM も生成しやすい • パートナーの個別性吸収は LLM に丸っとお願いしたい ◦ 「パートナーにどのようにデータをもらうか」という入口と「パートナー共通ロジックに必要な要素」という出口が決まっているので LLM にコードを丸投げできるはず ◦ パートナーが増えてもデータパイプラインの実装がスケールするにはとても重要な要素になる ◦ この部分の探索が今後の鍵になる • とはいえ domain vault 以降のプロダクトが増えるごとに作っていかなければならない部分はまだ始まったばかり & ここは人間がモデリングすることがたくさんある ◦ 今！またとない事業機会に溢れている！ 34

data vaultを用いたマルチプロダクトのためのデータ基盤開発

data vaultを用いたマルチプロダクトのためのデータ基盤開発

More Decks by tenajima

Featured

Transcript