视频时间序列数据分析
来源：Global Video Tech Meetup：Paris 主讲人：Daniel Holbling-lnzko 内容整理：彭峰 本文来自 VideoTech 公司的工程师在 Global Video Tech Meetup 上的演讲，主要介绍了视频分析中时间序列数据的概念，就数据来源、数据基数以及数据基数所带来的问题进行了讨论，得出了传统的数据库并不能很好应对视频分析中的时间序列数据场景，最后介绍了对应解决方案。
目录
- 时间序列和视频分析
- 数据从何而来
- 数据基数——Cardinality kills you!
- 数据基数巨大带来的问题
- 基数问题的解决方案——Splitting
时间序列和视频分析
时间序列是在特定时间点的一系列测量。例如温度、股票价格、汽车速度、流速、CPU 使用率等，通常在某个时间点观察，然后也在某个时间点存储。例如测量每天早上 8 点的温度，并把将其放在一些测量日志之中，这样每个数据点会对应特定的日期。将数据与时间联系在一起，例如将日期作为横轴，将数据点绘制成为曲线会展现出其他信息，例如温度变化的趋势。
视频分析的本质是去追踪某些相关指标，在不同时间点上指标的值组合起来最终在本质上是图的形式。显然这种分析的服务对象不是个人用户而是 OTT 提供商，一些常见的指标如下：
- 观看人数
- 服务启动时间
- 视频服务的比特率
- 用户使用的设备情况
- 用户的分布情况
- 服务过程中的异常错误情况 ……
当所有这些数据汇集到一起之后，可以将其用于提升对应服务商的用户体验，指导内容提供商去改变其服务从而提高服务质量。当然这些数据的表现形式如同曲线图一样，例如在将过去三天的观看用户数以时间为横轴呈现出来可以像下图一样。在讨论其他问题之前，首先将说明数据从何而来。
图1 视频观看量数据
数据从何而来
所有的这些指标数据来源于用户群体，其主要的获得方式是通过浏览器或者是设备上运行的收集器(Collector)实现，例如在 JAVA 和 IOS 设备中都有类似的收集器，这些运行的收集器会关联到视频元素上，并监听所有的活动。这个收集器可以感知到视频的播放行为，并将视频流在播放过程中的相关指标数据返回，每隔特定的时间，收集器会返回一个信标(beacon)来传递相应的数据，例如下图所示的指标数据。这些数据数据的量是庞大的，如果使用数据库将全部数据全部保存起来，会存在一些问题。
图2 收集器返回数据示例
数据基数——Cardinality kills you!
通常而言，平均每个视频服务会话会产生约 80 个信标，这意味着每个观众的每个视频流播放的内容产生了大约 80 个击中后端的有效载荷。而这些信标中的每一个都有大约 100 个字段。那么对于一百万的播放量而言，产生的数据量是
行数据，90 天的数据量就会是 7,200,000,000 行，365 天的数据量是 29,200,000,000 行。尽管现如今储存设备的价格已经大幅下降，但是在这种情况下，如果想要保存这些指标数据是极为困难的，更不用说去使用这些数据（简单的查询就将耗费大量资源）。
当然或许会有人觉得一百万的播放量比较大，但真实场景下，实际的数据量远不止如此，以 YouTube 为例，其网站每天会有 2,000,000,000， 即 20 亿的登录用户，这些人每天看超过 1,000,000,000 小时的视频，并且平均每天观看大约 9 个视频，所以大约每天 18,000,000,000 个视频。回到上述的讨论之中，如果想要储存这么多的视频播放所产生的指标数据集几乎不可能。
大量的数据等同于大量的问题，例如存储成本高昂、查询时间长、对数据操作时需要很多资源等。例如想要计算某个指标的数值就必须对所有的数据进行扫描、读取和计算，其成本是难以想象的。如果非要使用如此多的数据，只能考虑分布式系统，例如分布式数据库对数据存储。
在上述的情况下，想要存储所有的时序数据是困难的，为了利用时序数据对服务评价，需要一些解决方法，最直接的一个方法就是，依据实际的时间去存储时序数据，例如将分钟作为数据间隔。在此情况下，存储数据的开销是可以预测的，并且对数据查询和处理的时间也是有限的，因为在一年之中仅仅只有 50 万左右分钟，极大降低了存储和处理数据的开销。
尽管上述的方法——使用真实世界的时间间隔去记录时序数据可以使得指标数据具有可用性，但是时间间隔的增大使得数据并不呈现出时序特征。如下图所示，不同浏览器上产生的视频播放量呈现出多段时间序列数据的形式。
图3 多段时间序列数据
我们的客户并不关系这些多段时间序列的数据，他们关心的是特定的问题，例如他们服务的用户在使用什么浏览器什么样的设备、来自哪个地区等，简单的三个问题总结起来，可能会导致数据量变得巨大。以统计德国的安卓设备使用服务的情况为例，常见的浏览器约有 30 种，设备种类数量则更多，在此假设安卓设备种类为 100 种，不同地区数为 195 个，则某一个时刻需要记录的数据数为
，当视频服务器中有 1000 个视频时，则需要
的数据条目数来记录，如此大的数据基数将会带来很多问题。
数据基数巨大带来的问题
图4 是 Influx DB 的硬件手册，可以看到随着序列数据量的增大，其负载情况堪忧，并且如图5 所示，随着序列数据的增大，Influx DB 所需要的 RAM （随机存取存储器）呈现指数级增长。
图4 Influx DB 负载随序列数据变化情况
图5 Influx DB 内存随序列数据变化情况
在实际系统运行中，需要根据不同的场景来决定需要使用多少的时间序列数据，并且目前的系统中有超过 40 个评价指标。为了减小数据基数，会采取一些侵略性很强的操作，例如仅统计前 15 个浏览器、仅储存前 30 个热门视频数据、仅统计 30 个国家的相关情况，仅考虑 10 种最常使用的设备，这种减少数据基数的方法称为 TopK。从而我们需要的时间序列数据数量为
，数据基数极大程度减小。
但是在实际系统不断运行的过程中，上述的 TopK 方法存在判定困难问题，如图6 所示，系统运行过程中，来自不同浏览器的服务使用情况随着时间而变化，如果想要仅仅保存前 3 个浏览器所代表的时间序列数据，那么该如何判断前 3 三个热门浏览器是哪 3 个。
图6 TopK方法存在问题说明
此外，TopK 方法也在判断视频的热门程度时也存在问题，除非在遇到一些重大活动，例如超级碗时，TopK 方法就无需考虑此类问题，因为重大活动的观看人数稳定且巨大。因而以不同的时间间隔作为 TopK 的作用域时，会产生不连续现象。
基数问题的解决方案——Splitting
为了解决时间序列数据数据基数巨大的问题，可以在 TopK 的基础上，将对时间序列数据的查询划分，分别作用域不同的时间段，以并行的方式去查询，同时访问多个数据库，这可以减少 40% 的加载时间。
图7 查询划分示意图
通过上述的讨论可以得到如下结论：
- 预先计算的时间序列大大提高了性能；
- 高粒度是一个需要重视的特征；
- 没有免费的午餐，只有不同的取舍；
- 基于时间的数据允许折衷的灵活性；
- 视频分析系统不能仅靠一个数据库模型来解决。
附上演讲视频：