BigQuery のデータ品質やデータ活用を高める Dataplex 等の活用

Google Cloud Next Tokyo '23で発表した資料です。

Transcript

1. © GO Inc. 2023.11.16 GO株式会社 AI技術開発部データプラットフォームグループ 伊田 正寿 Google Cloud Next Tokyo '23 BigQuery のデータ品質やデータ活 用を高める Dataplex 等の活用
2. © GO Inc. 本資料はデータ基盤の開発者やデータを活用したい方に対して、 データ品質の改善やメタデータの整備事例を紹介しています。 2023.11現在も試行錯誤中ではありますが、現場の生の声として、 参考にして頂ければ幸いです。 ※本資料は Google Cloud Next Tokyo '23 のセッションの発表資料 に、一部公開用に修正を加えております
3. © GO Inc. GO株式会社 データエンジニア ／ 伊田 正寿 (タクシーアプリ『GO』のデータ基盤の開発運用をやっています) おでんがおいしい季節になりました 3 自己紹介 プロフィール写真 正方形にトリミングした写 真を「図形に合わせてトリ ミング」で円形にすると真 円になる
4. Index © GO Inc. 1. 会社紹介 2. データ基盤紹介 3. 背景・課題 4. 課題解決のための取り組み 5. データ品質管理を Dataplex で実現する 6. データカタログを DataHub で実現する 7. リネージを DataHub で実現する 8. まとめ 4
5. © GO Inc. 5 会社紹介 01
6. © GO Inc. 6 GO株式会社について タクシーDX 乗務員向けナビゲーション端末 タクシーアプリのキャッシュレス決済機 能 乗務員向けアプリの開発・運営 ※記載されている会社名や商品名などは、各社の商標または登録商標です。（出願中含む） 脱炭素化 タクシーの運行特性に応じた EV運行マネジメントとエネルギーマネジメントに よるCO2削減 アプリ注文のみを受け取る車両の配車 交通事故削減支援 AIドラレコを活用した 危険シーンを解析・報告し運行管理に活用 タクシーサイネージメディア（動画広告） AIドラレコのデータを元に、地図と実際の道路 情報の差分をAI技術によりメンテナンス タクシー配車や経費精算などを簡単効率化 した法人向けサービス
7. © GO Inc. 7 データ基盤紹介 02
8. © GO Inc. 8 主要な『GO』データ基盤 GO 動態ログ GO イベントログ （ユーザーアプリ） Google Cloud DB ログ （Cloud SQL） AWS DBログ （Aurora） 外部データ (地図・天気など) データソース データ パイプライン BigQuery RAWデータ データマート データ活用 BI・プロダクト分析 バッチ同期 バッチ同期 (federated query) バッチ同期 (S3 → GCS) ストリーミング挿入 (Pub/Sub, Dataflow) タクシー会社向け GO ヘルプデスク GO 施策運用 ・ ・ ・ 加工パイプライン (Dataform) データウェア ハウス AIサービス 加工パイプライン (Dataform) ※ 緑の枠 が自チームの担当領域 ストリーミング挿入 (Pub/Sub, Dataflow)
9. © GO Inc. 9 『GO』データ基盤の活用 • 『GO』データ基盤は多くのデータを保持している ◦ 累計 1,500 万ダウンロードのアプリのユーザーデータ ◦ 約 10 万台のタクシー車両データ ◦ 地図、道路データ ◦ 天気、降水量 ◦ など • 活用事例 ◦ 「AI 予約」や「タクシーの到着時間予想」などの AI サービス ◦ KPI モニタリングやプロダクト分析をもとにした意思決定 ◦ など
10. © GO Inc. 10 活用事例 AI 予約 • AI 予約とは、日時と場所を指定してタクシーを手配する機能 • 予約したい時間と場所におけるタクシー供給量と予約可能かを 数理モデルと機械学習モデルで予測 • 結果、従来の電話予約の 10 倍以上の予約依頼に対応できるように！
11. © GO Inc. 11 活用事例 KPI モニタリング、プロダクト分析、データ抽出 • 日次 KPI モニタリング • 月次事業定例としての利用 • 新規機能・施策リリース時の 評価指標の定義、分析 KPI モニタリング プロダクト分析 データ抽出 • 各部署から依頼に応じて対応 • 国交省など社外への提供も
12. © GO Inc. 背景・課題 12 03
13. © GO Inc. 背景 • 現在、BigQuery × Looker を中心とする分析基盤が整備されている ◦ Looker のアクティブユーザーは 100 人 / 週 • 会社やプロダクトの成長に伴い、データソースとなるテーブルが増加し、3 桁 を超えている • 同様に、分析基盤の利用者も増加し、分析要件も多様化している (主な利用者はデータ アナリスト、データ サイエンティスト、PdM、BizDev) ⇒ 分析に伴う工数が増加している 13
14. © GO Inc. 課題 • 利用者がすぐにデータを活用できない ◦ データがどこにあるのかわからない ◦ データの意味がわからない ◦ データを使ってよいのかわからない • 障害発生時や仕様変更時の調査が大変になっている ◦ データがどのレポートに影響があるのかわからない • いつの間にかデータが壊れている ◦ 利用者からのエスカレーションで初めて気づく 14
15. © GO Inc. 「利用者がすぐにデータを活用できない」について • 課題 ◦ 利用者がすぐに分析できない ▪ データがどこにあるのかわからない ▪ データの意味がわからない ▪ データを使ってよいのかわからない • 具体例 ◦ 利用者が調べ・質問する時間や、それを受け分析基盤担当者が調査・ 回答するのに時間がかかり、本来の業務を圧迫している（0.5 〜 1 人月/月) ◦ 分析をするときに欠損率など、デグレがないことを確認してから 分析する必要がある ◦ 普段ユーザーアプリの分析をしているアナリストが、急遽の依頼により 不慣れな乗務員向けアプリの分析をする時に、ノウハウが分からず、 有識者に質問が集中する 15
16. © GO Inc. 「障害発生時や仕様変更時の調査が大変になっている」について • 課題 ◦ 障害発生時や仕様変更時の調査が大変になっている ▪ データがどのレポートに影響があるのかわからない • 具体例 ◦ 機能がシンプルなタクシー配車だけしかない頃はテーブル数も 数十程度であったが、現在のサービス規模では既に人の記憶で なんとかなるレベルではなくなっており、テーブルの仕様が 変更されると、どのダッシュボードに影響があるのか 誰にもわからない状態になっている 16
17. © GO Inc. 課題解決のため の取り組み メタデータ（データカタログ）、リネージ、データ品質 17 04
18. © GO Inc. 18 課題解決のための取り組み 課題 取り組み 機能 利用者がすぐにデータを活 用できない データがどこにあるのか わからない ドキュメントを整備して 簡単に探せるようにする データカタログ データの意味がわからない ドキュメントを整備して意味が わかるようにする （少なくとも問い合わせ先が わかるようにする) データカタログ データを使ってよいのか わからない データの品質を確認できる ようにして、分析要件を満たすか 判断できるようにする データ品質管理 ＆ データカタログ 障害発生時や仕様変更時の 調査が大変になっている データがどのレポートに 影響があるのかわからない データとレポートを紐づけて 影響範囲を特定できるようにする リネージ いつの間にかデータが 壊れている 利用者からのエスカレーション で初めて気づく データをテストしてデータの 品質低下に気付けるようにする データ品質管理
19. © GO Inc. 19 機能要件 • データカタログ機能要件 ◦ BigQuery および Looker をメタデータとして取り込めること ◦ メタデータを検索できる UI があること ◦ 用語集が画像などを交えたリッチなドキュメントで作成できる ◦ 用語と取り込んだメタデータの紐づけができること • リネージ機能要件 ◦ BigQuery から Looker のリネージが描画できること ◦ (Looker は View ⇔ Explore ⇔ Dashboard まで) • データ品質管理機能要件 ◦ BigQuery のテーブルに対してデータ品質テストが実行できること ◦ パイプライン処理では完全性がテストできること ◦ データマート作成ではビジネス要件を満たすテストができること ◦ (テスト項目は次ページ参照)
20. © GO Inc. 20 データ品質管理 テスト項目 テスト項目 テスト内容 一意 テーブル内で一意になっている NULL NULL ではない 辞書 値が用意した辞書に含まれている 範囲 値が設定範囲内に収まっている if-then 特定の値のときに、ある期待値になっている (A のとき、B は NOT NULL など) 型 json パースしたときに期待した型になっている 欠損 テーブルとテーブルを比較してレコードが欠損していない 鮮度 過去 XX 日（XX 時）のデータが存在する 『エンジニアのためのデータ分析基盤入門』、『Data Quality Definition Language』を参考にしました
21. © GO Inc. 21 Dataplex と DataHub で実現 実現したい 3 つのデータマネジメントの機能を Google Cloud Dataplex と DataHub（OSS）で実現しました データマネジメントの機能 製品 データ品質管理 Google Cloud Dataplex メタデータ DataHub リネージ
22. © GO Inc. データ品質管理を Dataplex で実現する 22 05
23. © GO Inc. 23 Dataplex とは Dataplex は複数の機能を内包した製品です。 • データメッシュ • データカタログ ◦ （元々独立した製品だったが、2022 年に Dataplex に統合された） • データ プロファイリング • データ品質管理 ◦ テスト定義を SQL に変換してテスト ◦ SQL を超えた複雑度を持つテスト（例えば、外れ値を除外してテスト）な どはできない
24. © GO Inc. 24 Dataplex データ品質管理 Dataplex データ品質管理には 2 つの機能があり、データ品質タスクを選択した 項目 自動データ品質（Auto DQ） データ品質タスク（DQ Tasks） 概要 データ プロファイリングの結果をもとに 自動的にテストルールを推奨してくれる。 手動でテストルールを設定することもできる OSS をベースにしたデータ品質サービス。現在 は Auto DQ の使用が推奨されている 設定の簡単さ ◯ UI 上から簡単に設定できる ✕ UI 上から設定できない。Yaml ファイルにテ ストルールを記述し、GCS にファイルを配置す る テスト 設定 定義済みテスト ◎ 範囲チェック、NULL チェック、 辞書チェック、正規表現チェック、 一意性チェック、統計チェック ◯ NULL チェック、空文字チェック、正規表現 チェック ユーザ定義テスト ✕ SELECT 句しかかけない。JOINが使えない (この問題については Google Issue Tracker に起票済み) ◯ SQL 全体をかける。JOIN も使える CLI (gcloudコマンド) 対応 ✕(※) ◯ 結果出力 BQコンソールからの確認 ✕(※) ✕ BQのテーブルとして出力 ✕(※) ◯ 採用 これが決め手 欠損テストのために JOINが必要 (※)2023 年 8 月時点で ◯ になった
25. © GO Inc. • 結論 ◦ Dataform も検討したが不採用とした • 理由 ◦ Dataplex と Dataform でテストできる項目に大差はない。 どちらも SQL を実行するだけであるため ◦ そのため Dataplex と Dataform の優位な点を比較し、 Dataplex を採用した • Dataplex が優位な点 ◦ 今後の拡張性に期待が持てること • Dataform が優位な点 ◦ テスト失敗時に後続処理を停止できること ▪ 弊社の場合はメリットにならない。現状のユースケースでは後続処 理が停止するぐらいであれば、品質が低いテーブルを生成するほう が良い場合が多いため ▪ (例: テーブルのレコード件数から主要KPIを計算し、詳細分析には特定のカラムの品質が 重要になる場合であれば一旦テーブルが生成されたほうが良い) Dataform Assertion ではダメなの？ 25
26. © GO Inc. Dataplex の導入 • 概要 ◦ パイプライン処理では完全性、データマート作成ではビジネス要件をテストした • やったこと ◦ テストの設計 ▪ 全部（200 〜 300 テーブル以上）をテストするのは工数がかかりすぎるため 諦めた ▪ レポート配信など日常的に使用される約 20 テーブルに、導入が比較的容易な 鮮度テストを設定した • 30 分間隔の区切りでレコードの有無をテスト。理由は以前、23 時に障害が あって日次で集計したときに 1 時間分データが足りないことがあったため ▪ （次のページに続く） 26
27. © GO Inc. Dataplex の導入 • やったこと ◦ テストの設計 ▪ KPI に直結する重要 4 テーブルのテストを設計した • 設計方法：テスト項目とカラムのマトリクスから網羅的に抽出 • テストの例 ◦ トランザクション結果を格納された DB を正として、アプリログが 欠損していないかのテストを設計した ◦ データマート作成後にレコードが欠落していないかテストを設計した ◦ テーブル固有のビジネス要件からテストを設計した ◦ Dataplex の実行設定 ▪ テストを日次で実行し、失敗時は Slack 通知する ◦ 振り返り会の設立 ▪ 定期的に振り返り会を実施し、テスト失敗時の原因調査・対応する運用を確立した 27
28. © GO Inc. Dataplex 導入の結果 • 結果 ◦ 既存のテーブルからバグが検出された ▪ 長く運用してきたテーブルのため、どこかのタイミングでバグが混入したが見過ごされてきた • あるカラムはユニークであるはずがユニークになっていなかった • 数珠つなぎに設定されるデータがあり、自位置から先頭を見つける処理にバグがあった。 RECURSIVE 構文を利用した方式を提案した • 所感 ◦ テスト設計時は効果に少し懐疑的な部分もあったが、この件からテストの重要性を再認識できた ◦ データソース起因の問題はすぐに直すことが出来ず、対応が長期化することがあると認識できた ▪ すぐに直すことができない理由： • データソースは複数のマイクロサービスであり、どこでバグが発生しているのか 特定するのが難しい • データソースはプロダクト直結であり、修正に時間が掛かる ◦ テストの失敗が長期間 Slack に通知されてしまうので、テスト設定をオフにするのではなく Slack の通知を制御するようにしています 28
29. © GO Inc. データカタログを DataHubで実現する 29 06
30. © GO Inc. 30 データカタログを実現する製品選定 • 以下の製品を調査しました ◦ Castor ◦ Metaphor ◦ Secoda ◦ Acryl（DataHub の SaaS 版） ◦ Google Cloud Data Catalog ◦ DataHub • セキュリティポリシー上 SaaS 製品の利用は難しいという判断になり、SasS 製品は除外されました • 次ページで「Google Cloud Data Catalog」、「DataHub」を比較します
31. © GO Inc. 31 データカタログを実現する製品選定 項目 Google Cloud Data Catalog DataHub 概要 フルマネージドのメタデータ管 理サービス DataHub は OSS のデータカタログで、 元々 LinkedIn 社のメタデータ管理ツール をオープンソース化したものです。 利用までのハードル ◯ ✕ 構築・運用が工数大 UIが使いやすい ◯ ◯ 用語集の作成ができる ◯ ◯ メタデータが BigQuery, Looker に対応している ✕ Looker に対応していない ◯ リネージが BigQuery, Looker に対応している ✕ Looker に対応していない ◯ 用語を BigQuery, Looker と紐付けられる ✕ Looker に対応していない ◯ 採用 これが決め手 これが決め手 これが決め手 Looker 対応 が必須要件
32. © GO Inc. 32 メタデータ一覧(DataHubへの取込) メタデータの種類 取得元の種類 取得元の詳細 取得方法 システムメタデータ データウェア ハウス BigQuery のデータセット、 テーブルの Description BigQuery API を利用して DataHub の機 能で収集 BI LookML （View 定義、Explore 定 義） GitHub API を利用して DataHub の機能 で収集 Dashboard と LookML の関 係 Looker API を利用して DataHub の機能 で収集 ビジネスメタデータ 用語集 既存のドキュメントから転記
33. © GO Inc. 33 BigQuery の Description の充実 メタデータ連 携 BigQuery の Description を拡充するために、データソースの DB の CREATE TABLE 文にコメントを埋めて、BigQuery に連携しました データソースの DB (MySQL/PostgreSQL) BigQuery DataHub データソースの DB 担当 データ基盤の担当 INFORMATION _SCHEMA Description システム メタデータ CREATE TABLE 文のコメントが時々埋 まっていないことがあり、開発側と調整し て、開発側の GitHub リポジトリに PR を出すスキームを整備しました（なるべく データの上流で対処する） Description 連携 GitHub コメント拡充の PR テーブルのリリース CREATE TABLE文 ID XXXX COMMENT "ID" NAME XXXX COMMENT "名前" GitHub
34. © GO Inc. 34 DataHub（データカタログ）導入の結果 • 結果 ◦ メタデータの拡充が不足しており、利用者が自己解決できるほど整備が できていない ▪ メタデータの拡充の体制ができておらず、あまり進んでいない • 打ち手として、役員に必要性を説得し、旗振り役の組織長（部長） の工数を確保した • 所感 ◦ DataHub の運用が大変 ▪ OSS の集合体。裏で MySQL, Elasticsearch, Kafka, neo4j などが動 いていて不具合調査が大変。オーバースペック ▪ Google Cloud Data Catalog で Looker の対応をして欲しい！
35. © GO Inc. リネージを DataHub で実現する 35 07
36. © GO Inc. ※画像は DataHub で BigQuery から Looker までのリネージが描画されているもの BigQuery はテーブルレベルリネージ、Looker はカラムレベルリネージになっている 36 DataHub (リネージ) の使い勝手 BigQuery テーブル BigQuery View Looker View Looker Explore Looker Dashboard Looker Dashboard の要素
37. © GO Inc. 37 DataHub (リネージ) 導入の結果 • 結果 ◦ データカタログと違い、基本的にメタデータの連携だけで リネージが使えるようになった ◦ BigQuery から Looker まで繋がることで調査がしやすくなった ◦ 課題として、導入はしたが想定利用者にあまり認知されておら ず、仕様変更や障害調査で使われていないことが判明 ▪ 今後、利用されるように推進していく
38. © GO Inc. まとめ 38 08
39. © GO Inc. 39 まとめ • 背景、課題 ◦ プロダクトが成長するに従って、データソースおよび利用者増加 ◦ 分析仕様が複雑化し、データ品質に関する課題が発生 • 課題への対応 ◦ データカタログ、リネージ、データ品質管理の導入 • 「利用者がすぐにデータを活用できない」 ◦ メタデータの拡充が不足しており、利用者が自己解決できるほど整備ができていない。 メタデータ拡充の旗振り役が重要 • 「障害発生時や仕様変更時の調査が大変になっている」 ◦ BigQuery から Looker までリネージが繋がり、調査がしやすくなった。 今後は、社内での認知を広めていく • 「いつの間にかデータが壊れている」 ◦ 重要なテーブルに対してテストを実施した結果、テーブルの品質異常を 発見することができた。テストの重要性を再認識した
40. © GO Inc. 40 We’re hiring ! データ アーキテクト、データ マネージャー 絶賛募集中です！ リンクはこちら↓ https://hrmos.co/pages/goinc/jobs/3300002 https://hrmos.co/pages/goinc/jobs/9900975 もしくは「goinc データアーキテクト」 「goinc データマネージャー」で検索！
41. 文章・画像等の内容の無断転載及び複製等の行為はご遠慮ください。 © GO Inc.