Cara mengonfigurasi dependensi penjadwalan untuk mengontrol urutan eksekusi tugas - DataWorks

Di DataWorks, scheduling dependency menentukan hubungan hulu dan hilir antara node yang dijadwalkan secara berkala. Setelah Anda mengonfigurasi dependensi, sistem memastikan bahwa instans node hilir hanya dipicu setelah semua instans node hulunya berhasil, sehingga menjamin data diproduksi dan dikonsumsi dalam urutan yang benar. Dokumen ini menjelaskan konsep dasar, jenis, dan metode konfigurasi dependensi penjadwalan untuk membantu Anda memahami prinsipnya serta menemukan instruksi yang relevan.

Cara kerja

Scheduling dependency adalah mekanisme di DataWorks yang menentukan hubungan hulu dan hilir antar node. Dengan mengonfigurasi dependensi, Anda dapat menentukan bahwa suatu node hanya dimulai setelah node hulunya berhasil, sehingga menjamin urutan pemrosesan data yang tepat. Setelah dependensi dikonfigurasi, sistem penjadwalan DataWorks secara otomatis mengatur urutan eksekusi. Sebuah instans hilir hanya dipicu ketika semua instans hulunya telah berhasil dan semua kondisi lainnya—seperti waktu dan ketersediaan resource—telah terpenuhi.

DataWorks menetapkan dependensi dengan mencocokkan nama output node hulu dengan nama input node hilir. Alur kerja utama untuk mengonfigurasi dependensi adalah sebagai berikut:

Konfigurasikan output pada node hulu: Tambahkan nama output ke node hulu, biasanya dalam format project_name.table_name (misalnya, my_project.dim_user), untuk merepresentasikan tabel data yang dihasilkan oleh node tersebut.
Konfigurasikan input pada node hilir: Pada node hilir, cari dan pilih nama output dari node hulu sebagai inputnya (dependensinya). Hal ini menetapkan hubungan dependensi.
Penguraian otomatis (opsional): Untuk node berbasis SQL, DataWorks dapat secara otomatis mengurai pernyataan INSERT dan SELECT dalam kode Anda untuk mengidentifikasi tabel input dan output, lalu menghasilkan konfigurasi dependensi. Anda juga dapat menyesuaikan secara manual konfigurasi hasil penguraian otomatis tersebut. Untuk daftar jenis node yang mendukung penguraian otomatis, lihat Skenario penguraian otomatis untuk berbagai jenis node.

Penting

Setiap node harus memiliki setidaknya satu nama output. Sistem secara otomatis menghasilkan output default untuk setiap node dalam format project_name.nodeID_out. Output default ini tetap ada meskipun Anda menghapus semua output kustom.

Aturan dan batasan

Berlaku setelah deployment: Scheduling dependency hanya berlaku setelah Anda commit dan deploy node ke Operation Center. Konfigurasi yang dibuat di development environment tidak disinkronkan secara otomatis ke production environment.
Status penjadwalan hulu dan hilir: Agar dependensi berfungsi, baik instans node hulu maupun hilir harus dihasilkan dan berada dalam status penjadwalan normal. Jika node dikonfigurasi salah atau instans hulu gagal, node hilir mungkin menjadi terisolasi dan gagal berjalan sesuai jadwal.
Batasan dependensi siklus: Sistem melarang dependensi siklus, baik langsung (A bergantung pada B, dan B bergantung pada A) maupun tidak langsung. Jika dependensi siklus terdeteksi saat commit, sistem akan memblokir deployment dan melaporkan error.

Jenis dependensi

DataWorks mendukung dua jenis dependensi penjadwalan: same-cycle dependency dan cross-cycle dependency. Masing-masing jenis cocok untuk skenario bisnis yang berbeda.

Konsep prasyarat

Siklus adalah konsep relatif yang ditentukan oleh waktu penjadwalan suatu node. "Siklus penjadwalan" adalah selisih waktu antara dua instans terjadwal berturut-turut dari suatu node dan ditentukan oleh frekuensi penjadwalannya. Misalnya, untuk tugas harian, siklus sebelumnya merujuk pada instans dari hari sebelumnya. Untuk tugas per jam, siklus sebelumnya merujuk pada instans dari jam sebelumnya.

