高可用Hadoop平臺－探索

1.概述

　　上篇《高可用Hadoop平臺－啓航》博客已經讓咱們初步瞭解了Hadoop平臺；接下來，咱們對Hadoop作進一步的探索，一步一步的揭開Hadoop的神祕面紗。下面，咱們開始贅述今天的探索之路。

2.探索

　　在探索以前，咱們來看一下Hadoop解決了什麼問題，Hadoop就是解決了大數據（大到單臺服務器沒法進行存儲，單臺服務器沒法在限定的時間內進行處理）的可靠存儲和處理。

• HDFS：在由普通或廉價的服務器（或PC）組成的集羣上提供高可用的文件存儲，經過將塊保存多個副本的辦法解決服務器或硬盤壞掉的問題。
• MapReduce：經過簡單的Mapper和Reducer的抽象提供一個編程模型，能夠在一個由幾十臺或上百臺的服務器組成的集羣上進行併發，分佈式的處理大量的數據集；而併發，分佈式（如：機器間通訊）和故障恢復等計算細節隱藏起來。而Mapper和Reducer的抽象，又是各類各樣的複雜數據處理均可以分解爲基本元素。這樣，複雜的數據處理能夠分解爲由多個Job（包含一個Mapper和一個Reducer）組成的有向無環圖（DAG），而後每一個Mapper和Reducer放到Hadoop集羣上執行，就能夠得出以下圖所示的結果：

　　在Hadoop的源碼中，提供了一個很經典的例子：WordCount，具體源碼能夠參見上篇文章，若是對MapReduce不熟悉，經過該示例對MapReduce進行一些瞭解對理解下文會由幫助。在MapReduce中，Shuffle是一個很是重要的過程，正是有了看不見的Shuffle過程，纔可使在MapReduce之上寫數據處理的開發者徹底感受不到分佈式和併發的存在。

　　注：廣義的Shuffle是指圖中在Map和Reduce之間的一系列過程。

2.1Hadoop的侷限和不足

　　MapReduce存在如下侷限，使用起來比較困難。

• 抽象層次低，須要手工編寫代碼來完成，使用上難以上手，入門門檻較高。
• 只提供兩個操做，Map和Reduce，表達的力度不夠。
• 一個Job只有Map和Reduce兩個階段，複雜的計算須要大量的Job來完成。Job之間的依賴關係是由開發者本身來管理的。
• 　　處理邏輯隱藏在代碼細節中，沒有總體邏輯。
• 中間結果也放在HDFS文件系統中。
• ReduceTask須要等待全部的MapTask都完成後才能夠開始。
• 時延高，只適用Batch數據處理，對於交互式數據處理，實時數據處理的支持不夠。
• 對於迭代式數據處理性能比較差。

　　舉個例子，用MapReduce實現表與表之間的join，都是一個很須要技巧來處理的過程，以下圖：

　　所以，在Hadoop以後，出現來不少相關技術對其中的侷限進行改進，如：Hive，Oozie，Tez，Spark，Storm等等。

3.Hive

　　Hive是Facebook的產品，目前已託管到Apache基金。關於Hive的安裝搭建和使用請參考《那些年使用Hive踩過的坑》和《Hive的安裝部署》，這裏就很少贅述了。Hive是一種底層封裝了Hadoop的數據倉庫處理工具，使用類SQL的HiveSQL語言實現數據查詢，全部Hive的數據都存儲在HDFS中。Hive在加載數據過程當中不會對數據進行任何的修改，只是將數據移動到HDFS中Hive的指定目錄下，所以，Hive不支持對數據的改寫和添加，全部的數據都是在加載的時候肯定的。

　　Hive解決類MapReduce存在的大量手寫代碼，語義隱藏，提供操做種類少的問題。相似的項目還有Pig，JAQL等。

4.Tez

　　Tez是HortonWorks的Stinger Initiative的的一部分。做爲執行引擎，Tez也提供了有向無環圖（DAG），DAG由頂點（Vertex）和邊（Edge）組成，Edge是對數據的移動的抽象，提供了One-To-One，BroadCast，和Scatter-Gather三種類型，只有Scatter-Gather才須要進行Shuffle。

　　示例：

SELECT a.state, COUNT(*), AVERAGE(c.price) FROM a JOIN b ON (a.id = b.id) JOIN c ON (a.itemId = c.itemId) GROUP BY a.state

　　Tez的優化主要體如今：

1. 去除了連續兩個任務之間的寫屏障
2. 去除了每一個工做流中多餘的Map階段

　　經過提供DAG語義和操做，提供了總體的邏輯，經過減小沒必要要的操做，Tez提高了數據處理的執行性能。

5.Spark

 

　　Spark也是一個大數據處理的引擎，主要特色是提供了一個集羣的分佈式內存抽象，以支持須要工做集的應用。

 

