さまざまなシナリオに応じたデータインポートのチューニング方法 - AnalyticDB

AnalyticDB for MySQL は、さまざまなシナリオに対応する多様なデータインポート方法を提供しています。しかし、データインポートのパフォーマンスは、不適切なテーブルモデリングによるデータスキューや、最適でないインポート設定による非効率なリソース使用などの要因によって影響を受ける可能性があります。このトピックでは、さまざまなシナリオでデータインポートのパフォーマンスをチューニングする方法について説明します。

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

分散キーの確認

分散キーは、データをシャード間にどのように分散させて同時インポートを行うかを決定します。データが均等に分散されていない場合、より多くのデータを受け取ったシャードがボトルネックとなり、データスキューを引き起こし、インポートジョブ全体を遅くする原因となります。これを避けるために、インポート中にデータが均等に分散されるようにしてください。分散キーの選択方法の詳細については、「分散キーの選択」をご参照ください。

分散キーが適切かどうかを確認します：

データをインポートする前に、ビジネスロジックに基づいて選択した分散キーを評価します。たとえば、Lineitem テーブルで l_discount 列を分散キーとして選択した場合、そのカーディナリティが低い (個別値が 11 個のみ) ため、深刻なデータスキューが発生します。同じ割引値を持つすべてのデータが同じシャードに送信され、ボトルネックが生じ、パフォーマンスが低下します。オーダー ID は一意であり、データをより均等に分散させるため、l_orderkey 列の方がより良い選択です。
データをインポートした後、データモデリング診断レポートで分散フィールドの偏りが示された場合、分散キーが不均等なデータ分散を引き起こしています。これらの診断の表示方法の詳細については、「ストレージ診断」をご参照ください。

パーティションキーの確認

INSERT OVERWRITE SELECT を使用すると、インポートされたパーティションは、ターゲットテーブル内の同じ名前の既存のパーティションを上書きします。各シャード内で、データはパーティションキーに基づいてそれぞれのパーティションにインポートされます。パフォーマンスを低下させる外部ソートプロセスをトリガーしないように、一度に多くのパーティションをインポートしないでください。パーティションキーの選択方法の詳細については、「パーティションキーの選択」をご参照ください。

パーティションキーが適切かどうかを確認します：

データをインポートする前に、ビジネスニーズとデータ分散に基づいてパーティションキーを評価します。たとえば、Lineitem テーブルを 7 年間の l_shipdate 列でパーティション分割する場合、日単位でパーティション分割すると 2,000 以上のパーティションが作成され、非効率です。月単位または年単位でのパーティション分割がより適切なアプローチです。
データをインポートした後、データモデリング診断レポートでパーティション数が不適切であると示された場合、そのパーティションキーは不適切です。これらの診断の表示方法の詳細については、「パーティションテーブルの診断」をご参照ください。

インデックスの確認

デフォルトでは、AnalyticDB for MySQL はテーブル作成時にすべての列にインデックスを作成します。ワイドテーブルに全列インデックスを構築すると、リソースを大量に消費します。ワイドテーブルにデータをインポートする場合は、プライマリキーインデックスを使用してください。プライマリキーインデックスは重複排除に使用されますが、プライマリキーに多くの列を使用すると、このプロセスが遅くなる可能性があります。プライマリキーの選択方法の詳細については、「プライマリキーの選択」をご参照ください。

インデックスが適切かどうかを確認します：

オフラインインポートのシナリオでは、オフラインコンピューティングジョブがすでにデータの重複排除を行っているため、通常、プライマリキーインデックスは不要です。
監視情報 > テーブル情報統計 タブで、テーブルデータ、インデックスデータ、およびプライマリキーインデックスデータのサイズを確認します。インデックスデータのサイズがテーブルデータのサイズを超える場合は、長い文字列値を持つ列がないか確認してください。これらの列にインデックスを作成すると、時間がかかり、大量のストレージを消費します。これらのインデックスは削除できます。詳細については、「ALTER TABLE」をご参照ください。

説明
プライマリキーインデックスは削除できません。テーブルを再構築する必要があります。

ヒントを追加してインポートを高速化

