©2023 10X, Inc. 10Xでのデータ基盤の変遷と これから データマネジメントのリアル 〜BtoB企業3社の歩みとこれから〜 株式会社10X Yasuhisa Yoshida

©2023 10X, Inc. 自己紹介 ● 吉田 康久 ○ Twitterやはてなidは@syou6162 / id:syou6162 ● 株式会社10Xでデータエンジニア ○ 2022/09に入社。入社して2年が経ちました ○ エンジニアリング本部 データ基盤チームに所属 ○ データマネジメント / データガバナンスの仕事をしてます ○ 京都から働いてます ● これまでの職歴としては研究者(NLP & ML) => Webアプリケーションエンジニア / MLエンジニア => アナリティク スエンジニア / データエンジニア ● コミュニティ活動を色々やってます ○ datatech-jpというコミュニティの運営をやってます。Slackを中心に活動、1450人の参加者がいます ○ dbt Community spotlight & Google Cloud Champion Innovatorに選出されました ○ 先月「全日本dbt-osmosisを愛でる会」というめちゃくちゃニッチな勉強会を開催しました 2

©2023 10X, Inc. 提供プロダクト お客様アプリ ● 数万SKUから商品からスムーズにカゴを作成できるUX ● キーワード・カテゴリ検索・お気に入り・注文変更・ 購入履歴といった基本機能 ● 商品の受け取り方法を選択 ● 注文状況・配達状況の確認や通知 ● Web(オプションにて提供) 数万点のSKUから スムーズにお買い物ができるUXを提供 主な機能 3

©2023 10X, Inc. 提供プロダクト スタッフアプリ ● ピッキングリストを自動生成 ● 移動距離最短化、複数スタッフに並行作業可能 ● バーコード照合でのヒューマンエラー防止をサポート ● 多様な受け取り方法に対応 ミスが少なく効率的な 業務オペレーションシステムを提供 主な機能 4

©2023 10X, Inc. 提供サービス 商品・在庫ロジック 構築 マスタの半自動生成 店舗でのお買い物に限りなく近い品揃えを実現 半自動の商品在庫マスタ生成プロセスを提供し 欠品と運用コストを削減 データソース特定 データI/F開発 アルゴリズム開発 日別店別 在庫マスタ生成 発注データ 販売データ 廃棄データ 販促データ 店舗A 店舗B 店舗C 店舗D Stailerと つなぐ I/Fの開発 アルゴリズムの 開発 販促情報 発注周期 品揃除外 etc. 5

©2023 10X, Inc. 6 Stailer Flywheel w/Lever - 事業成長のはずみ車とレバー パートナー シップ締結 Engagement Accessibility Capacity Accessibility Selection Discovery Growth 投資リソース の最大化 More Capacity More Order More AOV 初回利用者の獲得 キャパシティの最大化 品揃え/価格最適 化 ディスカバリー最大化 関係の強化 店舗/エリア/アクセ スの開設 スロットキャパシティの増加 満便率の増加 継続利用者の増加 利用頻度の増加 かご単価の増加 再投資

©2023 10X, Inc. 前置き: 組織とデータ基盤に対する私の考え ● 最強のデータ基盤というものは存在しない ○ 正確には「任意のタイミングの任意の組織に対する最強のデータ基盤は存在しない」と私が思っている ● 以下の要素によって、データ基盤のよさ(適切さ)は変動し得るもの ○ 対象となる組織や事業構造 ○ 組織や事業のフェイズ ○ 開発するチーム / データを活用するチームのケイパビリティ ● ある事業 / 組織の特定の時期に「最適な」データ基盤は目指すことができるはず ● 株式会社10Xというスタートアップで、約4.5年という期間の間、どういったデータ基盤が存在し、それぞれ何を志向 して、運用していく中でどういった課題が出てきたかを紹介 ○ その時期には最適であったと判断した結果の推移 ○ みなさんの会社に合うものがあったら幸いです ● 現状の課題を受けて、さらにどういった取り組みをしていこうとしているか紹介 7

