AntV 是由蚂蚁集团产出的开源企业级数据可视化解决方案，在企业内部和社区有大量应用实践积累。本文将基于这些实践经验和领域研究，结合 AntV/G2 5.0 和 AntV/AVA 3.0 在升级过程中的更新，向大家分享相关思考。我们总结了分析需求对可视化工程提出的三点挑战，用一个具体工程案例来展示可视化工程升级前后的对比。我们总结了可视化应该基于声明式语法的原因，并且提出了三个可视化工程发展上要考虑的趋势：将可视化本身视为一种数据、更重视分析交流的便捷度、走向更深度的自动化。
对可视化工程提出更高要求
以前的 BI 工具和图表主要的目的是展示数据，在分析类需求日益增长后，业务场景中越来越重视图表之上的分析能力。因此，许多原先的可视化基础设施不能满足更高的要求，在工程上产生了许多问题。
第一，分析需求带来了技术分层增多，导致了多层封装降低灵活度的问题。由于基础图表库大多只能提供最通用的能力和展示形态，许多产品的技术设计中会约束需求从而定制图表组件。在定制图表组件之上，还需要以各种交互、tooltip 等形式提供进一步的分析功能。有些大型业务中还需要拆分为通用分析功能和业务特定的功能两层。这种层层封装带来的开发复杂和复用困难的问题。而在一些专门从事商业智能、数据分析领域的大型应用中，还可能出现图表组件本身的层层堆砌。
实际业务中对可视化的层层封装
第二，分析需求带来了更多图形元素，在图表上添加特性变得更加繁琐。原本只需要展示数据客观状态的图表通常都是结构比较清晰简单的。但是，如果要展示更多分析性的内容，则要考虑各种“特例”，比如局部高亮、凭空添加趋势线、指向特定数据位置的箭头和文本，等等。这些图形元素通常具有不规则性，他们的开发比较定制、难度也更大。同时，这些元素的出现条件和布局方式也需要更多考量。
比如“线”的绘制，就多了很多种类型。
第三，分析需求带来了分析结论，在可视化上需要合理展示这些洞察结果。不同的洞察类型应该使用什么样的设计标准来进行传达？是否需要合理的文本解读来辅助洞察的理解？图文结合的形式、交互的形式应该如何选择？这些都不是简单的问题。
用可视化展示洞察信息的几种层次
一个具体的工程案例
在公司内部，我们基于 AntV/G2 栈构建了业务图表资产库。通过图表资产库向上服务蚂蚁众多的数据分析业务场景。假如你是一名前端工程师，接了个“小”需求，要在图表资产库中做出一张下面这样的图表。完成它，需要哪些步骤，需要多长时间呢？可能有同学会疑惑，这不就是个折线图吗，有什么难点呢？其实，它不是普通的折线图，而是带有异动信息的增强展现图表。仔细看，可以发现，它除了折线图本身的样子外，还带有波动区间、基线和指标异常值等额外信息。
基于原先的可视化工程，有两种方案可以实现这个图表：
- 基于图表标注 annotation，使用组件库的标注能力 API 在原折线图组件上叠加增强展现信息。
- 绘制多图层图表，将折线图、面积图两个图表作图层叠加。使用折线图绘制实际值、基线和异常点，使用面积图绘制波动区间。
方案一能在原有折线图上直接迭代，开发者只需要关注 annotation，不需要过多关心折线图本身的逻辑，更不会碰伤折线图现有能力。但在 G2 4.x 中 annotation 是“二等公民”，无法自由绑定数据、绘制自定义图形、生成 Legend 和 Tooltip 组件，更无法和图表本身进行联动，图表的功能扩展性会变差。
而方案二中的多图层图表需要替换原图表组件，改动量较大，很可能碰伤存量图表。如果可视化图表和增强展现的开发涉及到多团队合作，这个问题会变得更加复杂。双方将不可避免地需要在对方的仓库中如履薄冰地修改代码。我们期望有种方式，集合方案一二的好处，无需担忧它们的缺点。
G5 5.0 底层基于 Spec（图表的声明式描述），还提供了自定义 Mark（图形符号）。不再区分 annotation（图形标注）和 geometry（几何元素），所有的几何元素都可以是 Mark，都是 “一等公民”。从此，多图层叠加变得更灵活，展示能力变得更强大，图表 Mark 和增强展现 Mark 能够自由组合。Spec 结构本身也便于存储、流转和复用。
基于 G2 5.0 和 AVA 3.0，蚂蚁内部的数据分析业务和技术架构得以升级，能够在原图表组件之上自由叠加内容，且叠加的内容和其他几何元素 geometry 是同等地位的。可视化图表和增强展现内容可以分层设计与开发，研发时间和合作摩擦将大大降低。增强展现内容可以抽为组件，各处复用。
现在，只需要将 AVA 可视化数据洞察里生成的 Spec 放入 G2。异动折线图就会跃然于眼前。借助 AVA ，还可以为图表添加直观的文本解读。
基于声明式语法的可视化
为了分析过程的灵活性和分析结果的易于传达，可视化工具底层的范式应该向声明式发展。这种底层架构的选择是十分重要的，是令其他设计考量具有可行性的基础。
命令式（imperative）和声明式（declarative）是两种相对的编程范式。在命令式编程中，开发者需要指定如何执行任务，更面向过程“怎么做（How）”。相比之下，声明式编程则让开发者只需要描述想完成的结果“是什么样（What）”。对于可视化而言，本身就是为了“展示”和“分析”。在展示上，通常我们更关心的是结果的样子，因此声明式的语法更加适合。在分析上，声明式语法可以让我们更专注于数据本身，而不用关注太多代码的实现细节，提高数据分析效率。
一个命令式和声明式对比的案例
不仅如此，声明式编程范式本身还有很多优势。由于简化了过程描述，声明式语法更加简洁和易于理解，这就降低了学习成本；不必通过反复的过程描述就可以创建复杂的效果，提高了开发效率；描述同样的局部结果可以使用同样的声明片段，可复用性更强；声明式的静态结构本身可以当做一种数据形式，有利于存储、跨平台传输和转换格式。
近十几年来，无论在业界还是学界，可视化工具的发展趋势中一直可以看到声明式语法的影响力。比如 ECharts 一类的图表库虽然不能说是声明式的，但其中以 JS 对象或 JSON 结构进行图表配置的“配置式”方式也属于一种声明式能力。再到 Vega 和 Vega-Lite 声明式语法的发展，已经形成了巨大的影响力。
因此，当我们现在来讨论下一代可视化工具的时候，不得不将“支持声明式语法”作为一个重要的考量。以一个图表库来说，也许可以不完全是一种声明式形态，但至少其底层应该支持声明式的规范表达（Specification）。
以 G2 v5 设计为例，虽然仍然提供命令式的链式语法 API，但底层都对应一套声明式的 Specification 表达。而 AVA 作为智能可视分析框架，其图表推荐的产出也直接是声明式表达而不是某种具象的图形形式。
- Heer, J. and Bostock, M., 2010. Declarative language design for interactive visualization. IEEE Transactions on Visualization and Computer Graphics, 16(6), pp.1149-1156.
- Li, D., Mei, H., Shen, Y., Su, S., Zhang, W., Wang, J., Zu, M. and Chen, W., 2018. ECharts: a declarative framework for rapid construction of web-based visualization. Visual Informatics, 2(2), pp.136-146.
- Satyanarayan, A., Moritz, D., Wongsuphasawat, K. and Heer, J., 2016. Vega-lite: A grammar of interactive graphics. IEEE transactions on visualization and computer graphics, 23(1), pp.341-350.
将可视化作为一种数据
可视化作为一种承载分析结果的载体，其本身应该要支持被转换、被查询等数据向的能力，新的可视化工程和工具应该要将支持这类能力。今天，各行各业对数据的重视程度越来越高，对数据的利用率也越来越高。可视化作为数据展示和传播的最主要渠道已经非常普及。无论是承载可视化内容的图片还是可交互的可视化媒体，在网络和社会中的数量都在飞速增长。不论是图片还是代码的形式，这些用来展示和解释数据的可视化，本身也成为了一种数据。
AI4VIS 提出的几种可视化应用场景
在 AI4VIS 这篇综述论文中，通过把可视化本身看做数据这一种视角，借鉴数据库的理论，将近年来数据可视化领域中的大量工作进行了分类总结。比如可视化的转换（Transformation）、评估（Assessment）、比较（Comparison）、查询（Querying）、推理（Reasoning）、推荐（Recommendation）、挖掘（Mining）。基于这种精彩的类比，我们得以看到图表的更多潜在的应用方向。
以格式转换（Transformation）为例，通常我们可以很容易地通过图表库将代码转换成可视化图表，但是将网页上的可交互图表或静态图片转化成代码或声明式 Specification 的逆向工程则通常很难。虽然现在的图像识别技术日新月异，但如果图片分辨率不够高或者未标出一些具体的数字文本，要精确解析图表背后的明细数据几乎是不可能的。但是，由于图片本身仍然是传递信息（数据和洞察）的最主要形式之一，这个问题需要有方案解决。一种可能的解决方案是类似于 VisCode 的方法，将数据或者图表的声明式代码通过“暗水印”的方式编码在图片中，然后图片经过解码可以还原“复活”。
AntV 提供的数据暗水印工具，可以将图表信息编码在图片上， Demo 地址：https://antv.vision/vis-steg/
再以查询（querying）为例，想象一个含有大量可视化内容的公司 BI 系统，要从中搜索出一张图表来，并不比从我们的手机相册里凭印象找出一张曾经随手拍摄的照片容易。除了从日期、部门、报表类别等路径一层层去找，更好的方式应该是拥有一套可视化搜索系统。如果每个可视化实例背后都有其详细的信息，这样的查询系统就是可以建立的。不过，只包含图表本身的声明式代码可能不够，还可以包含和分析相关的更多信息。
比如，在一个分析系统中，一个可视化实例背后至少应该包含以下三种结构：
- 数据模型：数据的查询条件、来源、数据本身，等；
- 展示形式：图表的类型、声明式结构、标注样式，等；
- 洞察信息：想表达的分析洞见、洞察类型、解释性的文本，等。
基于转换和查询的例子，我们可以想象其余几种应用类型。比如通过对可视化数据库的推理和挖掘来获得大量额外信息、比如通过对图表相似性的比较来生成和推荐图表，等等。
通过图表间的计算，在 AR 环境中实现自动的类似图表“加法”的效果
基于这种图表即数据的定义，还让图表本身变得可以计算，比如图表间的交、并、差等逻辑运算，以此可以引发出很多应用形态。在 ComputableViz 这篇论文中，作者展示了图表计算的多种应用场景。比如可以将两张柱状图相加变成一张堆叠柱状图。
- Wu, A., Wang, Y., Shu, X., Moritz, D., Cui, W., Zhang, H., Zhang, D. and Qu, H., 2021. Ai4vis: Survey on artificial intelligence approaches for data visualization. IEEE Transactions on Visualization and Computer Graphics.
- Zhang, P., Li, C. and Wang, C., 2020. Viscode: Embedding information in visualization images using encoder-decoder network. IEEE Transactions on Visualization and Computer Graphics, 27(2), pp.326-336.
- Wu, A., Tong, W., Li, H., Moritz, D., Wang, Y. and Qu, H., 2022, April. Computableviz: Mathematical operators as a formalism for visualisation processing and analysis. In Proceedings of the 2022 CHI Conference on Human Factors in Computing Systems (pp. 1-15).
更重视分析交流的便捷度
数据分析的过程也是高频高密度的综合处理信息的过程，面向分析的可视化工具应该对信息的处理和交流有更友好的支持。这种更高的友好度包含：对人更友好、对机器更友好、对以上任意两者间的协同更友好。
从对人更友好的角度出发，可视化产品应该有灵活的探索分析交互能力、美观而准确的展示标准、对分析结果具有充分的解释力。比如对于图表库来说，交互灵活度的提升、动画能力的提升、数据标注能力的提升、更丰富的图表类型，都是要努力的方向。再比如对于分析流程而言，从交互发起分析、更合理的标注规范、分析结论和洞察的可解释、分析结果的灵活导出等，都是可以发力的方向。
G2 5.0 拥有丰富的展示和交互效果
比如 G2 从 v4 向 v5 升级的过程中，针对分析类的图表使用场景，在动画、标注、风格、图表类型灵活度等方面进行了专门的优化。
AVA 所参照的洞察展示设计标准
对于分析过程中的设计规范和技术方案，我们总结了一份《增强分析白皮书——洞察展现篇》，分享给大家~
从对机器更友好的角度出发，可视化工程应该能对各种 API 和跨平台传输有更好的兼容性。随着人工智能和大数据浪潮的一次次升级，数据分析背后的计算和模型能力都在不断增强。面向分析的可视化工程应该让机器可以更好地处理和解释可视化信息。一方面通过声明式存储可以便于做到这一点，另一方面也可以考虑提供更“接口友好（API Friendly）”的设计以极大利用后端计算能力。
从协同角度来看，以标准化结构存储的可视化信息已经能够做到在“机器”间方便地流转和扩展。我们还需要考虑一些用户协作上的问题。随着分析平台的普及，越来越多分析师、业务人员、开发者参与到分析工作中来。举个例子，同一份报表、同一个图表、同一份洞察信息，都可能由多人参与编辑，甚至是实时协同编辑。在产品能力方面，我们需要考虑支持用户对于可视化的协同交互。在可视化工程能力方面，上述提到的多种基于声明式的衍生能力可以帮到我们。比如，当图表本身通过 Specification 描述，我们可以更好地对图表的编辑做版本控制。甚至，当图表间支持了诸如差（Difference）的计算能力后，系统可以自动对来自不同用户和不同分支的图表版本进行自动冲突识别和自动合并。
有意思的是，甚至一些“人去理解机器”的过程也可以变得简单。比如当一个图表的图片其实是根据声明式结构形成的，人们在阅读其代码或者 URL 时都获得了更大的可解释性和编辑的便捷性。
一个基于 QuickChart 的可解释性可视化图片地址案例
- Apache ECharts. (n.d.). Bar chart with data color [Example]. Retrieved October20,2021, from https://echarts.apache.org/examples/zh/editor.html?c=bar-data-color
- QuickChart. (n.d.). QuickChart: Open Source Chart Image API. Retrieved March 20, 2023, fromhttps://quickchart.io/
走向更深度的自动化
为了让用户能更专心于数据分析本身，分析产品应该尽可能提高自动化水平，不让繁琐的配置流程打断分析者的心流。一方面，可以利用自动化简化分析环节，比如自动推荐图表、自动配置、自动布局、自动设置特定分析方法的流程，等等。另一方面，应该尽可能提供智能分析能力，主动为用户提供他未曾发现的信息。
AVA 经验驱动的图表推荐过程示意图
关于自动图表推荐，已经有许多研究和实践。无论是基于简单决策树的思路，基于约束系统的推荐思路，还是基于模型的推荐，在分析产品的工程中大多是为了解决选择常用图表类型和自动配置映射关系的问题。这是未来的数据分析类应用所必须解决的问题。比如，一个着重于分析过程的自助分析系统，用户每次选择出的数据子空间是不同的、临时的，不可能每次都展示一个表格或者每次都需要用户配置图表，必须具备自动绘制图表的能力。
AVA 提供了前端侧的图表推荐能力，可以基于所选数据自动推荐图表类型。
关于智能分析能力，也有很多业界产品在不断探索。比如在基于数据自动挖掘出一些智能洞察并对用户进行提示、播报、告警。比如将某些标准的分析方法配置为自动化算子，让用户通过简单交互就能完成一整套分析流程。
增强分析应用中的一些智能分析场景和资产规范
最后畅想一下，在大模型时代，无论是图表推荐、洞察挖掘、洞察解释、分析问答等，都可以通过更高效的形式为业务和用户带来价值。
类似 chatGPT 的可视化问答形式的概念
AntV 一直坚持探索最先进的可视化理论，并应用到实际工程和业务中去。基于本文的思考，G2 和 AVA 将不断优化，为未来各行各业的数据分析助力。今天 G2 5.0 和 AVA 3.0 已正式发布，欢迎尝鲜，更欢迎意见、建议和贡献！
G2 和 AVA 研发团队在发布现场
更多分享
- G2 5.0 技术发布 https://www.yuque.com/antv/blog/zgtv9ezu83r8nusr
- AVA 3.0 介绍 https://www.yuque.com/antv/blog/ava2022
- 白皮书发布 https://www.yuque.com/antv/whitepapers/sqkgczdmvrzzigsv
AntV 数据可视化官网
AntV 数据可视化 GitHub
✨ 关注我们，了解更多~
