CN105512139B - 数据可视化的实现方法及装置 - Google Patents

Abstract

本发明提供一种数据可视化的实现方法及装置，其中，该方法包括：配置数据源、可视化样式，以及数据源和可视化样式之间的关联关系；当收到触发请求时，将数据源、可视化样式、关联关系的配置信息通过定制化接口导入可视化渲染框架；可视化渲染框架根据配置信息进行渲染，并输出至浏览器引擎。本发明的有益效果是：将可视化渲染框架和数据源、可视化样式及其关联关系独立封装，用户只需要对数据源、可视化样式及其关联关系进行配置，即可导入可视化渲染框架进行渲染，提高了研发效率和前端性能。

Description

数据可视化的实现方法及装置

技术领域

本发明涉及一种数据可视化的实现方法及装置，尤其涉及一种前端数据可视化的实现方法及装置。

背景技术

随着技术的进步，大数据分析越发升温，除了海量数据计算和存储的难题，还有一个影响产品研发效率和用户体验的重要环节，即数据可视化。然而即使有EXT、GoogleLineChart等众多可供选择的前端报表技术，也只能被当做工具使用，没有形成一套可扩展的前端IOC开发框架，不能够有效降低研发成本。

在前端报表技术中，常见的包括Ext、Google LineChart、HighChart等等。这些技术通常重渲染而轻框架，仅能作为工具使用。它们各自都规定了自身的数据结构，用户必须自己做AJAX查询，解析JSON，再将data适配为这些工具要求的结构……，这个过程中，工具能够帮助用户解决的仅仅是报表渲染环节，而数据可视化技术的环节还涉及到数据查询、数据解析、数据缓存、结构转换、数据交互、定时驱动、布局控制、弹出拖拽浮动、公用参数控制等等。如果放任这些环节由开发人员自行解决，往往会导致风格迥异的javascript充斥在各个产品代码中(我们不能保证每个前端开发人员都有很高的重构抽象能力)，一旦公用的逻辑没有沉淀重用，接下来的维护和扩展工作就会浪费大量的编码成本、学习成本、返工成本。

发明内容

本发明的目的在于提供一种数据可视化的实现方法及装置。

为实现上述发明目的之一，本发明一实施方式提供了一种数据可视化的实现方法，所述方法包括：

配置数据源、可视化样式，以及所述数据源和所述可视化样式之间的关联关系；

当收到触发请求时，将所述数据源、可视化样式、关联关系的配置信息通过定制化接口导入可视化渲染框架；

所述可视化渲染框架根据所述配置信息进行渲染，并输出至浏览器引擎。

作为本发明一实施方式的进一步改进，所述数据源、可视化样式，以及所述可视化渲染框架分别独立封装。

作为本发明一实施方式的进一步改进，所述定制化接口为IOC接口。

作为本发明一实施方式的进一步改进，所述数据源和所述可视化样式为多对多的关联关系，每一个数据源对应至少一个可视化样式，每一个可视化样式对应至少一个数据源。

作为本发明一实施方式的进一步改进，所述『所述可视化渲染框架根据所述配置信息进行渲染』具体包括：

根据所述数据源中配置的服务查询地址及参数信息，获取相应的数据；

根据所述关联关系将所述数据转换为可视化样式匹配的渲染模型；

根据所述渲染模型，调用渲染工具进行渲染。

作为本发明一实施方式的进一步改进，所述参数信息包括：

查询数据的周期、粒度、数据ID的至少其中之一。

作为本发明一实施方式的进一步改进，『根据所述渲染模型，调用渲染工具进行渲染』具体包括：

根据所述可视化样式提供的结构转换逻辑，将所述渲染模型转换为对应的渲染工具所要求参数格式；

根据所述参数格式，调用对应的渲染工具进行渲染。

作为本发明一实施方式的进一步改进，『根据所述参数格式，调用对应的渲染工具进行渲染』具体包括：

根据所述参数格式以及所述可视化样式提供的参数逻辑，调用相应的渲染工具进行渲染。

作为本发明一实施方式的进一步改进，所述『根据所述关联关系将所述数据转换为可视化样式匹配的渲染模型』具体包括：

根据所述关联关系将所述数据转换为可视化样式匹配的的数据结构；

调取所述数据结构并根据与所述数据结构关联的可视化样式，将所述数据结构转换为可视化样式匹配的渲染模型。

作为本发明一实施方式的进一步改进，

所述数据源为插件形式，每个插件中包括数据的服务查询地址及参数信息；

所述可视化样式为插件形式，每个插件中包括一种可视化样式。

作为本发明一实施方式的进一步改进，所述方法还包括：

将事件监听逻辑注册到浏览器引擎。

作为本发明一实施方式的进一步改进，所述方法包括：

配置获取页面坐标函数，以获取触发事件相应的页面元素的页面坐标；

配置获取数据函数，以在获取触发事件相应的页面元素的页面坐标后，调取与所述页面坐标相应的数据；

其中，每一报表类型只对应一个页面元素。

为实现上述发明目的之一，本发明一实施方式提供了一种数据可视化的实现装置，所述数据可视化的实现装置包括：

配置模块，用于配置数据源、可视化样式，以及所述数据源和所述可视化样式之间的关联关系；

导入模块，用于当收到触发请求时，将所述数据源、可视化样式、关联关系的配置信息通过定制化接口导入可视化渲染框架；

所述可视化渲染框架还用于根据所述配置信息进行渲染，并输出至浏览器引擎。

作为本发明一实施方式的进一步改进，所述数据源、可视化样式，以及所述可视化渲染框架分别独立封装。

作为本发明一实施方式的进一步改进，所述定制化接口为IOC接口。

作为本发明一实施方式的进一步改进，所述数据源和所述可视化样式为多对多的关联关系，每一个数据源对应至少一个可视化样式，每一个可视化样式对应至少一个数据源。

