Pemeriksaan titik status asinkron untuk kueri stateful

Catatan

Tersedia di Databricks Runtime 10.4 LTS ke atas.

Titik pemeriksaan status asinkron mempertahankan jaminan sekali persis untuk kueri streaming tetapi dapat mengurangi latensi keseluruhan untuk beberapa beban kerja stateful Streaming Terstruktur yang disempitan pada pembaruan status. Ini dicapai dengan mulai memproses mikro-batch berikutnya segera setelah komputasi mikro-batch sebelumnya telah selesai tanpa menunggu titik pemeriksaan status selesai. Tabel berikut membandingkan tradeoff untuk titik pemeriksaan sinkron dan asinkron:

Karakteristik	Titik pemeriksaan sinkron	Titik pemeriksaan asinkron
Latensi	Latensi yang lebih tinggi untuk setiap mikro-batch.	Latensi berkurang karena batch mikro dapat tumpang tindih.
Mulai ulang	Pemulihan cepat karena hanya batch terakhir yang perlu dijalankan kembali.	Penundaan restart yang lebih lama karena lebih dari satu micro-batch mungkin perlu dijalankan ulang.

Berikut ini adalah karakteristik pekerjaan streaming yang mungkin mendapat manfaat dari titik pemeriksaan status asinkron:

• Pekerjaan memiliki satu atau beberapa operasi stateful (misalnya, agregasi, flatMapGroupsWithState, mapGroupsWithState, penggabungan aliran)

• Latensi titik pemeriksaan status adalah salah satu kontributor utama terhadap latensi eksekusi batch secara keseluruhan. Informasi ini dapat ditemukan di aktivitas StreamingQueryProgress. Aktivitas ini juga ditemukan di log log4j pada driver Spark. Berikut adalah contoh progres kueri streaming dan cara menemukan dampak titik pemeriksaan status pada latensi eksekusi batch secara keseluruhan.

  • {
       "id" : "2e3495a2-de2c-4a6a-9a8e-f6d4c4796f19",
       "runId" : "e36e9d7e-d2b1-4a43-b0b3-e875e767e1fe",
       "...",
       "batchId" : 0,
       "durationMs" : {
         "...",
         "triggerExecution" : 547730,
         "..."
       },
       "stateOperators" : [ {
         "...",
         "commitTimeMs" : 3186626,
         "numShufflePartitions" : 64,
         "..."
       }]
    }
    

  • Analisis latensi titik pemeriksaan status dari aktivitas progres kueri di atas

    • Durasi batch (durationMs.triggerDuration) adalah sekitar 547 detik.
    • Latensi komit penyimpanan status (stateOperations[0].commitTimeMs) adalah sekitar 3.186 detik. Latensi penerapan diagregasikan di seluruh tugas yang berisi penyimpanan status. Dalam hal ini, ada 64 tugas seperti itu (stateOperators[0].numShufflePartitions).
    • Setiap tugas yang berisi operator status mengambil rata-rata 50 detik (3.186/64) untuk pemeriksaan. Ini adalah latensi ekstra yang berkontribusi pada durasi batch. Dengan asumsi semua 64 tugas berjalan bersamaan, langkah pos pemeriksaan menyumbang sekitar 9% (50 detik / 547 detik) dari durasi batch. Persentasenya menjadi lebih tinggi ketika jumlah tugas bersamaan maksimum kurang dari 64.

Mengaktifkan pemeriksaan status asinkron

Anda harus menggunakan penyimpanan status berbasis RocksDB untuk titik pemeriksaan status asinkron. Atur konfigurasi berikut:

spark.conf.set(
  "spark.databricks.streaming.statefulOperator.asyncCheckpoint.enabled",
  "true"
)

spark.conf.set(
  "spark.sql.streaming.stateStore.providerClass",
  "com.databricks.sql.streaming.state.RocksDBStateStoreProvider"
)

Batasan dan persyaratan untuk titik pemeriksaan asinkron

Catatan

Komputasi penskalaan otomatis memiliki batasan dalam penskalaan turun ukuran kluster untuk beban kerja streaming terstruktur. 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.

• Setiap kegagalan di titik pemeriksaan asinkron di satu penyimpanan atau lebih akan membuat kueri gagal. Dalam mode pemeriksaan sinkron, titik pemeriksaan akan dijalankan sebagai bagian dari tugas, dan Spark akan mencoba kembali tugas beberapa kali sebelum gagal dalam kueri. Mekanisme ini tidak menyajikan pemeriksaan status asinkron. Databricks merekomendasikan penggunaan pekerjaan berkelanjutan untuk percobaan ulang otomatis pada kegagalan pekerjaan. Lihat Menjalankan pekerjaan secara terus menerus.
• Titik pemeriksaan asinkron berfungsi paling baik ketika lokasi penyimpanan status tidak diubah di antara eksekusi mikro-batch. Perubahan ukuran kluster, dalam kombinasi dengan pemeriksaan titik status asinkron, mungkin tidak berfungsi baik karena instans penyimpanan status mungkin didistribusikan ulang ketika simpul ditambahkan atau dihapus sebagai bagian dari proses perubahan ukuran kluster.
• Pemeriksaan status asinkron hanya didukung dalam implementasi penyedia penyimpanan status RocksDB. Implementasi penyimpanan status dalam memori default tidak mendukung ini.