Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

GO Inc. dev
November 22, 2023

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

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

GO Inc. dev

November 22, 2023
Tweet

More Decks by GO Inc. dev

Other Decks in Programming

Transcript

  1. © GO Inc.
    2023.11.16
    GO株式会社
    AI技術開発部データプラットフォームグループ
    伊田 正寿
    Google Cloud Next Tokyo '23
    BigQuery のデータ品質やデータ活
    用を高める Dataplex 等の活用

    View full-size slide

  2. © GO Inc.
    本資料はデータ基盤の開発者やデータを活用したい方に対して、
    データ品質の改善やメタデータの整備事例を紹介しています。
    2023.11現在も試行錯誤中ではありますが、現場の生の声として、
    参考にして頂ければ幸いです。
    ※本資料は Google Cloud Next Tokyo '23 のセッションの発表資料
    に、一部公開用に修正を加えております

    View full-size slide

  3. © GO Inc.
    GO株式会社
    データエンジニア / 伊田 正寿
    (タクシーアプリ『GO』のデータ基盤の開発運用をやっています)
    おでんがおいしい季節になりました
    3
    自己紹介
    プロフィール写真
    正方形にトリミングした写
    真を「図形に合わせてトリ
    ミング」で円形にすると真
    円になる

    View full-size slide

  4. Index
    © GO Inc.
    1. 会社紹介
    2. データ基盤紹介
    3. 背景・課題
    4. 課題解決のための取り組み
    5. データ品質管理を Dataplex で実現する
    6. データカタログを DataHub で実現する
    7. リネージを DataHub で実現する
    8. まとめ
    4

    View full-size slide

  5. © GO Inc. 5
    会社紹介
    01

    View full-size slide

  6. © GO Inc.
    6
    GO株式会社について
    タクシーDX
    乗務員向けナビゲーション端末
    タクシーアプリのキャッシュレス決済機

    乗務員向けアプリの開発・運営
    ※記載されている会社名や商品名などは、各社の商標または登録商標です。(出願中含む)
    脱炭素化
    タクシーの運行特性に応じた
    EV運行マネジメントとエネルギーマネジメントに
    よるCO2削減
    アプリ注文のみを受け取る車両の配車
    交通事故削減支援
    AIドラレコを活用した
    危険シーンを解析・報告し運行管理に活用
    タクシーサイネージメディア(動画広告)
    AIドラレコのデータを元に、地図と実際の道路
    情報の差分をAI技術によりメンテナンス
    タクシー配車や経費精算などを簡単効率化
    した法人向けサービス

    View full-size slide

  7. © GO Inc. 7
    データ基盤紹介
    02

    View full-size slide

  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)

    View full-size slide

  9. © GO Inc.
    9
    『GO』データ基盤の活用
    ● 『GO』データ基盤は多くのデータを保持している
    ○ 累計 1,500 万ダウンロードのアプリのユーザーデータ
    ○ 約 10 万台のタクシー車両データ
    ○ 地図、道路データ
    ○ 天気、降水量
    ○ など
    ● 活用事例
    ○ 「AI 予約」や「タクシーの到着時間予想」などの AI サービス
    ○ KPI モニタリングやプロダクト分析をもとにした意思決定
    ○ など

    View full-size slide

  10. © GO Inc.
    10
    活用事例 AI 予約
    ● AI 予約とは、日時と場所を指定してタクシーを手配する機能
    ● 予約したい時間と場所におけるタクシー供給量と予約可能かを
    数理モデルと機械学習モデルで予測
    ● 結果、従来の電話予約の 10 倍以上の予約依頼に対応できるように!

    View full-size slide

  11. © GO Inc.
    11
    活用事例 KPI モニタリング、プロダクト分析、データ抽出
    ● 日次 KPI モニタリング
    ● 月次事業定例としての利用
    ● 新規機能・施策リリース時の
    評価指標の定義、分析
    KPI モニタリング プロダクト分析 データ抽出
    ● 各部署から依頼に応じて対応
    ● 国交省など社外への提供も

    View full-size slide

  12. © GO Inc.
    背景・課題
    12
    03

    View full-size slide

  13. © GO Inc.
    背景
    ● 現在、BigQuery × Looker を中心とする分析基盤が整備されている
    ○ Looker のアクティブユーザーは 100 人 / 週
    ● 会社やプロダクトの成長に伴い、データソースとなるテーブルが増加し、3 桁
    を超えている
    ● 同様に、分析基盤の利用者も増加し、分析要件も多様化している
    (主な利用者はデータ アナリスト、データ サイエンティスト、PdM、BizDev)
    ⇒ 分析に伴う工数が増加している
    13

    View full-size slide

  14. © GO Inc.
    課題
    ● 利用者がすぐにデータを活用できない
    ○ データがどこにあるのかわからない
    ○ データの意味がわからない
    ○ データを使ってよいのかわからない
    ● 障害発生時や仕様変更時の調査が大変になっている
    ○ データがどのレポートに影響があるのかわからない
    ● いつの間にかデータが壊れている
    ○ 利用者からのエスカレーションで初めて気づく
    14

    View full-size slide

  15. © GO Inc.
    「利用者がすぐにデータを活用できない」について
    ● 課題
    ○ 利用者がすぐに分析できない
    ■ データがどこにあるのかわからない
    ■ データの意味がわからない
    ■ データを使ってよいのかわからない
    ● 具体例
    ○ 利用者が調べ・質問する時間や、それを受け分析基盤担当者が調査・
    回答するのに時間がかかり、本来の業務を圧迫している(0.5 〜 1 人月/月)
    ○ 分析をするときに欠損率など、デグレがないことを確認してから
    分析する必要がある
    ○ 普段ユーザーアプリの分析をしているアナリストが、急遽の依頼により
    不慣れな乗務員向けアプリの分析をする時に、ノウハウが分からず、
    有識者に質問が集中する
    15

    View full-size slide

  16. © GO Inc.
    「障害発生時や仕様変更時の調査が大変になっている」について
    ● 課題
    ○ 障害発生時や仕様変更時の調査が大変になっている
    ■ データがどのレポートに影響があるのかわからない
    ● 具体例
    ○ 機能がシンプルなタクシー配車だけしかない頃はテーブル数も
    数十程度であったが、現在のサービス規模では既に人の記憶で
    なんとかなるレベルではなくなっており、テーブルの仕様が
    変更されると、どのダッシュボードに影響があるのか
    誰にもわからない状態になっている
    16

    View full-size slide

  17. © GO Inc.
    課題解決のため
    の取り組み
    メタデータ(データカタログ)、リネージ、データ品質
    17
    04

    View full-size slide

  18. © GO Inc.
    18
    課題解決のための取り組み
    課題 取り組み 機能
    利用者がすぐにデータを活
    用できない
    データがどこにあるのか
    わからない
    ドキュメントを整備して
    簡単に探せるようにする
    データカタログ
    データの意味がわからない ドキュメントを整備して意味が
    わかるようにする
    (少なくとも問い合わせ先が
    わかるようにする)
    データカタログ
    データを使ってよいのか
    わからない
    データの品質を確認できる
    ようにして、分析要件を満たすか
    判断できるようにする
    データ品質管理
    & データカタログ
    障害発生時や仕様変更時の
    調査が大変になっている
    データがどのレポートに
    影響があるのかわからない
    データとレポートを紐づけて
    影響範囲を特定できるようにする
    リネージ
    いつの間にかデータが
    壊れている
    利用者からのエスカレーション
    で初めて気づく
    データをテストしてデータの
    品質低下に気付けるようにする
    データ品質管理

    View full-size slide

  19. © GO Inc.
    19
    機能要件
    ● データカタログ機能要件
    ○ BigQuery および Looker をメタデータとして取り込めること
    ○ メタデータを検索できる UI があること
    ○ 用語集が画像などを交えたリッチなドキュメントで作成できる
    ○ 用語と取り込んだメタデータの紐づけができること
    ● リネージ機能要件
    ○ BigQuery から Looker のリネージが描画できること
    ○ (Looker は View ⇔ Explore ⇔ Dashboard まで)
    ● データ品質管理機能要件
    ○ BigQuery のテーブルに対してデータ品質テストが実行できること
    ○ パイプライン処理では完全性がテストできること
    ○ データマート作成ではビジネス要件を満たすテストができること
    ○ (テスト項目は次ページ参照)

    View full-size slide

  20. © GO Inc.
    20
    データ品質管理 テスト項目
    テスト項目 テスト内容
    一意 テーブル内で一意になっている
    NULL NULL ではない
    辞書 値が用意した辞書に含まれている
    範囲 値が設定範囲内に収まっている
    if-then 特定の値のときに、ある期待値になっている
    (A のとき、B は NOT NULL など)
    型 json パースしたときに期待した型になっている
    欠損 テーブルとテーブルを比較してレコードが欠損していない
    鮮度 過去 XX 日(XX 時)のデータが存在する
    『エンジニアのためのデータ分析基盤入門』、『Data Quality Definition Language』を参考にしました

    View full-size slide

  21. © GO Inc.
    21
    Dataplex と DataHub で実現
    実現したい 3 つのデータマネジメントの機能を Google Cloud Dataplex と
    DataHub(OSS)で実現しました
    データマネジメントの機能 製品
    データ品質管理 Google Cloud Dataplex
    メタデータ DataHub
    リネージ

    View full-size slide

  22. © GO Inc.
    データ品質管理を
    Dataplex で実現する
    22
    05

    View full-size slide

  23. © GO Inc.
    23
    Dataplex とは
    Dataplex は複数の機能を内包した製品です。
    ● データメッシュ
    ● データカタログ
    ○ (元々独立した製品だったが、2022 年に Dataplex に統合された)
    ● データ プロファイリング
    ● データ品質管理
    ○ テスト定義を SQL に変換してテスト
    ○ SQL を超えた複雑度を持つテスト(例えば、外れ値を除外してテスト)な
    どはできない

    View full-size slide

  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 月時点で ◯ になった

    View full-size slide

  25. © GO Inc.
    ● 結論
    ○ Dataform も検討したが不採用とした
    ● 理由
    ○ Dataplex と Dataform でテストできる項目に大差はない。
    どちらも SQL を実行するだけであるため
    ○ そのため Dataplex と Dataform の優位な点を比較し、
    Dataplex を採用した
    ● Dataplex が優位な点
    ○ 今後の拡張性に期待が持てること
    ● Dataform が優位な点
    ○ テスト失敗時に後続処理を停止できること
    ■ 弊社の場合はメリットにならない。現状のユースケースでは後続処
    理が停止するぐらいであれば、品質が低いテーブルを生成するほう
    が良い場合が多いため
    ■ (例: テーブルのレコード件数から主要KPIを計算し、詳細分析には特定のカラムの品質が
    重要になる場合であれば一旦テーブルが生成されたほうが良い)
    Dataform Assertion ではダメなの?
    25

    View full-size slide

  26. © GO Inc.
    Dataplex の導入
    ● 概要
    ○ パイプライン処理では完全性、データマート作成ではビジネス要件をテストした
    ● やったこと
    ○ テストの設計
    ■ 全部(200 〜 300 テーブル以上)をテストするのは工数がかかりすぎるため
    諦めた
    ■ レポート配信など日常的に使用される約 20 テーブルに、導入が比較的容易な
    鮮度テストを設定した
    ● 30 分間隔の区切りでレコードの有無をテスト。理由は以前、23 時に障害が
    あって日次で集計したときに 1 時間分データが足りないことがあったため
    ■ (次のページに続く)
    26

    View full-size slide

  27. © GO Inc.
    Dataplex の導入
    ● やったこと
    ○ テストの設計
    ■ KPI に直結する重要 4 テーブルのテストを設計した
    ● 設計方法:テスト項目とカラムのマトリクスから網羅的に抽出
    ● テストの例
    ○ トランザクション結果を格納された DB を正として、アプリログが
    欠損していないかのテストを設計した
    ○ データマート作成後にレコードが欠落していないかテストを設計した
    ○ テーブル固有のビジネス要件からテストを設計した
    ○ Dataplex の実行設定
    ■ テストを日次で実行し、失敗時は Slack 通知する
    ○ 振り返り会の設立
    ■ 定期的に振り返り会を実施し、テスト失敗時の原因調査・対応する運用を確立した
    27

    View full-size slide

  28. © GO Inc.
    Dataplex 導入の結果
    ● 結果
    ○ 既存のテーブルからバグが検出された
    ■ 長く運用してきたテーブルのため、どこかのタイミングでバグが混入したが見過ごされてきた
    ● あるカラムはユニークであるはずがユニークになっていなかった
    ● 数珠つなぎに設定されるデータがあり、自位置から先頭を見つける処理にバグがあった。
    RECURSIVE 構文を利用した方式を提案した
    ● 所感
    ○ テスト設計時は効果に少し懐疑的な部分もあったが、この件からテストの重要性を再認識できた
    ○ データソース起因の問題はすぐに直すことが出来ず、対応が長期化することがあると認識できた
    ■ すぐに直すことができない理由:
    ● データソースは複数のマイクロサービスであり、どこでバグが発生しているのか
    特定するのが難しい
    ● データソースはプロダクト直結であり、修正に時間が掛かる
    ○ テストの失敗が長期間 Slack に通知されてしまうので、テスト設定をオフにするのではなく
    Slack の通知を制御するようにしています
    28

    View full-size slide

  29. © GO Inc.
    データカタログを
    DataHubで実現する
    29
    06

    View full-size slide

  30. © GO Inc.
    30
    データカタログを実現する製品選定
    ● 以下の製品を調査しました
    ○ Castor
    ○ Metaphor
    ○ Secoda
    ○ Acryl(DataHub の SaaS 版)
    ○ Google Cloud Data Catalog
    ○ DataHub
    ● セキュリティポリシー上 SaaS 製品の利用は難しいという判断になり、SasS
    製品は除外されました
    ● 次ページで「Google Cloud Data Catalog」、「DataHub」を比較します

    View full-size slide

  31. © GO Inc.
    31
    データカタログを実現する製品選定
    項目 Google Cloud
    Data Catalog
    DataHub
    概要 フルマネージドのメタデータ管
    理サービス
    DataHub は OSS のデータカタログで、
    元々 LinkedIn 社のメタデータ管理ツール
    をオープンソース化したものです。
    利用までのハードル ◯ ✕
    構築・運用が工数大
    UIが使いやすい ◯ ◯
    用語集の作成ができる ◯ ◯
    メタデータが BigQuery,
    Looker に対応している
    ✕ Looker に対応していない ◯
    リネージが BigQuery,
    Looker に対応している
    ✕ Looker に対応していない ◯
    用語を BigQuery,
    Looker と紐付けられる
    ✕ Looker に対応していない ◯
    採用
    これが決め手
    これが決め手
    これが決め手
    Looker 対応
    が必須要件

    View full-size slide

  32. © GO Inc.
    32
    メタデータ一覧(DataHubへの取込)
    メタデータの種類 取得元の種類 取得元の詳細 取得方法
    システムメタデータ データウェア
    ハウス
    BigQuery のデータセット、
    テーブルの Description
    BigQuery API を利用して DataHub の機
    能で収集
    BI LookML
    (View 定義、Explore 定
    義)
    GitHub API を利用して DataHub の機能
    で収集
    Dashboard と LookML の関

    Looker API を利用して DataHub の機能
    で収集
    ビジネスメタデータ 用語集 既存のドキュメントから転記

    View full-size slide

  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

    View full-size slide

  34. © GO Inc.
    34
    DataHub(データカタログ)導入の結果
    ● 結果
    ○ メタデータの拡充が不足しており、利用者が自己解決できるほど整備が
    できていない
    ■ メタデータの拡充の体制ができておらず、あまり進んでいない
    ● 打ち手として、役員に必要性を説得し、旗振り役の組織長(部長)
    の工数を確保した
    ● 所感
    ○ DataHub の運用が大変
    ■ OSS の集合体。裏で MySQL, Elasticsearch, Kafka, neo4j などが動
    いていて不具合調査が大変。オーバースペック
    ■ Google Cloud Data Catalog で Looker の対応をして欲しい!

    View full-size slide

  35. © GO Inc.
    リネージを
    DataHub で実現する
    35
    07

    View full-size slide

  36. © GO Inc.
    ※画像は DataHub で BigQuery から Looker までのリネージが描画されているもの
    BigQuery はテーブルレベルリネージ、Looker はカラムレベルリネージになっている
    36
    DataHub (リネージ) の使い勝手
    BigQuery
    テーブル
    BigQuery
    View
    Looker
    View
    Looker
    Explore
    Looker
    Dashboard
    Looker
    Dashboard
    の要素

    View full-size slide

  37. © GO Inc.
    37
    DataHub (リネージ) 導入の結果
    ● 結果
    ○ データカタログと違い、基本的にメタデータの連携だけで
    リネージが使えるようになった
    ○ BigQuery から Looker まで繋がることで調査がしやすくなった
    ○ 課題として、導入はしたが想定利用者にあまり認知されておら
    ず、仕様変更や障害調査で使われていないことが判明
    ■ 今後、利用されるように推進していく

    View full-size slide

  38. © GO Inc.
    まとめ
    38
    08

    View full-size slide

  39. © GO Inc.
    39
    まとめ
    ● 背景、課題
    ○ プロダクトが成長するに従って、データソースおよび利用者増加
    ○ 分析仕様が複雑化し、データ品質に関する課題が発生
    ● 課題への対応
    ○ データカタログ、リネージ、データ品質管理の導入
    ● 「利用者がすぐにデータを活用できない」
    ○ メタデータの拡充が不足しており、利用者が自己解決できるほど整備ができていない。
    メタデータ拡充の旗振り役が重要
    ● 「障害発生時や仕様変更時の調査が大変になっている」
    ○ BigQuery から Looker までリネージが繋がり、調査がしやすくなった。
    今後は、社内での認知を広めていく
    ● 「いつの間にかデータが壊れている」
    ○ 重要なテーブルに対してテストを実施した結果、テーブルの品質異常を
    発見することができた。テストの重要性を再認識した

    View full-size slide

  40. © GO Inc.
    40
    We’re hiring !
    データ アーキテクト、データ マネージャー
    絶賛募集中です!
    リンクはこちら↓
    https://hrmos.co/pages/goinc/jobs/3300002
    https://hrmos.co/pages/goinc/jobs/9900975
    もしくは「goinc データアーキテクト」
    「goinc データマネージャー」で検索!

    View full-size slide

  41. 文章・画像等の内容の無断転載及び複製等の行為はご遠慮ください。
    © GO Inc.

    View full-size slide