『InfoQ』是如何实现每秒 200 万次的数据处理？，Netflix 作者丨BenSykes译者丨平川策划丨田晓旭

文章图片
作者丨BenSykes
译者丨平川
策划丨田晓旭
Netflix是如何实现每秒200万次的数据处理，并查询超过1.5万亿行的数据？
在推动技术创新升级的同时，还要确保Netflix始终如一的良好体验，这并非易事。
如何才能确保更新不会影响到用户呢？如果确保我们的改进是可度量的呢？Netflix使用来自回放设备的实时日志作为事件源来获得度量，以便理解和量化用户设备浏览和回放的流畅度。

文章图片
一旦有了这些度量，我们就把它们输入数据库。每一项指标都附有与所使用设备类型相关的匿名细节，例如，该设备是智能电视、iPad还是Android手机。这样，我们就可以对设备进行分类，并从不同的方面来查看数据。同样，我们还能够只隔离影响特定群体的问题，如应用的版本、特定类型的设备或特定国家。
这些聚合数据可以立即用于查询，可以通过仪表板查询，也可以通过即席查询。这些指标还会持续检查报警信号，比如新版本是否会影响某些用户或设备的回放或浏览。这些检查用于通知负责的团队，让他们可以尽快处理问题。
在软件更新期间，我们为一部分用户启用新版本，并使用这些实时指标来比较新版本与旧版本的性能。在度量中，如果有任何不合适，我们可以中止更新并将那些已获得新版本的用户恢复到以前的版本。
由于这些数据的处理速度超过每秒200万次，所以将其存入一个可以快速查询的数据库非常困难。我们需要足够的数据维数，以便能够有效地隔离问题，如此一来，我们每天生成超过1150亿行数据。在Netflix ，我们利用ApacheDruid帮助我们在这种规模下解决这一挑战。
Druid
ApacheDruid是一个高性能的实时分析数据库。它是针对特别注重快速查询和摄取的工作流而设计。 Druid特别适合于即时的数据可视化、即席查询、操作分析和高并发处理。 ——druid.io
因此， Druid非常适合我们的用例，事件数据摄取率很高，而且具有高基数（highcardinality）和快速查询需求。
Druid不是一个关系型数据库，但是一些概念是可以转化的。我们有数据源，而不是表。与关系型数据库一样，有表示为列的数据逻辑分组。与关系型数据库不同的是，没有连接的概念。因此，我们需要确保在每个数据源中都包含希望的筛选或分组的列。
数据源中主要有三种列——时间、维度和度量。
Druid中的一切都有时间标记。每个数据源都有一个时间戳列，这是主要的分区机制。维度是可用于筛选、查询或分组的值。度量是可以聚合的值，并且几乎总是数值。
通过移除执行连接的能力，并假设数据都有时间戳， Druid可以在存储、分发和查询数据方面做一些优化，这样我们就可以将数据源扩展到数万亿行，并且仍然可以实现查询响应时间在10毫秒以内。
为了达到这种程度的可扩展性， Druid把存储的数据分成时间块。时间块的长度是可配置的。可以根据数据和用例选择适当的区间。对于数据和用例，我们使用1小时的时间块。时间块中的数据存储在一个或多个段中。每个段包含所有属于这个时间块的数据行，时间块由它的时间戳列决定。段的大小可以配置为行数上限或段文件的总大小。

文章图片
在查询数据时， Druid将查询发送到集群中所有那些拥有的段所属的时间块在查询范围内的节点。在将中间结果发送回查询代理节点之前，每个节点都并行地针对其持有的数据处理查询。在将结果集发送回客户端之前，代理将执行最后的合并和聚合。