Frekuensi penjadwalan	Satu siklus
Harian, mingguan, bulanan, tahunan	1 hari Catatan Untuk tugas mingguan, bulanan, dan tahunan, instans tetap dihasilkan setiap hari, tetapi merupakan instans dry-run pada hari-hari non-jadwal. Oleh karena itu, perhitungan dependensi berdasarkan granularitas harian, dan `instans` siklus sebelumnya mungkin merupakan `instans` dry-run.
Per jam	Interval per jam
Per menit	Interval tingkat menit (misalnya, setiap 5 menit)

Dua jenis dependensi

Sebagai contoh, node A yang dijadwalkan harian menghasilkan tabel dim_user, dan node hilir B mengonsumsi tabel ini:

Dependensi siklus sama: Instans Node B untuk hari ini menunggu instans Node A untuk hari ini berhasil. Artinya, Node B mengonsumsi data yang dihasilkan oleh Node A pada hari yang sama.
Dependensi lintas siklus: Instans Node B untuk hari ini menunggu instans Node A dari kemarin berhasil. Artinya, Node B mengonsumsi data yang dihasilkan oleh Node A pada hari sebelumnya.

Item	Dependensi siklus sama	Dependensi lintas siklus (dependensi pada siklus sebelumnya)
Definisi	`Instans` siklus saat ini dari suatu `node` bergantung pada hasil `instans` siklus saat ini dari `node` hulunya.	`Instans` siklus saat ini dari suatu `node` bergantung pada hasil `instans` siklus sebelumnya dari `node` tertentu. `Node` yang ditentukan dapat berupa `node` itu sendiri (dependensi diri), `node` hilir langsung, atau `node` lainnya.
Representasi DAG	Direpresentasikan dengan garis solid.	Direpresentasikan dengan garis putus-putus.
Kasus penggunaan khas	Node B perlu membaca data yang dihasilkan oleh Node A hari ini.	Suatu `node` bergantung pada data yang dihasilkan kemarin (misalnya, pembacaan T-1). Tugas per jam atau per menit menggunakan dependensi diri untuk memastikan eksekusi serial dan menghindari eksekusi konkuren.
Metode konfigurasi	Mendukung penguraian otomatis, koneksi drag-and-drop di editor alur kerja, dan konfigurasi manual.	Di panel konfigurasi penjadwalan, pada bagian "Previous Cycle", pilih bentuk dependensi dan tentukan ID `node`-nya.

Catatan: Same-cycle dependency dan cross-cycle dependency dapat eksis antara pasangan node yang sama, tetapi Anda harus memahami logika bisnis masing-masing. Jika Anda hanya membutuhkan cross-cycle dependency, ingatlah untuk menghapus same-cycle dependency yang mungkin telah dihasilkan secara otomatis. Jika tidak, instans hilir tetap akan menunggu instans hulu siklus saat ini selesai, yang dapat menyebabkan penundaan tak terduga.

Konfigurasi

Untuk menjamin integritas dan kemudahan pemeliharaan pipeline penjadwalan Anda, semua node harus memiliki dependensi hulu yang dikonfigurasi sebelum dapat dideploy ke Operation Center untuk penjadwalan otomatis. Jika suatu node tidak memiliki dependensi data, node tersebut harus bergantung pada zero load node atau root node. Untuk mengonfigurasi scheduling dependency, analisis logika bisnis node, identifikasi objek dan jenis dependensinya, lalu pilih metode terbaik untuk membangun alur data yang andal.

1. Identifikasi objek dependensi

Sebelum mengonfigurasi dependensi, lengkapi persiapan berikut:

Analisis data lineage: Pastikan tabel atau partisi yang dihasilkan oleh node hulu sesuai dengan tabel atau partisi yang dibaca oleh node hilir.
Periksa properti penjadwalan: Pastikan siklus penjadwalan node, tanggal efektif, dan scheduling parameter diatur dengan benar, karena properti ini secara langsung memengaruhi perilaku dependensi.

Pilih objek dependensi berdasarkan kebutuhan dependensi data node Anda.

Skenario 1: Dependensi pada output langsung

Kasus penggunaan: Data yang dibutuhkan oleh node hilir berasal langsung dari tabel yang dihasilkan oleh node hulu lain yang dijadwalkan otomatis oleh DataWorks.
Strategi konfigurasi: Dasarkan dependensi node pada data lineage.
Nilai inti: Ini adalah metode paling langsung dan andal. Sistem penjadwalan memastikan node hilir hanya dimulai setelah data hulu siap, sehingga menjamin konsistensi data end-to-end.

