- 可视化论文精读系列：VegaFusion
- 论文题目：《VegaFusion: Automatic Server-Side Scaling for Interactive Vega Visualizations 》
- 论文作者：Nicolas Kruchten ，Jon Mease，Dominik Moritz
Vega 是啥？
在了解 VegaFusion 做的事情之前，你有必要了解一下Vega，上链接：
在研究VegaFusion 做了什么之前，先来解决灵魂拷问：为什么要做服务端运算？
论文说：因为 Vega 太慢了。在大数据量的情况下计算缓慢。在交互场景下计算缓慢。
这....也太直接了吧，丝毫不考虑Vega 的感受呀。
那 VegaFusion 做了什么？
一言以蔽之：使用服务端计算分担浏览器图表渲染计算任务。
还是不懂？好吧，我们先看看demo。
Large Altair Gallery Examples
Emm，看起来不错。
从上图的效果看，在数据量较大的场景下，在浏览器端进行大量的数据运算，会引起较大的交互延迟。如果把运算过程放到服务端，则能带来非常好的用户体验。一个字：顺滑！
前人栽树
VegaFusion 的论文中声明了他实际上是基于更早的一篇论文《Dynamic client-server optimization for scalable interactive visualization on the web》所做的实现。
在这篇 2015 年著成的论文中，作者描述了针对于可视化交互所做的 Client-Server 的动态优化系统。让我们首先来看看这篇论文。
系统构成
在该论文所述系统中，可视化的生成流程如下：
可以看出，整体结构仍旧与 GoG 的理论类似，但是被处理成了更为简明的几个环节：
- 数据转化计算：基于数据逻辑的计算，得到的计算结果仅与数据本身关联；
- 视觉转化计算：与视觉呈现关联的计算，例如与屏幕像素点相关的计算；
- 视觉通道映射：将视觉转化计算结果应用到绘制图元中。
（悄悄的告诉你，
这一模型实际上来源于 2000 年的论文《A taxonomy of visualization techniques using the data state reference model》）
这一模型并不像 GoG 那样细致。需要注意的是，核心两个转化环节（Data & Visualization）的划分描述了两类计算类型的区别：不涉及渲染设备带来的限制的计算 与 针对于具体渲染的计算。
两者一定程度上可以对应到 Server 端计算和 Client，但是并不一定需要依据这一划分进行实现，在不考虑不同客户端复用计算结果的场景下，Visualization 计算同样可以交由服务端执行。
计算模型
论文首先将延迟归纳为两个算式。
- 交互式响应延迟时间的总和 cost 通过这一式子进行描述：
其中 i 代表不同的交互动作，latency 代表对应的延迟，w 代表了不同延迟的权重。
- 单次延迟 latency 通过这一式子进行描述：
其中，b & c & d 分别代表了当前执行中由数据决定的参数，如果需要执行网络传输则 r 为 1 否则为 0。
两个式子虽然给出了具体的计算方式，但实际上两个更偏向于 定性 的分析，或者根据经验值来进行优化。
虽然我们很难直接拿上这两个式子去做计算，但是至少论文中提出了一些优化的思考方向：
- 划分 Server 与 Client 职责（衡量网络传输与 CPU 执行时间，取得更优的平衡）
- 优化 dataflow 结构以降低计算量 & 数据传输量（例如提前执行 filter）
- 动态变更 dataflow 以优化执行过程（例如添加运算符以执行缓存）
同时，论文提供了一个简单的预测模型，帮助我们思考如何执行优化：
图片描述了一个基于马尔可夫链的交互状态转化模型。所有可能的下一个交互状态的概率均由当前状态所确定。这一预测模型有助于我们在交互发生之前提前执行某些操作（例如数据加载）以优化下一状态的延时。
但想要真正使用这一模型，我们仍然需要思考：如何将连续的交互形式离散化（例如 scroll 交互）？
系统示例
针对于具体的优化措施，论文并没有给出详细的描述。我们可以从论文提供的一些例子中得到一些借鉴。
图片实际上描述了 划分 Server 与 Client 职责 的优化，左侧执行流程中 aggregation 过程由 Server 执行。这一处理应用于初始的渲染，用于降低大数据量带来的网络开销。交互变更到数据较为稀疏的区域后（例如缩放交互），客户端可以在空闲时间加载足够的数据，并承担更多的数据计算阶段，从而剪除不必要的数据传输。
VegaFusion
好了。该看看 VegaFusion 了。
与上述论文相比，VegaFusion 论文所讲述的内容更多的是 工程实现 的设计。
在 VegaFusion 的理想场景下，图表库的触角触及到数据分析的领域，试图通过将图表库逻辑与数据分析后端支持更加密切结合的方式优化可视化体验。
工程实现目标
VegaFusion 所做的事情与上一篇论文所描述的相同，但是 VegaFusion 所针对的场景更狭窄。VegaFusion 期望达成三个目标：
- 渐进增强 & 优雅降级：如果存在服务端则执行服务端计算优化，如果不存在服务端则仍然正常支持客户端渲染；
- 将计算移出客户端：将较重的计算负担从客户端转移至服务端执行；
- 细粒度的缓存控制：对数据流中的各个计算阶段（Operator）结果进行细粒度的缓存。
架构设计
VegaFusion 的核心架构设计并不复杂。
在 Vega 的基础上，VegaFusion 设计了三个核心模块：
- Planner：planner 基于 vega 解析的结果将 runtime spec 分为两个部分，一部分为 Client 负责执行的 operator ，另一部分为 Server 负责执行的 operator；
- Middleware：middleware 负责与 Server 进行通信，将服务端计算嵌入到 dataflow 过程中；
- Runtime：这一 runtime 并不是 vega 解析生成的 runtime spec，而是存在于服务端的执行结构，负责与 middleware 通信、执行 operator 计算并做缓存处理。
VegaFusion 小结
VegaFusion 所提供的架构基本上是一种非常符合直觉的实现结构。
- 在 VegaFusion 所针对的大数据量计算场景中，尤其是 包含 Filter/Aggregate 的计算场景 中，VegaFusion 很好的达到了性能优化的目的；
- 在数据计算并不重要的场景下，VegaFusion 所能提供帮助极其有限，甚至造成负优化；
- VegaFusion 所设计的缓存结构在特定场景下效果一般，并且从论文的内容来看，其实际达到的效果并没有数据验证支撑。
让我们跳出 VegaFusion 为自己设定的框架，从更广泛的角度来评价论文的内容。与上一篇论文相互印证，我们还可以发现一些论文中并没有提到的点：
- 在 VegaFusion Planner 的设计中，并没有提到具体的 优化算法。VegaFusion 并未考虑如何更优的划分 Server 与 Client 的职责，而是简单的将 transform 进行了划分（这也也意味着较小数据量的传输可能造成比 Server 与 Client 间计算性能差异更多的时间消耗）；
- VegaFusion 对 Server 与 Client 的计算职责划分并不支持 动态调整，因此其无法应用上一篇论文中所提到的动态优化措施；
回观 VegaFusion 所设定的目标，他很好的完成了三项要求，但是并没有对更广泛的延时优化场景作出足够的尝试。其更像是已经有了实现的工程结果，随后做了实现目标的归纳。
参考资料
-
《VegaFusion: Automatic Server-Side Scaling for Interactive Vega Visualizations》
-
《Dynamic client-server optimization for scalable interactive visualization on the web》
-
《A taxonomy of visualization techniques using the data state reference model》
