[[269610]]

01 傳統(tǒng)數(shù)據(jù)基礎架構

如圖1-1所示，傳統(tǒng)單體數(shù)據(jù)架構(Monolithic Architecture)最大的特點便是集中式數(shù)據(jù)存儲，企業(yè)內(nèi)部可能有諸多的系統(tǒng)，例如Web業(yè)務系統(tǒng)、訂單系統(tǒng)、CRM系統(tǒng)、ERP系統(tǒng)、監(jiān)控系統(tǒng)等，這些系統(tǒng)的事務性數(shù)據(jù)主要基于集中式的關系性數(shù)據(jù)庫(DBMS)實現(xiàn)存儲，大多數(shù)將架構分為計算層和存儲層。

存儲層負責企業(yè)內(nèi)系統(tǒng)的數(shù)據(jù)訪問，且具有最終數(shù)據(jù)一致性保障。這些數(shù)據(jù)反映了當前的業(yè)務狀態(tài)，例如系統(tǒng)的訂單交易量、網(wǎng)站的活躍用戶數(shù)、每個用戶的交易額變化等，所有的更新操作均需要借助于同一套數(shù)據(jù)庫實現(xiàn)。

▲圖1-1 傳統(tǒng)數(shù)據(jù)結構

單體架構的初期效率很高，但是隨著時間的推移，業(yè)務越來越多，系統(tǒng)逐漸變得很大，越來越難以維護和升級，數(shù)據(jù)庫是唯一的準確數(shù)據(jù)源，每個應用都需要訪問數(shù)據(jù)庫來獲取對應的數(shù)據(jù)，如果數(shù)據(jù)庫發(fā)生改變或者出現(xiàn)問題，則將對整個業(yè)務系統(tǒng)產(chǎn)生影響。

后來隨著微服務架構(Microservices Architecture)的出現(xiàn)，企業(yè)開始逐漸采用微服務作為企業(yè)業(yè)務系統(tǒng)的架構體系。微服務架構的核心思想是，一個應用是由多個小的、相互獨立的微服務組成，這些服務運行在自己的進程中，開發(fā)和發(fā)布都沒有依賴。不同的服務能依據(jù)不同的業(yè)務需求，構建的不同的技術架構之上，能夠聚焦在有限的業(yè)務功能。

▲圖1-2 微服務架構

如圖1-2所示，微服務架構將系統(tǒng)拆解成不同的獨立服務模塊，每個模塊分別使用各自獨立的數(shù)據(jù)庫，這種模式解決了業(yè)務系統(tǒng)拓展的問題，但是也帶來了新的問題，那就是業(yè)務交易數(shù)據(jù)過于分散在不同的系統(tǒng)中，很難將數(shù)據(jù)進行集中化管理。

對于企業(yè)內(nèi)部進行數(shù)據(jù)分析或者數(shù)據(jù)挖掘之類的應用，則需要通過從不同的數(shù)據(jù)庫中進行數(shù)據(jù)抽取，將數(shù)據(jù)從數(shù)據(jù)庫中周期性地同步到數(shù)據(jù)倉庫中，然后在數(shù)據(jù)倉庫中進行數(shù)據(jù)的抽取、轉換、加載(ETL)，從而構建成不同的數(shù)據(jù)集市和應用，提供給業(yè)務系統(tǒng)使用。

02 大數(shù)據(jù)數(shù)據(jù)架構

起初數(shù)據(jù)倉庫主要還是構建在關系型數(shù)據(jù)庫之上，例如Oracle、Mysql等數(shù)據(jù)庫，但是隨著企業(yè)數(shù)據(jù)量的增長，關系型數(shù)據(jù)庫已經(jīng)無法支撐大規(guī)模數(shù)據(jù)集的存儲和分析，因此越來越多的企業(yè)開始選擇基于Hadoop構建企業(yè)級大數(shù)據(jù)平臺。

