1. 起源
在使用 StarRocks 之前，短暫的先學習瞭解過 ClickHouse。ClickHouse 的起源和 StarRocks 有很多相似性。
1.1. ClickHouse起源
ClickHouse 全稱是 Click Stream,Data WareHouse。根據名字可以分析為：在採集資料過程中，一次頁面點選（click）會產生一個事件（event）。其邏輯就是，基於頁面的點選事件流，面向資料倉儲進行 OLAP 分析。
ClickHouse 最初是由俄羅斯搜尋巨頭 Yandex 的工程師開發的，用於加強其Web分析和廣告技術的內部資料處理能力。Yandex 是俄羅斯最大的搜尋引擎，在全球搜尋引擎排名第五，僅次於 Google、Bing、Yahoo 和 Baidu。
2016年，Yandex 決定將 ClickHouse 開源，釋出在 GitHub 上，這標誌著 ClickHouse 對外部開發者社群的開放。2017年，ClickHouse 被 Apache 軟體基金會認定為頂級專案。
ClickHouse 開源後，大家也發現了巨大的商業價值，紛紛推出商業版產品。核心研發團隊分離 Yandex 成立了
ClickHouse, Inc. 公司，很多新功能只在商業版維護。類似商業版還包括 Altinity、Yandex.Cloud 等等。
國內各大廠商也基於開源版本推出自己的商業版本，提供商業化服務。例如位元組就成立了一家叫 ByteHouse 的公司，推出自己的同名商業化產品。
在瞭解ClickHouse的起源時，就有些感慨。同樣是搜尋引擎公司，Google 的三駕馬車推動了Hadoop大資料生態的發展，俄羅斯的 Yandex 誕生了 ClickHouse，我們國內的百度又有啥成就？
1.2. StarRocks起源（Doris）
1.2.1. Apache Doris
作為搜尋引擎門戶，百度最核心的業務就是廣告投放。和 Yandex 研發 ClickHouse 類似，百度也是基於廣告業務研發了 Doris。廣告商在百度投放了廣告，就需要可以透過各種統計報表、大盤看板，看到自己廣告投放的效果。
產品最早的名字是Palo（OLAP倒過來），2018年貢獻給 Apache 基金會時由於和其他專案重名，改名為 Apache Doris。
開源後，Doris 在社群內蓬勃發展，和 ClickHouse 一樣，也有不少人發掘它的商業價值。
1.2.2. StarRocks
2020年，百度 Doris 團隊少量貢獻者率先出來創業，基於 Apache Doris 當時的開源版本做了自己的商業化閉源產品 DorisDB。
但這些貢獻者從此再也沒有在 Apache Doris 專案上貢獻過一行程式碼，將所有的精力都投入 DorisDB。DorisDB 作為商業化獨立分支，新提交的程式碼也沒有反哺回 Apache Doris，被Apache Doris 社群斥責違背了開源精神。
而且 DorisDB 的名字就讓人誤會，商業宣傳時又常以 Apache Doris 社群作為宣傳點，也被人詬病。後來該團隊所在鼎石科技公司，將 DorisDB 改名為 StarRocks。
1.2.3. SelectDB
百度 Doris 團隊剩下人繼續孵化 Apache Doris 專案，直至2022年，Apache Doris 也被 Apache 軟體基金會認定為頂級專案。
同年，百度 Doris 團隊一些人也出來開了飛輪科技公司，推出自己的商業版本 SelectDB。
SelectDB 團隊吸取經驗，在外以 Apache Doris 正統自居，和Apache Doris 社群保持良好關係，商業化之後依然繼續貢獻程式碼。
但是畢竟起步慢了兩年，商業化市場已經被 StarRocks 佔據了大半，就看未來是否能迎頭趕上了。
所以 StarRocks 源自於 Apache Doris，可以對比 《Apache Doris Docs文件》 和 《StarRocks Docs文件》，可以發現二者的系統架構基本一致，僅在表引擎、查詢最佳化等功能上有部分差異。
市場上基本沒有StarRocks的書，但是關於Apache Doris的書和文件挺多，如果想深入瞭解StarRocks的架構設計，可以退一步看看 Apache Doris 的。
2. 架構設計
StarRocks 的分散式架構和 ElasticSearch 及其相似，無論是叢集節點上，還是資料儲存上。
- ES 中由“資料節點”（對應 SR 中 BE節點）來做資料儲存和執行讀寫。
- ES 的叢集和配置管理由主節點們負責，主節點選舉後勝出1個“Master節點”，其他的為“候選節點”，還包括不參與選舉的“只讀節點”（對應 SR 中FE節點的 Master、Follower、Observer 角色節點）。
沒有像 ClickHouse 一樣，引用 ZooKeeper 實現叢集管理。
2.1. FE節點 VS BE節點
StarRocks 架構通常包括兩類節點：Frontend（FE）節點和 Backend（BE）節點。
1. Frontend（FE）節點
- 協調器（Coordinator）：FE 節點接收來自客戶端的所有 SQL 請求，並對其進行解析、編譯和最佳化生成執行計劃。
- 後設資料管理：FE 節點儲存和管理所有的後設資料，包括資料庫、表、列、分割槽以及其他物件的定義和狀態資訊。
- 叢集管理：FE 節點管理叢集的狀態，確保 BE 節點之間的負載均衡和資料分佈。
- 使用者許可權控制：FE 節點處理使用者的認證和授權，管理訪問控制和安全相關的操作。
- 日誌記錄：FE 節點記錄叢集操作的日誌，以便於故障恢復和資料一致性保證。
- 任務排程：FE 節點負責資料匯入、例行維護任務和其他管理操作的排程。
2. Backend（BE）節點
- 資料儲存：BE 節點負責實際的資料儲存，以列式儲存格式存放資料以支援高效查詢。
- 查詢執行：BE 節點根據 FE 節點生成的執行計劃，執行查詢操作並返回結果。
- 資料處理：BE 節點執行資料更新、刪除和插入等資料操縱語言（DML）操作，處理資料壓縮、索引維護等任務。
- 資料副本管理：BE 節點負責資料的副本管理，實現資料的高可用性和容錯。
FE 節點更像是資料庫的大腦，負責理解 SQL 請求、計劃查詢以及管理叢集的配置和狀態。BE 節點則像是執行器，負責儲存資料和在物理硬體上執行查詢計劃。
2.2. 三種FE節點角色
在 StarRocks 的架構中，FE（Frontend）節點可以有三種不同的角色，每個角色都有其特定的職責。這三種角色分別是：
1. Master
Master FE 節點是叢集的主節點，它負責處理所有的寫操作，包括更新後設資料（如資料庫、表、分割槽等的變更）、處理 DDL（資料定義語言）操作，以及處理客戶端的查詢請求。Master FE 節點還負責協調和管理其他 FE 節點，包括同步後設資料的變更給 Follower 和 Observer FE 節點。在叢集中通常只有一個 Master FE 節點。
2. Follower
Follower FE 節點是主節點的熱備份。它們透過複製 Master FE 節點的日誌來同步後設資料變化。在 Master FE 發生故障時，其中一個 Follower FE 節點可以被提升為新的 Master FE，從而確保叢集的高可用性。Follower FE 節點可以處理讀操作，但所有的寫操作都需要透過 Master FE 節點來協調。
3. Observer
Observer FE 節點提供了一個只讀檢視的叢集狀態，它們同樣透過複製 Master FE 的日誌來保持後設資料的同步。Observer FE 節點主要用於提供冗餘和讀取擴充套件，以及在一些架構中，可能用於負載均衡或實現讀寫分離。Observer 節點在故障轉移中不會被提升為 Master FE 節點。
這種設計允許 StarRocks 叢集實現高可用性，透過 Follower 和 Observer 節點可以在 Master 節點當機時快速進行故障切換，而不會丟失關鍵的後設資料資訊，並且還可以在高負載情況下擴充套件讀操作。
此外，Observer FE 節點可以用作備份，以便在叢集升級或維護時保證服務的持續可用性。
2.3. FE、CN
業務中隨著使用者儲存資料量的增加，往往需要不斷擴容儲存資源，從而增加 BE 節點，但導致 BE 節點上計算資源的浪費。
3.0 版本開始引入 存算分離 架構，資料儲存功能從原來的 BE 中抽離，BE 節點升級為無狀態的 CN (Compute Node) 節點。
資料可持久儲存在遠端物件儲存或 HDFS 上，CN 本地磁碟只用於快取熱資料來加速查詢。
3. 分割槽、分桶、副本
FE、BE是從叢集架構上體現分散式，從表資料儲存上，也同樣有分散式的體現。
1. 分割槽（Partitioning）
表資料首先被邏輯上劃分為多個分割槽，通常基於一個或多個列的值，這些列稱為分割槽鍵。
每個分割槽可以包含一段連續的資料範圍，比如日期列，可以按月或年來分割槽。
分割槽使得資料管理更為高效，特別是針對大資料量的表，因為它可以縮小查詢作用域，提高資料訪問速度。
2. 分桶（Bucketing）
在每個分割槽內部，資料進一步被劃分為多個桶（Bucket），這通常是基於資料的某個列的雜湊值。
分桶策略有助於在 BE 節點間均衡資料分佈，保證負載均衡和高效地並行處理查詢。
3. 資料副本（Replication）
為了提高資料的可靠性和可用性，StarRocks 會在不同的 BE 節點上建立資料的副本。
資料副本可以保證在某個 BE 節點失敗時，系統仍然能夠訪問到資料，從而實現故障恢復。
如圖中：
- 表按照日期劃分為 4 個分割槽，第一個分割槽進一步切分成 4 個桶（Tablet）。
- 每個桶使用 3 副本進行備份，分佈在 3 個不同的 BE 節點上