技術決策：自研和半自研數據報表與可視化大盤

著做權歸做者全部。商業轉載請聯繫 Scott 得到受權，非商業轉載請註明出處[務必保留全文，勿作刪減]。

數據只有被看見，真相才浮出水面，數據跳動在大盤，洞察才造成預判。

今天 2020/1/7，到小菜整整 2 年半，看到團隊在數據報表量產和可視化上面有了新的成果，這些年來也瞭解到前端後端面對不可勝數的數據報表和後臺可視化大盤，真心苦不堪言，就趁這個節點，跟你們聊聊兩年半來咱們是如何從前端來驅動數據報表量產和可視化大盤的技術探索。

首先上結論：

• 公司的數據倉庫（簡稱數倉）要投人力持續建設，它是報表及可視化的基礎
• 前端自研報表及可視化會有較高的成本，須要謹慎再謹慎，競品調研再調研
• 魔改 Metabase 是一個不錯的選擇，須要前端學習 Clojure 和熟悉 React

簡而言之，先推進技術團隊把數據倉庫建設到基本成熟，再來基於 Metabase 魔改出本身的報表和可視化業務後臺，這是一個可取的套路，得出這個結論，是由於兩年半的探索咱們有斬獲也有疼痛的教訓。

固然一路自研過來，咱們也調研了不少方案，不管是商業付費仍是開源，對第三方可替代競品的選擇標準以下：

• 代碼開源免費，有團隊/人持續在維護
• 產品交互流程易用可定製，有設計感
• 技術棧對前端友好，學習上手成本低

閱讀兩篇舊文，有助於你們理解下文：

• 技術驅動：量產數據報表的工具如何搭建
• 技術驅動：業務大盤數據可視化技術探索

爲何數據報表是剛需

無論是 toB 仍是 toC 的公司，不管是 +互聯網仍是互聯網+，都對數據報表有着近乎瘋狂的依賴，這不只僅是像馬老師說的咱們正在進入 DT 時代，數據運營甚至數據智能價值挖掘和應用愈來愈普及，而是對於任何一家高速迭代的互聯網公司，在產業互聯網的大背景下，在中早期各類紅利逐漸消逝的前提下，基於數據的成本意識和精細化運營能力愈來愈考驗一家公司在所謂寒冬活下去的實力。

業務現場無時無刻都在產生着數據，經過什麼途徑觀測業財健康直接決定一個公司/一條業務線的頂層決策，頂層決策有何等重要，促成決策的數據報表就有多重要，因此一個公司只要上了信息化系統，數據報表都會成爲絕對剛需。

基於這個剛需，有的公司招專門的 BI 工程師，組建算法團隊甚至大數據團隊，有的則是業務方直接把要看的字段丟給開發團隊，讓先後端工程師，一個寫跨庫跨表的 SQL API，一個寫能篩選日期和排序的 DataTable 頁面。

顯然小菜早期，就是以 SQL -> API -> DataTable 的流程開發報表，效率極低，成就感極弱，先後端成長極慢，帶來的影響有不少，好比工程師更不穩定，好比業務決策等待的週期更長，好比報表的零散維護出錯率更高...

第一波探索 - SQLEditor

啓動數據報表是在 2017 年 7 月份，屆時市面上尚未較爲成熟的開源方案可選，包括目前的 Metabase，調研無果後，咱們選擇了純自研，目標是讓產品經理/後端開發能夠快速在線製做報表並渲染出來。
**
方式是參考數據倉庫業務表的文檔，在系統上快速的定義報表列的中文名稱以及對應的庫表字段的查詢（好比產品經理能夠不借助開發資源，自行查詢銷售的周市調次數和周我的交易單量這樣的簡單報表），因爲是取代運營本地人肉的 「搭表格」，所以這個系統取名叫作 「大表哥」，它的技術棧的進化以下：

早期技術棧

• 前端：React + Ant
• 後端：Node.js/Koa2/MongoDB/RDS
• 服務器：1 臺 2 核 4G Centos

功能清單：

• 報表需求提交（看某業務的哪些數據）
• 報表加工（在後臺網頁編輯 SQL)
• 過濾組件（基於某字段作數據篩選過來）
• 報表查看（按照一套模板渲染報表）
• 報表導出（Excel 格式導出）

技術棧缺點：

• Koa2 是一個精巧精簡的 Node.js 框架，不是一個企業級的框架，從 0 開始配置開發，成本仍是比較高

