なぜDWHの課金は膨らむのか ― ETL×ELTで見直すクラウドコスト
データドリブン経営の進展により、増大するクラウドコストが企業の財務を圧迫するケースが増えています。コスト急増の主な要因は、データウェアハウス（DWH）内で行われる負荷の高いデータ結合処理にあります。
本コラムでは、ETLを用いた前処理によって、データウェアハウスのリソース消費を抑え、コストをコントロールするための手法を紹介します。
データ活用の裏側にある「隠れたコスト」
データに基づいた経営が求められる中、扱うデータ量と分析頻度は爆発的に増加しており、その結果、システム基盤やインフラコストへの負荷も急速に高まっています。
特に機械学習（AI/ML）や生成AIの進展に伴い、モデル訓練に必要なデータセットは巨大化・複雑化の一途を辿っています。また、従来の構造化データに加え、テキストや画像といった非構造化データの活用が一般化したことも、保存・処理コストを押し上げる大きな要因となっています。
このコラムを読んでいる方の中には、クラウドの請求額が当初の想定を超えて膨らみ、頭を悩ませている方もいるかもしれません。クラウドネイティブな環境では、データ処理の遅延は意思決定を遅らせるだけでなく、処理が長引くことで不要なリソース消費を招き、コスト面でも無視できない影響を与えます。本来はデータ活用によって利益を生むはずが、気づけばコストばかりが増えてしまう……そんな状況は、どのようにすれば避けられるのでしょうか。 本稿では、その考え方や対策について掘り下げていきます。
コスト増大の犯人
DWHや分散データベース環境において、処理コストの大部分を占めるのは、単純なデータの絞り込み（フィルタリング）ではなく、「データ同士の結合（ジョイン）」です。
SnowflakeやGoogle BigQuery、AWSのAmazon Redshiftといった分散データ処理基盤では、大規模データが複数のサーバー（ノード）に分散して保存されています。ジョインを実行する際、システムは一致するキーを持つデータ同士を物理的に同じ場所に集めて突合する必要があります。このノード間を大量にデータが飛び交うプロセスを「シャッフル」と呼びます。
この「シャッフル」こそが、予想外のクラウドコストの増加をもたらす原因のひとつです。Snowflakeの公式事例によれば、最適化されていないジョインはネットワーク負荷を10倍以上（約3GBから約39GBへ）も膨れ上がらせることが確認されており、この急激なデータ転送量の増加が、パフォーマンスを低下させ、リソースを消費する主な要因になります。
また、この「シャッフル」は処理時間にも影響します。ジョインの回数が増えるにつれ、処理負荷は二次関数的に増大します。あるケースでは、最初のジョインには約610スロット秒しかかからなかった処理が、ジョインを繰り返した最終工程では約37,000スロット秒（約60倍）にまで膨れ上がった例も確認されています。
ビジネスにおいて迅速な意思決定が求められるなか、「分析に必要だからとりあえず結合する」というジョインありきの設計が、知らず知らずのうちにインフラ費用を浪費し、プロジェクトのROI（投資対効果）を毀損してしまう可能性があります。
▼DWHについてもっと詳しく知りたい
⇒ DWH｜用語集
現代のデータ連携における設計思想
データ結合がコストを押し上げる大きな要因となっている今、改めて注目されているのが、データ処理の設計思想である「ETL」と「ELT」の使い分けです。
従来主流だったETL（Extract/Transform/Load）は、ソースから抽出したデータを「DWHに入れる前に」加工・整形する手法です。一方、クラウド時代の到来とともに普及したELT（Extract/Load/Transform）は、まず生のデータをDWHへロードし、その強力な計算リソースを用いて「DWHの中で」変換処理を行う手法を指します。
かつては、DWHの計算リソースが高価だったため、格納前にデータを整形する「ETL」が必須でした。その後、クラウド型DWHの普及により「まずはロードしてDWH内で加工する」という「ELT」が手軽な手法として広まりました。しかし、前項で述べたようなジョインによるコストの急増によって、すべてのデータ処理をDWH内（ELT）内で行うことに限界が見えています。
ここで重要になるのが、ETLツールによる「前処理」です。DWHに流し込む前に、ETLツール側で不要なデータの削減や、重いジョインを避けるための事前集計・クレンジングを行う。この「前処理」を挟むことで、DWH側の無駄な計算リソース（クレジットやスロット）の消費を抑えることが可能になります。
つまり、「スピードのELT」と「統制とコスト最適化のETL」を適材適所で組み合わせるハイブリッドなアプローチこそが、現代のデータエンジニアリングにおけるひとつの重要なポイントです。
▼ETLについてもっと詳しく知りたい
⇒ ETL｜用語集
DWHのコストを改善する「前処理」
ELTが主流となった今、あえてDWHの手前でETLツールを活用する最大のメリットは、高単価なDWHの計算リソースを、無駄なシャッフルに使わせないことにあります。
例えば、データのカーディナリティ（カラムに含まれるユニークな値のバリエーションの多さ）を事前に下げるという手があります。ジョインが重くなる最大の原因はレコード数が多いこと。DWHにロードする前に、ETLツール側で不要な行のフィルタリングや、分単位のデータを日単位に集計しておくことで、DWH内でのジョイン対象となるテーブルサイズを最小化できます。
また、マスターデータのクレンジングや、小さなジョインをDWH外で済ましておくことも有効です。DWH内でいちいち表記揺れの修正をしながらジョインを行うと、処理はさらに複雑化します。ETLツール側でマスターデータのクリーニングを完了させ、結合キーをあらかじめ最適化しておくことで、DWHは内部で複雑なデータ変換を行う必要がなくなり、最も負荷の低い計算ルートを迷わず選択できるようになります。
トランザクションデータに少数のマスター属性を付与する程度の処理であれば、ロードプロセスの中でETLツール側にて結合を済ませ、ワイドテーブル（あらかじめ必要な項目を横方向に結合し、1枚にまとめた表）としてロードしたほうが、DWH側での「シャッフル」を物理的にゼロにできます。
コストを分けるジョイン戦略
前項で述べた通り、DWHのコストを最適化する鍵はいかにデータを移動させないかにあります。そこで、DWH内部で実行されるジョインの種類と違いを理解しておくことが重要です。
①シャッフル・ハッシュジョイン
巨大なテーブル同士を結合する際に選択される方式です。各ノードに分散しているデータを、結合キーに基づいてネットワーク経由で全ノードへ再配置（シャッフル）します。データの移動量が膨大になるため、ネットワーク帯域を消費し、処理時間は劇的に増大します。 この場合、そもそも巨大なテーブル同士を結合しなくて済むよう、ETLツール側で事前にデータを絞り込む、あるいは中間テーブルを作成しておく設計が不可欠です。
②ブロードキャストジョイン
片方のテーブルが相対的に小規模な場合、そのテーブルの全コピーをすべてのノードに配布する方式です。大きい方のテーブルは動かす必要がなく、各ノードが手元にあるマスターデータと突合するだけで済みます。ネットワーク転送が最小限に抑えられるため、シャッフルに比べて圧倒的に高速かつ低コストです。
多くのDWHでは自動最適化機能がありますが、テーブルサイズが閾値を超えると強制的にシャッフルに切り替わります。ここでETLツールの出番です。マスターデータをあらかじめクレンジングし、軽量な状態にしておくことで、確実にブロードキャストジョインを選択させ、DWHの課金を最小化できます。「SQLが動くからよし」とするのではなく、その裏側で「データがシャッフルされているか、ブロードキャストされているか」を意識できるか否かで、月間のクラウド請求額に数万〜数十万円の差が生まれます。
まとめ：データエンジニアリングはコストコントロール
データ活用と言えば「データを蓄積できるか」に注目が集まりがちですが、「いかに効率よく処理できるか」も非常に重要な観点です。ELTという便利な手法にすべて委ねるのではなくETLによる前処理を組み合わせることによって、クラウドコストの浪費を抑え、データ活用におけるROIを高めることに貢献できます。
データエンジニアリングの本質は、単にシステムを動かすことではなく、ビジネスの成長に合わせて「コストとスピードを最適にコントロールすること」にあります。まずは自社のDWHで、無駄な「シャッフル」が発生していないか、コストパフォーマンスを見直すことから始めてみてはいかがでしょうか。
記事を書いた人
