基於StarRocks的極速實時資料分析實踐

語言: CN / TW / HK

總篇119篇 2021年第10篇

實時資料分析的現狀

在汽車之家內部,實時資料的來源主要是三部分:

手機端戶行為的日誌;

應用程式的服務端的日誌;

MySQL SQLServer 資料

實時資料分析場景,目前面臨的一些痛點包括:

使用 Flink 做指標聚合, Flink 聚合不靈活,面對需求的時候開發成本比較高的,面對多變的需求,經常需要重複開發;

Kylin 支援指標預計算,併發支援較好,但是不能夠支援高效的明細資料查詢。在一些需要下鑽或者獲取明細資料的場景支撐的不夠好;

TiDB 不支援預聚合模型,某些資料量大的場景,聚合指標需要線上計算。線上計算會導致伺服器壓力瞬間增大,而且查詢效能不穩定,取決於參與計算的資料量和當時伺服器的負載情況。

為什麼選擇 StarRocks

上圖是幾個 OLAP 引擎的橫向對比。 StarRocks 作為一款新興 OLAP 產品,具有以下幾個突出的優點:

查詢場景靈活: StarRocks 所能夠支撐的查詢場景比較靈活。既能夠從明細資料進行聚合分析,也能基於預聚合的模型去提前構建好,加速查詢;

相容 MySQL 協議,平時使用 MySQL 的客戶端就能進行查詢和簡單的運維: StarRocks 相容 MySQL 協議,使用成本、運維成本都比較低;

全面向量化引擎,查詢效能好:查詢效能高,並且能支援較高的併發和吞吐;

架構精簡,易於運維。

但是 StarRocks 作為 OLAP 界的 年輕人 ,也存在一些不太成熟的方面,比如:目前各個公司應用的深度可能不會特別深,所以還需要結合業務持續打磨。

在選型過程中,我們對 StarRocks 和常用的 OLAP 引擎做了一些對比測試。

VS Apache Kylin

在汽車之家內部 Apache Kylin 主要是面對固定查詢的場景。主要都是一些特定的資料產品,還有一些日常的報表等。由於 Apache Kylin 是基於純預聚算模型的,拿空間去換時間。所以在固定報表的場景下查詢效能是非常好的,也能支援很高的併發。缺點就是不太靈活,要預先定義模型,如果要修改模型話,要重刷歷史資料。

上圖是 StarRocks Apache Kylin 的一些對比。在 6 個億的資料量下,用一個線上的 Cube ,和兩臺 StarRocks 去做一個簡單的對比,在命中物化檢視的場景下, StarRocks 的查詢效能可以媲美 Apache Kylin ,有些查詢甚至比 Apache Kylin 還要快。

VS ClickHouse

ClickHouse 雖然能支援明細資料和預聚合模型,也是基於向量化的引擎,但主要缺點是運維成本高,對多表關聯查詢的支援較弱,所以我們選擇了 StarRocks

上圖是 StarRocks ClickHouse 的效能對比。在 120 億的資料規模下,部署了四臺伺服器,針對 Count 非精確去重兩種查詢做效能對比。在 Count 的場景下, ClickHouse 的效能是比較接近的,兩者沒有明顯的差異。在 非精確去重( HLL )場景下, StarRocks 查詢效能明顯優於 ClickHouse 。這得益於 StarRocks 1.18 針對 HLL 查詢的效能優化,在我們的測試場景下 HLL 查詢的效能相比 StarRocks 1.17 提升了 3~4 倍。

VS Apache Doris

上圖是 StarRocks Apache Doris 的效能對比。也是在 6 個億的資料量和兩臺機器的規模下進行的對比。由於 StarRocks 引入向量化引擎,相比 Apache Doris 查詢效能有 2~7 倍的提升。

VS Presto、Spark(hive外表)

上圖是 StarRocks Presto Spark 查詢 Hive 外表的一些效能對比。在 10 億的資料量下,部署了八臺伺服器(是和 Presto Spark 對等的資源),測試用例主要是 Count Count Distinct 查詢。測試的結果是 StarRocks 效能最優, 大部分查詢 StarRocks 效能優於 Presto Presto 的效能優於 Spark 。還有另外一個使用 StarRocks 優勢就是可以直接用 ndv 函式去做非精確的排重( HLL ),此時查詢效能優勢更為明顯。

其它

機械硬碟和 SSD 硬碟的對比。在 6 個億的資料量和兩臺機器的規模下,在未命中 PageCache 情況下, SSD 叢集查詢效能提升 3~8 倍;在命中 PageCache 情況下,兩個叢集的效能是比較接近的,此時 SSD 不會帶來效能提升。

應用實踐

當前我們已經初步完成了 StarRocks 和實時、離線平臺的整合工作。

