网飞公司是如何使用Druid进行实时观测以确保高质量体验的？
最后更新：2020-04-13 12:57:22 手机定位技术交流文章
全文有4381个单词，预计需要13分钟来学习。
资料来源:Pexels
随着时代的发展，软件的版本也在与时俱进，不断更新，以更好地满足用户的需求。
但是我们如何保证这个版本的更新一定会让用户满意呢？我们的努力真的能有所作为吗？
对网飞来说，在确保良好用户体验的同时进行持续的技术创新并不容易。
通过使用回放设备中的实时日志作为事件源，我们获得了理解和量化用户设备如何无缝处理浏览和回放的指标。
记录到度量数据管道
一旦我们得到这些指标，我们将把它们输入数据库。每个指示器都将显示所用设备的隐藏细节，例如该设备是智能电视、iPad还是安卓手机。这使我们能够根据不同的方面对设备进行分类并查看数据。这反过来使我们能够消除可能只影响特定群体的问题，例如应用程序的版本、特定类型的设备或特定国家。
可以通过控制面板或特殊查询立即查询这些聚合数据。这些指示器还会持续检查报警信号，例如新版本是否会影响某些用户或设备的回放或浏览。所有这些检查都是为了提醒负责团队尽快解决问题。
在软件更新过程中，我们会向一些用户提供一个新版本，并使用这些实时指标来比较新版本和以前版本的性能。度量中的任何回归/降级都会向我们发送一个信号，让我们停止更新，并将那些获得新版本的用户恢复到以前的版本。
因为这些数据的处理速度可能超过每秒200万次，所以很难将它们放入可以快速查询的数据库中。我们需要足够的维度来有效地隔离问题，以便每天能够生成超过1150亿行的数据。在网飞，我们使用阿帕奇德鲁伊来帮助我们解决这个挑战。
德鲁伊
“Apache Druid是一个高性能实时分析数据库，它是为快速查询和快速获取数据的工作流而设计的。Druid擅长实时数据可视化、临时查询、运行分析和高性能并发处理。—druid.io
如上所述，德鲁伊非常适合我们的用例。因为它可以快速查询和摄取具有高基数的对象数据。虽然德鲁伊不是一个关系数据库，但有些概念是可以转移的。我们有数据源，不是表。像关系数据库一样，这些表是数据的逻辑组合，以列的形式呈现。然而，与关系数据库不同，它不支持连接操作。因此，请确保我们要筛选或分组的列包含在每个数据源中。
在数据源中，列属性可以分为3类:时间戳列、维度列和指标列。
德鲁伊教的一切都是由时间决定的。每个数据源都有一个时间戳列作为主要的分区机制。维度列用于过滤、查询或分组。指标列用于聚合数据，通常是数字。
Druid可以通过删除执行连接操作的能力，并假设数据是由时间戳列键入的，来优化其存储、分发和查询数据的方式，从而将数据源扩展到数万亿行，并且仍然在10毫秒内响应查询。
为了实现这种可伸缩性，Druid将存储的数据划分为时间块，并可以根据数据和用例为时间块配置适当的持续时间。目前，我们的数据和用例使用一个小时的时间段。时间块内的数据存储在一个或多个段中。每个段保存的数据行都在由时间戳列的键列确定的时间段内。Druid可以配置段的大小，以便对行或段文件的总大小有一个上限。
细分示例
查询数据时，Druid将查询发送到集群中的所有节点，这些节点为查询范围内的时间块保存段。每个节点在其保存的数据上并行处理查询，然后将中间结果发送回查询代理节点。最终结果由代理节点合并并返回给调用者。
德鲁伊集群概述
接收
数据库插入是实时的。事件(我们示例中的指示器列)是从卡夫卡流中读取的，而不是单独插入到数据源中。每个数据源使用一个主题。在Druid中，我们使用Kafka索引任务来创建分布在实时节点(中间管理器)中的多个索引工作器。
每个索引器订阅主题，并从工作流中读取其事件共享。索引器根据接收规范从事件消息中提取值，并将创建的行累积到内存中。一旦创建了行，就可以对其进行查询。如果查询到达仍然由索引器填充的时间块，索引器本身将提供服务。由于索引任务基本上需要执行两个任务，即接收和调度查询，因此及时向历史节点发送数据并以更优化的方式将查询工作转移给它们是非常重要的。
德鲁伊可以在接收数据时进行汇总，以最小化要存储的原始数据。汇总是聚合或预聚合的一种形式。在某些情况下，对数据执行汇总可以显著减少需要存储的数据量，甚至可以按数量级减少行数。然而，这种存储减少是有代价的:我们失去了查询单个事件的能力，只能以预定义的查询粒度进行查询。对于我们的用例，我们选择了1分钟的查询粒度。
在接收期间，如果具有相同维度的行出现，并且它们的时间戳在同一分钟内(我们的查询粒度)，那么这些行将被累计。这意味着一行是由所有的度量加上一个计数器组成的，这样我们就知道有多少事件影响了该行的值。这种汇总形式可以显著减少数据库中的行数，从而减少需要操作和聚合的行数，从而加快查询速度。
一旦累积的行数达到某个阈值或段已打开太长时间，这些行将被写入段文件并卸载到深度存储。然后，索引器通知协调器该段已准备好，以便协调器通知一个或多个历史节点执行加载。一旦该段成功加载到历史节点中，它将从索引器中卸载，并且对数据的任何查询都将由历史节点提供服务。
数据管理
正如你所想的，随着维度基数的增加，同一分钟内发生同一事件的概率会降低。汇总后的管理基础是实现良好查询性能的有力手段。
为了获得所需的输入，我们已经运行了许多索引器实例。即使在索引任务中的相同行通过上滚合并之后，在索引任务的相同实例中获得这些相同行的可能性也非常低。为了解决这个问题并优化汇总操作，我们安排了一个任务，在给定时间段内的所有段都移交给历史节点后运行。
压缩任务从深度存储中获取时间块中的所有段，并通过映射/缩减作业重新创建这些段，实现完美的累积。然后，新的段将由历史节点加载和发布，以替换和替换在前一次汇总中不足的段。在我们的示例中，通过使用额外的压缩任务，行数增加了2倍。
要找出给定时间段内的所有事件何时被接收到并不容易。因为Kafka上可能有延迟的数据，或者索引器可能需要花费时间将段传递给历史节点。为了解决这个问题，我们将在运行压缩之前进行限制和检查。
首先，太迟到达的数据将被丢弃。我们认为这种方法太过时了，在实时系统中没有用。这将限定延迟数据的范围。其次，压缩任务的调度也有延迟，这使得正常流中的段有足够的时间被卸载到历史节点。最后，当给定时间段的压缩任务开始时，它会查询该段的元数据，以检查是否有任何相关的段仍在被写入或传递。如果是这样，它将等待几分钟，然后再次尝试确保压缩作业已经处理了所有数据。
如果不采取这些措施，我们会发现数据有时会丢失。压缩开始时仍在写入的数据段将被新压缩的数据段覆盖，这些数据段具有更高的版本，因此具有优先级。这实际上删除了那些尚未交付的部件中包含的数据。
询问
德鲁伊支持两种查询语言:德鲁伊SQL查询和本地查询。在底部，德鲁伊SQL查询被转换为本地查询。本地查询作为JSON提交给REST端点，这是我们的主要使用机制。
对集群的大多数查询都是由定制的内部工具(如仪表板和报警系统)生成的。这些系统最初是为我们的内部开发和开源时间序列数据库阿特拉斯系统而设计的。因此，这些工具使用阿特拉斯堆栈查询语言。
为了加快德鲁伊查询的采用并允许重用现有的工具，我们增加了一个翻译层，接受阿特拉斯查询，将它们重写为德鲁伊查询，发出查询，并将结果重新格式化为阿特拉斯结果。这个抽象层不改变现有工具的使用，并且允许用户在不创建额外学习曲线的情况下访问德鲁伊数据存储中的数据。
调整比例
在调整集群节点配置时，我们以高速运行一系列可重复且可预测的查询，以获得每个给定配置的响应时间和查询吞吐量基准。这些查询旨在隔离集群的各个部分，以检查查询性能的改善或退化。
例如，我们对最新数据执行目标查询，只查询中间管理器。同样，对于持续时间较长的数据，我们只查询较旧的数据，以确保只查询历史节点来测试缓存配置。并使用高基数维度再次查询该组，以检查合并的影响。我们继续调整和运行这些基准测试，直到我们对查询性能感到满意。
在这些测试中，我们发现调整缓冲区大小、线程数量、查询队列长度和分配给查询缓存的内存对查询性能有显著影响。然而，压缩作业的引入对查询性能有更显著的影响。它完美地重新卷起并重新压缩未完全卷起的片段。
我们还发现在历史节点上启用缓存非常有用，而在代理节点上启用缓存没有任何效果，因此我们不在代理节点上使用缓存。这可能也是我们用例的一个问题，但是我们做的几乎每个查询都没有在代理上缓存，这可能是因为查询通常包含最新的数据，这些数据不会像往常一样出现在任何缓存中。
摘要
资料来源:Pexels
在对用例和数据速率进行了许多调整之后，德鲁伊证明了它和我们最初预期的一样多才多艺。
我们已经有了一个可靠且易于使用的系统，但是还有更多的工作要做。随着接收量和速度的不断增加，查询的数量也在增加，复杂性也在增加。因为这些详细数据的价值需要更多的团队来实现，所以我们经常添加更多的度量和维度来推动系统更加努力地工作。我们必须继续监控和调整，以保持正常的查询性能。
目前，我们每秒接收超过200万个事件，查询超过1.5万亿行，以获得关于用户体验服务的详细信息。所有这些都有助于我们实现持续创新，同时保持网飞的高品质体验。
以上是网飞的一个经验，我相信它能给其他公司一些启示。
评论、表扬和关注
让我们分享人工智能学习和发展的干货。
如果重印，请在后台留言并遵守重印规则。
本文由 在线网速测试 整理编辑，转载请注明出处。
