©2023 10X, Inc. Elementaryを用いたデータ品質の 可視化とデータ基盤の運用改善 Tokyo dbt Meetup #8 株式会社10X Yasuhisa Yoshida

©2023 10X, Inc. 自己紹介 ● 吉田 康久 ○ Twitterやはてなidは@syou6162 / id:syou6162 ● 株式会社10Xでデータエンジニア ○ 2022/09に入社 ○ エンジニアリング本部 データサイエンス&エンジニアリング部に所属 ○ データマネジメント / データガバナンスの仕事をしてます ○ 京都から働いてます ○ Tokyo dbt Meetup主催の@takimoさんは同僚です ● これまでの職歴としては研究者(NLP & ML) => Webアプリケーションエンジニア, MLエンジニア => データエンジニ ア, Analytics Engineer ● 最近はdatatech-jpのオーガナイザーの一人をやってます ○ 月末の「みなさん、データのメタデータ管理ってどうやってますか？」でも登壇します 2

©2023 10X, Inc. アイスブレイク: 最近推しのdbt関連のライブラリ(dbt-osmosis & dbterd) 3 推しなので、両方ともコントリビューター になりました。 Slackのコメント欄で皆さんの推しdbtライ ブラリを教えてください!

©2023 10X, Inc. アジェンダ ● 背景: 10XとStailerについて ● 10Xのデータマネジメント上の課題の遷移 ● 現在取り組んでいるデータ品質の課題と取り組み方の全体像 ● Elementaryを使ったデータ品質の可視化 ○ 可用性の可視化 ○ 正確性の可視化 ● Elementaryを使ったデータ基盤の運用改善への活用事例 ○ 安全にテーブルを撤退する ○ 障害時に報告すべき関係者を素早くピックアップ ○ 生成元と参照先でデータ品質のギャップがないかを把握する 4

©2023 10X, Inc. アジェンダ ● 背景: 10XとStailerについて ● 10Xのデータマネジメント上の課題の遷移 ● 現在取り組んでいるデータ品質の課題と取り組み方の全体像 ● Elementaryを使ったデータ品質の可視化 ○ 可用性の可視化 ○ 正確性の可視化 ● Elementaryを使ったデータ基盤の運用改善への活用事例 ○ 安全にテーブルを撤退する ○ 障害時に報告すべき関係者を素早くピックアップ ○ 生成元と参照先でデータ品質のギャップがないかを把握する 5

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

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

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

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

©2023 10X, Inc. アジェンダ ● 背景: 10XとStailerについて ● 10Xのデータマネジメント上の課題の遷移 ● 現在取り組んでいるデータ品質の課題と取り組み方の全体像 ● Elementaryを使ったデータ品質の可視化 ○ 可用性の可視化 ○ 正確性の可視化 ● Elementaryを使ったデータ基盤の運用改善への活用事例 ○ 安全にテーブルを撤退する ○ 障害時に報告すべき関係者を素早くピックアップ ○ 生成元と参照先でデータ品質のギャップがないかを把握する 10

©2023 10X, Inc. 入社直後にやったこと: データマネジメント成熟度アセスメントの実施 11 事業上データが重要にも関わらず 様々な箇所でデータの課題が山積 DMBOKの項目に沿ってアセスメント を実施。優先度を決めた

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

©2023 10X, Inc. 課題の遷移: データセキュリティ => データディスカバリー => メタデータ 13 セキュリティを改善した結果、ボトルネックが データディスカバリーにシフト データディスカバリーを改善するために、データ カタログにDataplex、メタデータ管理に dbt-osmosisを導入。メタデータのカバレッジが1 割から5~8割に改善! 詳細は発表資料やアーカイブ 動画を参照してください

©2023 10X, Inc. アジェンダ ● 背景: 10XとStailerについて ● 10Xのデータマネジメント上の課題の遷移 ● 現在取り組んでいるデータ品質の課題と取り組み方の全体像 ● Elementaryを使ったデータ品質の可視化 ○ 可用性の可視化 ○ 正確性の可視化 ● Elementaryを使ったデータ基盤の運用改善への活用事例 ○ 安全にテーブルを撤退する ○ 障害時に報告すべき関係者を素早くピックアップ ○ 生成元と参照先でデータ品質のギャップがないかを把握する 14

