©2023 10X, Inc. 10XにおけるData Contractの 導入について Data Contract事例共有会 株式会社10X Yasuhisa Yoshida

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

©2023 10X, Inc. 宣伝: datatech-jpで近々色々な活動があります! 是非ご参加ください! 3

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

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

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

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

©2023 10X, Inc. アジェンダ ● 入口の改善: Data Contract ○ 導入までの背景 / 課題感 ○ 導入 / 運用時の考慮ポイント ○ 今後の取り組み ● 出口の改善: Data Reliability Level 8 データパイプライン ダッシュボード / 各分析のユースケース データソース これまでに改善が進んできた 出口の改善: Data Reliability Level 入口の改善: Data Contract

©2023 10X, Inc. アジェンダ ● 入口の改善: Data Contract ○ 導入までの背景 / 課題感 ○ 導入 / 運用時の考慮ポイント ○ 今後の取り組み ● 出口の改善: Data Reliability Level 9 データパイプライン ダッシュボード / 各分析のユースケース データソース これまでに改善が進んできた 出口の改善: Data Reliability Level 入口の改善: Data Contract

©2023 10X, Inc. これまで: データパイプライン(Data Transform)の品質が低かった 10 データパイプライン ダッシュボード / 各分析のユースケース データソース 詳しくは「10Xでのデータ基盤の変遷とこれから」を参照してください。 ここの品質が低く、課題が多かった...

©2023 10X, Inc. 最近: レイヤリングを改善し、データパイプラインの品質が向上 11 詳しくは「10Xでのデータ基盤の変遷とこれから」を参照してください。

©2023 10X, Inc. 最近: データソース側の課題が目立つようになってきた 12 データパイプライン ダッシュボード / 各分析のユースケース データソース これまでに改善が進んできた データパイプラインが改善された結果、データソー ス側に課題を感じることが増えてきた

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

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

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

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

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

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

©2023 10X, Inc. アジェンダ ● 入口の改善: Data Contract ○ 導入までの背景 / 課題感 ○ 導入 / 運用時の考慮ポイント ○ 今後の取り組み ● 出口の改善: Data Reliability Level 19 データパイプライン ダッシュボード / 各分析のユースケース データソース これまでに改善が進んできた 出口の改善: Data Reliability Level 入口の改善: Data Contract

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

©2023 10X, Inc. 脱線: 「Data Contractってデータ定義書と同じでは?」 ● 主観ですが、おおむね正しい ○ しかし、振り子ではなく、技術の螺旋構造になっていると思っている ● Data Contractが登場してきた背景 ○ データが重要、主役のアプリケーション(Data Product)が以前と比べて増えてきた ○ データの種類も増えてきて、認知負荷の増大がより深刻になってきた ■ チーム間のやり取りを疎に行ないたい ○ マイクロサービスによる開発が普及し、スキーマファーストな文化も広がりつつある ■ それに伴なって、スキーマレジストリやProtocol Buffersなどエコシステムも充実してきた ○ Web開発で培われてきたプラクティスをデータ基盤の開発にも取り入れたい ■ Data Contractとして再定義 ● やりたいことの本質はあまり変わっていないが、より現代の文脈に沿ってデータ定義書やその目的 / 手段を再定義し たものがData Contractではないか ○ …と自分は解釈している 23

©2023 10X, Inc. アジェンダ ● 入口の改善: Data Contract ○ 導入までの背景 / 課題感 ○ 導入 / 運用時の考慮ポイント ○ 今後の取り組み ● 出口の改善: Data Reliability Level 24 データパイプライン ダッシュボード / 各分析のユースケース データソース これまでに改善が進んできた 出口の改善: Data Reliability Level 入口の改善: Data Contract

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

©2023 10X, Inc. Data Contractの今後(その2) 26 データパイプライン データソース 集計結果などをデータソースへ書き戻す(Data activation / Reverse ETL) 箇所でもData Contractを使ってやり取り。データ基盤がProducer側になることもある! 今までは「データソース」から「データパイプライン」への Data Contractの話のみをしていた

©2023 10X, Inc. Data Contractの今後(その3) 27 データパイプライン データパイプライン データパイプライン データパイプライン データメッシュ的にドメイン毎にデータパイプラインが繋がるケースも 出てきており、やり取りのインターフェイスとしてData Contractを導入予定

©2023 10X, Inc. アジェンダ ● 入口の改善: Data Contract ○ 導入までの背景 / 課題感 ○ 導入 / 運用時の考慮ポイント ○ 今後の取り組み ● 出口の改善: Data Reliability Level 28 データパイプライン ダッシュボード / 各分析のユースケース データソース これまでに改善が進んできた 出口の改善: Data Reliability Level 入口の改善: Data Contract

©2023 10X, Inc. 最近: 活用側との期待値のギャップが目立つようになってきた 29 データパイプライン ダッシュボード / 各分析のユースケース データソース これまでに改善が進んできた 活用側との期待値のギャップが出てきた!

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

©2023 10X, Inc. Data Contractよりもう少し人間 / 分析に向いた枠組みが欲しい ● Data Contractは割とかっちりとした枠組み。対システムを意識している ○ 例: Data ContractからProtocol BuffersやdbtのsourceのYAMLファイル / テストを自動生成 ○ 例: カラムにPIIのラベルが付与されていたら、カラムレベルセキュリティで自動的に権限を絞る ● 分析向けでは、もう少し柔らかい枠組みが欲しいことが多い ○ 例: 正確さは多少犠牲にして、スピード重視で分析がしたい ○ 例: 不確実性が大きいため、半年後も運用し続ける必要があるか分からない ○ 例: あまり精査されていないが、深掘り分析のためにスプレッドシートとJOINがしたい ○ 例: 一週間くらいバッチがこけても実は何とかなる利用用途 ● Data Contractの思想は反映しつつ、対人間の分析向けの枠組みが欲しい ○ 「Data Reliability Level」として、自社独自に定義 31

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

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

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

©2023 10X, Inc. Data Reliability Levelの今後 ● 特にTrustedと定義したデータについて、満たすべき品質まで高める ○ 逆に言うと、Data Reliability Levelを定めることで、基準が低くてよいものは頑張り過ぎる必要がない、という ことを定義できているとも言える ○ 手間をかけるところに濃淡を付ける ● 「何でもかんでも品質を高める」ではなく、品質をコントロール配下に置き、制御できるようにすることが重要 ○ SREのSLOと思想は同じ ○ 制御できるように、チーム内で以下のような動きを取った ■ 当初、Business Insightに該当するテーブルが148個(多い...!)あった ■ 「今のチーム状況で、これだけのBusiness Insightレベルのテーブルを運用できますか?」を自問自答 ■ 約半数をadhocに運用レベルを落とす、あるいは捨てるという動きを取れた ● 新規にテーブルやダッシュボードを作る際は、活用側とData Reliability Levelを定めた上でデータの提供する ● すでに提供しているテーブルやダッシュボードについては、活用側とData Reliability Level認識を合わせた上でデータ を提供する形に持っていく 35

©2023 10X, Inc. まとめ ● データパイプラインの改善に伴ない、入口と出口での課題が目立ってきた ● 入口側の改善としてData Contract、出口側の改善としてData Reliability Levelを一部導入 / 運用を開始 ● すでに導入した箇所は、より詳細な項目を含められるようにし、導入の範囲を広げることを今後はやっていきたい ● Data Contract / Data Reliability Levelの導入による具体的な恩恵事例なども今後発表していきたい 36 データパイプライン ダッシュボード / 各分析のユースケース データソース これまでに改善が進んできた 出口の改善: Data Reliability Level 入口の改善: Data Contract