Pertimbangan produksi untuk Streaming Terstruktur

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

Databricks merekomendasikan untuk selalu melakukan 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.
• Jangan aktifkan penskalaan otomatis untuk komputasi untuk pekerjaan Streaming Terstruktur.

Beberapa beban kerja mendapat manfaat dari hal berikut:

• Mengonfigurasi penyimpanan status RocksDB di Azure Databricks
• Pemeriksaan titik status secara asinkron untuk kueri yang mempertahankan status
• Apa itu pelacakan kemajuan asinkron?

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.

Merancang beban kerja streaming untuk mengharapkan kegagalan

Databricks merekomendasikan selalu mengonfigurasi pekerjaan streaming untuk memulai ulang secara otomatis saat gagal. Beberapa fungsionalitas, termasuk evolusi skema, mengasumsikan bahwa 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. Untuk operasi ini, Anda harus memastikan bahwa alur pemrosesan Anda idempoten. 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 menetapkan kueri secara opsional 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 menyediakan 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

Anda tidak perlu menggunakan streamingQuery.awaitTermination() atau spark.streams.awaitAnyTermination(). Tugas akan secara otomatis mencegah proses menyelesaikan saat kueri streaming aktif.

Menggunakan kumpulan penjadwal untuk beberapa kueri streaming

Anda dapat mengonfigurasi kumpulan jadwal 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, sementara 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.

Lihat dokumentasi penjadwal adil Apache untuk detail lebih lanjut.