flink 配置kafkadebug级别日志 flink kafka exactly once

转载

墨香四溢 2024-03-17 13:13:13

文章标签 flink kafka big data 协调者检查点 文章分类 架构后端开发

1 引言

2 2PC协议

2.1 投票阶段

2.2 执行阶段

2.3 优缺点

3 EOS原理

3.1 幂等 Sink

3.2 事务性 Sink

4 EOS实现

4.1 开始事务

4.2 预提交阶段

4.3 提交阶段

4.4 终止事务

1 引言

在分布式存储或者计算系统中，常见的消息可靠性有 At Most Once、At Least Once 和 Exactly Once 三种。严格来说只有 Exactly Once 满足确定性的要求，但如果整个业务逻辑是幂等的，基于At Least Once 也可以达到结果的确定性。

实时计算的 Exactly Once 通常指端到端的 Exactly Once，保证输出到下游系统的数据和上游的数据是一致的，没有重复计算或者数据丢失。要达到这点，需要分别实现读取数据源（Source 端）的 Exactly Once、计算的 Exactly Once 和输出到下游系统（Sink 端）的 Exactly Once。

其中前面两个都比较好保证，因为 Flink 应用出现异常会自动恢复至最近一个成功 checkpoint，Pull-Based 的 Source 的状态和 Flink 内部计算的状态都会自动回滚到快照时间点，而问题在于 Push-Based 的 Sink 端。Sink 端是否能顺利回滚依赖于外部系统的特性，通常来说需要外部系统支持事务，然而不少大数据组件对事务的支持并不是很好，即使是实时计算最常用的 Kafka 也直到 2017 年的 0.11 版本才支持事务，更多的组件需要依赖各种 trick 来达到某种场景下的 Exactly-Once。

2 2PC协议

两阶段提交：在分布式系统中，为了让每个节点都能够感知到其他节点的事务执行状况，需要引入一个中心节点来统一处理所有节点的执行逻辑，这个中心节点叫做协调者（coordinator），被中心节点调度的其他业务节点叫做参与者（participant）。

顾名思义，2PC将分布式事务分成了两个阶段，两个阶段分别为提交请求（投票）和提交（执行）。协调者根据参与者的响应来决定是否需要真正地执行事务，具体流程如下。

2.1 投票阶段

协调者向所有参与者发送prepare请求与事务内容，询问是否可以准备事务提交，并等待参与者的响应。
参与者执行事务中包含的操作，并记录undo日志（用于回滚）和redo日志（用于重放），但不真正提交。
参与者向协调者返回事务操作的执行结果，执行成功返回yes，否则返回no。

2.2 执行阶段

分为成功与失败两种情况。

若所有参与者都返回yes，说明事务可以提交：

协调者向所有参与者发送commit请求。
参与者收到commit请求后，将事务真正地提交上去，并释放占用的事务资源，并向协调者返回ack。
协调者收到所有参与者的ack消息，事务成功完成。

若有参与者返回no或者超时未返回，说明事务中断，需要回滚：

协调者向所有参与者发送rollback请求。
参与者收到rollback请求后，根据undo日志回滚到事务执行前的状态，释放占用的事务资源，并向协调者返回ack。
协调者收到所有参与者的ack消息，事务回滚完成。

下图分别示出这两种情况。

提交成功情况：

flink 配置kafkadebug级别日志 flink kafka exactly once_协调者

提交失败情况：

flink 配置kafkadebug级别日志 flink kafka exactly once_检查点_02

2.3 优缺点

2PC的优点在于原理非常简单，容易理解及实现。缺点主要有3个，列举如下：

协调者存在单点问题。如果协调者挂了，整个2PC逻辑就彻底不能运行。
执行过程是完全同步的。各参与者在等待其他参与者响应的过程中都处于阻塞状态，大并发下有性能问题。
仍然存在不一致风险。如果由于网络异常等意外导致只有部分参与者收到了commit请求，就会造成部分参与者提交了事务而其他参与者未提交的情况。

3 EOS原理

Flink作为流式处理引擎，依托检查点机制和轻量级分布式快照算法ABS保证了内部状态的exactly once。而端到端的exactly once语义是输入、处理逻辑、输出三部分协同作用的结果，要实现这种情况下的精确一次输出，需要施加以下两种限制之一：幂等性写入（idempotent write）、事务性写入（transactional write）。

3.1 幂等 Sink

