StarRocks 在 58 集團全業務線的深度實踐

語言: CN / TW / HK

 作者:劉春雷,58 集團資料庫專家,StarRocks Community Champion

58 集團是中國網際網路生活服務領域的領導者,旗下有國內最大的生活服務平臺,覆蓋各類業務場景,例如車業務、房產業務、本地服務、招聘業務、金融業務等等。

隨著業務的高速發展,越來越多的分析需求湧現,例如:安全分析、商業智慧分析、數倉報表等。這些場景的資料體量都較大,對資料分析平臺提出了很高的要求。

為了滿足這些分析型業務的需求,DBA 團隊從 2021 年初就開始調研各類分析型資料庫,包括 StarRocks、TiFlash、ClickHouse 等,評測效能及功能。

總體評測下來,StarRocks 在運維方便性、查詢效能、寫入效能上、官方支援力度上均表現優秀,於是我們進行了測試並逐步上線應用,在實際使用上也是滿足預期。

 

#01

引入 StarRocks

DBA 組運維大量的 TiDB 資料庫,叢集 120 套+,TiDB 在 4.0 版本引入了 TiFlash  元件,支援 HTAP 的場景,DBA 引入並上線了部分叢集。

使用中發現 TiFlash 的效能無法完全滿足業務的需求,例如:

  • 寫入效能不能滿足

原因:TiFlash 資料同步於 TiKV,寫速度受限於 TiKV 的效能,如果 AP 的業務比重比較大,則需要很多的 TiKV 與 TiFlash,才能保證效能,造成了資源浪費

  • 讀效能不能滿足

原因:SQL 的執行計劃會自動選擇 TiKV、TiFlash,有時執行計劃不準,本應該走 TiFlash 更快,但是走了 TiKV,導致 SQL 執行時間不穩定;另有些走了 TiFlash 的,效能也無法滿足要求

綜上:TiDB 主打的 HTAP 場景,TP 為主,AP 次要,或者輕量級的 AP 分析

但是業務有很多純AP的分析場景,為了更好的滿足 AP 分析需求,DBA 組調研了StarRocks,並對比了 ClickHouse,發現 StarRocks 在效能、功能、易運維等方面均優於 ClickHouse,便進行了引入與落地。

 

1、新一代極速全場景 MPP 資料庫 StarRocks 

簡介

  • StarRocks 是⼀款經過業界檢驗、現代化的、⾯向多種資料分析場景、相容 MySQL 協議的⾼效能分散式關係型列式資料庫。

  • StarRocks 充分吸收關係型 OLAP 資料庫和分散式儲存系統在大資料時代的優秀研究成果, 並在業界實踐的基礎上, 進⼀步改進、優化、架構升級,加⼊新功能,形成企業級產品。

  • StarRocks 致力於滿足企業⽤戶的多種資料分析場景。支援多種資料模型(明細模型、聚合模型、主鍵模型), 多種匯入方式,可整合和接⼊多種現有系統(Apache Spark、Apache Flink、Apache Hive、ElasticSearch)。

  • StarRocks 相容 MySQL 協議,可使用 MySQL 客戶端,常用 BI ⼯具都可以對接 StarRocks 來進行資料分析。

  • StarRocks 採⽤分散式架構,對 table 進行水平劃分並以多副本儲存。叢集規模可以靈活伸縮,能夠支援 10PB 級別的資料分析,支援 MPP 並行加速計算,支援多副本,具有彈性容錯能力。

  • StarRocks 採用關係模型,使用嚴格的資料型別。使用列式儲存引擎,通過編碼和壓縮技術,降低讀寫放大。使用向量化執行方式,充分挖掘多核 CPU 的平行計算能力,從而顯著提升查詢效能。

