DataWorks:Solusi untuk latensi tugas sinkronisasi real-time

Identifikasi apakah bottleneck berada di sumber atau tujuan

Buka tab Details untuk node tersebut di Operation Center (Real-Time Node O&M > Real-time Synchronization Nodes > klik nama node pada halaman Real Time DI).

Pada bagian Reader Statistics dan Writer Statistics, bandingkan nilai waitTimeWindow (5 min). Metrik ini menunjukkan durasi tunggu node—baik saat membaca dari sumber maupun menulis ke tujuan—selama 5 menit terakhir. Sisi dengan nilai lebih tinggi merupakan lokasi bottleneck.

Untuk informasi lebih lanjut tentang cara mengakses tampilan ini, lihat Mengelola tugas sinkronisasi real-time.

Node sinkronisasi real-time membaca dari sumber dan menulis ke tujuan secara berurutan. Jika proses penulisan lebih lambat daripada pembacaan, tujuan memberikan tekanan balik (backpressure) pada reader, sehingga memperlambat ingestion. Fokuskan investigasi pada sisi dengan nilai waitTimeWindow (5 min) yang lebih tinggi—di situlah bottleneck berasal.

Periksa adanya exception selama periode latensi

Pada tab Log panel yang sama, cari kata kunci berikut dalam rentang waktu ketika latensi melonjak:

• Error

• error

• Exception

• exception

• OutOfMemory

Jika entri log exception muncul selama periode latensi, lihat FAQ tentang sinkronisasi real-time untuk menentukan apakah mengoptimalkan konfigurasi node dapat menyelesaikan masalah tersebut.

Periksa error out of memory (OOM)

Pada tab Failover, tinjau apakah failover terjadi lebih dari sekali dalam rentang 10 menit. Frekuensi sebesar itu mengindikasikan bahwa node kehabisan memori.

Untuk mengonfirmasi penyebabnya, arahkan kursor ke event failover di kolom Failover Events, atau klik View Details di kolom Actions untuk melihat log lengkap sebelum failover. Cari OutOfMemory di salah satu lokasi tersebut. Jika error tersebut muncul, node memerlukan lebih banyak memori.

Tingkatkan ukuran memori menggunakan metode yang sesuai dengan cara pembuatan node:

Periksa adanya kesenjangan data atau batas throughput (sumber Kafka, DataHub, LogHub)

Untuk node yang membaca dari Kafka, DataHub, atau LogHub: setiap partisi atau shard dikonsumsi oleh satu thread tunggal. Jika sebagian besar data masuk terkonsentrasi hanya pada beberapa partisi atau shard, saluran tersebut menjadi bottleneck dan node tertinggal, terlepas dari jumlah thread paralel yang dikonfigurasi.

Diagnosis kesenjangan data:

Pada tab Details di bawah Reader Statistics, periksa metrik Total Bytes. Bandingkan dengan metrik yang sama untuk node lain yang berjalan normal pada sumber yang sama. Nilai yang jauh lebih tinggi menunjukkan bahwa partisi sumber node ini menerima data secara tidak proporsional lebih banyak.

Nilai Total Bytes bersifat kumulatif sejak offset awal node. Untuk node yang telah berjalan lama, angka ini mungkin tidak mencerminkan kesenjangan data saat ini. Dalam kasus tersebut, periksa metrik langsung di sistem sumber.

Jika kesenjangan data dikonfirmasi, perbaikan harus diterapkan di hulu—yaitu dengan menyeimbangkan ulang distribusi data di seluruh partisi atau shard pada topik Kafka, topik DataHub, atau Logstore LogHub. Menyesuaikan konfigurasi node itu sendiri tidak akan menyelesaikan masalah kesenjangan di sumber.

Diagnosis habisnya batas throughput:

Jika laju transmisi dari sistem hulu ke sumber, atau dari satu partisi/shard ke node, mencapai batas maksimum sistem sumber, tambahkan lebih banyak partisi atau shard.

Jika beberapa node sinkronisasi real-time membaca dari topik Kafka, topik DataHub, atau Logstore LogHub yang sama, periksa apakah total laju baca semua node melebihi batas sistem sumber.

Periksa adanya transaksi besar atau operasi DDL/DML massal (sumber MySQL)

Untuk node yang membaca dari MySQL: jika transaksi besar dikomit atau sejumlah besar operasi DDL atau bahasa manipulasi data (DML) dijalankan pada sumber, log biner tumbuh lebih cepat daripada yang dapat dikonsumsi oleh node, sehingga menyebabkan node tertinggal.

Contoh operasi yang mempercepat pertumbuhan log biner:

• Memperbarui nilai bidang di seluruh tabel besar

• Menghapus sejumlah besar baris

Diagnosis Penyebab:

Pada tab Details, periksa kecepatan sinkronisasi data:

• Kecepatan sinkronisasi yang tinggi mengonfirmasi bahwa volume log biner bertambah pesat.

• Jika kecepatan yang ditampilkan tidak terlalu tinggi, periksa log audit dan metrik log biner langsung di server MySQL untuk mendapatkan laju pertumbuhan log biner yang sebenarnya.

Kecepatan sinkronisasi yang ditampilkan pada tab Details mungkin meremehkan laju konsumsi log biner yang sebenarnya. Jika database atau tabel sumber tidak ditentukan dalam konfigurasi node, node melakukan filter data *setelah* membacanya—sehingga throughput baca untuk tabel-tabel tersebut tidak termasuk dalam kecepatan dan total byte yang ditampilkan.

Jika penyebabnya adalah transaksi besar atau perubahan massal sementara, tunggu hingga node berhasil mengejar ketinggalan. Setelah backlog data log biner diproses, latensi akan berkurang dengan sendirinya.

Periksa operasi flush berlebihan (tujuan MaxCompute dengan partisi dinamis)

Untuk node yang menulis ke MaxCompute dengan partisi dinamis berdasarkan nilai bidang: node mempertahankan serangkaian antrian tulis, satu untuk setiap nilai partisi unik yang ditemui dalam flush interval (default: 1 menit). Ukuran maksimum antrian secara default adalah 5.

Ketika jumlah nilai partisi berbeda dalam satu flush interval melebihi batas antrian, node memicu flush untuk semua data yang dibuffer. Flush yang sering terjadi secara signifikan mengurangi throughput tulis.

Diagnosis masalah:

Pada tab Log, cari:

uploader map size has reached uploaderMapMaximumSize

Jika pesan ini muncul, buka panel konfigurasi tujuan dan tingkatkan ukuran partition cache queue.

Tingkatkan jumlah thread paralel atau aktifkan mode eksekusi terdistribusi

Jika tidak ada penyebab sebelumnya yang berlaku dan latensi disebabkan oleh pertumbuhan trafik bisnis yang berkelanjutan, peningkatan jumlah thread paralel dapat menguranginya.

Panduan konfigurasi thread dan memori:

Selalu tingkatkan memori secara proporsional saat menambahkan thread. Gunakan rasio 4:1—misalnya, menggandakan jumlah thread memerlukan penggandaan alokasi memori.

Konfigurasikan thread paralel dan memori menggunakan metode yang sesuai dengan cara pembuatan node:

Mode eksekusi terdistribusi menghilangkan batas sumber daya mesin tunggal. Saat ini didukung untuk kombinasi berikut: