DataWorks:オフライン同期の高速化またはスロットリング

次の要因がデータ同期速度に影響します:

デフォルトでは、Data Integration の同期タスクはスロットリングされません。 タスクは、構成された同時実行数制限内で可能な限り最高の速度で実行されます。 ただし、高速化するとデータベースに過度のストレスがかかり、他の本番サービスに影響を与える可能性があります。 Data Integration は、必要に応じて構成できるスロットリングオプションを提供します。 スロットリングを有効にした後、最大速度を 30 MB/s 以下に設定することをお勧めします。 次のコードは、コードエディタでスロットリングを構成して帯域幅制限を 1 MB/s に設定する方法を示しています。

"setting": {
      "speed": {
         "throttle": true // スロットリングを有効にします。
        "mbps": 1,　// 特定のレート。
      }
    }

• 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 の関係

  専用リソースグループでは、vCPU と同時実行数の比率は 1:2 です。 たとえば、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 を設定します。

  実行中のすべてのタスクが使用する合計メモリが、専用リソースグループ内のすべてのマシンの合計メモリより少なくとも 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