メダリオンアーキテクチャからゼロETLへ

ゼロETLというデータ処理の方式が頭角を現しつつあります。
どういう背景があって生まれたのか、また従来のETLやメダリオンアーキテクチャとは何が違ってどんなメリットがあるか見ていきます。

メダリオンアーキテクチャが色褪せている

AIやDXを始めとする最近の流れでビジネスにおける意思決定の在り方が大きく変化しています。
とにかく速く失敗して速く改善するFail Fastの精神が重要です。
そんな中、ビジネスの意思決定を支えるデータ処理の在り方も変化を求められています。

今もっともよく見るデータ処理アーキテクチャはETLでしょうか。
各データソースから集めたデータをデータレイクに貯めて、そこからキレイにしてデータウェアハウスに置いて、最終的に社内ユーザーが使いやすい形、つまりデータマートとして保存します。
レイク、ウェアハウス、マートをそれぞれブロンズ、シルバー、ゴールドという名称に置き換えたのがメダリオンアーキテクチャですね。（厳密に言うとレイクとウェアハウスを統合したレイクハウスの文脈でメダリオンアーキテクチャは登場します）

そんなメダリオンアーキテクチャは堅牢で高品質なデータを準備できるメリットがありつつも、ビジネスの速度にやや置いていかれているデメリットがあります。
またテーブルの数やそれらテーブルを作るためのパイプライン、コンポーネント、ソースコードなどの数も必然的に増えてしまい、複雑なアーキテクチャになってしまいがちです。
テーブルにせよパイプラインにせよ、自作のものが増えるとそれだけバグを仕込む確率が高くなってしまい、メダリオンアーキテクチャのメリットであるはずの品質がだんだん確保できなくなっていきます。
今、メダリオンアーキテクチャが変革のときを迎えているのです。

ゼロETLへ

そこで登場したのがゼロETLという概念です。
ブロンズ、シルバー、ゴールドという3層をやめて、ほぼ生の（従来で言うブロンズ、あるいはシルバーのような）テーブルから直接分析やBIに使ってもらうイメージです。
3層それぞれのテーブルを作るのに行われていたExtract、Transform、Loadも同時になくすことができます。
つまりゼロETLというわけです。

ゼロETLの特徴はスキーマオンリードの考え方です。
従来のテーブルはスキーマを定義してCREATEするので、INSERTするときにデータとスキーマが合っていないとエラーになります。
一方スキーマオンリードの場合、とりあえずデータをオブジェクトストレージなどに置いておき、呼び出すときに初めてスキーマを当てはめるのです。
こちらの方が柔軟性が高くとりあえずさっとデータ分析したいときに役立ちます。
最悪専任のデータエンジニアがいなくてもアナリストだけでデータを準備できてしまうのは、人的リソースが限られる小さめの組織にとっては大きなメリットでしょう。

それではメダリオンアーキテクチャやETLが完全に不要になる未来が来るかというと、それはないと思います。
ビジネスの意思決定でもFail Fastが有効な場面とそうでない場面があるように、データの品質が最優先な状況は相変わらず残り続けるからです。
他にも、大きな組織で色んなチームが同じような分析クエリを何度も実行しているような状況では、データマート（ゴールド層）がある方が品質の面でも処理資源の面でも良いように思います。（マテリアルビューを使って引き続きゼロETLを維持するのは有効な選択肢でしょうか）
また、小さな組織でゼロETLを採用する場合も品質をないがしろにして良いというわけではありません。
メダリオンアーキテクチャで実施していた品質確保策よりも丁寧な策が要求されます。
そのためのメトリクスなどを細かに取るべきでしょう。

まとめ

ETLやメダリオンアーキテクチャという方法に加えてゼロETLが求められるようになりました。
組織の規模やビジネスのフェーズなどに合ったアーキテクチャを採用する必要があります