Pertimbangan produksi untuk Streaming Terstruktur

Halaman ini berisi rekomendasi untuk menjadwalkan beban kerja Streaming Terstruktur menggunakan pekerjaan di Azure Databricks.

Databricks merekomendasikan agar Anda selalu mengonfigurasi hal berikut:

  • Hapus kode yang tidak perlu dari notebook yang akan mengembalikan hasil, seperti display dan count.
  • Jangan jalankan beban kerja Streaming Terstruktur menggunakan komputasi serba guna. Selalu jadwalkan aliran data sebagai pekerjaan menggunakan komputasi pekerjaan.
  • Jadwalkan pekerjaan menggunakan Continuous mode. Ini mengacu pada fitur penjadwalan Pekerjaan Azure Databricks, bukan interval trigger Streaming Terstruktur.
  • Jangan aktifkan penskalaan otomatis untuk komputasi untuk pekerjaan Streaming Terstruktur.

Beberapa beban kerja mendapat manfaat dari hal berikut:

Azure Databricks telah memperkenalkan Alur Deklaratif Lakeflow Spark untuk mengurangi kompleksitas pengelolaan infrastruktur produksi untuk beban kerja Streaming Terstruktur. Databricks merekomendasikan penggunaan Alur Deklaratif Lakeflow Spark untuk alur Streaming Terstruktur baru. Lihat Alur Deklaratif Lakeflow Spark.

Catatan

Komputasi penskalaan otomatis memiliki batasan dalam mengurangi ukuran kluster untuk beban kerja Terstruktur Streaming. Databricks merekomendasikan penggunaan Alur Deklaratif Lakeflow Spark dengan penskalaan otomatis yang disempurnakan untuk beban kerja streaming. Lihat Mengoptimalkan pemanfaatan kluster Alur Deklaratif Lakeflow Spark dengan Autoscaling.

:::note Komputasi tanpa server

Pada komputasi tanpa server, hanya Trigger.AvailableNow() dan Trigger.Once() didukung. Databricks merekomendasikan Trigger.AvailableNow().

Untuk streaming berkelanjutan pada komputasi tanpa server, gunakan mode alur yang dipicu atau berkelanjutan dalam mode berkelanjutan.

Lihat Batasan streaming.

:::

Merancang beban kerja streaming untuk mengharapkan kegagalan

Databricks merekomendasikan selalu mengonfigurasi pekerjaan streaming untuk memulai ulang secara otomatis saat gagal. Beberapa kemampuan, termasuk evolusi skema, mengharuskan beban kerja Streaming Terstruktur dikonfigurasi untuk mencoba kembali secara otomatis. Lihat Mengonfigurasi pekerjaan Streaming Terstruktur untuk memulai ulang kueri streaming saat gagal.

Beberapa operasi seperti foreachBatch memberikan jaminan setidaknya-sekali daripada tepat-sekali. Pastikan bahwa alur pemrosesan Anda bersifat idempoten untuk operasi-operasi ini. Lihat Gunakan foreachBatch untuk menulis ke sink data sembarang.

Catatan

Saat kueri dimulai ulang, mikro-batch yang direncanakan selama eksekusi sebelumnya akan diproses. Jika pekerjaan Anda gagal karena kesalahan kehabisan memori atau Anda membatalkan pekerjaan secara manual karena mikro-batch yang terlalu besar, Anda mungkin perlu meningkatkan komputasi agar berhasil memproses mikro-batch.

Jika Anda mengubah konfigurasi di antara eksekusi, konfigurasi ini berlaku untuk batch baru pertama yang direncanakan. Lihat Memulihkan setelah perubahan dalam kueri Streaming Terstruktur.

Kapan tugas mengulang?

Anda dapat menjadwalkan beberapa tugas sebagai bagian dari pekerjaan Azure Databricks. Saat mengonfigurasi pekerjaan menggunakan pemicu berkelanjutan, Anda tidak dapat mengatur dependensi antar tugas.

Anda dapat memilih untuk menjadwalkan beberapa aliran dalam satu pekerjaan menggunakan salah satu pendekatan berikut:

  • Multiple tasks: Mendefinisikan sebuah pekerjaan dengan beberapa tugas yang menjalankan beban kerja streaming menggunakan pemicu kontinu.
  • Beberapa kueri: Tentukan beberapa kueri streaming dalam kode sumber untuk satu tugas.

Anda juga dapat menggabungkan strategi ini. Tabel berikut membandingkan pendekatan ini.

Strategi Beberapa tugas Beberapa kueri
Bagaimana sumber daya komputasi dibagikan? Databricks merekomendasikan penerapan komputasi yang berukuran sesuai untuk setiap beban kerja streaming. Anda dapat secara opsional berbagi komputasi di seluruh tugas. Semua kueri berbagi komputasi yang sama. Anda dapat secara opsional menetapkan kueri ke kumpulan penjadwal.
Bagaimana penanganan ulang dilakukan? Semua tugas harus gagal sebelum tugas dijalankan ulang. Tugas akan mencoba ulang jika ada kueri yang gagal.

