前面說完了大數(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ù)懸浮圖層巩掺，隱隱流淌出一股運(yùn)籌帷幄，決勝千里的氣質(zhì)的XX智慧城市系統(tǒng)呢页畦？

又或者胖替，是近有裸眼3D VR現(xiàn)實，遠(yuǎ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ū)分開來，改進(jìn)了目標(biāo)定位和功能特性的報表系統(tǒng)當(dāng)然就不好意思再叫這個名字了耍共。最起碼烫饼，也得冠上個BI商業(yè)智能系統(tǒng)的頭銜 ；）

所以试读，你看杠纵，市面上知名度較高的報表類系統(tǒng)，不叫BI都不敢出來混钩骇，如果逼格高一點的比藻，哪怕在外圍用上了一點點分布式計算技術(shù)的铝量，那還必須得叫敏捷BI，以示和“老朽緩慢的”傳統(tǒng)商業(yè)智能系統(tǒng)劃清界限银亲。然后大家都“敏捷”了慢叨，怎么辦？那就要返璞歸真強(qiá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(tuán)隊，經(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)品璧亮，基本上功能都很強(qiáng)大萧诫，但是部署和學(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)進(jìn)行流程上的集成猾漫，那基本上是不太可能的点晴。想要拓展功能，比如添加個實時圖表展示能力悯周，和開發(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)域里，底層的存儲和計算引擎差異巨大蛙粘，遠(yuǎn)還沒有達(dá)到標(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ā)者介入，降低平臺維護(hù)成本蹂析。

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

• 以頁面維度為單位進(jìn)行自定義配置開發(fā)舔示，頁面中可以自由添加多個圖表展示控件
• 支持自定義圖表頁面布局的能力碟婆，包括但不限于Frame／Column等基礎(chǔ)布局組件
• 支持常用的圖表和文本組件，支持過濾器等組件惕稻，提供參數(shù)化配置組件的能力
• 標(biāo)準(zhǔn)化數(shù)據(jù)源接口竖共，可動態(tài)拓展新的數(shù)據(jù)源
• 提供基礎(chǔ)的數(shù)據(jù)分析和格式化配置能力，支持如同比俺祠，環(huán)比公给，聚合運(yùn)算，閾值基線蜘渣，維度層級定義等功能
• 查看數(shù)據(jù)的終端用戶淌铐，能夠自定義數(shù)據(jù)視圖，可以進(jìn)行排序宋梧，過濾匣沼，鉆取分析，局部縮放等動作
• 支持定時動態(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)用戶唇撬，進(jìn)行角色配置，目錄審核展融，審批（增刪改等）
• 支持對各類圖表設(shè)置不同的安全等級窖认，區(qū)別管理，高安全等級的報表告希，目錄扑浸，角色的管理，需要走審批流程
• 支持圖表元數(shù)據(jù)信息的檢索燕偶，在沒有詳情權(quán)限的情況下喝噪，支持列表和簡介瀏覽，便于自主申請權(quán)限

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

• 支持圖表的郵件訂閱指么，定時以郵件形式發(fā)送圖表內(nèi)容
• 支持可視化頁面嵌入第三方后臺酝惧，便于第三方后臺集成具體圖表進(jìn)行展示，節(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ù)庫表格筷狼，添加一個折線圖的控件進(jìn)行展示瓶籽，這個折線圖控件，就是一個圖表埂材。而整合了多個圖表控件塑顺，最終提供給用戶查看的頁面，可能被叫做儀表盤（Dashboard）楞遏。在開發(fā)配置流程上茬暇，它們是獨立的首昔，一個管具體數(shù)據(jù)展現(xiàn)形式寡喝，一個管頁面布局。

而在我司的可視化系統(tǒng)中勒奇，用戶進(jìn)行圖表配置開發(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)這往往是他們的賣點之一，這個說我有火焰圖撮珠，字符云沮脖，那個說我支持任意雙樣式圖例等等。至于字體大小樣式，線條顏色粗細(xì)勺届，數(shù)據(jù)點形狀大小驶俊，文字對齊方式，邊框距離之類的各種參數(shù)多半也都是可以自定義調(diào)整的免姿。

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

你說這些功能有沒有用澜掩，肯定有用购披，有總比沒有強(qiáng)（除了用戶界面難免更加復(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)為計算和展示方面功能性的改進(jìn)，優(yōu)先級遠(yuǎn)高于UI視覺效果方面的改進(jìn)丝格；常用核心控件易用性的改進(jìn)撑瞧，優(yōu)先級遠(yuǎn)高于整體控件種類豐富度的改進(jìn)。

目前我司的可視化系統(tǒng)支持如下控件显蝌，感覺已經(jīng)稍微有點多了预伺，現(xiàn)階段還是應(yīng)該重點加強(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ù)源就是一個較為理想的方案

但是爷怀，這里面最主要的問題是阻肩，不同的后端引擎對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ù)進(jìn)行各種維度的聚合操作智厌，以支持靈活的下鉆和上卷分析功能。這些功能往往不是所有的后端數(shù)據(jù)庫或存儲查詢引擎都能較好的支持的盲赊。

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

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

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

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

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

