推特十亿级事务处理架构转型记

在数据爆炸时代各个企业都拥有巨量的，多数据源的数据信息，如何快速处理这些数据，实时提供服务是大家共同面临的挑战。作为世界最大的微博客服务商推特更是如此，推特数据系统每天要处理千亿个事件，生成PB级数据。其消费数据的事件源分布在各种不同的系统中。那么推特是数据架构要如何转型才能适应这些挑战呢，其过程值得我们大家学习参考。

概述

在推特，每天要实时处理大4000亿个事件，生成PB级数据。其消费数据的事件源分布在各种不同的平台和存储系统，有Hadoop、Vertica、Manhattan分布式数据库、Kafka、Twitter Eventbus、GCS、BigQuery和PubSub等。为了在这些不同的数据源和平台中处理这些类型的数据，推特数据平台团队构建了内部工具，例如用于批处理的Scalding、用于流式处理的Heron、用于批处理和实时处理的名为TimeSeries AggregatoR (TSAR) 的集成框架，以及用于数据发现和消费的数据访问层。然而，随着数据的快速增长，大规模仍然挑战着工程师用来运行管道的数据基础设施。例如，有一个交互和参与管道，可以批量和实时处理大规模数据。随着数据规模快速增长，面临着减少流延迟并提供更高的数据处理准确性以及实时数据服务的高要求。

对于交互和参与管道，各种实时流以及服务器和客户端日志中收集和处理数据，以提取具有各种聚合级别、时间粒度和其他指标维度的推文和用户交互数据。聚合的交互数据尤其重要，并且是推特的广告收入服务和数据产品服务检索印象和参与度指标信息的真实来源。 此外，还要保证跨数据中心对存储系统中交互数据的快速查询，低延迟、高准确率。

老架构

推特旧架构包括一个包含批处理和实时处理管道的lambda架构，在 Summingbird平台内构建并与TSAR集成。批处理组件源是存储在Hadoop分布式文件系统 (HDFS) 上的Hadoop日志，例如客户端事件、时间线事件和Tweet事件。有多个Scalding管道来预处理原始日志并将它们作为离线源提取到 Summingbird Platform中。实时组件源是Kafka主题。实时数据存储在推特Nighthawk分布式缓存中，批量数据存储在曼哈顿分布式存储系统中。有一个查询服务来访问来自两个商店的实时数据，供客户服务使用。

挑战

由于实时处理的数据规模大、吞吐量大，因此实时管道可能会丢失数据和不准确。 对于Heron拓扑，在需要处理的事件较多且Heron bolt无法及时处理的情况下，拓扑内部存在背压。此外，由于垃圾收集成本高，Heron bolts 会逐渐变慢。

当系统长时间处于背压下时，Heron bolt会累积spout延迟，这时系统延迟很高。通常发生这种情况时，拓扑滞后需要很长时间才能下降。更常见的是有许多 Heron Stream Manager死亡（Stream Manager 管理拓扑组件之间的元组路由），并且延迟不断增加。

针对这种情况，解决方案是要重新启动Heron容器使得流管理器恢复正常处理。但是这样可能会导致操作期间的事件丢失，从而导致Nighthawk存储中的聚合计数不准确。

对于批处理组件，有多个处 PB级数据并每小时运行一次以将数据汇入Manhattan的繁重计算管道。 集中式 TSAR 查询服务整合Manhattan和Nighthawk数据，为客户服务提供数据服务。 由于潜在的实时数据丢失，TSAR 服务可能向客户提供较少的聚合指标。

为了克服这个数据丢失问题，减少系统延迟并优化架构，通过在kappa架构中构建管道，以流模式处理事件。解决方案中，移除了批处理组件并依靠实时组件来提供低延迟和高精度的数据，这简化了架构并消除了批处理管道中的计算成本。

基于Kafka和数据流的新架构

新架构建立在推特数据中心服务和谷歌云GCP之上。在推特内部构建了预处理和中继事件处理，将Kafka主题事件转换为具有至少一次语义的发布订阅主题事件。 在谷歌云，使用流式Dataflow作业来应用重复数据删除，然后执行实时聚合并将数据汇入BigTable。

首先，通过构建了几个事件迁移器作为预处理管道，它们执行转换和重新映射字段，然后将事件发送到Kafka主题。然后使用基Kafka的内部定制流框架为至少一次语义创建了这些流管道。

其次构建事件处理器来以至少一次语义流式传输事件。事件处理器处理到Pubsub事件表示的转换，并生成由UUID和其他与处理上下文相关的元信息组成的事件上下文。UUID用于下游的Dataflow工作器进行重复数据删除。在内部 Pubsub Publisher应用几乎无限重试设置，以实现至少一次将消息从推特数据中心发送到谷歌云。创建新的Pubsub表示事件后，事件处理器将事件发送到谷歌Pubsub主题。

在谷歌云上，使用基于Google Dataflow构建的推特内部框架进行实时聚合。 Dataflow work实时处理重复数据删除和聚合。重复数据删除过程的准确性取决于定时窗口。通过同时将数据写入BigQuery并连续查询重复的百分比，证明了高重复数据删除的准确性。

最后，将带有查询键的聚合计数写入 Bigtable。对于服务层，使用推特内部LDC查询服务，前端在推特数据中心和不同的后端，例如Bigtable和BigQuery。 整个系统每秒可以流式传输数百万个事件，延迟低至约10秒，并且可以在本地和云流式传输系统中以高流量进行扩展。用Cloud Pubsub作为消息缓冲区，同时保证本地流媒体系统不会丢失数据。然后是重复数据删除以实现近乎一次的处理。

这种新架构节省了构建批处理流水线的成本，对于实时流水线，能够实现更高的聚合精度和稳定的低延迟。 此外，不需要在多个数据中心维护不同的实时事件聚合。

性能评估

系统性能评估

与旧架构中的Heron拓扑相比，新架构提供更低的延迟并提供更高的吞吐量。新架构处理延迟事件计数，并且在进行实时聚合时不会丢失事件。另外新架构中没有批处理组件，因此简化了设计并降低了旧架构中存在的计算成本。

聚合计数验证

计数验证过程分两个步骤。首先，评估了重复数据删除前后Dataflow中的重复事件百分比。其次，对于所有键，直接比较了原始TSAR批处理管道的计数和去重后Dataflow的计数。

第一步，创建一个单独的Dataflow管道来导出原始事件，然后直接从Pubsub到 BigQuery进行重复数据删除。然后，创建了计划查询以随时间连续查询计数。同时，创建了另一个Dataflow管道以将重复数据删除的事件计数导出到 BigQuery。这样，可以看到重复事件的百分比和去重后的百分比变化。

第二步，构建一个验证工作流，在该工作流中，将实现去重和聚合的数据导出到 BigQuery，并将原始 TSAR 批处理管道生成的数据从推特数据中心加载到谷歌云上的BigQuery。这样就可以运行预定查询来比较所有键的计数。

目前已经实现与Tweet交互流的批处理数据具有>95%的精确匹配。<5%的差异中，主要原因是原始TSAR批处理管道丢弃了新流管道捕获的后期事件。这进一步证明了新架构系统的更高准确度。

总结

通过将基于TSAR的旧架构迁移到推特数据中心和谷歌云平台上的混合架构，可以实现实时处理数十亿事件，并实现低延迟、高精度、稳定性、架构简单和低运成本的数据实时处理。