大資料的歷史

2018年9月30日，中國網際網路巨頭騰訊公司的總裁劉熾平發出一封全員信，正式啟動了公司歷史上第三次重大組織架構調整，外界解讀騰訊此舉是為了把人工智慧、大資料和雲端計算提升到更核心的戰略位置，其實不止騰訊，谷歌、亞馬遜、阿里巴巴、百度、小米等網際網路巨頭近年來都在調整組織架構，這些種種都是為了適應已經無法迴避的ABC時代的到來。所謂ABC 是指以A（AI，人工智慧）、B（Big Data，大資料）、C（Cloud，雲端計算）為代表的產業趨勢和技術變革。業界普遍認為這將是繼PC時代、移動網際網路時代後的又一次產業變革，標誌著一個全新的時代已經來臨。這其中雲端計算（C）將會像我們日常生活中的水和電一樣，作為整個網際網路的底層基礎設施提供服務，為企業的資料資產提供保管、訪問的場所和渠道。有了基礎設施但對企業來說只有資料才是真正有價值的資產，這裡說的資料包括企業內部的經營資訊、網際網路中的商品資訊、聊天軟體中人與人的溝通訊息、位置資訊等等，這些資料的數量將遠遠超過企業現有的IT架構和基礎設施的承載能力，隨之而來的是企業應用的實時性要求也將大大超越現有的計算能力。如何盤活使用這些極具價值的資料資產，讓它們能為國家治理、企業決策和個人生活服務，正是大資料處理的核心，也是雲端計算內在的靈魂和必然的升級方向。

隨著這股趨勢，最近幾年大資料這個詞也在諸多技術大會上越來越多地被提及。人們用它來描述和定義資訊時代產生的海量資料，並命名與之相關的技術發展與創新。最早提出大資料時代到來的是全球知名諮詢公司麥肯錫，其實大資料在物理學、生物學、環境生態學等領域以及軍事、金融、通訊等行業存在已有時日，只是因近年來網際網路和IT行業的發展而引起人們關注。根據中國資訊通訊研究院結合對大資料相關企業的調研測算，2017年我國大資料產業規模為4700億元人民幣，同比增長30%，預計到2020年產業規模將達到一萬億。（來源：中國資訊通訊研究院，《大資料白皮書(2018)》）

究竟何為大資料？根據研究機構Gartner給出的定義：大資料是需要新處理模式才能具有更強的決策力、洞察發現力和流程優化能力來適應海量、高增長率和多樣化的資訊資產。大資料技術的戰略意義不在於掌握龐大的資料資訊，而在於對這些含有意義的資料進行專業化處理。換言之，如果把大資料比作一種產業，那麼這種產業實現盈利的關鍵，在於提高對資料的“加工能力”，通過“加工”實現資料的“增值”。（來源：搜狗百科）而麥肯錫全球研究所給出的定義是：一種規模大到在獲取、儲存、管理、分析方面大大超出了傳統資料庫軟體工具能力範圍的資料集合，具有海量的資料規模、快速的資料流轉、多樣的資料型別和價值密度低四大特徵。諸多定義中搜狗百科的大資料詞條更得我心：大資料是指無法在一定時間範圍內用常規軟體工具進行捕捉、管理和處理的資料集合，是需要新處理模式才能具有更強的決策力、洞察發現力和流程優化能力的海量、高增長率和多樣化的資訊資產。

被譽為“大資料商業應用第一人”的維克托·邁爾·舍恩伯格認為大資料是指不用隨機分析法（比如抽樣調查）這樣的捷徑，而是採用對所有資料進行分析處理的方式，大資料的核心就是預測，它將為人類的生活創造前所未有的可量化的維度。他認為大資料時代最大的轉變就是，放棄對因果關係的渴求，而取而代之關注相關關係。也就是說只要知道“是什麼”，而不需要知道“為什麼”。這就顛覆了千百年來人類的思維慣例，對人類的認知和與世界交流的方式提出了全新的挑戰（來源：《大資料時代》作者訪華 與田溯寧對話大資料_網易科技）。這些用IBM的總結就是5V特點：Volume（大量）、Velocity（高速）、Variety（多樣）、Value（低價值密度）、Veracity（真實性）。大資料技術的戰略意義不在於掌握龐大的資料資訊，而在於對這些含有意義的資料進行專業化處理。換而言之，如果把大資料比作一種產業，那麼這種產業實現盈利的關鍵，在於提高對資料的“加工能力”，通過“加工”實現資料的“增值”。