作为本发明一实施方式的进一步改进，所述可视化渲染框架具体用于：

根据所述数据源中配置的服务查询地址及参数信息，获取相应的数据；

根据所述关联关系将所述数据转换为可视化样式匹配的渲染模型；

根据所述渲染模型，调用渲染工具进行渲染。

作为本发明一实施方式的进一步改进，所述参数信息包括：

查询数据的周期、粒度、数据ID的至少其中之一。

作为本发明一实施方式的进一步改进，所述可视化渲染框架具体用于：

根据所述可视化样式提供的结构转换逻辑，将所述渲染模型转换为对应的渲染工具所要求参数格式；

根据所述参数格式，调用对应的渲染工具进行渲染。

作为本发明一实施方式的进一步改进，所述可视化渲染框架具体用于：

根据所述参数格式以及所述可视化样式提供的参数逻辑，调用相应的渲染工具进行渲染。

作为本发明一实施方式的进一步改进，所述可视化渲染框架具体用于：

根据所述关联关系将所述数据转换为可视化样式匹配的的数据结构；

调取所述数据结构并根据与所述数据结构关联的可视化样式，将所述数据结构转换为可视化样式匹配的渲染模型。

作为本发明一实施方式的进一步改进，

所述数据源为插件形式，每个插件中包括数据的服务查询地址及参数信息；

所述可视化样式为插件形式，每个插件中包括一种可视化样式。

作为本发明一实施方式的进一步改进，所述可视化渲染框架还用于将事件监听逻辑注册到浏览器引擎。

作为本发明一实施方式的进一步改进，所述配置模块还用于：

配置获取页面坐标函数，以获取触发事件相应的页面元素的页面坐标；

配置获取数据函数，以在获取触发事件相应的页面元素的页面坐标后，调取与所述页面坐标相应的数据；

其中，每一报表类型只对应一个页面元素。

与现有技术相比，本发明的有益效果是：将可视化渲染框架和数据源、可视化样式及其关联关系独立封装，用户只需要对数据源、可视化样式及其关联关系进行配置，即可导入可视化渲染框架进行渲染，提高了研发效率和前端性能。

附图说明

图1是本发明一实施方式的数据可视化的实现方法的流程图；

图2是本发明一实施方式中数据源、可视化样式、以及关联关系与可视化渲染框架中各环节对应的模块示意图；

图3是本发明一实施方式中将前端的角色进行IOC架构设计的模块图；

图4是本发明一实施方式中XSTING用户期望展示一个表格，表格中展示交易摘要相关的数据时的编码示意图；

图5是本发明一实施方式中在多数据源场景下，用户定义ds1和ds2两个数据源配置的编码示意图；

图6是与图5对应的展现效果图；

图7是本发明一实施方式中展现一天1440分钟的数据走势的曲线图；

图8是本发明一实施方式中用DOM元素绘制图7所示的数据走势的示意图；

图9是本发明一实施方式的数据可视化的实现装置的模块图。

具体实施方式

以下将结合附图所示的各实施方式对本发明进行详细描述。但这些实施方式并不限制本发明，本领域的普通技术人员根据这些实施方式所轻易做出的结构、方法、或功能上的变换均包含在本发明的保护范围内。

如图1所示，本发明一实施方式提供了一种数据可视化的实现方法，其包括：

配置数据源、可视化样式，以及数据源和可视化样式之间的关联关系；

在数据分析领域，用户往往会面对多种多样的数据源。比如在数据仓库产出BI报表时，可能既要获取DB中ETL清洗出来的数据(比如某个商品的交易次数)，又要获取日志分析的数据(比如某个商品被用户浏览的UV)，还要加上消息事件的数据(比如某个商品的炒信行为数量)，甚至要去捞取微博上的舆情数据。

用户在想要展现某个报表时，必然清楚应该展示为什么样式(是表格、曲线、还是饼图等)，而这些不同的样式也即定义为可视化样式。

数据源和可视化样式为多对多的关联关系，每一个数据源对应至少一个可视化样式，每一个可视化样式对应至少一个数据源。例如，分钟级统计的数据既可以展示为曲线图样式也可以展示为表格样式；而表格样式既可以展示分钟级统计数据又可以展示多笔业务状态机结果。此步骤中，相应地配置了数据源和可视化样式之间的关联关系，以在每个数据源中，为它支持的可视化样式各提供一个之间的关联关系，以便将本数据源查询的原始JSON转换为不同可视化样式偏爱的数据结构，而数据源和可视化样式之间的关联关系就像关系型数据库里的中间表，维持了数据源和可视化样式的多对多关系。

当收到触发请求时，将数据源、可视化样式、关联关系的配置信息通过定制化接口导入可视化渲染框架，可视化渲染框架根据配置信息进行渲染，并输出至浏览器引擎。

如图2所示，触发请求可以是例如定时触发、用户点击等，可视化渲染框架内封装有一套完整的实现流程(这部分将在下文中做详细的描述)，并向外暴露定制化接口，等待上述的数据源、可视化样式、关联关系的配置信息导入后实现。而数据源、可视化样式、以及关联关系三者对应到该可视化渲染框架中各部分的关系即如图2所示，图中所示的圆形框中为需要通过数据源、可视化样式、以及关联关系进行配置的逻辑部分。

在本发明的一实施方式中，可视化渲染框架内封装的流程有：

查询驱动(Query Driver)按照一定策略(可能是定时、也可以是人工触发、也可能是页面刚打开时的初始化触发)，触发异步查询(Async Query)。

异步查询向提供数据查询服务的REST服务发起AJAX查询，获取数据(比如JSON结构的数据)。具体地，异步查询需要根据数据源中配置的服务查询地址和参数信息，获取相应的数据，这里的服务查询地址指的是数据源为异步查询提供的是REST服务的查询地址，参数信息包括查询数据的周期、粒度、数据ID的至少其中之一。

