Menjalankan pembaruan alur

Artikel ini menjelaskan pembaruan alur dan memberikan detail tentang cara memicu pembaruan.

Apa itu pembaruan alur kerja?

Setelah Anda membuat alur dan siap untuk menjalankannya, Anda memulai pembaruan . Pembaruan alur kerja menyediakan hal-hal berikut:

• Memulai kluster dengan konfigurasi yang benar.
• Menemukan semua tabel dan tampilan yang ditentukan dan memeriksa kesalahan analisis apa pun seperti nama kolom yang tidak valid, dependensi yang hilang, dan kesalahan sintaksis.
• Membuat atau memperbarui tabel dan tampilan dengan data terbaru yang tersedia.

Dengan menggunakan dry run, Anda dapat memeriksa masalah dalam kode sumber alur tanpa menunggu tabel dibuat atau diperbarui. Fitur ini berguna saat mengembangkan atau menguji alur karena memungkinkan Anda dengan cepat menemukan dan memperbaiki kesalahan dalam alur Anda, seperti nama tabel atau kolom yang salah.

Bagaimana pembaruan pipeline dipicu?

Gunakan salah satu opsi berikut untuk memulai pembaruan alur:

Perbarui pemicu	Detail lebih lanjut
Buku Petunjuk	Anda dapat memicu pembaruan alur secara manual dari Editor Alur Lakeflow, atau daftar alur. Lihat Menjalankan pembaruan pipeline secara manual.
Scheduled	Anda dapat menjadwalkan pembaruan untuk alur menggunakan tugas. Lihat Tugas pipeline untuk pekerjaan.
Programmatic	Anda dapat memicu pembaruan secara terprogram menggunakan alat, API, dan CLIs pihak ketiga. Lihat Menjalankan pipeline dalam alur kerja dan pipeline REST API.

Memicu pembaruan pipelin secara manual

Gunakan salah satu opsi berikut untuk memicu pembaruan alur secara manual:

• Jalankan alur lengkap, atau subset alur (satu file sumber, atau satu tabel), dari Editor Alur Lakeflow. Untuk informasi selengkapnya, lihat Menjalankan kode alur.
• Jalankan pipeline penuh dari daftar Pekerjaan & Pipeline. Klik di baris yang sama dengan alur dalam daftar.
• Dari halaman pemantauan pipa, klik tombol .

Nota

Perilaku default untuk pembaruan alur yang dipicu secara manual adalah me-refresh semua himpunan data yang ditentukan dalam alur.

Semantik pembaruan jalur

Tabel berikut ini menjelaskan perilaku refresh bawaan, refresh penuh, dan reset cek poin untuk view materialisasi dan tabel streaming.

Jenis Pembaruan	Tampilan Terwujud	Tabel streaming
Muat Ulang (default)	Memperbarui hasil untuk mencerminkan hasil saat ini untuk kueri yang didefinisikan. Ini memeriksa biaya, dan akan melakukan penyegaran bertahap jika lebih hemat biaya. Lihat Refresh inkremental untuk tampilan materialisasi	Memproses rekaman baru melalui logika yang ditentukan dalam tabel dan alur streaming.
Pembaruan penuh	Memperbarui hasil untuk mencerminkan hasil saat ini untuk kueri yang didefinisikan.	Menghapus data dari tabel streaming, menghapus informasi status (titik pemeriksaan) dari alur, dan memproses ulang semua rekaman dari sumber data. Lihat Refresh penuh untuk tabel streaming
Mengatur ulang titik pemeriksaan aliran streaming	Tidak berlaku untuk tampilan materialisasi.	Menghapus informasi status (titik pemeriksaan) dari alur tetapi tidak menghapus data dari tabel streaming, dan memproses ulang semua rekaman dari sumber data.

Secara default, semua tampilan materialisasi dan tabel streaming dalam refresh alur dengan setiap pembaruan. Anda dapat secara opsional menghilangkan tabel dari pembaruan menggunakan fitur berikut:

• Pilih tabel untuk refresh: Gunakan UI ini untuk menambahkan atau menghapus tampilan materialisasi dan tabel streaming sebelum menjalankan pembaruan. Lihat Memulai pembaruan alur untuk tabel yang dipilih.
• Refresh tabel yang gagal: Mulai pembaruan untuk tampilan materialisasi yang mengalami kegagalan dan tabel streaming, beserta dependensi hilir. Lihat Memulai pembaruan alur untuk tabel yang gagal.

Kedua fitur ini mendukung semantik refresh default atau refresh penuh. Anda dapat secara opsional menggunakan dialog Pilih tabel untuk refresh untuk mengecualikan tabel tambahan saat menjalankan refresh untuk tabel yang gagal.

Untuk tabel streaming, Anda dapat memilih untuk menghapus titik pemeriksaan streaming untuk alur yang dipilih dan bukan data dari tabel streaming terkait. Untuk menghapus titik pemeriksaan untuk alur yang dipilih, gunakan Databricks REST API untuk memulai refresh. Lihat Mulai pembaruan pipeline untuk menghapus titik pemeriksaan aliran streaming selektif.

