OLAP的統一及技術趨勢:StarRocks 架構和實踐分享

一、StarRocks 產品介紹

EMR Serverless StarRocks 產品目前主要以全托管和半托管兩種形態存在。雖然我們目前并不主力推廣半托管形態,但該形態仍會持續提供,以滿足部分用戶在云端快速構建、部署和運維的需求。半托管版本采用開源模式,并在運維方面提供一定的支持。
相較而言,我們更傾向于引導用戶使用全托管形態,因為它除了具備 StarRocks 所宣傳的極速統一等特性外,還提供了全托管服務,在 serverless 環境下實現了免運維。
此外,還針對內核和管控方面做了許多數據運維管理工作,例如可視化分析 MySQL 的性能數據、導入任務管理、元數據管理以及外表元數據管理等。為了方便用戶進行 Adhoc 場景操作,還提供了 SQL Editor 等工具。
結合云原生技術,產品提供了便捷的集群創建、擴縮容、升降配等功能。自動升級能力也讓用戶在版本切換時更加輕松。此外,我們還與數據湖、DLF 等云產品進行了集成,并支持與 Flink CDC 的 CDAS 能力,以便快速將 MySQL 數據庫遷移至 StarRocks。
未來,還將與 MaxCompute 等阿里特色產品進行集成,以滿足數倉用戶的需求。總體而言,EMR 產品增值服務主要圍繞數據運維和集群運維,旨在降低使用門檻、提高效率,為用戶提供更便捷的云端體驗。

EMR 產品主要包括三種形態,來滿足不同場景的需求。首先,on ECS 半托管形態,該形態已逐漸成為主流,受到了廣泛關注。其次,on ACK 形態,即基于 Kubernetes(K8S)的容器化形態,也在逐步完善和推廣。此外,我們首次在 EMR 中引入了 Serverless 形態,以 StarRocks 引擎為代表,降低了用戶在使用大數據處理引擎時的運維負擔。
未來,我們將繼續擴展 EMR 的 Serverless 形態,計劃將 Spark 等更多技術納入其中,以滿足更多用戶的需求。然而,需要注意的是,這些新增功能的研究與開發周期可能會較長。總之,EMR 致力于不斷優化產品形態,為用戶提供更加便捷、高效的大數據處理解決方案。

半托管模式,如上圖中左半部分,主要幫助用戶解決集群運維部署和售后支持方面的問題。這種模式仍存在一定的局限性。為此,我們推出了全托管模式,如上圖中右半部分,它在半托管基礎上,進一步將計算資源層(如 FE/BE)納入托管,提升了數據運維相關能力。
在 manager 層面,實現了查詢診斷分析、元數據管理、導入任務管理、SQL Editor 等功能。此外,還實現了權限可視化控制,并關注穩定性和運維問題的解決。例如,如何快速定位導入任務、物化視圖等背后任務的管理,以及在出現問題時,如何通過可視化手段幫助用戶快速定位并解決問題。
目前,我們有兩種版本可供選擇:入門版和標準版。入門版適用于對 StarRocks 不熟悉的用戶,提供了一個有限的 12 CU 配置,供用戶進行試用和體驗。此外,我們還針對入門版展開了一些免費推廣活動,用戶可以適時嘗試。
全托管模式致力于解決集群運維部署和售后支持問題,提供全面的診斷分析、元數據管理、SQL Editor 等功能,以及權限可視化控制。在穩定性和運維方面,著重優化了任務管理和問題定位能力,以幫助用戶快速應對日常使用中可能遇到的問題。目前,有入門版和標準版兩種版本供用戶選擇,入門版更適合初學者,并提供了一些免費推廣活動。

只要是阿里云的正常賬號,且此前未開通過 EMR 和 StarRocks 相關產品,均可免費開通入門版,感興趣的用戶可以參加相關活動。目前,該版本雖免費,但資源有限。例如,每小時 5000 CU 和 48000 GB 存儲空間。以 12 CU 為例,用戶可連續使用約 20 天。當然,我們也注意到部分用戶的訴求,他們希望開設更大規格的版本。因此,我們計劃在 12 CU 基礎上增加 32 CU 規格,以滿足這些用戶的需求。用戶可根據自身需求選擇合適規格的版本,既可以簡單測試性能,又不必擔心資源浪費。
此外,我們還提供標準版,這是目前主要售賣的版本。如果用戶在生產環境中使用,建議選擇標準版。
我們將繼續關注用戶需求,優化產品版本和規格,為大家提供更好的使用體驗。

