攜程是全球領(lǐng)先的一站式旅行平臺，現(xiàn)有員工約30000人，公司旗下的平臺可面向全球用戶提供一套完整的旅行產(chǎn)品、服務(wù)及差異化的旅行內(nèi)容。攜程大住宿部是國內(nèi)最大的酒店分銷電子商務(wù)平臺，在全球擁有約63萬家國內(nèi)酒店和70萬家國際酒店。攜程大住宿數(shù)據(jù)智能平臺中70%的實時數(shù)據(jù)場景已經(jīng)接入StarRocks，查詢響應(yīng)速度平均在200ms左右，超過500ms的慢查詢數(shù)大幅度減少，同時人力和硬件成本大大降低。后續(xù)會將剩余的實時場景和離線場景全部遷入StarRocks。
(作者：史文俊攜程大住宿數(shù)據(jù)智能部資深開發(fā)工程師，負責攜程大住宿數(shù)據(jù)智能平臺的研發(fā))
平臺現(xiàn)狀
大住宿數(shù)據(jù)智能平臺(簡稱HData)是一個為攜程大住宿業(yè)務(wù)提供數(shù)據(jù)可視化的平臺，簡而言之，就是用圖表的形式更為直觀地展示與解讀數(shù)據(jù)，幫助業(yè)務(wù)獲得知識和洞察，形成正確的決策，做出快速決策，少犯錯誤。在大住宿內(nèi)部，每個部門關(guān)心的指標側(cè)重點會不同，權(quán)限控制也都會不一樣，所以數(shù)據(jù)展示的方式也是多樣化。
HData每天有將近2200左右的UV，10w左右的PV來訪問我們的系統(tǒng)，而節(jié)假日期間的訪問量基本都會翻2到3倍。
從2018年開始使用ClickHouse以來，我們90%的業(yè)務(wù)線都強依賴于ClickHouse，95%左右的接口響應(yīng)時長都在1s以內(nèi)，ClickHouse強悍的查詢性能得到了充分體現(xiàn)。
現(xiàn)在總數(shù)據(jù)行數(shù)大概700億左右，每天有超過2000個左右的流程，需要更新的數(shù)據(jù)行數(shù)大概有150億左右。
未壓縮前的數(shù)據(jù)總?cè)萘浚?T，壓縮后的數(shù)據(jù)總?cè)萘浚?.75T。
但是ClickHouse無法支持高并發(fā)查詢的缺陷也很明顯，現(xiàn)在CPU大部分情況下消耗是在30%以內(nèi)，不過當有用戶大量查詢時CPU使用率可能就會被拉的很高。并且如果出現(xiàn)一個復(fù)雜的高消耗查詢，只靠人工手刷，可能在很短的時間內(nèi)就可以把40C的CPU使用率打滿：
工作日的早上9點一般會有一波訪問高峰，為了保持系統(tǒng)穩(wěn)定，我們采用主動建立緩存+用戶被動觸發(fā)緩存的機制來降低ClickHouse服務(wù)器的壓力。
一方面我們會將一些高頻訪問的頁面查詢結(jié)果進行緩存。另一方面，在離線數(shù)據(jù)更新完成后，我們通過分析用戶行為數(shù)據(jù)，主動給最近5天來訪問過相關(guān)數(shù)據(jù)的用戶緩存默認條件的數(shù)據(jù)，降低波峰。
現(xiàn)在的主動緩存+被動緩存取代了原本需要從ClickHouse上很大一部分的查詢量，這樣可以避免我們無限的擴容服務(wù)器。同時也可以把因為集中并發(fā)的查詢拉起來的峰刺打平。
現(xiàn)階段痛點
在節(jié)假日期間，實時數(shù)據(jù)是關(guān)注的重點，以今年勞動節(jié)為例，實時看板的訪問量要比平時高10倍左右。
工作日期間，CPU使用率一般不會超過30%。
節(jié)假日期間，CPU使用率一度超過70%，這對服務(wù)器的穩(wěn)定性造成了很大隱患。
面對這種情況，一方面我們在前端做了節(jié)流來防止用戶高頻查詢，同時在后端也做了緩存，但是實時數(shù)據(jù)的緩存時間不能太久，一般1~2分鐘已經(jīng)是用戶可接受的極限。通過下圖可以發(fā)現(xiàn)，離線數(shù)據(jù)的緩存命中率一般都會比較高，基本能達到50%以上甚至更高，但對于實時數(shù)據(jù)，命中率則只有10%左右：
另一方面，我們在服務(wù)端啟用了分流機制：實際應(yīng)用場景中有一些業(yè)務(wù)的權(quán)限比較小，對應(yīng)需要查詢的數(shù)據(jù)量也會比較小，我們通過分析定義出了一個閾值，比如權(quán)限數(shù)小于5000的用戶從MySQL請求數(shù)據(jù)，這部分用戶即使通過MySQL查詢速度也很快。讓權(quán)限大的用戶通過ClickHouse請求數(shù)據(jù)，這樣可以引流很大一部分用戶。
這樣做雖然暫時解決了眼下的問題，不過新的問題又接踵而至：
·數(shù)據(jù)需要雙寫到ClickHouse和MySQL，無法保證兩邊數(shù)據(jù)的一致性
·同時存在兩套數(shù)據(jù)，導(dǎo)致硬件成本增加
·ClickHouse不支持標準SQL語法，所以代碼也需要維護兩套，開發(fā)成本增加
針對上述問題的挑戰(zhàn)，我們的目標是尋求一個新的OLAP引擎來減少開發(fā)和運維成本，同時還要兼顧查詢性能，并在高并發(fā)和高吞吐的場景下有較好的適用性。
為此我們嘗試了一些市面上其他引擎，如Ingite、CrateDB、Kylin等，每種引擎從硬件成本或性能上都有自己特有的優(yōu)勢，不過綜合到使用場景，最終我們選擇了StarRocks。
StarRocks介紹
·StarRocks是一個高性能分布式關(guān)系型列式數(shù)據(jù)庫，通過MPP執(zhí)行框架，單節(jié)點每秒可處理多達100億行數(shù)據(jù)，同時支持星型模型和雪花模型。
·StarRocks集群由FE和BE構(gòu)成，可以使用MySQL客戶端訪問StarRocks集群。
·FE接收MySQL客戶端的連接，解析并執(zhí)行SQL語句，管理元數(shù)據(jù)，執(zhí)行SQL DDL命令，用Catalog記錄庫、表、分區(qū)，tablet副本等信息。
·BE管理tablet副本，tablet是table經(jīng)過分區(qū)分桶形成的子表，采用列式存儲。BE受FE指導(dǎo)，創(chuàng)建或刪除子表。
·BE接收FE分發(fā)的物理執(zhí)行計劃并指定BE coordinator節(jié)點，在BE coordinator的調(diào)度下，與其他BE worker共同協(xié)作完成執(zhí)行。
·BE讀本地的列存儲引擎，獲取數(shù)據(jù)，通過索引和謂詞下沉快速過濾數(shù)據(jù)。
我們選擇StarRocks主要基于以下幾方面的考慮：
1.亞秒級查詢延時
2.在高并發(fā)查詢、多表關(guān)聯(lián)等復(fù)雜多維分析場景有良好的性能表現(xiàn)
3.支持彈性擴展，擴容不影響線上業(yè)務(wù)，后臺自動完成數(shù)據(jù)rebalance
4.集群中服務(wù)有熱備，多實例部署，節(jié)點的宕機、下線、異常都不會影響集群服務(wù)的整體穩(wěn)定性。
5.支持物化視圖和Online Schema Change
6.兼容MySQL協(xié)議，支持標準的SQL語法
性能測試
HData上的數(shù)據(jù)以多表關(guān)聯(lián)為主，在這種場景下，ClickHouse單機性能相比集群性能要好，因而在這里選取ClickHouse單機做對比。下面用3個測試用例分別對StarRocks和ClickHouse進行對比，我們用6臺虛擬機構(gòu)建成了一個集群，3臺FE、BE混部，3臺BE，機器配置如下：
軟件版本：StarRocks標準版1.16.2
ClickHouse配置如下：
軟件版本：ClickHouse20.8
測試用例1
·StarRocks用時：547ms
·ClickHouse用時：1814ms
測試用例2
·StarRocks用時：126ms
·ClickHouse用時：142ms
測試用例3
·StarRocks用時：387ms
·ClickHouse用時：884ms
可以看到，StarRocks的查詢性能完全不遜色于ClickHouse，甚至更快。
數(shù)據(jù)更新機制
StarRocks根據(jù)攝入數(shù)據(jù)和實際存儲數(shù)據(jù)之間的映射關(guān)系，將數(shù)據(jù)表的明細表，聚合表和更新表，分別對應(yīng)有明細模型，聚合模型和更新模型。
·明細模型：表中存在主鍵重復(fù)的數(shù)據(jù)行，和攝入數(shù)據(jù)行一一對應(yīng)，用戶可以召回所攝入的全部歷史數(shù)據(jù)。
·聚合模型：表中不存在主鍵重復(fù)的數(shù)據(jù)行，攝入的主鍵重復(fù)的數(shù)據(jù)行合并為一行，這些數(shù)據(jù)行的指標列通過聚合函數(shù)合并，用戶可以召回所攝入的全部歷史數(shù)據(jù)的累積結(jié)果，但無法召回全部歷史數(shù)據(jù)。
·更新模型：聚合模型的特殊情形，主鍵滿足唯一性約束，最近攝入的數(shù)據(jù)行，替換掉其他主鍵重復(fù)的數(shù)據(jù)行。相當于在聚合模型中，為數(shù)據(jù)表的指標列指定的聚合函數(shù)為REPLACE，REPLACE函數(shù)返回一組數(shù)據(jù)中的最新數(shù)據(jù)。
·StarRocks系統(tǒng)提供了5種不同的導(dǎo)入方式，以支持不同的數(shù)據(jù)源(如HDFS、Kafka、本地文件等)，或者按不同的方式(異步或同步)導(dǎo)入數(shù)據(jù)。
·Broker Load：Broker Load通過Broker進程訪問并讀取外部數(shù)據(jù)源，然后采用MySQL協(xié)議向StarRocks創(chuàng)建導(dǎo)入作業(yè)。適用于源數(shù)據(jù)在Broker進程可訪問的存儲系統(tǒng)(如HDFS)中。
·Spark Load：Spark Load通過Spark資源實現(xiàn)對導(dǎo)入數(shù)據(jù)的預(yù)處理，提高StarRocks大數(shù)據(jù)量的導(dǎo)入性能并且節(jié)省StarRocks集群的計算資源。
·Stream Load：Stream Load是一種同步執(zhí)行的導(dǎo)入方式，通過HTTP協(xié)議發(fā)送請求將本地文件或數(shù)據(jù)流導(dǎo)入到StarRocks中，并等待系統(tǒng)返回導(dǎo)入的結(jié)果狀態(tài)，從而判斷導(dǎo)入是否成功。
·Routine Load：Routine Load提供了一種自動從指定數(shù)據(jù)源進行數(shù)據(jù)導(dǎo)入的功能。用戶通過MySQL協(xié)議提交例行導(dǎo)入作業(yè)，生成一個常駐線程，不間斷的從數(shù)據(jù)源(如Kafka)中讀取數(shù)據(jù)并導(dǎo)入到StarRocks中。
·Insert Into：類似MySQL中的Insert語句，可以通過INSERT INTO tbl SELEC...或INSERT INTO tbl VALUES(...)等語句插入數(shù)據(jù)。
·HData中的數(shù)據(jù)主要分為實時數(shù)據(jù)和離線T+1數(shù)據(jù)。
實時數(shù)據(jù)主要通過Routine load的方式導(dǎo)入，以使用更新模型為主
離線T+1數(shù)據(jù)主要使用Zeus平臺，通過Stream load的方式導(dǎo)入，以使用明細模型為主
實時數(shù)據(jù)通過攜程自研的消息隊列系統(tǒng)QMQ實現(xiàn)，下圖是原先的實時數(shù)據(jù)導(dǎo)入流程：
接入StarRocks后的實時數(shù)據(jù)導(dǎo)入流程：
很快我們就遇到了一個難題：有一個場景是訂閱訂單狀態(tài)變化的消息，下游我們以訂單號作為主鍵，使用更新模型來將數(shù)據(jù)落地。對外我們提供訂單狀態(tài)為非取消的數(shù)據(jù)進行展示。
在收到消息后，我們還需要調(diào)用外部接口來補全一些其他字段，最后再把數(shù)據(jù)落地。但如果收到一條消息就調(diào)用一次接口，這么做會對接口造成壓力，所以我們采取了批處理的方式。
不過這樣做產(chǎn)生了一個問題：Kafka本身無法保證全局消息是有序的，只能保證partition內(nèi)的有序性。同一個批次同一個訂單，但訂單狀態(tài)不同的2條數(shù)據(jù)如果分別落在了不同的partition，routine load時無法保證哪條數(shù)據(jù)會先被消費。如果訂單狀態(tài)為取消的消息先被消費，而其他訂單狀態(tài)的消息后被消費，這樣會造成原本應(yīng)該取消的訂單重新變成了非取消訂單，從而影響統(tǒng)計的準確性。
我們也考慮過不通過QMQ而改用原生的Kafka，將訂單號作為key來指定發(fā)送到哪個partition中，不過這樣做需要二次開發(fā)，而且改動的成本也不低。
為了解決這個問題，我們選擇了一個折中的辦法：在消息落地同時，又用明細模型落地了一個日志表，表里只需要存訂單號、訂單狀態(tài)以及消息發(fā)送時間。同時，有一個定時任務(wù)每隔一段時間會對該表內(nèi)相同訂單號的數(shù)據(jù)進行排序，取消息發(fā)送時間最新的一條數(shù)據(jù)，用訂單號與正式表中訂單狀態(tài)不一致的數(shù)據(jù)進行匹配然后進行更新，以這樣的形式對數(shù)據(jù)進行一個補償。
T+1數(shù)據(jù)我們通過攜程自研的數(shù)據(jù)同步平臺Zeus進行ETL和導(dǎo)入：
DR和高可用
攜程對DR有著很高的要求，每隔一段時間都會有公司級的DR演練。StarRocks本身已經(jīng)具備了十分優(yōu)秀的DR機制，在此基礎(chǔ)之上，我們構(gòu)建了一套適合自己的高可用體系：
·服務(wù)器分別部署在2個機房，以5:5的流量對外提供服務(wù)。對外提供服務(wù)的FE節(jié)點的負載均衡以配置項的形式實現(xiàn)，可以動態(tài)修改，實時生效(主要是考慮有服務(wù)器打補丁、版本升級等需要手動拉出的情況)。
·每個FE和BE進程全部都用supervisor進行進程守護，保證進程出現(xiàn)意外退出時可以被自動拉起。
·當FE節(jié)點出現(xiàn)故障時，存活的follower會立即選舉出一個新的leader節(jié)點提供服務(wù)，但是應(yīng)用端卻無法立即感知，為了應(yīng)對這種情況，我們起了一個定時任務(wù)，每隔一段時間對FE服務(wù)器進行health check，一旦發(fā)現(xiàn)FE節(jié)點故障，則立即將故障節(jié)點拉出集群，同時以短信方式通知開發(fā)人員。
·當BE節(jié)點出現(xiàn)故障時，StarRocks內(nèi)部會自動進行副本均衡，對外仍可繼續(xù)提供服務(wù)，同時我們也會有一個定時任務(wù)對其進行health check，每當發(fā)現(xiàn)有BE節(jié)點故障，則會以郵件形式通知開發(fā)人員。
·同時，我們針對每臺服務(wù)器的硬件指標也配置了告警，通過攜程自研的智能告警中臺，一旦服務(wù)器的CPU、Mem、磁盤空間等指標發(fā)生異常，開發(fā)人員可以立即感知并介入。
總結(jié)和后期規(guī)劃
現(xiàn)在HData中70%的實時數(shù)據(jù)場景已經(jīng)接入StarRocks，查詢響應(yīng)速度平均在200ms左右，耗時500ms以上的查詢只占總查詢量的1%;并且數(shù)據(jù)和代碼也只需要維護一套，人力和硬件成本大大降低。
后期規(guī)劃
·將剩余的實時場景全部遷入StarRocks。
·離線場景也逐漸遷入StarRocks，逐步用StarRocks來統(tǒng)一OLAP分析全場景。
·進一步完善對StarRocks的監(jiān)控機制，使其更健壯。
·通過讀取Hive外表的形式做數(shù)據(jù)冷熱分離，減少硬件成本。
