作者簡介

?

岳毅，攜程高級(jí)研發(fā)經(jīng)理，負(fù)責(zé)酒店數(shù)據(jù)智能平臺(tái)研發(fā)，大數(shù)據(jù)技術(shù)創(chuàng)新工作。喜歡探索研究大數(shù)據(jù)的開源技術(shù)框架。

背景

隨著大數(shù)據(jù)不斷地融入到工作中，如何使大量的數(shù)據(jù)資產(chǎn)變現(xiàn)，并提供有價(jià)值的見解，通過大量的歷史數(shù)據(jù)和實(shí)時(shí)數(shù)據(jù)作為業(yè)務(wù)工作的參考預(yù)測未來，驅(qū)動(dòng)業(yè)務(wù)的發(fā)展，需要統(tǒng)一數(shù)據(jù)平臺(tái)來滿足用戶工作的需求。

?

一、為什么要做？

平臺(tái)建立之前，我們主要依賴各種不同的數(shù)據(jù)工具來處理團(tuán)隊(duì)數(shù)據(jù)需求。隨著業(yè)務(wù)的發(fā)展，數(shù)據(jù)在工作中作用越來越大，但不同工具各自獨(dú)立引起的數(shù)據(jù)問題也越來越嚴(yán)重。酒店數(shù)據(jù)智能平臺(tái)的起源，當(dāng)時(shí)主要從以下幾個(gè)現(xiàn)實(shí)痛點(diǎn)出發(fā)：

散：數(shù)據(jù)分散在不同平臺(tái)，沒有地方可以統(tǒng)一查看所有數(shù)據(jù)；

雜：不同平臺(tái)邏輯不同，沒有統(tǒng)一評(píng)判標(biāo)準(zhǔn)；

淺：數(shù)據(jù)明細(xì)不夠直觀深入，無法清楚地了解趨勢及問題；

慢：查詢速度慢，臨時(shí)取數(shù)流程漫長；

晚：當(dāng)時(shí)存在的數(shù)據(jù)報(bào)表平臺(tái)都無法實(shí)現(xiàn)實(shí)時(shí)的數(shù)據(jù)監(jiān)控，對(duì)于業(yè)務(wù)在工作中，特別是訂單高峰期庫存時(shí)刻在變化的時(shí)候，不能起到很好的指導(dǎo)和推動(dòng)作用；

?

下圖是平臺(tái)創(chuàng)建之前的工作方式，不同的部門在很多個(gè)數(shù)據(jù)平臺(tái)獲取各種數(shù)據(jù)：

下圖是平臺(tái)創(chuàng)建之后，每個(gè)部門都用同一份數(shù)據(jù)，整個(gè)平臺(tái)的各種指標(biāo)邏輯統(tǒng)一：

平臺(tái)的創(chuàng)建起步數(shù)據(jù)引擎采用的是多節(jié)點(diǎn)SQL服務(wù)器為主，ElasticSearch為輔的方式，但同樣遇到了大多數(shù)數(shù)據(jù)平臺(tái)的通病，數(shù)據(jù)量太大，數(shù)據(jù)表多，查詢性能差，各種問題防不勝防，主要問題集中在以下幾點(diǎn)：

1）數(shù)據(jù)量日積月累越來越大，哪怕sharding也很難實(shí)現(xiàn)到查詢秒出，并且硬件成本和程序復(fù)雜度都很高；

2）數(shù)據(jù)查詢涉及邏輯復(fù)雜，單個(gè)SQL往往涉及多個(gè)表join，以致SQL執(zhí)行慢，SQL優(yōu)化難度大；

3）歷史數(shù)據(jù)更新量大，普通的SQL數(shù)據(jù)庫數(shù)據(jù)導(dǎo)入都會(huì)存在io瓶頸；

4）搜索條件多，匯總維度不固定，導(dǎo)致很多數(shù)據(jù)無法更進(jìn)一步匯總；

5）同時(shí)在線用戶量很高，特別是針對(duì)業(yè)績數(shù)據(jù)，實(shí)時(shí)訂單數(shù)據(jù)和獎(jiǎng)金數(shù)據(jù)等場景是業(yè)務(wù)非常關(guān)心的，所以這些case的并發(fā)量非常高；

