汽車之家(NYSE：ATHM)成立于2005年，為消費(fèi)者提供優(yōu)質(zhì)的汽車消費(fèi)和汽車生活服務(wù)，助力中國(guó)汽車產(chǎn)業(yè)蓬勃發(fā)展。我們致力于通過(guò)產(chǎn)品服務(wù)、數(shù)據(jù)技術(shù)、生態(tài)規(guī)則和資源為用戶和客戶賦能，建設(shè)“車內(nèi)容、車交易、車金融、車生活”4個(gè)圈，建立以數(shù)據(jù)和技術(shù)為核心的智能汽車生態(tài)圈，正式邁向智能化的3.0時(shí)代。

　　汽車之家目前在智能推薦的效果分析，物料點(diǎn)擊、曝光、計(jì)算點(diǎn)擊率、流量寬表等場(chǎng)景，對(duì)實(shí)時(shí)分析的需求日益強(qiáng)烈。經(jīng)過(guò)多輪的探索，最終選定StarRocks作為實(shí)時(shí)OLAP分析引擎，實(shí)現(xiàn)了對(duì)數(shù)據(jù)的秒級(jí)實(shí)時(shí)分析。

　　　　實(shí)時(shí)數(shù)據(jù)分析的現(xiàn)狀

　　在汽車之家內(nèi)部，實(shí)時(shí)數(shù)據(jù)的來(lái)源主要是三部分：

　　·手機(jī)端戶行為的日志;

　　·應(yīng)用程序的服務(wù)端的日志;

　　·MySQL、SQLServer數(shù)據(jù)。

　　實(shí)時(shí)數(shù)據(jù)分析場(chǎng)景，目前面臨的一些痛點(diǎn)包括：

　　·使用Flink做指標(biāo)聚合，F(xiàn)link聚合不靈活，面對(duì)需求的時(shí)候開(kāi)發(fā)成本比較高的，面對(duì)多變的需求，經(jīng)常需要重復(fù)開(kāi)發(fā);

　　·Kylin支持指標(biāo)預(yù)計(jì)算，并發(fā)支持較好，但是不能夠支持高效的明細(xì)數(shù)據(jù)查詢。在一些需要下鉆或者獲取明細(xì)數(shù)據(jù)的場(chǎng)景支撐的不夠好;

　　·TiDB不支持預(yù)聚合模型，某些數(shù)據(jù)量大的場(chǎng)景，聚合指標(biāo)需要在線計(jì)算。在線計(jì)算會(huì)導(dǎo)致服務(wù)器壓力瞬間增大，而且查詢性能不穩(wěn)定，取決于參與計(jì)算的數(shù)據(jù)量和當(dāng)時(shí)服務(wù)器的負(fù)載情況。

　　　　為什么選擇StarRocks

　　上圖是幾個(gè)OLAP引擎的橫向?qū)Ρ?。StarRocks作為一款新興OLAP產(chǎn)品，具有以下幾個(gè)突出的優(yōu)點(diǎn)：

　　·查詢場(chǎng)景靈活：StarRocks所能夠支撐的查詢場(chǎng)景比較靈活。既能夠從明細(xì)數(shù)據(jù)進(jìn)行聚合分析，也能基于預(yù)聚合的模型去提前構(gòu)建好，加速查詢;

　　·兼容MySQL協(xié)議，平時(shí)使用MySQL的客戶端就能進(jìn)行查詢和簡(jiǎn)單的運(yùn)維：StarRocks兼容MySQL協(xié)議，使用成本、運(yùn)維成本都比較低;

　　·全面向量化引擎，查詢性能好：查詢性能高，并且能支持較高的并發(fā)和吞吐;

　　·架構(gòu)精簡(jiǎn)，易于運(yùn)維。

　　但是StarRocks作為OLAP界的“年輕人”，也存在一些不太成熟的方面，比如：目前各個(gè)公司應(yīng)用的深度可能不會(huì)特別深，所以還需要結(jié)合業(yè)務(wù)持續(xù)打磨。

　　在選型過(guò)程中，我們對(duì)StarRocks和常用的OLAP引擎做了一些對(duì)比測(cè)試。

　　　　業(yè)務(wù)規(guī)模

　　多維監(jiān)控平臺(tái)整體業(yè)務(wù)規(guī)模：

