flink checkpoint 重启_当Flink遇到Kafka - FlinkKafkaConsumer使用详解

Flink是新一代的流处理计算引擎。通过轻量级的checkpoint，Flink可以在高吞吐量的情况下保证exactly-once(这需要数据源能够提供回溯消费的能力)。Flink支持众多的source(从中读取数据)和sink(向其写入数据)，列表如下：

Kafka作为目前非常流行的消息中间件，它不仅能够提供极大的吞吐量，还能够配合Flink在消费端达到exactly-once。

本文将详细介绍如何配置Flink读取Kafka，运行机制和exactly-once是如何保证的，最后，还会给出监控Flink消费Kafka的方案。(注: 本文的使用的是Flink 1.3.1-release和 Kafka 0.8)

Flink 是通过Connector与具体的source 和 sink进行通信的，具体到Kafka 0.8，相应的Connector是 FlinkKafkaConsumer08和FlinkKafkaProducer08。

我们首先介绍FlinkKafkaConsumer08的配置：

一、 Kafka Consumer的配置

FlinkKafkaConsumer08可以消费一个或多个Kafka topic的数据，它的构造器需要接收以下参数:

1. topic名或 topic名的列表

2. 反序列化约束，以便于Flink决定如何反序列化从Kafka获得的数据

3. Kafka consumer的属性配置，下面两个属性配置是必须的:

· “zookeeper.connect” (Zookeeper servers的地址列表，以逗号分隔)

· “group.id” (consumer group)

· “bootstrap.servers” (Kafka brokers的地址列表，以逗号分隔)

示例代码：

以下几个参数是需要我们重点关注的。

(一) 反序列化shema

Flink Kafka Consumer 需要知道如何将来自Kafka的二进制数据转换为Java/Scala对象。DeserializationSchema接口允许程序员指定这个序列化的实现。该接口的 T deserialize(byte[]message) 会在收到每一条Kafka的消息的时候被调用。

我们通常会实现 AbstractDeserializationSchema，它可以描述被序列化的Java/Scala类型到Flink的类型(TypeInformation)的映射。如果用户的代码实现了DeserializationSchema，那么就需要自己实现getProducedType(...) 方法。

为了方便使用，Flink提供了一些已实现的schema:

1. TypeInformationSerializationSchema (andTypeInformationKeyValueSerializationSchema) ，他们会基于Flink的TypeInformation来创建schema。这对于那些从Flink写入，又从Flink读出的数据是很有用的。这种Flink-specific的反序列化会比其他通用的序列化方式带来更高的性能。

2. JsonDeserializationSchema (andJSONKeyValueDeserializationSchema) 可以把序列化后的Json反序列化成ObjectNode，ObjectNode可以通过objectNode.get(“field”).as(Int/String/…)() 来访问指定的字段。

3. SimpleStringSchema可以将消息反序列化为字符串。当我们接收到消息并且反序列化失败的时候，会出现以下两种情况: 1) Flink从deserialize(..)方法中抛出异常，这会导致job的失败，然后job会重启；2) 在deserialize(..) 方法出现失败的时候返回null，这会让Flink Kafka consumer默默的忽略这条消息。请注意，如果配置了checkpoint 为enable，由于consumer的失败容忍机制，失败的消息会被继续消费，因此还会继续失败，这就会导致job被不断自动重启。

(二) Kafka Consumers 起始offset配置

FlinkKafkaConsumer 允许我们配置Kafka partition被消费的offset的起始位，示例代码如下：