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

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

　　　　實時數據分析的現狀

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

　　·手機端戶行為的日志;

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

　　·MySQL、SQLServer數據。

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

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

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

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

　　　　為什么選擇StarRocks

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

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

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

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

　　·架構精簡，易于運維。

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

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

　　　　業務規模

　　多維監控平臺整體業務規模：

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

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

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

　　　　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，特點就是日增的數據量在數十億級，主要是應用GroupingSet模式，把所有可能的組合都計算好，給用戶提供一個數據表格，并支持按照條件篩選;同時這個需求中涉及多個UV指標(非精確去重)的計算，每一行數據中包含6個UV指標的計算，下面是SQL的示例：

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

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

　　　　總結與規劃

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

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

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