共用方式為

內嵌批次處理

  • 發行項

概觀

適用於： ✅Microsoft網狀架構✅Azure 數據總管

在佇列擷取程式期間，服務會在擷取之前將小型輸入數據區塊批處理，以優化輸送量。 批處理可減少佇列擷取程式所耗用的資源，而且不需要擷取后資源來優化非批次擷取所產生的小型數據分區。

在擷取之前進行批處理的缺點是強制延遲。 因此，從要求數據擷取到準備查詢的數據都較大為止，端對端時間。

當您定義原則 IngestionBatching 時，必須找出優化輸送量與時間延遲之間的平衡。 此原則適用於佇列擷取。 它會定義將小型 Blob 批處理在一起時允許的最大強制延遲。 若要深入瞭解如何使用批處理原則命令和優化輸送量，請參閱：

密封批次

大量擷取的最佳大小約為 1 GB 的未壓縮數據。 擷取具有較少數據的 Blob 是次佳，因此在佇列內嵌中，服務會將小型 Blob 批處理在一起。

下列清單顯示用來密封批次的基本批處理原則觸發程式。 當符合第一個條件時，批次會密封並內嵌：

  • Size：已達或超過批次大小限制
  • Count：已達到批處理檔號碼限制
  • Time：批處理時間已過期

原則 IngestionBatching 可以在資料庫或數據表上設定。 預設值如下：5 分鐘最大延遲時間、500 個專案、大小總計 1 GB。

重要

將此原則設定為非常小值的影響是 COGS（銷售的商品成本）增加，並降低效能。 此外，由於管理多個擷取程式的額外負荷，減少批處理原則值實際上 可能會導致有效的端對端擷取延遲增加 。

下列清單顯示封存單一 Blob 擷取相關批次的條件。 符合條件時，批次會密封並內嵌：

如果設定條件 SystemFlush ，則會在觸發系統排清時密封批次。 SystemFlush設定參數時，系統會排清數據，例如，因為資料庫調整或系統元件的內部重設。

預設值和限制

類型 屬性 預設 低延遲設定 最小值 最大值
項目數 MaximumNumberOfItems 500 500 1 25,000
資料大小 （MB） MaximumRawDataSizeMB 1024 1024 100 4096
時間 （TimeSpan） MaximumBatchingTimeSpan 00:05:00 00:00:20 - 00:00:30 00:00:10 00:30:00

使用擷取批處理原則控制端對端延遲的最有效方式，是根據延遲需求的較高界限，改變其在數據表或資料庫層級的時間界限。 資料庫層級原則會影響該資料庫中未定義數據表層級原則的所有數據表，以及任何新建立的數據表。

重要

如果您在低輸入數據表上設定擷取批處理原則的時間界限太低，當資料庫嘗試優化新建立的數據分區時，可能會產生額外的計算和記憶體工作。 如需數據分區的詳細資訊，請參閱 範圍。

批次數據大小

批處理原則數據大小會針對未壓縮的數據進行設定。 對於 Parquet、AVRO 和 ORC 檔案，會根據檔案大小計算估計。 針對壓縮的數據，未壓縮的數據大小會以精確度遞減順序進行評估：

  1. 如果在擷取來源選項中提供未壓縮的大小，則會使用該值。
  2. 使用 SDK 擷取本機檔案時，會檢查 zip 封存和 gzip 數據流，以評估其原始大小。
  3. 如果先前的選項未提供數據大小，則會將因數套用至壓縮的數據大小，以估計未壓縮的數據大小。

批處理延遲

延遲可能會導致許多可使用批處理原則設定來解決的原因。

原因 解決方法
數據延遲與 time 設定相符，數據太少而無法達到 size 或 count 限制 time減少限制
由於大量非常小型的檔案，所以批處理效率不佳 增加來源檔案的大小。 如果使用 Kafka 接收，請將它設定為以 ~100 KB 區塊或更新版本傳送數據。 如果您有許多小型檔案，請在資料庫或數據表擷取原則中增加 count （最多 2000 個）。
批處理大量未壓縮的數據 擷取 Parquet 檔案時，這是常見的。 以累加方式將數據表或資料庫批處理原則縮減 size 為 250 MB，並檢查是否有改進。
待處理專案，因為資料庫正在調整 接受任何 Azure 建議程序建議，以將資料庫相應放大或相應增加。 或者，手動調整資料庫，以查看待辦專案是否已關閉。 如果這些選項無法運作，請連絡支持人員以尋求協助。