1637218412(1).png推特上,我们每天需要实时处理4000亿个事件,生成Pb 数据。其消费数据的事件源分布在各种平台和存储系统上,包括Hadoop、vertica、Manhattan分布式数据库、Kafka、Twitter eventbus、GCS、bigquery和PubSub。为了在这些不同的数据源和平台上处理这些类型的数据,推特数据平台团队构建了内部工具,例如用于批处理的缩放、用于流处理的 Heron、用于批处理和实时处理,以及用于数据发现和消费的数据访问层。然而,随着数据的快速增长,大规模仍然挑战着工程师用来运行管道的数据基础设施。例如,有一个交互和参与管道,可以批量和实时处理大规模数据。随着数据规模的快速增长,面临着降低流延迟、提供更高的数据处理精度和实时数据服务的高要求。


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


在谷歌云上,使用基于谷歌数据流的推特内部框架进行实时聚合。 Dataflowwork 实时处理重复数据删除和聚合。 重复数据删除过程的准确性取决于计时窗口。 通过同时将数据写入 bigquery 并不断查询重复百分比来证明高重复数据删除的准确性。最tuitecom.com后,将带有查询键的聚合计数写入 BigTable。 对于服务层,使用了twitter内部的LDC查询服务。 前端在推特数据中心和不同的后端,比如BigTable和bigquery。 整个系统每秒可以流式传输数百万个事件,延迟低至约 10 秒,并且可以在本地和云流式传输系统中进行高流量扩展。 使用云发布订阅作为消息缓冲区,保证本地流媒体系统不会丢失数据。 然后是用于近乎一次性处理的重复数据删除。