DataWorks：FAQ sinkronisasi offline

• Jika pengujian konektivitas sebelumnya berhasil, jalankan kembali untuk memastikan bahwa kelompok sumber daya dan database masih terhubung. Pastikan tidak ada perubahan yang dilakukan pada database.

• Periksa apakah kelompok sumber daya yang digunakan untuk pengujian konektivitas sama dengan yang digunakan untuk eksekusi tugas.

  Untuk melihat kelompok sumber daya tempat tugas berjalan:

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

  • Jika tugas berjalan di kelompok 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 terjadwal gagal secara intermiten di pagi hari tetapi berhasil saat dijalankan ulang, periksa beban database pada saat terjadi kesalahan.

Tugas sinkronisasi offline dapat gagal secara intermiten jika konfigurasi daftar putih tidak lengkap. Periksa apakah daftar putih database telah dikonfigurasi sepenuhnya.

Saat Anda menggunakan kelompok sumber daya eksklusif untuk Integrasi Data:

• Jika Anda menambahkan alamat IP antarmuka jaringan elastis (ENI) dari kelompok sumber daya eksklusif untuk Integrasi Data ke daftar putih sumber data, Anda harus memperbarui daftar putih setelah melakukan penskalaan keluar kelompok sumber daya. Tambahkan alamat IP ENI dari kelompok sumber daya yang diskalakan ke daftar putih sumber data.

• Untuk menghindari pembaruan daftar putih setelah penskalaan keluar kelompok sumber daya, Anda dapat menambahkan blok CIDR vSwitch dari kelompok sumber daya eksklusif untuk Integrasi Data ke daftar putih database. Untuk informasi lebih lanjut, lihat Tambahkan daftar putih.

Saat Anda menggunakan kelompok sumber daya Serverless: Untuk informasi lebih lanjut, lihat Tambahkan daftar putih untuk memeriksa konfigurasi daftar putih kelompok sumber daya dan memastikan pengaturan jaringan benar.

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

• Penyebab yang mungkin:

  Tingkat konkurensi diatur terlalu tinggi, sehingga menyebabkan sumber daya tidak mencukupi.

• Solusi:

  Kurangi tingkat konkurensi tugas sinkronisasi offline.

  • Saat mengonfigurasi tugas sinkronisasi offline di antarmuka tanpa kode, kurangi nilai Maximum Concurrency di pengaturan kontrol saluran. Untuk informasi lebih lanjut, lihat Konfigurasi node sinkronisasi di antarmuka tanpa kode.

  • Saat mengonfigurasi tugas sinkronisasi offline di editor kode, kurangi nilai parameter concurrent di pengaturan kontrol saluran. Untuk informasi lebih lanjut, lihat Konfigurasi node sinkronisasi di editor kode.

Untuk mengatasi kesalahan ini, lakukan langkah-langkah berikut:

1. Jika konfigurasi plugin mendukung parameter seperti `batchSize` atau `maxFileSize`, kurangi nilainya.

   Untuk memeriksa plugin mana yang mendukung parameter ini, buka Sumber data yang didukung dan plugin reader dan writer dan klik plugin terkait untuk melihat detail parameternya.

2. Kurangi tingkat konkurensi.

   • Saat Anda mengonfigurasi tugas sinkronisasi offline di antarmuka tanpa kode, kurangi nilai Maximum Concurrency di pengaturan kontrol saluran. Untuk informasi lebih lanjut, lihat Konfigurasi node sinkronisasi di antarmuka tanpa kode.

   • Jika Anda mengonfigurasi tugas sinkronisasi offline di editor kode, kurangi nilai parameter concurrent di pengaturan kontrol saluran. Untuk informasi lebih lanjut, lihat Konfigurasi node sinkronisasi di editor kode.

3. Untuk sinkronisasi file, seperti menyinkronkan file dari OSS, kurangi jumlah file yang akan dibaca.

4. Di bagian Running Resources pada konfigurasi tugas, tingkatkan nilai Resource Consumption (CU) ke tingkat yang sesuai untuk menghindari memengaruhi tugas lain yang sedang berjalan.

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

• Kemungkinan penyebab: Integrasi Data tidak mengizinkan instance berbeda dari node tugas sinkronisasi yang sama berjalan secara bersamaan. Artinya, beberapa tugas sinkronisasi yang memiliki konfigurasi JSON yang sama tidak dapat berjalan pada waktu yang sama. Misalnya, tugas sinkronisasi dijadwalkan berjalan setiap 5 menit dan mengalami penundaan upstream. Pada pukul 00:05, instance untuk 00:00 dan instance untuk 00:05 dipicu. Hal ini dapat menyebabkan salah satu instance gagal. Konflik juga dapat terjadi jika operasi pengisian ulang data atau pengulangan ulang dilakukan saat instance tugas sedang berjalan.

• Solusi: Atur waktu eksekusi instance agar tidak bertumpang tindih. Untuk tugas yang berjalan setiap jam atau menit, Anda dapat mengatur dependensi mandiri. Hal ini memastikan bahwa instance untuk siklus saat ini dimulai hanya setelah instance untuk siklus sebelumnya selesai. Untuk versi sebelumnya dari Pengembangan Data, lihat Dependensi mandiri. Untuk versi baru Pengembangan Data, lihat Pilih jenis dependensi (dependensi lintas siklus).

• Pesan kesalahan: Tugas sinkronisasi data gagal dengan kesalahan MongoDBReader$Task - operation exceeded time limitcom.mongodb.MongoExecutionTimeoutException: operation exceeded time limit.

