數據可視化平台理論與實踐

前面說完了大數據開發平台的核心組件，作業調度系統，接下來討論一下大數據開發平台的臉面之一，數據可視化平台。和調度系統一樣，這又是一個很多公司可能想要自己造一個輪子的系統。。。

數據可視化平台是什麼?

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

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

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

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

好吧，是，也不是。

相似的是途徑，都是希望藉助更加豐富的視覺圖形圖像手段，將數據更加直觀的展現出來。不同的是，對視覺效果的追求，暫時還不在我所指代的可視化系統的目標範圍之內，簡單的說，酷炫是一個加分項，但不是核心需求。

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

所以我為什麼這麼矯情，故弄玄虛，不早說報表系統這幾個字呢?

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

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

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

因此，總結下來，就是報表系統這個名字所代表的境界，太Low了。要建設好四個現代化的大數據平台，我們需要一個比傳統報表系統更現代化一點的數據可視化平台。當然了，重要的不是它叫什麼，而是在名字的背後，它所試圖提供的產品形態是什麼。

又造輪子，那些商業智能系統們，有什麼問題么?

商業化的BI產品廠商很多，國外比較知名的產品，比如 Tableau, QlikView, Power BI，國內號稱已經敏捷化的，比如永洪BI，帆軟FineBI和BDP。

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

從產品自身定位的角度來說，這些商業化的產品並沒有太大的問題，我們造輪子，並不是因為他們的產品自身功能做得不夠好，比如圖例夠不夠豐富，用戶交互夠不夠直觀，操作夠不夠便捷之類。這方面的能力，是商業產品賴以生存的根基所在，別人家幾十幾百人的團隊，經過幾年十幾年的時間開發的產品，當然不是我們派上個把同學，短時間內自己造輪子能夠比得過的。別說我們，你看連企鵝爸爸在自己的公有雲大數據套件服務上，提供的都是永洪的產品。

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

目標定位為商業BI替代品的 Saiku /pantaho 體系

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

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

緣起OpenTSDB為監控而生的Grafana

那麼，問題來了，論成熟度和易用性你多半做不過商業產品，想「省錢」也有開源產品，為什麼還要自己玩，是因為閑得慌么?樓上的Airbnb，還有阿里/騰訊/網易在不做公有雲對外販賣BI服務之前，也都是自己開發自己用，大家都是沒事可做了么?

我個人以為，根本上還是由於一些應用場景，商業產品難以適配的原因，至少，對於我司這類「互聯網」公司來說是這樣的 ;)

傳統的商業BI產品，基本上功能都很強大，但是部署和學習成本也比較高，而且往往流程定製化程度很高，和SAP等產品體系的整合做得也比較深入，所以基本上是屬於比較自洽和封閉的系統，它們的目標是給你提供一整套完整的解決方案。

而公有雲上的BI產品，雖然部署和學習成本相對較低(因為功能沒有成熟的商業產品那麼紛繁複雜 )，但是，從自洽和封閉的角度來說，也是類似的，對接外部系統的能力較弱(或者說並不情願)

比如，多數產品會提供從數據源採集，清洗到展示的定製流程，而用戶的許可權管理，數據的存儲和生命周期管理，有些產品甚至連數據格式，都是自成體系的。此外，這些產品的內部功能組件，數據結構信息等，通常也不會以服務的形式對外暴露。

所以，在這種情況下，如果你的數據處理鏈路可以全部交給對應的系統去管控，或者你所需要查詢展示的數據可以完全導入到對應的系統中，又或者該產品能通過jdbc介面查詢你自己管理的數據，並且不存在性能等問題，那麼問題不大，如果不行，就會比較難處理。

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

至於既有的開源的系統，雖然不存在封閉的問題，但其自身業務邏輯也往往比較固定和模式化，要改動成本也不低，能不能二次開發為你所用，也取決於你自己平台的流程和功能定位。

總結下來，是直接使用商業產品，還是開源二次開發，又或者是完全自主開發，基本上是按照你的業務複雜度和你所使用的周邊系統的生態環境來決定的，通常情況下，你的業務模式也複雜，你需要自主開發的可能性就越高。但是，不排除你可以針對不同的場景需求，採用不同的解決方案來最小化總體代價。

