DataWorks:FAQ sinkronisasi batch

• Jika pengujian konektivitas jaringan sebelumnya berhasil, jalankan kembali pengujian tersebut. Verifikasi bahwa grup sumber daya masih dapat terhubung ke database dan konfigurasi database tidak berubah.

• Verifikasi bahwa tugas menggunakan grup sumber daya yang sama dengan yang lolos pengujian konektivitas jaringan.

  Untuk memeriksa grup sumber daya yang digunakan oleh tugas:

  • Jika tugas dijalankan pada grup sumber daya default, log berisi informasi berikut:running in Pipeline[basecommon_ group_xxxxxxxxx]

  • Jika tugas dijalankan pada grup sumber daya eksklusif untuk Integrasi Data, log berisi informasi berikut:running in Pipeline[basecommon_S_res_group_xxx]

  • Jika tugas dijalankan pada grup sumber daya Serverless, log berisi informasi berikut:running in Pipeline[basecommon_Serverless_res_group_xxx]

• Jika tugas terjadwal gagal secara intermiten di pagi hari tetapi berhasil saat dijalankan ulang, periksa beban database pada saat error terjadi.

Tugas sinkronisasi batch dapat gagal secara intermiten jika konfigurasi daftar putih alamat IP tidak lengkap. Verifikasi bahwa daftar putih alamat IP database telah dikonfigurasi sepenuhnya.

Jika Anda menggunakan grup sumber daya eksklusif untuk Integrasi Data:

• Jika Anda telah menambahkan alamat IP dari elastic network interfaces (ENIs) grup sumber daya eksklusif Anda untuk Integrasi Data ke daftar putih alamat IP sumber data, Anda harus memperbarui daftar putih tersebut dengan alamat IP ENI baru saat memperluas kapasitas grup sumber daya.

• Untuk menghindari pembaruan daftar putih setelah memperluas kapasitas, kami menyarankan agar Anda menambahkan seluruh Blok CIDR dari vSwitch untuk grup sumber daya eksklusif Anda untuk Integrasi Data ke daftar putih alamat IP database. Untuk informasi lebih lanjut, lihat Konfigurasi daftar putih alamat IP.

Jika Anda menggunakan grup sumber daya Serverless, lihat Konfigurasi daftar putih alamat IP untuk memverifikasi konfigurasi daftar putih dan memastikan pengaturan jaringan Anda benar.

Jika daftar putih alamat IP telah dikonfigurasi dengan benar, periksa apakah beban database yang tinggi mengganggu koneksi.

• Penyebab:

  Jumlah thread paralel yang ditentukan melebihi sumber daya yang tersedia.

• Solusi:

  Kurangi jumlah thread paralel untuk tugas sinkronisasi batch.

  • Jika Anda mengonfigurasi tugas sinkronisasi batch di antarmuka tanpa kode, kurangi parameter Expected Maximum Concurrency di bagian kebijakan kontrol channel. Untuk informasi lebih lanjut, lihat Konfigurasi tugas menggunakan antarmuka tanpa kode.

  • Jika Anda mengonfigurasi tugas sinkronisasi batch dalam mode skrip, kurangi parameter concurrent di bagian kebijakan kontrol channel skrip Anda. Untuk informasi lebih lanjut, lihat Konfigurasi tugas dalam mode skrip.

Untuk mengatasi masalah ini, lakukan salah satu atau beberapa hal berikut:

1. Jika konfigurasi reader atau writer mencakup parameter batchsize atau maxfilesize, kurangi nilainya.

   Untuk memeriksa apakah reader atau writer Anda mendukung parameter ini, lihat Sumber data, reader, dan writer yang didukung dan klik reader atau writer tertentu untuk melihat parameternya.

2. Kurangi jumlah thread paralel.

   • Jika Anda mengonfigurasi tugas sinkronisasi batch di antarmuka tanpa kode, kurangi parameter Expected Maximum Concurrency di bagian kebijakan kontrol channel. Untuk informasi lebih lanjut, lihat Konfigurasi tugas menggunakan antarmuka tanpa kode.

   • Jika Anda mengonfigurasi tugas sinkronisasi batch dalam mode skrip, kurangi parameter concurrent di bagian kebijakan kontrol channel skrip Anda. Untuk informasi lebih lanjut, lihat Konfigurasi tugas dalam mode skrip.

3. Jika Anda menyinkronisasi file, seperti objek Object Storage Service (OSS), baca lebih sedikit file dalam setiap tugas.

4. Di bagian Running Resources konfigurasi tugas, tingkatkan Resource Usage (CU). Atur nilai CU dengan hati-hati untuk menghindari dampak pada tugas lain yang sedang berjalan.

• Gejala: Pesan error berikut dikembalikan: Error updating database. Cause: com.mysql.jdbc.exceptions.jdbc4.MySQLIntegrityConstraintViolationException: Duplicate entry 'cfc68cd0048101467588e97e83ffd7a8-0' for key 'uk_uk_op'.

• Penyebab: Integrasi Data tidak mengizinkan beberapa instans dari node yang sama berjalan secara konkuren. Dengan kata lain, beberapa instans tugas sinkronisasi yang memiliki konfigurasi JSON yang sama tidak dapat berjalan secara bersamaan. Misalnya, untuk tugas sinkronisasi yang dijadwalkan berjalan setiap 5 menit, keterlambatan hulu dapat menyebabkan instans yang dijadwalkan pukul 00:00 dan instans yang dijadwalkan pukul 00:05 keduanya dimulai pada pukul 00:05. Konflik ini mencegah salah satu instans dimulai. Masalah ini juga dapat terjadi jika Anda mengisi ulang data untuk suatu instans atau menjalankannya ulang saat instans tersebut sedang berjalan.

• Solusi: Atur waktu mulai instans agar tidak bersamaan. Untuk tugas tingkat jam atau menit, konfigurasikan dependensi mandiri sehingga instans hanya dimulai setelah instans dari siklus sebelumnya selesai. Di DataWorks (klasik), lihat dependensi mandiri. Di DataWorks (baru), lihat dependensi lintas siklus.

• Gejala: Tugas sinkronisasi batch gagal dengan pesan error: MongoDBReader$Task - operation exceeded time limitcom.mongodb.MongoExecutionTimeoutException: operation exceeded time limit.

• Penyebab: Tugas menarik jumlah data yang berlebihan selama pemuatan penuh.

• Solusi:

  • Tingkatkan konkurensi.

  • Kurangi nilai BatchSize.

  • Tambahkan parameter cursorTimeoutInMs ke pengaturan reader dan atur ke nilai yang lebih besar, seperti 3.600.000 ms.

• Error baca

  • Gejala:

    Saat Anda membaca data, error berikut dilaporkan: Communications link failure The last packet successfully received from the server was 7,200,100 milliseconds ago. The last packet sent successfully to the server was 7,200,100 milliseconds ago. - com.mysql.jdbc.exceptions.jdbc4.CommunicationsException: Communications link failure

  • Penyebab:

    Eksekusi kueri SQL yang lambat di database menyebabkan timeout baca MySQL.

  • Solusi:

    • Periksa apakah klausa WHERE dikonfigurasi dan pastikan kolom yang difilter diindeks.

    • Periksa apakah tabel sumber berisi volume data yang besar. Jika demikian, pertimbangkan untuk membagi tugas menjadi beberapa tugas yang lebih kecil.

    • Periksa log untuk mengidentifikasi pernyataan SQL yang menyebabkan kemacetan, dan konsultasikan dengan administrator basis data Anda untuk menyelesaikan masalah tersebut.

