データ連携の基本テクニック「中間データストア」のポイント

ユニリタのETL：データ連携ツール「Waha! Transformer」などを使ってデータ処理を機械化・自動化する際、さまざまなデータ変換・加工処理が動作しますが、処理を効率化するために、中間的なデータストアを使用して、初期加工済みのデータを投入し、そこから複数の詳細な加工処理を動作させる例をよく見かけます。
セントラルウェアハウスほどではありませんが、冗長な加工処理を省くために有効な手法です。

＜追記参考＞
データ分析システムの全体像を理解する(3) データウェアハウスとスタースキーマ | Think IT（シンクイット）

データウェアハウスとは、データ分析システムで利用可能とするデータを一元的に格納するデータベースのことです。データウェアハウスに格納されたデータは、BIツールを通じてさまざまな分析に利用されます(図1)。

しかし、データウェアハウスは、単純に1つのデータベースから構成されるとは限りません。実際には以下の3つから構成されます(図2)。

セントラル・ウエアハウス
データウェアハウスの本体となるデータベースです。通常、リレーショナル・データベースが使用されます。

DSA(データステージングエリア)
業務システムのデータをセントラル・ウェアハウスに格納する前に必要となるETL処理を行うための一時的な保存場所となります。通常、OSのファイルシステム上のテキスト・ファイルもしくは、リレーショナル・データベース内のテーブルとして作成されます。

>

データマート
セントラル・ウェアハウスのデータの一部を、BIツールの種類やデータ分析の要件に最適な形で再構成された形態を持つ小規模なデータベースです。通常、リレーショナル・データベースが使用されます。

このような中間データストアにRDBMS：データベースを使用するのはよくあることですが、速度等の処理効率についてはどうなのでしょうか。

以下、筆者のチームが計測してみた結果を共有します。

評価対象は主要な有償データベースとオープンソースデータベースです。ローダーは各社データベースで通常ロードと高速ロードがある場合、それぞれ別に計測して記載しました。

Insertと単純READは「Waha! Transformer」を使用しています。ODBCによる書き込みなのですが、秘伝の(笑)高速書き込みアルゴリズムを使用しているため、生半可なアプリケーションより数十倍は高速です。
各種RDBMSの通常ロードよりInsert処理の方が速い事にご注目ください。

こうして計測してみると、さすがに有償データベースはオープンソースとは速度のレベルが違うようです。しかし、今回はデータ加工の中間データストアとしての利用パターンであり、大量データを一気に書き込む時間の比較ですので、OLTPのような使い方とは大きく異なる事を申し添えておきます。

中間データストアのデータベースに、有償データベースを使用するのはコスト上許されないということであれば、MySQLでMyISAMを使用するのがよいかもしれません。
しかし、有償データベースの多くは制限はあるものの無償版がありますので、利用実績のあるデータベースであれば、その無償版を使用するのも手かもしれませんね。

ただ、データを絞り込む程度では、中間データストアにデータベースを使用するのはあまり意味がありません。
後続処理がさまざまなビューでデータを参照したり、複雑なジョインをデータベースに任せたりする場合には有効ですが、一時的に貯めて一括処理するだけなら、CSVだけでも十分なのではないでしょうか。
ただしその際には、ETL機能がCSVを対象にした十分な変換・加工機能を持っていることが前提となります。

まとめますと、中間データストアの選択は、以下のように考えられます。

ETLに十分な加工機能があるなら、CSVファイルで保存
用途が限られるのであれば、無料のオープンソース
すでに使いこなしているなら、有償データベースの無償版
予算があれば有償データベース

選定時には、システムの規模、重要性、利用期間（短期、長期）などにも考慮が必要ですね。

さて、オマケですが、
中間データストアにMySQLを使用する場合、V5.1までのバージョンでは、「サーバーからクライアントへのデータ引き渡しがタイムアウトしたときのエラーが通知されない」という障害があります。
クエリーを出して、ODBC APIからデータを受け取る間になにか処理をしていて時間が空いた時に発生するのですが、この問題が発生すると、ODBCドライバーがキャッシュとして先行で受け取った分だけの中途半端なデータで処理が継続されてしまうため、致命的です。

この問題はmy.iniでパラメータ「net_write_timeout」の値を大きくすることで緩和されますが、エラーが通知されないため、もし現象が発生してデータが不完全になっても、それを知る手段がありません。
残念ながら現時点で、改善されたという文書は発見できていませんが、V5.5、V5.6では改善されているようなので、最新版のV5.6を使用する事で回避できるでしょう。

オープンソースは無償で使用出来て、シェアが大きければネット上に情報も多いのですが、このような問題が起きた場合にメーカー問い合わせができないところは、試行錯誤に時間を取られるところも見込んでおきましょう。