隨著 Shopee 業務數據的不斷擴大，僅通過表格這樣的數據分析方式已經無法滿足日常的數據分析需求，豐富的圖表分析 Dashboard 就顯得格外重要。但是，從事前端開發的同學都知道，這種 Dashboard 頁面純手工開發會耗費比較多的人力資源和時間資源，在量比較多的情況下，可能業務需求都沒辦法及時響應了。

如果能有一個可以自動生成這些 Dashboard 頁面的工具平臺，那么可以節省大量的人力和時間，效率提升將會非常顯著。本文將分享如何從零開始創建一個數據可視化大屏搭建系統。

1.現狀分析

先來看一份數據。我們團隊平均每個季度會有 3-4 個 Dashboard 相關需求，平均每個需求的項目周期約 40 天。目前已經累計有 20+ 頁面，每個頁面的圖表組件約 50+，另一個準備重構的平臺（Stella）Dashboard 頁面 25+，涉及到的圖表組件更多，粗略統計 100+。

這些 Dashboard 頁面絕大部分頁面內容復雜，交互也復雜。按照傳統的開發方式，一個頁面的上線大約需要 PM、Dev、QA 共 50+ 人/日。

除開人力資源，接下來看看開發一個 Dashboard 的研發流程是怎樣的。

這是一個再正常不過的開發流程。在整個流程中，用時最多的就是數據同步、接口數據聚合、頁面開發、聯調這四大塊——大約占了 70% 的時間。如果能有一個平臺解決這幾個問題，那么這個平臺對于 解放人力瓶頸、縮短研發流程、提高研發效率 就有著非常大的意義。

目前市面上類似的平臺非常多，我們也做了很多橫向對比。綜合來看，考慮到業務場景的貼近程度，以及開發投入和收益，最終我們決定自研平臺 “Data Visualization”（下文簡稱 “Datav”）。

我們希望這個平臺能夠承擔的角色如下：

Datav 平臺承載了兩個主要目標：

縮短項目周期，從 40 天縮短至 20 天；

減少人力成本，FE 從 10 人/日減少到 3 人/日，PM 從 15 人/日減少到 5 人/日，不再需要 BE 和 QA 參與。

2. Datav 設計與關鍵節點實現

為了能夠達成以上兩個目標，我們將 Datav 要實現的功能抽象成了五個關鍵點：

• 重塑整個項目流程，提高 PM 和開發之間的協作效率；
• 支持簡單的元數據計算以及更加靈活的數據查詢；
• 支持頁面快速配置；
• 支持頁面組件直連數據源；
• 支持組件聯動和篩選查詢。

2.1 整體架構設計

接下來將一一介紹每個關鍵點的實現，下圖是我們的整體架構設計。

整個 Datav 平臺包含五個非常重要的子系統和模塊：

• Designer：設計器是 Datav 平臺的核心與難點，支持頁面布局配置、頁面交互配置和組件數據配置等功能，另外還支持代碼片段的配置，也可以稱得上是一個低代碼平臺。
• Admin：是 Datav 的運營管理平臺，包含了數據計算、作品管理、組件狀態管理、頁面發布、頁面權限等等常規的平臺管理功能。
• UI Components：是整個平臺最基礎的模塊，我們在開源的圖表庫上面定義了一層標準的 DSL 協議，這個協議和接入 Designer 的協議是對應的，目前已經有 50+ 相關組件，組件數量還在不斷增長。
• Datav Server：是一個 node 服務，主要提供一些權限校驗、數據聚合、動態 SQL 的生成等功能。
• Datasource Access Server：專門用于連接不同數據源的服務，例如直連 MySQL、ClickHouse、Elasticsearch、Presto 等等，提供了不同的連接 client。

從架構圖可以看出，Datav 平臺支持直連各種數據源，最終會產出一個 URL，可以方便地集成到任何平臺上。下一步計劃是支持生成源代碼，可供使用方進行二次編輯。

2.2 如何提高各個角色之間的協作效率

在解決這個問題之前，我們和各個角色之間進行了多次溝通，分析了各個角色在項目中的痛點以及花費的成本：

• PM 側的痛點是畫原型圖，每個需求畫原型圖需要花費 10 天左右的時間，而且還是靜態的圖片，跟開發對完需求后，還需要去改里面的一些靜態數據，然后再進行 PRD 評審；
• BE 和 FE 主要的精力花在頁面開發、接口開發、數據同步以及頁面聯調這些事情上。