優勢

  • 效能好:

       -  寫入效能好,Broker Load 匯入速度 170W+/s

       -  讀效能好,大單表以及多表關聯查詢效能均優於 ClickHouse

  • 易運維:

       -  只有 FE、BE、Broker 節點,架構簡單

       -  新建叢集簡單,正常只建立 FE、BE 角色即可

       -  擴容、縮容簡單,一條命令即可擴縮容,自動均衡資料

  • 資料接入方便

       -  多種匯入途徑,例如 Broker Load(資料來源HDFS)、Routine Load(資料來源 Apache Kafka)、Stream Load(資料來源本地檔案)、外表(資料來源 MySQL、TiDB、ES、Hive 等)、Flink、 DataX 等

      -  58 已經支援多種匯入途徑

  • 支援、相容 MySQL 協議

       -  無需更改 SQL,直接可以使用,遷移方便

  • 表支援多種模型:

       -  支援明細模型,聚合模型,更新模型,主鍵模型,可以滿足業務的明細查詢、聚合查詢以及資料更新的需求

  • 高併發:     

        -  支援高併發查詢

 

2、基於滿足 AP 分析需求的評測

大致評測方向,從兩方面來看,一個是功能上,一個是效能上。StarRocks、ClickHouse、TiDB&TiFalsh 每種資料庫都有各自的特點。

功能

效能

此處引用的測試版本比較低了,根據社群小夥伴以及我們自己內部的測試,StarRocks 新版本比老的版本,效能提升明顯,後面會再進行一次整體的對比測試,敬請期待~

測試基本資訊:

 

效能測試結論:

  • 單表/多表查詢,StarRocks 總體時間均最短

  • 單表查詢:StarRocks 最快次數最多,ClickHouse 次之

  • 多表查詢:StarRocks 所有執行均最快

  • TiDB/TiFlash 總體時間單表/多表查詢均最長

  • TiDB 執行計劃多數走 TiKV,導致執行時間長,且資料量越多,執行時間越長

  • TiDB 強制走 TiFlash,單表多數提速多,多表多數變慢,但 4.0.10/5.0.1 版本的執行計劃多數不走

  • ClickHouse 多表查詢需要更改 SQL,使型別一致才可以,且欄位名、表名區分大小寫

  • ClickHouse 大單表查詢方式效率較好,多表關聯效率降低明顯

  • ClickHouse 分散式表 Join 比全本地單表 Join 的查詢快

  • ClickHouse 小表不推薦使用分散式表 Join,只大表進行分散式表 Join,執行時間均變短

單表查詢對比

 

多表關聯查詢

 

低基數查詢效能對比

StarRocks 2.0 版本引入低基數優化後,與 ClickHouse 的 SQL 查詢效能對比。

基本資訊:

 

結論:

StarRocks 1.19.5 無低基數字典優化,平均執行效能:是 ClickHouse 單例項的 3.18倍,是 ClickHouse 分散式的 1.23 倍

StarRocks 2.0.1 未啟用低基數字典優化,平均執行效能:是 ClickHouse 單例項的 3.09 倍,是 ClickHouse 分散式的 1.20 倍

StarRocks 2.0.1 啟用低基數字典優化,平均執行效能,是 ClickHouse 單例項的 7.05 倍,是 ClickHouse 分散式的 2.73 倍

總體來看,在分散式對等條件下,StarRocks 1.19.5 和 2.0.1 未開啟低基數優化時,效能略優於 ClickHouse,在開啟低基數優化後,StarRocks 效能明顯提升,是 ClickHouse 的 2-3 倍。

#02

業務實踐

目前 StarRocks 已經應用到了所有業務線,涉及日誌流水、使用者畫像、安全分析、DBA 慢 SQL、實時數倉,報表系統、監控資料、風控資料分析等場景,很好地支撐了業務需求。業務型別比較多,以下面三個業務為例:

 

1、安全分析相關業務

每天伺服器上的資訊情況,是內部安全人員比較關心的,但是伺服器上每天有大量的資訊,如何能快速收集落地,統一實時分析呢?

  • 寫入的量上的要求,每天大約幾億的資料需要落地

  • 實時分析:快速的分析,例如:最近 15 分鐘,機器資訊的情況是怎樣的?

  • 定期資料清理

  • 數量累增

