探索額外成本節省選擇結構化流24 x7x365正常運行時間的工作負載

[dataslicer]

我目前有多個崗位(集群)每個運行自己的工作為我的火花結構化流管道上長時間運行24 x7x365 DBR 9. x / 10。x LTS。我的sla 24 x7x365 1分鍾的延遲。

我已經完成了以下成本節約的機會:

1. 使用集群工作代替通用計算
2. 觸發間隔在1分鍾間隔處理
3. 使用公平調度器池
4. 基於利用調整職工VM SKU類型

鑒於上述,以下額外的成本節約配置證明*滿足上述流sla和支持* *磚?

1. 現貨實例
2. 自動伸縮
3. 探索的動機這兩個成本節約的選擇是因為流數據有不同的消息量(高、低)在不同時間的一天。
4. 任何新的額外的成本節約選項沒有提及到目前為止也歡迎。

* = =實證結果證明在一些大規模生產場景中對一些長時間來證明它的魯棒性。

* *支持= =狀態流和恢複支持當前引發3。x的api

的背景下,我已經應用當前(2022-04-14)由磚的最佳實踐。

支持和反對的任何引用“實例”和“伸縮”是感激。

謝謝你！

[匿名 · Accepted solution]

與結構化流自動定量不工作,所以這不是一個真正的可選項。自動定量是基於工作坐在工作隊列很長一段時間,但這並不是流的情況。流很多頻繁的小工作。

現貨實例應該省錢,但你有可能失去vm如果你出價。它也可以是有用的提前購買大量的虛擬機從雲提供商。通常,如果你提供購買很多時間你可以得到一個數量折扣。

光子實現應該加快速度,減少整個虛擬機所需要的。您將使用更多的DBUs但在一個更小的集群仍然所以你應該省錢成本少雲的整體。

[dataslicer]

謝謝你的額外的觀點!

是的,已經有一個卷折扣(VM資源提前購買)公司和雲提供商的談判。對不起我離開,是我太專注於技術的選擇。

我和你在同一頁麵,自動定量和現貨實例都不符合我的結構化流工作負載和sla。例如,恢複場景的一個“實例”的出價,我必須考慮到X的時間為下一個節點可用和Y的時間節點完成引導序列(成像和添加到我的集群)。時間變量(X + Y之和)已經把我流負載的SLA和源數據積壓。

學習你,唯一可行的變量,我沒有探索到目前為止是光子。

有一般的經驗法則理解光子如何從non-Photon集群大小/工作負載?例如,光子的物理內存需求減少20% non-Photon如果負載是相同的工作負載。但CPU核心應該是相同的。<——當然,這是一個完整的製造,但這個想法是我在尋找這樣的映射和翻譯所以我知道如何優化集群虛擬機大小的光子運行時。任何引用都欣賞。<——快樂要使它成為一個新問題的工作量是否會超出了最初的範圍問題。例如:如何優化我的計算工作負載(流)當使用光子運行時。請讓我知道。謝謝!

[匿名]

如此多的光子能做什麼取決於你在做什麼。如果你做的事情是非常兼容的sql引擎和內置函數,它是偉大的。如果你有python udf,並非如此。如果你做三角洲讀/寫那麼好。我一定會先測試它,但總的來說與光子應該快約1.8 - 2倍,所以你隻需要60%,許多工人節點。

使用光子時,SQL DAG將出現在黃色而不是正常的藍色,因此你可以看到它正在做什麼。

[dataslicer]

非常感謝您在不同的場景中描述光子改進!

我肯定會探索新路徑。