在数据规模逐渐膨胀的当下，基于网页端的交互可视化，不再能够把所有的数据存储在内存中并处理。为了能更好得与大规模数据沟通，可视化的应用也需要一个强大的后端支撑。当前端的交互可视化遇上后端数据库服务，开发者面临着许多新兴的问题，例如交互逻辑到API以及数据库查询的映射，非同步的请求响应处理，以及缓存数据优化等等。本文的核心想法就是希望提出一个通用的框架，来帮助开发者透明得编写前端交互可视化，自动地处理上述问题。
首先，作者总结了前端交互可视化与后端联动时，开发者主要面临的五个挑战。C1生成查询，当前端的交互需要访问数据时，在后端需要相应地生成查询语句。C2数据通信，前端与后端之间需要接口来进行数据的通信。C3并发处理的问题，主要指通信的异步性，使得请求的响应顺序并不一定是时序性的。C4缓存优化的问题，以及C5交互的多样性，为不同的交互可能单独的编写相关的API，十分繁琐。那么面对以上挑战的框架，最需要解决的两个方面，一个是透明性，指开发者可以环境无关地编写可视化和交互，另一个是时间上下文，开发者可以定义可视化的状态在接收到不同请求回应时。
SQL作为最通用的后端语言之一，作者选择使用SQL作为框架DIEL的基础，对前端与后端都使用类SQL的接口与语言。类似SQL的数据模型，DIEL将一个交互事件看作一个数据项，存储在事先定义好的事件表中，然后进入一个事件循环。事件循环主要有四个步骤，第一步是调用事件函数，将新的事件存储到对应的事件表中；第二步在存储时为该事件添加一个时间戳，同时将该数据项送至后端进行数据查询；第三步前端得到返回的数据结果的同时，保留原先的时间戳为请求时间戳，并为数据添加一个新的事件戳，代表接收到返回结果的时间。第四步是调用渲染函数，将返回的数据作为新的参数传递进去。而这一次调用也将做为一个新的事件，开启新的事件循环，只是渲染事件并不涉及到后端。
DIEL的语法是基于SQL语法的，在初始化DIEL时，开发者只需要将所有的后端查询语句文件和后端的地址传递给DIEL。在对交互事件构建事件表时，需要申明表的名字，表的参数以及数据类型。在构建完成事件表后，开发者就可以在前端直接通过DIEL语句（类SQL语句）控制事件的行为以及可视化的状态，而这些可以很好地在前端封装为函数，保证了对于开发者的透明性。接下来，作者讨论了在可视化中的八种基本交互方式，在DIEL中的具体实现，分别是选择、过滤、重构、探索、编码、抽象、链接、撤销。
并发相关的问题，根据导致的原因可以分为三类。第一类是由于通信的延迟等原因导致的响应结果顺序与请求顺序不同情况，由于DIEL将响应结果也作为数据单独存储在对应已申明的表中，并且每个数据项都包含有请求时间戳和返回时间戳作为表的两个属性，因此开发者可以直接用SQL语句来通过数据控制调用的函数以及最终可视化的状态。第二类是由于数据实时加载的缘故，在可视化运行的同时有新的数据流入，通常有两种处理方法，一种是每当有新的数据流入，实时地刷新可视化的结果，另一种是加载新的数据后，只在有数据相关的交互事件后再刷新可视化的状态。这两种方法都可以在DIEL中实现。第三类是因为人在与可视化交互的过程中需要时间去获得知识，因而可以假设交互之间应当存在最小时间间隔，通过控制最小时间戳的差可以实现，同时避免了用户因连续点击等原因而出现的过快的误触等。
在实际运行的过程中，DIEL使用了两个数据库中成熟的技术来提高运行的效率，分别是分布式查询处理和维持物化视图。结合开发者在实际中使用DIEL的体验，作者讨论了DIEL目前的局限性，主要体现在三个方面。第一点是，DIEL的能力还需要加强和优化，例如目前的查询语句并没有根据实际的数据库类型或者网络架构而进行优化或加速，另一方面，目前的事件表存储了全部的历史事件，随着可视化的运行，事件表会逐渐变长，最终超出前端的存储上限。第二个方面是，框架基于SQL而SQL的表达能力存在一定的局限性。第三个方面是，DIEL提供了一些快捷的关键词来简化SQL的编写，但调试排错的过程却变得更苦难了，开发者可能更难直接定位代码中的错误。
笔者认为这篇论文尝试通过SQL的语法和数据模型来规范化交互可视化构建时，前端与后端之间的通信和开发环境等。作者使用SQL的申明语句来模式化八种交互方式的结果很新颖，这样的思路也值得学习。在实际过程中，随着交互的多样以及融合，也许开发者在使用DIEL的方式会容易产生一些错误，可能更需要一些约束性的语句，类似SQL中的alert等来约束交互，比避免产生一些冲突性的错误。
评论关闭。