©2023 10X, Inc. アジェンダ ● 前置き: 組織とデータ基盤に対する私の考え ● データパイプラインの変遷: 年表と各世代の特徴を見ながら ○ レイヤリングの改善例 ○ 品質の可視化により、どこで何のテストをすべきか決めていく ○ 撤退のしやすいレイヤリングや運用方法 ● 今後の取り組み ○ 出口の改善: Data Reliability Level ○ 入口の改善: Data Contract 8 データパイプライン ダッシュボード / 各分析のユースケース データソース これまで改善してきたこと 今後の取り組み(出口の改善): Data Reliability Level 今後の取り組み(入口の改善): Data Contract

©2023 10X, Inc. データパイプラインの年表 9 (恐しいことに)4.5年の間で 5つのデータパイプラインが存在していた...!

©2023 10X, Inc. Digdag時代 ● できた背景 ○ 大量のデータを対象にしたFirestoreでのデータ抽出はやりやすくなかったため、BigQueryにデータを同期 ■ RedashからBigQueryのデータを参照 ■ Digdag on GKE上でデータパイプラインを組む ○ 対象となるパートナー数もまだ少なく、出すべき指標もシンプルかつ多くなかった ● 関わっていたメンバー ○ 開発メンバー、アナリスト ● よかったポイント ○ 開発メンバーが慣れているGKE上で動作するため、初速が出る ○ 金銭面での増加はほとんどない ● 露呈してきた難しさ ○ 徐々にアナリストがクエリを書くことが増えてきたが、アナリストにGit + Digdagは開発難度が高い ○ Digdagはリネージの可視化ができず、クエリの認知負荷が大きい ○ テストが書きにくいため、リファクタリングや機能追加がやりにくい 10

©2023 10X, Inc. dbt(v0)時代 ● できた背景 ○ この時期もある程度決まったデータ抽出が目的の中心 ○ 商品在庫マスタでdbtを先行して使い始めており、リネージやテストのありがたさを実感 ○ データ分析でもdbtのご利益を受けたい ● 関わっていたメンバー ○ アナリスト ○ データエンジニア ● よかったポイント ○ dbt Cloudを利用することで、エンジニア以外の職種の方も開発に参加しやすくなった ○ リネージ可視化により、依存関係が分かりやすくなった ● 露呈してきた難しさ ○ ある程度決まったデータ抽出だけでなく、探索的なデータ分析をしたいケースが増えてきた ■ Growth本部ができるなど、分析ニーズが高まってきた ○ ざっくりとした金額くらいしか分からず、分析軸が設計されていないため、深掘り分析ができない 11

©2023 10X, Inc. dbt(v0.1)時代 ● できた背景 ○ 分析ニーズの高まりにより、探索的なデータ分析をしたいケースが増えてきた ● 関わっていたメンバー ○ データエンジニア(データエンジニアに職種を変えたばかりで、当初はデータモデリングに詳しいわけではな かった) ● よかったポイント ○ 探索的なデータ分析をするためのテーブル(例: fact_ordersやdim_users)ができた ○ BizDevを含め、社内で割と広く使われる形になった ● 露呈してきた難しさ ○ fact_ordersやdim_usersなどディメンショナルモデリングっぽい名前ではあったが、洗練はされていなかった ■ factテーブルが大福帳になり肥大化、メンテナンスがしにくくなった ■ dimensionalテーブルはSCD Type 2のような履歴を管理できるわけではない ■ 設計が練れておらず、外部キーの命名規則がバラバラで、どのキーでJOINすればいいか分かりにくい ○ ビジネスプロセスがモデリングできておらず、適切な抽象化ができていない ○ SSoTが徹底できておらず、各マートでロジックがバラバラで数字が合わない ■ パートナー数の増加もあり、問題が顕在化してきた ■ 「テストが書きやすければ、テストが書かれる」とは限らない 12

©2023 10X, Inc. dbt(v0.2)時代 ● できた背景 ○ 設計が練れていないディメンショナルモデリングのテーブルの運用が辛くなってきた ○ 適切なビジネスプロセスのモデリングの欠如 ● 関わっていたメンバー ○ データエンジニア、アナリティクスエンジニア ● よかったポイント ○ 分析におけるEntityは何かやビジネスプロセスをきちんと考えて設計ができる / しやすくなった ■ Data Vaultによる恩恵も大きい ○ 「少数の巨大なテーブルを頑張ってメンテナンス」ではなく「小さいが、よくテストされた使い勝手がよい テーブルを組み合せて使う」という思想になってきた ● 露呈してきた難しさ ○ 初期のオンボーディングコストの高さ、開発メンバー間のスキルギャップをどう埋めるか 13

