©2023 10X, Inc. Dataplexとdbt-osmosisを活用した 「がんばらない」データカタログと メタデータ管理の運用 Data Engineering Study #22 5社のデータエンジニアが振り返る2023 株式会社10X Yasuhisa Yoshida

©2023 10X, Inc. 自己紹介 ● 吉田 康久 ○ Twitterやはてなidは@syou6162 / id:syou6162 ● 株式会社10Xでデータエンジニア ○ 2022/09に入社 ○ エンジニアリング本部 データサイエンス&エンジニアリング部に所属 ○ データマネジメント / データガバナンスの仕事をしてます ○ 京都から働いてます ● これまでの職歴としては研究者(NLP) => Webアプリケーションエンジニア => データエンジニア, Analytics Engineer ● 最近はdatatech-jpのオーガナイザーの一人をやってます 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. 入社直後にやったこと: データマネジメント成熟度アセスメントの実施 7 事業上データが重要にも関わらず 様々な箇所でデータの課題が山積 DMBOKの項目に沿ってアセスメント を実施。優先度を決めた

©2023 10X, Inc. 入社直後にやったこと: データマネジメント成熟度アセスメントの実施 8 11項目がフラットに並んでいると理 解が難しかったので、各項目の依存 関係を可視化 取り組みの詳細は過去の発表を参 照してください 特に優先して進めたい項目! 特にデータセ キュリティは大きく進捗できた

©2023 10X, Inc. 最近の課題: データディスカバリー 9 どのデータを使えば いいか分からない どのデータが使えるか分からない

©2023 10X, Inc. データディスカバリーが課題になった背景 ● 約一年前は分析に必要なテーブルがまだ限定的であった ○ 主要テーブルを把握していれば何とかなった時代 ● ほぼ全員が生データを見ることができたので、主要テーブルで情報が足りない場合でも何とかなっていた ○ 生データの仕様が分からなければ、データ定義(スプレッドシートで管理)を見ればよかった ○ カバレッジもある程度高かった 10

©2023 10X, Inc. 様々な要因によりデータディスカバリーが課題に 11 [課題] 個別パートナーのDWHにはカラ ムの定義が書かれていない。SQLから 定義を追うには、専門家でない人には難 しすぎる。 自分が必要なデータがどれか分からず、 適切でないデータの使用により間違った 意思決定をしてしまう可能性が高くなっ てしまう...! 間違いを防ぐためにアナリティクスエンジ ニアへの依頼が多くなり、基盤構築にか ける時間も減ってしまう [ガバナンスの強化 / 権限整備] データレイクやパートナー横断DWH のデータは権限的に使えない人が 増えた [プロダクトの成長] Stailerの成長に 伴ない、データ定義にないテーブル が増加し、定義の更新が止まってし まった。少数の主要テーブルだけ見 れば分かるという状況でもなくなっ てきた [データモデリングの高度化] staging / data vault / dimentional modeling / 大福帳テー ブルの導入により、定義を追うのは簡単では なくなってきた

©2023 10X, Inc. データカタログの導入? ● データディスカバリーを高めるためにはデータカタログやメタデータ管理が有効 ● 過去のData Engineering Studyでもデータカタログの回があった ○ 見てない方は是非見ましょう! ○ データカタログ導入だけでなく、メタデータの継続的な整備も重要という学びがあった 12

©2023 10X, Inc. 導入時に検討したこと ● コストをどれくらい割けるか ○ 導入時のコストもそうだし、運用時のコストもそう ○ スタートアップなので、フルスクラッチで実装して運用する工数はもちろんない ○ OpenMetadataなども検討したが、運用コストはバカにできない ■ 例: メタデータ収集のために裏側でAirflowが動いている ■ 例: 10Xで必要としているものに対して機能がtoo much ○ => SaaSでManagedかつBigQueryを利用していたら、自然と便利になって欲しい ● データユーザーにとって使いやすいこと ○ dbtを使っているならば、dbt docsは便利 ○ 開発者にとっては便利だが、データユーザーにとっては分析には使わない or 閲覧権限がない中間レイヤーの テーブルなども含まれてしまう 13

©2023 10X, Inc. Dataplex(旧Data Catalog)の導入 ● Google Cloudのマネージドサービス ○ カタログ側へのメタデータのsyncが不要で、運用の手間がかからない ○ 普通にBigQueryを使っていれば勝手に使える ○ GCSやSpanner、Cloud Pub/Subも対象に含んでくれる ● データカタログ専用のSaaSと比べると安価 ● セキュリティ観点 ○ 必要な権限はroles/bigquery.metadataViewerとはいえ、Google Cloud外に情報を出さずに済む ○ データカタログの検索結果もIAMと自然に連携できる 14

©2023 10X, Inc. Dataplexのデータカタログ観点で嬉しい点: 検索が強い 15 日本語で検索できる(BigQueryではできなかった)! テーブル名だけでなく、カラム名でも検索できる!