StarRocks 致力于實現 OLAP 在整個大數據領域的統一。從阿里云 EMR 客戶的視角來看,越來越多的用戶將 OLAP 相關業務遷移至 StarRocks。許多客戶場景下,StarRocks 逐漸替代了 Presto 和 Spark。然而,這個過程可能需要一些時間,特別是在等待 StarRocks 3.1 至 3.2 版本發布并穩定下來,以及產品化能力全面跟上之后。
在規模方面,StarRocks 目前可以替代大約十幾臺的 Hadoop 集群。這種規模的中小企業客戶更傾向于采用 StarRocks,因為它可以實現技術棧的統一,降低維護成本。用戶無需深入了解 Flink、Spark、Hive 和 HDFS 等開源大數據引擎,只需掌握 StarRocks 基本的 SQL 語法和表結構設計,即可輕松上手使用。
StarRocks 始終致力于簡化大數據技術棧,提供統一的平臺,使得用戶可以更輕松地遷移和整合業務。隨著 StarRocks 版本的不斷更新和優化,我們相信它將在更多企業中得到廣泛應用,成為大數據領域的重要力量。
二、StarRocks 功能介紹
接下來介紹一下產品的主要功能。

全托管服務主要圍繞實例概念展開,這里的一個實例相當于一個集群。全托管服務為用戶提供實例的基本管理功能,包括自動升級、可視化配置以及一鍵告警等。通過 serverless 架構,用戶可以輕松創建和管理實例,無需關注底層基礎設施的運維。

除實例管理功能外,全托管服務還具備數據運維層面的能力,包括 MySQL 診斷分析等。這些功能旨在幫助用戶更高效地管理和維護數據庫,提升運維水平。

全托管服務還為用戶提供數據開發和 Adhoc 場景的支持,涵蓋簡單的數據分析、SQL 編輯器等能力。盡管目前這項功能尚處于初期階段,但已具備基本的 SQL 運行和簡單 SQL 運維能力,可以滿足用戶在數據處理、查詢和分析方面的需求。

全托管服務在滿足復雜 Adhoc 場景方面,目前尚需經過兩三個迭代的產品升級以及添加元數據管理能力和可視化管理功能的過程。在這個過程中,用戶對于統一查看外部 Catalog 元數據的需求也得到了關注。
針對這一需求,EMR 數據湖解決方案已經提供了從 DRF 系統中查看數據湖中所有元數據相關信息的功能。未來將實現內外表元數據以及外部 Catalog 統一視圖的管理,從而進一步提升用戶在復雜 Adhoc 場景下的數據處理和分析效率,為業務發展提供有力支持。

權限管理主要包括用戶管理和訪問控制。

對于全托管和半托管服務,我們并未做特殊的差異化處理。只有在 Flink VVP 的集成方面,提供了一些特殊的支持,因為 Flink VVP 的一些特性,無法合并到社區版本中。
此外,半托管服務主要在于可視化集群管理等功能,而全托管服務還具備例如 FEBE 免運維、小版本自動升級等一些獨特的能力。

Serverless 版本更注重數據運維管理能力的提升。正如之前所提及的,元數據、MySQL 數據庫以及導入任務管理等方面都是我們關注的重點。針對阿里云上眾多中小客戶在數據導入方面的痛點,我們計劃在后續版本中優化數據導入速度,提升用戶體驗。目前還是以內部導入任務的管理為主。
未來,隨著存算分離的實現,我們將結合物化視圖來支持小型數據倉庫場景。物化視圖在數據倉庫中的應用越來越重,因此我們也將重視物化視圖的管理功能,盡管目前其優先級相對較低。
三、StarRocks 客戶場景案例
接下來要介紹的案例主要是用 StarRocks 替代原有的 OLAP 平臺。在近 200 個 EMR 現有用戶中,大部分都是從 Presto、Impala 等舊引擎遷移而來。他們轉向 StarRocks 的主要原因是性能提升,而且資源占用較少。例如,有些客戶在運行時,StarRocks 資源僅需 Presto 的一半,便能達到相近甚至更佳的性能。因此,他們在降低成本和提高性能方面都得到了實惠,紛紛選擇 StarRocks。

以一個在線教育客戶為例,他們曾嘗試過 Presto 和 MySQL,但由于數據量較大,整體性能差距明顯。經過速度和其他方面的對比,他們最終選擇了 StarRocks。
該客戶典型的 BI 報表分析平臺包含自定義報表和多維分析場景。整個數據鏈路如下:從 MySQL 或服務日志等來源通過 Kafka 傳輸,經過 Flink 處理后寫入 StarRocks,最終完成數據應用。此外,為了保證熱數據緩存和后續指標平臺的運行,他們還需要將離線數據同步至 StarRocks,采用按天或小時級的數據同步策略。

客戶在實時數據分析場景中,采用了 Kafka、Flink、StarRocks 等工具進行數據處理。數據從 Kafka 流入,經過 Flink 處理后寫入 StarRocks。在 StarRocks 端,數據按照天進行分區,按照用戶 ID 進行分桶,生成數據埋點詳細表。此外,還創建了一些小時級物化視圖,實現了簡單的 ETL 流程。這種處理方式既不算是數倉,也不算是復雜的數據分析,而是提前進行了一些預處理,以滿足后續固定維度的事件分析需求。
針對明細表,StarRocks 可以支持用戶跟蹤等場景,提供明細查詢功能。在性能方面,相較于原有方案,StarRocks 實現了約兩倍的提升。