©2023 10X, Inc. 現在取り組んでいる課題: データ品質 15 項目名 具体例 可用性 注文の分析をしたいと思い、いつも通り利用している注文テーブルを確認しようとしたらテーブルが存在していなかった 一意性 あるユーザーIDに対して二つのレコードが存在しており、ユーザーが登録した日時が正確に判断できない 一貫性 商圏を確認するために注文情報にある住所データを利用していたが、同じ地域なのに別の表記がされていて分析するときに名寄 せが必要になってしまう 妥当性 購入率などの確率を表す指標が 100%を超えてしまう 追跡可能性 スプレッドシート経由でデータを提供しようとしたが、他のシートの参照やコピーを複数利用していたので実際にどのデータから作 成されたシートなのかが判断できない 明瞭性 商品の分析をしようと BigQueryにアクセスしてデータを探していたが、目的のデータがどこにあるのかわからない

©2023 10X, Inc. 前提: 包括的にデータ品質を捉えたい ● 社内に複数のデータプロダクトが存在 ○ 分析用DWH: ■ 最新バージョン / 旧バージョン / adhocなど複数のバージョンが存在 ■ 余談: これ以外にも古い2系統のDWHが存在していたものを撤退完了しました ○ 商品在庫マスタ: パートナー固有の事情はどうしても入る部分があり、商品在庫マスタもパートナー毎に構成 やデータ品質が異なる場合がある ● 個別にデータ指標を定義すると、比較が困難になる ○ 例: 求められるデータ品質を満たせていない部署にデータエンジニアを多めにアサインしたいが、指標が異な ると客観的な判断が難しい ○ 例: 異なるデータチーム間でのコミュニケーションが難しくなる(データ品質指標のSSoT問題) ○ 逆に、指標が同じであればあるプロダクトの改善方法が別プロダクトの改善に生かしやすくなるかもしれない 16 アーキテクチャは大きく異なるものの、担保でき ているデータ品質はどれくらい違うのか?は定量 化できていなかった

©2023 10X, Inc. データ品質やその管理のあるべき状態を定義する 17 項目 As-is To-be データの目的の明 確化 データの目的が不明瞭なものがある - あるデータの目的が見たいときにいつでも見れる状態になっている - データの目的に関する項目は一定のフォーマットに従って統一的に定義さ れている データ品質指標の 定義 全社共通の指標の定義がない 全社共通でデータ品質を計ることができる指標が明確に定義されている。開 発者の間で指標の共通認識がある 指標の測定方法 の確立 指標の測定方法がない 指標を定量的に測定するメトリクスが定義されている 指標の可視化・監 視 指標が可視化されておらず、指標に変化があっても検知できない - 指標を常に可視化し、データ利用者がデータの品質を認識できる - 指標のマクロな変化を監視し、データ開発者がデータ品質が維持できてい るかを確認できる 指標を維持、改善 する開発ライフサ イクル 一部にアーキテクチャは存在するが、個人の設計や実装能力に依 存している部分が大きい - 個人に依存しない開発ライフサイクルやパッケージを開発し、指標に対応し た実装方法やテストが明確になっている - 各開発チームの中で開発ライフサイクルに関する To-beが定められており、 それらに向かった活動が行われている (Enabling) 利用者の品質の 認知 - データ利用者によってデータ品質の理解度に差がある - 共通の理解が取れているのかは定かではない データ利用者が品質に対する高い理解を等しく持てている状態を作る (デー タアンバサダー施策など ) いきなり指標の 可視化を行なわない!

©2023 10X, Inc. データ品質指標の定義 ● DAMAやデータ品質管理ガイドブックなどデータ品質の定義はよく知られたものがある ○ しかし、指標の定義が10以上あり、スタートアップがデータ品質に取り組むにはちょっと重い... ● チーム内の認知負荷を上げないためにも、大雑把に4つに分類 ○ Data Quality Score: The next chapter of data quality at Airbnbを参考にさせてもらった 18 利用性については dbt-osmosisを使ったメタ データ管理で大部分でき ていた dbtを使っていれば自然 とリネージが可視化でき るため、大部分できてい た

