六年前提起实时流式计算,熟悉的同窗会想起Storm,三年前提起,你们应该会想到Spark Streaming,如今再提起那无疑是Flink了。可见开源世界技术的迭代是飞速的,稍不留神就落伍了,因此咱们要不停地学习,跟着技术的浪潮上下翻滚,可是你学习的速度也没法老是跟得上技术的更替,因此年纪大了依旧可能被淘汰,前浪老是会拍打到沙滩上,“你有没有这种感受,好像一辈子都身不禁己”。算法
好了先不思考人生了,言归正传。
咱们先把 storm/spark/flink 这些花里胡哨的技术都抛开,这些我以后的文章会详细讲,如今就说说实时流式计算自己。流式计算有什么用呢?实际场景会告诉你:架构
流处理适用场景仍是很丰富的,它最大的特色就是及时,试想一些,没有下面的这些流式计算系统,公司会损失多少MONEY:学习
时间对于批计算来讲好像没有什么特别的,就是一个字段而已,可是流式计算里,除了字段里的那个时间(专业点,咱们称这个时间为事件时间event-time)还有一个数据到达的时间及处理系统的当前时间(处理时间process-time)。大数据
那问题来了,为何要管这个处理时间?由于数据会有延迟,你处理的时间批次里,可能会有好久以前的数据延迟到了如今,也有可能如今的数据没有及时到达致使缺数。spa
不知道看到这里你们会不会想到大数据比较经常使用的Lambda架构,先提供时效性高准确性较低的结果,而后对以前的数据作矫正,保证最终正确性(固然前提条件是批处理做业启动时,须要的数据应该已经所有到达了)。对于这个问题的解决办法实际上是和Lambda架构相似的,后面我会细说。orm
看上面的文字描述可能会有点抽象,咱们先来看看下面这幅图,横轴为事件时间,纵轴为处理时间,圈起来的数字表明真实的数据,它们分别都有事件时间和处理时间,在二者相同的理想状况下,就如同下面浅色的虚线是一条直线,这样是最好处理的,可是实际状况倒是很曲折的,如深色的虚线,咱们把虚线称为水位线,水位线是根据必定算法根据最近处理的事件的事件时间估算出来的,能够做为事件的触发的一个参考项。blog
上面提到了事件时间和处理时间,写过SparkStreaming的同窗应该知道它有一个处理时间的窗口,就是说能够对某个时间窗口内的数据进行聚合或者其余操做,可是这个时间窗口的时间是基于处理时间的,一样会有上面提到的问题,数据延迟了怎么办?事件
那么理所固然会有人提出基于事件时间的窗口,这个处理方式就是《Google:DataFlow》中提出来的,spark和flink后来都有了相应的工程实现。spark
所谓触发(Triggers)即时间窗口结束后对数据的处理方式。咱们直接来看《DataFlow》中的几种触发机制。io
撤回的操做适用于数据处理管道有多个串行的 GroupByKeyAndWindow 场景,撤回是必要的,由于同一个窗口的不一样触发计算结果可能在下游会被分组到不一样键中去,这句话是关键,不知道你们有没有理解,简单地说就是,触发时间的变化可能会致使这条延迟数据被分配到的组的变化,从而致使后续的聚合计算不许确,因此须要把以前的数据撤回,带上这条数据一块儿再作一次GroupByKeyAndWindow。
这一篇提到的不少概念和名字不少同窗可能一时会比较难消化,确实比较抽象,因此不要紧,后面讲到flink的时候会举具体的例子给你们看,这一篇只是和你们介绍下流式计算以及在流式计算中你须要重点关注的几个点:时间/窗口/触发,记住这三个词也是一个收获。
另外,你们有精力有时间有兴趣的话,推荐你们好好看看Google在2015年发布的一篇关于实时流式计算的论文,《The Dataflow Model》,这篇论文催生了spark的structed streaming以及给了当初默默无闻的flink成就如今辉煌的灵感。用词好像有点浮夸了,可是它确实是在流式计算领域颇有指导性意义的一篇论文。
以为有价值请关注 ▼