白玉辛，劉曉燕

（昆明理工大學，云南 昆明 650500）

0 引言

大數(shù)據(jù)的時代已經悄然來臨，信息技術發(fā)展上升到了一個新的歷史階段，影響著社會生產模式和人們生活的方方面面。我國高度重視大數(shù)據(jù)技術的研究和產業(yè)發(fā)展，把大數(shù)據(jù)技術研究納入國家戰(zhàn)略發(fā)展的重要項目，以期在“第三次信息化浪潮中”占得先機、引領市場。近年來，華為公司提出5G概念并將其投入生產實踐，使得5G 網絡逐步取代第四代移動通信網絡，峰值理論傳輸速度可達10 Gb/s，比4G 網絡的傳輸速度快數(shù)百倍。可見，大數(shù)據(jù)正在改變著人們的生活、工作和思想[1-2]。

2004 年Google 的3 篇 論 文MapReduce[3]、GFS[4]和BigTable[5]開啟了針對大數(shù)據(jù)問題的關鍵技術研究。Cutting 等人根據(jù)論文的描述實現(xiàn)開源的MapReduce 計算框架，將其和NDFS 結合在一起，使其成為今天熟知的Hadoop，并在2008 年成為Apache軟件基金會旗下的頂級項目，命名為Hadoop[6]。

2008 年，柏林理工大學開發(fā)了一套大數(shù)據(jù)處理平臺，此為Flink 的前身。隨后，在2014 年被Apache 孵化器所接受，然后迅速成為阿帕奇基金會（Apache Software Foundation，ASF）的頂級項目之一。Flink 是一個用于分布式數(shù)據(jù)處理的開源平臺，可以用于Google 數(shù)據(jù)流模型[7]。它使用戶能夠編寫可以分布在多個工作節(jié)點的程序，使得可以比單個計算機更快地處理大規(guī)模數(shù)據(jù)集。Flink 核心是一個流式的數(shù)據(jù)流執(zhí)行引擎，提供抽象層的API，以便用戶編寫分布式任務。目前，互聯(lián)網領域的實時搜索、數(shù)據(jù)平臺整合、數(shù)據(jù)分析和機器學習任務等，都可以在Flink 平臺上運行。

Flink 和MapReduce 相比較具有各種優(yōu)點，但Flink 始終是一款大數(shù)據(jù)的計算框架，與Hadoop 中的MapReduce 具有類似的數(shù)據(jù)處理功能，都是拿來做數(shù)據(jù)處理的計算引擎。所以，在數(shù)據(jù)計算過程中Hadoop 的分布式文件系統(tǒng)HDFS 不可或缺。Hadoop一開始的設計思路是為了用戶不用清楚詳細了解分布式底層細節(jié)實現(xiàn)的情況下開發(fā)分布式應用程序，使用集群開發(fā)環(huán)境使運算性能最大化，同時利用分布式文件系統(tǒng)存儲數(shù)據(jù)處理后的結果，實現(xiàn)了大規(guī)模的批處理，是一款真正意義上的大數(shù)據(jù)處理平臺。Flink 支持數(shù)據(jù)流中的迭代，一個特例是Delta Iterations[8]。對于Delta 迭代的某些計算，并非每個迭代步驟都要更新每個數(shù)據(jù)項。他們在工作集和解決方案集上工作，工作集是推動迭代的動力。在每個步驟中，計算新的工作集并將其反饋到迭代中。Delta Iteration 在工作集為空或達到最大迭代次數(shù)時終止。兩者有著不同的實際應用場景。

1 Hadoop 技術原理及其生態(tài)系統(tǒng)

1.1 Hadoop 技術原理