從傳統的開發流程來看，這些都是正常的流程，是最小開發路徑。要解決這個問題，我們就需要重塑整個項目的流程，讓各個角色都能參與到配置中來，于是我們一起重新定義了 Dashboard 項目的開發流程，如下圖。

• PM 可以直接在 Datav 上面配置原型頁面；
• Data Dev 也支持直接將數據計算的結果自動同步到 ClickHouse；
• FE 可以通過 Datav 直連數據源，并且可以復用步驟 1 里面 PM 配置的原型頁面，進行配置優化；
• 最終生成頁面的 URL，PM 可以直接訪問 URL 進行測試。

新的流程效果非常顯著，整個項目周期縮短了一半，從 8 周縮短到了 4 周，也不再需要 BE 和 QA 的支持，FE 平均只需要投入 3 天支持需求。

2.3 如何支持元數據計算

2.3.1 基礎知識

支持元數據計算是個比較復雜且龐大的功能。數據是所有系統的基石，任何平臺和業務都離不開數據的流轉。同時，數據的流轉也是非常復雜的，特別是在數據量比較龐大的情況下。

我們先來認識一下數據的產生和流轉都做了什么事情，以及從客戶端產生數據開始，到 Dashboard 看到數據的聚合，都經歷了哪些階段。

上圖是一個常規的大數據平臺的架構圖，它清楚地描述了數據產生到數據應用的整個過程?？赡芾锩嬗幸恍Ｓ性~匯對于 FE 來講有點陌生，但這里我們只需要了解：用戶所產生的數據，需要經過一系列的加工之后，才會有比較大的價值。

下面再用一個更容易理解的流程圖來說明：

從圖中可以看出，數據準備有四個關鍵流程， 數據采集、數據預處理、數據建模、數據服務 ，每個階段都有一系列的事情要做，Data Dev 同學可以借助數倉以及相關工具，快速產出業務所需要的數據，Datav 平臺不會涉及到這部分的功能，Datav 所處理的是在數據服務之后。

這里從數倉產出的數據，雖然經過了一系列的計算，但是往往也不是頁面展示想要的數據。根據經驗來看，一個 Dashboard 頁面往往會有非常多的數據聚合邏輯，也就是說還需要根據數據服務產出的數據進行數據聚合。例如要計算同比、環比這樣的指標等等。

2.3.2 Datav 打通數據直連通道

業務方需要做數據聚合，也就意味著需要后端開發提供 API 接口給前端。數倉產出的數據，由于環境隔離和權限等原因，目前無法直接給業務團隊使用，因此業務團隊使用這些數據有一個特別曲折的過程，使得整個流程比較復雜、鏈路也比較長。

這個流程 BE Dev 階段需要提供兩個服務，一個數據同步服務，一個 API 接口服務。粗略統計，BE Dev 這一步需要花費整個項目流程 30% 左右的時間，而且這些工作也是重復的。

因此 Datav 解決的第一個問題——打通數據直連通道，采用的方案就是直連 ClickHouse。

Datav 提供了一個 直連數據源的服務 ，可以直接連接 Data Infrastructure 團隊提供的 ClickHouse，這樣一來，大部分 Dashboard 頁面就有了直連數據源的能力，不再需要依賴 BE 團隊提供 API，使整個項目周期縮短了 30% 左右的時間。

上面提到，API 主要作用是用于一些數據聚合和數據邏輯計算的，那么 Datav 是如何支持這些功能的呢？這就是 Datav 面臨的第二個大的挑戰——支持數據聚合計算以及邏輯字段增加。

2.3.3 支持元數據計算

接下來用一個簡單的例子來說明：Datav 如何實現替代 API 接口支持一些數據聚合計算。例如，有一個銷售表 tab_sales（這是數倉計算出來的離線數據），內容如下：

現在有一個需求：要求計算每個 category 的支付成功率。

按照以前的方式，API 接口會按照類型先把數據查出來，查詢 SQL：

得到原始數據后需要進行計算，得到最終右側的數據結構給到前端：

試想，如果 Datav 能夠產生這樣一條 SQL，查詢出來的結果也能夠返回同樣的數據結構，是不是就可以不用依賴 API 接口了？帶著這樣的疑問，我們做了很多的嘗試。

