Hadoop專業解決方案-第13章 Hadoop的發展趨勢

時間 2019-11-29

原文原文鏈接

1、前言：html

　　很是感謝Hadoop專業解決方案羣：313702010，兄弟們的大力支持，在此說一聲辛苦了，通過兩週的努力，已經有啦初步的成果，目前第13章 Hadoop的發展趨勢小組已經翻譯完成，在此對：hbase-深圳-1836一、旅人AQUARION表示感謝。git

2、意見徵集：程序員

　　本章節由《Hadoop專業解決方案羣：313702010》翻譯小組完成，爲小組校驗稿，已經經過小組內部校驗經過，特此面向網絡徵集意見，若是對本章節內容有任何異議，請在評論中加以說明，說明時，請標明行號，也能夠以修訂的方式，發送給我。很是感謝。github

3、原書說明正則表達式

　　英文原書《Wrox.Professional.Hadoop.Solutions》第十三章，請參照英文原文。算法

4、翻譯原稿sql

4.1 章節目錄
數據庫

頁碼-435express

這個章節將介紹的內容：apache

瞭解當前以及新興的MapReduce的DSLs

瞭解更高效，高擴展性的程序改進

回顧安全性方面的功能改進

瞭解最新的趨勢

Hadoop在迅速的發展變化，彷佛每一個星期業界新聞上都能看到新的發行版以及基於hadoop的開源項目的發佈，而且可以提供更增強勁的功能。若是您看到Apache的JIRA對於Hadoop的請求優化（部分在第10章中討論的內容），您將發現hadoop的明天將會擁有更多的功能。

在過去的幾年中，新的特定領域語言(DSLs)衆所周知簡化了hadoop的mapreduce編程，並且是hadoop中快速發展的領域，特別是在圖形處理方面。實時的hadoop（做爲第9章的討論內容）在今天呈現一個不斷增加的趨勢，而且在將來會不斷的發展。正如第10章和第12章的內容，安全性將不斷的發展和變化。雖然本書涉及到了不少將來將會改變和發展的內容，而您應該去了解更多本章沒有涉獵的領域。

本章開篇DSLs簡化mapreduce編程爲當前的發展趨勢，這種方法是經過在特定的問題領域引入更高級別的概念以及使用一個簡易的API縮短代碼的開發週期,您將瞭解到在hadoop2.0版本執行時間的新的實現（優化），從而爲mapreduce提供了更高的擴展性和可伸縮性。

頁碼-436

在本章中您還將瞭解到Tez-一個嶄新健壯的hadoop和Oozie框架，且支持通用性和實時性，本章還突出探討了即將實現的安全性更改。最後，您將瞭解到hadoop應用的新趨勢。

在本書中已經被證明，hadoop能夠用來解決不少不一樣的問題。本章重點集中在當下更多的組織選擇使用hadoop，以及在將來這些組織如何來使用它。讓咱們開始討論DSLs以及它們在hadoop編程中扮演的角色。

4.2 正文

DSL簡化mapreduce編程

到目前爲止，本書重點集中於mapreduce-容許在機器的集羣中拆分任務執行的hadoop編程模型，mapreduce賦予開發人員可以充分利用hadoop的權限，甚至是自定義執行（見第四章）從而更好的利用hadoop。Mapreduce是一個底層的模型，提供的權限對用開發者來講是一個新的挑戰。DSLs提供了一種簡化hadoop編程的方法，儘管本書能夠介紹每個hadoop的DSL，但本節僅快速」品味」他們其中的一些，展現在hadoop的這個發展的領域中如何下降了用戶的入門難度。本節重點介紹一些成熟的，已經被普遍應用的DSLs（例如HiveQL和PigLatin）以及一些新生和發展中的DSLs。

DSL是什麼？

DSL是一種編程語言，設計用來提供特定領域問題的解決方案。模仿其餘領域的術語和概念，例如：結構化查詢語言（SQL）能夠認爲是DSL的關係模型，DSLs嘗試解決實時系統中特定領域和底層實現中的差距。

一些精心設計的DSL讓一些非程序員可以編寫本身的程序，許多臨時的SQL使用者可以使用SQL查詢來獲取他們須要的信息，卻對關係型數據庫的底層結構知之甚少。另外一個關於普遍使用DSL的很好的例子是，Microsoft Excel的腳本語言，稱爲Visual Basic（VBA）。

雖然DSL是專門針對非程序員，可是對於開發人員依然是一種財富，由於DSL使開發人員成爲了特定語言領域的專家。在實踐中，DSLs與底層架構工做相比使程序員更加有效率。

DSL每每不必定完備，實際上意味着它們不能用於寫任意複雜的算法，或者是做爲通用的編程語言。相反，它們一般是聲明用戶的預期成果並實現這一結果。例如，在SQL中，能夠經過查詢來操做數據表中的數據。在大多數。

頁碼-437

關係型數據庫中，實時運行的系統將決定如何存儲數據和知足您的查詢

DSLs也被分類爲內部和外部：

外部DSL的應用與其它編程語言使用相同工具，設計獨特的語法以及用於解析程序語言的自定義編譯器

內部DSL（有時稱爲嵌入DSL）是「託管」在另外一個更通用的編程語言（或者DSL）上，這意味着它使用程式化的主機語言的語法，而不是具備其獨特的語法

