データレイヤーと内製化

はじめに

過去にデータの可視化やデータエンジニアリングについて以下のような記事を書いてきました。

1.データの可視化は健康診断
2.「はじめての分析」で見落としがちなポイント
3.「はじめての分析」で見落としがちなポイント②
4. データの品質について考える

今回はデータエンジニアリングの側面からデータのレイヤーについての話をします。
あわせてデータ利活用の内製化が進まない理由についても考察していますので、目を通していただけましたら幸いです。

データレイヤーの定義

データは発生した時点の姿から加工を経てBIやMLなどで使われる姿まで、何回か姿を変えていきます。
姿を変える理由は、データがデータとして扱いやすい形でなかったり、何かと掛け合わせて初めて意味が生まれるデータだったりするために、段階的に加工していくからです。
この姿をレイヤーとして定義して、レイヤーごとに物事を考えていきましょうというのがデータレイヤーの考え方になります。

まずは一般的なレイヤーの定義を以下に示します。

一般的と言いながら、各レイヤーの呼び方は誰が言っているかによってバラバラです。
また、レイヤリングの論点も概念の言語化であったりデータ保管の整理のためだったりと様々です。
ただ、結果として整理されたレイヤーはどの場合でも似たり寄ったりですのでまとめて記載をします。

レイヤー	別名	内容
Raw data layer	- Ingestion data layer - Landing data layer	データの源泉から受領したそのままのもの
Curated data layer	- Conformed data layer - Cleansed data layer - Staging data layer	PreparationやCleaningされて使える形になっているもの
Application data layer	- User data layer - Production data ayer - Analytics data layer	BIやML、業務システムなど使う側に最適化されたもの

これが一般的な定義になります。
こういったドキュメントも参考になります。

実務上はRaw Data Layerでは定義が少し粗いように感じますので、Rawのみさらに以下に細分化するのが良いかなと思います。

詳細	内容
Aggregated	基幹システムやSaaSなどから収集されたデータ
Atomic	IoTから収集されたデータやシステムログなど

アーキテクチャとの分離

データレイヤーの話をすると、「Datalake / DWH / Datamartの話ね」という反応を示される方もいますが、
これはアーキテクチャの話ではないので、そこは分離して考えた方が良いかと思います。

たとえば、AggregatedデータをDatalakeのみで保持しているという企業はあまり見たことがありません。
一方でAtomicデータはDatalakeのみに保持するパターン（クエリサービスで直接クエリを投げる）も多いです。

アーキテクチャとデータレイヤーの関係についてマトリクスで表現すると、以下のようなパターンが多いかなと思います。

アーキテクチャ	利用サービスなど	Raw data layer		Curated data layer	Applicatoin data layer
		Atomic	Aggregated
Datalake	S3,ADLS2など	〇	〇 *1	-	-
Datawarehouse	Redshift,Synapse Analytics,Snowflakeなど	-	〇 *1	〇 *2	-
Datamart	〃(クラウドDWH)またはRDB	-	-	〇 *2	〇

*1 両方で重複して保持する *2 場合によってどちらで保持するかが異なる

Curated data layerは多くの場合Datawarehouseに配置されますが、整備が進んでくると部署単位などでDatamartに配置されることもあります。

内製化が進まない理由とデータレイヤー

世の中の内製化の流れの中でも、とりわけBIという領域は内製化を進めようと考えているお客様が多いです。
IT部門による内製だけではなく、事業部門の内製(データの民主化)に踏み込もうとしている話も耳に入ってきます。

こういったときにまず何をするかというと、BIツールのトレーニングを受講します。
BIツールはよくできていますので、基本的な操作自体は難しくはありません。
ところが、実際に現場でデータを扱おうとすると壁にぶつかってしまうんですね。

なぜなら、実業務で扱うデータはトレーニングデータみたいに綺麗なデータではないからです。

実業務で扱うデータ

たとえばAggregatedデータを想像してみてください。
システムで保持しているデータというのは、ユーザーが見やすいようにワイド（横持ち）でデータを持っていたりします。
ところが、BIツールから扱いやすいデータはロング(縦持ち)なので変換(unpivot)が必要になったりします。
これは最も単純な例ですが、このようなデータの持ち方の変換は常に発生します。

重複の排除、データの一意での特定なども頻繁に発生します。
SQLの分析関数(row_number()など)と同様に、ある項目で並び替えたのち最新のものだけを採用する、みたいな判定をいれるパターンですね。
逆にSQLでいうCROSS JOINをわざと発生させてレコードを増幅させないと表現できないような状況もあります。

「事業部門による内製」でこれらをクリアするにはとてもハードルが高いですよね。
従って、内製化を進めるためにはこういった下準備をしておいてあげる必要があります。

つまり、Curated data layer、もしくは、Application data layerのデータ準備が必要です。

Curated data layer/Application data layerの事前整備

ではCurated data layer/Application data layerを最初に整備しておけばいいのかというと、そうではありません。

Curated data layer/Application data layerというのはある程度ニーズがわかってからでないと整備できません。
なぜなら、データ分析基盤の基本的な考え方はSchema on readだからです。
Schema on readというのは、「データを使う側がデータの形を決める」という原則のことです。

そのため、Curated data layer/Application data layer整備のスタートはボトムアップアプローチになります。
ある程度サンプルが揃ってきたタイミングでトップダウンに変えていくことがスピードアップの秘訣になるかなと考えています。

タイミングを考慮をしていないと、使われないCurated data layerの発生や、内製化の停滞などが発生してしまいます。

DXの成熟度にあわせてステップを踏んでいく

DXには成熟度の段階があり、成熟度にあわせてステップを踏むことが必要だと思っています。

どこでボトムアップ/トップダウンを切り替えるか、あるいは、どこまでは自由に進めてどこから統制をとるか。
DX成熟度のどの段階にいるかによって、手を付けるべき内容も変わってくるはずです。

最後まで読んでいただきありがとうございました。