幂等性是分布式领域里十分有用的特性，它意味着相同的操作执行一次和执行多次可以获得相同的结果，因此 at-least-once 自然等同于 exactly-once。如此一来，在从快照恢复的时候幂等 sink 便不需要对外部系统撤回已发消息，相当于回避了外部系统的状态回滚问题。比如写入 KV 数据库的 sink，由于插入一行的操作是幂等的，因此 sink 可以无状态的，在错误恢复时也不需要关心外部系统的状态。然而幂等 sink 的适用场景依赖于业务逻辑，如果下游业务本来就无法保证幂等性，这时就需要应用事务性 sink。

3.2 事务性 Sink

事务性 sink 顾名思义类似于传统 DBMS 的事务，将一系列（一般是一个 checkpoint 内）的所有输出包装为一个逻辑单元，理想的情况下提供 ACID 的事务保证。之所以说是“理想的情况下”，主要是因为 sink 依赖于目标输出系统的事务保证，而分布式系统对于事务的支持并不一定很完整，比如 HBase 就不支持跨行事务，再比如 HDFS 等文件系统是不提供事务的，这种情况下 sink 只可以在客户端的基础上再包装一层来尽最大努力地提供事务保证。

然而仅有下游系统本身提供的事务保证对于 exactly-once sink 来说是不够的，因为同一个 sink 的子任务（subtask）会有多个，对于下游系统来说它们是处在不同会话和事务中的，并不能保证操作的原子性，因此 exactly-once sink 还需要实现分布式事务来达到所有 subtask 的一致 commit 或 rollback。由于 sink 事务生命周期是与 checkpoint 一一对应的，或者说 checkpoint 本来就是实现作业状态持久化的分布式事务，sink 的分布式事务也理所当然可以通过 checkpoint 机制提供的 hook 来实现。

4 EOS实现

在Spark Streaming中，要实现事务性写入完全靠用户自己，框架本身并没有提供任何实现。但是在Flink中提供了基于2PC的SinkFunction，名为TwoPhaseCommitSinkFunction，帮助我们做了一些基础的工作。

flink 配置kafkadebug级别日志 flink kafka exactly once_检查点_03

Flink Checkpoint 提供给算子的 hook 有 CheckpointedFunction 和 CheckpointListener 两个，前者在算子进行 checkpoint 快照时被调用，后者在 checkpoint 成功后调用。为了简单起见 Flink 结合上述两个接口抽象出 exactly-once sink 的通用逻辑抽象 TwoPhaseCommitSinkFunction 接口，从命名即可看出这是对两阶段提交协议的一个实现，其主要方法如下:

beginTransaction()：开始一个事务，返回事务信息的句柄。在有新数据到达并且当前事务为空时调用。
preCommit()：预提交（即提交请求）阶段的逻辑。在 sink 算子进行快照的时候调用。
commit()：正式提交阶段的逻辑。在作业的 checkpoint 完成时调用。
abort()：取消事务。在作业 checkpoint 失败的时候调用。

下面以Flink与Kafka的集成来说明2PC的具体流程。注意这里的Kafka版本必须是0.11及以上，因为只有0.11+的版本才支持幂等producer以及事务性，从而2PC才有存在的意义。Kafka内部事务性的机制如下框图所示（详细实现机制自行查阅）。

flink 配置kafkadebug级别日志 flink kafka exactly once_flink_04

4.1 开始事务

FlinkKafkaProducer011类实现的beginTransaction()方法。当要求exactly once语义时，会调用createTransactionalProducer()生成包含事务ID的producer。

@Override
protected KafkaTransactionState beginTransaction() throws FlinkKafka011Exception {
    switch (semantic) {
        case EXACTLY_ONCE:
            FlinkKafkaProducer<byte[], byte[]> producer = createTransactionalProducer();
            producer.beginTransaction();
            return new KafkaTransactionState(producer.getTransactionalId(), producer);
        case AT_LEAST_ONCE:
        case NONE:
            // Do not create new producer on each beginTransaction() if it is not necessary
            final KafkaTransactionState currentTransaction = currentTransaction();
            if (currentTransaction != null && currentTransaction.producer != null){
                return new KafkaTransactionState(currentTransaction.producer);
            }
            return new KafkaTransactionState(initNonTransactionalProducer(true));
        default:
            throw new UnsupportedOperationException("Not implemented semantic");
    }
}

beginTransaction()是在TwoPhaseCommitSinkFunction的initializeState与snapshotState阶段被调用用于创建下一个新事务。

4.2 预提交阶段

FlinkKafkaProducer011.preCommit()方法的实现很简单。其中的flush()方法实际上是代理了KafkaProducer.flush()方法。

@Override
protected void preCommit(KafkaTransactionState transaction) throws FlinkKafka011Exception {
    switch (semantic) {
        case EXACTLY_ONCE:
        case AT_LEAST_ONCE:
            flush(transaction);
            break;
        case NONE:
            break;
        default:
            throw new UnsupportedOperationException("Not implemented semantic");
    }
    checkErroneous();
}

