Flink与其他流式计算系统的比较

流计算

Dataflow编程模型： 清晰的定义这些问题，并针对性的在模型框架层面加以解决
01.概念一
      bounded data(processing)
    unbounded data(processing)
02.概念二 ： Event time和 Process time
    常见的流式计算框架中的［key，value］两元组tuple形式的信息数据，
                  变换成了［key,value, event time, window ］这样的四元组模型
    多数基于Process time定义的固定窗口或滑动窗口模型，并没有特别强调窗口触发这样一个概念
03.Dataflow提供了可自定义的窗口触发模型
04.网络流控是为了在上下游速度不匹配的情况下，防止下游出现过载

Storm

01.容错方式
   at least once(实现采用record-level acknowledgments)，可能存在重复发送的情况
    Trident可以支持storm 提供exactly once语义。
   ACK机制 ：对每个消息进行全链路跟踪，失败或超时进行重发
 状态管理
02. 无状态，需用户自行进行状态管理
03 
04
05.  feedback 机制 
     Storm 在每一个 Bolt 都会有一个监测反压的线程（Backpressure Thread）

Spark

Spark Streaming

 01. 端到端的exactly-once 容错-- failure detector 以及 failover处理
      Write-Ahead Logs
      Configuring write-ahead logs 
        spark.streaming.receiver.writeAheadLog.enable
        spark.streaming.receiver.writeAheadLog.closeFileAfterWrite    
02. 状态计算
        updateStateByKey  reduceByKeyAndWindow 
03.Event time 以及乱序和迟到数据 
        水印
04.窗口和触发模型

05. 网络限速
  001. Setting the max receiving rate
        spark.streaming.receiver.maxRate 
        spark.streaming.kafka.maxRatePerPartition
  002.backpressure
            spark.streaming.backpressure.enabled 
            spark.streaming.backpressure.initialRate
        Fecher 会实时的从 Buffer、Processing 这样的节点收集一些指标
 然后通过 Controller 把速度接收的情况再反馈到 Receiver，实现速率的匹配
06.执行流程
  Driver - Executor
  Master -worker
  任务调度： DAG stage task

Spark Structure Streaming

01. end-to-end exactly-once fault-tolerance guarantees 
       通过 checkpointing and Write-Ahead Logs
02. Stateful Stream Processing 
          mapGroupsWithState  和 flatMapGroupsWithState
03.Event time 以及乱序和迟到数据 
        水印
04.窗口和触发模型

05. 网络限速

Flink

Flink  checkpointing 和 Two phase commit
    Phase 1: Pre-commit
    Phase 2:Commit
02. 状态计算

03.Event time 以及乱序和迟到数据 
     水印

04.窗口和触发模型

05. 网络限速  
   1.5之前 Flink TCP-based 
     基于 TCP 流控 + bounded buffer 实现反压
   1.5之后 Credit-based flow control 基于信用度的流量传输控制
     Credit 可以类比为 TCP 的 Window 机制，实现了自己托管的 credit - based 流控机制，在应用层模拟 TCP 的流控机制
 默认情况下，jobmanager会每隔50ms采集对每个task采集100个stack trace来决定是否有反压。
    如果是0.01只表明100个采样中，有1个很慢
     OK  LOW HIGH
      配置 
        jobmanager.web.backpressure.refresh-interval ： web默认是60s采集一次反压值
        jobmanager.web.backpressure.num-samples ： 采集样本的数量决定反压，默认值是100
        jobmanager.web.backpressure.num-samples ： 采集样本的数量决定反压，默认值是100
06.网络通信
   Apache Flink 在 Dispatcher、JobMaster、ResourceManager、TaskExecutor 几大组件之间采用 akka 进行通信
 Task之间的通信Netty
   Flink的这个Buffer接口主要是一种flink层面用于传输数据和事件的统一抽象，其实现类是NetworkBuffer，是对MemorySegment的包装
   为了方便管理NetworkBuffer，Flink提供了BufferPoolFactory，并且提供了唯一实现NetworkBufferPool
 执行流程
   Jobmanager TaskManger   dispatcher  resourceManager
   进程master和worker
   任务调度： StreamGraph JobGraph ExecutionGraph

各个性能

功能：
   功能完整性
性能指标：
   稳定性
   吞吐量（Throughput）
   延迟（Latency）
 其他概念
   幂等 f(f(x)) = f(x)
   非幂等
     幂等：多次重复操作和一次操作产生的影响是一样的。
   非幂等：多次重复操作和一次操作产生的影响是不一样的。
      WriteAheadLog()      WAL机制支持非幂等业务请求场景  或者exactly once业务场景
      HBase的Write Ahead Log (WAL)提供了一种高并发、持久化的日志保存与回放机制。
          每一个业务数据的写入操作（PUT / DELETE）执行前，都会记账在WAL中。
   过程 commit  abort 
附录：
   当一个特定时间窗口被触发以后，后续晚到的数据如何处理，如何对之前触发结算的结果进行修正
  三种策略 丢弃  累计  累计并更正

   ProcessFunction函数是低级别的流处理操作，可访问所有（非循环）流应用程序的基本构建块(basic building blocks)，比如：
      a、Events (stream elements)
      b、State (fault tolerant, consistent)
      c、Timers (event time and processing time)
   ProcessFunction可以看作是一个可访问keyed state和定时器(timers)的FlatMapFunction
 网络流控
    网络流控的实现：
      01.静态限速 传统的做法可以在 Producer 端实现一个类似 Rate Limiter 这样的静态限流
      02.动态反馈（自动反压）的机制：

参考：

谷歌DataFlow编程模型以及Spark/Flink/StreamCQL的相关实现 https://blog.csdn.net/colorant/article/details/74923577
Apache Flink进阶（七）：网络流控及反压剖析 https://cloud.tencent.com/developer/news/467888
A Deep-Dive into Flink's Network Stack https://flink.apache.org/2019/06/05/flink-network-stack.html
http://www.liaojiayi.com/

他山之玉

面对未知概念的时候，我们首先根据已经理解的概念去理解，但是在理解达到了某种程度后，我们必须放弃对旧概念的依赖。进行类比是对相近的事务理解的途径，如果和我们所知道的不一样，怎么去理解，有待重新认识

blogroll

social