REST服务返回的只是服务端定义的数据结构，不一定适合前端。造成这种现象的一个重要原因就是前后端的角色差异。差异之一，服务端偏稳，前端追求灵活，面对频繁变更的需求我们更倾向于灵活的修改前端逻辑，而让后端服务逐渐沉淀稳态。差异之二，是前后端的数据视角不同，后端更倾向于通用的视角，而前端则倾向于面向当前展示场景的视角。

例如，服务器端保存了全国各所大学的学生信息，其暴露的REST服务定义的结构可能就是偏本质的List<Student>，Student对象中包含了学号、姓名、性别、专业等基本信息，另一个REST服务提供学分成绩查询(提供学号作为参数)，会返回GPA对象(包含各科成绩)。而前端的某个页面可能是一个班级的学分成绩展示场景，它更偏爱的数据结构是List<StudentGPA>，StudentGPA＝{学号:xxx,姓名:xxx,高等数学:86,英语:92,离散数学:77,Linux程序设计:99…}，而且这个List最好还是按总学分降序排列的。

由于上述的这些需求差异，就需要将REST服务返回的原始结果交给数据模型转(Data Model Transform)换进行结构转换，变成前端偏爱的结构。转换好的结果就可以交给数据模型缓存(Data Model Cache)进行前端缓存了(可以做单例缓存，也可以实现多版本，视情况而定)。

渲染驱动(Render Driver)按一定的策略(可能是定时、人工触发、查询完成触发等等)获取数据模型缓存中的数据，执行渲染模型转换。数据源中的多个关联关系(Adaptor)是为渲染模型转换提供结构转换逻辑。在此过程中，需要根据关联关系将该数据转换为可视化样式匹配的渲染模型，更具体地，先根据关联关系将数据转换为可视化样式匹配的数据结构，再调取数据结构并根据与该数据结构关联的可视化样式，将数据结构转换为可视化样式匹配的渲染模型。不同可视化样式要求的渲染模型不同(比如时间曲线样式要求提供Map<Time,Value>，而表格样式要求提供一个二维数组)，所以在一个数据源中每个可视化样式会对应一个专有的关联关系，此关联关系负责将原始JSON转换为该可视化样式的渲染模型；同时，可视化样式会为渲染模型转换提供渲染工具的结构转换逻辑(比如将可视化样式自身的渲染模型转换为EXT饼状图所要求的参数格式)。

还是以学生信息为例，List<StudentGPA>结构虽然适用于“班级学分绩展示”这个前端场景，但是它不一定适用于开发者当前使用的报表渲染工具，EXT有它要求的结构、GoogleLineChart要求的又是另一种结构……多出这样一个转换步骤最大的目的在于不被工具绑架数据结构。一旦数据结构被某个工具绑架，会带来诸多问题，例如换工具的时候非常麻烦、结构偏离本质导致可维护性变差、Dashboard难以支持多种展现形式(比如用户想要看心情来选择展示为表格或者饼图)。

转换为渲染模型(Render Model)以后，就正式的托管给各类渲染工具(RenderTool，例如EXT)了。在托管给渲染工具之前，需要根据渲染模型，调用渲染工具进行渲染。具体地，先根据可视化样式提供的结构转换逻辑，将需渲染模型转换为对应的渲染工具所要求参数格式，并根据该参数格式，调用对应的渲染工具进行渲染，如此，可适应更多的渲染工具。而在根据参数格式，调用对应的渲染工具进行渲染时，会同时根据参数格式以及可视化样式提供的参数逻辑(比如曲线样式的可视化样式就会使用EXT中的LineChart、表格样式的可视化样式则使用EXT中的Grid，并提供表头、标题等信息)，调用相应的渲染工具进行渲染。

渲染工具按照各自实现方式的不同，将渲染模型提供的信息注册到浏览器引擎(比如向document中插入一个<table>)，完成渲染；与此同时，提供给渲染工具的还可能包含事件监听逻辑，此时需要将该事件监听逻辑一并注册到浏览器引擎。

如果DOM元素捕获到交互事件，浏览器引擎则会回调事件监听handler，后者完成事件处理逻辑，这里的逻辑就可能多种多样了，可能是一个简单的alert，也可能是对数据模型缓存中结构的修改，也可能是人工触发一次新的查询流程或渲染流程。

如图3所示，本发明的一实施方式中，上述的定制化接口为IOC接口。IOC(Inversion of Control，控制反转)是一个重要的面向对象编程的法则来削减计算机程序的耦合问题，也是轻量级的Spring框架的核心。通过将控制权交给框架，由框架做重复的流程，而用户只需关注自身的业务(或功能)。在IOC架构实现的过程中，底层的可视化渲染框架负责一套流程的封装和实现，但忽略所有定制化逻辑的实现细节，而是向外暴露IOC接口，等待上层实现；中间的Plugin层负责封装常用的定制化逻辑(包括常用的数据源及常见的可视化样式)；最顶层则是最终产品的逻辑，此层的编码要尽量简化，在可视化渲染框架、Plugin两层封装之后，产品层应该只需要提供不同Plugin所必须的参数即可。

在进行IOC的架构设计时，数据源、可视化样式，以及可视化渲染框架分别独立封装。数据源被配置为插件形式，每个插件中包括数据的服务查询地址及参数信息，每个数据源就是一个数据源插件，例如，封装的数据源包括分钟级统计数据、秒级数据统计、ERROR日志分词统计、单笔业务状态机、海量槽位全表遍历查询等多种多样格式不一的数据源；类似地，可视化样式也被配置为插件形式，每个插件中包括一种可视化样式，每个可视化样式就是一个可视化样式插件，例如曲线图、饼图、表格、柱状图等实现逻辑，在XFLUSH中还包含了链路图、网状图、灯图等更多复杂样式。