©2023 10X, Inc. dbt(v0.2)の初期のレイヤリング 14 データレイク Staging Raw Vault Business Vault Data Mart Fact / Dim 重複の削除 / CamelCaseから snake_caseへの変換などを行なう Data VaultによるEntityやビジネスモデリングを定義 ディメンショナルモデリング 特定の用途やダッシュボード用のテーブル。大 福帳テーブル(OBT)は提供しない

©2023 10X, Inc. ビジネスモデリングを行なうレイヤーを明示的に導入 15 データレイク Staging Raw Vault Business Vault Data Mart Fact / Dim サービスや組織の活動をどうビジネスプロセスとしてモデリングするか、Entityとして何 を切り出すか、それぞれの接続をどう表現するか、ということを明示的に考えるレイ ヤーができた(Data Vaultのおかげ)。 よくテストされた小さいパーツをどう組み合わせて使うか、という発想に変わってきた。

©2023 10X, Inc. 運用していく中で辛みも発生... 16 データレイク Staging Raw Vault Business Vault Data Mart Fact / Dim 様々なData Martの要望を叶えるため、個別要 件に近い要素がFact / Dimに入ってきだした。メ ンテナンスが困難になり、品質も落ちてきた...

©2023 10X, Inc. メタデータ(elementary)を駆使し、現状の課題を定量化する 17 コード含めた詳細はこちらを 参照してください 「データセットA / B / Cは特にテストが多いが、データ セットCはvalidity(妥当性)に関するテストが圧倒的に 少ない」 テーブル生成の過程やテストに関するメタデータにさっと アクセスできると、データ品質指標の可視化もさっとできる!

©2023 10X, Inc. 分析結果を言語化 18 データレイク Staging Raw Vault Business Vault Data Mart Fact / Dim validity(妥当性)のテストが想定以上にあることが分かっ た。Data Mart内に個別のビジネスロジックが書かれてい るのがよくない! ビジネスロジックやそれに関するテストも似たようなもの が多数できてしまってSSoTになってない...

©2023 10X, Inc. 分析結果と言語化を元にレイヤリングの改善 19 データレイク Staging Raw Vault Business Vault Data Mart Fact / Dim Data MartはFact / Dimに依存しない形で切り離 してあくまで汎用的な分析用途にする ロジックはBusiness Vaultに固めることで、SSoTを保つ。 Raw / Business VaultはビジネスプロセスやEntityを強く意識 し、よくテストされた小さいパーツになるように設計。 Data Martでは基本的にロジックを書かない。 Raw / Business VaultのパーツをJOINした際に意図せずfan-outし ていないかなどのnot_null / uniqueのテストに留める 詳しくは「Elementaryを用いたデータ品質の可視化とデータ基盤の運用改善」や 「データマネジメントを支える武器としてのメタデータ管理」を参照してください。

©2023 10X, Inc. 露呈してきた難しさとの向き合い方 ● データ基盤の開発チーム向け ○ チーム内で開発者向けのディメンショナルモデリング勉強会を実施 ■ 初めて実装するメンバーがいる時にはモブプロでサポート ○ Data VaultのEntityの切り出しやビジネスプロセスのモデリングに迷ったら、Design Documentを書く ■ そもそもどういう案が考えられるか、松竹梅などで案出し ■ 設計の議論過程がドキュメントとして残し、今後の設計の参考にしやすくする ○ 整備したレイヤリングが今後崩れないようにCIでガードレールを設ける ● BizDev向け ○ 活用者向けのディメンショナルモデリング勉強会を実施 ■ 「そもそも10Xではなぜ大福帳テーブルを提供していないか」といった背景を説明 ○ 10Xでは元々簡単なSQLであればBizDevも日常的に書く文化があったという背景もある ○ その他、データアンバサダー企画を行なうなど、社内のデータリテラシーやケイパビリティの引き上げを行な う活動も同時並行で行なう 20 活用者に向き合うことももちろん重要だが、 成果物を正しく活用してもらえるように活用者の ケイパビリティを上げることも重要!