早期的hadoop的開發者開發DSL很是迅速，您可能據說過它們中的一些：

Hive, Pig, Clojure-Hadoop, Grumpy (Groovy Hadoop), Sawzall, Scoobi, Lingual, Pattern, Crunch, Scrunch

並且這個隊伍還在不斷的壯大

Hadoop的DSLs

Hadoop的DSL通常能夠分爲幾個大類：

? 基於SQL的DSL—DSL基於SQL（開放性的基於SQL和「相似於SQL」）對於擁有後臺數據庫的非程序員最實用，運用這些DSLs，人們「認爲」在數據庫語言能夠完成數據分析任務而沒必要去想MapReduce

? 數據流DSL—這些DSL經過數據管道篩選和轉換，處理數據和聚合數據流

? 特殊問題的編程語言—這些DSL重點放在一個特定的問題域，有時使用不一樣的模型來處理數據。圖形處理就是其中的一個例子，模型數據圖（例如：社交網絡中的好友鏈接）和數據計算類型的圖。

Hive 和基於SQL的DSLs

您可能已經熟悉了Hive，它採用HiveQL,Hadoop中一種基於SQL的DSL，以SQL爲導向從而使非程序員易於使用，固然這只是其中一個例子。相似於基於HDFS數據的SQL類查詢工具，它容許用戶訪問您的表模式的數據，並在內部實現了使用MapReduce的查詢。Hive不是一個關係型數據庫管理系統（RDBMS），由於它沒有事務的概念或者記錄級的CRUD（建立，查找，更新和刪除），可是它切實提供了一種語言（叫作HiveQL），很容易被數據庫的用戶理解。它把重點放在查詢—請求數據和進行聚集操做。

儘管新接觸Hadoop的用戶傾向於使用Hive做爲一個關係型數據庫，可是須要重視的是MapReduce任務批量的使用HiveQL的命令，這使得Hive不適合知足快速查詢的需求（儘管正在進行中的工做可以使Hive更快的從Mapreduce中解耦，將在本章後面的內容中討論），Hive歷來沒有

頁碼-438

要取代一個企業級的數據倉庫，但做爲一種簡化和合做數據集合的方法，讓未必是JAVA開發人員的其餘人可以處理數據集並得到價值。

Facebook發明了Hive並將它在2008年開源貢獻給了Apache基金會，Facebook的數據分析師須要友好的生產工具去操做在Hadoop集羣中的數據，由於SQL是如此的廣泛，一個基於SQL的工具是一個合乎邏輯的選擇，Hive也許是推進Hadoop採用的最重要的工具，由於它爲剛接觸Hadoop的使用者下降了門檻。

Hive使用外部DSL（正如前面分類），HiveQL擁有本身的語法，編譯器和運行環境。大多數的Hive查詢被轉換成MapReduce任務，但數據定義語言（DDL），用於建立和修改數據庫，表和視圖不須要Mapreduce。Hive存儲這些元數據信息在一個單獨的數據庫（例如，Mysql），在讀取或處理HDFS上的數據或者其餘數據存儲的時候，大多數的查詢會觸發一個或者多個MapReduce任務，經過Hive的查件支持不一樣的數據格式。

讓咱們探討Hive做爲一個DSL的概念，並獲取到按照年，月，日分隔的HDFS的服務的數據做爲一個例子。具體發生了什麼的任何特殊細節不在這裏討論，只爲了說明一個強大的DSL的價值。表單13-1提供了服務器日誌數據的DDL實例表：

表單13-1：日誌表定義

表內容…….

表單13-1中所示由3個主要部分組成。該第一部分包含文件及它們的類型（相似於一個普通的數據庫表），第二部分是對Hive的特殊設計，特殊的數據分區。在表單13-1的數據分區說明：表將包括幾個部分，其中之一用於記錄天天的日誌，最後的第三部分每一個分區存儲做爲一個單獨的序列。

Hive組織分區數據到不一樣的目錄，若是倉庫目錄在HDFS中被配置爲一個倉庫的話，那麼這個分區表的外觀目錄結構就如同在表單13-2：

439

表單13-2：分區目錄

...

/warehouse/logs/year=2013/month=4/day=13

/warehouse/logs/year=2013/month=4/day=14

/warehouse/logs/year=2013/month=4/day=15

...

如上所示，全部的數據將在4月13日的目錄中，如今，考慮使用一個例子進行查詢（表單13-3），在4月13日中午到下午一點之間發生了什麼

表單13-3

SELECT hour, min, sec, msec, severity, message

FROM logs

WHERE year = 2013 AND month = 4 AND day = 13 AND

hour>= 12 AND hour <= 13

ORDER BY severity DESC, hour, min, sec, msec;

在表單13-3中的語法對於任何一個熟悉SQL的人來講是很是直觀的，而相反，經過MapReduce的JAVA的API來寫這個查詢是很是具備挑戰性的，由於實現ORDER BY的子句可能須要掌握專業編程語句。

在這個例子中，須要注意的是日誌的查詢區間永遠是波動的，以下所示，WHERE子句的邊界時間戳範圍敏感，由於數據已經按照年，月，日分隔，Hive知道只須要掃描子集目錄（在這個例子中爲4月13日）從而提供了相對快速的查詢結果，即便是一個涵蓋許多年達到TB級別的日誌數據集。