從技術發展歷史看，可以把大資料處理劃分為前身、產生、和應用三階段。從上個世紀的90年代一直到本世紀初，可以說是大資料處理的前身，那時的資料儲存和處理的主流還是在資料庫上，隨著資料庫技術和資料探勘理論的日漸成熟，資料倉儲和資料探勘技術開始逐步發展起來，各種商業智慧工具開始被應用，比如資料倉儲、專家系統、知識管理系統等等。

隨著網際網路各種新業務的出現，各類非結構化的資料大量湧現，使傳統的資料庫技術越來越難以應對。例如Facebook的流行使得社交類應用產生的大量非結構化資料，眾所周知的 Google 公司其搜尋引擎業務天然要面對日益膨脹的海量資料的儲存和處理，這些都帶動了大資料技術的發展進入了快車道。業界一般以 Google 公司在2003到2006年之間釋出的三篇論文作為大資料處理技術產生的起點，分別是：GFS、MapReduce和Bigtable。GFS（2003）是一個可擴充套件的分散式檔案系統，用於對分散式的大量的資料進行訪問，它執行於廉價的普通硬體上，並提供了容錯功能。MapReduce（2004）是處理海量資料的並行程式設計模式，用於大規模資料集的並行運算，它能夠充分利用GFS叢集中所有低價伺服器提供的大量CPU，從架構上來說可以看做GFS的補充，它與GFS一道構成了海量資料處理的核心。GFS適合儲存少量的非常大的檔案，但不適合儲存成千上萬的小檔案，為了處理大量的格式化以及半格式化資料，誕生了管理非關係型資料的分散式資料儲存系統BigTable（2006），它的設計目標是快速可靠地處理PB級別的資料，並且能夠部署到上千臺機器上。以這三篇論文為標誌可以看做大資料處理技術的起源。

在大資料處理技術的發展歷程中不得不提的是Hadoop，2005年由Apache軟體基金會主席Doug Cutting在雅虎時建立這個專案是一個針對大資料分析的開源分散式計算平臺，它能夠讓應用安全擴充套件以處理數千個節點以及PB級資料。Hadoop通過構建一個關於MapReduce的開源平臺，無意中建立了一個蓬勃發展的生態系統，其影響力所及的範圍遠遠超出了其最初Hadoop的範圍。在Hadoop社群，工程師可以從早期的GFS和MapReduce論文中改進和擴充套件這些想法，基於此之上產生了許多有用的工具，如Pig、Hive、HBase、Crunch等等。這種開放性是導致整個行業現有思想多樣性的關鍵，同時Hadoop的開放性生態也直接促進了流計算系統發展。隨著網際網路行業的快速發展，生產、使用、處理和分析資料的速度也在以令人難以置信的步伐迅速增加，由社交媒體、物聯網、廣告和遊戲等垂直領域都開始處理正在變得越來越大的資料集。從業務上來看這些行業需要一種接近實時的資料處理和分析，因此像Hadoop這種用於大資料的批處理的傳統框架已不是很適合這些場合。2007年之後陸續啟動了多個開源專案以新的思路來處理來自不止一個資料來源的源源不斷的資料記錄，其中以Apache的眾多專案最為著名，目前這些專案都處於不同的發展階段。

現如今，隨著智慧移動裝置、物聯網等技術的廣泛應用，資料的碎片化、分散式、流媒體特徵更加明顯，大資料技術開始與移動和雲技術相結合，開始向複雜事件處理、圖形資料庫和記憶體計算等方向發展。大資料的概念越來越被垂直行業以及大眾所接受，通過催化新的商業模式使得大資料同傳統行業的邊界變得越來越模糊，大家開始更加關注業務的創新而非技術本身，大資料產業的主題也轉向應用對行業的變革性影響，來到了真正的應用階段。