同時眾多Sql-On-Hadoop技術方案的提出，也讓企業(yè)在Hadoop上構建不同類型的數(shù)據(jù)應用變得簡單而高效，例如通過使用Apache Hive進行數(shù)據(jù)ETL處理，通過使用Apache Impala進行實時交互性查詢等。

大數(shù)據(jù)技術的興起，讓企業(yè)能夠更加靈活高效地使用自己的業(yè)務數(shù)據(jù)，從數(shù)據(jù)中提取出更多重要的價值，并將數(shù)據(jù)分析和挖掘出來的結果應用在企業(yè)的決策、營銷、管理等應用領域。但不可避免的是，隨著越來越多新技術的引入與使用，企業(yè)內(nèi)部一套大數(shù)據(jù)管理平臺可能會借助眾多開源技術組件實現(xiàn)。

例如在構建企業(yè)數(shù)據(jù)倉庫的過程中，數(shù)據(jù)往往都是周期性的從業(yè)務系統(tǒng)中同步到大數(shù)據(jù)平臺，完成一系列ETL轉換動作之后，最終形成數(shù)據(jù)集市等應用。但是對于一些時間要求比較高的應用，例如實時報表統(tǒng)計，則必須有非常低的延時展示統(tǒng)計結果，為此業(yè)界提出一套Lambda架構方案來處理不同類型的數(shù)據(jù)。

例圖1-3所示，大數(shù)據(jù)平臺中包含批量計算的Batch Layer和實時計算的Speed Layer，通過在一套平臺中將批計算和流計算整合在一起，例如使用Hadoop MapReduce進行批量數(shù)據(jù)的處理，使用Apache Storm進行實時數(shù)據(jù)的處理。

這種架構在一定程度上解決了不同計算類型的問題，但是帶來的問題是框架太多會導致平臺復雜度過高、運維成本高等。在一套資源管理平臺中管理不同類型的計算框架使用也是非常困難的事情?？偠灾?，Lambda架構是構建大數(shù)據(jù)應用程序的一種很有效的解決方案，但是還不是最完美的方案。

▲圖1-3 大數(shù)據(jù)Lambada架構

后來隨著Apache Spark的分布式內(nèi)存處理框架的出現(xiàn)，提出了將數(shù)據(jù)切分成微批的處理模式進行流式數(shù)據(jù)處理，從而能夠在一套計算框架內(nèi)完成批量計算和流式計算。

但因為Spark本身是基于批處理模式的原因，并不能完美且高效地處理原生的數(shù)據(jù)流，因此對流式計算支持的相對較弱，可以說Spark的出現(xiàn)本質(zhì)上是在一定程度上對Hadoop架構進行了一定的升級和優(yōu)化。

03 有狀態(tài)流計算架構

數(shù)據(jù)產(chǎn)生的本質(zhì)，其實是一條條真實存在的事件，前面提到的不同的架構其實都是在一定程度違背了這種本質(zhì)，需要通過在一定時延的情況下對業(yè)務數(shù)據(jù)進行處理，然后得到基于業(yè)務數(shù)據(jù)統(tǒng)計的準確結果。

實際上，基于流式計算技術局限性，我們很難在數(shù)據(jù)產(chǎn)生的過程中進行計算并直接產(chǎn)生統(tǒng)計結果，因為這不僅對系統(tǒng)有非常高的要求，還必須要滿足高性能、高吞吐、低延時等眾多目標。

而有狀態(tài)流計算架構(如圖1-4所示)的提出，從一定程度上滿足了企業(yè)的這種需求，企業(yè)基于實時的流式數(shù)據(jù)，維護所有計算過程的狀態(tài)，所謂狀態(tài)就是計算過程中產(chǎn)生的中間計算結果，每次計算新的數(shù)據(jù)進入到流式系統(tǒng)中都是基于中間狀態(tài)結果的基礎上進行運算，最終產(chǎn)生正確的統(tǒng)計結果。

