DataWorks:FAQ sinkronisasi batch

• Jika uji konektivitas sebelumnya berhasil, lakukan uji ulang untuk memastikan kelompok sumber daya dan database saat ini terhubung (dan tidak ada perubahan di sisi database).

• Periksa apakah kelompok sumber daya yang lulus uji konektivitas sama dengan yang digunakan untuk menjalankan tugas.

  Periksa kelompok sumber daya yang digunakan oleh tugas:

  • Jika tugas berjalan di kelompok sumber daya default, log berisi informasi berikut: running in Pipeline[basecommon_ group_xxxxxxxxx]

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

  • Jika tugas berjalan di kelompok sumber daya serverless, log berisi informasi berikut: running in Pipeline[basecommon_Serverless_res_group_xxx]

• Jika tugas kadang-kadang gagal selama penjadwalan dini hari tetapi berhasil setelah dijalankan ulang, periksa beban database pada saat error terjadi.

Jika tugas sinkronisasi batch kadang-kadang gagal, penyebabnya kemungkinan konfigurasi daftar putih yang tidak lengkap. Periksa apakah daftar putih database telah dikonfigurasi secara lengkap.

Saat menggunakan grup sumber daya eksklusif untuk Integrasi Data:

• Jika sebelumnya Anda menambahkan alamat IP antarmuka jaringan elastis (ENI) dari grup sumber daya eksklusif untuk Integrasi Data ke daftar putih sumber data, dan grup sumber daya tersebut telah diskalakan, perbarui daftar putih sumber data untuk menyertakan alamat IP ENI dari grup sumber daya yang telah diskalakan.

• Untuk menghindari pembaruan daftar putih setiap kali grup sumber daya diskalakan, kami menyarankan Anda menambahkan Blok CIDR dari vSwitch yang terkait dengan grup sumber daya eksklusif untuk Integrasi Data sebagai daftar putih database. Untuk informasi lebih lanjut, lihat Tambahkan daftar putih.

Saat menggunakan kelompok sumber daya serverless: lihat Konektivitas jaringan kelompok sumber daya serverless untuk memeriksa konfigurasi daftar putih kelompok sumber daya dan memastikan jaringan dikonfigurasi dengan benar.

Jika daftar putih telah dikonfigurasi dengan benar, periksa apakah beban database terlalu tinggi, yang dapat menyebabkan koneksi terputus.

• Penyebab kemungkinan:

  Konkurensi diatur terlalu tinggi, sehingga menyebabkan sumber daya tidak mencukupi.

• Solusi:

  Kurangi konkurensi tugas sinkronisasi batch.

  • Jika Anda mengonfigurasi tugas sinkronisasi batch dalam mode wizard, kurangi nilai Expected Maximum Concurrency di Kontrol Saluran. Untuk informasi lebih lanjut, lihat Konfigurasi kontrol saluran dalam mode wizard.

  • Jika Anda mengonfigurasi tugas sinkronisasi batch dalam mode skrip, kurangi nilai parameter concurrent di Kontrol Saluran. Untuk informasi lebih lanjut, lihat Konfigurasi kontrol saluran dalam mode skrip.

Untuk mengatasi error ini:

1. Jika konfigurasi plugin mendukung parameter seperti batchsize atau maxfilesize, kurangi nilai yang sesuai.

   Anda dapat memeriksa apakah setiap plugin mendukung parameter tersebut. Buka topik Sumber data dan reader/writer yang didukung dan klik plugin yang sesuai untuk melihat detail parameter.

2. Kurangi konkurensi.

   • Jika Anda mengonfigurasi tugas sinkronisasi batch dalam mode wizard, kurangi nilai Expected Maximum Concurrency di Kontrol Saluran. Untuk informasi lebih lanjut, lihat Konfigurasi kontrol saluran dalam mode wizard.

   • Jika Anda mengonfigurasi tugas sinkronisasi batch dalam mode skrip, kurangi nilai parameter concurrent di Kontrol Saluran. Untuk informasi lebih lanjut, lihat Konfigurasi kontrol saluran dalam mode skrip.

3. Jika Anda menyinkronkan file, seperti file OSS, kurangi jumlah file yang dibaca.

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

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

• Penyebab kemungkinan: Integrasi Data tidak mengizinkan instans berbeda dari node yang sama (yaitu, tugas sinkronisasi dengan konfigurasi JSON yang sama) berjalan secara bersamaan. Misalnya, jika tugas sinkronisasi berjalan dengan jadwal 5 menit, dan keterlambatan hulu menyebabkan instans 00:00 dan 00:05 dipicu pada 00:05, salah satu instans tidak dapat dimulai. Hal ini juga dapat terjadi ketika Anda mengisi kembali data atau menjalankan ulang instans saat instans tugas masih berjalan.

• Solusi: Atur waktu eksekusi instans agar tidak bertabrakan. Untuk tugas yang dijadwalkan dengan interval per jam atau per menit, kami menyarankan Anda mengatur dependensi diri sendiri sehingga instans saat ini dimulai hanya setelah instans dari siklus sebelumnya selesai. Untuk konfigurasi di Data Studio lama, lihat Dependensi diri sendiri. Untuk konfigurasi di Data Studio baru, lihat Konfigurasi dependensi diri sendiri.

• Detail error: Selama tugas sinkronisasi data, tugas gagal dengan error berikut: MongoDBReader$Task - operation exceeded time limitcom.mongodb.MongoExecutionTimeoutException: operation exceeded time limit.

• Penyebab kemungkinan: Tarikan data penuh terlalu besar.

• Solusi:

  • Tingkatkan konkurensi.

  • Kurangi BatchSize.

  • Tambahkan konfigurasi cursorTimeoutInMs di bagian parameter Reader, dan atur ke nilai besar, seperti 3600000 ms.

• Error baca

  • Gejala:

    Saat membaca data, terjadi error berikut: 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 kemungkinan:

    Database mengeksekusi kueri SQL secara lambat, menyebabkan timeout baca MySQL.

  • Solusi:

    • Periksa apakah kondisi filter where dikonfigurasi dan pastikan kolom filter diindeks.

    • Periksa apakah tabel sumber berisi terlalu banyak data. Jika ya, bagi tugas menjadi beberapa tugas.

    • Periksa log untuk menemukan pernyataan SQL yang menyebabkan pemblokiran dan konsultasikan dengan administrator basis data untuk menyelesaikan masalah.

• Error tulis

  • Gejala:

    Saat menulis data, terjadi 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 kemungkinan:

    Kueri lambat menyebabkan SocketTimeout. SocketTimeout default untuk koneksi TDDL adalah 12 detik. Jika pernyataan SQL membutuhkan waktu lebih dari 12 detik untuk dieksekusi di MySQL, error 4614 dilaporkan. Error ini dapat terjadi sesekali ketika volume data besar atau server sibuk.

  • Solusi:

    • Tunggu hingga database stabil lalu jalankan ulang tugas sinkronisasi.

    • Hubungi administrator basis data untuk menyesuaikan nilai timeout.

Penyebab kemungkinan 2: Menunggu resource eksekusi tugas Integrasi Data

Solusi 2: Jika log menunjukkan status WAIT yang berkepanjangan, grup sumber daya eksklusif untuk Integrasi Data yang digunakan oleh tugas saat ini tidak memiliki konkurensi yang cukup untuk menjalankan tugas. Untuk detail penyebab dan solusi, lihat Troubleshoot masalah konkurensi kelompok sumber daya.

• Contoh skenario

  SQL yang dieksekusi adalah sebagai berikut:

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

  Eksekusi dimulai pada 2016-10-25 11:01:24.875 dan hasil mulai dikembalikan pada 2016-10-25 11:11:05.489. Program sinkronisasi menunggu database mengembalikan hasil kueri SQL, dan MaxCompute harus menunggu waktu yang lama sebelum eksekusi dapat dilanjutkan.

• Analisis akar penyebab

  Kolom createTime dalam klausa WHERE tidak diindeks, menyebabkan pemindaian tabel penuh.