大資料的發展方向

大資料技術是一種新的技術和架構，致力於以較低的成本、更快速的採集、處理和分析各種超大規模的資料，從中提取對企業有價值的資訊。隨著該技術的蓬勃發展，讓我們處理海量資料更加容易、更加便宜和迅速，成為利用資料的好助手，甚至可以改變許多行業的商業模式。在人工智慧、雲端計算和物聯網的幫助下，即使是複雜的大資料，也可以由普通的資料從業者利用相應的資料分析工具來進行處理。大資料分析已經脫離了熱門IT趨勢標籤，現如今成為了公司業務必須的一部分，它將很快取代黃金成為人類最寶貴的資產之一，在《未來簡史》中講到：“誰擁有資料，誰擁有對資料的解釋權，誰就有可能在未來的競爭中佔得先機”。為了讓讀者快速瞭解有關大資料的最新資訊，下面列出了一些最熱門的大資料趨勢，以推動行業未來發展。以下是摘自阿里雲棲社群翻譯整理的關於大資料值得了解的十大資料發展趨勢

快速增長的物聯網網路

由於物聯網（IoT）技術，智慧手機被用於控制家用電器變得越來越普遍。隨著小米和阿里等智慧裝置在家庭中實現特定任務的自動化的普及，物聯網熱潮也正吸引著很多公司投資於該技術的研發。

更多組織將抓住機會以提供更好的物聯網解決方案，這必然將帶來更多收集大量資料的方法，以及管理和分析資料的方法。業界的研究趨勢是推動更多能夠收集、分析和處理資料的新裝置，比如手環、智慧音響、眼鏡等。

普及的人工智慧技術

人工智慧現在更常用於幫助大公司和小公司改善其業務流程。人工智慧現在可以在執行任務時，能夠比人類更快、更精確，以此減少人為引入的錯誤並改善整體流程，這使得人們能夠更好地專注於更關鍵的任務，並進一步提高服務質量。

人工智慧的快速發展以及較高的薪資吸引著很多開發人員進入該領域，幸運的是，市面上有成熟的人工智慧開發工具箱可供使用，每個人都可以根據實際任務構建相應的演算法，滿足不斷增長的需求。如果個人組織能夠找到將其整合到業務流程中的最有效方式，那麼可能會獲得較大的優勢。

預測分析的興起

大資料分析一直是企業獲得競爭優勢並實現目標的關鍵戰略之一，研究人員使用必要的分析工具來處理大資料並確定某些事件發生的原因。現在，通過大資料進行預測分析可以幫助更好地預測未來可能發生的情況。

毫無疑問，這種策略在幫助分析收集的資訊以預測消費者行為方面非常有效，這允許公司在做相關開發之前瞭解客戶的下一步行動，以確定他們必須採取的措施。資料分析還可以提供更多資料上下文，以幫助瞭解其背後真正的原因。

遷移到雲端的暗資料

尚未轉化為數字格式的資訊稱為暗資料，它是一個目前尚未開發的巨大資料庫。預計這些模擬資料庫將被數字化並遷移到雲端，進而用於對企業有利的預測分析。

首席資料官將發揮更大的作用

現在，大資料越來越成為執行業務戰略中的重要組成部分，首席資料官也在其組織中發揮著更重要的作用。首席資料管們被期待著引導公司走向正確的方向，並採取更積極的方法，這一趨勢為尋求職業發展的資料營銷人員開啟了大門。

量子計算

目前，使用我們現有的的技術分析和解釋大量資料可能需要花費大量時間，如果能在短短几分鐘內同時處理數十億的資料，我們就可以大大縮短處理時間，讓公司有機會做出及時的決策，以達到更理想的效果。