• Error tulis

  • Gejala:

    Saat menulis data, tugas gagal dengan error berikut: Caused by: java.util.concurrent.ExecutionException: ERR-CODE: [TDDL-4614][ERR_EXECUTE_ON_MYSQL] Error occurs when execute on GROUP 'xxx' ATOM 'dockerxxxxx_xxxx_trace_shard_xxxx': Communications link failure The last packet successfully received from the server was 12,672 milliseconds ago. The last packet sent successfully to the server was 12,013 milliseconds ago. More...

  • Penyebab:

    Kueri lambat mengakibatkan timeout soket. Default socketTimeout untuk koneksi TDDL adalah 12 detik. Jika pernyataan SQL memerlukan waktu lebih dari 12 detik untuk dieksekusi di server MySQL dan mengembalikan hasil, TDDL melaporkan error 4614. Error ini dapat terjadi secara intermiten dengan volume data besar atau saat server sibuk.

  • Solusi:

    • Jalankan ulang tugas sinkronisasi setelah kinerja database stabil.

    • Hubungi administrator basis data Anda untuk menyesuaikan pengaturan timeout.

Penyebab 2: Menunggu sumber daya runtime Integrasi Data

Solusi 2: Jika log menunjukkan status WAIT yang berkepanjangan, grup sumber daya eksklusif untuk Integrasi Data tidak memiliki slot konkuren yang cukup untuk menjalankan tugas. Untuk detail lebih lanjut tentang penyebab dan solusi, lihat Mengapa tugas Integrasi Data selalu menunjukkan status 'wait'?.

• Contoh skenario

  Contoh pernyataan SQL:

  SELECT bid,inviter,uid,createTime FROM `relatives` WHERE createTime>='2016-10-2300:00:00' AND reateTime<'2016-10-24 00:00:00';

  Kueri dimulai pada 2016-10-25 11:01:24.875 dan mulai mengembalikan hasil pada 2016-10-25 11:11:05.489. Tugas menunggu database mengembalikan hasil kueri, menyebabkan penundaan signifikan sebelum MaxCompute dapat melanjutkan.

• Penyebab

  Kolom createTime yang digunakan dalam klausa WHERE tidak diindeks, yang memaksa pemindaian tabel penuh.

• Solusi

  Gunakan kolom yang diindeks dalam klausa WHERE untuk meningkatkan kinerja. Jika perlu, tambahkan indeks ke kolom tersebut.

Untuk versi sebelumnya dari Pengembangan Data:

Di DataStudio, Anda dapat mengubah grup sumber daya untuk debugging tugas sinkronisasi batch di halaman detailnya. Di Operation Center, Anda dapat mengubah grup sumber daya Integrasi Data untuk eksekusi terjadwal. Untuk detailnya, lihat Ganti grup sumber daya Integrasi Data.

Untuk versi baru Pengembangan Data:

Di DataStudio, Anda dapat mengubah grup sumber daya untuk debugging tugas Integrasi Data. Di Operation Center, Anda dapat mengubah grup sumber daya Integrasi Data untuk eksekusi terjadwal. Untuk detailnya, lihat O&M grup sumber daya.

Catatan data dianggap sebagai dirty data jika gagal ditulis ke sumber data tujuan karena error.

Tugas menghitung catatan dirty data saat berjalan. Jika jumlah ini melebihi ambang batas yang dikonfigurasi, tugas berhenti segera.

• Retensi data: Tujuan mempertahankan semua data yang berhasil ditulis sebelum tugas berhenti. Sistem tidak melakukan rollback.

• Kebijakan toleransi nol: Jika Anda menetapkan ambang batas dirty data ke 0, tugas gagal dan berhenti segera setelah mendeteksi catatan dirty data pertama.

• Gejala:

  Jika data Anda mencakup emoji, error dirty data serupa berikut dapat terjadi selama sinkronisasi: [13350975-0-0-writer] ERROR StdoutPluginCollector - Dirty data {"exception":"Incorrect string value: '\\xF0\\x9F\\x98\\x82\\xE8\\xA2...' for column 'introduction' at row 1","record":[{"byteSize":8,"index":0,"rawData":9642,"type":"LONG"}],"type":"writer"} .

• Penyebab yang mungkin:

  • Encoding database bukan utf8mb4, yang diperlukan untuk menyinkronisasi emoji dengan benar.

  • Data sumber itu sendiri berisi karakter rusak.

  • Format encoding database berbeda dari format encoding klien.

  • Encoding browser berbeda dari encoding database atau klien, yang menyebabkan kegagalan pratinjau atau karakter rusak.

• Solusi:

  Pilih solusi berdasarkan akar penyebabnya:

  • Jika data sumber Anda berisi karakter rusak, perbaiki data sumber terlebih dahulu, lalu jalankan tugas sinkronisasi batch.

  • Jika database dan klien menggunakan format encoding yang berbeda, konfigurasikan agar menggunakan format yang sama.

  • Jika encoding browser berbeda, atur agar sesuai dengan encoding database dan klien sebelum Anda mempratinjau data.

  Anda juga dapat mencoba hal berikut:

  1. Untuk sumber data yang ditambahkan melalui URL JDBC, tambahkan pengaturan utf8mb4 ke URL: jdbc:mysql://xxx.x.x.x:3306/database?com.mysql.jdbc.faultInjection.serverCharsetIndex=45

  2. Untuk sumber data yang ditambahkan dalam mode instans Alibaba Cloud, tambahkan berikut ke nama database: database?com.mysql.jdbc.faultInjection.serverCharsetIndex=45.

  3. Ubah encoding database ke utf8mb4. Misalnya, ubah encoding database untuk instans ApsaraDB RDS di konsol ApsaraDB RDS.

     Catatan

     Untuk mengatur format encoding untuk sumber data ApsaraDB RDS, jalankan set names utf8mb4. Untuk melihat format encoding database ApsaraDB RDS, jalankan show variables like 'char%'.

Saat DataWorks membuat tabel tujuan, hanya nama kolom, tipe data, dan komentar dari tabel sumber yang dipertahankan. Properti lain, seperti nilai default dan batasan (termasuk batasan not-null dan indeks), tidak dipertahankan.

Tidak, kunci utama komposit tidak dapat digunakan sebagai shard key untuk tugas sinkronisasi batch.

Jika Anda menemukan masalah kualitas data setelah sinkronisasi data, lihat Troubleshooting masalah kualitas data dalam sinkronisasi offline.

T: Bagaimana cara mengatasi error "Task have SSRF attacks"?

Penyebab: Untuk keamanan, DataWorks memblokir tugas dari penggunaan alamat IP publik untuk mengakses alamat jaringan internal. Kontrol ini dipicu jika URL dalam konfigurasi plugin, seperti HTTP Reader, mengarah ke alamat IP pribadi atau nama domain VPC.

Pendekatan yang direkomendasikan:

• Jangan gunakan alamat IP pribadi, seperti 10.x.x.x dan 192.168.x.x, dalam konfigurasi Anda.

• Akses sumber data internal Anda secara aman dengan menggunakan grup sumber daya Serverless (direkomendasikan) atau grup sumber daya eksklusif untuk Integrasi Data dan mengonfigurasi konektivitas VPC.

Solusi: Untuk menjalankan tugas pada sumber data internal, gunakan grup sumber daya Serverless (direkomendasikan) atau grup sumber daya eksklusif untuk Integrasi Data alih-alih grup sumber daya publik.

Beralihlah ke mode skrip untuk tugas sinkronisasi dan tambahkan konfigurasi berikut di bawah kunci common di halaman konfigurasi tugas:

"common": {
  "column": {
    "dateFormat": "yyyyMMdd",
    "datetimeFormatInNanos": "yyyyMMdd HH:mm:ss.SSS"
  }
}