基于有狀態(tài)計算的方式最大的優(yōu)勢是不需要將原始數(shù)據(jù)重新從外部存儲中拿出來，從而進行全量計算，因為這種計算方式的代價可能是非常高的。從另一個角度講，用戶無須通過調(diào)度和協(xié)調(diào)各種批量計算工具，從數(shù)據(jù)倉庫中獲取數(shù)據(jù)統(tǒng)計結果，然后再落地存儲，這些操作全部都可以基于流式計算完成，可以極大地減輕系統(tǒng)對其他框架的依賴，減少數(shù)據(jù)計算過程中的時間損耗以及硬件存儲。

▲圖1-4 有狀態(tài)計算架構

如果計算的結果能保持一致，實時計算在很短的時間內(nèi)統(tǒng)計出結果，批量計算則需要等待一定時間才能得出，相信大多數(shù)用戶會更加傾向于選擇使用有狀態(tài)流進行大數(shù)據(jù)處理。

04 為什么會是Flink

可以看出有狀態(tài)流計算將會逐步成為企業(yè)作為構建數(shù)據(jù)平臺的架構模式，而目前從社區(qū)來看，能夠滿足的只有Apache Flink。Flink通過實現(xiàn)Google Dataflow流式計算模型實現(xiàn)了高吞吐、低延遲、高性能兼具實時流式計算框架。

同時Flink支持高度容錯的狀態(tài)管理，防止狀態(tài)在計算過程中因為系統(tǒng)異常而出現(xiàn)丟失，F(xiàn)link周期性地通過分布式快照技術Checkpoints實現(xiàn)狀態(tài)的持久化維護，使得即使在系統(tǒng)停機或者異常的情況下都能計算出正確的結果。

Flink具有先進的架構理念、諸多的優(yōu)秀特性，以及完善的編程接口，而Flink也在每一次的Release版本中，不斷推出新的特性，例如Queryable State功能的提出，容許用戶通過遠程的方式直接獲取流式計算任務的狀態(tài)信息，數(shù)據(jù)不需要落地數(shù)據(jù)庫就能直接從Flink流式應用中查詢。對于實時交互式的查詢業(yè)務可以直接從Flink的狀態(tài)中查詢最新的結果。

在未來，F(xiàn)link將不僅作為實時流式處理的框架，更多的可能會成為一套實時的狀態(tài)存儲引擎，讓更多的用戶從有狀態(tài)計算的技術中獲益。

Flink的具體優(yōu)勢有以下幾點。

1. 同時支持高吞吐、低延遲、高性能

Flink是目前開源社區(qū)中唯一一套集高吞吐、低延遲、高性能三者于一身的分布式流式數(shù)據(jù)處理框架。像Apache Spark也只能兼顧高吞吐和高性能特性，主要因為在Spark Streaming流式計算中無法做到低延遲保障;而流式計算框架Apache Storm只能支持低延遲和高性能特性，但是無法滿足高吞吐的要求。而滿足高吞吐、低延遲、高性能這三個目標對分布式流式計算框架來說是非常重要的。

2. 支持事件時間(Event Time)概念

在流式計算領域中，窗口計算的地位舉足輕重，但目前大多數(shù)框架窗口計算采用的都是系統(tǒng)時間(Process Time)，也是事件傳輸?shù)接嬎憧蚣芴幚頃r，系統(tǒng)主機的當前時間。

Flink能夠支持基于事件時間(Event Time)語義進行窗口計算，也就是使用事件產(chǎn)生的時間，這種基于事件驅(qū)動的機制使得事件即使亂序到達，流系統(tǒng)也能夠計算出精確的結果，保持了事件原本產(chǎn)生時的時序性，盡可能避免網(wǎng)絡傳輸或硬件系統(tǒng)的影響。

3. 支持有狀態(tài)計算

Flink在1.4版本中實現(xiàn)了狀態(tài)管理，所謂狀態(tài)就是在流式計算過程中將算子的中間結果數(shù)據(jù)保存在內(nèi)存或者文件系統(tǒng)中，等下一個事件進入算子后可以從之前的狀態(tài)中獲取中間結果中計算當前的結果，從而無須每次都基于全部的原始數(shù)據(jù)來統(tǒng)計結果，這種方式極大地提升了系統(tǒng)的性能，并降低了數(shù)據(jù)計算過程的資源消耗。

