推特大规模应用的流处理框架:Apache Heron

21-07-14 banq

Apache Heron是实时、分布式、容错的流处理引擎。自 2014 年以来,Heron 为 Twitter 的各种用例提供​​了所有实时分析的支持。事件报告下降了一个数量级,证明了经过验证的可靠性和可扩展性

从一开始,Heron 就被设想为一种新型的流处理系统,旨在满足最苛刻的技术要求,处理甚至最大规模的工作负载,并满足各种规模和复杂程度的组织的需求。

Heron/Storm 可以实现亚秒级实时报告。Spark 在混合小批量处理方面处于中间位置。据报道,Twitter 已经使用 Heron/Storm 跟踪所有推文中的字数以找到热门话题,其中一条新推文进入整个网络更新的字数之间的延迟为 100 毫秒。

 

与Storm关系

Twitter 将其构建的“下一代 Storm”项目分享给Apache。这是 Twitter 的一个内部团队对 Apache Storm 进行的彻底重写。作为开源项目历史回顾,Apache Storm 最初由一家名为 Backtype 的初创公司构建,该项目由 Backtype 的技术创始人 Nathan Marz 领导。然后,Backtype 被 Twitter 收购,Storm 成为 Twitter 大规模流处理(推文、推文分析和其他事情)的主要组件。

然而,在某个时刻,Nathan Marz 离开了 Twitter,另一组工程师试图在 Twitter 内部重新思考 Storm。当时还有很多围绕 Apache Mesos 的工作正在进行。Heron 是他们对 Storm 的“重新思考”的合并,同时也使使用 Mesos 管理类似 Storm 的 Heron 集群成为可能。

很多 Storm 是用 Java 编写的,但“核心”是用 Clojure 编写的。与其说是社区“机会”,不如说是放弃 Clojure 的“决定”。我的理解是,Storm 的生产采用者之一阿里巴巴做了一个从 Clojure 到 Java 的清洁移植,他们称之为 jstorm。然后他们将该实现捐赠/提供给了 Apache Storm 项目,该项目决定基于它构建 Storm 2.x 系列。所以 Storm 1.x 仍然拥有 Clojure 核心,沿袭原始 Backtype 版本,但 2.x 来自 jstorm。Storm 2.x 的一大重点是大规模性能、延迟和背压管理。与此同时,在 Storm 2.x 成型之前,Heron 作为一个专注于性能的 Storm 替代品而出现,它的 API 与 Storm 兼容。

同时,Storm 在 1.x 系列中变得非常非常稳定,然后在 2.x 系列中从 Clojure 到 Java 进行了干净的重写,主要是为了进一步提高性能。上一个稳定版/主要 Storm 版本是在 2020 年。

Storm 提供了流处理编程 API、多语言线协议和集群管理方法。但是某些集群计算问题现在可能可以在基础设施层得到更好的解决。(比如Storm是在整个容器+docker+k8s专注于云操作之前开发的。)Storm解决的核心问题:将数据处理建模为计算图;线程、进程和节点之间的高速网络通信;消息传递保证和重试能力;可调并行性;内置监控和日志记录;以及更多。

Heron 与 Apache Storm 的 API 兼容,因此迁移不需要更改代码。

 

定位区别:

  • - Hadoop 是一个生态系统。
  • - Kafka 是一个分布式日志。
  • - Storm/Heron、Samza 和 Flink 是流处理引擎。
  • - Spark 是一个 Map/Reduce 框架,它使用内存来缓存计算,以提供比其他基于磁盘的框架的一些性能提升。如果您眯眼足够用力,它还可以进行一些流式计算。

 

流处理用处:

流处理的标准用例是:

  • 1.丰富事件流。假设您有一个带有 IP 地址字段的日志记录流。在将日志发送到 Elasticsearch 之前,您希望丰富地理位置。
  • 2. 窗口聚合。也许您有一个发出“登录”事件的应用程序,并且您想检测彼此在 X 分钟内来自不同 IP 地址的登录尝试。
  • 3. 加入多个事件流。您有多个不同的事件流,并且希望使用一些通用的连接键(可能是会话 ID 或类似的东西)将它们连接在一起,以计算聚合所有这些的指标。

针对 tiktok、facebook、youtube 等推荐系统的流媒体模型训练。如果您希望模型能够快速学习新事件,从而使它们在非常新的内容/用户上做得更好,您将需要使用流媒体管道。

 

大容量自托管分布式流处理解决方案最流行的选择仍然是 Spark、Flink 和 Kafka Streams。

Kafka流更简单,因为它基本上只是Kafka本身之上的一个框架,因此如果您已经使用Kafka进行流数据并且没有复杂的需求,那么它可能是一个不错的选择。

Spark 和 Flink 类似。两者都支持批处理(例如在 Hadoop 之上)和流处理。Spark 有更好的工具,但 Flink 对流窗口函数有更复杂的支持。Spark 还使用“微批处理”而不是真正的实时,因此在使用 Spark 进行流式处理时会有更多的延迟,如果这很重要的话。

 

猜你喜欢