摘要：至于如何優(yōu)雅地管理使用，再次祭出潘神的文章手摸手，帶你優(yōu)雅的使用掘金項目的后端接口文檔我是用的進行的管理，其實有很多強大的功能，不僅僅是一個接口測試工具，接口文檔管理就是其中一個。

首先放個線上地址大家感受一下(由于后端用的是 leancloud 的免費套餐，因此可能會比較慢)：

vue-data-board

P.S. 建議大家盡量自己注冊一個賬號(可以隨便填一個密碼)，如果用默認的測試賬號，不要亂改東西，否則別人進來就沒得看了，因為你做的任何改動都會保存到后端數(shù)據(jù)庫里。

再放幾個 GIF 吸睛：

拖拽實現(xiàn)數(shù)據(jù)的查詢和可視化

向看板中添加圖表

通過拖拽自定義看板布局

也不知道為什么，公司里對數(shù)據(jù)分析、數(shù)據(jù)可視化的需求越來越多。這部分需求有的來自數(shù)據(jù)分析師(如果公司有數(shù)據(jù)分析師的話)，有的來自產(chǎn)品、運營、開發(fā)，還有的來自公司的中層、高層領(lǐng)導(dǎo)，有的只是要把某一個表的數(shù)據(jù)導(dǎo)出，也有的希望能從多個維度對數(shù)據(jù)進行分析、可視化，還有的希望把多個可視化圖表整合在一個頁面中形成可視化的報表，有的是一次性的需求，有的是周期性的常態(tài)化需求，這些需求常常雜亂無章，而且數(shù)據(jù)的維度很多，交互比較復(fù)雜，可視化圖表的各種參數(shù)眾多，很難做到通用，而且很多數(shù)據(jù)較為敏感又需要嚴(yán)格的權(quán)限控制，時間一長，權(quán)限的管理又成了一個頭疼的事情，種種因素導(dǎo)致各種數(shù)據(jù)需求耗費了前端開發(fā)的大量精力，發(fā)量日漸稀薄。

相信很多公司都會有類似的數(shù)據(jù)需求，零散卻必須，雖然市面上也有不少產(chǎn)品提供了類似的數(shù)據(jù)管理功能，但是一來由于數(shù)據(jù)的敏感性，許多公司不愿意將自己的數(shù)據(jù)放到別的平臺上，二來這些數(shù)據(jù)管理的產(chǎn)品大多收費昂貴且功能難以定制。所以很多公司里這種數(shù)據(jù)需求就會落到前端的頭上，這些需求雖然零散甚至臨時，但是實現(xiàn)起來卻并不簡單，可視化的視覺效果需要各種參數(shù)去配置，而大量的數(shù)據(jù)需要驗證、清洗、轉(zhuǎn)換又使得接口調(diào)試和對接變得十分麻煩，增加了前端的工作量，也讓前端的 coding 變得十分惱人。

這時候做一個強大靈活易用的數(shù)據(jù)分析后臺就十分有用了，通過傻瓜式地拖拽生成圖表的方式，可以讓沒有數(shù)據(jù)基礎(chǔ)的同事也能很快上手；通過將公司的數(shù)據(jù)源整合到一起，可以方便地對數(shù)據(jù)進行管理；通過構(gòu)建看板整合多個圖表，可以快速生成報表，便于查看、分享；通過用戶自定義圖表參數(shù)，可以有效地解決前端調(diào)參的痛苦。(一個十分工整的排比句，oh yeah!)

我在我司搭建數(shù)據(jù)分析后臺也將近一年了，實際上我從第一份實習(xí)開始就在接觸BI、數(shù)據(jù)相關(guān)的事情，在數(shù)據(jù)分析后臺的搭建過程中也踩了許多的坑，期間經(jīng)歷了同事的各種吐槽，嘗試了各種不同的解決方案，如今雖然代碼能力不見多少提升，但是對于業(yè)務(wù)需求的雜亂無章、變幻莫測可謂多有體會。

在經(jīng)歷了半年多痛苦的折磨之后，我根據(jù)業(yè)務(wù)需求，參考其他數(shù)據(jù)分析產(chǎn)品，搭建了全新的數(shù)據(jù)分析平臺，這一平臺如今在我司運轉(zhuǎn)良好，一方面已經(jīng)滿足了一部分數(shù)據(jù)需求，另一方面也有很好的可擴展性，可以應(yīng)對更復(fù)雜的業(yè)務(wù)場景。我將前端部分抽離出來，形成了這個開源項目：

dongsuo/vue-data-board

首先介紹下這個項目的基本情況，這個項目主要是用 Vue+ElementUI 搭建的，可視化部分是用的echarts，拖拽和布局部分是 vue-grid-layout 和 vuedraggable這兩個庫。這個項目一些技術(shù)、思路以及一部分輔助代碼是參考了潘神的這個后臺項目：

