1.1 核心特點

1.1.1 批流一體

所有的數據都天然帶有時間的概念，必然發生在某一個時間點。把事件按照時間順序排列起來，就形成了一個事件流，也叫作數據流。例如信用卡交易事務，傳感器收集設備數據、機器日志數據以及網站或移動應用程序上的用戶交互行為數據等，所有這些數據都是數據流。

數據時時刻刻都在產生，如同江河奔流不息。例如，每一個人每天都在處理各種各樣的事情（事件），解決問題（響應），一年結束之時，人們往往會坐下來總結這一年的得失，并制訂新一年的計劃。在總結過去的時候，其實就默認給了一個時間范圍。再舉一個例子，企業進行年終總結時，會統計當年完成了多少業績，而不是考慮每一筆業務的業績。由此可以引出兩個概念：無界數據（流）、有界數據（批）。

1.無界數據

無界數據是持續產生的數據，所以必須持續地處理無界數據流。數據是無限的，也就無法等待所有輸入數據到達后處理，因為輸入是無限的，沒有終止的時間。處理無界數據通常要求以特定順序（例如事件發生的順序）獲取，以便判斷事件是否完整、有無遺漏。

2.有界數據

有界數據，就是在一個確定的時間范圍內的數據流，有開始有結束，一旦確定了就不會再改變。

Flink的設計思想與谷歌Cloud Dataflow的編程模型較為接近，都以流為核心，批是流的特例。Flink擅長處理無界和有界數據。Flink提供的精確的時間控制能力和有狀態計算的機制，讓它可以輕松應對任何類型的無界數據流，同時Flink還專門設計了算法和數據結構來高效地處理有界數據流。

1.1.2 可靠的容錯能力

在分布式系統中，硬件故障、進程異常、應用異常、網絡故障等多種多樣的異常無處不在。像Flink這樣的分布式計算引擎必須能夠從故障中恢復到正常狀態，以便實現全天候運行。這就要求引擎在故障發生后不僅可以重新啟動應用程序，還要確保其內部狀態保持一致，從最后一次正確的點重新執行，從用戶的角度來說，最終的計算結果與未發生故障是一樣的。

1.集群級容錯

（1）與集群管理器集成

Flink與集群管理器緊密集成，例如Hadoop YARN、Mesos或Kubernetes。當進程掛掉時，將自動啟動一個新進程來接管它的工作。

（2）高可用性設置

Flink具有高可用性模式特性，可消除所有單點故障。HA模式基于Apache ZooKeeper，Zookeeper是一種經過驗證的可靠的分布式協調服務。

2.應用級容錯

Flink使用輕量級分布式快照機制，設計了檢查點（Checkpoint）來實現可靠的容錯。其特性如下。

（1）一致性

Flink的恢復機制基于應用程序狀態的一致性檢查點。如果發生故障，將重新啟動應用程序并從最新檢查點加載其狀態。結合可重放的流數據源，此特性可以保證精確、一次的狀態一致性。

Flink、Spark、Storm等都支持引擎內的Exactly-Once語義，即確保數據僅處理一次，不會重復也不會丟失。但是在把結果寫入外部存儲的時候，可能會發生存儲故障、網絡中斷、Flink應用異常恢復等多種情況，在這些情況下，部分數據可能已經寫入外部存儲，重復執行可能導致數據的重復寫出，此時需要開發者為寫出到外部存儲的行為保證冪等性。

在Spark、Storm中需要開發者自行實現Sink，實現端到端的Exactly-Once行為。而Flink利用檢查點特性，在框架層面提供了Exactly-Once的支持，內置了支持Exactly-Once語義的Sink，即使出現故障，也能保證數據只寫出一次。

（2）輕量級

對于長期運行的Flink應用程序，其檢查點的狀態可能高達TB級，生成和保存檢查應用程序的檢查點成本非常高。所以Flink提供了檢查點的執行異步和增量檢查點，以便盡量降低生成和保存檢查點帶來的計算負荷，避免數據處理的延遲異常變大和吞吐量的短暫劇降。

1.1.3 高吞吐、低延遲

從Storm流計算引擎開始，大家似乎留下了這樣一個印象，要實現低延遲，就要犧牲吞吐量，高吞吐、低延遲是流處理引擎的核心矛盾。以Storm為代表的第一代流計算引擎可以做到幾十毫秒的處理延遲，但是吞吐量確實不高。后來的Spark Streaming基于mini-batch的流計算框架能夠實現較高的吞吐量，但是數據處理的延遲不甚理想，一般可達到秒級。

Flink借助輕量級分布式快照機制，能夠定時生成分布式快照，并將快照保存到外部存儲中。檢查點之間的數據處理被當作是原子的，如果失敗，直接回到上一個檢查點重新執行即可。在整個數據處理過程中不會產生阻塞，不必像mini-batch機制一樣需要等待調度，可以持續處理數據，容錯開銷非常低。Flink在數據的計算、傳輸、序列化等方面也做了大量的優化，既能保持數據處理的低延遲，也能盡可能地提高吞吐量。

1.1.4 大規模復雜計算

Flink在設計之初就非常在意性能相關的任務狀態和流控等關鍵技術的設計，這些都使得用Flink執行復雜的大規模任務時性能更勝一籌。

對于大規模復雜計算，尤其是長期運行的流計算應用而言，有狀態計算是大數據計算引擎中一個比較大的需求點。所謂的有狀態計算就是要結合歷史信息進行的計算，例如對于反欺詐行為的識別，要根據用戶在近幾分鐘之內的行為做出判斷。一旦出現異常，就需要重新執行流計算任務，但重新處理所有的原始數據是不現實的，而Flink的容錯機制和State能夠使Flink的流計算作業恢復到近期的一個時間點，從這個時間點開始執行流計算任務，這無疑能夠大大降低大規模任務失敗恢復的成本。

Flink為了提供有狀態計算的性能，針對本地狀態訪問進行了優化，任務狀態始終駐留在內存中，如果狀態大小超過可用內存，則保存在高效磁盤上的數據結構中。因此，任務通過訪問本地（通常是內存中）狀態來執行所有計算，從而達到特別低的處理延遲。Flink通過定期和異步檢查點將本地狀態進行持久存儲來保證在出現故障時實現精確、一次的狀態一致性。

Flink的輕量級容錯機制也能夠盡量降低大規模數據處理時的調度、管理成本，計算規模的增大不會顯著增加容錯，數據吞吐不會劇烈下降，數據延遲不會急劇增大。

1.1.5 多平臺部署

Flink是一個分布式計算系統，需要計算資源才能執行應用程序。Flink可以與所有常見的集群資源管理器（如Hadoop YARN、Apache Mesos和Kubernetes）集成，也可以在物理服務器上作為獨立集群運行。

為了實現不同的部署模式，Flink設計了一套資源管理框架，針對上面提到的資源管理平臺實現了對應的資源管理器（ResourceManager），能夠與上面提到的資源管理平臺無縫對接。

部署Flink應用程序時，Flink會根據應用程序配置的并行度自動識別所需資源，并向資源管理器申請資源。如果發生故障，Flink會通過請求新的資源來替換發生故障的資源。Flink提供了提交或控制應用程序的REST接口，方便與外部應用進行集成，管理Flink作業。