©2023 10X, Inc. dbt(adhoc)時代 ● できた背景 ○ スピード重視、スポットでの分析がBizDevからの要望が多くなった ■ スプレッドシートの情報とJOINしたい、など ○ 他の目的で使うことは少ないことが想定されるので、dbt(v0.2)でのモデリングの時間を取りたくない ● 関わっていたメンバー ○ アナリスト ● よかったポイント ○ アナリストがData Vaultを知らなくてもクエリを書ける ● 露呈してきた難しさ ○ さっと作れるのはいいが、撤退のルールを決め切れていなかったため、技術的な負債が溜りやすい ○ パフォーマンスが悪かったり、クエリコストが高いテーブルができやすい 21

©2023 10X, Inc. 観点毎のまとめ: 22 Digdag dbt(v0) dbt(v0.1) dbt(v0.2) dbt(adhoc) 注: 左上ほど時間軸が古く、右下ほど最近

©2023 10X, Inc. 観点毎のまとめ: 開発状況 / 撤退状況 23 Digdag dbt(v0) dbt(v0.1) dbt(v0.2) dbt(adhoc) 2020年に開発開始、 2024年に撤退完了 2021年に開発開始、 2023年に撤退完了 2022年に開発開始、 現在の主戦力 注: 左上ほど時間軸が古く、右下ほど最近 2022年に開発開始、 現在は撤退活動中 2023年に開発開始、 現在は補助的な存在

©2023 10X, Inc. 観点毎のまとめ: 分析ニーズの変化 24 Digdag dbt(v0) dbt(v0.1) dbt(v0.2) dbt(adhoc) 型が決まったデータ抽出が中心 探索的なデータ分析ニーズの高まり よりスピード感が必要とされる スポットの分析 注: 左上ほど時間軸が古く、右下ほど最近 ニーズに合わせた形で成果物を作ったため、幸いにしてどの世 代でも「使われないデータ基盤」にはならなかった。 全般的には型が決まったものから探索的なニーズへの対応に変 化してきた。 一方で、高いデータ品質の成果物を提供するために 固く作る方法も模索してきた。

©2023 10X, Inc. 観点毎のまとめ: 作っている人の変化 25 Digdag dbt(v0) dbt(v0.1) dbt(v0.2) dbt(adhoc) プロダクト側の 開発チームが中心 アナリスト + データエンジニア データエンジニア + アナリティクスエンジニア 注: 左上ほど時間軸が古く、右下ほど最近 データエンジニア アナリスト ニーズの変化に合わせて、作っている人が 変わったり職種も変化。より分析寄りかつ分析のた めの設計ができるケイパビリティが求められるよう になってきた。 ニーズに対してケイパビリティが足りない場合は採 用、社内の勉強会でカバー。

©2023 10X, Inc. 撤退のしやすいレイヤリングや運用方法 ● 年表で可視化した結果、撤退活動にかなりの期間かかっている ○ 吉田が入社したのは2022/09だが、入社以降ずっと何かしらの撤退が起きている ○ 適切に設計されたものほど捨てやすい ● 仮名加工化などビジネス上の要請にも対応しやすくなった ● データ負債の解消やコスト改善にも繋がる 26 詳しくはデータマネジメントを支える武器としてのメタデータ管理を参照してください。

©2023 10X, Inc. まとめ: データパイプラインの変遷 ● データパイプラインは分析のニーズに応じて変わっていくのが自然 ○ 最強を作り込む、だけじゃなく変化に対応できるアジリティも大事 ○ 変化するためにも撤退活動をいかにスムーズにできるかも重要 ● ニーズや成果物とともにケイパビリティも変化していく必要性 ○ 足りなければチームや組織で学んでいく必要性 27

©2023 10X, Inc. アジェンダ ● 前置き: 組織とデータ基盤に対する私の考え ● データアーキテクチャの変遷: 年表と各世代の特徴を見ながら ○ レイヤリングの改善例 ○ 品質の可視化により、どこで何のテストをすべきか決めていく ○ 撤退のしやすいレイヤリングや運用方法 ● 今後の取り組み ○ 出口の改善: Data Reliability Level ○ 入口の改善: Data Contract 28 データパイプライン ダッシュボード / 各分析のユースケース データソース これまで改善してきたこと 今後の取り組み(出口の改善): Data Reliability Level 今後の取り組み(入口の改善): Data Contract

©2023 10X, Inc. 活用側との期待値を合わせる: Data Reliability Level 29 データパイプライン ダッシュボード / 各分析のユースケース データソース これまで説明した改善で 大分よくなってきた! 一方で、出口側で 課題感が増えてきた...!