Hadoop 中的分布式文件系統(tǒng)（Hadoop Distribute File System，HDFS）較好地滿足了大規(guī)模數(shù)據(jù)存儲需求，通過網絡實現(xiàn)文件在多臺機器上的分布式存儲。大數(shù)據(jù)時代需解決大規(guī)模數(shù)據(jù)的高效存儲問題，還需要解決大規(guī)模數(shù)據(jù)的高效處理問題。Hadoop中的MapReduce 基于分布式并行編程框架，有利于提高程序性能，實現(xiàn)高效的批量數(shù)據(jù)處理。隨著hadoop 生態(tài)系統(tǒng)其他組件的不斷豐富，為了使hadoop 可以支持更多的應用場景，提供更高的可用性，資源管理調度框架YARN 脫穎而出。以上3 大模塊共同組成了Hadoop 的基礎架構。

1.1.1 HDFS

HDFS[9]是基于谷歌文件系統(tǒng)（Google File System，GFS）的開源實現(xiàn)，并與MapReduce 計算框架一起成為Hadoop 的核心組成部分。HDFS 采用“主-從”節(jié)點的理念，使用名稱節(jié)點（namenode）負責文件和目錄的創(chuàng)建、刪除和重命名等，同時管理數(shù)據(jù)節(jié)點和文件塊的映射關系；使用數(shù)據(jù)節(jié)點（datanode）負責數(shù)據(jù)的存儲和讀取。HDFS 兼容廉價的硬件設備，支持流數(shù)據(jù)讀寫，可以處理大規(guī)模數(shù)據(jù)集，遵從“一次寫入、多次讀取”的理念，同時支持跨平臺。HDFS 的基本架構以及數(shù)據(jù)讀寫流程，如圖1 所示。

1.1.2 MapReduce

大規(guī)模數(shù)據(jù)集的處理包括分布式存儲和分布式計算兩個核心環(huán)節(jié)。整個MapReduce 的思想可以用“分而治之”來概括?？梢詫⒁粋€大規(guī)模數(shù)據(jù)集切分為許多個Map 任務在多臺機器上并行執(zhí)行，每個Map 任務通常運行在數(shù)據(jù)存儲的結點上。當Map 任務結束后，會生成k-v 鍵值對形式表示中間的結果，然后這些中間結果會被發(fā)送到Reduce 任務機器上進行匯總得到最后結果，最后輸出到分布式文件系統(tǒng)。圖2 是MapReduce 的整個流程。

1.1.3 YARN

為了克服Hadoop1.0 版本的缺陷，重新設計了Hadoop2.0 以后版本的體系結構，以MapReduce2.0 與另一種資源協(xié)調者（Yet Another Resource Negotiator，YARN）[10]全新模式進行數(shù)據(jù)處理。重新設計后的YARN 包 括ResourceManager、ApplicationMaster 和NodeManager。其中，ResourceManager 負責資源管理，由ApplicationMaster 負責任務調度和監(jiān)控，由NodeManager 負責執(zhí)行原TaskTracker 的任務。通過這種“放權”設計，大大降低了JobTracker 的負擔，提升了系統(tǒng)運行的效率和穩(wěn)定性。它的架構設計思路如圖3 所示。

圖1 HDFS 的架構以及數(shù)據(jù)讀寫流程

圖2 MapReduce 的整個流程

圖3 YARN 架構設計思路

1.2 Hadoop 生態(tài)系統(tǒng)

Hadoop 在不斷完善自身核心組件性能的同時，生態(tài)系統(tǒng)也在不斷豐富發(fā)展。為了應對大數(shù)據(jù)時代不同應用場景的數(shù)據(jù)處理，Hadoop 衍生出許多重要的子項目，共同構成了Hadoop 生態(tài)系統(tǒng)[11]，如表1 所示。

表1 Hadoop 生態(tài)系統(tǒng)

2 Flink 技術原理及其生態(tài)系統(tǒng)

2.1 Flink 技術原理

