さようなら、謎の数値ズレ。dbtを活用してデータ品質管理をはじめよう
tl;dr
- すべてのデータを高品質に保とうとしない。事業フェーズやプロダクト仕様、マネタイズ方法に応じて、品質を守るべきデータを明確に定義し、「品質が守られた箱の中の世界」を明確にする。
- データ品質維持の前提は、Single Source of Truth。SSOTなDWHを構築することとセットな取り組みであることが大切。
- データ品質管理のHowとしては、dbtがおすすめ。not_nullやrelationshipなどdbtがもつtest機能を活用し、データ品質監視を実現しよう。
- 当然、dbtだけでは品質は守られない。Data Meshのような議論から運用体制を考えていく必要もある。
- 聞こえのよい新しいものに踊らされる前に、着実に必要なデータ品質を守っていこうね。
こんにちは、こんばんは。Ubie Discoveryのsotaronです。データエンジニアをやったり、小倉唯さんのファンクラブ会員などをやっています。
2020年11月にUbieに入社してからは主にData Scienceチームで社内医師向け業務アプリケーションの開発をやったり、データ基盤の開発や運用をやったりしていました。が、今年に入ってからは、事業サイドのBI担当としてレポーティング周りの仕組みを整えたり、その土台となるデータ基盤の部分に手を入れています。すっかりデータアナリストに戻った気分です。
さて、今回はそんなデータアナリスト時々データエンジニアな取り組みの中から、改めて痛感した「データの品質」についてお話をしようと思います。
本記事ではdbtとBigQueryを採用した構成で話を進めますが、それらについての詳細な説明は特にしません。適宜公式ドキュメントなどを読んでください。
データの品質って？
ところで、「データの品質」ってなんでしょうか？私はここ1~2年ずっとこのテーマに取り組んできました。
これまでの発表資料は以下です。本記事はこれらを読んでいなくても読み進められます。もし興味があれば補足として読んでください。
データの品質については、ざっくりと以下のように整理できそうです。
- ソフトウェアに品質があるように、データにも品質がある
- 一つは、データの完全性、一貫性など「データそのもの」にまつわる品質
- もう一つは、可用性、冗長性など「データ関連システム」にまつわる品質
データの品質に目を向けていない場合、様々な問題が起こります。わかりやすい例だと、たとえば意思決定に用いているKPIの値や施策の評価値がズレてしまうケースです。極端な話、正しくデータを収集し集計できていればA案を選択していたところが、データ欠損などにより不当にB案のほうが効果が大きいように見え、B案を採択してしまう。といったケースが考えられます。
他には、データ品質に関連して起きるとまずいことといえば、対外的な報告義務、責任がある会計関連のデータやレポート値に一貫性、整合性がない場合でしょうか。この手のデータが整合、一貫していない場合はかなりややこしいことになります。具体的には、たとえば同じメトリクスを異なる集計軸でみているレポートで、集計軸によってメトリクスの総数にズレが発生してしまうケースなどです。数字がズレたレポートは、顧客やステークホルダーに信用できないものだと思われてしまうリスクがありますし、そもそも正しいのかすらわかりません。
データの品質に目を向けることが大事だということは、データ分析やそのアウトプットに携わる人であれば、誰でもわかっていることかとは思います。しかし、具体的になにをどうすればいいのかはわからない…という方も多いのではないでしょうか。本記事では、この「なにを」「どうする」について、掘り下げていきます。
すべてを高品質に、は難しい。「品質が守られた箱」をつくろう
上述のようにデータの品質を高く保つことは非常に重要です。しかし、多くの場合、データ品質を高く保つための取り組みは、通常のプロダクト開発やサービス提供に+αの工数を要求します。
特に事業的な不確実性の大きいスタートアップでは、プロダクト開発のサイクルの中ではデータの品質までケアしきれないといった現場が多いと思います。なので、初めからあれもこれも高い品質を目指すのではなく、優先順位の高いデータから品質を守っていくべきです。すべてを高品質に、は難しいのです。
では、どのように優先順位を決めればよいでしょうか？データ品質にまつわる「なにを」の話です。
「どのデータから守っていくか」は事業フェーズに強く依存しています。たとえば、PMF前の新規プロダクトでは正確なレポーティングよりも大筋の方向性を素早く検証できることのほうが大事です。一方で、PMF後のスケールフェーズであれば、そのプロダクト上でのユーザーの活動が正確に記録されているはずだという暗黙の期待のもとに施策が展開されることが多くなります。
これらはあくまで一例です。「事業フェーズに強く依存する」と書きましたが、事業フェーズから機械的に品質を守るべき対象データを定義できるわけではありません。事業によって、「品質への暗黙の期待」がうまれる瞬間、フェーズがあるということです。それを見逃さずに、その暗黙の期待を明文化し、応えていく必要があります。私はよく、このプロセスを「品質が守られた箱の中と外という世界観を作る」と表現しています。実現のためには、月並ですが、事業ドメインに明るいメンバーの「品質への暗黙の期待」を引き出しましょう。なにか問題が発生したときに初めてその期待が明らかになることもありますが、可能な限り、事前に引き出すべきです。
この辺りのUbieでの実践的な取り組みとして、弊社望月によるこちらの記事もぜひご参考ください。
当然ですが、問題が発生したときに明らかになる品質期待もちゃんとケアします。こちらの話は、SREの文脈におけるポストモーテムのようなアプローチを用いて、うまく期待を引き出し、明文化しようという話なので、今回は詳しく話しませんがとても大切なことです。
また、参考程度ですが、私はだいたい事業ドメインやフェーズに限らず、まずざっくりと以下の基準でデータを整理し、品質維持/向上のための活動をしていくことが多いです。
- 対外的に見られうるデータなのか
- 集計値が一件でもずれた場合、意味が変わるデータなのか
自社プロダクト上でのユーザー行動データを対外的に報告していたりする場合は、事業としてPMFしていなくてもデータ品質を高く保つことが重要です。
プロダクトの対内的なKPIやメトリクスは、（規模感次第ではありますが）数件レベルのデータ欠損やズレは大きな問題にならないことが、体感としては多い気がします。しかし、社内的にみているデータでも当然品質のケアが必要なものはあります。
たとえば、なんらかの意思決定に用いるためのデータ分析や予測をするとき、そこで扱われているデータの品質がどれほど重要になるかは、感度の問題です。予測に用いられるデータの数件のズレが、どれほど予測結果と最終的な意思決定に影響を与えるか、ということです。この影響度合いが大きい、かつ事業上きわめて重要な意思決定に用いられる予測、およびその元となるデータは、上記基準には沿わなくとも品質を高く保つべきです。
結局のところ、全世界共通の「これを守ればOK」はありません。そのデータがどういったことに利用されているのか。その利用先はどれくらい重要なものなのか。そういったことに気を払いながら、顧客やステークホルダーの「品質への暗黙の期待」に気づき、明文化していく、「品質が守られた箱の中」を定義するしかありません。ここでお伝えしたいのは、杓子定規な基準そのものではなく、品質を優先的に守るべきデータとそうでないデータを明確に分けて、品質向上の取り組みをしていくべきだ、ということです。
また、品質維持の優先順位をたてることと同じくらい重要なのが、関係者間で優先順位、および現在どのデータは品質が担保されていて、どのデータはされていないのかの認識が共通となっていることです。そうでないと、データを利用したい人たちは身動きがとれなくなるか、正しいかもわからないデータを怯えながら利用し続ける日々を送ることになるからです。そして、後述しますが、データ品質を守るにはそのデータが関わる社内のすべてのワークフローに統一された情報源が用いられているべきです。どのデータセットは信頼して使えるものなのかを関係者に周知し、高い品質を求められるアウトプットには、それらのデータセットだけを使ってもらうようにするべきです。
dbtによるDWH構築とデータ品質管理
ここからは、実際にデータ品質を守るためにどういったことができるのか、するべきなのかについてお話していきます。本記事では特に出口側として典型的なレポーティングにおけるデータ品質を題材にお話します。ですが、基本的な考え方は他のアウトプットでも共通しているはずです。
最近では、データ活用の文脈でデータウェアハウス（以降、DWH）やデータマートを含んだ「データ基盤」の構築に多くの企業が取り組んでいると思いますが、データ品質に関してもこの「データ基盤」をどのように作るかがキモになってきます。この記事を読んでくださっている皆さんの中にもきっとこの「データ基盤」に携わっている方は多いと思います。そこで、質問です。なぜ、わざわざDWHやデータマートを作る必要があるのでしょうか？
もちろん、答えは一つではないと思います。データ加工/集計作業の標準化、効率化やナレッジの共有などなど、DWHやデータマートを作ることには様々な効果があります。なかでも私は、DWHやデータマートの構築が分析/レポーティングデータにおけるSingle Source of Truthを実現する手段だという点を重視しています。
DWHやデータマートの作り方にもいろいろとありますが、基本的にある同じメトリクスを算出する上では、参照されるデータソースが必ず同じものになるように作るべきだと私は思っています。ある情報を扱うデータソースが複数存在しないこと≒複数の定義が存在しないことは、拡張性や運用の観点からとても重要だからです。プロダクトで仕様変更があったときに関連するレポート用のSQLを修正して回る…なんてことはしたくありませんよね。（今までたくさんしてきましたが泣）
後述しますが、Ubieのデータ基盤においてもスタースキーマを採用し、上記のようにDWH層のテーブルを整理しています。ファクトテーブル（とディメンション）をSingle Source of Truthとみなし、以降の中間便利テーブルを作ったり、データマートを作っています。そうすることで、プロダクト仕様変更やログの異常系考慮、CV定義の変更などをDWH層のファクトテーブルに集中でき、以降の依存テーブルはそのファクトテーブル（とディメンション）を参照するだけでOKになる、といった具合です。
ここまでの話で自明だとは思いますが、データ基盤におけるSingle Source of Truthの実現は、データ品質管理においても極めて重要な意味を持ちます。ドメインやイベントごとに、ただ一つのデータソースの品質のみを監視し、維持すればよいからです。各社員のローカルPCに保存されたSQLファイルが正しいかどうかなんて、気にしていられるほど人生は長くないのです。
そして、Ubieでは、このSingle Source of TruthたるDWHやデータマートを構築するシステムにdbtを採用しています。dbtを採用することで、データの品質をモニタしつつ、DWHやデータマートの実装ができます。
dbtの具体的な活用方法の前に前提となる設計の話をします。DWHの設計手法のひとつに「スタースキーマ」や「ディメンショナルモデリング」と呼ばれるものがあります。この手法についての詳細な説明は本記事での本題ではないので割愛しますが、全く知らないという方はこちらの方の記事などを読んでみてください。（私も最近拝読しましたが、とてもわかりやすかったです。）
この手法は、データ品質維持と相性が良いので、この設計手法を用いてデータ品質管理をすることをおすすめします。相性が良いというのは、レポーティングにおけるデータ品質として求められるものを、スタースキーマやディメンショナルモデリングの考え方を借りて、以下のように整理できるからです。
- 集計対象たるファクトテーブルのキーが有効であること(nullでない、不当に重複していない、など)
- 集計軸たるディメンションが既知の値の集合であること
- データ欠損がないこと
今回はレポーティングがテーマなので、データはなんらかの集計軸で集計したメトリクスに変換される想定で考えてみます。
1は集計値のズレに関する品質です。ここでいうファクトテーブルのキーとは、COUNT(DISTINCT key) となるようなデータのことです。
本来キーが入るべきところにnullが入ってしまったり、重複しないことを想定していたサロゲートキー的なカラムの値が重複していると集計値がプラスにもマイナスにもズレます。これを防ぐ必要があります。
2は集計軸の正しさに関する品質です。
スタースキーマやディメンショナルモデリングにおいては、ディメンションごとにファクトを集計するという結合/集計作業がよくされますが、その際に集計軸となるディメンションの値に対するテストです。ディメンショナルモデリングなんてよくわからんという方は、厳密ではありませんが「いつ、どこで、誰が、何を」のデータくらいに思ってもらえると分かりやすいとは思います。
レポーティングにおける集計軸は基本的に既知の値のみで構成されることが望ましいケースがほとんどかと思います。Enumのようなものをイメージするとわかりやすいかもしれません。
広告ROI評価のために集計するとしたらキャンペーンIDごとにその後のファネルやCVをみるでしょうし、サービス内のどのページがよく見られているかを知りたければ、各ページの固有名やURLごとにPV数の集計などをするでしょう。逆に、この「〇〇ごとに」の〇〇（＝ディメンション）に未知の値が入ってくる場合、ほとんどレポートはおかしくなります。
新規に追加されたディメンションならば、それを含めたレポートを作ればいいという話ですが、問題は、これがたとえばログの実装ミスなどによって意図せぬキャンペーンIDが混入してしまうケースなどです。本来キャンペーンAの集計値として計上されるべきものが、計上されなくなり、結果的にキャンペーンAの実績値が過小にレポートされてしまいます。これが対外的に報告義務があるレポートの場合を考えると、頭が痛くなってきますよね。
3は1,2の大前提です。とはいえ、私はこの3のデータ欠損対策については本格的に着手すべき順番は一番最後でもいいと思っています。もちろん程度にはよるので、あまりに不安定なパイプラインからログデータなどを供給していることが自明なのだとしたらそちらから手を入れるべきです。
しかし、昨今のある程度コモディティ化されたデータパイプライン実装を採用しているのならば、ここは一定程度その信頼性に乗っかってもいいという考えです。ただ、本格的な欠損対策や監視はしないまでも、最低限hourlyで最新のログをチェックして、パイプラインが止まってしまっていないかなどの監視は初期段階で入れておくべきです。
これらは、レポーティング以外でも、入力データに制約をかけるという意味では広く応用できるはずです。先述した機械学習モデルにおける感度分析などにも同様のアプローチが一定程度有用だと思います。
やっとdbtの話です。dbtは、入力となるソースデータや出力としてのDWHテーブルやマートテーブルが1と2の条件を満たしているかチェックするtest機能を備えています。dbt testの基本的な使い方はこちらです。
では、上記の1,2についてそれぞれ説明していきます。
集計対象たるファクトテーブルのキーが有効であることのチェック
集計対象となるキー（ここではログのIDやユーザーIDをイメージしてもらえるとわかりやすいと思います）が有効であることのチェックにはdbt testsのうちnot_nullやuniqueを使います。以下のように記述します。
こうすることで、たとえばuser_idというカラムにnullが入ってしまっているテーブルにdbt testを実行すると、testがfailします。Ubieではこれをdbt管理repoのCIとして実行し、本番のパイプラインに異常データが流れていないかをチェックしています。異常を発見した場合は、対象プロダクトの開発チームと連携をとります。
また、プロダクトやそのデータ特有の制約がある場合は、dbtにはカスタムでテストを定義する機能もあるので、そちらを利用してもいいと思います。SQLで表現できるものであれば、独自のテストを追加可能です。
集計軸たるディメンションが定数の集合であることのチェック
集計軸のチェックには、accepted_valuesやrelationshipsを使います。accepted_valuesはカラムが持ちうる既知の値のリストとして表現します。既知の値のみで構成され、かつカーディナリティが低いカラムであれば、こちらを使うのがおすすめです。UbieではAI問診ユビーを導入いただいている医療機関様のタイプをHP/GPで区別していますが、こういったデータはHP/GPどちらかの値のみが入ることを想定しているので、以下のように書けます。
一方で、キャンペーンIDやページ名など変数ではないものの、値のバリエーションが多いカラムはrelationshipsを使うのがおすすめです。こちらは他テーブルの特定カラムを指定することで、テスト対象のデータがその値の集合に含まれているかをチェックできます。外部キー制約のようなものですね。
これらのテストはdbtにおけるschemaファイルに記述されます。schemaファイルはテーブルのメタデータ情報を記述するyamlファイルです。
dbtではschemaファイルの他に、実際のデータ加工処理を書くSQLファイルやドキュメント用のMarkdownファイルを記述します。dbtはこれらを利用し、実際のDWHやデータマートのテーブル作成からデータ品質のテスト、リネージュや各テーブルのdescriptionを記載したドキュメント作成までをおこなってくれます。これら三つを一つのエコシステムの中で生成、管理してくれるのがdbtの一番良いところだと思います。
ぜひ、dbtを利用してデータ品質を担保できるデータ基盤構築づくりをしてみてください。
ツールの先に
dbtを活用することで、重要データの品質をチェックする仕組みが作れることはわかりました。しかし、これだけで品質は維持され続けるでしょうか？
答えはもちろん否。プロダクトの仕様変更などのアップデートにどう追従していくか、dbt testが落ちてデータ異常を発見したときに、誰がどんなアクションをとるのか、そういうことが決まってないと意味はありません。つまり、運用体制や設計が大事なのです。上述したようにDWH層のファクトテーブルをSingle Source of Truthとして作るのも、dbtによる品質監視に意味をもたせる設計の一つです。
さらには、これらの成果物を基盤チームのような人たちが管理するのではなく、プロダクトサイドに自然とケアしてもらえる仕組みを作れるとなおよいでしょう。いわゆるData Meshというワードで最近議論が盛り上がっているテーマです。（最近弊社の渥美がちょうどData Meshについての記事を書いていたので、ぜひこちらもご一読を！）
dbtのアラートをそのドメインを管理してるチームに流してもいいし、リリース前/後のチェックリストに入れてもらったり、リリース後のフローの一環として関連するdbt管理下のクエリを修正してもらったりするのもよいでしょう。結局のところ、データにまつわる仕様変更や異常ケースに一番詳しいのは、その発生源を実装した本人たちのはずです。
Ubieもまさに今、dbtというツールの先にあるこの運用の問題にチャレンジしているところです。まだまだこれからな領域なので、今は大した話を書けませんが、成果が出ていそうな3ヶ月後くらいには、この辺りについても詳細に掘り下げたブログを書くと思います（たぶん）。
Next StepとしてのData Discovery
ここ最近のデータ基盤の注目トピックとして、メタデータ基盤やData Discoveryがあります。「データの民主化」とはもう随分耳慣れた言葉ですが、その大本命という感じもします。しかし、メタデータ整備やそれにより実現できるData Discoveryは、このデータ品質監視体制を作り、それを運用することで品質のケアができるようになった先にあるものだと私は考えています。Ubieでも年内にData Discoveryの仕組みを構築することを考えていますが、ロードマップ的には「品質が守られた箱の中」の定義とデータ品質監視、担保の先に見据えています。耳聞こえは良いし、おもしろそうな分野とは思いますが、そもそも品質のわからないデータが多くの人に広まるのは逆に混乱をうむリスクでもあるのです。
情報が透明にいきわたることは極めて重要なことですが、間違った情報をそうとわからずに広めてしまうことはかえって「データの民主化」を遅らせてしまう原因にもなると思います。導入によるリターンが最大化できるタイミングを見計らってやるべきものでしょう。
まとめ
長々と書いてきましたが、お話したいことはここまでです。まとめると、以下が重要です。
- すべてのデータを高品質に保とうとしない。事業フェーズやプロダクト仕様、マネタイズ方法に応じて、品質を守るべきデータを明確に定義し、「品質が守られた箱の中の世界」を明確にする。
- データ品質維持の前提は、Single Source of Truth。SSOTなDWHを構築することとセットな取り組みであることが大切。
- データ品質管理のHowとしては、dbtがおすすめ。not_nullやrelationshipなどdbtがもつtest機能を活用し、データ品質監視を実現しよう。
- 当然、dbtだけで品質は守られない。Data Meshのような議論から運用体制を考えていく必要もある。
- 聞こえのよい新しいものに踊らされる前に、着実に必要なデータ品質を守っていこうね。
最後に採用の宣伝ですが、Ubieでは、データ品質担保の取り組みやその先にあるプロダクト成長のための分析業務を担ってくれるデータアナリストを熱烈募集しています。
ぜひ、本記事の内容やUbieにおけるデータ基盤の取り組みに興味を持っていただけた方はご応募ください。「ちょっと話を聞いてみたい」、「このブログの内容について議論したい！」という方は私のTwitter(@__sotaron__ ) DMまでご一報ください。お待ちしております。
それでは:)
