作者簡介

?

岳毅，攜程高級研發經理，負責酒店數據智能平臺研發，大數據技術創新工作。喜歡探索研究大數據的開源技術框架。

背景

隨著大數據不斷地融入到工作中，如何使大量的數據資產變現，并提供有價值的見解，通過大量的歷史數據和實時數據作為業務工作的參考預測未來，驅動業務的發展，需要統一數據平臺來滿足用戶工作的需求。

?

一、為什么要做？

平臺建立之前，我們主要依賴各種不同的數據工具來處理團隊數據需求。隨著業務的發展，數據在工作中作用越來越大，但不同工具各自獨立引起的數據問題也越來越嚴重。酒店數據智能平臺的起源，當時主要從以下幾個現實痛點出發：

散：數據分散在不同平臺，沒有地方可以統一查看所有數據；

雜：不同平臺邏輯不同，沒有統一評判標準；

淺：數據明細不夠直觀深入，無法清楚地了解趨勢及問題；

慢：查詢速度慢，臨時取數流程漫長；

晚：當時存在的數據報表平臺都無法實現實時的數據監控，對于業務在工作中，特別是訂單高峰期庫存時刻在變化的時候，不能起到很好的指導和推動作用；

?

下圖是平臺創建之前的工作方式，不同的部門在很多個數據平臺獲取各種數據：

下圖是平臺創建之后，每個部門都用同一份數據，整個平臺的各種指標邏輯統一：

平臺的創建起步數據引擎采用的是多節點SQL服務器為主，ElasticSearch為輔的方式，但同樣遇到了大多數數據平臺的通病，數據量太大，數據表多，查詢性能差，各種問題防不勝防，主要問題集中在以下幾點：

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

2）數據查詢涉及邏輯復雜，單個SQL往往涉及多個表join，以致SQL執行慢，SQL優化難度大；

3）歷史數據更新量大，普通的SQL數據庫數據導入都會存在io瓶頸；

4）搜索條件多，匯總維度不固定，導致很多數據無法更進一步匯總；

5）同時在線用戶量很高，特別是針對業績數據，實時訂單數據和獎金數據等場景是業務非常關心的，所以這些case的并發量非常高；

6）接口性能不穩定，數據更新時接口性能波動大；

?

二、如何做？

2.1 方案選型

針對上述問題，我們需要解決平臺的查詢性能，高并發以及每天大量的數據更新時用戶端應用的高可用，同時我們的性能響應時間指標是pc端小于3秒，app端小于1秒。

為此，我們嘗試了很多種數據庫，考慮過相互之間盡量互補，各取所長。經過多次測試，實踐得出每個數據庫應用于我們場景的結論：

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

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

3）Ingite 雖然也是內存數據庫，但性能在高并發的時候內存會打爆，不能滿足我們的要求，這個是用5臺24G內存的虛擬機測試結果；

4）Presto 查詢時直接讀取hive表，能減少數據同步的流程，降低開發成本，查詢速度勉強能接受，但不能滿足高可用。因此這個只針對我們團隊內部應用場景，不對業務端需求采用該技術方案；

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

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

其他還有Hbase，Kylin，Garuda等等，每個數據庫我們都有搭建環境壓測，每個數據庫從硬件成本，性能上都有自己特有的優勢，綜合到使用場景，暫時最適合我們的還是ClickHouse。

?

2.2 方案落地

ClickHouse在去年的文章《每天十億級數據更新，秒出查詢結果，ClickHouse在攜程酒店的應用》中有介紹，雖然它很快，但也有缺點，特別是高并發場景。只要出現瓶頸會很快出現惡性循環，查詢請求積壓，連接數打滿，cpu使用率直線上升。所以ClickHouse會作為一個主力引擎來承受查詢請求，充分的利用它的優勢，但也需要對它有足夠的保護。

實踐中我們總結了以下方式來優化接口性能同時起到保護ClickHouse的作用：

1）做好查詢監控，針對每個接口，每個查詢語句都能知道查詢消耗時間，case by case優化；

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

3）針對使用率很高數據量又非常大的表，可以創建一個全量表，同時也創建一個只有最近6個月數據的表。因為我們通過埋點發現，90%以上的查詢都主要集中在查最近6個月的數據。所以有90%以上的查詢使用的表數據量遠遠小于全量表，性能會好很多，服務器的開銷也會小很多。當然這個方案也是需要case by case看的，也許某些case用戶訪問量最高的數據集中在最近3個月，可以根據實際情況來定；

4）統計出日常調用量比較大的接口，有針對性的做如下優化：

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