因為寫入量大及快速分析的需求,我們選擇了 StarRocks。在使用初期,我們使用了明細模型,20 天左右,資料量就 800 億+了,磁碟 8T 左右,導致一定的效能影響,後與開發方商定,不需要儲存詳細的歷史明細,記錄指定時間的彙總數量即可,於是改成聚合模型,每 15 分鐘進行聚合,次數累增,這樣就大幅減少了資料量,並且資料按照時間分割槽,定期清理分割槽即可,方便了資料清理且方便了查詢。目前每天 10 億左右資料,資料量降低了 75%。

 

2、DBA 內部業務

MySQL 中介軟體我們使用的是 ProxySQL,ProxySQL 支援展示 SQL 情況,但是每次需要重置,才重新開始統計,比較麻煩。如何分析指定時間的 SQL 情況,比較困擾。每個 ProxySQL 有自己的全日誌,我們可以分析全日誌來獲取需要的資訊。第一個架構方案,我們想到了 ElasticSearch,ProxySQL全日誌-->filebeat採集-->Kafka-->logstash-->ElasticSearch,但是實際使用,發現檢視流水可以,但是分析起來就比較麻煩,不如寫 SQL 方便。後來架構又改成了 ProxySQL 全日誌-->filebeat採集-->Kafka-->StarRocks,這樣就可以利用 SQL 進行快速分析了。

另一個問題,因為線上的 ProxySQL 的日誌量特別大,不能所有叢集都開,我們設定了可以選擇開啟,這樣有需要的叢集才進行分析,降低了儲存的壓力。

舉例:分析某 30 分鐘某叢集的 SQL 執行情況,按照次數排序,查詢很快。 

 

3、業務報表

某部門的報表系統底層儲存使用的是自己搭建的資料庫,為 Infobright,這是一款基於知識網格的列式資料庫,對大批量資料的查詢效能非常高。

但是公司要進行成本節約,不允許再申請機器了,且業務需要自己維護資料庫,所以需要有一個由運維團隊支援運維且效能更好的資料庫產品進行替代。使用 StarRocks,在效能上提升明顯,之前千萬級別的表的查詢在 2s+,當前查詢在300ms 左右,查詢平均提升 90% 以上。目前業務整體已經遷移了 80%,已經遷移表 700張+。既減少了運維壓力,又提升了查詢效能。

 

 

#03

管理實踐

58 內部使用的 StarRocks 經歷了多個版本,從 1.11 到 2.2.3 版本,每次新版本的釋出都會帶來一定的效能提升、bug 修復。在版本上,推薦大家按需升級到最新的版本比較好,優先升級不太重要的業務的叢集,分批逐步升級。

 

1、拓撲工具

如何快速知道一個 StarRocks 叢集的拓撲,需要有方便展示的工具。我們開發了qstarrocks 工具,此工具跟元資訊架構緊密相連的,大家逐層設計好元資訊表即可,例如叢集資訊表,例項資訊表,業務線資訊表,庫資訊表,負責人資訊表,域名資訊表,vip 資訊表等,大家參考各自公司的實際情況實現即可。

功能支援:

  • 支援叢集拓撲資訊展示,包括:角色、IP、Port、機房、Domain、VIP、業務線、負責人、重要性、建立時間、監控地址等

  • 支援快速登入指定 FE,方便日常操作

  • 支援叢集重點資訊展示、叢集號、埠、版本、重要性、型別、各節點數量、庫數量、磁碟總量、使用量、佔比、增速、業務線等

叢集拓撲資訊展示:

 

所有叢集重點資訊展示:

 

2、叢集管理工具

為了應對大量叢集的部署、擴縮容、版本升級、開啟、管理、維護等管理員操作,需要有一個統一的管理工具,因此我們開發了starrocks_manage工具,支援:

  • 部署新叢集

  • 複用叢集

  • 新增

  • 刪除

  • 開啟

  • 停止

  • 重啟

  • 升級

  • 資訊

  • 重新載入配置重啟

  • 建立賬號

  • 建立 ETL 域名

 

 

 