• Kemungkinan penyebab: Jumlah data yang ditarik terlalu besar.

• Solusi:

  • Tingkatkan tingkat konkurensi.

  • Kurangi BatchSize.

  • Di pengaturan parameter Reader, tambahkan konfigurasi cursorTimeoutInMs. Coba atur nilai yang lebih besar, misalnya 3.600.000 ms.

• Kesalahan baca

  • Gejala:

    Saat data dibaca, terjadi kesalahan 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 yang mungkin:

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

  • Solusi:

    • Periksa apakah kondisi filter where diatur dan pastikan bahwa indeks telah ditambahkan ke bidang yang difilter.

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

    • Temukan pernyataan SQL yang memblokir di log dan konsultasikan dengan administrator basis data (DBA) untuk menyelesaikan masalah.

• Kesalahan tulis

  • Gejala:

    Saat data ditulis, terjadi kesalahan 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 yang mungkin:

    Kueri lambat menyebabkan timeout soket. Timeout soket default untuk koneksi TDDL adalah 12 detik. Jika pernyataan SQL memerlukan waktu lebih dari 12 detik untuk dieksekusi di sisi MySQL tanpa mengembalikan hasil, kesalahan 4614 dilaporkan. Kesalahan ini dapat terjadi secara intermiten ketika volume data besar atau server sibuk.

  • Solusi:

    • Jalankan ulang tugas sinkronisasi setelah database stabil.

    • Hubungi administrator basis data untuk menyesuaikan periode timeout.

Kemungkinan penyebab 2: Tugas sedang menunggu sumber daya eksekusi Integrasi Data

Solusi 2: Jika log menunjukkan status `WAIT` yang berkepanjangan, kelompok sumber daya eksklusif untuk Integrasi Data yang digunakan oleh tugas tidak memiliki cukup sumber daya konkuren yang tersedia untuk menjalankan tugas. Untuk informasi lebih lanjut tentang penyebab dan solusi, lihat Mengapa tugas Integrasi Data selalu menunjukkan status "wait"?.

• Contoh skenario

  Pernyataan 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. Akibatnya, MaxCompute harus menunggu lama sebelum dapat dieksekusi.

• Analisis penyebab

  Saat mengkueri dengan klausa `WHERE`, kolom createTime tidak memiliki indeks, yang menyebabkan pemindaian tabel penuh.

• Solusi

  Gunakan kolom yang diindeks dalam klausa where untuk meningkatkan kinerja. Anda juga dapat menambahkan indeks ke kolom yang diperlukan.

Untuk versi sebelumnya dari Pengembangan Data:

Anda dapat memodifikasi kelompok sumber daya untuk debugging di halaman detail tugas sinkronisasi offline di DataStudio. Anda juga dapat memodifikasi kelompok sumber daya eksekusi Integrasi Data untuk penjadwalan tugas di Operation Center. Untuk informasi lebih lanjut, lihat Beralih kelompok sumber daya Integrasi Data.

Untuk versi baru Pengembangan Data:

Anda dapat memodifikasi kelompok sumber daya yang digunakan untuk debugging tugas Integrasi Data di DataStudio. Anda juga dapat memodifikasi kelompok sumber daya eksekusi untuk tugas Integrasi Data terjadwal di Operation Center. Untuk informasi lebih lanjut, lihat O&M kelompok sumber daya.

Definisi data kotor: Satu catatan data yang menyebabkan pengecualian saat ditulis ke sumber data target dianggap sebagai data kotor. Data apa pun yang gagal ditulis diklasifikasikan sebagai data kotor.

Jumlah catatan data kotor diakumulasi selama eksekusi tugas. Jika jumlah ini melebihi batas data kotor yang ditentukan, tugas segera dihentikan.

• Retensi data: Data yang berhasil ditulis ke tujuan sebelum tugas dihentikan tetap disimpan. Tidak ada operasi rollback yang dilakukan.

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

• Gejala:

  Jika data mencakup emoji, kesalahan data kotor dapat dilaporkan 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"} .

• Kemungkinan penyebab:

  • Encoding database tidak diatur ke `utf8mb4`, yang menyebabkan kesalahan saat menyinkronkan emoji.

  • Data sumber itu sendiri rusak.

  • Database dan klien menggunakan set karakter yang berbeda.

  • Browser menggunakan set karakter yang berbeda, yang menyebabkan kegagalan pratinjau atau teks rusak.

• Solusi:

  Pilih solusi yang sesuai berdasarkan penyebab teks rusak:

  • Jika data mentah Anda rusak, proses data mentah sebelum menjalankan tugas sinkronisasi.

  • Jika database dan klien menggunakan set karakter yang tidak konsisten, satukan set karakter terlebih dahulu.

  • Jika browser menggunakan set karakter yang tidak konsisten dengan set karakter database atau klien, satukan set karakter terlebih dahulu, lalu pratinjau data.

  Anda dapat mencoba operasi berikut:

  1. Untuk sumber data yang ditambahkan menggunakan format Konektivitas Basis Data Java (JDBC), modifikasi string koneksi untuk menggunakan `utf8mb4`: jdbc:mysql://xxx.x.x.x:3306/database?com.mysql.jdbc.faultInjection.serverCharsetIndex=45.

  2. Untuk sumber data yang ditambahkan menggunakan ID instans, tambahkan parameter setelah nama database: database?com.mysql.jdbc.faultInjection.serverCharsetIndex=45.

  3. Modifikasi format encoding database yang relevan ke `utf8mb4`. Misalnya, Anda dapat memodifikasi format encoding database RDS di konsol RDS.

     Catatan

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

