內嵌批次處理原則

概觀

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

在擷取之前執行批次的缺點是強制延遲。 因此,從要求資料擷取直到準備好查詢的資料的端對端時間會較長。

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

密封批次

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

下列清單顯示要密封批次的基本批次處理原則觸發程式。 當符合第一個條件時,批次會密封並擷取:

  • Size:已達到或超過批次大小限制
  • Count:已達到批次檔案數目限制
  • Time:批次時間已過期

您可以在資料庫或資料表上設定IngestionBatching原則。 默認值如下所示: 5 分鐘 的最大延遲時間、 1000 個專案、 總大小為 1 GB

重要

將此原則設定為極小值的影響,是在叢集的 COGS (已售出貨物成本) 方面的增加,並且會降低效能。 此外,減少批次處理原則值可能會因為平行管理多個擷取程序的額外負荷,而實際上導致有效的端對端擷取延遲增加

下列清單顯示密封與單一 Blob 擷取相關批次的條件。 當條件符合時,就會密封和擷取批次:

  • SingleBlob_FlushImmediately:擷取單一 Blob,因為已設定 'FlushImmediately'
  • SingleBlob_IngestIfNotExists:擷取單一 Blob,因為已設定 'IngestIfNotExists'
  • SingleBlob_IngestByTag:擷取單一 Blob,因為已設定 'ingest-by'
  • SingleBlob_SizeUnknown:擷取單一 Blob,因為 Blob 大小未知

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

預設值和限制

類型 屬性 預設 低延遲設定 最小值 最大值
項目數 MaximumNumberOfItems 500 500 1 25,000
資料大小 (MB) MaximumRawDataSizeMB 1024 1024 100 4096
時間 (秒) MaximumBatchingTimeSpan 300 20 - 30 10 1800

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

重要

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

批次資料大小

批次處理原則資料大小會針對未壓縮的資料設定。 若為 Parquet、AVRO 和 ORC 檔案,會根據檔案大小來計算估計值。 針對壓縮的數據,未壓縮的數據大小會以精確度遞減順序評估如下:

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

批次延遲

延遲可能是因為許多原因,可使用批處理原則設定來解決。

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