インポートステートメントに direct_batch_load=true ヒントを追加することで、インポートを高速化できます。

説明

このヒントは、V3.1.5 以降のエラスティック Data Warehouse Edition クラスターでのみサポートされています。パフォーマンスが大幅に向上しない場合は、チケットを起票。

例：

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

エラスティックインポートによるインポートの高速化

説明

エラスティックインポート機能は、カーネルバージョンが 3.1.10.0 以降のクラスターでのみ利用可能です。
この機能は、ジョブリソースグループを持つ Enterprise Edition、Basic Edition、および Data Lakehouse Edition のクラスターでサポートされています。
エラスティックインポートは、MaxCompute のデータと、Object Storage Service (OSS) の CSV、Parquet、または ORC 形式のデータのみをサポートしています。
エラスティックインポートを使用する際は、キューイング時間の長期化、実行の遅延、およびジョブの失敗を防ぐために、ジョブリソースグループに十分なリソースがあることを確認してください。

エラスティックインポート機能を使用すると、複数のインポートジョブを同時に実行できます。また、より多くのリソースを割り当てることで、単一のインポートジョブを高速化することもできます。詳細については、「データインポート方法」をご参照ください。

例：

/*+ 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] パラメーターの値に正比例します。[Expected Maximum Concurrency] を可能な限り大きく設定することを推奨します。
  
  重要
  期待最大同時実行数の値を高くすると、DataWorks のリソース消費量が増加します。ニーズに合った値を選択してください。
- 同期パフォーマンスを向上させるには、[Distributed Execution] を有効にします。

一般的な問題と解決策

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

解決策：書き込みごとのデータレコード数 と [Expected Maximum Concurrency] の値を大きくします。データインポートのパフォーマンスは、インポートの負荷が増加するにつれて直線的に向上します。
ターゲットテーブルにデータスキューが存在する場合、一部のクラスターノードが過負荷になり、インポートパフォーマンスが低下します。この場合、CPU とディスク I/O の使用率は低いですが、書き込み応答時間は長くなります。診断の最適化 > データモデリング診断 ページで、偏りのあるテーブルを特定できます。

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

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

クライアント側の最適化

アプリケーションでのデータバッチ処理
- JDBC プログラムを使用してデータをインポートする場合、バッチインポートを使用することで、ネットワークと接続のオーバーヘッドを削減できます。特別な要件がない限り、単一行のインポートは避けてください。
- バッチサイズは 2048 レコードにすることを推奨します。単一のレコードが大きい場合は、合計バッチサイズを 8 MB 以下に保ってください。バッチあたりのレコード数は、8 MB を単一レコードのサイズで割ることで計算できます。大きすぎるバッチは、フロントエンドノードで過剰なメモリを消費し、インポートパフォーマンスを低下させる可能性があります。
アプリケーションの同時実行の設定
- アプリケーションからデータをインポートする場合、複数の同時実行スレッドを使用してください。単一のスレッドではクライアントリソースを完全には活用できず、クライアント側のデータ処理とバッチ処理のために、データベースのインポート速度に追いつけないことがよくあります。同時インポートにより、速度を大幅に向上させることができます。
- 最適な同時実行レベルは、バッチ処理、データソース、クライアントマシンの負荷などの要因によって異なります。単一の最適な値はありません。ワークロードに最適な同時実行数を見つけるためにテストを行ってください。インポート速度が期待を下回る場合は、同時実行数を 2 倍にしてみてください。その後速度が低下した場合は、徐々に減らして最適な設定を見つけてください。

一般的な問題と解決策

カスタムプログラムから AnalyticDB for MySQL にデータをインポートする際にパフォーマンスが低い場合は、まずクライアント側のパフォーマンスボトルネックを確認してください。

データソースが十分な速度でデータを提供できることを確認してください。データが他のシステムやファイルから提供される場合は、クライアントでの出力ボトルネックを確認してください。
データ処理速度を確認し、データの生成と消費が同期していること、および AnalyticDB for MySQL へのインポートを待機している十分なデータがあることを確認してください。
クライアントマシンの負荷をチェックして、CPU やディスク I/O などのシステムリソースが十分であることを確認してください。