Flink 小貼士 (7): 4個步驟，讓 Flink 應用達到生產狀態
原文： ofollow,noindex">https://data-artisans.com/blog/4-steps-flink-application-production-ready
作者：Nico Kruber, Markos Sfikas
譯者：雲邪（Jark）
本文闡述了使 Flink 應用達到生產就緒狀態所需要的一些配置步驟。在以下部分中，我們概述了重要的配置引數，這些引數是技術領導、DevOps、工程師們在將 Flink 應用程式上線生產之前都需要仔細考慮的。Apache Flink 為大多數配置都提供了開箱即用的預設選項，在許多情況下，它們是POC階段（概念驗證）或探索 Flink 不同 API 和抽象的很好的起點。
然而，將 Flink 應用程式投入生產還需要額外的配置，這些配置可以高效地調整應用的規模，使其達到生產就緒狀態，並能與不同系統之間保持相容，以保證未來迭代升級的需求。
下面幾點是我們收集的需要在 Flink 應用上線前做的檢查：
1. 明確定義 Flink 運算元的最大併發度
Flink 的 keyed state 是由 key group 進行組織的，並分佈在 Flink 運算元（operator）的各個併發例項上。Key group 是用來分佈和影響 Flink 應用程式可擴充套件性的最小原子單元，每個運算元上的 key group 個數即為最大併發數（maxParallelism），可以手動配置也可以直接使用預設配置。預設值粗略地使用 operatorParallelism * 1.5 ，下限 128，上限 32768 。可以通過 setMaxParallelism(int maxParallelism) 來手動地設定作業或具體運算元的最大併發。
任何進入生產的作業都應該指定最大併發數。但是，一定要仔細考慮後再決定該值的大小。因為一旦設定了最大併發度（ 無論是手動設定，還是預設設定 ），之後就無法再對該值做更新。想要改變一個作業的最大併發度，就只能將作業從全新的狀態重新開始執行。目前還無法在更改最大併發度後，從上一個 checkpoint 或 savepoint 恢復。
最大併發度的取值建議設定一個足夠高的值以滿足應用未來的可擴充套件性和可用性，同時，又要選一個相對較低的值以避免影響應用程式整體的效能。這是由於一個很高的最大併發度會導致 Flink 需要維護大量的元資料（用於擴縮容），這可能會增加 Flink 應用程式的整體狀態大小。
2. 為 Flink 運算元指定唯一使用者ID（UUID）
對於有狀態的 Flink 應用，推薦給每個運算元都 指定唯一使用者ID（UUID） 。 嚴格地說，僅需要給有狀態的運算元設定就足夠了。但是因為 Flink 的某些內建運算元（如 window）是有狀態的，而有些是無狀態的，可能使用者不是很清楚哪些內建運算元是有狀態的，哪些不是。所以從實踐經驗上來說，我們建議每個運算元都指定上 UUID。
Flink 運算元的 UUID 可以通過 uid(String uid) 方法指定。運算元 UUID 使得 Flink 有效地將運算元的狀態從 savepoint 對映到作業修改後（拓撲圖可能也有改變）的正確的運算元上，這是 savepoint 在 Flink 應用中正常工作的一個基本要素。
3. 充分考慮 Flink 程式的狀態後端
當前 Flink 還不支援狀態後端之間的互換功能，也就是當我們用記憶體狀態後端做了一個 savepoint，我們無法把作業改成 RocksDB 狀態後端然後恢復。所以，開發人員和工程負責人在將作業投向生產之前要仔細考慮好該 Flink 應用的最合適的狀態後端型別。
關於 Flink 當前支援的三種不同的狀態後端型別，可以閱讀我們的上一篇文章： 《Flink 小貼士 (4): 如何選擇狀態後端》
對於生產用例來說，強烈建議使用 RocksDB 狀態後端，因為這是目前唯一一種支援大型狀態和非同步操作（如快照過程）的狀態後端，非同步操作能使 Flink 不阻塞正常資料流的處理的情況下做快照操作。另一方面，使用 RocksDB 狀態後端可能存在效能折衷，因為所有狀態訪問和檢索都需要序列化（和反序列化）來跨越 JNI 邊界，這與記憶體狀態後端相比可能會影響應用程式的吞吐量。
4. 配置 JobManager 的高可用性（HA）
高可用性（HA）配置確保了 Flink 應用中 JobManager 元件發生潛在故障後的自動恢復，從而將停機時間降到最低。JobManager 的主要職責是協調 Flink 的部署，例如排程和適當的資源分配。
預設情況下，Flink 為每個叢集設定一個 JobManager 例項。這會導致單點故障（SPOF）：如果 JobManager 崩潰了，則無法提交新的作業，而且正在執行的程式也會失敗。因此，強烈建議為生產用例 配置高可用性（HA） 。
上述 4 個步驟總結自社群的最佳實踐，使得 Flink 應用能夠保持狀態的同時任意地擴縮容，處理更大規模的資料和狀態，並提高系統的可用性。我們強烈建議您在將應用投入生產之前，仔細閱讀上述步驟。