Menjalankan pembaruan alur

Pembaruan pipeline akan memulai kluster, memvalidasi kode sumber Anda, dan memperbarui tabel serta tampilan yang didefinisikan dalam pipeline. Anda dapat memicu pembaruan secara manual, sesuai jadwal, atau secara terprogram.

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 view yang ditentukan serta memeriksa apakah ada kesalahan analisis, seperti nama kolom yang tidak valid, dependensi yang hilang, dan kesalahan sintaks.
• 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 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 agar mencerminkan hasil terkini dari kueri pendefinisi. Azure Databricks memeriksa biaya dan melakukan refresh bertahap ketika lebih efisien. Lihat Refresh inkremental untuk tampilan materialisasi	Memproses rekaman baru melalui logika yang ditentukan dalam tabel dan alur streaming.
Pembaruan penuh	Menghitung ulang hasil agar mencerminkan hasil terkini dari kueri pendefinisi.	Menghapus data dari tabel streaming, menghapus 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 titik pemeriksaan dari alur tetapi tidak menghapus data dari tabel streaming, lalu 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.

Kapan 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 menyegarkan titik pemeriksaan streaming yang dipilih, gunakan permintaan pembaruan di REST API alur Lakeflow.

Parameter reset_checkpoint_selection menerima daftar nama alur. Anda harus memberikan setiap nama alur dalam format bernama lengkap catalog.schema.flow_name. Hanya menggunakan nama sederhana (misalnya, my_flow alih-alih my_catalog.my_schema.my_flow) menyebabkan pembaruan alur gagal dengan IllegalArgumentException.

• Jika Anda menentukan alur dengan nama eksplisit (misalnya, menggunakan flow_name parameter di create_auto_cdc_flow), nama alur yang sepenuhnya memenuhi syarat adalah <catalog>.<schema>.<flow_name>.
• Jika Anda tidak menetapkan nama alur eksplisit, nama alur default adalah nama tabel target yang sepenuhnya memenuhi syarat, dalam catalog.schema.table format.

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 yang ditentukan dengan nama kustom:

curl -X POST \
-H "Authorization: Bearer <your-token>" \
-H "Content-Type: application/json" \
-d '{
"reset_checkpoint_selection": ["my_catalog.my_schema.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 proses kering selesai, setiap kesalahan dan wawasan inkrementalisasi ditampilkan di baki event di panel bawah. Mengklik baki peristiwa menampilkan masalah apa pun yang ditemukan di panel bawah. Selain itu, log kejadian hanya menampilkan kejadian yang terkait dengan dry run, dan tidak ada metrik yang ditampilkan dalam grafik pipeline. Jika ditemukan kesalahan atau wawasan, detail tersedia di log peristiwa.

Anda hanya dapat melihat hasil dry run di UI saat dry run adalah pembaruan terbaru dari pipeline Anda. Pilih di riwayat pembaruan untuk melihat hasilnya. Untuk mengetahui berapa lama setiap jenis pembaruan tetap tersedia di UI, lihat ketersediaan hasil pembaruan.

Ketersediaan hasil pembaruan

Apakah hasil pembaruan muncul di UI tergantung pada jenis pembaruan dan dua kondisi:

• Jendela retensi: Berapa lama pembaruan yang sudah selesai disimpan. Pipeline mempertahankan 60 hari pembaruan sebelumnya.
• Pembaruan terbaru: Apakah pembaruan ini adalah pembaruan terbaru yang dimulai untuk pipeline.

Tabel berikut menunjukkan kapan setiap jenis pembaruan tersedia:

Jenis Pembaruan	Tersedia di UI selama	Dihapus dari UI ketika
Pembaruan rutin	Itu masih dalam jendela retensi, atau masih aktif (belum selesai). Pembaruan aktif tetap tersedia meskipun dimulai sebelum jendela retensi.	Sudah selesai dan lebih tua dari jendela retensi.
Eksekusi kering	Ini adalah pembaruan terbaru dari pipeline.	Setiap pembaruan berikutnya akan dimulai, baik itu latihan ulang atau pembaruan biasa.

Dalam semua kasus, event pembaruan tetap ada di log event setelah hasilnya tidak lagi ditampilkan 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.