產品交互易用性：

• 前端頁面的交互未通過設計，前端自行設計，比較粗糙難用

中期技術棧

• 前端：React + Ant + Apollo + React Native
• 後端：Node.js/Egg/Python
• 服務器：1 臺 2 核 4G Centos

功能清單：

• 報表需求提交/加工/查看/導出優化，及更多過濾組件
• 報表權限（誰能看哪些報表）
• 數據權限（誰能看哪些報表背後數據庫的哪些表）
• 透出報表到 App 端（ReactNative 報表組件）

技術棧缺點:

• 低版本 RN 報表組件開發踩了很多坑
• Python 加工數據性能壓力比較大，且比較吃 CPU，沒法高效的解析二進制類型的數據

產品交互易用性：總體的產品設計較粗糙，菜單管理權限管理粗暴，維護成本較高，導出功能不穩定

目前技術棧

• 如今：AntD + AntV + Apollo + Rxjs + React + Rematch + React Native
• 後端：Node.js/Egg/Envoy/Python/gRPC/Docker
• 服務器：1 臺 4 核 8G Centos + 1 臺 2 核 4G Centos

功能清單：

• 報表需求提交/加工/查看/導出優化(分佈式 Docker 部署)
• 報表權限/數據權限接入權限中心
• 報表到 App 端的組件化豐富與開發

技術棧缺點：

• 大量的報表查詢與導出，給 RDS 帶來較大查詢壓力，同時超大報表的導出，服務器 I/O 壓力大

產品交互易用性：

• 總體功能可用，但流程偏複雜，設計感不強

報表製做後臺，能夠跨庫跨表的查詢數倉的數據，自由度很高：

報表展現頁面，自動關聯各類篩選組件，加強報表的檢索功能：

第二波探索 - 可視化大盤

啓動可視化大盤是在 2019 年 1 月份，屆時銷售征戰四海，業務遍及全國各地，須要有一些更宏觀、更易於理解、更易於診斷和決策的視角來看時間線上的業務財務變化，以及跟進地面部隊的 KPI 完成狀況，就啓動了數據大盤這個項目，由於它須要有很強的定製性（好比更改 KPI 和錄入新指標等），並且比較緊急，除了付費用阿里雲 DataV 作一些過渡外，就在大表哥的基礎上啓動了數據大盤的開發，讓它能夠直接長在數據報表之上，技術棧狀況以下：

當前技術棧

• 前端：React + Apollo + AntV
• 後端：Node.js/Egg/Python/C#
• 服務器：1 臺 2 核 4G Centos

功能清單：

• 元數據過濾聚合
• 10 個圖形組件可選擇
• 自由挑選組件組成看板
• 自定義看板佈局
• Redis 緩存數據
• 看板查看權限
• 圖表動態篩選組件

技術棧缺點：

• 明細數據數據量大，致使前端加載慢
• GraphQL 沒法 URL 緩存
• C# 計算 Excel 方案吃 CPU，服務器壓力太大
• Python 計算性能差

產品交互易用性：編排流程覆盤，須要定時觸發任務加工數據，編輯體驗和調試體驗很差，可視化的大盤性能很差

除了傳統的餅圖柱狀圖二維表等等，也有偏定製的跟蹤 KPI 的錄入式卡片集：

第三波探索 - Metabase

啓動 Metabase 是在 2019 年 7 月份，屆時 Metabase 趨於穩定，公司的數據倉庫建設也更加成熟穩定，能夠面向 BI 團隊接收需求來開發一張張業務寬表，具有了可快速查詢的條件。

另外需求也有變化，更多端的報表及可視化的透出需求愈來愈多，好比透出到釘釘 H5 上，內部的 App webview 內，PC 中後臺的系統中，甚至是客戶的微信 H5 帳戶主頁上，就啓動了這一次的探索：基於 Metabase 來魔改報表及圖表的拼裝流程，公司本身登錄系統/權限系統的集成，與原來的大表哥作融合升級抽離微服務等等，基於這麼多可視化大盤的需求，咱們把這個通過魔改的 Metabase 更名叫 「大盤子」，它的技術棧狀況以下：

當前技術棧

• 前端：React + Redux + D3
• 後端：Clojure/Docker/RDS
• 服務器：1 臺 2 核 4G Centos

功能清單：

