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

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

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

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

　　·手機端戶行為的日志;

　　·應用程序的服務端的日志;

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

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

　　·使用Flink做指標聚合，F(xiàn)link聚合不靈活，面對需求的時候開發(fā)成本比較高的，面對多變的需求，經常需要重復開發(fā);

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

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

　　　　為什么選擇StarRocks

　　上圖是幾個OLAP引擎的橫向對比。StarRocks作為一款新興OLAP產品，具有以下幾個突出的優(yōu)點：

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

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

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

　　·架構精簡，易于運維。

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

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

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

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

　　協(xié)議：3000多個協(xié)議，也就是對應3000多個維度表。

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

　　并發(fā)量：異常檢測平臺調用，最高33w/min的調用峰值。

　　　　VS Apache Kylin

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

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

　　　　VS ClickHouse

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

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

　　　　VS Apache Doris

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

　　　　VS Presto、Spark（hive外表）

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

　　　　其它

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

　　　　應用實踐

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

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

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

　　上圖是一個基于Flink+StarRocks的實時ETL的案例：

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

　　·通過DATE_FORMAT函數(shù)以及CASE WHEN語句對字段做處理;

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

　　在離線調度平臺上，我們提供了一個標準的Python腳本用來提交broker load任務，通過腳本+參數(shù)配置的方式，可將Hive數(shù)據(jù)高效導入到StarRocks中。同時這個腳本會持續(xù)檢查broker load任務的進度，如果執(zhí)行失敗了，那么對應的調度任務也會失敗，并觸發(fā)調度平臺本身的重試及告警機制。

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

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

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

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

　　　　推薦服務實時監(jiān)控

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

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

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

　　　　搜索實時效果

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

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

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

　　　　總結與規(guī)劃

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

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

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