从Storm到Heron,Twitter的实时计算框架有哪些重大进化?

1.Twitter is real time

生活中，有很多事务需要实时分析处理。让我们以Twitter为例。Twitter的产品的基石就是 实时性 。

这里列举了一些Twitter的实时服务：

展示实时趋势；基于某个Tweet的话题的公开会话讨论；实时推荐；实时搜索。

目前日常生产中，Twitter的一个大型实时数据源，可以达到接近每秒千万级的事件。同时，Twitter的实时数据源很多很多！对同一个数据源的也有很多很多不同的相互独立的复杂处理任务！

如何实时分析处理如此大量的数据，是个巨大的挑战！

一个简单的场景是，我想实时知道，此时此刻全球各个不同地区使用Twitter的人数。时间延迟在1s内。

2.Twitter Storm

大家知道，开发分布式系统从来不是一件简单的事。需要考虑的事情很多：比如说，如何在不同机器间传递数据，如何保证数据的传递不丢失等等......

让每一个需要开发实时处理大量数据的应用程序的工程师，都具备相关的经验和基础，并不是一件实际的事情。所以当时我们重度依赖Storm来解决这些问题。考虑到并非所有人都有相关的经验，请容许我稍微介绍以下Storm。

这一页也提及了使用Storm的一些好处。

后来我们开源了Storm，它也是目前业界最流行的实时计算框架。

但是随着Twitter的数据流量越来越大，以及使用场景越来越复杂，我们发现了storm的局限性。这里我仅列举了一些，不会在这次分享进行深入讨论。

这张，说的是Storm job在提交执行的过程中，很多地方容易形成瓶颈，以及一些没有解决的问题。

这张，说的是storm运行模型，为了保证资源，很容易造成资源的浪费。

考虑到大家并不没有深入了解storm的实现，所以我不对各张图进行深入的分析。

我们对storm做过很多的改进，然而还是无法满足Twitter的需求。

我们常常会思考思考：我们是应该继续改进Storm呢，还是使用一个新系统？需要注意的是，当时的时间是2013年底，讨论的storm也是当时的版本。

最后我们发现:

storm的局限性涉及一些很基础底层的架构问题，改进Storm也需要大量的重写。

我们也考虑过其他开源项目，但是没有合适的。

我们决定开发新一代实时计算框架来满足我们的需求：Heron。

这里列举了我们当时使用storm中最大的痛点，也是我们最需要解决的问题

1，性能可预测（跟scability相关）

2，容易管理，降低维护，运维成本

3，降低用户使用成本，提高开发生产力

各位可能发现，提高性能并不是我们主要痛点；但事实上作为副产出我们最后大大地提高了性能，在后面会提及。

毕竟，让我们回想一下，我们需要分布式框架最根本的原因是为了让工程师们更好更容易地开发分布式程序！当然，这并不意味着性能不重要。

这是Heron的一部分设计目标，不一而足。其中兼容storm是为了方便移植，毕竟Twitter重度依赖Storm。

一个数据是，2014年底，Twitter已经完全用Heron取代了Storm；Twitter再没有一个Storm job。而数百个在线上生产的storm jobs迁移到Heron，约1个季度就完成。

这是提交运行Heron job的流程。

Heron是一个Library，本身不是一个service。运行Heron topology依赖现成的resource manager，比如说YARN or Mesos，来部署，heron只需要实现相应的Adaptor。我们专门为简便使用不同的adaptor做了相应设计，目前支持Local, Aurora和Slurm。Mesos和YARN已经有相应的pull request，很快就会check in。这样可以很好地利用现成的resource manager的功能而不需要重新造轮子，比如说authentication的功能。

这是Heron的运行时情况，我做简单介绍，不过度深入。

会有一个Topology Master做了中心点（一个Topology一个，不同Topology的相互独立），来分析那个极少量的同步控制信息（非数据信息）。

会使用Zookeeper做了启动时的service discovery。只存极少量的信息，尽量降低对其的依赖。

不同的运行组件，会打包成一个个的container。根据不同的resource manager，会有不同的资源隔离程度。

里面的I1，I2是Heron instance，执行用户真正的逻辑；

heron instance类似手机，而stream mgr类似信号塔。所有heron instance的数据交流，都要通过stream mgr。这样可以使的Heron instance变得很轻便，除了用户逻辑外，受系统本身影响降到最小。使得发生错误的时候容易隔离.大部分的系统逻辑都在stream mgr内，这样提高的隔离性。另外，考虑到stream mgr对性能要求很高，并且对内存控制及其复杂，我们决定使用高性能的非VM语言: C++来实现stream mgr。

我们将方便debug/tune，提高生产力作为高度设计目标，每个组件都会产生大量的metrics。而Metrics Mgr，就是负责处理这些metrics的。

4.Heron in practice

让我试试看，使用Heron有多简单。

首先，你需要获得binaries。你可以选择使用预先编译好的mac os x 和 Ubuntu的。如果是其他系统，也支持，但是需要自己手动从源代码编译。

这张显示了最后安装成功的提示信息。

安装成功之后，你并不需要一个真正的分布式resource manager，你在本地就可以使用Heron！并且是完全功能的，并不是单进程或者其他精简版的模拟！

