[2022] Astraea 技術發表

[chia7712]

醜婦終須見公婆，有個場合和機會展示一下我們的努力總是一件好事，類型比較合適的活動如下：

名稱	連結	發表日	截稿日期	投影片
TCSE	https://tcse2022.seat.org.tw	06.24~06.25	05.23	kafka的最後一哩路.pdf
COSCUP	https://blog.coscup.org/2022/03/coscup-2022-call-for-participation-now.html	7/30～7/31	5/15	kafka partitioner 平衡框架.pdf Apache Kafka 叢集負載平衡.pdf
iThome雲端大會	https://cloudsummit.ithome.com.tw/2022/speaker-page/575	07.26	03.31	優化 Kafka 的最後一哩路.pdf
sitcon	https://sitcon.org/2022/cfp	09.04	N/A	kafka的最後一哩路.pdf
Jcconf	https://jcconf.tw/2022/	10.07	N/A	Kafka Consumer Assignor 使用時機.pdf Kafka replica搬移成本估計.pdf
DataCon	https://2022.datacon.tw	11/20	11/25	Kafka 優化的最後一哩路.pdf

演講錄影：

https://www.youtube.com/watch?v=s-icLoa1iHc&feature=youtu.be

[wycccccc]

分享的部分我認爲按照碩士論文的樣式

1. 導論
2. 系統架構
3. 效能量測
4. 結論

我會先開始寫導論與系統架構的部分，預計3月15日前會有一個初版生出來。

[chia7712]

我會先開始寫導論與系統架構的部分，預計3月15日前會有一個初版生出來。

看看是否方便用google doc分享出來文字的部分

[chia7712]

IThome的投稿：

https://www.evernote.com/shard/s268/sh/b6d46723-873f-a408-91f0-055bb88f7e9f/563cc55dee7de4b7598bedaf8e2c29df

@garyparrot @qoo332001 麻煩也看一下，我把你們的產出也包含在裡面 ：）

[chia7712]

@garyparrot @qoo332001

Coscup 2022 的截止日在5/15 有興趣嗎

[wycccccc]

@chia7712
最後的文章應該會包含以下幾個部分

1. 前言
2. 研究背景
3. astraea partition介紹
4. 實驗數據
5. 相關研究
6. 結論

目前按進度先完成了前三個部分，我第一次嘗試寫這東西，說實話不太知道怎麼寫，所以如果有任何建議我會再及時做修改反饋。
另外會google文檔會跑版，看是要用dropbox或是其他方式也可以。
https://docs.google.com/document/d/133WwenbbnN3ia_aTy58_NVBq8J3Gsy8ESxTeenZse_w/edit?usp=sharing

後三部分及引用會在之後跟進，具體時間我還有些想法所以需要討論一下再定。

[chia7712]

@wycccccc 幾個小建議：

1. 圖檔都要自己重新畫過
2. 前言要講三個重點：
   1. kafka很屌很猛大家都在用，因此優化它是一件很有價值的事情
   2. 叢集負載不均在生產環境中是很嚴重的事情，而default partitioner無法處理
   3. 我們的partitioner可以有效應付負載不均，而且實驗證明可以提昇n%速度
3. 2.5節可以做一張圖表來說明default partitioner在面對負載不均的叢集時的吞吐量變化（越來越慢）

第一頁的內容很重要，因為很多審查委員第一頁看一看沒興趣就不會往下看了（我在審業界論文的時候就是這樣），因此要幫這些懶人把重點擺到前面去

[wycccccc]

1.圖都是自己畫得，模糊應該是google文檔的問題
2.好 我根據這些建議再思考優化一些，把第一頁做得儘量吸引人。

[chia7712]

@wycccccc 論文可能要解釋為何定義好問題後（處理負載不均），就直接選擇SWRR。例如所謂「低權重的節點長時間處於空閒狀態」這句話是要避免什麼副作用？權重低（負載重）很少被選擇會怎麼樣？

另外我上次會議提到的各種可能問題也要放在未來展望裡面，例如：
1）其他producer如果使用不同partitioner會怎麼樣？
2）異質環境
3）如何調整weight?
之類的

[wycccccc]

