1. 引言

通過 BI 平台取數看數分析數成為輔助決策、精細運營等非常重要的手段，然而随着去哪兒網業務不斷發展，産品、運營等同學對這方面有更高的要求，例如簡單易用的拖拽式報表、取數方便的自由式分析、查詢速度的秒級響應、觀測指标數據的準确可信等等。面對用戶的個性化訴求以及海量數據，在平台體系化建設和技術實現上有一定的挑戰性，本文将介紹去哪兒網BI平台的建設曆程及實踐，通過打造全場景的 BI 平台為業務增長賦能。

2. 建設曆程

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

1. 用戶盡可能的自助完成，使開發同學盡可能少的介入，即提升取數看數分析數效率；
2. 平台功能上，操作方便門檻要低、取數方式要豐富，即提升平台易用性；
3. 系統性能上，查詢速度要快，即提升查詢性能；
4. 數據指标準确可信，即提升數據可信度。

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

1. 原始階段，2016年之前，一路到底式的報表系統 V1 ；
2. 發展階段，2016年—2018年，配置式的報表系統 V2 、自助分析、 OLAP ；
3. 體系建設階段，2019年—至今，即席查詢、自助郵件報表、數據報表系統 V3 、 OLAP(CRM) ；子系統互聯互通、全面對接指标系統建設标準化指标。

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

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

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

1. 通過 Hive 解析日志，進行 ETL ，按業務邏輯将計算結果導出到關系型數據庫 MySQL ；
2. 報表系統的工程裡寫後端邏輯從 MySQL 數據庫裡查詢；
3. 寫前端頁面實現各種個性化的圖和表來展示數據。

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

1. 這種一路到底式的開發模式，導緻消化需求并沒有想象中的迅速，反而效率低，而且代碼風格不一質量不一；
2. 每個需求有自己的個性，同樣也有共性，結果是無論數據還是圖表，出現大量的個性化而且互相冗餘。

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

2.2.發展階段

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

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

1. 數據開發同學根據需求将數倉最終産出的 ADS 層數據導入 PostgreSQL ，這裡用到 PostgreSQL 是因為其有豐富的分析函數，在統計方面效率表現很好；
2. 産品等用戶首先配置維度、指标和篩選項作為數據單元，此數據單元可在不同報表中複用，然後在報表中引用後，發布成最終的報表展示數據。

1. 報表系統引入的是數倉 ADS 層數據表，是固化口徑計算好的結果，然而并不能很好得支持多樣的分析場景；
2. 從 DWD 到 ADS 的過程需要數據開發同學排期完成，對于不會寫 SQL 的産品運營同學，臨時性、靈活且簡單的聚合分析想獲取數據，需要提需求，周期太長，如果能夠基于 DWD 明細數據，用戶直接自由分析可以很大程度提升數據分析效率，數據開發同學也能從瑣碎的數據需求中釋放；
3. 規範化埋點的實時數據（包括行為和訂單數據），也需要數據開發同學排期做實時 ETL ，是否可以做到全程自動化，在平台上能分析實時的埋點數據。

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

2.2.2.2.整體架構

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

1. 需要支持實時數據插入、更新和讀取
2. 需要支持直接讀取離線數倉表和實時數據表，查看截止到當前時刻時間段的數據，而且需要支持表關聯進行分析
3. 自助分析需要對多個維度指标查詢，且需較快的響應

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

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

數據寫入過程

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

數據讀取過程

1. 用戶在分析頁面選擇維度分組、篩選條件、統計周期、指标運算等點擊查詢；
2. 查詢模塊首先從緩存中取，如果是重複請求直接返回，如果不是則解析請求參數，拼接查詢Impala的SQL；
3. 對于多指标分析，為提升整體查詢效率，拆分成多條SQL并行執行；
4. 對于跨多天的非去重查詢，将查詢結果按天存為碎片緩存，減少後續的重複查詢，提升查詢效率；
5. 将查詢Impala的數據和從碎片緩存取出來的數據，合并後返回到頁面展示。

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

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

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

2.2.3.1.計算引擎

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

1. Kylin在十幾個維度情況下與Druid是差不多的，但我們遇到的場景是幾十個維度，Kylin的Cube膨脹率很高，查詢性能也達不到預期；再一個業務需求變化得重建Cube不夠靈活，Kylin比較适合固定20個維度内，且業務邏輯計算很複雜需要預計算的場景；
2. Presto不支持實時數據，且秒級的交互式查詢也滿足不了；
3. ES在億級别數據量下多維分析查詢性能不佳，寫入效率也不高；
4. Kudu Impala方案看起來比較合适，但當前需求不關心數據更新，更多關注的是在億級别的數據量之下查詢響應的時長。

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

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

至此 OLAP 解決方案如下：

1. 離線數據通過 Hive 同步到 PostgreSQL ，這條鍊路是報表系統 V2 的統計數據源，Superset 可直接接入，對可視化圖表類型有更高要求的用戶有了一個不錯的選擇；
2. 實時數據通過 Kafka Index Server 攝入 Druid 集群， Superset 連接 Druid ，看闆裡設置刷新頻率或手動刷新查看實時數據；
3. 我們對 Superset 進行了二次開發，内容包括接入公司 SSO 登錄、統一的權限系統、集成 ECharts 使可視化圖表更加豐富，例如漏鬥圖、國家地圖等。

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

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

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

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