Saat DataWorks membuat tabel target, hanya nama kolom, tipe data, dan komentar dari tabel sumber yang dipertahankan. Nilai default tabel sumber atau kendala seperti kendala `NOT NULL` dan indeks tidak dipertahankan.

Tidak. Tugas integrasi offline tidak mendukung penggunaan kunci utama komposit sebagai kunci shard.

Jika Anda mengalami masalah kualitas data setelah sinkronisasi data selesai, lihat Memecahkan masalah kualitas data dalam sinkronisasi offline untuk pemecahan masalah terperinci.

T: Bagaimana cara menangani kesalahan "Task have SSRF attacks"?

Penyebab: Untuk memastikan keamanan cloud, DataWorks melarang tugas mengakses langsung alamat jaringan internal di lingkungan cloud menggunakan alamat IP publik. Langkah keamanan ini dipicu ketika URL yang mengarah ke alamat IP internal atau nama domain VPC dimasukkan dalam konfigurasi plugin, seperti HTTP Reader.

Solusi:

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

• Untuk mengakses sumber data internal secara aman, beli kelompok sumber daya Serverless (disarankan) atau kelompok sumber daya eksklusif untuk Integrasi Data dan konfigurasi konektivitas jaringan VPC.

Untuk tugas yang berjalan di sumber data internal, hentikan penggunaan kelompok sumber daya publik. Sebagai gantinya, beralihlah ke kelompok sumber daya Serverless yang aman dan andal (disarankan) atau kelompok sumber daya eksklusif untuk Integrasi Data.

Setelah Anda beralih tugas sinkronisasi ke editor kode, tambahkan item 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 tipe `DATE` sumber (tanpa waktu) dikonversi ke teks.

• `datetimeFormatInNanos` menentukan format tanggal yang digunakan saat tipe `DATETIME` atau `TIMESTAMP` sumber (dengan waktu) dikonversi ke teks, dengan presisi hingga milidetik.

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

2. Anda dapat menggunakannya dengan parameter penjadwalan, seperti '${bizdate}'. Untuk informasi lebih lanjut tentang cara menggunakan parameter penjadwalan, lihat Format parameter penjadwalan yang didukung.

3. Anda dapat memasukkan nama kolom partisi yang ingin Anda sinkronkan, seperti `pt`.

4. Jika nilai yang Anda masukkan tidak dapat diuraikan, tipe ditampilkan sebagai 'Custom'.

5. Anda tidak dapat mengonfigurasi fungsi ODPS.

6. Jika kolom yang ditambahkan secara manual ditampilkan sebagai kustom, seperti kolom partisi MaxCompute atau kolom yang tidak dipratinjau dalam data LogHub, eksekusi tugas tidak terpengaruh.

Di daftar pemetaan bidang, di bawah Bidang tabel sumber, klik Add Row atau Add Field. Masukkan nama kolom partisi, seperti pt, dan konfigurasikan pemetaannya ke bidang tabel target.

Dengan mengonfigurasi MaxCompute Writer, Anda dapat melakukan operasi yang tidak didukung MaxCompute, seperti penyaringan kolom, pengurutan ulang, dan pengisian null. Misalnya, jika daftar bidang yang akan diimpor mencakup semua bidang, Anda dapat mengonfigurasinya sebagai "column": ["*"].

Jika tabel MaxCompute memiliki tiga bidang, `a`, `b`, dan `c`, dan Anda ingin menyinkronkan hanya bidang `c` dan `b`, Anda dapat mengonfigurasi kolom sebagai "column": ["c","b"]. Artinya, kolom pertama dan kedua dari reader diimpor ke bidang `c` dan `b` tabel MaxCompute, dan bidang `a` di baris yang baru dimasukkan ke tabel MaxCompute diatur ke null.

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

MaxCompute Writer hanya mendukung penulisan data ke partisi tingkat terakhir. Tidak mendukung fitur seperti perutean partisi berdasarkan bidang tertentu. Misalnya, jika tabel memiliki tiga tingkat partisi, konfigurasi partisi harus secara eksplisit menentukan penulisan ke partisi tingkat ketiga. Misalnya, untuk menulis data ke partisi tingkat ketiga tabel, Anda dapat mengonfigurasinya sebagai pt=20150101, type=1, biz=2, tetapi tidak sebagai pt=20150101, type=1 atau pt=20150101.

MaxCompute Writer memastikan idempotensi penulisan saat Anda mengonfigurasi "truncate": true. Artinya, jika operasi penulisan gagal dan tugas dijalankan lagi, MaxCompute Writer menghapus data sebelumnya dan mengimpor data baru untuk memastikan konsistensi data setelah setiap pengulangan ulang. Jika tugas terganggu oleh pengecualian lain selama eksekusi, atomisitas data tidak dapat dijamin. Data tidak dikembalikan atau dijalankan ulang secara otomatis. Anda harus menggunakan fitur idempotensi dan menjalankan ulang tugas untuk memastikan integritas data.

• Pesan kesalahan:

  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:

  Sinkronisasi offline menggunakan perintah Tunnel MaxCompute untuk mengunggah dan mengunduh data. Siklus hidup sesi Tunnel di server adalah 24 jam. Oleh karena itu, jika tugas sinkronisasi offline berjalan lebih dari 24 jam, tugas gagal dan berhenti. Untuk informasi lebih lanjut tentang Tunnel, lihat Petunjuk.

• Solusi:

  Tingkatkan tingkat konkurensi tugas sinkronisasi offline dan rencanakan jumlah data yang akan disinkronkan untuk memastikan tugas dapat diselesaikan dalam waktu 24 jam.