用戶查詢使用方面

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

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

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

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

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

如果這些部分用戶可以簡單快速的在查詢時進(jìn)行定制，那么就沒有必要在圖表開發(fā)時專門進(jìn)行配置了芒篷，從而間接的提高了圖表開發(fā)者的工作效率搜变，讓他們可以集中精力去關(guān)注維度指標(biāo)和運(yùn)算邏輯等真正和數(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)然，為了達(dá)到這個目標(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ù)進(jìn)行環(huán)比對照铸敏，連續(xù)的數(shù)據(jù)流缚忧，數(shù)據(jù)時間間隔不固定，個數(shù)不固定杈笔，一天內(nèi)未來時間點的數(shù)據(jù)還沒有生成闪水，圖表展示范圍如何正確處理，X軸坐標(biāo)如何生成等等蒙具。

這些問題嚴(yán)格說來球榆，也不見得在離線圖表的場景下絕對不會遇到朽肥，只是通常來說，離線圖表在這些方面通常沒有強(qiáng)烈的需求持钉，所以市面上的系統(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)時間軸進(jìn)行人工分段處理）流椒，去適配靜態(tài)圖表的展示形式敏簿，配置的難度還比較大，后續(xù)需要考慮進(jìn)一步簡化流程宣虾。

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

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

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

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

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

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

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

至于圖表和角色安全等級的設(shè)置菜谣，主要是為了加強(qiáng)敏感數(shù)據(jù)的安全管控工作珠漂。不同等級的圖表，具體申請過程中尾膊，需要審批的環(huán)節(jié)各不相同媳危，最低等級的圖表，無需申請冈敛，就是完全公開的待笑。最高等級的圖表，需要高層領(lǐng)導(dǎo)和風(fēng)控團(tuán)隊參與審批莺债，而中間等級的圖表滋觉，一般只需要圖表負(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)然這種模式下，用戶就無法進(jìn)行一些復(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ù)接口，獲取這些頁面醇蝴，嵌入到自己的后臺上進(jìn)行展示和交互宣肚。這樣既降低了第三方后臺開發(fā)者的開發(fā)代價，使用過程中悠栓，用戶也無需跳轉(zhuǎn)到可視化平臺霉涨，整體體驗較好。

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

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

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

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

先看一下我司可視化平臺內(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ù)方不意愿使用铲掐。

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

• 加強(qiáng)常用核心控件的改進(jìn)豪椿，借鑒商業(yè)產(chǎn)品中這部分控件的功能形態(tài)設(shè)計，進(jìn)一步重點提升它們的功能和易用性携栋，讓價值產(chǎn)出最大化
• 針對使用頻率低得不合理的控件搭盾，調(diào)研分析，找到阻礙用戶使用的問題點婉支，改進(jìn)形態(tài)鸯隅，加強(qiáng)推廣。

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

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

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

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

• 支持查詢時自定義聚合操作疏橄，比如用戶在查詢時可以自定義特定字段的聚合條件，做一些簡單的類似求和／求平均之類的統(tǒng)計操作略就，不需要報表開發(fā)者在配置圖表階段進(jìn)行定義捎迫，或者迫使用戶下載數(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ù)視圖方面的配置膏燃，如果沒有特殊需求（比如強(qiáng)制過濾條件茂卦，限制用戶的查詢范圍）必須預(yù)定義的何什，那么它們的變更和設(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ù)據(jù)業(yè)務(wù)展示能力

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

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

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

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

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

其它雜類

• 對移動端展示平臺的支持
• 多租戶的進(jìn)一步隔離两波，比如提供獨立URL瞳步，提供物理隔離的資源部署（比如針對第三方渲染服務(wù)，OLAP類計算密集業(yè)務(wù)等場景腰奋，就有可能有這樣的資源隔離需求）的能力

小結(jié)

臉面单起，總得好好玩吧。

常按掃描下面的二維碼劣坊，關(guān)注“大數(shù)據(jù)務(wù)虛雜談”嘀倒，務(wù)虛，我是認(rèn)真的 局冰；）