前面说完了大数据开发平台的核心组件，作业调度系统，接下来讨论一下大数据开发平台的脸面之一，数据可视化平台。和调度系统一样，这又是一个很多公司可能想要自己造一个轮子的系统。。。

数据可视化平台是什么?

不过，慢着，先等一下，什么是数据可视化平台?我们用这个高端大气上档次的词语，所指的对象和你所理解的是同一个东西么?

它是像天猫双十一时，这种占据了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类计算密集业务等场景，就有可能有这样的资源隔离需求)的能力