攜程是全球領(lǐng)先的一站式旅行平臺(tái)，現(xiàn)有員工約30000人，公司旗下的平臺(tái)可面向全球用戶提供一套完整的旅行產(chǎn)品、服務(wù)及差異化的旅行內(nèi)容。攜程大住宿部是國內(nèi)最大的酒店分銷電子商務(wù)平臺(tái)，在全球擁有約63萬家國內(nèi)酒店和70萬家國際酒店。攜程大住宿數(shù)據(jù)智能平臺(tái)中70%的實(shí)時(shí)數(shù)據(jù)場景已經(jīng)接入StarRocks，查詢響應(yīng)速度平均在200ms左右，超過500ms的慢查詢數(shù)大幅度減少，同時(shí)人力和硬件成本大大降低。后續(xù)會(huì)將剩余的實(shí)時(shí)場景和離線場景全部遷入StarRocks。

　　(作者：史文俊攜程大住宿數(shù)據(jù)智能部資深開發(fā)工程師，負(fù)責(zé)攜程大住宿數(shù)據(jù)智能平臺(tái)的研發(fā))

　　平臺(tái)現(xiàn)狀

　　大住宿數(shù)據(jù)智能平臺(tái)(簡稱HData)是一個(gè)為攜程大住宿業(yè)務(wù)提供數(shù)據(jù)可視化的平臺(tái)，簡而言之，就是用圖表的形式更為直觀地展示與解讀數(shù)據(jù)，幫助業(yè)務(wù)獲得知識(shí)和洞察，形成正確的決策，做出快速?zèng)Q策，少犯錯(cuò)誤。在大住宿內(nèi)部，每個(gè)部門關(guān)心的指標(biāo)側(cè)重點(diǎn)會(huì)不同，權(quán)限控制也都會(huì)不一樣，所以數(shù)據(jù)展示的方式也是多樣化。

　　

 

　　HData每天有將近2200左右的UV，10w左右的PV來訪問我們的系統(tǒng)，而節(jié)假日期間的訪問量基本都會(huì)翻2到3倍。

　　

 

　　從2018年開始使用ClickHouse以來，我們90%的業(yè)務(wù)線都強(qiáng)依賴于ClickHouse，95%左右的接口響應(yīng)時(shí)長都在1s以內(nèi)，ClickHouse強(qiáng)悍的查詢性能得到了充分體現(xiàn)。

　　現(xiàn)在總數(shù)據(jù)行數(shù)大概700億左右，每天有超過2000個(gè)左右的流程，需要更新的數(shù)據(jù)行數(shù)大概有150億左右。

　　未壓縮前的數(shù)據(jù)總?cè)萘浚?T，壓縮后的數(shù)據(jù)總?cè)萘浚?.75T。

　　

 

　　但是ClickHouse無法支持高并發(fā)查詢的缺陷也很明顯，現(xiàn)在CPU大部分情況下消耗是在30%以內(nèi)，不過當(dāng)有用戶大量查詢時(shí)CPU使用率可能就會(huì)被拉的很高。并且如果出現(xiàn)一個(gè)復(fù)雜的高消耗查詢，只靠人工手刷，可能在很短的時(shí)間內(nèi)就可以把40C的CPU使用率打滿：

　　

 

　　工作日的早上9點(diǎn)一般會(huì)有一波訪問高峰，為了保持系統(tǒng)穩(wěn)定，我們采用主動(dòng)建立緩存+用戶被動(dòng)觸發(fā)緩存的機(jī)制來降低ClickHouse服務(wù)器的壓力。

　　一方面我們會(huì)將一些高頻訪問的頁面查詢結(jié)果進(jìn)行緩存。另一方面，在離線數(shù)據(jù)更新完成后，我們通過分析用戶行為數(shù)據(jù)，主動(dòng)給最近5天來訪問過相關(guān)數(shù)據(jù)的用戶緩存默認(rèn)條件的數(shù)據(jù)，降低波峰。

