StarRocks強大的實時數據分析

代碼倉庫：https://github.com/StarRocks/starrocks?tab=readme-ov-file

StarRocks | A High-Performance Analytical Database

快速開始：StarRocks | StarRocks

StarRocks 是一款高性能分析型數據倉庫，使用向量化、MPP 架構、CBO、智能物化視圖、可實時更新的列式存儲引擎等技術實現多維、實時、高并發的數據分析。StarRocks 既支持從各類實時和離線的數據源高效導入數據，也支持直接分析數據湖上各種格式的數據。StarRocks 兼容 MySQL 協議，可使用 MySQL 客戶端和常用 BI 工具對接。同時 StarRocks 具備水平擴展，高可用、高可靠、易運維等特性。廣泛應用于實時數倉、OLAP 報表、數據湖分析等場景。

StarRocks?是 Linux 基金會項目，采用 Apache 2.0 許可證，可在 StarRocks GitHub 存儲庫中找到（請參閱?StarRocks 許可證）。StarRocks（i）鏈接或調用第三方軟件庫中的函數，其許可證可在?licenses-binary?文件夾中找到；和（ii）包含第三方軟件代碼，其許可證可在?licenses?文件夾中找到。

什么是 StarRocks

StarRocks 是新一代極速全場景 MPP (Massively Parallel Processing) 數據庫。StarRocks 的愿景是能夠讓用戶的數據分析變得更加簡單和敏捷。用戶無需經過復雜的預處理，就可以用 StarRocks 來支持多種數據分析場景的極速分析。

StarRocks?架構簡潔，采用了全面向量化引擎，并配備全新設計的 CBO (Cost Based Optimizer) 優化器，查詢速度（尤其是多表關聯查詢）遠超同類產品。

StarRocks 能很好地支持實時數據分析，并能實現對實時更新數據的高效查詢。StarRocks 還支持現代化物化視圖，進一步加速查詢。

使用 StarRocks，用戶可以靈活構建包括大寬表、星型模型、雪花模型在內的各類模型。

StarRocks 兼容 MySQL 協議，支持標準 SQL 語法，易于對接使用，全系統無外部依賴，高可用，易于運維管理。StarRocks 還兼容多種主流 BI 產品，包括 Tableau、Power BI、QuickBI、FineBI 和 Smartbi。

適用場景?

StarRocks 可以滿足企業級用戶的多種分析需求，包括 OLAP (Online Analytical Processing) 多維分析、定制報表、實時數據分析和 Ad-hoc 數據分析等。

OLAP 多維分析?

利用 StarRocks 的 MPP 框架和向量化執行引擎，用戶可以靈活的選擇雪花模型，星型模型，寬表模型或者預聚合模型。適用于靈活配置的多維分析報表，業務場景包括：

用戶行為分析
用戶畫像、標簽分析、圈人
高維業務指標報表
自助式報表平臺
業務問題探查分析
跨主題業務分析
財務報表
系統監控分析

實時數據倉庫?

StarRocks 設計和實現了主鍵表，能夠實時更新數據并極速查詢，可以秒級同步 TP (Transaction Processing) 數據庫的變化，構建實時數倉，業務場景包括：

電商大促數據分析
物流行業的運單分析
金融行業績效分析、指標計算
直播質量分析
廣告投放分析
管理駕駛艙
探針分析APM（Application Performance Management）

高并發查詢?

StarRocks 通過良好的數據分布特性，靈活的索引以及物化視圖等特性，可以解決面向用戶側的分析場景，業務場景包括：

廣告主報表分析
零售行業渠道人員分析
SaaS 行業面向用戶分析報表
Dashboard 多頁面分析

統一分析?

通過使用一套系統解決多維分析、高并發查詢、預計算、實時分析查詢等場景，降低系統復雜度和多技術棧開發與維護成本。
使用 StarRocks 統一管理數據湖和數據倉庫，將高并發和實時性要求很高的業務放在 StarRocks 中分析，也可以使用 External Catalog 和外部表進行數據湖上的分析。

架構

StarRocks 架構簡潔明了，整個系統僅由兩種組件組成：前端和后端。前端節點稱為?FE。后端節點有兩種類型，BE?和?CN?(計算節點)。當使用本地存儲數據時，您需要部署 BE；當數據存儲在對象存儲或 HDFS 時，需要部署 CN。StarRocks 不依賴任何外部組件，簡化了部署和維護。節點可以水平擴展而不影響服務正常運行。此外，StarRocks 具有元數據和服務數據副本機制，提高了數據可靠性，有效防止單點故障 (SPOF)。

