データドリブンな人間を目指している香取です。
データ分析の世界でよく耳にする「ETL」と「ELT」。ELT の方がモダンでイケてるんでしょ？くらいに思っていたのですが、それぞれ違いやサービス選定時の考慮事項を改めて整理してみました。
ETL と ELT とは？
ETL は Extract・Transform・Load の略で、ELT は Extract・Load・Transform の略です。
ETL では以下の流れでデータを処理します。
・Extract (抽出)：データソースからデータを抽出
・Transform (変換)：分析で使用可能な形式に変換
・Load (ロード)：データ基盤 (データレイクやデータウェアハウス) にロード
一方、ELT では以下の流れとなります。
・Extract (抽出)：データソースからデータを抽出
・Load (ロード)：未加工データをデータレイクにロード
・Transform (変換)：データ基盤上で変換し、データウェアハウスに再ロード
つまり、ETL と ELT の違いはデータ基盤にデータを取り込む前に変換を済ませておくか否かの違いと言えます。
6つの観点から見る ETL と ELT の違い
ETL と ELT の違いについて以下の6つの観点で比較してみます。 全ての観点を完全に満たすというのは難しいため、ご自身のユースケースやビジネス要件に応じて観点の優先度を決めておくといいかもしれません。
| 観点 | ETL | ELT | 補足 |
|---|---|---|---|
| 可用性 | △ | ⚪︎ | データがいつ利用できる状態になるか。 ・ETL : データロード前に変換方法を事前定義する必要があり、変換が完了するまでデータを利用できない。 ・ELT : 未加工データを先にロードするため、変換処理を待たずにすぐに未加工データにアクセスして探索的な分析が可能。 |
| 柔軟性 | △ | ⚪︎ | どれだけ容易に分析要件の変更に対応できるか。 ・ETL : 事前に変換定義を決める必要があり、要件変更時には変換ロジックの修正とパイプライン再構築が必要。 ・ELT : 未加工データが常に利用可能なため、新しい分析要件に応じて後から異なる変換を適用できる。 |
| アクセシビリティ | △ | ⚪︎ | データに誰がどれだけ自由にアクセスできるか。 ・ETL : 基本的には IT 部門やデータエンジニアが変換ロジックを管理し、データ利用者は変換済みデータにのみアクセス可能。 ・ELT : データアナリストやビジネスユーザーが未加工データに直接アクセスし、SQL や BI ツールで自由に変換・集計できる。 |
| 拡張性 | △ | ⚪︎ | データ量が増えた時にどれだけ対応できるか。 ・ETL : 新しいデータソース追加時に変換定義の修正、テスト、デプロイが必要で時間がかかる。 ・ELT : 新しいデータソースを単純にロードするだけで済み、変換は後から必要に応じて追加できるため迅速な拡張が可能。 |
| ストレージ | ⚪︎ | △ | データを保存するために必要な容量。 ・ETL : 変換後の必要なデータのみを保存するためストレージコストを抑制できる。 ・ELT : 全ての未加工データを保存するため大容量ストレージが必要だが、クラウドの安価なオブジェクトストレージを活用すれば比較的低コストで実現可能。 |
| コンプライアンス | ⚪︎ | △ | 法的規則や社内規則などにどれだけ対応しやすいか。 ・ETL : 変換段階で PII（個人識別情報）のマスキングや削除が可能で、GDPR や HIPAA などの厳格な規制に準拠しやすい。 ・ELT : 機密情報を含む未加工データが一時的に保存されるため、厳密なアクセス制御、暗号化、監査ログによる管理が必要。 |
AWS 上でのデータパイプライン実装例
ETL や ELT のパイプラインは、さまざまなサービスを組み合わせることで構築できます。例として、AWS サービスのみで ELT 構成を組む場合以下のようなアーキテクチャーが考えられます。
このように AWS のサービスのみで ELT パイプラインを構築することもできますが、ユースケースに合わせて他の SaaS 製品を組み合わせるパターンも考えられます。例えば、抽出部分では TROCCO や Fivetran を、変換・ワークフロー管理では dbt を使用するといったケースなどです。
サービス選定時の考慮事項
ETL や ELT 関連のサービスは非常に多くの選択肢があるため迷うことも多いかと思います。ここでは、選定時に考慮しておくとよさそうなポイントをいくつかご紹介します。
コスト
サービス選定時に考慮すべきコストは、単純な利用料金だけではありません。運用にかかる人件費やインフラを維持する費用も含めて考える必要があります。初期費用が安くても、運用に手間がかかって人件費がかさんだり、データ量が増えてインフラ費用が高くなったりすることもあります。長期的な視点で、全体としてどれくらいの費用がかかるのかを見積もることが重要です。
セキュリティ要件
顧客情報や機密性の高い情報を処理する場合は、そのサービスが提供するセキュリティ機能を確認する必要があります。具体的には、データが送られたり保存されたりする際に暗号化されるか、誰がデータにアクセスできるかを細かく設定できるアクセス制御の仕組みがあるか、データの操作履歴を記録する監査ログの機能があるかなどを確認しましょう。
パフォーマンスとスケーラビリティ
パフォーマンスは、大量のデータを処理する際にどれくらいの速さで処理が完了するか、スケーラビリティはデータの量が増えてもシステムが問題なく動き続けられるか、必要に応じて処理能力を簡単に増やせるか、という観点です。リアルタイムに近い速度でデータ処理が求められる場合や、将来的にデータ量が大幅に増えることが予想される場合には、これらの要素が特に重要になります。
複雑な処理への対応
ここでの「複雑な処理」とは、例えば「複数データソースの結合」や「機械学習の前処理」などを指します。これらの処理が必要な場合、そのサービス自身が持つ機能や、必要に応じて機能を拡張できるかどうかが重要なポイントになります。
既存システムとの連携性
すでに使っているシステムやサービスがある場合、それらとの連携のしやすさも考慮すべき点になります。具体的には、外部から操作できる機能（API）が提供されているか、様々なデータ形式に対応した接続機能（コネクタ）があるか、データの形式に互換性があるかなどです。もしも既に AWS 上でデータを管理している場合は、AWS のサービスと連携しやすいものを選ぶと良いでしょう。
サポート・コミュニティの充実度
サービスを選ぶ際、問題が発生したときにどれだけスムーズに解決できるかは非常に重要です。オープンソースのサービスはサポートがほとんどない場合もありますが、エラー時にプログラムのソースコードを直接確認できるという利点があります。一方で、ソースコードを読むことに慣れていない場合はサポート体制が充実したマネージドサービスを選ぶと良いでしょう。日本語でのサポートが受けられるか、公式ドキュメントが豊富に用意されているかなどもポイントとなります。
また、そのサービスがどれくらいの企業で使われているか、利用している人たちのコミュニティが活発かといった点も参考になります。導入実績が多いほど、そのサービスの信頼性が高いと考えられますし、コミュニティが活発だと困った時に情報を見つけやすかったりするメリットがあります。
学習コストと導入しやすさ
新しいサービスを導入する際、その使い方を覚えるためにかかる時間や労力も考慮すべきです。例えば、SQL ベースでデータの変換ができるサービスは多くのエンジニアにとって馴染み深い言語なので、比較的短期間で使いこなせるようになります。また、AWS Glue Studio や AWS Glue DataBrew のように GUI ベースで操作できるサービスもあります。 一方で、Python や Scala といったプログラミング言語を使って変換を行うサービスはそれらの言語の知識が必要になるため、学習コストが高くなることもあります。
生成 AI
最近では、自然言語での指示をもとに ETL や ELT のパイプラインを自動生成したり、データ変換の SQL クエリ文を提案してくれる生成 AI を提供しているサービスも増えてきています。これらの機能は、特にデータエンジニアリングの専門知識が少ないチームにとって有用です。
さいごに
ETL と ELT の共通点と違い、そしてサービス選定における考慮事項について、改めて整理してみました。
最初から完璧な構成やツールを見つけるのは非常に難しいことです。もし選定がうまく進まない時は、原点に立ち返って「何のためのデータなのか」「誰が、いつ、どんな風に利用するのか」「誰がデータ基盤を運用するのか」といった、そもそものユースケースやビジネス要件を整理することから始めてみるといいかもしれません。
この記事が ETL と ELT についての理解を深めるきっかけとなれば幸いです。
香取 拓哉 (記事一覧)
2023年度新卒入社
データドリブンな人間を目指しています
好きな食べ物は芽ねぎ