　　現(xiàn)在的主動(dòng)緩存+被動(dòng)緩存取代了原本需要從ClickHouse上很大一部分的查詢量，這樣可以避免我們無限的擴(kuò)容服務(wù)器。同時(shí)也可以把因?yàn)榧胁l(fā)的查詢拉起來的峰刺打平。

　　

 

　　現(xiàn)階段痛點(diǎn)

　　在節(jié)假日期間，實(shí)時(shí)數(shù)據(jù)是關(guān)注的重點(diǎn)，以今年勞動(dòng)節(jié)為例，實(shí)時(shí)看板的訪問量要比平時(shí)高10倍左右。

　　

 

　　工作日期間，CPU使用率一般不會(huì)超過30%。

　　

 

　　節(jié)假日期間，CPU使用率一度超過70%，這對(duì)服務(wù)器的穩(wěn)定性造成了很大隱患。

　　

 

　　面對(duì)這種情況，一方面我們?cè)谇岸俗隽斯?jié)流來防止用戶高頻查詢，同時(shí)在后端也做了緩存，但是實(shí)時(shí)數(shù)據(jù)的緩存時(shí)間不能太久，一般1~2分鐘已經(jīng)是用戶可接受的極限。通過下圖可以發(fā)現(xiàn)，離線數(shù)據(jù)的緩存命中率一般都會(huì)比較高，基本能達(dá)到50%以上甚至更高，但對(duì)于實(shí)時(shí)數(shù)據(jù)，命中率則只有10%左右：

　　

 

　　另一方面，我們?cè)诜?wù)端啟用了分流機(jī)制：實(shí)際應(yīng)用場景中有一些業(yè)務(wù)的權(quán)限比較小，對(duì)應(yīng)需要查詢的數(shù)據(jù)量也會(huì)比較小，我們通過分析定義出了一個(gè)閾值，比如權(quán)限數(shù)小于5000的用戶從MySQL請(qǐng)求數(shù)據(jù)，這部分用戶即使通過MySQL查詢速度也很快。讓權(quán)限大的用戶通過ClickHouse請(qǐng)求數(shù)據(jù)，這樣可以引流很大一部分用戶。

　　

 

　　這樣做雖然暫時(shí)解決了眼下的問題，不過新的問題又接踵而至：

　　·數(shù)據(jù)需要雙寫到ClickHouse和MySQL，無法保證兩邊數(shù)據(jù)的一致性

　　·同時(shí)存在兩套數(shù)據(jù)，導(dǎo)致硬件成本增加

　　·ClickHouse不支持標(biāo)準(zhǔn)SQL語法，所以代碼也需要維護(hù)兩套，開發(fā)成本增加

　　針對(duì)上述問題的挑戰(zhàn)，我們的目標(biāo)是尋求一個(gè)新的OLAP引擎來減少開發(fā)和運(yùn)維成本，同時(shí)還要兼顧查詢性能，并在高并發(fā)和高吞吐的場景下有較好的適用性。

　　為此我們嘗試了一些市面上其他引擎，如Ingite、CrateDB、Kylin等，每種引擎從硬件成本或性能上都有自己特有的優(yōu)勢，不過綜合到使用場景，最終我們選擇了StarRocks。

　　StarRocks介紹

　　·StarRocks是一個(gè)高性能分布式關(guān)系型列式數(shù)據(jù)庫，通過MPP執(zhí)行框架，單節(jié)點(diǎn)每秒可處理多達(dá)100億行數(shù)據(jù)，同時(shí)支持星型模型和雪花模型。

　　·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ū)分桶形成的子表，采用列式存儲(chǔ)。BE受FE指導(dǎo)，創(chuàng)建或刪除子表。

　　·BE接收FE分發(fā)的物理執(zhí)行計(jì)劃并指定BE coordinator節(jié)點(diǎn)，在BE coordinator的調(diào)度下，與其他BE worker共同協(xié)作完成執(zhí)行。