如图4所示，为用户编写的一个实际例子，他期望展示的是一个表格，表格中展示“交易摘要”相关的数据。他所需的编码内容包括：

第一个框：为数据源提供必需的参数，比如schema＝DataSource1是在选择一个数据源插件(DataSource1选择的是分钟级统计数据源)，table则表示选择哪张表里的统计结果(可以将XFLUSH中的几千个分钟级统计规则的结果看做几千张表，而此例中则使用了交易相关的数据表)，最后这个数据源对象还为Style4提供了专属参数：valueColIndex＝3，表示此表返回的结果中代表数值的data会放在第3列提供给Style4。

第二个框：为可视化样式提供必需的参数，比如schema是在选择插件(Style4是高级表格展示插件)，heads是在定义表头(表头第3列是“数量”也和valueColIndex对应)，defaultSortColIndex＝3表示默认按第3列进行排序，defaultSortCount表示默认排序展示前多少个。

第三个框：为报表提供一些基本信息，比如位置、大小、刷新速度、标题等。

只需要这些信息，就能展示出用户所需的报表了，在目前日趋丰富的插件库支持下，能够支持的数据源和样式组合已经能够满足所有日常所需了，用户也只需要简单的编码，就能轻松实现各种不同效果。

如图5和图6所示，在多数据源的场景下作用更加明显：

在本发明的一实施方式中，期望将多个数据源的数据展示在同一张曲线报表中，用户只需要定义多个数据源即可(图5定义了ds1和ds2两个数据源配置，图6为展现效果)。而且多个数据源可以是相异的插件(本例中都是DataSource1插件，实际使用时可以组合使用任意的数据源插件，只要它们都实现了支持曲线图可视化样式的关联关系即可，比如在双十一大促时，ds1获取交易数据，ds2获取微博舆情数据(每分钟出现的与双十一相关的微博数量)，继而展示到同一张曲线图中)。而且异步查询环节也利用了Javascript的Deferred技术，实现了同步的编程模型，简化了框架设计，解决了多个异步查询返回结果的时间差问题，避免轮询等劣质解决方案。

不仅如此，框架提供的事件监听机制、交互控制、弹出动态报表等功能都是以最简化的IOC接口暴露给用户，将用户编码量降至最低，只提供绝对需要的定制化参数而已，不需要考虑底层实现细节。

如图7所示，在传统的前端报表技术中，有些只能做到DOM元素级别的渲染和控制。比如一个曲线图，展现了一天1440分钟的数据走势，其中就会有一千多个数据(1440个点)需要渲染，在HTML5等技术出现之前，前端报表技术往往非常被动的采用一些复杂解决方案，甚至会产生与数据点数量相当的DOM元素来绘制出曲线。

如图8所示，这些<circle>元素最终绘制出了图中的曲线。这样的做法不论好坏，在性能上还是略逊一筹的，起码在交互事件上就会非常被动。比如想要监听曲线中某一个点的鼠标单击事件，那就是1440个DOM元素都要被妥善的注册、管理它们的生命周期、处理它们的交互事件等。DOM元素其实还是粒度比较粗的运行时对象(内部包含很多的元数据、运行时数据)，会给浏览器引擎带来较大的负担。而且作为渲染为主的工具，往往很难加入细粒度的交互功能(比如想要监听图8中LineChart上某一个“点”的鼠标单击事件，工具未必能够开放出简洁的API)，这类工具暴露给用户的交互API粒度一般是较粗的(比如对整个图表进行拖拽、点击)。

而本申请的一实施方式中，为了实现细粒度的交互渲染控制(比如一段1440个“点”的曲线，希望鼠标点击曲线中的某一段区域能弹出另一张详情报表、比如想控制曲线不同区域段的颜色粗细、比如希望将曲线图当做node绘制一个网状交织的链路关系图等等)，采用了HTML5的Canvas技术实现了一套简洁易用的渲染工具，也就是类似EXT、GoogleLineChart的制图工具javascript库。此工具库和常规的实现方案最大的区别就是充分采用了游戏引擎中“时间换空间”的设计思路。

在游戏引擎客户端渲染的场景中，可以将2D、3D的地图或模型都全量制造并存储为数据文件，运行时在根据场景切换来动态加载数据文件，将地图、模型数据载入内存，最终完成渲染。举例说明，在2D游戏中，一张野外草地的地图如果是一张图片，那可能会达到1MB(假如有1024*1024个像素，每个像素的RGB值占一个byte)，在载入该地图后其实就是将整张图片绘制到界面上。而实际的设计往往简单很多：制造4张小图片ABCD，体现略有差异的植被特征，这4张小图片的排列组合就制造出了不同的地图场景(比如A代表纯草地，B代表有小石头的草地，C代表有杂草的草地，D代表光秃的黄土，那2D地图文件可以仅仅是一个二维数组，其中的元素就是ABCD四选一，不同的排列组合就能形成不同的地图样貌)，这种做法能够极大的降低存储空间损耗、内存占用量、元素管理和交互控制的负担，唯一增加的就是渲染时的逻辑复杂度，需要一定的计算量(不像绘制一张大图片那么简单)。

对应到本申请的数据可视化实现方法一实施方式中：

首先，配置获取页面坐标函数，以获取触发事件相应的页面元素的页面坐标；

还是以1440个“点”的曲线举例，原始的数据是Map<Time,Value>，传统的做法就是产生1440个DOM元素，注册给浏览器引擎，后者完成渲染和元素生命周期管理、事件控制。而本发明的做法是：提供一个获取页面坐标函数(getPositionByEntry)；对于Map里的每个entry(也就是每个点)，作为参数调用页面坐标函数函数(Time可推算出x坐标，Value可推算出y坐标)；使用HTML5的Canvas完成“点”的绘制(绘制时可根据各种个性化需求选择颜色、大小等效果)。

