【持續更新】重要FLIP總結

码以致用發表於2024-06-21

FLIP-27: Refactor Source Interface

流批一體API
1、解耦SplitEnumerator與SplitReader
SplitEnumerator：發現並分配splits（比如files/kafka_partitions）
SourceReader：從splits裡實際讀取資料
這樣就使不同的splits分配策略與讀取動作解耦，可分別封裝成兩個元件，Source介面即變成構建SplitEnumerator、SourceReader的工廠。而且降低chkpt鎖競爭
0
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

FLIP-188: Introduce Built-in Dynamic Table Storage

流批一體儲存

相關文章