前面說完了大數(shù)據(jù)開發(fā)平臺的核心組件，作業(yè)調(diào)度系統(tǒng)，接下來討論一下大數(shù)據(jù)開發(fā)平臺的臉面之一，數(shù)據(jù)可視化平臺。和調(diào)度系統(tǒng)一樣，這又是一個很多公司可能想要自己造一個輪子的系統(tǒng)。。。

數(shù)據(jù)可視化平臺是什么?

不過，慢著，先等一下，什么是數(shù)據(jù)可視化平臺?我們用這個高端大氣上檔次的詞語，所指的對象和你所理解的是同一個東西么?

它是像天貓雙十一時，這種占據(jù)了200個平米的屏幕，全球各地曲線狂飛，五顏六色的數(shù)字噼啪跳動，流光溢彩，渾身毛孔都洋溢著互聯(lián)網(wǎng)必勝精神的大屏狂歡系統(tǒng)么?

還是像各種定位未來，使用三維全息地圖，旋轉(zhuǎn)透視，指哪打哪，動態(tài)疊加各種數(shù)據(jù)懸浮圖層，隱隱流淌出一股運籌帷幄，決勝千里的氣質(zhì)的XX智慧城市系統(tǒng)呢?

又或者，是近有裸眼3D VR現(xiàn)實，遠有黑客帝國天網(wǎng)矩陣，虛擬和現(xiàn)實交融，不知是莊周夢蝶還是蝶夢莊周的終極數(shù)字物化空間?

　　好吧，是，也不是。

相似的是途徑，都是希望借助更加豐富的視覺圖形圖像手段，將數(shù)據(jù)更加直觀的展現(xiàn)出來。不同的是，對視覺效果的追求，暫時還不在我所指代的可視化系統(tǒng)的目標(biāo)范圍之內(nèi)，簡單的說，酷炫是一個加分項，但不是核心需求。

那你問，我說來說去，這個可視化平臺，到底指的是什么玩意?讓我換個不那么陽春白雪的名詞：報表系統(tǒng)，這幾個字，大家應(yīng)該不陌生了吧。

所以我為什么這么矯情，故弄玄虛，不早說報表系統(tǒng)這幾個字呢?

這是因為傳統(tǒng)的報表系統(tǒng)，多半是以表格，或者有限的圖例比如折線圖的形式，靜態(tài)的展示底層的數(shù)據(jù)快照，通常也沒有太多的用戶交互能力，更多的是一個固定了邏輯和形式的單向展示系統(tǒng)。

為了和傳統(tǒng)報表系統(tǒng)的下里巴人形象區(qū)分開來，改進了目標(biāo)定位和功能特性的報表系統(tǒng)當(dāng)然就不好意思再叫這個名字了。最起碼，也得冠上個BI商業(yè)智能系統(tǒng)的頭銜 ;)

所以，你看，市面上知名度較高的報表類系統(tǒng)，不叫BI都不敢出來混，如果逼格高一點的，哪怕在外圍用上了一點點分布式計算技術(shù)的，那還必須得叫敏捷BI，以示和“老朽緩慢的”傳統(tǒng)商業(yè)智能系統(tǒng)劃清界限。然后大家都“敏捷”了，怎么辦?那就要返璞歸真強調(diào)內(nèi)涵了，好比你玩嘻哈的，這時候就要問，你有沒有Free Style呢?于是，可視化這么低調(diào)而有內(nèi)涵的詞語，也就漸漸流行開來。

因此，總結(jié)下來，就是報表系統(tǒng)這個名字所代表的境界，太Low了。要建設(shè)好四個現(xiàn)代化的大數(shù)據(jù)平臺，我們需要一個比傳統(tǒng)報表系統(tǒng)更現(xiàn)代化一點的數(shù)據(jù)可視化平臺。當(dāng)然了，重要的不是它叫什么，而是在名字的背后，它所試圖提供的產(chǎn)品形態(tài)是什么。

又造輪子，那些商業(yè)智能系統(tǒng)們，有什么問題么?

商業(yè)化的BI產(chǎn)品廠商很多，國外比較知名的產(chǎn)品，比如 Tableau, QlikView, Power BI，國內(nèi)號稱已經(jīng)敏捷化的，比如永洪BI，帆軟FineBI和BDP。

此外，還有源自互聯(lián)網(wǎng)行業(yè)公司的產(chǎn)品新兵，比如阿里云的Quick BI，網(wǎng)易的網(wǎng)易有數(shù)，Amazon的QuickSight也是同類產(chǎn)品。而阿里云的DataV，則是奔著更炫的展示效果去的，比如我們前面說的雙十一大屏，智慧城市之類，BI數(shù)據(jù)分析功能不是它的重點

