當前這個數據時代，各領域各業務場景時時刻刻都有大量的數據產生，如何理解大數據，對這些數據進行有效的處理成為很多企業和研究機構所面臨的問題。本文將從大數據的基礎特性開始，進而解釋分而治之的處理思想，最後介紹一些流行的大數據技術和組件，讀者能夠通過本文了解大數據的概念、處理方法和流行技術。

來源：Carlos Muza on Unsplash

什麼是大數據？

大數據，顧名思義，就是擁有龐大體量的數據。關於什麼是大數據，如何定義大數據，如何使用大數據等一系列問題，不同領域背景的朋友理解各不相同。IBM將大數據歸納為5個V[^1]，涵蓋了大數據絕大多數的特性。

• Volume：數據量大，從TB（1,024 GB）、PB（1,024 TB）、EB（1,024 PB）、ZB（1,024 EB）甚至到YB（1,024 ZB）。紐約證交所每天產生的交易數據大約在TB級，瑞士日內瓦附近的大型強子對撞機每年產生的數據約為PB級，而目前全球數據總量已經在ZB級，相當於 1,000,000 PB，也就是大家更熟悉的10億 TB。基於更大規模的數據，我們可以對某個研究對象的歷史、現狀和未來有更加全面的瞭解。
• Velocity：數據產生速度快，所要求的處理速度和時效性高，因為時間就是金錢。金融市場的交易數據必須以秒級的速度進行處理，搜索和推薦引擎需要在分鐘級將實時新聞推送給用戶。更快的數據處理速度，讓我們基於最新的數據上做更加實時的決策。
• Variety：數據類型繁多，包括數字、文字、圖片、視頻等不同的數據形式，也包括來自社交網絡、視頻網站、可穿戴設備以及各類傳感器的數據。數據可能是Excel裡高度結構化的數據，也可能是圖片和視頻這種非結構化的數據。
• Veracity：數據真實性。一方面，數據並非天然具有高價值，一些異常值會被摻雜進來，例如，統計偏差、人的情感影響、天氣、經濟因素甚至謊報數據等。另一方面，數據源類型不同，數據源多樣，如何將這些多元異構數據連接、匹配、清洗和轉化，形成具有高置信度的數據是一項非常有挑戰的工作。
• Value：數據價值。我們研究和利用大數據的最終目的是提供更有價值的決策支持，基於以上提到的四個V，挖掘大數據的深層價值。

在數據分析領域，研究對象的全部被稱為總體（Population），總體包含大量的數據，甚至說數據可能是無限的。比如調查15個國家的國民的誠信情況，所有國民是總體。很多情況下，我們無法保證能收集和分析總體的所有數據，因此研究者一般基於研究對象的一個子集進行數據分析。樣本（Sample）是從總體中抽取的個體，是研究對象的子集，通過對樣本的調查和分析，研究者可以推測總體的情況。在誠信調查的案例中，我們可以在每個國家抽取一部分國民作為樣本，以此推測該國國民的誠信水平。

在大數據技術成熟之前，受限於數據收集、存儲和分析能力，樣本數量相對較小，大數據技術的出現讓數據存儲和分析能力不再是瓶頸，研究者可以在更大規模的數據上，以更快地速度進行數據分析。但數據並非天然有價值，如何讓數據點石成金非常有挑戰。在誠信調查中，如果我們直接詢問樣本對象：“你是否謊報了自己和家庭的資產以獲取更大的金融借貸額度？”十之八九，我們得不到真實的答案，但我們可以綜合多種渠道來分析該問題，比如結合樣本對象的工作經歷、徵信記錄等數據。

可見，大數據具有更大的數據量、更快的速度、更多的數據類型的特點。在一定的數據真實性基礎上，大數據技術最終為數據背後的價值服務。

隨著大數據技術的發展，數據的複雜性越來越高，有人在這5個V的基礎上，又提出了一些補充，比如增加了動態性（Vitality），強調整個數據體系的動態性；增加了可視性（Visualization），強調數據的顯性化展現；增加了合法性（Validity），強調數據採集和應用的合法性，特別是對於個人隱私數據的合理使用等；增加了數據在線（Online），強調數據永遠在線，能隨時調用和計算。

分佈式計算 分而治之

計算機誕生之後，一般是在單臺計算機上處理數據。大數據時代到來後，一些傳統的數據處理方法無法滿足大數據的處理需求，將一組計算機組織到一起形成一個集群，利用集群的力量來處理大數據的工程實踐逐漸成為主流方案。這種使用集群進行計算的方式被稱為分佈式計算，當前幾乎所有的大數據系統都是在集群進行分佈式計算。

分而治之的算法思想