6）接口性能不穩(wěn)定，數(shù)據(jù)更新時(shí)接口性能波動(dòng)大；

?

二、如何做？

2.1 方案選型

針對(duì)上述問題，我們需要解決平臺(tái)的查詢性能，高并發(fā)以及每天大量的數(shù)據(jù)更新時(shí)用戶端應(yīng)用的高可用，同時(shí)我們的性能響應(yīng)時(shí)間指標(biāo)是pc端小于3秒，app端小于1秒。

為此，我們嘗試了很多種數(shù)據(jù)庫，考慮過相互之間盡量互補(bǔ)，各取所長。經(jīng)過多次測試，實(shí)踐得出每個(gè)數(shù)據(jù)庫應(yīng)用于我們場景的結(jié)論：

1）ClickHouse 查詢速度快，但無法承受高并發(fā)；

2）ElasticSearch 查詢速度快，cpu消耗到60%對(duì)查詢性能不會(huì)有太大的影響，但不能做多表join，大寬表維護(hù)成本不現(xiàn)實(shí)，約束了我們的使用場景；

3）Ingite 雖然也是內(nèi)存數(shù)據(jù)庫，但性能在高并發(fā)的時(shí)候內(nèi)存會(huì)打爆，不能滿足我們的要求，這個(gè)是用5臺(tái)24G內(nèi)存的虛擬機(jī)測試結(jié)果；

4）Presto 查詢時(shí)直接讀取hive表，能減少數(shù)據(jù)同步的流程，降低開發(fā)成本，查詢速度勉強(qiáng)能接受，但不能滿足高可用。因此這個(gè)只針對(duì)我們團(tuán)隊(duì)內(nèi)部應(yīng)用場景，不對(duì)業(yè)務(wù)端需求采用該技術(shù)方案；

5）CrateDB底層沿用了ElasticSearch的源碼，支持SQL語法，比ElasticSearch的使用更友好，也解決了es不能join的問題，但在多表join的場景qps達(dá)到20個(gè)左右內(nèi)存就會(huì)被打爆（6臺(tái)8核24G內(nèi)存虛擬機(jī)測試場景），單表查詢性能和高并發(fā)支撐還是可以的；

6）MongoDB 走索引查詢速度非常快，但太依賴左側(cè)原則，也不能join，只能通過嵌套文檔的方案解決join的問題，但我們的查詢條件太多，不能強(qiáng)依賴左側(cè)原則來查詢；

其他還有Hbase，Kylin，Garuda等等，每個(gè)數(shù)據(jù)庫我們都有搭建環(huán)境壓測，每個(gè)數(shù)據(jù)庫從硬件成本，性能上都有自己特有的優(yōu)勢，綜合到使用場景，暫時(shí)最適合我們的還是ClickHouse。

?

2.2 方案落地

ClickHouse在去年的文章《每天十億級(jí)數(shù)據(jù)更新，秒出查詢結(jié)果，ClickHouse在攜程酒店的應(yīng)用》中有介紹，雖然它很快，但也有缺點(diǎn)，特別是高并發(fā)場景。只要出現(xiàn)瓶頸會(huì)很快出現(xiàn)惡性循環(huán)，查詢請(qǐng)求積壓，連接數(shù)打滿，cpu使用率直線上升。所以ClickHouse會(huì)作為一個(gè)主力引擎來承受查詢請(qǐng)求，充分的利用它的優(yōu)勢，但也需要對(duì)它有足夠的保護(hù)。

實(shí)踐中我們總結(jié)了以下方式來優(yōu)化接口性能同時(shí)起到保護(hù)ClickHouse的作用：

1）做好查詢監(jiān)控，針對(duì)每個(gè)接口，每個(gè)查詢語句都能知道查詢消耗時(shí)間，case by case優(yōu)化；

2）所有數(shù)據(jù)查詢請(qǐng)求拆成異步請(qǐng)求，避免大接口中數(shù)據(jù)請(qǐng)求等待的過程影響數(shù)據(jù)展示的速度；