這項艱鉅的任務只能通過量子計算實現，儘管目前量子計算機的研究處於起步階段，但已經有一些公司正在使用量子計算機進行相關實驗，以幫助不同行業的實踐和理論研究。之後不久，谷歌、IBM和微軟等大型科技公司都將開始測試量子計算機，將它們整合到業務流程中。

開源解決方案

目前，有許多可用的公共資料解決方案，例如開源軟體，它們已經在加速資料處理方面取得了相當大的進步，同時還具有實時訪問和響應資料的功能。出於這個原因，預計它們將在今後快速發展且需求量會很大。雖然，開源軟體很便宜，可以使用開源軟體降低企業的運營成本，但是，使用開源軟體也有一些弊端，這裡是你需要知道的一些缺點。

邊緣計算

由於物聯網的發展趨勢，許多公司正在轉向研究連線裝置以收集客戶更多的資料或流程資料，這就創造了對技術創新的需求。新的技術旨在減少從資料收集到雲端，其分析和需要採取行動的滯後時間。

針對這一問題，邊緣計算可以提供更好的效能，因為其流入和流出網路的資料更少，雲端計算的成本更低。如果公司選擇刪除掉之前從物聯網中收集到的不必要的資料，公司也可以從降低儲存和基礎設施這些成本中受益。此外，邊緣計算可以加速資料分析，為公司做出正確的反應提供充足的時間。

更智慧的聊天機器人

由於人工智慧的快速發展，很多公司現在正部署聊天機器人來處理客戶查詢等應用場景，以提供更加個性化的互動模式，同時消除對人工的需求。

大資料與提供更愉快的客戶體驗之間有著很大的關係，因為機器人通過處理大量資料，進而根據客戶在查詢中輸入的關鍵字來提供相關答案。在互動過程中，他們還能夠從對話中收集和分析出有關客戶的資訊，這一流程進而幫助營銷人員制定出更簡化的策略，以實現更好的使用者轉化率。

總結

所有這些不同跨行業的技術飛躍，都是基於大資料的發展為其奠定的堅實基礎。技術的進步將繼續通過更智慧的流程幫助我們創造出一個更美好的社會。我們必須充分了解這種技術的使用方式，以及腰實現具體的業務目標，二者結合才能最終從這些趨勢中受益。這些都只是一個開始，大資料將繼續作為我們在業務和技術方面所經歷變革的催化劑。我們可以做的是思考如何有效地適應這些變化，並利用這項技術實現業務蓬勃發展。

其他還有人民網與去年發表的2018全球大資料產業將呈七大發展趨勢

大資料處理框架簡介

從技術角度看，一般認為真正開啟大資料處理技術之門的是 Google 在2003到2006年間發表的三篇經典文章：GFS、BigTable、MapReduce，它們也被稱為 Google 的分散式計算三駕馬車，由此開始誕生了第一個在開源社群獲得極大關注的大資料處理框架 Hadoop ，這個以 HDFS、HBase、MapReduce 為主的技術棧其影響一直延續到今天。

開始時大資料處理大都採用 離線處理 的方式，其核心處理邏輯是 MapReduce 。所謂 MapReduce 就是把所有的操作都分成兩類：map 和 reduce。map 用來把資料分成多份，分開處理。reduce 則把處理後的結果進行歸併，得到最終的結果。MapReduce 的理念雖好但在實際應用中的效能表現欠佳。其後出現了 Spark 框架通過其強大而高效能的批處理技術逐漸取代 MapReduce 成為大資料處理的主流。

隨著時代的發展很多業務已經不再滿足於離線的批處理方式，需要實時處理的場景變得越來越多。為了應付此類需求，Spark 推出了 Spark Streaming 以 微批處理 來模擬 準實時 的效果，但在處理實效上還是不盡如人意。以2011年 Twitter 推出的 Storm 流計算系統為標誌，開啟了面向更低延遲的流處理的方案。之後流處理的模式由 Flink 發揚光大，Flink 並不侷限於單純的流計算引擎，而是提供了一種更通用的可以處理批處理任務的流處理框架，從而開始正面挑戰 Spark 的地位。