https://drive.google.com/file/d/1gI5Se9Ax9ZHKhjPRKjPpH6rr_hBkcwrZ/view?usp=sharing
@chia7712 總算是生出來了，大體上就是這樣。
然後表格的部分可能會再優化一下，還差注釋部分沒有完成，文章我再找時間通讀一遍改一改細節。

[chinghongfang]

COSCUP投稿

議程軌：JVM博覽會

投稿要求撰寫

1. Proposal title
2. 摘要
3. 說明(optional)
4. 備忘(optional)

Proposal title

Kafka Partitioner 平衡框架

摘要

Apache Kafka 是一個分散式事件串流平台(distributed event-streaming platform)，提供訊息的發佈與訂閱。目前有許多知名應用使用，如：LinkedIn, Line, ...等。
而分散式系統會遇到的負載平衡問題，雖然Kafka 在概念上(partition) 有為平衡作考慮，但也是會發生負載平衡問題。為了解決這個問題，我們從客戶端(client) 下手，設計一個訊息分配框架，讓使用者根據自己在意的"效能指標"，決定訊息分配的策略。

說明

Kafka producer 在發送資料時，可以選擇要把資料送到哪個partition，也因此可以從這下手，調整叢集機器間的吞吐。
不同情境會有不同的解決方法，我們設計出一個框架，讓管理員可以藉由參數調整，改變producer 的發送策略，以符合不同的情境。框架的好處在於

1. 彈性面對各式情境：
   情境有千千百百種，要一一條列解決是不可行的，因此，我們就需要框架來重複利用程式碼，藉由修改參數，滿足多種不同情境。
2. no-code 重新組態partitioner：
   在no-code 下重新組態partitioner，讓管理員無須完全瞭解底層架構，也能調整partitioner 應對方針。
3. 方便自定義：
   在未來，若出現新的情境，或許是需要"自定義的數據"，只要在程式碼中實作2~3個介面方法，便將程式插入我們的框架，方便自定義。

[chia7712]

https://drive.google.com/file/d/1gI5Se9Ax9ZHKhjPRKjPpH6rr_hBkcwrZ/view?usp=sharing

幾個建議：

Kafka 作為一個分散式系統,性能是至關重要的
一項考量。因為 Kafka 在並行傳輸大量資料方面的
顯著優勢,它常會被部署在吞吐量大的複雜環境
中。業集中的機器需要面對多個資料的發佈者與
訂閱者,且每台機器面對的發佈者與訂閱者不一
定是相同的。這就會造成每一臺機器的負載情況
也存在差異。

你的貢獻是主要是解決擴充後所帶來的副作用（負載不均），因此要強調一下“擴充性”這件事情的重要。例如：Kafka的性能至關重要不是因為“作為一個分散式系統”，而是要服務大數據。擴充性很重要，是因為要能及時反應不斷膨脹的資料吞苦需求。會造成負載的差異也不是因為“發佈者與訂閱者不一定是相同的”...

總之，這段文字有很多“因為xxx所以ooo"，但兩者的關係並沒那麼貼切。要麻煩再潤飾一下

本研究會通過製造一個負載不平衡的 Kafka 業集

這句很重要，你文章中有說明這個“不平衡”的叢集是合理的嗎？會不會這個狀況根本不可能在真實世界上演？

們設計了 Astraea Partitioner 一種新的 Partitioner 用
來替換 Kafka 中的 Default Partitioner,達到業集更

讀者可能還不知道partitioner是什麼，因此這時候直接用專有名詞可能沒那麼適當。可以考慮比較白話的方式描述，例如：我們重新設計Kafka寫入端的資料路由規則(partitioner)，藉由xxx達到oooo