• Pesan kesalahan:

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

• Kemungkinan penyebab:

  • Kemungkinan penyebab 1: Pengecualian tipe data. Data sumber tidak sesuai dengan spesifikasi tipe data ODPS. Misalnya, Anda mencoba menulis nilai `4.2223` ke bidang tipe data ODPS `decimal(18,10)`.

  • Kemungkinan penyebab 2: Pengecualian blok atau komunikasi ODPS.

• Solusi:

  Konversi data ke tipe data yang sesuai dengan spesifikasi tipe data.

Anda dapat mengonfigurasi ini dengan mengikuti petunjuk di Menyinkronkan tabel ter-shard.

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

• Penyebab:

  • `net_read_timeout`: DataX membagi data dari RDS for MySQL menjadi beberapa pernyataan pengambilan data SQL (`SELECT`) yang sama berdasarkan `SplitPk`. Saat waktu eksekusi pernyataan SQL melebihi waktu eksekusi maksimum yang diizinkan di sisi RDS, kesalahan ini terjadi.

  • `net_write_timeout`: Periode timeout untuk menunggu pengiriman blok ke klien terlalu singkat.

• Solusi:

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

• Saran:

  Jika tugas dapat dijalankan ulang, atur tugas untuk dijalankan ulang otomatis saat terjadi kesalahan.

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

Penyebab:

Nilai default untuk parameter wait_timeout di MySQL adalah 8 jam. Jika data masih diambil saat waktu ini tercapai, tugas sinkronisasi terganggu.

Solusi:

Modifikasi file konfigurasi MySQL my.cnf (atau my.ini di Windows). Di bawah modul MySQL, tambahkan parameter berikut (dalam detik): wait_timeout=2592000 interactive_timeout=2592000. Kemudian, mulai ulang dan masuk ke MySQL lalu jalankan pernyataan berikut untuk memeriksa apakah pengaturan berhasil: 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, atur tugas ke Jalankan Ulang saat Terjadi Kesalahan. Untuk informasi lebih lanjut, lihat Konfigurasi properti waktu.

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

• Kemungkinan penyebab: Hal ini terjadi karena menarik data dari database memerlukan waktu lama. Tingkatkan nilai parameter max_standby_archive_delay dan max_standby_streaming_delay. Untuk informasi lebih lanjut, lihat Peristiwa Server Cadangan.

Jika menghubungkan ke Amazon RDS mengembalikan Host is blocked, Anda perlu menonaktifkan pemeriksaan kesehatan load balancer Amazon. Setelah Anda menonaktifkannya, masalah pemblokiran tidak lagi dilaporkan.

Kesalahan terjadi saat Anda menambahkan sumber data MongoDB dengan pengguna root karena Anda harus menggunakan nama pengguna yang dibuat di database tabel yang perlu Anda sinkronkan. Anda tidak dapat menggunakan pengguna root.

Sebagai contoh, untuk mengimpor tabel `name`, dan tabel `name` berada di database `test`, nama database di sini harus `test`, dan Anda harus menggunakan nama pengguna pengguna yang dibuat di database `test`.

Anda dapat menggunakan node penugasan untuk terlebih dahulu memproses waktu tipe tanggal menjadi timestamp dan menggunakan nilai ini sebagai parameter input untuk sinkronisasi data MongoDB. Untuk informasi lebih lanjut, lihat Cara melakukan sinkronisasi inkremental pada bidang tipe timestamp di MongoDB?

Anda perlu mengatur zona waktu di konfigurasi MongoDB Reader. Untuk informasi lebih lanjut, lihat MongoDB Reader.

Anda dapat memulai ulang tugas setelah periode waktu tertentu dengan kondisi kueri tetap sama. Artinya, menunda waktu eksekusi tugas sinkronisasi tanpa mengubah konfigurasi.

Saat membaca data, Column.name yang dikonfigurasi pengguna peka terhadap huruf besar/kecil. Jika dikonfigurasi salah, data yang dibaca adalah null. Misalnya:

• Data sumber MongoDB:

  {
      "MY_NAME": "zhangsan"
  }

• Konfigurasi Kolom tugas sinkronisasi:

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

Karena huruf besar/kecil dalam konfigurasi tugas sinkronisasi tidak cocok dengan data sumber, terjadi pengecualian pembacaan data.

Parameter konfigurasi timeout adalah cursorTimeoutInMs, dengan nilai default 600.000 ms (10 menit). Parameter ini mewakili total waktu yang dibutuhkan server MongoDB untuk mengeksekusi kueri, tidak termasuk waktu transmisi data. Jika jumlah data yang dibaca dalam tarikan penuh besar, hal ini dapat menyebabkan kesalahan: 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 pembacaan dari node sekunder, kesalahan no master dilaporkan.

• Analisis penyebab:

  Kesalahan ini disebabkan oleh timeout kursor.

• Solusi:

  Tingkatkan nilai parameter cursorTimeoutInMs.

Anda perlu meningkatkan tingkat konkurensi tugas dan `BatchSize` untuk membaca.

• Penyebab potensial:

  Saat tugas sinkronisasi berjalan, tugas tersebut menggunakan perintah splitVector untuk pembagian tugas secara default. Beberapa versi MongoDB tidak mendukung perintah splitVector, yang menyebabkan kesalahan no such cmd splitVector.

• Solusi:

  1. Buka halaman konfigurasi tugas sinkronisasi dan klik tombol Konversi ke skrip . Ubah tugas ke editor kode.

  2. Di konfigurasi parameter MongoDB, tambahkan parameter

     "useSplitVector" : false

     untuk menghindari penggunaan splitVector.