在大資料處理技術的討論中經常會聽到兩個詞：處理框架 和 處理引擎，按我個人的理解 引擎 和 框架 其實並沒有什麼區別，都是指對系統中的資料進行計算，但大部分時候把實際負責處理資料操作的元件稱作引擎，而承擔類似作用的 一系列元件 則叫做框架。比如 Hadoop 可以看作一種以 MapReduce 作為預設處理引擎的處理框架，而另一個處理框架 Spark 則可以納入 Hadoop 中取代 MapReduce 的作用。這種元件和元件之間的互操作特性也是大資料系統之所以如此靈活的原因之一，因此在談論大資料時一般情況下可以把 引擎 和 框架 相互替換或同時使用。

假如把大資料的處理框架按處理資料的狀態進行分類，則某些系統是用批處理的方式處理資料，一些系統是以流的方式處理連續不斷流入系統的資料，還有一些系統則同時支援這兩種方式。因此我們可以把大資料處理框架分為三種型別：批處理、流處理 和 混合處理 。

批處理

所謂 批處理 是指把一項資料處理任務先分解成更小粒度的任務，把這些任務分佈在叢集中的各臺例項上進行計算，之後把各例項上的計算結果重新計算和組合成最終結果。批處理系統通常會操作大量的靜態的資料，並等到這些資料全部處理完成後才能得到返回的結果。這種模式適用於需要訪問全量記錄才能完成的工作，比如在計算總數和平均數時必須將資料集作為一個整體加以處理，而不能將其視作多條記錄的集合。由於批處理在處理海量的持久資料方面表現出色，所以通常用於處理歷史資料，很多線上分析處理系統的底層計算框架就是使用的批處理。批處理方式使用的資料集通常有以下特徵：

• 有界：批處理資料集代表資料的有限集合
• 持久：資料通常始終儲存在某種型別的持久儲存位置中
• 大量：批處理操作通常是處理極為海量資料集的唯一方法

批處理框架的代表就是 Hadoop ，它是第一個在開源社群獲得極大關注的大資料處理框架，很長時間內幾乎是大資料技術的代名詞。Hadoop 是一種分散式計算的基礎架構，迄今為止 Hadoop 已經形成了一個廣闊的生態圈，內部實現了大量的演算法和元件，其核心有兩個：HDFS 和 MapReduce 。HDFS （Hadoop 分散式檔案系統）是一個分散式檔案系統，這樣的檔案系統可以架構在價格低廉的叢集上。MapReduce 是一種分散式任務處理的架構，正是這兩部分構成了 Hadoop 的基石。Hadoop 的核心機制是通過 HDFS 和 MapReduce 進行資料儲存、記憶體和程式的有效利用與管理。通過 Hadoop 把由多臺普通的、廉價的伺服器組合成分散式的計算-儲存叢集，從而提供大資料的儲存和處理能力。

Hadoop 實際是一個大專案的總稱，內部包含了很多子專案：

• HDFS：Hadoop分散式檔案系統。它是 GFS 的開源實現，用於儲存 Hadoop 叢集中所有儲存節點上的檔案。可以在普通的 PC 叢集上提供可靠的檔案儲存，通過資料塊進行多個副本備份來解決伺服器當機或者硬碟損壞的問題。
• MapReduce：一個基於 Java 的並行分散式計算框架，它是 Hadoop 的原生批處理引擎，也是 Google 的 MapReduce 論文的開源實現。
• HBase：一個開源的分散式 NoSQL 資料庫，它參考了 Google 的 BigTable建模。
• Hive：資料倉儲工具。
• Pig：大資料分析平臺。
• Mahout：一個機器學習 Java 類庫的集合，用於完成各種各樣的任務，如分類、評價性的聚類和模式挖掘等。其內部提供了一些經典的機器學習的演算法。
• Zookeeper：一個開源的分散式協調服務，由雅虎建立，是 Google Chubby 的開源實現。在 Hadoop 中它主要用來控制叢集中的資料，比如管理 Hadoop 叢集中的 NameNode，Hbase 中 Master Election、Server 之間狀態同步等。
• Sqoop：用於在 Hadoop 與傳統的資料庫間進行資料的傳遞。
• Ambari：Hadoop 管理工具，可以快捷的監控、部署、管理叢集。

  