　　協(xié)議：3000多個(gè)協(xié)議，也就是對(duì)應(yīng)3000多個(gè)維度表。

　　數(shù)據(jù)量：維度表的原始數(shù)據(jù)量非常大，峰值數(shù)據(jù)達(dá)到33億條/min，3萬(wàn)億/天。

　　并發(fā)量：異常檢測(cè)平臺(tái)調(diào)用，最高33w/min的調(diào)用峰值。

　　　　VS Apache Kylin

　　在汽車之家內(nèi)部Apache Kylin主要是面對(duì)固定查詢的場(chǎng)景。主要都是一些特定的數(shù)據(jù)產(chǎn)品，還有一些日常的報(bào)表等。由于Apache Kylin是基于純預(yù)聚算模型的，拿空間去換時(shí)間。所以在固定報(bào)表的場(chǎng)景下查詢性能是非常好的，也能支持很高的并發(fā)。缺點(diǎn)就是不太靈活，要預(yù)先定義模型，如果要修改模型話，要重刷歷史數(shù)據(jù)。

　　上圖是StarRocks與Apache Kylin的一些對(duì)比。在6個(gè)億的數(shù)據(jù)量下，用一個(gè)線上的Cube，和兩臺(tái)StarRocks去做一個(gè)簡(jiǎn)單的對(duì)比，在命中物化視圖的場(chǎng)景下，StarRocks的查詢性能可以媲美Apache Kylin，有些查詢甚至比Apache Kylin還要快。

　　　　VS ClickHouse

　　ClickHouse雖然能支持明細(xì)數(shù)據(jù)和預(yù)聚合模型，也是基于向量化的引擎，但主要缺點(diǎn)是運(yùn)維成本高，對(duì)多表關(guān)聯(lián)查詢的支持較弱，所以我們選擇了StarRocks。

　　上圖是StarRocks與ClickHouse的性能對(duì)比。在120億的數(shù)據(jù)規(guī)模下，部署了四臺(tái)服務(wù)器，針對(duì)Count和非精確去重兩種查詢做性能對(duì)比。在Count的場(chǎng)景下，ClickHouse的性能是比較接近的，兩者沒(méi)有明顯的差異。在非精確去重(HLL)場(chǎng)景下，StarRocks查詢性能明顯優(yōu)于ClickHouse。這得益于StarRocks 1.18針對(duì)HLL查詢的性能優(yōu)化，在我們的測(cè)試場(chǎng)景下HLL查詢的性能相比StarRocks 1.17提升了3~4倍。

　　　　VS Apache Doris

　　上圖是StarRocks與Apache Doris的性能對(duì)比。也是在6個(gè)億的數(shù)據(jù)量和兩臺(tái)機(jī)器的規(guī)模下進(jìn)行的對(duì)比。由于StarRocks引入向量化引擎，相比Apache Doris查詢性能有2~7倍的提升。

　　　　VS Presto、Spark（hive外表）

　　上圖是StarRocks與Presto、Spark查詢Hive外表的一些性能對(duì)比。在10億的數(shù)據(jù)量下，部署了八臺(tái)服務(wù)器(是和Presto、Spark對(duì)等的資源)，測(cè)試用例主要是Count和Count Distinct查詢。測(cè)試的結(jié)果是StarRocks性能最優(yōu)，大部分查詢StarRocks性能優(yōu)于Presto，Presto的性能優(yōu)于Spark。還有另外一個(gè)使用StarRocks優(yōu)勢(shì)就是可以直接用ndv函數(shù)去做非精確的排重(HLL)，此時(shí)查詢性能優(yōu)勢(shì)更為明顯。

　　　　其它

　　機(jī)械硬盤和SSD硬盤的對(duì)比。在6個(gè)億的數(shù)據(jù)量和兩臺(tái)機(jī)器的規(guī)模下，在未命中PageCache情況下，SSD集群查詢性能提升3~8倍;在命中PageCache情況下，兩個(gè)集群的性能是比較接近的，此時(shí)SSD不會(huì)帶來(lái)性能提升。

　　　　應(yīng)用實(shí)踐

　　當(dāng)前我們已經(jīng)初步完成了StarRocks和實(shí)時(shí)、離線平臺(tái)的集成工作。

