Simplify ClusterLogAllocation

[chia7712]

這隻PR示範如何簡化ClusterLogAllocation

一個關鍵的地方是LayeredClusterLogAllocation很在意產生規劃過程中的物件建構成本，這導致LayeredClusterLogAllocation在設計上需要耗費很多程式碼去避免不斷產生規劃時額外製造的物件，但或許這個問題並不需要在意，原因有二：

1. 使用者不可能一次處理過多的partitions，這個搬移的成本會很恐怖
2. 假如使用者打算一次搬移很多partitions，那麼產生規劃所需的時間相比之下根本九牛一毛，更不用去在意如何少產生幾個物件

因此LayeredClusterLogAllocation這個物件其實可以省略，我們可以就immutable object的思維來設計ClusterLogAllocation

[chia7712]

@qoo332001 @garyparrot 這個是禮拜三會議的起頭，現在的balancer裡面還有很多地方有點過度設計可以簡化，當然這隻PR不一定正確，或許你們有看到一些我沒想到的地方，都可以在禮拜三之前先在這隻PR上討論

[garyparrot]

一個關鍵的地方是LayeredClusterLogAllocation很在意產生規劃過程中的物件建構成本，這導致LayeredClusterLogAllocation在設計上需要耗費很多程式碼去避免不斷產生規劃時額外製造的物件，但或許這個問題並不需要在意，原因有二：
使用者不可能一次處理過多的partitions，這個搬移的成本會很恐怖

當初的效能優化並非在優化處理大量 Partition 的搬移情境，那個情境和你說的一樣搬移成本很高，通常不太會有人這樣做，當時優化的目標是，在大叢集環境中，增進搜尋計劃的速度，這個計劃生成是整體流程的第一站，如果他跑太慢會連帶使後面的 Cost Function 計算也變慢，想象一個叢集有 7500 多個 Log，我們對他做 3 個搬移，可能有 7500*7499*7498 種可能(隨便算的)，然後當時因為資料複製的問題，導致這個計劃生成的第一站每秒只能產生 250 多個計劃，整體搜尋的效果會很差勁，造成整體計劃搜尋效率的下降(浪費了很多 CPU 時間在複製幾乎相同的東西)。提升整體計劃搜尋速度才是主要要修正的東西

https://github.com/skiptests/astraea/pull/474/files#diff-f06d96b5278eae4f511ab84dff9de7dda606622975d4597be3330529b3dcb64bR177

這個實作內依然有複製整個 Map，他在 log 數量大的時候也會撞到類似的問題，immutable object 很好，但當我們複製的 object 變重的時候又是另外一回事。我一開始也是寫 immutable object 的版本，撞到那個問題之後才改成 Layered 的版本。

或是說我們去哪裡找個 lazy 版本的 map 來使用。

[chia7712]

我們對他做 3 個搬移，可能有 750074997498 種可能(隨便算的)，

我確認一下，這邊說的log是指replica嗎？如果是的話，ClusterLogAllocation在使用上會保存「所有」的replica allocation嗎？我的想象中那應該是保存「目標」topic的partitions而已，換言之，在ClusterLogAllocation這一層保存的物件不會涵蓋整個叢集的範圍。如果會的話，那可能要重新審視架構面的東西，這代表有太多「類別」用來表達「同樣」的東西

然後當時因為資料複製的問題，導致這個計劃生成的第一站每秒只能產生 250 多個計劃，整體搜尋的效果會很差勁，造成整體計劃搜尋效率的下降(浪費了很多 CPU 時間在複製幾乎相同的東西)。提升整體計劃搜尋速度才是主要要修正的東西

這是一個好問題，一秒250個是足夠還是不足夠？感覺你是覺得不夠多，那麼可否分享一下原因是什麼？例如你做了實驗發現比較好的評估通常落在後面20000個計畫？如果是的話，或許是要考慮說為何好的計畫落在後面，而不是我們能多快找到好的計畫

或是說我們去哪裡找個 lazy 版本的 map 來使

承接上面的討論，我希望先確定這個「問題」是值得處理的，否則我們只是花了很多時間寫很複雜的程式碼去處理一個不值得的問題

