データ利用に重心を置いたデータパイプラインを考える

サマリ

データモデリングを前提とした開発QCDを重視したパイプラインではなく、
データを利用する側の目線に立ち、もっと砕けたスタイルのデータパイプラインの姿を模索したアイデア記事です。
データマート作成までの経緯を問わず、作成されたマート自体の品質を後から評価し、適切に利用できる状態を作るための手段を書き並べています。

2022-08時点で描きかけなので、調査が進んだり、何か思いついたら追記します。
※データモデリングやdata valutについて記載していますが、調査過程の記事なので不正確な部分が多いです。気づきがあればコメントをください。

モチベーション

現状、データパイプラインはながくて作られるテーブルもたくさんある。
長さゆえにたどるのが辛い。理解するのが辛い。障害原因の特定が辛い。影響範囲の特定が辛い。

課題は何かというと、加工処理が多いこと。抽出、変換、結合、集計の各ステップが繰り返されるから多い。
もう一つの課題は、依存関係があること。別のテーブルやマートの処理結果が変わると影響を受けること。

先行研究では、パイプラインの保守性・拡張性を上げるために、さまざまな工夫がなされてきた。
ただし、重心が開発目線にあり、データ利用に重点をおくとどうしてもスピード感が足りないとも感じる。

理想は、目の前にあるそれっぽいテーブルを使ってさっさとデータを抜いてこれる。当然品質はそこそこだが、そこそこであることがわかっている、後からアラートがあがる、そんな仕組みがあると嬉しい。
(例えば3人のチームで運用してる分析基盤ではtoo muchだと思う。)

先行研究

SSoTとディメンショナルモデリングがあるが、どちらも事業のへんかに弱い。長期で支えるテーブルとはならないのがデメリット

• SSoT
  信頼できるテーブルをしっかりとメンテする方法。SSoTからは、加工処理が少なくなる。SSoTの保守は大変だが、SSoTの先は保守が楽になる。
  SSoTを作るのが難しいのがデメリット

• ディメンショナルモデリング
  事業が注目するファクトに基づいて、多数の属性を紐付けておく方法。結合を減らせる。
  ファクトを見出しにくいのがデメリット

• data vault
  3NFのテーブルをベースに、リンクやブリッジを作って事業の変化に強くしたもの。
  導入コストが高そう

• data mesh
  データレイクのような一元管理されたDBをおかず、ドメイン側にデータのオーナーシップを持たせる方法
  代わりに、メタデータを拡充したりして、ガバナンスを行うことでデータを探しやすくしたりする
  ただし、そのガバナンスの難易度が高いのがデメリット。誰もメタデータなんて登録しない。責任はんいと言われても責任を果たす人が少ない。

アプローチ

先行研究は偉大で、真面目にデータモデリングを導入すれば、大抵の事業課題は解決する。
しかし、モデリングは正直億劫。

一方で「昨日みんなには秘密で、こっそりリリースしたサービスの初速のインプレッションモニタリングしたい。一旦今日欲しい。ぶっちゃけ制度はどうでもよくて、オーダーだけわかればいい」みたいなお題に対して、いちいちモデリング、SSoTを、というのスピード間に見合ってない。

そこで、適当なテーブルから自由にマートをつくれるが、それでも品質を守れる方法、というのを探したい。
「一旦めぼしいテーブルからマート作りました。品質？俺がしっかり見たから大丈夫！」っていうのを許可した上で。そのテーブルの品質を守りたい。

要は data mesh みたいなことがしたい。

data mesh は組織間のスケールなので、組織内でのオーナーシップやガバナンスが必要になってくる。
一方で、単一の組織内であれば、自動化やシステムによる仕組みで、ある程度はガバナンスを効かせることができるんじゃないか。
特定の事業をBigQueryだけ、っていう前提で data mesh 的なことをしたらいいんじゃないか。

なので今回は、

• ある程度制約のある条件で
• モデリング不要、パイプライン管理不要だが、ガバナンスが聞いたパイプラインを

考える

前提条件を考える

個人開発のケースとかにするとチームや企業で使えないので、昨今のトレンドに合わせて妥当な前提条件を考える

データレイクは固定

データレイク、すなわちアプリケーションDBにあるデータは、ちゃんと BigQuery まで持ってくることにする。
これ自体は結構大変だが、Data Transfer Service とかで最近は結構簡単にできるようになった。
BigQueryに持ってきたデータなら、勝手に使っていいよ。それ以外はダメだよ、というところで線引きする。

最終的なデータマートの置き場所も固定。

変換した結果のアウトプットは、Tableauだったり、Excelだったりするが、これも今回のスコープからは落とす。
TableauやExcelで品質を損なうような複雑な加工はなるべくしないでね！という前提になる。
簡単のために、最終的に使うデータマートはBigQueryにあるものとする。

(自分はTableauでLOD使い倒した集計をしたりもするので、この前提には懐疑的…)

パイプラインに使うツールは自由。アウトプットのマートの形式も自由。