從產(chǎn)品自身定位的角度來說，這些商業(yè)化的產(chǎn)品并沒有太大的問題，我們造輪子，并不是因為他們的產(chǎn)品自身功能做得不夠好，比如圖例夠不夠豐富，用戶交互夠不夠直觀，操作夠不夠便捷之類。這方面的能力，是商業(yè)產(chǎn)品賴以生存的根基所在，別人家?guī)资畮装偃说膱F隊，經(jīng)過幾年十幾年的時間開發(fā)的產(chǎn)品，當(dāng)然不是我們派上個把同學(xué)，短時間內(nèi)自己造輪子能夠比得過的。別說我們，你看連企鵝爸爸在自己的公有云大數(shù)據(jù)套件服務(wù)上，提供的都是永洪的產(chǎn)品。

所以你要說是大家不想出錢用商業(yè)產(chǎn)品，所以自己開發(fā)么?也未必，且不說購買商業(yè)產(chǎn)品服務(wù)的價格和自己開發(fā)的代價哪個高，不要錢的開源產(chǎn)品也有不少啊，通用的，專用的都有，比如：

目標(biāo)定位為商業(yè)BI替代品的 Saiku /pantaho 體系

Airbnb租房公司自己玩得很high然后開源的Superset

ELK體系中為日志分析而生的Kibana

緣起OpenTSDB為監(jiān)控而生的Grafana

那么，問題來了，論成熟度和易用性你多半做不過商業(yè)產(chǎn)品，想“省錢”也有開源產(chǎn)品，為什么還要自己玩，是因為閑得慌么?樓上的Airbnb，還有阿里/騰訊/網(wǎng)易在不做公有云對外販賣BI服務(wù)之前，也都是自己開發(fā)自己用，大家都是沒事可做了么?

我個人以為，根本上還是由于一些應(yīng)用場景，商業(yè)產(chǎn)品難以適配的原因，至少，對于我司這類“互聯(lián)網(wǎng)”公司來說是這樣的 ;)

傳統(tǒng)的商業(yè)BI產(chǎn)品，基本上功能都很強大，但是部署和學(xué)習(xí)成本也比較高，而且往往流程定制化程度很高，和SAP等產(chǎn)品體系的整合做得也比較深入，所以基本上是屬于比較自洽和封閉的系統(tǒng)，它們的目標(biāo)是給你提供一整套完整的解決方案。

而公有云上的BI產(chǎn)品，雖然部署和學(xué)習(xí)成本相對較低(因為功能沒有成熟的商業(yè)產(chǎn)品那么紛繁復(fù)雜 )，但是，從自洽和封閉的角度來說，也是類似的，對接外部系統(tǒng)的能力較弱(或者說并不情愿)

比如，多數(shù)產(chǎn)品會提供從數(shù)據(jù)源采集，清洗到展示的定制流程，而用戶的權(quán)限管理，數(shù)據(jù)的存儲和生命周期管理，有些產(chǎn)品甚至連數(shù)據(jù)格式，都是自成體系的。此外，這些產(chǎn)品的內(nèi)部功能組件，數(shù)據(jù)結(jié)構(gòu)信息等，通常也不會以服務(wù)的形式對外暴露。

所以，在這種情況下，如果你的數(shù)據(jù)處理鏈路可以全部交給對應(yīng)的系統(tǒng)去管控，或者你所需要查詢展示的數(shù)據(jù)可以完全導(dǎo)入到對應(yīng)的系統(tǒng)中，又或者該產(chǎn)品能通過jdbc接口查詢你自己管理的數(shù)據(jù)，并且不存在性能等問題，那么問題不大，如果不行，就會比較難處理。

而想要和你自己的周邊系統(tǒng)進行流程上的集成，那基本上是不太可能的。想要拓展功能，比如添加個實時圖表展示能力，和開發(fā)平臺流程打通等等，也基本不用想了。

至于既有的開源的系統(tǒng)，雖然不存在封閉的問題，但其自身業(yè)務(wù)邏輯也往往比較固定和模式化，要改動成本也不低，能不能二次開發(fā)為你所用，也取決于你自己平臺的流程和功能定位。

總結(jié)下來，是直接使用商業(yè)產(chǎn)品，還是開源二次開發(fā)，又或者是完全自主開發(fā)，基本上是按照你的業(yè)務(wù)復(fù)雜度和你所使用的周邊系統(tǒng)的生態(tài)環(huán)境來決定的，通常情況下，你的業(yè)務(wù)模式也復(fù)雜，你需要自主開發(fā)的可能性就越高。但是，不排除你可以針對不同的場景需求，采用不同的解決方案來最小化總體代價。

最后嘮叨一下，你要問，商業(yè)或開源產(chǎn)品難道就不可能成熟到可以很好的適配各種復(fù)雜應(yīng)用場景么? 理論上，我認(rèn)為是有可能的，但就目前來看，至少幾年內(nèi)不太現(xiàn)實，因為

首先在大數(shù)據(jù)領(lǐng)域里，底層的存儲和計算引擎差異巨大，遠還沒有達到標(biāo)準(zhǔn)檢索方式能一統(tǒng)天下的局面，各種業(yè)務(wù)組件和流程往往需要定制和靈活適配處理邏輯。

其次，現(xiàn)有的比較成熟的產(chǎn)品，其封閉的邏輯思維要打破，首先受其商業(yè)模式的限制，未必愿意，而即使愿意，也需要花費很長的時間才能逐步完成。

