FLINTERS Engineer's Blog

FLINTERSのエンジニアによる技術ブログ

Dataplexの自動データ品質導入を始めた話

はじめに

こんにちは。 株式会社FLINTERS に出向中のおのきです。

この記事は 10 周年記念として 133 日間ブログを書き続けるチャレンジの 64 日目の記事です。

2 回目の投稿となりますが、現在データエンジニアとして広告データのデータウェアハウス(DWH)構築を行なっており、 そこでのデータ品質の導入までについて書いてみようと思います。

経緯と要件と検討結果

現在構築中のDWHは、DMBOKを参考にデータマネジメントに取り組みながらDWH構築を進めています。 その中で、メタデータの管理やデータアーキテクチャをGitHub(ソースコード)であったり、Google Cloudのサービスを用いて仕組み化しています。

また、構築メンバーは 4 人で新規のテーブル(データ)構築・運用をこなしており、 既存のDWHでの品質における課題を感じつつ、 少ないリソースで提供DWHの運用から品質、そのチェックまでを考えた時、

＊数百を超える各媒体社広告データの取得については Flinters Data Hub という FLINTERS 社のサービスを利用し、E(xtract)L(oad)T(ransfer)の部分をチームで構築を進めています

  • なるべく保守・運用作業を行わないでも済む仕組み
  • 導入や学習コストを抑えられるもの
  • 監視や状態可視化までもっていけそうなもの
  • 現在利用しているComposerを用いたデータパイプラインToolからの実行が可能そうなもの

という視点で検討したところ、

Dataplexの自動データ品質にたどり着きました！ (検討時点でのデータ品質機能はベータでしたが、無事Dataplex内のサービスの一つとしてリリースされてます。)

他には Dataform やdbt-core を自前で用意も選択肢として出ましたが、マネージドサービスを利用することにこだわった点、リポジトリ管理面(既にGitHubで管理している状況で、複雑化しそう)だったりsqlxの学習コスト、データ品質箇所の外部サービスからの実効性を鑑みて、PoCを行なった結果 Dataform や自前でのdbt-core の導入は見送りとなりました。 (Dataform のパイプライン構築を含めたデータテストの動作などはとても興味深いので他のプロジェクトで利用を画策中...)

導入

経緯部分が長くなりましたが、自動データ品質導入は、 自動データ品質の概要 の内容を読み、 自動データ品質を使用する に沿って進めていくだけだったりします。

順番としては、上のドキュメント記載通り

  1. ルールの定義
  2. ルールの実行
  3. モニタリングとアラート

ルールの定義におけるルールタイプについては、データ品質をチェックする上で必要な各種次元の選択肢が揃っています。

今回の記事ではレポートデータに関してデータの一意性をチェックすることにし、 日付毎のアカウントのレポートデータを対象にします。

単一カラムの一意性をチェックすることではカバーできなさそうということで、 複数カラムのデータで一意性をチェックするために、

  • カスタム SQL ルールを作成する

で、かつ、集計ルールの利用とオンデマンドでの実行を目的として進めていきます。

ここでのポイントとしては、

集計ルールの場合、期待値はデータ全体で集計された 1 つの値に適用されます。(略) 合格するには、チェックがブール値 true に評価される必要があります。

を踏まえて、 設定のために作成したSQLっぽいものがこちら↓

  COUNT((
    SELECT
      CONCAT(report_date, account_id, campaign_id, adgroup_id)
    FROM
      `sample-pj.sample_dataset.adgroup_report`
    GROUP BY
      report_date,
      account_id,
      campaign_id,
      adgroup_id,
    HAVING
      COUNT(*) > 1
    LIMIT
      1 )) = 0

各日付に対しての各項目が一意ではない状態で False(= 0) になり、チェックとして異常という判断になるという仕上がりです。

上でSQLっぽいと書いたのは上記のクエリっぽいものだけではSQLとして成立せず、これを利用してDataplex側でさらにクエリを組み立て、データ品質チェックのクエリとしているためです。

実行結果としては、データ品質スキャンのリストの、ルール複数に対して、成功 or 失敗がリスト化され表示されます。

実行結果についてもCloud Loggingで抽出可能だったり、 モニタリングとアラート の情報を元に可視化なども進められるようになってます。

最後は端折った説明となってしまいましたが、導入としては以上です。

まとめ

今回DWHの品質定義とデータ品質チェックを行ったことで、提供DWH(サービス)のデータ状態の可視化、障害検知、利用者側への通知など色々幅広い取り組みや価値提供の可能性が見出せたことがとても大きな学びとなりました。

また、今回集計ルールを採用しましたが、ポイントを押さえたクエリがパッと思い浮かばないということもあり、SQLっぽいものを作成するのにチームでモブプログラミングでやってみました。SQLっぽいもののアイデアが出てしまえばシンプルな作業になるのですが、チームで品質について考える機会が得られたり導入までのプロセスが楽しめたと思ってます。

ちなみに、データ プロファイリングについて も試してみました、が、今回プロファイリングした結果のデータ分布をみた限りですが、取り立てて新たな示唆は得られなかったです。

＊データプロファイリング実行後、データ品質ルールにレコメンドがされるようになるので、プロファイリング機能に意味がないと言いたいわけではないです！

おそらく何かしら意図した条件下で集計 / 計算した結果をテーブル化しそれに対してのプロファイリングスキャンを行うというのが一般的な使い方かと思うので、把握しきれていない膨大な生データを構造化までは行ったデータに対してプロファイリングを行なっても統計的特性は見つけられずということなのかも...

今後の課題感としては、導入に際しての費用面などがはっきり見えておらず、データ量踏まえ試行錯誤しながらのチェック拡充だったり、対象データのサンプリングだったりのチェック条件の見直しを検討してたりします。 費用についてはこちら

以上、DataplexやBigQueryについては今後も続々と新たな機能が追加されていくかと思うので要チェックです。

引き続き 65 日目の記事もどうぞお楽しみに！