Flink 实战(十二) Flink 多Sink的数据一致性验证

Flink

HbaseSink1

kafkaSink2

这种场景下面当hbase写入的失败的时候，不影响kakfa的写入。
如何保证hbase和kafka都写入成功呢？

原生无法保证.

Data Source 和 Sink 的容错保证

当程序出现错误的时候，Flink 的容错机制能恢复并继续运行程序。这种错误包括机器硬件故障、网络故障、瞬态程序故障等等。

只有当 source 参与了快照机制的时候，Flink 才能保证对自定义状态的精确一次更新。下表列举了 Flink 与其自带连接器的状态更新的保证。

请阅读各个连接器的文档来了解容错保证的细节。

Source	Guarantees	Notes
Apache Kafka	exactly once	根据你的版本用恰当的 Kafka 连接器 v011
AWS Kinesis Streams	exactly once
RabbitMQ	at most once (v 0.10) / exactly once (v 1.0)
Twitter Streaming API	at most once
Google PubSub	at least once
Collections	exactly once
Files	exactly once
Sockets	at most once

为了保证端到端 exactly-once的数据交付（在 exactly-once的状态语义上更进一步），sink需要参与 checkpointing 机制。

下表列举了 Flink 与其自带 sink 的交付保证（假设 exactly-once状态更新）。

Sink	Guarantees	Notes
HDFS BucketingSink	exactly once	实现方法取决于 Hadoop 的版本
Elasticsearch	at least once
Kafka producer	at least once / exactly once	当使用事务生产者时，保证精确一次 (v 0.11+)
Cassandra sink	at least once / exactly once	只有当更新是幂等时，保证精确一次
AWS Kinesis Streams	at least once
File sinks	exactly once
Socket sinks	at least once
Standard output	at least once
Redis sink	at least once

##exactly_once 语义与实现机制

为了实现 EXACTLY ONCE 语义，Flink 通过一个 input buffer 将在对齐阶段收到的数据缓存起来，等对齐完成之后再进行处理。

而对于 AT LEAST ONCE 语义，无需缓存收集到的数据，会对后续直接处理，所以导致 restore 时，数据可能会被多次处理。

需要特别注意的是，Flink 的 Checkpoint 机制只能保证 Flink 的计算过程可以做到 EXACTLY ONCE，端到端的 EXACTLY ONCE 需要 source 和 sink 支持。 实现TwoPhaseCommitSinkFunction