最后，針對大數(shù)據(jù)領(lǐng)域應(yīng)用場景的結(jié)合，說實話，我對傳統(tǒng)背景廠商的產(chǎn)品在這方面的研發(fā)能力，是表示懷疑的，這不是投幾個人的問題，而是思維方式和產(chǎn)品定位的問題。當(dāng)你的多數(shù)用戶對這類場景沒有復(fù)雜需求的時候，你即沒有經(jīng)驗，也不可能把精力投入到小眾專家用戶的需求上去。這點，橫向類比的看看公有云服務(wù)廠商所提供hadoop集群服務(wù)就知道了，基本都是用最基礎(chǔ)最簡單的功能去滿足絕大多數(shù)小白用戶的需求，減少服務(wù)的變數(shù)和風(fēng)險，才是他們保證產(chǎn)品成功的關(guān)鍵，定制?靈活?統(tǒng)統(tǒng)免談。

具體產(chǎn)品需求分析

對我司來說，我們自主開發(fā)的數(shù)據(jù)可視化系統(tǒng)，既不打算追求界面的酷炫，也不打算追求各種組件的極度豐富，和大數(shù)據(jù)生態(tài)系各種組件的配合，和公司內(nèi)部各種私有數(shù)據(jù)源的打通，與周邊系統(tǒng)和開發(fā)平臺開發(fā)流程的深度集成，對數(shù)據(jù)權(quán)限和用戶的全面自主管控，才是核心所在。

所以我司數(shù)據(jù)可視化系統(tǒng)的產(chǎn)品設(shè)計目標(biāo)如下：

產(chǎn)品定位

總體目標(biāo)定位是通用的數(shù)據(jù)圖表可視化服務(wù)后臺，不僅局限于BI業(yè)務(wù)，也希望通過自定義配置的方式，可以支持各類有數(shù)據(jù)展示需求的業(yè)務(wù)后臺。使用方提供數(shù)據(jù)來源，我們負(fù)責(zé)提供平臺和可視化服務(wù)，通過簡單的配置，完成大多數(shù)圖表展示業(yè)務(wù)所需的功能，節(jié)省圖表開發(fā)人員的工作量，節(jié)省其它業(yè)務(wù)后臺開發(fā)人員的工作量。

使用模式上，希望盡可能的讓用戶能夠自主定義和管理相關(guān)自己的圖表，從開發(fā)，查詢，檢索到權(quán)限管控，都盡量讓用戶能夠自主的完成，無需管理員或者平臺開發(fā)者介入，降低平臺維護成本。

　　大的產(chǎn)品功能維度

以頁面維度為單位進行自定義配置開發(fā)，頁面中可以自由添加多個圖表展示控件

支持自定義圖表頁面布局的能力，包括但不限于Frame/Column等基礎(chǔ)布局組件

支持常用的圖表和文本組件，支持過濾器等組件，提供參數(shù)化配置組件的能力

標(biāo)準(zhǔn)化數(shù)據(jù)源接口，可動態(tài)拓展新的數(shù)據(jù)源

提供基礎(chǔ)的數(shù)據(jù)分析和格式化配置能力，支持如同比，環(huán)比，聚合運算，閾值基線，維度層級定義等功能

查看數(shù)據(jù)的終端用戶，能夠自定義數(shù)據(jù)視圖，可以進行排序，過濾，鉆取分析，局部縮放等動作

支持定時動態(tài)刷新圖表，支持實時數(shù)據(jù)展示業(yè)務(wù)

支持個人業(yè)務(wù)視圖，支持圖表收藏訂閱等功能

多租戶管理和用戶權(quán)限維度

支持可嵌套的業(yè)務(wù)分組能力，支持按目錄結(jié)構(gòu)樹分級授權(quán)管理可視化圖表，授權(quán)范圍為業(yè)務(wù)組自身頂級目錄以下的所有內(nèi)容包括子目錄

業(yè)務(wù)組管理員角色可以管理組內(nèi)用戶，進行角色配置，目錄審核，審批(增刪改等)

支持對各類圖表設(shè)置不同的安全等級，區(qū)別管理，高安全等級的報表，目錄，角色的管理，需要走審批流程

支持圖表元數(shù)據(jù)信息的檢索，在沒有詳情權(quán)限的情況下，支持列表和簡介瀏覽，便于自主申請權(quán)限

和周邊系統(tǒng)的開放集成維度

支持圖表的郵件訂閱，定時以郵件形式發(fā)送圖表內(nèi)容

支持可視化頁面嵌入第三方后臺，便于第三方后臺集成具體圖表進行展示，節(jié)省開發(fā)工作量

支持以API的形式根據(jù)模版創(chuàng)建圖表，便于和開發(fā)平臺等外部后臺集成，支持一些快速自動生成圖表的業(yè)務(wù)場景。

部分產(chǎn)品需求的實踐詳解

頁面布局開發(fā)流程方面

在頁面布局這一部分，理想的情況，你可能會希望做到，隨意拖拽，所見即所得，但我們沒有走這條路，而是顯式的提供了列布局等控件，通過配置參數(shù)的形式(比如需要幾列，長寬多少)來決定最終頁面的布局情況。