• Solusi

  Kami menyarankan klausa where menggunakan kolom yang diindeks untuk meningkatkan kinerja. Anda juga dapat menambahkan indeks sesuai kebutuhan.

Data Studio lama:

Anda dapat memodifikasi kelompok sumber daya yang digunakan untuk debugging di halaman detail tugas sinkronisasi batch di DataStudio. Anda juga dapat mengubah kelompok sumber daya eksekusi tugas Integrasi Data yang digunakan selama penjadwalan di Operation Center. Untuk informasi lebih lanjut, lihat Ganti kelompok sumber daya Integrasi Data.

Data Studio baru:

Anda dapat memodifikasi kelompok sumber daya yang digunakan untuk debugging tugas Integrasi Data di DataStudio. Anda juga dapat mengubah kelompok sumber daya eksekusi tugas Integrasi Data yang digunakan selama penjadwalan di Operation Center. Untuk informasi lebih lanjut, lihat Ganti kelompok sumber daya Integrasi Data.

Data kotor: Catatan yang gagal ditulis ke sumber data tujuan karena pengecualian.

Tugas mengakumulasi jumlah catatan data kotor selama eksekusi. Setelah jumlah melebihi ambang batas data kotor yang dikonfigurasi, tugas segera dihentikan.

• Pertahanan data: Data yang berhasil ditulis ke tujuan sebelum tugas dihentikan dipertahankan. Tidak ada rollback yang dilakukan.

• Kebijakan toleransi nol: Saat ambang batas data kotor diatur ke 0, sistem menerapkan kebijakan toleransi nol. Artinya, tugas gagal dan berhenti segera setelah mendeteksi catatan data kotor pertama.

• Pesan error:

  Jika data berisi karakter emoji, error data kotor 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 kemungkinan:

  • Encoding database tidak diatur ke utf8mb4, yang menyebabkan error saat menyinkronkan karakter emoji.

  • Data sumber itu sendiri berisi karakter rusak.

  • Encoding database dan klien tidak konsisten.

  • Encoding browser berbeda, menyebabkan kegagalan pratinjau atau karakter rusak.

• Solusi:

  Pilih solusi yang sesuai berdasarkan penyebab karakter rusak:

  • Jika data asli berisi karakter rusak, perbaiki data sebelum menjalankan tugas sinkronisasi.

  • Jika format encoding database dan klien tidak konsisten, modifikasi format encoding terlebih dahulu.

  • Jika encoding browser tidak konsisten dengan encoding database atau klien, satukan format encoding sebelum melakukan pratinjau data.

  Anda dapat mencoba hal berikut:

  1. Untuk sumber data yang ditambahkan dalam format JDBC, modifikasi utf8mb4 sebagai berikut: jdbc:mysql://xxx.x.x.x:3306/database?com.mysql.jdbc.faultInjection.serverCharsetIndex=45.

  2. Untuk sumber data yang ditambahkan berdasarkan ID instans, tambahkan berikut ke nama database: database?com.mysql.jdbc.faultInjection.serverCharsetIndex=45.

  3. Modifikasi format encoding database ke utf8mb4. Misalnya, modifikasi format encoding database RDS di konsol RDS.

     Catatan

     Perintah untuk mengatur format encoding sumber data RDS: set names utf8mb4. Perintah untuk memeriksa format encoding database RDS: show variables like 'char%'.

• Skenario: Saat Anda menyinkronkan data ke MaxCompute (ODPS), tugas gagal atau data yang ditulis terpotong karena bidang sumber melebihi 8 MB.

• Penyebab: Untuk tugas sinkronisasi yang menggunakan MaxCompute sebagai tujuan, MaxCompute (ODPS) Writer memberlakukan batas ukuran 8 MB per bidang.

• Solusi:

  • Di pengaturan lanjutan konfigurasi MaxCompute (ODPS) Writer, atur kebijakan penanganan bidang kelebihan panjang (overLengthRule) untuk menentukan cara menangani bidang yang terlalu besar: potong bidang menjadi 8 MB, atur bidang ke NULL, atau tulis bidang apa adanya tanpa pemotongan.

  • Untuk skenario yang melibatkan objek besar, seperti file atau log, simpan data mentah di Object Storage Service (OSS) dan simpan hanya URL di database. Kemudian gunakan DataWorks untuk menyinkronkan URL alih-alih objek besar itu sendiri.

  • Sebagai langkah pra-pemrosesan, bagi bidang yang terlalu besar menjadi beberapa sub-bidang yang lebih kecil di sumber, misalnya menjadi segmen 7 MB. Sinkronkan sub-bidang secara terpisah dan gabungkan kembali di tujuan.

Saat membuat tabel tujuan, DataWorks hanya mempertahankan nama kolom, tipe data, dan komentar dari tabel sumber. Nilai default, kendala (termasuk kendala not-null dan indeks) tidak dipertahankan.

Tugas sinkronisasi batch tidak mendukung penggunaan kunci utama komposit sebagai kunci pemisah.

• Skenario: Tugas sinkronisasi inkremental gagal dengan error yang menunjukkan bahwa kolom kunci pemisah (splitPk) yang dikonfigurasi tidak valid.

• Penyebab kemungkinan: Konfigurasi kunci pemisah tidak memenuhi persyaratan. Misalnya, beberapa kolom dikonfigurasi sebagai kunci pemisah, tipe data kolom yang dikonfigurasi tidak didukung, atau kolom yang dikonfigurasi tidak ada di tabel.

• Solusi:

  1. Segarkan pemetaan tabel sumber untuk melihat kolom kunci pemisah yang disarankan sistem secara otomatis.

  2. Pastikan hanya satu kolom yang dikonfigurasi sebagai kunci pemisah dan tipe data kolom tersebut adalah tipe integer. Seperti yang dijelaskan sebelumnya dalam dokumen ini, splitPk hanya mendukung pembagian data berbasis integer dan tidak mendukung string, floating-point, tanggal, atau tipe lainnya.

  3. Jika kolom yang disarankan secara otomatis tidak memenuhi kondisi ini, ubah secara manual kunci pemisah menjadi satu kolom tipe integer yang memenuhi persyaratan.

Untuk informasi lebih lanjut tentang bagaimana kunci pemisah memengaruhi kinerja sinkronisasi, lihat Bagaimana cara troubleshooting tugas sinkronisasi batch yang membutuhkan waktu lama untuk berjalan?

Jika masalah kualitas data terjadi setelah sinkronisasi data, lihat Troubleshoot masalah kualitas data setelah sinkronisasi untuk troubleshooting detail.

P: Bagaimana cara menangani error "Task have SSRF attacks"?

Penyebab: Untuk memastikan keamanan cloud, DataWorks melarang tugas mengakses alamat jaringan internal cloud melalui alamat IP publik. Saat URL dalam konfigurasi plugin (seperti HTTP Reader) mengarah ke alamat IP internal atau nama domain VPC, pemeriksaan keamanan ini dipicu.

Pendekatan yang benar:

• Jangan gunakan alamat IP internal seperti 10.x.x.x atau 192.168.x.x dalam konfigurasi.

• Beli kelompok sumber daya serverless (disarankan) atau grup sumber daya eksklusif untuk Integrasi Data dan konfigurasi konektivitas VPC untuk mengakses sumber data internal secara aman.

Solusi: Untuk tugas yang mengakses sumber data internal, hentikan penggunaan kelompok sumber daya bersama dan beralih ke kelompok sumber daya serverless yang aman (disarankan) atau grup sumber daya eksklusif untuk Integrasi Data.

Beralih tugas sinkronisasi ke mode skrip dan tambahkan konfigurasi berikut di bagian setting halaman konfigurasi tugas:

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

Di mana:

• dateFormat menentukan format tanggal yang digunakan saat mengonversi data tipe DATE sumber (tanpa waktu) ke teks.

• datetimeFormatInNanos menentukan format tanggal yang digunakan saat mengonversi data tipe DATETIME/TIMESTAMP sumber (dengan waktu) ke teks. Anda dapat menentukan presisi hingga milidetik.

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