©2023 10X, Inc. Dataplexのデータカタログ観点で嬉しい点: 検索が強い 16 ☆(お気に入り)のテーブルに絞って検索できる! 候補が複数ある場合、社内でよく使われていると検 索結果の上にくる。テーブルのクエリされた回数も テーブル個別の検索結果画面で分かる! IAMと統合されているため、閲覧権限のあるテーブル やデータセットのみ検索結果に表示できる!

©2023 10X, Inc. Dataplexのデータカタログ観点で嬉しい点: データリネージが分かる 17 ユーザー側は何もしなくてもデータリネージが分かる(運 用工数が発生しない)。dbtのようなリネージが出せない 生のクエリを使っている場合は特に有用! 生成に使われたクエリも分かる! 該当テーブルの生成元や利用先 が分かるため、障害調査やテーブ ルの統廃合もやりやすくなる! BigQueryのテーブルだけでなく、 GCSもリネージに含んでくれる!

©2023 10X, Inc. 残る課題: 継続的なメタデータの管理 ● データカタログは決まった、じゃあどうやってメタデータを入れるか? ○ 特にビジネスメタデータをどうやって入れるか ● 待ち受ける課題 ○ 課題1: カバレッジが足りていないと、そもそも検索に引っかからない ○ 課題2: 継続的にメンテナンスできないと、誤った意思決定に繋がることも ○ 両方をちゃんとやるのは大変...! 18

©2023 10X, Inc. 人手によるカラムdescriptionのメンテナンスは大変... 19 データレイクの テーブル カラムA カラムB DWHの テーブル カラムAを参照 カラムBを参照 データマートの テーブル カラムAを参照 カラムBを参照 データレイクのカラムdescriptionをコピペ... 参照箇所が数十箇所以上あるんだけど... 大本の定義が変更された場合は後続もコピペし なおすの...?

©2023 10X, Inc. 継続的なメタデータの管理: dbt-osmosisの導入 ● dbtの便利ライブラリ ○ https://github.com/z3z1ma/dbt-osmosis ○ 最小限のカラムのdescriptionを埋めれば、それを参照しているカラムのdescriptionも自動的に埋めてくれる ● dbt-osmosisの導入効果 ○ 導入前: カラムのdescriptionは1割も付与されていない ■ データカタログが機能できない ○ 導入後: よく使われるデータセット内のカラムのdescriptionは50~80%付与されている! ● 運用時にかかるコスト ○ 大本にあたるカラムのdescriptionを追加 / 修正すると、dbt-osmosisが参照しているカラムのdescriptionも自 動的に埋めてくれる ○ GitHub Actionsで自動更新できるようにしている、エンジニア以外でも簡単にできる ● 大本にあたるカラムのdescriptionの初期の追加はチームで気合で埋めました 20

©2023 10X, Inc. dbt-osmosisによるカラムdescriptionの伝播 21 データレイクの テーブル カラムA カラムB DWHの テーブル カラムAを参照 カラムBを参照 データマートの テーブル カラムAを参照 カラムBを参照 後段で参照しているカラムのdescriptionは自動 で埋めてくれる! 多段の参照関係になっていても 問題なくカラムdescriptionを埋めてくれる! 大本の定義のみ人間がメンテナンス。 大本の定義が更新されたら、後段のカラムのdescriptionも自動的に追従

©2023 10X, Inc. 脱線: 自社運用に適用できるようにdbt-osmosisに貢献 ● dbt-osmosisのコアコンセプトは素晴らしいが、そのままでは自社運用に適用できない箇所があった ● 自分たちのユースケースを説明しつつ、実装を取り込んでもらった ○ 毎週のようにPull Requestを送り続けること20件 ○ 詳細は データカタログの本格導入に向けたdbt-osmosisへの貢献について紹介します - 10X Product Blog を参 照してください 22

©2023 10X, Inc. 自分のお気に入りの機能: カラムdescriptionの定義元が分かるようにする ● データモデリングが複雑化すると、1つのデータマートを作るために参照しているデータソースや中間テーブルが10 個を越えることは珍しくない ● dbt-osmosisでカラムのdescriptionを付与したとして「このカラム、説明が分かりにくいから修正したいな。でも、 参照しているテーブルが多すぎて、どこのdescriptionを修正すればいいか分からない...」ということが起き始めた ● Pull Requestを送り、伝播元がどこか分かるようにyamlファイルに埋め込めるようにした(meta.osmosis_progenitor) 23 伝播元が分かるので、カラムdescriptionの修正 やそれに基づいた再伝播が容易になった!

©2023 10X, Inc. まとめ ● データセキュリティの強化とともに、データディスカバリーが課題になってきた ● スタートアップのため、データカタログやメタデータ管理にコストをかけるのが難しい ○ データカタログ: Dataplex ○ メタデータ管理: dbt-osmosis ● マネージドSaaSと便利OSSのおかげで「がんばらない」でデータディスカバリーの課題に対応できるようになって きた ○ データユーザー: セルフサービスで自分の分析に必要なデータを見つけることができる ○ データエンジニア: データ品質など他の重要なイシューに時間を割くことができる 24

No content