©2023 10X, Inc. アジェンダ ● 背景: 10XとStailerについて ● 10Xのデータマネジメント上の課題の遷移 ● 現在取り組んでいるデータ品質の課題と取り組み方の全体像 ● Elementaryを使ったデータ品質の可視化 ○ 可用性の可視化 ○ 正確性の可視化 ● Elementaryを使ったデータ基盤の運用改善への活用事例 ○ 安全にテーブルを撤退する ○ 障害時に報告すべき関係者を素早くピックアップ ○ 生成元と参照先でデータ品質のギャップがないかを把握する 19

©2023 10X, Inc. データ品質指標の実装 / 可視化: elementary ● dbtのモニタリングツールの一つ ● Cloud版とOSS版があるが、本日の話はどちらでも使える話 ● 提供する機能は簡易なダッシュボードやSlackのアラート通知など 20

©2023 10X, Inc. elementaryの中でイチオシの機能: スキーマ変更の検知 ● 大きく分けて2種類の方法が提供されている ● elementary.schema_changes ○ スキーマ情報の変化を時系列で見る方法 ■ elementaryはdbtの実行後にon-end hookでデータソースや成果物のカラムの型などを保存する ■ 前回実行時と型の情報が異なる場合に検知してくれる ○ 時系列での型の比較をするだけなので、schema_changes_from_baselineと比べると簡単に始められる ● elementary.schema_changes_from_baseline ○ yamlに記載されているdata_typeとDBの型が異なるかを検知する方法 ○ data_typeを記載しないといけない分、手間はかかる ■ Data Contractをやりたいのであれば、こちらのほうが理想的ではある(と個人的に思う) ■ なお、data_typeを機械的に網羅したい場合、dbt-osmosisが一撃で埋めてくれるのでオススメ ● いずれの方法でもカラムの追加 / 削除 / 型の変更の検知がサポートされている 21 外部から受領するデータで固く作りたい場合や データメッシュなど他チームと協業する際にオススメ!

©2023 10X, Inc. データ品質はelementaryの基本機能だけで十分...? ● 少なくとも10Xの場合はそうではなかった ● 理由1: 社内に複数のデータプロダクトが存在(分析用DWH / 商品在庫マスタ) ○ dbtのプロジェクトは分かれているが、指標としては一元的に見たい ● 理由2: 独自に実装したdbtのテストのデータ品質項目への分類を独自に行ないたい ○ dbt標準のテストであれば、elementaryが大まかに分類してくれる ■ 例: not_null => 完全性(Completeness) ○ しかし、それだけでは足りず独自にテストを書いているため、それらも独自に分類をしたい ■ Singular tests ■ Custom generic tests ● 理由3: 可視化できる粒度の調整がしにくい ○ 粒度荒ら過ぎ or 細か過ぎ ○ 後のスライドで後述 22 elementaryの成果物を使って、より柔軟にデータ品質の可 視化を行おう!

©2023 10X, Inc. データ品質指標を可視化する上でのelementaryの魅力 ● dbtは実行後に成果物(artifacts)をjsonで出力してくれる ○ manifest.json: dbtのリソース(model / test / macro / exposuresなど)やその依存関係などを保持 ○ run_results.json: dbt runの実行履歴。各モデルの成否や実行時間などを保持 ● データ品質の可視化もSQLで完結したいが、dbtの素の成果物は深くネストしたJSONになっている ○ DWH上では扱いやすいとはいえない ● elementaryはdbtの成果物を溶き解した上で、DWH上にアップロードしてくれる ○ 使いやすいように正規化 / 非正規化などをいい感じにやってくれる ○ アップロードはdbtのon-run-endでやってくれる ○ アップロード先のデータセットを指定するくらいでめっちゃ簡単に使い始めることができる! ● NOTE: これ以降のスライドで登場するクエリはBigQueryを対象としています ○ しかし、BigQuery特有の機能は特にないはずなので、他のプラットフォームでも同様の実装ができるはずです 23

©2023 10X, Inc. アジェンダ ● 背景: 10XとStailerについて ● 10Xのデータマネジメント上の課題の遷移 ● 現在取り組んでいるデータ品質の課題と取り組み方の全体像 ● Elementaryを使ったデータ品質の可視化 ○ 可用性の可視化 ○ 正確性の可視化 ● Elementaryを使ったデータ基盤の運用改善への活用事例 ○ 安全にテーブルを撤退する ○ 障害時に報告すべき関係者を素早くピックアップ ○ 生成元と参照先でデータ品質のギャップがないかを把握する 24

