Dataplexとdbt-osmosisを活用した「がんばらない」データカタログとメタデータ管理の運用(Data Engineering Study #22)

Data Engineering Study #22 5社のデータエンジニアが振り返る2023 での発表資料になります。

- https://forkwell.connpass.com/event/299633/

Transcript

1. ©2023 10X, Inc. Dataplexとdbt-osmosisを活用した 「がんばらない」データカタログと メタデータ管理の運用 Data Engineering Study #22 5社のデータエンジニアが振り返る2023 株式会社10X Yasuhisa Yoshida
2. ©2023 10X, Inc. 自己紹介 • 吉田 康久 ◦ Twitterやはてなidは@syou6162 / id:syou6162 • 株式会社10Xでデータエンジニア ◦ 2022/09に入社 ◦ エンジニアリング本部 データサイエンス&エンジニアリング部に所属 ◦ データマネジメント / データガバナンスの仕事をしてます ◦ 京都から働いてます • これまでの職歴としては研究者(NLP) => Webアプリケーションエンジニア => データエンジニア, Analytics Engineer • 最近はdatatech-jpのオーガナイザーの一人をやってます 2
3. ©2023 10X, Inc. 提供プロダクト お客様アプリ • 数万SKUから商品からスムーズにカゴを作成できるUX • キーワード・カテゴリ検索・お気に入り・注文変更・ 購入履歴といった基本機能 • 商品の受け取り方法を選択 • 注文状況・配達状況の確認や通知 • Web(オプションにて提供) 数万点のSKUから スムーズにお買い物ができるUXを提供 主な機能 3
4. ©2023 10X, Inc. 提供プロダクト スタッフアプリ • ピッキングリストを自動生成 • 移動距離最短化、複数スタッフに並行作業可能 • バーコード照合でのヒューマンエラー防止をサポート • 多様な受け取り方法に対応 ミスが少なく効率的な 業務オペレーションシステムを提供 主な機能 4
5. ©2023 10X, Inc. 提供サービス 商品・在庫ロジック 構築 マスタの半自動生成 店舗でのお買い物に限りなく近い品揃えを実現 半自動の商品在庫マスタ生成プロセスを提供し 欠品と運用コストを削減 データソース特定 データI/F開発 アルゴリズム開発 日別店別 在庫マスタ生成 発注データ 販売データ 廃棄データ 販促データ 店舗A 店舗B 店舗C 店舗D Stailerと つなぐ I/Fの開発 アルゴリズムの 開発 販促情報 発注周期 品揃除外 etc. 5
6. ©2023 10X, Inc. 6 Stailer Flywheel w/Lever - 事業成長のはずみ車とレバー パートナー シップ締結 Engagement Accessibility Capacity Accessibility Selection Discovery Growth 投資リソース の最大化 More Capacity More Order More AOV 初回利用者の獲得 キャパシティの最大化 品揃え/価格最適 化 ディスカバリー最大化 関係の強化 店舗/エリア/アクセ スの開設 スロットキャパシティの増加 満便率の増加 継続利用者の増加 利用頻度の増加 かご単価の増加 再投資
7. ©2023 10X, Inc. 入社直後にやったこと: データマネジメント成熟度アセスメントの実施 7 事業上データが重要にも関わらず 様々な箇所でデータの課題が山積 DMBOKの項目に沿ってアセスメント を実施。優先度を決めた
8. ©2023 10X, Inc. 入社直後にやったこと: データマネジメント成熟度アセスメントの実施 8 11項目がフラットに並んでいると理 解が難しかったので、各項目の依存 関係を可視化 取り組みの詳細は過去の発表を参 照してください 特に優先して進めたい項目! 特にデータセ キュリティは大きく進捗できた
9. ©2023 10X, Inc. 最近の課題: データディスカバリー 9 どのデータを使えば いいか分からない どのデータが使えるか分からない
10. ©2023 10X, Inc. データディスカバリーが課題になった背景 • 約一年前は分析に必要なテーブルがまだ限定的であった ◦ 主要テーブルを把握していれば何とかなった時代 • ほぼ全員が生データを見ることができたので、主要テーブルで情報が足りない場合でも何とかなっていた ◦ 生データの仕様が分からなければ、データ定義(スプレッドシートで管理)を見ればよかった ◦ カバレッジもある程度高かった 10
11. ©2023 10X, Inc. 様々な要因によりデータディスカバリーが課題に 11 [課題] 個別パートナーのDWHにはカラ ムの定義が書かれていない。SQLから 定義を追うには、専門家でない人には難 しすぎる。 自分が必要なデータがどれか分からず、 適切でないデータの使用により間違った 意思決定をしてしまう可能性が高くなっ てしまう...! 間違いを防ぐためにアナリティクスエンジ ニアへの依頼が多くなり、基盤構築にか ける時間も減ってしまう [ガバナンスの強化 / 権限整備] データレイクやパートナー横断DWH のデータは権限的に使えない人が 増えた [プロダクトの成長] Stailerの成長に 伴ない、データ定義にないテーブル が増加し、定義の更新が止まってし まった。少数の主要テーブルだけ見 れば分かるという状況でもなくなっ てきた [データモデリングの高度化] staging / data vault / dimentional modeling / 大福帳テー ブルの導入により、定義を追うのは簡単では なくなってきた
12. ©2023 10X, Inc. データカタログの導入? • データディスカバリーを高めるためにはデータカタログやメタデータ管理が有効 • 過去のData Engineering Studyでもデータカタログの回があった ◦ 見てない方は是非見ましょう! ◦ データカタログ導入だけでなく、メタデータの継続的な整備も重要という学びがあった 12
13. ©2023 10X, Inc. 導入時に検討したこと • コストをどれくらい割けるか ◦ 導入時のコストもそうだし、運用時のコストもそう ◦ スタートアップなので、フルスクラッチで実装して運用する工数はもちろんない ◦ OpenMetadataなども検討したが、運用コストはバカにできない ▪ 例: メタデータ収集のために裏側でAirflowが動いている ▪ 例: 10Xで必要としているものに対して機能がtoo much ◦ => SaaSでManagedかつBigQueryを利用していたら、自然と便利になって欲しい • データユーザーにとって使いやすいこと ◦ dbtを使っているならば、dbt docsは便利 ◦ 開発者にとっては便利だが、データユーザーにとっては分析には使わない or 閲覧権限がない中間レイヤーの テーブルなども含まれてしまう 13
14. ©2023 10X, Inc. Dataplex(旧Data Catalog)の導入 • Google Cloudのマネージドサービス ◦ カタログ側へのメタデータのsyncが不要で、運用の手間がかからない ◦ 普通にBigQueryを使っていれば勝手に使える ◦ GCSやSpanner、Cloud Pub/Subも対象に含んでくれる • データカタログ専用のSaaSと比べると安価 • セキュリティ観点 ◦ 必要な権限はroles/bigquery.metadataViewerとはいえ、Google Cloud外に情報を出さずに済む ◦ データカタログの検索結果もIAMと自然に連携できる 14
15. ©2023 10X, Inc. Dataplexのデータカタログ観点で嬉しい点: 検索が強い 15 日本語で検索できる(BigQueryではできなかった)! テーブル名だけでなく、カラム名でも検索できる!
16. ©2023 10X, Inc. Dataplexのデータカタログ観点で嬉しい点: 検索が強い 16 ☆(お気に入り)のテーブルに絞って検索できる! 候補が複数ある場合、社内でよく使われていると検 索結果の上にくる。テーブルのクエリされた回数も テーブル個別の検索結果画面で分かる! IAMと統合されているため、閲覧権限のあるテーブル やデータセットのみ検索結果に表示できる!
17. ©2023 10X, Inc. Dataplexのデータカタログ観点で嬉しい点: データリネージが分かる 17 ユーザー側は何もしなくてもデータリネージが分かる(運 用工数が発生しない)。dbtのようなリネージが出せない 生のクエリを使っている場合は特に有用! 生成に使われたクエリも分かる! 該当テーブルの生成元や利用先 が分かるため、障害調査やテーブ ルの統廃合もやりやすくなる! BigQueryのテーブルだけでなく、 GCSもリネージに含んでくれる!
18. ©2023 10X, Inc. 残る課題: 継続的なメタデータの管理 • データカタログは決まった、じゃあどうやってメタデータを入れるか? ◦ 特にビジネスメタデータをどうやって入れるか • 待ち受ける課題 ◦ 課題1: カバレッジが足りていないと、そもそも検索に引っかからない ◦ 課題2: 継続的にメンテナンスできないと、誤った意思決定に繋がることも ◦ 両方をちゃんとやるのは大変...! 18
19. ©2023 10X, Inc. 人手によるカラムdescriptionのメンテナンスは大変... 19 データレイクの テーブル カラムA カラムB DWHの テーブル カラムAを参照 カラムBを参照 データマートの テーブル カラムAを参照 カラムBを参照 データレイクのカラムdescriptionをコピペ... 参照箇所が数十箇所以上あるんだけど... 大本の定義が変更された場合は後続もコピペし なおすの...?
20. ©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
21. ©2023 10X, Inc. dbt-osmosisによるカラムdescriptionの伝播 21 データレイクの テーブル カラムA カラムB DWHの テーブル カラムAを参照 カラムBを参照 データマートの テーブル カラムAを参照 カラムBを参照 後段で参照しているカラムのdescriptionは自動 で埋めてくれる! 多段の参照関係になっていても 問題なくカラムdescriptionを埋めてくれる! 大本の定義のみ人間がメンテナンス。 大本の定義が更新されたら、後段のカラムのdescriptionも自動的に追従
22. ©2023 10X, Inc. 脱線: 自社運用に適用できるようにdbt-osmosisに貢献 • dbt-osmosisのコアコンセプトは素晴らしいが、そのままでは自社運用に適用できない箇所があった • 自分たちのユースケースを説明しつつ、実装を取り込んでもらった ◦ 毎週のようにPull Requestを送り続けること20件 ◦ 詳細は データカタログの本格導入に向けたdbt-osmosisへの貢献について紹介します - 10X Product Blog を参 照してください 22
23. ©2023 10X, Inc. 自分のお気に入りの機能: カラムdescriptionの定義元が分かるようにする • データモデリングが複雑化すると、1つのデータマートを作るために参照しているデータソースや中間テーブルが10 個を越えることは珍しくない • dbt-osmosisでカラムのdescriptionを付与したとして「このカラム、説明が分かりにくいから修正したいな。でも、 参照しているテーブルが多すぎて、どこのdescriptionを修正すればいいか分からない...」ということが起き始めた • Pull Requestを送り、伝播元がどこか分かるようにyamlファイルに埋め込めるようにした(meta.osmosis_progenitor) 23 伝播元が分かるので、カラムdescriptionの修正 やそれに基づいた再伝播が容易になった!
24. ©2023 10X, Inc. まとめ • データセキュリティの強化とともに、データディスカバリーが課題になってきた • スタートアップのため、データカタログやメタデータ管理にコストをかけるのが難しい ◦ データカタログ: Dataplex ◦ メタデータ管理: dbt-osmosis • マネージドSaaSと便利OSSのおかげで「がんばらない」でデータディスカバリーの課題に対応できるようになって きた ◦ データユーザー: セルフサービスで自分の分析に必要なデータを見つけることができる ◦ データエンジニア: データ品質など他の重要なイシューに時間を割くことができる 24