• Gejala:

  Masalah ini dapat terjadi dalam tugas sinkronisasi, misalnya di antarmuka tanpa kode, jika Write Mode (Overwrite) diatur ke Yes dan bidang selain _id dikonfigurasi sebagai Business Primary Key.

• Penyebab potensial:

  Data berisi catatan yang _id-nya tidak cocok dengan Business Primary Key yang dikonfigurasi (seperti my_id dalam contoh konfigurasi di atas).

• Solusi:

  • Solusi 1: Modifikasi tugas sinkronisasi offline untuk memastikan bahwa Business Primary Key yang dikonfigurasi konsisten dengan _id.

  • Solusi 2: Gunakan _id sebagai kunci utama bisnis untuk 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, RedisWriter dikonfigurasi dengan `"keyIndexes":[ 0, 1]`. Di Redis, `id` dan `name` digunakan sebagai kunci, `age` sebagai atribut, dan `address` sebagai nilai, disimpan dalam tipe hash. Jika sumber ODPS dikonfigurasi hanya dengan dua kolom, Anda tidak dapat menggunakan mode hash untuk menyimpan cache Redis, dan pengecualian ini dilaporkan.

• Solusi:

  Jika Anda hanya ingin menggunakan dua kolom, konfigurasikan Redis untuk menyimpan informasi dalam mode String. Jika Anda harus menggunakan mode hash, konfigurasikan setidaknya tiga kolom di sumber.

