本文討論大數據處理生態系統和相關的架構棧，包括對適應於不同任務的多種框架特性的調研。除此之外，文章還從多個層次對框架進行深入研究，如存儲，資源管理，數據處理，查詢和機器學習。
使用門檻的降低是互聯網上數據最初增長的驅動力。隨着智能手機和平板電腦等一系列新設備的出現，這一趨勢得以加強。在第一代數據增長的基礎上，社交媒體平臺推動數據量以指數級增長，這也就是所謂由社交媒體釋放的第二次增長浪潮。信息分享平臺的協作特質促成了數據分享的病毒式增長。第三次的增長則很大程度上來自於智能互聯設備的的快速增加，而這也將帶來前所未有的數據擴張。此外，科學領域的進步和更加廉價的計算力已經爲包括醫療科學、物理學、天文學和基因學在內的諸多領域帶來了新的應用。在這些領域中，收集的數據被用來驗證假說，推動新的發現和創造。
在這裏我還是要推薦下我自己建的大數據學習交流qq裙：522189307 ， 裙 裏都是學大數據開發的，如果你正在學習大數據 ，小編歡迎你加入，大家都是軟件開發黨，不定期分享乾貨（只有大數據開發相關的），包括我自己整理的一份最新的大數據進階資料和高級開發教程，歡迎進階中和進想深入大數據的小夥伴。上述資料加羣可以領取
數據獲取和存儲的快速擴張將我們帶到了一個新的階段——將數據處理爲有意義的解釋。處理大量數據的現實需要導致了對可擴展及並行系統的需求。這些系統能夠以更高的速度和更大的規模處理數據。開源技術就是大規模數據處理所需高性能計算技術的不二之選。本文將爲大數據處理棧不同層次可用的開源框架及組件做總體的介紹。
用於大數據處理的組件架構棧 隨着越來越多的大數據（以數量，速度和種類三個V爲特徵）的生成和收集，各種各樣系統開始發展，以期挖掘出這些數據的巨大而多樣的潛力。儘管許多系統表現出了相同的特性，但它們往往有着不同的設計哲學，這也帶來了更大的選擇空間。企業決定數據策略的戰略指導原則之一就是採用通用的數據存儲層，這將便利不同框架對數據的運用，同時數據也能夠跨框架共享。圖1展示了一個典型的數據處理架構棧。
這個架構棧也可以被視爲一個多階段的數據處理流水線，如圖2所示。非結構化的數據往往有多樣的格式，例如文本數據、圖片、視頻和音頻等。而這些數據也有包括交易記錄、網絡日誌、公衆網站、數據庫、多種設備和工具以及其他相聯繫的數據在內的多種數據源。經過清洗和錯誤檢查後，這些數據會進入數據存儲層。接下來的任務就是利用下一部分描述的框架對數據進行反覆和交互式的處理。處理過程本身可能會有多個子階段，期間有可能伴隨着與存儲層的交互。它可以進一步使用統計算法探索和建模來推導和驗證假設。用數據對算法進行訓練，然後將其用於預測建模。當有新的數據集進入系統時，這些算法可以進行週期性的訓練。數據集進一步用於探索性分析，從而發現潛藏的知識和見解。在處理和探索過程中，通過使用可視化工具對處理後的數據集進行可視化，促進對於數據的理解，並可將其用於與利益相關者的溝通。
存儲層中的數據可以被組織內的不同利益相關者複用。大數據通常是不確定的，而多數處理框架已經適應了這一特性。事實上，這個特性正是一個框架成功的關鍵因素。下面，讓我們討論這些不同層次的框架和庫。
存儲和數據層 讓我們從存儲和數據層開始。這是大數據棧是最重要的組成要素和基礎。正如其名，大數據通常以其大量的數據爲特徵，而這要求巨大乃至理論上無限的存儲容量。促成更便宜的存儲和計算資源的技術進步，導致了集羣存儲和計算平臺的出現。這些平臺擺脫了存儲限制，並實質上實現了無限量的數據存儲。這些平臺不受傳統數據建模和模式設計範例的限制。它們通常是無模式的，允許存儲所有形式的數據（結構化，半結構化和非結構化）。這使得創建更具動態性的系統成爲可能，分析人員也可以擺脫現有模型的限制對數據進行探索。
HDFS（https://hadoop.apache.org/）：這是Hadoop生態系統中的可擴展的、具有容錯性的分佈式文件系統。將商用服務器添加到集羣中即可擴展HDFS。已知的最大集羣包括了大約4500個節點和高達128PB的數據。HDFS支持並行讀取和寫入數據。HDFS系統中的帶寬隨節點數量線性變化。通過存儲在系統中的多個數據副本實現內置冗餘。這些文件被分解成塊（Blocks）並像文件一樣存儲在集羣中。爲了實現可靠性，這些文件會被複制多份。HDFS具有主/從體系結構，在集羣中有一個稱爲NameNode的組件，該組件作爲主服務器。NameNode管理文件系統命名空間（文件，目錄和塊以及它們的關係）。命名空間存儲在內存中，並且定期將更改保存到磁盤中。除此之外，還有一些稱爲DataNode的從屬組件，在集羣中的每個節點都有一個這樣的組件。這些進程管理特定計算節點所依賴的存儲。
NoSQL數據庫（http://nosql-database.org/）：隨着Web不斷髮展並變得更易於訪問，現有的關係數據庫技術無法滿足Web 2.0的大量數據和併發需求。這已經成爲顯而易見的事實。爲了滿足這一需求，“不僅僅是數據查詢（Not only SQL）”數據庫作爲存儲和管理系統的新選擇出現了。相比於HDFS和Hadoop最爲數據分析領域實時或批量處理引擎，NoSQL數據庫本質上是應用於基於前後端系統的Web應用的數據存儲層，特別那些需要有大量併發處理能力的Web應用。
這些數據庫的特點包括他們通常是無結構的（或者僅需要極少的結構設計）、水平可擴展以及依賴於事件一致性模型而不是即時一致性模型。
現在出現了四種基本的NoSQL架構，他們是
- 基於哈希數據結構或關聯數組數據模型的鍵值存儲。這類數據庫建立在亞馬遜的Dynamo論文之上。（http://www.allthingsdistributed.com/files/amazon-dynamo-sosp2007.pdf）。
- 列式數據庫（DB）基於Google的BigTable論文（http://research.google.com/archive/bigtable-osdi06.pdf）。這一數據模型允許每行有自己的模式，例如， HBase和Cassandra。
- 文檔數據庫將數據存儲爲文檔，每個文檔都是鍵值對的集合。通常，這些文檔以JSON形式存在（例如，MongoDB和CouchDB）。
- 圖數據庫將數據模型表示爲節點或表示爲節點之間關係。節點和關係都以鍵值對（例如Neo4J）表示。
Tachyon（http://tachyon-project.org/）：這是一個跨集羣框架和作業提供可靠內存數據共享的平臺。Tachyon實質上位於諸如HDFS之類的存儲平臺之上，因此可跨羣集框架和作業提供以內存爲中心的數據處理功能。儘管Spark等一些現有的集羣計算框架已經實現了在內存中進行數據處理，但這一方案存在三個關鍵的缺陷，促成了Tachyon的發展：
- 雖然作業在內存中處理數據，但作業和框架間的數據共享尚未實現，因爲數據僅在作業的JVM上下文中可用。
- 由於執行引擎和存儲位於相同的JVM上下文中，因此任何執行引擎崩潰都會導致數據丟失並且需要重新計算。
- 在某些情況下，內存中的數據會在作業間複製，導致數據佔用空間更大，觸發更爲嚴重的垃圾收集。
Tachyon正是爲了解決上述問題而得以發展。它通過與存儲層建立血統關係（lineage）實現。它可以在內存中只存儲一個數據副本，這些數據副本可在所有框架（如Spark，MapReduce等）中使用。此外，它通過依賴於血統關係的重新計算來實現容錯功能。
數據處理框架 將數據保存到存儲層後，下一步就是處理這些數據，並從中形成見解。我們將在這裏比較幾個框架。
Apache Hadoop 棧（https://hadoop.apache.org/）是大數據處理框架的祖師爺，並且已經成爲這些技術彙集的事實上的平臺。該平臺的成本效益和可擴展性完全符合業界大規模數據處理的需求。此外，平臺的可靠性，社區支持和圍繞該平臺產生的生態系統使該平臺得到更廣泛的採用。
Hadoop生態系統有三個主要目標：
可擴展性 - 僅僅通過向集羣添加節點即可實現擴展以滿足更大的需求。由於框架採用本地計算模型以便從簡化的可伸縮性模型中獲益，這個特性得到了進一步的增強。
靈活性 - 爲存儲不同格式的結構化數據提供靈活性。這是通過“模式讀取（Schema on Read）”方法實現的，該方法使系統能夠存儲任何內容，並且只在讀取數據時才解析數據，而這正是需要了解數據的時間。
效率 - 確保集羣資源得到最佳利用以提高效率。
Hadoop MapReduce（https://hadoop.apache.org/）是MapReduce編程範式的實現（由Google論文推廣）。這種編程範式意在通過大型集羣並行處理超大型數據集，同時確保可靠性和容錯性。MapReduce() 範式本身是一個建立在確保可靠性和可擴展性的分佈式文件系統之上的概念。一個MapReduce() 程序包括兩個程序 Map() 和Reduce()。Map() 過程並行處理輸入數據集併產生處理後的輸出。由於Map() 階段發生在一個非常大的分佈式數據集上，散佈在一個巨大的節點集羣中，隨後執行Reduce() 階段，該階段聚合來自於多個Map節點排序後的數據集，這個框架以及底層的HDFS系統能夠處理以PB爲單位運行的，分佈在數千個節點上的超大型數據集。
Apache Flink（https://flink.apache.org/）是一個數據處理系統，結合了Hadoop HDFS層的可擴展性和強大功能以及作爲關係型數據庫基石的的聲明式特性和性能優化。Flink提供了一個運行時系統，它是Hadoop MapReduce框架的替代選擇。
Apache Tez（https://tez.apache.org/）是一個分佈式數據處理引擎，建立在Yarn（Hadoop 2.0生態系統）之上。Tez將數據處理工作流程建模爲分佈式非循環圖（Distributed Acyclic Graphs, DAGs）。憑藉這一獨特功能，Tez可讓開發人員直觀地將複雜的數據處理作業建模爲一系列任務，同時利用Hadoop 2.0生態系統的基礎資源管理功能。
Apache Spark（https://spark.apache.org/）是大數據處理的分佈式執行引擎，可提供處理內存中的大型數據集的高效抽象。雖然基於Yarn的MapReduce提供了使用集羣計算資源的抽象方法，但它在需要複用數據的迭代算法和交互式數據挖掘算法中缺乏效率。Spark以RDD（彈性分佈式數據集）的形式實現內存中的容錯數據抽象。這中種存儲在內存中的並行數據結構形式存在。RDD通過追蹤轉換過程（血統，lineage）而不是實際數據實現容錯功能。如果有一個部分在丟失後需要回復，則只需要在這個數據集上執行變換。這比跨節點複製數據集以提高容錯性要高效得多。據推測，這比Hadoop MR快100倍。
Spark還爲批處理，流數據處理，交互式數據挖掘提供了統一的框架，還包括Java，Scala和Python中的API在內。它提供了一個交互式命令行工具（shell）。通過這一工具可以使用快速查詢功能、用於機器學習的庫（MLLib和GraphX）、用於圖形數據處理的API、SparkSQL（一種聲明性查詢語言）和SparkStreaming（用於流數據處理的流式API）。SparkStreaming是一個用於實時處理事件流的系統。SparkStreaming將流處理視爲微批處理（microbatch）數據集。輸入流被分成預設時長的批次。這些批處理被輸入到底層的Spark系統中，並且通過與Spark批處理編程範式相同的方式進行處理。這使得實時處理所需的極低延遲和實時集成批處理特性得以實現。
Apache Storm（https://storm.apache.org/）是一個用於實時處理連續數據流的系統。它具有高度可擴展性，容錯能力，並實現了可靠處理的概念，從而不會丟失任何事件。Hadoop提供了批量處理數據的框架，而Storm在流式事件數據實現了同樣的功能。它使用有向無環圖（DAG）,並藉助噴嘴（spouts, 輸入數據源）和閃電（bolts）的概念來定義數據處理流水線或拓撲。流是流經這些處理流水線的元組。Storm集羣由三部分組成：
- Nimbus，運行在主節點上，負責在工作進程中分配工作。
- Supervisor守護進程在工作節點上運行，監聽分配的任務，並根據需要管理工作進程以啓動/停止它們，以完成工作。
- Zookeeper處理Nimbus和Supervisors之間的協調，並維持容錯狀態。
用於分析和查詢的高級語言 隨着集羣編程框架逐漸演變爲解決大數據處理問題的主要手段，另一個問題伴隨着更大規模的實用嘗試而開始出現。使用這些計算框架編程變得越來越複雜且難以維護。技能可伸縮性成爲另一個值得關注的問題，因爲有許多人熟悉熟悉SQL和腳本等技能的領域專業知識。因此，集羣計算框架的更高層次的編程抽象開始出現，它們對低層次的編程API進行抽象。本部分討論了其中一些框架。
Hive（https://hive.apache.org/）和Pig（https://pig.apache.org/）是MapReduce的高級語言實現。語言接口從用高級語言編寫的查詢命令在內部生成MapReduce程序，從而抽象出MapReduce和HDFS的基本內容。Pig實現了PigLatin，這是一種類似過程式的語言接口，而Hive提供了Hive查詢語言（HQL），它是一種與SQL類似的聲明式語言接口。
Pig適合於爲迭代處理場景編寫數據處理流程。Hive採用聲明式SQL語言，可用於臨時數據查詢，探索性分析和商業智能（BI）。
BlinkDB（http://blinkdb.org/）是大數據處理生態系統的新進者。它提供了一個支持大數據近似查詢的交互式查詢處理平臺。隨着數據量呈指數級增長，越來越多的長期研究出現在這個領域，並聚焦於創建低延遲的計算模型。Apache Spark在朝這一方向發展，它致力於利用內存數據結構降低延遲。
Blink DB通過引入近似查詢的概念進一步壓縮延遲基準。在一些行業案例中，如果速度的能有所提升，少量的錯誤是可以接受的。BlinkDB通過在原始數據集的樣本而非整個數據集上運行查詢。該框架能爲查詢定義可接受的錯誤界限，或指定時間限制。系統根據這些約束處理查詢並返回給定範圍內的結果。BlinkDB利用統計學採樣誤差的概念，即採樣誤差不隨總體規模而變化，而是取決於樣本量。因此，即便隨着數據量的增加，相同的樣本量總能以適當的水平反映總體的性質。這種想法帶來了令人難以置信的性能改善。由於查詢的時間大部分是消耗在I/O過程中，如果將樣本量設定爲原始數據的10%，處理速度就可以提升10倍，同時誤差小於0.02％。BlinkDB構建在Hive Query引擎上，並支持Hadoop MR和Apache Shark執行引擎。BlinkDB對這種複雜的近似方法進行抽象，並提供了一種類SQL的命令結構。這種語言在用戶利用原始命令自定義的函數之外還支持標準的聚合，過濾，分組，聯合以及嵌套查詢。
圖1：大數據處理組件棧
集羣資源管理框架 集羣資源管理是大數據處理棧中的關鍵組件之一。現有的資源管理框架已經能夠將支持多種上層框架的通用性與一些所需的重要特性結合起來。這些特性包括完全不同的處理需求、數據控制的穩健性和無縫恢復。通用框架將避免在集羣內的不同框架之間複製大量數據。提供一個易於使用的管理接口同樣十分重要。下面我會介紹幾個實現了這一功能的資源管理框架。
Apache Hadoop Yarn （https://hadoop.apache.org/ _）：_Hadoop 1.0完全根據MapReduce範式而構建的引擎。隨着Hadoop被廣泛接受爲分佈式大數據批處理系統的平臺，其他計算模式（如消息傳遞接口，圖形處理，實時流處理，臨時和迭代處理等）的需求也不斷增長。MapReduce作爲一種編程範式，並不支持這些要求。因此，新的（以及其他現有的）框架開始發展。另外，HDFS作爲大數據存儲系統得到了廣泛接受，而爲其他框架單獨設計存儲結構並沒有什麼意義。因而Hadoop社區致力改進現有平臺，從而使其不僅僅侷限於MapReduce。這一努力的成果就是Hadoop 2.0，它將資源管理與應用程序管理分離開來。資源管理系統被命名爲Yarn。Yarn同樣是主從架構，資源管理器作爲主服務，負責管理對集羣上不同應用程序的資源分配。從屬組件稱爲NodeManager，在羣集中的每個節點上運行，並負責啓動應用程序所需的計算容器。ApplicationMaster是框架特定的實體。它負責協調ResourceManager中的資源並與節點管理器一起提交和監視應用程序任務。ApplicationMaster是框架特定的實體。它負責協調ResourceManager中的資源並與節點管理器一起提交和監視應用程序任務。
這種解耦允許其他框架與MapReduce一起工作，訪問和共享同一集羣上的數據，從而有助於提高集羣利用率。
Apache Mesos（http://mesos.apache.org/）是一種通用的集羣資源管理框架，可以管理數據中心中的所有資源。Mesos採用與Yarn不同的方式調度工作。Mesos實現了一個兩級調度機制，主服務器向框架調度器提供資源，框架決定是否接受或拒絕它們。這個模型使得Mesos變得具有良好可擴展性和通用性，並且允許框架能很好地滿足特定的目標，比如數據局部性。Mesos是一個主/從架構，Mesos主服務器（master）在其中一個節點上運行，並且與多個備用主服務器相配合，以便在出現故障時進行接管。主服務器管理集羣節點上的從屬進程以及在節點上運行任務的框架。運行在Mesos上的框架有兩個組件：在主服務器上註冊的框架調度器，以及在Mesos從服務器上啓動的框架執行器。在Mesos中，從服務器向主服務器報告所提供的可用資源。Mesos 主服務器查找分配策略並根據策略向框架提供資源。該框架根據其目標和需要運行的任務可以完全接受，部分或甚至拒絕分配。如果有的話，它會發回一個接受的響應和要運行的任務。Mesos主服務器將這些任務轉發給相應的從服務器，這些從服務器將所提供的資源分配給執行者，然後執行器啓動任務。
圖2：大數據處理流水線
機器學習庫 如果不能最終提供商業價值，將努力付出在大數據上將毫無意義。機器學習使系統能夠學習或處理大量數據，並能夠將其應用於預測未知輸入數據集上的結果。在顯示生活中，已經有許多機器學習系統的案例，例如定向廣告，推薦引擎，“下一個最佳報價/行爲”，自學自治系統等。下面這個領域的一些框架。
Apache Mahout（）旨在提供一個可伸縮的機器學習平臺。它實現了多種”開箱即用“算法，並提供了一個實現自定義算法的框架。儘管Apache Mahout是最早的機器學習庫之一，但它最初是作爲爲MapReduce編程範例而編寫的。然而，MapReduce不太適合機器學習算法的迭代特性，因此並沒有取得很大的成功。當Spark開始展露頭角時，Mahout已被移植到Apache Spark，並重新命名爲Spark MLLib，且不再使用Hadoop MapReduce。
Spark MLLib（）是一個可擴展的機器學習平臺。它建立在在Spark的上層，可視爲Spark Core執行引擎的擴展。Spark MLLib已經是Spark Core的本地擴展實現，因此它有許多優勢。Spark MLLib有幾種爲ML問題編寫的算法，例如分類，迴歸，協同過濾，聚類，分解等。
PredictionIO（http://prediction.io/）是一種可擴展的機器學習服務器。它提供了一個框架，可加快機器學習應用程序的原型設計和生產應用。它基於Apache Spark構建，並利用Spark MLLib所提供多種機器學習算法的實現。它提供了一個接口將訓練過的預測模型抽象爲一種服務，而這是通過基於事件服務器的架構提供的。它還提供了一種將分佈式環境中持續訓練訓練模型的方法。生成的事件是實時收集的，並且可以用來作爲批處理作業重新訓練模型。客戶端應用程序可以通過REST API查詢服務，並JSON響應返回預測結果。