　　這個抽象就是RDD（Resilient Distributed Dataset），RDD就是一個不可變的帶分區的記錄集合，RDD也是Spark中的編程模型。Spark提供了RDD上的兩類操做，轉換和動做。轉換是用來定義一個新的RDD，包括map, flatMap, filter, union, sample, join, groupByKey, cogroup, ReduceByKey, cros, sortByKey, mapValues等，動做是返回一個結果，包括collect, reduce, count, save, lookupKey。

 

　　Spark支持故障恢復的方式也不一樣，提供兩種方式，Linage，經過數據的血緣關係，再執行一遍前面的處理，Checkpoint，將數據集存儲到持久存儲中。

 

　　Spark的API很是簡單易用，使用Spark，WordCount的示例以下所示：

val spark = new SparkContext(master, appName, [sparkHome], [jars])
val file = spark.textFile("hdfs://nna:9000/hdfs/in/a.txt")
val counts = file.flatMap(line => line.split(" "))
                 .map(word => (word, 1))
                 .reduceByKey(_ + _)
counts.saveAsTextFile("hdfs://nna:9000/hdfs/out")

　　其中的file是根據HDFS上的文件建立的RDD，後面的flatMap，map，reduceByKe都建立出一個新的RDD，一個簡短的程序就可以執行不少個轉換和動做。在Spark中，全部RDD的轉換都是是惰性求值的。Spark的任務是由相互依賴的多個RDD組成的有向無環圖（DAG），每一個RDD又包含多個分區，當在RDD上執行動做時，Spark纔對任務進行調度。

　　Spark對於有向無環圖對任務進行調度，肯定階段，分區，流水線，任務和緩存，進行優化，並在Spark集羣上運行任務。RDD之間的依賴分爲寬依賴（依賴多個分區）和窄依賴（只依賴一個分區），在肯定階段時，須要根據寬依賴劃分階段。根據分區劃分任務。

　　Spark爲迭代式數據處理提供更好的支持。每次迭代的數據能夠保存在內存中，而不是寫入文件。

　　Spark的性能相比Hadoop有很大提高，2014年10月，Spark完成了一個Daytona Gray類別的Sort Benchmark測試，排序徹底是在磁盤上進行的，與Hadoop以前的測試的對比結果如表格所示：

　　原圖連接地址：http://databricks.com/blog/2014/11/05/spark-officially-sets-a-new-record-in-large-scale-sorting.html

　　從表格中能夠看出排序100TB的數據（1萬億條數據），Spark只用了Hadoop所用1/10的計算資源，耗時只有Hadoop的1/3。

　　Spark的優點不只體如今性能提高上的，Spark框架爲批處理（Spark Core），交互式（Spark SQL），流式（Spark Streaming），機器學習（MLlib），圖計算（GraphX）提供一個統一的平臺，這相對於使用Hadoop有很大優點。

6.總結

　　那麼Spark解決了Hadoop的哪些問題？

• 抽象層次低，須要手工編寫代碼來完成，使用上難以上手。
  • =>基於RDD的抽象，實數據處理邏輯的代碼很是簡短。
• 只提供兩個操做，Map和Reduce，表達力欠缺。
  • =>提供不少轉換和動做，不少基本操做如Join，GroupBy已經在RDD轉換和動做中實現。
• 一個Job只有Map和Reduce兩個階段，複雜的計算須要大量的Job完成，Job之間的依賴關係是由開發者本身管理的。
  • =>一個Job能夠包含RDD的多個轉換操做，在調度時能夠生成多個階段，並且若是多個map操做的RDD的分區不變，是能夠放在同一個Task中進行。
• 處理邏輯隱藏在代碼細節中，沒有總體邏輯。
  • =>在Scala中，經過匿名函數和高階函數，RDD的轉換支持流式API，能夠提供處理邏輯的總體視圖。
• 代碼不包含具體操做的實現細節，邏輯更清晰。 中間結果也放在HDFS文件系統中。
  • =>中間結果放在內存中，內存放不下了會寫入本地磁盤，而不是HDFS。
• ReduceTask須要等待全部MapTask都完成後才能夠開始
  • =>它容許用戶單獨爲Map Task和Reduce Task設置不一樣的資源，進而細粒度控制任務佔用資源量，有利於大做業的正常平穩運行。
• 時延高，只適用Batch數據處理，對於交互式數據處理，實時數據處理的支持不夠。
  • =>經過將流拆成小的batch提供Discretized Stream處理流數據。
• 對於迭代式數據處理性能比較差。
  • =>經過在內存中緩存數據，提升迭代式計算的性能。

　　這篇文章就分享到這裏，若在研究的過程當中有什麼疑問，能夠加羣討論或發送郵件給我，我會盡我所能爲您解答，與君共勉！