Parameter:

• dateFormat: Menentukan format teks untuk nilai DATE sumber, yang tidak mencakup jam, menit, atau detik.

• datetimeFormatInNanos: Menentukan format teks untuk nilai DATETIME atau TIMESTAMP sumber. Format ini mendukung presisi milidetik.

1. Anda dapat memasukkan konstanta. Nilainya harus diapit tanda kutip tunggal, seperti 'abc' atau '123'.

2. Anda dapat menggunakan parameter penjadwalan, seperti '${bizdate}'. Untuk informasi lebih lanjut, lihat Format yang Didukung untuk Parameter Penjadwalan.

3. Anda dapat memasukkan kolom kunci partisi untuk disinkronisasi, seperti pt.

4. Jika nilai yang Anda masukkan tidak dapat diurai, tipenya ditampilkan sebagai 'custom'.

5. Fungsi MaxCompute tidak didukung.

6. Tugas masih dapat berjalan sebagaimana mestinya meskipun kolom yang ditambahkan secara manual diklasifikasikan sebagai 'custom'. Hal ini dapat terjadi dengan kolom kunci partisi MaxCompute atau kolom yang tidak terlihat dalam pratinjau data LogHub.

Di daftar pemetaan bidang, di bawah kolom bidang sumber, klik Add or Create Field. Masukkan nama kolom kunci partisi (misalnya, pt), lalu petakan ke bidang tujuan.

Dengan mengonfigurasi MaxCompute Writer, Anda dapat melakukan operasi yang tidak didukung MaxCompute sendiri, seperti penyaringan kolom, pengurutan ulang, dan pengisian nilai null. Misalnya, untuk mengimpor semua bidang, Anda dapat mengatur konfigurasi ke "column": ["*"].

Jika tabel MaxCompute memiliki tiga kolom, a, b, dan c, dan Anda ingin menyinkronisasi data hanya ke kolom c dan b, Anda dapat mengonfigurasi kolom sebagai "column": ["c","b"]. Konfigurasi ini memetakan kolom pertama dan kedua dari reader ke kolom c dan b di tabel MaxCompute, masing-masing. Di baris yang baru dimasukkan, kolom a diatur ke null.

Untuk mencegah kehilangan data, MaxCompute Writer melaporkan error jika Anda mencoba menulis lebih banyak kolom daripada yang dimiliki tabel tujuan.

MaxCompute Writer hanya dapat menulis data ke partisi tingkat terendah. Fitur ini tidak mendukung fitur seperti routing data ke partisi berdasarkan nilai bidang. Jika tabel memiliki tiga tingkat partisi, Anda harus menentukan jalur lengkap ke partisi tingkat ketiga dalam konfigurasi partisi. Misalnya, untuk menulis data ke partisi tingkat ketiga, Anda dapat menentukan pt=20150101, type=1, biz=2. Anda tidak dapat menentukan partisi tingkat menengah seperti pt=20150101, type=1 atau pt=20150101.

MaxCompute Writer memastikan idempotensi tulis dengan konfigurasi "truncate": true. Saat tugas dijalankan ulang setelah kegagalan, pertama-tama menghapus data yang sebelumnya ditulis sebelum mengimpor data baru, menjamin konsistensi. Namun, jika pengecualian lain mengganggu tugas, atomisitas tidak dijamin: data tidak dikembalikan dan tugas tidak dijalankan ulang secara otomatis. Anda harus menjalankan ulang tugas secara manual, memanfaatkan idempotensi untuk memastikan integritas data.

• Gejala

  Code:DATAX_R_ODPS_005:Failed to read ODPS data, Solution:[Please contact the ODPS administrator]. RequestId=202012091137444331f60b08cda1d9, ErrorCode=StatusConflict, ErrorMessage=The download session is expired.

• Penyebab yang mungkin

  Tugas sinkronisasi batch menggunakan layanan MaxCompute Tunnel untuk mengunggah dan mengunduh data. Sesi Tunnel memiliki siklus hidup 24 jam di server. Jika tugas sinkronisasi batch berjalan lebih dari 24 jam, sesi kedaluwarsa dan tugas gagal. Untuk informasi lebih lanjut tentang Tunnel, lihat Catatan penggunaan.

• Solusi

  Tingkatkan jumlah thread paralel untuk tugas dan rencanakan volume data untuk memastikan sinkronisasi batch selesai dalam 24 jam.

• Gejala

  Code:[OdpsWriter-09], Description:[Failed to write data to the ODPS destination table.]. - Failed to write block:0 to the ODPS destination table, uploadId=[202012081517026537dc0b0160354b]. Please contact the ODPS administrator for assistance. - java.io.IOException: Error writing request body to server.

• Penyebab yang mungkin

  • Tipe data salah: Data sumber tidak sesuai dengan spesifikasi tipe data ODPS. Misalnya, Anda tidak dapat menulis nilai 4.2223 ke kolom bertipe DECIMAL(18,10) di ODPS.

  • Masalah blok ODPS atau error komunikasi.

• Solusi

  Pastikan data sumber sesuai dengan spesifikasi tipe data tujuan. Jika perlu, konversi data ke tipe yang didukung.

Untuk instruksi konfigurasi, lihat Menyinkronisasi data dari database dan tabel ter-shard.

Saat menambahkan sumber data dengan string koneksi, modifikasi format JDBC ke jdbc:mysql://xxx.x.x.x:3306/database?com.mysql.jdbc.faultInjection.serverCharsetIndex=45. Untuk informasi lebih lanjut, lihat Tambahkan sumber data MySQL.

• Penyebab:

  • net_read_timeout: Saat Integrasi Data membaca data dari ApsaraDB RDS untuk MySQL, kueri dibagi menjadi beberapa pernyataan SELECT berdasarkan shard key (splitPk). Error ini terjadi jika waktu eksekusi salah satu pernyataan tersebut melebihi waktu eksekusi maksimum yang diizinkan di instans ApsaraDB RDS.

  • net_write_timeout: Error ini terjadi jika waktu untuk mengirim blok data ke klien melebihi timeout yang dikonfigurasi.

• Solusi:

  Anda dapat menambahkan parameter ke URL JDBC sumber data atau memodifikasinya di konsol ApsaraDB RDS.

• Rekomendasi:

  Jika tugas dapat dijalankan ulang dengan aman, aktifkan pengulangan ulang tugas otomatis.

Contoh: jdbc:mysql://192.168.1.1:3306/lizi?useUnicode=true&characterEncoding=UTF8&net_write_timeout=72000

Penyebab:

Di MySQL, parameter wait_timeout memiliki nilai default 8 jam. Jika tugas sinkronisasi masih mengambil data saat timeout ini tercapai, tugas terganggu.

Solusi:

Modifikasi file konfigurasi my.cnf di server MySQL Anda (atau my.ini di Windows). Di bagian MySQL, tambahkan parameter berikut dengan nilai dalam detik: wait_timeout=2592000 interactive_timeout=2592000. Setelah Anda menyimpan perubahan, mulai ulang layanan MySQL, login ke MySQL, dan jalankan perintah show variables like '%wait_time%' untuk memverifikasi pengaturan baru.

Error ini dapat terjadi jika koneksi terputus karena penggunaan memori tinggi, meskipun pemanfaatan CPU normal.

Jika tugas dapat dijalankan ulang dengan aman, aktifkan pengulangan ulang otomatis saat error. Untuk informasi lebih lanjut, lihat properti waktu.

• Gejala: Tugas sinkronisasi batch yang membaca data dari database PostgreSQL gagal dengan error berikut: org.postgresql.util.PSQLException: FATAL: terminating connection due to conflict with recovery