©2023 10X, Inc. 課題感: 開発者と活用側の間の期待値のギャップ 30 大まかな傾向が分かればいいと 聞いていたのに、なんでそんなク リティカルなオペレーション用途で 使われているの...? バッチ落ちたら土日でも対応してく れますよね 色々要望あったから頑張ってメン テナンスしてたけど、全然使われ てないじゃん... なんでこのカラムにNULLが入る の? ちゃんと品質担保してよ こういう仕様で要望してたのに、い つの間にか仕様満たせてないじゃ ん! PoCで欲しいって言われたテーブ ル、いつまでメンテナンスし続けな いといけないの? 欲しいテーブルが全然見つけられ ない。重要なテーブルはちゃんと 見つけられるようにして! 開発者 活用側

©2023 10X, Inc. Data Reliability Level: データに対する期待値を定義する ● 元々はGitLabのData Developmentを参考にしており、10Xに合った形で定義しなおした ● Trusted / Business Insight / Adhocの3つのレベルを定義 ○ それぞれのレベルに応じて、どういった観点や開発プロセスを満たしている必要があるかを明示する ● Trusted: ○ ビジネスの重要な意思決定に使われるデータ ○ 代表例: 経営向けのダッシュボード、CRMなどで使われるテーブル ● Business Insight: ○ 定常的な観測用のダッシュボードなどに使われるデータ ○ 代表例: ファネル分析のダッシュボード、ディメンショナルモデリングを提供しているテーブル ● Adhoc: ○ アドホックやPoCで利用するデータ ○ 代表例: 特定店舗用の未精査の指標が使われている分析 31

©2023 10X, Inc. Data Reliability Levelの代表的な観点 ● Speficication ○ 仕様書が記載されているか ○ ビジネスオーナーが記載されているか ○ (adhocであれば)削除期限が記載されているか ● Data Catalog ○ テーブルやカラムのdescriptionは記載されているか ● Test Development ○ テストのカバレッジは十分か、項目毎に必須のテストが通っているか ● SLO ○ どの程度の可用性が要求されているか ● Information Mart ○ 適切なモデリングを経て、テーブルが生成されているか ● Manual Data Usage(手動で作成されたデータが使われていないか) ○ 精査されていないスプレッドシートなどを参照していると品質が担保できない ● Direct Source Usage(データソースを直接参照していないか) ○ 適切にモデリングされ、テストされたコンポーネントを参照しないと品質が担保できない 32

©2023 10X, Inc. Data Reliability Levelの現在地 33 Data Reliability Levelに関連する各項目をAsIsをdbt のyamlファイルに記載。 dbtの成果物(manifest.json)を利用しスクリプトで記入 したり、気合で全ファイル記入。 記入したAsIsと実際のToBeにどれくらい距離があるかLooker Studioで可視化(elementaryを利用)。 重点的に強化したほうがいい項目を洗い出したり、レベルを下げ れるテーブルがないか、などを検討しやすくなった。

©2023 10X, Inc. Data Reliability Levelの今後 ● 特にTrustedと定義したデータについて、満たすべき品質まで高める ○ 逆に言うと、Data Reliability Levelを定めることで、基準が低くてよいものは頑張り過ぎる必要がない、という ことを定義できているとも言える ○ 手間をかけるところに濃淡を付ける ● 「何でもかんでも品質を高める」ではなく、品質をコントロール配下に置き、制御できるようにすることが重要 ○ SREのSLOと思想は同じ ● 新規にテーブルやダッシュボードを作る際は、活用側とData Reliability Levelを定めた上でデータの提供する ● すでに提供しているテーブルやダッシュボードについては、活用側とData Reliability Level認識を合わせた上でデータ を提供する形に持っていく 34

©2023 10X, Inc. アジェンダ ● 前置き: 組織とデータ基盤に対する私の考え ● データアーキテクチャの変遷: 年表と各世代の特徴を見ながら ○ レイヤリングの改善例 ○ 撤退のしやすいレイヤリングや運用方法 ○ 品質の可視化により、どこで何のテストをすべきか決めていく ● 今後の取り組み ○ 出口の改善: Data Reliability Level ○ 入口の改善: Data Contract 35 データパイプライン ダッシュボード / 各分析のユースケース データソース これまで改善してきたこと 今後の取り組み(出口の改善): Data Reliability Level 今後の取り組み(入口の改善): Data Contract