原因有兩個，其一，說實話，我們沒有那么多的人手來開發(fā)這種拖拽式的交互頁面，其二，拖拽這種形式，如果不能做到極度智能，收益并不明顯，甚至對于要求精確控制布局的場景，操作起來反而更加繁瑣。你看阿里云的DataV，這種極度看重展現(xiàn)形式的應(yīng)用，拖拽布局的功能改版過幾次就知道了。而多數(shù)用戶在絕大多數(shù)場景下，頁面布局都是相對簡單標(biāo)準(zhǔn)的，參數(shù)化的操作形式可能反而更加簡潔。

頁面整體展示和具體的圖表控件配置流程方面

對于頁面布局和具體組件的配置，不少的商業(yè)系統(tǒng)都是走的獨立配置和管理的路，比如，你為一個數(shù)據(jù)庫表格，添加一個折線圖的控件進行展示，這個折線圖控件，就是一個圖表。而整合了多個圖表控件，最終提供給用戶查看的頁面，可能被叫做儀表盤(Dashboard)。在開發(fā)配置流程上，它們是獨立的，一個管具體數(shù)據(jù)展現(xiàn)形式，一個管頁面布局。

而在我司的可視化系統(tǒng)中，用戶進行圖表配置開發(fā)時，最小的管理單位就是頁面(你可以理解為就是其他家所說的儀表盤)，在頁面內(nèi)添加多個控件，然后編輯這些控件，控件對本頁面外的其它頁面來說是不共享，不可見的。

這兩者的選擇，我們也是經(jīng)過權(quán)衡的，前者的優(yōu)勢是控件可以在多個儀表盤之間共享，目標(biāo)顯然是為了能夠復(fù)用控件，降低開發(fā)工作量。

但是，我們認(rèn)為，這是一個相對理想的愿望，實際上共享起來也面臨很多的問題，比如權(quán)限的管理授權(quán)方面就會更加復(fù)雜，有更多的對象要管理和授權(quán)，然后，信息同步也是問題，如果共享這個控件的幾個儀表盤是由不同的同學(xué)負(fù)責(zé)，那么誰對控件說了算?或者之后不同的儀表盤對這個空間的展現(xiàn)形式有了不同的需求，怎么辦等等。這些問題，當(dāng)然都能找到解決方案，但是在業(yè)務(wù)，流程方面的溝通代價也就更高了。此外操作流程上也會更加繁瑣一點(這個倒不是最大的問題)

當(dāng)然，如何取舍，最終還是取決于在你的實際應(yīng)用場景中那種方案綜合代價最低。就我們的場景來說，目前看來，在儀表盤之間共享完全一樣的圖表控件的需求并不大，方便權(quán)限和業(yè)務(wù)管理，盡可能簡化開發(fā)流程，相對來說反而更加重要一點。

具體控件功能支持方面

在控件類型豐富度和參數(shù)配置靈活度方面，如果你去比對一下國內(nèi)的商業(yè)產(chǎn)品，你會發(fā)現(xiàn)這往往是他們的賣點之一，這個說我有火焰圖，字符云，那個說我支持任意雙樣式圖例等等。至于字體大小樣式，線條顏色粗細，數(shù)據(jù)點形狀大小，文字對齊方式，邊框距離之類的各種參數(shù)多半也都是可以自定義調(diào)整的。

這么靈活的配置，必然也是有代價的，工作量擺在那里，沒有幾十人的團隊打底，這些玩意，絕對是做不出來的～～～

你說這些功能有沒有用，肯定有用，有總比沒有強(除了用戶界面難免更加復(fù)雜以外)。但是常不常用，該不該用，有些時候，我覺得往往是走入誤區(qū)的。不是說系統(tǒng)具備這些功能有什么不好，而是說很多時候用戶為了炫而炫的用法，恨不得把頁面畫成彩虹，在儀表盤里把所有的控件和顏色用個遍。。。這往往就脫離了數(shù)據(jù)可視化的本質(zhì)目的：更簡單，更直觀，更高效的理解數(shù)據(jù)。

事實上，對于可視化系統(tǒng)上的業(yè)務(wù)來說，如何用合理的方式組織數(shù)據(jù)，讓目標(biāo)用戶快速的掌握情況，發(fā)現(xiàn)問題，得到結(jié)論，這才是工作的重點。

思維方式的不同，其實在國外和國內(nèi)的BI商業(yè)產(chǎn)品的實現(xiàn)身上也看得到一些跡象，為了迎合國內(nèi)很多企業(yè)追求絢麗花哨的展示效果的需求，國內(nèi)的產(chǎn)品在UI視圖展現(xiàn)方面花了很多力氣，幾乎無所不能，但是在流程管控，系統(tǒng)穩(wěn)定性，處理數(shù)據(jù)的能力和效率，以及開發(fā)模式和工具標(biāo)準(zhǔn)化等方面投入的精力相比國外成熟產(chǎn)品，就少了很多。

