【ITニュース解説】Why ETL Becomes ELT or Even LET?

システムエンジニアがデータを取り扱う際、「ETL」という言葉は頻繁に登場する。ETLとは、Extract（抽出）、Transform（変換）、Load（ロード）の頭文字を取った略語で、複数の異なるシステムに点在するデータを集め、目的に合わせて加工し、最終的に利用するシステム（主にデータベース）に格納するまでの一連の処理を指す。

このプロセスは、まず「Extract（抽出）」で、さまざまなデータソース（例えば、別のデータベース、ファイル、Webサイトなど）から必要なデータを取り出す。次に「Transform（変換）」で、抽出したデータをターゲットシステムで使いやすい形に加工する。具体的には、データのフォーマットを統一したり、誤ったデータを修正したり、複数のデータを結合して新たな情報を生成したりする作業が含まれる。最後に「Load（ロード）」で、変換済みのデータを最終的に保存したいデータベースなどに書き込む。

理想的なETLプロセスは、「抽出」→「変換」→「ロード」という順序で進む。つまり、必要なデータだけを元の場所から取り出し、それをきちんと加工してから、最終的なデータベースに格納するのが最も効率的で理にかなっていると考えられている。

しかし、実際のデータ処理の現場では、この理想的なETLの順序が崩れることがしばしば発生する。ETLが「ELT（抽出→ロード→変換）」や「LET（ロード→抽出→変換）」といった変則的な形になるケースが増えているのである。

なぜこのような変則的な流れが発生するのか。その主な理由は、データの発生源である「ソース」の計算能力が低いことにある。多くのデータは、高性能なデータベースではない、計算能力がほとんどないファイルやWebサービスといった場所から生まれる。これらの場所で直接データの抽出や変換といった複雑な処理を行うのは、技術的にも性能的にも難しい場合が多い。

そこで、多くのシステム開発者が目をつけたのが、高性能な計算能力を持つデータベースである。データをまずデータベースにロードしてしまえば、その後はデータベースの強力な機能や豊富なSQLを使って、必要な抽出や変換を効率的に行える、という考え方が広まった。特に、複数の異なるデータベースからデータを集めて結合したり加工したりする場合には、一度ターゲットとなるデータベースにすべてのデータを集約する方が、個々のデータベースで処理するよりも便利に見えることが多かった。これがELTやLETといった変則的なデータ処理の流れを生む主な要因となっている。

しかし、ELTやLETといった変則的なETL方式は、一見便利に見えても、実際の運用において深刻な問題を引き起こす。

一つ目の問題は「時間コストの増大」である。本来なら変換によって不要な部分が取り除かれるはずの、大量の未加工データ（時にはまったく必要ないデータも含む）を、最初に丸ごとデータベースにロードすることになる。この大量のデータをデータベースに書き込む作業だけでも膨大な時間を要する。さらに、ロードしたデータベースの内部で、抽出や変換といった計算処理を追加で行うため、全体の処理時間はさらに長くなる。ETL処理は、通常、業務への影響を避けるために、夜間などシステムの利用が少ない「ETL時間枠」と呼ばれる限られた時間帯に実行される。例えば夜10時から翌朝5時といったように厳密に定められていることが多い。処理時間が長引き、この時間枠内にETLが完了しないと、翌日の業務システムに遅延や不具合が発生し、ビジネスに直接的な損害を与える可能性がある。ETL処理が長くなればなるほど、利用できる時間枠は狭まり、ビジネスへのリスクは高まる一方である。

二つ目の問題は「データベースの負荷増大」である。大量の未加工データがデータベースに格納されるため、データベースのストレージ容量が大きく圧迫される。これにより、データベースの負荷が高まり、将来的なシステム拡張（スケーラビリティ）の面で大きな課題となる。特に、現代のアプリケーションで多用されるJSONやXMLのような階層構造を持つ複雑なデータは、データベースに格納する際に複数の関連テーブルを作成する必要があり、データベース容量の問題をさらに悪化させる。データベース内で計算処理が増えれば増えるほど、データベースのリソースは消費され、処理に要する時間も長くなる。この負の連鎖により、システム全体が悪循環に陥ってしまう。

これらの問題の根源は、やはり「データベース外のデータソースの計算能力が低い」という点と、「データベースの計算能力に頼りすぎる」という点にある。もし、データベースにロードする前に、外部で十分な計算能力を提供できれば、ETLは本来の「抽出」→「変換」→「ロード」という理にかなった順序に戻すことができるはずである。

そこで注目されるのが、オープンソースの「esProc SPL」のようなツールである。SPLは、独立して動作するデータ計算エンジンであり、データベースに依存しない形で、様々なデータソースに接続し、データ処理を行う能力を持つ。

SPLは、この「データベース外での計算能力」を提供することで、真のETLプロセスを実現する。データ抽出（E）とデータ変換（T）をデータベースの外で実行し、完全に準備されたデータのみをターゲットデータベースにロード（L）するのだ。これにより、前述したELT/LETが抱える多くの問題を解決できる。

SPLの具体的な特徴と利点は多岐にわたる。

まず、SPLは多様なデータソースへの接続と混合計算をサポートしている。リレーショナルデータベースはもちろん、ファイル、Webサービスなど、計算能力の有無に関わらずあらゆるデータソースから、その独自のメソッドや構文を使ってデータを効率的に抽出・変換できる。特に、JSONやXMLといった階層構造を持つ複雑なデータについても、簡単な関数一つで解析し、加工できる能力は、現代のデータ処理において非常に強力である。これにより、複数の異なるデータソースからデータを抽出し、データベースの計算能力に頼らずに加工し、データベースにロードすることが可能になる。