3）針對(duì)使用率很高數(shù)據(jù)量又非常大的表，可以創(chuàng)建一個(gè)全量表，同時(shí)也創(chuàng)建一個(gè)只有最近6個(gè)月數(shù)據(jù)的表。因?yàn)槲覀兺ㄟ^埋點(diǎn)發(fā)現(xiàn)，90%以上的查詢都主要集中在查最近6個(gè)月的數(shù)據(jù)。所以有90%以上的查詢使用的表數(shù)據(jù)量遠(yuǎn)遠(yuǎn)小于全量表，性能會(huì)好很多，服務(wù)器的開銷也會(huì)小很多。當(dāng)然這個(gè)方案也是需要case by case看的，也許某些case用戶訪問量最高的數(shù)據(jù)集中在最近3個(gè)月，可以根據(jù)實(shí)際情況來定；

4）統(tǒng)計(jì)出日常調(diào)用量比較大的接口，有針對(duì)性的做如下優(yōu)化：

固定緩存：如果數(shù)據(jù)固定范圍或者對(duì)于訪問量高的頁面默認(rèn)查詢條件，數(shù)據(jù)當(dāng)天更新后由job觸發(fā)主動(dòng)模擬用戶查詢，提前為用戶把數(shù)據(jù)緩存到redis中。用戶在上班時(shí)間段查詢就會(huì)從redis中拿數(shù)據(jù)，性能提高了，ClickHouse的壓力也降低了，也避免了用戶高峰期間集中查詢對(duì)ClickHouse服務(wù)器的沖擊。

動(dòng)態(tài)緩存：如果數(shù)據(jù)范圍不固定，但調(diào)用量也很大，特別是實(shí)時(shí)數(shù)據(jù)，為了ClickHouse的穩(wěn)定性，也建議增加緩存。我們?cè)?jīng)在這里踩過坑，用戶會(huì)用同樣的條件不斷的刷數(shù)據(jù)，也許他在期待業(yè)績數(shù)據(jù)的變化，遇到高并發(fā)的時(shí)候會(huì)把ClickHouse服務(wù)器CPU打滿。實(shí)際上通過埋點(diǎn)發(fā)現(xiàn)，哪怕緩存時(shí)間只有3分鐘也可以降低50%以上的ClickHouse查詢請(qǐng)求。

分流機(jī)制：ClickHouse主要是解決我們大表join查詢性能，實(shí)際應(yīng)用中可以將一些場景拆解，比如一些一線業(yè)務(wù)的權(quán)限比較小，對(duì)應(yīng)權(quán)限的酒店數(shù)據(jù)量也會(huì)比較小。我們可以定義一個(gè)閥值，比如小于5000或者8000的數(shù)據(jù)走mysql，這部分人走mysql速度也會(huì)很快，讓權(quán)限大的用戶走ClickHouse，這樣會(huì)引流很大一部分用戶，提升整個(gè)平臺(tái)的查詢性能。

2.3 高可用

數(shù)據(jù)平臺(tái)每天都有大量的數(shù)據(jù)更新，如何保證線上幾百個(gè)接口不會(huì)隨著數(shù)據(jù)量的增加性能降低，如何保證2000多個(gè)數(shù)據(jù)流程準(zhǔn)點(diǎn)更新完數(shù)據(jù)，如何保證平臺(tái)的高可用，下面是我們針對(duì)一些潛在問題的監(jiān)控和解決方案：

1）流程監(jiān)控機(jī)制：當(dāng)前整個(gè)平臺(tái)100多億的數(shù)據(jù)量，每天需要更新幾十億的歷史數(shù)據(jù)，2000多個(gè)數(shù)據(jù)更新流程，我們需要保證數(shù)據(jù)每天能按時(shí)更新到ClickHouse中，所以我們做了很多監(jiān)控。包括最晚截止時(shí)間未執(zhí)行的預(yù)警，數(shù)據(jù)量不一致的預(yù)警，ClickHouse數(shù)據(jù)切換異常預(yù)警，都會(huì)通過oncall電話或者手機(jī)短信通知到我們。

