はじめに（翻訳者から）
こんにちは。primeNumberマーケティングチームの齋藤です。
本日は、翻訳記事『ゼロETLの未来はやってくるのか？』をお届けいたします！
昨今、大手クラウドプラットフォーマーのキーノートスピーチに登場した「ゼロETL」というキーワード。
データパイプライン構築の負荷を大幅に低減するとともに、サービス間のシームレスな統合により、分析用データの利活用をより加速させるための考え方であり、開発です。
みなさまは、この「ゼロETL」というアプローチについてどのようにお考えでしょうか。
この記事が「ゼロETL」について考察するうえで材料の一つとなれば幸甚です。
目次
推奨される読者
- ゼロETLについて知りたい方
- ゼロETLの将来と実現性について考えたい方
- ゼロETLときいて魅力を感じる方
- 本当にETLは無くなるのか疑問を持っている方
本記事は、Seattle Data Guyのこちらの記事を許諾のもとで書き起こし、邦訳したものです。
Coordinated and Reviewed by Brett Torenvlied of primeNumber, Inc.
前置き
AWSはつい先日、流行に乗って「ETLの必要性を無くす」と宣言した。
Snowflakeも、ハイブリットテーブルとSalesforceとのパートナーシップの文脈双方から同様のアナウンスをした。
僕は「ゼロETL」という呼び方に少し違和感がある。
なぜなら表面を眺めてみると、そこで説明されている機能性というのは、「統合が無くなる」未来に近いからだ。
これはあまり魅力的ではない。
また、今回のアナウンスメントは、AWSやSnowflakeといった企業がETLを無くすためにとる動きの第一段階にすぎない可能性がある。
総合的に、データを複製するためのロジックやデータ量を減らすというアイディアには賛成する。
もし「ゼロETL」の世界まで僕らを導く道筋があるなら、僕らはその道筋を実現化すべきだ。
しかし、「ゼロETL」の未来に至るまでに何が必要だろうか？
この記事では「ゼロETL」の未来と、どうやったらそこにたどり着く可能性があるかについて考察してみたい。
認知的な課題
僕が冒頭のようなアナウンスメントを読んだり聞いたりしたときに感じるのは、
「議論にあがらないニュアンスがある」ということだ。
しかし、ビジネスサイドの人々が同じアナウンスメントを読んだときには、
書かれていることを文字通り受け止めていそうだと、僕は感じた。
そうしたビジネスサイドの人間は、会社に戻ってチームに告げる。
「この、ノーコードで、ゼロETLで、サーバレスな未来を取り入れよう。」
ビジネスサイドからは、これは聞こえのいい話だ。コストを削減し、その業務領域にあてる人員を減らすことができ、データは価値を瞬時に生んでくれる。
しかしこうした見方は、推進にあたって不可避となるニュアンスを見過ごして進めていることになりかねない。
ゼロETLの未来について語る前に、そもそもETLが何のために存在しているのかについておさらいしてみよう。
なぜETLが存在するのか
ある地点Aから地点Bにデータを移動するだけでは、ETLとは呼ばない。
もしそれが必要なことの全てなら、僕らはただデータベースを複製してそれをベースにレポートを作成すれば良い。
なら、なぜ複雑なシステムを構築する必要があったりAirflowやPrefectのようなツールを使う必要が出てくるのだろうか？
なぜ、高給を支払ってデータエンジニアを雇うのだろうか？
なぜ、そもそもETLする必要があるのだろうか？
ヒストリカルデータ
一般的に言って、オペレーショナルデータベースはヒストリカルデータを追尾しない方式になっている。
例えば「顧客の住所」のように、時を経て変わっていくようなエンティティのデータ更新履歴についてトラッキングしてくれないのだ。
だから、データが更新されたり削除されたりしていくと、CDC(変更データキャプチャ)が無い場合には、過去データを失ってしまうことになる。
この問題があったから存在するのが、「スロー・チェンジ・ディメンション(Slowly Changing Dimensions＝SCD)」というコンセプトだ。
顧客に州をまたぐような引越があったり、新しい企業へ転職した際など、時間とともに変更履歴を正確に記録しておく。
ここで一点述べておきたい。
伝統的なSCDの手法を用いる代わりに日付でパーティションを切り、永遠に拡張しつづけるテーブルにデータを流し込み続けるという方法もありうる。
この方法はデザインがよりシンプルだから、Facebookでは時々この手法を使った。
しかし、この手法ではデータサイエンティストやデータアナリストがデータをクエリすることが難しくなることがある。
多くのケースで、セカンダリーテーブルを作って日付ごとの変更履歴を追尾するロジックを組み込んだことがあった。
だから結論として、データモデルからSCDという考え方を除外することは難しい。
（ただし、作業を自動化することはできそう？）
データ統合
僕がFacebookで勤務していた際に得た大きな恩恵の一つは、アプリケーションレベルでデータがいかによく統合されていたかということだった。
誰もが利用できるエンティティ層が存在しており、新機能の開発をしながらでもその層からエンティティを引っ張ってくることができた。
つまり、アプリケーションサイドと分析サイド双方のレベルで、エンティティ同士を結合(ジョイン)する作業を容易に行えたのだ。
Facebookでの勤務が終盤にさしかかるまでに、僕らはコアとなるデータパイプラインを30-50個くらいに集約することができた。
大部分は、構成上の工夫だった。SQLのパートでさえ、いくらか削除することができた。
これは、エンティティ層が非常によく開発されていたために、データを結合するための複雑なクエリを書かなくて済んだということがとても大きい。
上記のような状況ではないことが多々あるだろう。企業は多様な形式とサイズのデータを保有しており、ソースを横断したデータ統合は不可能に近い。
また、エンティティ同士を結合するためだけでも、数百行のSQLを書く必要がある。
MongoDBやMySQLといったオペレーショナルデータベースから抽出されたデータは大抵、分析者にとって扱いにくい構成になっている。
アナリストにMongoDBからのデータファイルを渡す際を想像してもらえるだろうか？
非常に深くネストされていて、使える状態になるように丁重な処理をかけてあげても、エラーが起きてしまいやすい。
伝統的なMySQLデータベースで、重厚に正規化されたデータモデルを使っても問題が起きることがある。
RedshiftやSnowflakeにデータをコピーしようとするだけでも、アナリストは複数のジョインと、場合によってはビジネスロジックの入ったクエリを記述しなければならないことがある。
これも、エラーが起きやすい作業だ。
データにどんな処理がかかろうとも(名称の標準化にしろ、データモデルをそっくり新しくするにしろ)、それは分析者をデータによりアクセスしやすくするためだ。
ただ他のデータベースにぽいっと投げ込むのではなく、ユーザーが触れるプロダクトとしてデータを扱うのだ。
これらのことを全て述べた後に言えるのは、以下のようなことだ。
ETLについて、少なくともコアなデータ層を構築するためのETLについては、その必要性を取り除く未来は、可能だと思う。
ゼロETLの未来のためには何が必要なのか
命名やデータ型の標準化、SCDといった左側のレイヤーは自動化の余地があるが、
右側のKPIやメトリクスのレイヤーは人が関わる部分なので自動化は難しそうだという。
エンティティ層
もしより多くの企業がアプリケーション層で統合されているシステムを作ることができるなら、データ統合についてはイシューが生じないように思う。
これはつまり、企業のアプリケーションチームやSaaSソリューションにより多くの責務を負わせるということでもある。ゼロETLの未来に進むうえで大きな課題となってくるだろうし、未来の到達を遅らせる要因の一つともなってきそうである。
命名規則とデータ型の標準化
データの命名規則とデータ型を標準化すると、冗長な作業の多くを解消できるように思う。
これはフェアな疑問だと思うが、どうしてデータエンジニアはいまだにDWHにデータをロードする前に細かい変換(“EtLT”)をしなければならないのだろうか？
結論を言うと、合意のもとで標準化された命名規則を全てのフィールドについて使い始めた方が良いと思っている。
これができると、データ型についても標準化が可能になるだろう。ソフトウェアエンジニアについてはデータのフォーマットについても合意が必要だ。
データ生産者による所有と責務
データウェアハウスもしくは純粋なインフラ層については、何らかの標準化なしにはSaaSアプリケーション領域のzeroETLを実現することはできないだろう。このビジョンを実現するためには、SaaSベンダーが顧客のデータをウェアハウスに送るという責務を引き受けることが必要になる。
– Arun Thulasidharan
データを動かすということに加えて、SaaSベンダーとデータ生産者はロジックとデータの変更履歴を確実にマネジメントする必要が出てくるだろう。
ETLを取り払うのに一番難しいのは、「T(変形)」の部分だ。
例えば、名称やデータ型を標準化するといったシンプルな変形にとどまったことではない。
(それにしても、なぜこれがいまだに自動化されていないのだろうか？）
スロー・チェンジ・ディメンション(SCD)でさえ、標準化できる可能性がある。
さらに上記の変形を終えてデータがたどり着く先でも、かなりの変形加工が発生してくる。
手動運用が必要になりそうないかなるビジネスロジックや列挙子(enumerator)についても、データの生産者によって管理されなければならない。
企業のアプリケーションであっても、Salesforceであっても、だ。
真実
僕はデータエンジニアとしてこのキャリアをスタートしているから、データエンジニアなら誰しもが取り組む課題であるETLを援護すると思った方もおられるだろう。
しかしながら世界は変わるもので、その世界が「データエンジニアがETLパイプラインを構築することは不要だ」と言ったら？それでいいと思う。
今僕が考えるのは、この先2年くらいはそういったことは実現しないだろうということだ。
少なくとも、エンタープライズレベルの企業では起きない。こうした企業では、うまくいってもこの先2年間は既存のソリューションからマイグレーションしていく期間になるだろうからだ。
だから彼らが今日始めたとしても、僕らはゼロETLの未来からはまだまだほど遠いところにある。
あなたはどんな風に考えているだろう？ETLの無い未来をイメージできるだろうか？
何が必要になってきそうだろうか？
最後に (翻訳者から)
いかがでしたでしょうか。
trocco®︎はデータ分析基盤の総合支援SaaSとして、ETL/ELTのほか、データカタログやdbt連携機能など幅広く企業のデータマネジメントにご活用いただける機能を有しております。
ぜひご興味がございましたら、無料のトライアルにて触ってみていただけましたら幸いです！
今回の記事は以上です。Have a Happy Data Engineering Day!!
Credit: Seattle Data Guy (https://www.theseattledataguy.com/)
Thanks for letting us transcribing and translating this video!