• Gejala:

  Saat Anda mengonfigurasi tugas sinkronisasi offline untuk membaca data dari penyimpanan file seperti OSS atau FTP, jika file dalam format CSV dan menggunakan beberapa karakter sebagai pemisah kolom (misalnya, |,, ##, atau ;;), tugas dapat gagal dengan kesalahan "data kotor". Di log eksekusi tugas, Anda akan melihat kesalahan serupa IndexOutOfBoundsException (indeks array di luar batas), dan data kotor dihasilkan.

• Analisis penyebab:

  Reader csv bawaan DataWorks ("fileFormat": "csv") memiliki keterbatasan saat menangani pemisah yang terdiri dari beberapa karakter, yang menyebabkan pembagian kolom data baris tidak akurat.

• Solusi:

  • Antarmuka tanpa kode: Beralihlah ke tipe teks dan tentukan secara eksplisit pemisah multi-karakter Anda.

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

Sinkronisasi offline itu sendiri tidak membatasi jumlah file yang dapat dibaca oleh plugin reader OSS. Batasan utama pada pembacaan file berasal dari konsumsi sumber daya (CU) tugas itu sendiri. Membaca terlalu banyak file sekaligus dapat dengan mudah menyebabkan kesalahan kehabisan memori. Oleh karena itu, kami menyarankan agar Anda tidak mengatur parameter objek ke `*` untuk mencegah kesalahan OutOfMemoryError: Java heap space .

OSS Writer menggunakan nama file untuk mensimulasikan struktur direktori. OSS memiliki batasan berikut pada nama objek: jika Anda menggunakan `"object": "datax"`, objek yang ditulis dimulai dengan `datax`, dan string acak ditambahkan sebagai akhiran. Jumlah file ditentukan oleh jumlah tugas ter-shard aktual.

Jika Anda tidak ingin akhiran UUID acak, atur `"writeSingleObject" : "true"`. Untuk informasi lebih lanjut, lihat deskripsi `writeSingleObject` di dokumentasi sumber data OSS.

• Penyebab:

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

• Solusi:

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

• Analisis penyebab:

  Parameter mapred.task.timeout mungkin diatur ke nilai yang terlalu singkat, yang menyebabkan Hadoop menghentikan tugas dan membersihkan direktori sementara. Hal ini mengakibatkan data sementara tidak ditemukan.

• Solusi:

  Di pengaturan sumber data untuk tugas sinkronisasi offline, jika Anda memilih Read Data Based On Hive JDBC (supports Conditional Filtering) untuk Read Hive Method, Anda dapat mengatur parameter mapred.task.timeout di bidang Session Configuration. Misalnya: mapred.task.timeout=600000.

• Pesan kesalahan:

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

• Kemungkinan penyebab:

  Kesalahan disebabkan karena jumlah data yang dikirimkan ke DataHub oleh DataX dalam satu batch melebihi batas DataHub. Parameter konfigurasi yang memengaruhi jumlah data yang dikirimkan ke DataHub terutama:

  • maxCommitSize: Ukuran maksimum buffer data dalam megabyte (MB) sebelum data dikirimkan ke tujuan dalam satu batch. Nilai default adalah 1 MB (1.048.576 byte).

  • batchSize: Jumlah catatan data yang diakumulasi di buffer DataX-On-Flume. Saat jumlah catatan yang terakumulasi mencapai `batchSize` yang ditentukan, catatan tersebut dikirimkan ke tujuan sebagai satu batch.

• Solusi:

  Kurangi parameter maxCommitSize dan batchSize.

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

Integrasi Data menggunakan waktu data masuk ke LogHub. Di konsol LogHub, periksa apakah bidang metadata `receive_time` berada dalam rentang waktu yang dikonfigurasi untuk tugas.

Jika hal ini terjadi, edit kolom secara manual di antarmuka.

Logikanya sama dengan metode penulisan API. Data di baris dan kolom yang sama ditimpa, sedangkan data lain tetap tidak berubah.

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

• Perintah Kueri Shell:

  //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'

• Dapatkan bidang dari hasil:

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

  Dalam hasil yang dikembalikan, bagian `properties` berisi semua bidang dan definisi propertinya untuk indeks tersebut. Indeks di atas berisi tiga bidang: `field1`, `field2`, dan `field3`.

Anda dapat menambahkan variabel penjadwalan tanggal ke konfigurasi indeks. Hal ini memungkinkan string indeks dihitung berdasarkan tanggal berbeda, yang memungkinkan perubahan otomatis pada nama indeks Elasticsearch Reader. Proses konfigurasi mencakup tiga langkah: mendefinisikan variabel tanggal, mengonfigurasi variabel indeks, dan menerbitkan serta mengeksekusi tugas.

1. Definisikan variabel tanggal: Di konfigurasi penjadwalan tugas sinkronisasi, pilih Tambah Parameter untuk mendefinisikan variabel tanggal. Dalam contoh di bawah, `var1` dikonfigurasi untuk mewakili waktu eksekusi tugas (hari ini), dan `var2` mewakili stempel waktu data tugas (hari sebelumnya).

2. Konfigurasikan variabel indeks: Beralihlah ke editor kode dan konfigurasikan indeks Elasticsearch Reader. Format konfigurasi adalah: `${variable_name}`, seperti yang ditunjukkan pada gambar di bawah.

3. Terbitkan dan eksekusi tugas: Setelah validasi, kirim dan terbitkan tugas ke Pusat Operasi, lalu jalankan menggunakan jadwal berulang atau pengisian ulang data.

   1. Klik tombol Run With Parameters untuk menjalankan tugas untuk validasi. Tindakan ini menggantikan parameter sistem penjadwalan dalam konfigurasi tugas. Setelah tugas selesai, periksa log untuk memverifikasi bahwa indeks yang disinkronkan sesuai harapan.

      Catatan

      Saat Anda menjalankan dengan parameter, masukkan langsung nilai parameter untuk pengujian.

      

   2. Jika validasi berhasil, Anda dapat mengklik Save dan Submit untuk menambahkan tugas sinkronisasi ke lingkungan produksi.

      Untuk proyek standar, klik tombol Publish untuk membuka pusat penerbitan dan menerbitkan tugas sinkronisasi ke lingkungan produksi.

4. Hasil: Gambar berikut menunjukkan konfigurasi dan hasil indeks aktual dari eksekusi.

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

   Indeks yang dijalankan diganti menjadi: esstress_1_20230106_20230105.

   

Untuk menyinkronkan properti bidang objek, Anda harus menggunakan editor kode. Di editor kode, konfigurasikan `multi` sebagai berikut, dan konfigurasikan kolom menggunakan format `property.sub-property`.

"multi":{
   "multi":true 
 }

Anda dapat merujuk pada contoh berikut untuk konfigurasi:

#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 Writer: 1 baris dengan 3 kolom. Urutan kolom sama dengan konfigurasi reader.
KOLON               NILAI
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 tambahan di sekitar karakter adalah masalah tampilan di alat Kibana. Data aktual tidak memiliki tanda kutip ganda di sekitarnya. Anda dapat menggunakan perintah curl atau Postman untuk melihat data aktual. Perintah curl untuk mendapatkan 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 bidang tulis ES sebagai `nested` untuk menyinkronkan data string tipe JSON dari ODPS ke ES dan menyimpannya dalam format bersarang. Contoh berikut menyinkronkan bidang `name` ke ES dalam format bersarang.

   • Konfigurasi sinkronisasi: Konfigurasikan tipe `name` sebagai nested.

   • Hasil sinkronisasi: `name` adalah tipe objek bersarang.

Ada dua cara untuk mengonfigurasi penulisan ke ES sebagai tipe array. Anda dapat memilih metode sinkronisasi yang sesuai berdasarkan format data sumber.

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

  • Konfigurasi antarmuka tanpa kode:

  • Konfigurasi editor kode:

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

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

  • Batasan:

    • Hanya satu jenis pemisah yang didukung per tugas. Pemisah bersifat unik secara global. Anda tidak dapat mengonfigurasi pemisah berbeda untuk beberapa bidang Array. Misalnya, jika kolom sumber adalah col1="1,2,3,4,5" , col2="6-7-8-9-10", Anda tidak dapat mengonfigurasi pemisah terpisah untuk setiap kolom.

    • Pemisah dapat berupa ekspresi reguler. Misalnya, jika nilai kolom sumber adalah `"6-,-7-,-8+,*9-,-10"`, Anda dapat mengonfigurasi `splitter:".,."`. Hal ini didukung di antarmuka tanpa kode.

  • Konfigurasi antarmuka tanpa kode: splitter: Default "-,-"

  • Konfigurasi editor kode:

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

• Analisis penyebab:

  HttpClient telah dikonfigurasi sebelumnya untuk pertama kali membuat permintaan tanpa kredensial setiap kali koneksi dibuat. Setelah menerima persyaratan otorisasi dan menentukan metode autentikasi berdasarkan respons, permintaan kemudian dibuat dengan kredensial. Koneksi perlu dibuat setiap kali data ditulis ke ES, sehingga ada satu permintaan tanpa kredensial untuk setiap penulisan. Hal ini menyebabkan setiap penulisan data dicatat di log audit.

• Solusi:

  Anda perlu menambahkan konfigurasi "preemptiveAuth":true di editor kode.

Ada dua cara untuk mengonfigurasi penulisan tanggal. Anda dapat memilih sesuai kebutuhan.

• Menulis langsung konten bidang yang dibaca oleh reader ke bidang Date ES:

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

  • Konfigurasikan `"format"` untuk menentukan atribut format untuk bidang saat Anda membuat pemetaan menggunakan 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"
          }
            ]
  }