©2023 10X, Inc. データ品質の可視化: 可用性 ● そもそも成果物ができていないと話にならないので、初手で見たいことが多い指標 ● elementaryのレポートでも「全体」あるいは「単独のモデル」の可用性は可視化できる ○ しかし、レイヤリングで性質が違っていたり、モデル数が多い場合は自分たちで定義したデータセットやタグ 毎に可用性を可視化したくなる...! ○ 10Xでは商品在庫マスタ、DWH(新世代 / 旧世代 / adhoc)など色々な粒度でデータ品質を見たい対象がある ○ DWHだけでも2200テーブル(自動生成されたものを含む)存在している 25 dbt run全体の実行の成否や実行時間の推 移。Prometheus Metrics経由でDatadogで 可視化(詳細)。これだと荒過ぎる... elementaryがディフォルトで提供してくれ る単独のモデルの実行の成否や実行時 間の推移。これだと細か過ぎる

©2023 10X, Inc. 可用性を可視化するために利用する成果物: dbt_run_results & dbt_models ● dbt_run_results: dbtの実行結果を蓄積する履歴テーブル ○ いつどういう{model, test, seed, snapshot}が実行され、どうなったか(status)が蓄積される ○ これ単独だと、INFORMATION_SCHEMA.JOBSができることとほとんど変わらないように見える ■ しかし、後述するdbt_modelsやdbt_testsやdbt_sourcesなどと組み合わせると非常に強力 ■ JOINして組み合わせるためのキーがunique_id ● dbt_models: dbtのmodel(table / view / ephemeralなど)に関するメタデータを保持しているテーブル 26 カラム名 詳細 database_name プロジェクト名 schema_name データセット名 tags タグの配列が文字列で入っているので、使う際はバラす必要がある depends_on_nodes 依存(ref)しているモデルが配列として入っている description 問題あるモデルの一覧を出したときに「このモデル、どういう目的のものだっけ」をさっと見れる original_path モデルの定義元のファイルパス。モデルの一覧を出したときに「このモデルの詳細調べたいな」をさっと調査できる 情報量としては各種yamlファイルや manifest.jsonとほぼ同じ。 しかし、SQLのみで料理できるようになっ ている、ということが重要!

©2023 10X, Inc. 補足: elementaryの成果物に対するER図 27 登場人物が多く、何と紐付けられるか 把握が初見だと難しいので参考にして ください。 基本的にリソースの定義(models / tests / sources / etc)と実行結果(run_results / invocations)の2種類があると思ってお けばOK

©2023 10X, Inc. 可用性の可視化の例 28 コード含めた詳細はこちらを 参照してください 注意: 図はあくまで例であって、こんなに毎日 dbtが落ちているわけではないです 実行結果と モデルの詳細をJOIN

©2023 10X, Inc. 可用性の可視化を通じたボトルネックの特定 29 データレイク Staging Raw Vault Business Vault Data Mart Fact / Dim dbtで落ちてる or skipされたテーブ ルの大半はData Mart。 しかし、Data Martを直接改善すれ ば可用性が改善するかというと、そ うではなかった Data Martの可用性が下がっていた根本原因は たった数個のVaultのモデル。ここの品質が足りて いなかったので、品質向上していく必要があるこ とが可視化からも分かった データレイクに起因す る課題も当然ある データユーザーに対して「Data Martの可用性を向上させるためには、 基盤であるVaultの品質を上げていく必要がある」ということを可視化結 果を見せながらコミュニケーションしやすくなった!

©2023 10X, Inc. アジェンダ ● 背景: 10XとStailerについて ● 10Xのデータマネジメント上の課題の遷移 ● 現在取り組んでいるデータ品質の課題と取り組み方の全体像 ● Elementaryを使ったデータ品質の可視化 ○ 可用性の可視化 ○ 正確性の可視化 ● Elementaryを使ったデータ基盤の運用改善への活用事例 ○ 安全にテーブルを撤退する ○ 障害時に報告すべき関係者を素早くピックアップ ○ 生成元と参照先でデータ品質のギャップがないかを把握する 30