1. 報表系統，可視化圖表類型不夠豐富，添加新類型圖表需要定制開發，這裡涉及大量的前端開發工作；
2. Superset的看闆可以部分替代數據報表來用，其分析功能強大，數據分析同學非常喜愛，但産品運營同學覺得使用門檻高以至于不想用；
3. OLAP場景訴求更加個性化，大寬表模式已無法滿足需求；
4. 對于極其個性的取數看數訴求不得不自行寫SQL通過AdHoc來獲取；
5. 業務指标口徑不一，各方看到的同一個指标數據結果對不齊，需要找開發、産品等一遍遍的對口徑。

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

2.3.1.即席查詢與自助郵件報表

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

1. 即席查詢和自助郵件報表用戶自行編寫 SQL ，即席查詢用戶手動點擊運行，自助郵件報表通過配置的定時或調度依賴自動觸發查詢請求；
2. 服務模塊首先做語法檢測，然後解析 SQL 獲取要查詢的表和分區數量，調用權限系統校驗用戶是否有表的訪問權限，再根據用戶等級來限制允許加載的分區數量、校驗允許同時執行的任務數量、任務 MR 并行度等，最終提交查詢到執行模塊；
3. 執行模塊通過 JDBC 連接并執行 SQL ，然後将數據展示在前端頁面預覽或下載到本地或以郵件的形式發送報表。

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

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

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

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

• 使用門檻盡可能的低

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

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

2.3.2.1.架構設計

• 數據源層

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

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

• 數據接入層

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

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

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

• 存儲/引擎層

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

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

• 數據模型層

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

• 數據展示層

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

• 系統管理

1. 數據看闆作為資源接入統一的權限系統進行管理
2. 離線導數任務通過調度系統周期調起任務
3. 各層均有系統性能監控，時刻關注平台性能狀态
4. 用戶使用平台的行為通過埋點記錄，用于掌握用戶使用情況，尤其是對無人訪問的看闆做下線參考
5. 支持圖表和看闆嵌入到第三方系統，目前已嵌入機酒業務多個平台中

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

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

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

2.3.2.3.業務自主管理

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

2.3.2.4.亮點功能

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

多指标計算

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

監控告警

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

血緣信息

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

2.3.4.OLAP模塊

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

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

1. 任意個數的維度聚合計算 UV 指标，要保證精确去重，所以不能預聚合，隻能将數據存成明細，即時查詢；
2. 酒店維度表通常思路可以做成大寬表的方式提前關聯上，例如酒店所在城市，但對于動态信息字段例如 HOS 分會經常變化，需求是得根據查詢時間段拿最後一天的酒店 HOS 分，隻能在查詢時即時關聯維度表；
3. 需要根據維度指标任意排列組合得去查詢，而且要求 3 秒内出結果，但整體數據量級在百億。

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

1. Apache Druid 對實時數據支持良好，基于數據預聚合模型查詢性能強，但當前場景用戶的查詢靈活度很高，不得不把數據存成明細，而且需要計算 UV 這種精确去重指标以及不得不關聯維表查詢，因此 Druid 不是最好的選擇，後續也沒必要參與做實際的性能測試了；
2. Impala 對于我們來講最大的好處在于可與離線數倉的現有數據無縫集成，不需要導入操作，所以查詢性能受制于底層存儲系統 HDFS ，尤其對于複雜場景的複雜 SQL 性能下降嚴重，在性能上不達标；
3. Apache Doris 相對 Druid 和 Impala 比較适合，支持 MySQL 訪問協議 ，也支持高并發和高吞吐查詢且響應及時，但在當前場景需要百億級别的數據量下性能相對ClickHouse稍有遜色，另外其相對 ClickHouse 社區不夠活躍成熟。

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

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

2.3.4.3.架構設計

數據寫入

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

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

2.3.4.4.場景應用和優化

整個集群部署如上圖，訪問入口由 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 對應的右表全量數據一定都在本地）來提升查詢的整體性能。

2.3.5.标準化指标

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

2.3.5.1.數據分析場景

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

2.3.5.2.數據報表場景

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

2.3.6.互聯互通

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

1. 數據分析模塊，基于指标系統産出的明細表以及派生、複合、原子指标進行深入探索分析，分析的固化結果可以保存到數據看闆模塊
2. 數據報表模塊，展示指标系統産出的業務指标數據，從數據分析模塊保存來的看闆可回到數據分析模塊中繼續探索分析
3. 即席查詢模塊，可以直接查詢通過指标系統建模産出的數倉表，SQL 結果可以直接發郵件報表，亦可固化保存至數據看闆模塊
4. QBI 各個模塊均可從指标系統獲取标準化數據，相反也可回溯到指标系統中查看指标元信息。

3.QBI總結

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

1. 即席查詢模塊，适用于自由編寫 SQL 跑數；日執行次數五千，平均執行時長一分鐘内。
2. 郵件報表模塊，适用于自由編寫 SQL 自助發郵件報表，簡單的數據需求不必再提可完全自助完成；
3. OLAP 模塊，适用于針對某業務數據維度指标，自由勾選進行多維分析并即時響應，目前支撐了百億明細數據，維度指标上百個，查詢 P99 在 2 秒内。
4. 數據分析模塊，适用于對數據自由探索，例如上卷下鑽探查深入分析，查詢 P95 在 8 秒内；
5. 數據報表模塊，适用于數據豐富的圖表展示，看日常業務指标。MAU 兩千，可視化圖表 1萬 ，展示數據 P90 在 1 秒内。

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

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

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

更多精彩资讯请关注tft每日頭條，我们将持续为您更新最新资讯!