任何類型的數(shù)據(jù)都是作為事件流產生的。信用卡交易、傳感器測量、機器日志、網站或移動應用程序上的用戶交互，所有這些數(shù)據(jù)都以流的形式生成[12]。Apache Flink 正是為處理這些流而設計的。首先，Apache Flink 是一個框架，其分布式的計算模式使其成為一個可伸縮的開源流處理平臺，用于無界數(shù)據(jù)集和有界數(shù)據(jù)集進行狀態(tài)計算。核心模塊是一個數(shù)據(jù)流引擎，主要通過Java 代碼實現(xiàn)。對時間和狀態(tài)的精確控制，使Flink 運行時無界流能運行任何類型的應用程序。有界流由專門固定大小的數(shù)據(jù)集設計的數(shù)據(jù)結構和算法進行內部處理，從而獲得優(yōu)異的性能。Flink 常被設計應用于集群環(huán)境中運行，以內存中的速度和任何規(guī)模執(zhí)行計算，使得可以比單個計算機更快地處理大規(guī)模數(shù)據(jù)集。Flink 最近提出了本地閉環(huán)迭代操作符[13]和基于成本的自動優(yōu)化器，能夠重新排序操作符，并更好地支持流。

Apache Flink 功能強大，支持開發(fā)和運行多種不同種類的應用程序。它的主要特性包括批流一體化、精密的狀態(tài)管理、事件時間支持以及精確一次的狀態(tài)一致性保障等。Flink 不僅可以運行在包括YARN、Mesos、Kubernetes 在內的多種資源管理框架上，還支持在裸機集群上獨立部署[14]。在啟用高可用選項的情況下，它不存在單點失效問題。事實證明，F(xiàn)link 已經可以擴展到數(shù)千核心，其狀態(tài)可以達到TB 級別，且仍能保持高吞吐、低延遲的特性。世界各地有很多要求嚴苛的流處理應用運行在Flink 上。

Flink 提供3 層API。每個API 在簡潔性和表達性之間提供不同的權衡，并針對不同的用例。如圖4 所示，層級越高，代碼越簡潔，同時表達能力越弱，層級越低。

圖4 Flink 的3 層API 及各接口內容

Process Functions 是Flink 提供的最具表現(xiàn)力的功能接口[15]。Flink 提供Process Function 來處理來自窗口中分組的一個或兩個輸入流或事件的單個事件。它提供對時間和狀態(tài)的細粒度控制，還可以任意修改其狀態(tài)并注冊將在未來觸發(fā)回調函數(shù)的定時器。因此，Process Functions 可以根據(jù)許多有狀態(tài)事件驅動的應用程序的需要實現(xiàn)復雜的事件業(yè)務邏輯[16]。

數(shù)據(jù)流API 可用于Java 和Scala 和基于功能，如map()、reduce()和aggregate()，可以通過擴展接口或Java 或Scala lambda 函數(shù)來定義函數(shù)。Flink 具有兩個關系API、Table API 和SQL。這兩個API 都是用于批處理和流處理的統(tǒng)一API，即在無界的實時流或有界的記錄流上以相同的語義執(zhí)行查詢，并產生相同的結果。Table API 和SQL 利用Apache Calcite 進行解析、驗證和查詢優(yōu)化。它們可以與DataStream 和DataSet API 無縫集成，并支持用戶定義的標量、聚合和表值函數(shù)。

該引擎同樣可以在獨立Hadoop YARN 或Apache Mesos 集群模式下運行，提供了具有不同抽象級別的API。最低級API 為有狀態(tài)流處理提供構建塊。核心數(shù)據(jù)集（批處理）和DataStream API 位于最常用的位置，且表和SQL API 位于其頂部[17]，提供其他庫以直接支持各種特定上下文。核心API支持Java 和Scala，數(shù)據(jù)集API 還支持Python?？梢允褂抿寗映绦蛑械难h(huán)或通過Iterative Stream 或Iterative data集類實現(xiàn)迭代。前者在技術上不是迭代，而是驅動程序根據(jù)需要循環(huán)和擴展DAG，這是有限的可約性。在DAG 中，單個節(jié)點可以迭代地執(zhí)行一組轉換，使用最后計算的值或解決方案集狀態(tài)可以在每次迭代中修改。Flink 還主要利用內存計算來最小化磁盤通信[17]。

