Pertimbangan produksi untuk Streaming Terstruktur

Jalankan beban kerja Structured Streaming di lingkungan produksi sebagai Lakeflow Jobs terjadwal di Azure Databricks. Lihat Pekerjaan Lakeflow.

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 Structured Streaming menggunakan komputasi tujuan umum. Selalu jadwalkan aliran sebagai Pekerjaan Lakeflow menggunakan komputasi pekerjaan.
  • Jadwalkan Pekerjaan Lakeflow 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:

Databricks memperkenalkan alur Lakeflow untuk mengurangi kompleksitas pengelolaan infrastruktur produksi untuk beban kerja Streaming Terstruktur. Databricks merekomendasikan penggunaan alur Lakeflow untuk alur Streaming Terstruktur baru. Lihat Spark Declarative Pipelines.

Catatan

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

:::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.

:::

Kurangi latensi untuk streaming operasional

Beban kerja streaming operasional mengambil, mengubah, dan bertindak pada data hampir secara real time. Contoh umum termasuk deteksi penipuan, deteksi anomali, personalisasi, serta pemantauan dan peringatan secara real-time, di mana pemrosesan yang tertunda langsung memengaruhi hasil bisnis. Latensi rendah untuk beban kerja ini biasanya berarti puluhan hingga ratusan milidetik, meskipun banyak tim menetapkan perjanjian tingkat layanan (SLA) dalam rentang detik untuk memperhitungkan variabilitas pada persentil yang lebih tinggi.

Untuk latensi end-to-end terendah, gunakan mode real-time, yang mencapai latensi end-to-end di bawah satu detik pada kondisi terburuk dan sekitar 300 milidetik dalam kondisi umum. Lihat konsep mode waktu nyata.

Ketika mode real-time tidak sesuai dengan beban kerja Anda, praktik terbaik berikut mengurangi latensi untuk Structured Streaming micro-batch:

  • Mode keluaran: Gunakan mode pembaruan jika operator kueri dan sink Anda mendukungnya. Mode pembaruan menghasilkan baris yang diperbarui setelah setiap pemicu dijalankan dan terus memperbarui baris tersebut hingga watermark kedaluwarsa, jadi pastikan downstream sink Anda bersifat idempoten untuk menangani hasil yang diperbarui. Gunakan mode append untuk beban kerja yang tidak didukung oleh mode pembaruan, seperti join stream-stream, atau saat Anda dapat mengabaikan data yang datang terlambat. Jangan gunakan mode lengkap untuk latensi rendah. Lihat Pilih mode output untuk Streaming Terstruktur.
  • Pemicu: Gunakan pemicu processingTime dengan interval 0, yang memulai mikro-batch berikutnya segera setelah mikro-batch sebelumnya selesai dan data baru tersedia. Ini memberikan latensi micro-batch terendah, tetapi meningkatkan biaya API penyimpanan cloud. Jangan gunakan AvailableNow, Once, atau Continuous untuk beban kerja operasional. Lihat Konfigurasi Interval Pemicu Streaming Terstruktur.
  • Watermark: Atur watermark cukup lama untuk memasukkan data yang datang terlambat sehingga beban kerja Anda tidak boleh turun. Watermark mengatur berapa lama kueri menerima data event-time yang datang tidak berurutan sebelum membuangnya dan membersihkan status, sehingga watermark yang terlalu pendek akan diam-diam membuang rekaman valid yang datang terlambat. Dalam batasan tersebut, watermark yang lebih pendek menurunkan latensi dan mempertahankan status yang lebih sedikit, dan watermark yang lebih panjang mentolerir data yang lebih terlambat dengan mengorbankan latensi dan status. Kelipatan kecil dari SLA latensi Anda, seperti 2x, adalah titik awal yang masuk akal untuk penyetelan. Lihat Terapkan watermark untuk mengontrol ambang batas pemrosesan data.
  • Sumber dan penyerap: Baca dari sumber berlatensi rendah seperti bus pesan (Apache Kafka, Amazon Kinesis, Apache Pulsar, atau Google Cloud Pub/Sub) atau ubah data feed dari tabel Delta Lake dan Apache Iceberg. Menulis ke tujuan output berlatensi rendah dan berthroughput tinggi seperti bus pesan, basis data operasional, atau tujuan output foreach. Rancang operasi sink agar idempoten sehingga konsumen hilir dapat menangani data duplikat dan data yang terlambat masuk.
  • Status dan checkpointing: Untuk kueri stateful, gunakan penyimpanan status RocksDB, yang diperlukan untuk checkpointing changelog dan checkpointing status asinkron. Aktifkan checkpointing changelog untuk menyimpan secara persisten hanya perubahan status inkremental. Ketika proses checkpoint status menjadi hambatan utama dalam durasi batch Anda, aktifkan checkpoint status asinkron agar penulisan checkpoint dapat berjalan bersamaan dengan micro-batch berikutnya, setelah meninjau catatan penting terkait pemulihan dari kegagalan dan pengubahan ukuran klaster. Sediakan direktori checkpoint tersendiri untuk setiap kueri di penyimpanan awan yang persisten. Lihat Mengonfigurasi penyimpanan status RocksDB di Azure Databricks, Titik pemeriksaan status asinkron untuk kueri berkeadaan, dan Titik pemeriksaan Structured Streaming.
  • Manajemen offset: Untuk mengurangi latensi akibat checkpoint offset pada stream kontinu, aktifkan pelacakan progres asinkron, yang memperbarui log offset dan log komit tanpa menghambat pemrosesan data. Itu tidak kompatibel dengan pemicu AvailableNow atau Once. Lihat Pelacakan kemajuan asinkron.
  • Lompatan penyimpanan: Pertahankan komputasi dalam satu pipeline streaming tunggal jika memungkinkan. Membagi logika ke beberapa tugas atau pipeline menambah tahapan penyimpanan yang meningkatkan latensi.

Merancang beban kerja streaming untuk mengharapkan kegagalan

Databricks merekomendasikan agar Anda selalu mengonfigurasi pekerjaan streaming untuk memulai ulang secara otomatis saat gagal. Beberapa kemampuan, termasuk evolusi skema, mengharuskan beban kerja Streaming Terstruktur 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.

Saat tugas dicoba ulang

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.

Untuk detail selengkapnya tentang bekerja dengan beberapa tugas atau kueri, lihat Menjalankan beberapa kueri Streaming Terstruktur pada kluster yang sama.

Mengonfigurasi pekerjaan Streaming Terstruktur untuk memulai ulang kueri streaming saat gagal

Databricks merekomendasikan agar Anda 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 Lakeflow, 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. Memanggil awaitTermination() kembali memunculkan pengecualian kueri pada driver.
  • Last updated on