?一、引言

通過 BI 平臺取數(shù)、看數(shù)、分析數(shù)成為輔助決策、精細運營等非常重要的手段，然而隨著去哪兒網(wǎng)業(yè)務不斷發(fā)展，產(chǎn)品、運營等同學對這方面有更高的要求，例如簡單易用的拖拽式報表、取數(shù)方便的自由式分析、查詢速度的秒級響應、觀測指標數(shù)據(jù)的準確可信等等。

面對用戶的個性化訴求以及海量數(shù)據(jù)，在平臺體系化建設(shè)和技術(shù)實現(xiàn)上有一定的挑戰(zhàn)性，本文將介紹去哪兒網(wǎng)BI平臺的建設(shè)歷程及實踐，通過打造全場景的BI平臺為業(yè)務增長賦能。

二、建設(shè)歷程

從2015年至今BI平臺的建設(shè)，經(jīng)歷了多年迭代發(fā)展，始終結(jié)合業(yè)務需要遵循以下幾個原則：

用戶盡可能的自助完成，使開發(fā)同學盡可能少的介入，即提升取數(shù)看數(shù)分析數(shù)效率；

• 平臺功能上，操作方便門檻要低、取數(shù)方式要豐富，即提升平臺易用性；

• 系統(tǒng)性能上，查詢速度要快，即提升查詢性能；

• 數(shù)據(jù)指標準確可信，即提升數(shù)據(jù)可信度。

BI 平臺建設(shè)時間線如上圖，根據(jù)實際業(yè)務需要上線相應模塊，總體大致分為三個階段：

• 原始階段，2016年之前，一路到底式的報表系統(tǒng) V1 ；

• 發(fā)展階段，2016年—2018年，配置式的報表系統(tǒng) V2 、自助分析、 OLAP ；

• 體系建設(shè)階段，2019年—至今，即席查詢、自助郵件報表、數(shù)據(jù)報表系統(tǒng) V3 、 OLAP(CRM) ；子系統(tǒng)互聯(lián)互通、全面對接指標系統(tǒng)建設(shè)標準化指標。

后續(xù)將詳細介紹每個階段的痛點和解決方案。

?1、原始階段

關(guān)鍵詞：一路到底式、數(shù)據(jù)體量小、快速完成需求開發(fā)

原始時期，業(yè)務處于快速發(fā)展階段，公司絕大多數(shù)的精力在業(yè)務上，用戶的取數(shù)看數(shù)分析數(shù)訴求基本依賴數(shù)據(jù)部門排期開發(fā)的報表，為滿足這種大量的數(shù)據(jù)需求，全部數(shù)據(jù)開發(fā)資源投入業(yè)務需求，進行一路到底式的報表開發(fā)，從收集解析日志、ETL、導數(shù)、寫報表平臺前后端等，如下圖所示。

• 通過 Hive 解析日志，進行 ETL ，按業(yè)務邏輯將計算結(jié)果導出到關(guān)系型數(shù)據(jù)庫 MySQL ；

• 報表系統(tǒng)的工程里寫后端邏輯從 MySQL 數(shù)據(jù)庫里查詢；

• 寫前端頁面實現(xiàn)各種個性化的圖和表來展示數(shù)據(jù)。

這種方式屬于初級階段，還談不上平臺建設(shè)，雖能以快速滿足業(yè)務需求為目的但也暴露出很多問題：

• 這種一路到底式的開發(fā)模式，導致消化需求并沒有想象中的迅速，反而效率低，而且代碼風格不一質(zhì)量不一；

• 每個需求有自己的個性，同樣也有共性，結(jié)果是無論數(shù)據(jù)還是圖表，出現(xiàn)大量的個性化而且互相冗余。

總結(jié)后我們發(fā)現(xiàn)，業(yè)務的快速發(fā)展不是借口，這種方式并不快而是痛苦，亟需明確分工，通過平臺建設(shè)將大量堆積的數(shù)據(jù)需求轉(zhuǎn)化成用戶部分自助。

?2、發(fā)展階段

關(guān)鍵詞：分工明確、部分自助