2）當(dāng)某一個(gè)節(jié)點(diǎn)出現(xiàn)問題的時(shí)候，能將查詢請(qǐng)求快速轉(zhuǎn)移到健康的服務(wù)器上，對(duì)于redis/mysql/es我們公司有健全的DR機(jī)制和故障轉(zhuǎn)移機(jī)制。對(duì)于ClickHouse，我們是將不同的機(jī)房服務(wù)器構(gòu)建成虛擬集群，比如A機(jī)房一臺(tái)服務(wù)器與B機(jī)房一臺(tái)服務(wù)器構(gòu)建成一個(gè)集群，通過程序控制將查詢請(qǐng)求打散分布到兩臺(tái)服務(wù)器上實(shí)現(xiàn)負(fù)載均衡。如果A機(jī)房有異常或者某一臺(tái)服務(wù)器有異常，只需要配置對(duì)應(yīng)的虛擬集群把對(duì)應(yīng)機(jī)器設(shè)置下線后人工介入處理。

3）需要有風(fēng)險(xiǎn)意識(shí)，由監(jiān)控抓出對(duì)服務(wù)器CPU/IO消耗大的查詢語句或者數(shù)據(jù)流程。當(dāng)服務(wù)器CPU使用率突然增加20%或者服務(wù)器CPU持續(xù)消耗超過20%，我們都會(huì)抓出當(dāng)前正在執(zhí)行的語句同時(shí)發(fā)出預(yù)警郵件，類似于dump做事后分析。同時(shí)開發(fā)過程中每個(gè)人都需要有意識(shí)的關(guān)注每個(gè)功能的數(shù)據(jù)量，當(dāng)遇到數(shù)據(jù)量大或者訪問量大的復(fù)雜需求，需要做好緩存，埋點(diǎn)監(jiān)控以及降級(jí)方案。

4）需要有數(shù)據(jù)校驗(yàn)機(jī)制，因?yàn)镈R機(jī)制我們的數(shù)據(jù)是多寫，可能會(huì)因?yàn)槟炒尉W(wǎng)絡(luò)異常引發(fā)兩邊數(shù)據(jù)不一致的情況。雖然這種概率很低，但有了校驗(yàn)機(jī)制可以及時(shí)發(fā)現(xiàn)并解決這類問題。

5）異常預(yù)警：上線的每一個(gè)功能，所有報(bào)錯(cuò)都會(huì)發(fā)郵件通知整個(gè)開發(fā)組。這樣就需要控制程序中的每一個(gè)異常，每個(gè)報(bào)錯(cuò)都需要case by case分析并解決掉，同時(shí)也需要對(duì)我們自己的開發(fā)質(zhì)量有足夠的信心。

?

2.4 架構(gòu)和結(jié)果

下面是系統(tǒng)架構(gòu)圖：

?

?

現(xiàn)在整個(gè)平臺(tái)架構(gòu)由多個(gè)虛擬集群組成，隨著業(yè)務(wù)量的增長或者某個(gè)集群出現(xiàn)負(fù)載壓力，可以動(dòng)態(tài)配置新的虛擬集群無限橫向擴(kuò)展?jié)M足業(yè)務(wù)增長需求，也可以將資源利用率低的A集群中的服務(wù)器拉入B集群同時(shí)分擔(dān)A，B集群流量。

現(xiàn)在總平臺(tái)數(shù)據(jù)量是100多億，每天有2000多個(gè)數(shù)據(jù)流程運(yùn)行，需要更新歷史數(shù)據(jù)幾十億。工作日平臺(tái)每天有2000多在線用戶，50多萬次的數(shù)據(jù)查詢，調(diào)用ClickHouse的次數(shù)達(dá)到了300多萬次。每天有40%左右的請(qǐng)求主要落在數(shù)據(jù)量比較大的業(yè)績數(shù)據(jù)，用戶行為表上，都是好幾億級(jí)業(yè)務(wù)數(shù)據(jù)需要join幾千萬的權(quán)限表加千萬級(jí)的信息表實(shí)時(shí)計(jì)算。