首先是實時平臺,實時計算平臺直接整合 Flink-connector-StarRocks ;然後是離線平臺,我們通過提供 broker load 指令碼,支援將 Hive 資料匯入到 StarRocks 。最後是 StarRocks 監控,主要是基於 Prometheus Grafana ,我們還收集了 StarRocks 本身的 audit log ,並解析每個 SQL 的執行情況、分析 StarRocks 的查詢效能和成功率。

首先看一下 StarRocks Flink 平臺( AutoStream )的整合,使用者可以通過 Flink 原生的 DDL 來定義 StarRocks 表,也就是把   StarRocks 裡面已經存在的一張表對映成 Flink 表。

上圖是一個基於 Flink + StarRocks 的實時 ETL 的案例:

·        從一張表裡面過濾 user_id 大於 0 的, biz_id   biz_type  是數字型別的, event_id 在這幾個事件裡面的資料;

·        通過 DATE_FORMAT 函式以及 CASE WHEN 語句對欄位做處理;

·        最終把結果寫入到 StarRocks 表中。

在離線排程平臺上,我們提供了一個標準的 Python 指令碼用來提交 broker load 任務,通過指令碼 + 引數配置的方式,可將 Hive 資料高效匯入到 StarRocks 中。同時這個指令碼會持續檢查 broker load 任務的進度,如果執行失敗了,那麼對應的排程任務也會失敗,並觸發排程平臺本身的重試及告警機制。

這是我們 DBA 同事配置的 StarRocks 監控的報表。當時遇到了一個問題,就是 StarRocks FE metrics 格式不規範,導致 Prometheus TextParser 解析失敗,我們做了一些程式碼修復。

這是 StarRocks 叢集的統計報表。前面提到了,我們會實時收集、解析 auditlog 中的查詢記錄, 並將這些查詢記錄寫回到一張 StarRocks 表中;再通過配置 AutoBI 的儀表版,就實現了 StarRocks 本身的效能監控及分析。

在報表中我們可以從資料庫、使用者的維度檢視 StarRocks 的查詢次數、相應時間、異常 SQL 等資訊。當叢集發生問題時,這個報表可以幫助我們快速定位問題、恢復業務;同時使用者也可以瞭解自己業務的查詢情況,定位慢 SQL 並進行優化。

截止 10 月底, StarRocks 在汽車之家已經有兩個實時資料分析業務上線,分別是:推薦服務實時監控、搜尋實時效果分析。

推薦服務實時監控

首先是推薦服務的實時監控。需求背景是實時推薦體系涉及多個子系統,為了提升推薦服務的整體穩定性,需要實時監控各子系統的服務健康情況。

上圖是一個大概的鏈路,各個子系統會引入方法監控的 SDK ,通過 SDK 把每分鐘的方法監控的明細資料聚合起來,並將這些經過初步聚合的資料寫入到監控系統裡,監控團隊負責把這些資料推送到 Kafka ,並通過 Flink 實時把資料寫到 StarRocks 表中。在這個場景中,每天寫入 StarRocks 的資料有兩億條左右,這是 StarRocks 在汽車之家上線的第一個業務。

最終在 AutoBI 中的儀表板如上圖,報表的 TP95 響應時間在 1 秒左右,響應速度還是比較快的。

搜尋實時效果

搜尋實時效果,需求是搜尋效果資料的實時 統計,檢視各頻道、 實驗、內容型別的無結果率、跳出率、曝光量、點選量、 CTR ,特點就是日增的資料量在數十億級,主要是應用 Grouping Set 模式,把所有可能的組合都計算好,給使用者提供一個數據表格,並支援按照條件篩選;同時這個需求中涉及多個 UV 指標(非精確去重)的計算,每一行資料中包含 6 UV 指標的計算,下面是 SQL 的示例:

在這個場景下,由於資料量較大,並且包含多個聚合指標,所以我們定義了物化檢視來加速查詢。最後的展示形式就是下面的這種圖表加上明細表格的形式。

我們最初使用的是 StarRocks 1.17 ,由於存在多個 UV 指標,查詢效能並不理想,在升級到 StarRocks 1.18 之後,效能得到了較大的提升,響應時間從十幾秒降到四秒內。

總結與規劃

最後簡單總結一下,我們通過引入 StarRocks 統一了明細查詢和預聚合兩種模型。其次是流批的統一,實時的資料和離線的資料都可以寫到 StarRocks 裡面,對外暴露統一的 OLAP 引擎來提供服務,這對使用者來說是很友好的。另外在查詢效能方面,我們通過跟其他的引擎的對比發現, StarRocks 的查詢效能整體上來說是有優勢的。最後 StarRocks 相容 MySQL 協議,容易上手,運維簡單。

後續我們會持續完善內部工具鏈,支援將業務表資料實時分發到 StarRocks 表中,進一步簡化實時分析的鏈路。同時我們也會持續擴充套件 StarRocks 應用場景,積累經驗,提升叢集穩定性,更好的支援業務。

作者簡介

▼ 關注「 之家技術 」,獲取更多技術乾貨 

「其他文章」