Mengonfigurasi pekerjaan Streaming Terstruktur untuk memulai ulang kueri streaming saat gagal

Databricks merekomendasikan untuk mengonfigurasi semua beban kerja streaming menggunakan pemicu berkelanjutan. Lihat Menjalankan pekerjaan secara terus menerus.

Pemicu berkelanjutan memiliki perilaku berikut secara default:

  • Mencegah lebih dari satu menjalankan tugas secara bersamaan.
  • Memulai perulangan baru saat perulangan sebelumnya gagal.
  • Menggunakan penundaan eksponensial untuk pengulangan.

Databricks merekomendasikan untuk selalu menggunakan komputasi pekerjaan alih-alih komputasi serba guna saat menjadwalkan alur kerja. Pada saat kegagalan tugas dan percobaan ulang, sumber daya komputasi baru disebarkan.

Catatan

Databricks merekomendasikan agar Anda tidak menggunakan streamingQuery.awaitTermination() atau spark.streams.awaitAnyTermination(). Lihat Kapan menggunakan awaitTermination().

Kapan harus menggunakan awaitTermination()

streamingQuery.awaitTermination() dan spark.streams.awaitAnyTermination() akan memblokir utas saat ini hingga kueri streaming berakhir. Apakah akan menggunakan fungsi-fungsi ini tergantung pada lingkungan eksekusi Anda.

Untuk Pekerjaan Databricks, jangan gunakan streamingQuery.awaitTermination() atau spark.streams.awaitAnyTermination(). Fungsi-fungsi ini tidak diperlukan karena Jobs service secara otomatis mencegah penyelesaian proses saat kueri streaming aktif. Kedua fungsi menghalangi penyelesaian sel notebook dan mencegah layanan Jobs melacak kueri streaming, yang mengganggu metrik backlog serta pemberitahuan pekerjaan.

Gunakan awaitTermination() dalam kasus berikut:

Skenario penggunaan Perilaku
Notebook interaktif dalam komputasi serbaguna awaitTermination() memastikan sel tetap berjalan, memungkinkan Anda mengamati status kueri, dan memastikan bahwa kegagalan muncul di output notebook.
Lingkungan lokal dan pengembangan Saat menjalankan program Spark secara lokal, proses akan berhenti ketika utas utama selesai. Panggil awaitTermination() untuk menjaga agar program tetap hidup hingga kueri streaming selesai atau gagal.
Penyebaran kegagalan ke driver Tanpa awaitTermination(), kegagalan kueri streaming dalam konteks non-pekerjaan mungkin tidak menyebar ke utas panggilan. Kueri dapat gagal secara diam-diam, membuat kegagalan lebih sulit dideteksi dan didiagnosis. Pemanggilan awaitTermination() melempar ulang pengecualian kueri pada driver.

Menggunakan kumpulan penjadwal untuk beberapa kueri streaming

Anda dapat mengonfigurasi kumpulan penjadwal untuk menetapkan kapasitas komputasi ke kueri saat menjalankan beberapa kueri streaming dari kode sumber yang sama.

Secara default, semua kueri yang dimulai dalam sebuah notebook dijalankan dalam pool penjadwalan yang adil yang sama. Tugas Apache Spark yang dihasilkan oleh pemicu dari semua kueri streaming dalam catatan berjalan satu per satu dalam urutan "masuk pertama, keluar pertama" (FIFO). Hal ini dapat menyebabkan penundaan yang tidak perlu dalam kueri, karena tidak membagikan sumber daya klaster secara efisien.

Kumpulan penjadwal memungkinkan Anda mendeklarasikan kueri Streaming Terstruktur mana yang berbagi sumber daya komputasi.

Contoh berikut menetapkan query1 ke kumpulan khusus, sedangkan query2 dan query3 berbagi kumpulan penjadwal.

# Run streaming query1 in scheduler pool1
spark.sparkContext.setLocalProperty("spark.scheduler.pool", "pool1")
df.writeStream.queryName("query1").toTable("table1")

# Run streaming query2 in scheduler pool2
spark.sparkContext.setLocalProperty("spark.scheduler.pool", "pool2")
df.writeStream.queryName("query2").toTable("table2")

# Run streaming query3 in scheduler pool2
spark.sparkContext.setLocalProperty("spark.scheduler.pool", "pool2")
df.writeStream.queryName("query3").toTable("table3")

Catatan

Konfigurasi properti lokal harus berada di sel buku catatan yang sama tempat Anda memulai kueri streaming.

Untuk informasi selengkapnya tentang kumpulan penjadwal apache fair, lihat Dokumentasi penjadwal apache fair.

  • Last updated on