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

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

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

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

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

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

　　好吧，是，也不是。

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

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

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

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

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

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

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

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

商業(yè)化的BI產(chǎn)品廠商很多，國外比較知名的產(chǎn)品，比如 Tableau, QlikView, Power BI，國內(nèi)號(hào)稱已經(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ù)分析功能不是它的重點(diǎn)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

最后，針對大數(shù)據(jù)領(lǐng)域應(yīng)用場景的結(jié)合，說實(shí)話，我對傳統(tǒng)背景廠商的產(chǎn)品在這方面的研發(fā)能力，是表示懷疑的，這不是投幾個(gè)人的問題，而是思維方式和產(chǎn)品定位的問題。當(dāng)你的多數(shù)用戶對這類場景沒有復(fù)雜需求的時(shí)候，你即沒有經(jīng)驗(yàn)，也不可能把精力投入到小眾專家用戶的需求上去。這點(diǎn)，橫向類比的看看公有云服務(wù)廠商所提供hadoop集群服務(wù)就知道了，基本都是用最基礎(chǔ)最簡單的功能去滿足絕大多數(shù)小白用戶的需求，減少服務(wù)的變數(shù)和風(fēng)險(xiǎn)，才是他們保證產(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ā)平臺(tái)開發(fā)流程的深度集成，對數(shù)據(jù)權(quán)限和用戶的全面自主管控，才是核心所在。

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

產(chǎn)品定位

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

具體控件功能支持方面

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

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

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

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

思維方式的不同，其實(shí)在國外和國內(nèi)的BI商業(yè)產(chǎn)品的實(shí)現(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)品相比較，是有不小的差距的。但這其中，我個(gè)人認(rèn)為計(jì)算和展示方面功能性的改進(jìn)，優(yōu)先級遠(yuǎn)高于UI視覺效果方面的改進(jìn);常用核心控件易用性的改進(jìn)，優(yōu)先級遠(yuǎn)高于整體控件種類豐富度的改進(jìn)。

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

　　數(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ù)源就是一個(gè)較為理想的方案

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

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

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

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

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

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

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

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

用戶查詢使用方面

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

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

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

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

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

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

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

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

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

對此，你可以通過將數(shù)據(jù)實(shí)時(shí)刷新到DB中，定時(shí)輪詢的方式來實(shí)現(xiàn)，以此來規(guī)避對實(shí)時(shí)數(shù)據(jù)源的處理。對于絕大多數(shù)場景，這是一種確實(shí)可行的方案。當(dāng)然，為了達(dá)到這個(gè)目標(biāo)，對系統(tǒng)和整體數(shù)據(jù)處理鏈路還是有一些要求的，比如可視化系統(tǒng)支持定時(shí)刷新圖表，此外數(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)圖表有一些不同。舉例來說：比如你要配置一個(gè)實(shí)時(shí)監(jiān)控業(yè)務(wù)數(shù)據(jù)，你可能需要滑動(dòng)刷新展示最近一個(gè)小時(shí)時(shí)間窗口的數(shù)據(jù)，你也可能需要和昨日對應(yīng)時(shí)刻的數(shù)據(jù)進(jìn)行環(huán)比對照，連續(xù)的數(shù)據(jù)流，數(shù)據(jù)時(shí)間間隔不固定，個(gè)數(shù)不固定，一天內(nèi)未來時(shí)間點(diǎn)的數(shù)據(jù)還沒有生成，圖表展示范圍如何正確處理，X軸坐標(biāo)如何生成等等。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

可視化組件改進(jìn)

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

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

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

第二，一些直覺來說應(yīng)該也比較很常用/有用的控件，當(dāng)前的實(shí)際使用頻率如此之低，未必真的合理?？赡艿脑虬ǎ盒麻_發(fā)的控件推廣不夠，業(yè)務(wù)方的使用思維還停留在簡單表格階段;這些控件的功能和易用性還比較粗糙，難用，業(yè)務(wù)方不意愿使用。

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

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

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

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

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

加強(qiáng)終端用戶自定義視圖能力

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

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

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

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

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

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

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

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

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

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

增強(qiáng)對第三方平臺(tái)的服務(wù)能力

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

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

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

其它雜類

對移動(dòng)端展示平臺(tái)的支持

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