• 建立需求
• 建立儀表盤（看板）
• 建立定時任務（發送需求至郵箱）
• 自動分析數據庫數據
• 14 個可視化組件
• 自動分析生產儀表盤
• 下鑽分析
• 支持多種數據源
• 權限管理

技術棧缺點：

• 先後端耦合
• React 過低，只有 15，沒法使用不少社區資源

產品交互易用性：

• 漢化的效果不佳，總體的設計稿偏樸素，流程上手有必定的理解成本

預期技術棧

• 前端：React + Redux + d3 + AntV + AntD + Storybook + gRPC
• 後端：Clojure/Node.js/Envoy/gRPC/Python/Docker/RDS/Druid
• 服務器：3 臺 2 核 4G Centos

功能清單：

• 建立需求
• 建立儀表盤（看板）
• 建立定時任務（發送需求至郵箱/釘釘）
• 自動分析數據庫數據
• 22+ 個可視化組件
• 自動分析生產儀表盤
• 下鑽分析
• 支持多種數據源
• 數據權限管理
• 釘釘小程序組件
• 多種主題（目標替代已付費的 DataV）
• 模塊組件
• 分佈式服務

大表哥和大盤子生產鏈路

大表哥一句話

網頁版的報表編輯器和展現工具，具有量產數據報表和可視化搭建圖表的能力。

大盤子一句話

基於 Metabase 魔改的系統，具有數據報表和圖表搭建的全鏈路生產與應用能力。

生產報表鏈路

大表哥，更偏工具屬性，它的生產鏈路是從一份報表的需求提交開始，好比想要一個報表，看全部門店昨日成交 總單數、GMV...假如門店業務的 10 個表頭業務字段也定義好了，接下來 PD/開發 進場：

1、 製做階段：

• 從報表需求進入到網頁後臺的 SQL Panel 製做頁面，引入各方數據表（跨庫跨表）
• 對各類表進行 join，提煉業務字段並定義、過濾(數據內容、數據權限管理)、數據聚合、排序和分頁規則
• 最終生成兩套 SQL，一套是能查出這份報表的 SQL 自己，一個是對它的 count 操做
• 生成的 SQL 以元字段和特定規則持久化到 MongoDB，報表製做完畢

2、 渲染階段：

• 從 MongoDB 中拿到特定報表的 SQL 規則
• 把規則轉成 SQL，鏈接 RDS(MySQL) 進行 Query
• 查詢後拿到的 Rows Data 返回，經由 GraphQL Query Endpoint 進一步篩選聚合
• 網頁拿到二維數據及表頭數據，開始渲染 Table 渲染及配套的過濾組件

3、導出階段：

• 導出 Excel 依靠另一臺服務器，作 Excel 的流式存儲

4、透出階段：

• 透出到移動端，藉助於額外開發的 RN 移動報表組件，來實現九宮格、卡片、列表、Tab、複合篩選等報表功能

5、圖表製做：

• 在 1 基礎上，定時更新，過濾、聚合（統計邏輯）、將大盤背後的數據，定時持久化到 Redis（單個寬表）
• 挑選 redis 報表數據源，二次加工數據，編排組合這些二維表和圖表，生成特定業務域的可視化數據大盤

6、定製通知：

• 在 5 的基礎上，能夠以關注的形式跟進大盤的數據變化，得到實時的釘釘消息推送

從製做到展現，到透出到移動端，整個報表鏈路是閉環的，可是也有不足和缺陷：

• 移動端只能適配 APP，沒法適配 H5，而且強依賴 APP 的熱更新發布
• 移動端只建設了二維表組件，未建設可視化組件（這也不是 RN 強項）
• 產品的 SQL 能力有限，跨庫跨表查詢容易把數據庫查掛，或者拖慢總體的性能
• 數據倉庫的底層未建設，放開跨庫跨表查詢的權限有安全風險
• 編排可視化大盤與報表的綁定太過耦合，對其餘數據源的兼容度很差
• 報表、可視化以及移動端的 RN 報表組件內，對於權限的管理不夠體系化

大盤子，雖然也是工具屬性，但因爲它是站在了數倉寬表基礎設施完善的基礎上，因此針對單表（可額外 Join 一張表）的數據聚合、組合和圖表編排能力更完整，它的主流程以下：

1、數據源建立階段：