2. Anda dapat menggunakan parameter penjadwalan, seperti '${bizdate}'. Untuk informasi tentang cara menggunakan parameter penjadwalan, lihat Konfigurasi parameter penjadwalan.

3. Anda dapat memasukkan kolom partisi untuk disinkronkan, seperti pt.

4. Jika nilai yang dimasukkan tidak dapat diurai, tipe ditampilkan sebagai 'Custom'.

5. Fungsi ODPS tidak didukung.

6. Jika kolom yang ditambahkan secara manual ditampilkan sebagai Custom (misalnya, kolom partisi MaxCompute atau kolom LogHub yang tidak ditampilkan dalam pratinjau data), hal ini tidak memengaruhi eksekusi tugas aktual.

Di daftar pemetaan kolom, klik Add atau Create Field di bawah kolom tabel sumber, masukkan nama kolom partisi (seperti pt), dan konfigurasikan pemetaan ke kolom tabel tujuan.

Dengan mengonfigurasi MaxCompute Writer, Anda dapat mengimplementasikan operasi penyaringan kolom, pengubahan urutan, dan pengisian null yang tidak didukung oleh MaxCompute itu sendiri. Misalnya, untuk mengimpor semua kolom, konfigurasikan "column": ["*"].

Jika tabel MaxCompute memiliki tiga kolom a, b, dan c, dan Anda ingin menyinkronkan hanya kolom c dan b, konfigurasikan daftar kolom sebagai "column": ["c","b"]. Ini berarti kolom pertama dan kedua dari Reader diimpor ke kolom c dan b tabel MaxCompute, dan kolom a yang baru disisipkan di tabel MaxCompute diatur ke null.

Untuk memastikan keandalan penulisan data dan menghindari masalah kualitas data yang disebabkan oleh kehilangan data kolom tambahan, MaxCompute Writer melaporkan error jika kolom tambahan ditulis. Misalnya, jika tabel MaxCompute memiliki kolom a, b, dan c, dan MaxCompute Writer mencoba menulis lebih dari tiga kolom, error dilaporkan.

• Skenario: Tugas sinkronisasi batch yang menulis ke MaxCompute (ODPS) gagal, dan troubleshooting menunjukkan bahwa tabel tujuan berisi kolom tipe JSON.

• Penyebab kemungkinan: MaxCompute Writer mungkin tidak mendukung penulisan ke kolom tujuan tipe JSON dalam semua kasus.

• Solusi: Periksa skema tabel tujuan MaxCompute untuk mengonfirmasi apakah berisi kolom tipe JSON. Jika iya, coba salah satu metode berikut:

  • Ubah tipe kolom menjadi STRING di sisi MaxCompute, misalnya dengan menjalankan ALTER TABLE ADD COLUMN atau perubahan skema setara.

  • Kecualikan kolom tipe JSON dari pemetaan bidang sehingga tidak ditulis selama sinkronisasi.

MaxCompute Writer hanya mendukung penulisan ke partisi tingkat terakhir dan tidak mendukung routing partisi berdasarkan kolom. Jika tabel memiliki tiga tingkat partisi, Anda harus menentukan partisi tingkat ketiga secara tepat dalam konfigurasi partisi. Misalnya, untuk menulis data ke partisi tingkat ketiga, konfigurasikan sebagai pt=20150101, type=1, biz=2. Anda tidak dapat mengonfigurasinya sebagai pt=20150101, type=1 atau pt=20150101.

MaxCompute Writer memastikan idempotensi penulisan dengan mengonfigurasi "truncate": true. Saat penulisan gagal dan dijalankan ulang, MaxCompute Writer menghapus data sebelumnya dan mengimpor data baru, memastikan konsistensi data setelah setiap rerun. Jika tugas terganggu karena pengecualian lain selama eksekusi, atomisitas data tidak dijamin. Data tidak dikembalikan atau dijalankan ulang secara otomatis. Manfaatkan fitur idempotensi untuk menjalankan ulang tugas dan memastikan kelengkapan data.

• Pesan error:

  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 kemungkinan:

  Saat sinkronisasi batch membaca data MaxCompute, menggunakan perintah tunnel MaxCompute untuk mengunggah dan mengunduh data. Sesi Tunnel memiliki masa aktif sisi server 24 jam. Oleh karena itu, jika tugas sinkronisasi batch berjalan lebih dari 24 jam, tugas gagal. Untuk informasi lebih lanjut tentang tunnel, lihat Ikhtisar Tunnel.

• Solusi:

  Tingkatkan konkurensi tugas sinkronisasi batch dan rencanakan volume data secara tepat untuk memastikan tugas selesai dalam 24 jam.

• Pesan error:

  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 kemungkinan:

  • Penyebab kemungkinan 1: Pengecualian tipe data, artinya data sumber tidak sesuai dengan spesifikasi tipe data ODPS. Misalnya, menulis nilai 4.2223 ke tipe data decimal(18,10) di ODPS.

  • Kemungkinan Penyebab 2: Blok ODPS atau pengecualian komunikasi.

• Solusi:

  Konversi tipe data dan gunakan data yang sesuai dengan spesifikasi tipe data.

• Skenario: Tugas sinkronisasi batch seluruh database ke MaxCompute gagal dengan ErrorCode=MethodNotAllowed, ErrorMessage=cdc mode not supported.

• Penyebab kemungkinan: Atribut transaksional atau change data capture (CDC) dari tabel tujuan MaxCompute mungkin tidak cocok dengan mode penulisan yang digunakan oleh tugas sinkronisasi.

• Solusi: Periksa apakah tabel tujuan dibuat dengan atribut CDC atau transaksional yang tidak kompatibel dengan mode penulisan tugas sinkronisasi saat ini. Jika Anda tidak yakin tentang atribut tabel, hubungi dukungan teknis untuk konfirmasi lebih lanjut.

• Skenario: Saat Anda mengonfigurasi tugas sinkronisasi batch dengan MaxCompute sebagai tujuan, pemilih kelompok sumber daya Tunnel di konfigurasi tujuan tidak mencantumkan kelompok sumber daya Serverless yang telah dibeli.

• Penyebab: Kelompok sumber daya Tunnel dan kelompok sumber daya yang menjalankan tugas sinkronisasi, seperti kelompok sumber daya Serverless, adalah dua item konfigurasi independen dengan tujuan berbeda. Kelompok sumber daya Tunnel hanya digunakan untuk transmisi unggah dan unduh data MaxCompute, dan secara default menggunakan resource transmisi publik, yaitu kuota Tunnel MaxCompute. Kelompok sumber daya yang menjalankan tugas hanya digunakan untuk menjalankan tugas sinkronisasi itu sendiri, termasuk membaca sumber, memproses data, dan penjadwalan. Karena kedua konfigurasi ini memiliki tujuan berbeda, keduanya independen dan tidak dapat saling menggantikan.

Anda dapat merujuk ke dokumen berikut untuk konfigurasi: Sinkronkan tabel sharded MySQL ke MaxCompute.

Tambahkan sumber data menggunakan string koneksi. Kami menyarankan memodifikasi URL JDBC menjadi: jdbc:mysql://xxx.x.x.x:3306/database?com.mysql.jdbc.faultInjection.serverCharsetIndex=45. Untuk informasi lebih lanjut, lihat Tambahkan sumber data MySQL.

• Penyebab error:

  • net_read_timeout: DataX membagi data MySQL menjadi beberapa pernyataan SELECT berukuran sama berdasarkan SplitPk. Selama eksekusi, salah satu pernyataan SQL melebihi waktu eksekusi maksimum yang diizinkan di sisi RDS.

  • net_write_timeout: Timeout untuk menunggu pengiriman blok ke klien diatur terlalu kecil.

• Solusi:

  Tambahkan parameter ke koneksi URL sumber data, atur net_write_timeout/net_read_timeout ke nilai yang lebih besar, atau sesuaikan parameter di konsol RDS.

• Saran perbaikan:

  Jika tugas dapat dijalankan ulang, atur tugas untuk dijalankan ulang secara otomatis saat error.

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

Penyebab error:

Parameter MySQL wait_timeout defaultnya 8 jam. Jika data masih diambil saat timeout ini tercapai, tugas sinkronisasi terganggu.