隨著業(yè)務和數(shù)據(jù)團隊的發(fā)展，數(shù)據(jù)倉庫和數(shù)據(jù)平臺建設(shè)同樣重要，從此分化兩個方向，一個是偏向于業(yè)務數(shù)據(jù)的團隊，可以將更多的精力放在業(yè)務和數(shù)據(jù)本身以及數(shù)倉模型建設(shè)上；另一個是偏向于數(shù)據(jù)平臺的團隊，將報表、權(quán)限等等系統(tǒng)重構(gòu)并專門負責，有利于將數(shù)據(jù)平臺建設(shè)得更加易用，提升用戶取數(shù)看數(shù)分析數(shù)效率。因此此階段除了重構(gòu)報表系統(tǒng)將報表的配置工作交給用戶外，還搭建了自助數(shù)據(jù)分析系統(tǒng)和 OLAP 系統(tǒng)，進一步提升取數(shù)看數(shù)分析數(shù)的自助率。

1）報表系統(tǒng) V2

• 數(shù)據(jù)開發(fā)同學根據(jù)需求將數(shù)倉最終產(chǎn)出的 ADS 層數(shù)據(jù)導入 PostgreSQL ，這里用到 PostgreSQL 是因為其有豐富的分析函數(shù)，在統(tǒng)計方面效率表現(xiàn)很好；

• 產(chǎn)品等用戶首先配置維度、指標和篩選項作為數(shù)據(jù)單元，此數(shù)據(jù)單元可在不同報表中復用，然后在報表中引用后，發(fā)布成最終的報表展示數(shù)據(jù)。

2）自助數(shù)據(jù)分析

①場景痛點

• 報表系統(tǒng)引入的是數(shù)倉 ADS 層數(shù)據(jù)表，是固化口徑計算好的結(jié)果，然而并不能很好得支持多樣的分析場景；

• 從 DWD 到 ADS 的過程需要數(shù)據(jù)開發(fā)同學排期完成，對于不會寫 SQL 的產(chǎn)品運營同學，臨時性、靈活且簡單的聚合分析想獲取數(shù)據(jù)，需要提需求，周期太長，如果能夠基于 DWD 明細數(shù)據(jù)，用戶直接自由分析可以很大程度提升數(shù)據(jù)分析效率，數(shù)據(jù)開發(fā)同學也能從瑣碎的數(shù)據(jù)需求中釋放；

• 規(guī)范化埋點的實時數(shù)據(jù)（包括行為和訂單數(shù)據(jù)），也需要數(shù)據(jù)開發(fā)同學排期做實時 ETL ，是否可以做到全程自動化，在平臺上能分析實時的埋點數(shù)據(jù)。

如下圖的界面功能是從 SQL 語法中抽象而來，用戶只需點選即可自助完成常規(guī)的聚合查詢分析。

②整體架構(gòu)

結(jié)合實際痛點分析出有以下必要的訴求點：

• 需要支持實時數(shù)據(jù)插入、更新和讀取

• 需要支持直接讀取離線數(shù)倉表和實時數(shù)據(jù)表，查看截止到當前時刻時間段的數(shù)據(jù)，而且需要支持表關(guān)聯(lián)進行分析

• 自助分析需要對多個維度指標查詢，且需較快的響應

針對同時查離線和實時數(shù)據(jù)的訴求，首先得有個統(tǒng)一的查詢?nèi)肟?，然后對億級別以內(nèi)量級的數(shù)據(jù)做數(shù)據(jù)分析要保障效率，由此可以想到 Impala+Kudu 和 Impala+HDFS（ Parquet ）組合（ Kudu 只存當天的實時數(shù)據(jù)，離線數(shù)據(jù)從原有的 HDFS 上讀?。＿@個方案相對把兩類數(shù)據(jù)都導入到某個其他引擎中，從存儲和實現(xiàn)成本上是較小的。

Apache Kudu 是介于 Hadoop 和 Hbase 之間的，既能滿足高吞吐量的數(shù)據(jù)分析需求又能滿足快速的數(shù)據(jù)隨機讀寫需求?；?Impala 和 Kudu 的系統(tǒng)架構(gòu)圖如下：

• 數(shù)據(jù)寫入過程

• 離線數(shù)據(jù)無需寫入，數(shù)據(jù)存在 HDFS 上，Impala 連 Hive 可直接讀表查詢，減少離線數(shù)據(jù)處理環(huán)節(jié)節(jié)省成本，這也是選擇 Impala 的原因之一；
• 實時數(shù)據(jù)來源包括實時數(shù)倉、規(guī)范化埋點實時數(shù)據(jù)等，通過 Kafka 由 Flink 實時寫入 Kudu 表作為熱數(shù)據(jù)，同時寫一份到 HDFS 做為冷數(shù)據(jù)和備份；