这一方面，其实就是我们之前提及的different resource manager adaptor的一个实现：把本地文件系统做了resource manager；另外一方面，这个设计可以大大方便Heron开发者进行测试，调试。它是完全功能的，跟运行在分布式环境在功能上是没有区别的。

好了，现在Topology跑起来的，但是我们满足了么？

不！我们还希望有更多可见的信息，方便我们在部署中调试，提高开发和部署效率！

除此之外，用户还可以运行heron-tracker这个service。这允许你发送RESTful请求，并返回plan json的结果来查询topology当前运行的任何状况！

最后 我们还附带了Heron UI。

5.Heron Performance

大家知道，benchmark是很容易迷糊人的，因为那并不是实际生产的情况。所以这里，我们想分享一个我们实际的生产例子（因为保密原因，做了修改组件名等不影响比较的修改）。

简单来说，这个 topology的input traffic约 2M events/seconds，进行filter，然后count，最后汇集结果。

Q2: Heron 与 Spark Streaming 相比优劣点？谢谢

A2:

Heron是实时流处理，数据一旦来到，就进行处理；而Spark Streaming是micro-batch processing，数据要在到来后，放一段时间，再一起处理。所以Spark Streaming在latency上会有一些问题；而latency对于实时处理是一个比较大的顾虑。

Q3: 如果一个实时业务需要将实时流数据和海量的历史数据做复杂的聚合运算，如何实现比较合理？

A3:

这个设计具体的场景，不能简单说清楚。毕竟不同的场景的取舍不同。建议参考Twitter另外一个开源项目summingbird(which also can run on top of heron)，里面会有原生的实时流数据和海量的历史数据做复杂的聚合运算的支持，建议参考一下。

Q4: 请问Heron可以完全替代Storm吗？

A4:

从2014年底开始，Heron已经完全取代Storm成为 Twitter新一代的实时计算框架，并取得了很好的产出，所以在Twitter，Heron可以很好地适用所有之前用Storm的场景。Heron完全兼容native Storm API，所以正常情况下，用Heron跑storm job一行源代码都不需要改；只改编译文件的一个依赖就行了。但是但是对于一些建立在native Storm API之上的功能，如DRPC，基于用户需求和使用情况进行了裁剪。如果大家对这些功能有需求，我们也欢迎大家移植contribute进来。

Q5:如果 想深入了解Heron，可以从哪里获取学习信息和资源？

A5: 我们的官方网站：heronstreaming.io。里面有对应的goolge group和文档。

我们的github: https://github.com/twitter/heron

我们的相关论文，刚刚的slides里面。

Q6:Heron现在对多业务混用支持如何？隔离和资源利用率方面呢？

A6:

Heron现在对多业务混用支持如何  -- 不明白问题隔离和资源利用率方面呢 -- 目前Heron的设计中，只要resource manager支持，adaptor可以精确地要求资源，如CPU, RAM， Disk 和端口。举例来说，我可以给我的一个heron topology隔离地要求1.3个cpu，2GB RAM, 10GB Disk, 5个端口。所以隔离和资源利用率很好。

Q7: 您好。我是大数据小白。想咨询一下Heron与Hadoop的关系，是否之前用Spark或Strom做的事情，可以直接平行迁移到Heron上来做。在部署上是否有重要的区别？

A7:

不严谨地说：Hadoop mapreduce是批处理，输入的有限的确定数据，处理完后一起输出，输出是有限的确定结果。Heron是流处理，输入的是无穷的数据流，输出也是无穷的数据流，数据来一个处理一个进行迭代。我们把Storm的东西都迁移到Heron了。至于Spark和Hadoop mapreduce，批处理的任务，是否迁移到流处理框架，还请根据具体场景分析，因为他们会有不同的取舍和优化场景，不能直接给出回答。部署上则是具体情况具体分析，不能一概而论。

Q8: 目前Heron的成熟度如何，社区支持及活跃程度如何？会不会向Storm一样，是一个过渡产品，生命周期会有多长？

A8:

Heron从2014年年开始已经在Twitter完全进入production很好地运行。比较大型的Heron job处理~10M events/s 而没有任何问题。刚刚开源，社区也很火，目前除Twitter外，主要贡献者还有Microsoft, Cisco，Adobe， Elodina，Stanford University，ndiana University… 另外，Storm也不是过渡产品。它现在归属开源社区Apache不归属 Twitter，所以我没法回答你的这个Storm相关问题。

Q9:符老师好，intance用双线程，除了因为matrix收集的原因，性能上比单线程以及storm的多线程在这点上的比较有吗？

A9: 很有意思的问题。instance使用双线程，主要是为了防止一个corner case而不是出于性能原因。在性能上我们是有比较的，在slides也提及了。另外，Heron默认会自动产生大量的metrics，包括每个线程使用的cpu time，进程的内容使用情况。欢迎自己试用进行对比并分享。

符茂松，Twitter实时计算平台技术主管，负责Heron， Presto等服务。Heron的原作者之一。专注于分布式系统，在SIGMOD等会议期刊发表多篇论文。本科毕业于华中科技大学；研究生毕业于Carnegie Mellon University。