サーバーサイドエンジニアのデータベースエンジニア寄りの枠ぐらいの認識しかないと、
データエンジニアリングの尖った部分に永遠に近づけないという感触がある。
サーバーサイドエンジニアの入口から入った場合はちゃんとチェンジしないといけないな。
dbtが公式で「データエンジニアリングの用語と概念」を長い尺で説明していて学んでみた。
サーバーサイドエンジニア的にはETLは普通のジョブやバッチ処理だと思うが、
ELT化することで何を改善しようとしていて何が達成されたのか説明できるようになった。
dbt Fundamentals
https://courses.getdbt.com/courses/fundamentals
ETLとELTの違い
旧来から分析基盤を作るためにデータを抽出してどこかに蓄え加工してDBに入れてきた。
これは、巨大なデータをダイレクトに入れる箱や資源がなくそれ以外の選択肢がなかったため。
これはもうサーバーサイド開発であってバッチ処理で必要なデータを揃えているのにあたる。
構成を実現するためのインフラレベルの観点、分析用途に加工するビジネスロジックの観点の2つ。
この2つをゴチャっと処理する巨大なソフトウエアを書かないといけなかった。
クラウドベースのDWが登場し、巨大なデータを入れる箱や資源が安く手に入るようになった。
そしてdbtのように「生データをうまいこと加工する」ツールが手に入るようになった。
抽出したままの生データを突っ込むのは簡単だし、ツールでうまいこと加工できるようになった。
もちろんSQLだけで加工するので出来ること出来ないことはあるが、
うまくいけば、誰も開発やメンテがしづらい巨大なソフトウエアを書かなくてもよくなった。
分析用ビジネスロジックの分離
dbt公式のdbt Fundamentalsの初っ端で、
抽出したデータをDWに投入するインフラレベルの人たちを「Data Engineers」、
生データをBIで必要なレベルまで加工する人たちを「Analytics Engineers」、
分析する人たちを「Data Analysts」と分類している。
実際、エンジニアが分析対象を理解しようとすると、キャリアの壁にぶち当たる。
エンジニアは技術力が必要だし分析者は要件定義能力が必要。
要件定義的なことができるエンジニアは圧倒的に不足しているのが世の常で、
エンジニアに対する要件から要件定義能力を分離したいというのは切実な思い。
dbt Fundamentalsで紹介されている下の表はよく出来ていると思う。
(フロントにETLを前提としたBIツールがあってTとLをUIでやらせる世界観だと
組み合わせたときにELTLになってしまう。トータルで考えないと上手くいかないと思う)
Modern Data Stackとdbt
dbtは「T」をやるツール。dbtの有名な図は以下。「E」と「L」は外。BIやMLは外。
ほぼSQLとymlだけで構成できるところが特徴。
SQLを使ってモデルを開発して、SQLを使ってテストして、ドキュメンテーションを構造化する。
WHがあって初めて存在するツールであって、WHの資源を使って動く。
オーケストレーションとDAGの管理が内包される。
まとめ
インフラ的な観点とビジネスロジック的な観点の2つがゴチャった何かを作るのは大変という世界がある。
まぁそれでも書けよ、とも思うけど単にデータを抜いて格納するだけの人と、
要件定義してビジネスロジックを考えてデータを加工する人を分けられれば、人を集めやすい。
強力なDWが出来たことでデカいデータを生でぶち込めるようになったし、dbtみたいなツールができて
ビジネスロジックに基づいて生データを加工するのが簡単になった。
トータルで複雑なソフトウエアを作らなくてもよくなるからELT美味しいよ、という話でした。