Penyegaran penuh untuk tabel streaming

Refresh penuh tabel streaming membuang semua data dan metadata yang ada dan memulai ulang aliran dari awal. Secara khusus, ini memotong tabel streaming, menghapus semua data titik pemeriksaan, dan memulai ulang proses streaming dengan titik pemeriksaan baru untuk setiap penulisan alur ke tabel. Halaman ini menjelaskan kapan Anda mungkin diharuskan untuk menjalankan refresh penuh, dan dampak menjalankan refresh penuh. Ini juga termasuk praktik terbaik tentang pembaruan penuh.

Untuk panduan tentang cara memicu refresh penuh, lihat Menjalankan pembaruan alur.

Dampak pada sumber data

Refresh penuh menghapus semua data yang ada dari tabel streaming. Jika sumber data Anda memiliki batas retensi—seperti topik Kafka dengan periode retensi singkat—beberapa data historis mungkin menjadi tidak dapat dipulihkan setelah refresh penuh.

Misalnya, jika sumber Anda adalah Kafka dengan retensi 24 jam dan Anda menjalankan refresh penuh setelah jendela tersebut, pesan yang lebih lama tidak lagi tersedia dan tidak dapat diolah ulang.

Nota

Refresh penuh tidak disarankan untuk beban kerja streaming volume tinggi atau ketika retensi upstram mencegah pemutaran ulang data historis.

Jika tabel streaming memiliki tabel hilir dependen, pipeline mengalami kegagalan hingga tabel tersebut juga sepenuhnya di-refresh, kecuali jika tabel streaming memiliki skipChangeCommits diaktifkan. Tampilan view materialisasi hilir juga harus sepenuhnya diperbarui.

Kapan menjalankan refresh penuh

Refresh penuh pada Alur Deklaratif Lakeflow Spark harus dipicu secara eksplisit. Anda dapat menjalankan refresh penuh dengan mengklik Refresh Penuh di UI alur atau dengan mengaktifkan refresh penuh otomatis di Lakeflow Connect.

Direkomendasikan untuk melakukan refresh penuh ketika perubahan mencegah kueri streaming untuk melanjutkan dengan aman dari titik pemeriksaan yang ada, atau ketika data yang telah diproses sebelumnya berisiko menjadi tidak konsisten dengan logika, skema, atau konfigurasi sumber yang telah diperbarui. Bagian berikut ini menjelaskan skenario umum.

Perubahan skema

Perubahan skema berikut dalam tabel target tidak kompatibel mundur dan memerlukan refresh penuh:

• Mengganti nama kolom tanpa mode pemetaan kolom diaktifkan.
• Mengubah kolom deduplikasi.
• Memodifikasi jenis data kolom, termasuk:
  • Ketik penyempitan (misalnya, BIGINT → INT atau DOUBLE → FLOAT).
  • Perubahan jenis yang tidak kompatibel (misalnya, STRING → INT).
• Penghapusan keras kolom dari skema tabel.

Untuk jenis perubahan skema ini, Databricks merekomendasikan untuk membuat kolom baru dengan skema atau nama yang diinginkan, lalu menggunakan tampilan di atas tabel streaming untuk menyatukan nilai lama dan baru.

Perubahan tata letak data fisik

Perubahan tata letak data fisik berikut memerlukan refresh penuh:

• Migrasi dari partisi warisan ke skema pengklusteran baru.

Perubahan sumber hulu

Perubahan sumber upstream berikut memerlukan pembaruan penuh:

• Memodifikasi tabel sumber yang dibaca oleh kueri streaming.
• Beralih antar jenis sumber (misalnya, Kafka ke Delta atau Auto Loader ke Kafka).
• Mengubah lokasi sumber, seperti jalur tabel atau langganan topik Kafka.
• Menghilangkan dan membuat ulang tabel Delta sumber, bahkan ketika skema tetap tidak berubah.

Perubahan pemrosesan stateful

Perubahan pemrosesan stateful berikut ini memerlukan refresh penuh:

