两种类型
数据可视化分成两种类型：
- 可视化库，如： D3、Echarts、G2 等库，面向开发者，开发者可以基于这些库开发数据可视化项目；
- 可视化平台，如：腾讯小马 BI 的 datatalk、阿里的 Quick BI，这些面向分析师和一般使用者，直接拿来分析数据，无需开发
如何选择可视化平台
为什么要做一个差不多的平台？
当时我们团队要做数据可视化项目时，有对市面上一个已经完成数据可视化项目产品的开发进行了考察，其中了解到腾讯的小马BI产品（即将停服）、阿里 Quick BI 两个产品的数据源安全性问题，以及部分功能上的需求小马BI没有，所以我们才决定自己做一个数据可视化看板项目
当然，我们遇到产品上的问题可以参考这两个产品的方案。有句话叫做取长补短
- 对于未开源的我们可以参考产品的产品设计和交互体验
- 对于开源的我们可以参考代码的设计模式及规范
开源项目：github.com/dongsuo/vue… ；体验网址：v11nlab.com/
另外，开源的项目我们还可以参考其方案选型，比如以上项目选择 Echarts 做图表，选择 vue-grid-layout 做拖拽
- 关于拖拽方案的选型调研如下：
| 拖拽方案 | vue原生拖拽 | vue-grid-layout |
|---|---|---|
| 布局 | 布局灵活性高 | 吸贴式布局 |
| 开发成本 | 成本高，很多东西需要从无到有开发 | 成本低，基本功能已具备 |
| 优点 | 布局可自定义 | 本身设计就解决了冲突 |
| 缺点 | 处理叠层冲突难度高、用户体验差 | 组件无法自定义位置 |
| 选择 | √ |
- 关于侧边栏功能设置的方案选型调研如下：
| 方案 | 同级 | 父子组件传参 |
|---|---|---|
| 优点 | 实时更新 | 关闭再起效，多个DOM操作合并 |
| 缺点 | 多个操作会造成卡顿 | 无法实时更新 |
| 选择 | √（按照产品的要求） |
- 关于图表制作方案的选型见下方
如何选择可视化库
通用参考要素（万金油）：
- Github 星星数多吗
综合比分高
- 代码行数的数量级
如果 Star 数量差不多，运行 cloc 工具 查看代码行数，数量级差一个级别，功能上的差距就体现出来了，代码量太少的功能有限
不过得看各自的项目需求：想要轻量级的、功能要求不高的也可以选择代码量少的；不过大多数情况下做项目还是希望功能多比较好
- 提交频率是否处于上升趋势
从 GitHub 的 contributors 页面可以看出这个项目是否活跃，比如下面这种长期提交的，说明发展稳定：
优秀项目
而下面这种提交不稳定，越来越少的，就是弃坑了：
弃坑项目
几个不错的数据可视化库
从哪些角度去进行分析？
| 可视化库 | D3 | Echarts | G2 | Chart.js |
|---|---|---|---|---|
| Github Star 数 | 98.1k | 47.8k | 10.9k | 54.7k |
| constructors 趋势 | 下降 | 稳定 | 稳定 | 稳定 |
| 丰富度 | 种类较少 | 种类最多 | 种类较多 | 种类较少 |
| 配置项 | 配置项较多但灵活 | 配置项较多但不灵活 | 配置项最少 | |
| 上手成本 | 较低 | 较低 | 较高 | 较低 |
| 我们团队选择 | √ |
以下内容转载自 zhuanlan.zhihu.com/p/149398216
D3 - 可视化界的 jQuery
前端可视化最著名的项目是 D3，它不仅能做出各种可视化效果，还是许多其它图表库的基础，前面说到搜 chart 的结果有 7.6w，而如果改成搜 D3 结果就有 5.6w，可见影响力极广。
D3 最早出现在 Mike Bostock 读博期间发表的一篇论文里，它的目的并不是做图表库，而是成为更底层的基础设施，简化数据可视化的开发，它在 API 设计方面参考了 jQuery，使用比如这样的写法 d3.selectAll("p").attr("class", "graf")，把 d3.selectAll 改成 $ 就和 jQuery 一样了。
除了类似 jQuery 的链式调用，D3 还有鲜明的特点是将功能拆得非常细，做到了函数级别，从数据解析、转换到布局算法都有提供，这使得开发者可以十分灵活地进行组合，实现各种可视化的展现，这使得 D3 非常适合拿来学习的可视化算法，而且还能很方便地将这些算法整合到自己的项目中。
D3 的链式调用可以让代码变得很少，取代 for 循环，比如下面这样的代码：
d3.select("body")
.selectAll("p")
.data([4, 8, 15, 16, 23, 42])
.enter()
.append("p")
.text(function (d) {
return "I’m number " + d + "!";
});
如果用普通的写法需要用 for 循环遍历数据，然后根据顺序对找到的 p 标签进行操作，而 D3 只需要一行就能搞定，然而既是它的优点也是缺点，对于没学过 D3 的人会完全看不懂，即便学过每次看都要花不少精力读懂，我的个人经历是基于 D3 风格写的代码过两周后自己就快看不懂了，还不如当初写个 for 循环。
如果只是想绘制常见图表，倒是没必要直接用 D3，可以看看那些基于 D3 的图表库，比如下面这些：
- nvd3 早在 2012 年就出现了，但最近更新时间是 2018 年 6 月，尽管之前坚持了 6 年，但还是放弃了，具体原因不清楚，几个核心开发者在 GitHub 上都不活跃了，不过它的故事没结束，下一篇里会有介绍。
- c3 最早追溯到 2013 年，因为几乎是同时出现的，之前经常拿来和 nvd3 对比，现在看和很多年前没太大差别，从更新日志看这两年基本都在修 bug。
- vx/Recharts/react-vis/nivo/Victory，这些都是专门给 React 项目使用的图表库，我个人不看好这个思路，一方面是 jsx 写起来比 json 还繁琐，另一方面这种写法的实际收益并不大，还会导致难以使用 canvas 渲染。
- dc.js 主要是用来做多维分析，特色是支持在前端快速进行不同维度过滤，但这种方案的使用场景有限。
- billboard.js 是 Naver 开源的，其实是 C3.js 的一个 fork 版本，因为他们公司内部用了 C3.js，实际用的时候发现不少问题，比如不支持 D3 v4，他们提交了 PR 也没人理，就干脆另起炉灶了。
- Britecharts 提供了类似 D3 的链式调用接口，发版虽然频繁，但每个版本的改进很少，而且目前配置项也很少。
- ploty.js 在 2012 年就有了，一直都有更新，从功能和项目活跃度看是最好的，代码规模有 9w 多行，远超前面几个，它背后是一家公司，这家公司除了 ploty.js 还有给分析师用的 Dash 应用产品，我们将在下一篇里介绍。
论功能丰富度 ploty.js > nivo > vx，其它都没必要看了，D3 虽然很火，但在专业图表领域能拿得出手的其实只有 ploty.js，而 ploty.js 也并不是只用 D3，它还依赖了 gl-plot2d、regl 等基于 WebGL 的库，因为 D3 的接口基于 DOM，用来操作 SVG 没问题，但无法用来操作 Canvas 和 WebGL，这使得 D3 无法用于大数据量及需要像素级别操作的特效。
总体来说 D3 是一款成功的可视化基础设施，它的源码值得学习，但不推荐直接使用它例子开发图表，一方面基于它写的代码上手门槛高，另一方面是它的定位并非图表库，要用的话最好是其它基于 D3 开发的图表库，比如 Ploty.js。
ECharts - 穷人的 Highcharts
十几年前浏览器能用的图表库我就只知道 Highcharts 和 Adobe Flex，Highcharts 虽然是收费产品，但它提供了下载，所以付费完全靠自觉，当时国内大家都没有给软件付费的习惯，不少公司在内部偷摸着用。
百度最早内部图表组件使用的是 Flash 技术（很可能是 Flex，不记得了），后来随着 HTML5 的崛起，来自 Safari 的 Canvas 逐渐得到了广泛支持，加上 Apple 在 iOS 中明确不支持 Flash，使得 Flash 的技术前景开始黯淡。
于是百度商业前端团队就尝试基于 Canvas 来开发图表库 ECharts（同一时期用 Canvas 技术的还有个商业公司 CanvasJS），比起 SVG/VML，Canvas 虽然调试麻烦，但在大量数据点下性能更好，早期开发者 kener 和 pissang 非常给力，没多久就补齐了大量常用图表，加上中文文档的优势，ECharts 很快在国内流行起来，它至今依然是国内最火的图表库。
2017 年陆奇加入百度后大力推广开源，ECharts 也在 2018 年进入 Apache 孵化器，开始在国外受到关注，比如 Gitlab 还专门写了篇文章说为什么他们从 D3 换成了 ECharts。
ECharts 的配置项相当多，预计超过 600 个，我们的 Sugar 平台中大部分图表是基于 Echarts 实现的，至今还有不少高级配置项还没补齐。如果想配制出漂亮的图表，建议多逛逛 Gallery，可以淘到很多漂亮的效果，只看官方文档是想不到的，比如下面这：
疫情期间用户分享的例子
Echarts 和 Highcharts 的 API 非常像，很多公司其实是当成了免费的 Highcharts 来用，但 Echarts 其实有不少自己独特的功能，其中最具亮点的就是 Echarts-gl，它能实现三维图表和地球的展示，这点其他开源库基本没有，而其它商业图表都是基于 SVG 的，只能弄仿三维效果，只有 Echarts-gl 是基于 WebGL 做的真三维，可以配置光照、材质、阴影等，还有独家的后期特效功能。
Echarts-gl 主要归功于 pissang，最开始听说 pissang 的时候就知道他写了个自己的 WebGL 框架 claygl（之前叫 qtek），作为 WebGL 小白的我没想通为啥有 Threejs 还要自己山寨一个，后来才知道这个框架不简单。
学过三维图形学会知道有两种常见的渲染架构，一个是前向渲染，另一个是延迟渲染，一般来说前向渲染实现起来更简单，但它无法支持大量光源，而延迟渲染实现成本更高，但支持大量光源且适合做后期特效，所以包括 Unity、Unreal Engine 4 在内的主流游戏引擎都主要使用延迟渲染，只有在低端设备下才切换为前向渲染。
然而你翻遍 GitHub 就会发现，在 WebGL 领域 claygl 是唯一支持延迟渲染的，包括 Three.js（尝试过但放弃了）、Babylon.js、Playcanvas 以及各种你没听说过的 WebGL 引擎都不支持，所以它们都会限制光源数量，比如最多 4 个。
除了延迟渲染这个独特的亮点，claygl 还内置了 Bloom、SSAO、SSR 等特效，支持动画、GLTF 等，是少数几个功能完整的 WebGL 框架。
正是因为在三维图形方面的深入了解，Echarts-gl 能做出的效果远超其他图表库，然而这个巨大的门槛是优点也是缺点，Echarts-gl 的最大问题是了解 WebGL 的前端工程师太少，加上使用自研的渲染引擎导致门槛更高了，这个项目长期都只有 pissang 一个人在提交，我最近给地球加个小特效竟然就成了贡献榜第二。
作为一个公司内的开源产品，Echarts 从功能和文档方面都达到了商业产品的水平，还有主题编辑器和大量社区贡献的案例，而且 Echarts 团队在过去 7 年一直都有提交，非常不容易，目前正在规划新的 5.0 版本，将会在动画、数据处理和性能等方面有明显改善，值得期待。
G2/F2 - 《The Grammar Of Graphics》的追随者
G2 是支付宝前端团队开发的，虽然当时 Echarts 已经很成熟了，但支付宝还是选择了自己做了一个，也就是 G2 的前身 acharts，它的 API 和 Echarts 基本类似，后来作者看了《The Grammar Of Graphics》那本书，就调整了方向，开始基于这本书的思路开发 G2，这个 G2 的命名就是这本书名里的两个 G。
受这本书影响的可视化库有很多，前面说的 Vega-Lite 在作者的论文里就提到过借鉴了不少了，和 G2 一样参考那本书的还有 chart-parts，不过别看它是微软的项目，其实也只有一个人在开发，提交次数非常不稳定，作者同时还在忙另一个更知名的项目 react-dnd，所以大概率以后会弃坑。
《The Grammar Of Graphics》里作者主要是借鉴了面向对象的思想，将图表拆分成了很多组成部分，比如数据源、数据转换、坐标系、图形等，通过将它们组装起来实现各种展现效果，从技术角度倒是不新奇，但这本书通过数学的方式来进行组合和分析，看起来非常高级。
G2 中那个看起来奇怪的 chart.interval().position('genre*sold'); 写法就是来自那本书，这里的 * 不是乘法，而是作者自己定义的一种操作符，表示合并，不过因为 JavaScript 不支持操作符重载，导致这里只能用字符串，丢失了类型信息，很容易拼错了都不知道。
比起 Echarts 之类的图表库，G2 的定位更接近 Vega，也就是比直接拿来用的图表库低一层，对于想把它当成 Echarts 来用的人来说会觉得上手成本更高，所以 G2 后来又提供了更简化的 G2Plot 专注于普通图表的绘制。
这个项目我没实际用过，看文档和例子做得很用心，也是达到了商业项目的水平，可以满足大部分需求，但从提交历史看有些不稳定，F2 在 2019 年停滞了好几个月，G2 的提交量也明显减少，最近半年才恢复，可能是在内部进行重构。
值得一提的是 AntV 团队还弄了很多方向，比如关系图 G6/X6、地图 L7、自动选图 AVA 等，但这些项目大多只有一个人，团队精力可能有点分散了。
Chart.js - 顶级推广案例
我之前对 Chart.js 这个库了解比较少，几年前第一次发现的时候它的 Star 数就很高了，它现在的 Star 数量高达 49.3k，在 npm 上的周下载量达到百万，和 D3 是一个量级的，恐怕是最火的前端图表库了。
既然怎么火，它在技术上情况怎样呢？这个项目的最早提交时间是 2013 年，7 年来提交没怎么中断，然而整个项目代码量只有 1w 多行，它的图表种类少，可配置项也不多，整体来说比 Echarts/Highcharts 都差很远，看了半天实在没搞懂为什么那么火，或许反应出大部分人对图表要求不高，能显示几种场景图表，有点交互和动画就够了。
在我看来它唯一值得关注的就是宣传和推广能力，是如何做到那么火的？难道只是名字起得好？