對于數(shù)據(jù)量大且運算邏輯非常復雜的流式計算場景，有狀態(tài)計算發(fā)揮了非常重要的作用。

4. 支持高度靈活的窗口(Window)操作

在流處理應用中，數(shù)據(jù)是連續(xù)不斷的，需要通過窗口的方式對流數(shù)據(jù)進行一定范圍的聚合計算，例如統(tǒng)計在過去的1分鐘內(nèi)有多少用戶點擊某一網(wǎng)頁，在這種情況下，我們必須定義一個窗口，用來收集最近一分鐘內(nèi)的數(shù)據(jù)，并對這個窗口內(nèi)的數(shù)據(jù)進行再計算。

Flink將窗口劃分為基于Time、Count、Session，以及Data-driven等類型的窗口操作，窗口可以用靈活的觸發(fā)條件定制化來達到對復雜的流傳輸模式的支持，用戶可以定義不同的窗口觸發(fā)機制來滿足不同的需求。

5. 基于輕量級分布式快照(Snapshot)實現(xiàn)的容錯

Flink能夠分布式運行在上千個節(jié)點上，將一個大型計算任務的流程拆解成小的計算過程，然后將tesk分布到并行節(jié)點上進行處理。在任務執(zhí)行過程中，能夠自動發(fā)現(xiàn)事件處理過程中的錯誤而導致數(shù)據(jù)不一致的問題，比如：節(jié)點宕機、網(wǎng)路傳輸問題，或是由于用戶因為升級或修復問題而導致計算服務重啟等。

在這些情況下，通過基于分布式快照技術的Checkpoints，將執(zhí)行過程中的狀態(tài)信息進行持久化存儲，一旦任務出現(xiàn)異常停止，F(xiàn)link就能夠從Checkpoints中進行任務的自動恢復，以確保數(shù)據(jù)在處理過程中的一致性。

6. 基于JVM實現(xiàn)獨立的內(nèi)存管理

內(nèi)存管理是所有計算框架需要重點考慮的部分，尤其對于計算量比較大的計算場景，數(shù)據(jù)在內(nèi)存中該如何進行管理顯得至關重要。針對內(nèi)存管理，F(xiàn)link實現(xiàn)了自身管理內(nèi)存的機制，盡可能減少JVM GC對系統(tǒng)的影響。

另外，F(xiàn)link通過序列化/反序列化方法將所有的數(shù)據(jù)對象轉換成二進制在內(nèi)存中存儲，降低數(shù)據(jù)存儲的大小的同時，能夠更加有效地對內(nèi)存空間進行利用，降低GC帶來的性能下降或任務異常的風險，因此Flink較其他分布式處理的框架會顯得更加穩(wěn)定，不會因為JVM GC等問題而影響整個應用的運行。

7. Save Points(保存點)

對于7*24小時運行的流式應用，數(shù)據(jù)源源不斷地接入，在一段時間內(nèi)應用的終止有可能導致數(shù)據(jù)的丟失或者計算結果的不準確，例如進行集群版本的升級、停機運維操作等操作。

值得一提的是，F(xiàn)link通過Save Points技術將任務執(zhí)行的快照保存在存儲介質(zhì)上，當任務重啟的時候可以直接從事先保存的Save Points恢復原有的計算狀態(tài)，使得任務繼續(xù)按照停機之前的狀態(tài)運行，Save Points技術可以讓用戶更好地管理和運維實時流式應用。

關于作者：張利兵，資深架構師，流式計算領域?qū)＜摇Ｓ卸嗄甏髷?shù)據(jù)、流式計算方面的開發(fā)經(jīng)驗，對Hadoop、Spark、Flink等大數(shù)據(jù)計算引擎有著非常深入的理解，積累了豐富的項目實踐經(jīng)驗。