ETL

概要

ETLは、Extract（抽出）・Transform（変換）・Load（格納）の頭文字で、あちこちに散らばったデータを分析できる形に整えて一か所に集める、データパイプラインの基本形です。業務システムのデータベース、SaaSのAPI、アプリケーションのログといった複数のデータ源から夜間などにデータを取り出し、形式を揃えてクレンジングし、データウェアハウスのような分析基盤へ積み込む、という一連の流れを指します。

「先月の売上をチャネル別に見たい」「解約率をユーザー属性と掛け合わせたい」— こうした分析の前提には、必要なデータが分析可能な形で一か所に揃っていることがあります。その「揃える」作業を自動化・定型化したものがETLで、データエンジニアリングという職種の中心的な仕事のひとつです。

なぜ生まれたか

企業のシステムは、販売管理・会計・在庫・顧客管理と、業務ごとに別々に作られていくのが常です。その結果、データはシステムごとのRDBMSやファイルに散在し、同じ「顧客」でもシステムによってID体系が違う、日付の形式が違う、金額に税が含まれたり含まれなかったりする、という状態になります。この状態で横断的な分析をしようとすると、毎回手作業でデータをかき集めて突き合わせることになり、時間がかかるうえに集計のたびに数字が食い違います。

さらに、業務システムのデータベースに重い集計クエリを直接投げると、本番業務の処理を圧迫する危険もあります。そこで1970年代以降のデータウェアハウスの発展とともに、「業務システムからデータを定期的に写し取り、分析用に変換してから専用の置き場に積む」という工程が定型化されました。これがETLです。散在と不整合という問題を、「変換を一度だけ、パイプラインの中で行い、以降は整った一枚のデータを全員が使う」ことで解決したのです。

詳細

三つの段階

Extract（抽出）は、データ源からデータを取り出す段階です。業務DBからのSQLによる読み出し、SaaSのAPI呼び出し、ログファイルの収集などが該当します。全件を毎回取り直す方式と、前回以降の差分だけを取る増分方式があり、データ量が増えるほど増分抽出の設計が重要になります。Transform（変換）は、取り出した生データを分析に使える形へ整える段階です。形式の統一（日付・通貨・文字コード）、重複や欠損の処理、システム間で異なるIDの突き合わせ（名寄せ）、集計しやすい構造への組み替えなどを行います。Load（格納）は、変換済みデータを分析基盤へ積み込む段階です。

ETLからELTへ — 変換を後回しにする転回

近年の大きな変化が、順序を入れ替えたELT（Extract-Load-Transform）の台頭です。従来のETLでは、格納前に専用の変換サーバやツールでデータを整えていました。分析基盤の容量と計算力が貴重で、「汚れたデータを置く余裕はない」時代の合理的な設計です。ところがBigQueryやSnowflakeといったクラウドDWHの登場で前提が変わりました。ストレージは安価になり、DWH自身が巨大な計算力を持つようになったため、「まず生データをそのまま積んでしまい、変換はDWHの中でSQLとして実行する」方が合理的になったのです。ELTでは生データが手元に残るため、変換ロジックの誤りに後から気づいてもやり直しがきき、変換処理をSQLとしてバージョン管理できる利点もあります。dbtのような変換管理ツールがこの流儀を後押しし、現在の主流になりつつあります。

バッチとストリーミング

ETLの実行タイミングには二つの流儀があります。伝統的なのは「夜間に1日分をまとめて処理する」バッチ処理で、実装が単純で障害時のやり直しも容易なため、今も大半のパイプラインの基本形です。一方、「今起きていることを分単位で見たい」という要求には、データが発生するそばからメッセージキュー（Kafkaなど）を通じて流し続けるストリーミング処理が使われます。リアルタイム性と引き換えに、順序の乱れや重複到着への対処が必要になり、設計の難易度は大きく上がります。「本当にリアルタイムが必要か」を見極め、バッチで済むものはバッチにするのが実務の定石です。

落とし穴 — パイプラインは静かに壊れる

ETLの厄介なところは、壊れても即座にエラーにならず「間違った数字が静かに流れ続ける」ことです。データ源側のスキーマ変更（列の追加・型の変更）で変換が黙って狂う、途中失敗したジョブの再実行でデータが二重に積まれる、といった事故が典型です。再実行しても結果が変わらない冪等性を持たせた設計、件数や値域を検証するデータ品質テスト、パイプラインの監視は、ETL運用の必須項目です。「分析の数字がおかしい」という指摘は往々にしてダッシュボードではなくパイプラインの上流に原因があり、データがどこから来てどう変換されたかを追える系譜（リネージ）の整備が、信頼されるデータ基盤の分かれ目になります。