　　首先是實(shí)時(shí)平臺(tái)，實(shí)時(shí)計(jì)算平臺(tái)直接集成Flink-connector-StarRocks;然后是離線平臺(tái)，我們通過(guò)提供broker load腳本，支持將Hive數(shù)據(jù)導(dǎo)入到StarRocks。最后是StarRocks監(jiān)控，主要是基于Prometheus、Grafana，我們還收集了StarRocks本身的audit log，并解析每SQL的執(zhí)行情況、分析StarRocks的查詢性能和成功率。

　　首先看一下StarRocks和Flink平臺(tái)(AutoStream)的集成，用戶可以通過(guò)Flink原生的DDL來(lái)定義StarRocks表，也就是把StarRocks里面已經(jīng)存在的一張表映射成Flink表。

　　上圖是一個(gè)基于Flink+StarRocks的實(shí)時(shí)ETL的案例：

　　·從一張表里面過(guò)濾user_id大于0的，biz_id和biz_type是數(shù)字類型的，event_id在這幾個(gè)事件里面的數(shù)據(jù);

　　·通過(guò)DATE_FORMAT函數(shù)以及CASE WHEN語(yǔ)句對(duì)字段做處理;

　　·最終把結(jié)果寫入到StarRocks表中。

　　在離線調(diào)度平臺(tái)上，我們提供了一個(gè)標(biāo)準(zhǔn)的Python腳本用來(lái)提交broker load任務(wù)，通過(guò)腳本+參數(shù)配置的方式，可將Hive數(shù)據(jù)高效導(dǎo)入到StarRocks中。同時(shí)這個(gè)腳本會(huì)持續(xù)檢查broker load任務(wù)的進(jìn)度，如果執(zhí)行失敗了，那么對(duì)應(yīng)的調(diào)度任務(wù)也會(huì)失敗，并觸發(fā)調(diào)度平臺(tái)本身的重試及告警機(jī)制。

　　這是我們DBA同事配置的StarRocks監(jiān)控的報(bào)表。當(dāng)時(shí)遇到了一個(gè)問(wèn)題，就是StarRocks它FE metrics格式不規(guī)范，導(dǎo)致Prometheus TextParser解析失敗，我們做了一些代碼修復(fù)。

　　這是StarRocks集群的統(tǒng)計(jì)報(bào)表。前面提到了，我們會(huì)實(shí)時(shí)收集、解析auditlog中的查詢記錄，并將這些查詢記錄寫回到一張StarRocks表中;再通過(guò)配置AutoBI的儀表版，就實(shí)現(xiàn)了StarRocks本身的性能監(jiān)控及分析。

　　在報(bào)表中我們可以從數(shù)據(jù)庫(kù)、用戶的維度查看StarRocks的查詢次數(shù)、相應(yīng)時(shí)間、異常SQL等信息。當(dāng)集群發(fā)生問(wèn)題時(shí)，這個(gè)報(bào)表可以幫助我們快速定位問(wèn)題、恢復(fù)業(yè)務(wù);同時(shí)用戶也可以了解自己業(yè)務(wù)的查詢情況，定位慢SQL并進(jìn)行優(yōu)化。

　　截止10月底，StarRocks在汽車之家已經(jīng)有兩個(gè)實(shí)時(shí)數(shù)據(jù)分析業(yè)務(wù)上線，分別是：推薦服務(wù)實(shí)時(shí)監(jiān)控、搜索實(shí)時(shí)效果分析。

　　　　推薦服務(wù)實(shí)時(shí)監(jiān)控

　　首先是推薦服務(wù)的實(shí)時(shí)監(jiān)控。需求背景是實(shí)時(shí)推薦體系涉及多個(gè)子系統(tǒng)，為了提升推薦服務(wù)的整體穩(wěn)定性，需要實(shí)時(shí)監(jiān)控各子系統(tǒng)的服務(wù)健康情況。

　　上圖是一個(gè)大概的鏈路，各個(gè)子系統(tǒng)會(huì)引入方法監(jiān)控的SDK，通過(guò)SDK把每分鐘的方法監(jiān)控的明細(xì)數(shù)據(jù)聚合起來(lái)，并將這些經(jīng)過(guò)初步聚合的數(shù)據(jù)寫入到監(jiān)控系統(tǒng)里，監(jiān)控團(tuán)隊(duì)負(fù)責(zé)把這些數(shù)據(jù)推送到Kafka，并通過(guò)Flink實(shí)時(shí)把數(shù)據(jù)寫到StarRocks表中。在這個(gè)場(chǎng)景中，每天寫入StarRocks的數(shù)據(jù)有兩億條左右，這是StarRocks在汽車之家上線的第一個(gè)業(yè)務(wù)。