最後嘮叨一下，你要問，商業或開源產品難道就不可能成熟到可以很好的適配各種複雜應用場景么? 理論上，我認為是有可能的，但就目前來看，至少幾年內不太現實，因為

首先在大數據領域裡，底層的存儲和計算引擎差異巨大，遠還沒有達到標準檢索方式能一統天下的局面，各種業務組件和流程往往需要定製和靈活適配處理邏輯。

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

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

具體產品需求分析

對我司來說，我們自主開發的數據可視化系統，既不打算追求界面的酷炫，也不打算追求各種組件的極度豐富，和大數據生態系各種組件的配合，和公司內部各種私有數據源的打通，與周邊系統和開發平台開發流程的深度集成，對數據許可權和用戶的全面自主管控，才是核心所在。

所以我司數據可視化系統的產品設計目標如下：

產品定位

總體目標定位是通用的數據圖表可視化服務後台，不僅局限於BI業務，也希望通過自定義配置的方式，可以支持各類有數據展示需求的業務後台。使用方提供數據來源，我們負責提供平台和可視化服務，通過簡單的配置，完成大多數圖表展示業務所需的功能，節省圖表開發人員的工作量，節省其它業務後台開發人員的工作量。

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

大的產品功能維度

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

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

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

標準化數據源介面，可動態拓展新的數據源

提供基礎的數據分析和格式化配置能力，支持如同比，環比，聚合運算，閾值基線，維度層級定義等功能

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

支持定時動態刷新圖表，支持實時數據展示業務

支持個人業務視圖，支持圖表收藏訂閱等功能

多租戶管理和用戶許可權維度

支持可嵌套的業務分組能力，支持按目錄結構樹分級授權管理可視化圖表，授權範圍為業務組自身頂級目錄以下的所有內容包括子目錄

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

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

支持圖表元數據信息的檢索，在沒有詳情許可權的情況下，支持列表和簡介瀏覽，便於自主申請許可權

和周邊系統的開放集成維度

支持圖表的郵件訂閱，定時以郵件形式發送圖表內容

支持可視化頁面嵌入第三方後台，便於第三方後台集成具體圖表進行展示，節省開發工作量

支持以API的形式根據模版創建圖表，便於和開發平台等外部後台集成，支持一些快速自動生成圖表的業務場景。

部分產品需求的實踐詳解

頁面布局開發流程方面

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

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

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

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

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

這兩者的選擇，我們也是經過權衡的，前者的優勢是控制項可以在多個儀錶盤之間共享，目標顯然是為了能夠復用控制項，降低開發工作量。

但是，我們認為，這是一個相對理想的願望，實際上共享起來也面臨很多的問題，比如許可權的管理授權方面就會更加複雜，有更多的對象要管理和授權，然後，信息同步也是問題，如果共享這個控制項的幾個儀錶盤是由不同的同學負責，那麼誰對控制項說了算?或者之後不同的儀錶盤對這個空間的展現形式有了不同的需求，怎麼辦等等。這些問題，當然都能找到解決方案，但是在業務，流程方面的溝通代價也就更高了。此外操作流程上也會更加繁瑣一點(這個倒不是最大的問題)

當然，如何取捨，最終還是取決於在你的實際應用場景中那種方案綜合代價最低。就我們的場景來說，目前看來，在儀錶盤之間共享完全一樣的圖表控制項的需求並不大，方便許可權和業務管理，儘可能簡化開發流程，相對來說反而更加重要一點。

具體控制項功能支持方面

在控制項類型豐富度和參數配置靈活度方面，如果你去比對一下國內的商業產品，你會發現這往往是他們的賣點之一，這個說我有火焰圖，字元雲，那個說我支持任意雙樣式圖例等等。至於字體大小樣式，線條顏色粗細，數據點形狀大小，文字對齊方式，邊框距離之類的各種參數多半也都是可以自定義調整的。

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

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

事實上，對於可視化系統上的業務來說，如何用合理的方式組織數據，讓目標用戶快速的掌握情況，發現問題，得到結論，這才是工作的重點。

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

對於我司自研的可視化系統而言，客觀的來說，我們在控制項豐富度和配置的靈活度方面和商業產品相比較，是有不小的差距的。但這其中，我個人認為計算和展示方面功能性的改進，優先順序遠高於UI視覺效果方面的改進;常用核心控制項易用性的改進，優先順序遠高於整體控制項種類豐富度的改進。