PanJiaChen/vue-element-admin

項目的后端部分除了少數(shù)數(shù)據(jù)是用了 mock 數(shù)據(jù)之外，都是用了 [leancloud](http://leancloud.cn) 進行搭建， Demo 數(shù)據(jù)的數(shù)據(jù)庫部分則是用了國外的一個免費數(shù)據(jù)庫 Free MySQL Hosting 速度比較慢，也沒有 root 權(quán)限，但是測試足夠用了，其他的用戶數(shù)據(jù)、圖表、看板等則是用了 leancloud 的對象存儲。

首先介紹項目的主要功能點及實現(xiàn)原理：

這個功能主要是通過構(gòu)建 SQL 語句來查詢數(shù)據(jù)庫，在后端的查詢是用 Presto 來做的，Presto 可以統(tǒng)一查詢多種數(shù)據(jù)庫，除了傳統(tǒng)的關(guān)系型數(shù)據(jù)庫還可以查詢 HDFS，查詢能力比較強大。前端部分數(shù)據(jù)查詢主要是通過對 SQL 語句的解構(gòu)，劃分成維度、數(shù)據(jù)、篩選、排序、數(shù)據(jù)條數(shù)等交互元素，便于沒有 SQL 基礎(chǔ)的用戶使用。用戶在前端的交互按照特定語法規(guī)則動態(tài)生成 SQL 發(fā)送到后端進行數(shù)據(jù)庫的查詢。當(dāng)然目前 SQL 的構(gòu)建功能還不完整，有一些 SQL 語法還有待支持，已經(jīng)列入了開發(fā)計劃中。

對數(shù)據(jù)進行可視化渲染主要是通過數(shù)據(jù)查詢的維度和數(shù)值來判斷可用的圖表類型，然后利用 vue.js 的動態(tài)組件來渲染對應(yīng)的圖表組件：

// Vue.js 動態(tài)組件渲染對應(yīng)的圖表類型

這里有一個問題是圖表與數(shù)據(jù)的映射關(guān)系的問題，不同的數(shù)據(jù)適合用不同的圖表來展示，例如餅圖的數(shù)據(jù)跟堆疊柱狀圖的數(shù)據(jù)就不一樣，因此需要對各個圖表所需要的數(shù)據(jù)結(jié)構(gòu)進行定義：

// 這是餅圖的匹配規(guī)則定義
matchRule: {
    desc: "1個維度1個數(shù)值;0個維度多個數(shù)值",
    isUsable(dimensions, calculs) {
        return (dimensions.length === 1 && calculs.length === 1) || (dimensions.length === 0 && calculs.length >= 1)
    }
},

然后根據(jù)匹配規(guī)則來判斷圖表類型是否可用。

前端生成圖表后就可以保存到后端了，由于定義一個圖表所需要的字段太多，而且這些字段還可能會經(jīng)常增減改動，因此不太可能讓后端在數(shù)據(jù)庫一一定義這些字段，因此我們采用的方案是由前端來維護這些字段，后端統(tǒng)一將所有的內(nèi)容以字符串或者 json 對象的方式存在數(shù)據(jù)庫的一個字段(如 content)中。

這樣一來圖表的回顯問題也就沒有任何問題了，按照生成圖表的邏輯把 content 字段的內(nèi)容解析出來就好了。

很多時候業(yè)務(wù)都需要同時查看多個圖表，這個時候就需要一個看板來整合多個圖表?？窗迤鋵嵤侵?Dashboard，中文其實沒有很貼切的翻譯可以對應(yīng)，看板勉強達意。

看板整合多個圖表在后端而言只是一個關(guān)聯(lián)關(guān)系的管理，對前端而言則需要根據(jù)看板關(guān)聯(lián)的圖表來對頁面進行布局，然后根據(jù)保存的圖表來查詢數(shù)據(jù)、可視化渲染。頁面布局主要是利用了 vue-grid-layout 進行 grid 布局，同時也支持拖拽和大小調(diào)整等?？梢暬倪壿嫺鷦?chuàng)建圖表時的可視化是一樣的，不再贅述。

這里遇到的問題是對于已有布局的看板，添加新圖表時，新圖表的定位要如何計算。這其實跟圖片瀑布流的問題有些相似，但是由于各個 item 不定寬高，其實相對更難一些，我已經(jīng)找到了思路，做了一些計算，但是目前還不完善，完善后我會再寫文章來介紹。