• SQL Panel（單庫單表，額外 Join 一張表），引入寬表數據源
• 字段定義、過濾、聚合、排序生成 SQL（能夠預覽 SQL）
• SQL 規則持久化，數據源定義完成

2、圖表/二維表製做階段：

• 在 1 的基礎上，透出二維表/圖表類型的映射選擇
• 針對表的字段再定義
• 渲染展現和導出 Excel（導出性能很差）
• 不斷的重複 1 到 2 的圖表/二維表選擇，製做不少單圖表組件
• 組合編排這些單圖表組件，生成可視化數據大盤

3、透出階段：

• Webview url 內嵌或者組件引入，渲染特定的二維表/圖表/綜合大盤的 PC/H5 頁面

顯然大盤子的鏈路更短，並且能夠被 webview 嵌入，能夠充分利用瀏覽器能力，它的發佈效率更高，特別是 Bug 修復和大盤具有迭代的時候，但大盤子的報表導出性能不高，同時對於偏錄入式的可視化組件支持不夠，以及 webview 自身的加載性能問題。

自研與半自研的價值比較

你們若是對比上面三波探索的功能點，會發現這個公式：

大表哥(自研) + 大表哥可視化(自研) ≈ 大盤子(半自研)

也就是咱們辛辛苦苦迭代了 2 年的的數據報表和可視化的成果，也就能頂上開發半年的 Metabase 的成果，WTF...

若是讓咱們從新回到 2017 年，咱們必定會作以下的選擇，來避開兩段彎路：

• 在數據倉庫不 Ready 的前提下，咱們不會啓動數據報表平臺的建設
• 在 Metabase 趨於成熟的時候，咱們會選擇用半自研替代全自研

提到價值，就必定是這套技術解決方案給公司帶來的價值，在對它門覆盤時候咱們是這樣評估的：

• 大表哥的價值：實現了公司數據報表量產的從 0 到 1，所謂量產，就是提效，提升數據報表從需求到上線的效率，進而提升業務方的決策效率，這個價值在過去的 2 年被充分證實了（有產品經理形容作報表比從起快了 8 倍，從起兩三天，如今兩三小時）
• 大盤子的價值：實現了公司報表及可視化的流程貫通，所謂貫通，就是降本，下降團隊繼續迭代報表和可視化的研發成本（基於原來的大表哥繼續自研下去，研發成本會居高不下）

因此這個價值是一個遞進關係的價值，在不一樣的階段發揮能力，但不能否認，咱們整個報表體系化建設中，的的確確走了彎路，多浪費了幾個月的時間，半自研的啓動其實能夠更早更果斷一些。

最後你們若是要作獨立的報表系統，或者長出大盤可視化的能力，咱們的建議依然是：

• 先驅動公司技術團隊，建設好數倉，來接管複雜報表和大盤的多表計算需求，實時更新寬表
• 前端自研報表及可視化會有較高的成本，競品調研再調研，能承擔付費就用第三方過渡
• 魔改 Metabase 是一個不錯的選擇，前端至少要學習 Clojure，須要跨棧能力

基於前面的三波探索，咱們目前明確的方向是，把大盤子和大表哥作融合，製做二維表/圖表/編排大盤的能力都給到大盤子，數倉未建設到位的零碎報表展現由大表哥接管（會被逐步弱化但難以替代，由於高頻的小報表需求是層出不窮的），同時 PC 端的大盤展現一概接入大表哥作展現，在大盤子和大表哥的背後，抽離鏈接數倉和其餘 API 的能力，封裝成微服務，同時供給大表哥和大盤子使用，以及將大表哥的導出服務也貢獻給大盤子用，簡而言之，大盤子上面製做，大表哥上面看，要透出到多端的時候，一概來嵌大盤子的大盤 URL 或者組件 SDK。

Scott 近兩年不管是面試仍是線下線上的技術分享，遇到許許多多前端同窗，因爲團隊緣由，我的緣由，職業成長，技術方向，甚至家庭等等緣由，在理想國與現實之間，在放棄與堅守之間，搖擺不停，心酸硬扛，你們能夠找我聊聊南聊聊北，對工程師的宿命有更多的瞭解，有更多的看見與聽見，Scott 微信： codingdream，也能夠來 關注 Scott 語雀跟進最新動態，本文未經許可不準轉載，得到許可請聯繫 Scott，不然在公衆號上直接轉載，尤爲是裁剪內容後轉載，我都會直接進行投訴處理。