為了實現(xiàn)穩(wěn)健性，它在JVM 中實現(xiàn)了自己的內存管理，嘗試通過溢出到磁盤來防止內存錯誤，減少垃圾回收壓力等。系統(tǒng)不對鍵值對進行操作，但對于某些操作員（如分組）需要“虛擬”鍵。它處理任意數(shù)據(jù)類型，并通過簡化鍵控（如基于元組索引或對象屬性）為元組和對象提供額外支持。它的核心API 支持一組轉換，這些轉換與Apache Spark 的核心API 大致類似。

2.2 Flink 生態(tài)系統(tǒng)

社區(qū)正在努力支持catalog、schema registries 以及metadata stores，包括API 和SQL 客戶端的支持，并且正在添加數(shù)據(jù)定義語言（Data Definition Language，DDL）支持，以便能方便地添加表和流到catalog中[18]。還有一個巨大的工作是集成Flink 與Hive 生態(tài)系統(tǒng)。Flink 和Hadoop、Spark 一樣，是Apache軟件基金會下的頂級項目，所以Flink 也有屬于自己的生態(tài)系統(tǒng)，基本框架如圖5 所示。

圖5 Flink 生態(tài)系統(tǒng)

Flink 框架圖從下到上有部署層、核心層、庫和API 接口。其中，接口層提供CEP 復雜事件處理接口，主要是獲取大量流數(shù)據(jù)中的重要信息。Flink和Sprak 一樣，提供一個機器學習的庫，里面包含許多數(shù)據(jù)挖掘的算法和機器學習的算法，支持向量機、回歸問題、k-means 等一些常用算法。Gelly 庫里面的函數(shù)用于解決大量圖形計算?，F(xiàn)在主流的大數(shù)據(jù)處理引擎都支持類SQL 語言，Table API 提供流處理及批處理中使用的SQL 語言，將SQL 嵌入Flink，滿足用戶從數(shù)據(jù)庫中提取數(shù)據(jù)做分析。核心的兩個接口是DataStream API 和DataSet API。在流處理場景中，使用DataStream API 接口對數(shù)據(jù)進行有狀態(tài)的計算，最后輸出到本地文件系統(tǒng)或者分布式文件系統(tǒng)HDFS。而DataSet API 接口應用于批處理場景中，將批數(shù)據(jù)作為流數(shù)據(jù)的極限特例進行數(shù)據(jù)分析。可以將Flink 部署到云，也可以使用單機模式。

3 Hadoop 與Flink 特性分析

3.1 Hadoop 技術優(yōu)勢

Hadoop 是一個能夠對大量數(shù)據(jù)進行分布式處理的軟件框架，且是以一種可靠、高效、可伸縮的方式進行處理的[19]。MapReduce 是與Flink 相對應的大數(shù)據(jù)編程框架，因此下面將主要闡述MapReduce的技術優(yōu)勢。

3.1.1 可讀性

開發(fā)者將整個MapReduce 非常復雜的并行計算過程高度抽象成兩個函數(shù)，一個是Map 函數(shù)，另一個是Reduce 函數(shù)。整個框架核的核心設計是這兩個函數(shù)，所以極大地降低了分布式并行編程的難度[19]。

3.1.2 可擴展性

整個集群可以動態(tài)地隨意增加或者減少相關的計算節(jié)點，不需要高端的機器，只需要普通廉價的PC 機即可。

3.1.3 高可靠性

采用典型的非共享式架構，使得在整個集群中每個節(jié)點都擁有自己的內存。任何一個節(jié)點出現(xiàn)問題，不會影響到其他節(jié)點正常運行。此外，整個集群設計了冗余和容錯機制。

3.2 Hadoop 技術劣勢

3.2.1 抽象層次低

