Topik ini menjelaskan cara memecahkan dan mengatasi masalah latensi pada tugas sinkronisasi real-time.
Identifikasi bottleneck: sumber atau tujuan
Untuk tugas sinkronisasi real-time di DataStudio, buka dan klik nama tugas untuk melihat detailnya. Untuk informasi selengkapnya, lihat Jalankan dan kelola tugas sinkronisasi real-time.
Pada detail eksekusi, periksa metrik Window Wait Time (5 min). Metrik ini menunjukkan waktu yang dihabiskan tugas untuk menunggu membaca dari sumber atau menulis ke tujuan selama lima menit terakhir. Metrik ini membantu Anda mengidentifikasi bottleneck dalam sinkronisasi data. Saat terjadi latensi, pihak dengan nilai metrik yang lebih tinggi biasanya merupakan bottleneck.
Periksa adanya exception sistem
Setelah mengidentifikasi bottleneck, buka tab Logs. Cari kata kunci seperti "Error", "error", "Exception", "exception", atau "OutOfMemory" untuk menemukan stack exception dari periode latensi tinggi. Jika Anda menemukan exception, gunakan detailnya dan rujuk Tangani error umum untuk melihat apakah mengoptimalkan konfigurasi tugas dapat mengatasi masalah tersebut.
Tugas sinkronisasi real-time membaca data dari satu sistem dan menuliskannya ke sistem lain. Jika penulisan data lebih lambat daripada pembacaan, sistem tujuan dapat memberikan backpressure ke sistem sumber, sehingga menyebabkan perlambatan. Artinya, bottleneck pada satu sistem dapat memicu exception di sistem lain. Utamakan penyelidikan exception pada sistem yang telah diidentifikasi sebagai bottleneck.
Kode berikut memberikan contoh khas stack trace exception:
java.lang.NullPointerException
at com.alibaba.streamx.core.util.EngineHelper.filterJobConfiguration(EngineHelper.java:31)
at com.alibaba.streamx.core.flink.trans.SinkFunctionAdaptor.open(SinkFunctionAdaptor.java:602)
at org.apache.flink.api.common.functions.util.FunctionUtils.openFunction(FunctionUtils.java:36)
at org.apache.flink.streaming.api.operators.AbstractUdfStreamOperator.open(AbstractUdfStreamOperator.java:102)
at org.apache.flink.streaming.api.operators.StreamSink.open(StreamSink.java:48)
at org.apache.flink.streaming.runtime.tasks.StreamTask.openAllOperators(StreamTask.java:439)
at org.apache.flink.streaming.runtime.tasks.StreamTask.invoke(StreamTask.java:288)
at org.apache.flink.runtime.taskmanager.Task.run(Task.java:747)
at java.lang.Thread.run(Thread.java:853)Periksa adanya error OOM yang sering terjadi
Pada detail tugas, buka tab Failover untuk memeriksa frekuensi failover, yang didefinisikan sebagai terjadi lebih dari sekali setiap 10 menit. Jika failover sering terjadi, periksa informasi exception untuk setiap kejadian tersebut. Jika Anda menemukan pesan yang mengandung kata kunci OutOfMemory, artinya tugas kekurangan memori dan mengalami masalah out-of-memory (OOM) yang berulang.
Untuk menambah memori, buka editor tugas dan tingkatkan nilai CU pada area Running Resources.
Periksa kesenjangan data sumber atau kebutuhan partisi
Jika sumbernya adalah Kafka, DataHub, atau LogHub dan langkah-langkah sebelumnya tidak menunjukkan adanya exception atau failover, periksa sistem sumber terhadap adanya data skew. Selain itu, periksa apakah trafik baca untuk partisi atau shard mencapai batas laju sinkronisasi.
Untuk sumber Kafka, DataHub, dan LogHub, setiap partisi atau shard hanya dapat dikonsumsi oleh satu thread paralel. Jika data terkonsentrasi pada beberapa partisi atau shard sementara yang lain hampir kosong, kesenjangan data ini dapat menciptakan bottleneck konsumsi dan menyebabkan latensi. Masalah ini tidak dapat diselesaikan dengan menyesuaikan pengaturan tugas. Anda harus mengatasi kesenjangan data pada aplikasi penghasil data hulu untuk sistem Kafka, DataHub, atau LogHub. Latensi akan teratasi begitu distribusi data menjadi seimbang.
Pada kotak dialog detail tugas, alihkan ke tab Running Information dan tinjau jumlah total byte untuk berbagai thread pembaca. Jika satu thread pembaca memiliki jumlah byte yang jauh lebih tinggi dibandingkan yang lain, kemungkinan besar terdapat kesenjangan data. Namun, jumlah total byte mencakup semua data yang diproses sejak offset terakhir yang diproses. Untuk tugas yang berjalan lama, metrik ini mungkin tidak mencerminkan kesenjangan data terkini. Anda juga harus memeriksa metrik pemantauan pada sistem sumber untuk memastikan apakah terjadi kesenjangan data.
Jika trafik data untuk satu partisi atau shard mencapai batasnya, Anda dapat mengatasi latensi dengan menambah jumlah partisi atau shard pada sistem sumber. Misalnya, kluster Kafka dapat memiliki batas laju baca yang dikonfigurasi untuk partisi, satu partisi DataHub memiliki laju baca maksimum 4 MB/s, dan satu shard LogHub memiliki laju baca maksimum 10 MB/s. Jika tugas sinkronisasi real-time melebihi batas kecepatan baca untuk satu partisi, tambahkan jumlah partisi atau shard pada sistem sumber untuk mengatasi latensi.
Jika beberapa tugas sinkronisasi real-time mengonsumsi data dari topik Kafka yang sama, topik DataHub, atau logstore LogHub, pastikan bahwa kecepatan baca gabungan semua tugas tidak melebihi batas sistem sumber.
Periksa MySQL terhadap transaksi besar atau perubahan yang sering
Untuk tugas sinkronisasi real-time dengan sumber MySQL, jika langkah-langkah sebelumnya tidak menunjukkan adanya exception atau failover, periksa apakah sistem sumber sedang memproses transaksi besar atau mengalami perubahan yang sering, seperti banyak operasi DML dan DDL. Aktivitas ini dapat menyebabkan log biner tumbuh lebih cepat daripada yang dapat dikonsumsi oleh tugas, sehingga menghasilkan latensi.
Misalnya, memperbarui bidang di seluruh tabel atau menghapus sejumlah besar data dapat menyebabkan pertumbuhan log biner yang cepat. Pada kotak dialog detail tugas, alihkan ke tab Running Information untuk melihat kecepatan sinkronisasi:
Kecepatan sinkronisasi yang tinggi menunjukkan bahwa log biner tumbuh dengan cepat.
Jika kecepatan sinkronisasi tidak tinggi, periksa statistik log biner dan log audit pada server MySQL untuk mengonfirmasi laju pertumbuhan aktual.
Kecepatan sinkronisasi mungkin tidak mencerminkan laju aktual konsumsi log biner MySQL oleh tugas. Jika suatu transaksi atau perubahan melibatkan database atau tabel yang tidak termasuk dalam konfigurasi tugas, tugas akan memfilter data tersebut setelah membacanya. Data yang difilter ini tidak termasuk dalam statistik kecepatan sinkronisasi atau volume data.
Jika Anda memastikan bahwa transaksi besar atau lonjakan sementara dalam perubahan menyebabkan latensi, tugas pada akhirnya akan mengejar ketinggalan setelah memproses backlog perubahan tersebut.
Periksa pergantian yang sering dalam partisi dinamis
Untuk tugas sinkronisasi real-time yang menulis ke MaxCompute, jika Anda memilih partisi dinamis berdasarkan konten bidang, pantau secara cermat kolom sumber yang dipetakan ke kolom partisi tabel MaxCompute. Dalam satu Flush Interval (default 1 menit) yang dikonfigurasi pada panel Basic Configurations, jumlah nilai unik dalam kolom ini harus rendah.
Dalam interval flush, data yang ditujukan untuk tabel MaxCompute disimpan sementara dalam satu set antrian di dalam tugas sinkronisasi real-time. Setiap antrian menyimpan data untuk satu operasi penulisan MaxCompute. Jumlah maksimum antrian default adalah lima. Jika jumlah nilai unik dari kolom partisi sumber melebihi batas ini dalam interval flush yang dikonfigurasi, flush segera untuk semua data yang disimpan sementara akan dipicu. Operasi flush yang sering sangat menurunkan performa penulisan.
Anda harus memastikan apakah flush yang sering dipicu karena antrian cache partisi tabel MaxCompute telah penuh. Pada kotak dialog detail tugas, alihkan ke tab Logs dan cari pesan uploader map size has reached uploaderMapMaximumSize.
Tingkatkan konkurensi atau aktifkan eksekusi terdistribusi
Jika langkah-langkah sebelumnya menunjukkan bahwa latensi disebabkan oleh peningkatan trafik sumber dan bukan exception, Anda dapat menguranginya dengan meningkatkan konkurensi tugas.
Saat Anda meningkatkan konkurensi, Anda juga harus menambah memori tugas. Sebagai aturan umum, tambahkan 1 GB memori untuk setiap empat thread paralel tambahan.
Konfigurasikan konkurensi dan memori tugas sebagai berikut:
Untuk tugas sinkronisasi real-time ETL satu-tabel-ke-satu-tabel yang dibuat di DataStudio, klik Basic Configurations di sebelah kanan untuk mengonfigurasi konkurensi dan memori tugas. Pada panel Basic Settings, Anda dapat mengonfigurasi parameter seperti Synchronization Method, sakelar distributed execution mode, resource group, CUs, dan number of parallel threads. Perluas Advanced Settings untuk mengonfigurasi flush interval (default: 60000 ms) dan MaxCompute Channel Resources. Misalnya, pilih Streaming Tunnel dan atur slot number.
Untuk tugas DataStudio lainnya, seperti migrasi database ke DataHub, konfigurasikan jumlah thread paralel pada langkah Configure Resource dan memori pada panel Basic Configurations.
Untuk tugas solusi sinkronisasi, Anda dapat mengonfigurasi jumlah thread paralel dan memori pada langkah Configure Resource.
Jika mode eksekusi terdistribusi dinonaktifkan, atur jumlah thread paralel menjadi 32 atau kurang. Mengatur jumlah di atas 20 dapat menyebabkan latensi karena bottleneck resource mesin tunggal. Untuk saluran tertentu, Anda dapat mengaktifkan mode eksekusi terdistribusi untuk meningkatkan performa. Saluran yang mendukung mode eksekusi terdistribusi tercantum dalam tabel berikut.
Jenis tugas | Sumber | Tujuan |
DataStudio ETL task | Kafka | MaxCompute |
DataStudio ETL task | Kafka | Hologres |