大數據的發展歷史
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的眾多項目最為著名，從Flume到Beam，它們都處于不同的發展階段。
現如今，隨著智能移動設備、物聯網等技術的廣泛應用，數據的碎片化、分布式、流媒體特征更加明顯，大數據技術開始與移動和云技術相結合，開始向復雜事件處理、圖形數據庫和內存計算等方向發展。大數據的概念越來越被垂直行業以及政府和大眾所接受，通過催化新的商業模式使得大數據同傳統行業的邊界變得越來越模糊，大家開始更加關注業務的創新而非技術本身，大數據產業的主題也轉向應用對行業的變革性影響，來到了真正的應用階段。
大數據的發展方向
大數據技術是一種新的技術和架構，致力于以較低的成本、更快速的采集、處理和分析各種超大規模的數據，從中提取對企業有價值的信息。隨著該技術的蓬勃發展，讓我們處理海量數據更加容易、更加便宜和迅速，成為利用數據的好助手，甚至可以改變許多行業的商業模式。在人工智能、云計算和物聯網的幫助下，即使是復雜的大數據，也可以由普通的數據從業者利用相應的數據分析工具來進行處理。大數據分析已經脫離了熱門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 生態圈
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 提供了真正的流處理并具備批處理能力，通過深度優化可運行針對其他平臺編寫的任務，提供低延遲的處理，但實際應用方面還為時過早。
最適合的解決方案主要取決于待處理數據的狀態，對處理所需時間的需求，以及希望得到的結果。具體是使用全功能解決方案或主要側重于某種項目的解決方案，這個問題需要慎重權衡。隨著逐漸成熟并被廣泛接受，在評估任何新出現的創新型解決方案時都需要考慮類似的問題。