Scheduledクエリでもいいし、Argoでpythonのコードを実行してもいいし、dbt run してもいい。
最終的にBQテーブルやViewとしてBigQueryにテーブルが完成されたらなんでもOKとする。
特定のSSoTテーブルとかも気にしなくてOK
中間テーブルも自由に作ってOK

マートに対する自動テストが可能

dbt や　great expectation、あるいは BQMLを使った異常値検出を使って、データに対するテストができるようになってきた。
今回の対象となるアウトプットのマートに適用できる環境があるとする。

ガバナンスを効かせるには

SQLやソースコード、中間テーブルは全く当てにならないので、「インプットとなるデータレイクのデータ」と「アウトプットとなるデータマートのデータ」だけが扱えるリソースになる。
しかも、インプットとアウトプットは自動では紐づかない。

そのため、コードに対する単体テストや、中間テーブルのスキーマテストみたいなのはアプローチとして使えない。

また、手動でやるものもあるが、基本的には人に期待せず、自動で担保できる仕組みを考える。

別のデータマートとの自動リレーションによる信頼性担保

分析で重要なのは、「チームで同じ指標を追いかけること」だが、それをそのまま、「特定のデータマートのカラムの値と関係があること」としてテストを行う。
新たにテーブルを作ったら、マスターとなる別テーブルのカラムを探して、自信のテーブルをスレーブとして登録する。
もし比較対象のカラムがないとしたら、そのカラムは「このサービスで唯一信頼できる数字」としてマスターとして登録する。
つまり、作られたテーブルのカラム全てがマスタかスレーブのどちらかになる。

例えば日毎にPV数を集計しているテーブルAに対して、8/1のPV数カラムが100件だとする。
※以下、「特定のカラムと同じ」と記載するが、1:1でも1:Nでも集計結果が合致でも、なんらかの条件であれば良いとする。

テーブルAのPV数カラムはマスターカラムで、テーブルB,C,D,E,F,Gの6つのPV数カラムと合致する関係にあり、全て真であるとすると、かなりの確率でテーブルAのPV数カラムは信頼に足ることがわかる。

これと同時に。テーブルB,C,D,E,F,Gも、マスタとなるテーブル AのPV数カラムと同じなので、同時に信頼できる値と判断できる。

この時、テーブルA~Gが、どんな経緯で作成されたか、とか、どうゆうツール、テーブルから作成されたのか、とかは全く気にする必要はない。

加えて、テーブルAのPV数カラムが、テーブルHのPV数カラムと合致していない、とする。
すると、テーブルAの信頼度は少し下がるが、テーブルHは、おそらく集計ミスを起こしてるんじゃないか、と疑うことができる。

もちろん全てのカラムに手動でリレーションを入れていくのは辛い。
(そんなことするくらいならデータモデリングしたほうが早い人もいる気がする)

なので、「こんなカラム名、こんなデータが並んでいるカラムは、このテーブルのこのカラムがマスターになるべき」みたいなものをものをルールベースで自動判定する仕組みが必要になる。(機械学習とかも支える気がしたが、専門外なので誰か教えてください)

データマートに対するスキーマテストの実施

not_null とか unique などのスキーマテストを、テーブル更新時にチェックする

データマートに対する時系列予測の実施

過去のデータ更新状況から逸脱した数値の発生や、大幅な件数増が発生していないかを、テーブル更新時にチェックする

利用数の少ないマートの不活性化

年に一度しか見られていないようなもの、更新されてないものは、タグをつける、権限を絞るなどして、不活性化を進める。
仮に年に一度だけ見られる重要なマートがあるとするなら、条件を満たせるよう、年に一度だけ作成しなおすこととする。
ある程度の参照階数を求め、テーブルが乱立した場合も、重要なテーブルが目立つようにする。

ゴールデンデータの自動定義

「8/1のPV数は絶対に100」「カスタマーID = AAAAA となるデータは絶対に存在する」のようなルールをカラムごとに設けておく。PV数やカスタマーIDという、同じ名前のカラムにはこのテストを自動で適用する。

テストを通したければ、ゴールデンデータが含まれるように変換処理を書き換えるか、カラムの名称を変えるように徹底する。

もちろん全てのカラムに手動でゴールデンデータを見出してルール化するのは辛い。
これも、ルールベースで既存のテーブルからゴールデンデータを見出し、勝手に適用していく仕組みが必要なる。
(同じカラム名を持つ2つのテーブルを比較して、重複する要素があればそれをゴールデンデータとする、とか)

考察

別のデータマートとの自動リレーションによる信頼性担保 と ゴールデンデータの自動定義 をどうやって実現するかがポイントになりそう。
手動で頑張る世界線だと、モデリングして信頼できるSSoTからデータを作った方が、テスト書く手間が減るので、あまりメリットが出てこないかもしれない。
自動化するための前提条件を明確にしていけば、データの成り立ちや、データのオーナーシップのような人に依存する要素を最小限にしたパイプラインを考えられるかもしれない。