数据可视化大屏产品在滴滴的技术探索

1. 

前言

随着技术的发展，更多的人不满足于使用基础的图表来展示数据，如何让数据更直观、更炫酷的展示成为了大家的追求。为了能更好的展示滴滴各业务线的发展，本文介绍的数据可视化大屏从城市、全国和全球维度展示了业务线的实时信息，下面将从基础地图的构建、轨迹、气泡、热力、飞线、散点六个方面来讲述一下开发中遇到的难题及解决方案。

• 1）地图的一次性加载，考虑到易用性和维护性，需自研一套地图框架；

• 2）大量数据涉及到的性能问题，包含数据的计算、传输和实时渲染；

• 3）数据业务方较多，接口稳定性和维护性问题；

• 4）可视化还原度；

• 1）自研地图框架map3；

• 2）将数据计算移到后端，对数据进行压缩，同时在大量数据的传输方面采用ArrayBuffer。尽量减轻GPU和CPU的压力，提高页面流畅度。

• 3）因为数据大屏对数据的依赖性较强，为了保障展示的稳定性，对数据采取了缓存兜底方案；

• 4）通过开发调试面板，降低与设计师沟通的成本，为提高可视化还原度提供了便利。

  
  

const map3 = new Map3({  container: string | HTMLElement;  style: Style;  center?: number[];  pitch?: number;  bearing?: number;  zoom?: number;  controller?: boolean;  hash?: boolean；});

其中，style是我们传入的样式数据，针对本项目中的北京地图，style文件中包含了背景、灯光、天空、结构(建筑、道路、水、绿地等数据)、精模(望京SOHO、CCTV、故宫、工人体育馆、中关村等精细模型数据)。通过在map3中对style数据一层层的解析和渲染，最终我们可以得到一次性加载完成的北京地图。

▍3.数据压缩

项目中需要用threejs来绘制整个北京城，包括道路、建筑、绿地、山脉等，数据量超过300M，且要求一次性加载完毕。平时js文件超过2M就要考虑优化，300M已经突破了浏览器的最大限制，即这么大的文件浏览器不会缓存（当然可以通过设置来更改这个最大限制，但是首次加载是必须的），所以要考虑如何压缩文件。

mapbox的geobuf可以解决这个问题。geobuf能以近乎无损的方式将geojson压缩6-8倍，即使经过gzip处理也能压缩2-2.5倍。通过源码大致了解其压缩原理，下面写出来与大家交流下，有不完善的地方望指正。

geobuf使用protocol buffers作为数据存储的格式，protocol buffers是一种轻便高效的结构化数据存储格式，可以用于结构化数据串行化，或者说序列化。它很适合做数据存储或RPC数据交换格式。它是与语言无关、平台无关、可扩展的序列化结构数据格式。关于protocol buffers的介绍这里不再赘述，大家可以参考官网或网络上的一些介绍，这里只重点指出与geobuf相关的一个特性，就是varint。varint的介绍及原理，也可以参考官网或https://www.ibm.com/developerworks/cn/linux/l-cn-gpb/index.html，这里直接说下其特点。varint的特点就是存储较小的数据所用的字节数很少，例如存储1、2、3这样的数字，就只用1个字节。varint的这个特性与后面所要讲的geobuf的压缩有很大关系，所以这里重点强调下。

geobuf把数据压缩的那么小，还是涉及很多方面的优化，下面我将对个人认为压缩得最厉害的地方做一个介绍。以下是一段geojson，描述了一段LineString，geobuf并不是直接使用浮点数来存储这些数值，而是将数值做了一个计算，除第一组经纬度外，其他经纬度取与前面经纬度的差值，再将差值乘1e5（为了方便介绍，后面这一步暂时称为整型化，具体是乘1e5还是1e6或者其他值，取决于geojson本身的精度）。

图3.3 geojson数据示例

以上面的数据为例，取差值后的值为[[120.07045, 30.20248], [0.00001, -0.00022], [-0.00001, -0.00009]...]，整型化后的值为[[12007045, 3020248], [1, -22], [-1, -9]...]。geojson描述的无论是polygon还是linestring，coordinates里面的经纬度值其实都比较接近，所以处理后的数值都会比较小，这样再使用varint来存储就会得到比较好的压缩效果。

最后说下项目中对geobuf的改进。主要包含以下两点：

• 1）因为项目中绘制的区域相对较小，例如杭州，范围在东经118°21′-120°30′，北纬29°11′-30°33′ °，这样对于每一条LineString或者polygon的首个点来说，存储全部的数值也存在一些浪费，于是我们在计算前加入了一个减法计算，将所有的经纬度减去一组数值，例如上面的例子中，减去[120, 30]，这样数值将变为[[7045, 20248], [1, -22], [-1, -9]...]，首个点的数值更小了，所需要的字节数也更少了（这一步虽然减小了一点数据量，但失去了灵活性，需要权衡利弊）。
  

• 2）地图绘制都存在投影计算，我们将投影计算放在了encode的代码中，浏览器接收到数据decode后可以直接使用，这步可以减小浏览器的计算，节省cpu和计算时间的开支。

