指標レイヤのシフトレフト: 指標定義はデータソースに記述する

[takegue]

• データマート層 / DWH層の使い分けは認知負荷が高い

  • 「実装者観点」として合理的な分け方だが、「データ利用者観点」で誤った分け方である

• 集計データは再利用性が低い: 使いまわすことをあきらめる方が無難

  • グレインテーブルを構成する 分析ユニット / セグメント / 指標 の3要素 最小粒度の定義は困難
    • 最小粒度にしても、ストレージコストにそこまでメリットが生まれない
  • 「計測」としての「目的」「用途」「目的達成のための方法・手段」は再利用できない

• 集計テーブルを定義するのではなく、指標定義データソースに書く

  • レイヤーを増やすのではなく、Viewを利用しカラム方向に拡張をする

データの集計操作は不可逆性の高い操作

https://github.com/takegue/estante/issues/15 で言及はしたが、集計操作は不可逆性の高い操作である。

• データソースは状態を持つと考えるのが自然であり、この情報は集計によって失われやすい
  • 計測システムにおける障害や問題の修正、backfilling

「計測」は再利用できない

集計データ、とは大なり小なり意思決定のために利用される。 何かを計測するために存在する。

ここで計測とは、何かを触れると JIS Z 8103:2019 より

特定の目的をもって，測定の方法及び手段を考究し，実施し，その結果を用 いて所期の目的を達成させること。

とある。 計測における「目的」「用途」「目的達成のための方法・手段」は再利用できない

• 「目的」: 目的に応じたイベント定義や分析ユニット
• 「用途」: 誰がどこでそのデータを使うか
• 「目的の達成方法・手段」: データの前処理、集計の後処理の仕方

輝きを失った黄金パターン: データウェアハウスレイヤとデータマート

データレイク/データウェアハウス/データマート の3レイヤでの分割 データウェアハウシングを進めるうえでの「データエンジニア観点」の考え方フレームワークとしてよかったが これは「データ利用のI/Fに適していない」分割で「データ利用者観点」では関心の分離が微妙で分割方法としては誤っている。

• データの状態が3層に依存するため、結局そのつながりをすべて認知しないといけない

  • テーブルの使い分けは認知負荷がかかり、経験ベースでの習得が必要になる
  • 計測における問題修正や仕様変更に伴って、依存をすべて適切に管理しないといけない

• 責任の境界をこの層の間で引いてしまうと運用がかえって難しくなる

  • これらの整合性を適切に管理し続けるのは運用負荷が高い
  • 依存は厳しく管理されなければならない

「データ利用者」にとってどこに認知負荷がかかりやすいか？

• 認知負荷がかかるのは
  • データに関する仕様は認知負荷
  • データ仕様に関する前処理 / 後処理 など
  • 複数のテーブルの使い分け
  • テーブル同士の結合操作

逆に認知負荷が低いのは

• SQLによる集計操作: sumやcount distinctは容易に習得できる
• ワイドテーブルの単一テーブルに大量のカラムがある場合

万能なファクトテーブル

• よく利用するID列群とその集計値のカラムをひとつのテーブルをファクトテーブルを用意する
• セグメントについてディメンジョンテーブルのテーブルで管理する
• セグメントに関する指標は、ファクトテーブルにディメンジョンテーブルを結合し、再集計することでリソース効率よく管理が可能になる

ただ上記操作では

• よく利用するID列群を選ぶ組み合わせに自由度がある

これがどういう運用になるかというと

• 不要なID列があとからあると、ファクトテーブルは作り直しになる
  • ファクトテーブルを作りなおすと、ファクトテーブルを利用したテーブルも作り直しになる

これを避けるためにどういうことするかというと

• すべてのID列を列挙したファクトテーブルを作る

ということになる。 こうなってくると事前計算するコストメリットがかなり薄く、これはデータソースそのものとほぼ一致する スタースキーマは大体のケースにおいて早すぎる最適化の方法にしかならない。

「指標」レイヤのシフトレフト

「指標」定義を再利用するためにはどうするとよいのか？

• https://benn.substack.com/p/metrics-layer
• https://www.getdbt.com/coalesce-2021/keynote-the-metrics-system/

指標の標準化は大事である一方、指標レイヤは実装するべきではない。 もし定義すべき指標があるなら、DWHレイヤにカラムとして、切り出していくべきである。

例

DWH layer

awesome_dataset.dwh

-- DWH layer
with data as (
    select * from unnest([
        struct(1 as id, "one" as label)
        ,  (2, "two")
        ,  (3, "three")
        ,  (4, "four")
        # ...
    ])
)

select * from data

awesome_datamart.core

-- Datamart Layer
with 
_pre as (
  select * from `awesome_dataset.dwh`
  where mod(id, 2) = 1
)
, _agg as (
  select 
    countif(label is not null) as nonnulls
    ,  countif(distinct id) as uniques
  from _pre
)

select * from _agg

Metric Layer

select "Odd Number Uniqueness" as name, uniques as value  from `awesome_datamart.core`
-- union all ...

こうするべきでは？

• データの前処理含めて、カラムとして追加で定義する
  • データソースと指標定義が比較できるため、デバッグも容易
  • フィルタしやすいカラムは提供してても、whereによるフィルタは直接行わない
• データマートレイヤは集計操作を行うだけ

awesome_dataset.dwh

-- DWH layer
with data as (
    select * from unnest([
        struct(1 as id, "one" as label)
        ,  (2, "two")
        ,  (3, "three")
        ,  (4, "four")
        # ...
    ])
)
, metric_columns as (
  select 
     *
     , if(mod(id, 2) = 1,  id, null) as metric__oddlabel__uniquenss
     , if(mod(id, 2) = 1,  label is not null, null) as metric__oddlabel_nonnull
   from data
)

select * from metric_columns 

awesome_datamart.core

select 
  count(distinct metric__oddlabel_uniquenss)
  , countif(metric__oddlabel_nonnull)
from `awesome_dataset.dwh`