3、監控實現

StarRocks 監控分為:存活監控 、效能監控。參考之前 TiDB 的經驗,建設分為:

  • 存活監控:

       -  存活檢查工具,方便日常的狀態檢查

       -  存活監控,任務式採集,報警

  • 效能監控:

       -  根據一定的運維經驗,獲取重要的監控指標,分為:伺服器相關指標、例項相關的指標

  • 彙總監控:

       -  因為正常部署是一套叢集一套監控,要同一地點檢視所有叢集的重點監控的話,就要彙總到一套 Grafana 上

當前監控工具也可以檢查元資訊與 Zabbix 的差異 host,並新增/刪除節點。

此處為監控的全部架構設計圖:

存活監控

存活監控的節點資訊獲取是來自於資料庫的命令:

  • SHOW FRONTENDS;

  • SHOW BACKENDS;

Prometheus+Grafana 是官方推薦的監控架構,所以我們通過 Prometheus 的介面來獲取節點的存活資訊,可以從監控項:up 裡面獲取 FE、BE 節點的存活情況,上報到 DBA 統一監控 Zabbix,利用 Zabbix 傳送報警等。

例如:

檢查工具實現:

效能監控

prometheus 介面獲取重點資訊、伺服器級別、例項級別資訊,上報到 Zabbix,利用 Zabbix 實現效能報警等。

當前已經完成了監控項的採集,具體的監控圖展示還在開發中。

 

4、匯入任務管理

在業務使用 StarRocks 時,有多種接入方式,常見的有 Flink、DataX、Kafka、Stream Load 等,其中 Kafka 直接寫入是很方便的一種方式,為 Routine Load;

當前已經在執行的 Kafka 任務超過了 120 個,急需一個對 Kafka 匯入任務的管理體系。

梳理需求如下:

  • 業務人員:工單申請接入 Kafka,簡單的引導方式

  • DBA:自動化執行 Kafka 工單

  • 開發、DBA:檢視

       -  可檢視任務執行狀態

       -  可檢視任務的基本資訊

       -  非 running 等異常狀態,可報警

       -  可檢視延遲資訊及詳細的各個 Partition 的延遲資訊

       -  可檢視建立 SQL

       -  可檢視匯入的條數、報錯條數等

  • 開發:操作

       -  可以下線任務

       -  可以重建任務

     -  可以設定報警接收人員

我們開發了快速檢視任務建立 SQL 的工具——qstarrocks,可以通過此命令快速檢視任務的狀態,建立 SQL,進行快速重建。原理就是利用 show routine load 命令的結果,拼接任務的建立 SQL。

檢視叢集的所有匯入任務狀態:

 

檢視建立 SQL:

 

為了更方便開發、DBA 詳細的瞭解任務的情況,我們又整體設計了任務的管理,並開發了 starrocks_kafka 工具。

此工具整合了多種功能:

  • 建立、重建 Kafka 任務

  • 檢視 Kafka 的狀態:執行狀態、延遲狀態、消費行數等狀態

  • 檢視 Kafka 的具體資料

  • 獲取建立 SQL

  • 監控與報警:DBA 與業務負責人 

 

架構圖:

 

我們自己開發的管理平臺,分為使用者端與管理端。

使用者端-申請 Kafka 接入任務的工單:

 

 使用者端-任務展示:

 

使用者端-具體任務展示:基本資訊與報錯資訊 

 

使用者端-具體任務展示:監控圖

 

使用者端-具體任務展示:建立 SQL

 

通過開發以上工具和平臺,當前可以比較輕鬆的實現 Kafka 的任務維護,業務同學也可以方便地檢視任務的相關資訊。

 

5、慢 SQL 管理

具體實現

在 StarRocks 的日常使用中,我們需要清晰的瞭解資料庫的 SQL 執行效率,展示慢 SQL 的情況,方便 DBA 與開發檢視,包括天級別慢 SQL 情況、SQL 實時流水、指定時間彙總展示三部分。

