阿里云 E-MapReduce Serverless StarRocks 版是阿里云提供的 Serverless StarRocks 全托管服務卡辰，提供高性能反砌、全場景、極速統(tǒng)一的數(shù)據(jù)分析體驗森渐，具備開箱即用竟块、彈性擴展浪秘、監(jiān)控管理、慢 SQL 診斷分析等全生命周期能力夺衍。內(nèi)核 100% 兼容 StarRocks，性能比傳統(tǒng) OLAP 引擎提升 3-5 倍矛紫，助力企業(yè)高效構(gòu)建大數(shù)據(jù)應用。本篇文章重點介紹阿里云 EMR StarRocks 與開源 StarRocks 的對比與客戶案例贪染。
一、開源對比
阿里云 EMR StarRocks 與社區(qū)版本功能對比分為三個部分痰憎，首先是 StarRocks 內(nèi)核及架構(gòu)的差異；其次是在實例運維管理能力上的差異蜗细；接下來一部分就是關于數(shù)據(jù)的運維，也就是對 StarRocks 內(nèi)部的數(shù)據(jù)應該如何管理的問題缎岗。通過阿里云 EMR StarRocks Manager，大家可以做很多與數(shù)據(jù)運維或業(yè)務運維相關的事情眷细。
內(nèi)核及架構(gòu)對比
首先第一部分就是關于 StarRocks 內(nèi)核的對比掌敬，阿里云 EMR 團隊與 StarRocks 社區(qū)已經(jīng)合作很長時間了楷兽，所以基本上會貢獻給社區(qū)。但是如果是周邊產(chǎn)品的集成或新加的一些功能還是暫時會放到 EMR StarRocks 商業(yè)化的板塊中進行管理揭厚。一些商業(yè)化能力經(jīng)過一些時間差也會逐步合并到社區(qū)版本中。
當前內(nèi)核部分太援，第一個不同就是高 QPS 點查，在上萬級別的 QPS 場景中碱蒙，EMR Serverless StarRocks 做了一系列優(yōu)化巧还，能夠保證高 QPS 下的性能的穩(wěn)定性。接下來是現(xiàn)代物化視圖阶牍，對于這個部分，EMR Serverless StarRocks 添加了物化改寫的能力磕瓷，用戶去查詢物化視圖的時候，如果基表更新了硕盹，但是物化視圖還沒有更新的情況下，就能夠快速去查詢到實時更新的那部分數(shù)據(jù)垛贤，而用戶的業(yè)務 SQL 是不需要改寫的。還有一部分就是存算分離部凑，存算分離主要是指數(shù)據(jù)湖當中的存算分離版本，在數(shù)據(jù)湖存算分離的版本下比勉，EMR Serverless StarRocks 對數(shù)據(jù)湖部分做了大量優(yōu)化，性能提升也極為明顯墓捻，約為20%~30%，極端情況下能到70%梧兼，以上也是內(nèi)核目前存在的比較大的差異點。
其次是數(shù)據(jù)湖的部分考赛，在這一部分 StarRocks 重點結(jié)合 Paimon 做了大量的改造，包括集團內(nèi)部也在進行業(yè)務試點的嘗試，構(gòu)建彈內(nèi)的 StarRocks 加 Paimon 的數(shù)據(jù)湖場景腌零。這部分的性能差異用戶也能在 StarRocks 使用到最新的版本，最新版本中性能和功能都會較為完善闲询。還有一部分就是和阿里云實時計算合作，加入了整庫整表同步的功能鸽捻，用戶可以通過 Flink VVP 進行試用衣赶，也可以使用 Dataworks + StarRocks 進行實時寫入和批量寫入，同樣也能實現(xiàn)整庫整表同步更新。這一部分的功能也是和開源版本存在差異团搞，因為它需要借助阿里云上的其他產(chǎn)品的能力去實現(xiàn)實時的寫入，例如將 MySQL 的數(shù)據(jù)實時地導入到 StarRocks 當中复隆，實現(xiàn)整庫遷移。對于實現(xiàn)這樣的效果亏栈，StarRocks 也將這一部分功能進行了集成。
以上就是目前在內(nèi)核部分的大部分差異闷游，基本上和社區(qū)在內(nèi)核層面保持一致，但會增加一些功能幫助用戶提升查詢性能业簿，或提升并發(fā)度和優(yōu)化用戶體驗蔚携。
實例運維管理
在實例運維層面酝蜒，如上圖所示，在開源版本當中沒有可視化的管理平臺，在 EMR StarRocks 當中則有一整套的在線擴縮容途戒、部署、集群運維管理系統(tǒng)星爪。包括監(jiān)控報警功能都是現(xiàn)成的。用戶只需要使用開了 EMR StarRocks 的賬號進行登錄抄肖，即開即用。在 Serverless 版本中會有故障自動恢復潮售，以及相應的一些自動恢復機制鞍泉，保障各種節(jié)點自動恢復边器，不需要用戶過多關注底層的機器資源故障或問題。以上也是 EMR Serverless StarRocks 免運維的部分砚嘴，即集群的自動恢復能力方面，不需要用戶使用過多人力進行機器運維。
另外一部分差異就在于彈性方面如绸，目前用戶對于彈性的需求較為明顯，無論是 StarRocks 做數(shù)據(jù)湖分析蜕提，還是在傳統(tǒng)的 StarRocks OLAP 報表分析場景當中，用戶都會經(jīng)常遇到偶發(fā)的波峰，而在夜晚耗費的資源就會比較少须喂，有了彈性的能力就可以幫助用戶更好的節(jié)省計算成本，具體發(fā)布見官方發(fā)布的公告是己，預計在6月初推出 CN 節(jié)點的彈性。當用戶的業(yè)務有明顯的波峰和波谷時逆皮，用戶可以結(jié)合彈性更好地節(jié)省計算成本。
接下來就是小版本的自動升級辰企，眾所周知，StarRocks 迭代較快潜索，非常活躍整陌。用戶經(jīng)常面臨的問題就是如何從2.5.8升級到2.5.10，類似于以上的小版本升級震放。如果是自建的話，就需要自己手動做維護勉躺。在 EMR Serverless StarRocks 當中妇萄，就能夠通過一鍵按鈕冠句，自動的進行小版本滾動升級，這也是 EMR Serverless StarRocks 較為受歡迎的點丐重，因為 StarRocks 更新確實較為頻繁。
另外還有一個在計劃之中的特點就是 Multi WareHouse崖蜜，開源版本目前并不會有 Multi WareHouse，但大概在7月底等恐，平臺會基于 Serverless StarRocks 3.3版本推出 Multi WareHouse 能力， 幫助用戶更方便地進行業(yè)務隔離。較為典型的場景就是有時需要將導入任務和查詢?nèi)蝿辗珠_同欠，讓他們分別使用不同的計算資源，以免由于導入任務忽然很大茎刚，導致 SQL 無法查詢蚊荣，或一個 SQL 查的很大互例，導致導入任務無法寫入媳叨，以上是用戶在使用 Serverless StarRocks 集群時經(jīng)常會碰到的問題解寝。
接下來是 Cluster Linking夫偶，在進行集群遷移或備份到新的集群的場景當中可以借助 Cluster Linking 工具。目前说铃， Cluster Linking 還只是一個工具并沒有完全產(chǎn)品化砾嫉，因為基本上已經(jīng)能夠滿足大部分場景舶沿。
以上就是關于 EMR StarRocks 與開源版本在集群或?qū)嵗矫娴哪芰Σ町悺?/p>
StarRocks Manager
在 StarRocks Manager 中提供了很多功能溉旋，提供 SQL Editor岩喷，用戶在寫 SQL婶溯，或是日常進行命令行操作時都可以使用 SQL Editor 工具褐筛，只需要在頁面上連接實例，就能夠打開 SQL Editor 進行相應的 SQL 操作或者查詢。在線 SQL Editor 的主要優(yōu)勢就是方便用戶進行在線查詢或開發(fā)調(diào)試倘核。
此外隶校，Manager 層還提供了可視化數(shù)據(jù)庫或數(shù)據(jù)表管理的功能，可以查看數(shù)據(jù)庫或數(shù)據(jù)表峦睡，包括表的分區(qū)或其他相關信息，以上是源數(shù)據(jù)可視化的查看和管理的能力。
Manager 層還提供集群的實例健康報告作岖，用戶可以直接在控制臺集群上查看健康報告痘儡。健康報告當中會幫助用戶統(tǒng)一分析 SQL、導入任務枢步、抓取源數(shù)據(jù)等等沉删，健康報告會顯示使用較多、使用資源較大醉途、查詢較為耗時的 SQL 語句矾瑰；在導入任務方面同樣也會分析導入任務占用資源較多的進程采幌；在抓取源數(shù)據(jù)方面會給出小文件分布較多的表或分區(qū)的數(shù)據(jù)的位置，以上就是平臺結(jié)合整個集群實例會給予用戶的健康報告內(nèi)容慰毅，以幫助用戶做集群治理或業(yè)務層面的數(shù)據(jù)治理。
在慢 SQL 方面，EMR Serverless StarRocks 同樣也提供相應的歸因分析挪拟。在用戶日常使用當中绒障，會出現(xiàn)某個 SQL 運行得很慢的情況，用戶不知道為什么運行得很慢名眉，Serverless StarRocks 就會提供一套慢 SQL 的可視化信息分析掏秩，用戶可以看到每個 SQL 的使用情況队询，包括運行慢的原因，需要如何解決等。以上所提內(nèi)容會在 EMR Serverless StarRocks 最新的版本當中迭代支持照藻。
在導入任務方面列疗，無論是實時導入還是批量導入疤剑，或是其他各種導入任務的日常管理管钳，也是 Serverless StarRocks 的痛點，平臺會提供相應導入任務的相關管理界面躬拢，用戶可以實時看到有什么任務在運行蚪腐、任務故障的日志信息、錯因、進度信息等。
安全及權(quán)限
接下來是權(quán)限可視化方面，EMR Serverless StarRocks 提供了基礎的可視化權(quán)限配置摊腋，當然用戶也可以直接通過命令行進行權(quán)限管理。
目前，可視化物化管理部分、血緣分析已經(jīng)在設計中，在 Serverless StarRocks 3.x之后的湖倉新范式的概念中绽诚，用戶會越來越多的把許多數(shù)據(jù)處理或數(shù)據(jù)加工的任務放到 Serverless StarRocks 當中费坊，則會面臨一個問題就是血源關系是什么樣的漫雕？以及倘若任務出現(xiàn)故障，影響故障的上下游是哪些？以上均是 StarRocks 3.x 之后的湖倉新范式的概念中用戶應用到具體場景中會出現(xiàn)的問題，這兩部分就是物化視圖和血緣滑频，預計在六到七月份做版本發(fā)布。
還有一部分是與 Cache 相關的齿坷，用戶在使用 Serverless StarRocks3.x 版本之后，會進行到存算分離的架構(gòu)當中，在這套架構(gòu)當中用戶會面臨的問題是開始在哪里慰照？有沒有命中？哪些表命中了？哪些表沒命中腻脏？哪些 SQL 命中了？哪些 SQL 沒有命中贡茅？對于以上情況病涨，平臺都會提供 Cache 相關的一整套 Manager 能力，這套 Manager 能力主要就是解決在緩存當中會碰到的一系列問題留搔。用戶可以看到 SQL 中緩存的命中情況苍息、命中的比例。對于數(shù)據(jù)表和數(shù)據(jù)庫泉哈，用戶也能夠看到數(shù)據(jù)庫或數(shù)據(jù)表緩存的數(shù)據(jù)量有多大，包括在健康報告當中也會給出緩存相關的分析信息肢扯，例如會給出哪些表使用較多需要進行緩存？或者哪些緩存現(xiàn)在是該命中的情況下沒有命中只怎，可能需要進行優(yōu)化票渠。以上內(nèi)容也會在健康報告當中結(jié)合緩存的分析報告杜窄，給出用戶相應的治理建議。內(nèi)容對于存算分離場景下的緩存也是較為重要的算途，如果要把存算分離的架構(gòu)用到最優(yōu)塞耕，對緩存的管理就是第一步。
售后及支持
售后服務方面嘴瓤，如果是社區(qū)扫外，用戶則需要依賴于社區(qū)的版本支持；如果是 EMR Serverless StarRocks廓脆，就可以通過支持群或聯(lián)系技術(shù)專家進行售前階段及售后階段的咨詢筛谚，幫助用戶盡快將業(yè)務落實到 Serverless StarRocks 上。如果在使用過程當中出現(xiàn)問題也可以尋找技術(shù)專家進行支持停忿。
以上內(nèi)容就是 EMR Serverless StarRocks 和社區(qū)版本的能力差異刻获，也是 EMR Serverless StarRocks 產(chǎn)品希望能夠幫助用戶解決到的問題。用戶在選型時可以進行綜合評估瞎嬉，同時也能加入釘群進行反饋蝎毡。
二、客戶案例
以下為 EMR Serverless StarRocks 典型客戶案例氧枣，可供參考沐兵。
案例一：某在線教育客戶- BI自助/指標平臺/多維分析/
首先是某在線教育客戶，致力于做傳統(tǒng)的 BI 報表便监、對內(nèi)的運營分析報表扎谎、指標平臺等業(yè)務系統(tǒng)的數(shù)據(jù)。這部分數(shù)據(jù)當中有 T+1 的烧董，也有實時寫入的毁靶。該用戶要求指標能夠靈活定義，各個維度之間能任意組合逊移。該用戶原先使用的解決方案预吆，有 Presto/MySQL 方案，也有較為傳統(tǒng)的 Hive胳泉、Spark拐叉，但基本上性能較差岩遗。EMR Serverless StarRocks 和 Spark 對比，性能有幾倍的提升凤瘦，該用戶期望有更高性能的報表分析綜合平臺宿礁，就選擇了 EMR Serverless StarRocks 路線。
其次蔬芥，EMR Serverless StarRocks 支持 upsert 場景梆靖，傳統(tǒng)平臺和 Spark 不支持 upsert 場景， 當然目前結(jié)合一些湖格式用戶也能夠完成笔诵，但整體的彈性性能不如直接使用 EMR Serverless StarRocks 進行查詢涤姊。如上圖所示，該用戶的整個數(shù)據(jù)架構(gòu)就是將原始的數(shù)據(jù)嗤放、Binlog、日志實時地通過Kafka壁酬、Flink 進行處理之后次酌，實時寫入到 Serverless StarRocks。以上是實時數(shù)據(jù)的鏈路舆乔，還有一部分數(shù)據(jù)量較大的數(shù)據(jù)使用離線的方式岳服，通過小時級使用 Hive 加工之后，然后通過 BulkLoad 的形式上傳到 Serverless StarRocks 當中希俩，完成之后就在 Serverless StarRocks 內(nèi)部形成了一整套的對業(yè)務相關的表的集合吊宋。基于這個集合就可以做上游的多維報表分析颜武、自助 BI 報表平臺或指標平臺璃搜。以上功能基于 Serverless StarRocks 都會對該用戶提供較大的性能提升，此外鳞上，相應的技術(shù)棧也會相對簡單这吻。在 OLAP 場景下將所有數(shù)據(jù)都交給 Serverless StarRocks 即可，以上就是某在線教育客戶的場景篙议，其實也是 Serverless StarRocks 最擅長的場景唾糯，即傳統(tǒng)的 OLAP 報表分析。
案例二：某在線教育客戶-實時事件分析
該案例的在線教育客戶主要進行實時事件分析鬼贱，即實時地將一些數(shù)據(jù)通過 Flink 直接寫到 Serverless StarRocks 做事件分析移怯。對于實時事件分析的場景，在之前用戶會使用 Druid 方案當中一些相對較為復雜的結(jié)構(gòu)这难，查詢性能和 SQL 語法支持方面相對于 Serverless StarRocks 來說較弱舟误。所以最后用戶整體上使用了 Serverless StarRocks，用 Serverless StarRocks 替代了實時寫入姻乓、實時查詢脐帝、簡單的域聚合等同云，在將所有東西嵌入到 Serverless StarRocks 之后，整體的查詢性能有兩倍以上的提升堵腹，SQL 的查詢語法也是 Serverless StarRocks 所支持的炸站，所以他的 SQL 靈活度也較高，可以隨意使用一些組合疚顷，對用戶實時寫入旱易、實時進行事件分析的場景較為適用。在日常生活當中能夠見到的一些大屏也是實時寫入的案例腿堤，同樣使用的也是 Flink 加 Serverless StarRocks 的組合阀坏，對于類似的場景，使用這套組合也是極其穩(wěn)定和保險的笆檀，同時也是 Serverless StarRocks 所擅長的核心場景忌堂。
案例三：某金融公司-OLAP 組件統(tǒng)一提速
本案例中該用戶的初衷是對 OLAP 組件統(tǒng)一提速，這也和 EMR Serverless StarRocks 所宣傳的概念一致酗洒。該客戶是一個金融公司士修，對于金融公司來說可能會有較多的 OLAP 組件喘垂，就會存在相應隱患俱恶。較多的 OLAP 組件對于公司來說第一個缺點是運維較為復雜啦逆，第二個缺點就是存在大量實例优幸，會消耗極大一部分的硬件資源成本蜕径，在某些場景當中并發(fā)會受限晨川，慢 SQL 運行的也會比較慢刷喜，以上內(nèi)容都是該用戶所面臨的痛點荣回，總結(jié)起來就是組件過多難以維護侄榴，需要部署的集群過多成本較高雹锣。
最后該公司決定將整個 OLAP 相關的明細或數(shù)據(jù)等所有業(yè)務數(shù)據(jù)都關聯(lián)到 EMR Serverless StarRocks 當中，通過 Serverless StarRocks 做統(tǒng)一的 OLAP 組件癞蚕，在此操作之下對該用戶的業(yè)務性能查詢提升也是較為明顯的笆制，整體提升40%左右，資源使用率降低達到50%涣达，主要在于 Tidb 方面節(jié)省的成本在辆。在進行簡單的數(shù)據(jù)處理加工時，進行預聚合的時間原來需要三十分鐘度苔，現(xiàn)在只需要三十秒匆篓，所達到的提升有原來的幾十倍。所以對該用戶來說寇窑，性能也提升了鸦概，成本也降低了，原來的預聚合場景的性能提升也非常快窗市，所以消耗的資源也就變少了先慷。
此案例也有越來越多的客戶在選型時進行參考，尤其是在選擇新業(yè)務的時候咨察，基本上就會選擇 Serverless StarRocks论熙。對于用戶來說，節(jié)省了成本摄狱，在后期的技術(shù)當中也能做得更為統(tǒng)一脓诡。本案例中的客戶還希望實現(xiàn)對用戶行為進行分析、監(jiān)控媒役、報警祝谚、用戶畫像的功能，該用戶也就是期望所有 OLAP 相關的能力都可以由 Serverless StarRocks 統(tǒng)一管理和維護酣衷。
案例四：某游戲公司-廣告投放
該用戶是一個偏具體的場景交惯，從技術(shù)角度來看，有兩個數(shù)據(jù)量較大的表穿仪，數(shù)據(jù)寫入頻率也較高席爽。在需要多表、專業(yè)的性能要求較高牡借、寫入的性能要求較高的場景下，就比較適用于 Serverless StarRocks袭异，對用戶來說钠龙，將這部分數(shù)據(jù)切到了 Serverless StarRocks，提升了整個數(shù)據(jù)鏈路的實時性御铃，提升了整體的查詢性能碴里，業(yè)務使用查詢性能提升也較為明顯，成本也相對較低上真。
以上就是 EMR Serverless StarRocks 部分案例場景咬腋。
目前也存在一種現(xiàn)象，越來越多的用戶會直接將相應的數(shù)據(jù)放到 Serverless StarRocks 進行建倉睡互，進行存算分離的用戶也越來越多根竿，或使用 Serverless StarRocks 去構(gòu)建一整套的小型數(shù)倉場景，即直接使用湖倉新范式直接去落地就珠。
