本文為您介紹EMR Serverless StarRocks的架構。
EMR Serverless StarRocks架構
EMR Serverless StarRocks的產品架構主要由以下三個層次構成：
儲存層：
存算一體版：StarRocks內表使用雲端硬碟或本地碟作為資料存放區的介質，使用StarRocks Table Format儲存格式。
存算分離版：StarRocks內表使用Object Storage Service或HDFS等資料湖儲存，使用StarRocks Table Format儲存格式。
資料湖分析版：通過StarRocks外部表格，直接讀取資料湖（例如Object Storage Service或HDFS）中的Hive格式或湖格式的資料，採用DataLake Table Format。
StarRocks執行個體：
全部執行個體（包括前端FE，後端BE或CN）都在雲端託管，實現免營運。
通過計算群組（Warehouse）可以進行資源靈活配置及隔離。
通過彈效能力可以確保低成本的資源使用，降低資源成本。
通過緩衝機制能顯著提升存算分離或資料湖分析的查詢速度，同時，產品內建的StarRocks緩衝管理功能進一步助力您高效地進行緩衝調優。
產品能力：
執行個體營運：提供無需營運的執行個體管理功能，包括資源與組態管理、警示、健康報告和自動升級等，提升營運效率與系統穩定性。
資料營運：提供即開即用的資料管理能力，例如可視化SQL編輯器、匯入任務、慢查詢、資料審計、中繼資料管理以及許可權配置等能力。
基於以上產品能力，您可以更加高效地聚焦於自己的業務應用，例如營運分析、使用者畫像、自助報表、訂單分析以及使用者報表產生等方面。
StarRocks系統架構
StarRocks架構的核心只有FE（Frontend）、BE（Backend）或CN（Compute Node）節點，方便部署與維護。節點可以線上水平擴充，中繼資料和業務資料都有副本機制，確保整個系統無單點。StarRocks提供MySQL協議介面，支援標準的SQL文法，您可以通過MySQL用戶端方便地查詢和分析StarRocks中的資料。
隨著StarRocks產品的發展，系統架構從存算一體（shared-nothing）進化到存算分離（shared-data）。
在3.0版本更新前，StarRocks採用存算一體架構，其中BE節點負擔著資料的儲存和計算任務，所有資料訪問和分析操作都直接在本地節點完成，以確保快速響應的查詢效能。
自3.0版本起，StarRocks開始採納存算分離架構，轉變了資料存放區的方式。原有的BE節點得到升級改造成為無狀態的計算節點（CN），並將資料持久化儲存遷移至遠端Object Storage Service服務或HDFS。在這一新架構下，CN節點的本地磁碟主要用於緩衝經常訪問的熱資料，進而提高查詢處理的速度。存算分離架構的優勢在於支援計算節點的動態添加或刪除，實現了更靈活高效的擴縮容功能。
如下圖所示，是從存算一體向存算分離架構演化的形象展示。
本文部分內容和圖片來源於社區StarRocks的Architecture。
存算一體
StarRocks 3.0版之前採用的是存算一體（shared-nothing）架構，這是其作為MPP資料庫的顯著特點。在這種架構中，BE節點負責資料的儲存與計算。在查詢時可以直接讀取本機資料進行計算，極大地提升了查詢的速度，有效避免了資料轉送和拷貝的延遲。此外，存算一體支援多副本資料存放區，提高了並發查詢能力和資料的可靠性，非常適合對查詢效能要求極高的情境。
在StarRocks的存算一體架構中，系統主要由前端節點（FE）和後端節點（BE）兩種類型的節點構成。
FE
FE負責管理中繼資料、管理用戶端串連、查詢規劃和調度等工作，並在每個節點的記憶體中儲存一份完整的中繼資料副本，以確保服務的一致性。
角色 | 中繼資料讀寫 | Leader選舉 | 說明 |
Leader | 讀寫 | 自動選舉 | Leader FE在對中繼資料進行讀寫操作後，通過BDB JE (Berkeley DB Java Edition) 同步變更至Follower和Observer。Leader由Follower節點中選舉產生，如果Leader失敗，其他Follower將進行新一輪選舉。 |
Follower | 唯讀 | 參與 | Follower只有中繼資料的讀取許可權，並通過Leader的中繼資料日誌來非同步同步資料。Follower節點也參與Leader的選舉，選舉過程基於BDB JE協議，並要求超過半數的Follower節點正常運行。 |
Observer | 唯讀 | 不參與 | Observer節點與Follower具有相同的讀取許可權，並進行非同步資料同步，但不參與Leader選舉。Observer的主要目的是增強叢集的查詢並發能力，並不給叢集選舉帶來額外負擔。 |
BE
BE負責SQL計算和資料存放區的任務，採用本機存放區和多副本機制以提高系統的可用性。
資料存放區： BE節點在儲存方面完全均等，沒有主次之分。資料由前端節點（FE）根據特定政策分配到各個BE節點，其中BE節點負責將接收的資料轉換成可儲存的格式並建立相應的索引。
SQL計算： 對於SQL查詢的處理，BE節點首先將SQL語句按照語義規劃成邏輯執行單元，然後再根據資料的分布情況拆分成具體的物理執行單元。這些物理執行單元直接在指定的BE節點上執行，實現了資料計算的本地化，避免了不必要的資料轉送和複製，從而極大的提升了查詢效能。
儘管存算一體架構在查詢效能上具有顯著優勢，但也存在一些局限性：
成本高：為了確保資料的可靠性，BE節點必須使用多副本，特別是三副本機制，這隨著資料量的增加會導致儲存資源的持續擴充，可能會造成計算資源的浪費。
架構複雜：多副本的維護要求高一致性，這使得存算一體架構變得更加複雜，提高了管理和維護的難度。
彈性不足：在存算一體模式下，擴縮容往往伴隨著資料重新平衡的過程，可能會影響彈性使用體驗。
存算分離
StarRocks存算分離架構是在存算一體的基礎上將計算和儲存進行解耦。在這種模式中，資料持久化儲存轉移到了成本更最佳化且可靠性更高的遠程Object Storage Service（例如OSS）或HDFS上。計算節點（CN）所在的本地磁碟主要用作緩衝，以加速對高頻訪問資料的查詢。當本機快取得到命中時，存算分離模式能夠提供與存算一體相當的查詢速度。
存算分離模式下，您可以動態地添加或移除計算節點，實現秒層級的擴縮容，有效降低了資料存放區與資源擴充的成本，並促進資源隔離及計算資源的Auto Scaling。此模式類似於存算一體，整個系統依舊由前端（FE）和計算節點（CN）兩種服務進程構成，需要您額外配置的僅是後端的Object Storage Service。
在StarRocks存算分離架構中，FE節點的角功能保持不變，而BE節點轉變為無狀態的CN節點，其僅緩衝熱資料，負責資料匯入、查詢計算和快取資料管理等任務。
儲存
StarRocks的存算分離技術目前支援以下後端儲存解決方案，您可以根據需求靈活選擇：
阿里雲OSSObject Storage Service。
HDFS，包括自建Hadoop或阿里雲EMR DataLake叢集。
在資料格式方面，StarRocks存算分離的資料檔案與存算一體保持一致，並支援各種索引技術，其中中繼資料（例如TabletMeta）經過重新設計以更好地適應Object Storage Service環境。
緩衝
為了最佳化查詢效能，StarRocks構建了層級分明的資料緩衝體系。熱資料存放在記憶體，確保快速可達；次熱資料則存放在本地磁碟；而冷資料則位於遠端的Object Storage Service中。資料會根據訪問頻率在這三個層次中流轉。
在查詢操作中，通常來說熱資料會直接從緩衝中擷取，冷資料需要從後端Object Storage Service中讀取並緩衝至本地，以便加快後序訪問速度。通過記憶體、本地磁碟及遠程儲存的聯合，StarRocks構建了多層資料訪問體系，您可以自訂資料冷熱規則以最佳化業務需求，實現了高效計算與成本可控的儲存。
您在建立表時可以選擇是否開啟緩衝。開啟緩衝後，資料將在寫入過程中同時存放到本地磁碟以及後端Object Storage Service中。在查詢時，CN節點會優先讀取本地磁碟中的資料，若本機快取未命中，則從後端Object Storage Service擷取未經處理資料，並將其緩衝至本地磁碟，以最佳化後續的訪問速度。對於未緩衝的冷資料，StarRocks還針對性地進行了最佳化，結合應用的訪問模式，通過預讀技術和並行掃描等策略，降低了對遠端Object Storage Service訪問的頻率，進一步提升了查詢效率。