正如HiveQL這樣的一個好的DSL應該作到：

提供一個簡潔的，聲明性的方法來陳述信息結構和工做方式

對於特定領域專家（即數據分析師）直觀的語言，Hive隱藏了數據存儲和查詢的複雜性

很容易指定數據的組織方式（在這個實例下，經過時間戳分區）來提升查詢速度

相比手寫Java的MapReduce，HiveQL代碼更小的開銷

提供了擴展鉤子，可以插入不一樣的格式和功能

Hive可以使您經過不一樣的方式擴展它的功能：

容許您指定不一樣輸入和輸出格式

容許您使用自定義的序列化器和反序列化器（稱爲SerDe）進行格式化

440

容許您建立用戶自定義函數（udf），能夠用Java編寫並在HiveQL中聲明

容許在您的查詢中自定義mappers和reduces

讓咱們來看看如何擴展Hive的一些示例，若是您回顧13-1表單中的DDL語句，它指示Hive存儲中的數據序列，使用SequenceFile格式化輸入。對於靈活性和可擴展性,Hive容許開發人員輕鬆的插入本身的輸入格式，容許在各類不一樣的格式和業務中讀取數據，它還使您能夠插入本身查詢結果的輸出格式，這個鉤子已經被整合在Hive在Hbase的數據存儲，Cassandra和其餘數據存儲的應用中。

如前所述，Hive還能夠經過指定SerDe支持獨特的記錄格式（串行器/解碼器），知道如何將輸入記錄解析成列，並選擇性的以相同的格式輸出。注意，Hive簡化輸入和輸出的格式化，清楚記錄的存儲方式（或字節流），而SerDe瞭解每一個記錄是如何解析成列的。

一個流行的記錄格式的例子是JavaScript的對象表示法（JSON），列表13-4中，修改聲明JSON爲存儲數據的格式，其中每一個JSON記錄存儲一行。

表單13-4：使用JSON定義的記錄表

CREATE TABLE logs ( -- the

severity STRING,

...,

hour TINYINT,

...)

PARTITIONED BY (...)

STORED AS ROW FORMAT SERDE

'org.apache.hadoop.hive.contrib.serde2.JsonSerde'

WITH SERDEPROPERTIES (

"severity"="$.severity",

...,

"hour"="$.timestamp.hour",

...);

在此表中的例子，JsonSerde實現了Hive的SerDe API ，這是Hive的一個重要特徵，指導您使用Hive處理記錄。在這個示例中，Hive將調用JSON SerDe解析每一個JSON記錄成列，在表中聲明的SERDEPROPERTIES, SERDEPROPERTIES是Hive的一個功能，經過特殊的鍵--值對指定定義SerDe接口，在這種狀況下，使用$引用JSON的文檔，因此變量$.timestamp.hour

意味着「使用小時單位時間戳內的記錄」將被用於小時列。

最後，Hive支持UDF來擴展或者聚合記錄和操做列，經過UDFs，您能夠編寫JAVA函數由HiveQL聲明，對於Hive自己不支持

441

的功能是很是有用的。例如，Hive不提供窗口的功能，像大部分關係型數據庫管理系統那樣，將記錄聚合在一個提供的可移動的窗口中，一個典型的例子股票交易員使用收集若干天的股票收盤價的趨勢走向，很明顯的揭示當前的最新趨勢，這些經過自定義的UDF來提供。

Hive是Hadoop的DSL中很是好的一個例子，隱藏了MapReduce的複雜性併爲Hadoop的數據處理提供了一個可普遍理解的語言，多數的狀況下，它把JAVA手寫MapReduce代碼的開銷下降到最小，而且提供了擴展點可以自定義代碼解決大部分Hive還沒有涉及到的部分。這種在MapReduce中抽象的方法來源於數據庫工程師，使他們可以專一於本身的數據問題，而不是編程。

固然還有其餘基於SQL的DSL在使用，特別是Hadoop的實時查詢引擎，在第9章（Cloudera的Impala以及Apache的Drill）使用基於SQL的DSLs做爲編程語言。

數據流和相關的DSLs

輕量級的DSL使開發人員可以經過管道，轉換和聚合的方式處理大型數據集。例如，衆多的DSLs最廣爲人知的是Pig，一個與大多數的Hadoop發行版捆綁在一塊兒的工具，使用輕量級語言，抽象MapReduce框架，做用在MapReduce的底層。

Pig

Facebook發明了Hive，使分析人員熟練的使用Hadoop的數據進行工做，雅虎發明了Pig，更適合於轉換和聚合數據，它有一個叫作PigLatin的定製語言，不是基於SQL，意味着它更適合於開發人員，而不是經驗豐富的SQL用戶。

Hive主要介紹了數據的查詢，Pig主要介紹了提取，轉換和加載(ETL)處理。使用PigLatin，開發人員可以指定如何加載數據，在管道中建立數據的檢查點，而且它是高度可定製的，然而Pig和Hive的部分功能是重疊的，以至於您可使用兩種語言來查詢和ETL（注：Extraction-Transformation-Loading數據提取，轉換和加載）