　　·BE讀本地的列存儲(chǔ)引擎，獲取數(shù)據(jù)，通過索引和謂詞下沉快速過濾數(shù)據(jù)。

　　

 

　　我們選擇StarRocks主要基于以下幾方面的考慮：

　　1.亞秒級(jí)查詢延時(shí)

　　2.在高并發(fā)查詢、多表關(guān)聯(lián)等復(fù)雜多維分析場景有良好的性能表現(xiàn)

　　3.支持彈性擴(kuò)展，擴(kuò)容不影響線上業(yè)務(wù)，后臺(tái)自動(dòng)完成數(shù)據(jù)rebalance

　　4.集群中服務(wù)有熱備，多實(shí)例部署，節(jié)點(diǎn)的宕機(jī)、下線、異常都不會(huì)影響集群服務(wù)的整體穩(wěn)定性。

　　5.支持物化視圖和Online Schema Change

　　6.兼容MySQL協(xié)議，支持標(biāo)準(zhǔn)的SQL語法

　　性能測試

　　HData上的數(shù)據(jù)以多表關(guān)聯(lián)為主，在這種場景下，ClickHouse單機(jī)性能相比集群性能要好，因而在這里選取ClickHouse單機(jī)做對(duì)比。下面用3個(gè)測試用例分別對(duì)StarRocks和ClickHouse進(jìn)行對(duì)比，我們用6臺(tái)虛擬機(jī)構(gòu)建成了一個(gè)集群，3臺(tái)FE、BE混部，3臺(tái)BE，機(jī)器配置如下：

　　

 

　　軟件版本：StarRocks標(biāo)準(zhǔn)版1.16.2

　　ClickHouse配置如下：

　　

 

　　軟件版本：ClickHouse20.8

　　

 

　　測試用例1

　　

 

　　·StarRocks用時(shí)：547ms

　　·ClickHouse用時(shí)：1814ms

　　測試用例2

　　

 

　　·StarRocks用時(shí)：126ms

　　·ClickHouse用時(shí)：142ms

　　測試用例3

　　

 

　　·StarRocks用時(shí)：387ms

　　·ClickHouse用時(shí)：884ms

　　可以看到，StarRocks的查詢性能完全不遜色于ClickHouse，甚至更快。

　　數(shù)據(jù)更新機(jī)制

　　StarRocks根據(jù)攝入數(shù)據(jù)和實(shí)際存儲(chǔ)數(shù)據(jù)之間的映射關(guān)系，將數(shù)據(jù)表的明細(xì)表，聚合表和更新表，分別對(duì)應(yīng)有明細(xì)模型，聚合模型和更新模型。

　　·明細(xì)模型：表中存在主鍵重復(fù)的數(shù)據(jù)行，和攝入數(shù)據(jù)行一一對(duì)應(yīng)，用戶可以召回所攝入的全部歷史數(shù)據(jù)。

　　·聚合模型：表中不存在主鍵重復(fù)的數(shù)據(jù)行，攝入的主鍵重復(fù)的數(shù)據(jù)行合并為一行，這些數(shù)據(jù)行的指標(biāo)列通過聚合函數(shù)合并，用戶可以召回所攝入的全部歷史數(shù)據(jù)的累積結(jié)果，但無法召回全部歷史數(shù)據(jù)。