最終結論證明，在大部分場景下，完全能夠不用依賴 API 接口。就如同上面的例子，我們將 SQL 變化一下，就能夠得到相同的數據結構：

2.3.4 Datav 數據管理

為了解決上述兩大問題——如何打通數據直連通道、如何支持元數據邏輯計算，Datav 建設了數據管理模塊。

數據管理是比較重要的一個模塊，在配置頁面之前，第一步想到的應該是這個頁面的數據都來自哪，頁面中每個組件的數據都來自哪張表，是否是通過某些字段計算得到的等等問題。

因此，數據管理模塊應該包含幾大塊：數據源管理、數據字段編輯（包括字段名別名、新增字段、支持字段間的計算、字段格式化、字段展示權限等）、數據主題管理（支持多表間關聯產生邏輯數據寬表，以及自定義 SQL 查詢生成數據主題）。流程如下：

1）數據源管理

目前數據源支持直連離線數據源（MySQL、ClickHouse），即將支持直連實時數據源（Kafka、Elasticsearch、Prometheus 等）。

2）數據字段編輯

字段編輯提供了針對表以及表字段的別名設置、表字段權限設置、新增邏輯字段、字段邏輯計算、字段格式化等一些列高級功能。

3）數據主題管理

數據主題目前支持可視化配置和自定義 SQL。目前可視化配置僅支持單表設置，即將支持多表關聯形成邏輯寬表。

多表關聯功能如圖：

自定義 SQL 查詢如圖：

2.4 如何支持頁面快速配置

支持頁面快速配置的核心就是 Designer 的實現。跟目前業界低代碼平臺實現的思路類似，都是通過將頁面組件的位置信息、屬性用一種通用的中間協議 DSL 來描述，然后通過解析引擎在運行時動態去解析 DSL，再渲染到頁面中。

架構如下圖：

為了進一步提高 UI 和 FE 之間的協作效率，我們預留了一些高級功能。

• 例如實現一個 Figma 插件，可以讓 UI 在設計頁面的時候就用到我們的組件，然后通過這個插件生成頁面的 DSL 產物，再交給 Datav 解析引擎去做頁面渲染；
• 還有一種更加大膽的想法，就是通過機器學習的方式，將圖片中的組件識別出來，自動生成頁面的 DSL 產物，最終再交給 Datav 解析引擎去做頁面渲染。

這兩種方案都還處于設計階段，暫時還沒有實現。

Designer 這一塊功能比較多，而且比較復雜，這里就不展開細節講。我們目前已經實現了兩種頁面布局的方式：絕對布局和 Flex 布局。針對不同的場景，采用不同的布局方式，頁面配置效率會非常高。

Flex 布局：適用于頁面結構簡單且清晰，類似 Admin 表單類型頁面的配置場景。

絕對布局：頁面結構復雜且組件布局毫無規律的頁面配置，大屏頁面就特別符合。

2.5 頁面組件直連數據源

組件直連數據源的關鍵點包括：

• 理解維度和指標；
• 理解如何生成一個 SQL 語句。

接下來先用兩個例子直觀說明：

這是一個二維一指標的圖表，一個維度是日期，即 X 軸；另一個維度是柱子的分類，指標就是 Y 軸的數據。

如果要生成這樣一個圖表，那我們的 SQL 語句應該這樣寫：

Select [indicator] from [table_xxx] group by [dimension1], [dimension2]

從 SQL 語句中可以發現，維度屬性放在 group by? 后面，指標屬性放在 Select 后面。

再來看一個例子：

同理，這是一張一維一指標的圖，對應的 SQL 如下：

Select [indicator] from [table_xxx] group by [dimension1]

理解了維度和指標，以及 SQL 的生成規則后，基于這樣的思路，我們實現了一個 Data-Connector 組件，這個組件可以配置維度、指標、分頁、排序等字段，最終再根據這些配置生成一個對應的 SQL 語句。

它對應生成的 SQL 語句是這樣的：

SELECT field1 FROM Demo-Table GROUP BY date_day LIMIT 1000 OFFSET 100 ORDER BY  field3  ASC

這樣，我們就實現了組件直連數據源，展示對應的動態數據。

2.6 支持組件聯動和篩選查詢

在絕大部分的場景下，我們配置出來的頁面不是一個靜態頁面，它需要動態數據，也需要各種交互，最常見的就是篩選這種交互。