對于我司自研的可視化系統(tǒng)而言，客觀的來說，我們在控件豐富度和配置的靈活度方面和商業(yè)產(chǎn)品相比較，是有不小的差距的。但這其中，我個人認(rèn)為計算和展示方面功能性的改進，優(yōu)先級遠高于UI視覺效果方面的改進;常用核心控件易用性的改進，優(yōu)先級遠高于整體控件種類豐富度的改進。

目前我司的可視化系統(tǒng)支持如下控件，感覺已經(jīng)稍微有點多了，現(xiàn)階段還是應(yīng)該重點加強基礎(chǔ)控件的功能和易用性改進

　　數(shù)據(jù)源支持方面

對于傳統(tǒng)的BI工具來說，數(shù)據(jù)都在RDBMS中，語法相對規(guī)范，所以數(shù)據(jù)源的支持不是什么大問題，而對于大數(shù)據(jù)環(huán)境下的可視化系統(tǒng)來說，外部數(shù)據(jù)來源種類繁多，應(yīng)用模式復(fù)雜，能靈活的適配支持各種數(shù)據(jù)源，就變得非常重要。

透過JDBC去獲取數(shù)據(jù)是最常見的形式。理論上來說，如果后端引擎的查詢效率足夠好，并且提供類SQL方言的查詢語法，那么通過JDBC接口對接外部數(shù)據(jù)源就是一個較為理想的方案

但是，這里面最主要的問題是，不同的后端引擎對SQL的支持程度并不完全一樣，特別是那些非傳統(tǒng)RDBMS的引擎，比如Hive，實際使用的是HQL語法，和SQL標(biāo)準(zhǔn)并不完全兼容，而在性能方面，不同的引擎往往也有各自的優(yōu)化方式和最佳實踐模式。

所以，如何拓展數(shù)據(jù)源，并沒有一個完美通用的解決方案。JDBC的方案能解決一大部分問題，其它數(shù)據(jù)源要么可能要針對性的寫對應(yīng)的接口，要么可能需要經(jīng)過導(dǎo)入轉(zhuǎn)換的過程來解決。

不過，JDBC的接口，從基礎(chǔ)功能和SQL語法設(shè)計的角度來說，也未必完全滿足可視化系統(tǒng)的需求，主要的問題是在OLAP即時分析類應(yīng)用場景下，需要對數(shù)據(jù)進行各種維度的聚合操作，以支持靈活的下鉆和上卷分析功能。這些功能往往不是所有的后端數(shù)據(jù)庫或存儲查詢引擎都能較好的支持的。

此外OLAP類應(yīng)用往往還需要定義各種維度指標(biāo)模型或Cube模型，為了提升性能，可能還需要實現(xiàn)針對數(shù)據(jù)或者針對查詢的Cache緩存層。

以上兩點，總結(jié)來說，就是在面向用戶的展示配置表達層，和面向數(shù)據(jù)的存儲引擎層之間，是否需要實現(xiàn)一個通用的聚合運算層來銜接。這部分工作，在國內(nèi)多數(shù)的BI商業(yè)產(chǎn)品中往往并沒有實現(xiàn)。

當(dāng)然，自己做一層聚合運算層，其實是很困難的，這一中間層做得越好，對底層引擎的依賴固然越少，拓展數(shù)據(jù)源的能力也越強，但是實現(xiàn)的代價也就越高。而且針對不同的底層引擎，一些計算下推下去執(zhí)行，效率可能會更高，但每個引擎如何適配，哪些在計算層處理，哪些交給后端引擎處理，在非RDBMS的領(lǐng)域中，往往沒有固定答案，具體流程也可能千差萬別，所以界限并不是那么容易劃分。因此至今為止，市面上也并沒有太理想的方案。

不過，單純就OLAP查詢表達邏輯這一點來說，相對常見的做法是在用戶配置表達層和JDBC/SQL執(zhí)行層之間，添加一層基于MDX語法的OLAP查詢語義層，用來承載業(yè)務(wù)邏輯的語義描述，然后通過類似Mondrian之類的引擎翻譯成SQL語法去執(zhí)行。在這個過程中，這些中間服務(wù)引擎可以針對OLAP的場景做一些優(yōu)化，比如我們上面所說的，做一些聚合運算，緩存優(yōu)化之類的工作。

我司當(dāng)前的實現(xiàn)，基本上還是抽象在了JDBC/SQL語法這一層面上，在此之上做了少量的聚合操作，此外，對一些后端引擎的SQL方言做了兼容處理，并且支持我司內(nèi)部一些自研的數(shù)據(jù)源。總體來說，這方面的工作還需要進一步的改進。

用戶查詢使用方面

相對傳統(tǒng)的定制開發(fā)的報表系統(tǒng)，可視化系統(tǒng)以控件的方式支持全自助圖表開發(fā)，目的是為了提高了圖表開發(fā)者的工作效率，增強應(yīng)用模式。

