一、貨拉拉雲台是什麼
貨拉拉雲台是貨拉拉内部自研BI（Business Intelligence（商業智能），簡稱：BI）可視化平台。
截至2022年12月，貨拉拉業務範圍已覆寫352座中國内地城市，月活司機達66萬，月活使用者達950萬，随着公司業務不斷擴張，對資料分析和資料價值轉化的需求愈加明顯，原先提供的資料分析平台在一定程度上已經無法滿足業務的多樣化需求，且無法直接與公司現有的權限管理系統、業務應用系統打通，更存在一定的資料權限管控和資料洩露風險，此時打造自研BI平台的迫切性越來越強，貨拉拉雲台便應運而生。
二、貨拉拉雲台系統架構介紹
其實“商業智能”（BI）一詞最早出現在1865年，當時理查德·米勒·德文斯(Richard Millar Devens）在《商業趣聞百科全書》（Cyclopaediaof Commercial and Business Anecdotes）中用它來描述銀行家亨利·福尼斯爵士（HenryFurnese）通過收集并利用資料資訊，先于競争對手采取行動，進而達到獲利的目标。時至今日，BI經過了曆史沉澱，被我們重新定義為：利用技術手段或方法，将資料轉化為知識，用以支撐企業決策、發掘商業價值的一套解決方案。以資料為中心，BI的核心功能主要有 資料倉庫 、資料ETL、資料分析、資料挖掘和 資料可視化 。
跟業務資訊化對各個業務系統不同業務之間的使用者資料處理不同的是，資料資訊化是跨業務、跨系統之間的資料分析洞察與整體名額産出，它能夠反向推動業務智能化建設，提高決策科學度，是以往往更依賴架構、模型和算力，而這也決定了企業資料資訊化的高度。随着自然語言處理、人工智能、湖倉一體等技術的發展，已經有人提出了AI+BI的概念，Databricks（由 Apache Spark 建立者成立的大資料處理平台公司）也認為同時支援 BI 和 ML 的資料平台基礎設施才是資料分析的未來。未來的BI隻需要你對着計算機說出問題，即可獲得答案。但是從“目前”和“國内”來說，真正地實作商業“智能”還是有很遙遠的距離。
接下來我們看一下貨拉拉大資料體系架構，簡單劃分如下：
基礎層、平台層：通過資料倉庫，算力平台等基礎設施（包括資料接入，運算引擎和治理開發等）為公司提供資料存儲、資料處理、資料開發等能力。
服務層、應用層：主要偏向資料價值挖掘類平台，充分利用基礎層和平台層的能力，實作公司資料資産價值最大化。
除此之外，貨拉拉大資料體系中還建立了資料安全防護體系，如：資料權限管控系統、資料安全審計、資料加密脫敏等。
可以看到整個雲台可視化分析是資料與使用者最直接的一個連接配接之一，在大資料業務體系中起到一個承上啟下的作用。以資料為中心，向上直接對業務使用者負責，向下依賴資料倉庫、資料ETL、資料分析、資料挖掘等。
雲台 系統的設計目标：讓使用者在幾分鐘内就能制作出專業的場景化的資料報表。
使用流程：添加資料源 → 建立資料模型（模型配置&自定義SQL分析）→ 可視化報表制作（報表制作&儀表盤制作）→ 釋出（多業務系統共享&報表權限管控）
報表制作過程中使用了可視化開源元件Apach Echarts，使用者僅需要通過拖拽圖表元件以及資料字段就能非常容易地制作出一個報表。
對接多種資料源：
在資料源層面，雲台可以對接的資料源主要以内部自用類型為主，比如MYSQL、PostgreSQL，Phoenix、Doris、Hive等，也可以支援Excel/CSV資料檔案的上傳，同時對接了公司内部系統快速報表、名額庫，對公司内部資料源使用者無需知道具體的賬号密碼也可以連接配接使用。
資料模型：
前邊我們介紹到使用者建立資料模型有兩種方式，分别是模型配置和編寫自定義SQL，模型配置對非技術人員比較友好，雲台已抹平不同資料源查詢語句之間的差異，可以做到零代碼，使用者不需要懂SQL語句的書寫，通過拖拽的方式即可建立一個資料集和報表。自定義SQL的方式，除了一些必要的限制，使用者可以非常靈活的建立資料模型。
報表制作：
在報表制作工作台，也就是制作報表的主要編輯頁，目前支援14種圖表類型，如名額卡、漏鬥圖、交叉表、散點圖、堆疊圖等。
使用者可以使用拖拽次元和度量字段的方式進行資料綁定、全界面化的添加和修改圖表元件，還可以進行自定義排序、合計、分組、topN、同環比分析等操作，簡單靈活易用。
儀表盤制作：
在儀表盤界面，使用者使用拖拽式選取一些已經編輯好的圖表和過濾元件，即可生成互動式的可視化頁面實作自助分析。
完成的報表支援資料下載下傳，且通過釋出後可以與大資料資料安全管控系統對接，實作報表權限的統一管理，對一些敏感資料要求比較高的使用者比較友好，還可以共享到多個業務系統。
三、貨拉拉雲台可視化技術設計
資料源連接配接：
市面上可視化平台大多有個通病，就是資料源連接配接一般都需要填使用者名和密碼，因為很多商業智能BI工具考慮更多的是通用化，這點對業務使用者來說其實不太好，因為資料源的使用者名和密碼隻有技術開發才知道，使用者每次使用都要向開發拿，其中溝通成本和資料安全無法避免。
作為内部自研系統，就能很容易地避免這種情況，使用者甚至都不需要知道資料源連接配接串、密碼等，僅知道所需資料在哪個庫哪張表即可，這樣也友善針對使用者進行權限控制，而不是建立很多連接配接賬号。
資料模型：
前面架構介紹也有提到，借鑒了業界可視化平台，雲台也可以通過模型配置和寫SQL的方式，建立資料模型，包括多表Join，通過拖拽的方式将SQL語句查詢的結果綁定到可視化圖表上。
資料模型會根據查詢的字段屬性自動生成次元和度量，自動識别字段類型，比如整數、小數、字元串、日期，其中數值類型預設識别為度量，使用者也可以自行調整次元或者度量以及字段類型、字段備注等，度量可以進行正常的聚合操作，其中包括Sum、Count、Avg、Max、Min，去重計數等，次元和度量均可以編輯字段表達式對字段進行複制（Copy）、删除（Delete）和轉換（Transform）等函數操作。對具體的使用字段，我們也提供了列級和行級的權限管控。
查詢的靈活多樣性：
可視化平台的查詢需要非常靈活且多樣化，比如SQL的Where查詢，資料需要層層過濾，資料的格式轉換，比如小數位/百分比，日期時間的年/月/日聚合計算，次元的分組，次元和度量的排序、圖表與圖表之間的下鑽/關聯，過濾器之間的關聯等。
雲台互動式的資料過濾目前主要分為單個圖表的過濾和儀表盤的全局過濾兩種，單個圖表的過濾比較簡單，就是資料模型的單一次元Set集合。而儀表盤的全局過濾就相對比較複雜了，每個篩選器之間都可能存在關聯關系。
比如a關聯bcd、a+b關聯c，a+c關聯d，僅僅這3種過濾關聯關系，乍一看估計不太容易了解，但舉個例子就非清晰了：假設a是大區、b是省份、c是城市、d是區域，那麼廣東省對應華南，a+b關聯c就是華南區/廣東省下所有的城市，a+c關聯d實際上就是a+b+c關聯d，那麼d就等于華南區/廣東省/深圳市下的所有區域。
當然除了資料的篩選和過濾器之間的關聯以外，還有圖表之間的關聯、下鑽。例如點選圖表裡的中山市，想讓下邊的某一個元件展現中山市的具體資料。而下鑽有點類似多層級過濾器，這些都是過濾器之間的靈活互動使用。
資料計算：
使用者具體可以做的計算操作包括：字段表達式轉換、日期時間聚合計算、次元分組、合計、TopN等，這些最終都會轉為SQL語句在資料庫層面計算結果。
還有一種是基于SQL的查詢結果，在記憶體中進行二次計算。比如交叉表，單次SQL請求得不到最終結果，需要在記憶體中進行二次計算。
性能優化：
頁面查詢依賴底層資料庫引擎，比如查詢Hive我們使用了Presto，性能方面就有了很大的提升，還有Doris、ClickHouse、ElasticSearch等。除了查詢引擎，系統層面也有很多地方可以優化，比如以下幾點：
- 源資料緩存 ： 由于可視化平台的特殊性，除了報表的最終資料結果以外，整個報表制作過程中使用者其實不太關注所有資料，是以隻需對其中一部分資料查詢即可，到了真正展示報表的時候才顯示全部資料。比如一個日期次元的報表，在拖拽編輯時顯示1個月的資料，而不是1年，這樣對制作報表體驗比較好，查詢也比較快，雲台這裡主要使用了H2
- SQL查詢結果緩存：利用了Redis緩存了SQL執行結果，可以達到較好的性能效果
- 篩選器下拉選項值的緩存：下拉選項值一般都變化較少，持久化到資料庫，定時更新，對查詢性能有很大幫助
- 連接配接池遇到并發高：當連接配接數打滿且慢查詢比較多時，建立連接配接池處理新請求，保證不影響新進來的查詢，但需注意别超過資料庫max_user_connections
- 交叉透視表的查詢：由于行排序後前n條資料是固定的，那就可以把目前頁行的結果作為查詢條件，去查詢比對小的部分資料，這樣性能提升比較大
- 中斷大資料量查詢：使用google concurrent SimpleTimeLimiter中斷查詢時間過長的線程，這種非常耗CPU和記憶體
- 異步多線程：比如異步下載下傳資料
四、結語以及下一步規劃
本文主要從開發人員的角度介紹了貨拉拉雲台可視化産品的架構設計思路。作為一個自研的可視化平台，雲台在貨拉拉仍處于内部孵化階段，存在很多不足之處，比如有些資料源查詢速度不夠快、操作流程太繁瑣、提示不夠友好等等。但随着接入系統的增加以及使用者量增長，我們會努力完善系統功能、優化使用者體驗，保證系統穩定，力争讓雲台成為企業降本增效的利器。
技術層面的下一步規劃，大概有兩點：
- 系統穩定性治理：系統穩定性壓倒一切。老子曾說，“治大國若烹小鮮”，治理系統也類似，要掌握火候，精選食材，用料恰當，輔以煎炒烹炸煮，方能出一盤好菜。我們知道系統穩定性治理除了代碼健壯性，主要有3個方面：監控告警、壓測和演練，下一步計劃會聚焦在系統代碼的健壯性建設和監控告警降級等。
- 代碼設計整合：随着系統功能越來越豐富，代碼設計方面很難做到十全十美，性能與可讀性之間往往是選擇題，如何在多個選擇之間權衡取舍，并不是一件簡單的事情。所幸有一些這方面的書籍可供參考，比如《代碼整潔之道》《設計模式》等。
原文連結：https://juejin.cn/post/7211008551761543229