©2023 10X, Inc. データソースの仕様を生成者と消費者で握る: Data Contract 36 データパイプライン ダッシュボード / 各分析のユースケース データソース これまで説明した改善で 大分よくなってきた! Data Reliability Level の定義により、方向性 が見えてきた! 入口側でも 課題感がある...!

©2023 10X, Inc. 課題感: データソースのProducerとConsumerの仕様のやり取り 37 毎回違う人にデータの仕様聞か れて、開発がなかなか進められな い... このイベント、Google Analyticsに 先週から流れてこなくなってるよ?! プロダクトやサービスの運用もあ るし、考えるべきことは分析のこと だけじゃないよ... このカラム、INTだったのが STRINGに変わってバッチが落ち たよ! このカラム、どういうときにNULL が入ってくるか全然分からない。。 オペレーションの調査用に作った テーブル、いつの間にか分析に使 われてる... えっ、このカラム0の場合あるの?! データソースの 生成者側(Producer) データソースの 消費者側(Consumer)

©2023 10X, Inc. 初期のデータソースの仕様のやり取り ● 古きよき(?)スプレッドシート ○ ログの出力コードを変更したら、botがスプレッドシートへの動線を出してくれる 38

©2023 10X, Inc. 古びるスプレッドシート、増える仕様についての問い合わせ ● スプレッドシートへの記入は手間がかかり、時間とともに古びていった ● 正確な仕様を知るため、データエンジニアであればコードの定義を見にいくことで何とかなる ○ しかし、アナリストはそうもいかない ● Slackで毎回質問する/されるのはお互い大変 39

©2023 10X, Inc. Data Contractをインターフェイスにしたコミュニケーション ● 仕様についてのコミュニケーションを疎にしたい ○ Producer: ■ 生成するデータの仕様を書く ■ 仕様に沿ったデータソースの生成に責任を持つ ○ Consumer: ■ まず仕様書を確認する ■ 仕様を信じた上でDWHやデータマートを作る ○ ProducerとConsumerでコミュニケーションが発生するのは「仕様が明確でない」あるいは「データが仕様に 沿っていない」ときのみ ■ マイクロサービスを運用しているチーム間がスキーマをベースに会話するのと同じ ● ここでいう仕様のことを「Data Contract」と呼ぶ ○ 欧州の決済系サービスGoCardlessのエンジニアのAndrew Jonesが提唱した概念 ○ より詳細はDriving Data Quality with Data Contractsにまとまってます ○ datatech-jpで(2024/09現在)読書会が行なっています ■ datatech-jpでData Contractに特化した事例共有会を秋に行なう予定です 40

©2023 10X, Inc. Data Contractの例: テーブル単位 ● テーブルのdescription ○ イベントデータなどであればイベントの生成ポイントがいつか、なども ● 可用性 ○ XX時までに前日分のデータがBigQueryに同期される ● どのチームがオーナーか ○ 開発チームはドメインチームで分割されているため ● 主キーはどれか ● テーブルがdeprecatedかどうか ○ 削除や更新の停止がいきなり起きないで欲しい 41

©2023 10X, Inc. Data Contractの例: カラム単位 ● カラムのdescription ● Nullableか ○ NULLが入る場合も、「いつ以降はNULLが入らないように設計している」や「NULLが入り得るのはこういう ケース」という情報も欲しい。リバースエンジニアリングで条件を同定するのは大変だし、担保できない ● 重複がないか ● Enumの場合、どういう値を取り得るのか。また、それぞれに対応する番号のdescription ○ 例: dbtのaccepted_valuesテストの生成に使える ○ 例: payment_type = 1 => クレジットカードによる決済 ● 外部キーの場合、参照先のテーブルのカラム名 ○ 例: ER図の自動生成に使える ○ 例: dbtのrelationshipsテストの生成に使える ● 値の範囲の制約 ○ 例: 価格の値で0を含むのか、含む場合はどういうケースか ● PIIな情報を含むかどうか ○ データ基盤に取り込まなくする、あるいは列レベルセキュリティで守るなどの検討基準として欲しい ○ 開発側とデータ基盤側のセキュリティの基準を揃える意味でも有用 ● Deprecatedなカラムかどうか 42