通過下圖的監(jiān)控統(tǒng)計(jì)截圖可以看到，平臺(tái)接口1s內(nèi)響應(yīng)時(shí)間占比在不斷提高，超過1s的請(qǐng)求經(jīng)過優(yōu)化后占比也是不斷的降低。

	2019/5/3	2019/8/3	2019/12/3
<1s占比	75.14%	82.25%	93.33%
1s到3s	24.15%	17.28%	6.43%
超過3s	0.71%	0.47%	0.24%

上面主要是從服務(wù)端介紹了整個(gè)系統(tǒng)，其實(shí)從前端我們也做了很多工作，因?yàn)榧償?shù)據(jù)的呈現(xiàn)可能會(huì)讓人覺得枯燥，或者無法直觀的從數(shù)據(jù)中發(fā)現(xiàn)問題。

1）整個(gè)平臺(tái)無論多少功能，所有頁面加載采用異步請(qǐng)求。用戶在瀏覽任何頁面時(shí)，系統(tǒng)不會(huì)出現(xiàn)白屏式頁面刷新，主要是為了避免用戶在關(guān)注某個(gè)數(shù)據(jù)的時(shí)候因?yàn)轫撁嫠⑿露绊懙接脩舴治鰯?shù)據(jù)的思路。

2）如何讓用戶在茫茫的數(shù)據(jù)海洋中高效的找到關(guān)鍵數(shù)據(jù)，我們集成了第三方插件做出一些新穎的圖像，宏觀的分析數(shù)據(jù)趨勢以及關(guān)鍵類型的匯總占比，讓用戶通過圖形展示能更加直觀快速得到數(shù)據(jù)信息。同時(shí)我們修改了echart和highchart相關(guān)插件源碼，自定義默認(rèn)的顏色體系，自定義指標(biāo)的刻度值，通過這些前端的修改，可以提高前端視覺體驗(yàn)。也針對(duì)常用圖形控件做了一層封裝，提高前端的開發(fā)效率，降低了開發(fā)人員前端技能門檻。

?

三、后期規(guī)劃

本文主要介紹如何解決數(shù)據(jù)可視化平臺(tái)的性能問題，如何保證數(shù)據(jù)產(chǎn)品的高可用，以及從技術(shù)角度如何讓數(shù)據(jù)更直觀。2019年我們的主要側(cè)重點(diǎn)是將sql上的數(shù)據(jù)遷移到clickhouse并優(yōu)化查詢性能，現(xiàn)在90%以上的數(shù)據(jù)都在clickhouse上，而es，redis，mysql都是在不同的case輔助clickhouse，性能和穩(wěn)定性有了較大的提升。

今年持續(xù)監(jiān)控，優(yōu)化性能，同時(shí)關(guān)注點(diǎn)會(huì)適當(dāng)?shù)南鲁恋絛w，一起完善可視化的上游流程依賴，盡可能的使整個(gè)數(shù)據(jù)生態(tài)鏈更簡潔，運(yùn)行更快更穩(wěn)定。同時(shí)完善平臺(tái)功能，打通與其他系統(tǒng)之間的交互，加強(qiáng)數(shù)據(jù)系統(tǒng)與業(yè)務(wù)系統(tǒng)的關(guān)聯(lián)，通過不斷的完善提升數(shù)據(jù)對(duì)業(yè)務(wù)的幫助。

猜你喜歡

1、Spark 3.0 終于支持 event logs 滾動(dòng)了

2、Java 14 將于3月17日正式發(fā)布，包含大量減少代碼冗余的新特性

3、Delta Lake、Iceberg 和 Hudi 三大開源數(shù)據(jù)湖不知道如何選？那是因?yàn)槟銢]看這篇文章

4、濃縮精華的架構(gòu)演進(jìn)過程，我連看了八遍！

過往記憶大數(shù)據(jù)微信群，請(qǐng)?zhí)砑游⑿?#xff1a;fangzhen0219,備注【進(jìn)群】

總結(jié)

以上是生活随笔為你收集整理的100亿+数据量，每天50W+查询，携程酒店数据智能平台实践的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。