分佈式計算的概念聽起來很高深，其背後的思想十分樸素，即分而治之（Divide and Conquer），又被稱為分治法。分治法將一個原始問題分解為子問題，多個子問題分別在多臺機器上求解，藉助必要的數據交換和合並策略，將子結果彙總即可求出最終結果。具體而言，不同的分佈式計算系統所使用的算法和策略根據所要解決的問題各有不同，但基本上都是將計算拆分，把子問題放到多臺機器上，分而治之地計算求解。分佈式計算的每臺機器（物理機或虛擬機）又被稱為一個節點。

分佈式計算在科研界已經有很多比較成熟的方案，其中比較有名的有消息傳遞接口（Message Passing Interface，MPI）和MapReduce。

MPI

MPI是一個老牌分佈式計算框架，主要解決節點間數據通信的問題。在前MapReduce時代，MPI是分佈式計算的業界標準。MPI程序現在依然廣泛運行在全球各大超級計算中心、大學、政府和軍隊下屬研究機構中，許多物理、生物、化學、能源、航空航天等基礎學科的大規模分佈式計算都依賴MPI。

分治法將問題切分成子問題，在不同節點上分而治之地求解，MPI提供了一個在多進程多節點間進行數據通信的方案，因為絕大多數情況下，在中間計算和最終合併的過程中，需要對多個節點上的數據進行交換和同步。

MPI並行計算示意圖

MPI中最重要的兩個操作為數據發送（Send）和數據接收（Recv），Send表示將本進程中某塊數據發送給其他進程，Recv表示接收其他進程的數據。上圖展示了MPI架構在4臺服務器上並行計算的示意圖。在實際的代碼開發過程中，用戶需要自行設計分治算法，將複雜問題切分為子問題，手動調用MPI庫，將數據發送給指定的進程。

MPI能夠在很細的粒度上控制數據的通信，這是它的優勢，同時也是它的劣勢，因為細粒度的控制意味著從分治算法設計到數據通信到結果彙總都需要編程人員手動控制。有經驗的程序員可以對程序進行底層優化，取得成倍的速度提升。但如果對計算機和分佈式系統沒有太多經驗，編碼、調試和運行MPI程序的時間成本極高，加上數據在不同節點上不均衡和通信延遲等問題，一個節點進程失敗將會導致整個程序失敗，因此，MPI對於大部分程序員來說簡直就是噩夢。

並非所有的編程人員都能熟練掌握MPI編程，衡量一個程序的時間成本，不僅要考慮程序運行的時間，也要考慮程序員學習、開發和調試的時間。就像C語言運算速度極快，但是Python語言卻更受歡迎一樣，MPI雖然能提供極快的分佈式計算加速，但不太接地氣。

MapReduce

為了解決分佈式計算學習和使用成本高的問題，研究人員提出了更簡單易用的MapReduce編程模型[^2]。MapReduce是Google 2004年提出的一種編程範式，比起MPI將所有事情交給程序員控制不同，MapReduce編程模型只需要程序員定義兩個操作：map和reduce。

使用MapReduce製作三明治

網絡上有很多MapReduce的介紹和解釋，這裡我們用三明治的製作過程對MapReduce進行了分解。假設我們需要大批量地製作三明治，三明治的每種食材可以分別單獨處理，map階段將原材料在不同的節點上分別進行處理，生成一些中間食材，shuffle階段將不同的中間食材進行組合，reduce最終將一組中間食材組合成為三明治成品。可以看到，這種map + shuffle + reduce的方式就是分而治之思想的一種實現。

基於MapReduce編程模型，不同的團隊分別實現了自己的大數據框架：Hadoop是最早的一種開源實現，如今已經成為大數據領域的業界標杆，之後又出現了Spark和Flink。這些框架提供了編程接口和API，輔助程序員存儲、處理和分析大數據。

比起MPI，MapReduce編程模型將更多的中間過程做了封裝，程序員只需要將原始問題轉化為更高層次的API，至於原始問題如何切分為更小的子問題、中間數據如何傳輸和交換、如何將計算伸縮擴展到多個節點等一系列細節問題可以交給大數據框架來解決。因此，MapReduce相對來說學習門檻更低，使用更方便，編程開發速度更快。

批處理和流處理

數據與數據流

在大數據的5V定義中我們已經提到，數據的容量大且產生速度快。從時間維度上來講，數據源源不斷地產生，形成一個無界的數據流（Unbounded Stream）。例如我們每時每刻的運動數據都會累積到手機傳感器上，金融交易隨時隨地發生著，傳感器會持續監控並生成數據。數據流中的某段有界數據流（Bounded Stream）可以組成一個數據集。我們通常所說的對某份數據進行分析，指的是對某個數據集進行分析。隨著數據的產生速度越來越快，數據源越來越多，人們對時效性的重視程度越來越高，如何處理數據流成了大家更為關注的問題。