Skenario 2: Dependensi pada data non-terjadwal

Kasus penggunaan: Data hulu tidak dikelola oleh sistem penjadwalan DataWorks dan tidak menghasilkan instans yang dapat dijadwalkan untuk dependensi hilir. Contohnya meliputi:
- File yang didorong dari sistem eksternal ke OSS atau FTP.
- Tabel yang dihasilkan oleh sinkronisasi real-time.
- Tabel yang dihasilkan oleh alat sinkronisasi pihak ketiga yang tidak dijadwalkan oleh DataWorks.
- Tabel sementara yang dihasilkan oleh unggahan atau eksekusi manual.
Strategi konfigurasi: Konfigurasikan node pemeriksa (seperti node Check) untuk secara aktif memverifikasi apakah data sudah siap (misalnya, dengan memeriksa keberadaan file atau apakah partisi tabel telah dihasilkan). Node bisnis hilir dapat bergantung pada node pemeriksa ini.
Nilai inti: Pendekatan ini mengubah status "data dihasilkan" menjadi "event yang dapat dijadwalkan", sehingga proses selanjutnya dapat didorong oleh kesiapan data. Hal ini menjamin kebenaran data bahkan dalam alur kerja non-terjadwal.

Skenario 3: Dependensi logika bisnis

Kasus penggunaan: Suatu node sepenuhnya independen dalam pemrosesan data dan logika kodenya, tetapi perlu termasuk dalam proses bisnis tertentu atau dijadwalkan pada interval reguler.
Strategi konfigurasi:
- Bergantung pada zero load node: Mengelompokkan tugas terkait ke dalam unit logis menyederhanakan proses memulai, menghentikan, memantau, dan pemeliharaan, sehingga membantu menjaga logika bisnis tetap terorganisir.
- Bergantung pada root node suatu workspace: Hal ini memastikan tugas dapat diinstansiasi dan dieksekusi tepat waktu oleh sistem penjadwalan, mencegahnya menjadi node terisolasi yang tidak dapat dijadwalkan secara otomatis.
Nilai inti: Hal ini mencegah node menjadi terisolasi, memperjelas kontrol dan pemantauan proses, serta menjamin integritas alur logika bisnis.

2. Pilih jenis dependensi

Jika node Anda bergantung pada output langsung dari node hulu (Skenario 1), Anda perlu menentukan apakah dependensinya berlaku untuk output dari siklus yang sama atau siklus berbeda.

Keputusan utama

Periksa data siklus mana yang sebenarnya dibaca oleh node hilir. Dalam kebanyakan kasus, suatu node menggunakan scheduling parameter untuk menulis data secara dinamis ke partisi tertentu dari suatu tabel. Anda dapat merujuk ke Format yang didukung untuk scheduling parameter untuk memahami cara substitusi scheduling parameter bekerja. Jika Anda perlu bergantung pada node dalam workspace yang sama, Anda dapat memeriksa konfigurasi scheduling parameter-nya.

Cara memastikan

Untuk node dalam workspace yang sama: Periksa scheduling parameter dalam kode node hulu untuk melihat apakah partisi yang ditulis sesuai dengan "hari ini" atau "kemarin" setelah substitusi parameter.
- Di development environment, periksa konfigurasi dan kode scheduling parameter node hulu. Di production environment, periksa hasil substitusi parameter di detail instans.
Untuk node di workspace berbeda: Gunakan Data Map untuk melihat informasi partisi dan riwayat perubahan tabel hulu.
- Konfirmasi nilai partisi aktual yang ditulis setiap hari.

Pilih jenis

Kode hilir mengambil partisi hulu untuk hari/siklus saat ini: siklus sama.
Kode hilir mengambil partisi hulu dari hari/siklus sebelumnya: lintas siklus.
Tugas per jam/per menit perlu berjalan secara serial tanpa konkurensi: lintas siklus (dependensi diri pada node itu sendiri).

Penting

Konsekuensi verifikasi data lineage yang salah:

Risiko dependensi hilang: Jika hubungan data lineage ada tetapi scheduling dependency tidak dikonfigurasi, tugas hilir mungkin dimulai sebelum instans hulu berhasil, menyebabkan data hilang atau tidak lengkap.
Risiko ketidaksesuaian parameter: Jika dependensi dikonfigurasi tetapi parameter partisinya tidak sesuai (misalnya, node hulu menghasilkan partisi hari ini, tetapi node hilir membaca partisi kemarin), hal ini dapat menyebabkan error logika data dan masalah kualitas.

3. Konfigurasikan dependensi

Berdasarkan objek dan jenis dependensi yang diidentifikasi pada Langkah 1 dan 2, pilih metode yang sesuai untuk mengonfigurasi dependensi.

DataWorks memungkinkan Anda membuat dependensi antar tugas dengan frekuensi penjadwalan berbeda. Dengan menggabungkan dependensi siklus sama atau lintas siklus dengan scheduling parameter, Anda dapat menerapkan berbagai pola penjadwalan lanjutan. Untuk informasi lebih lanjut, lihat:

Mengonfigurasi penjadwalan untuk skenario dependensi kompleks

4. Verifikasi dependensi

Setelah konfigurasi dan sebelum deployment, Anda harus memverifikasi dependensi:

Metode verifikasi	Deskripsi
Saat konfigurasi: Pratinjau dependensi penjadwalan	Pratinjau dependensi penjadwalan yang telah dikonfigurasi untuk memastikan sesuai ekspektasi Anda. Saat ini, Anda hanya dapat melihat dependensi hulu dan hilir langsung dari `node` saat ini. Untuk memastikan dependensi ditampilkan dengan benar, pastikan `node` hulu telah disimpan. Dalam graf pratinjau dependensi, garis solid menunjukkan `same-cycle dependency`, dan garis putus-putus menunjukkan `cross-cycle dependency`.
Saat commit: Bandingkan hasil penguraian kode	Saat Anda `commit` suatu `node`, konfirmasi apakah perubahan dependensi sesuai ekspektasi dan evaluasi dampaknya terhadap `production environment`. Jika penguraian otomatis diaktifkan, Anda juga harus mengonfirmasi setiap perubahan pada konfigurasi penjadwalan node selama proses `commit`. Hal ini membantu memastikan perubahan dependensi tidak berdampak negatif pada tugas produksi.
Setelah deployment: Lihat Auto Triggered Nodes	Setelah suatu `node` dideploy, buka `Operation Center` untuk memastikan dependensi penjadwalan tugas produksi sudah benar. Konfirmasi dependensi tugas produksi Dalam `workspace` mode standar, dependensi suatu `node` dapat berbeda antara `development environment` dan `production environment`. Dependensi untuk node produksi harus dikonfigurasi di DataStudio dan hanya berlaku setelah `deployment`. Setelah suatu `node` dideploy, Anda dapat membuka halaman Auto Triggered Nodes di `Operation Center` dan memperluas node hulu dan hilir untuk melihat detail `scheduling dependency`. Penting Halaman Auto Triggered Nodes menampilkan status terbaru node di `production environment`. Namun, apakah dependensi baru ditambahkan atau dihapus dari suatu `instans` bergantung pada mode pembuatan instans yang dipilih. Konfirmasi status data produksi Setelah memastikan dependensi penjadwalan sudah benar, Anda juga perlu memverifikasi partisi data yang dibaca dan ditulis oleh node hulu dan hilir (yaitu, apakah `scheduling parameter` dikonfigurasi dengan benar). Hal ini mencegah `node` hilir membaca data yang salah, yang dapat menyebabkan masalah kualitas data. Catatan Jika alur `deployment` Anda mencakup proses review, kami menyarankan membuka halaman Auto Triggered Nodes di `Operation Center` setelah tugas dideploy untuk memeriksa dependensi dan propertinya. Jika Anda menemukan tugas tidak berperilaku seperti yang diharapkan, periksa apakah proses `deployment`-nya terblokir. Untuk informasi lebih lanjut, lihat Deploy tasks.

Dampak penghapusan dependensi

Selama operasi atau iterasi tugas, Anda mungkin perlu menghapus atau menyesuaikan dependensi penjadwalan yang ada.

Sebelum menghapus dependensi, Anda harus mengevaluasi dampaknya terhadap perilaku penjadwalan tugas hilir untuk menghindari pembuatan node terisolasi atau insiden data.

