Changing rate statistics

[chinghongfang]

#1024 (comment)

這隻 PR 實做了計算 "時間區間增減率" 的統計值。
創建時，使用者給予一時間區間 (e.g. 1 秒)，接著，每次紀錄(Stat#record())增減的數值 (e.g. +2.2 or -5.0)，WindowedRate 的觀察結果會是 增加量/過去總量 。以下舉個例子：假設我們設的時間區間是 2 時間單位

Time	Record Value	Current Value	measurement
0		0	0.0
1	+10	10	10/0 becomes Inf
2	+5	15	15/0 becomes Inf
3		15	(15-10)/10 = 0.5
4	-5	10	(10-15)/15 = -0.33
5		10	(10-15)/15 = -0.33
6		10	0.0

在時間 0 時，沒有任何紀錄，沒有比率。
在時間 1 時，紀錄了 +10，統計值會回傳正無限大，因為過去的值是0，除以零在浮點數運算會回傳 正負無限大。
在時間 2 時，紀錄了 +5，統計值會回傳正無限大，相同原因。
在時間 3 時，統計值會回傳 0.5，代表和時間 1 相比，數值增加 0.5 倍。
在時間 4 時，紀錄了-5，統計值會回傳 -0.33，代表和時間 2 相比，數值減少 0.33 倍。
到時間 6 時，統計值會回傳 0.0，代表和時間 4 相比，數值沒有變化。

---

11/13 (updated)
另外，新增了新的統計類別，WindowedRate，每次紀錄 "新增" or "減少" 的值。
回傳的觀測值將會是，和前段時間相比，增加的 "比率"。

比如說，假設觀測區間是 10 秒，且 10 秒前的值是 100，在這 10 秒內，增增減減總和是 +60 (現在的值是160)，那麼觀測值就會回傳 60%。

---

另外，也把 ConsumerThread 修改成使用 WindowedRate 來新增/減少的 partitions 數量。

---

另外，新增了新的統計類別，SetDifference，每次可以紀錄

1. 新增元素到集合
2. 從集合移除元素

可以觀察的值有

1. 現在集合內的元素數量
2. 和前 n 次比，多出來的元素數量
3. 和前 n 次比，減少的元素數量
4. 和前 n 次比，沒變得元素數量

[chia7712]

另外，新增了新的統計類別，SetDifference，每次可以紀錄
新增元素到集合
從集合移除元素
可以觀察的值有
現在集合內的元素
和前 n 次比，多出來的元素
和前 n 次比，減少的元素
和前 n 次比，沒變得元素

這個概念蠻有趣的，不過如果我們討論“統計”的話，重點放在“數值”上的變化就好，”元素“的真實內容是可以不在意的，尤其像 consumer 的例子中，partitions真的測試下可能數百數千，這時候我們並不會真的去看“有哪些partitions"，而是應該去看“數量變化而已"，因此我會建議改成觀察下列項目：

1. 現在集合內的元素數量
2. 和前 n 次比，多出來的元素數量
3. 和前 n 次比，減少的元素數量
4. 和前 n 次比，沒變得元素數量

[chia7712]

@chinghongfang 感謝更新，大致看起來還不錯，麻煩接著處理後續的議題：

1. 合併AvgRateByTime and Avg
2. 更新 perf 文件，將 consumer 的更新寫上去

[chinghongfang]

1. 合併AvgRateByTime and Avg

已經在 #1144 完成。

2. 更新 perf 文件，將 consumer 的更新寫上去

也順帶將其他過期文檔修正。

[chia7712]

@chinghongfang 我覺得這個議題討論到有點歪掉了，我們試著從結果回頭看一下 ( @harryteng9527 也麻煩看一下，這關係到你的實驗），簡單來說，要做測試的話我們“至少”需要兩張圖：

1. 每次 balancer 觸發後各個 consumers 負責的 partitions 變化量，例如：

2. consumers 的吞吐量/延遲圖，要搭配上面那張來顯示每次負載平衡的變化

就目前 perf 的指標來看，第一張圖無法畫出，因為我們只知道訂閱的partitions數量，但不知道其中是不是有變化，例如 consumer a 原本訂閱10個，負載平衡後也是10個，但我們不知道那10個是不是保持不變

[chinghongfang]

現在這隻 PR 和原本一樣，紀錄了

1. 現在 consumer 持有的 partition 量
2. rebalance 後，non-sticky partition 的量
3. rebalance 後，增/減 的 partition 量

就目前 perf 的指標來看，第一張圖無法畫出，因為我們只知道訂閱的partitions數量，但不知道其中是不是有變化

請問 "變化" 是指 non-sticky 的數量嘛？如果是的話，現在有紀錄 rebalance 後，non-stikcy partition 的量。

[harryteng9527]

目前看下來 @chinghongfang 是在 re-balance 時利用 listener 儲存 assigned、revoked 的 partitions，之後可以呼叫 static method 去計算 consumer instance re-balance 後的 non-sticky、sticky partition 的數量。

就我的想法，最終實驗所呈現的圖可能可以用下列的組合來說明：

1. re-balance 前後的 assignment 數量差異 與 吞吐量、延遲的關係
   • 這邊或許還能看出不同 consumer instance 在 re-balance 後，被分配了相同數量的 partitions 但吞吐量有差異，可能就可以透過 sticky partitions 的數量來解釋？
2. re-balance 的 downtime 時間與 sticky partition、 assignment 數量差異 的關係圖

而目前 @chinghongfang 已經在 listener 紀錄了 partitions ，這樣就能計算出 sticky partition 的數量。

1. 每次 balancer 觸發後各個 consumers 負責的 partitions 變化量，例如：

這邊的 partitions 變化量是指 sticky partitions 的數量變化嗎？ 還是 re-balance 前後的 assignment 數量差異？

[chia7712]

請問 "變化" 是指 non-sticky 的數量嘛？如果是的話，現在有紀錄 rebalance 後，non-stikcy partition 的量。
邊的 partitions 變化量是指 sticky partitions 的數量變化嗎？ 還是 re-balance 前後的 assignment 數量差異？

這個部分可以由 @chinghongfang 提到的東西（下方）來完成，所以這部分我沒有疑問

現在 consumer 持有的 partition 量
rebalance 後，non-sticky partition 的量
rebalance 後，增/減 的 partition 量

re-balance 前後的 assignment 數量差異 與 吞吐量、延遲的關係
這邊或許還能看出不同 consumer instance 在 re-balance 後，被分配了相同數量的 partitions 但吞吐量有差異，可能就可以透過 sticky partitions 的數量來解釋？
re-balance 的 downtime 時間與 sticky partition、 assignment 數量差異 的關係圖

這邊其實要講的故事叫做 "balance的成本“ ( 類似 @qoo332001 的題目），也就是為了讓 consumers 達到平衡，我們需要付出多少的成本？例如我們設計的 balancer 要執行多久？每次平衡的 partitions 變化量多大？會造成多少額外的延遲？會降低多少吞吐量？這些數字的優劣最好的呈現方式就是跟既有的 consumer policy 比較，這也是為何我先前會說實作來不及的話，拿既有的方法去做實驗也是一種貢獻，因為這些數據也很重要

@chinghongfang 如果已經有該些基本的數據了，那這隻PR還是應該要回頭把可以做成“趨勢”的統計做完，例如可以呈現近1/5/15分鐘的partitions變化

[chinghongfang]

可以做成“趨勢”的統計做完，例如可以呈現近1/5/15分鐘的partitions變化

不好意思，先確認一下 "近1/5/15分鐘的partitions變化"，是指 1/5/15 分鐘的平均值嘛？
如果是的話，想請問這裡需要 "趨勢" 的統計嘛？
如前面所說的，每一次的 rebalance 都很重要，另外 rebalance 發生的頻率也不會太頻繁，這裡用 "1/5/15 分鐘的平均值" 來統計 partitions 變化，是否有幫助？

[chia7712]

不好意思，先確認一下 "近1/5/15分鐘的partitions變化"，是指 1/5/15 分鐘的平均值嘛？
如果是的話，想請問這裡需要 "趨勢" 的統計嘛？
如前面所說的，每一次的 rebalance 都很重要，另外 rebalance 發生的頻率也不會太頻繁，這裡用 "1/5/15 分鐘的平均值" 來統計 partitions 變化，是否有幫助？

這個跟取樣的意思不太一樣，取樣是在實際無法觀察「全部」的值下的折衷辦法（通常是考慮效能問題），近 1/5/15分鐘這個則是用來反應「最近」的數字變化，另外它的平均概念上是逐漸「淡化」過去的值對變化的影響

[chinghongfang]

如果以上面那張圖的灰色線來舉例，那張圖看起來是只有 5 個值 (5 次 measure) 的折線圖。
那麽把灰色的那條化成 "趨勢" 的話，是不是會長得像下面這張圖的灰色虛線這樣呢？

[chia7712]

那麽把灰色的那條化成 "趨勢" 的話，是不是會長得像下面這張圖的灰色虛線這樣呢？

是的，不過我要提醒1/5/15分鐘這種「平均」是已經將「時間」和「數字」揉合在一起，通常是用來快速讓讀者看一個數字而知道「趨勢」。相比之下，你也可以收集很多每次發生的變化，然後畫成折線圖再將時間軸壓縮一樣可以看到趨勢。

所以不要把兩者的用途混在一起，對於 perf tool 來說，我們每次在console上秀出來的數據都應該要具有上述的「趨勢」特性（例如我們會算好平均吞吐量而不是印出每次寫出去的資料量），這樣方便使用者快速觀察。

[chia7712]

@chinghongfang 大體上還不錯，我們稍微加速把這個項目合併

@harryteng9527 也要麻煩你日後用於實驗看是否能產生“值得觀察”的圖表

[chia7712]

LGTM