©2023 10X, Inc. データ品質の可視化: 正確性 ● 可用性と同様に、自分たちが見たい粒度で正確性も可視化したい ● 正確性のデータ品質指標の例: ○ 完全性(Completeness): not_null ○ 一意性 (Uniqueness): unique / dbt_utils.unique_combination_of_columns ○ 一貫性(Consistency): relationships ○ 妥当性 (Validity): ■ カラムの型のテスト / not_null_proportion / accepted_values / accepted_range / lengthなど ● どういう正確性の指標かを大雑把に知りたい ○ 可視化の際は細かいテスト名はどうでもいい 31 dbtでよく見るテスト 独自のテストを実装することも多い

©2023 10X, Inc. 正確性を可視化するために利用する成果物: dbt_tests ● dbtのモデルやデータソースにどのようなテストが実装されているかを保持しているテーブル ○ テストの実行結果が含まれているのはdbt_run_resultsであることに注意 32 カラム名 詳細 short_name not_nullやuniqueなどテストの短縮名。より正確な名前が欲しい場合には nameやaliasを参照するとよい test_column_name カラムに関するテストの場合、テスト対象のカラム名が入る model_tags モデルに付与されているタグ情報が配列 (の文字列)として入る model_owners テストが記載されているモデルのオーナー情報が入る parent_model_unique_id テストが実装されている modelやsourceへのjoinキー original_path テストが記載されているファイルパス quality_dimension completeness / uniqueness / validitiyなど、どういった項目のテストかを大雑把に分類したカラム。データ品質の 可視化で大雑把に見たいときに便利

©2023 10X, Inc. 正確性の可視化の例 33 コード含めた詳細はこちらを 参照してください 「データセットA / B / Cは特にテストが 多いが、データセットCはvalidity(妥当 性)に関するテストが圧倒的に少ない」

©2023 10X, Inc. 正確性の可視化を通じた各レイヤが担うべきテストの見直し 34 データレイク Staging Raw Vault Business Vault Data Mart Fact / Dim 正確性の観点でもデータユーザーから の問い合わせが一番多いのはData Mart。 とにかくData Martのテストを増やして 正確性を担保すればいい...? ビジネスロジックはBusiness Vaultに寄せていく。ロジックが絡む妥当性 (Validity)に関するテストもBusiness Vaultで行なおう。 一方で、Data MartはJOINに関するミスが起きやすいから、一意性 (Uniqueness)や完全性(Completeness)のテストを厚めにしよう! レイヤ毎に正確性の可視化を行なった結果、どのレイヤで何を担保す るためのテストを行なうべきか見直したりToBeの設定ができるように なった。可視化しているので、ギャップも分かる! Data Mart内にビジネスロジックが書か れているのがよくない! ビジネスロジックやそれに関するテスト も似たようなものが多数できてしまって SSoTにできてない...

©2023 10X, Inc. アジェンダ ● 背景: 10XとStailerについて ● 10Xのデータマネジメント上の課題の遷移 ● 現在取り組んでいるデータ品質の課題と取り組み方の全体像 ● Elementaryを使ったデータ品質の可視化 ○ 可用性の可視化 ○ 正確性の可視化 ● Elementaryを使ったデータ基盤の運用改善への活用事例 ○ 安全にテーブルを撤退する ○ 障害時に報告すべき関係者を素早くピックアップ ○ 生成元と参照先でデータ品質のギャップがないかを把握する 35

©2023 10X, Inc. elementaryを使ったデータ基盤の運用改善: 安全にテーブルを撤退する ● データエンジニアやアナリティクスエンジニアは日々様々な認知負荷と戦っている ○ 認知負荷を下げるためにも利用されていないテーブルは積極的に撤退したい...! ● テーブルの撤退なんてINFORMATION_SCHEMAを見ればいいだけ...? => No! ○ 派生したテーブルが多数参照されている場合もあり、その場合は撤退できない 36 撤退できるかはこっちで考えないといけな いが、人間が考慮するのは無理... 撤退したいテーブル

©2023 10X, Inc. データリネージはdbtの得意技! elementaryでさらに使いやすく! ● dbtのref関数を使ったモデル間の依存関係はmanifest.jsonに記録されている ● elementaryはmanifest.jsonの情報を加工して、dbt_modelsで使いやすくアップロードしてくれている ● 親子関係のリネージを再帰的に辿りたい場合はWITH RECURSIVEを使いましょう 37 recの中でrecを参照している。今のモデル の親の親の親の...親を再帰で列挙しつく す depends_on_nodesに依存元の配列が文 字列として入っているので、溶き解す