爲了證實Pig和Hive之間功能的類似點，讓咱們嘗試一個實例查詢，一個蘋果公司的年度股票記錄，與去年同期相比的平均收盤價格，表單13-5展現了一個Hive查詢例子，這是一個簡單的SQL

表單13-5：使用Hive的有關蘋果公司的查詢

442

SELECT year(s. YYYY-MM-DD), avg(s.close)

FROM stocks s

WHERE s.symbol = 'AAPL'

GROUP BY year(s. YYYY-MM-DD);

與Hive不一樣的是，Pig沒有一個DDL（Data Definition Language數據庫定義語言），就像表單13-6中所示的Pig樣例展現，啓動時經過文件讀取數據。

表單13-6：使用Pig的有關蘋果公司的查詢

aapl = load '/path/to/AAPL.tsv' as (

YYYY-MM-DD: chararray,

...,

close: float,

...);

by_year = group aapl by SUBSTRING(YYYY-MM-DD, 0, 4);

year_avg = foreachby_year generate

group, AVG(aapl.close);

-- Dump to console:

dumpyear_avg;

在表單13-6中，您能夠看到熟悉的GROUP BY的SQL操做，對於每個a，b是一個映射，至關於使用SQL在a中選擇b。請注意，在分組aapl中，生成一個名爲by_year的新關係，Pig命令irstield組，從你的分組信息中取出包含年份鍵值的信息。Pig命名的第二個領域aapl（已經定義好的分組）保存分組記錄。所以，使用表達式foreach by_year生成組，AVG(aapl.close)的真正含義是，遍歷每一年的平均值經過by_year。

Pig被描述爲一個輕量級的語言，由於你定義的語句描述每一個步驟的數據處理，從原始模式來源到輸出。

表單13-7展現一個用Pig實現字數統計的程序

inpt = LOAD '/path/to/input' using TextLoader AS (line:chararray);

words = FOREACH inpt GENERATE flatten(TOKENIZE(line)) AS word;

grpd = GROUP words BY word;

cntd = FOREACH grpd GENERATE group, COUNT(words);

STORE cntd INTO '/path/to/output';

看起來像是執行「變量=值」的語句序列，實際上，每一行右邊的deines關係（這個詞的關係模型的定義）是左邊建立的別名（或者名字）

這個實現首先加載數據，在輸入模式中將每一行的文本做爲一條記錄，命名類型爲字符串類（一個字符串），而後遍歷每條記錄，對文本分詞，將每一個單詞造成單一記錄。將單詞分組，而後每一組統計所給單詞的出現信息，最後，將每一個單詞（擁有這個詞的字段如今被命名爲group）和每組（擁有這個組的分組信息關係內容的字段命名爲單詞）的大小進行分項

443

您的結果將輸出到一個路徑下。

Pig是一種自然數據流，但它也包括全部的傳統關係型業務，如同Hive所包含的（存在一些例外），包括GROUP BY,JOIN,PROJECTION,FILTERING(WHERE子句)，限制等等

像Hive同樣，Pig是一種擁有本身的語法和編譯器的外部DSL。它不是一個真正嚴謹的語言，所以，例如不支持通常的循環（除了信息的迭代），此外，像Hive和Pig支持插件的格式化和UDFs，可是Pig支持多種語言編寫UDF，包括Python，Ruby和JAVAScript,除了JAVA

Pig的好處在於比Hive更高的靈活性和逐步規範的數據流，數據庫的用戶喜歡用Hive，程序員喜歡用Pig，由於它看起來感受更像傳統的編程語言

如今讓咱們來談談比MapReduce相關的Hadoop的JAVA的API和更高層次基於JAVA虛擬機(JVM)的DSL。須要注意的是在JVM上而不是依託JAVA。由於，您會看到一些DSL在JVM上的使用，是基於JAVA之外的其餘語言。

Cascading和 Scalding

Cascading是在低級別的MapReduce API上最流行的JAVA的DSL，根據介紹，在2007年底的DSL實現大規模數據的函數編程中，Cascading是MapReduce是真正最完備的內部或嵌入式的DSL，在數據流中的明確的象徵性的排序管道，隱藏和許多底層的API的細節，使開發人員可以專一於手上的工做。

Cascading是基於「管道」來進行分割和合並數據流，對它們進行操做。在Cascading中，數據記錄稱爲元祖，管道被稱爲組件，穿越管道的記錄被稱爲元祖流，Cascading定義工做流管道元素，例如pipes（管道）, taps（開關）, and traps（陷阱）。

一個管道鏈接工做流（或管道）的主要內容，並定義哪些元祖穿越它完成工做，
管道由每一個類型（應用函數或過濾器）GroupBy（元祖字段流），CoGroup（加入一組常見的值），Every（適用於每個聚合器或滑動窗口）和組件（集成其餘的）。

一個開關（tap）表明一個資源，或者輕量級的數據源的鏈接，一個數據源開關一般是輸入開關（在哪裏讀數據）一個池開關一般是輸出開關（在哪裏寫數據）

一個陷阱（a trap）是一個池開關—這是寫入數據致使操做失敗的地方，使您可以繼續處理您的數據而不會由於數據的丟失出錯。

