【持续更新】重要FLIP总结

news/2024/9/27 17:29:26

FLIP-27: Refactor Source Interface

流批一体API

1、解耦SplitEnumerator与SplitReader

SplitEnumerator：发现并分配splits（比如files/kafka_partitions）

SourceReader：从splits里实际读取数据

这样就使不同的splits分配策略与读取动作解耦，可分别封装成两个组件，Source接口即变成构建SplitEnumerator、SourceReader的工厂。而且降低chkpt锁竞争

2、流批统一

每个Source实例都可作为batch、stream source，Boundedness有界性作为Source实例的内在属性，只有SplitEnumerators应该知道有界性，reader不用知道

FileSource：对于有界输入使用SplitEnumerator一次性枚举给定目录下的所有文件，对于流输入使用SplitEnumerator定期枚举给定目录下的所有文件并分配新文件

KafkaSource：对于有界输入使用SplitEnumerator找到所有分区并将每个分区的最新offset作为split的end offset；对于无界输入使用SplitEnumerator找到所有分区且将LONG_MAX作为split的end offset，若开启自动发现分析则定期枚举所有分区

3、顶层公用接口

Source - A factory style class that helps create SplitEnumerator and SourceReader at runtime. 也感知Boundedness
SourceSplit - An interface for all the split types.
SplitEnumerator - Discover the splits and assign them to the SourceReaders
SplitEnumeratorContext - Provide necessary information to the SplitEnumerator to assign splits and send custom events to the the SourceReaders.
SplitAssignment - A container class holding the source split assignment for each subtask.
SourceReader - Read the records from the splits assigned by the SplitEnumerator.
SourceReaderContext - Provide necessary function to the SourceReader to communicate with SplitEnumerator.
SourceOutput - A collector style interface to take the records and timestamps emit by the SourceReader.
WatermarkOutput - An interface for emitting watermark and indicate idleness of the source.
Watermark - A new Watermark class will be created in the package org.apache.flink.api.common.eventtime. This class will eventually replace the existing Watermark in org.apache.flink.streaming.api.watermark. This change allows flink-core to remain independent of other modules. Given that we will eventually put all the watermark generation into the Source, this change will be necessary. Note that this FLIP does not intended to change the existing way that watermark can be overridden in the DataStream after they are emitted by the source.

FLIP-147: Support Checkpoints After Tasks Finished

流批一体runtime

在流批一体场景下，若runtime层不支持部分task结束后继续做chkpt，则会有以下问题：

有界与无界输入混合的情况下，一旦发生failover会产生较大的回退开销
两阶段提交的sink依赖于chkpt实现端到端一致性，若结束的这部分task不提交chkpt会无法提交数据，无法保证一致性

对chkpt整体流程进行修改，首先将那些前序任务都已经终止但本身尚未终止的 task 识别为新的source task，然后从这些task开始发送barrier进行正常的chkpt操作。由于 checkpoint 中 state 是以 jobvertext 为单位进行记录的，因此如果一个 jobvertext 中所有 task 都已结束，会在它的状态中记录一个特殊的标记 ver，如果是部分 task 结束，会保留所有正在运行的 task state 作为 jobvertext state，而所有其他 jobvertext 的处理流程与正常 checkpoint 保持一致。作业发生 failover 重启之后，会跳过完全终止的 jobvertext，对其他的 task 的处理逻辑与正常的处理逻辑保持一致的

为了支持drain模式下也能等待savepoint完成、或正常结束的任务等待下一个chkpt完成后再结束，先通知所有 task EndOfDataEvent 进行结束但不关闭网络链接，等所有 task 结束之后，若是drain模式还要再发起一个 savepoint 操作，然后等待下一个chkpt或savepoint，等到之后再接收EndOfPartitionEvent关闭网络链接，就能实现所有 task 等待最后同一个 savepoint 或 chkpt而结束

对之前比较有歧义的 close() 和 dipose() 操作进行了重命名，分别改成了 finish() 和 close()，其中 finish() 只会在任务正常结束时进行调用，而 close() 会在作业正常结束和异常结束的时候都进行调用

FLIP-150: Introduce Hybrid Source

流批一体API

FLIP-95: New TableSource and TableSink interfaces

流批一体runtime

公用接口

Main interfaces:

DynamicTableSource
ScanTableSource extends DynamicTableSource
LookupTableSource extends DynamicTableSource
DynamicTableSink

Corresponding factory interfaces:

Factory
DynamicTableFactory extends Factory
DynamicTableSourceFactory extends DynamicTableFactory
DynamicTableSinkFactory extends DynamicTableFactory
FormatFactory extends Factory

Optional interfaces that add further abilities:

SupportsComputedColumnPushDown
SupportsFilterPushDown
SupportsProjectionPushDown
SupportsWatermarkPushDown
SupportsLimitPushDown
SupportsPartitionPushDown
SupportsPartitioning
SupportsOverwriting

Data structure interfaces and classes:

RowData
ArrayData
MapData
StringData
DecimalData
TimestampData
RawValueData
GenericRowData implements RowData
GenericArrayData implements ArrayData
GenericMapData implements MapData

FLIP-131: Consolidate the user-facing Dataflow SDKs/APIs (and deprecate the DataSet API)

建议用户使用DataStream/Table/SQL而逐步废弃DataSet。其实在此提出前DataStream在功能上已经能覆盖DataSet的功能，只是执行批处理效率欠佳，而Table/SQL则完全能高效处理流批数据。这个提议只是明确这个批是流特殊情况的理念，并在DataSet文档里加上了建议用户使用DataStream