而用戶查詢使用方面的產(chǎn)品功能設(shè)計，針對的則是圖表查閱者的使用效率。對于查看數(shù)據(jù)的終端用戶來說，能夠按照自己的思維模式，從不同的角度去查看數(shù)據(jù)，同樣是拓展應(yīng)用模式，提高工作效率的有效手段

所以，我們會需要比如排序，過濾，鉆取，縮放等等在圖表查詢時的自定義手段

進一步的來說，如果終端用戶可以通過自定義查詢視圖的手段來定制數(shù)據(jù)展現(xiàn)形式，那么實際上，對于圖表開發(fā)者來說，很有可能就可以花費更少的時間去關(guān)注和配置一些與視圖展現(xiàn)相關(guān)的邏輯。

比如用表格還是折線圖來展示數(shù)據(jù)，哪些字段需要做匯總，提供哪些過濾條件等等，從報表開發(fā)者的角度來說，往往沒有絕對的對錯，而是取決于終端用戶查詢的需求和目的。

如果這些部分用戶可以簡單快速的在查詢時進行定制，那么就沒有必要在圖表開發(fā)時專門進行配置了，從而間接的提高了圖表開發(fā)者的工作效率，讓他們可以集中精力去關(guān)注維度指標(biāo)和運算邏輯等真正和數(shù)據(jù)模型相關(guān)的內(nèi)容。

實時業(yè)務(wù)支持方面

實時數(shù)據(jù)業(yè)務(wù)的數(shù)據(jù)可視化支持工作，多數(shù)的商業(yè)BI系統(tǒng)其實并不能完全高效的承載，原因有兩點：

一是數(shù)據(jù)源方面，實時流式數(shù)據(jù)的接入形式和傳統(tǒng)靜態(tài)圖表JDBC形式的輸入源還是有比較大的差別的，比如它的數(shù)據(jù)來源可能是消息隊列。

對此，你可以通過將數(shù)據(jù)實時刷新到DB中，定時輪詢的方式來實現(xiàn)，以此來規(guī)避對實時數(shù)據(jù)源的處理。對于絕大多數(shù)場景，這是一種確實可行的方案。當(dāng)然，為了達到這個目標(biāo)，對系統(tǒng)和整體數(shù)據(jù)處理鏈路還是有一些要求的，比如可視化系統(tǒng)支持定時刷新圖表，此外數(shù)據(jù)源的更新必須足夠迅速(需要從外部系統(tǒng)批量導(dǎo)入數(shù)據(jù)，處理轉(zhuǎn)換成內(nèi)部數(shù)據(jù)結(jié)構(gòu)的這類BI系統(tǒng)，就卡殼了)

二是圖表的展現(xiàn)形式，可能和傳統(tǒng)離線靜態(tài)圖表有一些不同。舉例來說：比如你要配置一個實時監(jiān)控業(yè)務(wù)數(shù)據(jù)，你可能需要滑動刷新展示最近一個小時時間窗口的數(shù)據(jù)，你也可能需要和昨日對應(yīng)時刻的數(shù)據(jù)進行環(huán)比對照，連續(xù)的數(shù)據(jù)流，數(shù)據(jù)時間間隔不固定，個數(shù)不固定，一天內(nèi)未來時間點的數(shù)據(jù)還沒有生成，圖表展示范圍如何正確處理，X軸坐標(biāo)如何生成等等。

這些問題嚴(yán)格說來，也不見得在離線圖表的場景下絕對不會遇到，只是通常來說，離線圖表在這些方面通常沒有強烈的需求，所以市面上的系統(tǒng)在這方面的功能實現(xiàn)和產(chǎn)品形態(tài)考慮方面就會薄弱很多。

但實際上，從可視化的角度來說，實時業(yè)務(wù)的數(shù)據(jù)可視化需求，絕大多數(shù)的功能需求還是可以和靜態(tài)圖表業(yè)務(wù)復(fù)用的。而且隨著實時數(shù)據(jù)業(yè)務(wù)需求的日益增多，兩者之間的應(yīng)用邊界其實也越來越模糊，這種情況下，如果能做到一個系統(tǒng)承接兩種業(yè)務(wù)，當(dāng)然是最好了。

我司的可視化系統(tǒng)，從整體流程上來說，比如自動刷新圖表等功能是具備的，為了承接實時業(yè)務(wù)，一些圖表控件也做了少量的適配工作，不過在實時數(shù)據(jù)展現(xiàn)方面，更多的還是依靠預(yù)處理數(shù)據(jù)(比如對橫坐標(biāo)時間軸進行人工分段處理)，去適配靜態(tài)圖表的展示形式，配置的難度還比較大，后續(xù)需要考慮進一步簡化流程。

多租戶和用戶權(quán)限管控方面

我司的可視化系統(tǒng)定位的是一個開放的服務(wù)平臺，服務(wù)的對象不僅針對數(shù)倉/BI等團隊，所以有必要通過多租戶的形式來支持不同的業(yè)務(wù)方。

而要避免多租戶之間相互影響，就需要進行隔離管控。通過分級授權(quán)，可以將整個可視化系統(tǒng)的圖表目錄樹結(jié)構(gòu)拆分成獨立的業(yè)務(wù)組進行管理。