Apache Kafka 的核心功能十分直觀(圖

這句太口語了XDD

上述的情況,最終導致 through put效率變差,影響

throughput"效率" -> 贅字

最終導致 through put效率變差,影響
整個業集的效能。

這兩句都是講一樣的事情。可以改一下，例如：”導致叢集資源無法被充分使用"

Kafka 有曝露出 partitioner 的接口,方便用戶
自定義符合環境的 partitioner。同時通過 Kafka
metrics 可以觀察到整個 cluster 的 metrics 數據,因
此基於過去全局資訊預測來進行判斷就成為了一
種可行的解決方案,為此我們設計了 Astraea
partitioner。

我們選擇“實作partitioner"來解決這個問題不是因為“Kafka 有曝露出 partitioner 的接口”，而是partitioner是作為資料路由的角色。

量資料造成高負載,優雅的做到根據叢集負載狀
況將 record 發佈到 partition 上。

record可以用"資料“這個字來取代。有些英文有比較通俗的中文可以用就盡量用，避免文章出現太多中英夾雜的長敘述，不好閱讀

本實驗環境共六臺機器,每一臺機器 CPU 皆為
16 核心,32GB

規格寫錯了 8核心

發送資料的 Client1 與,Client3 中,提升的效能更
加明顯,達到了 12%與 22%。

圖的單位要寫，例如 MB/s

---

晚點會再仔細看一次

[chia7712]

@chinghongfang

不同情境會有不同的解決方法，我們設計出一個框架，讓管理員可以藉由參數調整，改變producer 的發送策略，以符合不同的情境。框架的好處在於可以彈性的面對各式情境，

這邊要說明”透過參數調整改變partitioner"行為的好處，例如使用者可在no-code下重新組態partitioner

我們將提出多種情境，並實驗使用這個框架，看是否可以滿足多種不同情境。

結尾用疑問句很像是對自己的產出感到懷疑，應該要用肯定句說，你做的partitioner可以透過參數快速重新組態，以此適應不同情境下的平衡需求

[wycccccc]

謝謝學長的建議，已按照修改。目前我在自己通讀修改，暫時先不用看其他部分。

V2.0版本
https://drive.google.com/file/d/10nPRqCTnupVuSFxVSDgGMI3uSi5T_tuV/view?usp=sharing

[wycccccc]

很高興他不出意外的推遲了，這樣我可以再打磨他一下。
我自我朗誦了一遍，在朗誦的過程中對通篇一些奇怪的語句做了修改。現在他應該可以被閱讀了。

V2.1版本
https://drive.google.com/file/d/1obwjz-NNcv-rF_wx0AxdhL7dKwHF2fFu/view?usp=sharing

[chia7712]

相對於一般的 MQ 系統,例如

這邊用簡寫似乎不太必要，尤其它全寫不長、同時又是在摘要

實際應用中,企業需要處理
的資料量和資料種類往往會不斷增長,這就導致
他們必須為整個叢集添加新的 partition。

比起加入新的partition，加入新的節點應該才是更常用的解法。而且也更好說明為何會負載不均（因為新的節點會是空的）

partition。而這些
手動添加的新 partition 因為沒有限制可以添加到
任一機器上,導致在叢集使用一段時間後
partition 的分佈會變得不均勻。

這裡前因後果的連結不太順，"加入任意機器“這邊要強調會隨機選擇節點加入，才會有後面分布不均

Kafka 在創立之初的目標就是為處理實時
數據提供一個統一、高吞吐、低延遲的平台。因
此盡可能維持一個高吞吐量是每一個用戶所希望
的事。

前面那句"kafka在創立xxx"跟後面那句"用戶所希望“也是不同議題。看要不要直接改成”負載不均導致硬體資源無法有效利用“這個論點

本研究會通過製造一個負載不平衡的 Kafka 業
集,來分析模擬業集負載不均在生產環境中會帶

這邊的製造要多說一句說這個不平衡的叢集是“真的可能發生”，否則讀者可能會有一種我們故意把kafka弄糟

這代表任何用戶都能在不引入新軟體的前
提下

這句不太確實，因為要用你們的partitioner必須引入新的jar檔。如果你想說jar檔不算軟體...就有點文字遊戲了

幾乎沒有成本的讓叢集達到更好的負載平
衡。經過對新模組的測試,效能相比與原生提昇

這邊的幾乎沒有成本也需要明確說明是什麼成本，同時也要在後面數據中有所呈現。否則就淪為嘴砲了

另外throughput可以看文字上下文適當的改成用中文吞吐量，這樣閱讀會比較順。例如：

上述的情況,最終導致叢集資源無法被充分使
用,throughput 變差。

這邊就很適合改成中文的吞吐量

圖 3 : Kafka default

這張圖上下部分應該可以重繪成一張圖

可能的做到整個 cluster中每一個

cluster可以用中文叢集取代

定義 broker 負載程度

Broker字首要大寫

本文中介紹了 Astraea Partitioner,他能夠有效
地解決由 partition 分佈不均勻帶來的叢集負載不均
勻的狀況。在實驗中可以看到,當 partition 分佈不
均勻的程度越極端,提升的 throughput 效能越明
顯。

結論可以再強調一下提升的數字

最後，整篇論文強調了kafka負載平衡，但缺乏跟現行熱門工具的比較（例如confluent balancer），建議用一個小節來講為何選擇重新設計partitioner，而非做一個balancer。

[wycccccc]

根據學長給出的建議進行了修改，同樣修改的地方用黃色標註了起來。等文字部分的內容確定我會做最後的文檔格式整理。

V3.0版本
https://drive.google.com/file/d/10KUgM7xq2ynt8yLN8i149FJ23lld4Pmh/view?usp=sharing

[chia7712]

@wycccccc 感謝更新，越來越有樣子了！

我晚點會在再仔細看一下，不過2.6相關研究中講了目前方法的缺點，但少了一個回馬槍說你提的方法不會有那個缺點

[wycccccc]

已添加迴馬槍

V3.1版本
https://drive.google.com/file/d/1ufRwMHHvos9DZn7RqkGxTuiYP_riJlew/view?usp=sharing

[chia7712]

@chinghongfang

框架的好處在於
彈性面對各式情境
no-code 重新組態partitioner
方便自定義
情境有千千百百種，要一一條列解決是不可行的，因此，我們就需要框架來重複利用程式碼，藉由修改參數，滿足多種不同情境。在no-code 下重新組態partitioner，讓管理員無須完全瞭解底層架構，也能調整partitioner 應對方針。在未來，若出現新的情境，或許是需要"自定義的數據"，只要在程式碼中實作2~3個介面方法，便將程式插入我們的框架，方便自定義。

這邊的文字看起來還不錯，不過可否將最後那一段文字分別填寫到各個好處的後面，也就是每一個好處的後面再補上文字多講一些細節，這樣使用者不需要在讀最後一段的時候還需要去想哪一個敘述是屬於哪一個好處

[garyparrot]

標題: Apache Kafka 叢集負載平衡
英文標題: Apache Kafka Cluster Load Balancing Tool
提交型態: (30 分鐘)
議程軌: JVM 博覽會
語言: Traditional Chinese (Taiwan)

摘要 (300 words)

Apache Kafka 爲目前熱門的分散式事件串流平臺，本身自帶各種豐富的功能，比如 Replication, JBOD, Authn/z, Encryption, Compression, At-most/At-least/Exactly once Delivery, Transaction，目前常見的 Kafka 應用包含：高吞吐量的資料管線、串流分析應用和資料整合中介軟體。

隨著叢集經歷上層應用的業務需求增長以及叢集資源使用變化，Kafka 叢集在經過這些現實情境的摧殘後，勢必會遭逢負載不平衡的情況， 放任負載不平衡的情況不顧，最終叢集會遭遇效能瓶頸和叢集穩定性問題。

我們提出了一個開源的高彈性的叢集負載平衡工具 - Astraea Balancer，藉由搬移計劃生成和滿足特定平衡目標的打分機制來做到負載平衡，協助管理者持續維護叢集的和平。

英文摘要:

Apache Kafka is a famous distributed event streaming platform that ships with plenty of features & functionalities. For example, Replication, JBOD, Authn/z, Encryption, Compression, At-most/At-least/Exactly once delivery, and Transaction. Some common use-cases covered by Kafka include high-performance data pipelines, streaming analytics, and data integration.

A typical Kafka cluster will experience business requirement changes and resource allocation changes. A resource imbalance issue will stem once a Kafka cluster suffers from these everyday situations. If one doesn't handle these issues, a cluster will experience performance problems, which eventually, makes the upper-layer application work unstable.

To resolve this issue, we proposed a new open-source cluster balance tool for Apache Kafka. The Astraea Balancer. We take advantage of custom rebalance plan generation and various load balance goals to maintain the stability of a cluster. This will ease the maintenance work for cluster administrators.

講者英文介紹:

Cheap graduate students at NCKU.

說明: (Optional)

Apache Kafka 爲以 JVM 為底的熱門分散式事件串流平臺，本身支援豐富多變的功能和高擴展性，方便上游應用利用，現今 Apache Kafka 已經被許多知名企業採用於生產環境。

由於業務需求和叢集資源使用的改變，Kafka 叢集勢必會遭逢負載不平衡的情況， 放任負載不平衡的情況，最終叢集會遭遇效能瓶頸和叢集穩定性問題。

對此我們提出了一個開源的 Kafka 叢集負載平衡工具，於伺服器端解決問題：

• 高彈性架構：負載平衡目標可重新定義，套用自己在意的負載平衡目標對症下藥
• 自動把關負載平衡過程：Kafka 伺服器端的負載平衡涉及很顯著的資料複製代價，我們將有一個機制確保負載平衡不影響上游應用運行。

備忘: (Optional)

These notes are meant for the organizer and won't be made public.

Additional Speaker:

• [email protected]
• [email protected]

If you have a co-speaker, please add their email address here, and we will invite them to create an account. If you have more than one co-speaker, you can add more speakers after finishing the proposal process.

其他投稿相關補充資料 (URL)

• https://github.com/skiptests/astraea

目標聽眾族群:

• 對 Apache Kafka 有興趣的朋友
• 對分散式系統的負載平衡有興趣的朋友

您所屬的公司或組織: (Optional)

留空

@chia7712 這裡有需要寫嗎

內容難易度:

中階

其實我發現我們東西還沒完成和測試，所以也不好意思在上面宣揚能夠做到什麼成果。

[chinghongfang]

coscup 議程投稿 的 檢閱連結:
https://pretalx.com/coscup-2022/talk/review/CUMAPQMZ3LA3GUD3VXRY8AJLL3CCAW79

[chia7712]

@garyparrot

你知道他報名頁面摘要和說明的差異嗎

直覺摘要是概觀用來第一眼做審查，有興趣後再看說明做比較深度的理解

這裡有需要寫嗎

就寫你們的成大啊XD

[chia7712]

對 Apache Kafka 有興趣的朋友

可以再補充一個「對分散式系統的負載平衡有興趣的朋友」

[chia7712]

其實我發現我們東西還沒完成和測試，所以也不好意思在上面宣揚能夠做到什麼成果。

那就要更加緊腳步了！！

[wycccccc]

@chia7712
差不多該投稿了，內容部分應該就這樣了我會再修一下排版和字體。
還有論文題目部分，目前如下

作者應該可以寫好幾個，我就按照學弟的樣式把三個寫上去。
應該會在這兩天內完成投稿。

[chia7712]

@wycccccc 內容就差不多這樣，衝一發

[garyparrot]

COSCUP 議程投稿 的 檢閱連結:
https://pretalx.com/coscup-2022/talk/review/HYK9SDSQYSPXC9NLAFWECNXSWCHQSH8B

@qoo332001, @chia7712 我有把你們加到 submitter 內，還麻煩查看一下 Email，謝謝。

[chia7712]

還麻煩查看一下 Email，謝謝。

done

[wycccccc]

已投稿完成
https://easychair.org/conferences/submitted?a=28793271;submission=6023632;track=276739

終稿
https://drive.google.com/file/d/1B65tFv-mWWZRhBKLpDCWD2gxN-Sick1t/view?usp=sharing

[chia7712]

@chinghongfang @garyparrot @qoo332001 要麻煩你們弄一些文字讓我看一下大概會講的內容和方向喔~或是你們直接準備投影片也可以，不過不要一次弄完，先弄個幾頁重點讓我知道你們主要講的項目

[wycccccc]

如下為準備上傳的定稿，根據郵件內容稍作了一些修改：
https://drive.google.com/file/d/1B65tFv-mWWZRhBKLpDCWD2gxN-Sick1t/view?usp=sharing

[chia7712]

@wycccccc 致謝的部分可否把"原昌工業“也加上去，例如

感謝原昌工業提供研究經費和業界師資，xxxx

[wycccccc]

本研究感謝「原昌工業」與科學園區計劃「自主高效串流資料管理平台與新興應用」提供的研究經費與叢集作為本實驗的堅實後盾，讓實驗節點能夠達到企業級吞吐量。

這樣一併感謝可以嘛，還是需要分段。

[chia7712]

這樣一併感謝可以嘛，還是需要分段。

一併就好，以免拖太長

[wycccccc]

修改完畢：
https://drive.google.com/file/d/1dYMch7IHWV8FtIy0qMW4mxXZkbXRPkJG/view?usp=sharing

[chia7712]

@wycccccc 我們稍微把感謝的部分寫得更簡單一點，不用把贊助了什麼具體寫出來，例如：

本研究感謝原昌工業與科學園區計劃「自主高效串流資料管理平台與新興應用」的支持

[wycccccc]

好 已修改成上述內容
https://drive.google.com/file/d/1dYMch7IHWV8FtIy0qMW4mxXZkbXRPkJG/view?usp=sharing

[chia7712]

@wycccccc 感謝！

[wycccccc]

https://docs.google.com/presentation/d/1ty6kni2ry0fAqTGH1O9Aw1oTwEldl693/edit?usp=sharing&ouid=103613814519986721645&rtpof=true&sd=true

有些小圖標因為線上ppt會跑掉，但不影響觀看。大體上會長這樣，講稿我還在寫，禮拜五前肯定能搞定。
再麻煩學長看看有沒有需要改進的地方，感謝。

[chia7712]

@wycccccc 感謝這麼快完成投影片，幾個建議

1. 加上頁碼/總頁數
2. 首頁把組員的名字加上去
3. 第三頁的圖是自己畫的嗎？
4. 第四頁要強調一下“問題的嚴重性”，用數據表現會比較有說服力
5. 不確定是不是格式跑掉，投影片滑起來的格式看起來飄飄的，例如有些字型不一致（例如圖內的文字）
6. p.11實驗環境的硬體設備要講一下
7. p.6, p.7, p.8這三頁的文字量有點多，考量時間不長，要試著精華一下文字，不然聽眾可能根本看不完文字
8. p.13可以用編號列舉，除了看起來舒服以外，聽眾也可以用編號來問問題

上面建議主要集中在格式，至於內容的部分等禮拜五聽完再討論一次

[chinghongfang]

COSCUP 發表，被題問題：
producer發送訊息到partition時，若該partition節點掉線，訊息會如何處置？

[chia7712]

producer發送訊息到partition時，若該partition節點掉線，訊息會如何處置？

@chinghongfang 你覺得這個是一個需要處理的議題嗎？

[chinghongfang]

partition 節點掉線，producer 就會一直嘗試重新傳送，直到重新傳送次數達 "指定數量" (retries) 或 超過"指定時間"(delivery.timeout.ms)，重新傳送都失敗的話，可以由使用者傳入的 CallBack 接到錯誤訊息，讓使用者自行處理無法傳送的情況。

簡單來說，就是 KafkaProdcer 會重試，真的不行就交由使用者處理。

但其實 Kafka 當然有設計成 "節點掉線，仍有備案"。
目前 Kafka 是用 In-Sync Replica 接替掉線的節點，這部份演講中沒有提到，有了 replica 機制，我們的叢集就有了容錯的能力，降低服務死掉的機會。

---

我覺得，應該是演講忽略了複雜的部份，讓觀眾產生了疑問。上述回答應該可以滿足觀眾的問題，但也許在演講時，便可以稍微題一下忽略的部份，讓聽眾有更全面的瞭解。

@chinghongfang 你覺得這個是一個需要處理的議題嗎？

我覺得 Kafka 處理得很妥當(重試，真不行再給使用者)，也具有彈性。藉由調整次數，使用者也可以讓 producer 不要重傳，自己接手處理。

[chia7712]

我覺得 Kafka 處理得很妥當(重試，真不行再給使用者)，也具有彈性。藉由調整次數，使用者也可以讓 producer 不要重傳，自己接手處理。

一個延伸的討論：如果某個partition是不可以使用的，那麼partitioner 在得知這個訊息之前，會不會導致演算法一直選到死掉的partition?

[chia7712]

此議題已經由 #886 加入首頁，因此關閉