這是一家互聯網金融客戶,他們曾使用過多款 OLAP 組件,如 CK、Impala 和 TiDB 等。然而,這些組件繁多,難以維護。此外,在 TiDB 上的并發性能受到限制,由于集群規模和成本等因素,某些場景下無法實現更多任務。因此,他們在尋求一種能夠提高查詢性能并降低資源消耗的解決方案。
針對這一需求,StarRocks 為其提供了約 40% 的查詢性能提升,同時資源使用降低 50%。這主要針對傳統報表場景和預聚合場景。原先在 TiDB 上的預聚合操作需耗時 30 分鐘,而現在在 StarRocks 上僅需 30 秒,大大降低了資源消耗。
此外,StarRocks 提供了統一的組件,使得運維人員數量減少,降低了運維難度。客戶希望未來能夠將 OLAP 相關場景逐步統一到 StarRocks,實現技術棧的統一。他們計劃在監控、報告、報警以及用戶行為分析等場景中,替代原有方案,采用 StarRocks 進行處理。

這是一個采用數據湖存儲架構的在線教育客戶,他們使用了 Hudi 作為數據存儲方案。數據從 Kafka 流入,通過 Flink 處理后,寫入 Hudi 格式存儲在數據湖中,如 SSR 等。然后,利用 StarRocks 以外表形式進行 OLAP 分析,替代了原有架構中的 Presto。

這是一家大型音頻公司,他們在某一塊獨立業務上嘗試使用 StarRocks。這一場景主要針對小型數據倉庫,特點是數據量較小,規模在 7、8 TB 左右。為了避免物化視圖穩定性問題,他們選擇了 StarRocks 作為解決方案。
此外,這家公司的業務非常垂直,上層應用變化較快。因此,他們需要一種輕量級的方案,以便快速迭代。使用傳統的 Hive 和 Spark 架構對于他們來說過于沉重,而 StarRocks 提供了一種更靈活的解決方案。
在新業務選型時,他們選擇了 StarRocks 作為整套方案。盡管這類客戶目前不多,但隨著 StarRocks 3.0 版本的發布以及物化視圖和穩定性問題的解決,更多類似客戶將會采用這一方案。這也將成為未來規劃中的重點推廣場景,預計在今年下半年或明年開始實施。

這是一家專注于用戶行為分析的游戲公司,他們面臨的主要挑戰是提高性能和降低成本,這也是許多客戶目前所關注的問題。
該游戲公司的架構與之前提到的場景類似,從 Kafka 讀取元數據,通過 Flink 處理后,寫入 StarRocks 進行實時查詢、業務報表和大數據展示等典型場景。這種架構充分利用了 StarRocks 的性能優勢,滿足了游戲公司對高效數據處理和分析的需求。

這是一個小型電商客戶,他們原先使用 CK、麒麟等 OLAP 引擎。由于歷史原因,他們需要處理多樣化的場景,如運營分析報表、指標平臺 Adhoc 查詢以及實時大屏展示等。
為了提高性能,該電商客戶在保留原有數倉體系的基礎上,將 BI 報表分析部分遷移至 StarRocks。這一變革使得他們在實時查詢、大數據分析等方面取得了顯著的性能提升。
四、StarRocks 產品未來規劃
至此,我們已經介紹了產品和一些典型客戶場景。盡管目前實際應用場景相對簡單,但一個顯著的趨勢是,越來越多的企業將原有 OLAP 引擎遷移至 StarRocks。這一趨勢表明,StarRocks 憑借其高性能和穩定性,逐漸成為企業數據處理和分析的首選解決方案。

在 EMR的規劃中,StarRocks 成為 OLAP 領域的重中之重。目前,EMR 中的所有 OLAP 業務重心都集中在 StarRocks。我們在 6 月 1 日正式開始商業化運營,隨著 2.5 版本的發布,支持了傳統 BI 場景和數據庫分析場景。目前已經發布支持 StarRocks 存算分離版本,存算分離版本 beta 測試中。
未來的工作將主要圍繞存算分離場景,包括替代 Presto 等產品。此外,我們計劃在今年 Q3 發布一些運維增強功能,如智能診斷和實例匯總信息,以幫助維護集群穩定性并快速定位問題。
隨著 3.1 版本的發布,彈性將成為一個重要特性。我們計劃在 12 月份發布全托管版本的彈性功能。此外,我們還將針對云上資源,如云盤,優化性能和存儲成本。在 manager 方面,我們將繼續關注導入物化視圖等能力。
總體而言,StarRocks 的未來規劃將圍繞 Lakehouse 場景展開,包括去年已經推出的數據庫分析場景,以及即將推出的小型數倉場景。我們期待在 3.1 或 3.2 版本穩定后,進一步拓展 Lakehouse 場景。
以上就是本次分享的全部內容。感謝大家的關注,我們將繼續努力,為大家提供更好的產品和服務。


