• 在 Hive 表和 Kudu 表基礎(chǔ)上建 Impala 視圖，將離線和實時數(shù)據(jù)表 Union 在一起，以供查詢。

• 數(shù)據(jù)讀取過程

• 用戶在分析頁面選擇維度分組、篩選條件、統(tǒng)計周期、指標運算等點擊查詢；

• 查詢模塊首先從緩存中取，如果是重復請求直接返回，如果不是則解析請求參數(shù)，拼接查詢Impala的SQL；

• 對于多指標分析，為提升整體查詢效率，拆分成多條SQL并行執(zhí)行；

• 對于跨多天的非去重查詢，將查詢結(jié)果按天存為碎片緩存，減少后續(xù)的重復查詢，提升查詢效率；

• 將查詢Impala的數(shù)據(jù)和從碎片緩存取出來的數(shù)據(jù)，合并后返回到頁面展示。

3）實時OLAP

業(yè)務上出現(xiàn)了兩個典型的 OLAP 場景，一個是收益團隊需要對歷史全量訂單，億級別的數(shù)據(jù)量進行全維度分析后制定策略，待策略上線后，再進行實時監(jiān)控成單收益效果，通過多維分析定位到具體哪個渠道、城市、星級等等維度效果不佳，指導及時調(diào)整策略。

另一個是酒店業(yè)務團隊，我們知道用戶預定酒店的過程中涉及搜索、列表頁、詳情頁、預定頁、成單等主要環(huán)節(jié)，需要針對各個階段的業(yè)務系統(tǒng)進行實時順暢度監(jiān)控，就是將用戶每次請求在各個階段的順暢度情況實時收集，這個數(shù)據(jù)量是億級別的，然后進行多維統(tǒng)計分析和實時監(jiān)控，有問題能夠及時告警甚至需要阻斷發(fā)布和自動報故障，輔助業(yè)務團隊定位問題解決問題，提升用戶在預定酒店過程的體驗感受。

從這些場景中可以提煉出一些關(guān)鍵點：數(shù)據(jù)實時性要求高，數(shù)據(jù)量為億級別，維度指標上百個，數(shù)據(jù)存儲適合大寬表，查詢要秒級響應。

①計算引擎

為滿足上述訴求OLAP引擎的選擇是關(guān)鍵，我們對比當時常用的引擎如下：

• Kylin在十幾個維度情況下與Druid是差不多的，但我們遇到的場景是幾十個維度，Kylin的Cube膨脹率很高，查詢性能也達不到預期；再一個業(yè)務需求變化得重建Cube不夠靈活，Kylin比較適合固定20個維度內(nèi)，且業(yè)務邏輯計算很復雜需要預計算的場景；

• Presto不支持實時數(shù)據(jù)，且秒級的交互式查詢也滿足不了；

• ES在億級別數(shù)據(jù)量下多維分析查詢性能不佳，寫入效率也不高；

• Kudu+Impala方案看起來比較合適，但當前需求不關(guān)心數(shù)據(jù)更新，更多關(guān)注的是在億級別的數(shù)據(jù)量之下查詢響應的時長。

通過多種維度的比較，我們最終選擇了能支撐億級別數(shù)據(jù)量、支持實時數(shù)據(jù)、在近百個維度指標情況下查詢性能依然很高的Apache Druid，來支撐這類實時 OLAP 場景。

②數(shù)據(jù)可視化

數(shù)據(jù)可視化方面選擇開源的 Superset ，主要原因是其深度支持 Apache Druid，并支持其他眾多數(shù)據(jù)源，能很好的兼容歷史數(shù)據(jù)。Superset 具有較強的數(shù)據(jù)分析能力，且有豐富的可視化圖表類型，另外也支持將圖表配置成數(shù)據(jù)看板，將固化的分析口徑以報表的形式呈現(xiàn)。

至此 OLAP 解決方案如下：

• 離線數(shù)據(jù)通過 Hive 同步到 PostgreSQL ，這條鏈路是報表系統(tǒng) V2 的統(tǒng)計數(shù)據(jù)源，Superset 可直接接入，對可視化圖表類型有更高要求的用戶有了一個不錯的選擇；

