前言
本文隶属于专栏《1000个问题搞定大数据技术体系》，该专栏为笔者原创，引用请注明来源，不足和错误之处请在评论区帮忙指出，谢谢！
本专栏目录结构和参考文献请见1000个问题搞定大数据技术体系
正文
Flink起源于一个名为Stratosphere的研究项目，目的是建立下一代大数据分析平台，于2014年4月16日成为Apache孵化器项目。
Apache Flink是一个面向数据流处理和批量数据处理的可分布式的开源计算框架，它基于同一个Flink流式执行模型（streaming execution model），能够支持流处理和批处理两种应用类型。
由于流处理和批处理所提供的SLA(服务等级协议)是完全不相同， 流处理一般需要支持低延迟、Exactly-once保证，而批处理需要支持高吞吐、高效处理，所以在实现的时候通常是分别给出两套实现方法，或者通过一个独立的开源框架来实现其中每一种处理方案。
比较典型的有：实现批处理的开源方案有MapReduce、Spark；实现流处理的开源方案有Storm；Spark的Streaming 其实本质上也是微批处理。
Flink在实现流处理和批处理时，与传统的一些方案完全不同，它从另一个视角看待流处理和批处理，将二者统一起来：
Flink是完全支持流处理，也就是说作为流处理看待时输入数据流是无界的；
批处理被作为一种特殊的流处理，只是它的输入数据流被定义为有界的。
Flink 在流式计算方面的优势是开源领域"无人能及"的。
特点
- 处理无界和有界数据
关于无边界和有边界请参考我的这篇博客——批处理和流处理如何区分？ 有边界数据和无边界数据如何区分？
- 部署应用到任意地方
Apache Flink 是一个分布式系统，它需要计算资源来执行应用程序。Flink 集成了所有常见的集群资源管理器，例如 Hadoop YARN、 Apache Mesos 和 Kubernetes，但同时也可以作为独立集群运行。
Flink 被设计为能够很好地工作在上述每个资源管理器中，这是通过资源管理器特定(resource-manager-specific)的部署模式实现的。
Flink 可以采用与当前资源管理器相适应的方式进行交互。
部署 Flink 应用程序时，Flink 会根据应用程序配置的并行性自动标识所需的资源，并从资源管理器请求这些资源。
在发生故障的情况下，Flink 通过请求新资源来替换发生故障的容器。
提交或控制应用程序的所有通信都是通过 REST 调用进行的，这可以简化 Flink 与各种环境中的集成
- 运行任意规模应用
Flink 旨在任意规模上运行有状态流式应用。
因此，应用程序被并行化为可能数千个任务，这些任务分布在集群中并发执行。
所以应用程序能够充分利用无尽的 CPU、内存、磁盘和网络 IO。
而且 Flink 很容易维护非常大的应用程序状态。
其异步和增量的检查点算法对处理延迟产生最小的影响，同时保证精确一次状态的一致性。
Flink 用户报告了其生产环境中一些令人印象深刻的扩展性数字：
每天处理数万亿的事件
可以维护几TB大小的状态
可以部署上千个节点的集群
- 利用内存性能
有状态的 Flink 程序针对本地状态访问进行了优化。
任务的状态始终保留在内存中，如果状态大小超过可用内存，则会保存在能高效访问的磁盘数据结构中。
任务通过访问本地（通常在内存中）状态来进行所有的计算，从而产生非常低的处理延迟。
Flink 通过定期和异步地对本地状态进行持久化存储来保证故障场景下精确一次的状态一致性。
- 有状态计算的Exactly-once语义
状态是指flink能够维护数据在时序上的聚类和聚合，同时它的checkpoint机制
- 支持带有事件时间（event time）语义的流处理和窗口处理
事件时间的语义使流计算的结果更加精确，尤其在事件到达无序或者延迟的情况下。
- 支持高度灵活的窗口（window）操作
支持基于time、count、session，以及data-driven的窗口操作，能很好的对现实环境中的创建的数据进行建模。
- 轻量的容错处理（ fault tolerance）
它使得系统既能保持高的吞吐率又能保证exactly-once的一致性。通过轻量的state snapshots实现
- 支持高吞吐、低延迟、高性能的流处理
- 支持 savepoints 机制（一般手动触发）
即可以将应用的运行状态保存下来；在升级应用或者处理历史数据是能够做到无状态丢失和最小停机时间。
- 支持具有Backpressure功能的持续流模型
- Flink在JVM内部实现了自己的内存管理
- 支持迭代计算
- 支持程序自动优化：避免特定情况下Shuffle、排序等昂贵操作，中间结果进行缓存
扫一扫
230
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
