Bagikan melalui

Kebijakan batch penyerapan

  • Artikel

Gambaran Umum

Selama proses penyerapan yang diantrekan, layanan mengoptimalkan throughput dengan mengumpulkan potongan data ingress kecil bersama-sama sebelum penyerapan. Batching mengurangi sumber daya yang dikonsumsi oleh proses penyerapan yang diantrekan dan tidak memerlukan sumber daya pasca-penyerapan untuk mengoptimalkan pecahan data kecil yang dihasilkan oleh penyerapan yang tidak di-batch.

Kelemahan melakukan pembuatan batch sebelum dipakai adalah penundaan paksa. Oleh karena itu, waktu secara keseluruhan dari permintaan akan penyerapan data hingga data yang siap untuk kueri itu lebih besar.

Saat menentukan kebijakan IngestionBatching, Anda harus menemukan keseimbangan antara pengoptimalan throughput dan penundaan waktu. Kebijakan ini berlaku untuk penyerapan dalam antrean. Kebijakan ini menentukan penundaan paksa maksimum yang diizinkan saat pembuatan batch blob kecil bersama-sama. Untuk mempelajari selengkapnya tentang cara menggunakan perintah kebijakan pembuatan batch, dan mengoptimalkan throughput, lihat:

Menyegel batch

Ada ukuran optimal data yang tidak terkompresi sekitar 1 GB untuk penyerapan data secara massal. Penyerapan blob dengan data yang jauh lebih sedikit kurang optimal, sehingga saat penyerapan di antrean, layanan akan membuat batch pada blob kecil secara bersamaan.

Daftar berikut menunjukkan pemicu kebijakan pembuatan batch dasar untuk menyegel batch. Batch disegel dan diserap jika syarat pertama terpenuhi:

  • Size: Batas ukuran batch tercapai atau terlampaui
  • Count: Batas jumlah file tercapai
  • Time: Waktu pembuatan batch berakhir

Kebijakan IngestionBatching dapat diatur pada database atau tabel. Nilai default-nya adalah sebagai berikut: Waktu tunda maksimum 5 menit, 1000 item, ukuran total 1 GB.

Penting

Dampak dari penetapan kebijakan ini ke nilai yang sangat kecil adalah peningkatan COGS (biaya barang yang dijual) dari kluster dan penurunan performa. Selain itu,pengurangan nilai kebijakan pembuatan batch mungkin sebenarnya menghasilkan peningkatan latensi penyerapan menyeluruh yang efektif, karena overhead dari pengelolaan beberapa proses penyerapan secara paralel.

Daftar berikut menunjukkan syarat untuk menyegel batch yang terkait dengan penyerapan blob tunggal. Batch disegel dan diserap jika syarat terpenuhi:

  • SingleBlob_FlushImmediately: Menyerap satu blob karena 'FlushImmediately' ditetapkan
  • SingleBlob_IngestIfNotExists: Menyerap satu blob karena 'IngestIfNotExists' ditetapkan
  • SingleBlob_IngestByTag: Menyerap satu blob karena 'ingest-by' ditetapkan
  • SingleBlob_SizeUnknown: Menyerap satu blob karena ukuran blob tidak diketahui

Jika syarat SystemFlush ditetapkan, batch akan disegel saat penghapusan sistem dipicu. Dengan ditetapkannya parameter SystemFlush, sistem menghapus data, misalnya karena penskalaan kluster atau reset internal komponen sistem.

Default dan batasan

Jenis Properti Default Pengaturan latensi yang rendah Nilai minimum Nilai maksimum
Jumlah item MaximumNumberOfItems 500 500 1 25.000
Ukuran data (MB) MaximumRawDataSizeMB 1024 1024 100 4096
Waktu (dtk) MaximumBatchingTimeSpan 300 20 - 30 10 1800

Cara paling efektif untuk mengontrol latensi end-to-end menggunakan kebijakan pembuatan batch penyerapan adalah dengan mengubah batas waktunya pada tingkat tabel atau database, sesuai dengan batas persyaratan latensi yang lebih tinggi. Kebijakan tingkat database memengaruhi semua tabel dalam database yang tidak memiliki kebijakan tingkat tabel yang ditentukan, dan tabel yang baru dibuat.

Penting

Jika Anda mengatur batas waktu kebijakan Pembuatan Batch Penyerapan terlalu rendah pada tabel ingress rendah, Anda dapat menimbulkan pekerjaan komputasi dan penyimpanan tambahan saat kluster mencoba mengoptimalkan pecahan data yang baru dibuat. Untuk informasi selengkapnya tentang pecahan data, lihat jangkauan.

Ukuran data batch

Ukuran data kebijakan pembuatan batch ditetapkan untuk data terkompresi. Untuk file Parquet, AVRO, dan ORC, estimasi dihitung berdasarkan ukuran file. Untuk data terkompresi, ukuran data yang tidak terkompresi dievaluasi sebagai berikut dalam urutan akurasi dari bawah:

  1. Jika ukuran yang tidak terkompresi tersebut disediakan dalam opsi sumber penyerapan, nilai tersebut digunakan.
  2. Saat menyerap file lokal menggunakan SDK, arsip zip dan aliran gzip diperiksa untuk menilai ukuran mentahnya.
  3. Jika opsi sebelumnya tidak memberikan ukuran data, salah satu faktor diterapkan pada ukuran data terkompresi untuk memperkirakan ukuran data yang tidak terkompresi.

Latensi pembuatan batch

Latensi dapat dihasilkan dari sejumlah penyebab yang dapat diatasi menggunakan pengaturan kebijakan pembuatan batch.

Penyebab Solusi
Latensi data menyesuaikan pengaturan time, dengan terlalu sedikit data untuk mencapai batas size atau count Mengurangi batas time
Pembuatan batch yang tidak efisien karena banyaknya file berukuran sangat kecil Tingkatkan ukuran file sumber. Jika menggunakan Kafka Sink, konfigurasikan untuk mengirim data dalam gugus berukuran ~ 100 KB atau lebih tinggi. Jika Anda memiliki banyak file kecil, tingkatkan count (hingga 2.000) dalam database atau kebijakan penyerapan tabel.
Pembuatan batch sejumlah besar data yang tidak terkompresi Hal ini umum terjadi saat menyerap file Parket. Kurangi size secara bertahap untuk tabel atau kebijakan pembuatan batch database menjadi 250 MB dan periksa peningkatan.
Backlog karena kluster sedang berada di bawah skala Terima setiap saran penasihat Azure untuk menskalakan atau menaikkan skala kluster Anda. Atau, skalakan kluster Anda secara manual untuk melihat apakah backlog ditutup. Jika opsi ini tidak berfungsi, hubungi dukungan untuk bantuan.