Solusi:

Modifikasi file konfigurasi MySQL my.cnf (atau my.ini di Windows). Tambahkan parameter di bawah modul MySQL (dalam detik): wait_timeout=2592000 interactive_timeout=2592000. Kemudian restart dan login ke MySQL, dan jalankan pernyataan berikut untuk memverifikasi: show variables like '%wait_time%'.

Penggunaan CPU normal tetapi penggunaan memori tinggi dapat menyebabkan koneksi terputus.

Jika Anda memastikan bahwa tugas dapat dijalankan ulang secara otomatis, kami menyarankan Anda mengaktifkan Auto Rerun on Error. Untuk informasi lebih lanjut, lihat Konfigurasi auto rerun.

• Skenario: Saat alat sinkronisasi batch menyinkronkan data PostgreSQL, terjadi error berikut: org.postgresql.util.PSQLException: FATAL: terminating connection due to conflict with recovery

• Penyebab kemungkinan: Error ini terjadi karena waktu tarik data dari database terlalu lama. Tingkatkan nilai max_standby_archive_delay dan max_standby_streaming_delay. Untuk informasi lebih lanjut, lihat Standby Server Events.

• Skenario: Tugas sinkronisasi real-time dari AWS PostgreSQL ke MaxCompute gagal karena pengguna PostgreSQL sumber tidak memiliki hak istimewa REPLICATION.

• Penyebab kemungkinan: Pengguna PostgreSQL sumber tidak memiliki hak istimewa REPLICATION. Di beberapa instans AWS RDS PostgreSQL yang dikelola, atribut ini tidak dapat diberikan menggunakan ALTER ROLE.

• Solusi: Sinkronisasi batch (offline, terjadwal) tidak memerlukan hak istimewa REPLICATION. Jika Anda tidak dapat memberikan hak istimewa REPLICATION di instans AWS PostgreSQL Anda, gunakan tugas sinkronisasi batch dengan jadwal periodik sebagai gantinya dari sinkronisasi real-time sebagai solusi sementara.

• Skenario: Setelah Anda menyinkronkan kolom timestamp PostgreSQL (tanpa zona waktu) ke kolom DATETIME MaxCompute, nilai yang dihasilkan bergeser, misalnya 2 jam, dibandingkan dengan nilai yang diharapkan.

• Penyebab kemungkinan: Tipe timestamp PostgreSQL (tanpa zona waktu) menyimpan nilai waktu lokal apa adanya. Tipe DATETIME MaxCompute menyimpan nilai dalam UTC dan mengonversinya untuk ditampilkan berdasarkan zona waktu proyek atau sesi. Perbedaan perilaku penyimpanan dan konversi ini dapat menyebabkan deviasi zona waktu.

• Solusi:

  1. Periksa apakah zona waktu server PostgreSQL, yang dapat Anda kueri dengan menjalankan SHOW timezone;, cocok dengan zona waktu proyek MaxCompute. Anda dapat melihat zona waktu proyek di halaman Informasi Dasar proyek MaxCompute.

  2. Jika zona waktu berbeda, konfigurasikan zona waktu di pengaturan lanjutan tugas sinkronisasi batch. Atur zona waktu tugas sinkronisasi agar cocok dengan zona waktu server PostgreSQL sehingga nilai timestamp diurai dalam zona waktu tersebut sebelum ditulis ke MaxCompute, yang menghilangkan deviasi.

     Ketidaksesuaian zona waktu antara sumber dan tujuan biasanya muncul sebagai offset tetap N jam di setiap bidang waktu. Misalnya, kedua ujung diatur ke Asia/Bangkok tetapi nilai yang disinkronkan berbeda 1 jam, atau kelompok sumber daya berjalan di Jerman dan default ke Europe/Berlin sementara bisnis Anda memerlukan nilai disimpan dalam UTC. Dalam kasus seperti ini, pilih zona waktu yang ingin Anda gunakan di pengaturan lanjutan tugas.

  Catatan

  Mengubah zona waktu penjadwalan tidak memengaruhi zona waktu yang digunakan oleh proses Integrasi Data. Kedua pengaturan ini independen. Jika kolom tanggal masih mengembalikan nilai yang tidak diharapkan setelah Anda menyesuaikan zona waktu penjadwalan, atur zona waktu secara eksplisit di pengaturan lanjutan tugas sinkronisasi batch juga.

  Pengaturan zona waktu defaultnya GMT+8. Biarkan apa adanya saat bidang waktu disinkronkan dengan benar, dan atur ke zona waktu yang diharapkan bisnis Anda hanya saat terjadi offset waktu. Dalam mode skrip, pengaturan ini setara dengan konfigurasi berikut:

  "common":{"column":{"timeZone":"Asia/Bangkok"}}

• Skenario: Saat Anda mengonfigurasi kondisi WHERE atau pernyataan querySql kustom untuk sinkronisasi inkremental dari PostgreSQL, Anda perlu mengonversi parameter waktu berformat string menjadi timestamp untuk perbandingan.

• Solusi: Gunakan fungsi PostgreSQL standar TO_TIMESTAMP alih-alih fungsi MySQL STR_TO_DATE, karena PostgreSQL dan MySQL menggunakan dialek SQL berbeda untuk mengonversi string tanggal dan waktu. Contoh:

  TO_TIMESTAMP('${start_time}', 'YYYYMMDDHH24')
  TO_TIMESTAMP('${end_time}', 'YYYYMMDDHH24')

  TO_TIMESTAMP mengonversi string dalam format yang ditentukan menjadi objek timestamp, yang kemudian dapat Anda gunakan untuk menyaring baris dalam rentang waktu di kondisi WHERE atau pernyataan querySql.

• Skenario: Saat tugas sinkronisasi batch membaca data dari Oracle dengan kondisi WHERE, tugas gagal dengan ORA-00932: inconsistent datatypes.

• Penyebab kemungkinan: Klausa WHERE secara langsung membandingkan kolom DATE Oracle dengan nilai NUMBER, misalnya literal tanggal yang ditulis sebagai angka biasa. Perbandingan ini menyebabkan ketidakcocokan tipe data di Oracle.

• Solusi: Konversi eksplisit nilai tanggal numerik ke tipe DATE sebelum perbandingan. Misalnya, gunakan TO_DATE('20250611', 'YYYYMMDD') atau literal DATE '2025-06-11' di kondisi WHERE alih-alih membandingkan kolom dengan angka biasa.

Saat menghubungkan ke Amazon RDS dan menerima error Host is blocked, nonaktifkan pemeriksaan kesehatan load balancer Amazon. Setelah dinonaktifkan, masalah pemblokiran tidak akan terjadi lagi.

Saat menambahkan sumber data MongoDB, gunakan pengguna yang dibuat di database yang berisi tabel untuk disinkronkan. Pengguna root tidak didukung.

Misalnya, jika Anda ingin mengimpor tabel name, dan tabel name berada di database test, nama database harus test, dan Anda perlu menggunakan username pengguna yang dibuat di database test.

Anda dapat menggunakan node assignment untuk terlebih dahulu mengonversi nilai tipe tanggal ke timestamp, lalu meneruskan nilai tersebut sebagai parameter input untuk tugas sinkronisasi data MongoDB.

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

Anda dapat menjalankan ulang tugas setelah penundaan tanpa mengubah kondisi kueri, yaitu menunda waktu eksekusi tugas sambil mempertahankan konfigurasi tidak berubah.

Saat membaca data, Column.name yang dikonfigurasi pengguna peka terhadap huruf besar/kecil. Konfigurasi yang salah menyebabkan data baca menjadi null. Misalnya:

• Data sumber MongoDB:

  {
      "MY_NAME": "zhangsan"
  }

• Konfigurasi kolom tugas sinkronisasi:

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

Karena huruf besar/kecil konfigurasi kolom tidak cocok dengan data sumber, pembacaan data gagal.