StarRocks 兼容 MySQL 協議，支持標準 SQL。用戶可以輕松地通過 MySQL 客戶端連接到 StarRocks 實時查詢分析數據。

架構選擇?

StarRocks 支持存算一體架構 (每個 BE 節點將其數據存儲在本地存儲) 和存算分離架構 (所有數據存儲在對象存儲或 HDFS 中，每個 CN 僅在本地存儲緩存)。您可以根據需要決定數據存儲的位置。

Architecture choices

存算一體?

本地存儲為實時查詢提供了更低的查詢延遲。

作為典型的大規模并行處理 (MPP) 數據庫，StarRocks 支持存算一體架構。在存算一體架構中，BE 負責數據存儲和計算。將數據存儲在 BE 中使得數據可以在當前節點中計算，避免了數據傳輸和復制，從而提供極快的查詢和分析性能。該架構支持多副本數據存儲，增強了集群處理高并發查詢的能力并確保數據可靠性，非常適合追求最佳查詢性能的場景。

shared-data-arch

節點?

在存算一體架構中，StarRocks 由兩種類型的節點組成：FE 和 BE。

FE 負責元數據管理和構建執行計劃。
BE 執行查詢計劃并存儲數據。BE 利用本地存儲加速查詢，并使用多副本機制確保高數據可用性。

FE?

FE 負責元數據管理、客戶端連接管理、查詢規劃和查詢調度。每個 FE 在其內存中存儲和維護一份完整的元數據副本，保證 FE 之間服務的一致性。FE 分為 Leader FE 節點、Follower 節點和 Observer 節點。Follower 節點可以根據類似 Paxos 的 BDB JE（Berkeley DB Java Edition）協議選舉主節點。

FE 角色	元數據管理	節點選主
Leader 節點	Leader FE 負責讀寫元數據。Follower 節點和 Observer 節點只能讀取元數據，并將元數據寫請求路由到 Leader FE。Leader FE 更新元數據，然后使用 BDB JE 將元數據更改同步到 Follower 節點和 Observer 節點。只有在元數據更改同步到超過一半的Follower 節點后，數據寫入才被認為成功。	Leader FE 技術上也是一個 Follower 節點，是從Follower 節點中選舉出來的。要執行主節點選舉，集群中必須有超過一半的Follower 節點處于活動狀態。當 Leader FE 發生故障時，Follower 節點將開始另一輪主節點選舉。
Follower 節點	Follower 節點只能讀取元數據。它們從 Leader FE 同步和重放日志以更新元數據。	Follower 節點參與主節點選舉，這需要集群中超過一半的 Follower 節點處于活動狀態。
Observer 節點	Observer 節點從 Leader FE 同步和重放日志以更新元數據。	Observer 節點主要用于增加集群的查詢并發性。 Observer 節點不參與主節點選舉，因此不會增加集群的主節點選舉壓力。

BE?

BE 負責數據存儲和 SQL 執行。

數據存儲：BE 具有等效的數據存儲能力。FE 根據預定義規則將數據分發到各個 BE。BE 轉換導入的數據，將數據寫入所需格式，并為數據生成索引。
SQL 執行：FE 根據查詢的語義將每個 SQL 查詢解析為邏輯執行計劃，然后將邏輯計劃轉換為可以在 BE 上執行的物理執行計劃。BE 在本地存儲數據以及執行查詢，避免了數據傳輸和復制，極大地提高了查詢性能。

存算分離?

對象存儲和 HDFS 提供低成本、高可靠性和可擴展性等優勢。除了可以擴展存儲外，還可以隨時添加和刪除 CN 節點。因為存儲和計算分離，增刪節點也無需重新平衡數據。

在存算分離架構中，BE 被“計算節點 (CN)”取代，后者僅負責數據計算任務和緩存熱數據。數據存儲在低成本且可靠的遠端存儲系統中，如 Amazon S3、GCP、Azure Blob Storage、MinIO 等。當緩存命中時，查詢性能可與存算一體架構相媲美。CN 節點可以根據需要在幾秒鐘內添加或刪除。這種架構降低了存儲成本，確保更好的資源隔離，并具有高度的彈性和可擴展性。

存算分離架構與存算一體架構一樣簡單。它僅由兩種類型的節點組成：FE 和 CN。唯一的區別是用戶必須配置后端對象存儲。

shared-data-arch

節點?

在存算分離架構中，FE 提供的功能與存算一體架構中的相同。

BE 被 CN (計算節點) 取代，存儲功能被轉移到對象存儲或 HDFS。CN 是無狀態的計算節點，可以執行除存儲數據外所有 BE 的功能。