/**
* Flush pending records.
*/
private void flush(KafkaTransactionState transaction) throws FlinkKafka011Exception{
    if (transaction.producer != null) {
        transaction.producer.flush();
    }
    long pendingRecordsCount = pendingRecords.get();
    if (pendingRecordsCount != 0) {
        throw new IllegalStateException("Pending record count must be zero at this point: " + pendingRecordsCount);
    }

    // if the flushed requests has errors, we should propagate it also and fail the checkpoint
    checkErroneous();
}

preCommit()方法在TwoPhaseCommitSinkFunction的snapshotState阶段被调用。从前面类图可知，TwoPhaseCommitSinkFunction继承了CheckpointedFunction接口，所以2PC是与检查点机制一同发挥作用的。结合Flink检查点的原理，可以用下图来形象地表示预提交阶段的流程。

flink 配置kafkadebug级别日志 flink kafka exactly once_协调者_05

一旦开启了checkpoint功能，JobManager就在数据流中源源不断地打入屏障（barrier），作为检查点的界限。屏障随着算子链向下游传递，每到达一个算子都会触发将状态快照写入状态后端的动作。当屏障到达Kafka sink后，通过KafkaProducer.flush()方法刷写消息数据，但还未真正提交。

4.3 提交阶段

FlinkKafkaProducer011.commit()方法实际上是代理了KafkaProducer.commitTransaction()方法，正式向Kafka提交事务。

@Override
protected void commit(KafkaTransactionState transaction) {
    if (transaction.isTransactional()) {
        try {
            transaction.producer.commitTransaction();
        } finally {
            recycleTransactionalProducer(transaction.producer);
        }
    }
}

该方法的调用点位于TwoPhaseCommitSinkFunction的notifyCheckpointComplete阶段。顾名思义，当所有检查点都成功完成之后，会回调这个方法。

@Override
public final void notifyCheckpointComplete(long checkpointId) throws Exception {
    Iterator<Map.Entry<Long, TransactionHolder<TXN>>> pendingTransactionIterator = pendingCommitTransactions.entrySet().iterator();
    checkState(pendingTransactionIterator.hasNext(), "checkpoint completed, but no transaction pending");
    Throwable firstError = null;
 
    while (pendingTransactionIterator.hasNext()) {
        Map.Entry<Long, TransactionHolder<TXN>> entry = pendingTransactionIterator.next();
        Long pendingTransactionCheckpointId = entry.getKey();
        TransactionHolder<TXN> pendingTransaction = entry.getValue();
        if (pendingTransactionCheckpointId > checkpointId) {
            continue;
        }
 
        LOG.info("{} - checkpoint {} complete, committing transaction {} from checkpoint {}",name(), checkpointId, pendingTransaction,pendingTransactionCheckpointId);
 
        logWarningIfTimeoutAlmostReached(pendingTransaction);
        try {
            commit(pendingTransaction.handle);
        } catch (Throwable t) {
            if (firstError == null) {
                firstError = t;
            }
        }
 
        LOG.debug("{} - committed checkpoint transaction {}", name(), pendingTransaction);
 
        pendingTransactionIterator.remove();
    }
 
    if (firstError != null) {
        throw new FlinkRuntimeException("Committing one of transactions failed, logging first encountered failure",firstError);
    }
}

该方法每次从正在等待提交的事务句柄中取出一个，校验它的检查点ID，并调用commit()方法提交之。这阶段的流程可以用下图来表示。

flink 配置kafkadebug级别日志 flink kafka exactly once_检查点_06

只有在所有检查点都成功完成这个前提下，写入才会成功。这符合前文所述2PC的流程，其中JobManager为协调者，各个算子为参与者（不过只有sink一个参与者会执行提交）。一旦有检查点失败，notifyCheckpointComplete()方法就不会执行，作业会从最近成功的checkpoint中进行恢复。

4.4 终止事务

如果提交事务阶段不成功的话，最终会调用abort()方法回滚事务。

@Override
protected void abort(KafkaTransactionState transaction) {
    if (transaction.isTransactional()) {
        transaction.producer.abortTransaction();
        recycleTransactionalProducer(transaction.producer);
    }
}

事务回滚是在initializeState和close阶段调用。

简单总结一下TwoPhaseCommitSinkFunction的4个方法及其被调用的时机：

本文章为转载内容，我们尊重原作者对文章享有的著作权。如有内容错误或侵权问题，欢迎原作者联系我们进行内容更正或删除文章。