Parameter konfigurasi timeout adalah cursorTimeoutInMs, yang defaultnya 600000 ms (10 menit). Parameter ini menentukan total waktu yang dihabiskan Server MongoDB untuk mengeksekusi kueri, tidak termasuk waktu transfer data. Jika pembacaan data penuh besar, error berikut dapat terjadi: MongoDBReader$Task - operation exceeded time limitcom.mongodb.MongoExecutionTimeoutException: operation exceeded time limit.

Saat ini, tugas sinkronisasi DataWorks tidak mendukung pembacaan data dari node sekunder. Jika Anda mengonfigurasi node sekunder untuk pembacaan, error berikut terjadi: no master.

• Analisis akar penyebab:

  Disebabkan oleh timeout kursor.

• Solusi:

  Tingkatkan nilai parameter cursorTimeoutInMs.

Tingkatkan konkurensi tugas dan BatchSize baca.

• Penyebab kemungkinan:

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

• Solusi:

  1. Buka halaman konfigurasi tugas sinkronisasi dan klik tombol Convert to Script di bagian atas. Ubah tugas ke mode skrip.

  2. Di konfigurasi parameter MongoDB, tambahkan parameter berikut:

     "useSplitVector" : false

     Hal ini menghindari penggunaan splitVector.

• Pesan error:

  Dalam tugas sinkronisasi, mengambil mode wizard sebagai contoh, masalah ini dapat terjadi saat Write Mode (Overwrite) diatur ke Yes dan kolom non-_id dikonfigurasi sebagai Business Key.

  Dalam konfigurasi tujuan tugas sinkronisasi, pilih sumber data MongoDB (nama instans: xc_mongo_rds), atur nama koleksi ke xc_timestamp, aktifkan mode timpa (atur 'Timpa' ke Ya), dan tentukan my_id sebagai kunci utama bisnis."

• Penyebab kemungkinan:

  Data yang ditulis berisi catatan di mana _id tidak cocok dengan Business Key yang dikonfigurasi (seperti my_id dalam contoh di atas).

• Solusi:

  • Opsi 1: Modifikasi tugas sinkronisasi batch untuk memastikan bahwa Business Key yang dikonfigurasi sama dengan _id.

  • Opsi 2: Gunakan _id sebagai kunci utama bisnis selama sinkronisasi data.

• Penyebab:

  Saat Redis menggunakan mode hash untuk penyimpanan, atribut dan nilai hash harus muncul berpasangan. Misalnya: odpsReader: "column":[ "id", "name", "age", "address" ]. Di tujuan, jika RedisWriter dikonfigurasi sebagai: "keyIndexes":[ 0, 1], maka di Redis, id dan name berfungsi sebagai kunci, age berfungsi sebagai atribut, dan address berfungsi sebagai nilai dalam tipe hash. Jika hanya dua kolom dikonfigurasi di sumber ODPS, mode hash tidak dapat digunakan untuk penyimpanan Redis, dan pengecualian ini dilemparkan.

• Solusi:

  Jika Anda hanya ingin menggunakan dua kolom, konfigurasikan mode String Redis untuk penyimpanan. Jika Anda harus menggunakan mode hash, konfigurasikan minimal tiga kolom di sisi sumber.