存儲?

StarRocks 存算分離集群支持兩種存儲解決方案：對象存儲 (例如，AWS S3、Google GCS、Azure Blob Storage 或 MinIO) 和 HDFS。

在存算分離集群中，數據文件格式與存算一體集群 (存儲和計算耦合) 保持一致。數據存儲為 Segment 文件，云原生表（專門用于存算分離集群的表）也可以利用存算一體架構中支持的各種索引技術。

緩存?

StarRocks 存算分離集群將數據存儲與計算分離，使兩方都能夠獨立擴展，從而降低成本并提高系統彈性擴展能力。然而，這種架構會影響查詢性能。

為減少架構對于性能的影響，StarRocks 建立了包含內存、本地磁盤和遠端存儲的多層數據訪問系統，以便更好地滿足各種業務需求。

對于針對熱數據的查詢，StarRocks 會先掃描緩存，然后掃描本地磁盤。而針對冷數據的查詢，需要先將數據從對象存儲中加載到本地緩存中，加速后續查詢。通過將熱數據緩存在計算單元內，StarRocks 實現了真正的高計算性能和高性價比存儲。此外，還通過數據預取策略優化了對冷數據的訪問，有效消除了查詢的性能限制。

可以在建表時啟用緩存。啟用緩存后，數據將同時寫入本地磁盤和后端對象存儲。在查詢過程中，CN 節點首先從本地磁盤讀取數據。如果未找到數據，將從后端對象存儲中檢索，并將數據緩存到本地磁盤中。

產品特性

MPP 分布式執行框架?

StarRocks 采用 MPP (Massively Parallel Processing) 分布式執行框架。在 MPP 執行框架中，一條查詢請求會被拆分成多個物理計算單元，在多機并行執行。每個執行節點擁有獨享的資源（CPU、內存）。MPP 執行框架能夠使得單個查詢請求可以充分利用所有執行節點的資源，所以單個查詢的性能可以隨著集群的水平擴展而不斷提升。

MPP1

如上圖所示，StarRocks 會將一個查詢在邏輯上切分為多個邏輯執行單元（Query Fragment）。按照每個邏輯執行單元需要處理的計算量，每個邏輯執行單元會由一個或者多個物理執行單元來具體實現。物理執行單元是最小的調度單位。一個物理執行單元會被調度到集群某個 BE 上執行。一個邏輯執行單元可以包括一個或者多個執行算子，如圖中的 Fragment 包括了 Scan，Project，Aggregate。每個物理執行單元只處理部分數據。由于每個邏輯執行單元處理的復雜度不一樣，所以每個邏輯執行單元的并行度是不一樣的，即，不同邏輯執行單元可以由不同數目的物理執行單元來具體執行，以提高資源使用率，提升查詢速度。

MPP1

與很多數據分析系統采用的 Scatter-Gather 分布式執行框架不同，MPP分布式執行框架可以利用更多的資源處理查詢請求。在 Scatter-Gather 框架中，只有 Gather 節點能處理最后一級的匯總計算。而在 MPP 框架中，數據會被 Shuffle 到多個節點，并且由多個節點來完成最后的匯總計算。在復雜計算時（比如高基數 Group By，大表 Join 等操作），StarRocks 的 MPP 框架相對于 Scatter-Gather 模式的產品有明顯的性能優勢。

全面向量化執行引擎?

StarRocks 通過實現全面向量化引擎，充分發揮了 CPU 的處理能力。全面向量化引擎按照列式的方式組織和處理數據。StarRocks 的數據存儲、內存中數據的組織方式，以及 SQL 算子的計算方式，都是列式實現的。按列的數據組織也會更加充分的利用 CPU 的 Cache，按列計算會有更少的虛函數調用以及更少的分支判斷從而獲得更加充分的 CPU 指令流水。

另一方面，StarRocks 的全面向量化引擎通過向量化算法充分的利用 CPU 提供的 SIMD（Single Instruction Multiple Data）指令。這樣 StarRocks 可以用更少的指令數目，完成更多的數據操作。經過標準測試集的驗證，StarRocks的全面向量化引擎可以將執行算子的性能，整體提升 3~10 倍。

除了使用向量化技術實現所有算子外，StarRocks 還在執行引擎中實現了其他的優化。比如 StarRocks 實現了 Operation on Encoded Data 的技術。對于字符串字段的操作，StarRocks 在無需解碼情況下就可以直接基于編碼字段完成算子執行，比如實現關聯算子、聚合算子、表達式算子計算等。這可以極大的降低 SQL 在執行過程中的計算復雜度。通過這個優化手段，相關查詢速度可以提升 2 倍以上。