表單13-1展現Cascading管道的一個例子，即你們熟悉的字數統計

444

圖13-1中有兩個開關，輸入開關（接收文檔的集合）和輸出開關（產生字數）。管道也有兩個功能----一個標記和計數功能（聚合器），和數據流的分組組件。

表單13-8顯示了一個使用Cascading實現字數統計的方法

importorg.cascading.*;

// other imports...

public class WordCount {

public static void main(String[] args) {

// Set up app properties.

Properties properties = new Properties();

FlowConnector.setApplicationJarClass(properties, WordCount.class);

// Define the input and output "taps".

Scheme sourceScheme = new TextLine(new Fields("line"));

Scheme sinkScheme = new TextLine(new Fields("word", "count"));

String inputPath = args[0];

String outputPath = args[1];

Tap source = new Hfs(sourceScheme, inputPath);

Tap sink = new Hfs(sinkScheme, outputPath, SinkMode.REPLACE);

// Connect the pipes for the data flow.

Pipe assembly = new Pipe("wordcount");

// Regular expression to tokenize into words.

String regex = "(?<!\\pL)(?=\\pL)[^ ]*(?<=\\pL)(?!\\pL)";

Function function = new RegexGenerator(new Fields("word"), regex);

assembly = new Each(assembly, new Fields("line"), function);

assembly = new GroupBy( assembly, new Fields("word"));

Aggregator count = new Count(new Fields("count"));

assembly = new Every(assembly, count);

FlowConnectorflowConnector = new FlowConnector( properties );

Flow flow = flowConnector.connect( "word-count", source, sink, assembly);

flow.complete();

}

該代碼經過設置應用程序的屬性和源，控制開關，經過管道聚集數據建立數據流，須要注意SQL包含一些關鍵字操做例如GroupBy和Projection（映射）和函數計算，Cascading將這些封裝成了JAVA類。像Pig的腳本（表單13-7），您遍歷每一行，標記關鍵字（使用正則表達式）進行分組，計算每組大小，最後將結果輸出。

445

這個實例展現了Cascading關係操做的算法

這樣的框架模板比單純的展現MapReduce的字數統計如何工做的模板少不少

注意：這是一個更加複雜的數據流實例，參閱CMU Workshop on CoPA（Cascading + City of Palo Alto Open Data）在https://github.com/Cascading/CoPA/wiki，展現瞭如何使用Cascading和Hadoop清理未加工的和非結構化的數據，例如公園，街道開放數據和樹的數據信息。Workshop創建多個應用程序，利用這些數據提供一個示例應用。

雖然Cascading是一個JAVA API，可是APIs當前容許使用其餘的語言，列表包括Scala的Scalding, Clojure的Cascalog, Python的PyCascading以及其餘。它們當中還包括一些JAVA API中所沒有的功能性的加強。例如，Cascalog增長了基於數據日誌的邏輯查詢功能，而Scalding增長了有關遍歷問題以及許多機器算法的數學模型。

表單13-9展示了一個版本的使用遍歷的數字統計

表單13-9Scalding實現數字統計

importcom.twitter.scalding._

classWordCountJob(args: Args) extends Job(args) {

TextLine(args("input"))

.read

.flatMap('line -> 'word) {

line: String =>

line.trim.toLowerCase.split("\\W+")

}

.groupBy('word) { group =>group.size('count) }

}

.write(Tsv(args("output"))) // tab-delim. output

}

正如表單13-9中的說明裏的內容，Scalding是從Twitter中發展出來的。讓咱們注意一些重要的事情而不去關注Scala語法的細節。

首先，簡潔的代碼—明顯優於JAVA,有些例外的是，這段代碼看起來像典型的Scala代碼爲了更小以及內存數據集合設置的內置API。

其次，關係運算（如分組）是函數調用而不是類。.groupBy('word) { group =>group.size('count)這行意味着之間的輸出函數調用GroupBy函數。分組在這種狀況下，跨越域命名。此外一個匿名函數傳遞給GROUPBY須要每一個組做爲參數，並返回該組的大小，標記值做爲域的命名計數。這一步的數據輸出（加入製表分隔符的輸出）包含每一個詞和它的計數。

446

在表單13-9中flatMap作了些什麼？它表明了MapReduce的map階段。在數學領域，map實際上老是一一對應的，也就是說每一個輸出元素對應一個輸入元素。MapReduce放寬了這個約束，容許0對多的輸入/輸出對應關係。這正是flatMap的實際意義。這個匿名函數從原始的數據集合輸入元素對應0對多的關係到輸出元素。而後flatMap」flattens」嵌套的集合到一個」flat」集合。所以，您一直在使用Flat MapReduce。

Crunch和Scrunch

另外一個MapReduce的DSL被應用於MapReduce中的被稱爲Crunch，仿照谷歌的JAVA池的設計，使用小型的原始操做巨大的數據流。Crunch擁有三種數據抽象：PCollection<T>（用於並行數據類型爲T的數據集合），PTable<K,V>（分別鍵值對關係的並行表的拆分），PGroupedTable<K,V>（分組的操做輸出），在集羣中也存在並行結構實現業務處理。

表單13-10展現Crunch實現字數統計

// import statements...

