为何要使用Flink

  1. Flink通过实现Google Dataflow流式计算模型实现高吞吐，低延迟，高性能兼具实时流式计算框架
  2. Flink支持高度容错状态管理，防止状态在计算过程中因为系统异常而出现丢失
  3. Flink周期性的通过分布式快照技术CheckPoins实现状态的持久化维护，从而解决系统停机或异常情况下，仍然能计算出正确结果

Flink应用场景

1.实时智能推荐

  1.   - 根据用户历史购买行为，通过推荐算法训练模型，来预测用户可能会买什么；但时代技术发展，除了算法越来越完善外，对于时延的要求更加苛刻，因此利用flink流式计算来构建更加实时的智能推荐系统

2.复杂事件处理

  1.   - 案例主要集中在工业领域中，如车载传感器，机械设备等实时故障检测，此业务类型通常数据量非常大，对于数据处理时效性要求非常高
  2.   - Flink提供CEP(复杂事件处理)进行事件模式抽取，且应用Flink的SQL进行事件数据转换，在流式系统中构建实时规则引擎，一旦事件触发报警规则，便立即将告警结果传输通知下游，实现快速预警监测能力

3.实时欺诈检测

  1.   - 在金融领域，常有各种欺诈行为，如信用卡欺诈，贷款欺诈等；在以往需要几小时才能通过交易数据计算出用户行为指标，再通过规则判别出具有欺诈行为用户，在这情况下资金可能早已被转移了
  2.   - Flink流式计算技术能够再毫秒内完成对欺诈行为指标的计算，在实时对交易流水进行规则判断或模型预测，一旦检测出交易中存在欺诈嫌疑，则可对交易进行实时拦截，避免处理不及时而导致的损失

4.实时数仓与ETL

  1.   - Flink流计算的优势和SQL灵活的加工能力，对流式数据进行实时清洗，归并，结构化处理，为离线数仓进行补充和优化
  2.   - 用有状态计算技术，可以尽可能降低由于离线数据计算过程中调度逻辑的复杂度，且高效快速的处理需要的统计结果

5.流数据分析

  1.   - 实时计算各类数据指标，并利用实时结果及时调整在线系统相关策略，在各类内容投放，无线智能推送领域有大量的应用

6.实时报表分析

  1.   - 实时报表分析利用流式计算时得出的结果直接推送到前端应用，实时显示重要指标的变换情况。
  2.   - 经典案例便是双十一活动，在整个计算链路中包括从下单购买到数据采集，数据计算，数据校验等结果落地呈现屏幕中，全链路时间压缩在5秒内，顶峰计算性能高达30w单/秒，通过多链路流计算备份确保万无一失

Flink优势

1.高吞吐，低延迟，高性能

  1.   1. Flink是目前唯一一套集高吞吐，低延迟，高性能三者于一身的分布式流式数据处理框架
  2.   1. Apache Spark只兼顾高吞吐，高性能特征，因为Spark Streaming流式计算中无法做到低延迟保障
  3.   1. Apache Storm只兼顾高性能，低延迟特征，无法满足高吞吐的要求

2.支持事件时间(Event Time)概念

  1.   1. 多数框架窗口计算采用的都是系统时间(ProcessTime)，也是事件传输到计算框架处理时，系统主机的当前时间
  2.   1. Flink能够支持基于事件时间(Event Time)语义进行窗口计算(也就是使用事件产生的事件)，这种基于事件驱动的机制使得事件即使乱序到达，流系统也能够计算出精确的结果，保持了事件原本产生的时序性，尽可能避免网络传输或硬件系统的影响

3.支持有状态计算

  1.   1. Flink(1.4v)实现了状态管理，所谓状态就是流式计算中将算子的中间结果数据保存在内存或者文件系统中，等待下一个事件进入算子后可以从之前的状态中获取中间结果中计算当前的结果，无须每次基于全部原始数据来统计结果；从而降低了数据计算过程资源消耗，极大提高了系统性能

4.支持高度灵活的窗口(Window)操作

  1.   1. Flink将窗口划分为基于Time，Count，Session，Data-driven等类型窗口操作，窗口可以灵活的触发条件定制化来达到对复杂的流传输模式的支持，开发者可以定义不同的窗口触发机制来满足不同的需求

5.基于轻量级分布式快照(CheckPoints)实现的容错

  1.   1. Flink分布式运行上千个节点，将大型计算任务流程拆解成小个计算过程，再将任务分布到并行节点处理；在执行过程中，能够自动发现事件处理过程中的错误而导致数据不一致的问题，如，节点宕机，网络传输，升级或修复导致服务重启等
  2.   1. 基于分布式快照技术CheckPoints，将执行过程中的状态信息进行持久化存储，一旦任务出现异常停止，Flink就能过从CheckPoints中进行任务自动恢复，以确保数据在处理过程中的一致性

6.基于JVM实现独立的内存管理

  1.   1. Flink实现了自身管理内存机制，尽可能减少JVM GC对系统的影响
  2.   1. Flink通过序列化/反序列化方法将所有的数据对象转换为二进制在内存中存储，降低数据存储的大小，更有效利用内存空间；降低GC带来的性能下降或任务异常风险

7.SavePoints(保存点)

  1.   1. 对于流式应用，在一段时间内应用终止有可能导致数据丢失或计算结果不准确，如，集群版本升级，停机运维操作等
  2.   1. Flink通过SavePoints技术将任务执行快照保存在存储介质上，当重启后直接从事先保存的SavePoints恢复原有计算状态

流式计算框架对比

产品 模型 API 保证次数 容错机制 状态管理 延时 吞吐量
Storm Native(数据进入立即处理) 组合式(基础API) 至少一次 Record ACK(ACK机制) 无 低 低
Trident Micro-Batching(划分为小批处理) 组合式 仅一次 Record ACK 基于操作(每次操作有一个状态) 中 中
Spark Streaming Micro-Batching 声明式(提供封装后的高阶函数) 仅一次 RDD CheckPoints(基于RDD做CheckPoints) 基于DStream 中 高
Flink Native 声明式 仅一次 CheckPoints 基于操作 低 高

模型

  • Storm和Flink是一条一条处理数据，Trident(Storm的封装框架)和Spark Streaming其实都是小批处理，一次处理一小批量数据

    API

  • Storm和Trident都使用基础API进行开发，而Spark Streaming和Flink中都提供封装的高阶函数

    保证次数

  • 在数据处理方面，Storm可以实现至少处理一次，这样会导致数据重复处理问题，从而产生一些误差；Trident，Spark Streaming，Flink通过事务可以保证对数据实现仅一次处理

    容错机制

  • Storm和Trident通过ACK机制实现数据容错机制，Spark Streaming和Flink通过CheckPoints机制实现容错机制

    状态管理

  • Storm没有状态管理，SparkStreaming基于DStream的状态管理，Trident和Flink实现了操作状态管理