本文為您介紹EMR Serverless StarRocks的架構。
EMR Serverless StarRocks架構
EMR Serverless StarRocks的產品架構主要由以下三個層次構成：
存儲層：
存算一體版：StarRocks內表使用云盤或本地盤作為數據存儲的介質，使用StarRocks Table Format存儲格式。
存算分離版：StarRocks內表使用對象存儲或HDFS等數據湖存儲，使用StarRocks Table Format存儲格式。
數據湖分析版：通過StarRocks外部表，直接讀取數據湖（例如對象存儲或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節點負擔著數據的存儲和計算任務，所有數據訪問和分析操作都直接在本地節點完成，以確?？焖夙憫牟樵冃阅堋?/p>
自3.0版本起，StarRocks開始采納存算分離架構，轉變了數據存儲的方式。原有的BE節點得到升級改造成為無狀態的計算節點（CN），并將數據持久化存儲遷移至遠端對象存儲服務或HDFS。在這一新架構下，CN節點的本地磁盤主要用于緩存經常訪問的熱數據，進而提高查詢處理的速度。存算分離架構的優勢在于支持計算節點的動態添加或刪除，實現了更靈活高效的擴縮容功能。
如下圖所示，是從存算一體向存算分離架構演進的形象展示。
本文部分內容和圖片來源于社區StarRocks的系統架構。
存算一體
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存算分離架構是在存算一體的基礎上將計算和存儲進行解耦。在這種模式中，數據持久化存儲轉移到了成本更優化且可靠性更高的遠程對象存儲（例如OSS）或HDFS上。計算節點（CN）所在的本地磁盤主要用作緩存，以加速對高頻訪問數據的查詢。當本地緩存得到命中時，存算分離模式能夠提供與存算一體相當的查詢速度。
存算分離模式下，您可以動態地添加或移除計算節點，實現秒級別的擴縮容，有效降低了數據存儲與資源擴展的成本，并促進資源隔離及計算資源的彈性伸縮。此模式類似于存算一體，整個系統依舊由前端（FE）和計算節點（CN）兩種服務進程構成，需要您額外配置的僅是后端的對象存儲。
在StarRocks存算分離架構中，FE節點的角功能保持不變，而BE節點轉變為無狀態的CN節點，其僅緩存熱數據，負責數據導入、查詢計算和緩存數據管理等任務。
存儲
StarRocks的存算分離技術目前支持以下后端存儲解決方案，您可以根據需求靈活選擇：
阿里云OSS對象存儲。
HDFS，包括自建Hadoop或阿里云EMR DataLake集群。
在數據格式方面，StarRocks存算分離的數據文件與存算一體保持一致，并支持各種索引技術，其中元數據（例如TabletMeta）經過重新設計以更好地適應對象存儲環境。
緩存
為了優化查詢性能，StarRocks構建了層級分明的數據緩存體系。熱數據存放在內存，確?？焖倏蛇_；次熱數據則存放在本地磁盤；而冷數據則位于遠端的對象存儲中。數據會根據訪問頻率在這三個層次中流轉。
在查詢操作中，通常來說熱數據會直接從緩存中獲取，冷數據需要從后端對象存儲中讀取并緩存至本地，以便加快后序訪問速度。通過內存、本地磁盤及遠程存儲的聯合，StarRocks構建了多層數據訪問體系，您可以自定義數據冷熱規則以優化業務需求，實現了高效計算與成本可控的存儲。
您在建立表時可以選擇是否開啟緩存。開啟緩存后，數據將在寫入過程中同時存放到本地磁盤以及后端對象存儲中。在查詢時，CN節點會優先讀取本地磁盤中的數據，若本地緩存未命中，則從后端對象存儲獲取原始數據，并將其緩存至本地磁盤，以優化后續的訪問速度。對于未緩存的冷數據，StarRocks還針對性地進行了優化，結合應用的訪問模式，通過預讀技術和并行掃描等策略，降低了對遠端對象存儲訪問的頻率，進一步提升了查詢效率。