實際開發(fā)過程中，許多的業(yè)務邏輯沒有辦法從更高層撰寫相關的邏輯代碼，需要去最底層人工進行編碼。即使是完成一個非常簡單的任務，都需要編寫一個完整的MapReduce 代碼，然后編譯打包運行。

3.2.2 表達能力有限

現(xiàn)實中一些實際的問題沒有辦法用Map 和Reduce 兩個函數(shù)完成相關任務。

3.2.3 執(zhí)行迭代操作效率低

對于MapReduce 來說，它本身將整個作業(yè)劃分成多個階段進行，每一個階段完成后將結果寫入分布式文件系統(tǒng)HDFS，供下一個MapReduce 作業(yè)階段調用。這樣高代價的磁盤I/O，造成了執(zhí)行迭代操作效率低[20]。

3.2.4 資源浪費

整個任務執(zhí)行嚴格劃分階段（Map 階段和Reduce 階段），要求所有的Map 任務都處理完成后才能開始Reduce 任務階段。這樣Reduce 任務的結點一直處于空閑狀態(tài)，導致資源的浪費。

3.2.5 實時性差

MapReduce 計算框架是針對批處理設計的，因此在實時交互查詢應用中一般很難實現(xiàn)。

3.3 Flink 技術優(yōu)勢

Flink 以流數(shù)據(jù)處理為核心，借鑒MapReduce計算框架存在的諸多問題，設計彌補了MapReduce不能處理實時計算的局限，因此它的優(yōu)勢極為明顯。

（1）Flink 擅長處理無界和有界數(shù)據(jù)集。精確控制時間和狀態(tài)，使Flink 的運行能夠在無界流上運行任何類型的應用程序[21]。有界流由算法和數(shù)據(jù)結構內部處理，這些算法和數(shù)據(jù)結構專為固定大小的數(shù)據(jù)集而設計，從而擁有出色的性能。

（2）Flink 最明顯的優(yōu)勢在于充分利用內存中的性能，將任務狀態(tài)始終保留在內存中，如果狀態(tài)大小超過可用內存，則保存在訪問高效的磁盤上的數(shù)據(jù)結構中。因此，任務通過訪問本地（通常是內存中）狀態(tài)來執(zhí)行所有計算，從而產生非常低的處理延遲。Flink 通過定期和異步地將本地狀態(tài)檢查點持久存儲來保證出現(xiàn)故障時一次性狀態(tài)一致性[22]。

（3）Flink 旨在以任何規(guī)模運行有狀態(tài)流應用程序。應用程序并行化為數(shù)千個在集群中分布和同時執(zhí)行的任務，因此應用程序可以利用幾乎無限量的CPU、主內存、磁盤和網絡IO。Flink 很容易保持非常大的應用程序狀態(tài)，其異步和增量檢查點算法可確保對處理延遲的影響最小，同時保證一次性狀態(tài)一致性。

（4）Flink 是一個分布式系統(tǒng)，需要計算資源才能執(zhí)行應用程序。Flink 可與所有常見的集群資源管理器（如Hadoop YARN、Apache Mesos 和Kubernetes）集成，也可以設置為獨立集群運行[23]。Flink 旨在很好地運作以前列出的每個資源管理器。這是通過特定于資源管理器的部署模式實現(xiàn)的，這些模式允許Flink 以其慣用方式與每個資源管理器進行交互。

3.4 Flink 技術劣勢

雖然Flink 處理實時數(shù)據(jù)的性能要遠優(yōu)于MapReduce，但大數(shù)據(jù)時代下很多的處理數(shù)據(jù)場景是將過去幾年或者過去幾十年的數(shù)據(jù)從數(shù)據(jù)倉庫中提取出來做批處理。如果這些數(shù)據(jù)量超過內存大小，F(xiàn)link 將不再適用，這時使用MapReduce 做數(shù)據(jù)處理更合適。Flink 近幾年才流行起來，目前尚不成熟，是一款大有前途的軟件，因此目前的一些設計使得其在適用性方面存在一定的局限性。

4 Hadoop 與Flink 應用場景

