?一、引言

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

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

二、建設歷程

從2015年至今BI平臺的建設，經歷了多年迭代發展，始終結合業務需要遵循以下幾個原則：

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

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

• 系統性能上，查詢速度要快，即提升查詢性能；

• 數據指標準確可信，即提升數據可信度。

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

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

• 發展階段，2016年—2018年，配置式的報表系統 V2 、自助分析、 OLAP ；

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

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

?1、原始階段

關鍵詞：一路到底式、數據體量小、快速完成需求開發

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

• 通過 Hive 解析日志，進行 ETL ，按業務邏輯將計算結果導出到關系型數據庫 MySQL ；

• 報表系統的工程里寫后端邏輯從 MySQL 數據庫里查詢；

• 寫前端頁面實現各種個性化的圖和表來展示數據。

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

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

• 每個需求有自己的個性，同樣也有共性，結果是無論數據還是圖表，出現大量的個性化而且互相冗余。

總結后我們發現，業務的快速發展不是借口，這種方式并不快而是痛苦，亟需明確分工，通過平臺建設將大量堆積的數據需求轉化成用戶部分自助。

?2、發展階段

關鍵詞：分工明確、部分自助

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

1）報表系統 V2

• 數據開發同學根據需求將數倉最終產出的 ADS 層數據導入 PostgreSQL ，這里用到 PostgreSQL 是因為其有豐富的分析函數，在統計方面效率表現很好；

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

2）自助數據分析

①場景痛點

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

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

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

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

②整體架構

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

• 需要支持實時數據插入、更新和讀取

• 需要支持直接讀取離線數倉表和實時數據表，查看截止到當前時刻時間段的數據，而且需要支持表關聯進行分析

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

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

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

• 數據寫入過程

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

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

• 數據讀取過程

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

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

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

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

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

3）實時OLAP

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

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

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

①計算引擎

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

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

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

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

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

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

②數據可視化

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

至此 OLAP 解決方案如下：

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

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

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

4）階段總結

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

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

?3、體系建設階段

關鍵詞：多元化、個性化、標準化、體系化

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

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

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

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

• 對于極其個性的取數看數訴求不得不自行寫SQL通過AdHoc來獲?。?/li>

• 業務指標口徑不一，各方看到的同一個指標數據結果對不齊，需要找開發、產品等一遍遍的對口徑。

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

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

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

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

• 服務模塊首先做語法檢測，然后解析 SQL 獲取要查詢的表和分區數量，調用權限系統校驗用戶是否有表的訪問權限，再根據用戶等級來限制允許加載的分區數量、校驗允許同時執行的任務數量、任務 MR 并行度等，最終提交查詢到執行模塊；

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

2）數據報表模塊

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

• 開發同學盡可能少的介入

作為數據平臺開發同學，以平臺建設思維，一次性搭建，將圖表組件化。

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

• 使用門檻盡可能的低

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

業務內部管理權限以及數據看板等繁雜事務，完全自助。

①架構設計

• 數據源層

離線數據支持從 MySQL 、離線數倉以及指標系統中同步，也支持業務系統的監控數據同步；

實時數據從實時數倉提供的 Kafka 接入，基本是 DWD 層數據；

• 數據接入層

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

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

實時數據由 Kafka 導入 ClickHouse 或 Apache Druid 。

• 存儲/引擎層

根據不同場景選擇不同的存儲，離線結果數據推薦 PostgreSQL ，數據量大推薦 GP ；實時統計數據存入 Druid ，多維數據分析場景存入 ClickHouse ；

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

• 數據模型層

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

• 數據展示層

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

• 系統管理

• 數據看板作為資源接入統一的權限系統進行管理

• 離線導數任務通過調度系統周期調起任務

• 各層均有系統性能監控，時刻關注平臺性能狀態

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

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

②自助拖拽配置

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

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

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

③業務自主管理

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

④亮點功能

作為數據報表系統，除了常規的功能例如看板/大屏、上卷下鉆、同環比等之外，還重點支持了以下幾個重要的功能點。

• 多指標計算

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

• 監控告警

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

• 血緣信息

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

3）OLAP模塊

①需求場景

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

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

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

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

• 需要根據維度指標任意排列組合得去查詢，而且要求 3 秒內出結果，但整體數據量級在百億。

②引擎選型

?

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

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

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

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

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

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

③架構設計

• 數據寫入

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

• 數據讀取

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

④場景應用和優化

?

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

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

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

4）標準化指標

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

①數據分析場景

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

②數據報表場景

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

5）互聯互通

QBI 已形成多個模塊的全場景數據消費形態，但模塊之間并不是割裂的反而是互聯互通的，而且關系非常緊密，圍繞標準化的指標系統為核心如下圖所示。

• 數據分析模塊，基于指標系統產出的明細表以及派生、復合、原子指標進行深入探索分析，分析的固化結果可以保存到數據看板模塊

• 數據報表模塊，展示指標系統產出的業務指標數據，從數據分析模塊保存來的看板可回到數據分析模塊中繼續探索分析

• 即席查詢模塊，可以直接查詢通過指標系統建模產出的數倉表，SQL 結果可以直接發郵件報表，亦可固化保存至數據看板模塊

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

三、QBI總結

?

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

• 即席查詢模塊，適用于自由編寫 SQL 跑數；日執行次數五千，平均執行時長一分鐘內。

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

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

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

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

四、未來規劃

?1、移動端BI

基于公司自研 IM 工具，支持訂閱數據看板、交互式數據分析、業務指標監控告警等，隨時隨地關注業務數據動態。

?2、QBI各層整合抽象

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

?3、數據分析場景豐富

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