動態緩存：如果數據范圍不固定，但調用量也很大，特別是實時數據，為了ClickHouse的穩定性，也建議增加緩存。我們曾經在這里踩過坑，用戶會用同樣的條件不斷的刷數據，也許他在期待業績數據的變化，遇到高并發的時候會把ClickHouse服務器CPU打滿。實際上通過埋點發現，哪怕緩存時間只有3分鐘也可以降低50%以上的ClickHouse查詢請求。

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

2.3 高可用

數據平臺每天都有大量的數據更新，如何保證線上幾百個接口不會隨著數據量的增加性能降低，如何保證2000多個數據流程準點更新完數據，如何保證平臺的高可用，下面是我們針對一些潛在問題的監控和解決方案：

1）流程監控機制：當前整個平臺100多億的數據量，每天需要更新幾十億的歷史數據，2000多個數據更新流程，我們需要保證數據每天能按時更新到ClickHouse中，所以我們做了很多監控。包括最晚截止時間未執行的預警，數據量不一致的預警，ClickHouse數據切換異常預警，都會通過oncall電話或者手機短信通知到我們。

2）當某一個節點出現問題的時候，能將查詢請求快速轉移到健康的服務器上，對于redis/mysql/es我們公司有健全的DR機制和故障轉移機制。對于ClickHouse，我們是將不同的機房服務器構建成虛擬集群，比如A機房一臺服務器與B機房一臺服務器構建成一個集群，通過程序控制將查詢請求打散分布到兩臺服務器上實現負載均衡。如果A機房有異常或者某一臺服務器有異常，只需要配置對應的虛擬集群把對應機器設置下線后人工介入處理。

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

4）需要有數據校驗機制，因為DR機制我們的數據是多寫，可能會因為某次網絡異常引發兩邊數據不一致的情況。雖然這種概率很低，但有了校驗機制可以及時發現并解決這類問題。

5）異常預警：上線的每一個功能，所有報錯都會發郵件通知整個開發組。這樣就需要控制程序中的每一個異常，每個報錯都需要case by case分析并解決掉，同時也需要對我們自己的開發質量有足夠的信心。

?

2.4 架構和結果

下面是系統架構圖：

?

?

現在整個平臺架構由多個虛擬集群組成，隨著業務量的增長或者某個集群出現負載壓力，可以動態配置新的虛擬集群無限橫向擴展滿足業務增長需求，也可以將資源利用率低的A集群中的服務器拉入B集群同時分擔A，B集群流量。

現在總平臺數據量是100多億，每天有2000多個數據流程運行，需要更新歷史數據幾十億。工作日平臺每天有2000多在線用戶，50多萬次的數據查詢，調用ClickHouse的次數達到了300多萬次。每天有40%左右的請求主要落在數據量比較大的業績數據，用戶行為表上，都是好幾億級業務數據需要join幾千萬的權限表加千萬級的信息表實時計算。

通過下圖的監控統計截圖可以看到，平臺接口1s內響應時間占比在不斷提高，超過1s的請求經過優化后占比也是不斷的降低。

	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%

上面主要是從服務端介紹了整個系統，其實從前端我們也做了很多工作，因為純數據的呈現可能會讓人覺得枯燥，或者無法直觀的從數據中發現問題。

1）整個平臺無論多少功能，所有頁面加載采用異步請求。用戶在瀏覽任何頁面時，系統不會出現白屏式頁面刷新，主要是為了避免用戶在關注某個數據的時候因為頁面刷新而影響到用戶分析數據的思路。

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

?

三、后期規劃

本文主要介紹如何解決數據可視化平臺的性能問題，如何保證數據產品的高可用，以及從技術角度如何讓數據更直觀。2019年我們的主要側重點是將sql上的數據遷移到clickhouse并優化查詢性能，現在90%以上的數據都在clickhouse上，而es，redis，mysql都是在不同的case輔助clickhouse，性能和穩定性有了較大的提升。

今年持續監控，優化性能，同時關注點會適當的下沉到dw，一起完善可視化的上游流程依賴，盡可能的使整個數據生態鏈更簡潔，運行更快更穩定。同時完善平臺功能，打通與其他系統之間的交互，加強數據系統與業務系統的關聯，通過不斷的完善提升數據對業務的幫助。

猜你喜歡

1、Spark 3.0 終于支持 event logs 滾動了

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

3、Delta Lake、Iceberg 和 Hudi 三大開源數據湖不知道如何選？那是因為你沒看這篇文章

4、濃縮精華的架構演進過程，我連看了八遍！

過往記憶大數據微信群，請添加微信：fangzhen0219,備注【進群】

總結

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

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。