4.1 Hadoop 應用場景

從MapReduce 的所有長處來看，它基本上是一個批處理系統(tǒng)，并不適合交互式分析，不可能執(zhí)行一條查詢并在幾秒內或更短的時間內得到結果。典型情況下，執(zhí)行查詢需要幾分鐘或者更久。因此，MapReduce 更適合沒有用戶在現(xiàn)場等待查詢結果的離線使用場景。然而，從最初的原型到現(xiàn)在，Hadoop 的發(fā)展已經超越了批處理本身。實際上，“Hadoop”一次有時被用于指代一個更大的、多個項目組成的生態(tài)系統(tǒng)，而不僅是HDFS 和MapReduce。這些項目都屬于分布式計算和大規(guī)模數(shù)據(jù)處理范疇。這些項目中許多都是由Apache 軟件基金會管理。該基金會為開源軟件項目社區(qū)提供支持，所以大多數(shù)應用場景都是用Hadoop 中的分布式文件系統(tǒng)HDFS 或者分布式數(shù)據(jù)庫HBase存儲數(shù)據(jù)，用YARN 做集群資源調度框架，根據(jù)需求使用不同的計算框架處理數(shù)據(jù)。例如，針對大規(guī)模數(shù)據(jù)的批量計算，使用MapReduce、Spark等；針對流數(shù)據(jù)的實時計算，使用Storm、Flink、S4、Flume、Streams、Puma、DStream、Super、Mario 以及銀河流數(shù)據(jù)處理平臺等；針對大規(guī)模圖結構數(shù)據(jù)的處理，使用Pregel、GraphX、Giraph、PowerGraph、Hama 以及GoldenOrb 等；大規(guī)模數(shù)據(jù)的存儲管理和查詢分析，使用Dremel、Hive、Cassandra 以及Impala 等。

Hadoop 設計之初以離線處理大批量的數(shù)據(jù)為主，通過10 年的發(fā)展，其生態(tài)系統(tǒng)技術不斷完善，使得Hadoop 在大多數(shù)基于大規(guī)模離線數(shù)據(jù)處理場景中得到了廣泛應用，主要包括ETL、日志分析、數(shù)據(jù)挖掘與機器學習等場景。

4.1.1 ETL

要想使MapReduce 處理得數(shù)據(jù)更加準確，首先得保證其處理的數(shù)據(jù)不是“臟數(shù)據(jù)”。大型企業(yè)使用數(shù)據(jù)倉庫存放歷史數(shù)據(jù)，在實際開發(fā)中這些原始數(shù)據(jù)不能達到存儲規(guī)范，所以需要對存入數(shù)據(jù)倉庫數(shù)據(jù)進行預處理，即數(shù)據(jù)的抽取、轉換和裝載（Extract-Transform-Load，ETL）[24]。當前主流的ETL 抽取方式是基于MapReduce 的并行ETL。由Bala[25]帶頭開發(fā)一套與傳統(tǒng)ETL 工具相比性能更好的且基于MapReduce 并行計算框架的數(shù)據(jù)倉庫ETL 平臺；而Zhang[26]等人實現(xiàn)了ETL 處理Web頁面也是基于MapReduce 框架；Li[27]率先將基于MapReduce 思想的ETL 應用在種子篩選的生活實際問題上，取得了不錯的結果；Priya[28]的團隊開發(fā)了基于MapReduce 的ETL 工具進行識別，成績斐然?？偠灾?，MapReduce 在ETL 場景中優(yōu)勢明顯。

4.1.2 日志分析