• 實時數(shù)據(jù)通過 Kafka Index Server 攝入 Druid 集群， Superset 連接 Druid ，看板里設(shè)置刷新頻率或手動刷新查看實時數(shù)據(jù)；

• 我們對 Superset 進行了二次開發(fā)，內(nèi)容包括接入公司 SSO 登錄、統(tǒng)一的權(quán)限系統(tǒng)、集成 ECharts 使可視化圖表更加豐富，例如漏斗圖、國家地圖等。

4）階段總結(jié)

在此階段通過明確的分工，將特定資源集中在數(shù)據(jù)平臺建設(shè)上，解決了用戶大部分取數(shù)看數(shù)分析數(shù)場景的訴求，包括報表配置、自助數(shù)據(jù)分析、實時 OLAP 等，用戶能夠通過工具自助獲取，不再完全依賴數(shù)據(jù)開發(fā)同學，效率相對有很大的提升；數(shù)據(jù)開發(fā)同學也大大減少了臨時性瑣碎的取數(shù)需求，把更多的精力放到業(yè)務本身和數(shù)倉建設(shè)上。

然而我們面對用戶多種多樣的訴求，不斷投入專門的資源來滿足，不斷推翻迭代造成資源浪費，這就引發(fā)了接下來的BI平臺體系化建設(shè)。

?3、體系建設(shè)階段

關(guān)鍵詞：多元化、個性化、標準化、體系化

用戶的訴求是多樣化的，但又不可能都得開發(fā)相應的系統(tǒng)來對應滿足，伴隨以下痛點我們當前需要統(tǒng)籌思考、整體設(shè)計、一勞永逸，做體系化建設(shè)。

• 報表系統(tǒng)，可視化圖表類型不夠豐富，添加新類型圖表需要定制開發(fā)，這里涉及大量的前端開發(fā)工作；

• Superset的看板可以部分替代數(shù)據(jù)報表來用，其分析功能強大，數(shù)據(jù)分析同學非常喜愛，但產(chǎn)品運營同學覺得使用門檻高以至于不想用；

• OLAP場景訴求更加個性化，大寬表模式已無法滿足需求；

• 對于極其個性的取數(shù)看數(shù)訴求不得不自行寫SQL通過AdHoc來獲??；

• 業(yè)務指標口徑不一，各方看到的同一個指標數(shù)據(jù)結(jié)果對不齊，需要找開發(fā)、產(chǎn)品等一遍遍的對口徑。

經(jīng)歷之前兩個階段后 BI 平臺雛形已現(xiàn)，下圖中展示了當前階段 BI 平臺的整體架構(gòu)概略設(shè)計，本文將著重介紹本階段的建設(shè)和實踐，接下來分場景模塊來介紹。

1）即席查詢與自助郵件報表

即席查詢在之前基本通過登錄客戶機或開源的 HUE 來寫 SQL 取數(shù)，這種方式會面臨很多問題，例如權(quán)限控制無法很好地保障有數(shù)據(jù)安全風險、SQL 腳本無法管理隨著人員流失就流失掉了、寫 SQL 用到的日期變量沒有靈活的支持等等個性化需求，因此結(jié)合業(yè)務訴求搭建了即席查詢與自助郵件報表系統(tǒng)。

• 即席查詢和自助郵件報表用戶自行編寫 SQL ，即席查詢用戶手動點擊運行，自助郵件報表通過配置的定時或調(diào)度依賴自動觸發(fā)查詢請求；

• 服務模塊首先做語法檢測，然后解析 SQL 獲取要查詢的表和分區(qū)數(shù)量，調(diào)用權(quán)限系統(tǒng)校驗用戶是否有表的訪問權(quán)限，再根據(jù)用戶等級來限制允許加載的分區(qū)數(shù)量、校驗允許同時執(zhí)行的任務數(shù)量、任務 MR 并行度等，最終提交查詢到執(zhí)行模塊；

• 執(zhí)行模塊通過 JDBC 連接并執(zhí)行 SQL ，然后將數(shù)據(jù)展示在前端頁面預覽或下載到本地或以郵件的形式發(fā)送報表。

2）數(shù)據(jù)報表模塊