• Memodifikasi kunci pengelompokan agregasi atau fungsi agregat.
• Menambahkan atau menghapus agregasi.
• Mengubah kunci gabungan atau jenis gabungan.
• Menambahkan atau menghapus gabungan.
• Memodifikasi kolom deduplikasi atau logika deduplikasi.

Masalah kelangsungan data

Refresh penuh mungkin diperlukan saat kelangsungan data disusupi:

• Log CDC menjadi tidak tersedia karena kedaluwarsa retensi.
• Kerusakan atau penghapusan direktori titik pemeriksaan streaming.
• Kerusakan atau kehilangan file pelacakan skema atau lokasi skema.

Untuk informasi selengkapnya tentang memulihkan alur dari kegagalan titik pemeriksaan, lihat Memulihkan alur dari kegagalan titik pemeriksaan streaming.

Keterbatasan

Batasan berikut berlaku untuk refresh penuh. Lihat Praktik terbaik untuk informasi guna membantu bekerja dalam batasan ini.

• Refresh penuh tidak memproses ulang data kecuali sumber Anda mempertahankan himpunan data historis lengkap.
• Himpunan data besar dapat membuat refresh penuh mahal dan memakan waktu.
• Konsumen hilir yang bergantung pada tabel mungkin gagal atau mengembalikan hasil yang tidak lengkap sampai refresh selesai.

Praktik terbaik

Situasi	Praktik terbaik
Desain untuk stabilitas	Rencanakan skema Anda untuk menghindari perubahan yang memerlukan refresh penuh. Menambahkan kolom umumnya aman, sementara memodifikasi kolom atau skema partisi yang ada biasanya memerlukan komputasi ulang tabel.
Streaming dari sumber dengan periode retensi singkat	Streaming dari sumber, seperti topik Kafka, yang tidak memiliki periode retensi yang lama berarti bahwa refresh penuh kehilangan data yang tidak masih ada di sumbernya. Untuk menghindari kehilangan data historis, mengalirkan data mentah ke dalam tabel streaming (tabel perunggu, dalam medallion architecture). Gunakan jenis kolom fleksibel (varian atau string, misalnya), untuk menghindari tabel ini yang memerlukan refresh penuh jika data hulu berubah. Tabel ini dapat menyimpan data historis dan digunakan oleh tabel streaming hilir (yang mungkin memiliki jenis yang lebih ketat atau perubahan struktural lainnya). Jika tabel hilir memerlukan refresh penuh, tabel ini memiliki data historis, sementara tidak memerlukan refresh penuh itu sendiri.
Pertimbangkan alternatif sebelum menjalankan refresh penuh	Alternatifnya meliputi: Jika mengubah sumber alur, pertimbangkan untuk membuat alur baru daripada memperbarui alur tabel streaming yang ada. Ini mempertahankan data yang ada dalam tabel, tetapi dapat menulis data duplikat karena alur baru memiliki titik pemeriksaan baru. Atau, Anda dapat mengatur ulang titik pemeriksaan, tetapi ini dapat menyebabkan data duplikat ditulis ke tabel target. Jika tidak ada opsi yang dapat diterima, pertimbangkan untuk membuat tabel streaming baru dan menggunakan tampilan untuk menyatukan tabel streaming lama dan baru.
Saat refresh penuh diperlukan	Ikuti praktik terbaik ini saat refresh penuh diperlukan: Uji operasi di lingkungan pengembangan atau penahapan. Dokumentasikan dependensi hilir yang terpengaruh. Jadwalkan refresh selama jendela pemeliharaan untuk meminimalkan dampak pada beban kerja produksi. Pastikan sistem sumber menyimpan data historis yang cukup untuk memutar ulang aliran.

Untuk mengisi ulang data setelah refresh penuh, Anda dapat membuat append oncealur. Ini melakukan pengisian ulang satu kali tanpa terus berjalan setelah isi ulang pertama. Kode tetap berada di alur Anda, dan jika alur pernah sepenuhnya di-refresh lagi, isi ulang akan dimulai ulang.