• Penyebab: Error ini terjadi pada instans PostgreSQL standby saat kueri berjalan lama bertentangan dengan proses pemulihan database. Server menghentikan kueri karena melebihi batas waktu yang ditetapkan oleh parameter max_standby_archive_delay atau max_standby_streaming_delay. Untuk mengatasi ini, tingkatkan nilai parameter ini untuk memberikan lebih banyak waktu bagi kueri agar selesai. Untuk informasi lebih lanjut, lihat Standby Server Events.

Jika koneksi ke sumber data Amazon RDS Anda mengembalikan error Host is blocked, nonaktifkan pemeriksaan kesehatan load balancing Amazon untuk mencegah error ini terjadi berulang.

Saat Anda menambahkan sumber data MongoDB, Anda harus menggunakan pengguna yang dibuat di database yang berisi koleksi yang ingin Anda sinkronisasi. Anda tidak dapat menggunakan pengguna root.

Misalnya, jika Anda ingin mengimpor koleksi name dari database test, Anda harus menggunakan pengguna yang dibuat di database test.

Anda dapat menggunakan node assignment untuk mengonversi nilai tanggal ke timestamp dan menggunakannya sebagai parameter input untuk tugas sinkronisasi MongoDB. Untuk informasi lebih lanjut, lihat Bagaimana cara melakukan sinkronisasi inkremental untuk bidang timestamp di MongoDB?

Atur zona waktu dalam konfigurasi MongoDB Reader. Untuk informasi lebih lanjut, lihat MongoDB Reader.

Mulai ulang tugas setelah interval, biarkan semua konfigurasi lainnya tidak berubah.

Ya. Saat data dibaca, Column.name yang Anda konfigurasi peka terhadap huruf besar/kecil. Jika huruf besar/kecil yang dikonfigurasi tidak cocok dengan sumber, data dibaca sebagai null. Misalnya:

• Data sumber di MongoDB:

  {
      "MY_NAME": "zhangsan"
  }

• Konfigurasi kolom dalam tugas sinkronisasi:

  {
      "column":
      [
          {
              "name": "my_name"
          }
      ]
  }

Ketidakcocokan ini menyebabkan error pembacaan data.

Parameter timeout adalah cursorTimeoutInMs. Nilai defaultnya adalah 600.000 ms (10 menit). Parameter ini menentukan waktu eksekusi kueri maksimum di server MongoDB, tidak termasuk waktu transfer data. Jika Anda membaca jumlah data yang besar dalam sinkronisasi penuh, error berikut dapat terjadi: MongoDBReader$Task - operation exceeded time limitcom.mongodb.MongoExecutionTimeoutException: operation exceeded time limit.

Tugas sinkronisasi saat ini tidak mendukung pembacaan dari instans sekunder. Mengonfigurasi tugas untuk membaca dari instans sekunder menyebabkan error no master.

• Penyebab:

  Terjadi timeout kursor.

• Solusi:

  Tingkatkan nilai parameter cursorTimeoutInMs.

Tingkatkan jumlah thread paralel dan ukuran batch untuk tugas.

• Penyebab yang mungkin:

  Secara default, tugas sinkronisasi menggunakan perintah splitVector untuk slicing tugas. Namun, beberapa versi MongoDB tidak mendukung perintah splitVector, yang menyebabkan error no such cmd splitVector.

• Solusi:

  1. Di halaman konfigurasi tugas sinkronisasi, klik ikon Convert to Script di bilah alat atas untuk memasuki mode skrip.

  2. Dalam konfigurasi parameter MongoDB, tambahkan parameter.

     "useSplitVector" : false

     Untuk menghindari penggunaan splitVector.

• Gejala:

  Masalah ini terjadi dalam tugas sinkronisasi batch saat Write Mode (Overwrite) diatur ke Yes dan Business Key yang dikonfigurasi bukan bidang _id.

• Penyebab yang mungkin:

  Data yang akan ditulis berisi entri di mana _id tidak cocok dengan Business Key yang dikonfigurasi (seperti my_id dari contoh konfigurasi sebelumnya).

• Solusi:

  • Solusi 1: Di data sumber Anda, pastikan nilai bidang Business Key cocok dengan nilai bidang _id.

  • Solusi 2: Ubah konfigurasi tugas untuk menggunakan bidang _id sebagai business key.

• Penyebab:

  Saat menyimpan data di Redis menggunakan mode hash, atribut dan nilai harus muncul berpasangan. Misalnya, jika sumber Anda dikonfigurasi dengan odpsReader: "column":[ "id", "name", "age", "address" ] dan writer Redis tujuan dikonfigurasi dengan RedisWriter: "keyIndexes":[ 0, 1], kolom id dan name digunakan sebagai kunci. Kolom yang tersisa, age dan address, kemudian menjadi atribut dan nilai untuk hash. Jika sumber hanya menyediakan dua kolom, dan keduanya ditentukan sebagai kunci, tidak ada kolom yang tersisa untuk membentuk pasangan atribut-nilai, menyebabkan error ini.

• Solusi:

  Jika Anda hanya perlu menggunakan dua kolom, konfigurasikan Redis untuk menggunakan mode string. Jika Anda harus menggunakan mode hash, pastikan sumber menyediakan setidaknya tiga kolom: satu untuk kunci, satu untuk atribut, dan satu untuk nilai.

• Gejala:

  Saat membaca dari layanan penyimpanan file seperti OSS atau FTP, tugas sinkronisasi batch mungkin gagal dengan error dirty data. Masalah ini terjadi jika file sumber dalam format CSV dan menggunakan delimiter multi-karakter, seperti |,, ##, atau ;;. Log eksekusi tugas akan menunjukkan IndexOutOfBoundsException dan error dirty data.

• Penyebab:

  Reader csv bawaan ("fileFormat": "csv") di DataWorks tidak dapat memproses delimiter multi-karakter dengan benar, yang menyebabkan pemisahan kolom salah.

• Solusi:

  • Mode wizard: Ganti tipe file ke teks dan tentukan secara eksplisit delimiter multi-karakter Anda.

  • Mode skrip: Ubah "fileFormat": "csv" ke "fileFormat": "text" dan atur delimiter dengan parameter berikut: "fieldDelimiter":"<your_multi-character_delimiter>", "fieldDelimiterOrigin":"<your_multi-character_delimiter>".

Reader OSS tidak membatasi jumlah file yang dapat Anda baca dalam tugas sinkronisasi batch. Batasan utama berasal dari unit komputasi (CU) yang dikonsumsi oleh tugas. Membaca terlalu banyak file sekaligus dapat menyebabkan error kehabisan memori. Untuk mencegah error OutOfMemoryError: Java heap space , hindari mengatur parameter objek ke *.

OSS Writer mensimulasikan struktur direktori dengan menggunakan nama file objek yang ditulis. Misalnya, jika Anda menentukan "object": "datax", nama objek yang dihasilkan dimulai dengan datax dan ditambahkan dengan string acak. Jumlah subtugas dalam tugas sinkronisasi batch menentukan jumlah file yang dibuat.

Untuk menghindari sufiks UUID acak, atur "writeSingleObject" : "true". Untuk informasi lebih lanjut, lihat deskripsi writeSingleObject dalam dokumentasi sumber data OSS.

• Penyebab:

  AccessKey untuk sumber data tidak memiliki izin yang diperlukan untuk bucket.

• Solusi:

  Berikan izin baca pada bucket ke AccessKey yang digunakan untuk sumber data OSS.

