Heron是Apache Storm的一个直接继承者。从架构角度来看，它与Storm截然不同，但是从API的角度看它是完全向后兼容的。
文章指明了Heron和Storm的区别，描述了Heron背后的设计目标，并解释了其架构的主要组件。 代码库 Heron代码库的详细指南在这里。 拓扑 你可以认为一个Heron集群是一种管理流式处理实体（称作拓扑）的生命周期机制的机制。更多信息可以查看Heron拓扑文档。 与Apache Storm的关系 Heron是Apache Storm的直接继承者，但是以下面两点为构建目标： 1. 通过把Storm的基于线程的计算模型替换为基于进程的模型，克服Storm的性能，可靠性，和其他缺点。 2. 保留与Storm的数据模型和拓扑API的完全兼容。 关于Heron和Storm更深入的讨论，查看Twitter Heron: Stream Processing at Scale论文。 Heron设计目标 隔离 – 拓扑应该是基于进程的而非基于线程的，而且每个进程应该独立执行以便于调试，分析和排错。 资源限制 – 拓扑应该只使用它们初始分配的那些资源，永远不能超过那些限制。这使得Heron在共享的基础设施上也保证安全。 兼容性 – Heron与Apache Storm的API和数据模型是完全兼容的，使得开发人员便于在系统间迁移。 反压机制 – 在Heron这类分布式系统中，不能保证所有的系统组件以相同的速度执行。Heron有内置的反压机制来确保拓扑在组件缓慢的情况下可以自适应。 性能 – 许多Heron的设计选择使得Heron获得了比Storm更高的吞吐量和更低的延迟，同时还提供了增强的可配置性来微调可能的延迟/吞吐量的折中。 语义保证 – Heron支持at-most-once和at-least-once两种处理语义。 效率 – Heron的构建目标是以最小的资源使用量达到上述所有目标。 拓扑组件 Heron拓扑的下列核心组件在以下小节中深入讨论： - Topology Master - Container - Stream Manager - Heron Instance - Metrics Manager - Heron Tracker Topology Master Topology Master（TM）管理拓扑的整个生命周期，从提交直到最终被杀死。当==heron==部署一个拓扑时，它启动了一个TM和多个containers。这个TM创建了一个临时ZooKeeper节点以保证这个拓扑只有一个TM，并且这个TM可被拓扑中任何进程发现。这个TM也负责构建拓扑的物理计划，传递给不同组件。
Topology Master配置 TM有多种配置参数，你可以在拓扑生命周期每一个阶段进行调整。 Container每个Heron拓扑包括多个containers，每个container包含多个Heron实例，一个Stream Manager和一个Metrics Manager。Containers与拓扑的TM通信以确保拓扑形成一个全联通图。 作为插图，查看上述Topology Master小节的图片。 Stream Manager Stream Manager（SM）管理拓扑组件间元组的路由。一个拓扑中的每个Heron实例连接到它的本地SM，同时在一个给定的拓扑中所有的SM互相连接形成了一个网络。下面是SM网络的图示：
除了作为数据流的路由引擎外，SM还负责在需要时在拓扑中传播反压。下面是反压的图示：
上图中，假定bolt B3（在container A中）所有输入都来自spout S1。B3比其他组件运行更慢。结果是，container A的SM会拒绝来自容器C和D的输入，因为那样会导致那些容器的套接字缓冲填满，进而导致吞吐量崩溃。 在这种情况下，Heron的反压机制起效。容器A中的SM会向其他所有SM发送一条消息。结果是，其他SM会检查容器的物理计划，并切断流入bolt B3的spouts的输入（本例中是spout S1）。
一旦落后的bolt（B3）恢复正常，容器A的SM会通知其他SM，这个拓扑的流路由就会恢复正常。 Stream Manger配置 SM有多种配置参数，你可以在拓扑生命周期每一个阶段进行调整。 Heron Instance 一个Heron Instance（HI）是一个处理一个独立spout或bolt任务的进程，支持简单的调试和分析。目前，Heron只支持Java，所以所有HI都是JVM进程，但是未来会改变。 Heron Instance配置 HI有多种配置参数，你可以在拓扑生命周期每一个阶段进行调整。 Metrics Manager 每个拓扑运行一个Metrics Manager（MM），用于收集和导出一个container中所有组件的度量。然后把哪些度量信息路由给Topology Master和外部收集器，如Scribe， Graphite，或类似系统。 你可以通过实现自己的定制度量池（sink），使Heron支持其他系统。 集群级别组件 上述小节列出的所有组件在每个拓扑中都可以找到。下面列出的组件是集群级别的组件，在特定拓扑外起作用。 Heron CLI Heron有一个称作==heron==的CLI工具，用于管理拓扑。文档参照Managing Topologies。 Heron Tracker Heron Tracker（或Tracker）是一个关于拓扑的集群信息的集中入口，包括哪个拓扑正在运行，正在启动，正在被杀死，等等。它依赖于与集群中拓扑所使用的相同的ZooKeeper节点，并提供了JSON REST API接口来获取那些信息。Tracker可以运行在Heron集群内（在Heron scheduler管理的相同的机器上），也可以运行在Heron集群外。 运行包含JSON API文档的操作说明可以参考Heron Tracker。 Heron UI Heron UI是一个富可视化接口，可以用于与拓扑交互。通过Heron UI，可以看到集群中每个拓扑的逻辑和物理计划的着色的展现。
学习大数据，找大数据培训机构，就来科多大数据，带给你最好的学习体验。
文章指明了Heron和Storm的区别，描述了Heron背后的设计目标，并解释了其架构的主要组件。 代码库 Heron代码库的详细指南在这里。 拓扑 你可以认为一个Heron集群是一种管理流式处理实体（称作拓扑）的生命周期机制的机制。更多信息可以查看Heron拓扑文档。 与Apache Storm的关系 Heron是Apache Storm的直接继承者，但是以下面两点为构建目标： 1. 通过把Storm的基于线程的计算模型替换为基于进程的模型，克服Storm的性能，可靠性，和其他缺点。 2. 保留与Storm的数据模型和拓扑API的完全兼容。 关于Heron和Storm更深入的讨论，查看Twitter Heron: Stream Processing at Scale论文。 Heron设计目标 隔离 – 拓扑应该是基于进程的而非基于线程的，而且每个进程应该独立执行以便于调试，分析和排错。 资源限制 – 拓扑应该只使用它们初始分配的那些资源，永远不能超过那些限制。这使得Heron在共享的基础设施上也保证安全。 兼容性 – Heron与Apache Storm的API和数据模型是完全兼容的，使得开发人员便于在系统间迁移。 反压机制 – 在Heron这类分布式系统中，不能保证所有的系统组件以相同的速度执行。Heron有内置的反压机制来确保拓扑在组件缓慢的情况下可以自适应。 性能 – 许多Heron的设计选择使得Heron获得了比Storm更高的吞吐量和更低的延迟，同时还提供了增强的可配置性来微调可能的延迟/吞吐量的折中。 语义保证 – Heron支持at-most-once和at-least-once两种处理语义。 效率 – Heron的构建目标是以最小的资源使用量达到上述所有目标。 拓扑组件 Heron拓扑的下列核心组件在以下小节中深入讨论： - Topology Master - Container - Stream Manager - Heron Instance - Metrics Manager - Heron Tracker Topology Master Topology Master（TM）管理拓扑的整个生命周期，从提交直到最终被杀死。当==heron==部署一个拓扑时，它启动了一个TM和多个containers。这个TM创建了一个临时ZooKeeper节点以保证这个拓扑只有一个TM，并且这个TM可被拓扑中任何进程发现。这个TM也负责构建拓扑的物理计划，传递给不同组件。
Topology Master配置 TM有多种配置参数，你可以在拓扑生命周期每一个阶段进行调整。 Container每个Heron拓扑包括多个containers，每个container包含多个Heron实例，一个Stream Manager和一个Metrics Manager。Containers与拓扑的TM通信以确保拓扑形成一个全联通图。 作为插图，查看上述Topology Master小节的图片。 Stream Manager Stream Manager（SM）管理拓扑组件间元组的路由。一个拓扑中的每个Heron实例连接到它的本地SM，同时在一个给定的拓扑中所有的SM互相连接形成了一个网络。下面是SM网络的图示：除了作为数据流的路由引擎外，SM还负责在需要时在拓扑中传播反压。下面是反压的图示：
上图中，假定bolt B3（在container A中）所有输入都来自spout S1。B3比其他组件运行更慢。结果是，container A的SM会拒绝来自容器C和D的输入，因为那样会导致那些容器的套接字缓冲填满，进而导致吞吐量崩溃。 在这种情况下，Heron的反压机制起效。容器A中的SM会向其他所有SM发送一条消息。结果是，其他SM会检查容器的物理计划，并切断流入bolt B3的spouts的输入（本例中是spout S1）。
一旦落后的bolt（B3）恢复正常，容器A的SM会通知其他SM，这个拓扑的流路由就会恢复正常。 Stream Manger配置 SM有多种配置参数，你可以在拓扑生命周期每一个阶段进行调整。 Heron Instance 一个Heron Instance（HI）是一个处理一个独立spout或bolt任务的进程，支持简单的调试和分析。目前，Heron只支持Java，所以所有HI都是JVM进程，但是未来会改变。 Heron Instance配置 HI有多种配置参数，你可以在拓扑生命周期每一个阶段进行调整。 Metrics Manager 每个拓扑运行一个Metrics Manager（MM），用于收集和导出一个container中所有组件的度量。然后把哪些度量信息路由给Topology Master和外部收集器，如Scribe， Graphite，或类似系统。 你可以通过实现自己的定制度量池（sink），使Heron支持其他系统。 集群级别组件 上述小节列出的所有组件在每个拓扑中都可以找到。下面列出的组件是集群级别的组件，在特定拓扑外起作用。 Heron CLI Heron有一个称作==heron==的CLI工具，用于管理拓扑。文档参照Managing Topologies。 Heron Tracker Heron Tracker（或Tracker）是一个关于拓扑的集群信息的集中入口，包括哪个拓扑正在运行，正在启动，正在被杀死，等等。它依赖于与集群中拓扑所使用的相同的ZooKeeper节点，并提供了JSON REST API接口来获取那些信息。Tracker可以运行在Heron集群内（在Heron scheduler管理的相同的机器上），也可以运行在Heron集群外。 运行包含JSON API文档的操作说明可以参考Heron Tracker。 Heron UI Heron UI是一个富可视化接口，可以用于与拓扑交互。通过Heron UI，可以看到集群中每个拓扑的逻辑和物理计划的着色的展现。
学习大数据，找大数据培训机构，就来科多大数据，带给你最好的学习体验。
