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

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 或类似的东西）将它们连接在一起，以计算聚合所有这些的指标。