• Penyebab:

  Error ini dapat terjadi jika nilai parameter mapred.task.timeout terlalu rendah. Saat timeout tercapai, Hadoop menghentikan tugas dan membersihkan direktori sementara. Tugas kemudian gagal karena tidak dapat menemukan data sementara.

• Solusi:

  Dalam pengaturan sumber data tugas sinkronisasi batch, jika Anda mengatur Hive read methods ke Read data using Hive JDBC (supports conditional filtering), Anda dapat meningkatkan nilai parameter mapred.task.timeout di bagian Session Configuration. Misalnya, atur parameter ke mapred.task.timeout=600000.

• Gejala:

  Anda menerima pesan error serupa berikut:ERROR JobContainer - Exception when job runcom.alibaba.datax.common.exception.DataXException: Code:[DatahubWriter-04], Description:[Failed to write data.]. - com.aliyun.datahub.exception.DatahubServiceException: Record count 12498 exceed max limit 10000 (Status Code: 413; Error Code: TooLargePayload; Request ID: 20201201004200a945df0bf8e11a42)

• Penyebab:

  Error ini terjadi karena data dalam satu permintaan DataX melebihi batas layanan DataHub. Parameter berikut mengontrol ukuran setiap komitmen batch:

  • Parameter maxCommitSize mengatur ukuran maksimum data, dalam megabyte (MB), yang dibuffer DataX sebelum meng-commit batch ke tujuan. Nilai defaultnya adalah 1 MB, yaitu 1.048.576 byte.

  • Parameter batchSize mengatur jumlah catatan maksimum yang dibuffer DataX sebelum meng-commit batch ke tujuan.

• Solusi:

  Untuk mengatasi masalah ini, kurangi parameter maxCommitSize dan batchSize.

Bidang plugin ini peka terhadap huruf besar/kecil. Periksa konfigurasi column di reader LogHub.

Integrasi Data mengambil data berdasarkan waktu kedatangannya di LogHub. Di konsol LogHub, verifikasi bahwa bidang metadata receive_time data berada dalam rentang waktu yang dikonfigurasi tugas.

Jika hal ini terjadi, edit manual column di UI.

Waktu mulai dan akhir yang dikonfigurasi untuk tugas sinkronisasi batch digunakan oleh Reader untuk memanggil API SLS GetCursor untuk menentukan kursor awal dan akhir. Waktu-waktu ini digunakan untuk menentukan rentang baca berdasarkan waktu penerimaan server SLS. Tugas benar-benar membaca data dalam rentang kursor. Ini tidak setara dengan penyaringan berdasarkan bidang output __time__.

Bidang output __time__ berasal dari log.getTime() untuk setiap log dan mewakili timestamp log itu sendiri. Kueri di konsol SLS biasanya berdasarkan rentang waktu kueri, pernyataan kueri, dan bidang yang diindeks, dengan waktu log __time__ menjadi referensi waktu umum. Oleh karena itu, meskipun tugas sinkronisasi dan kueri konsol menggunakan nilai waktu yang sama, rentang __time__ yang diambil atau jumlah catatan mungkin tidak konsisten jika mereka menggunakan referensi waktu yang berbeda.

Skenario umum meliputi:

1. Jika ada penundaan dalam pengumpulan atau pengiriman log, log historis dikirim ulang, atau waktu klien tidak akurat, waktu log__time__ mungkin lebih awal atau lebih lambat daripada waktu penerimaan server SLS. Karena tugas sinkronisasi menentukan posisi kursor berdasarkan waktu penerimaan server dan konsol mengkueri data berdasarkan __time__, hasil dari keduanya mungkin berbeda.

2. Saat Anda menggunakan pemrosesan data SLS untuk menulis data ke LogStore lain, jika pernyataan pemrosesan data tidak secara eksplisit mengatur __time__, __time__ log tujuan biasanya mempertahankan timestamp log sumber, bukan waktu eksekusi tugas pemrosesan data. Dalam kasus ini, tugas sinkronisasi mungkin membaca log ini dalam rentang waktu saat ditulis ke LogStore tujuan. Namun, Anda mungkin tidak menemukan log ini saat mengkueri konsol LogStore tujuan berdasarkan waktu eksekusi pemrosesan atau rentang waktu saat ini. Anda harus mengkueri berdasarkan rentang waktu yang sesuai dengan __time__ aktual log.

3. Jumlah catatan mungkin berbeda jika pernyataan kueri konsol, bidang yang diindeks, rentang waktu, dan pernyataan filter aturan (SPL) dalam tugas sinkronisasi tidak konsisten, meskipun kerangka waktu keseluruhan sama.

Saran troubleshooting:

1. Pastikan rentang waktu kueri, pernyataan, dan bidang yang diindeks di konsol cocok dengan waktu mulai, waktu akhir, dan aturan filter (SPL) tugas sinkronisasi.

2. Di column, keluarkan baik __time__ (waktu log) maupun __tag__:__receive_time__ (bidang yang dapat diamati untuk waktu penerimaan sisi server SLS yang harus ada di tag log), untuk membandingkan waktu log dengan waktu penerimaan sisi server;

3. Jika data berasal dari pemrosesan data SLS, verifikasi bahwa pernyataan pemrosesan secara eksplisit mengatur __time__, dan sesuaikan rentang waktu kueri di konsol untuk LogStore tujuan sesuai dengan __time__ aktual.

4. Jika sistem hilir Anda memerlukan rekonsiliasi ketat berdasarkan waktu log, Anda dapat menyaring atau melakukan statistik berdasarkan __time__ setelah menulis ke target.

Misalnya, __time__ log sumber adalah 2026-06-01 10:00:00. Tugas pemrosesan data SLS menulis log ke LogStore tujuan pada 2026-06-12 10:00:00, dan pernyataan pemrosesan tidak secara eksplisit memodifikasi __time__. Dalam kasus ini, __time__ log tujuan masih 2026-06-01 10:00:00. Jika waktu mulai dan akhir yang dikonfigurasi untuk tugas sinkronisasi mencakup 2026-06-12 10:00:00, tugas mungkin membaca log ini. Namun, saat Anda mengkueri LogStore tujuan di konsol, Anda mungkin tidak menemukan log jika Anda memilih rentang waktu sekitar 2026-06-12 10:00:00 dan konsol menyaring log berdasarkan __time__. Dalam kasus ini, Anda harus menyesuaikan waktu kueri di konsol ke rentang waktu sekitar 2026-06-01 10:00:00 atau secara eksplisit mengatur __time__ log tujuan selama pemrosesan data berdasarkan kebutuhan bisnis Anda.

Reader mencocokkan nama bidang dari konten log yang diambil, pemetaan bidang metadata bawaannya, dan LogTag berdasarkan konfigurasi column. Nama bidang peka terhadap huruf besar/kecil, dan jika tidak ditemukan kecocokan, Reader mengeluarkan null tanpa melaporkan error.

Penyebab umum meliputi:

1. Huruf besar/kecil nama bidang yang dikonfigurasi di column tidak cocok dengan huruf besar/kecil kunci bidang log asli.

2. Konsol menampilkan alias, bidang yang diindeks, atau bidang JSON yang diperluas, yang berbeda dari kunci log mentah yang diterima reader.

3. Bidang berasal dari LogTag dan harus dikonfigurasi sebagai __tag__:<tagKey>.

4. Setelah Anda mengonfigurasi pernyataan filter aturan (SPL) atau konfigurasi pemrosesan, nama bidang output yang diproses tidak persis cocok dengan column.

Saat troubleshooting, Anda dapat terlebih dahulu menggunakan Source Field dan Data Preview di halaman visual untuk mengonfirmasi bidang yang benar-benar dikenali oleh Reader. Dalam mode skrip, Anda juga dapat sementara mengatur column ke ["*"], amati kunci bidang untuk konten log umum yang diambil Reader, lalu konfigurasi column menggunakan kunci asli.

