AnalyticDB:データインポートパフォーマンスの最適化

外部テーブルインポートの最適化

SUBMIT JOB /*+ direct_batch_load=true*/INSERT OVERWRITE adb_table
SELECT * FROM adb_external_table;

/*+ elastic_load=true, elastic_load_configs=[adb.load.resource.group.name=resource_group]*/
submit job insert overwrite adb_table select * from adb_external_table;

DataWorks データインポートの最適化

ジョブ設定の最適化

• 書き込みあたりのデータレコード の最適化

  このパラメーターは、各インポートのバッチサイズを指定します。ほとんどの場合、デフォルト値の 2048 を維持することを推奨します。

  ただし、単一のレコードが 512 KB のように大きい場合は、このパラメーターを 16 に設定することを検討してください。これにより、バッチサイズが 8 MB 未満に保たれ、フロントエンドノードでメモリ使用量が多くなるのを防ぎます。

• チャネル制御の最適化

  • データ同期のパフォーマンスは、[タスクの最大同時実行数] パラメーターの値に正比例します。[タスクの最大同時実行数]をできるだけ大きくすることを推奨します。

    重要

    [Expected Maximum Concurrency] の値を大きくすると、より多くの DataWorks リソースを消費します。ニーズに合った値を選択してください。

  • 同期パフォーマンスを向上させるには、[分散処理能力]を有効にしてください。

一般的な問題と解決策

• クライアントがデータを送信する速度が遅すぎる場合、クラスターの CPU 使用率、ディスク I/O、書き込み応答時間も低くなります。データベースサーバーはクライアントから送信されたデータを処理できますが、受信データ量が少ないため、書き込み TPS が予想よりも低くなります。

  解決策: [書き込みごとのデータレコード数] と タスクの最大同時実行数 の値を大きくします。データインポートのパフォーマンスは、インポートの負荷が増加するにつれて線形に向上します。

• ターゲットテーブルにデータスキューが存在する場合、一部のクラスターノードが過負荷になり、インポートのパフォーマンスが低下します。この場合、CPU とディスク I/O の使用率は低いですが、書き込み応答時間は長くなります。診断の最適化 > データモデリング診断 ページで、スキューのあるテーブルを特定できます。

  解決策：テーブルスキーマを再設計してから、データを再インポートしてください。詳細については、「テーブルスキーマ設計」をご参照ください。

JDBC データインポートの最適化

クライアント側の最適化

• アプリケーションでのデータのバッチ処理

  • JDBC プログラムを使用してデータをインポートする場合は、バッチインポートを使用してネットワークと接続のオーバーヘッドを削減してください。特定の要件がない限り、単一行のインポートは避けてください。

  • バッチサイズは 2048 レコードを推奨します。単一のレコードが大きい場合は、バッチの合計サイズを 8 MB 未満に保ってください。8 MB を単一レコードのサイズで割ることで、バッチあたりのレコード数を計算できます。バッチが大きすぎると、フロントエンドノードで過剰なメモリを消費し、インポートのパフォーマンスが低下する可能性があります。

• アプリケーションの同時実行数の設定

  • アプリケーションからデータをインポートする場合は、複数の同時スレッドを使用してください。単一のスレッドではクライアントリソースを十分に活用できず、クライアント側でのデータ処理とバッチ処理のため、データベースのインポート速度に追いつけないことがよくあります。同時インポートにより、速度を大幅に向上させることができます。

  • 最適な同時実行レベルは、バッチ処理、データソース、クライアントマシンの負荷などの要因によって異なります。単一の最適値はありません。ワークロードに最適な同時実行数を見つけるためにテストしてください。インポート速度が予想を下回る場合は、同時実行数を 2 倍にしてみてください。速度が低下した場合は、徐々に減らして最適な設定を見つけてください。

一般的な問題と解決策