Twitter订阅源中的事件调用示例
在这篇文章中，我们将尝试理解：
- Twitter过去是如何处理事件的，以及那种方法存在哪些问题?
- 是什么业务和客户影响促使Twitter迁移到新架构?
- 新架构
- 旧架构和新架构的性能比较。
为了处理事件，Twitter有自己的一套内部工具，例如：
- Scalding是Twitter用于批处理的工具。
- Heron是Twitter自己的流处理引擎。
- TimeSeriesAggregator(TSAR)用于批处理和实时处理。
在我们深入了解事件系统如何演变之前，让我们简要了解一下这四种内部工具。
- Scalding：Scalding是一个Scala库，可以轻松指定Hadoop MapReduce作业。Scalding建立在Cascading之上，Cascading是一个抽象了底层Hadoop细节的Java库。Scalding与Pig相当，但提供了与Scala的紧密集成，将Scala的优势带入MapReduce作业中。
- Heron：Apache Heron是Twitter自己的流处理引擎，由于需要处理PB级别的数据，提高开发人员的生产力并简化调试而开发。Heron中的流应用程序称为拓扑。拓扑是一个有向无环图，其节点表示数据计算元素，边表示数据流动的流。
- Spouts：它们连接到数据源并将数据注入流中
- Bolts：它们处理传入的数据并发出数据
TimeSeriesAggregator：
Twitter的数据工程团队面临着每天处理数十亿事件的挑战，无论是批处理还是实时处理。TSAR是一个健壮的、可扩展的、实时事件时间序列聚合框架，主要用于监控参与度：聚合与推文的互动，按多种维度(如设备、参与类型等)进行分段。
让我们在非常高的层次上检查Twitter的工作原理。所有Twitter功能都由遍布全球的微服务支持，包括超过10万个实例。它们负责生成事件，这些事件被发送到事件聚合层，该层由Meta的一个开源项目构建。这一层负责对这些事件进行分组，运行聚合作业，并将数据存储在HDFS中。然后处理这些事件，并进行格式转换，重新压缩数据，以创建格式良好的数据集。
旧架构
Twitter的旧架构基于lambda架构，它包括批处理层、速度层和服务层。批处理部分是由客户端生成的日志，并在事件处理后存储在Hadoop分布式文件系统(HDFS)上。Twitter构建了几个扩展管道，用于预处理原始日志，并将它们作为离线源摄入到Summingbird平台中。速度层的实时组件源是Kafka主题。
一旦数据被处理，批处理数据就存储在Manhattan分布式系统中，而实时数据则存储在Twitter自己的分布式缓存Nighthawk中。TSAR系统，如TSAR查询服务，查询缓存和数据库，是服务层的一部分。
Twitter在三个不同的数据中心有实时管道和查询服务。为了减少批处理计算成本，Twitter在一个数据中心运行批处理管道，并将数据复制到其他两个数据中心。
你能想到为什么实时数据会存储在缓存中而不是数据库中吗?
旧架构中的挑战
让我们尝试理解这种架构在实时事件处理中可能遇到的挑战。
让我们用一个例子来理解这一点：
假设有一个大事件，如FIFA世界杯。推文源将开始向推文拓扑发送大量事件。解析推文的bolts无法及时处理事件，拓扑内部出现了背压。当系统长时间处于背压状态时，heron bolts可能会积累spout滞后，这表明系统延迟高。Twitter观察到，当这种情况发生时，拓扑滞后的下降需要很长时间。
团队使用的操作解决方案是重启Heron容器以重新开始处理流。这可能导致操作期间事件丢失，从而导致缓存中聚合计数的不准确。
现在让我们尝试理解批处理事件的例子。Twitter有几个重计算管道处理PB级别的数据，并每小时运行一次，以将数据同步到Manhattan数据库中。现在让我们想象一下，如果同步作业需要超过一个小时，而下一个作业已经安排开始。这可能导致系统的背压增加，并可能导致数据丢失。
正如我们所看到的，TSAR查询服务整合了Manhattan和缓存服务，为客户提供数据。由于实时数据可能丢失，TSAR服务可能会向客户提供不准确的指标。
让我们尝试理解促使他们解决这个问题的客户和业务影响：
- Twitter广告服务是Twitter最主要的收入模式之一，如果其性能受到影响，直接影响他们的商业模式。
- Twitter提供各种数据产品服务来检索印象和参与度指标的信息;这些服务会因数据不准确而受到影响。
- 另一个问题是，从事件创建到可用于使用可能需要几个小时，因为批处理作业。这意味着客户端进行的数据分析或任何其他操作将不会拥有最新数据。可能会有几个小时的时间滞后。
现在，这意味着如果我们想根据用户生成的事件更新用户的时间线，或者根据用户与Twitter系统的互动进行用户行为分析，客户将无法做到，因为他们需要等待批处理完成。
新架构
新架构建立在Twitter数据中心服务和Google Cloud平台上。Twitter构建了一个事件处理管道，将kafa主题转换为pub sub主题，然后发送到Google Cloud。在Google Cloud上，流数据流作业执行实时聚合，并将数据沉入BigTable中。
对于服务层，Twitter使用了一个在Twitter数据中心前端和Bigtable及Bigquery后端的LDC查询服务。整个系统可以以低延迟(约10毫秒)流式处理每秒数百万事件，并且在高流量期间可以轻松扩展。
这种新架构节省了构建批处理管道的成本，对于实时管道，Twitter能够实现更高的聚合精度和稳定的低延迟。此外，他们不需要在多个数据中心维护不同的实时事件聚合。
性能比较
与旧架构中的Heron拓扑相比，新架构提供了更低的延迟，并提供了更高的吞吐量。此外，新架构处理了延迟事件计数，并且在进行实时聚合时不会丢失事件。更重要的是，新架构中没有批处理组件，因此简化了设计并减少了旧架构中存在的计算成本。
结论
通过将基于TSAR的旧架构迁移到Twitter数据中心和Google Cloud平台的混合架构，Twitter能够实时处理数十亿事件，并实现低延迟、高精度、稳定性、架构简化和降低工程师的运营成本。