Logika tulis identik dengan panggilan API. Data di baris dan kolom yang cocok ditimpa, meninggalkan semua data lainnya tidak berubah.

Anda dapat menggunakan perintah curl untuk mendapatkan pemetaan untuk indeks ES. Anda kemudian dapat mengekstrak semua definisi bidang dari pemetaan tersebut.

• Perintah shell kueri:

  // Untuk ES 7.x
  curl -u username:password --request GET 'http://esxxx.elasticsearch.aliyuncs.com:9200/indexname/_mapping'
  // Untuk ES 6.x
  curl -u username:password --request GET 'http://esxxx.elasticsearch.aliyuncs.com:9200/indexname/typename/_mapping'

• Contoh respons:

  {
      "indexname": {
          "mappings": {
              "typename": {
                  "properties": {
                      "field1": {
                          "type": "text"
                      },
                      "field2": {
                          "type": "long"
                      },
                      "field3": {
                          "type": "double"
                      }
                  }
              }
          }
      }
  }

  Dalam respons, objek properties berisi semua bidang dan definisi propertinya untuk indeks. Dalam contoh ini, indeks berisi tiga bidang: field1, field2, dan field3.

Anda dapat menggunakan variabel penjadwalan berbasis tanggal dalam konfigurasi indeks Anda. Hal ini memungkinkan sistem menghasilkan nama indeks secara dinamis berdasarkan tanggal eksekusi. Proses ini melibatkan tiga langkah: mendefinisikan variabel tanggal, mengonfigurasi variabel indeks, dan menerapkan serta menjalankan tugas.

1. Definisikan variabel tanggal: Dalam pengaturan penjadwalan untuk tugas sinkronisasi, tambahkan parameter baru untuk mendefinisikan variabel tanggal. Dalam contoh berikut, var1 mewakili waktu eksekusi tugas (hari ini), dan var2 mewakili tanggal bisnis (hari sebelumnya).

2. Konfigurasi variabel indeks: Beralih ke mode skrip dan konfigurasikan indeks untuk Elasticsearch Reader. Gunakan format ${variable_name}, seperti yang ditunjukkan pada gambar berikut.

3. Terapkan dan jalankan tugas: Setelah Anda memverifikasi tugas, commit dan terapkan ke Operation Center. Anda kemudian dapat menjalankannya berdasarkan jadwal atau menggunakan fitur pengisian ulang data.

   1. Klik Running with Parameters untuk menjalankan dan menguji tugas. Tindakan ini mengganti parameter penjadwalan dalam konfigurasi dengan nilai aktual. Setelah tugas berjalan, periksa log untuk memverifikasi bahwa indeks yang benar digunakan.

      Catatan

      Saat Anda menggunakan Run with Parameters, masukkan nilai parameter secara langsung untuk menguji.

      

   2. Jika hasil pengujian sesuai harapan, konfigurasi tugas selesai. Klik Save lalu Commit untuk commit tugas sinkronisasi ke lingkungan produksi.

      Jika proyek Anda dalam mode standar, Anda harus klik Deploy untuk membuka pusat deployment dan menerapkan tugas sinkronisasi ke lingkungan produksi.

4. Hasil: Contoh berikut menunjukkan konfigurasi dan nama indeks aktual yang digunakan saat runtime.

   Konfigurasi indeks dalam mode skrip: "index": "esstress_1_${var1}_${var2}".

   Nama indeks yang digunakan saat runtime: esstress_1_20230106_20230105.

   

Untuk menyinkronisasi properti bidang object, Anda harus menggunakan mode skrip. Dalam mode skrip, konfigurasikan parameter multi seperti yang ditunjukkan dalam kode berikut dan tentukan jalur kolom menggunakan notasi titik, misalnya, property.child_property.

"multi":{
   "multi":true 
 }

Contoh berikut menunjukkan konfigurasinya:

# Contoh:
## Data di ES
"hits": [
    {
        "_index": "mutiltest_1",
        "_type": "_doc",
        "_id": "7XAOOoMB4GR_1Dmrrust",
        "_score": 1.0,
        "_source": {
            "level1": {
                "level2": [
                    {
                        "level3": "testlevel3_1"
                    },
                    {
                        "level3": "testlevel3_2"
                    }
                ]
            }
        }
    }
]
## Konfigurasi reader
"parameter": {
  "column": [
      "level1",
      "level1.level2",
      "level1.level2[0]"
  ],
  "multi":{
        "multi":true
    }
}
## Hasil di tujuan: satu baris dengan tiga kolom, dalam urutan yang sama seperti konfigurasi reader.
COLUMN              VALUE
level1:             {"level2":[{"level3":"testlevel3_1"},{"level3":"testlevel3_2"}]}
level1.level2:      [{"level3":"testlevel3_1"},{"level3":"testlevel3_2"}]
level1.level2[0]:   {"level3":"testlevel3_1"}

1. Tanda kutip ganda di sekitar string adalah artefak tampilan di Kibana. Data aktual di Elasticsearch tidak memiliki tanda kutip tambahan ini. Anda dapat menggunakan perintah curl atau alat seperti Postman untuk melihat data mentah. Perintah curl untuk mendapatkan data adalah sebagai berikut:

   // Untuk ES 7.x
   curl -u username:password --request GET 'http://esxxx.elasticsearch.aliyuncs.com:9200/indexname/_search'
   // Untuk ES 6.x
   curl -u username:password --request GET 'http://esxxx.elasticsearch.aliyuncs.com:9200/indexname/typename/_search'

   

2. Ya, Anda dapat mengonfigurasi tipe bidang tujuan ES sebagai nested untuk menyinkronisasi string JSON dari MaxCompute ke objek nested di ES. Contoh berikut menunjukkan cara menyinkronisasi bidang name ke format nested di ES.

   • Konfigurasi sinkronisasi: Atur type bidang name ke nested.

   • Hasil sinkronisasi: Bidang name adalah objek nested.

Untuk menulis data sebagai array ke ES, Anda dapat menggunakan salah satu dari dua metode berdasarkan format data sumber Anda.

• Uraikan data sumber sebagai array JSON. Jika data sumber Anda adalah "[1,2,3,4,5]", atur json_array=true untuk mengurai data sumber. Hal ini menulis data sebagai array ke bidang ES. Atur json_array=true dalam konfigurasi kolom.

  • Konfigurasi di antarmuka tanpa kode:

  • Konfigurasi dalam mode skrip:

    "column":[
      {
        "name":"docs",
        "type":"keyword",
        "json_array":true
      }
    ]

• Uraikan data sumber menggunakan delimiter. Jika data sumber Anda adalah "1,2,3,4,5", konfigurasikan splitter="," untuk mengurai string dan menulisnya sebagai array ke bidang ES.

  • Batasan:

    • Setiap tugas hanya mendukung satu splitter (delimiter). Anda tidak dapat mengonfigurasi delimiter berbeda untuk bidang array berbeda. Misalnya, jika Anda memiliki kolom sumber col1="1,2,3,4,5" dan col2="6-7-8-9-10", Anda tidak dapat menentukan splitter berbeda untuk setiap kolom.

    • splitter dapat berupa ekspresi reguler. Misalnya, jika nilai kolom sumber adalah "6-,-7-,-8+,*9-,-10", Anda dapat mengatur splitter ke "[-,*+]". Ini didukung di antarmuka tanpa kode.

  • Konfigurasi di antarmuka tanpa kode: Default splitter adalah "-,-".

  • Konfigurasi dalam mode skrip:

    "parameter" : {
          "column": [
            {
              "name": "col1",
              "array": true,
              "type": "long"
            }
          ],
          "splitter":","
    }