交互對于頁面配置來講是一個難點，因為交互特別多，有些交互也特別復雜。Datav 目前只支持了部分交互，例如組件數據篩選、按鈕點擊事件、彈窗、tab 切換等等比較常見的功能。

我們先看一個例子，為什么一定要支持組件間的交互呢？

這是我們利用組件直連數據源查詢出來的數據，你會發現數據量非常大。

這個時候，有可能會導致組件崩潰或者頁面卡死。因此，解決這種問題最好的方式就是支持數據篩選，即支持一個組件可以篩選另一個組件的數據，如下圖。

這就是我們希望獲得的效果：用一個篩選組件控制圖表組件的數據量。那么如何實現呢？

我們也調研了業界的類似方案，最常用的就是支持寫代碼，利用發布訂閱設計模式來實現。實現原理大致如圖：

這樣做的優勢非常明顯——簡單，但是同樣也存在一些不足：

• 需要寫 JS 代碼，只對前端同學比較友好；
• 如果關聯組件比較多，那代碼維護將會變得非常復雜；
• 頁面配置的效率也會大大降低。

因此，為了解決這些問題，Datav 實現了可視化配置組件聯動，對于復雜的情況，也支持寫代碼的方式。實現原理也不復雜，總結起來分成四個步驟：

• 建立篩選組件和展示組件的關聯關系，以及篩選組件和篩選參數的關系；
• 監聽篩選參數的變化；
• 一旦篩選參數發生變化，通知所有相關聯的展示組件，并將新的值傳遞給它；
• 通知工具函數拉取新的數據并重新渲染。

原理架構圖如圖：

整個 Datav 平臺比較龐大，有非常多的功能點，很多功能點的設計都可以單獨寫一篇文章來介紹。而本篇文章主要圍繞 Datav 解決的一些關鍵問題來展開，我們希望通過這篇文章讓大家了解到 Datav 是一個什么平臺，能解決哪些問題，適用于哪些業務場景。因此在技術細節上面并沒有太多的展開，后續會另寫文章介紹。

3. Datav 帶來的收益

Datav 項目帶來的收益可以從流程優化、開發效率，和基礎建設等方面來考量。

3.1 流程優化

整個項目流程的周期從原來的 40 天左右減少到了現在的 20 天左右。耗費的人力也有所減少，不一定需要 BE 和 QA 同學的加入了，項目周期縮短了 100%。

這是因為 PM 同學可以直接通過 Datav 平臺配置頁面的原型，確定好需求后，這個原型配置可以直接交給 FE 同學進行加工，加上一些交互和數據相關配置，就可以直接提測。

3.2 開發效率

單從前端的開發效率來看，平均 10 人/日縮短到了平均 3 人/日，效率提升 200% +。

從整個研發階段的效率來看，以前需要參與的人力總和為： (Data dev) 10 人/日 + (BE Dev) 13 人/日 + (FE Dev) 10 人/日 = 33 人/日 。

現在人力總和為： (Data dev) 10 人/日 + (FE Dev) 3 人/日 = 13 人/日 ，從 33 人/日縮短到了 13 人/日，效率仍然提升了 150% +。因此 Datav 對于研發效率的提升來講，也是意義非凡的。

3.3 基礎建設

除了上面提到的量化收益，Datav 還帶了比較多的隱性收益，例如在團隊基礎建設上的：

• 制定了組件開發規范；
• 建立了一套標準組件庫以及組件平臺；
• 沉淀了一些標準的 Node 中間件，例如 logger；
• 沉淀了一套標準的自動化腳本，組件創建、自動編譯、自動化生成文檔、代碼規范檢測等等；

更細粒度的權限管理系統（建設中）。

本文作者

Liangquan、Huiwen、Mingye、Yanqiu，前端工程師，來自 Shopee Digital Purchase & Local Services 團隊。

團隊介紹

Shopee 數字產品與本地生活（Digital Purchase & Local Services）團隊業務涉及數字商品的售賣服務，包括話費、游戲充值等生活繳費，電影、演出等娛樂票務，以及火車票、飛機票、公交票等出行 OTA 服務。

我們已經覆蓋東南亞日常大部分數字商品消費場景，市場規模龐大，具有交易頻度高、用戶黏度高等特性。我們還為用戶提供便捷的本地生活服務，包括餐飲、娛樂、購物等，這些都是線下支付的重要場景和流量入口。目前服務已覆蓋大部分東南亞市場，用戶規模龐大且進一步擴展。