公司的數(shù)據(jù)其實相當(dāng)敏感，對于上市公司而言，數(shù)據(jù)會影響股價走勢，對非上市公司來說，會影響投融資的進度，都是關(guān)系到公司財務(wù)甚至生死存亡的大事，因此數(shù)據(jù)的權(quán)限管理是十分重要的。在這個項目里，這一部分的解決方案其實并不簡單，但是復(fù)雜度主要在于后端而不是前端。簡單來說，我們的權(quán)限是做到了數(shù)據(jù)表這一層級，由管理員向系統(tǒng)中添加數(shù)據(jù)源，添加的同時定義好該數(shù)據(jù)源的權(quán)限范圍，如產(chǎn)品、運營、開發(fā)等權(quán)限角色。用戶進入系統(tǒng)后，由管理員給用戶分配權(quán)限角色，用戶只能查詢其自身對應(yīng)角色所能查看的數(shù)據(jù)。由于權(quán)限和數(shù)據(jù)源管理的部分暫時還沒有添加到這個開源項目中來，因此也就不細說了，先挖個坑，以后有機會再填。

首先項目的構(gòu)建是用了 [email protected]，除了默認的配置之外，還通過 vue.config.js 做了一些自定義的配置。另外還有環(huán)境變量的配置等等，項目的配置方面建議參考潘神的這篇文章：

手摸手，帶你用vue擼后臺 系列五(v4.0新版本) - 掘金

項目中用到了很多 icon，雖然Element UI 的 icon 在2.8.x版本之后增加了不少， 但是還是不能滿足我們的需求(一些常用的 icon 仍然沒有，比如保存)，因此需要自己來解決 icon 的問題，這里要感謝 iconfont 上的設(shè)計師如山提供的這套漂亮的數(shù)據(jù)可視化圖標(biāo)庫。至于 icon 如何優(yōu)雅地管理使用，再次祭出潘神的文章：

手摸手，帶你優(yōu)雅的使用 icon - 掘金

項目的后端接口文檔我是用的 postman 進行的管理，其實 postman 有很多強大的功能，不僅僅是一個接口測試工具，接口文檔管理就是其中一個。我在開發(fā)時一般是在本地同時起前端和后端兩個項目，本地開發(fā)時通過環(huán)境變量判斷接入本地的后端接口地址：

const fetchInstance = axios.create({
    baseURL: process.env.VUE_APP_BASE_API
*}*)

本地開發(fā)完成后，前端打包發(fā)布到 gh-page 分支( git subtree push --prefix docs origin gh-pages )，后端通過 leancloud 提供的 cli 工具一鍵部署，還是挺方便的。前端的打包發(fā)布其實可以配置 Travis-ci 來實現(xiàn)自動部署，我暫時還沒有配(已棄療的拖延癥患者在此)。

項目的登錄授權(quán)、圖表和看板的增刪改查等都是使用了 leancloud 提供的解決方案，其實利用 leancloud 的 js-sdk ，前端也可以很方便地實現(xiàn)對象存儲的增刪改查，不需要寫后端接口。但是為了保持項目代碼的純潔，避免代碼中引入奇奇怪怪的 AV.query 這種東西，我還是自己做了后端的部分，當(dāng)然這部分也做的比較簡單，畢竟只是一個 Demo，主要就是基于 koa.js 做的的一些增刪改查，基本上是面向文檔編程。

項目里的狀態(tài)管理用到了 vuex, 但是其實目前為止并沒有很多全局狀態(tài)管理的需求，只有用戶 token 保存在了 store 里。另外關(guān)于狀態(tài)管理，我在這個項目的創(chuàng)建圖表的部分還嘗試用了Vue 的簡單狀態(tài)管理模式( 代碼在此 )，掘金上有一篇文章介紹過這個模式：

為管理復(fù)雜組件狀態(tài)困擾？試試 vue 簡單狀態(tài)管理 Store 模式 - 掘金

這個模式用起來是沒問題的，對于大型項目里的復(fù)雜組件來說是很好用的，很方便地解決了復(fù)雜組件內(nèi)部的狀態(tài)共享問題。但是目前對于我這個項目而言并不是特別適用，因為這部分的狀態(tài)管理放在全局狀態(tài)也挺合適，當(dāng)然這里是見仁見智了，我覺得就目前這樣也挺好。

這個項目的核心功能目前算是已經(jīng)完成得七七八八了，還有一些功能很不完善，后期會逐步完善起來。數(shù)據(jù)分析可視化平臺國內(nèi)社區(qū)里的討論貌似不多，一些中文的討論大多是設(shè)計和產(chǎn)品方面的介紹，而且過于理想化，在實踐中可能不太容易落地，關(guān)于技術(shù)實現(xiàn)的討論不多(當(dāng)然后端和運維方面還是比較多的)，開源項目也沒見多少，因此我這個項目也算是做了一些探索，當(dāng)然我沒多少經(jīng)驗，雖然參考了幾個商業(yè)平臺的產(chǎn)品交互設(shè)計，但是很多地方都是摸著石頭過河，有些地方應(yīng)該會有更好的解決方案，希望我的這個項目可以拋磚引玉，也希望大家能夠多提意見。
本文原創(chuàng)地址： 觀眾老爺們，來試試這個用 Vue 擼的數(shù)據(jù)可視化后臺吧-DongSuo