厉害了 word 哥，这篇关于可视化工具的文章竟然不是清单体的！
当我们谈论可视化工具时我们在谈论什么
以『可视化工具』作为关键词，会搜索到很多类似『N个可视化工具』标题的清单体文章。在知乎有关可视化工具问题的回答中，也会看到很多这样的答案。
很遗憾，大部分的关于可视化的文章都只是简单的罗列一些工具。有 JavaScript 图表库，有 BI 系统，有的甚至只是某种特定可视化形式的生成工具。不同的工具为不同的使用场景、不同能力构成的用户而设计，将他们不加区分的列在一起明显是错误的。
这些清单体的内容暴露了一个问题：我们对于可视化工具缺乏系统化的讨论，其中最重要的就是对工具的分类。
分类对于我们认识事物有着极其重要的作用：
- 分类让我们告别零散的单维列表，创建多维度的结构化信息
- 不再需要单独学习零散的每一个，而是举一反三的了解一类
- 分类甚至可以帮助我们发现未知领域
这篇文章将发掘各种可视化工具的本质，并尝试对他们进行分类。希望在学习、选择、创造可视化工具时对你有所帮助。
需要注意的是，本文的“可视化”是一个广泛的概念，它可能包含了我们经常谈论的信息图、数据新闻、统计图等等概念。区分这些概念并不是本文的重点，想要严格区分它们的意义也不是一件容易的事情，不妨先搁置这些区别采用通常意义上的“可视化”一词来泛指。
分类法
通过事物的属性我们可以建立很多分类方法。可视化工具有多种属性，例如是否需要编写代码、是否支持交互操作等等。但只有选择更接近本质的属性才能建立真正有效的分类法。
可视化本质上是数据到图形的映射，那么对于可视化工具来说，创建数据到图形映射过程的差异可以作为分类的关键属性。
在 2015 年的 OpenVisConf 上， Jeffrey Heer 关于下一代可视化工具的演讲中提到了下面的可视化工具分类法：经过尝试与思考，我对上面的分类法做了一些修改：移除了 Component architectures 这类，因为这个类别经常会导致模棱两可的情况（并且 Prefuse 和 Flare 目前已不再维护）。并且不再把交互形式作为一种分类依据，而是将构建数据到图形过程的封装程度作为依据。修改后的分类如下：
- 图形系统类
- 可视化语法类
- 可视化分析类
- 图表类
下面将会详细的介绍这些分类，每个类别还会选择一些代表工具作为参照。
1. 图形系统类
图形系统类包含了类似 OpenGL、WebGL、Canvas、SVG 这样的底层图形系统，也包含了类似 Three.js、Raphael 等这些在基础图形系统上封装出来的工具包，还应该包含 illustrator、Sketch 等这类 GUI 的矢量图形工具（其实还应该包含笔和纸）。
这类工具大都并非专为可视化而生，它们提供了较为底层的绘图 API，使用时需要编写绘图代码，进行大量的数据到图形几何属性的映射计算。
- 优点：极高的自由度，可控制设计细节，发挥无限创意；
- 缺点：过于底层，很多事情需要亲力亲为，即使制作一个非常简单的柱状图也需要很大的工作量；学习曲线陡峭，需要对数学与编程有较深入的了解，才能真正发挥出这些工具的威力。
Processing
Processing 是一个非常具有代表性的编程语言，专门为电子艺术和视觉交互设计而创建。查看 Processing 的 API 就会发现典型绘图系统的特征：Shape、Curve、Color。
Nodebox 3
NodeBox 3 并不需要编写绘图代码，取而代之的是拖拽并连接绘制流程。本质上来说 NodeBox 3 依然是图形系统，只不过他的接口是以 Flow-based programming 的形式呈现给使用者的。
2. 可视化语法类
为了摆脱繁琐的绘制图形操作与计算，通过对底层图形系统进行封装与可视化流程的统一，产生了可视化语法（Visualization Grammar）。可视化语法指的是一种描述可视化的方法，它由由各种可视化元素构成。常见的可视化元素有：Data、Transforms、Scales、Guides、Marks。以柱状图为例，它的可视化语法描述如下：
- 优点：可视化语法为我们提供了声明式的可视描述方法，我们不再需要操作原始的图形来构建可视化。同时又具备很高的灵活性，可以控制丰富图形元素的细节。可视化语法非常适合作为更高层可视化工具的渲染引擎，无需与更加底层的图形接口打交道即可产出高自定义的可视化内容。
- 缺点：作为一种“语法”，接口设计的好坏与对语法的掌握程度限制了应用的程度；学习曲线较陡。
D3
D3 是最为流行的可视化工具之一，D3 底层是基于 Web 的 SVG 图形系统。而在 D3 之上，构建出了无数的可视化库。
为什么将 D3 归入可视化语法呢？我们可以观察一段 D3 代码，其主要内容就是围绕数据(Data)进行变换（Transforms），创建数据到视觉映射的映射（Scale、Marks），所以说 D3 是一种松散形式的可视化语法。
Vega
Vega 是一个非常标准的应用可视化语法的工具，并且自创建之初就定义为更高层工具的底层引擎，设计十分用心：只需一个 JSON 描述文件，便可渲染出各种类型的交互式可视化内容。Vega 与 D3 师出同门，作为晚辈的 Vega 也许并没有 D3 那么有名，但是其设计思路非常值得借鉴。
Lyra
Lyra 是一个无需代码即可设计可视化内容的交互式工具，本质上是一个交互式的 Vega 环境，将“写”描述文件变成“拖拽”配置文件。相比于 Tableau，Lyra 具有更高的灵活性，可控制的设计细节更多。二者的对比也体现了可视化语法与图表工具的区别。
3. 可视化分析语法类
可视化分析语法与上面的可视化语法有些相似，区分这两类时只需抓住一个要点即可：可视化语法偏向可视化的构建（面向图形，封装图形接口），而可视化分析语法更倾向于解决实际的问题（面向分析）。可视化语法与图表工具也有一定区别：可视化分析语法提供了更丰富的自定义接口甚至是可拼装的组件，而图表工具更多是基于一个图表模板来进行参数调整。与可视化语法一样，可视化分析语法可以作为更高层级工具的底层依赖，也可以独立运作。
- 优点：可快速完成分析图表的构建；具有一定的灵活性；
- 缺点：对设计细节无法控制；受限于语法的设计与现实。
ggplot2
ggplot2 是一个基于 Grammar of Graphics 的 R 语言统计学绘图框架。通过基础图表属性的拼装便可构建出丰富且图表：data、geoms（几何属性如 size、color、x/y）、coordinate。
类似的还有Wolfram、Matlab等。
VizQL
作为 Tableau 的底层支撑，VizQL 是一种声明式的编程语言，它可以用来描述常见的可视化类型。简单来说，VizQL 定义了从查询数据记录的结果到图表上 Marks 的映射，使得数据的探索更为方便快捷，从而实现高效的可视化分析。
Vega-lite
相比于Vega，Vega-lite 具有更高的抽象层级，大量的默认参数让使用者无需关心更多的细节便可快速制作出统计图表。
4. 图表类
历史悠久的 Excel 以及大部分的 BI（Buniess Intellgence) 工具都属于这一分类。这类工具一般需要固定格式的数据结构，选择某种可视化图表，采用图表模板、字段填充或参数配置的方式来自定义图表。
需要注意的是，很多（并非所有）基于 Web 技术的 JavaScript 图表库也属于此分类，因为本质上这些图表库也使用参数配置，只不过是以代码的形式来进行。
- 优点：可方便快捷的制作出常见的图表，学习成本低；一些工具还具有强大的数据处理功能与交互式的界面；
- 缺点：无法更高的自定义需求与定制化的可视化形式。
Excel（图表模板）
从列表中选择一种图表类型，然后选择主题或是配色即可得到图表。大部分对自定义要求不是很高的工具都选择这类实现方式。例如 Excel、Plot.ly，还有一些信息图制作工具如 infogr.am 等。
Tableau（字段填充类）
相比于图表模板类的选择图表类型，越来越多的 BI 系统选择使用更具交互性的拖拽式字段填充。与简单的选择图表类型然后选择参数的传统可视化创建方式相比，这种交互式的工具更加符合直觉，从而提高了数据分析的效率。并且细化了可视化元素，增加了可视化的灵活性，为创建更复杂、更自定义化的可视化效果提供了可能。
类似的产品的还有开源的 Raw、Polestar 等。
JavaScript 图表库（参数配置类）
我们经常见到的大部分 JavaScript 图表库也属于图表工具，虽然要编写代码，但大部分的代码都是在配置图表的参数。这类图表库一般都有着详尽的参数文档，来说明哪些参数可以自定义。虽然有时图表库无法百分之百的满足我们的自定义需求，但是如果要在 Web 平台创建图表首先还是应该选择使用这种工具。这类工具的代表： Highcharts、ECharts、还有基于 d3.js 的大量图表库等等。
总结
这就是四种分类，总的来说各种不同的类型是易用性与表现力相互权衡的产物。放弃了易用性，带来的更强的表现力；提高了易用性，却降低了表现力。不同的平衡构成也决定了工具所适用场景的不同。
本文讨论的分类法并不是一个非常完美的分类方法，也许会出现一些工具无法明确的归在哪一类的情况，这时我们就需要思考是分类的问题还是工具本身特性所导致的。
如何选择工具
面对越来越多的可视化工具，我们该如何选择呢？
首先应广泛了解各种工具的特点，对于各类工具的能力有所了解，哪些是工具可以做到的，哪些做不到的。然后从需求出发，明确自身可视化目标，选择适合自己的工具来学习掌握。为什么要进行可视化，是为了分析问题，还是为了通过数据讲述一个故事？可以通过回答这些问题来帮助我们选择工具。
在开发复杂可视化时，可在初期或原型阶段选择封装程度较高的工具，忽略视觉细节快速完成原型，验证想法，了解数据内涵。
工具的未来
前面讨论了现有的可视化工具，那么未来的可视化工具应该是什么样的？作为工具的生产者我们应当创造出什么样的工具？这里是我一些个人的想法：
不要重复劳动
几乎每隔一段时间就会出现新的 JavaScript 图表库，而他们的形态大都是固定图表形式与参数配置。这些图表库并非没有价值，而是作为工具的创造者应当将更多的精力放在如何运用更好的设计来解决可视化问题，而不是耗费时间在一些重复的问题上。
例如 G2 和 Recharts 我认为是一些很好的尝试，它并没有采取常规的图表库的设计思路。G2 使用了 Grammar of Graphics 来作为支撑，而 Recharts 则充分利用了 React 的组件机制。虽然 Grammar of Graphics 和组件拼装并不是什么新鲜的概念，但相比于其他图表库他们确实是在探索和思考。
构建生态系统
在某些场景下，完整的生态系统胜过单一的工具。Vega 提供了自底向上的完整工具链，从图形系统封装 vega、可视化分析工具 vega-lite 到交互式图表创建工具 Lyra，再到可视化方法推荐工具 Voyager。Vega 构建了一个囊括可视化工作中各个阶段的完整生态。并且各个层级之间相互依赖并保持开放，为构建第三方工具提供了无限可能。也许未来的可视化工具也应该拥有如此完整的生态系统来满足各种可视化场景。
新形态工具
是否存在上述常见几种工具类型之外的新工具呢？
这是一个非常有趣的问题，不妨让我们建立一个坐标系，以易用性作为横坐标（ x 轴）、产出内容复杂性作为纵坐标（ y 轴），将现有的可视化工具放入坐标：
左上方是绘图系统，左下方是可视化语法与可视化分析语法，右下方是大部分的图表与 BI 工具，而在坐标系的右上方是一片空白。这里代表着操作简便却能产出复杂的、高自定义程度的可视化内容。目前来看，最符合这个定义的是 Bret Victor 的概念工具 Dynamic Drawing，或许这只是答案之一，你的答案是什么呢？
（正文完）
扩展链接
后记
距上次更新又过去一年了，专栏保持了良好的年更传统（竟然还有脸回来）。其实关于可视化有很多内容可以做，比如每周精选一些可视化案例、介绍一些可视化工具等等，但这样可能会让内容变得水分更重，我更倾向于一些总结概况性的话题（强行找理由）。下篇的话题是关于如何区分图表、信息图、可视化等这些概念，这次绝对不会年更（但愿吧）。
若有收获，就点个赞吧
0 人点赞
