快手基于快手基于ApacheFlink的优化实践的优化实践
一、流式计算的介绍
流式计算主要针对 unbounded data(无界数据流)进行实时的计算,将计算结果快速的输出或者修正。
这部分将分为三个小节来介绍。第一,介绍大数据系统发展史,包括初始的批处理到现在比较成熟的流计算;第二,为大家简
单对比下批处理和流处理的区别;第三,介绍流式计算里面的关键问题,这是每个优秀的流式计算引擎所必须面临的问题。
1、大数据系统发展史
上图是 2003 年到 2018 年大数据系统的发展史,看看是怎么一步步走到流式计算的。
2003 年,Google 的 MapReduce 横空出世,通过经典的 Map&Reduce 定义和系统容错等保障来方便处理各种大数据。很快
就到了 Hadoop,被认为是开源版的 MapReduce, 带动了整个apache开源社区的繁荣。再往后是谷歌的 Flume,通过算子连
接等 pipeline 的方式解决了多个 MapReduce 作业连接处理低效的问题。
流式系统的开始以 Storm 来介绍。Storm 在2011年出现, 具备延时短、性能高等特性, 在当时颇受喜爱。但是 Storm 没有
提供系统级别的 failover 机制,无法保障数据一致性。那时的流式计算引擎是不精确的,lamda 架构组装了流处理的实时性和
批处理的准确性,曾经风靡一时,后来因为难以维护也逐渐没落。
接下来出现的是 Spark Streaming,可以说是第一个生产级别的流式计算引擎。Spark Streaming 早期的实现基于成熟的批处
理,通过 mini batch 来实现流计算,在 failover 时能够保障数据的一致性。
Google 在流式计算方面有很多探索,包括 MillWheel、Cloud Dataflow、Beam,提出了很多流式计算的理念,对其他的流式
计算引擎影响很大。
再来看 Kafka。Kafka 并非流式计算引擎,但是对流式计算影响特别大。Kafka 基于log 机制、通过 partition 来保存实时数
据,同时也能存储很长时间的历史数据。流式计算引擎可以无缝地与kafka进行对接,一旦出现 Failover,可以利用 Kafka 进
行数据回溯,保证数据不丢失。另外,Kafka 对 table 和 stream 的探索特别多,对流式计算影响巨大。
Flink 的出现也比较久,一直到 2016 年左右才火起来的。Flink 借鉴了很多 Google 的流式计算概念,使得它在市场上特别具
有竞争力。后面我会详细介绍 Flink 的一些特点。
2、批处理与流计算的区别
批处理和流计算有什么样的区别,这是很多同学有疑问的地方。我们知道 MapReduce 是一个批处理引擎,Flink 是一个流处
理引擎。我们从四个方面来进行一下对比:
1)使用场景
MapReduce 是大批量文件处理,这些文件都是 bounded data,也就是说你知道这个文件什么时候会结束。相比而言,Flink
处理的是实时的 unbounded data,数据源源不断,可能永远都不会结束,这就给数据完备性和 failover 带来了很大的挑战。