Apache Flink源码解析之stream-source

原创 2016年05月05日 23:22:13

今天我们来解读一下Flink stream里的source模块。它是整个stream的入口,也是我们了解其流处理体系的入口。

SourceFunction

SourceFunction是所有stream source的根接口。

它继承自一个标记接口(空接口)Function

SourceFunction定义了两个接口方法:

  • run : 启动一个source,即对接一个外部数据源然后emit元素形成stream(大部分情况下会通过在该方法里运行一个while循环的形式来产生stream)。
  • cancel : 取消一个source,也即将run中的循环emit元素的行为终止。

正常情况下,一个SourceFunction实现这两个接口方法就可以了。其实这两个接口方法也固化了一种实现模板

比如,实现一个XXXSourceFunction,那么大致的模板是这样的:

private volatile boolean isRunning = true;

    @Override
    public void run(SourceContext<T> ctx) throws Exception {
        while (isRunning && otherCondition == true) {
            ctx.collect(getElement());
        }
    }

    @Override
    public void cancel() {
        isRunning = false;
    }

SourceContext

Flink将Source的运行机制跟其如何emit元素进行了分离。具体如何emit元素,取决于另外一个独立的接口SourceContextSourceFunction以内部接口的方式定义了该上下文接口对象,将具体的实现抛给具体的sourceFunction。该接口中定义了emit元素的接口方法:

  • collect : 从source emit一个元素,该元素的时间戳被自动设置为本地时钟(System#currentTimeMillis()),这种由当前source自动追加的时间戳,在Flink里称之为Ingress Time(即摄入时间)。
  • collectWithTimestamp : 根据用户提供的自定义的时间戳emit一个元素,这种被称之为Event Time(即用户自行设置的事件时间)。
  • emitWatermark : 手动发射一个Watermark

这里有几个时间概念可参考我之前的文章:http://vinoyang.com/2016/05/02/flink-concepts/#时间

Watermark:Flink用Watermark来对上面的Event Time类型的事件进行窗口处理。所谓的Watermark是一个时间基准。WaterMark包含一个时间戳,Flink使用WaterMark标记所有小于该时间戳的消息都已流入,Flink的数据源在确认所有小于某个时间戳的消息都已输出到Flink流处理系统后,会生成一个包含该时间戳的WaterMark,插入到消息流中输出到Flink流处理系统中,Flink操作符按照时间窗口缓存所有流入的消息,当operator处理到WaterMark时,它对所有小于该WaterMark时间戳的时间窗口数据进行处理并发送到下一个operator节点,然后也将WaterMark发送到下一个operator节点。

内置的SourceFunction

source相关的完整类图如下:

flink-stream-source_class-diagram

RichSourceFunction

一个抽象类,继承自AbstractRichFunction。为实现一个Rich SourceFunction提供基础能力(其实所谓的Rich,主要是提供某种范式或者模板帮助你完成一部分基础实现)。该类的子类有两个,不过他们仍然是抽象类,只是在此基础上提供了更具体的实现:

  • MessageAcknowledgingSourceBase :它针对的是数据源是消息队列的场景并且提供了基于ID的应答机制。
  • MultipleIdsMessageAcknowledgingSourceBase : 在MessageAcknowledgingSourceBase的基础上针对ID应答机制进行了更为细分的处理,支持两种ID应答模型:session idunique message id

ParallelSourceFunction

该接口只是个标记接口,用于标识继承该接口的Source都是并行执行的。其直接实现类是RichParallelSourceFunction,它是一个抽象类并继承自AbstractRichFunction(从名称可以看出,它应该兼具richparallel两个特性,这里的rich体现在它定义了openclose这两个方法)。

继承RichParallelSourceFunction的那些SourceFunction意味着它们都是并行执行的并且可能有一些资源需要open/close,Flink提供了这么几个实现:

  • FileSourceFunction : 以文件为数据源的Source,它根据给定的InputFormat作为数据源记录的生产器(它可以接收一个file path来基于文件生产记录),根据给定的TypeInformation来产生序列化器,再结合内部创建的splitIterator实现了一个基于文件的sourceFunction。
  • ConnectorSource : 抽象类,没有具体的实现。通过其构造器注入了一个属性DeserializationSchema,该属性是一个协议接口,用于定义如何将二进制数据反序列化为Java/Scala对象。
  • StatefulSequenceSource :有状态的序列Source。它接收startend作为一个发射序列的区间,然后根据一定的算法算得需要发射的时间间隔,并保证区间内的元素送达具有exactly once的强一致性,具体的计算方式需要结合当前task的subtask的数量以及当前subtask在集合中的索引计算得出。
  • FromSplittableIteratorFunction :根据给定的SplittableIterator(它是一个全局的iterator)结合当前task运行时subtask的数量,以及该subtask在所有subtask中的序号计算出分区(partition)从而产生一个细分的Iterator。通过Iterator迭代来发射元素。

FileMonitoringFunction

该Source是以监控给定path位置的文件为手段,根据给定的interval作为时间间隔,emit的内容依赖监控文件的变。Flink为这种形式的Source提供了三种watchtype :

    public enum WatchType {
        ONLY_NEW_FILES,                 //仅关注新文件产生
        REPROCESS_WITH_APPENDED,    //当有文件产生变更,该文件的所有内容都需要被重新处理
        PROCESS_ONLY_APPENDED       //当有文件产生变更,只有变更的内容需要被处理
    }

该类型的Source始终发射的是一个三元组(Tuple3),它包含三个元素:

  • filePath : 标识文件路径
  • offset : 偏移量
  • fileSize : 文件大小

watchtype的不同主要影响发射元素的内容。当WatchType的类型为ONLY_NEW_FILESREPROCESS_WITH_APPENDED类型时,offset会被设置为0,fileSize被设置为-1。而WatchType类型为PROCESS_ONLY_APPENDED,则三个值都为其对应的真实值。

SocketTextStreamFunction

根据给定的hostnameport,以socket的方式进行通信并获取数据,以delimiter参数给定的字符作为终止标识符。

FromIteratorFunction

该Source接收一个迭代器,然后在发射循环体中,依次迭代发射数据。

FromElementsFunction

该Source接收一个元素迭代器(一组元素的集合),以Flink的类型序列化机制将其序列化为二进制数据,然后在发射元素的循环体中,进行反序列化为初始类型,再发射数据。

这里先序列化为二进制,再从二进制反序列化为最初的对象类型。不是特别容易理解,乍一看多此一举,让人匪夷所思。其实,这么做是有原因的,是因为Flink的序列化机制是其自定义的,并且跟其自主管理内存紧密联系在一起(想了解其自主内存管理的可参看我之前的系列文章)。而自主内存管理又涉及到二进制数据的存储。FromElementsFunction支持从某个check point部分恢复,所以必须先还原其原先的存储位置(通过序列化),然后跳过不需要emit的元素,然后再发射需要发射的元素(将这些元素反序列化)。

常见连接器中的Source

Flink自身提供了一些针对第三方主流开源系统的连接器支持,它们有:

  • elasticsearch
  • flume
  • kafka(0.8/0.9版本)
  • nifi
  • rabbitmq
  • twitter

这些连接器有些可以同时作为sourcesink。因为我们今天的主题是source,所以我们先来看看以上这些被支持的连接器它们的source都是继承自刚刚我们谈到的哪些接口或者类。

  • kafka : RichParallelSourceFunction
  • nifi : RichParallelSourceFunction
  • rabbitmq : MultipleIdsMessageAcknowledgingSourceBase(因为rabbitmq具备非常成熟的ack机制,所以继承这个类是顺其自然的)

小结

这篇文章我们主要谈及了Flink的stream source相关的设计、实现。当然这个主题还没有完全谈完,还会有后续篇幅继续解读。


微信扫码关注公众号:Apache_Flink

apache_flink_weichat

版权声明:本文为博主原创文章,未经博主允许不得转载。

相关文章推荐

Flink之CEP案例分析-网络攻击检测

上一篇我们介绍了Flink CEP的API,这一篇我们将以结合一个案例来练习使用CEP的API编写应用程序,以强化对API的理解。所选取的案例是对网络遭受的潜在攻击进行检测并给出告警。当下互联网安全形...

Apache Flink fault tolerance源码剖析(一)

因某些童鞋的建议,从这篇文章开始结合源码谈谈Flink Fault Tolerance相关的话题。上篇官方介绍的翻译是理解这个话题的前提,所以如果你想更深入得了解Flink Fault Toleran...

02_Flink Streaming SourceFunction

env对象的addSource(Source)。需要传入一个Source对象。这个对象作为接入数据源的接口 package com.alibaba.flink.train.streaming; im...

Flink流计算编程--在WindowedStream中体会EventTime与ProcessingTime

Flink DataStream EventTime
  • lmalds
  • lmalds
  • 2016-06-17 14:46
  • 4824

Flink学习笔记 --- WaterMark机制 and low WaterMark 保序机制

Flink学习笔记 --- 实时数据保序功能(WaterMark机制)

回顾2016--Apache Flink流处理在生产中的实践

Flink

Flink Event Time Processing and Watermarks

由于之前一直看Flink官方文档学习Flink,但是由于看到WaterMark时候弄得满头雾水,便开始到处搜寻WaterMark的资料,在国外网站找到一篇很容易理解WaterMark的博文,再次分享一...
  • Dax1n
  • Dax1n
  • 2017-05-11 08:43
  • 345

Flink流计算编程--状态与检查点

Flink 流计算 快照 状态
  • lmalds
  • lmalds
  • 2016-07-21 18:21
  • 3407

Flink 两种发送自定义的timestamp以及watermark的方式

Flink提供了抽象类来让开发者赋值自己的时间戳并发送他们自己的Watermark。更具体来说,开发者需要依照不同用例情况来实现接口AssignerWithPeriodicWatermarks或接口A...

Flink如何应对背压问题

经常有人会问Flink如何处理背压问题。其实,答案很简单:Flink没用使用任何通用方案来解决这个问题,因为那根本不需要那样的方案。它利用自身作为一个纯数据流引擎的优势来优雅地响应背压问题。
内容举报
返回顶部
收藏助手
不良信息举报
您举报文章:深度学习:神经网络中的前向传播和反向传播算法推导
举报原因:
原因补充:

(最多只允许输入30个字)