DataWorks:バッチ同期のスロットル設定

以下は、データ同期速度に影響を与える主な要因です：

デフォルトでは、Data Integration のタスクはレート制限されません。タスクは、構成された同時実行数の上限内で可能な限り最高速度で実行されます。ただし、過度に高い速度は本番データベースに過大な負荷をかける可能性があります。Data Integration では、必要に応じて設定可能なレート制限機能を提供しています。最大速度制限は 30 MB/s を超えないよう設定することを推奨します。以下の例では、コードエディタで 1 MB/s のレート制限を構成する方法を示しています。

"setting": {
      "speed": {
         "throttle": true, // レート制限を有効にするかどうかを指定します。
        "mbps": 1, // MB/s 単位での具体的なレート。
      }
    }

• throttle は true または false のいずれかに設定できます：

  • throttle を true に設定すると、レート制限が有効になります。この場合、mbps に具体的な値を設定する必要があります。mbps を設定しないと、プログラムが失敗するか、レートが異常になります。

  • throttle を false に設定すると、レート制限は無効になり、mbps の設定は無視されます。

• トラフィックの測定値は Data Integration 自体が測定したものであり、実際のネットワークインターフェイスコントローラー（NIC）のトラフィックを表すものではありません。通常、NIC トラフィックはチャネルトラフィックの 1～2 倍になります。実際のトラフィックの膨張率は、特定のデータストレージシステムのデータシリアル化方式によって異なります。

• 半構造化の単一ファイルには分割キーがありません。複数のファイルの場合、ジョブ単位のレート制限を設定することで同期速度を向上させることができます。ジョブ単位のレート制限はファイル数に関係します。

  例：ファイル数が n 個の場合、設定可能な最大ジョブレート制限は n MB/s です：

  • n+1 MB/s に設定した場合、同期速度は n MB/s のままになります。

  • n−1 MB/s に設定した場合、同期速度は n−1 MB/s になります。

• リレーショナルデータベースの場合、テーブルをレート制限に基づいて分割するため、ジョブ単位のレート制限と分割キーの両方を設定する必要があります。リレーショナルデータベースでは通常、数値型の分割キーのみがサポートされます。ただし、Oracle データベースでは数値型および文字列型の分割キーの両方がサポートされます。

データ同期タスクログの詳細ページで、「JobContainer - Job set Channel-Number to 2 channels.」に類似したログエントリを確認できます。channels の値が、タスクの実際の同時実行数です。

専用リソースグループでは、リソース使用量は同時実行数と CPU・メモリの両方に関係します：

• 同時実行数と CPU 使用量の関係

  専用リソースグループでは、同時実行数と CPU の比率は 1:0.5 です。つまり、4 vCPU および 8 GiB メモリを備えた ECS インスタンスは、専用リソースグループに対して同時実行数クォータ 8 を提供します。同時実行数 1 のオフライン同期タスクを最大 8 件、または同時実行数 2 のオフライン同期タスクを最大 4 件実行できます。

  専用リソースグループに新しいタスクを送信した際に、そのタスクに必要な同時実行数がグループの残りクォータを超える場合、新しいタスクは待機状態になります。実行中のタスクが完了し、残りの同時実行数クォータが新しいタスクに十分になるまで、タスクは開始されません。

  説明

  新しいタスクの同時実行数設定が専用リソースグループの最大同時実行数クォータを超える場合、タスクはリソースを無期限に待機します。例：4 vCPU および 8 GiB メモリの ECS インスタンス上にある専用リソースグループに、同時実行数 10 のタスクを送信した場合、そのタスクは実行されません。リソースグループは送信順にリソースを割り当てるため、後続のタスクもブロックされます。

• 同時実行数とメモリ使用量の関係

  専用リソースグループでは、単一タスクのメモリ使用量は Min{768 + (同時実行数 − 1) × 256, 8029} MB で計算されます。ただし、タスク設定でこの関係をオーバーライドできます。コードエディタで、JSON 構成テキスト内の $.setting.jvmOption JSON パスを設定します。

  タスクの安定した実行を確保するためには、実行中のすべてのタスクの合計メモリ使用量が、専用リソースグループ内のすべてのマシンの合計メモリ量より少なくとも 1 GB 小さくなければなりません。この条件を満たさない場合、Linux OOM Killer メカニズムがタスクを強制終了する可能性があります。

  説明

  コードエディタを使用してタスクのメモリを増加させない場合、タスク送信時に専用リソースグループの同時実行数クォータ制限のみを考慮すればよいです。

異なるデータソース間では、同時読み取りおよび書き込み速度に大きな差異があります。以下の表は、専用リソースグループにおける代表的なデータソースの単一同時実行あたりの平均同期速度を示しています：

• 異なる Writer プラグインの単一同時実行あたりの平均速度

  Writer	単一同時実行あたりの平均速度 (KB/s)
  AnalyticDB for PostgreSQL	147.8
  AnalyticDB for MySQL	181.3
  ClickHouse	5259.3
  DataHub	45.8
  DRDS	93.1
  Elasticsearch	74.0
  FTP	565.6
  GDB	17.1
  HBase	2395.0
  hbase20xsql	37.8
  HDFS	1301.3
  Hive	1960.4
  HybridDB for MySQL	323.0
  HybridDB for PostgreSQL	116.0
  Kafka	0.9
  LogHub	788.5
  MongoDB	51.6
  MySQL	54.9
  ODPS	660.6
  Oracle	66.7
  OSS	3718.4
  OTS	138.5
  PolarDB	45.6
  PostgreSQL	168.4
  Redis	7846.7
  SQLServer	8.3
  Stream	116.1
  TSDB	2.3
  Vertica	272.0

• 異なる Reader プラグインの単一同時実行あたりの平均速度

  Reader	単一同時実行あたりの平均速度 (KB/s)
  AnalyticDB for PostgreSQL	220.3
  AnalyticDB for MySQL	248.6
  DRDS	146.4
  Elasticsearch	215.8
  FTP	279.4
  HBase	1605.6
  hbase20xsql	465.3
  HDFS	2202.9
  Hologres	741.0
  HybridDB for MySQL	111.3
  HybridDB for PostgreSQL	496.9
  Kafka	3117.2
  LogHub	1014.1
  MongoDB	361.3
  MySQL	459.5
  ODPS	207.2
  Oracle	133.5
  OSS	665.3
  OTS	229.3
  OTSStream	661.7
  PolarDB	238.2
  PostgreSQL	165.6
  RDBMS	845.6
  SQLServer	143.7
  Stream	85.0
  Vertica	454.3