• Jika Anda telah mengonfigurasi `type:version`, ES saat ini tidak mendukung penentuan versi eksternal.

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

• Solusi:

  Anda perlu menghapus konfigurasi `"type":"version"`. Elasticsearch Writer saat ini tidak mendukung penentuan versi eksternal.

• Analisis penyebab:

  Elasticsearch Reader tidak dapat mengurai format tanggal bidang tipe tanggal karena pemetaan untuk bidang tanggal yang sesuai di sumber data ES tidak memiliki format yang dikonfigurasi.

• Solusi:

  • Konfigurasikan parameter `dateFormat` dengan format yang sama seperti format bidang tanggal ES, dipisahkan oleh "||". Format harus mencakup semua format tipe tanggal. Misalnya:

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

  • Atur pemetaan untuk semua bidang tanggal di database ES ke format.

• Analisis penyebab:

  Karena batasan kata kunci fastjson, mungkin ada kata kunci seperti `$ref` di indeks atau kolom.

• Solusi:

  Elasticsearch Reader saat ini tidak mendukung sinkronisasi indeks dengan kata kunci `$ref` di bidangnya. Untuk informasi lebih lanjut, lihat Elasticsearch Reader.

• Analisis penyebab:

  Mekanisme kunci optimis ES dipicu. Nomor versi saat ini seharusnya xxx, tetapi perintah pembaruan melewatkan nomor versi yang berbeda, yang menyebabkan konflik versi. Saat data diperbarui, proses lain sedang menghapus data indeks.

• Solusi:

  1. Periksa dan pastikan apakah terjadi perilaku penghapusan data.

  2. Ubah metode sinkronisasi tugas dari Update ke Index.

• Analisis penyebab:

  Saat Anda mengonfigurasi properti lanjutan seperti `similarity` atau `properties` untuk bidang Kolom, `other_params` diperlukan agar plugin dapat mengenalinya.

• Solusi:

  Konfigurasikan other_params di Kolom, dan tambahkan `similarity` di dalam other_params, seperti yang ditunjukkan di bawah:

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

• Analisis penyebab:

  Saat ini, sinkronisasi offline 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 menangani tipe yang tidak didukung oleh Elasticsearch Writer:

  • Jangan gunakan Elasticsearch Writer untuk membuat pemetaan indeks. Gunakan pemetaan yang dibuat pelanggan sebagai gantinya.

  • Ubah tipe yang sesuai menjadi `NESTED`.

  • Modifikasi konfigurasi menjadi: 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 berlaku saat indeks dibuat. Pembuatan indeks terjadi dalam dua kasus: saat indeks tidak ada, dan saat cleanup=true. Saat cleanup=true, konfigurasi Pengaturan tidak perlu menggunakan `"index"`.

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

• Analisis penyebab:

  Untuk tipe bersarang, Elasticsearch Writer hanya menggunakan pemetaan tingkat atas, yang memungkinkan ES menyesuaikan tipe komposit di bawahnya. Mengubah tipe properti menjadi `text` dan menambahkan `fields:keyword` adalah perilaku adaptif ES dan tidak memengaruhi penggunaannya. Jika Anda khawatir tentang format pemetaan ini, lihat Kemampuan tugas sinkronisasi Integrasi Data.

• Solusi:

  Sebelum sinkronisasi, buat pemetaan indeks ES yang diharapkan, lalu atur parameter pembersihan tugas sinkronisasi ES ke false dan jalankan tugas sinkronisasi.

Kafka Reader membaca data secara batch. Jika batch data berisi catatan yang melebihi endDateTime, sinkronisasi berhenti, tetapi data yang melebihi endDateTime ini juga ditulis ke sumber data tujuan.

• Anda dapat menggunakan item konfigurasi `skipExceedRecord` untuk menentukan apakah akan menyinkronkan data berlebih ini. Untuk informasi lebih lanjut tentang cara menggunakannya, lihat Kafka Reader. [Kami menyarankan agar Anda tidak mengatur ini untuk tidak menyinkronkan, karena dapat menyebabkan kehilangan data.]

• Anda dapat mengonfigurasi parameter `max.poll.records` Kafka untuk menentukan jumlah data yang ditarik sekaligus. Dikombinasikan dengan tingkat konkurensi, hal ini dapat mengontrol jumlah data berlebih yang berpotensi. Jumlah data berlebih kurang dari `max.poll.records` × tingkat konkurensi.

• Analisis penyebab:

  Jumlah data kecil atau distribusi data yang tidak merata menyebabkan beberapa partisi Kafka tidak memiliki data baru, atau data baru belum mencapai offset akhir yang ditentukan untuk dibaca. Karena kondisi keluar tugas adalah bahwa semua partisi harus mencapai offset akhir yang ditentukan, partisi "menganggur" ini tidak dapat memenuhi kondisi, yang menghambat penyelesaian normal seluruh tugas.

• Solusi:

  Dalam kasus ini, atur Kebijakan Akhir Sinkronisasi ke: Berhenti jika tidak ada data baru yang dibaca selama 1 menit (di editor kode, atur parameter stopWhenPollEmpty ke true dan parameter stopWhenReachEndOffset ke true). Hal ini memungkinkan tugas keluar segera setelah membaca data offset terbaru dari semua partisi dan menghindari eksekusi kosong. Namun, perhatikan bahwa jika catatan dengan stempel waktu lebih awal dari offset akhir yang dikonfigurasi ditulis ke partisi setelah tugas selesai, catatan tersebut tidak akan dikonsumsi.

