Azure Data Explorer 高攝取延遲和流式傳輸

Question

我們正在使用 stream 從事件中心攝取到 Azure 數據資源管理器。 該文檔指出以下內容：

流式攝取操作在 10 秒內完成，完成后您的數據立即可供查詢。

我也知道一些限制，例如

流式攝取性能和容量隨着 VM 和集群大小的增加而擴展。 每個核心的並發攝取請求數限制為六個。 例如，對於 16 個核心 SKU，例如 D14 和 L16，支持的最大負載為 96 個並發攝取請求。 對於兩個核心 SKU，例如 D11，支持的最大負載是 12 個並發攝取請求。

但我們目前正在經歷 5 分鍾的攝取延遲（如 Azure 指標所示），並且看到數據實際上可在攝取 10 分鍾后進行查詢。

我們的開發環境是最便宜的 SKU 開發（無 SLA）_Standard_D11_v2，但鑒於我們在此環境中每天僅攝取約 5000 個事件（按“接收的事件”度量），此延遲非常高，無法在我們需要的流式傳輸場景中使用使數據可用 < 1 分鍾進行查詢。

這是我們必須從開發環境中獲得的延遲，還是我們可以應用的任何調整以在這些環境中實現更低的延遲？

延遲在 Standard_D12_v2 等生產環境中的表現如何？ 我們是否也必須期待那些高數字，或者在這個問題上，開發/測試和生產環境之間的行為是否存在根本差異？

Answer 1

您是否遵循了為特定表啟用流式攝取所需的兩個步驟，即在集群和表上啟用流式攝取？

通常，這是意料之中的，如果您使用一些事件對其進行測試並看到相同的延遲，則開發/測試集群應該表現出與生產集群相同的行為，並且在操作的大小和規模方面具有預期的限制出事了。

如果您確實遵循了這些步驟，但仍然無法正常工作，請打開支持票。