[garyparrot]

我確認一下，這邊說的log是指replica嗎？如果是的話，ClusterLogAllocation在使用上會保存「所有」的replica allocation嗎？

看傳入的 ClusterInfo 而定，如果傳入的 ClusterInfo 只有部分訊息，那 generator 產生的結果也只有部分訊息。

我的想象中那應該是保存「目標」topic的partitions而已

目標是指?

這是一個好問題，一秒250個是足夠還是不足夠？感覺你是覺得不夠多，那麼可否分享一下原因是什麼？例如你做了實驗發現比較好的評估通常落在後面20000個計畫？如果是的話，或許是要考慮說為何好的計畫落在後面，而不是我們能多快找到好的計畫

嘗試次數本來就是多多易善，沒有足夠的問題。能不能快速找到好的計劃，除了要看 generator 吐出的計劃品質，能不能快速產生結果也有一些因素在，你的問題是前者(generator 的品質)的問題，而原先的 layered 版本在處理後者。

[chia7712]

目標是指?

我想像中的用法是基於topic來作負載平衡，所以這裡說的目標是指某個topic的replicas

嘗試次數本來就是多多易善，沒有足夠的問題。能不能快速找到好的計劃，除了要看 generator 吐出的計劃品質，能不能快速產生結果也有一些因素在，你的問題是前者(generator 的品質)的問題，而原先的 layered 版本在處理後者。

你這段話講的是正確的，但沒有回答說「為何你覺得後者這個問題值得處理」，例如你說一秒250個規劃的效果很差勁，這會有兩個議題（就如我前面說的，你這邊複述的）品質和速度，為何你選擇處理後者。另外你這邊提到的差勁是指什麼意思？是已經有一個方式來評估plan了嗎？如果是的話，可否分享一下方法？

[garyparrot]

我想像中的用法是基於topic來作負載平衡，所以這裡說的目標是指某個topic的replicas

你是指 cluster log allocation 或說 generator 的輸出只包含他要做的變更嗎

你這段話講的是正確的，但沒有回答說「為何你覺得後者這個問題值得處理」，例如你說一秒250個規劃的效果很差勁，這會有兩個議題（就如我前面說的，你這邊複述的）品質和速度，為何你選擇處理後者。

當時我還有餘力，所以就順帶處理後者，前者的部分我覺得現階段還不需要處理，隨機在小規模的情境下夠用。

另外你這邊提到的差勁是指什麼意思？是已經有一個方式來評估plan了嗎？如果是的話，可否分享一下方法？

差勁只是形容詞，指他花了不少力氣在複製資料而非評估計劃。評估計劃是 Cost Function 在做的事情

[chia7712]

你是指 cluster log allocation 或說 generator 的輸出只包含他要做的變更嗎

是的

當時我還有餘力，所以就順帶處理後者，前者的部分我覺得現階段還不需要處理，隨機在小規模的情境下夠用。
差勁只是形容詞，指他花了不少力氣在複製資料而非評估計劃。評估計劃是 Cost Function 在做的事情

這個就很像之前 @wycccccc 一直被我抓著問，也是工程領域很需要的一個技能，叫做“這個解法、這個問題，值不值得"

簡單來說，你當時選擇了一個較為“複雜”的方式來處理“這個問題“，這是因為你發現了什麼關鍵的瓶頸還是只是”感覺“要處理所以就處理？如果是前者的話，就會想知道那個關鍵的瓶頸是什麼？（例如你前面給了一個叫做250/秒，當然這可能是你隨意給的或是憑感覺給的)，如果是後者的話，那我們可以試著去釐清你的“感覺”正不正確，如果正確，那我們接下來就討論該如何去處理這個問題，要維持原本較為複雜的方式？還是如我前面提到要去處理產生規劃的品質。反之你的感覺不正確，那故事就很簡單，我們一起來簡化balancer的架構

[chia7712]

@garyparrot @qoo332001 麻煩你們看一下~

[chia7712]

@garyparrot 我先合併此PR，你有任何回饋我都會再開PR修正