每個業(yè)務(wù)組目錄范圍內(nèi)的圖表，目錄結(jié)構(gòu)等完全由業(yè)務(wù)組各自的管理員獨立管理，日常的角色，權(quán)限分配，流程審批等，也不需要平臺超級管理員進行干預(yù)，業(yè)務(wù)組內(nèi)部可以再創(chuàng)建子業(yè)務(wù)組，進一步分隔權(quán)限。只有在新建頂層業(yè)務(wù)組時需要召喚平臺超級管理員。

這樣做的目的是盡可能對業(yè)務(wù)方充分授權(quán)，能夠獨立對自己所負(fù)責(zé)的對象進行自主管轄和二次授權(quán)。同時又不至于對其它租戶的業(yè)務(wù)造成影響。

從我們的實踐來看，這種方案從功能的角度來看，可以實現(xiàn)我們的預(yù)設(shè)目標(biāo)，不過，真正要發(fā)揮作用，還是需要用戶能夠利用好這些功能機制，畢竟業(yè)務(wù)組的管理，目錄結(jié)構(gòu)的整理等等還是有一些工作要做的。

很多情況下，為了圖一時之方便，不少用戶并不愿意做這種梳理工作，巴不得人人都是超級管理員，想干啥干啥，這樣一來風(fēng)險其實就不可控了，業(yè)務(wù)組的價值也就小了很多。這點需要平臺開發(fā)者進一步思考簡化管理的可能，并對用戶進行最佳實踐的引導(dǎo)。

至于圖表和角色安全等級的設(shè)置，主要是為了加強敏感數(shù)據(jù)的安全管控工作。不同等級的圖表，具體申請過程中，需要審批的環(huán)節(jié)各不相同，最低等級的圖表，無需申請，就是完全公開的。最高等級的圖表，需要高層領(lǐng)導(dǎo)和風(fēng)控團隊參與審批，而中間等級的圖表，一般只需要圖表負(fù)責(zé)人或者業(yè)務(wù)負(fù)責(zé)人審批就可以了。

為了防止圖表授權(quán)出去以后，就收不回來的現(xiàn)象，申請流程中加入了生命周期的管理，過期的圖表自動收回權(quán)限。

周邊系統(tǒng)集成方面

上面的多租戶能力是從用戶和業(yè)務(wù)的角度討論平臺的開放性，而這一節(jié)，是從系統(tǒng)集成的角度來討論平臺的開放性。

除了讓用戶登陸系統(tǒng)查看數(shù)據(jù)，我們還提供通過郵件訂閱的形式定時發(fā)送圖表數(shù)據(jù)給訂閱者。當(dāng)然這種模式下，用戶就無法進行一些復(fù)雜的交互操作了，不過多數(shù)情況下，日常快速瀏覽數(shù)據(jù)還是足夠的。

另外，實際上，我們的可視化系統(tǒng)的定位，所服務(wù)的業(yè)務(wù)并不是單一的報表系統(tǒng)。大量的業(yè)務(wù)后臺，都需要展示自己的業(yè)務(wù)數(shù)據(jù)，雖然數(shù)據(jù)不同，但是展現(xiàn)形式多半還是類似的，那么能不能輸出可視化平臺既有的圖表配置開發(fā)能力和業(yè)務(wù)管控流程，減少這些業(yè)務(wù)后臺的開發(fā)工作量呢?

這一般有兩種做法，一是提供可復(fù)用的代碼組件，業(yè)務(wù)方在此基礎(chǔ)上自主開發(fā)，這種形式可以節(jié)省一部分的控件開發(fā)代價，但是整體的管控流程和配置化的開發(fā)方式還是沒法復(fù)用。所以，我們提供的是頁面嵌入第三方后臺的服務(wù)能力。

業(yè)務(wù)方可以在可視化平臺上通過配置的方式開發(fā)自己的圖表頁面，然后通過特定的服務(wù)接口，獲取這些頁面，嵌入到自己的后臺上進行展示和交互。這樣既降低了第三方后臺開發(fā)者的開發(fā)代價，使用過程中，用戶也無需跳轉(zhuǎn)到可視化平臺，整體體驗較好。

要支持頁面嵌入第三方后臺的功能，主要需要考慮的是用戶權(quán)限的傳遞管控和交互模式的銜接，這些都不算太難，只是形態(tài)方面要考慮周全。

產(chǎn)品改進目標(biāo)

產(chǎn)品的改進目標(biāo)，前面多少也提到過了一些，這里再統(tǒng)一整理總結(jié)一下

可視化組件改進

先看一下我司可視化平臺內(nèi)，各種組件的使用頻率數(shù)據(jù)

從上圖大致可以看到，整體來說，當(dāng)前，我司的可視化平臺內(nèi)，95%以上的圖表只會使用類似表格/折線圖/柱狀圖/餅圖/文本這類最基礎(chǔ)的控件。這說明了兩個問題：

第一，多數(shù)業(yè)務(wù)的數(shù)據(jù)展示，真的不需要稀奇古怪的展示形式，標(biāo)準(zhǔn)的形式覆蓋了多數(shù)的需求。

