Twitter的旧软件架构基于lambda架构，包括批处理层、速度层与服务层。

Twitter每日需实时处理高达4000亿的事件，并生成PB级的数据。这些数据主要来源于分布式数据库、Kafka以及Twitter事件总线等多种事件源。

背景与挑战

Twitter 实时处理 4000 亿个事件，每天产生 PB 级的数据。这些事件来自许多来源，包括不同的平台和系统：Hadoop、Kafka、Google BigQuery、 Google Cloud Storage、Google PubSub等。为了处理海量数据，Twitter 针对每种需求构建了内部工具：Scalding用于批处理，Heron用于流处理，TimeSeries AggregatoR框架用于批处理和流处理，Data Access Layer用于数据消费。

尽管该技术非常稳健，但数据增长仍然给基础设施带来压力；最明显的例子是互动和参与管道，它批量实时处理大规模数据。该管道收集和处理来自各种实时流以及服务器和客户端日志的数据，以提取具有多级聚合和指标维度的推文和用户交互数据。该管道的聚合数据是 Twitter 广告收入和许多数据产品服务的真相来源。因此，管道必须确保低延迟和高准确性。让我们看看 Twitter 如何处理这一任务。

以下部分，我们描述 Twitter 原始的交互和参与管道解决方案。

旧的架构

概述

Twitter 最初的解决方案采用了 lambda 架构。它有两个独立的管道：批处理（提供批处理的精确视图）和实时流处理（提供在线数据的视图）。

这两个视图输出最终会融合在一起。Twitter 的架构如下：

• Summingbird平台：该平台包括多个分布式引擎，如 Scalding、Heron，一个专用库，允许用户定义 MapReduce 逻辑并在这些引擎上执行。

• TimeSeries AggregatoR：一个强大且可扩展的实时事件时间序列聚合框架。

• 批处理：批处理管道的来源可以是 HDFS 中的日志、客户端事件或推文事件。有许多 Scalding 管道用于预处理原始数据，然后将其导入 Summingbird 平台。管道的结果将存储在曼哈顿分布式存储系统中。为了节省成本，Twitter 在一个数据中心部署批处理管道，并在其他两个数据中心复制数据。

• 实时：实时管道的来源是 Kafka topic主题。数据将“流”到 Summingbird 平台内的 Heron，然后 Heron 的结果将存储在 Twitter Nighthawk 分布式缓存中。与批处理管道不同，实时管道部署在 3 个不同的数据中心。

• 批处理和实时存储之上还包括查询服务。

挑战

由于实时数据规模大、吞吐量高，存在数据丢失和不准确的风险。如果处理速度赶不上事件流，Heron 拓扑（有向无环图表示数据处理的 Heron 流程）中就会出现背压。当系统处于背压状态一段时间后，Heron Bolts（可以想象为 Worker）可能会累积滞后，从而导致系统整体延迟过高。

此外，许多 Heron 流管理器可能会因背压而失败（流管理器管理拓扑组件之间的数据路由）。Twitter 的解决方案是重新启动 Heron 容器以启动流管理器。然而，重新启动肯定会导致事件丢失，从而降低管道的整体准确性。

以下部分描述了 Twitter 在认识到原有解决方案的局限性后提出的新解决方案。

新架构

概述

通过新方法，Twitter 使用 Kappa 架构简化了解决方案，仅使用一个实时管道。该架构将利用内部 Twitter 和 Google Cloud Platform 解决方案：

• 内部部署：他们构建了预处理服务，将 Kafka 主题事件转换为 Google Pubsub 事件表示。

• 在 Google Cloud 上：他们使用Pubsub进行事件提取，使用Dataflow作业进行重复数据删除和实时聚合，并使用BigTable作为输出接收器。

新架构的流程可以这样描述：

• 步骤 1：它们从源 Kafka 主题使用数据，进行转换和字段重新映射，最后将结果发送到中间 Kafka 主题。

• 第 2 步：事件处理器将中间 Kafka 主题中的数据转换为 Pubsub 表示，并使用 UUID（用于 Dataflow 中的重复数据删除）和一些与处理上下文相关的元信息装饰事件。

• 步骤 3：事件处理器将事件发送到 Google Pubsub 主题。Twitter 几乎无限次重试此 PubSub 发布过程，以确保消息以至少一次的方式从数据中心传递到 Google Cloud。

• 步骤 4：Google Dataflow 作业将处理来自 PubSub 的数据。Dataflow 工作器实时处理重复数据删除和聚合。

• 步骤5：Dataflow 工作者将聚合结果写入BigTable。

  Dataflow 工作者将聚合结果写入 BigTable。

评估

Twitter 对新架构的实现与迭代

新方法的实现

• 与旧架构的 10 秒至 10 分钟的延迟相比，延迟保持稳定在 ~10 秒。

• 与旧架构的最大吞吐量约 100 MB/s 相比，实时管道的吞吐量最高可达到约 1GB/s。

• 通过至少一次向 Google Pubsub 发布数据以及 Dataflow 的重复数据删除工作，确保几乎精确地进行一次处理。

• 节省建设批量流水线的成本。

• 实现更高的聚合精度。

• 处理延迟事件的能力。

• 重启时无事件丢失

他们如何监控重复百分比？

Twitter 创建了两个独立的 Dataflow 管道：一个管道将原始数据从 Pubsub 直接路由到 BigQuery，另一个管道将去重后的事件计数导出到 BigQuery。

这样，Twitter 就可以监控重复事件的百分比以及去重后的百分比变化。

他们是如何比较旧批处理管道和新 Dataflow 管道中的重复数据并删除计数的？

• 除了写入 BigTable 之外，新的工作流程还将重复数据删除和聚合的数据导出到 BigQuery。

• Twitter 还将旧的批量数据管道结果加载到 BigQuery 中。

• 运行计划查询来比较重复计数。

• 结果是，新流水线结果的 95% 以上与旧批处理流水线完全匹配。5% 的差异主要是因为原始批处理流水线丢弃了迟到事件，而新流水线可以有效捕获这些事件。

结语

通过迁移到新的 Kappa 架构，Twitter 在延迟和正确性方面比旧架构有了显著改善。

新架构不仅性能更好，而且简化了数据管道，只保留了流管道。

我们下篇博客再见。