Hadoop 及其 MapReduce 處理引擎提供了一套久經考驗的批處理模型，以其可靠、高效、可伸縮的特點使人們能很方便地處理海量資料。允許使用者通過很低成本的元件即可搭建完整功能的 Hadoop 叢集，因此這種廉價而高效的處理技術可以靈活應用在很多案例中。與其他框架和引擎的相容與整合能力使 Hadoop 可以成為使用不同技術的多種工作負載處理平臺的底層基礎。不過由於這種處理模式需要依賴持久儲存，計算任務需要在叢集的節點上執行多次讀寫，因此在速度上會稍顯劣勢，但是其吞吐量也同樣是其他框架所不能匹敵的，這也是批處理模式的特點。

流處理

流處理 方式會隨時對進入系統的資料進行實時的計算，這種模式不需要針對整個資料集執行操作，而是對通過系統傳輸的每個資料項執行操作。流處理中的資料集是 無邊界 的，這就產生了幾個重要的影響：

• 完整資料集只能代表截至目前已經進入到系統中的資料總量。
• 工作資料集也許更相關，在特定時間只能代表某個單一資料項。
• 處理工作是基於事件的，除非明確停止否則沒有“盡頭”。處理結果立刻可用，並會隨著新資料的抵達繼續更新。

小學時我們都會做過這樣的數學題：一個水池有一個進水管和一個出水管，只開啟進水管x個小時充滿水，只開啟出水管y個小時流光水，那麼同時開啟進水管和出水管，水池多長時間充滿水？流處理系統就相當於這個水池，把流進來的水（資料）進行加工，然後再把加工過的水（資料）從出水管放出去。這樣資料就像水流一樣永不停止，而且在水池中就被處理過了。這種處理永不停止的接入資料的系統就叫做流處理系統。流處理系統並不對已經存在的資料集進行操作，而是對從外部系統接入的的資料進行處理。流處理系統可以分為兩種：

• 逐項處理：每次處理一條資料，是真正意義上的流處理。
• 微批處理：這種處理方式把一小段時間內的資料當作一個微批次，對這個微批次內的資料進行處理。

由於海量資料的處理需要耗費大量的時間，所以批處理的方式不適合對處理結果時延要求較高的場景。而不管是逐項處理還是微批處理，其實時性都要遠好於批處理模式，因此流處理適用於有接近實時處理需求的任務場景，比如日誌分析，裝置監控、網站實時流量變化等。因為這些領域對資料的變化做出及時反饋是很常見的需求，流處理適用於必須對變動或峰值做出響應，並且關注一段時間內變化趨勢的資料。

流處理系統領域比較著名的框架有 Twitter 公司開源的 Storm ，LinkedIn 公司開源的 Samza，阿里巴巴的 JStrom，Spark 的 Spark Streaming 等等，它們都具有低延遲、可擴充套件和容錯性等優點，允許你在執行資料流程式碼時，將任務分配到一系列具有容錯能力的計算機上並行執行。也都提供了簡單的 API 來簡化底層實現，這些框架內部使用的術語可能並不相同，但包含的概念其實還是類似的，這裡以 Storm 為例主要介紹一下。

在 Storm 中有一個用於實時計算的圖狀結構，稱之為拓撲（topology）。這個拓撲將會被提交給叢集，由叢集中的主控節點（master node）分發程式碼，再將任務分配給工作節點（worker node）執行。一個拓撲中有 spout 和 bolt 兩種角色，其中 spout 傳送訊息，負責將資料流以 tuple 元組形式傳送出去。而 bolt 則負責轉換這些資料流，在 bolt 中可以完成計算、過濾等操作，bolt 本身也可以隨機將資料傳送給其他 bolt。由 spout 發射出的 tuple 是不可變陣列，對應著固定的鍵值對。