　　·更新模型：聚合模型的特殊情形，主鍵滿足唯一性約束，最近攝入的數(shù)據(jù)行，替換掉其他主鍵重復(fù)的數(shù)據(jù)行。相當(dāng)于在聚合模型中，為數(shù)據(jù)表的指標(biāo)列指定的聚合函數(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進(jìn)程訪問并讀取外部數(shù)據(jù)源，然后采用MySQL協(xié)議向StarRocks創(chuàng)建導(dǎo)入作業(yè)。適用于源數(shù)據(jù)在Broker進(jìn)程可訪問的存儲(chǔ)系統(tǒng)(如HDFS)中。

　　·Spark Load：Spark Load通過Spark資源實(shí)現(xiàn)對(duì)導(dǎo)入數(shù)據(jù)的預(yù)處理，提高StarRocks大數(shù)據(jù)量的導(dǎo)入性能并且節(jié)省StarRocks集群的計(jì)算資源。

　　·Stream Load：Stream Load是一種同步執(zhí)行的導(dǎo)入方式，通過HTTP協(xié)議發(fā)送請(qǐng)求將本地文件或數(shù)據(jù)流導(dǎo)入到StarRocks中，并等待系統(tǒng)返回導(dǎo)入的結(jié)果狀態(tài)，從而判斷導(dǎo)入是否成功。

　　·Routine Load：Routine Load提供了一種自動(dòng)從指定數(shù)據(jù)源進(jìn)行數(shù)據(jù)導(dǎo)入的功能。用戶通過MySQL協(xié)議提交例行導(dǎo)入作業(yè)，生成一個(gè)常駐線程，不間斷的從數(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í)時(shí)數(shù)據(jù)和離線T+1數(shù)據(jù)。

　　實(shí)時(shí)數(shù)據(jù)主要通過Routine load的方式導(dǎo)入，以使用更新模型為主

　　離線T+1數(shù)據(jù)主要使用Zeus平臺(tái)，通過Stream load的方式導(dǎo)入，以使用明細(xì)模型為主

　　

 

　　實(shí)時(shí)數(shù)據(jù)通過攜程自研的消息隊(duì)列系統(tǒng)QMQ實(shí)現(xiàn)，下圖是原先的實(shí)時(shí)數(shù)據(jù)導(dǎo)入流程：

　　

 

　　接入StarRocks后的實(shí)時(shí)數(shù)據(jù)導(dǎo)入流程：

　　

 

　　很快我們就遇到了一個(gè)難題：有一個(gè)場景是訂閱訂單狀態(tài)變化的消息，下游我們以訂單號(hào)作為主鍵，使用更新模型來將數(shù)據(jù)落地。對(duì)外我們提供訂單狀態(tài)為非取消的數(shù)據(jù)進(jìn)行展示。

　　在收到消息后，我們還需要調(diào)用外部接口來補(bǔ)全一些其他字段，最后再把數(shù)據(jù)落地。但如果收到一條消息就調(diào)用一次接口，這么做會(huì)對(duì)接口造成壓力，所以我們采取了批處理的方式。

　　不過這樣做產(chǎn)生了一個(gè)問題：Kafka本身無法保證全局消息是有序的，只能保證partition內(nèi)的有序性。同一個(gè)批次同一個(gè)訂單，但訂單狀態(tài)不同的2條數(shù)據(jù)如果分別落在了不同的partition，routine load時(shí)無法保證哪條數(shù)據(jù)會(huì)先被消費(fèi)。如果訂單狀態(tài)為取消的消息先被消費(fèi)，而其他訂單狀態(tài)的消息后被消費(fèi)，這樣會(huì)造成原本應(yīng)該取消的訂單重新變成了非取消訂單，從而影響統(tǒng)計(jì)的準(zhǔn)確性。

　　我們也考慮過不通過QMQ而改用原生的Kafka，將訂單號(hào)作為key來指定發(fā)送到哪個(gè)partition中，不過這樣做需要二次開發(fā)，而且改動(dòng)的成本也不低。

　　為了解決這個(gè)問題，我們選擇了一個(gè)折中的辦法：在消息落地同時(shí)，又用明細(xì)模型落地了一個(gè)日志表，表里只需要存訂單號(hào)、訂單狀態(tài)以及消息發(fā)送時(shí)間。同時(shí)，有一個(gè)定時(shí)任務(wù)每隔一段時(shí)間會(huì)對(duì)該表內(nèi)相同訂單號(hào)的數(shù)據(jù)進(jìn)行排序，取消息發(fā)送時(shí)間最新的一條數(shù)據(jù)，用訂單號(hào)與正式表中訂單狀態(tài)不一致的數(shù)據(jù)進(jìn)行匹配然后進(jìn)行更新，以這樣的形式對(duì)數(shù)據(jù)進(jìn)行一個(gè)補(bǔ)償。

　　T+1數(shù)據(jù)我們通過攜程自研的數(shù)據(jù)同步平臺(tái)Zeus進(jìn)行ETL和導(dǎo)入：

　　

 

　　DR和高可用

　　攜程對(duì)DR有著很高的要求，每隔一段時(shí)間都會(huì)有公司級(jí)的DR演練。StarRocks本身已經(jīng)具備了十分優(yōu)秀的DR機(jī)制，在此基礎(chǔ)之上，我們構(gòu)建了一套適合自己的高可用體系：

　　·服務(wù)器分別部署在2個(gè)機(jī)房，以5:5的流量對(duì)外提供服務(wù)。對(duì)外提供服務(wù)的FE節(jié)點(diǎn)的負(fù)載均衡以配置項(xiàng)的形式實(shí)現(xiàn)，可以動(dòng)態(tài)修改，實(shí)時(shí)生效(主要是考慮有服務(wù)器打補(bǔ)丁、版本升級(jí)等需要手動(dòng)拉出的情況)。

　　·每個(gè)FE和BE進(jìn)程全部都用supervisor進(jìn)行進(jìn)程守護(hù)，保證進(jìn)程出現(xiàn)意外退出時(shí)可以被自動(dòng)拉起。

　　·當(dāng)FE節(jié)點(diǎn)出現(xiàn)故障時(shí)，存活的follower會(huì)立即選舉出一個(gè)新的leader節(jié)點(diǎn)提供服務(wù)，但是應(yīng)用端卻無法立即感知，為了應(yīng)對(duì)這種情況，我們起了一個(gè)定時(shí)任務(wù)，每隔一段時(shí)間對(duì)FE服務(wù)器進(jìn)行health check，一旦發(fā)現(xiàn)FE節(jié)點(diǎn)故障，則立即將故障節(jié)點(diǎn)拉出集群，同時(shí)以短信方式通知開發(fā)人員。

　　

 

　　·當(dāng)BE節(jié)點(diǎn)出現(xiàn)故障時(shí)，StarRocks內(nèi)部會(huì)自動(dòng)進(jìn)行副本均衡，對(duì)外仍可繼續(xù)提供服務(wù)，同時(shí)我們也會(huì)有一個(gè)定時(shí)任務(wù)對(duì)其進(jìn)行health check，每當(dāng)發(fā)現(xiàn)有BE節(jié)點(diǎn)故障，則會(huì)以郵件形式通知開發(fā)人員。

　　

 

　　·同時(shí)，我們針對(duì)每臺(tái)服務(wù)器的硬件指標(biāo)也配置了告警，通過攜程自研的智能告警中臺(tái)，一旦服務(wù)器的CPU、Mem、磁盤空間等指標(biāo)發(fā)生異常，開發(fā)人員可以立即感知并介入。

　　

 

　　

 

　　總結(jié)和后期規(guī)劃

　　現(xiàn)在HData中70%的實(shí)時(shí)數(shù)據(jù)場景已經(jīng)接入StarRocks，查詢響應(yīng)速度平均在200ms左右，耗時(shí)500ms以上的查詢只占總查詢量的1%;并且數(shù)據(jù)和代碼也只需要維護(hù)一套，人力和硬件成本大大降低。

　　

 

　　

 

　　后期規(guī)劃

　　·將剩余的實(shí)時(shí)場景全部遷入StarRocks。

　　·離線場景也逐漸遷入StarRocks，逐步用StarRocks來統(tǒng)一OLAP分析全場景。

　　·進(jìn)一步完善對(duì)StarRocks的監(jiān)控機(jī)制，使其更健壯。

　　·通過讀取Hive外表的形式做數(shù)據(jù)冷熱分離，減少硬件成本。