數據與數據流

批處理

批處理（Batch Processing）是對一批數據進行處理。我們身邊批量計算比比皆是，最簡單的批量計算例子有：微信運動每天晚上有一個批量任務，把用戶好友一天所走的步數統計一遍，生成排序結果後推送給用戶；銀行信用卡中心每月賬單日有一個批量任務，把一個月的消費總額統計一次，生成用戶月度賬單；國家統計局每季度對經濟數據做一次統計，公佈季度GDP增速。可見，批量任務一般是對一段時間的數據聚合後進行處理。對於數據量龐大的應用，如微信運動、銀行信用卡等情景，一段時間內積累的數據總量非常大，計算非常耗時。

批量計算的歷史可以追溯的計算機剛剛起步的上世紀60年代，當前應用最為廣泛的當屬數據倉庫的ETL（Extract Transform Load）數據轉化工作，如以Oracle為代表的商業數據倉庫和以Hadoop/Spark為代表的開源數據倉庫。

流處理

如前文所說，數據其實是以流（Stream）的方式持續不斷地產生著，流處理（Stream Processing）就是對數據流進行處理。時間就是金錢，對數據流進行分析和處理，獲取實時數據價值越發重要。個人用戶每晚看一次微信運動排名覺得是一個比較舒適的節奏，但是對於金融界來說，時間是以百萬、千萬甚至上億為單位的金錢！雙十一電商大促銷，管理者要以秒級的響應時間查看實時銷售業績、庫存信息以及與競品的對比結果，以爭取更多的決策時間；股票交易要以毫秒級的速度來對新信息做出響應；風險控制要對每一份欺詐交易迅速做出處理，以減少不必要的損失；網絡運營商要以極快速度發現網絡和數據中心的故障等等。以上這些場景，一旦出現故障，造成了服務的延遲，損失都難以估量，因此，響應速度越快，越能減少損失，增加收入。而IoT物聯網和5G通信的興起將為數據生成提供更完美的底層技術基礎，海量的數據在IoT設備上採集生成，並通過更高速的5G通道傳輸到服務器，更龐大的實時數據流將洶湧而至，流式處理的需求肯定會爆炸式增長。

代表性大數據技術

如前文所述，MapReduce編程模型的提出為大數據分析和處理開創了一條先河，之後陸續湧現出了Hadoop、Spark和Flink等大數據框架。

Hadoop

2004年，Hadoop的創始人受MapReduce編程模型等一系列論文的啟發，對論文中提及的思想進行了編程實現。Hadoop的名字來源於創始人Doug Cutting兒子的玩具大象。由於創始人Doug Cutting當時加入了雅虎，並在此期間支持了大量Hadoop的研發工作，因此Hadoop也經常被認為是雅虎開源的一款大數據框架。時至今日，Hadoop不僅僅是整個大數據領域的先行者和領導者，更形成了一套圍繞Hadoop的生態系統，Hadoop和它的生態是絕大多數企業首選的大數據解決方案。

Hadoop生態

儘管Hadoop生態中的組件眾多，其核心組件主要有三個：

• Hadoop MapReduce：Hadoop版本的MapReduce編程模型，可以處理海量數據，主要面向批處理。
• HDFS：HDFS全稱為Hadoop Distributed File System，是Hadoop提供的分佈式文件系統，有很好的擴展性和容錯性。
• YARN：YARN是Yet Another Resource Negotiator的縮寫，是Hadoop生態系統中的資源調度器，可以管理一個Hadoop集群，併為各種類型的大數據任務分配計算資源。

這三大組件中，數據存儲在HDFS上，由MapReduce負責計算，YARN負責集群的資源管理。除了三大核心組件，Hadoop生態圈還有很多其他著名的組件：

• Hive：藉助Hive，用戶可以編寫SQL語句來查詢HDFS上的結構化數據，SQL會被轉化成MapReduce執行。
• HBase：HDFS上的數據量非常龐大，但訪問和查詢速度比較慢，HBase可以提供給用戶毫秒級的實時查詢服務，是一個基於HDFS的分佈式數據庫。
• Storm：Strom是一款實時計算框架，主要負責流處理。
• Zookeeper：Hadoop生態圈很多組件使用動物來命名，形成了一個大型動物園，Zookeeper是這個動物園的管理者，主要負責分佈式環境的協調。

Spark

Spark於2009年誕生於加州大學伯克利分校，2013年被捐獻給Apache基金會。Spark是一款大數據計算框架，其初衷是改良Hadoop MapReduce的編程模型和執行速度。與Hadoop相比，Spark的改進主要有兩點：

