⑴ hdfs文件系統可以代替mysql嗎
不能。
不是一個概念。mysql是傳統的關系型資料庫。hdfs是nosql hadoop的存儲方式。hdfs是分布式的自帶高可用存儲，文件格式跟mysql的存儲引擎不一樣。大數據離線存儲，當然是hdfs更合適。通過Map/Rece進行批處理遞送到Apache Hadoop仍然是中樞環節。但隨著要從「超思維速度「分析方面獲取競爭優勢的壓力遞增，因此Hadoop(分布式文件系統)自身經歷重大的發展。
科技的發展允許實時查詢，如Apache Drill, Cloudera Impala和Stinger Initiative正脫穎而出，新一代的資源管理Apache YARN 支持這些。為了支持這種日漸強調實時性操作,我們正發布一個新MySQL Applier for Hadoop(用於Hadoop的MySQL Applier)組件。它能夠把MySQL中變化的事務復制到Hadoop / Hive / HDFS。Applier 組件補充現有基於批處理Apache Sqoop的連接性。
⑵ hadoop是做什麼的
提供海量數據存儲和計算的，需要java語言基礎。
Hadoop實現了一個分布式文件系統（Hadoop Distributed File System），簡稱HDFS。有高容錯性的特點，並且設計用來部署在低廉的（low-cost）硬體上；而且它提供高吞吐量來訪問應用程序的數據，適合那些有著超大數據集（large data set）的應用程序。
特點
1、快照支持在一個特定時間存儲一個數據拷貝，快照可以將失效的集群回滾到之前一個正常的時間點上。HDFS已經支持元數據快照。
2、HDFS的設計是用於支持大文件的。運行在HDFS上的程序也是用於處理大數據集的。這些程序僅寫一次數據，一次或多次讀數據請求，並且這些讀操作要求滿足流式傳輸速度。
HDFS支持文件的一次寫多次讀操作。HDFS中典型的塊大小是64MB，一個HDFS文件可以被切分成多個64MB大小的塊，如果需要，每一個塊可以分布在不同的數據節點上。
3、階段狀態：一個客戶端創建一個文件的請求並不會立即轉發到名位元組點。實際上，一開始HDFS客戶端將文件數據緩存在本地的臨時文件中。
⑶ 大數據核心技術有哪些
大數據技術的體系龐大且復雜，基礎的技術包含數據的採集、數據預處理、分布式存儲、NoSQL資料庫、數據倉庫、機器學習、並行計算、可視化等各種技術范疇和不同的技術層面。首先給出一個通用化的大數據處理框架，主要分為下面幾個方面：數據採集與預處理、數據存儲、數據清洗、數據查詢分析和數據可視化。
一、數據採集與預處理
對於各種來源的數據，包括移動互聯網數據、社交網路的數據等，這些結構化和非結構化的海量數據是零散的，也就是所謂的數據孤島，此時的這些數據並沒有什麼意義，數據採集就是將這些數據寫入數據倉庫中，把零散的數據整合在一起，對這些數據綜合起來進行分析。數據採集包括文件日誌的採集、資料庫日誌的採集、關系型資料庫的接入和應用程序的接入等。在數據量比較小的時候，可以寫個定時的腳本將日誌寫入存儲系統，但隨著數據量的增長，這些方法無法提供數據安全保障，並且運維困難，需要更強壯的解決方案。
Flume NG作為實時日誌收集系統，支持在日誌系統中定製各類數據發送方，用於收集數據，同時，對數據進行簡單處理，並寫到各種數據接收方(比如文本，HDFS，Hbase等)。Flume NG採用的是三層架構：Agent層，Collector層和Store層，每一層均可水平拓展。其中Agent包含Source，Channel和 Sink，source用來消費（收集）數據源到channel組件中，channel作為中間臨時存儲，保存所有source的組件信息，sink從channel中讀取數據，讀取成功之後會刪除channel中的信息。
NDC，Netease Data Canal，直譯為網易數據運河系統，是網易針對結構化資料庫的數據實時遷移、同步和訂閱的平台化解決方案。它整合了網易過去在數據傳輸領域的各種工具和經驗，將單機資料庫、分布式資料庫、OLAP系統以及下游應用通過數據鏈路串在一起。除了保障高效的數據傳輸外，NDC的設計遵循了單元化和平台化的設計哲學。
Logstash是開源的伺服器端數據處理管道，能夠同時從多個來源採集數據、轉換數據，然後將數據發送到您最喜歡的 「存儲庫」 中。一般常用的存儲庫是Elasticsearch。Logstash 支持各種輸入選擇，可以在同一時間從眾多常用的數據來源捕捉事件，能夠以連續的流式傳輸方式，輕松地從您的日誌、指標、Web 應用、數據存儲以及各種 AWS 服務採集數據。
Sqoop，用來將關系型資料庫和Hadoop中的數據進行相互轉移的工具，可以將一個關系型資料庫(例如Mysql、Oracle)中的數據導入到Hadoop(例如HDFS、Hive、Hbase)中，也可以將Hadoop(例如HDFS、Hive、Hbase)中的數據導入到關系型資料庫(例如Mysql、Oracle)中。Sqoop 啟用了一個 MapRece 作業（極其容錯的分布式並行計算）來執行任務。Sqoop 的另一大優勢是其傳輸大量結構化或半結構化數據的過程是完全自動化的。
流式計算是行業研究的一個熱點，流式計算對多個高吞吐量的數據源進行實時的清洗、聚合和分析，可以對存在於社交網站、新聞等的數據信息流進行快速的處理並反饋，目前大數據流分析工具有很多，比如開源的strom，spark streaming等。
Strom集群結構是有一個主節點（nimbus）和多個工作節點（supervisor）組成的主從結構，主節點通過配置靜態指定或者在運行時動態選舉，nimbus與supervisor都是Storm提供的後台守護進程，之間的通信是結合Zookeeper的狀態變更通知和監控通知來處理。nimbus進程的主要職責是管理、協調和監控集群上運行的topology（包括topology的發布、任務指派、事件處理時重新指派任務等）。supervisor進程等待nimbus分配任務後生成並監控worker（jvm進程）執行任務。supervisor與worker運行在不同的jvm上，如果由supervisor啟動的某個worker因為錯誤異常退出（或被kill掉），supervisor會嘗試重新生成新的worker進程。
當使用上游模塊的數據進行計算、統計、分析時，就可以使用消息系統，尤其是分布式消息系統。Kafka使用Scala進行編寫，是一種分布式的、基於發布/訂閱的消息系統。Kafka的設計理念之一就是同時提供離線處理和實時處理,以及將數據實時備份到另一個數據中心，Kafka可以有許多的生產者和消費者分享多個主題，將消息以topic為單位進行歸納；Kafka發布消息的程序稱為procer，也叫生產者，預訂topics並消費消息的程序稱為consumer，也叫消費者；當Kafka以集群的方式運行時，可以由一個服務或者多個服務組成，每個服務叫做一個broker，運行過程中procer通過網路將消息發送到Kafka集群，集群向消費者提供消息。Kafka通過Zookeeper管理集群配置，選舉leader，以及在Consumer Group發生變化時進行rebalance。Procer使用push模式將消息發布到broker，Consumer使用pull模式從broker訂閱並消費消息。Kafka可以和Flume一起工作，如果需要將流式數據從Kafka轉移到hadoop，可以使用Flume代理agent，將Kafka當做一個來源source，這樣可以從Kafka讀取數據到Hadoop。
Zookeeper是一個分布式的，開放源碼的分布式應用程序協調服務，提供數據同步服務。它的作用主要有配置管理、名字服務、分布式鎖和集群管理。配置管理指的是在一個地方修改了配置，那麼對這個地方的配置感興趣的所有的都可以獲得變更，省去了手動拷貝配置的繁瑣，還很好的保證了數據的可靠和一致性，同時它可以通過名字來獲取資源或者服務的地址等信息，可以監控集群中機器的變化，實現了類似於心跳機制的功能。
二、數據存儲
Hadoop作為一個開源的框架，專為離線和大規模數據分析而設計，HDFS作為其核心的存儲引擎，已被廣泛用於數據存儲。
HBase，是一個分布式的、面向列的開源資料庫，可以認為是hdfs的封裝，本質是數據存儲、NoSQL資料庫。HBase是一種Key/Value系統，部署在hdfs上，克服了hdfs在隨機讀寫這個方面的缺點，與hadoop一樣，Hbase目標主要依靠橫向擴展，通過不斷增加廉價的商用伺服器，來增加計算和存儲能力。
Phoenix，相當於一個Java中間件，幫助開發工程師能夠像使用JDBC訪問關系型資料庫一樣訪問NoSQL資料庫HBase。
Yarn是一種Hadoop資源管理器，可為上層應用提供統一的資源管理和調度，它的引入為集群在利用率、資源統一管理和數據共享等方面帶來了巨大好處。Yarn由下面的幾大組件構成：一個全局的資源管理器ResourceManager、ResourceManager的每個節點代理NodeManager、表示每個應用的Application以及每一個ApplicationMaster擁有多個Container在NodeManager上運行。
Mesos是一款開源的集群管理軟體，支持Hadoop、ElasticSearch、Spark、Storm 和Kafka等應用架構。
Redis是一種速度非常快的非關系資料庫，可以存儲鍵與5種不同類型的值之間的映射，可以將存儲在內存的鍵值對數據持久化到硬碟中，使用復制特性來擴展性能，還可以使用客戶端分片來擴展寫性能。
Atlas是一個位於應用程序與MySQL之間的中間件。在後端DB看來，Atlas相當於連接它的客戶端，在前端應用看來，Atlas相當於一個DB。Atlas作為服務端與應用程序通訊，它實現了MySQL的客戶端和服務端協議，同時作為客戶端與MySQL通訊。它對應用程序屏蔽了DB的細節，同時為了降低MySQL負擔，它還維護了連接池。Atlas啟動後會創建多個線程，其中一個為主線程，其餘為工作線程。主線程負責監聽所有的客戶端連接請求，工作線程只監聽主線程的命令請求。
Ku是圍繞Hadoop生態圈建立的存儲引擎，Ku擁有和Hadoop生態圈共同的設計理念，它運行在普通的伺服器上、可分布式規模化部署、並且滿足工業界的高可用要求。其設計理念為fast analytics on fast data。作為一個開源的存儲引擎，可以同時提供低延遲的隨機讀寫和高效的數據分析能力。Ku不但提供了行級的插入、更新、刪除API，同時也提供了接近Parquet性能的批量掃描操作。使用同一份存儲，既可以進行隨機讀寫，也可以滿足數據分析的要求。Ku的應用場景很廣泛，比如可以進行實時的數據分析，用於數據可能會存在變化的時序數據應用等。
在數據存儲過程中，涉及到的數據表都是成千上百列，包含各種復雜的Query，推薦使用列式存儲方法，比如parquent,ORC等對數據進行壓縮。Parquet 可以支持靈活的壓縮選項，顯著減少磁碟上的存儲。
三、數據清洗
MapRece作為Hadoop的查詢引擎，用於大規模數據集的並行計算，」Map（映射）」和」Rece（歸約）」，是它的主要思想。它極大的方便了編程人員在不會分布式並行編程的情況下，將自己的程序運行在分布式系統中。
隨著業務數據量的增多，需要進行訓練和清洗的數據會變得越來越復雜，這個時候就需要任務調度系統，比如oozie或者azkaban，對關鍵任務進行調度和監控。
Oozie是用於Hadoop平台的一種工作流調度引擎，提供了RESTful API介面來接受用戶的提交請求(提交工作流作業)，當提交了workflow後，由工作流引擎負責workflow的執行以及狀態的轉換。用戶在HDFS上部署好作業(MR作業)，然後向Oozie提交Workflow，Oozie以非同步方式將作業(MR作業)提交給Hadoop。這也是為什麼當調用Oozie 的RESTful介面提交作業之後能立即返回一個JobId的原因，用戶程序不必等待作業執行完成（因為有些大作業可能會執行很久(幾個小時甚至幾天)）。Oozie在後台以非同步方式，再將workflow對應的Action提交給hadoop執行。
Azkaban也是一種工作流的控制引擎，可以用來解決有多個hadoop或者spark等離線計算任務之間的依賴關系問題。azkaban主要是由三部分構成：Relational Database，Azkaban Web Server和Azkaban Executor Server。azkaban將大多數的狀態信息都保存在MySQL中，Azkaban Web Server提供了Web UI，是azkaban主要的管理者，包括project的管理、認證、調度以及對工作流執行過程中的監控等；Azkaban Executor Server用來調度工作流和任務，記錄工作流或者任務的日誌。
流計算任務的處理平台Sloth，是網易首個自研流計算平台，旨在解決公司內各產品日益增長的流計算需求。作為一個計算服務平台，其特點是易用、實時、可靠，為用戶節省技術方面（開發、運維）的投入，幫助用戶專注於解決產品本身的流計算需求。
四、數據查詢分析
Hive的核心工作就是把SQL語句翻譯成MR程序，可以將結構化的數據映射為一張資料庫表，並提供 HQL(Hive SQL)查詢功能。Hive本身不存儲和計算數據，它完全依賴於HDFS和MapRece。可以將Hive理解為一個客戶端工具，將SQL操作轉換為相應的MapRece jobs，然後在hadoop上面運行。Hive支持標準的SQL語法，免去了用戶編寫MapRece程序的過程，它的出現可以讓那些精通SQL技能、但是不熟悉MapRece 、編程能力較弱與不擅長Java語言的用戶能夠在HDFS大規模數據集上很方便地利用SQL 語言查詢、匯總、分析數據。
Hive是為大數據批量處理而生的，Hive的出現解決了傳統的關系型資料庫(MySql、Oracle)在大數據處理上的瓶頸 。Hive 將執行計劃分成map->shuffle->rece->map->shuffle->rece…的模型。如果一個Query會被編譯成多輪MapRece，則會有更多的寫中間結果。由於MapRece執行框架本身的特點，過多的中間過程會增加整個Query的執行時間。在Hive的運行過程中，用戶只需要創建表，導入數據，編寫SQL分析語句即可。剩下的過程由Hive框架自動的完成。
Impala是對Hive的一個補充，可以實現高效的SQL查詢。使用Impala來實現SQL on Hadoop，用來進行大數據實時查詢分析。通過熟悉的傳統關系型資料庫的SQL風格來操作大數據，同時數據也是可以存儲到HDFS和HBase中的。Impala沒有再使用緩慢的Hive+MapRece批處理，而是通過使用與商用並行關系資料庫中類似的分布式查詢引擎（由Query Planner、Query Coordinator和Query Exec Engine三部分組成），可以直接從HDFS或HBase中用SELECT、JOIN和統計函數查詢數據，從而大大降低了延遲。Impala將整個查詢分成一執行計劃樹，而不是一連串的MapRece任務，相比Hive沒了MapRece啟動時間。
Hive 適合於長時間的批處理查詢分析，而Impala適合於實時互動式SQL查詢，Impala給數據人員提供了快速實驗，驗證想法的大數據分析工具，可以先使用Hive進行數據轉換處理，之後使用Impala在Hive處理好後的數據集上進行快速的數據分析。總的來說：Impala把執行計劃表現為一棵完整的執行計劃樹，可以更自然地分發執行計劃到各個Impalad執行查詢，而不用像Hive那樣把它組合成管道型的map->rece模式，以此保證Impala有更好的並發性和避免不必要的中間sort與shuffle。但是Impala不支持UDF，能處理的問題有一定的限制。
Spark擁有Hadoop MapRece所具有的特點，它將Job中間輸出結果保存在內存中，從而不需要讀取HDFS。Spark 啟用了內存分布數據集，除了能夠提供互動式查詢外，它還可以優化迭代工作負載。Spark 是在 Scala 語言中實現的，它將 Scala 用作其應用程序框架。與 Hadoop 不同，Spark 和 Scala 能夠緊密集成，其中的 Scala 可以像操作本地集合對象一樣輕松地操作分布式數據集。
Nutch 是一個開源Java 實現的搜索引擎。它提供了我們運行自己的搜索引擎所需的全部工具，包括全文搜索和Web爬蟲。
Solr用Java編寫、運行在Servlet容器（如Apache Tomcat或Jetty）的一個獨立的企業級搜索應用的全文搜索伺服器。它對外提供類似於Web-service的API介面，用戶可以通過http請求，向搜索引擎伺服器提交一定格式的XML文件，生成索引；也可以通過Http Get操作提出查找請求，並得到XML格式的返回結果。
Elasticsearch是一個開源的全文搜索引擎，基於Lucene的搜索伺服器，可以快速的儲存、搜索和分析海量的數據。設計用於雲計算中，能夠達到實時搜索，穩定，可靠，快速，安裝使用方便。
還涉及到一些機器學習語言，比如，Mahout主要目標是創建一些可伸縮的機器學習演算法，供開發人員在Apache的許可下免費使用；深度學習框架Caffe以及使用數據流圖進行數值計算的開源軟體庫TensorFlow等，常用的機器學習演算法比如，貝葉斯、邏輯回歸、決策樹、神經網路、協同過濾等。
五、數據可視化
對接一些BI平台，將分析得到的數據進行可視化，用於指導決策服務。主流的BI平台比如，國外的敏捷BI Tableau、Qlikview、PowrerBI等，國內的SmallBI和新興的網易有數（可點擊這里免費試用）等。
在上面的每一個階段，保障數據的安全是不可忽視的問題。
基於網路身份認證的協議Kerberos，用來在非安全網路中，對個人通信以安全的手段進行身份認證，它允許某實體在非安全網路環境下通信，向另一個實體以一種安全的方式證明自己的身份。
控制許可權的ranger是一個Hadoop集群許可權框架，提供操作、監控、管理復雜的數據許可權，它提供一個集中的管理機制，管理基於yarn的Hadoop生態圈的所有數據許可權。可以對Hadoop生態的組件如Hive，Hbase進行細粒度的數據訪問控制。通過操作Ranger控制台，管理員可以輕松的通過配置策略來控制用戶訪問HDFS文件夾、HDFS文件、資料庫、表、欄位許可權。這些策略可以為不同的用戶和組來設置，同時許可權可與hadoop無縫對接。
⑷ 大數據開發常用的編程語言有哪些
1、Python語言
如果你的數據科學家不使用R，他們可能就會徹底了解Python。十多年來，Python在學術界當中一直很流行，尤其是在自然語言處理（NLP）等領域。因而，如果你有一個需要NLP處理的項目，就會面臨數量多得讓人眼花繚亂的選擇，包括經典的NTLK、使用GenSim的主題建模，或者超快、准確的spaCy。同樣，說到神經網路，Python同樣游刃有餘，有Theano和Tensorflow；隨後還有面向機器學習的scikit-learn，以及面向數據分析的NumPy和Pandas。
還有Juypter/iPython――這種基於Web的筆記本伺服器框架讓你可以使用一種可共享的日誌格式，將代碼、圖形以及幾乎任何對象混合起來。這一直是Python的殺手級功能之一，不過這年頭，這個概念證明大有用途，以至於出現在了奉行讀取－讀取－輸出－循環（REPL）概念的幾乎所有語言上，包括Scala和R。
Python往往在大數據處理框架中得到支持，但與此同時，它往往又不是「一等公民」。比如說，Spark中的新功能幾乎總是出現在Scala/Java綁定的首位，可能需要用PySpark編寫面向那些更新版的幾個次要版本（對Spark Streaming/MLLib方面的開發工具而言尤為如此）。
與R相反，Python是一種傳統的面向對象語言，所以大多數開發人員用起來會相當得心應手，而初次接觸R或Scala會讓人心生畏懼。一個小問題就是你的代碼中需要留出正確的空白處。這將人員分成兩大陣營，一派覺得「這非常有助於確保可讀性」，另一派則認為，我們應該不需要就因為一行代碼有個字元不在適當的位置，就要迫使解釋器讓程序運行起來。
2、R語言
在過去的幾年時間中，R語言已經成為了數據科學的寵兒——數據科學現在不僅僅在書獃子一樣的統計學家中人盡皆知，而且也為華爾街交易員，生物學家，和矽谷開發者所家喻戶曉。各種行業的公司，例如Google，Facebook，美國銀行，以及紐約時報都使用R語言，R語言正在商業用途上持續蔓延和擴散。
R語言有著簡單而明顯的吸引力。使用R語言，只需要短短的幾行代碼，你就可以在復雜的數據集中篩選，通過先進的建模函數處理數據，以及創建平整的圖形來代表數字。它被比喻為是Excel的一個極度活躍版本。
R語言最偉大的資本是已圍繞它開發的充滿活力的生態系統：R語言社區總是在不斷地添加新的軟體包和功能到它已經相當豐富的功能集中。據估計，超過200萬的人使用R語言，並且最近的一次投票表明，R語言是迄今為止在科學數據中最流行的語言，被61%的受訪者使用(其次是Python，39%)。
3、JAVA
Java，以及基於Java的框架，被發現儼然成為了矽谷最大的那些高科技公司的骨骼支架。 「如果你去看Twitter，LinkedIn和Facebook，那麼你會發現，Java是它們所有數據工程基礎設施的基礎語言，」Driscoll說。
Java不能提供R和Python同樣質量的可視化，並且它並非統計建模的最佳選擇。但是，如果你移動到過去的原型製作並需要建立大型系統，那麼Java往往是你的最佳選擇。
4、Hadoop和Hive
一群基於Java的工具被開發出來以滿足數據處理的巨大需求。Hadoop作為首選的基於Java的框架用於批處理數據已經點燃了大家的熱情。Hadoop比其他一些處理工具慢，但它出奇的准確，因此被廣泛用於後端分析。它和Hive——一個基於查詢並且運行在頂部的框架可以很好地結對工作。
⑸ spark和hadoop的區別
直接比較Hadoop和Spark有難度，因為它們處理的許多任務都一樣，但是在一些方面又並不相互重疊。
比如說，Spark沒有文件管理功能，因而必須依賴Hadoop分布式文件系統(HDFS)或另外某種解決方案。
Hadoop框架的主要模塊包括如下：
Hadoop Common
Hadoop分布式文件系統(HDFS)
Hadoop YARN
Hadoop MapRece
分區列表
計算每個分片的函數
依賴其他RDD的項目列表
面向鍵值RDD的分區程序(比如說RDD是散列分區)，這是可選屬性
計算每個分片的首選位置的列表(比如HDFS文件的數據塊位置)，這是可選屬性
雖然上述四個模塊構成了Hadoop的核心，不過還有其他幾個模塊。這些模塊包括：Ambari、Avro、Cassandra、Hive、 Pig、Oozie、Flume和Sqoop，它們進一步增強和擴展了Hadoop的功能。
Spark確實速度很快(最多比Hadoop MapRece快100倍)。Spark還可以執行批量處理，然而它真正擅長的是處理流工作負載、互動式查詢和機器學習。
相比MapRece基於磁碟的批量處理引擎，Spark賴以成名之處是其數據實時處理功能。Spark與Hadoop及其模塊兼容。實際上，在Hadoop的項目頁面上，Spark就被列為是一個模塊。
Spark有自己的頁面，因為雖然它可以通過YARN(另一種資源協調者)在Hadoop集群中運行，但是它也有一種獨立模式。它可以作為 Hadoop模塊來運行，也可以作為獨立解決方案來運行。
MapRece和Spark的主要區別在於，MapRece使用持久存儲，而Spark使用彈性分布式數據集(RDDS)。
性能
Spark之所以如此快速，原因在於它在內存中處理一切數據。沒錯，它還可以使用磁碟來處理未全部裝入到內存中的數據。
Spark的內存處理為來自多個來源的數據提供了近乎實時分析的功能：營銷活動、機器學習、物聯網感測器、日誌監控、安全分析和社交媒體網站。另 外，MapRece使用批量處理，其實從來就不是為驚人的速度設計的。它的初衷是不斷收集來自網站的信息，不需要這些數據具有實時性或近乎實時性。
易用性
支持Scala(原生語言)、Java、Python和Spark SQL。Spark SQL非常類似於SQL 92，所以幾乎不需要經歷一番學習，馬上可以上手。
Spark還有一種交互模式，那樣開發人員和用戶都可以獲得查詢和其他操作的即時反饋。MapRece沒有交互模式，不過有了Hive和Pig等附加模塊，採用者使用MapRece來得容易一點。
成本
「Spark已證明在數據多達PB的情況下也輕松自如。它被用於在數量只有十分之一的機器上，對100TB數據進行排序的速度比Hadoop MapRece快3倍。」這一成績讓Spark成為2014年Daytona GraySort基準。
兼容性
MapRece和Spark相互兼容;MapRece通過JDBC和ODC兼容諸多數據源、文件格式和商業智能工具，Spark具有與MapRece同樣的兼容性。
數據處理
MapRece是一種批量處理引擎。MapRece以順序步驟來操作，先從集群讀取數據，然後對數據執行操作，將結果寫回到集群，從集群讀 取更新後的數據，執行下一個數據操作，將那些結果寫回到結果，依次類推。Spark執行類似的操作，不過是在內存中一步執行。它從集群讀取數據後，對數據 執行操作，然後寫回到集群。
Spark還包括自己的圖形計算庫GraphX。GraphX讓用戶可以查看與圖形和集合同樣的數據。用戶還可以使用彈性分布式數據集(RDD)，改變和聯合圖形，容錯部分作了討論。
容錯
至於容錯，MapRece和Spark從兩個不同的方向來解決問題。MapRece使用TaskTracker節點，它為 JobTracker節點提供了心跳(heartbeat)。如果沒有心跳，那麼JobTracker節點重新調度所有將執行的操作和正在進行的操作，交 給另一個TaskTracker節點。這種方法在提供容錯性方面很有效，可是會大大延長某些操作(即便只有一個故障)的完成時間。
Spark使用彈性分布式數據集(RDD)，它們是容錯集合，裡面的數據元素可執行並行操作。RDD可以引用外部存儲系統中的數據集，比如共享式文件系統、HDFS、HBase，或者提供Hadoop InputFormat的任何數據源。Spark可以用Hadoop支持的任何存儲源創建RDD，包括本地文件系統，或前面所列的其中一種文件系統。
RDD擁有五個主要屬性：
RDD可能具有持久性，以便將數據集緩存在內存中。這樣一來，以後的操作大大加快，最多達10倍。Spark的緩存具有容錯性，原因在於如果RDD的任何分區丟失，就會使用原始轉換，自動重新計算。
可擴展性
按照定義，MapRece和Spark都可以使用HDFS來擴展。那麼，Hadoop集群能變得多大呢?
據稱雅虎有一套42000個節點組成的Hadoop集群，可以說擴展無極限。最大的已知Spark集群是8000個節點，不過隨著大數據增多，預計集群規模也會隨之變大，以便繼續滿足吞吐量方面的預期。
安全
Hadoop支持Kerberos身份驗證，這管理起來有麻煩。然而，第三方廠商讓企業組織能夠充分利用活動目錄Kerberos和LDAP用於身份驗證。同樣那些第三方廠商還為傳輸中數據和靜態數據提供數據加密。
Hadoop分布式文件系統支持訪問控制列表(ACL)和傳統的文件許可權模式。Hadoop為任務提交中的用戶控制提供了服務級授權(Service Level Authorization)，這確保客戶擁有正確的許可權。
Spark的安全性弱一點，目前只支持通過共享密鑰(密碼驗證)的身份驗證。Spark在安全方面帶來的好處是，如果你在HDFS上運行Spark，它可以使用HDFS ACL和文件級許可權。此外，Spark可以在YARN上運行，因而能夠使用Kerberos身份驗證。
總結
Spark與MapRece是一種相互共生的關系。Hadoop提供了Spark所沒有的功能特性，比如分布式文件系統，而Spark 為需要它的那些數據集提供了實時內存處理。完美的大數據場景正是設計人員當初預想的那樣：讓Hadoop和Spark在同一個團隊裡面協同運行。
⑹ 做大數據分析系統Hadoop需要用哪些軟體
1、ApacheMesos
代碼託管地址：ApacheSVN
Mesos提供了高效、跨分布式應用程序和框架的資源隔離和共享，支持Hadoop、MPI、Hypertable、Spark等。
Mesos是Apache孵化器中的一個開源項目，使用ZooKeeper實現容錯復制，使用LinuxContainers來隔離任務，支持多種資源計劃分配(內存和CPU)。提供Java、Python和C++APIs來開發新的並行應用程序，提供基於Web的用戶界面來提查看集群狀態。
2、HadoopYARN
代碼託管地址：ApacheSVN
YARN又被稱為MapRece2.0，借鑒Mesos，YARN提出了資源隔離解決方案Container，但是目前尚未成熟，僅僅提供Java虛擬機內存的隔離。
對比MapRece1.x，YARN架構在客戶端上並未做太大的改變，在調用API及介面上還保持大部分的兼容，然而在YARN中，開發人員使用ResourceManager、ApplicationMaster與NodeManager代替了原框架中核心的JobTracker和TaskTracker。其中ResourceManager是一個中心的服務，負責調度、啟動每一個Job所屬的ApplicationMaster，另外還監控ApplicationMaster的存在情況;NodeManager負責Container狀態的維護，並向RM保持心跳。ApplicationMaster負責一個Job生命周期內的所有工作，類似老的框架中JobTracker。
Hadoop上的實時解決方案
前面我們有說過，在互聯網公司中基於業務邏輯需求，企業往往會採用多種計算框架，比如從事搜索業務的公司：網頁索引建立用MapRece，自然語言處理用Spark等。
3、ClouderaImpala
代碼託管地址：GitHub
Impala是由Cloudera開發，一個開源的MassivelyParallelProcessing(MPP)查詢引擎。與Hive相同的元數據、SQL語法、ODBC驅動程序和用戶介面(HueBeeswax)，可以直接在HDFS或HBase上提供快速、互動式SQL查詢。Impala是在Dremel的啟發下開發的，第一個版本發布於2012年末。
Impala不再使用緩慢的Hive+MapRece批處理，而是通過與商用並行關系資料庫中類似的分布式查詢引擎(由QueryPlanner、QueryCoordinator和QueryExecEngine三部分組成)，可以直接從HDFS或者HBase中用SELECT、JOIN和統計函數查詢數據，從而大大降低了延遲。
4、Spark
代碼託管地址：Apache
Spark是個開源的數據分析集群計算框架，最初由加州大學伯克利分校AMPLab開發，建立於HDFS之上。Spark與Hadoop一樣，用於構建大規模、低延時的數據分析應用。Spark採用Scala語言實現，使用Scala作為應用框架。
Spark採用基於內存的分布式數據集，優化了迭代式的工作負載以及互動式查詢。與Hadoop不同的是，Spark和Scala緊密集成，Scala像管理本地collective對象那樣管理分布式數據集。Spark支持分布式數據集上的迭代式任務，實際上可以在Hadoop文件系統上與Hadoop一起運行(通過YARN、Mesos等實現)。
5、Storm
代碼託管地址：GitHub
Storm是一個分布式的、容錯的實時計算系統，由BackType開發，後被Twitter捕獲。Storm屬於流處理平台，多用於實時計算並更新資料庫。Storm也可被用於「連續計算」(continuouscomputation)，對數據流做連續查詢，在計算時就將結果以流的形式輸出給用戶。它還可被用於「分布式RPC」，以並行的方式運行昂貴的運算。
Hadoop上的其它解決方案
就像前文說，基於業務對實時的需求，各個實驗室發明了Storm、Impala、Spark、Samza等流實時處理工具。而本節我們將分享的是實驗室基於性能、兼容性、數據類型研究的開源解決方案，其中包括Shark、Phoenix、ApacheAccumulo、ApacheDrill、ApacheGiraph、ApacheHama、ApacheTez、ApacheAmbari。
6、Shark
代碼託管地址：GitHub
Shark，代表了「HiveonSpark」，一個專為Spark打造的大規模數據倉庫系統，兼容ApacheHive。無需修改現有的數據或者查詢，就可以用100倍的速度執行HiveQL。
Shark支持Hive查詢語言、元存儲、序列化格式及自定義函數，與現有Hive部署無縫集成，是一個更快、更強大的替代方案。
7、Phoenix
代碼託管地址：GitHub
Phoenix是構建在ApacheHBase之上的一個SQL中間層，完全使用Java編寫，提供了一個客戶端可嵌入的JDBC驅動。Phoenix查詢引擎會將SQL查詢轉換為一個或多個HBasescan，並編排執行以生成標準的JDBC結果集。直接使用HBaseAPI、協同處理器與自定義過濾器，對於簡單查詢來說，其性能量級是毫秒，對於百萬級別的行數來說，其性能量級是秒。Phoenix完全託管在GitHub之上。
Phoenix值得關注的特性包括：1，嵌入式的JDBC驅動，實現了大部分的java.sql介面，包括元數據API;2，可以通過多個行鍵或是鍵/值單元對列進行建模;3，DDL支持;4，版本化的模式倉庫;5，DML支持;5，通過客戶端的批處理實現的有限的事務支持;6，緊跟ANSISQL標准。
8、ApacheAccumulo
代碼託管地址：ApacheSVN
ApacheAccumulo是一個可靠的、可伸縮的、高性能、排序分布式的鍵值存儲解決方案，基於單元訪問控制以及可定製的伺服器端處理。使用GoogleBigTable設計思路，基於ApacheHadoop、Zookeeper和Thrift構建。Accumulo最早由NSA開發，後被捐獻給了Apache基金會。
對比GoogleBigTable，Accumulo主要提升在基於單元的訪問及伺服器端的編程機制，後一處修改讓Accumulo可以在數據處理過程中任意點修改鍵值對。
9、ApacheDrill
代碼託管地址：GitHub
本質上，ApacheDrill是GoogleDremel的開源實現，本質是一個分布式的mpp查詢層，支持SQL及一些用於NoSQL和Hadoop數據存儲系統上的語言，將有助於Hadoop用戶實現更快查詢海量數據集的目的。當下Drill還只能算上一個框架，只包含了Drill願景中的初始功能。
Drill的目的在於支持更廣泛的數據源、數據格式及查詢語言，可以通過對PB位元組數據的快速掃描(大約幾秒內)完成相關分析，將是一個專為互動分析大型數據集的分布式系統。
10、ApacheGiraph
代碼託管地址：GitHub
ApacheGiraph是一個可伸縮的分布式迭代圖處理系統，靈感來自BSP(bulksynchronousparallel)和Google的Pregel，與它們區別於則是是開源、基於Hadoop的架構等。
Giraph處理平台適用於運行大規模的邏輯計算，比如頁面排行、共享鏈接、基於個性化排行等。Giraph專注於社交圖計算，被Facebook作為其OpenGraph工具的核心，幾分鍾內處理數萬億次用戶及其行為之間的連接。
11、ApacheHama
代碼託管地址：GitHub
ApacheHama是一個建立在Hadoop上基於BSP(BulkSynchronousParallel)的計算框架，模仿了Google的Pregel。用來處理大規模的科學計算，特別是矩陣和圖計算。集群環境中的系統架構由BSPMaster/GroomServer(ComputationEngine)、Zookeeper(DistributedLocking)、HDFS/HBase(StorageSystems)這3大塊組成。
12、ApacheTez
代碼託管地址：GitHub
ApacheTez是基於HadoopYarn之上的DAG(有向無環圖，DirectedAcyclicGraph)計算框架。它把Map/Rece過程拆分成若干個子過程，同時可以把多個Map/Rece任務組合成一個較大的DAG任務，減少了Map/Rece之間的文件存儲。同時合理組合其子過程，減少任務的運行時間。由Hortonworks開發並提供主要支持。
13、ApacheAmbari
代碼託管地址：ApacheSVN
ApacheAmbari是一個供應、管理和監視ApacheHadoop集群的開源框架，它提供一個直觀的操作工具和一個健壯的HadoopAPI,可以隱藏復雜的Hadoop操作，使集群操作大大簡化，首個版本發布於2012年6月。
ApacheAmbari現在是一個Apache的頂級項目，早在2011年8月，Hortonworks引進Ambari作為ApacheIncubator項目，制定了Hadoop集群極致簡單管理的願景。在兩年多的開發社區顯著成長，從一個小團隊，成長為Hortonworks各種組織的貢獻者。Ambari用戶群一直在穩步增長，許多機構依靠Ambari在其大型數據中心大規模部署和管理Hadoop集群。
目前ApacheAmbari支持的Hadoop組件包括：HDFS、MapRece、Hive、HCatalog、HBase、ZooKeeper、Oozie、Pig及Sqoop。
⑺ 五種大數據處理架構
五種大數據處理架構
大數據是收集、整理、處理大容量數據集，並從中獲得見解所需的非傳統戰略和技術的總稱。雖然處理數據所需的計算能力或存儲容量早已超過一台計算機的上限，但這種計算類型的普遍性、規模，以及價值在最近幾年才經歷了大規模擴展。
本文將介紹大數據系統一個最基本的組件：處理框架。處理框架負責對系統中的數據進行計算，例如處理從非易失存儲中讀取的數據，或處理剛剛攝入到系統中的數據。數據的計算則是指從大量單一數據點中提取信息和見解的過程。
下文將介紹這些框架：
· 僅批處理框架：
Apache Hadoop
· 僅流處理框架：
Apache Storm
Apache Samza
· 混合框架：
Apache Spark
Apache Flink
大數據處理框架是什麼？
處理框架和處理引擎負責對數據系統中的數據進行計算。雖然「引擎」和「框架」之間的區別沒有什麼權威的定義，但大部分時候可以將前者定義為實際負責處理數據操作的組件，後者則可定義為承擔類似作用的一系列組件。
例如Apache Hadoop可以看作一種以MapRece作為默認處理引擎的處理框架。引擎和框架通常可以相互替換或同時使用。例如另一個框架Apache Spark可以納入Hadoop並取代MapRece。組件之間的這種互操作性是大數據系統靈活性如此之高的原因之一。
雖然負責處理生命周期內這一階段數據的系統通常都很復雜，但從廣義層面來看它們的目標是非常一致的：通過對數據執行操作提高理解能力，揭示出數據蘊含的模式，並針對復雜互動獲得見解。
為了簡化這些組件的討論，我們會通過不同處理框架的設計意圖，按照所處理的數據狀態對其進行分類。一些系統可以用批處理方式處理數據，一些系統可以用流方式處理連續不斷流入系統的數據。此外還有一些系統可以同時處理這兩類數據。
在深入介紹不同實現的指標和結論之前，首先需要對不同處理類型的概念進行一個簡單的介紹。
批處理系統
批處理在大數據世界有著悠久的歷史。批處理主要操作大容量靜態數據集，並在計算過程完成後返回結果。
批處理模式中使用的數據集通常符合下列特徵…
· 有界：批處理數據集代表數據的有限集合
· 持久：數據通常始終存儲在某種類型的持久存儲位置中
· 大量：批處理操作通常是處理極為海量數據集的唯一方法
批處理非常適合需要訪問全套記錄才能完成的計算工作。例如在計算總數和平均數時，必須將數據集作為一個整體加以處理，而不能將其視作多條記錄的集合。這些操作要求在計算進行過程中數據維持自己的狀態。
需要處理大量數據的任務通常最適合用批處理操作進行處理。無論直接從持久存儲設備處理數據集，或首先將數據集載入內存，批處理系統在設計過程中就充分考慮了數據的量，可提供充足的處理資源。由於批處理在應對大量持久數據方面的表現極為出色，因此經常被用於對歷史數據進行分析。
大量數據的處理需要付出大量時間，因此批處理不適合對處理時間要求較高的場合。
Apache Hadoop
Apache Hadoop是一種專用於批處理的處理框架。Hadoop是首個在開源社區獲得極大關注的大數據框架。基於谷歌有關海量數據處理所發表的多篇論文與經驗的Hadoop重新實現了相關演算法和組件堆棧，讓大規模批處理技術變得更易用。
新版Hadoop包含多個組件，即多個層，通過配合使用可處理批數據：
· HDFS：HDFS是一種分布式文件系統層，可對集群節點間的存儲和復制進行協調。HDFS確保了無法避免的節點故障發生後數據依然可用，可將其用作數據來源，可用於存儲中間態的處理結果，並可存儲計算的最終結果。
· YARN：YARN是Yet Another Resource Negotiator（另一個資源管理器）的縮寫，可充當Hadoop堆棧的集群協調組件。該組件負責協調並管理底層資源和調度作業的運行。通過充當集群資源的介面，YARN使得用戶能在Hadoop集群中使用比以往的迭代方式運行更多類型的工作負載。
· MapRece：MapRece是Hadoop的原生批處理引擎。
批處理模式
Hadoop的處理功能來自MapRece引擎。MapRece的處理技術符合使用鍵值對的map、shuffle、rece演算法要求。基本處理過程包括：
· 從HDFS文件系統讀取數據集
· 將數據集拆分成小塊並分配給所有可用節點
· 針對每個節點上的數據子集進行計算（計算的中間態結果會重新寫入HDFS）
· 重新分配中間態結果並按照鍵進行分組
· 通過對每個節點計算的結果進行匯總和組合對每個鍵的值進行「Recing」
· 將計算而來的最終結果重新寫入 HDFS
優勢和局限
由於這種方法嚴重依賴持久存儲，每個任務需要多次執行讀取和寫入操作，因此速度相對較慢。但另一方面由於磁碟空間通常是伺服器上最豐富的資源，這意味著MapRece可以處理非常海量的數據集。同時也意味著相比其他類似技術，Hadoop的MapRece通常可以在廉價硬體上運行，因為該技術並不需要將一切都存儲在內存中。MapRece具備極高的縮放潛力，生產環境中曾經出現過包含數萬個節點的應用。
MapRece的學習曲線較為陡峭，雖然Hadoop生態系統的其他周邊技術可以大幅降低這一問題的影響，但通過Hadoop集群快速實現某些應用時依然需要注意這個問題。
圍繞Hadoop已經形成了遼闊的生態系統，Hadoop集群本身也經常被用作其他軟體的組成部件。很多其他處理框架和引擎通過與Hadoop集成也可以使用HDFS和YARN資源管理器。
總結
Apache Hadoop及其MapRece處理引擎提供了一套久經考驗的批處理模型，最適合處理對時間要求不高的非常大規模數據集。通過非常低成本的組件即可搭建完整功能的Hadoop集群，使得這一廉價且高效的處理技術可以靈活應用在很多案例中。與其他框架和引擎的兼容與集成能力使得Hadoop可以成為使用不同技術的多種工作負載處理平台的底層基礎。
流處理系統
流處理系統會對隨時進入系統的數據進行計算。相比批處理模式，這是一種截然不同的處理方式。流處理方式無需針對整個數據集執行操作，而是對通過系統傳輸的每個數據項執行操作。
· 流處理中的數據集是「無邊界」的，這就產生了幾個重要的影響：
· 完整數據集只能代表截至目前已經進入到系統中的數據總量。
· 工作數據集也許更相關，在特定時間只能代表某個單一數據項。
處理工作是基於事件的，除非明確停止否則沒有「盡頭」。處理結果立刻可用，並會隨著新數據的抵達繼續更新。
流處理系統可以處理幾乎無限量的數據，但同一時間只能處理一條（真正的流處理）或很少量（微批處理，Micro-batch Processing）數據，不同記錄間只維持最少量的狀態。雖然大部分系統提供了用於維持某些狀態的方法，但流處理主要針對副作用更少，更加功能性的處理（Functional processing）進行優化。
功能性操作主要側重於狀態或副作用有限的離散步驟。針對同一個數據執行同一個操作會或略其他因素產生相同的結果，此類處理非常適合流處理，因為不同項的狀態通常是某些困難、限制，以及某些情況下不需要的結果的結合體。因此雖然某些類型的狀態管理通常是可行的，但這些框架通常在不具備狀態管理機制時更簡單也更高效。
此類處理非常適合某些類型的工作負載。有近實時處理需求的任務很適合使用流處理模式。分析、伺服器或應用程序錯誤日誌，以及其他基於時間的衡量指標是最適合的類型，因為對這些領域的數據變化做出響應對於業務職能來說是極為關鍵的。流處理很適合用來處理必須對變動或峰值做出響應，並且關注一段時間內變化趨勢的數據。
Apache Storm
Apache Storm是一種側重於極低延遲的流處理框架，也許是要求近實時處理的工作負載的最佳選擇。該技術可處理非常大量的數據，通過比其他解決方案更低的延遲提供結果。
流處理模式
Storm的流處理可對框架中名為Topology（拓撲）的DAG（Directed Acyclic Graph，有向無環圖）進行編排。這些拓撲描述了當數據片段進入系統後，需要對每個傳入的片段執行的不同轉換或步驟。
拓撲包含：
· Stream：普通的數據流，這是一種會持續抵達系統的無邊界數據。
· Spout：位於拓撲邊緣的數據流來源，例如可以是API或查詢等，從這里可以產生待處理的數據。
· Bolt：Bolt代表需要消耗流數據，對其應用操作，並將結果以流的形式進行輸出的處理步驟。Bolt需要與每個Spout建立連接，隨後相互連接以組成所有必要的處理。在拓撲的尾部，可以使用最終的Bolt輸出作為相互連接的其他系統的輸入。
Storm背後的想法是使用上述組件定義大量小型的離散操作，隨後將多個組件組成所需拓撲。默認情況下Storm提供了「至少一次」的處理保證，這意味著可以確保每條消息至少可以被處理一次，但某些情況下如果遇到失敗可能會處理多次。Storm無法確保可以按照特定順序處理消息。
為了實現嚴格的一次處理，即有狀態處理，可以使用一種名為Trident的抽象。嚴格來說不使用Trident的Storm通常可稱之為Core Storm。Trident會對Storm的處理能力產生極大影響，會增加延遲，為處理提供狀態，使用微批模式代替逐項處理的純粹流處理模式。
為避免這些問題，通常建議Storm用戶盡可能使用Core Storm。然而也要注意，Trident對內容嚴格的一次處理保證在某些情況下也比較有用，例如系統無法智能地處理重復消息時。如果需要在項之間維持狀態，例如想要計算一個小時內有多少用戶點擊了某個鏈接，此時Trident將是你唯一的選擇。盡管不能充分發揮框架與生俱來的優勢，但Trident提高了Storm的靈活性。
Trident拓撲包含：
· 流批（Stream batch）：這是指流數據的微批，可通過分塊提供批處理語義。
· 操作（Operation）：是指可以對數據執行的批處理過程。
優勢和局限
目前來說Storm可能是近實時處理領域的最佳解決方案。該技術可以用極低延遲處理數據，可用於希望獲得最低延遲的工作負載。如果處理速度直接影響用戶體驗，例如需要將處理結果直接提供給訪客打開的網站頁面，此時Storm將會是一個很好的選擇。
Storm與Trident配合使得用戶可以用微批代替純粹的流處理。雖然藉此用戶可以獲得更大靈活性打造更符合要求的工具，但同時這種做法會削弱該技術相比其他解決方案最大的優勢。話雖如此，但多一種流處理方式總是好的。
Core Storm無法保證消息的處理順序。Core Storm為消息提供了「至少一次」的處理保證，這意味著可以保證每條消息都能被處理，但也可能發生重復。Trident提供了嚴格的一次處理保證，可以在不同批之間提供順序處理，但無法在一個批內部實現順序處理。
在互操作性方面，Storm可與Hadoop的YARN資源管理器進行集成，因此可以很方便地融入現有Hadoop部署。除了支持大部分處理框架，Storm還可支持多種語言，為用戶的拓撲定義提供了更多選擇。
總結
對於延遲需求很高的純粹的流處理工作負載，Storm可能是最適合的技術。該技術可以保證每條消息都被處理，可配合多種編程語言使用。由於Storm無法進行批處理，如果需要這些能力可能還需要使用其他軟體。如果對嚴格的一次處理保證有比較高的要求，此時可考慮使用Trident。不過這種情況下其他流處理框架也許更適合。
Apache Samza
Apache Samza是一種與Apache Kafka消息系統緊密綁定的流處理框架。雖然Kafka可用於很多流處理系統，但按照設計，Samza可以更好地發揮Kafka獨特的架構優勢和保障。該技術可通過Kafka提供容錯、緩沖，以及狀態存儲。
Samza可使用YARN作為資源管理器。這意味著默認情況下需要具備Hadoop集群（至少具備HDFS和YARN），但同時也意味著Samza可以直接使用YARN豐富的內建功能。
流處理模式
Samza依賴Kafka的語義定義流的處理方式。Kafka在處理數據時涉及下列概念：
· Topic（話題）：進入Kafka系統的每個數據流可稱之為一個話題。話題基本上是一種可供消耗方訂閱的，由相關信息組成的數據流。
· Partition（分區）：為了將一個話題分散至多個節點，Kafka會將傳入的消息劃分為多個分區。分區的劃分將基於鍵（Key）進行，這樣可以保證包含同一個鍵的每條消息可以劃分至同一個分區。分區的順序可獲得保證。
· Broker（代理）：組成Kafka集群的每個節點也叫做代理。
· Procer（生成方）：任何向Kafka話題寫入數據的組件可以叫做生成方。生成方可提供將話題劃分為分區所需的鍵。
· Consumer（消耗方）：任何從Kafka讀取話題的組件可叫做消耗方。消耗方需要負責維持有關自己分支的信息，這樣即可在失敗後知道哪些記錄已經被處理過了。
由於Kafka相當於永恆不變的日誌，Samza也需要處理永恆不變的數據流。這意味著任何轉換創建的新數據流都可被其他組件所使用，而不會對最初的數據流產生影響。
優勢和局限
乍看之下，Samza對Kafka類查詢系統的依賴似乎是一種限制，然而這也可以為系統提供一些獨特的保證和功能，這些內容也是其他流處理系統不具備的。
例如Kafka已經提供了可以通過低延遲方式訪問的數據存儲副本，此外還可以為每個數據分區提供非常易用且低成本的多訂閱者模型。所有輸出內容，包括中間態的結果都可寫入到Kafka，並可被下游步驟獨立使用。
這種對Kafka的緊密依賴在很多方面類似於MapRece引擎對HDFS的依賴。雖然在批處理的每個計算之間對HDFS的依賴導致了一些嚴重的性能問題，但也避免了流處理遇到的很多其他問題。
Samza與Kafka之間緊密的關系使得處理步驟本身可以非常鬆散地耦合在一起。無需事先協調，即可在輸出的任何步驟中增加任意數量的訂閱者，對於有多個團隊需要訪問類似數據的組織，這一特性非常有用。多個團隊可以全部訂閱進入系統的數據話題，或任意訂閱其他團隊對數據進行過某些處理後創建的話題。這一切並不會對資料庫等負載密集型基礎架構造成額外的壓力。
直接寫入Kafka還可避免回壓（Backpressure）問題。回壓是指當負載峰值導致數據流入速度超過組件實時處理能力的情況，這種情況可能導致處理工作停頓並可能丟失數據。按照設計，Kafka可以將數據保存很長時間，這意味著組件可以在方便的時候繼續進行處理，並可直接重啟動而無需擔心造成任何後果。
Samza可以使用以本地鍵值存儲方式實現的容錯檢查點系統存儲數據。這樣Samza即可獲得「至少一次」的交付保障，但面對由於數據可能多次交付造成的失敗，該技術無法對匯總後狀態（例如計數）提供精確恢復。
Samza提供的高級抽象使其在很多方面比Storm等系統提供的基元（Primitive）更易於配合使用。目前Samza只支持JVM語言，這意味著它在語言支持方面不如Storm靈活。
總結
對於已經具備或易於實現Hadoop和Kafka的環境，Apache Samza是流處理工作負載一個很好的選擇。Samza本身很適合有多個團隊需要使用（但相互之間並不一定緊密協調）不同處理階段的多個數據流的組織。Samza可大幅簡化很多流處理工作，可實現低延遲的性能。如果部署需求與當前系統不兼容，也許並不適合使用，但如果需要極低延遲的處理，或對嚴格的一次處理語義有較高需求，此時依然適合考慮。
混合處理系統：批處理和流處理
一些處理框架可同時處理批處理和流處理工作負載。這些框架可以用相同或相關的組件和API處理兩種類型的數據，藉此讓不同的處理需求得以簡化。
如你所見，這一特性主要是由Spark和Flink實現的，下文將介紹這兩種框架。實現這樣的功能重點在於兩種不同處理模式如何進行統一，以及要對固定和不固定數據集之間的關系進行何種假設。
雖然側重於某一種處理類型的項目會更好地滿足具體用例的要求，但混合框架意在提供一種數據處理的通用解決方案。這種框架不僅可以提供處理數據所需的方法，而且提供了自己的集成項、庫、工具，可勝任圖形分析、機器學習、互動式查詢等多種任務。
Apache Spark
Apache Spark是一種包含流處理能力的下一代批處理框架。與Hadoop的MapRece引擎基於各種相同原則開發而來的Spark主要側重於通過完善的內存計算和處理優化機制加快批處理工作負載的運行速度。
Spark可作為獨立集群部署（需要相應存儲層的配合），或可與Hadoop集成並取代MapRece引擎。
批處理模式
與MapRece不同，Spark的數據處理工作全部在內存中進行，只在一開始將數據讀入內存，以及將最終結果持久存儲時需要與存儲層交互。所有中間態的處理結果均存儲在內存中。
雖然內存中處理方式可大幅改善性能，Spark在處理與磁碟有關的任務時速度也有很大提升，因為通過提前對整個任務集進行分析可以實現更完善的整體式優化。為此Spark可創建代表所需執行的全部操作，需要操作的數據，以及操作和數據之間關系的Directed Acyclic Graph（有向無環圖），即DAG，藉此處理器可以對任務進行更智能的協調。
為了實現內存中批計算，Spark會使用一種名為Resilient Distributed Dataset（彈性分布式數據集），即RDD的模型來處理數據。這是一種代表數據集，只位於內存中，永恆不變的結構。針對RDD執行的操作可生成新的RDD。每個RDD可通過世系（Lineage）回溯至父級RDD，並最終回溯至磁碟上的數據。Spark可通過RDD在無需將每個操作的結果寫回磁碟的前提下實現容錯。
流處理模式
流處理能力是由Spark Streaming實現的。Spark本身在設計上主要面向批處理工作負載，為了彌補引擎設計和流處理工作負載特徵方面的差異，Spark實現了一種叫做微批（Micro-batch）*的概念。在具體策略方面該技術可以將數據流視作一系列非常小的「批」，藉此即可通過批處理引擎的原生語義進行處理。
Spark Streaming會以亞秒級增量對流進行緩沖，隨後這些緩沖會作為小規模的固定數據集進行批處理。這種方式的實際效果非常好，但相比真正的流處理框架在性能方面依然存在不足。
優勢和局限
使用Spark而非Hadoop MapRece的主要原因是速度。在內存計算策略和先進的DAG調度等機制的幫助下，Spark可以用更快速度處理相同的數據集。
Spark的另一個重要優勢在於多樣性。該產品可作為獨立集群部署，或與現有Hadoop集群集成。該產品可運行批處理和流處理，運行一個集群即可處理不同類型的任務。
除了引擎自身的能力外，圍繞Spark還建立了包含各種庫的生態系統，可為機器學習、互動式查詢等任務提供更好的支持。相比MapRece，Spark任務更是「眾所周知」地易於編寫，因此可大幅提高生產力。
為流處理系統採用批處理的方法，需要對進入系統的數據進行緩沖。緩沖機制使得該技術可以處理非常大量的傳入數據，提高整體吞吐率，但等待緩沖區清空也會導致延遲增高。這意味著Spark Streaming可能不適合處理對延遲有較高要求的工作負載。
由於內存通常比磁碟空間更貴，因此相比基於磁碟的系統，Spark成本更高。然而處理速度的提升意味著可以更快速完成任務，在需要按照小時數為資源付費的環境中，這一特性通常可以抵消增加的成本。
Spark內存計算這一設計的另一個後果是，如果部署在共享的集群中可能會遇到資源不足的問題。相比HadoopMapRece，Spark的資源消耗更大，可能會對需要在同一時間使用集群的其他任務產生影響。從本質來看，Spark更不適合與Hadoop堆棧的其他組件共存一處。
總結
Spark是多樣化工作負載處理任務的最佳選擇。Spark批處理能力以更高內存佔用為代價提供了無與倫比的速度優勢。對於重視吞吐率而非延遲的工作負載，則比較適合使用Spark Streaming作為流處理解決方案。
Apache Flink
Apache Flink是一種可以處理批處理任務的流處理框架。該技術可將批處理數據視作具備有限邊界的數據流，藉此將批處理任務作為流處理的子集加以處理。為所有處理任務採取流處理為先的方法會產生一系列有趣的副作用。
這種流處理為先的方法也叫做Kappa架構，與之相對的是更加被廣為人知的Lambda架構（該架構中使用批處理作為主要處理方法，使用流作為補充並提供早期未經提煉的結果）。Kappa架構中會對一切進行流處理，藉此對模型進行簡化，而這一切是在最近流處理引擎逐漸成熟後才可行的。
流處理模型
Flink的流處理模型在處理傳入數據時會將每一項視作真正的數據流。Flink提供的DataStream API可用於處理無盡的數據流。Flink可配合使用的基本組件包括：
· Stream（流）是指在系統中流轉的，永恆不變的無邊界數據集
· Operator（操作方）是指針對數據流執行操作以產生其他數據流的功能
· Source（源）是指數據流進入系統的入口點
· Sink（槽）是指數據流離開Flink系統後進入到的位置，槽可以是資料庫或到其他系統的連接器
為了在計算過程中遇到問題後能夠恢復，流處理任務會在預定時間點創建快照。為了實現狀態存儲，Flink可配合多種狀態後端系統使用，具體取決於所需實現的復雜度和持久性級別。
此外Flink的流處理能力還可以理解「事件時間」這一概念，這是指事件實際發生的時間，此外該功能還可以處理會話。這意味著可以通過某種有趣的方式確保執行順序和分組。
批處理模型
Flink的批處理模型在很大程度上僅僅是對流處理模型的擴展。此時模型不再從持續流中讀取數據，而是從持久存儲中以流的形式讀取有邊界的數據集。Flink會對這些處理模型使用完全相同的運行時。
Flink可以對批處理工作負載實現一定的優化。例如由於批處理操作可通過持久存儲加以支持，Flink可以不對批處理工作負載創建快照。數據依然可以恢復，但常規處理操作可以執行得更快。
另一個優化是對批處理任務進行分解，這樣即可在需要的時候調用不同階段和組件。藉此Flink可以與集群的其他用戶更好地共存。對任務提前進行分析使得Flink可以查看需要執行的所有操作、數據集的大小，以及下游需要執行的操作步驟，藉此實現進一步的優化。
優勢和局限
Flink目前是處理框架領域一個獨特的技術。雖然Spark也可以執行批處理和流處理，但Spark的流處理採取的微批架構使其無法適用於很多用例。Flink流處理為先的方法可提供低延遲，高吞吐率，近乎逐項處理的能力。
Flink的很多組件是自行管理的。雖然這種做法較為罕見，但出於性能方面的原因，該技術可自行管理內存，無需依賴原生的Java垃圾回收機制。與Spark不同，待處理數據的特徵發生變化後Flink無需手工優化和調整，並且該技術也可以自行處理數據分區和自動緩存等操作。
Flink會通過多種方式對工作進行分許進而優化任務。這種分析在部分程度上類似於SQL查詢規劃器對關系型資料庫所做的優化，可針對特定任務確定最高效的實現方法。該技術還支持多階段並行執行，同時可將受阻任務的數據集合在一起。對於迭代式任務，出於性能方面的考慮，Flink會嘗試在存儲數據的節點上執行相應的計算任務。此外還可進行「增量迭代」，或僅對數據中有改動的部分進行迭代。
在用戶工具方面，Flink提供了基於Web的調度視圖，藉此可輕松管理任務並查看系統狀態。用戶也可以查看已提交任務的優化方案，藉此了解任務最終是如何在集群中實現的。對於分析類任務，Flink提供了類似SQL的查詢，圖形化處理，以及機器學習庫，此外還支持內存計算。
Flink能很好地與其他組件配合使用。如果配合Hadoop 堆棧使用，該技術可以很好地融入整個環境，在任何時候都只佔用必要的資源。該技術可輕松地與YARN、HDFS和Kafka 集成。在兼容包的幫助下，Flink還可以運行為其他處理框架，例如Hadoop和Storm編寫的任務。
目前Flink最大的局限之一在於這依然是一個非常「年幼」的項目。現實環境中該項目的大規模部署尚不如其他處理框架那麼常見，對於Flink在縮放能力方面的局限目前也沒有較為深入的研究。隨著快速開發周期的推進和兼容包等功能的完善，當越來越多的組織開始嘗試時，可能會出現越來越多的Flink部署
總結
Flink提供了低延遲流處理，同時可支持傳統的批處理任務。Flink也許最適合有極高流處理需求，並有少量批處理任務的組織。該技術可兼容原生Storm和Hadoop程序，可在YARN管理的集群上運行，因此可以很方便地進行評估。快速進展的開發工作使其值得被大家關注。
結論
大數據系統可使用多種處理技術。
對於僅需要批處理的工作負載，如果對時間不敏感，比其他解決方案實現成本更低的Hadoop將會是一個好選擇。
對於僅需要流處理的工作負載，Storm可支持更廣泛的語言並實現極低延遲的處理，但默認配置可能產生重復結果並且無法保證順序。Samza與YARN和Kafka緊密集成可提供更大靈活性，更易用的多團隊使用，以及更簡單的復制和狀態管理。
對於混合型工作負載，Spark可提供高速批處理和微批處理模式的流處理。該技術的支持更完善，具備各種集成庫和工具，可實現靈活的集成。Flink提供了真正的流處理並具備批處理能力，通過深度優化可運行針對其他平台編寫的任務，提供低延遲的處理，但實際應用方面還為時過早。
最適合的解決方案主要取決於待處理數據的狀態，對處理所需時間的需求，以及希望得到的結果。具體是使用全功能解決方案或主要側重於某種項目的解決方案，這個問題需要慎重權衡。隨著逐漸成熟並被廣泛接受，在評估任何新出現的創新型解決方案時都需要考慮類似的問題。