CData Sync V26.3 では 8 つの主要同期先を対象に、バルクロード処理のパフォーマンスが改善されました。対象は Databricks、Snowflake、Azure Synapse、Amazon Redshift、Google BigQuery、CSV、Avro、Parquet です。

特に効果が大きいのはカラム数の多いワイドテーブルで、検証環境では最大で約 2.2 倍の高速化を確認しています。

この改善はエンジン内部のバルクロード処理を最適化したものです。ジョブ側での設定変更や再設計は不要で、V26.3 へアップグレードするだけで既存ジョブにそのまま適用されます。

何が速くなったのか

今回の最適化が入ったのは、CData Sync がデータを一括で書き出す「バルクロード」フェーズです。対象となる同期先は以下の 8 つです。

• Databricks

• Snowflake

• Azure Synapse

• Amazon Redshift

• Google BigQuery

• CSV

• Avro

• Parquet

いずれもレコードをファイルやステージング領域へ一括書き出ししたうえで同期先にロードする方式を採っており、この書き出し処理を担うエンジン内部の実装が最適化の対象です。差分検知や CDC の仕組み自体には手が入っておらず、あくまで書き込みのボトルネックを解消する改善です。

ワイドテーブルで顕在化する書き込みコスト

カラム数の多いワイドテーブルでは、次のような理由で書き込み処理が重くなりがちでした。

CData Sync のバルクロード処理では、1 行を書き出すたびにカラムごとの型情報やメタデータを参照し、セルの値を文字列やバイト列に変換してファイルへ書き込みます。この処理は本来 1 行あたりカラム数に比例するコストで済むはずですが、従来の実装ではカラムメタデータの取得やバッファの確保を行ごと・カラムごとに毎回やり直していました。そのためカラム数が多いテーブルほど、行数の増加以上に処理時間が伸びる構造になっていました。

V26.3 での改善内容

V26.3 ではバルクロード処理の内部実装を見直し、行ごと・カラムごとに繰り返し発生していたオーバーヘッドを削減しました。いずれも「毎回作り直していたものを、事前に用意して使い回す」という方針にもとづく改善で、主な内容は次の 3 点です。

• カラム情報の事前計算 カラムごとの型情報を行ごとに取得し直すのではなく、あらかじめまとめて用意しておく方式に変更しました。

• 書き込み用領域の再利用 セルを処理するたびに一時領域を確保していた処理を、既存の領域を使い回す方式に変更しました。

• 変換データの直接書き込み 変換したデータをいったん別領域へコピーしてから書き込む手順を省き、書き込み先へ直接反映するようにしました。

こうした使い回しにより処理中に生成されるデータ量そのものが減るため、JVM の GC（ガベージコレクション）発生頻度の低下も確認されています。その結果、300 カラム規模のワイドテーブルを対象にした検証では、従来比で最大約 2.2 倍まで書き込み速度が伸びています（実際の改善幅は環境により変動します）。

なぜカラム数が多いほど高速化するのか

今回の改善は、1 行あたりに発生していたカラムごとの処理コスト（メタデータ取得、バッファ確保など）を削減するものです。削減されるコストはカラム数と行数の積にほぼ比例するため、カラム数が多いテーブルほど 1 行を処理するたびの削減量が積み上がり、全体としての短縮効果が大きくなります。

逆に言えば、カラム数が少ないテーブルでは 1 行あたりの削減量自体が小さいため、体感できる改善幅は相対的に小さくなります。数十カラム程度のテーブルでも改善は適用されますが、恩恵を強く受けるのは数百カラムのようなワイドテーブルを日常的に同期しているジョブです。

まとめ

CData Sync V26.3 では、主要な同期先を対象にバルクロード処理のパフォーマンスが改善されました。V26.3 へアップグレードするだけで既存ジョブに適用され、設定変更や再設計は必要ありません。

CData Sync の 30 日間無償トライアルはこちらからダウンロードいただけます。

使っていて気になった点やご不明な点があれば、お気軽にテクニカルサポートまでお問い合わせください。