存儲計算分離?

StarRocks 3.0 版本支持了全新的存算分離模式，實現了計算與存儲的完全解耦、計算節點彈性擴縮容、高性能熱數據緩存。存算分離模式下 StarRocks 具備靈活彈性、高性能、高可靠、低成本等特點。

shared-data

存算分離模式下，存儲與計算解耦，各自獨立服務，獨立擴縮容，解決了在存算一體模式下的計算與存儲等比例擴縮容所帶來的資源浪費問題。計算節點可以實現秒級的動態擴縮容，提升計算資源的利用率。

存儲層利用對象存儲近乎無限的容量，以及數據高可用的特性實現數據的海量存儲和持久化。支持包括 AWS S3，Azure Blob Storage，Google Cloud Storage，阿里云 OSS，騰訊云 COS，火山引擎 TOS，華為云 OBS，以及各類兼容 S3 協議的對象存儲，同時也支持 HDFS 存儲。

部署模式上用戶可以選擇基于公有云、私有云、本地機房部署。StarRocks 存算分離也支持基于 Kubernetes 部署，并提供了相應的 Operator 方便用戶自動化部署。

StarRocks 存算分離模式與存算一體模式功能保持一致，寫入及熱數據查詢性能也與存算一體基本持平。用戶在存儲分離模式下也可以實現數據更新、數據湖分析、物化視圖加速等多種場景。

CBO 優化器?

CBO

在多表關聯查詢場景下，僅靠優秀的執行引擎沒有辦法獲得最極致的執行性能。因為這類場景下，不同執行計劃的復雜度可能會相差幾個數量級。查詢中關聯表的數目越大，可能的執行計劃就越多，在眾多的可能中選擇一個最優的計劃，這是一個 NP-Hard 的問題。只有優秀的查詢優化器，才能選擇出相對最優的查詢計劃，從而實現極致的多表分析性能。

StarRocks 從零設計并實現了一款全新的，基于代價的優化器 CBO（Cost Based Optimizer）。該優化器是 Cascades Like 的，在設計時，針對 StarRocks 的全面向量化執行引擎進行了深度定制，并進行了多項優化和創新。該優化器內部實現了公共表達式復用，相關子查詢重寫，Lateral Join，Join Reorder，Join 分布式執行策略選擇，低基數字典優化等重要功能和優化。目前，該優化器已可以完整支持 TPC-DS 99 條 SQL 語句。

由于全新 CBO 的支持，StarRocks 能比同類產品更好地支持多表關聯查詢，特別是復雜的多表關聯查詢，讓全面向量化引擎能夠發揮極致的性能。

可實時更新的列式存儲引擎?

StarRocks 實現了列式存儲引擎，數據以按列的方式進行存儲。通過這樣的方式，相同類型的數據連續存放。一方面，數據可以使用更加高效的編碼方式，獲得更高的壓縮比，降低存儲成本。另一方面，也降低了系統讀取數據的 I/O 總量，提升了查詢性能。此外，在大部分 OLAP 場景中，查詢只會涉及部分列。相對于行存，列存只需要讀取部分列的數據，能夠極大地降低磁盤 I/O 吞吐。

StarRocks 能夠支持秒級的導入延遲，提供準實時的服務能力。StarRocks 的存儲引擎在數據導入時能夠保證每一次操作的 ACID。一個批次的導入數據生效是原子性的，要么全部導入成功，要么全部失敗。并發進行的各個事務相互之間互不影響，對外提供 Snapshot Isolation 的事務隔離級別。

columnar_storage_engine

StarRocks 存儲引擎不僅能夠提供高效的 Partial Update 操作，也能高效處理 Upsert 類操作。使用 Delete-and-insert 的實現方式，通過主鍵索引快速過濾數據，避免讀取時的 Sort 和 Merge 操作，同時還可以充分利用其他二級索引，在大量更新的場景下，仍然可以保證查詢的極速性能。

智能的物化視圖?

materialized_view

StarRocks 支持用戶使用物化視圖（materialized view）進行查詢加速和數倉分層。不同于一些同類產品的物化視圖需要手動和原表做數據同步，StarRocks 的物化視圖可以自動根據原始表更新數據。只要原始表數據發生變更，物化視圖的更新也同步完成，不需要額外的維護操作就可以保證物化視圖能夠維持與原表一致。不僅如此，物化視圖的選擇也是自動進行的。StarRocks 在進行查詢規劃時，如果有合適的物化視圖能夠加速查詢，StarRocks 自動進行查詢改寫(query rewrite)，將查詢自動定位到最適合的物化視圖上進行查詢加速。