第二，一些直覺來說應(yīng)該也比較很常用/有用的控件，當(dāng)前的實際使用頻率如此之低，未必真的合理。可能的原因包括：新開發(fā)的控件推廣不夠，業(yè)務(wù)方的使用思維還停留在簡單表格階段;這些控件的功能和易用性還比較粗糙，難用，業(yè)務(wù)方不意愿使用。

所以，針對上述問題，可視化組件改進的重點，應(yīng)該會是：

加強常用核心控件的改進，借鑒商業(yè)產(chǎn)品中這部分控件的功能形態(tài)設(shè)計，進一步重點提升它們的功能和易用性，讓價值產(chǎn)出最大化

針對使用頻率低得不合理的控件，調(diào)研分析，找到阻礙用戶使用的問題點，改進形態(tài)，加強推廣。

至于控件種類的擴展和與功能無關(guān)的視覺效果方面的改進，除非絕對必要，否則暫不考慮。

配色方面，考慮到頁面嵌入第三方后臺，進行系統(tǒng)集成時不要太違和，可以考慮頁面整體提供顏色主題模版供用戶選擇。

加強終端用戶自定義視圖能力

如前所述，增強終端用戶自定義視圖的能力，可以拓展用戶的應(yīng)用模式，提高查詢數(shù)據(jù)的工作效率，也能降低圖表開發(fā)者的開發(fā)代價。這方面，在我司可視化平臺現(xiàn)有功能的基礎(chǔ)上，可以改進的工作包括但不限于：

支持查詢時自定義聚合操作，比如用戶在查詢時可以自定義特定字段的聚合條件，做一些簡單的類似求和/求平均之類的統(tǒng)計操作，不需要報表開發(fā)者在配置圖表階段進行定義，或者迫使用戶下載數(shù)據(jù)后再扔到Execl之類的軟件中另行處理。

支持查詢時自主定義過濾組件，無需報表開發(fā)者提前配置可用于執(zhí)行過濾的字段和過濾用組件。

支持查詢時控件切換能力，比如折線圖切換成柱狀圖等，可以在有限的功能范圍內(nèi)，允許終端用戶自主選擇合適的展現(xiàn)形式。當(dāng)然，前提是這種切換是合理的，比如數(shù)據(jù)量大小，維度與控件的邏輯和應(yīng)用模式是否匹配等等

支持查詢時自定義數(shù)據(jù)同環(huán)比對比，基線閥值等能力。基本上任何數(shù)據(jù)，終端查詢用戶都有可能有與歷史數(shù)據(jù)比對的需求，完全靠圖表開發(fā)者來配置相關(guān)功能也是不太現(xiàn)實的。

總結(jié)來說，就是任何數(shù)據(jù)視圖方面的配置，如果沒有特殊需求(比如強制過濾條件，限制用戶的查詢范圍)必須預(yù)定義的，那么它們的變更和設(shè)定，都可以考慮從圖表配置階段挪到圖表查詢階段來實現(xiàn)，交給最終用戶來選擇，圖表開發(fā)者只提供必需的默認(rèn)值。

拓展數(shù)據(jù)源，增強OLAP業(yè)務(wù)能力

一方面適當(dāng)考慮接入開源的第三方中間層，比如Saiku，Mondrian等框架中的中間層部分，另一方面不排除定制適配一些OLAP類引擎數(shù)據(jù)源的可能性，總體目標(biāo)都是提高處理海量數(shù)據(jù)的能力，接入更多的OLAP類應(yīng)用場景

增強實時數(shù)據(jù)業(yè)務(wù)展示能力

如前所述，我們當(dāng)前要接入實時數(shù)據(jù)業(yè)務(wù)的展示，圖表開發(fā)配置的代價還比較高，需要進一步考慮針對實時連續(xù)數(shù)據(jù)流的場景，如何優(yōu)化配置流程和展示形式。

增強對第三方平臺的服務(wù)能力

目前我們所支持的比如郵件訂閱，頁面嵌入第三方平臺等服務(wù)能力，基本上都是屬于預(yù)定義圖表，然后單向輸出的形式。

但是實際上，還有很大一部分的第三方平臺，需要即時渲染數(shù)據(jù)的能力，比如用戶在數(shù)據(jù)開發(fā)平臺的WebIDE界面上，運行了一個腳本，想要將結(jié)果以圖形化方式展示出來。

如果可視化平臺能夠通過API接口，將圖形渲染功能服務(wù)化，對外提供即時定義圖表和數(shù)據(jù)渲染，圖形輸出的能力，那么也就能夠滿足這部分平臺的數(shù)據(jù)展示需求了。要提供這樣的服務(wù)，難點還是在于如何進行高效的數(shù)據(jù)傳輸和權(quán)限管控。

其它雜類

對移動端展示平臺的支持

多租戶的進一步隔離，比如提供獨立URL，提供物理隔離的資源部署(比如針對第三方渲染服務(wù)，OLAP類計算密集業(yè)務(wù)等場景，就有可能有這樣的資源隔離需求)的能力