其次，配置获取数据函数，以在获取触发事件相应的页面元素的页面坐标后，调取与所述页面坐标相应的数据；其中，每一报表类型只对应一个页面元素。

当鼠标点击事件发生时，将鼠标坐标作为参数调用获取数据函数(getEntryByPosition，x坐标可推算出最相近的Entry，假如x轴总长为N像素，一共M个点，当前x坐标为x，那就是第Math.round(x/(N/M))个entry)；将此entry的数据取出做后续事件监听处理。

如此，仅仅是在制图和交互时多了一点计算量，而1440个DOM元素所占用的空间和损耗的维护成本都可以避免了。除了上述实施例中提到的曲线图，表格、饼图等样式下的处理思路都是类似，在此不再赘述。

如图9所示，在本发明一实施方式中，数据可视化的实现装置100包括配置模块10、导入模块20、以及可视化渲染框架30。

配置模块10用于配置数据源、可视化样式，以及数据源和可视化样式之间的关联关系；

在数据分析领域，用户往往会面对多种多样的数据源。比如在数据仓库产出BI报表时，可能既要获取DB中ETL清洗出来的数据(比如某个商品的交易次数)，又要获取日志分析的数据(比如某个商品被用户浏览的UV)，还要加上消息事件的数据(比如某个商品的炒信行为数量)，甚至要去捞取微博上的舆情数据。

用户在想要展现某个报表时，必然清楚应该展示为什么样式(是表格、曲线、还是饼图等)，而这些不同的样式也即定义为可视化样式。

数据源和可视化样式为多对多的关联关系，每一个数据源对应至少一个可视化样式，每一个可视化样式对应至少一个数据源。例如，分钟级统计的数据既可以展示为曲线图样式也可以展示为表格样式；而表格样式既可以展示分钟级统计数据又可以展示多笔业务状态机结果。此步骤中，相应地配置了数据源和可视化样式之间的关联关系，以在每个数据源中，为它支持的可视化样式各提供一个之间的关联关系，以便将本数据源查询的原始JSON转换为不同可视化样式偏爱的数据结构，而数据源和可视化样式之间的关联关系就像关系型数据库里的中间表，维持了数据源和可视化样式的多对多关系。

导入模块20用于当收到触发请求时，将数据源、可视化样式、关联关系的配置信息通过定制化接口导入可视化渲染框架30，可视化渲染框架30根据配置信息进行渲染，并输出至浏览器引擎。

如图2所示，触发请求可以是例如定时触发、用户点击等，可视化渲染框架内封装有一套完整的实现流程(这部分将在下文中做详细的描述)，并向外暴露定制化接口，等待上述的数据源、可视化样式、关联关系的配置信息导入后实现。而数据源、可视化样式、以及关联关系三者对应到该可视化渲染框架中各部分的关系即如图所示，图中所示的圆形框中为需要通过数据源、可视化样式、以及关联关系进行配置的逻辑部分。

在本发明一实施方式中，可视化渲染框架30内包括：

查询驱动(Query Driver)按照一定策略(可能是定时、也可以是人工触发、也可能是页面刚打开时的初始化触发)，触发异步查询(Async Query)。

异步查询向提供数据查询服务的REST服务发起AJAX查询，获取数据(比如JSON结构的数据)。具体地，可视化渲染框架30中的异步查询用于根据数据源中配置的服务查询地址和参数信息，获取相应的数据，这里的服务查询地址指的是数据源为异步查询提供的是REST服务的查询地址，参数信息包括查询数据的周期、粒度、数据ID的至少其中之一。

REST服务返回的只是服务端定义的数据结构，不一定适合前端。造成这种现象的一个重要原因就是前后端的角色差异。差异之一，服务端偏稳，前端追求灵活，面对频繁变更的需求我们更倾向于灵活的修改前端逻辑，而让后端服务逐渐沉淀稳态。差异之二，是前后端的数据视角不同，后端更倾向于通用的视角，而前端则倾向于面向当前展示场景的视角。

例如，服务器端保存了全国各所大学的学生信息，其暴露的REST服务定义的结构可能就是偏本质的List<Student>，Student对象中包含了学号、姓名、性别、专业等基本信息，另一个REST服务提供学分成绩查询(提供学号作为参数)，会返回GPA对象(包含各科成绩)。而前端的某个页面可能是一个班级的学分成绩展示场景，它更偏爱的数据结构是List<StudentGPA>，StudentGPA＝{学号:xxx,姓名:xxx,高等数学:86,英语:92,离散数学:77,Linux程序设计:99…}，而且这个List最好还是按总学分降序排列的。

由于上述的这些需求差异，就需要将REST服务返回的原始结果交给数据模型转(Data Model Transform)换进行结构转换，变成前端偏爱的结构。转换好的结果就可以交给数据模型缓存(Data Model Cache)进行前端缓存了(可以做单例缓存，也可以实现多版本，视情况而定)。

渲染驱动(Render Driver)按一定的策略(可能是定时、人工触发、查询完成触发等等)获取数据模型缓存中的数据，执行渲染模型转换。数据源中的多个关联关系(Adaptor)是为渲染模型转换提供结构转换逻辑。在此过程中，可视化渲染框架30需要根据关联关系将该数据转换为可视化样式匹配的渲染模型，更具体地，先根据关联关系将数据转换为可视化样式匹配的数据结构，再调取数据结构并根据与该数据结构关联的可视化样式，将数据结构转换为可视化样式匹配的渲染模型。不同可视化样式要求的渲染模型不同(比如时间曲线样式要求提供Map<Time,Value>，而表格样式要求提供一个二维数组)，所以在一个数据源中每个可视化样式会对应一个专有的关联关系，此关联关系负责将原始JSON转换为该可视化样式的渲染模型；同时，可视化样式会为渲染模型转换提供渲染工具的结构转换逻辑(比如将可视化样式自身的渲染模型转换为EXT饼状图所要求的参数格式)。