次に、SPLの優れた計算能力と手続き型制御が挙げられる。SPLは、構造化データオブジェクトや、グループ化・集計、ループ、分岐、ソート、フィルタリング、集合演算といった基本的な処理に加え、順序ベースのランキングや複雑なグルーピングなど、高度な計算を直接サポートする。 ビッグデータ処理にも対応しており、「カーソル」と呼ばれる機能を使うことで、メモリに収まりきらないような大量のデータでも、メモリ内のデータを扱うのとほぼ同じ方法で効率的に処理できる。例えば、ファイルからデータを読み込み、性別と年齢の平均をカーソルを使ってグループ化・集計するような処理も容易である。 また、SPLは手続き型プログラミングをサポートしている。これは、プログラマが慣れ親しんだ思考の順序で、計算ステップを一つずつ記述できることを意味する。これにより、データベースのストアドプロシージャで記述されてきたような複雑なETL計算も、柔軟かつ高性能に、データベースに負荷をかけることなく実現できる。SPLで記述された「データベース外のストアドプロシージャ」は、従来のストアドプロシージャの理想的な代替となり、データベースの負荷を極力軽減できる。EとTの計算がデータベースの外で行われることで、データベースの計算リソースの消費や、大量の未加工データの保存が回避され、ストレージ容量の問題も解消される。

開発効率の面でもSPLは優位性を持つ。SQLやJavaよりも簡潔な構文を採用しており、特に複雑なEとTの計算を、より簡潔なアルゴリズムと短いコードで実現できる。これにより、開発効率が大幅に向上する。ある保険会社の事例では、SPLを使って車両保険のETL処理を実装したところ、わずか500セル未満のコードで済んだのに対し、元のストアドプロシージャでは2000行のコードが必要であったという。これは作業量が3分の1以上に削減されたことを示している。 技術スタックの観点からも、SPLは一貫した構文スタイルを持つため、ETL処理における多様なデータソースに対して統一された計算能力を提供する。これにより、プログラマは異なるデータソースに対応するための複数の方法を学ぶ必要がなく、学習コストやメンテナンスコストが削減される。さらに、統一されたアプローチはSPLコードの移行性を非常に高くする。ETL計算中に異なるソースに切り替える必要がある場合でも、データ取得コードを変更するだけでよく、中核となる計算ロジックはそのまま維持できる。

SPLの高性能な計算能力は、十分なETL時間枠を確保することにも貢献する。 SPLでは並列処理が容易に実現できるため、複数のCPUの利点を最大限に活かしてデータ取得と計算を高速化できる。例えば、複数のスレッドを使ってデータを取得したり、巨大なファイルからマルチスレッド処理でデータを読み込んだりすることが可能である。SPLの多くの関数は、自動並列処理を可能にするオプションをサポートしており、複雑な設定なしに高速化を実現する。

ETLプロセスでは、中間結果や最終結果を永続的に保存する（ストレージ）ことがよくあるが、SPLは独自のバイナリストレージ形式を提供している。この形式は、データタイプを保持してデータ解析の手間を省き、効率を高める。また、CPU負荷とディスクアクセス時間のバランスを考慮した適切な圧縮メカニズム、行指向と列指向の両方をサポートする柔軟性、さらに、追記可能な単一ファイル上でセグメンテーション（分割）を実現する独自の「ダブルインクリメントセグメンテーション」技術により、並列処理を容易にする。これらの高性能なストレージメカニズムは、計算性能の基本的な保証となる。適切なストレージと効率的なアルゴリズムは、高性能計算の要である。

SPLは多数の高性能アルゴリズムも提供する。前述の保険会社の事例では、SPLはコード量を3分の1に削減しただけでなく、独自の「多目的走査（Multi-purpose traversal）」技術により、計算時間を2時間から17分にまで短縮した。この技術は、大規模なデータテーブルを一度の走査で複数の操作を同時に実行することを可能にし、外部ストレージへのアクセス回数を劇的に減らす。これに対し、リレーショナルデータベース（RDB）のSQLでは、複数の操作を行うためにテーブルを複数回走査する必要がある。SPLは、このようにして性能を大幅に向上させる。 また、ETLプロセスでは、巨大な親テーブルと子テーブルの結合（例えば、注文テーブルと注文詳細テーブル）が頻繁に発生する。このような結合では、多くの場合、主キー（プライマリキー）を介して関連付けられており、一対多の関係にある。事前にテーブルを主キーでソートしておけば、「順序ベースマージ結合（Order-based merge algorithm）」と呼ばれるアルゴリズムを利用できる。このアルゴリズムは、従来のハッシュ結合アルゴリズムと比較して、計算の複雑度を大幅に削減し、性能を飛躍的に向上させる。RDBは順序付けされていない集合の理論に基づいており、SQLで順序付きデータを活用して性能を向上させることは難しいが、SPLはこの点で優位性を持つ。

このように、esProc SPLをETLプロセスの「抽出」と「変換」を行うエンジンとして利用することで、データ計算部分をソース側とターゲット側の両方から分離し、疎結合化できる。これにより、非常に柔軟で移行しやすいコードが実現され、ソース側とターゲット側のシステム負荷を適切に管理できる。データベース外での計算という利便性によって、ETLプロセスは本来の理想的な順序で実行可能となる。さらに、SPLは高性能なストレージ形式、最適化されたアルゴリズム、並列処理技術により、効率的なETLプロセスを保証し、限られた時間枠内で可能な限り多くのETLタスクを完了させる能力を持つ。

SPLはオープンソースであり、GitHubからソースコードを取得し、無料で試用できる。