大數據技術簡介

大數據的歷史

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 提供了真正的流處理並具有批處理能力，經過深度優化可運行鍼對其餘平臺編寫的任務，提供低延遲的處理，但實際應用方面還爲時過早。

最適合的解決方案主要取決於待處理數據的狀態，對處理所需時間的需求，以及但願獲得的結果。具體是使用全功能解決方案或主要側重於某種項目的解決方案，這個問題須要慎重權衡。隨着逐漸成熟並被普遍接受，在評估任何新出現的創新型解決方案時都須要考慮相似的問題。