还是以学生信息为例，List<StudentGPA>结构虽然适用于“班级学分绩展示”这个前端场景，但是它不一定适用于开发者当前使用的报表渲染工具，EXT有它要求的结构、GoogleLineChart要求的又是另一种结构……多出这样一个转换步骤最大的目的在于不被工具绑架数据结构。一旦数据结构被某个工具绑架，会带来诸多问题，例如换工具的时候非常麻烦、结构偏离本质导致可维护性变差、Dashboard难以支持多种展现形式(比如用户想要看心情来选择展示为表格或者饼图)。

转换为渲染模型(Render Model)以后，就正式的托管给各类渲染工具(RenderTool，例如EXT)了。在托管给渲染工具之前，可视化渲染框架30还用于根据渲染模型，调用渲染工具进行渲染。具体地，先根据可视化样式提供的结构转换逻辑，将需渲染模型转换为对应的渲染工具所要求参数格式，并根据该参数格式，调用对应的渲染工具进行渲染，如此，可适应更多的渲染工具。而在根据参数格式，调用对应的渲染工具进行渲染时，会同时根据参数格式以及可视化样式提供的参数逻辑(比如曲线样式的可视化样式就会使用EXT中的LineChart、表格样式的可视化样式则使用EXT中的Grid，并提供表头、标题等信息)，调用相应的渲染工具进行渲染。

渲染工具按照各自实现方式的不同，将渲染模型提供的信息注册到浏览器引擎(比如向document中插入一个<table>)，完成渲染；与此同时，提供给渲染工具的还可能包含事件监听逻辑，可视化渲染框架30会将该事件监听逻辑一并注册到浏览器引擎。

如果DOM元素捕获到交互事件，浏览器引擎则会回调事件监听handler，后者完成事件处理逻辑，这里的逻辑就可能多种多样了，可能是一个简单的alert，也可能是对数据模型缓存中结构的修改，也可能是人工触发一次新的查询流程或渲染流程。

如图3所示，本发明的一实施方式中，该定制化接口为IOC接口。IOC(Inversion ofControl，控制反转)是一个重要的面向对象编程的法则来削减计算机程序的耦合问题，也是轻量级的Spring框架的核心。通过将控制权交给框架，由框架做重复的流程，而用户只需关注自身的业务(或功能)。所以，本发明提供的数据可视化实现方法实际上是对原有的前端可视化实现流程中，查询流程和渲染流程两部分进行IOC架构实现的过程。底层的可视化渲染框架负责一套流程的封装和实现，但忽略所有定制化逻辑的实现细节，而是向外暴露IOC接口，等待上层实现；中间的Plugin层负责封装常用的定制化逻辑(包括常用的数据源及常见的可视化样式)；最顶层则是最终产品的逻辑，此层的编码要尽量简化，在可视化渲染框架、Plugin两层封装之后，产品层应该只需要提供不同Plugin所必须的参数即可。

在进行IOC的架构设计时，数据源、可视化样式，以及可视化渲染框架分别独立封装。数据源被配置为插件形式，每个插件中包括数据的服务查询地址及参数信息，每个数据源就是一个数据源插件，例如，封装的数据源包括分钟级统计数据、秒级数据统计、ERROR日志分词统计、单笔业务状态机、海量槽位全表遍历查询等多种多样格式不一的数据源；类似地，可视化样式也被配置为插件形式，每个插件中包括一种可视化样式，每个可视化样式就是一个可视化样式插件，例如曲线图、饼图、表格、柱状图等实现逻辑，还可包含了链路图、网状图、灯图等更多复杂样式。

如图4所示，为用户编写的一个实际例子，他期望展示的是一个表格，表格中展示“交易摘要”相关的数据。他所需的编码内容包括：

第一个框：为数据源提供必需的参数，比如schema＝DataSource1是在选择一个数据源插件(DataSource1选择的是分钟级统计数据源)，table则表示选择哪张表里的统计结果(可以将几千个分钟级统计规则的结果看做几千张表，而此例中则使用了交易相关的数据表)，最后这个数据源对象还为Style4提供了专属参数：valueColIndex＝3，表示此表返回的结果中代表数值的data会放在第3列提供给Style4。

第二个框：为可视化样式提供必需的参数，比如schema是在选择插件(Style4是高级表格展示插件)，heads是在定义表头(表头第3列是“数量”也和valueColIndex对应)，defaultSortColIndex＝3表示默认按第3列进行排序，defaultSortCount表示默认排序展示前多少个。

第三个框：为报表提供一些基本信息，比如位置、大小、刷新速度、标题等。

只需要这些信息，就能展示出用户所需的报表了，在目前日趋丰富的插件库支持下，能够支持的数据源和样式组合已经能够满足所有日常所需了，用户也只需要简单的编码，就能轻松实现各种不同效果。

如图5和图6所示，在多数据源的场景下的作用更加明显：

在本发明的一实施方式中，期望将多个数据源的数据展示在同一张曲线报表中，用户只需要定义多个数据源即可(图5定义了ds1和ds2两个数据源配置，图6为展现效果)。而且多个数据源可以是相异的插件(本例中都是DataSource1插件，实际使用时可以组合使用任意的数据源插件，只要它们都实现了支持曲线图可视化样式的关联关系即可，比如在双十一大促时，ds1获取交易数据，ds2获取微博舆情数据(每分钟出现的与双十一相关的微博数量)，继而展示到同一张曲线图中)。而且XSTING的异步查询环节也利用了Javascript的Deferred技术，实现了同步的编程模型，简化了框架设计，解决了多个异步查询返回结果的时间差问题，避免轮询等劣质解决方案。

不仅如此，框架提供的事件监听机制、交互控制、弹出动态报表等功能都是以最简化的IOC接口暴露给用户，将用户编码量降至最低，只提供绝对需要的定制化参数而已，不需要考虑底层实现细节。