目前我司的可視化系統支持如下控制項，感覺已經稍微有點多了，現階段還是應該重點加強基礎控制項的功能和易用性改進

數據源支持方面

對於傳統的BI工具來說，數據都在RDBMS中，語法相對規範，所以數據源的支持不是什麼大問題，而對於大數據環境下的可視化系統來說，外部數據來源種類繁多，應用模式複雜，能靈活的適配支持各種數據源，就變得非常重要。

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

但是，這裡面最主要的問題是，不同的後端引擎對SQL的支持程度並不完全一樣，特別是那些非傳統RDBMS的引擎，比如Hive，實際使用的是HQL語法，和SQL標準並不完全兼容，而在性能方面，不同的引擎往往也有各自的優化方式和最佳實踐模式。

所以，如何拓展數據源，並沒有一個完美通用的解決方案。JDBC的方案能解決一大部分問題，其它數據源要麼可能要針對性的寫對應的介面，要麼可能需要經過導入轉換的過程來解決。

不過，JDBC的介面，從基礎功能和SQL語法設計的角度來說，也未必完全滿足可視化系統的需求，主要的問題是在OLAP即時分析類應用場景下，需要對數據進行各種維度的聚合操作，以支持靈活的下鑽和上卷分析功能。這些功能往往不是所有的後端資料庫或存儲查詢引擎都能較好的支持的。

此外OLAP類應用往往還需要定義各種維度指標模型或Cube模型，為了提升性能，可能還需要實現針對數據或者針對查詢的Cache緩存層。

以上兩點，總結來說，就是在面向用戶的展示配置表達層，和面向數據的存儲引擎層之間，是否需要實現一個通用的聚合運算層來銜接。這部分工作，在國內多數的BI商業產品中往往並沒有實現。

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

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

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

用戶查詢使用方面

相對傳統的定製開發的報表系統，可視化系統以控制項的方式支持全自助圖表開發，目的是為了提高了圖表開發者的工作效率，增強應用模式。

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

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

進一步的來說，如果終端用戶可以通過自定義查詢視圖的手段來定製數據展現形式，那麼實際上，對於圖表開發者來說，很有可能就可以花費更少的時間去關注和配置一些與視圖展現相關的邏輯。

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

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

實時業務支持方面

實時數據業務的數據可視化支持工作，多數的商業BI系統其實並不能完全高效的承載，原因有兩點：

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

對此，你可以通過將數據實時刷新到DB中，定時輪詢的方式來實現，以此來規避對實時數據源的處理。對於絕大多數場景，這是一種確實可行的方案。當然，為了達到這個目標，對系統和整體數據處理鏈路還是有一些要求的，比如可視化系統支持定時刷新圖表，此外數據源的更新必須足夠迅速(需要從外部系統批量導入數據，處理轉換成內部數據結構的這類BI系統，就卡殼了)

二是圖表的展現形式，可能和傳統離線靜態圖表有一些不同。舉例來說：比如你要配置一個實時監控業務數據，你可能需要滑動刷新展示最近一個小時時間窗口的數據，你也可能需要和昨日對應時刻的數據進行環比對照，連續的數據流，數據時間間隔不固定，個數不固定，一天內未來時間點的數據還沒有生成，圖表展示範圍如何正確處理，X軸坐標如何生成等等。

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

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

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

多租戶和用戶許可權管控方面

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

而要避免多租戶之間相互影響，就需要進行隔離管控。通過分級授權，可以將整個可視化系統的圖表目錄樹結構拆分成獨立的業務組進行管理。

每個業務組目錄範圍內的圖表，目錄結構等完全由業務組各自的管理員獨立管理，日常的角色，許可權分配，流程審批等，也不需要平台超級管理員進行干預，業務組內部可以再創建子業務組，進一步分隔許可權。只有在新建頂層業務組時需要召喚平台超級管理員。

這樣做的目的是儘可能對業務方充分授權，能夠獨立對自己所負責的對象進行自主管轄和二次授權。同時又不至於對其它租戶的業務造成影響。

從我們的實踐來看，這種方案從功能的角度來看，可以實現我們的預設目標，不過，真正要發揮作用，還是需要用戶能夠利用好這些功能機制，畢竟業務組的管理，目錄結構的整理等等還是有一些工作要做的。