public class WordCount {

public static void main(String[] args) throws Exception {

// Setup the pipeline and the input.

Pipeline pipeline = new MRPipeline(WordCount.class);

PCollection<String> lines =

pipeline.readTextFile(args[0]);

// Tokenize the lines into words in parallel.

PCollection<String> words = lines.parallelDo(

"my splitter", new DoFn<String, String>() {

public void process(

String line, Emitter<String> emitter) {

for (String word : line.split("\\s+")) {

emitter.emit(word);

}

}, Writables.strings());

// Count the words.

PTable<String, Long> counts = Aggregate.count(words);

pipeline.writeTextFile(counts, args[1]);

pipeline.run();

}

從表單13-10中能夠發現，Crunch是開發人員可以使用更多底層的Hadoop JAVA API（例如，使用Avro的類寫入數據，使用起來很是便捷，對於熟悉JAVA的程序員很是容易學習）

447

Crunch的Scala版本叫作Scrunch，表單13—11將展現使用Scrunch進行的數字統計

表單13-11 使用Scrunch進行數字統計

// imports...

classWordCountExample {

val pipeline = new Pipeline[WordCountExample]

defwordCount(fileName: String) = {

pipeline.read(from.textFile(fileName))

.flatMap(_.toLowerCase.split("\\W+"))

.filter(!_.isEmpty())

.count

}

表單13-11如同Scalding DSL同樣展現了優雅，簡潔的操做數據流，Cascading和Scalding這組例子在量級和複雜度上很是類似

如上所示，Crunch 和 Scrunch更加側重模式和Cascading中的靜態數據類型，當前靜態和動態數據類型彼此之間的優點並不明顯，差別取決於您的工具的選擇和喜愛。

圖形處理

最後討論的這個DSL雖然在今天應用不是很普遍，但您將在將來的一段時間內更多的接觸到使用圖形化算法的DSLs。這樣的使用需求是巨大的。

在線社交圖化正在迅速的發展，而且將有愈來愈多的需求去分析它們。在線社交網站，如：Facebook, LinkedIn, Google+和Twitter像Yahoo和Google這樣的電子郵件網站有着數以億計的用戶，在廣告和個性化中分析人以及他們的關聯角色扮演着很是重要的角色。Google是率先發現圖表分析的重要性，並將網頁排名（PageRank）算法應用於其搜索引擎中的公司其中之一。Larry Page 和Sergey Brin（谷歌的創始人）將該算法應用在搜素訂單結果的「連接熱度」將更多的網站連接到一個網頁上。雖然決定排名的相關性因素衆多，不過該算法是應用於Google的網絡搜索工具當中。

其餘一些問題依賴於連接，圖形和網絡分析，今天，Facebook在Hadoop的這個領域一路領先，在Hadoop的將來發展中圖形化的DSL將是一個飛速發展的領域。

到目前爲止，圖形化的處理系統對於Hadoop來講是新興領域，由於可擴展的計算機集羣圖形化處理出於研究領域的前沿，尚且存在着一些問題，好比接下來的調查主題中所展示的：

448

如何在集羣中繪製分區的密度圖

如何跨集羣拆分圖從而最小化連接主機的數量

如何跨機器鏈路完成信息的更新

目前不少積極的工做和愈來愈多的應用投入到Hadoop的圖形處理中來，本章只探討目前提到的方法以及在「DSL 空間」項目計劃中內容，更多您應該本身進一步調查。

像以往同樣，谷歌的論文做爲先驅，Apache緊隨其後。Pregel是Google用於數據分析的大型圖形分析系統（http://googleresearch.blogspot.com/2009/06/large-scale-graph-computing-at-google.html），Giraph（將在本章稍後介紹）是APACHE對應Hadoop的Pregel開源版。其被Facebook用來分析用戶的社會以及朋友團體中的圖形化關係。

圖形化處理系統，如Pregel和Giraph基於並行處理模型稱做Bulk Synchronous Parallel散裝同步並行 (BSP)，可以同步圖形處理節點之間的通訊。爲了演示BSP的工做方式，在t0時刻，全部節點在同一時刻向其餘鏈接着的節點發送信息。全部的節點在t1時刻，根據須要，更新它們的狀態，以此類推。障礙同步發生在每次的數據發送以後。

創建的併發通訊模型的基礎上，您可能認爲MapReduce將會缺乏高度迭代模型—您的假設是正確的。在MapReduce中本機執行的BSP依賴於單獨的MapReduce任務每一個迭代的BSP將帶來可怕的開銷。

然而，圖形處理系統開始應用於Hadoop的數據存儲以及MapReduce的BSP並行計算操做中，一系列圖形處理系統涌現，讓咱們關注兩個這個類型的Hadoop開源系統：

Giraph是Apache的一個項目，相似於Google的Pregel，實現HDFS上的BSP。在Giraph上，您提交一個MapReduce任務，但其在內部處理迭代步驟使用Vertex的環境，保存狀態圖在內存中並不聯動MapReduce任務。Giraph利用了Hadoop和MapReduce的數據存儲的基礎資源管理，但與在MapReduce中使用BSP不一樣的是，Giraph還引入了ZooKeeper進行容錯以及集中的調度服務

Hama也是Apache的一個項目，相似於Giraph，是一個BSP的計算框架，該框架應用於HDFS的頂層。然而，Hama繞過了MapReduce，獨立了本身的一套跨集羣的計算過程，Hama避免了Hadoop的MapReduce資源調度和工做模式的侷限性。與試圖引入該框架相比組織每每不肯引入一套新的集羣的處理方式與MapReduce爭奪資源，出於這個緣由，Hama的使用每每獨立於集羣專門作這類的分析。

449

在將來Hadoop的圖形化DSLs具備飛速發展的潛力。

這個有關Hadoop的DSLs的簡短的總結代表，除了基礎的MapReduce框架，一組豐富的dsl可使編寫Hadoop的任務更有成效，更加適合用戶的需求。新的Hadoop DSLs會按期的涌現，例如，Cascading剛剛推出了兩款新的DSL。

Lingual–一個新的SQL類型的DSL

Pattern–一個新的機器學習類型的DSL

如今，您知道DSL如何幫助您簡化MapReduce的用法，下一節將看到MapReduce自己的改進，使其可以更快，更高擴展性的進行程序處理

正如本書所討論的，MapReduce基本架構實現是很是龐大的，而實現這個的重要組成部分是JobTracker（在第三章中詳細介紹的），負責資源管理，做業調度以及監控。除此以外，實施者已經發現，JobTracker的實現過於複雜可能會致使一些問題，包括內存消耗，嚴格的線程模型以及擴展性，可靠性和性能問題。

這個分析結果致使，Hadoop將在MapReduce上作一次完全的變革，有時候稱爲「次世代的MapReduce」，「MapReduce2.0（MRv2）」或者本節中另外一種資源的表明（YARN），在提出了這種變革以後，一個稱爲」Tez」（印度語中的速度）的新項目被引入了Apache孵化器。並聲稱可以大大提升Hadoop的性能，您在本章中將詳細的瞭解它們。

須要重點注意的是，雖然在下一節中的相關描述中被稱爲MapReduce2，但不會改變MapReduce實際的編程模型，或者本書中描述的開發人員使用的這些APIs

Apache YARN

Hadoop的開發委員會決定，解決方案是在原有的MapReduce的基礎上分裂資源管理和做業調度到單獨的守護進程，一個全新的全局資源管理器叫作YARN將JobTracker的功能拆分爲兩個獨立的守護進程。

一個全局資源管理器（RM），由一個調度程序和一個應用管理程序組成

一個應用程序主節點（AM）提供應用程序支持，一個在傳統意義上的MapReduce任務中添加一個常規任務的應用，或者一個定向非週期任務（a Directed Acyclic Graph (DAG) of jobs）（與6~8章中的Oozie相比較）。拆分JobTracker提供了更高的靈活性和更好的功能。

450

YARN的資源管理是基於很是廣泛的資源應用模型，提供特定數量的資源（內存，CPU等等），正如Hadoop中的其餘部分同樣，YARN的資源管理和執行框架也是利用主從架構來實現的。子節點或者節點管理器（NMS），運行在每一個節點。他們管理一個特定節點上的容器，檢測節點的執行狀態，將資源的可用性報告給主節點，被稱之爲資源管理器。主節點負責協調系統中的全部應用程序資源（與第二章中的HDFS體系結構相似）

具體的應用程序的執行是由主應用程序控制，主應用程序是徹底分佈式的，每一個節點上都有主應用程序的實例。主應用程序負責拆分多個任務以及與應用資源管理器（容器）進行協調。當一個資源被分配時，主應用程序與節點管理器（們）相互做用去放置，執行，監控應用程序任務。

總體的應用流程如圖13-2所示：

分爲如下步驟

圖13-2:YARN的體系結構

451

客戶端程序提交申請，向特定的應用程序主節點引入必要的規範，做爲應用程序的一部分提交，必須提供充分的信息到資源管理器去啓用應用程序的第一個容器—主應用程序。依賴的信息（應用程序提交的）包括應用程序運行所需的本地文件或者jar包，實際必須執行的命令（必要的命令參數），任何UNIX環境變量（可選）等等.以此類推，由主應用程序描述UNIX 進程（們）是很是重要的。
資源管理器分配必要的容器給主應用程序，而後啓動主應用程序
啓動時，主應用程序註冊到資源管理器，容許客戶端去查詢資源管理器得到主應用程序的細節，包括它的地址。獲得這些細節後，客戶端能夠直接與本身的主應用程序通訊
一旦主應用程序啓動並運行，它會檢查應用程序的請求，並協調應用程序執行的資源空間
資源空間被分配後，主應用程序將資源信息發佈到節點管理器上
執行的過程當中，應用程序代碼提供必要的信息（進度，狀態等等）到主節點，這些信息對於與應用程序通訊的客戶端也是可獲取的
一旦應用程序完成後，主應用程序釋放資源，註銷，關閉並釋放本身的容器

對於YARN須要注意的是，它不會改變實際的MapReduce編程模型（YARN使用的MapReduce2的名字容易形成誤導）和開發人員使用的API，它只提供了一個新的資源管理模式和實現應用於執行MapReduce任務。所以在最簡單的狀況下，現有的MapReduce將正常工做僅須要從新編譯

YARN可用於建立新的框架和執行模型（除了MapReduce的），利用Hadoop集羣的併發計算能力和豐富的數據存儲模型，以解決具體的新問題。這種新的框架能夠利用YARN的資源管理，提供一個新的應用程序管理器。在撰寫本文的時候，這些項目或多或少的都是移植YARN實現的：

Spark（一個開源的集羣計算系統）

Apache Hama（本章前面描述過的圖形分析框架）

Apache Giraph（同上）

Open MPI（一個高性能計算的開源項目）

452

Storm（一個第九章描述的開源，分佈式實時計算系統）

Apache S4（一個相似Storm的Apache項目，提供實時的事件處理）

YARN結構容許多個應用程序管理器共享相同的Hadoop集羣以及集羣上的數據，這樣簡化了駐留在Hadoop集羣上的多個框架之間的數據級別。

使用YARN執行MapReduce應用提升了可擴展性，可是MapReduce的編程模型並無充分利用YARN的能力，特別是內置的DAG的支持。MapReduce的使用一般伴隨Oozie編排的個體MapReduce任務。雖然這種方法很好的應用於批量的運行程序，可是給傳遞數據到HDFS以及應用程序的啓動時間方面帶來很大的開銷。

其中的一些不足之處在一個叫作Tez的新的Hadoop框架中被去除

Tez

Tez提供了一個通用的，高可用的框架，支持編排定製任務到DAG中，Tez不只是爲了個別的MapReduce任務，而是總體任務，從而得到比Oozie更快的性能。Tez的高性能是依靠消除多個任務帶來的開銷從而知足人機交互的響應時間需求以及PB級別的高吞吐量（第9章中的實時處理）。

最初由Stringer建立並支持，目標是Apache 的Hive的100倍的性能。Tez提供了一個單一的框架支持延時和吞吐量敏感的應用。所以，它消除了多個框架和系統的安裝，維護，支持的必要性，從而爲企業節省了大量的成本。

Tez是2013年出由Hortonworks貢獻給Apache並進入孵化階段的。它是一個有不少程序員參與的很是活躍的項目，在Hadoop的實時應用方面有着很是光明的前景。

安全性強化

如第10章介紹的，Hadoop社區正在致力於安全性方面的加強。增長了新的加密編解碼器，新的基於令牌的認證協議，支持屬性的統一認證系統，基於角色的訪問控制（ABAC），執行策略支持開放標準和XACML,改變hbase容許受權。Hadoop能夠從集羣環境和周邊級別環境中分離，從而知足高度安全的環境要求。

453

注意：想要了解更詳盡的信息，請參考第10章中的「安全性加強計劃Rhino」

新的趨勢

這本書已經涉及到了許多Hadoop的相關趨勢，雖然做者沒有水晶球，但他們認爲如下將成爲關鍵領域將在將來飛速發展。

實時的Hadoop—這種趨勢今天正在發生，並將持續下去，將Hadoop看作是一個批量處理模式的系統，Hadoop在將來（特別是近期出現的性能和伸縮性的改進）伴隨着人爲響應時間進行實時分析。您可能會習慣於很長時間才能完成的任務迅速的執行完成，這將在幾個不一樣的方面—欺詐檢測，事務分析，安全漏洞分析和實時事件的異常檢測以及和Hadoop生態系統中的其餘工具的根據需求的分析處理。

圖表分析和超越MapReduce的新算法—若是您伴隨着Hadoop發展的歷史，您將發現Google的影響力，Google的新的可伸縮分佈式圖形化分析算法引起了比MapReduce更大的興趣。由於Apache 的Giraph（本章前面討論過）是Google的高性能圖形化分析平臺（Pregel）的開源實現，而且Facebook應用Griaph的圖形分析於其社交網絡上，毫無疑問這將是Hadoop中飛速發展的領域。Apache的Hama（也在本章前面討論過）利用HDFS存儲以及其餘的圖形化算法在Hadoop上，這種趨勢將會繼續。

機器學習—雖然本書中沒有過多的介紹，這是一個發展中的話題。伴隨着Apache Mahout 和 Pattern這樣的項目，機器學習的Cascading的DSL，預測建模和機器學習將愈來愈多的用於Hadoop的常見用例，相似推薦，欺詐檢測和安全漏洞檢測。

更高層次的抽象以及本章以前介紹的DSLs，您已經瞭解到Hadoop的DSL的強大，以及它們是如何的簡化編程。使用這種語言或者工具將大大的減小Hadoop和MapReduce的使用的學習難度，而這一趨勢將會繼續增加。雖然使用一些工具確定會有性能上的損失，但更多的科學家和領域專家在專門的領域中使用Hadoop的工具集消除了屏障，使處理的速度變得更快。甚至有些數據專家不知道本身正在使用Hadoop！

Hadoop正在不斷的快速發展，擁有一個光明的將來，正如持續改進的領域所展現的，新的項目在擴散，性能的改進，安全性和DSLs的發展和增加，新的方向迅速的開展對於每個Hadoop的開發者來講是多麼的激動人心！

454

總結

本章強調了利用DSL簡化MapReduce的增加趨勢，您瞭解到了YARN和Tez對於Hadoop擴展性能的提高，以及安全性方面的改進提高以及Hadoop將來發展的新興趨勢。