數(shù)據(jù)報表模塊是迭代的第三個版本，除了貼合業(yè)務需求外，我們在重構(gòu)前需要思考第三版能用多久，帶著這個問題提煉出以下原則：

• 開發(fā)同學盡可能少的介入

作為數(shù)據(jù)平臺開發(fā)同學，以平臺建設(shè)思維，一次性搭建，將圖表組件化。

作為數(shù)據(jù)開發(fā)同學，開發(fā)維護好數(shù)據(jù)模型，基于此可支撐各種口徑各種類型圖表的配置。

• 使用門檻盡可能的低

作為產(chǎn)品運營等同學，不必寫SQL，通過拖拽，所見即所得。

業(yè)務內(nèi)部管理權(quán)限以及數(shù)據(jù)看板等繁雜事務，完全自助。

①架構(gòu)設(shè)計

• 數(shù)據(jù)源層

離線數(shù)據(jù)支持從 MySQL 、離線數(shù)倉以及指標系統(tǒng)中同步，也支持業(yè)務系統(tǒng)的監(jiān)控數(shù)據(jù)同步；

實時數(shù)據(jù)從實時數(shù)倉提供的 Kafka 接入，基本是 DWD 層數(shù)據(jù)；

• 數(shù)據(jù)接入層

專門的導數(shù)平臺，支持離線和實時數(shù)據(jù)導入到各種存儲中；

離線數(shù)據(jù)導數(shù)任務完成后會進行數(shù)據(jù)校驗，失敗則告警給導數(shù)任務的開發(fā)同學以及引用本數(shù)據(jù)源的圖表負責人；

實時數(shù)據(jù)由 Kafka 導入 ClickHouse 或 Apache Druid 。

• 存儲/引擎層

根據(jù)不同場景選擇不同的存儲，離線結(jié)果數(shù)據(jù)推薦 PostgreSQL ，數(shù)據(jù)量大推薦 GP ；實時統(tǒng)計數(shù)據(jù)存入 Druid ，多維數(shù)據(jù)分析場景存入 ClickHouse ；

為提升查詢效率，離線導數(shù)任務成功后，觸發(fā)引用當前數(shù)據(jù)源的圖表數(shù)據(jù)刷入緩存中，另外用戶自主查詢后的結(jié)果也都存入臨時性緩存；

• 數(shù)據(jù)模型層

基于導入的底層數(shù)據(jù)表，設(shè)置維度、指標定義數(shù)據(jù)模型，根據(jù)業(yè)務需求抽象合理的模型，這是數(shù)據(jù)報表模塊的核心，也是數(shù)據(jù)開發(fā)同學工作的重點；

• 數(shù)據(jù)展示層

可視化圖表，提供了常用圖表模板近十種類型，基于數(shù)據(jù)模型可以自由拖拽維度指標；最上層將多圖表組成數(shù)據(jù)看板用于報表展示，支持常用的上卷下鉆；對于實時數(shù)據(jù)大屏場景，通過拖拽也可高效完成。

• 系統(tǒng)管理

• 數(shù)據(jù)看板作為資源接入統(tǒng)一的權(quán)限系統(tǒng)進行管理

• 離線導數(shù)任務通過調(diào)度系統(tǒng)周期調(diào)起任務

• 各層均有系統(tǒng)性能監(jiān)控，時刻關(guān)注平臺性能狀態(tài)

• 用戶使用平臺的行為通過埋點記錄，用于掌握用戶使用情況，尤其是對無人訪問的看板做下線參考

• 支持圖表和看板嵌入到第三方系統(tǒng)，目前已嵌入機酒業(yè)務多個平臺中

②自助拖拽配置

針對可視化圖表，由前端實現(xiàn)拖拽效果，用戶在前端的所有拖拽和配置信息構(gòu)建成一個 Json 形式的 Config 中，傳到后端存儲；打開可視化圖表時前端獲取 Json 形式的 Config ，解析后渲染展示。

自由拖拽實際上是降低了圖表配置門檻，提升了配置效率。原報表系統(tǒng) V2 配置步驟繁雜，大部分還是由數(shù)據(jù)開發(fā)同學配置的，開發(fā)工期長。為提升整體效率，首先將此模塊抽象成四部分，存儲/引擎、數(shù)據(jù)模型、可視化圖表、看板/大屏，上一節(jié)已詳細介紹過。

