[转载出处：www.11jj.com]

阿里妹导读：本文将为大家展示饿了么大数据..在实时计算方面所做的工作，以及计算引擎的演变之路，你可以借此了解Storm、Spark、Flink的优缺点。如何选择一个合适的实时计算引擎？Flink凭借何种优势成为饿了么首选？本文将带你一一解开谜题。

[原创文章：www.11jj.com]

本文作者：易伟平

整理：姬平&郑宁

..现状

下面是目前饿了么..现状架构图：

来源于多个数据源的数据写到kafka里，计算引擎主要是Storm,Spark和Flink，计算引擎出来的结果数据再落地到各种存储上。

目前Storm任务大概有100多个，Spark任务有50个左右，Flink暂时还比较少。

目前我们集群规模每天数据量有60TB，计算次数有1000000000，节点有400个。这里要提一下，Spark和Flink都是on yarn的，其中Flink onyarn主要是用作任务间jobmanager隔离， Storm是standalone模式。

 

应用场景

1.一致性语义

在讲述我们应用场景之前，先强调实时计算一个重要概念， 一致性语义：

1) at-most-once：即fire and forget，我们通常写一个java的应用，不去考虑源头的offset管理，也不去考虑下游的幂等性的话，就是简单的at-most-once，数据来了，不管中间状态怎样，写数据的状态怎样，也没有ack机制。

2)  at-least-once： 重发机制，重发数据保证每条数据至少处理一次。    

  

3) exactly-once： 使用粗Checkpoint粒度控制来实现exactly-once，我们讲的exactly-once大多数指计算引擎内的exactly-once，即每一步的operator内部的状态是否可以重放；上一次的job如果挂了，能否从上一次的状态顺利恢复，没有涉及到输出到sink的幂等性概念。

4) at-least-one + idempotent = exactly-one：如果我们能保证说下游有幂等性的操作，比如基于mysql实现 update on duplicate key；或者你用es, cassandra之类的话，可以通过主键key去实现upset的语义, 保证at-least-once的同时，再加上幂等性就是exactly-once。

 

2. Storm

饿了么早期都是使用Storm，16年之前还是Storm，17年才开始有Sparkstreaming， Structed-streaming。Storm用的比较早，主要有下面几个概念：

1) 数据是tuple-based

2) 毫秒级延迟

3) 主要支持java， 现在利用apache beam也支持python和go。

4)  Sql的功能还不完备，我们自己内部封装了typhon，用户只需要扩展我们的一些接口，就可以使用很多主要的功能；flux是Storm的一个比较好的工具，只需要写一个yaml文件，就可以描述一个Storm任务，某种程度上说满足了一些需求，但还是要求用户是会写java的工程师，数据分析师就使用不了。