• Penyebab:

  HttpClient pertama-tama mengirim permintaan tanpa otorisasi untuk menentukan metode autentikasi yang diperlukan. Setelah server merespons dengan tantangan autentikasi, klien mengirim permintaan kedua yang telah diotorisasi. Proses ini terjadi untuk setiap koneksi. Oleh karena itu, setiap operasi tulis ke ES menghasilkan permintaan tanpa otorisasi awal, yang dicatat dalam log audit.

• Solusi:

  Tambahkan parameter "preemptiveAuth":true dalam mode skrip.

Untuk mengonfigurasi tulisan berbasis tanggal, gunakan salah satu metode berikut berdasarkan kebutuhan Anda.

• Tulis konten yang dibaca oleh reader langsung ke bidang date ES.

  • Atur origin:true untuk menulis konten langsung ke ES.

  • Parameter format menentukan properti format untuk bidang saat writer membuat pemetaan di ES.

    "parameter" : {
        "column": [
            {
                "name": "col_date",
                "type": "date",
                "format": "yyyy-MM-dd HH:mm:ss",
                "origin": true
            }
              ]
    }

• Konversi zona waktu: Jika Anda ingin Integrasi Data mengonversi zona waktu, tambahkan parameter Timezone.

  "parameter" : {
      "column": [
          {
              "name": "col_date",
              "type": "date",
              "format": "yyyy-MM-dd HH:mm:ss",
              "Timezone": "UTC"
          }
            ]
  }

• Anda telah mengonfigurasi kolom dengan type: "version". Elasticsearch tidak mendukung menentukan versi eksternal.

      "column":[
                              {
                                  "name":"id",
                                  "type":"version"
                              },
    ]

• Solusi:

  Hapus konfigurasi type: "version".

• Penyebab:

  Elasticsearch Reader tidak dapat mengurai format tanggal bidang date karena pemetaan untuk bidang tersebut di sumber data ES tidak menentukan format.

• Solusi:

  • Gunakan parameter dateFormat untuk menentukan semua format tanggal yang mungkin, dipisahkan oleh ||. Format-format tersebut harus cocok dengan nilai tanggal di bidang date sumber. Contoh:

    "parameter" : {
          "column": [
         			"dateCol1",
            	"dateCol2",
              "otherCol"
          ],
         "dateFormat" : "yyyy-MM-dd||yyyy-MM-dd HH:mm:ss",
    }

  • Perbarui pemetaan untuk semua bidang date di indeks ES Anda untuk menyertakan definisi format.

• Penyebab:

  Error ini dapat disebabkan oleh kata kunci terbatas, seperti $ref, dalam nama indeks atau bidang karena keterbatasan pustaka Fastjson.

• Solusi:

  Hindari menggunakan kata kunci terbatas seperti $ref dalam nama indeks atau bidang, karena Elasticsearch Reader tidak mendukung menyinkronisasi indeks yang mengandungnya. Untuk informasi lebih lanjut, lihat Elasticsearch Reader.

• Penyebab:

  Error ini terjadi karena konflik versi, yang dipicu oleh mekanisme kunci optimis di ES. Hal ini menunjukkan bahwa versi dokumen dalam perintah pembaruan tidak cocok dengan versi dokumen saat ini. Hal ini dapat terjadi jika dokumen sedang dihapus atau diperbarui oleh proses lain pada saat yang sama.

• Solusi:

  1. Periksa apakah proses lain sedang menghapus data dari indeks.

  2. Ubah metode sinkronisasi tugas dari Update ke Index.

• Penyebab:

  Saat Anda mengonfigurasi properti lanjutan seperti similarity dan properties untuk kolom, properti tersebut harus ditempatkan di dalam objek other_params agar plugin dapat mengenalinya.

• Solusi:

  Di Column, konfigurasikan other_params, dan di other_params, tambahkan similarity sebagai berikut:

  {"name":"dim2_name",...,"other_params":{"similarity":"len_similarity"}}

• Penyebab:

  Saat ini, Elasticsearch Writer tidak mendukung tipe dense_vector. Tipe yang didukung adalah:

  ID,PARENT,ROUTING,VERSION,STRING,TEXT,KEYWORD,LONG,
  INTEGER,SHORT,BYTE,DOUBLE,FLOAT,DATE,BOOLEAN,BINARY,
  INTEGER_RANGE,FLOAT_RANGE,LONG_RANGE,DOUBLE_RANGE,DATE_RANGE,
  GEO_POINT,GEO_SHAPE,IP,IP_RANGE,COMPLETION,TOKEN_COUNT,OBJECT,NESTED;

• Solusi:

  Untuk bekerja dengan tipe yang tidak didukung, lakukan langkah-langkah berikut:

  • Sebagai gantinya, buat pemetaan indeks secara manual di ES.

  • Ubah tipe data bidang tujuan ke NESTED.

  • Dalam konfigurasi writer, atur dynamic = true dan cleanup=false.

• Penyebab:

  # Konfigurasi salah
  "settings": {
    "index": {
      "number_of_shards": 1,
      "number_of_replicas": 0
    }
  }
  # Konfigurasi benar
  "settings": {
    "number_of_shards": 1,
    "number_of_replicas": 0
  }

• Solusi:

  Pengaturan hanya diterapkan saat indeks dibuat. Indeks dibuat dalam dua skenario: indeks tidak ada, atau cleanup=true diatur. Jika Anda mengatur cleanup=true, hapus objek pembungkus index dari konfigurasi settings.