如果說 Hadoop 是水桶只能一桶一桶的去井裡扛的話，那 Storm 就是水龍頭，只要開啟它就可以源源不斷的出水。Storm 支援的語言比較多，比如 Java、Ruby、Python 等等。Storm 可以方便的在一個叢集中編寫和擴充套件複雜的實時計算，Storm 保證每個訊息都會得到處理而且速度很快，在一個小叢集中每秒可以處理數以百萬計的訊息。

Storm 是一個側重於極低延遲的流處理框架，它可處理非常大量的資料，通過比其他解決方案更低的延遲提供結果。Storm 適合對於延遲要求比較高的單純的流處理型別工作，它可以保證每條訊息都被處理，還可以配合多種程式語言使用。

混合處理

在大資料處理技術中流派中，除了單純的批處理和流處理模式之外，還有一些處理框架既可以進行批處理也可以進行流處理，我們稱之為混合處理框架。雖然專注於一種處理方式可能非常適合特定場景，但是混合框架為資料處理提供了通用的解決方案。這些框架可以用相同或相關的元件和 API 處理兩種型別的資料，藉此讓不同的處理需求得以簡化。混合處理框架中目前比較著名的就是 Spark 和 Flink 。

Spark 是一種包含流處理能力的批處理框架，它既有自帶的實時流處理工具，也可以和 Hadoop 整合，代替其中的 MapReduce。Spark 還可以拿出來單獨部署叢集，但是得藉助 HDFS 等分散式儲存系統。Spark 的強大之處在於其運算速度，與 Storm 類似 Spark 也是基於記憶體的，並且在記憶體滿負載的時候，硬碟也能運算。Spark 最初的設計受 MapReduce 思想的啟發，但不同於 MapReduce 的是 Spark 通過記憶體計算模型和執行優化大幅提高了對資料的處理能力。除了最初開發用於批處理的 Spark Core 和用於流處理的 Spark Streaming 之外，它還提供了其他程式設計模型用於支援圖計算（GraphX）、互動式查詢（Spark SQL）和機器學習（MLlib）。

Flink 則是一種可以處理批處理任務的流處理框架。在設計初始，Fink 的側重點在於處理流式資料，這與 Spark 的設計初衷恰恰相反。Spark 把流拆分成若干個小批次來處理，而 Flink 把批處理任務當作有界的流來處理。Flink 中把批處理的資料看做是具備有限邊界的資料流，藉此將批處理任務作為流處理的子集加以處理。Flink 除了處理提供流處理（DataStream API）和批處理（DataSet API）能力之外，還提供了類SQL查詢（Table API）、圖計算（Gelly）和機器學習庫（Flink ML）。Flink 還相容原生 Storm 和 Hadoop 程式，可以在 YARN 管理的叢集上執行。雖然 Spark 同樣也提供了批處理和流處理的能力，但 Spark 流處理的微批次架構使其響應時間略長。Flink 流處理優先的方式實現了低延遲、高吞吐和真正逐條處理。雖然這兩種框架經常被拿來做對比，但在市場需求的驅使下，其實兩者都在朝著更多的相容性發展。

離線與實時

假如把大資料技術按資料處理的時效性來劃分則有離線計算和實時計算兩類。

離線計算是在計算開始前已知所有輸入資料，輸入資料不會產生變化，且在解決一個問題後就要立即得出結果的前提下進行的計算。一般來說，離線計算具有資料量巨大且儲存時間長；在大量資料上進行復雜的批量運算；資料在計算之前已經完全到位，不會發生變化；能夠方便的查詢批量計算的結果等特點。