©2023 10X, Inc. 派生テーブルも考慮して、安全にテーブルを撤退する 38 dbt_modelsはモデルのdescriptionの情報も持っ ているので、どういうテーブルかもさっと確認しな がら安心して撤退できる! 認知負荷を一定以下に抑えながら開 発できるので、新規の案件対応や既 存テーブルの品質向上に取り組む時 間を捻出しやすくなる!

©2023 10X, Inc. 障害時に報告すべき関係者を素早くピックアップ 39 model A model B model C model D model E model F model G ダッシュボード X ダッシュボード Y ダッシュボード Z ここで障害が起きた model C以降の成果物の関係者、 特に利用者の多いダッシュボード オーナーに連絡したい! 依存しているダッシュボードが多いと 列挙も簡単ではない... ステークホルダー「自分が普段見て いるどのダッシュボードに影響があ るの?」

©2023 10X, Inc. 障害時に報告すべき関係者を素早くピックアップ 40 ● 障害のあったモデルの絞り 込み ● run_resultとmodelとの紐付 け dbt_run_results ● 障害のあったモデルに依存し ているモデルの列挙 ● モデルの情報からBigQuery のテーブルを逆引き dbt_models ● 障害の影響があったモデルと ダッシュボードの紐付け ● ダッシュボードのオーナー情 報を使って報告 dbt_exposures JOIN JOIN @syou6162 テーブルAで障害が 発生しています。ダッシュボードA / B / Cに影響が出ています! @yasuhisa.yoshida テーブルAで障害 が発生しています。ダッシュボードX / Y / Zに影響が出ています!

©2023 10X, Inc. 脱線: ● dbtのexposureは自動生成させるのがオススメ ● 理由: ダッシュボードはdbtのライフサイクルの外で作られることが多いから ○ 10Xでも以前exposureを手動で管理しようとしていたが、メンテナンスし切れずに古びてしまった... ● 主要なBIツールはAPIや監査ログを提供しているため、それを利用してexposureを自動生成できる ○ 10XではTableau(API経由)、Looker Studio(監査ログ経由)、Connected Sheets(監査ログ経由)でexposureを毎週 GitHub Actions経由で自動生成している ○ 参照先リンクでスクリプト含め、やり方全部書いてます! ■ 上記エントリを参考にしてもらって、Timeeさんでも同様の事例が先日出ていました ● 追跡可能性 (Traceability)にBIも考慮できているので、データ品質自体の向上にも繋がっている ● ダッシュボードの棚卸しにも役に立っている ○ 「BigQueryの監査ログによると、このdbtのmodelは全然使われてないな。不要そうだから、削除しよう」 ○ 「あれ、CIでエラーが出ている。削除しようとしたdbtのモデルを参照しているダッシュボードがいるのか」 ○ 「このダッシュボードはそもそも見られていないから、アナリストに連携してダッシュボードも削除して棚卸 ししよう」 41 実際に削除する前にCIで気付けるので便利! その他、dbtのカラムにPIIタグを振っておいて、PIIが出力される可能 性があるダッシュボード一覧を洗い出す、などにも使える!

©2023 10X, Inc. 生成元と参照先でデータ品質のギャップがないかを把握する 42 model A model B model C model D model E model F model G ダッシュボード X ダッシュボード Y ダッシュボード Z 正確性や可用性にも 気を配ってデータ品 質高く作ってます! このダッシュボードは先方も数字見てるか ら、ぴったり合ってないと困るよ! クエリ少しおかしいかも しれないけど、ひとまず 数字出してます... 大まかな傾向が分かればいいから、 ざっくりしたクエリでいいよ dbtのモデルとダッシュボードにデータ品質のタグを付与しておけば、elementary 経由で期待するデータ品質にギャップがある箇所を把握できる!

©2023 10X, Inc. まとめ ● 10Xでのデータマネジメントの課題の遷移を紹介 ○ 現在はデータ品質の課題に取り組んでいる ● データ品質の課題への向き合い方、elementaryを使った実装方法について紹介 ○ データ品質の可視化の結果から、実際の改善やToBeの策定の実例も紹介 ○ elementaryはデータ基盤の運用改善にも活用できる ● 今後進めていきたいこと ○ SLAやSLOの策定 ○ 指標を維持、改善する開発ライフサイクル ○ 利用者の品質の認知 43 elementaryの設定(数行)と可視化の SQL(約100行)でさっと始められます!