如图7所示，在传统的前端报表技术中，有些只能做到DOM元素级别的渲染和控制。比如一个曲线图，展现了一天1440分钟的数据走势，其中就会有一千多个数据(1440个点)需要渲染，在HTML5等技术出现之前，前端报表技术往往非常被动的采用一些复杂解决方案，甚至会产生与数据点数量相当的DOM元素来绘制出曲线。

如图8所示，这些<circle>元素最终绘制出了图中的曲线。这样的做法不论好坏，在性能上还是略逊一筹的，起码在交互事件上就会非常被动。比如想要监听曲线中某一个点的鼠标单击事件，那就是1440个DOM元素都要被妥善的注册、管理它们的生命周期、处理它们的交互事件等。DOM元素其实还是粒度比较粗的运行时对象(内部包含很多的元数据、运行时数据)，会给浏览器引擎带来较大的负担。而且作为渲染为主的工具，往往很难加入细粒度的交互功能(比如想要监听图8中LineChart上某一个“点”的鼠标单击事件，工具未必能够开放出简洁的API)，这类工具暴露给用户的交互API粒度一般是较粗的(比如对整个图表进行拖拽、点击)。

而本申请的一实施方式中，为了实现细粒度的交互渲染控制(比如一段1440个“点”的曲线，希望鼠标点击曲线中的某一段区域能弹出另一张详情报表、比如想控制曲线不同区域段的颜色粗细、比如希望将曲线图当做node绘制一个网状交织的链路关系图等等)，采用了HTML5的Canvas技术实现了一套简洁易用的渲染工具，也就是类似EXT、GoogleLineChart的制图工具javascript库。此工具库和常规的实现方案最大的区别就是充分采用了游戏引擎中“时间换空间”的设计思路。

在游戏引擎客户端渲染的场景中，可以将2D、3D的地图或模型都全量制造并存储为数据文件，运行时在根据场景切换来动态加载数据文件，将地图、模型数据载入内存，最终完成渲染。举例说明，在2D游戏中，一张野外草地的地图如果是一张图片，那可能会达到1MB(假如有1024*1024个像素，每个像素的RGB值占一个byte)，在载入该地图后其实就是将整张图片绘制到界面上。而实际的设计往往简单很多：制造4张小图片ABCD，体现略有差异的植被特征，这4张小图片的排列组合就制造出了不同的地图场景(比如A代表纯草地，B代表有小石头的草地，C代表有杂草的草地，D代表光秃的黄土，那2D地图文件可以仅仅是一个二维数组，其中的元素就是ABCD四选一，不同的排列组合就能形成不同的地图样貌)，这种做法能够极大的降低存储空间损耗、内存占用量、元素管理和交互控制的负担，唯一增加的就是渲染时的逻辑复杂度，需要一定的计算量(不像绘制一张大图片那么简单)。

对应到本申请的数据可视化实现装置一实施方式中：

首先，配置模块10还用于配置获取页面坐标函数，以获取触发事件相应的页面元素的页面坐标；

还是以1440个“点”的曲线举例，原始的数据是Map<Time,Value>，传统的做法就是产生1440个DOM元素，注册给浏览器引擎，后者完成渲染和元素生命周期管理、事件控制。而本发明的做法是：提供一个获取页面坐标函数(getPositionByEntry)；对于Map里的每个entry(也就是每个点)，作为参数调用页面坐标函数函数(Time可推算出x坐标，Value可推算出y坐标)；使用HTML5的Canvas完成“点”的绘制(绘制时可根据各种个性化需求选择颜色、大小等效果)。

其次，配置模块10配置获取数据函数，以在获取触发事件相应的页面元素的页面坐标后，调取与所述页面坐标相应的数据；其中，每一报表类型只对应一个页面元素。

当鼠标点击事件发生时，将鼠标坐标作为参数调用获取数据函数(getEntryByPosition，x坐标可推算出最相近的Entry，假如x轴总长为N像素，一共M个点，当前x坐标为x，那就是第Math.round(x/(N/M))个entry)；将此entry的数据取出做后续事件监听处理。

如此，仅仅是在制图和交互时多了一点计算量，而1440个DOM元素所占用的空间和损耗的维护成本都可以避免了。除了上述实施例中提到的曲线图，表格、饼图等样式下的处理思路都是类似，在此不再赘述。

综上所述，将可视化渲染框架和数据源、可视化样式及其关联关系独立封装，用户只需要对数据源、可视化样式及其关联关系进行配置，即可导入可视化渲染框架进行渲染，提高了研发效率和前端性能。

所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，上述描述的系统，装置和单元的具体工作过程，可以参考前述方法实施方式中的对应过程，在此不再赘述。

在本发明所提供的几个实施方式中，应该理解到，所揭露的系统，装置和方法，可以通过其它的方式实现。例如，以上所描述的装置实施方式仅仅是示意性的，例如，所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或单元的间接耦合或通信连接，可以是电性，机械或其它的形式。

所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施方式方案的目的。

另外，在本发明各个实施方式中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以2个或2个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用硬件加软件功能单元的形式实现。

上述以软件功能单元的形式实现的集成的单元，可以存储在一个计算机可读取存储介质中。上述软件功能单元存储在一个存储介质中，包括若干指令用以使得一台计算机装置(可以是个人计算机，服务器，或者网络装置等)或处理器(processor)执行本发明各个实施方式所述方法的部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器(Read‐Only Memory，ROM)、随机存取存储器(Random Access Memory，RAM)、磁碟或者光盘等各种可以存储程序代码的介质。

最后应说明的是：以上实施方式仅用以说明本发明的技术方案，而非对其限制；尽管参照前述实施方式对本发明进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施方式所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本发明各实施方式技术方案的精神和范围。

Claims (22)

1.一种数据可视化的实现方法，其特征在于，所述方法包括：

配置数据源、可视化样式，以及所述数据源和所述可视化样式之间的关联关系；