# Pemetaan asli
{
  "name":"box_label_ret",
  "properties":{
    "box_id":{
      "type":"keyword"
    }
}
# Pemetaan setelah pembuatan ulang dengan cleanup=true
{
    "box_label_ret": {
      "properties": {
        "box_id": {
          "type": "text",
          "fields": {
            "keyword": {
              "type": "keyword",
              "ignore_above": 256
            }}}}
}

• Penyebab:

  Saat memproses tipe nested, Elasticsearch Writer hanya menerapkan pemetaan tingkat atas dan membiarkan Elasticsearch menyimpulkan pemetaan untuk properti nested. Perubahan ini adalah perilaku adaptif Elasticsearch dan tidak memengaruhi fungsionalitasnya. Jika Anda harus menggunakan format pemetaan tertentu, lihat Kemampuan tugas sinkronisasi dalam Integrasi Data.

• Solusi:

  Untuk mempertahankan pemetaan yang Anda inginkan, buat indeks ES dengan pemetaan yang diperlukan sebelum menjalankan tugas sinkronisasi. Kemudian, atur parameter cleanup ke false dalam konfigurasi tugas.

Kafka Reader membaca data dalam batch. Jika batch berisi catatan yang lebih baru daripada endDateTime yang ditentukan, reader berhenti menyinkronisasi batch berikutnya. Namun, reader tetap menulis catatan dari batch saat ini yang melebihi endDateTime ke sumber data tujuan.

• Anda dapat menggunakan parameter skipExceedRecord untuk mengontrol apakah akan menulis catatan berlebih ini. Untuk detailnya, lihat Kafka Reader. Kami tidak merekomendasikan melewatkan catatan ini karena dapat menyebabkan kehilangan data.

• Anda dapat mengonfigurasi parameter max.poll.records Kafka untuk membatasi jumlah catatan yang diambil dalam satu polling. Dengan menyesuaikan parameter ini bersama dengan jumlah thread paralel, Anda dapat mengontrol jumlah maksimum data berlebih. Jumlah data berlebih kurang dari max.poll.records * jumlah thread paralel.

• Penyebab:

  Volume data rendah atau distribusi data tidak merata dapat menyebabkan beberapa partisi Kafka tidak menerima data baru, atau data baru tidak mencapai offset akhir yang ditentukan. Tugas sinkronisasi batch hanya dapat keluar saat semua partisi telah mencapai offset akhir yang ditentukan. Partisi yang menganggur ini mencegah tugas selesai.

• Solusi:

  Dalam situasi ini, atur strategi keluar ke Keluar jika tidak ada data baru yang dibaca selama 1 menit. Dalam mode skrip, atur parameter stopWhenPollEmpty ke true dan parameter stopWhenReachEndOffset ke true. Hal ini memungkinkan tugas keluar setelah membaca semua data hingga offset terbaru di semua partisi, mencegah eksekusi menganggur. Namun, perhatikan bahwa jika catatan dengan timestamp lebih awal daripada endDateTime yang dikonfigurasi diproduksi setelah tugas keluar, catatan tersebut tidak dapat dikonsumsi.

RestAPI Writer menyediakan dua mode tulis. Untuk menyinkronisasi beberapa catatan data, atur parameter dataMode ke multiData dan tambahkan dataPath:"data.list" ke skrip RestAPI Writer. Untuk informasi lebih lanjut, lihat RestAPI Writer.

1. Konfigurasi Tablestore Writer harus mencakup parameter berikut:

   "newVersion": "true",
   "enableAutoIncrement": "true",

2. Jangan tentukan nama kolom kunci utama auto-increment.

3. Jumlah total kolom yang ditentukan dalam parameter primaryKey dan column harus sama dengan jumlah kolom dari Tablestore Reader hulu.

Misalnya, catatan data memiliki tiga tag: phone=xiaomi, RAM=8G, dan camera=LEICA.

• Contoh ekspor data (Tablestore Reader)

  • Untuk menggabungkan tag ini dan mengekspornya sebagai satu kolom, gunakan konfigurasi berikut:

    "column": [
          {
            "name": "_tags",
          }
        ],

    DataWorks mengekspor tag sebagai satu kolom dalam format berikut:

    ["phone=xiaomi","camera=LEICA","RAM=8G"]

  • Untuk mengekspor tag phone dan camera sebagai kolom terpisah, gunakan konfigurasi berikut:

    "column": [
          {
            "name": "phone",
            "is_timeseries_tag":"true",
          },
          {
            "name": "camera",
            "is_timeseries_tag":"true",
          }
        ],

    DataWorks mengekspor dua kolom dalam format berikut:

    xiaomi, LEICA

• Contoh impor data (Tablestore Writer)

  Asumsikan sumber data hulu berisi dua kolom data:

  • Satu kolom berisi: ["phone=xiaomi","camera=LEICA","RAM=8G"].

  • Kolom lain berisi 6499.

  Untuk menambahkan data dari kedua kolom ke bidang tag, gunakan konfigurasi ini:

  "column": [
        {
          "name": "_tags",
        },
        {
          "name": "price",
          "is_timeseries_tag":"true",
        },
      ],

  • Konfigurasi kolom pertama mengimpor seluruh array ["phone=xiaomi","camera=LEICA","RAM=8G"] ke bidang tag.

  • Konfigurasi kolom kedua mengimpor price=6499 sebagai tag terpisah ke bidang tag.

Jika nama tabel Anda mengikuti pola, seperti tabel harian bernama orders_20170310, orders_20170311, dan orders_20170312, dan memiliki skema tabel yang sama, Anda dapat menggunakan parameter penjadwalan dalam konfigurasi mode skrip untuk menentukan nama tabel kustom. Hal ini memungkinkan tugas secara otomatis membaca data dari tabel hari sebelumnya di database sumber setiap pagi.

Dalam mode Skrip, ganti nama tabel sumber dengan variabel, seperti orders_${tablename}. Karena Anda perlu membaca data hari sebelumnya, atur tablename=${yyyymmdd-1} dalam konfigurasi parameter tugas.

Buka halaman konfigurasi tugas sinkronisasi, perbarui pemetaan kolom, dan kirim ulang tugas.

Saat Anda mengonfigurasi tugas sinkronisasi batch, bagian Select source secara default hanya mencantumkan 25 tabel pertama. Jika tabel yang Anda butuhkan tidak tercantum, cari berdasarkan nama tabelnya atau gunakan editor kode.

• Penyebab: Tugas gagal saat nama kolom merupakan kata kunci yang dicadangkan atau diawali angka.

• Solusi: Alihkan tugas sinkronisasi Integrasi Data ke mode skrip dan gunakan karakter escape untuk bidang khusus dalam konfigurasi kolom. Lihat Konfigurasi Tugas dalam Mode Skrip untuk informasi lebih lanjut.

  • Untuk MySQL, tutup kata kunci dengan backtick (misalnya, `keyword`).

  • Untuk Oracle dan PostgreSQL, tutup kata kunci dengan tanda kutip ganda (misalnya, "keyword").

  • Untuk SQL Server, tutup kata kunci dengan tanda kurung siku (misalnya, [keyword]).

  Berikut contoh menggunakan MySQL:

• Contoh berikut menggunakan sumber data MySQL:

  1. Jalankan pernyataan berikut untuk membuat tabel bernama aliyun.create table aliyun (`table` int ,msg varchar(10));

  2. Jalankan pernyataan berikut untuk membuat view dan memberikan alias ke kolom table.create view v_aliyun as select `table` as col1,msg as col2 from aliyun;

     Catatan

     • Kata table adalah kata kunci MySQL. Akibatnya, pernyataan SQL yang dihasilkan gagal selama sinkronisasi data. Untuk mencegah hal ini, buat view dan berikan alias ke kolom table.

     • Sebagai praktik terbaik, hindari menggunakan kata kunci sebagai nama kolom.

  3. Saat Anda mengonfigurasi tugas sinkronisasi, pilih view v_aliyun alih-alih tabel aliyun untuk menggunakan alias yang Anda berikan ke kolom kata kunci.

Error ini terjadi jika pemetaan bidang untuk tugas sinkronisasi salah atau parameter column tidak dikonfigurasi dengan benar untuk plugin.

1. Verifikasi bahwa pemetaan bidang dikonfigurasi.

2. Pastikan bahwa parameter column dikonfigurasi dengan benar untuk plugin.

• Gejala:

  Mengklik Preview Data menampilkan pesan yang menunjukkan bahwa ukuran bidang melebihi batas byte.

  

• Penyebab: Untuk mencegah error kehabisan memori (OOM), layanan sumber data memeriksa panjang setiap bidang saat memproses permintaan pratinjau data. Jika satu kolom melebihi 1.000 byte, pesan ini muncul. Pesan ini tidak memengaruhi operasi normal tugas. Anda dapat mengabaikan error dan menjalankan tugas sinkronisasi batch.

  Catatan

  Jika file sumber ada dan konektivitas jaringan normal, pratinjau data juga dapat gagal karena alasan berikut:

  • Data dalam satu baris file melebihi batas 10 MB. Dalam kasus ini, tidak ada data yang ditampilkan, dan pesan serupa muncul.

  • Jumlah kolom dalam satu baris melebihi batas 1.000 kolom. Dalam kasus ini, hanya 1.000 kolom pertama yang ditampilkan, dan pesan muncul di kolom ke-1.001.

TTL adalah pengaturan tingkat tabel. Anda tidak dapat mengonfigurasinya dalam tugas sinkronisasi batch.

Tidak. Sinkronisasi data berbasis API tidak mendukung fungsi sumber. Proses data di sumber sebelum menyinkronisasikannya ke tujuan.