其次明確分工，數(shù)據(jù)開發(fā)同學主要做的事情是，根據(jù)需求場景將數(shù)據(jù)引入到合適的存儲/引擎中，根據(jù)需求內(nèi)容抽象合理的數(shù)據(jù)模型，剩下的配置可視化圖表和看板皆由產(chǎn)品、運營等自助拖拽完成。

③業(yè)務自主管理

各業(yè)務整合后面對的用戶涉及全司全業(yè)務，各業(yè)務對報表在組織和權(quán)限管理方面差異很大，希望能夠獨立自主管理，因此我們加入了 BU 的概念，按 BU 從邏輯上完全隔離開，包括導入后的存儲和引擎、數(shù)據(jù)模型、可視化圖表、數(shù)據(jù)看板，以及在權(quán)限系統(tǒng)中所有相關(guān)的資源。

④亮點功能

作為數(shù)據(jù)報表系統(tǒng)，除了常規(guī)的功能例如看板/大屏、上卷下鉆、同環(huán)比等之外，還重點支持了以下幾個重要的功能點。

• 多指標計算

對于已有指標 PV、UV，需要二次計算 PV/UV 得出人均瀏覽次數(shù)這種新指標。

• 監(jiān)控告警

針對某個特定（或一批）維度，對任意多個指標設(shè)置組合規(guī)則進行報警，支持發(fā)送報警信息到 Qunar 內(nèi)部即時通訊 QTalk 和企業(yè)微信。

• 血緣信息

用戶在看板中可對某個指標或某個圖表，查看上游的血緣信息，包括底表生產(chǎn)信息、底表質(zhì)檢信息、底表接入信息，做到了血緣信息一目了然，提升了數(shù)據(jù)可信度。數(shù)據(jù)有問題也方便定位，提升了問題解決效率。

3）OLAP模塊

①需求場景

基于原實時 OLAP 模塊的升級，以酒店 CRM 系統(tǒng)數(shù)據(jù)部分為例。每逢節(jié)日做活動，運營、銷售、管理層等角色的用戶，需要在活動期間實時分析所負責酒店在各種維度下的各種數(shù)據(jù)指標，以便做策略調(diào)整和決策。

具體形式如上所示（截取了部分），針對酒店用戶任意勾選二十多個維度、近百個指標，要求 3 秒內(nèi)出結(jié)果展示圖表。通過對需求的詳細分析歸納，得出以下技術(shù)挑戰(zhàn)點：

• 任意個數(shù)的維度聚合計算 UV 指標，要保證精確去重，所以不能預聚合，只能將數(shù)據(jù)存成明細，即時查詢；

• 酒店維度表通常思路可以做成大寬表的方式提前關(guān)聯(lián)上，例如酒店所在城市，但對于動態(tài)信息字段例如 HOS 分會經(jīng)常變化，需求是得根據(jù)查詢時間段拿最后一天的酒店 HOS 分，只能在查詢時即時關(guān)聯(lián)維度表；

• 需要根據(jù)維度指標任意排列組合得去查詢，而且要求 3 秒內(nèi)出結(jié)果，但整體數(shù)據(jù)量級在百億。

②引擎選型

?

引擎選型調(diào)研 ES、Presto、Kylin 在前面對比過結(jié)論是不適用當前場景，本次選型主要對比了在用的 Apache Druid、Impala 和新增的 Apache Doris、ClickHouse。

• Apache Druid 對實時數(shù)據(jù)支持良好，基于數(shù)據(jù)預聚合模型查詢性能強，但當前場景用戶的查詢靈活度很高，不得不把數(shù)據(jù)存成明細，而且需要計算 UV 這種精確去重指標以及不得不關(guān)聯(lián)維表查詢，因此 Druid 不是最好的選擇，后續(xù)也沒必要參與做實際的性能測試了；

• Impala 對于我們來講最大的好處在于可與離線數(shù)倉的現(xiàn)有數(shù)據(jù)無縫集成，不需要導入操作，所以查詢性能受制于底層存儲系統(tǒng) HDFS ，尤其對于復雜場景的復雜 SQL 性能下降嚴重，在性能上不達標；

• Apache Doris 相對 Druid 和 Impala 比較適合，支持 MySQL 訪問協(xié)議 ，也支持高并發(fā)和高吞吐查詢且響應及時，但在當前場景需要百億級別的數(shù)據(jù)量下性能相對ClickHouse稍有遜色，另外其相對 ClickHouse 社區(qū)不夠活躍成熟。

