01 傳統資料基礎架構
如圖1-1所示，傳統單體資料架構（Monolithic Architecture）最大的特點便是集中式資料存儲，企業内部可能有諸多的系統，例如Web業務系統、訂單系統、CRM系統、ERP系統、監控系統等，這些系統的事務性資料主要基于集中式的關系性資料庫（DBMS）實作存儲，大多數将架構分為計算層和存儲層。
存儲層負責企業内系統的資料通路，且具有最終資料一緻性保障。這些資料反映了目前的業務狀态，例如系統的訂單交易量、網站的活躍使用者數、每個使用者的交易額變化等，所有的更新操作均需要借助于同一套資料庫實作。
▲圖1-1 傳統資料結構
如果你準備入行大資料，關于2019大資料目前的
【發展前景】戳我閱讀
【就業崗位】戳我閱讀
【大資料薪資待遇】戳我閱讀
【完整的學習線路】戳我閱讀
關注微信公衆号itdaima擷取大資料全套開發工具以及入門學習資料
單體架構的初期效率很高，但是随着時間的推移，業務越來越多，系統逐漸變得很大，越來越難以維護和更新，資料庫是唯一的準确資料源，每個應用都需要通路資料庫來擷取對應的資料，如果資料庫發生改變或者出現問題，則将對整個業務系統産生影響。
後來随着微服務架構（Microservices Architecture）的出現，企業開始逐漸采用微服務作為企業業務系統的架構體系。微服務架構的核心思想是，一個應用是由多個小的、互相獨立的微服務組成，這些服務運作在自己的程序中，開發和釋出都沒有依賴。不同的服務能依據不同的業務需求，建構的不同的技術架構之上，能夠聚焦在有限的業務功能。
▲圖1-2 微服務架構
如圖1-2所示，微服務架構将系統拆解成不同的獨立服務子產品，每個子產品分别使用各自獨立的資料庫，這種模式解決了業務系統拓展的問題，但是也帶來了新的問題，那就是業務交易資料過于分散在不同的系統中，很難将資料進行集中化管理。
對于企業内部進行資料分析或者資料挖掘之類的應用，則需要通過從不同的資料庫中進行資料抽取，将資料從資料庫中周期性地同步到資料倉庫中，然後在資料倉庫中進行資料的抽取、轉換、加載（ETL），進而建構成不同的資料集市和應用，提供給業務系統使用。
02 大資料資料架構
起初資料倉庫主要還是建構在關系型資料庫之上，例如Oracle、Mysql等資料庫，但是随着企業資料量的增長，關系型資料庫已經無法支撐大規模資料集的存儲和分析，是以越來越多的企業開始選擇基于Hadoop建構企業級大資料平台。
同時衆多Sql-On-Hadoop技術方案的提出，也讓企業在Hadoop上建構不同類型的資料應用變得簡單而高效，例如通過使用Apache Hive進行資料ETL處理，通過使用Apache Impala進行實時互動性查詢等。
大資料技術的興起，讓企業能夠更加靈活高效地使用自己的業務資料，從資料中提取出更多重要的價值，并将資料分析和挖掘出來的結果應用在企業的決策、營銷、管理等應用領域。但不可避免的是，随着越來越多新技術的引入與使用，企業内部一套大資料管理平台可能會借助衆多開源技術元件實作。
例如在建構企業資料倉庫的過程中，資料往往都是周期性的從業務系統中同步到大資料平台，完成一系列ETL轉換動作之後，最終形成資料集市等應用。但是對于一些時間要求比較高的應用，例如實時報表統計，則必須有非常低的延時展示統計結果，為此業界提出一套Lambda架構方案來處理不同類型的資料。
例圖1-3所示，大資料平台中包含批量計算的Batch Layer和實時計算的Speed Layer，通過在一套平台中将批計算和流計算整合在一起，例如使用Hadoop MapReduce進行批量資料的處理，使用Apache Storm進行實時資料的處理。
這種架構在一定程度上解決了不同計算類型的問題，但是帶來的問題是架構太多會導緻平台複雜度過高、運維成本高等。在一套資源管理平台中管理不同類型的計算架構使用也是非常困難的事情。總而言之，Lambda架構是建構大資料應用程式的一種很有效的解決方案，但是還不是最完美的方案。
▲圖1-3 大資料Lambada架構
後來随着Apache Spark的分布式記憶體處理架構的出現，提出了将資料切分成微批的處理模式進行流式資料處理，進而能夠在一套計算架構内完成批量計算和流式計算。
但因為Spark本身是基于批處理模式的原因，并不能完美且高效地處理原生的資料流，是以對流式計算支援的相對較弱，可以說Spark的出現本質上是在一定程度上對Hadoop架構進行了一定的更新和優化。
03 有狀态流計算架構
資料産生的本質，其實是一條條真實存在的事件，前面提到的不同的架構其實都是在一定程度違背了這種本質，需要通過在一定時延的情況下對業務資料進行處理，然後得到基于業務資料統計的準确結果。
實際上，基于流式計算技術局限性，我們很難在資料産生的過程中進行計算并直接産生統計結果，因為這不僅對系統有非常高的要求，還必須要滿足高性能、高吞吐、低延時等衆多目标。
而有狀态流計算架構（如圖1-4所示）的提出，從一定程度上滿足了企業的這種需求，企業基于實時的流式資料，維護所有計算過程的狀态，所謂狀态就是計算過程中産生的中間計算結果，每次計算新的資料進入到流式系統中都是基于中間狀态結果的基礎上進行運算，最終産生正确的統計結果。
基于有狀态計算的方式最大的優勢是不需要将原始資料重新從外部存儲中拿出來，進而進行全量計算，因為這種計算方式的代價可能是非常高的。從另一個角度講，使用者無須通過排程和協調各種批量計算工具，從資料倉庫中擷取資料統計結果，然後再落地存儲，這些操作全部都可以基于流式計算完成，可以極大地減輕系統對其他架構的依賴，減少資料計算過程中的時間損耗以及硬體存儲。
▲圖1-4 有狀态計算架構
如果計算的結果能保持一緻，實時計算在很短的時間内統計出結果，批量計算則需要等待一定時間才能得出，相信大多數使用者會更加傾向于選擇使用有狀态流進行大資料處理。
04 為什麼會是Flink
可以看出有狀态流計算将會逐漸成為企業作為建構資料平台的架構模式，而目前從社群來看，能夠滿足的隻有Apache Flink。Flink通過實作Google Dataflow流式計算模型實作了高吞吐、低延遲、高性能兼具實時流式計算架構。
同時Flink支援高度容錯的狀态管理，防止狀态在計算過程中因為系統異常而出現丢失，Flink周期性地通過分布式快照技術Checkpoints實作狀态的持久化維護，使得即使在系統停機或者異常的情況下都能計算出正确的結果。
Flink具有先進的架構理念、諸多的優秀特性，以及完善的程式設計接口，而Flink也在每一次的Release版本中，不斷推出新的特性，例如Queryable State功能的提出，容許使用者通過遠端的方式直接擷取流式計算任務的狀态資訊，資料不需要落地資料庫就能直接從Flink流式應用中查詢。對于實時互動式的查詢業務可以直接從Flink的狀态中查詢最新的結果。
在未來，Flink将不僅作為實時流式處理的架構，更多的可能會成為一套實時的狀态存儲引擎，讓更多的使用者從有狀态計算的技術中獲益。
Flink的具體優勢有以下幾點。
1. 同時支援高吞吐、低延遲、高性能
Flink是目前開源社群中唯一一套集高吞吐、低延遲、高性能三者于一身的分布式流式資料處理架構。像Apache Spark也隻能兼顧高吞吐和高性能特性，主要因為在Spark Streaming流式計算中無法做到低延遲保障；而流式計算架構Apache Storm隻能支援低延遲和高性能特性，但是無法滿足高吞吐的要求。而滿足高吞吐、低延遲、高性能這三個目标對分布式流式計算架構來說是非常重要的。
2. 支援事件時間（Event Time）概念
在流式計算領域中，視窗計算的地位舉足輕重，但目前大多數架構視窗計算采用的都是系統時間（Process Time），也是事件傳輸到計算架構處理時，系統主機的目前時間。
Flink能夠支援基于事件時間（Event Time）語義進行視窗計算，也就是使用事件産生的時間，這種基于事件驅動的機制使得事件即使亂序到達，流系統也能夠計算出精确的結果，保持了事件原本産生時的時序性，盡可能避免網絡傳輸或硬體系統的影響。
3. 支援有狀态計算
Flink在1.4版本中實作了狀态管理，所謂狀态就是在流式計算過程中将算子的中間結果資料儲存在記憶體或者檔案系統中，等下一個事件進入算子後可以從之前的狀态中擷取中間結果中計算目前的結果，進而無須每次都基于全部的原始資料來統計結果，這種方式極大地提升了系統的性能，并降低了資料計算過程的資源消耗。
對于資料量大且運算邏輯非常複雜的流式計算場景，有狀态計算發揮了非常重要的作用。
4. 支援高度靈活的視窗（Window）操作
在流處理應用中，資料是連續不斷的，需要通過視窗的方式對流資料進行一定範圍的聚合計算，例如統計在過去的1分鐘内有多少使用者點選某一網頁，在這種情況下，我們必須定義一個視窗，用來收集最近一分鐘内的資料，并對這個視窗内的資料進行再計算。
Flink将視窗劃分為基于Time、Count、Session，以及Data-driven等類型的視窗操作，視窗可以用靈活的觸發條件定制化來達到對複雜的流傳輸模式的支援，使用者可以定義不同的視窗觸發機制來滿足不同的需求。
5. 基于輕量級分布式快照（Snapshot）實作的容錯
Flink能夠分布式運作在上千個節點上，将一個大型計算任務的流程拆解成小的計算過程，然後将tesk分布到并行節點上進行處理。在任務執行過程中，能夠自動發現事件處理過程中的錯誤而導緻資料不一緻的問題，比如：節點當機、網路傳輸問題，或是由于使用者因為更新或修複問題而導緻計算服務重新開機等。
在這些情況下，通過基于分布式快照技術的Checkpoints，将執行過程中的狀态資訊進行持久化存儲，一旦任務出現異常停止，Flink就能夠從Checkpoints中進行任務的自動恢複，以確定資料在處理過程中的一緻性。
6. 基于JVM實作獨立的記憶體管理
記憶體管理是所有計算架構需要重點考慮的部分，尤其對于計算量比較大的計算場景，資料在記憶體中該如何進行管理顯得至關重要。針對記憶體管理，Flink實作了自身管理記憶體的機制，盡可能減少JVM GC對系統的影響。
另外，Flink通過序列化/反序列化方法将所有的資料對象轉換成二進制在記憶體中存儲，降低資料存儲的大小的同時，能夠更加有效地對記憶體空間進行利用，降低GC帶來的性能下降或任務異常的風險，是以Flink較其他分布式處理的架構會顯得更加穩定，不會因為JVM GC等問題而影響整個應用的運作。
7. Save Points（儲存點）
對于7*24小時運作的流式應用，資料源源不斷地接入，在一段時間内應用的終止有可能導緻資料的丢失或者計算結果的不準确，例如進行叢集版本的更新、停機運維操作等操作。
值得一提的是，Flink通過Save Points技術将任務執行的快照儲存在存儲媒體上，當任務重新開機的時候可以直接從事先儲存的Save Points恢複原有的計算狀态，使得任務繼續按照停機之前的狀态運作，Save Points技術可以讓使用者更好地管理和運維實時流式應用。
關于作者：張利兵，資深架構師，流式計算領域專家。有多年大資料、流式計算方面的開發經驗，對Hadoop、Spark、Flink等大資料計算引擎有着非常深入的了解，積累了豐富的項目實踐經驗。
本文摘編自《Flink原理、實戰與性能優化》，經出版方授權釋出。