©2023 10X, Inc. 導入時の考慮ポイント: いきなり全部やらない ● 先ほど説明したData Contractの内容はかなり盛りだくさんになっている ○ 全部の内容を記載する場合、Consumer側には理想的ではあるが、Producer側には高負担 ● 導入時は重要かつ負担が少ない箇所から始める ○ 10Xの場合、型 / description / Nullableかどうか、からスタート ○ (拡張性は持たせておく) ● なぜData Contractを導入したいか、Producer側である開発チームに協力を求める ○ どういった課題がデータ活用の現場で起きているのか、どういう世界を目指したいのか、どういう始め方をし たいのか、機を見て何度も丁寧にコミュニケーション ○ Data Reliability Levelも同時期に進めているので、「Trusted」で使われているデータソースから優先的にやり たい、など濃淡を付ける 43 結果的に、一部分でPoC的に スタートすることができた...!

©2023 10X, Inc. 導入時の考慮ポイント: Data Contractを結ぶ箇所がどこかを明らかにする ● コード上の型とデータが出力されるストレージでの型が合わない場合が実際あった ○ 例: コード上はStringであったが、イベントログに出力される際にIntegerにキャストされてしまった ○ 例: コード上はArrayであったが、Google Analyticsの制約上スカラー値しか出力できないためString にキャストされ、しかも長さ制限のため出力が切り詰められてしまった ○ 例: コード上はPrice型で定義されているが、ストレージに出力される型は自明ではない ● Data Contractを結ぶ際はどこをContractを結ぶ箇所か明示するのがよい ○ Consumerが利用するデータが生成されるまでに、RDBMSやPub/SubやGCSなどを経由しているとContractの 内容が自明ではなくなってしまう ○ 10Xの場合はBigQueryのテーブルに出力される箇所をData Contractに設定しています ○ Data Meshをやりたい場合にもData Contractは重要な概念になってくるはず 44 CDC(Kafka + Debezium) BigQuery PostgreSQL プロダクトの開発チームが Data Contract Aを生成 Data Contract Aを元にリアルタイムデータの 開発チームがData Contract Bを生成 Data Contract Bを元にデータ基盤 チームがデータマートを開発

©2023 10X, Inc. 運用時の考慮ポイント: 自動化 ● Contractをコードとは別にドキュメンテーションすると、スプレッドシートと同様に古びてしまう... ● データを生成するコードにData Contractに関する情報を埋め込み、Data Contractの仕様書をCIで自動生成するのが オススメ ○ 仕様書を成果物としてcommitに含めるでもよいし、スキーマレジストリに登録するなどでもよい ○ 10Xの場合、GitHub Actionsで自動化して、Data Contractがyamlとして成果物に含まれる形 ○ 仕様の変更があった場合、どのcommitから変わったのかも追従しやすい! ● Protocol BuffersにData Contractの情報を埋め込む例をエントリで紹介しています ○ 10Xが現在このやり方でやっているわけではないですが、参考までに 45

©2023 10X, Inc. Data Contractの今後 ● Producer側で生成してもらったData ContractをConsumer側の運用に乗せる ○ 現状はData ContractをConsumer側でまだ明確に利用できているわけではない ○ 現状は手動で管理しているdbtのデータソースの自動生成に置き換えるなどを進めていきたい ● Data Contractに組み込む観点を徐々に増やす ○ 現状は型 / description / Nullableかどうか、くらいしか入っておらず、まだまだ情報としては不足 ● Data Contractを適用するデータの種類を増やす ○ 現状はclient-sideのイベントデータのみData Contractが生成されている ○ DBなどData Contractの生成範囲を広げていきたい 46

©2023 10X, Inc. まとめ ● データアーキテクチャは分析のニーズに応じて変わっていくのが自然 ○ 最強を作り込む、だけではなく変化に対応できるのも大事 ○ 変化するためにも撤退活動をいかにスムーズにできるかも重要 ● ニーズや成果物とともにケイパビリティも変化していく必要性 ○ 足りなければチームで学んでいく必要性 ● データパイプラインの中の改善だけでは不十分 ○ 出口と入口も同時に抑えることで、よりよいものを作りやすくする ○ Data Reliability LevelとData Contractの取り組みを紹介 47 データパイプライン ダッシュボード / 各分析のユースケース データソース これまで改善してきたこと 今後の取り組み(出口の改善): Data Reliability Level 今後の取り組み(入口の改善): Data Contract