對 Impala、Doris、ClickHouse 三種引擎做 Benchmark ，保證相同的數(shù)據(jù)表（需求相關(guān)的真實數(shù)據(jù)和量級）和相同的 SQL（按需求實際需要編寫），在各個引擎上做了簡單的測試（Impala 用 Parquet，ClickHouse 用 MergeTree 表引擎），查詢多次取均值結(jié)果如下：

通過直觀的性能對比結(jié)果，ClickHouse 的查詢性能表現(xiàn)很好，另外實際測試發(fā)現(xiàn)隨著查詢指標數(shù)量的增多對 ClickHouse 的性能影響也并不是很大，再結(jié)合我們的實際場景需求（主寬表查詢，帶小表 Join ）、硬件條件、開發(fā)成本以及業(yè)界經(jīng)驗綜合對比，ClickHouse 成為了不錯的選擇。

③架構(gòu)設(shè)計

• 數(shù)據(jù)寫入

離線數(shù)據(jù)通過導數(shù)平臺的 Waterdrop 從 Hive 中導入ClickHouse；實時數(shù)據(jù)通過導數(shù)平臺 ClickHouse 的 Kafka   Engine從Kafka 中實時消費，再由物化視圖將數(shù)據(jù)實時寫入 MergeTree 的單機表，然后基于此建分布式表。

• 數(shù)據(jù)讀取

用戶在頁面上任意勾選想要看的維度和指標，提交查詢到數(shù)據(jù)查詢服務，然后解析、拼裝查詢 SQL ，提交到 ClickHouse 執(zhí)行 SQL ，最后拿到結(jié)果數(shù)據(jù)返回到前端頁面展示成圖表。

④場景應用和優(yōu)化

?

整個集群部署如上圖，訪問入口由 Nginx 做負載均衡， CHProxy 代理用于管理集群用戶、限制并發(fā)、設(shè)置請求超時等，而集群的大部分分布式功能，則需要通過 ZooKeeper 來完成。結(jié)合 CRM 項目本身訴求以及性能要求設(shè)計了兩種表，整體原則是充分利用 ClickHouse 的單機計算性能強的優(yōu)勢。

第一種分布式表，通常用來存儲指標數(shù)據(jù)和關(guān)聯(lián)用的維度字段（如日期及酒店維度字段加到訂單流量數(shù)據(jù)），這種表通常數(shù)據(jù)量很大（ TB 甚至 PB 級別），需要用多臺機器分散存儲。分布式表需要設(shè)置 Sharding Key 來決定，由于涉及到查詢優(yōu)化，Sharding Key 最好是對應場景中出現(xiàn)頻率最高的查詢維度（比如日期），這樣能夠保證 Group By 的時候同一組維度數(shù)據(jù)一定在同一臺物理機上，然后通過修改配置 distributed_group_by_no_merge=1 將所有的聚合轉(zhuǎn)成本地操作，避免了額外的網(wǎng)絡開銷，提升查詢性能。

第二種單機表，通常用來存儲非靜態(tài)的維表，這類維表包含隨時間更新的維度（比如酒店星級，HOS 分等），需要在查詢的時候取維表數(shù)據(jù)和主表進行 Join 操作。通過設(shè)置一表多備的方式，我們讓每一臺機器都持有全量且一致的維表數(shù)據(jù)，這樣在Join的時候就可以將 Shuffle Join 優(yōu)化成 Local Join （因為每一個 Join Key 對應的右表全量數(shù)據(jù)一定都在本地）來提升查詢的整體性能。

4）標準化指標

基于 OneData 方法論，數(shù)倉建模通過指標系統(tǒng)最終產(chǎn)出的是標準化指標，定義和統(tǒng)一口徑，數(shù)倉同學為標準化指標數(shù)據(jù)負責。QBI 各個模塊從指標系統(tǒng)中獲取標準化數(shù)據(jù)，或分析或展示，以保障所有人看到同一個指標時數(shù)據(jù)是一致的，從根源上進一步提升了數(shù)據(jù)可信度。具體關(guān)系的細節(jié)如下圖所示。

①數(shù)據(jù)分析場景

