系列文章
一 、实时存储引擎 Kafka
SSD 缓存架构解决延迟消费污染缓存空间问题
二 、实时计算引擎 Flink
2.1 简介和系统架构
相当于 mapreduce/spark + 实时计算
在实时处理框架中，不会持久化，而是写入内存的一个 state，通过写入内存替代持久化，增加处理速度。
最近两年使用 streaming，Flink，生态比较好。
native 单条
micro-batch 微批
实时计算平台实际就是作业管理平台，提供了上面四种功能。
为了规范开发过程，在平台上完成所有工作，集中化管理作业，平台操作取代客户端。
以下是应用场景：
反爬虫：实时 一分钟之内一个IP访问某网站多少次
实时流量分析： 节日活动的效果
B 端：面向商家的应用
2.2 Flink 具体的作业
source从 kafka 数据源读数据，然后中间两个 Transform ，读过来的每一行的 id 进行分发，分发的时间窗口是 10s 中，每个窗口进行 sum。如果把 id 当作 ip , 就和上面的 爬虫案例 相同了。最后写到文件中。
上面是逻辑流程，我们看上面的流程是如何被编译成一段作业，一个 job 图，被分配到物理节点上去的。
中间的点呢都是操作（function），箭头是一个 streaming ，是一个数据流。source、map分布在多个组件上（分布式化），sink 可以是单一的或者分布式的。只有 keyby / apply的时候才需要进行 shuffle 。
source 和 map 都是分布式，合并后可以减少网络代价。
所以把进行了合并，合并后的节点就在同一个机器上进行运行。
这些节点最终被分配到用 YARN 做资源调度的模型当中，这个模型就是物理模型。这个物理模型就是 Flink 的 program 通过 Client 提交到 YARN 集群上去运行，YARN 集群上也有 Job Manager 和 Task Manager。Job Manager 是用来控制整个系统的，Task Manager 是我们上面讲的五个节点。
(可能这里少了一部分qaq)
在写 Spark 的时候关心它的状态吗？Spark 是没有这个概念的。在实时处理的时候是非常关心状态，是否数据丢失或者重复，这涉及到准确性语义保证。离线作业数据丢失或者重复可以重新再来一遍，但是实时处理不行，想做到重复消费需要非常麻烦的机制，这里不讲。所以流式处理的语义保证就有几种情况：
- 最多消费一次
- 至少消费一次
- 准确一次
这里说完了 state，再说说窗口（窗口就是比如统计过去 10 秒的数据中的10秒就是窗口），有很多种，如滑动窗口等。这里不细讲，同学们下去拓展延伸开来和 Spark 进行对比，理解的就比较透彻了。
2.3 Flink HA 新架构
这是一个基于 YARN 的 Flink 架构。
YRAN 申请资源；
job M 和 Task M通过 HDFS 和 ZK 进行交互；
有监控程序监控 Job Manager，监控程序轮询检测时间周期太长。怎么办呢？我们看看社区的解决方案。
社区的解决方案
Leader 的选举和发布 通过 zk 管理；类似分布式锁
当然这样也有问题
保证系统只有一个 app master
没有必要选举，所以去掉选举过程。最终方案如下：
三、QA
A：消费 kafka 不能保证一次性消费
A：日志不保证顺序，多进程 多线程不保证顺序性
Q：水位预估？
一般设置更大的阈值，一般是测试过程中拿到的数据比对去设置水位值
Q：Kafka 的扩容需要分区重新分配，代价比较大，美团再在 Kafka 扩容方面有做什么优化吗？
如果扩充分区，可以让新数据写新分区
代价大的是迁移数据，当我们发现不均衡的时候会启动迁移，选择压力比较小的时间（如晚上）进行
Q：实时数据和批数据怎么对齐，如果批数据和实时数据计算结果不一样？
当两种数据放到同一个表的时候，从业务上进行区分，分开写或者根据时间判断是由实时覆盖或者批数据进行覆盖。
Q：美团 Flink cep 应用场景多么吗？大流量下的准确性怎么验证呢？
将实时处理结果和离线结果进行比对。将测试阶段和实时阶段进行对比
Q：业务数据进入大数据平台后做离线分析前，需要检查 T+ 1 业务数据是否完整进入大数据平台吗？需要的话，会做哪些检查呢？
怎么保证进来的是完整的数据？完整性是需要检查的，但是这种检查是只是否全部收集，而不考虑数据的正确性。有两种策略，对于昨天进来的数据； check down （没太听清）。
注：
内容来自美团技术团队10.13大数据课程，侵删。