当收到触发请求时，将所述数据源、可视化样式、关联关系的配置信息通过定制化接口导入可视化渲染框架；

所述可视化渲染框架根据所述配置信息进行渲染，并输出至浏览器引擎；

其中，所述数据源、可视化样式，以及所述可视化渲染框架分别独立封装。

2.根据权利要求1所述的数据可视化的实现方法，其特征在于，所述定制化接口为IOC接口。

3.根据权利要求1所述的数据可视化的实现方法，其特征在于，所述数据源和所述可视化样式为多对多的关联关系，每一个数据源对应至少一个可视化样式，每一个可视化样式对应至少一个数据源。

4.根据权利要求1所述的数据可视化的实现方法，其特征在于，所述可视化渲染框架根据所述配置信息进行渲染具体包括：

根据所述数据源中配置的服务查询地址及参数信息，获取相应的数据；

根据所述关联关系将所述数据转换为可视化样式匹配的渲染模型；

根据所述渲染模型，调用渲染工具进行渲染。

5.根据权利要求4所述的数据可视化的实现方法，其特征在于，所述参数信息包括：

查询数据的周期、粒度、数据ID的至少其中之一。

6.根据权利要求4所述的数据可视化的实现方法，其特征在于，根据所述渲染模型，调用渲染工具进行渲染具体包括：

根据所述可视化样式提供的结构转换逻辑，将所述渲染模型转换为对应的渲染工具所要求参数格式；

根据所述参数格式，调用对应的渲染工具进行渲染。

7.根据权利要求6所述的数据可视化的实现方法，其特征在于，根据所述参数格式，调用对应的渲染工具进行渲染具体包括：

根据所述参数格式以及所述可视化样式提供的参数逻辑，调用相应的渲染工具进行渲染。

8.根据权利要求4所述的数据可视化的实现方法，其特征在于，所述根据所述关联关系将所述数据转换为可视化样式匹配的渲染模型具体包括：

根据所述关联关系将所述数据转换为可视化样式匹配的的数据结构；

调取所述数据结构并根据与所述数据结构关联的可视化样式，将所述数据结构转换为可视化样式匹配的渲染模型。

9.根据权利要求4所述的数据可视化的实现方法，其特征在于，

所述数据源为插件形式，每个插件中包括数据的服务查询地址及参数信息；

所述可视化样式为插件形式，每个插件中包括一种可视化样式。

10.根据权利要求1所述的数据可视化的实现方法，其特征在于，所述方法还包括：

将事件监听逻辑注册到浏览器引擎。

11.根据权利要求1所述的数据可视化的实现方法，其特征在于，所述方法包括：

配置获取页面坐标函数，以获取触发事件相应的页面元素的页面坐标；

配置获取数据函数，以在获取触发事件相应的页面元素的页面坐标后，调取与所述页面坐标相应的数据；

其中，每一报表类型只对应一个页面元素。

12.一种数据可视化的实现装置，其特征在于，所述数据可视化的实现装置包括：

配置模块，用于配置数据源、可视化样式，以及所述数据源和所述可视化样式之间的关联关系；

导入模块，用于当收到触发请求时，将所述数据源、可视化样式、关联关系的配置信息通过定制化接口导入可视化渲染框架；

所述可视化渲染框架还用于根据所述配置信息进行渲染，并输出至浏览器引擎；

其中，所述数据源、可视化样式，以及所述可视化渲染框架分别独立封装。

13.根据权利要求12所述的数据可视化的实现装置，其特征在于，所述定制化接口为IOC接口。

14.根据权利要求12所述的数据可视化的实现装置，其特征在于，所述数据源和所述可视化样式为多对多的关联关系，每一个数据源对应至少一个可视化样式，每一个可视化样式对应至少一个数据源。

15.根据权利要求12所述的数据可视化的实现装置，其特征在于，所述可视化渲染框架具体用于：

根据所述数据源中配置的服务查询地址及参数信息，获取相应的数据；

根据所述关联关系将所述数据转换为可视化样式匹配的渲染模型；

根据所述渲染模型，调用渲染工具进行渲染。

16.根据权利要求15所述的数据可视化的实现装置，其特征在于，所述参数信息包括：

查询数据的周期、粒度、数据ID的至少其中之一。

17.根据权利要求15所述的数据可视化的实现装置，其特征在于，所述可视化渲染框架具体用于：

根据所述可视化样式提供的结构转换逻辑，将所述渲染模型转换为对应的渲染工具所要求参数格式；

根据所述参数格式，调用对应的渲染工具进行渲染。

18.根据权利要求17所述的数据可视化的实现装置，其特征在于，所述可视化渲染框架具体用于：

根据所述参数格式以及所述可视化样式提供的参数逻辑，调用相应的渲染工具进行渲染。

19.根据权利要求15所述的数据可视化的实现装置，其特征在于，所述可视化渲染框架具体用于：

根据所述关联关系将所述数据转换为可视化样式匹配的的数据结构；

调取所述数据结构并根据与所述数据结构关联的可视化样式，将所述数据结构转换为可视化样式匹配的渲染模型。

20.根据权利要求15所述的数据可视化的实现装置，其特征在于，

所述数据源为插件形式，每个插件中包括数据的服务查询地址及参数信息；

所述可视化样式为插件形式，每个插件中包括一种可视化样式。

21.根据权利要求12所述的数据可视化的实现装置，其特征在于，所述可视化渲染框架还用于将事件监听逻辑注册到浏览器引擎。

22.根据权利要求12所述的数据可视化的实现装置，其特征在于，所述配置模块还用于：

配置获取页面坐标函数，以获取触发事件相应的页面元素的页面坐标；

配置获取数据函数，以在获取触发事件相应的页面元素的页面坐标后，调取与所述页面坐标相应的数据；

其中，每一报表类型只对应一个页面元素。