日志分析是大數(shù)據(jù)處理場景中的典型案例之一。2009 年谷歌計算機工程師通過分析海量的用戶查詢日志，對冬季流感的傳播趨勢進行了準確預測,其中MapReduce 起著決定性作用。Dewangan 的團隊[29]利用MapReduce 編程模型對事物日志文件進行分析，證明了事物日志系統(tǒng)上應用MapReduce計算的優(yōu)勢。MaRAOS 是Chen 團隊[30]開發(fā)的新框架，框架是Web 日志分析下的離線流數(shù)據(jù)的處理。Xhafa[31]利用MapReduce，通過對諸多類型日志的分析，揭示了Hadoop 處理海量日志數(shù)據(jù)的潛力。簡而言之，日志分析是大數(shù)據(jù)分析不可或缺的部分，充分利用MapReduce 對離線日志進行有效的分析，為企業(yè)決策提供參考。

4.1.3 數(shù)據(jù)挖掘與機器學習

因為Hadoop 是針對大規(guī)模批量數(shù)據(jù)處理，所以在數(shù)據(jù)挖掘或者是統(tǒng)計機器學習的應用場景下占有一席之地。因為每次都要將中間結果寫入本地磁盤，所以迭代效率低下。Hadoop 下的機器學習Mahout 組件在Spark 提出了其機器學習算法庫MLIib 停止更新，所以機器學習的應用場景更多使用的是Spark中的MLlib 組件。Flink 中也有自己的機器學習組件FLinkML，所以數(shù)據(jù)挖掘與機器學習的場景不建議使用Mahout，建議使用Spark 中的MLib。

4.1.4 數(shù)據(jù)采集與處理場景

MapReduce 能夠有效支持爬蟲技術，包括增量爬蟲的實現(xiàn)。所以，Cafarella 的團隊[32]實現(xiàn)了MapReduce 主要算法對Nutch 提供計算支持，成為Nutch 的標準計算引擎。Li 團隊[33]利用MapReduce框架進行網頁評分的計算，得到用戶偏好音樂的推薦；Zhang 等人[34]通過收集微博數(shù)據(jù)，在Nutch 框架下利用MapRedcue 分析微博站點的特色。可見，MapReduce適合應用于大規(guī)模數(shù)據(jù)采集的應用場景。

4.2 Flink 應用場景

Flink 因其豐富的功能集而成為開發(fā)和運行多種不同類型應用程序的絕佳選擇。Flink 的功能包括支持流和批處理、復雜的狀態(tài)管理、事件時處理語義以及狀態(tài)的一次性一致性保證[35]。此外，F(xiàn)link可以部署在各種資源提供者（如YARN、Apache Mesos 和Kubernetes）上，也可以作為裸機硬件上的獨立群集。配置為高可用性，F(xiàn)link 沒有單點故障。Flink 已被證明可擴展到數(shù)千個核心和太字節(jié)的應用程序狀態(tài)，提供高吞吐量和低延遲，并為世界上最苛刻的流處理應用程序提供支持。Flink 將數(shù)據(jù)產生當做流處理，擅長處理有界流和無界流。

4.2.1 流數(shù)據(jù)處理場景

Flink 將流數(shù)據(jù)[36]定義成無界流。無界流有一個開始但沒有定義的結束。它們不會在生成時終止并提供數(shù)據(jù)。必須連續(xù)處理無界流，即必須在攝取事件后立即處理事件。無法等待所有輸入數(shù)據(jù)到達，因為輸入是無界的，且在任何時間點都不會完成。處理無界數(shù)據(jù)通常要求以特定順序攝取事件，如事件發(fā)生的順序，以便能夠推斷結果完整性。Flink 中的DataStream程序是實現(xiàn)數(shù)據(jù)流轉換的常規(guī)程序（如過濾、更新狀態(tài)、定義窗口以及聚合）[37]，最初從各種源（如消息隊列、套接字流、文件）創(chuàng)建數(shù)據(jù)流，結果通過接收器返回，接收器可以將數(shù)據(jù)寫入文件或標準輸出（如命令行終端）。DataStream 程序可以在各種環(huán)境中運行，或獨立運行或嵌入其他程序中[38]。執(zhí)行可以在本地JVM 中執(zhí)行，也可以在許多計算機的集群上執(zhí)行。

4.2.2 批數(shù)據(jù)處理場景