• 易用性：比起MPI，MapReduce模型更友好，但仍然不夠方便，因為並不是所有計算任務都可以簡單拆分成map和reduce，有可能為了解決一個問題，要設計多個MapReduce任務，任務之間相互依賴，整個程序非常複雜，導致代碼的可讀性差。Spark提供更加方便易用的接口，提供Java、Scala、Python和R幾種語言的API，支持SQL、機器學習和圖計算，覆蓋了絕大多數大數據計算的場景。
• 速度快：Hadoop的map和reduce之間的中間結果都需要落地到磁盤上，而Spark儘量將大部分計算放在內存中，加上Spark的有向無環圖優化，在官方的基準測試中，Spark比Hadoop快一百倍以上。

Spark生態

Spark的核心在於計算，主要目的在於優化Hadoop MapReduce計算部分，在計算層面提供更細緻的服務，比如提供了常用幾種數據科學語言的API，提供了SQL、機器學習和圖計算支持，這些服務都是最終面向計算的。Spark並不能完全取代Hadoop，實際上，Spark融入到了Hadoop生態圈，成為其中的重要一元。一個Spark任務很可能依賴HDFS上的數據，向YARN來申請計算資源，將HBase作為輸出結果的目的地。當然，Spark也可以不用依賴這些Hadoop組件，獨立地完成計算。

Spark Streaming數據流示意圖

Spark主要面向批處理需求，因其優異的性能和易用的接口，Spark已經是批處理界絕對的王者。Spark Streaming提供了流處理的功能，它的流處理主要基於mini-batch的思想，即將輸入數據流拆分成多個批次，每個批次使用批處理的方式進行計算。因此，Spark是一款批量和流式於一體的計算框架。

Flink

Flink是由德國幾所大學發起的的學術項目，後來不斷髮展壯大，並於2014年末成為Apache頂級項目。Flink主要面向流處理，如果說Spark是批處理界的王者，那麼Flink就是流處理領域的冉冉升起的新星。在Flink之前，不乏流式處理引擎，比較著名的有Storm、Spark Streaming，但某些特性遠不如Flink。

流處理框架演進史

第一代被廣泛採用的流處理框架是Strom。在多項基準測試中，Storm的數據吞吐量和延遲都遠遜於Flink。Storm只支持"at least once"和"at most once"，即數據流裡的事件投遞只能保證至少一次或至多一次，不能保證只有一次。對於很多對數據準確性要求較高的應用，Storm有一定劣勢。第二代非常流行的流處理框架是Spark Streaming。Spark Streaming使用mini-batch的思想，每次處理一小批數據，一小批數據包含多個事件，以接近實時處理的效果。因為它每次計算一小批數據，因此總有一些延遲。但Spark Streaming的優勢是擁有Spark這個靠山，用戶從Spark遷移到Spark Streaming的成本較低，因此能給用戶提供一個批量和流式於一體的計算框架。

Flink是與上述兩代框架都不太一樣的新一代計算框架，它是一個支持在有界和無界數據流上做有狀態計算的大數據引擎。它以事件為單位，並且支持SQL、State、WaterMark等特性。它支持"exactly once"，即事件投遞保證只有一次，不多也不少，這樣數據的準確性能得到提升。比起Storm，它的吞吐量更高，延遲更低，準確性能得到保障；比起Spark Streaming，它以事件為單位，達到真正意義上的實時計算，且所需計算資源相對更少。

之前提到，數據都是以流的形式產生的。數據可以分為有界（bounded）和無界（unbounded），批量處理其實就是一個有界的數據流，是流處理的一個特例。Flink基於這種思想，逐步發展成一個可支持流式和批量處理的大數據框架。

經過幾年的發展，Flink的API已經非常完善，可以支持Java、Scala和Python，並且支持SQL。Flink的Scala版API與Spark非常相似，有Spark經驗的程序員可以用一個小時的時間熟悉Flink API。

與Spark類似，Flink目前主要面向計算，並且可以與Hadoop生態高度集成。Spark和Flink各有所長，也在相互借鑑，一邊競爭，一邊學習，究竟最終誰能一統江湖，我們拭目以待。

小結

大數據一般基於分而治之的思想，分佈式地進行計算。經過十幾年的發展，大數據生態圈湧現出一大批優秀的組件和框架，這些組件對一些底層技術做了封裝，提供給程序員簡單易用的API接口。在大數據分析和處理領域，Hadoop已經發展成為一個非常成熟的生態圈，涵蓋了很多大數據相關的基礎服務，Spark和Flink主要針對大數據計算，分別在批處理和流處理方向建立了自己的優勢。

閱讀更多 皮皮魯的AI星球 的文章

關鍵字: 電腦 分佈式計算 大數據