StarRocks 的物化視圖可以按需靈活創建和刪除。用戶可以在使用過程中視實際使用情況來判斷是否需要創建或刪除物化視圖。StarRocks 會在后臺自動完成物化視圖的相關調整。

StarRocks 的物化視圖可以替代傳統的 ETL 建模流程，用戶無需在上游應用處做數據轉換，可以在使用物化視圖時完成數據轉換，簡化了數據處理流程。

例如圖中，最底層 ODS 的湖上數據可以通過 External Catalog MV 來構建 DWD 層的 normalized table；并且可以通過多表關聯的物化視圖來構建 DWS 層的寬表 (denormalized table)；最上層可以進一步構建實時的物化視圖來支撐高并發的查詢，提供更加優異的查詢性能。

數據湖分析?

datalake_analytics

StarRocks 不僅能高效的分析本地存儲的數據，也可以作為計算引擎直接分析數據湖中的數據。用戶可以通過 StarRocks 提供的 External Catalog，輕松查詢存儲在 Apache Hive、Apache Iceberg、Apache Hudi、Delta Lake 等數據湖上的數據，無需進行數據遷移。支持的存儲系統包括 HDFS、S3、OSS，支持的文件格式包括 Parquet、ORC、CSV。

如上圖所示，在數據湖分析場景中，StarRocks 主要負責數據的計算分析，而數據湖則主要負責數據的存儲、組織和維護。使用數據湖的優勢在于可以使用開放的存儲格式和靈活多變的 schema 定義方式，可以讓 BI/AI/Adhoc/報表等業務有統一的 single source of truth。而 StarRocks 作為數據湖的計算引擎，可以充分發揮向量化引擎和 CBO 的優勢，大大提升了數據湖分析的性能。

StarRocks示例SQL

下面是一個starrocks數據操作實例

CREATE DATABASE IF NOT EXISTS quickstart;use quickstart;CREATE TABLE IF NOT EXISTS crashdata (CRASH_DATE DATETIME,BOROUGH STRING,ZIP_CODE STRING,LATITUDE INT,LONGITUDE INT,LOCATION STRING,ON_STREET_NAME STRING,CROSS_STREET_NAME STRING,OFF_STREET_NAME STRING,CONTRIBUTING_FACTOR_VEHICLE_1 STRING,CONTRIBUTING_FACTOR_VEHICLE_2 STRING,COLLISION_ID INT,VEHICLE_TYPE_CODE_1 STRING,VEHICLE_TYPE_CODE_2 STRING
);CREATE TABLE IF NOT EXISTS weatherdata (DATE DATETIME,NAME STRING,HourlyDewPointTemperature STRING,HourlyDryBulbTemperature STRING,HourlyPrecipitation STRING,HourlyPresentWeatherType STRING,HourlyPressureChange STRING,HourlyPressureTendency STRING,HourlyRelativeHumidity STRING,HourlySkyConditions STRING,HourlyVisibility STRING,HourlyWetBulbTemperature STRING,HourlyWindDirection STRING,HourlyWindGustSpeed STRING,HourlyWindSpeed STRING
);SET PASSWORD FOR 'root'@'%' = PASSWORD('123456');-- 紐約市每小時交通事故數量SELECT COUNT(*),date_trunc("hour", crashdata.CRASH_DATE) AS Time
FROM crashdata
GROUP BY Time
ORDER BY Time ASC
LIMIT 200;-- 紐約市的平均氣溫SELECT avg(HourlyDryBulbTemperature),date_trunc("hour", weatherdata.DATE) AS Time
FROM weatherdata
GROUP BY Time
ORDER BY Time ASC
LIMIT 100;-- 能見度情況對駕駛安全的影響SELECT COUNT(DISTINCT c.COLLISION_ID) AS Crashes,truncate(avg(w.HourlyDryBulbTemperature), 1) AS Temp_F,truncate(avg(w.HourlyVisibility), 2) AS Visibility,max(w.HourlyPrecipitation) AS Precipitation,date_format((date_trunc("hour", c.CRASH_DATE)), '%d %b %Y %H:%i') AS Hour
FROM crashdata c
LEFT JOIN weatherdata w
ON date_trunc("hour", c.CRASH_DATE)=date_trunc("hour", w.DATE)
WHERE w.HourlyVisibility BETWEEN 0.0 AND 1.0
GROUP BY Hour
ORDER BY Crashes DESC
LIMIT 100;