實時計算是電腦科學中對受到 實時約束 的計算機硬體和計算機軟體系統的研究，實時約束是從事件發生到系統回應之間的最長時間限制。實時程式必須保證在嚴格的時間限制內響應。通常要求實時計算的響應時間是以毫秒為單位，也有時是以微秒為單位。相比之下，非實時系統是一種無法保證在任何條件下，回應時間均匹配實時約束限制的系統。有可能大多數的情形下，非實時系統都可以匹配實時約束限制，甚至更快，只是無法保證在任何條件都可以匹配約束限制。與離線計算對應的則是實時計算，資料實時產生後就立刻處理，這種計算方式傾向於把資料看作是流。實時計算一般都是針對海量資料進行的，一般要求為秒級。實時計算主要分為兩塊:資料的實時入庫、資料的實時計算。

以 Storm 為代表的實時計算和以 MapReduce 為代表的離線計算。實時計算對資料處理時間有著較高的要求，對於延遲閾值大資料界一直沒有統一標準，預設是秒級（嚴格來說實時系統必須保證在某個時間邊界內響應，通常是毫秒級或亞秒級，但無論是 Spark Streaming 還是 Storm 都只能保證計算時間較低，因此應該屬於近實時系統）。離線計算對資料處理時間不太敏感，通常只要求在 N+1 的時間內看到結果。

由於應用場景不同，這兩種計算引擎接受資料的方式也不太一樣：實時計算的資料來源通常是流式的，也就是來一條資料處理一條，所以也被稱為流式計算。而離線計算的資料來源通常是靜態的、一個計算週期的完整資料，計算的時間也被設定在一個週期的資料全部收到後（通常是凌晨計算前一天的資料），所以也被稱為批處理計算。有時這兩種不同的資料接收方式以及它們所導致的不同的執行時間（實時計算任務需要一直執行，離線任務則是定時執行），會被一些工程師用於區分實時計算引擎和離線計算引擎。

總結

儘管流處理和批處理（特別是微批處理）之間的差異似乎只是時間差異很小的問題，但它們實際上對資料處理系統的體系結構和使用它們的應用程式都有著根本的影響。流處理系統的設計是為了在資料到達時對其進行響應。這就要求它們實現一個由事件驅動的體系結構, 即系統的內部工作流設計為在接收到資料後立即連續監視新資料和排程處理。另一方面, 批處理系統中的內部工作流只定期檢查新資料, 並且只在下一個批處理視窗發生時處理該資料。

流處理和批處理之間的差異對於應用程式來說也是非常重要的。為批處理而構建的應用程式，通過定義處理資料，具有延遲性。在具有多個步驟的資料管道中，這些延遲會累積。此外，新資料的到達與該資料的處理之間的延遲將取決於直到下一批處理視窗的時間--從在某些情況下完全沒有時間到批處理視窗之間的全部時間不等，這些資料是在批處理開始後到達的。因此，批處理應用程式(及其使用者)不能依賴一致的響應時間，需要相應地調整以適應這種不一致性和更大的延遲。

批量處理通常適用於具有最新資料並不重要的用例，以及容忍較慢響應時間的情況。而流處理對於需要實時互動和實時響應的用例是必需的。

大資料系統可使用多種處理技術。對於僅需要批處理的工作負載，如果對時間不敏感，比其他解決方案實現成本更低的 Hadoop 將會是一個好選擇。對於僅需要流處理的工作負載，Storm 可支援更廣泛的語言並實現極低延遲的處理，但預設配置可能產生重複結果並且無法保證順序。Samza 與 YARN 和 Kafka 緊密整合可提供更大靈活性，更易用的多團隊使用，以及更簡單的複製和狀態管理。對於混合型工作負載，Spark 可提供高速批處理和微批處理模式的流處理。該技術的支援更完善，具備各種整合庫和工具，可實現靈活的整合。Flink 提供了真正的流處理並具備批處理能力，通過深度優化可執行鍼對其他平臺編寫的任務，提供低延遲的處理，但實際應用方面還為時過早。

最適合的解決方案主要取決於待處理資料的狀態，對處理所需時間的需求，以及希望得到的結果。具體是使用全功能解決方案或主要側重於某種專案的解決方案，這個問題需要慎重權衡。隨著逐漸成熟並被廣泛接受，在評估任何新出現的創新型解決方案時都需要考慮類似的問題。