• Gejala:

  Saat mengonfigurasi tugas sinkronisasi batch untuk membaca data dari penyimpanan file seperti OSS atau FTP, jika file dalam format CSV dan menggunakan beberapa karakter sebagai pemisah kolom (seperti |,, ##, atau ;;), tugas mungkin gagal dengan error data kotor. Di log waktu proses, Anda akan melihat error IndexOutOfBoundsException bersama dengan data kotor.

• Analisis akar penyebab:

  Reader csv bawaan ("fileFormat": "csv") di DataWorks memiliki keterbatasan saat memproses pemisah multi-karakter, yang menyebabkan pembagian kolom tidak akurat untuk baris data.

• Solusi:

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

  • Mode skrip: Ubah "fileFormat": "csv" menjadi "fileFormat": "text" dan atur pemisah dengan benar: "fieldDelimiter":"<multi-char delimiter>", "fieldDelimiterOrigin":"<multi-char delimiter>".

Sinkronisasi batch itu sendiri tidak membatasi jumlah file yang dibaca oleh plugin OSS Reader. Batasan utama berasal dari resource CU yang dikonsumsi oleh tugas. Membaca terlalu banyak file sekaligus dapat dengan mudah menyebabkan error kehabisan memori. Oleh karena itu, kami tidak menyarankan mengonfigurasi parameter object sebagai: *, untuk mencegah error OutOfMemoryError: Java heap space .

OSS Writer menulis nama file dengan mensimulasikan direktori menggunakan nama objek. OSS memiliki batasan pada nama objek. Saat menggunakan "object": "datax", objek yang ditulis dimulai dengan datax, dengan akhiran string acak ditambahkan. Jumlah file ditentukan oleh jumlah tugas pemisah aktual.

Jika Anda tidak memerlukan akhiran UUID acak, konfigurasikan "writeSingleObject" : "true". Untuk informasi lebih lanjut, lihat deskripsi parameter writeSingleObject di dokumentasi OSS Writer.

• Penyebab:

  AccessKey yang dikonfigurasi untuk sumber data tidak memiliki izin pada bucket.

• Solusi:

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

• Analisis akar penyebab:

  Parameter mapred.task.timeout mungkin diatur terlalu rendah, menyebabkan Hadoop menghentikan tugas dan membersihkan direktori sementara, membuat data sementara tidak tersedia.

• Solusi:

  Di bagian sumber data tugas sinkronisasi batch, jika Hive read methods diatur ke Read Data Based on Hive JDBC (Supports Conditional Filtering), atur nilai parameter mapred.task.timeout di Session Configuration, misalnya, mapred.task.timeout=600000.

• Pesan error:

  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 kemungkinan:

  Error terjadi karena volume data yang dikirimkan DataX ke DataHub dalam satu batch melebihi batas DataHub. Parameter konfigurasi utama yang memengaruhi volume data yang dikirimkan ke DataHub adalah:

  • maxCommitSize: Menentukan ukuran data buffer terakumulasi. Saat data terakumulasi mencapai maxCommitSize (dalam MB), data dikirimkan ke tujuan dalam satu batch. Defaultnya 1 MB (1.048.576 byte).

  • batchSize: Menentukan jumlah catatan data buffer terakumulasi untuk DataX-On-Flume. Saat jumlah catatan terakumulasi mencapai batchSize, data dikirimkan ke tujuan dalam satu batch.

• Solusi:

  Kurangi nilai parameter maxCommitSize dan batchSize.

Plugin ini peka terhadap huruf besar/kecil untuk nama kolom. Periksa konfigurasi kolom LogHub Reader.

Integrasi Data menggunakan waktu saat data masuk LogHub. Periksa konsol LogHub untuk memverifikasi apakah kolom metadata receive_time berada dalam rentang waktu yang dikonfigurasi untuk tugas.

Jika ini terjadi, edit secara manual konfigurasi kolom di UI.

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

Kolom output __time__ berasal dari log.getTime() dari setiap entri log, yang merepresentasikan waktu log sendiri. Kueri konsol SLS biasanya menggunakan rentang waktu kueri, pernyataan kueri, dan kolom indeks untuk statistik, umumnya berdasarkan waktu log __time__. Oleh karena itu, meskipun tugas sinkronisasi dan konsol menggunakan nilai waktu yang sama, rentang __time__ atau jumlah catatan mungkin berbeda jika kedua sisi menggunakan metrik waktu yang berbeda.

Skenario umum:

1. Saat pengumpulan atau pengiriman log tertunda, log historis diisi kembali, atau jam klien tidak akurat, waktu log __time__ mungkin lebih awal atau lebih lambat daripada waktu penerimaan sisi server SLS. Tugas sinkronisasi menentukan kursor berdasarkan waktu penerimaan sisi server, sedangkan konsol mengkueri berdasarkan __time__, yang mungkin menghasilkan hasil berbeda.

2. Saat data ditulis ke LogStore lain melalui transformasi data SLS, jika pernyataan transformasi tidak secara eksplisit mengatur __time__, __time__ log target biasanya mempertahankan waktu log sumber daripada waktu eksekusi transformasi. Dalam kasus ini, tugas sinkronisasi mungkin membaca batch data ini dalam rentang waktu saat transformasi menulis ke LogStore target. Namun, saat mengkueri konsol LogStore target berdasarkan waktu eksekusi transformasi atau rentang waktu saat ini, log ini mungkin tidak ditemukan. Anda perlu mengkueri berdasarkan rentang waktu aktual __time__ log.

3. Saat pernyataan kueri konsol, kolom indeks, rentang waktu, dan pernyataan penyaringan aturan (SPL) dalam tugas sinkronisasi tidak konsisten, jumlah catatan mungkin berbeda meskipun metrik waktu sama.

Saran troubleshooting:

1. Verifikasi apakah rentang waktu kueri konsol, pernyataan kueri, kolom indeks, dan waktu mulai/akhir serta pernyataan penyaringan aturan (SPL) dalam tugas sinkronisasi konsisten.

2. Sertakan kedua __time__ (waktu log) dan __tag__:__receive_time__ (bidang yang dapat diamati untuk waktu penerimaan sisi server SLS, yang memerlukan bidang ini ada di tag log) dalam konfigurasi column untuk membandingkan waktu log dengan waktu penerimaan sisi server.

3. Jika data berasal dari transformasi data SLS, periksa apakah pernyataan transformasi secara eksplisit mengatur __time__, dan sesuaikan rentang waktu kueri konsol di LogStore target berdasarkan __time__ aktual.

4. Jika rekonsiliasi berdasarkan waktu log diperlukan di hilir, lakukan filter atau agregasi berdasarkan __time__ setelah data ditulis ke tujuan.

Contoh: __time__ log sumber adalah 2026-06-01 10:00:00. Tugas transformasi data SLS menulis log ini ke LogStore target pada 2026-06-12 10:00:00 tanpa secara eksplisit memodifikasi __time__. __time__ log target tetap 2026-06-01 10:00:00. Jika waktu mulai dan akhir tugas mencakup 2026-06-12 10:00:00, tugas mungkin membaca log ini. Namun, saat mengkueri konsol LogStore target sekitar 2026-06-12 10:00:00 dengan __time__ sebagai filter, log ini mungkin tidak ditemukan. Dalam kasus ini, sesuaikan waktu kueri konsol sekitar 2026-06-01 10:00:00, atau atur secara eksplisit __time__ log target selama transformasi data sesuai kebutuhan.

Reader mencocokkan nama kolom dari bidang konten log yang ditarik aktual, pemetaan meta-field bawaan Reader, dan LogTag berdasarkan konfigurasi column. Nama kolom peka terhadap huruf besar/kecil. Jika tidak ditemukan kecocokan, null dikeluarkan tanpa error.

Penyebab umum meliputi:

1. Nama kolom yang dikonfigurasi di column memiliki huruf besar/kecil berbeda dari kunci bidang log asli.

2. Konsol menampilkan alias dari analisis kueri, bidang indeks, atau bidang yang diperluas JSON, yang berbeda dari kunci log asli yang sebenarnya diambil Reader.

3. Kolom sebenarnya berasal dari LogTag dan perlu dikonfigurasi sebagai __tag__:<tagKey>.

4. Setelah mengonfigurasi pernyataan penyaringan aturan (SPL) atau transformasi, nama bidang output tidak sepenuhnya cocok dengan konfigurasi column.

Saat troubleshooting, pertama-tama periksa kolom tabel sumber dan pratinjau data di halaman visual untuk mengonfirmasi bidang yang sebenarnya diidentifikasi Reader. Dalam mode skrip, Anda juga dapat sementara mengatur column ke ["*"] untuk melihat kunci bidang konten log aktual yang diambil Reader, lalu konfigurasikan column berdasarkan kunci asli.

Perilakunya sama dengan logika penulisan API: data di baris dan kolom yang sama ditimpa, dan data lain tetap tidak berubah.

Ambil pemetaan indeks ES menggunakan perintah curl dan ekstrak semua kolom dari pemetaan.

• Perintah shell untuk mengkueri:

  //es7
  curl -u username:password --request GET 'http://esxxx.elasticsearch.aliyuncs.com:9200/indexname/_mapping'
  //es6
  curl -u username:password --request GET 'http://esxxx.elasticsearch.aliyuncs.com:9200/indexname/typename/_mapping'

• Mengambil kolom dari hasil:

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

  Kolom dan definisi atribut di bawah properties dalam respons adalah semua kolom indeks. Misalnya, indeks di atas berisi tiga kolom: field1, field2, dan field3.

Anda dapat menambahkan parameter penjadwalan tanggal ke konfigurasi indeks untuk secara otomatis menghitung string indeks berdasarkan tanggal berbeda, memungkinkan perubahan otomatis nama indeks Elasticsearch Reader. Konfigurasi melibatkan tiga langkah: mendefinisikan parameter tanggal, mengonfigurasi parameter indeks, dan menyebarkan serta menjalankan tugas.

1. Definisikan parameter tanggal: Di pengaturan jadwal tugas sinkronisasi, tambahkan parameter untuk mendefinisikan parameter tanggal. Konfigurasi var1 berikut merepresentasikan waktu eksekusi tugas (hari ini), dan var2 merepresentasikan tanggal bisnis (hari sebelumnya).

2. Konfigurasikan parameter indeks: Beralih tugas ke mode skrip dan konfigurasikan indeks Elasticsearch Reader menggunakan format: ${variable_name}, seperti yang ditunjukkan di bawah.

   {
       "type": "job",
       "version": "2.0",
       "steps": [
           {
               "stepType": "elasticsearch",
               "parameter": {
                   "retryCount": 30,
                   "scroll": "10m",
                   "column": [
                       "col18",
                       "col17"
   
                   ],
                   "index": "esstress_1_${var1}_${var2}",
                   "pageSize": 100,
                   "sort": {
                       "_id": "asc"
                   },

3. Sebarkan dan jalankan tugas: Setelah verifikasi, kirim dan sebarkan tugas ke Operation Center, dan jalankan sebagai jadwal periodik atau tugas pengisian kembali data.

   1. Klik tombol Running with Parameters untuk langsung menjalankan tugas untuk verifikasi. Running with parameters menggantikan parameter sistem penjadwalan yang digunakan dalam konfigurasi tugas. Setelah eksekusi, periksa log untuk memverifikasi apakah indeks yang disinkronkan sesuai ekspektasi.

      Catatan

      Saat running with parameters, masukkan nilai parameter secara langsung untuk pengujian penggantian.

   2. Jika langkah sebelumnya diverifikasi sesuai ekspektasi, konfigurasi tugas selesai. Klik Save lalu Commit untuk mengirimkan tugas sinkronisasi ke lingkungan produksi.

      Untuk ruang kerja mode standar, klik Deploy untuk membuka Deployment Center untuk menyebarkan tugas sinkronisasi ke lingkungan produksi.

4. Hasil: Berikut menunjukkan konfigurasi dan hasil indeks waktu proses aktual.

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

   Indeks waktu proses diselesaikan menjadi: esstress_1_20230106_20230105.

   ],
   "full":false,
   "gmtCreate":"2022-07-18 14:47:18",
   "gmtModified":"2022-07-18 14:47:18",
   "index":"esstress_1_20230106_20230105",
   "instanceId":"es-cn-2r42se1je001zwmt0",
   "ownerId":"1224800975333052",
   "pageSize":100,
   "password":"********",
   "privateNetworkIpWhiteList":[
       "0.0.0.0/0"
   ],

Untuk menyinkronkan properti bidang objek, Anda hanya dapat menggunakan mode skrip. Dalam mode skrip, konfigurasikan multi sebagai berikut, dan tentukan kolom menggunakan format attribute.sub-attribute.

"multi":{
   "multi":true 
 }

Lihat contoh berikut untuk konfigurasi:

#Contoh:
##Data di Elasticsearch
"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 Writer: 1 baris dengan 3 kolom, urutan kolom sesuai 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 ekstra yang ditampilkan sebelum dan sesudah karakter adalah masalah tampilan di Kibana. Data aktual tidak memiliki tanda kutip ganda di awal dan akhir. Gunakan perintah curl atau Postman untuk melihat data aktual. Perintah curl untuk mengambil data adalah sebagai berikut:

   //es7
   curl -u username:password --request GET 'http://esxxx.elasticsearch.aliyuncs.com:9200/indexname/_mapping'
   //es6
   curl -u username:password --request GET 'http://esxxx.elasticsearch.aliyuncs.com:9200/indexname/typename/_mapping'

2. Anda dapat mengonfigurasi tipe kolom tulis ES sebagai nested untuk menyinkronkan data string tipe JSON dari ODPS ke ES dalam format nested. Contoh berikut menyinkronkan kolom name ke ES dalam format nested.

   • Konfigurasi sinkronisasi: Konfigurasikan tipe name sebagai nested.

   • Hasil sinkronisasi: name adalah tipe objek nested.

     "total": {
         "value": 1,
         "relation": "eq"
     },
     "max_score": 1.0,
     "hits": [
         {
             "_index": "test",
             "_type": "_doc",
             "_id": "bb5oqoUBlqHPyI16REEQ",
             "_score": 1.0,
             "_source": {
                 "name": [
                     {
                         "fields1": "value"
                     }
                 ]
             }
         }
     ]
     }

Ada dua metode konfigurasi untuk menulis tipe array ke ES. Pilih metode sinkronisasi yang sesuai berdasarkan format data sumber.

• Tulis ke ES sebagai tipe array dengan mengurai data sumber sebagai JSON. Misalnya, jika data sumber adalah "[1,2,3,4,5]", konfigurasikan json_array=true untuk mengurai data sumber dan menulisnya ke kolom ES sebagai array. Konfigurasikan ColumnList dengan json_array=true.

  • Konfigurasi mode wizard。

  • Konfigurasi mode skrip:

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

• Tulis ke ES sebagai tipe array dengan mengurai data sumber dengan pemisah. Misalnya, jika data sumber adalah "1,2,3,4,5", konfigurasikan pemisah splitter="," untuk mengurai dan menulis data ke kolom ES sebagai array.

  • Batasan:

    • Tugas hanya mendukung satu pemisah. Splitter bersifat global unik dan tidak mendukung pemisah berbeda untuk kolom array berbeda. Misalnya, untuk kolom sumber col1="1,2,3,4,5" , col2="6-7-8-9-10", splitter tidak dapat dikonfigurasi secara terpisah untuk setiap kolom.

    • Splitter dapat dikonfigurasi sebagai ekspresi reguler. Misalnya, jika nilai kolom sumber adalah "6-,-7-,-8+,*9-,-10", Anda dapat mengonfigurasi splitter:".,." dan ini didukung dalam mode wizard.

  • Konfigurasi mode wizard: splitter: default "-,-"

  • Konfigurasi mode skrip:

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

• Analisis akar penyebab:

  HttpClient menetapkan bahwa setiap kali koneksi dibuat, permintaan tanpa autentikasi dilakukan terlebih dahulu. Setelah server mengembalikan persyaratan autentikasi (menentukan metode autentikasi berdasarkan respons), permintaan terautentikasi kemudian dilakukan. Karena setiap penulisan data ES memerlukan pembuatan koneksi, setiap penulisan data menghasilkan satu permintaan tanpa autentikasi, yang kemudian dicatat dalam log audit.

• Solusi:

  Tambahkan konfigurasi "preemptiveAuth":true dalam mode skrip.

Ada dua metode untuk mengonfigurasi penulisan tanggal. Pilih yang sesuai berdasarkan kebutuhan Anda.

• Tulis langsung ke kolom Date ES berdasarkan konten yang dibaca dari Reader:

  • Konfigurasikan origin:true untuk menulis konten yang dibaca langsung ke ES.

  • Konfigurasikan "format" untuk menentukan atribut format untuk kolom saat membuat pemetaan melalui penulisan ES.

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

• Konversi zona waktu: Jika Anda memerlukan Integrasi Data untuk melakukan konversi zona waktu, tambahkan parameter Timezone.

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

• tipe:version dikonfigurasi, tetapi ES tidak mendukung menentukan versi eksternal.

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

• Solusi:

  Hapus konfigurasi "type":"version". Elasticsearch Writer tidak mendukung spesifikasi versi eksternal.

• Analisis akar penyebab:

  Elasticsearch Reader tidak dapat mengurai format tanggal kolom tipe tanggal karena pemetaan untuk kolom tanggal ES yang sesuai tidak memiliki format yang dikonfigurasi.

• Solusi:

  • Konfigurasikan parameter dateFormat dengan format yang sama seperti format kolom tanggal ES, menggunakan "||" sebagai pemisah. Format harus mencakup semua format tipe tanggal. Contoh:

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

  • Atur format pemetaan untuk semua kolom tanggal di database ES.

• Analisis akar penyebab:

  Karena batasan kata kunci fastjson, indeks atau kolom mungkin berisi kata kunci seperti $ref.

• Solusi:

  Elasticsearch Reader tidak mendukung sinkronisasi indeks yang berisi kata kunci $ref di nama kolom. Untuk informasi lebih lanjut, lihat Elasticsearch Reader.

• Analisis akar penyebab:

  Ini memicu mekanisme kunci optimis ES. Nomor versi saat ini seharusnya satu nilai, tetapi nomor versi yang diteruskan oleh perintah pembaruan berbeda, menyebabkan konflik versi. Selama pembaruan, orang lain menghapus data indeks.

• Solusi:

  1. Periksa apakah operasi penghapusan data sedang terjadi.

  2. Ubah metode sinkronisasi tugas dari Update ke Index.

• Analisis akar penyebab:

  Saat mengonfigurasi atribut lanjutan seperti similarity dan properties untuk kolom, other_params diperlukan agar plugin mengenalinya.

  "parameter":{
          "__datasource__type":"elasticsearch",
          "actionType":"index",
          "aliasMode":"append",
          "batchSize":1024,
          "cleanup":false,
          "column":[
              {
                  "name":"id",
                  "type":"long"
              },
              {
                  "name":"dim1_code",
                  "type":"keyword"
              },
              {
                  "analyzer":"china",
                  "name":"dim1_name",
                  "similarity":"len_similarity",
                  "type":"text"
              },
              {
                  "analyzer":"china",
                  "name":"dim1_val",
                  "similarity":"len_similarity",
                  "type":"text"
              },
              {
                  "name":"dim1_sort",
                  "type":"long"
              }

• Solusi:

  Konfigurasikan other_params dalam konfigurasi kolom, dan tambahkan similarity di dalam other_params, sebagai berikut:

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

• Analisis akar penyebab:

  Saat ini, sinkronisasi batch menulis ke Elasticsearch tidak mendukung tipe dense_vector. Hanya tipe berikut yang didukung:

  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 tipe yang tidak didukung oleh Elasticsearch Writer, tangani sebagai berikut:

  • Kami tidak menyarankan menggunakan Elasticsearch Writer untuk membuat pemetaan indeks. Gunakan pemetaan kustom sebagai gantinya.

  • Ubah tipe yang sesuai menjadi NESTED.

  • Modifikasi konfigurasi menjadi: dynamic = true, 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:

  Settings hanya berlaku saat indeks dibuat, yang mencakup dua kasus: indeks tidak ada, atau cleanup=true. Saat cleanup=true, konfigurasi Settings tidak perlu menyertakan "index".

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

• Analisis akar penyebab:

  Untuk tipe nested, Elasticsearch Writer hanya menggunakan pemetaan tingkat atas dan membiarkan ES menyesuaikan otomatis tipe kompleks nested. Perubahan tipe atribut menjadi text dengan penambahan fields:keyword adalah perilaku penyesuaian otomatis ES dan tidak memengaruhi penggunaan ES. Jika Anda memerlukan format pemetaan spesifik, lihat Elasticsearch Writer.

• Solusi:

  Buat pemetaan indeks ES yang diharapkan sebelum sinkronisasi, lalu atur cleanup ke false dalam tugas sinkronisasi ES dan jalankan tugas.

Kafka Reader membaca data dalam batch. Dalam satu batch data, jika ada catatan yang melebihi endDateTime, sinkronisasi berhenti. Namun, data yang melebihi endDateTime dalam batch tersebut tetap ditulis ke sumber data tujuan.

• Anda juga dapat menggunakan konfigurasi skipExceedRecord untuk menentukan apakah akan menyinkronkan data yang melebihi. Untuk penggunaan detail, lihat Kafka Reader. [Mengatur ini untuk tidak menyinkronkan tidak disarankan karena dapat menyebabkan kehilangan data.]

• Anda dapat mengonfigurasi parameter max.poll.records Kafka untuk menentukan jumlah data yang ditarik dalam setiap batch. Dikombinasikan dengan konkurensi, Anda dapat mengontrol jumlah data yang mungkin melebihi batas. Volume data yang melebihi < max.poll.records × konkurensi.

• Analisis akar penyebab:

  Saat volume data kecil atau data tidak merata, beberapa partisi Kafka mungkin tidak memiliki data baru yang masuk atau data baru mungkin tidak mencapai offset akhir yang ditentukan. Karena kondisi keluar tugas memerlukan semua partisi mencapai offset akhir yang ditentukan, partisi "idle" ini tidak dapat memenuhi kondisi, menghalangi seluruh tugas menyelesaikan secara normal.

• Solusi:

  Atur kebijakan akhir sinkronisasi ke 1 menit tanpa membaca data baru (dalam mode skrip, atur stopWhenPollEmpty ke true dan stopWhenReachEndOffset ke true). Tugas keluar setelah membaca data offset terbaru dari semua partisi, menghindari berjalan idle. Namun, catatan dengan timestamp lebih awal dari offset akhir yang dikonfigurasi yang ditulis setelah tugas berakhir tidak akan dikonsumsi.

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

1. Konfigurasi OTS Writer harus mencakup dua persyaratan berikut:

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

2. Nama kolom kunci utama auto-increment tidak boleh dikonfigurasi di OTS Writer.

3. Jumlah entri primaryKey + jumlah entri column yang dikonfigurasi di OTS Writer harus sama dengan jumlah kolom dalam data OTS Reader hulu.

Contoh: Catatan data memiliki tiga tag: [phone=xiaomi, RAM=8G, camera=LEICA].

• Contoh ekspor data (OTS Reader)

  • Jika Anda ingin menggabungkan tag di atas menjadi satu kolom untuk diekspor, konfigurasikan sebagai berikut:

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

    DataWorks mengekspor tag sebagai satu kolom data dalam format berikut:

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

  • Jika Anda ingin mengekspor tag phone dan tag camera sebagai kolom terpisah, konfigurasikan sebagai berikut:

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

    DataWorks mengekspor dua kolom data dalam format berikut:

    xiaomi, LEICA

• Contoh impor data (OTS Writer)

  Sumber data hulu (Reader) memiliki dua kolom data:

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

  • Kolom lain berisi: 6499.

  Untuk menambahkan kedua kolom ke tag, format bidang tag yang diharapkan setelah penulisan adalah sebagai berikut:Konfigurasikan sebagai berikut:

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

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

  • Konfigurasi kolom kedua mengimpor price=6499 secara individual ke bidang tag.

Jika nama tabel Anda mengikuti pola reguler, seperti orders_20170310, orders_20170311, dan orders_20170312, di mana tabel dibedakan berdasarkan tanggal dan memiliki struktur yang sama, Anda dapat menggunakan parameter penjadwalan (Konfigurasi tugas sinkronisasi dalam mode skrip) untuk menyesuaikan nama tabel dan secara otomatis membaca data tabel hari sebelumnya dari database sumber setiap pagi hari.

Dalam mode skrip, ubah nama tabel sumber menjadi variabel, seperti orders_${tablename}. Karena tabel dibedakan berdasarkan tanggal dan Anda perlu membaca data hari sebelumnya setiap hari, tetapkan nilai variabel dalam konfigurasi parameter tugas sebagai tablename=${yyyymmdd}.

Buka halaman konfigurasi tugas sinkronisasi, modifikasi pemetaan kolom untuk memperbarui kolom yang berubah dalam konfigurasi tugas, lalu kirim ulang dan jalankan tugas agar perubahan berlaku.

Saat mengonfigurasi node sinkronisasi batch, bagian Sumber secara default hanya menampilkan 25 tabel pertama dari sumber data yang dipilih. Jika ada lebih banyak tabel, Anda dapat memasukkan nama tabel untuk mencari atau menggunakan mode skrip untuk pengembangan.

• Penyebab error: Konfigurasi kolom berisi kata kunci yang dicadangkan, atau konfigurasi kolom berisi kolom yang dimulai dengan angka.

• Solusi: Beralih tugas sinkronisasi Integrasi Data ke mode skrip dan escape kolom khusus dalam konfigurasi kolom. Untuk mengonfigurasi tugas dalam mode skrip, lihat Konfigurasi tugas sinkronisasi dalam mode skrip.

  • Karakter escape untuk MySQL adalah `keyword`.

  • Karakter escape untuk Oracle dan PostgreSQL adalah "keyword".

  • Karakter escape untuk SQL Server adalah [keyword].

  Contoh MySQL:

  {
      "stepType": "mysql",
      "parameter": {
          "envType": 0,
          "datasource": "wpw_test_mysql",
          "column": [
              "id",
              "`order`",
              "`add`"
          ],
          "connection": [
              {
                  "datasource": "wpw_test_mysql",
                  "table": [
                      "abc"
                  ]
              }

• Mengambil sumber data MySQL sebagai contoh:

  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 tabel: create view v_aliyun as select `table` as col1,msg as col2 from aliyun;

     Catatan

     • table adalah kata kunci MySQL. Selama sinkronisasi data, kode yang digabungkan menyebabkan error. Buat view dan berikan alias ke kolom tabel.

     • Kami tidak menyarankan menggunakan kata kunci sebagai nama kolom tabel.

  3. Setelah menjalankan pernyataan di atas, gunakan view v_aliyun alih-alih tabel aliyun saat mengonfigurasi tugas sinkronisasi.

Error ini mungkin terjadi karena pemetaan kolom tugas sinkronisasi tidak dikonfigurasi dengan benar, atau plugin tidak memiliki kolom yang dikonfigurasi dengan benar.

1. Periksa apakah pemetaan kolom dikonfigurasi.

2. Periksa apakah plugin memiliki kolom yang dikonfigurasi dengan benar.

• Gejala:

  Saat Anda mengklik Preview Data, muncul pesan serupa berikut, menunjukkan bahwa ukuran byte kolom melebihi batas.

  Pesan error adalah "Maximum column length of 1,000 exceeded in column 6 in record 1. Set the SafetySwitch property to false if you're expecting column lengths greater than 100,000 characters to avoid this error."

• Penyebab: Untuk mencegah OOM, layanan sumber data memeriksa panjang kolom saat memproses permintaan pratinjau data. Jika satu kolom melebihi 1000 byte, pesan di atas muncul. Pesan ini tidak memengaruhi eksekusi tugas aktual. Anda dapat mengabaikan error ini dan menjalankan tugas sinkronisasi batch secara langsung.

  Catatan

  Jika file ada dan konektivitas normal, situasi berikut juga dapat menyebabkan pratinjau data gagal:

  • Satu baris dalam file melebihi batas ukuran byte 10 MB. Dalam kasus ini, tidak ada data yang ditampilkan, mirip dengan pesan di atas.

  • Satu baris dalam file melebihi batas jumlah kolom 1000 kolom. Dalam kasus ini, hanya 1000 kolom pertama yang ditampilkan, dengan pesan ditunjukkan di kolom ke-1001.

TTL diatur di tingkat tabel. Tidak ada opsi TTL dalam konfigurasi tugas sinkronisasi.

Sinkronisasi berbasis API tidak mendukung penggunaan fungsi sisi sumber. Proses data menggunakan fungsi sisi sumber terlebih dahulu sebelum mengimpor.