【譯】A Deep-Dive into Flink's Network Stack（1）

• 2019 年 10 月 4 日
• 筆記

Flink的網絡堆棧是組成flink-runtime模塊的核心組件之一，是每個Flink工作的核心。 它連接所有TaskManagers的各個工作單元（子任務）。 這是您的流式傳輸數據流經的地方，因此，對於吞吐量和您觀察到的延遲，Flink作業的性能至關重要。 與通過Akka使用RPC的TaskManagers和JobManagers之間的協調通道相比，TaskManagers之間的網絡堆棧依賴於使用Netty的低得多的API。

這篇博文是關於網絡堆棧的一系列帖子中的第一篇。 在下面的部分中，我們將首先深入了解流操作符所呈現的抽象，然後詳細介紹Flink的物理實現和各種優化。 我們將簡要介紹這些優化的結果以及Flink在吞吐量和延遲之間的權衡。 本系列中的未來博客文章將詳細介紹監控和指標，調整參數和常見的反模式。

邏輯視圖

Flink的網絡堆棧在相互通信時為子任務提供以下邏輯視圖，例如在keyBy（）要求的網絡混洗期間。

它抽象了以下三個概念的不同設置：

• 子任務輸出類型（ResultPartitionType）：

1. 流水線的（有界的或無界的）：一旦產生數據就可以向下游發送，可能是一個接一個地，作為有界或無界的記錄流。
2. 阻塞：僅在生成完整結果時向下游發送數據。

• 調度類型：

1. 一次性（急切）：同時部署作業的所有子任務（用於流應用程序）。
2. 第一個輸出的下一個階段（懶惰）：一旦任何生產者生成輸出，就立即部署下游任務。
3. 完整輸出的下一個階段：當任何或所有生產者生成完整輸出集時，部署下游任務

• 傳輸：

1. 高吞吐量：Flink不是一個一個地發送每個記錄，而是將一堆記錄緩衝到其網絡緩衝區中並完全發送它們。這降低了每個記錄的成本並導致更高的吞吐量。
2. 通過緩衝區超時的低延遲：通過減少發送未完全填充的緩衝區的超時，您可能會犧牲吞吐量來延遲

我們將在下面的部分中查看吞吐量和低延遲優化，這些部分將查看網絡堆棧的物理層。 對於這一部分，讓我們詳細說明輸出和調度類型。 首先，重要的是要知道子任務輸出類型和調度類型是緊密交織在一起的，只能使兩者的特定組合有效。

流水線結果分區是流式輸出，需要實時目標子任務才能發送數據。 可以在生成結果之前或首次輸出時安排目標。 批處理作業生成有界結果分區，而流式處理作業產生無限結果。

批處理作業也可能以阻塞方式產生結果，具體取決於所使用的運算符和連接模式。 在這種情況下，必須先生成完整的結果，然後才能安排接收任務。 這允許批處理作業更有效地工作並且資源使用更少。

批處理作業也可能以阻塞方式產生結果，具體取決於所使用的運算符和連接模式。 在這種情況下，必須先生成完整的結果，然後才能安排接收任務。 這允許批處理作業更有效地工作並且資源使用更少。

下表總結了有效組合：

1目前Flink未使用。

2批量/流式統一完成後，這可能適用於流式作業。

此外，對於具有多個輸入的子任務，調度以兩種方式啟動：在所有或在任何輸入生成器生成記錄/其完整數據集之後。 要調整批處理作業中的輸出類型和調度決策，請查看ExecutionConfig #setExecutionMode（） – 特別是ExecutionMode – 以及ExecutionConfig #setDefaultInputDependencyConstraint（）

物理運輸

為了理解物理數據連接，請回想一下，在Flink中，不同的任務可以通過插槽共享組共享相同的插槽。 TaskManagers還可以提供多個插槽，以允許將同一任務的多個子任務安排到同一個TaskManager上。

未完待續