こんにちは、佐々木です。年末に書こうと思って、すっかり忘れていた宿題です。 2022年末のre:InventのキーノートでAWSのCEOであるAdam Selipskyが、『A Zero ETL future』という概念が提唱しました。言わんとすることは解るのですが、これは一体どういう文脈で、なんのためなのだろうと疑問に思う方は多いと思います。そこで、自分なりにデータ分析を取り巻く現状と課題、ゼロETLの概念が出てきた理由をまとめてみます。これは私自身の思考なので、全然違う可能性が高いですので、悪しからず。
データ分析とETLの現状と課題
ゼロETLの話をする前に、データ分析とETLの現状の話をしましょう。データ分析をする際には、必ずデータが必要です。では、そのデータはどこからやってくるのか？単一のシステム内で分析する場合もありますが、多くの場合はいろいろなシステムから必要なデータを集めて加工した上で分析します。この集めて加工するというのがミソになります。例えば、ユーザーの購買行動を分析する場合は、例えば広告の効果がどれくらいあったのかや、リアルの店舗やオンラインのECサイトの行動の違いなどをみたいと思います。その際には、広告の出稿データや、リアル店舗での購買データ、ECサイトでのアクセスログなどが必要になります。 分析するためには、それらの一連のデータを集めてユーザー単位に集計します。データ収集や集計（加工）に使うのがETLです。
ETLは、Extract（抽出）Transform（変換）Load（格納）の頭文字を組み合わせたものです。まず抽出工程で、他システムなどから対象となるデータを集めます。次に、持ってきたデータを分析の用途に応じて変換します。最後に格納ということで、分析で利用する場所にデータを配置します。これがETL処理です。AWSでETLといえば、AWS Glueというサービスを使う事が多いです。GlueはETL処理を作るための便利な機能がたくさんあります。一方で、ETL処理を記述するのは結構な手間がかかります。個人的な感覚ではありますが、データ分析基盤構築の半分以上はETLを作ることに費やしています。実際にKeynote中でも、Adamは顧客から聞いた声として、「ETLは持続不可能なブラックホールのようなもの。ETLパイプラインの構築には、手作業、複雑さ、未分化な力仕事が必要で、苦痛を伴います。」と紹介しています。
That brings up a phrase that strikes dread into the hearts of even the sturdiest of data engineering teams.The literally used this phrase thankless, unsustainable black hole.The manual effort, the complexity and the undifferentiated heavy lifting involved in building ETL pipelines is painful.It requires writing a bunch of custom code.Then you have to deploy and manage the infrastructure to make sure the pipeline scales.Still, it can be days before the data is ready.And all the while you’ve got eager analysts pinging you again and again to check if their data is available and if, when, something changes, you get to do it all over again.We’ve been working for a frew years now on building integrations between our services to make it easier to do analytics and machine learning without having to deal with the ETL muck.
この状況を改善するために、AWSはETLのサービスであるAWS Glueを中心に地道なツールの改善を繰り返してきました。今回は、それとは別のアプローチとしてゼロETLという概念を導入してETLの苦痛を解決しようとしています。
ゼロETLとは何なのか？
前置きが長くなりました。それでは、AWSが提唱するゼロETLとは何なのでしょうか？簡単にいうとシステム間のシームレスなデータの複製です。今回発表された「Amazon Aurora zero-ETL integration with Amazon Redshift」は、Auroraにデータが書き込まれると、Redshiftにデータが複製（レプリケーション）されます。また、同時に発表されたサービスとして「Amazon Redshift auto-copy from S3」があります。こちらも、S3のデータを自動的にRedshiftにコピーするというサービスです。ETLのExtract（抽出）とLoad（格納）の部分を自動的にしてしまうという事になります。これがゼロETLの基本的な概念です。
ETLとELTとBig Query
ここまで聞くと、じゃぁETLのTの部分であるTransform（変換）はどうなるのと疑問に持つでしょう。ここについては、キーノートでは明確なメッセージを発していなかったです。そこで、こう考えているのではないかなと推察をしてみます。以前、データの民主化とELTというタイトルでETLを作り込むより、とりあえずDWH（Redshift）にデータを入れてしまってSQLでグリグリ（Transform）する方が楽だよという話を書いていました。ETLならぬELTですね。
この考え方で成功しているのが、Big Queryと個人的には考えています。とりあえずBig Queryにデータを入れれば、後はなんとでもなると。一方で、AWSのアーキテクチャの中心は何と言ってもS3です。S3をデータレイクとしてデータを溜めていき、必要に応じてDWHに格納して活用すれば良いという考え方です。私もこの考え方に共鳴していますが、ETLを作るのが面倒くさいのも事実です。AthenaやSnowflakeを使うという手もありますが、（格納していれば）SQLだけで完結するBig Queryの方が楽なのは間違いないです。 ゼロETLはこのあたりの面倒くささを解消し、S3最高って世界を目指しているのではないかと思います。
でも複雑なTransform（変換）はどうするの？
Transform（変換）は、SQLで実施すると非常に楽にできます。一方で、SQLだけではどうしても実現できず、プログラム言語の助けが必要な変換もあります。体感的には変換処理の10%くらいはこれです。AWSはどう考えているのでしょうか？同時期に発表されたTrusted Language Extensions for PostgreSQLの発表が伏線になっているのではないかと個人的には考えています。Trusted Language Extensions はプロシージャを拡張して、好きなような処理をより簡単に組み込むことができます。元々RDSにはLambdaを読み込むトリガーなどがありましたが、さらに選択肢と柔軟性を増やしていっているのではと推測できます。
まとめ
ゼロETLの実態は、データベースやS3からDWH（Redshift）に簡単にExtract（抽出）とLoad（格納）できるようにするサービスでした。現状は、AuroraとS3のみですが、対象となるサービスはどんどん増えてくると思います。またTransform（変換）については、SQLで対応できない部分もデータベース側の機能を拡張しカバーするというのを並行して進めているようです。AWSが考えるゼロETLの姿がどういうものかまだまだ解りませんが、紐解きとアーキテクチャ検討の一助になれば幸いです。5年後くらいに、また答え合わせしてみたいですね