StarRocks 的 SQL 日誌格式:

fe/log/fe.audit.log

裡面有 2 種日誌:[query] 和 [slow_query]  ,慢 SQL 我們過濾 slow_query 即可

慢 SQL日誌舉例如下:

2022-06-08 09:05:49,223 [slow_query] |Client=10.1.1.2:42141|User=default_cluster:xxx|Db=default_cluster:xxx|State=EOF|Time=10|ScanBytes=1339|ScanRows=1|ReturnRows=1|StmtId=43542666|QueryId=edbdd4e3-fd64-11eb-b176-0ab2114db0b3|IsQuery=true|feIp=10.1.1.1|Stmt=SELECT 1|Digest=99fa3a962b9640a78ceb79d81a9e83c0

具體實現:

  • 使用通用的日誌採集工具,filebeat

  • StarRocks作為底層的儲存,方便分析

  • Kafka接入方式,快速、高效

  • SQL指紋方便進行分類

實現架構:

filebeat 過濾採集 --> Kakfa --> StarRocks

 

檢視錄入到庫裡的慢 SQL 結果:

 

平臺展示

叢集的天級別慢 SQL 趨勢情況:

 

具體慢 SQL:

 

實時慢 SQL:

 

指定時間的彙總:

 

6、雲化實踐

StarRocks 使用初期,BE 使用物理機混合部署,FE 使用虛擬機器部署,虛擬機器公司最高的配置為 8 核 32G 記憶體 300G 磁碟的,架構圖如下:

但是隨著業務的使用,我們發現總會有 FE 節點宕掉的情況發生,檢視原因為,記憶體吃滿 oom 了,有些是慢 SQL 導致,有些是元資訊過大導致的。但是 FE 已經是公司虛擬機器最高的配置了,不能再增加了,此時我們就想到了使用 Docker 來部署,於是制定了套餐,以滿足不同的業務需求:

FE套餐:

  • 8核-32G記憶體-200G磁碟

  • 16核-64G記憶體-200G磁碟

BE套餐:

  • 8核-32G記憶體-1024G磁碟

  • 16核-64G記憶體-1500G磁碟

  • 32核-64G記憶體-1500G磁碟

  • 32核-128G記憶體-3200G磁碟

雲化的叢集架構如下:

目前已經使用雲化部署的叢集已經有 7 套左右了,歷史的叢集在逐步遷移到雲環境上。新的叢集預設使用雲化環境部署。

其他雲化相關管理的工作還在持續開發中,例如雲宿主機智慧診斷、套餐資源池情況等等,後續會進行分享。

 

#04

總結和展望

我們線上使用 StarRocks 已經近 1 年了,承載了內部多項業務,效能良好,執行穩定,運維方便,很好地滿足了 OLAP 場景的需求。

雖然對於開發者來說有一定的學習成本,例如表模型、匯入方式選擇、查詢調優等,但是通過我們開發的內部工具和平臺,在一定程度上解決了這些問題,讓使用 StarRocks 變得簡單。當然,也希望官方能在這幾點上持續發力,讓大家更加簡單和高效地用起來。

未來我們會將更多的業務接入到 StarRocks,高效支撐業務方極速資料分析的需求。

 

關於 StarRocks 

StarRocks 創立兩年多來,一直專注打造世界頂級的新一代極速全場景 MPP 資料庫,幫助企業建立“極速統一”的資料分析新正規化,助力企業全面數字化經營。

當前已經幫助騰訊、攜程、順豐、Airbnb 、滴滴、京東、眾安保險等超過 110 家大型使用者構建了全新的資料分析能力,生產環境中穩定執行的 StarRocks 伺服器數目達數千臺。 

2021 年 9 月,StarRocks 原始碼開放,在 Github 上的星數已超過 3100 個。StarRocks 的全球社群飛速成長,至今已有超百位貢獻者,社群使用者突破 5000 人,吸引幾十家國內外行業頭部企業參與共建。