DataWorks:Pengendalian aliran sinkronisasi batch

Faktor-faktor berikut memengaruhi kecepatan sinkronisasi data:

Secara default, tugas Data Integration tidak dibatasi lajunya. Tugas berjalan dengan kecepatan tertinggi yang mungkin dalam batas konkurensi yang dikonfigurasi. Namun, kecepatan tinggi dapat memberikan tekanan berlebihan pada database produksi Anda. Data Integration menyediakan opsi pembatasan laju yang dapat Anda konfigurasi sesuai kebutuhan. Kami menyarankan agar Anda tidak mengatur batas kecepatan maksimum melebihi 30 MB/s. Contoh berikut menunjukkan cara mengonfigurasi pembatasan laju sebesar 1 MB/s di code editor.

"setting": {
      "speed": {
         "throttle": true, // Specifies whether to enable rate limiting.
        "mbps": 1, // The specific rate in MB/s.
      }
    }

• throttle dapat diatur ke true atau false:

  • Jika Anda mengatur throttle ke true, pembatasan laju diaktifkan. Anda harus menetapkan nilai spesifik untuk mbps. Jika Anda tidak menetapkan mbps, program akan gagal atau laju akan abnormal.

  • Jika Anda mengatur throttle ke false, pembatasan laju dinonaktifkan, dan pengaturan mbps diabaikan.

• Ukuran traffic adalah nilai yang diukur oleh Data Integration sendiri dan tidak merepresentasikan traffic NIC (network interface controller) aktual. Biasanya, traffic NIC adalah 1 hingga 2 kali lipat traffic channel. Inflasi traffic aktual bergantung pada serialisasi data dari sistem penyimpanan data tertentu.

• File tunggal semi-terstruktur tidak memiliki split key. Untuk beberapa file, Anda dapat mengatur batas laju pekerjaan untuk meningkatkan kecepatan sinkronisasi. Batas laju pekerjaan berkaitan dengan jumlah file.

  Misalnya, jika terdapat n file, batas laju pekerjaan maksimum yang dapat Anda tetapkan adalah n MB/s:

  • Jika Anda menetapkan batas ke n+1 MB/s, kecepatan sinkronisasi tetap n MB/s.

  • Jika Anda menetapkan batas ke n-1 MB/s, kecepatan sinkronisasi menjadi n-1 MB/s.

• Untuk database relasional, Anda harus menetapkan batas laju pekerjaan dan split key untuk membagi tabel berdasarkan batas laju tersebut. Database relasional biasanya hanya mendukung split key numerik. Namun, database Oracle mendukung split key numerik maupun string.

Pada halaman detail log tugas sinkronisasi data, Anda dapat menemukan entri log yang mirip dengan JobContainer - Job set Channel-Number to 2 channels. Nilai channels adalah konkurensi aktual tugas tersebut.

Dalam kelompok sumber daya eksklusif, penggunaan resource melibatkan hubungan antara konkurensi dengan CPU dan memori:

• Hubungan antara konkurensi dan penggunaan CPU

  Dalam kelompok sumber daya eksklusif, rasio konkurensi terhadap CPU adalah 1:0,5. Artinya, instance ECS dengan 4 vCPU dan memori 8 GiB menyediakan kuota konkurensi sebesar 8 untuk kelompok sumber daya eksklusifnya. Kelompok tersebut dapat menjalankan maksimal 8 tugas sinkronisasi offline dengan konkurensi 1, atau 4 tugas sinkronisasi offline dengan konkurensi 2.

  Jika konkurensi yang dibutuhkan oleh tugas baru yang dikirimkan ke kelompok sumber daya eksklusif lebih besar daripada kuota konkurensi tersisa kelompok tersebut, tugas baru harus menunggu. Tugas tersebut akan mulai berjalan setelah tugas-tugas yang sedang berjalan selesai dan kuota konkurensi tersisa mencukupi untuk tugas baru tersebut.

  Catatan

  Jika konkurensi yang ditetapkan untuk tugas baru melebihi kuota konkurensi maksimum kelompok sumber daya eksklusif, tugas tersebut akan menunggu resource tanpa batas. Misalnya, jika Anda mengirimkan tugas dengan konkurensi 10 ke kelompok sumber daya eksklusif pada instance ECS dengan 4 vCPU dan memori 8 GiB, tugas tersebut tidak akan pernah berjalan. Karena kelompok sumber daya mengalokasikan resource berdasarkan urutan pengiriman, tugas-tugas berikutnya juga akan terblokir.

• Hubungan antara konkurensi dan penggunaan memori

  Dalam kelompok sumber daya eksklusif, penggunaan memori untuk satu tugas dihitung sebagai Min{768 + (concurrency - 1) × 256, 8029} MB. Namun, Anda dapat mengganti hubungan ini dalam pengaturan tugas. Di code editor, atur path JSON $.setting.jvmOption dalam teks konfigurasi JSON.

  Untuk memastikan eksekusi tugas yang stabil, total memori yang digunakan oleh semua tugas yang sedang berjalan harus setidaknya 1 GB lebih kecil dari total memori semua mesin dalam kelompok sumber daya eksklusif. Jika kondisi ini tidak terpenuhi, mekanisme Linux OOM Killer dapat secara paksa menghentikan tugas-tugas tersebut.

  Catatan

  Jika Anda tidak menggunakan code editor untuk menambah memori tugas, Anda hanya perlu mempertimbangkan batas kuota konkurensi kelompok sumber daya eksklusif saat mengirimkan tugas.

Kecepatan baca dan tulis konkuren sangat bervariasi di antara sumber data yang berbeda. Tabel berikut mencantumkan kecepatan sinkronisasi rata-rata per konkurensi tunggal untuk sumber data khas dalam kelompok sumber daya eksklusif:

• Kecepatan rata-rata per konkurensi tunggal untuk berbagai Writer plug-in

  Writer	Average single-concurrency speed (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

• Kecepatan rata-rata per konkurensi tunggal untuk berbagai Reader plug-in

  Reader	Average single-concurrency speed (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