　　最終在AutoBI中的儀表板如上圖，報(bào)表的TP95響應(yīng)時(shí)間在1秒左右，響應(yīng)速度還是比較快的。

　　　　搜索實(shí)時(shí)效果

　　搜索實(shí)時(shí)效果，需求是搜索效果數(shù)據(jù)的實(shí)時(shí)統(tǒng)計(jì)，查看各頻道、實(shí)驗(yàn)、內(nèi)容類型的無(wú)結(jié)果率、跳出率、曝光量、點(diǎn)擊量、CTR，特點(diǎn)就是日增的數(shù)據(jù)量在數(shù)十億級(jí)，主要是應(yīng)用GroupingSet模式，把所有可能的組合都計(jì)算好，給用戶提供一個(gè)數(shù)據(jù)表格，并支持按照條件篩選;同時(shí)這個(gè)需求中涉及多個(gè)UV指標(biāo)(非精確去重)的計(jì)算，每一行數(shù)據(jù)中包含6個(gè)UV指標(biāo)的計(jì)算，下面是SQL的示例：

　　在這個(gè)場(chǎng)景下，由于數(shù)據(jù)量較大，并且包含多個(gè)聚合指標(biāo)，所以我們定義了物化視圖來(lái)加速查詢。最后的展示形式就是下面的這種圖表加上明細(xì)表格的形式。

　　我們最初使用的是StarRocks 1.17，由于存在多個(gè)UV指標(biāo)，查詢性能并不理想，在升級(jí)到StarRocks 1.18之后，性能得到了較大的提升，響應(yīng)時(shí)間從十幾秒降到四秒內(nèi)。

　　　　總結(jié)與規(guī)劃

　　最后簡(jiǎn)單總結(jié)一下，我們通過(guò)引入StarRocks統(tǒng)一了明細(xì)查詢和預(yù)聚合兩種模型。其次是流批的統(tǒng)一，實(shí)時(shí)的數(shù)據(jù)和離線的數(shù)據(jù)都可以寫到StarRocks里面，對(duì)外暴露統(tǒng)一的OLAP引擎來(lái)提供服務(wù)，這對(duì)用戶來(lái)說(shuō)是很友好的。另外在查詢性能方面，我們通過(guò)跟其他的引擎的對(duì)比發(fā)現(xiàn)，StarRocks的查詢性能整體上來(lái)說(shuō)是有優(yōu)勢(shì)的。最后StarRocks兼容MySQL協(xié)議，容易上手，運(yùn)維簡(jiǎn)單。

　　后續(xù)我們會(huì)持續(xù)完善內(nèi)部工具鏈，支持將業(yè)務(wù)表數(shù)據(jù)實(shí)時(shí)分發(fā)到StarRocks表中，進(jìn)一步簡(jiǎn)化實(shí)時(shí)分析的鏈路。同時(shí)我們也會(huì)持續(xù)擴(kuò)展StarRocks應(yīng)用場(chǎng)景，積累經(jīng)驗(yàn)，提升集群穩(wěn)定性，更好的支持業(yè)務(wù)。(作者：邸星星，汽車之家實(shí)時(shí)計(jì)算平臺(tái)負(fù)責(zé)人)

特別提醒：本網(wǎng)信息來(lái)自于互聯(lián)網(wǎng)，目的在于傳遞更多信息，并不代表本網(wǎng)贊同其觀點(diǎn)。其原創(chuàng)性以及文中陳述文字和內(nèi)容未經(jīng)本站證實(shí)，對(duì)本文以及其中全部或者部分內(nèi)容、文字的真實(shí)性、完整性、及時(shí)性本站不作任何保證或承諾，并請(qǐng)自行核實(shí)相關(guān)內(nèi)容。本站不承擔(dān)此類作品侵權(quán)行為的直接責(zé)任及連帶責(zé)任。如若本網(wǎng)有任何內(nèi)容侵犯您的權(quán)益，請(qǐng)及時(shí)聯(lián)系我們，本站將會(huì)在24小時(shí)內(nèi)處理完畢。