RestAPI Writer menyediakan dua mode penulisan. Saat Anda menyinkronkan beberapa catatan data, Anda perlu mengonfigurasi `dataMode` sebagai `multiData`. Untuk informasi lebih lanjut, lihat RestAPI Writer. Anda juga perlu menambahkan parameter `dataPath:"data.list"` di skrip RestAPI Writer.

1. Konfigurasi OTS Writer harus mencakup dua baris berikut:

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

2. OTS Writer tidak perlu dikonfigurasi dengan nama kolom kunci utama auto-increment.

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

Contoh: Catatan data memiliki tiga tag: `[phone=Xiaomi, memory=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 camera sehingga setiap tag berada di kolom terpisah, gunakan konfigurasi berikut:

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

    Dua kolom data berikut diperoleh:

    xiaomi, LEICA

• Contoh impor data (OTS Writer)

  Anggaplah sumber data upstream (Reader) memiliki dua kolom data:

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

  • Kolom lainnya adalah: 6499.

  Jika Anda ingin menambahkan kedua kolom ini ke tag, dengan format bidang tag yang diharapkan setelah penulisan seperti yang ditunjukkan di bawah: Maka 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 terpisah ke bidang tag.

Jika nama tabel Anda mengikuti pola reguler, seperti orders_20170310, orders_20170311, dan orders_20170312, dibedakan berdasarkan hari, dan memiliki struktur tabel yang konsisten, Anda dapat menggabungkan parameter penjadwalan dengan konfigurasi editor kode untuk menyesuaikan nama tabel. Hal ini memungkinkan Anda membaca data tabel hari sebelumnya dari database sumber secara otomatis setiap pagi.

Di editor kode, ubah nama tabel sumber menjadi variabel, misalnya, orders_${tablename}. Karena nama tabel dibedakan berdasarkan hari dan Anda perlu membaca data hari sebelumnya setiap hari, di konfigurasi parameter tugas, tetapkan variabel sebagai tablename=${yyyymmdd}.

Buka halaman konfigurasi tugas sinkronisasi dan modifikasi pemetaan bidang untuk memperbarui bidang yang berubah di konfigurasi tugas. Setelah itu, Anda perlu mengirim ulang dan mengeksekusi tugas agar perubahan berlaku.

Saat Anda mengonfigurasi node sinkronisasi offline, area Pilih Sumber hanya menampilkan 25 tabel pertama di sumber data yang dipilih secara default. Jika ada lebih banyak tabel, Anda dapat mencari berdasarkan nama tabel atau menggunakan editor kode untuk pengembangan.

• Penyebab: Kolom berisi kata tercadang, atau konfigurasi kolom berisi bidang yang dimulai dengan angka.

• Solusi: Beralihlah ke tugas sinkronisasi Integrasi Data ke editor kode dan hindari bidang khusus dalam konfigurasi kolom. Untuk informasi lebih lanjut tentang cara mengonfigurasi tugas di editor kode, lihat Konfigurasi node sinkronisasi di editor kode.

  • Karakter escape untuk MySQL adalah `keyword`.

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

  • Karakter escape untuk SQL Server adalah [keyword].

  Contoh MySQL:

• Ambil sumber data MySQL sebagai contoh:

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

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

     Catatan

     • `table` adalah kata kunci MySQL. Kode yang dihasilkan selama sinkronisasi data menyebabkan kesalahan. Oleh karena itu, Anda perlu membuat tampilan untuk memberikan alias ke kolom `table`.

     • Jangan gunakan kata kunci sebagai nama kolom tabel.

  3. Dengan menjalankan pernyataan di atas, Anda dapat memberikan alias ke kolom yang memiliki kata kunci. Saat Anda mengonfigurasi tugas sinkronisasi, pilih tampilan `v_aliyun` alih-alih tabel `aliyun`.

Kesalahan ini dapat terjadi karena pemetaan bidang tugas sinkronisasi tidak dikonfigurasi dengan benar, atau kolom plugin tidak dikonfigurasi dengan benar.

1. Periksa apakah pemetaan bidang dikonfigurasi.

2. Periksa apakah kolom plugin dikonfigurasi dengan benar.

• Gejala:

  Saat Anda mengklik Data Preview, pesan berikut ditampilkan, menunjukkan bahwa bidang melebihi ukuran byte maksimum.

  

• Penyebab: Untuk menghindari kesalahan kehabisan memori (OOM), layanan sumber data memeriksa panjang bidang saat memproses permintaan pratinjau data. Jika satu kolom melebihi 1.000 byte, pesan di atas muncul. Pesan ini tidak memengaruhi operasi normal tugas. Anda dapat mengabaikan kesalahan ini dan menjalankan tugas sinkronisasi offline secara langsung.

  Catatan

  Jika file ada dan konektivitas normal, alasan lain kegagalan pratinjau data meliputi:

  • Ukuran byte satu baris di file melebihi batas 10 MB. Dalam hal ini, tidak ada data yang ditampilkan, mirip dengan pesan di atas.

  • Jumlah kolom di satu baris file melebihi batas 1.000. Dalam hal ini, hanya 1.000 kolom pertama yang ditampilkan, dan pesan ditunjukkan di kolom ke-1001.

Waktu hidup (TTL) diatur pada tabel. Tidak ada opsi seperti ini di konfigurasi tugas sinkronisasi.

Sinkronisasi API tidak mendukung penggunaan fungsi sisi sumber. Anda perlu memproses data menggunakan fungsi di sisi sumber terlebih dahulu, lalu mengimpor data tersebut.