2015年10月27日火曜日

データ移行におけるデータの結合について その1 ~ ETLとELT

大須賀です



データ加工において、2つ以上のテーブルをキーで結合することがあります。

実現方法としては、データベースなら、SQLのジョインの構文を使用することをすぐに思いつきます。

しかし、SQLはあくまで構造化設計されたテーブルを獲得するための機能です。
そのため、データは絞り込まれることを前提に処理されます。
絞った結果数十万件になるようなリストをエンドユーザーアプリに返すような処理はありえないとして、想定していないからです。


SQLエンジンはデータのマッチングをメモリあるいはそれに準ずる高速領域で処理しようとします。限定されたデータをさらに高速に処理するための手法ですが、想定外の大量データなどの場合は、逆に遅くなります。リソースが足りない場合にはパラメータチューニングが必要になりますが、それでも足りない場合はあります。



データ移行における加工の場合はどうでしょうか。

データ移行の場合、大規模なデータを全件対象で処理する必要があります。そのため、SQLエンジンのような手法では、かえって速度が遅くなってしまいますし、それが動くことでデータベースの他のユーザーへの影響も出てしまいます。

大量データを全件処理する場合には、ETLツールのようなバッチ処理型の方が効果的です。それも、なるべく一回読んで書くだけに最適化されるとなお良いです。


手法はごく単純です。入力データの両方あるいはマッチさせるマスタ側をキーでソートし、頭からぶつけます。非常にドロくさい方法ですが、ジョインが複雑になるほど、この方式が高速になります。

外部から入手したデータを処理するために、わざわざSQLデータベースに読み込んで加工する方式(ELT-Extruct、Load、Transform:データをDBに読んでから加工するという、ETLに対向した言葉)も最近出て来ていますが、私はこれはDBメーカーの苦し紛れだと思います。だいたい、SQLデータベースの書き込みの遅さを無視していますね。先ほどのバッチの手法なら、ロードを待っている間に処理は終了します。

ロードに時間がかかり、SQL実行にさらに時間がかかり、DBデータ領域にフラグメンテーションを起こして、最終結果をそのまま使用するならともかく、たいていの場合最後のデータ反映にアプリケーションかストアドプロシージャのプログラムが必要になります。SQLでは、オンライン中のDBに対する複雑な条件でのデータ追加や書き換えができないからです。
確かにこれらのオーバーヘッド満載の加工処理が苦も無くできる大規模DB専用ハードウェアもありますが、そのお値段を考えると、疑問視せざるを得ませんね。



0 件のコメント:

コメントを投稿