很多情況下，為了圖一時之方便，不少用戶並不願意做這種梳理工作，巴不得人人都是超級管理員，想幹啥幹啥，這樣一來風險其實就不可控了，業務組的價值也就小了很多。這點需要平台開發者進一步思考簡化管理的可能，並對用戶進行最佳實踐的引導。

至於圖表和角色安全等級的設置，主要是為了加強敏感數據的安全管控工作。不同等級的圖表，具體申請過程中，需要審批的環節各不相同，最低等級的圖表，無需申請，就是完全公開的。最高等級的圖表，需要高層領導和風控團隊參與審批，而中間等級的圖表，一般只需要圖表負責人或者業務負責人審批就可以了。

為了防止圖表授權出去以後，就收不回來的現象，申請流程中加入了生命周期的管理，過期的圖表自動收回許可權。

周邊系統集成方面

上面的多租戶能力是從用戶和業務的角度討論平台的開放性，而這一節，是從系統集成的角度來討論平台的開放性。

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

另外，實際上，我們的可視化系統的定位，所服務的業務並不是單一的報表系統。大量的業務後台，都需要展示自己的業務數據，雖然數據不同，但是展現形式多半還是類似的，那麼能不能輸出可視化平台既有的圖表配置開發能力和業務管控流程，減少這些業務後台的開發工作量呢?

這一般有兩種做法，一是提供可復用的代碼組件，業務方在此基礎上自主開發，這種形式可以節省一部分的控制項開發代價，但是整體的管控流程和配置化的開發方式還是沒法復用。所以，我們提供的是頁面嵌入第三方後台的服務能力。

業務方可以在可視化平台上通過配置的方式開發自己的圖表頁面，然後通過特定的服務介面，獲取這些頁面，嵌入到自己的後台上進行展示和交互。這樣既降低了第三方後台開發者的開發代價，使用過程中，用戶也無需跳轉到可視化平台，整體體驗較好。

要支持頁面嵌入第三方後台的功能，主要需要考慮的是用戶許可權的傳遞管控和交互模式的銜接，這些都不算太難，只是形態方面要考慮周全。

產品改進目標

產品的改進目標，前面多少也提到過了一些，這裡再統一整理總結一下

可視化組件改進

先看一下我司可視化平台內，各種組件的使用頻率數據

從上圖大致可以看到，整體來說，當前，我司的可視化平台內，95%以上的圖表只會使用類似表格/折線圖/柱狀圖/餅圖/文本這類最基礎的控制項。這說明了兩個問題：

第一，多數業務的數據展示，真的不需要稀奇古怪的展示形式，標準的形式覆蓋了多數的需求。

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

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

加強常用核心控制項的改進，借鑒商業產品中這部分控制項的功能形態設計，進一步重點提升它們的功能和易用性，讓價值產出最大化

針對使用頻率低得不合理的控制項，調研分析，找到阻礙用戶使用的問題點，改進形態，加強推廣。

至於控制項種類的擴展和與功能無關的視覺效果方面的改進，除非絕對必要，否則暫不考慮。

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

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

如前所述，增強終端用戶自定義視圖的能力，可以拓展用戶的應用模式，提高查詢數據的工作效率，也能降低圖表開發者的開發代價。這方面，在我司可視化平台現有功能的基礎上，可以改進的工作包括但不限於：

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

支持查詢時自主定義過濾組件，無需報表開發者提前配置可用於執行過濾的欄位和過濾用組件。

支持查詢時控制項切換能力，比如折線圖切換成柱狀圖等，可以在有限的功能範圍內，允許終端用戶自主選擇合適的展現形式。當然，前提是這種切換是合理的，比如數據量大小，維度與控制項的邏輯和應用模式是否匹配等等

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

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

拓展數據源，增強OLAP業務能力

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

增強實時數據業務展示能力

如前所述，我們當前要接入實時數據業務的展示，圖表開發配置的代價還比較高，需要進一步考慮針對實時連續數據流的場景，如何優化配置流程和展示形式。

增強對第三方平台的服務能力

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

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

如果可視化平台能夠通過API介面，將圖形渲染功能服務化，對外提供即時定義圖表和數據渲染，圖形輸出的能力，那麼也就能夠滿足這部分平台的數據展示需求了。要提供這樣的服務，難點還是在於如何進行高效的數據傳輸和許可權管控。

其它雜類

對移動端展示平台的支持

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