數(shù)據(jù)分析模塊引入指標系統(tǒng)管理的 DIM 表、DWD 表明細數(shù)據(jù)，獲取指標系統(tǒng)構(gòu)建的原子指標、復合指標、派生指標信息，用戶在進行事件分析時可自由選擇來自指標系統(tǒng)的標準化指標，實際查詢相應底層的明細表進行分析，使用效果如下圖所示。

②數(shù)據(jù)報表場景

指標系統(tǒng)產(chǎn)出的標準化ADS表，通過導數(shù)平臺導入數(shù)據(jù)報表模塊，然后根據(jù)指標系統(tǒng)里定義的維度指標自動生成數(shù)據(jù)模型，基于此可實現(xiàn)自由拖拽可視化報表配置看板，相反在看板的圖表里可以查看底表和指標的來源信息，使用效果如下圖所示。

5）互聯(lián)互通

QBI 已形成多個模塊的全場景數(shù)據(jù)消費形態(tài)，但模塊之間并不是割裂的反而是互聯(lián)互通的，而且關(guān)系非常緊密，圍繞標準化的指標系統(tǒng)為核心如下圖所示。

• 數(shù)據(jù)分析模塊，基于指標系統(tǒng)產(chǎn)出的明細表以及派生、復合、原子指標進行深入探索分析，分析的固化結(jié)果可以保存到數(shù)據(jù)看板模塊

• 數(shù)據(jù)報表模塊，展示指標系統(tǒng)產(chǎn)出的業(yè)務指標數(shù)據(jù)，從數(shù)據(jù)分析模塊保存來的看板可回到數(shù)據(jù)分析模塊中繼續(xù)探索分析

• 即席查詢模塊，可以直接查詢通過指標系統(tǒng)建模產(chǎn)出的數(shù)倉表，SQL 結(jié)果可以直接發(fā)郵件報表，亦可固化保存至數(shù)據(jù)看板模塊

• QBI 各個模塊均可從指標系統(tǒng)獲取標準化數(shù)據(jù)，相反也可回溯到指標系統(tǒng)中查看指標元信息。

三、QBI總結(jié)

?

QBI 目前服務于 Qunar 全司十幾條業(yè)務線，整體 MAU 三千，現(xiàn)已形成較為完善的產(chǎn)品矩陣，包括以下場景：

• 即席查詢模塊，適用于自由編寫 SQL 跑數(shù)；日執(zhí)行次數(shù)五千，平均執(zhí)行時長一分鐘內(nèi)。

• 郵件報表模塊，適用于自由編寫 SQL 自助發(fā)郵件報表，簡單的數(shù)據(jù)需求不必再提可完全自助完成；

• OLAP 模塊，適用于針對某業(yè)務數(shù)據(jù)維度指標，自由勾選進行多維分析并即時響應，目前支撐了百億明細數(shù)據(jù)，維度指標上百個，查詢 P99 在 2 秒內(nèi)。

• 數(shù)據(jù)分析模塊，適用于對數(shù)據(jù)自由探索，例如上卷下鉆探查深入分析，查詢 P95 在 8 秒內(nèi)；

• 數(shù)據(jù)報表模塊，適用于數(shù)據(jù)豐富的圖表展示，看日常業(yè)務指標。MAU 兩千，可視化圖表 1萬+ ，展示數(shù)據(jù) P90 在 1 秒內(nèi)。

四、未來規(guī)劃

?1、移動端BI

基于公司自研 IM 工具，支持訂閱數(shù)據(jù)看板、交互式數(shù)據(jù)分析、業(yè)務指標監(jiān)控告警等，隨時隨地關(guān)注業(yè)務數(shù)據(jù)動態(tài)。

?2、QBI各層整合抽象

QBI 各個模塊由實際業(yè)務需要從歷史發(fā)展而來，目前雖已形成體系但從抽象的角度來看數(shù)據(jù)接入層、引擎層、查詢層可以合并同類項，抽象出公共的組件化服務，降低維護成本。

?3、數(shù)據(jù)分析場景豐富

目前數(shù)據(jù)分析模塊對事件分析和漏斗分析的支持已比較完善，后續(xù)可擴展更多的用戶分析場景，例如留存分析、歸因分析、分布分析、用戶路徑分析等等，支撐全業(yè)務各種細分場景需求，助力業(yè)務決策。?