Flink 將批數(shù)據(jù)[39]定義成有界流，具有定義的開始和結束。Flink 建立在DataSets（特定類型的元素集合，其上定義了隱式類型參數(shù)的操作）、作業(yè)圖和Con-tracts（PACTs）。作業(yè)圖表示具有任意任務的并行數(shù)據(jù)，消耗和產生數(shù)據(jù)流。PACT 是二階函數(shù)，用于定義其相關用戶定義（一階）函數(shù)（User-Defined Function，UDF）的輸入/輸出數(shù)據(jù)的屬性。這些屬性進一步用于并行化UDF 的執(zhí)行并應用優(yōu)化規(guī)則[40]，可以在執(zhí)行任何計算前通過攝取所有數(shù)據(jù)來處理有界流。處理有界流不需要有序攝取，因為可以始終對有界數(shù)據(jù)集進行排序。Flink中的DataSet 程序是實現(xiàn)數(shù)據(jù)集轉換的常規(guī)程序，如過濾、映射、連接以及分組等。數(shù)據(jù)集最初是從某些來源創(chuàng)建的，如通過讀取文件或從本地集合創(chuàng)建，結果通過接收器返回，接收器可以將數(shù)據(jù)寫入（分布式）文件系統(tǒng)或標準輸出（如命令行終端）。DataSet 程序可以在各種環(huán)境中運行，或獨立運行或嵌入其他程序。執(zhí)行可以在本地JVM 中執(zhí)行，也可以在許多計算機的集群上執(zhí)行。

4.2.3 數(shù)據(jù)挖掘與機器學習

Flink 在2014 年才成為Apache 基金會的頂級項目，社區(qū)正在為其開發(fā)適合自己的FLinkML 的機器學習組件。所以，F(xiàn)linkML 相對于Hadoop 中的Mhout 組件和Spark 中MLlib 不是很成熟，在數(shù)據(jù)挖掘、機器學習場景中還是使用成熟的Spark MLlib或者Hadoop 的Mhout 組件。Flink 在Terasort 算法和KMeans 上表現(xiàn)良好，編碼工作量最小，而在更復雜的MDS 算法上表現(xiàn)不佳[41]。大量的機器學習算法屬于K-Means 和Terabyte 排序復雜度，并且可以在這些平臺中有效實現(xiàn)它們。對于更復雜的算法，需要改進這些框架以支持算法要求。例如，F(xiàn)link需要高效的通信算法擴展需要緊密同步和集體通信的復雜機器學習算法。目前，F(xiàn)link 主要是做流處理和批處理[42]。

4.2.4 圖計算

從大類來看，根據(jù)圖是否有方向，可以將圖分為有向圖（Directed Graph）和無向圖（Undirected Graph）[43]。Gelly 是Flink 的Graph API[44]，包 含一組方法和實用程序，旨在簡化Flink 中圖形分析應用程序的開發(fā)。在Gelly 中，可以使用與批處理API 提供的類似的高級函數(shù)轉換和修改圖形。Gelly 提供了創(chuàng)建、轉換和修改圖形的方法以及圖形算法庫[45]。

4.3 應用場景總結

針對以上應用場景對比分析，得出Hadoop 與Flink 并不能適應所有的應用場景。所以，表2 給出了Hadoop 與Flink 的適用場景總結。

表2 Hadoop 與Flink 場景適用性總結

5 結語

本文從Hadoop 與Flink 的技術原理及其生態(tài)系統(tǒng)出發(fā)，重點分析Flink 與MapReduce 各自適用的應用場景特性，通過對比分析兩種不能完全適用所有的大數(shù)據(jù)處理應用場景。所以，面對大數(shù)據(jù)環(huán)境下日益增長的數(shù)據(jù)處理需求，實際應用場景中數(shù)據(jù)處理非常復雜。為了解決實際問題，需要將Hadoop與Flink 聯(lián)合使用，這是當前大數(shù)據(jù)解決方案的發(fā)展趨勢。