Haruskah saya menggunakan refresh penuh?

Databricks merekomendasikan untuk menjalankan refresh penuh hanya jika diperlukan. Refresh penuh selalu memproses ulang semua rekaman dari sumber data yang ditentukan melalui logika yang menentukan himpunan data. Waktu dan sumber daya untuk menyelesaikan refresh penuh berkorelasi dengan ukuran data sumber.

Tampilan materialisasi mengembalikan hasil yang sama apakah digunakan refresh default atau penuh. Menggunakan penyegaran penuh dengan tabel streaming akan mengatur ulang semua pemrosesan status dan informasi titik pemeriksaan, dan dapat mengakibatkan catatan yang hilang jika data input tidak lagi tersedia. Lihat Refresh penuh untuk tabel streaming

Databricks hanya merekomendasikan refresh penuh ketika sumber data input berisi data yang diperlukan untuk membuat ulang status tabel atau tampilan yang diinginkan. Pertimbangkan skenario berikut di mana data sumber input tidak lagi tersedia dan hasil menjalankan refresh penuh:

Sumber data	Alasan data input tidak ada	Hasil pembaruan penuh
Kafka	Ambang retensi pendek	Rekaman yang tidak lagi ada di sumber Kafka dihapus dari tabel target.
Berkas dalam penyimpanan objek	Kebijakan siklus hidup	File data tidak lagi ada di direktori sumber dihilangkan dari tabel target.
Rekaman dalam tabel	Dihapus demi kepatuhan	Hanya rekaman yang ada dalam tabel sumber yang diproses.

Untuk mencegah refresh penuh dijalankan pada tabel atau tampilan, atur properti tabel pipelines.reset.allowed ke false. Lihat Properti tabel jalur pemrosesan. Anda juga dapat menggunakan alur tambahan untuk menambahkan data ke tabel streaming yang ada tanpa memerlukan refresh penuh.

Memulai pembaruan alur untuk tabel yang dipilih

Anda dapat secara opsional memproses ulang data hanya untuk tabel yang dipilih di alur Anda. Misalnya, selama pengembangan, Anda hanya mengubah satu tabel dan ingin mengurangi waktu pengujian, atau pembaruan alur gagal dan Anda hanya ingin me-refresh tabel yang gagal.

Editor Alur Lakeflow memiliki opsi untuk memproses ulang file sumber, tabel yang dipilih, atau satu tabel. Untuk detailnya, lihat Menjalankan kode alur.

Memulai pembaruan alur untuk tabel yang gagal

Jika pembaruan alur gagal karena kesalahan dalam satu atau beberapa tabel dalam grafik alur, Anda dapat memulai pembaruan hanya tabel yang gagal dan dependensi hilir apa pun.

Nota

Tabel yang dikecualikan tidak diperbarui, meskipun bergantung pada tabel yang mengalami kegagalan.

Untuk memperbarui tabel yang gagal, pada halaman pemantauan alur, klik Refresh tabel yang gagal.

Untuk memperbarui hanya tabel yang gagal yang dipilih dari halaman pemantauan alur:

1. Klik di samping tombol Refresh tabel yang gagal dan klik Pilih tabel untuk refresh. Dialog Pilih tabel untuk refresh muncul.

2. Untuk memilih tabel yang akan di-refresh, klik setiap tabel. Tabel terpilih disorot dan diberi label. Untuk menghapus tabel dari pembaruan, klik tabel lagi.

3. Klik Segarkan pilihan.

   Nota

   Tombol pilihan Refresh menampilkan jumlah tabel terpilih dalam tanda kurung.

Untuk memproses ulang data yang sudah diserap untuk tabel yang dipilih, klik di samping tombol Pilihan refresh dan klik pilihan Refresh Penuh.

Memulai pembaruan jalur untuk menghapus titik pemeriksaan aliran streaming selektif

Anda dapat secara opsional memproses ulang data untuk alur streaming yang dipilih di alur Anda tanpa menghapus data yang sudah diserap.

Nota

Alur yang tidak dipilih menggunakan pembaruan REFRESH untuk dijalankan. Anda juga dapat menentukan full_refresh_selection atau refresh_selection untuk menyegarkan tabel lain secara selektif.

Untuk memulai pembaruan untuk me-refresh titik pemeriksaan streaming yang dipilih, gunakan permintaan pembaruan di REST API Alur Deklaratif Lakeflow Spark.

Parameter reset_checkpoint_selection menerima daftar nama alur. Anda harus menggunakan nama alur seperti yang muncul di grafik alur:

• Jika Anda menentukan alur dengan nama eksplisit (misalnya, menggunakan parameter di flow_name), gunakan nama tersebutcreate_auto_cdc_flow.
• Jika Anda tidak mengatur nama alur eksplisit, nama alur default adalah nama tabel yang sepenuhnya memenuhi syarat dalam catalog.schema.table format. Menggunakan hanya nama tabel (misalnya, gold alih-alih my_catalog.my_schema.gold) menyebabkan proses pembaruan alur gagal dengan IllegalArgumentException.

Anda dapat menemukan nama alur di UI pipeline atau di log peristiwa pipeline.

Contoh berikut menggunakan curl perintah untuk memanggil updates permintaan untuk memulai pembaruan alur:

curl -X POST \
-H "Authorization: Bearer <your-token>" \
-H "Content-Type: application/json" \
-d '{
"reset_checkpoint_selection": ["my_catalog.my_schema.my_streaming_table"]
}' \
https://<your-databricks-instance>/api/2.0/pipelines/<your-pipeline-id>/updates

Contoh berikut mengatur ulang titik pemeriksaan untuk alur dengan nama kustom:

curl -X POST \
-H "Authorization: Bearer <your-token>" \
-H "Content-Type: application/json" \
-d '{
"reset_checkpoint_selection": ["my_custom_flow_name"]
}' \
https://<your-databricks-instance>/api/2.0/pipelines/<your-pipeline-id>/updates

Periksa alur untuk kesalahan tanpa menunggu tabel diperbarui

Penting

Fitur alur Dry run ada di Pratinjau Umum.

Untuk memeriksa apakah kode sumber alur valid tanpa menjalankan pembaruan penuh, gunakan dry run. Eksekusi kering menyelesaikan definisi himpunan data dan alur yang ditentukan dalam alur tetapi tidak mewujudkan atau menerbitkan himpunan data apa pun. Kesalahan yang ditemukan selama uji coba, seperti nama tabel atau kolom yang salah, dilaporkan dalam antarmuka pengguna.

Untuk memulai eksekusi kering, klik pada halaman detail alur di samping Mulai dan klik Eksekusi kering.

Setelah eksekusi kering selesai, kesalahan apa pun ditampilkan di baki peristiwa di panel bawah. Mengklik tray event akan menampilkan masalah apa pun yang ditemukan di panel bawah. Selain itu, log peristiwa menunjukkan peristiwa yang hanya terkait dengan simulasi, dan tidak ada metrik yang ditampilkan di DAG. Jika kesalahan ditemukan, detail tersedia di log peristiwa.

Anda dapat melihat hasil hanya untuk dry run terbaru. Jika dry run adalah pembaruan yang terakhir dijalankan, Anda dapat melihat hasilnya dengan memilihnya dalam riwayat pembaruan. Jika pembaruan lain dijalankan setelah dry run, hasilnya tidak lagi tersedia di UI.

Memperbarui perilaku eksekusi

Perilaku pembaruan alur ditentukan oleh cara Anda memicunya:

• Pembaruan yang dipicu dari antarmuka pengguna pemantauan alur menggunakan Jalankan sekarang menggunakan perilaku start cepat, yang berfokus pada debugging.
• Pembaruan yang dipicu dari Jobs, Pipelines API, atau pipelines berkelanjutan menggunakan perilaku coba ulang dan mulai ulang otomatis.

Untuk alur yang dipicu, Anda dapat mengambil alih perilaku default untuk eksekusi tertentu dengan memilih Jalankan sekarang dengan pengaturan yang berbeda dari drop-down di Editor Alur Lakeflow atau halaman pemantauan alur.

Perilaku mulai cepat yang berfokus pada debugging

Digunakan untuk UI Jalankan sekarang dan pembaruan ad-hoc. Proses ini dioptimalkan untuk iterasi cepat.

• Menggunakan kembali kluster untuk menghindari beban restart. Secara default, kluster berjalan selama dua jam. Anda dapat mengubah ini dengan pipelines.clusterShutdown.delay pengaturan di Konfigurasikan komputasi klasik untuk alur kerja.
• Menonaktifkan percobaan ulang alur sehingga Anda dapat segera mendeteksi dan memperbaiki kesalahan.

Perilaku coba lagi dan mulai ulang otomatis

Digunakan untuk Pekerjaan, pembaruan yang dipicu API, dan alur berkelanjutan. Pelaksanaan ini memprioritaskan keandalan dan efisiensi biaya.

• Memulai ulang kluster untuk kesalahan tertentu yang dapat dipulihkan, termasuk kebocoran memori dan kredensial kedaluarsa.
• Coba lagi eksekusi jika terjadi kesalahan tertentu, seperti kegagalan untuk memulai kluster.
• Kluster dimatikan segera setelah pekerjaan selesai.

Nota

Jalankan perilaku hanya mengontrol eksekusi kluster dan alur. Lokasi penyimpanan dan skema target dalam katalog untuk tabel penerbitan harus dikonfigurasi sebagai bagian dari pengaturan alur dan tidak terpengaruh oleh perilaku eksekusi.