Skenario dependensi hilir	Dampak penghapusan	Tingkat risiko
Tugas hilir hanya bergantung pada `node` saat ini	Tugas hilir menjadi `node` terisolasi, kehilangan pemicu hulu, dan tidak lagi berjalan secara otomatis.	Tinggi
Tugas hilir bergantung pada beberapa node induk	Tugas hilir mungkin dimulai sebelum semua data hulu yang diperlukan siap, menyebabkan data hilang atau error perhitungan.	Sedang
Tugas hilir bergantung pada `instans` lintas siklus	Jika `cross-cycle dependency` dihapus, tugas hilir mungkin membaca data dari tanggal bisnis yang salah, menyebabkan error logika data.	Sedang

Kasus penggunaan

Gudang data offline berlapis: Konfigurasikan dependensi di seluruh pipeline ODS → DWD → DWS → ADS untuk memastikan data dihasilkan dalam urutan yang benar di setiap lapisan.
Pipeline ETL standar: Konfigurasikan same-cycle dependency untuk memastikan tugas hilir menunggu instans hulunya berhasil, sehingga menjamin pemrosesan data yang berurutan dan konsisten.
Laporan hari berikutnya (T+1): Konfigurasikan cross-cycle dependency (dengan offset -1) agar tugas hari ini bergantung pada data bisnis lengkap dari kemarin, memungkinkan analisis dan output akurat untuk hari berikutnya.
Agregasi hibrid multi-siklus: Konfigurasikan cross-cycle dependency agar tugas harian bergantung pada semua instans tugas per jam, memastikan data dasar sepenuhnya siap sebelum agregasi.
Pemicu kesiapan data eksternal: Konfigurasikan dependensi kustom atau node pemeriksa untuk memastikan file eksternal telah tiba atau API siap sebelum memicu alur kerja, memungkinkan penjadwalan lintas sistem.
Kontrol alur kerja kompleks: Gunakan zero load node untuk menggabungkan beberapa cabang dependensi, berperan sebagai tonggak kendali untuk menyederhanakan struktur pipeline dan meningkatkan visibilitas pemantauan.

FAQ

Bagian berikut menjelaskan skenario umum. Untuk pertanyaan umum lainnya tentang dependensi penjadwalan, lihat FAQ tentang dependensi.

Keunikan node
- Suatu node dapat memiliki konfigurasi berbeda tetapi secara logis unik: Satu node dapat memiliki konfigurasi scheduling dependency berbeda di development environment dan production environment. Meskipun bentuknya berbeda, node tersebut tetap merupakan satu node unik.
- Dependensi hilir harus dihapus di kedua lingkungan sebelum menghentikan node: Karena keunikan node, untuk memastikan tugas hilir berjalan dengan benar, Anda harus terlebih dahulu menghapus dependensi dari konfigurasi node hilir, mengonfigurasi ulang agar bergantung pada node hulu baru, lalu commit dan deploy perubahan tersebut. Hentikan tugas hulu asli hanya setelah memastikan dependensinya telah dihapus dari development environment dan production environment.
Mode pembuatan instans
- Saat membuat node, pastikan mode pembuatan instans-nya sama dengan node hulu dan hilirnya. Jika mode pembuatan instans berbeda—misalnya, jika node hulu menghasilkan instans pada hari yang sama tetapi node hilir menghasilkannya pada hari berikutnya—instans hilir mungkin menjadi node terisolasi.
- Jika Anda mengubah siklus penjadwalan node yang sudah ada dan memilih untuk menghasilkan instans segera setelah deployment, instans yang sebelumnya dihasilkan tidak dihapus secara otomatis. Hal ini dapat menyebabkan ketidaksesuaian dependensi untuk instans pada hari deployment. Untuk informasi lebih lanjut, lihat Dampak konversi instans real-time terhadap dependensi instans hari yang sama.
Terjadi error yang menunjukkan lebih dari 200 dependensi hulu saat memperbarui pekerjaan menggunakan API.
- Detail error: 'One file could not have more than 200 inputs'.
- Anda dapat menambahkan zero load node di DataStudio di antara node hulu dan hilir untuk mengurangi jumlah dependensi hulu langsung. Untuk informasi lebih lanjut tentang cara mengonfigurasi zero load node, lihat Zero load node.