search

opensource4you / astraea

釋放kafka的無限潛能
Apache License 2.0
125 stars 45 forks source link

Allow to bypass the dynamic bandwidth estimation in `NetworkCost` #1839

Closed garyparrot closed 10 months ago

garyparrot commented 10 months ago

有一種比較 Balancer 實作的方法是給定好一個叢集的 topic/partition/replica 配置，還有預先指定好每個 topic/partition 的各項開銷，然後營造出 Balancer 上述對應的輸入下去測演算法出來的結果，這種實驗手法很重要，他能夠讓我們比較不同品牌的 Balancer 實作，如 Cruise Control。目前的 NetworkCost 實作很難簡單地做到粗體那段，這個 PR 在讓粗體那段簡單一點，進而更好做上述的實驗。

目前 NetworkCost#clusterCost 函數會接受兩個參數：ClusterInfo 和 ClusterBean，從兩個資訊去判斷叢集的網路負載平衡狀況，這個過程中函數會從 ClusterBean 中的 JMX MBeans 去推斷每個 Partition 對應的讀取/寫入流量，這個過程在原始碼中是稱作 bandwidth estimation。bandwidth estimation 是一個很複雜的過程，他通常會需要從很大大量的 metrics 去判斷/過濾/檢查輸入的 metrics 是否正確 or 對應的 topic/partition 開銷是多少，這個過程在生產環境的真實實驗中是非常必須且重要的，如 https://github.com/skiptests/astraea/issues/1641 所述，metrics 的內容可能會不穩定或蒐集不完全，因此實務上有必要做這一段事情。

但由於 bandwidth estimation 的流程，導致第一段的實驗步驟很難在目前的 NetworkCost 實作下很難做到，實驗實作必須要把 topic-1 = 1000, topic-2 = 1024, ... 這個單純的訊息壓成一個 ClusterBean，然後由於 bandwidth estimation 本身的複雜度，這個 ClusterBean 可能會包含五花八門的 metrics，比如目前 NetworkCost 會蒐集下面這些 metrics

https://github.com/skiptests/astraea/blob/084c9d643471d18750759ca241c5c38c269b0f67/common/src/main/java/org/astraea/common/cost/NetworkCost.java#L193-L206

上述六個 metrics 中只有兩個和流量有關，剩下四個都在除錯或嘗試逆推叢集的狀態。

下面這兩段程式碼示範從流量 Map 到 ClusterBean 的實作複雜程度。

https://github.com/skiptests/astraea/blob/084c9d643471d18750759ca241c5c38c269b0f67/common/src/test/java/org/astraea/common/cost/NetworkCostTest.java#L643-L648

https://github.com/skiptests/astraea/blob/084c9d643471d18750759ca241c5c38c269b0f67/common/src/test/java/org/astraea/common/cost/NetworkCostTest.java#L655-L743

PR 的修正

新增 NetworkCost#setCalculation 函數，這個函數允許我們直接指定 ClusterBean 對應的 Partition 負載，進而繞過上述的 bandwidth estimation 過程，直接插入一個我們確定沒有問題的值。

我覺得更好的修正是把 Bandwidth Estimation 這段做成一個 interface (sealed maybe)，然後第一段的實驗程式碼可以直接插入一個 estimation implementation 是總是回傳給定的 topic/partition 負載量，不過這樣做會需要做比較大幅度的更改

garyparrot commented 10 months ago

後續工作會在 #1841 完成