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

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

1.現(xiàn)狀分析

先來看一份數(shù)據(jù)。我們團(tuán)隊平均每個季度會有 3-4 個 Dashboard 相關(guān)需求，平均每個需求的項目周期約 40 天。目前已經(jīng)累計有 20+ 頁面，每個頁面的圖表組件約 50+，另一個準(zhǔn)備重構(gòu)的平臺（Stella）Dashboard 頁面 25+，涉及到的圖表組件更多，粗略統(tǒng)計 100+。

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

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

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

目前市面上類似的平臺非常多，我們也做了很多橫向?qū)Ρ取＞C合來看，考慮到業(yè)務(wù)場景的貼近程度，以及開發(fā)投入和收益，最終我們決定自研平臺 “Data Visualization”（下文簡稱 “Datav”）。

我們希望這個平臺能夠承擔(dān)的角色如下：

Datav 平臺承載了兩個主要目標(biāo)：

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

減少人力成本，F(xiàn)E 從 10 人/日減少到 3 人/日，PM 從 15 人/日減少到 5 人/日，不再需要 BE 和 QA 參與。

2. Datav 設(shè)計與關(guān)鍵節(jié)點實現(xiàn)

為了能夠達(dá)成以上兩個目標(biāo)，我們將 Datav 要實現(xiàn)的功能抽象成了五個關(guān)鍵點：

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

2.1 整體架構(gòu)設(shè)計

接下來將一一介紹每個關(guān)鍵點的實現(xiàn)，下圖是我們的整體架構(gòu)設(shè)計。

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

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

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

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

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

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

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

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

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

2.3 如何支持元數(shù)據(jù)計算

2.3.1 基礎(chǔ)知識

支持元數(shù)據(jù)計算是個比較復(fù)雜且龐大的功能。數(shù)據(jù)是所有系統(tǒng)的基石，任何平臺和業(yè)務(wù)都離不開數(shù)據(jù)的流轉(zhuǎn)。同時，數(shù)據(jù)的流轉(zhuǎn)也是非常復(fù)雜的，特別是在數(shù)據(jù)量比較龐大的情況下。

我們先來認(rèn)識一下數(shù)據(jù)的產(chǎn)生和流轉(zhuǎn)都做了什么事情，以及從客戶端產(chǎn)生數(shù)據(jù)開始，到 Dashboard 看到數(shù)據(jù)的聚合，都經(jīng)歷了哪些階段。

上圖是一個常規(guī)的大數(shù)據(jù)平臺的架構(gòu)圖，它清楚地描述了數(shù)據(jù)產(chǎn)生到數(shù)據(jù)應(yīng)用的整個過程。可能里面有一些專有詞匯對于 FE 來講有點陌生，但這里我們只需要了解：用戶所產(chǎn)生的數(shù)據(jù)，需要經(jīng)過一系列的加工之后，才會有比較大的價值。

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

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

這里從數(shù)倉產(chǎn)出的數(shù)據(jù)，雖然經(jīng)過了一系列的計算，但是往往也不是頁面展示想要的數(shù)據(jù)。根據(jù)經(jīng)驗來看，一個 Dashboard 頁面往往會有非常多的數(shù)據(jù)聚合邏輯，也就是說還需要根據(jù)數(shù)據(jù)服務(wù)產(chǎn)出的數(shù)據(jù)進(jìn)行數(shù)據(jù)聚合。例如要計算同比、環(huán)比這樣的指標(biāo)等等。

2.3.2 Datav 打通數(shù)據(jù)直連通道

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

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

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

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

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

2.3.3 支持元數(shù)據(jù)計算

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

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

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

得到原始數(shù)據(jù)后需要進(jìn)行計算，得到最終右側(cè)的數(shù)據(jù)結(jié)構(gòu)給到前端：

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

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

2.3.4 Datav 數(shù)據(jù)管理

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

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

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

1）數(shù)據(jù)源管理

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

2）數(shù)據(jù)字段編輯

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

3）數(shù)據(jù)主題管理

數(shù)據(jù)主題目前支持可視化配置和自定義 SQL。目前可視化配置僅支持單表設(shè)置，即將支持多表關(guān)聯(lián)形成邏輯寬表。

多表關(guān)聯(lián)功能如圖：

自定義 SQL 查詢?nèi)鐖D：

2.4 如何支持頁面快速配置

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

架構(gòu)如下圖：

為了進(jìn)一步提高 UI 和 FE 之間的協(xié)作效率，我們預(yù)留了一些高級功能。

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

這兩種方案都還處于設(shè)計階段，暫時還沒有實現(xiàn)。

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

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

絕對布局：頁面結(jié)構(gòu)復(fù)雜且組件布局毫無規(guī)律的頁面配置，大屏頁面就特別符合。

2.5 頁面組件直連數(shù)據(jù)源

組件直連數(shù)據(jù)源的關(guān)鍵點包括：

• 理解維度和指標(biāo)；
• 理解如何生成一個 SQL 語句。

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

這是一個二維一指標(biāo)的圖表，一個維度是日期，即 X 軸；另一個維度是柱子的分類，指標(biāo)就是 Y 軸的數(shù)據(jù)。

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

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

從 SQL 語句中可以發(fā)現(xiàn)，維度屬性放在 group by? 后面，指標(biāo)屬性放在 Select 后面。

再來看一個例子：

同理，這是一張一維一指標(biāo)的圖，對應(yīng)的 SQL 如下：

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

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

它對應(yīng)生成的 SQL 語句是這樣的：

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

這樣，我們就實現(xiàn)了組件直連數(shù)據(jù)源，展示對應(yīng)的動態(tài)數(shù)據(jù)。

2.6 支持組件聯(lián)動和篩選查詢

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

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

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

這是我們利用組件直連數(shù)據(jù)源查詢出來的數(shù)據(jù)，你會發(fā)現(xiàn)數(shù)據(jù)量非常大。

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

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

我們也調(diào)研了業(yè)界的類似方案，最常用的就是支持寫代碼，利用發(fā)布訂閱設(shè)計模式來實現(xiàn)。實現(xiàn)原理大致如圖：

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

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

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

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

原理架構(gòu)圖如圖：

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

3. Datav 帶來的收益

Datav 項目帶來的收益可以從流程優(yōu)化、開發(fā)效率，和基礎(chǔ)建設(shè)等方面來考量。

3.1 流程優(yōu)化

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

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

3.2 開發(fā)效率

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

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

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

3.3 基礎(chǔ)建設(shè)

除了上面提到的量化收益，Datav 還帶了比較多的隱性收益，例如在團(tuán)隊基礎(chǔ)建設(shè)上的：

• 制定了組件開發(fā)規(guī)范；
• 建立了一套標(biāo)準(zhǔn)組件庫以及組件平臺；
• 沉淀了一些標(biāo)準(zhǔn)的 Node 中間件，例如 logger；
• 沉淀了一套標(biāo)準(zhǔn)的自動化腳本，組件創(chuàng)建、自動編譯、自動化生成文檔、代碼規(guī)范檢測等等；

更細(xì)粒度的權(quán)限管理系統(tǒng)（建設(shè)中）。

本文作者

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

團(tuán)隊介紹

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

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