改良后的geobuf叫做mbuf，下面是一组对比数据：（注：geobuf和mbuf还剔除了一些不需要的属性，所以geobuf相比官方提供的测试数据压缩比更大，官方提供的数据中gzip后可压缩2-2.5倍）

如何让轨迹动起来呢？其实就是每一帧都让轨迹沿着预设好的路线向前移动。设想轨迹有一个头和一个尾，每帧让头和尾都沿着路线移动固定的距离，再将头尾间的点连接起来即可。通常我们会用若干点来描绘一条路径（下面我们称这些点为路径点，即下图所示的实心点），点在路径上并不是均匀分布的，在转弯的地方会比较密集，直线的地方相对稀疏。所以在确认好头尾点的位置后，还需要将头尾点与中间的路径点串联起来，才是我们最终需要绘制的轨迹。如下图所示，红色曲线是需要绘制的部分。

图4.2 轨迹示意图1

所以如何定位首尾点的位置是重点。假设轨迹长为length，每帧向前移动x米，轨迹可见部分，即头尾长y米，第z帧的时候，head的位置就在距离起点x*z米的地方，但如果x*z>length，即head位置超过轨迹的总长度，则head的位置为length处，所以为min(x*z, length)；tail的位置需要判断有没有在可视范围内，所以值为max(0, x*z - y)。

那么现在问题又归结到如何在路径上找到距离起始点特定长度的点的坐标。大家可能会想到使用turf的distance方法， 使用起来很方便，输入两个点的坐标就可以得到两点间的距离，所以一开始我们也是想到使用turf，这也是埋的一个坑。turf的性能很差，原因就是每次计算两点之间距离的时候都会重新计算已经计算过的点，造成了性能上的浪费，画不了几条长轨迹就会卡，所以另寻他法。后来我们采用动态规划的思路，方法如下：

• 时间范围

  可以展示过去一分钟、十分钟、一小时等任意时间间隔内的热力情况。

• 半径大小

  可以以任意距离为单位，该范围内的订单数对应的色阶上的颜色即为该范围的热力图颜色。

• 色阶

  热力图的颜色是可调的。

7. 

飞线

1）取点

曲线是由一系列的点连接组成，若想得到平滑的曲线，首先需要得到能生成我们想要的曲线的点。这里我们每条曲线是由100个点连接而成，那么如何得到这100个点呢？如果只是想在地球上两点之间生成一条曲线这本身不是难事，但是为了美观性，我们想要达到每条曲线的最高点距离地球的距离都是相同的，这样在地球转动或者各种视角下，视觉体验上才会比较好。为了实现这点，我们做了以下计算，代表的是飞线起点向量和终点向量之间的夹角：

① 

② 

当角度大于30度时，我们发现得到的曲线两端变化较大，中间很长一部分几乎都是平缓的，整条曲线的弯曲变化不是特别顺滑。所以为了解决这种情况，我们对 的曲线采用了不同于三维三次贝塞尔曲线的方法，使用的是CatmullRomCurve3，即使用Catmull-Rom算法， 从一系列的点创建一条平滑的三维样条曲线，不仅限于两个控制点。我们采取的方案是根据起点和终点的经纬度差值、地球的半径和曲线最高点对应的半径进行插值计算，得到20个插值点的坐标，将这20个点传入CatmullRomCurve3中生成曲线，并利用其提供的getPoints方法得到曲线上的100个点用于绘制。

2）纹理映射

上一步我们获取的100个点是描绘一条完整曲线的全部点，但是从图7.1(b)中可以看出，飞线在飞的过程中展示的是完整的纹理，但是飞线长度只占总长度的1/3。如果按照正常的映射的话应该是完整的纹理对应完整的曲线，所以在飞的过程中应该只展示对应的纹理部分。那么如何实现动图中的效果呢？

第一反应就是改变顶点坐标，例如第一次render第0～30个点的范围，第二次render第10～40个点的范围，以此类推。效果确实是实现了，但是性能上有问题，由于频繁的更换顶点导致了页面的卡顿。

想到的第二种方案就是100个点全部绘制，在render的过程中z不断变换顶点对应的uv坐标。例如开始是第0～30个对应的uv坐标从0～1，下一次是第10～40个点对应的uv坐标从0～1，以此类推可以满足1/3长度的飞线展示完整的纹理，且不断移动。在这里还有个优化，一开始是在每次render的时候去遍历uv数组更改每个点对应的值，但是遍历数组也是耗性能的，特别是当数据量大的时候，后来是将一个常数传进了shader中用于计算每个点此时的uv坐标，每次render都会改变这个数，同时同步到shader中。

8. 

散点

平时我们用静态的散点比较多，这种实现很简单。但当展示的信息量不是很丰满时就显得页面有些空洞，这时候就需要添加动态呼吸的散点，让页面看起来更热闹。我们在散点大小变化的过程中对应的改变其透明度，产生渐隐渐现的呼吸效果，同时我们可以随机点出现的位置，让效果看起来更灵动。

9. 

结语

以上就是在全业务之城开发过程中的一些总结和思考，日后在不断开发数据可视化大屏的同时，我们也会加速沉淀通用组件库和搭建平台。