11、Flink连接器
1 Streaming Connector
1.1 预定义的source和sink
1.2 Bundled Connectors
1.3 Apache Bahir中的连接器
1.4 Async I/O
2 Flink Kafka Connector
3 Flink kafka Consumer
3.1 反序列化
3.2 消费起始位置
3.3 topic和partition动态发现
3.4 commit offset方式
3.5 Timestamp提取/Watermark生成
4. Flink kafka Producer
4.1 producer分区
4.2 容错
5 问题答疑
1 Streaming Connector
Flink是新一代流批统一的计算引擎，它需要从不同的第三方存储引擎中把数据读过来，进行处理，然后再写出到另外的存储引擎中。Connector的作用就相当于一个连接器，连接Flink计算引擎跟外界存储系统。Flink里有以下几种方式，当然也不限于这几种方式可以跟外界进行数据交换：
- Flink内部预定义了一些source和sink。
- Flink内部也提供了一些Boundled connectors。
- 可以使用第三方Apache Bahir项目中提供的连接器。
- 通过异步IO方式。
1.1 预定义的source和sink
Flink内部预定义了一部分source和sink。在这里分了几类。
基于文件的source和sink
如果从文本文件中读取数据可以直接使用：env.readTextFile(path)，也可以使用：env.readFile(fileInputFormat, path)，根据指定的fileInputFormat格式读取文件中的内容。
如果数据在Flink内进行了一系列的计算后把结果写出到文件里，也可以直接使用内部预定义的一些 sink，比如将结果以文本或csv格式写出到文件中，可以使用DataStream的writeAsText(path)和writeAsCsv(path)。
基于Socket的Source和Sink
提供Socket的hostname及port，可以直接用StreamExecutionEnvironment预定的接口socketTextStream创建基于Socket的source，从该socket中以文本的形式读取数据。当然如果想把结果写出到另外一个Socket，也可以直接调用DataStream writeToSocket。
基于内存Collections、Iterators的Source
可以直接基于内存中的集合或者迭代器，调用StreamExecutionEnvironment fromCollection、fromElements构建相应的source。结果数据也可以直接print、printToError的方式写出到标准输出或标准错误。
1.2 Bundled Connectors
Flink里已经提供了一些绑定的Connector，例如kafka source和sink，es sink等。读写kafka、es、rabbitMQ时可以直接使用相应connector的api即可。本文会详细介绍生产环境中最常用的kafka connector。
虽然该部分是Flink项目源代码里的一部分，但是真正意义上不算作Flink引擎相关逻辑，并且该部分没有打包在二进制的发布包里面。所以在提交Job时候需要注意，job代码jar包中一定要将相应的connetor相关类打包进去，否则在提交作业时就会失败，提示找不到相应的类，或初始化某些类异常。
1.3 Apache Bahir中的连接器
Apache Bahir最初是从Apache Spark中独立出来项目提供，以提供不限于Spark相关的扩展/插件、连接器和其他可插入组件的实现。通过提供多样化的流连接器（streaming connectors）和SQL数据源扩展分析平台的覆盖面。如有需要写到flume、redis的需求的话，可以使用该项目提供的connector。
1.4 Async I/O
流计算中经常需要与外部存储系统交互，比如需要关联MySQL中的某个表。一般来说，如果用同步I/O的方式，会造成系统中出现大的等待时间，影响吞吐和延迟。为了解决这个问题，异步I/O可以并发处理多个请求，提高吞吐，减少延迟。
Async的原理可参考官方文档：Asynchronous I/O for External Data Access
2 Flink Kafka Connector
本章重点介绍生产环境中最常用到的Flink kafka connector。使用Flink的同学，一定会很熟悉kafka，它是一个分布式的、分区的、多副本的、支持高吞吐的、发布/订阅消息系统。生产环境环境中也经常会跟kafka进行一些数据的交换，比如利用kafka consumer读取数据，然后进行一系列的处理之后，再将结果写出到kafka中。这里会主要分两个部分进行介绍，一是Flink kafka Consumer，一个是Flink kafka Producer。
首先看一个例子来串联下Flink kafka connector。代码逻辑里主要是从kafka里读数据，然后做简单的处理，再写回到kafka中。
分别用红框框出如何构造一个Source sink Function。Flink提供了现成的构造FlinkKafkaConsumer、FlinkKafkaProducer的接口，可以直接使用。这里需要注意，因为kafka有多个版本，多个版本之间的接口协议会不同。Flink针对不同版本的kafka有相应的版本的Consumer和Producer。例如：针对08、09、10、11版本，Flink对应的consumer分别是FlinkKafkaConsumer 08、09、010、011，producer也是。
3 Flink kafka Consumer
3.1 反序列化数据
因为kafka中数据都是以二进制byte形式存储的。读到Flink系统中之后，需要将二进制数据转化为具体的java、scala对象。具体需要实现一个schema类，定义如何序列化和反序列数据。反序列化时需要实现DeserializationSchema接口，并重写deserialize(byte[] message)函数，如果反序列化kafka中kv的数据，需要实现KeyedDeserializationSchema接口，并重写deserialize(byte[] messageKey, byte[] message, String topic, int partition, long offset)函数。
另外Flink中也提供了一些常用的序列化反序列化的schema类。例如，SimpleStringSchema，按字符串方式进行序列化、反序列化。TypeInformationSerializationSchema，它可根据Flink的TypeInformation信息来推断出需要选择的schema。JsonDeserializationSchema使用jackson反序列化json格式消息，并返回ObjectNode，可以使用.get(“property”) 方法来访问相应字段。
3.2 消费起始位置
如何设置作业从kafka消费数据最开始的起始位置，这一部分Flink也提供了非常好的封装。在构造好的 FlinkKafkaConsumer类后面调用如下相应函数，设置合适的起始位置。
- setStartFromGroupOffsets，默认策略，从group offset位置读取数据，group offset指的是kafka broker端记录的某个group的最后一次的消费位置。但是kafka broker端没有该group信息，会根据kafka的参数“auto.offset.reset”的设置来决定从哪个位置开始消费。
- setStartFromEarliest，从kafka最早的位置开始读取。
- setStartFromLatest，从kafka最新的位置开始读取。
- setStartFromTimestamp(long)，从时间戳大于或等于指定时间戳的位置开始读取。Kafka时间戳，是指kafka为每条消息增加另一个时戳。该时戳可以表示消息在proudcer端生成时的时间、或进入到kafka broker时的时间。
- setStartFromSpecificOffsets，从指定分区的offset位置开始读取，如指定的offsets中不存某个分区，该分区从group offset位置开始读取。此时需要用户给定一个具体的分区、offset的集合。
需要注意的是，因为Flink框架有容错机制，在作业故障的情况下，如果作业开启checkpoint，会从上一次checkpoint状态开始恢复。或者在停止作业的时候主动做savepoint，启动作业时从savepoint开始恢复。这两种情况下恢复作业时，作业消费起始位置是从之前保存的状态中恢复，与上面提到跟kafka这些单独的配置无关。
3.3 topic和partition动态发现
场景一，有一个Flink作业需要将五份数据聚合到一起，五份数据对应五个kafka topic，随着业务增长，新增一类数据，同时新增了一个kafka topic，如何在不重启作业的情况下作业自动感知新的topic？
场景二，作业从一个固定的kafka topic读数据，开始该topic有10个partition，但随着业务的增长数据量变大，需要对kafka partition个数进行扩容，由10个扩容到20。该情况下如何在不重启作业情况下动态感知新扩容的partition？
针对上面两种场景，首先需要在构建FlinkKafkaConsumer时properties中设置flink.partition-discovery.interval-millis参数为非负值，表示开启动态发现的开关，以及设置的时间间隔。此时FlinkKafkaConsumer内部会启动一个单独的线程定期去kafka获取最新的meta信息。
针对场景一，还需在构建FlinkKafkaConsumer时，topic的描述可以传一个正则表达式描述的pattern。每次获取最新kafka meta时获取正则匹配的最新topic列表。
针对场景二，设置前面的动态发现参数，在定期获取kafka最新meta信息时会匹配新的partition。为了保证数据的正确性，新发现的partition从最早的位置开始读取。
3.4 commit offset方式
Flink kafka consumer commit offset方式需要区分是否开启了checkpoint。
如果checkpoint关闭，commit offset要依赖于kafka客户端的auto commit。需设置enable.auto.commit，auto.commit.interval.ms参数到consumer properties，就会按固定的时间间隔定期auto commit offset到kafka。
如果开启checkpoint，这个时候作业消费的offset是Flink在state中自己管理和容错。此时提交offset到kafka，一般都是作为外部进度的监控，想实时知道作业消费的位置和lag情况。此时需要setCommitOffsetsOnCheckpoints为true来设置当checkpoint成功时提交offset到kafka。此时commit offset的间隔就取决于checkpoint的间隔，所以此时从kafka一侧看到的lag可能并非完全实时，如果checkpoint间隔比较长lag曲线可能会是一个锯齿状。
3.5 Timestamp提取/Watermark生成
当Flink作业内使用EventTime属性时，需要指定从消息中提取时戳和生成水位的函数。
FlinkKakfaConsumer构造的source后直接调用assignTimestampsAndWatermarks函数设置水位生成器的好处是此时是每个partition一个watermark assigner，如下图。source生成的时间戳为多个partition时间戳对齐后的最小时戳。此时在一个source读取多个partition，并且partition之间数据时戳有一定差距的情况下，因为在source端watermark在partition级别有对齐，不会导致数据读取较慢partition数据丢失。
4. Flink kafka Producer
4.1 producer分区
使用FlinkKafkaProducer往kafka中写数据时，如果不单独设置partition策略，会默认使用FlinkFixedPartitioner，该partitioner分区的方式是task所在的并发id对topic总partition数取余：parallelInstanceId % partitions.length。
- 此时如果sink为4，paritition为1，则4个task往同一个partition中写数据。但当sink task < partition个数时会有部分partition没有数据写入，例如sink task为2，partition总数为4，则后面两个partition将没有数据写入。
- 如果构建FlinkKafkaProducer 时，partition设置为null，此时会使用kafka producer默认分区方式，非key写入的情况下，使用round-robin的方式进行分区，每个task都会轮循的写下游的所有partition。该方式下游的partition数据会比较均衡，但是缺点是partition个数过多的情况下需要维持过多的网络连接，即每个task都会维持跟所有partition所在broker的连接。
4.2 容错
Flink kafka09、010版本下，通过setLogFailuresOnly为false，setFlushOnCheckpoint为true，能达到at-least-once语义。setLogFailuresOnly，默认为false，是控制写kafka失败时，是否只打印失败的log不抛异常让作业停止。setFlushOnCheckpoint，默认为true，是控制是否在checkpoint时flush数据到kafka，保证数据已经写到kafka。否则数据有可能还缓存在kafka客户端的buffer 中，并没有真正写出到kafka，此时作业挂掉数据即丢失，不能做到至少一次的语义。
Flink kafka011版本下，通过两阶段提交的sink结合kafka事务的功能，可以保证端到端精准一次。详细原理可以参考：https://www.ververica.com/blog/end-to-end-exactly-once-processing-apache-flink-apache-kafka
5 问题答疑
Q：在 Flink consumer 的并行度的设置：是对应 topic 的 partitions 个数吗？要是有多个主题数据源，并行度是设置成总体的 partitions 数吗？
A：这个并不是绝对的，跟 topic 的数据量也有关，如果数据量不大，也可以设置小于 partitions 个数的并发数。但不要设置并发数大于 partitions 总数，因为这种情况下某些并发因为分配不到 partition 导致没有数据处理。
Q：如果 partitioner 传 null 的时候是 round-robin 发到每一个 partition？如果有 key 的时候行为是 kafka 那种按照 key 分布到具体分区的行为吗？
A：如果在构造 FlinkKafkaProducer 时，如果没有设置单独的 partitioner，则默认使用 FlinkFixedPartitioner，此时无论是带 key 的数据，还是不带 key。如果主动设置 partitioner 为 null 时，不带 key 的数据会 round-robin 的方式写出，带 key 的数据会根据 key，相同 key 数据分区的相同的 partition，如果 key 为 null，再轮询写。不带 key 的数据会轮询写各 partition。
Q：如果 checkpoint 时间过长，offset 未提交到 kafka，此时节点宕机了，重启之后的重复消费如何保证呢？
A：首先开启 checkpoint 时 offset 是 Flink 通过状态 state 管理和恢复的，并不是从 kafka 的 offset 位置恢复。在 checkpoint 机制下，作业从最近一次 checkpoint 恢复，本身是会回放部分历史数据，导致部分数据重复消费，Flink 引擎仅保证计算状态的精准一次，要想做到端到端精准一次需要依赖一些幂等的存储系统或者事务操作。