十八款Hadoop工具幫你馴服大資料

Hadoop已經通過自身的蓬勃發展證明，它不僅僅是一套用於將工作內容傳播到電腦群組當中的小型堆疊--不，這與它的潛能相比簡直微不足道。 這套核心的價值已經被廣泛證實，目前大量專案如雨後春筍般圍繞它建立起來。 有些專案負責資料管理、有些負責流程監控、還有一些則提供先進的資料存儲機制。

Hadoop業界正在迅速發展，從業企業拿出的解決方案也多種多樣，其中包括提供技術支援、在託管集群中提供按時租用服務、為這套開源核心開發先進的功能強化或者將自有工具添加到方案組合當中。

在今天的文章中，我們將一同瞭解當下Hadoop生態系統當中那些最為突出的傑作。 總體而言，這是一套由眾多工具及代碼構成的堅實基礎、共同聚集在"Hadoop"這面象徵著希望的大旗之下。

Hadoop

雖然很多人會把映射與規約工具廣義化稱為Hadoop，但從客觀角度講、其實只有一小部分核心代碼算是真正的Hadoop。 多個工作節點負責對保存在本地的資料進行功能執行，而基於JAVA的代碼則對其加以同步。 這些工作節點得到的結果隨後經過匯總並整理為報告。 第一個步驟被稱為"映射（即map）"，而第二步驟則被稱為"規約（reduce）"。

Hadoop為本地資料存儲與同步系統提供一套簡化抽象機器制，從而保證程式師能夠將注意力集中在編寫代碼以實現資料分析工作上，其它工作交給Hadoop處理即可。 Hadoop會將任務加以拆分並設計執行規程。 錯誤或者故障在意料之中，Hadoop的設計初衷就在於適應由單獨設備所引發的錯誤。

專案代碼遵循Apache許可機制。

官方網站：hadoop.apache.org

Ambari

Hadoop集群的建立需要涉及大量重複性工作。 Ambari提供一套基於Web的圖形化使用者介面並配備引導腳本，能夠利用大部分標準化元件實現集群設置。 在大家採納Ambari並將其付諸運行之後，它將説明各位完成配置、管理以及監管等重要的Hadoop集群相關任務。 上圖顯示的就是集群啟動後Ambari所顯示的資訊螢幕。

Ambari屬於Apache旗下的衍生專案，並由Hortonworks公司負責提供支援。

下載位址：HTTP://incubator.apache.org/ambari/

HDFS (即Hadoop分散式檔案系統)

Hadoop分散式檔案系統提供一套基礎框架，專門用於拆分收集自不同節點之間的資料，並利用複製手段在節點故障時實現資料恢復。 大型檔會被拆分成資料塊，而多個節點能夠保留來自同一個檔的所有資料塊。 上圖來自Apache公佈的說明文檔，旨在展示資料塊如何分佈至各個節點當中。

這套檔案系統的設計目的在於同時實現高容錯性與高資料吞吐能力的結合。 載入資料塊能夠保持穩定的資訊流通，而低頻率緩存處理則將延遲降至最小。 預設模式假設的是需要處理大量本機存放區資料的長時間作業，這也吻合該專案所提出的"計算能力遷移比資料移轉成本更低"的座右銘。

HDFS同樣遵循Apache許可。

官方網站：hadoop.apache.org

HBase

當資料被匯總成一套規模龐大的清單時，HBase將負責對其進行保存、搜索並自動在不同節點之間共用該清單，從而保證MapReduce作業能夠以本地方式運行。 即使清單中容納的資料行數量高達數十億，該作業的本地版本仍然能夠對其進行查詢。

該代碼並不能提供其它全功能資料庫所遵循的ACID保證，但它仍然為我們帶來一部分關於本地變更的承諾。 所有衍生版本的命運也都維繫在一起--要麼共同成功、要麼一起失敗。

這套系統通常被與谷歌的BigTable相提並論，上圖所示為來自HareDB（一套專為HBase打造的圖形化使用者介面用戶端）的截圖。

官方網站：hbase.apache.org

Hive

將資料導入集群還只是大資料分析的第一步。 接下來我們需要提取HBase中來自檔的所有資料內容，而Hive的設計初衷在於規範這一提取流程。 它提供一套SQL類語言，用於深入發掘檔內容並提取出代碼所需要的資料片段。 這樣一來，所有結果資料就將具備標準化格式，而Hive則將其轉化為可直接用於查詢的存儲內容。

上圖所示為Hive代碼，這部分代碼的作用在於創建一套清單、向其中添加資料並選擇資訊。

Hive由Apache專案負責發行。

官方網站：hive.apache.org

Sqoop

要將蘊藏在SQL資料庫中的資料寶庫發掘出來並交給Hadoop打理需要進行一系列調整與操作。 Sqoop負責將飽含資訊的大型清單從傳統資料庫中移動到Hive或者HBase等工具的控制之下。

Sqoop是一款命令列工具，能夠控制清單與資料存儲層之間的映射關係，並將清單轉化為可為HDFS、HBase或者Hive所接納的可配置組合。 上圖所示為Apache文檔材料中的內容，可以看到Sqoop位於傳統庫與節點上的Hadoop結構之間。

Sqoop的最新穩定版本為1.4.4，但目前其2.0版本同樣進展順利。 兩個版本目前都可供下載，且遵循Apache許可。

官方網站：sqoop.apache.org

Pig

一旦資料以Hadoop能夠識別的方式被保存在節點當中，有趣的分析工作將由此展開。 Apache的Pig會用自己的小"豬拱"梳理資料，運行利用自有語言（名為Pig Latin）所編寫的代碼，並添加處理資料所需要的各種抽象機器制。 這樣的結構會一步步指引使用者走向那些易於以並行方式運行在整個集群當中的演算法。

Pig還擁有一系列針對常見任務的標準化功能，能夠輕鬆處理諸如資料平均值計算、日期處理或者字串差異比較等工作。 如果這些還不夠用--實際上一般都不夠用--大家還可以動手編寫屬於自己的功能。 上圖所示為Apache說明文檔中的一項實例，解釋了使用者如何將自己的代碼與Pig代碼結合起來、從而實現資料發掘。

目前Pig的最新版本為0.12.0。

官方網站：pig.apache.org

ZooKeeper

一旦Hadoop需要在大量設備之上，集群運作的順序就顯得非常重要，特別是在其中某些設備開始簽出的情況下。

ZooKeeper在集群中強制執行一套檔案系統式的層級結構，並為設備保存所有中繼資料，這樣我們就可以在不同設備之間進行作業同步。 （上圖所示為一套簡單的二層式集群。 ）說明文檔展示了如何在資料處理流程中實施多種標準化技術，例如生產方-消費方佇列，從而保證資料能夠以正確的順序進行拆分、清理、篩選以及分類。 當上述過程結束後，使用ZooKeeper的節點會彼此通信、並以最終生成的資料為起點開始分析工作。

如果大家希望瞭解更多資訊、說明文檔以及最新版本，請訪問ZooKeeper的官方網站。

官方網站：zookeeper.apache.org

NoSQL

並不是所有Hadoop集群都會使用HBase或者HDFS。 某些集成了NoSQL的資料存儲體系會採取自己的獨特機制實現跨集群各節點的資料存儲任務。 在這種情況下，此類體系能夠利用NoSQL資料庫的全部功能對資料進行存儲與檢索，而後利用Hadoop規劃同一集群當中的資料分析作業。

此類方案中最為常見的當數Cassandra、Riak或者MongoDB，而使用者則在積極探索將這兩種技術加以結合的最佳方式。 作為MongoDB的主要支援廠商之一，10Gen公司建議使用者利用Hadoop進行離線分析，而MongoDB同時仍然能夠以即時方式統計來自Web的資料。 上圖所示為連接器如何實現兩套體系之間的資料移轉。

Mahout

目前能夠説明我們進行資料分析、分類以及篩選的演算法多種多樣，而Mahout專案的設計目的正是為了將這些演算法引入Hadoop集群當中。 大多數標準化演算法，例如K-Means、Dirichelet、並行模式以及貝葉斯分類等，都能夠讓我們的資料同Hadoop類型的映射與規約機制進行協作。

上圖所示為一套篷聚類集群化演算法，它選擇點與半徑來構成圓圈、從而覆蓋整個點集合中的對應部分。 這只是眾多Hadoop內置資料分析工具之一。

Mahout從屬於Apache專案並遵循Apache許可。

官方網站：mahout.apache.org

Lucene/Solr

這是目前惟一的一款用於檢索非結構化文本大型塊的工具，它同時也是Hadoop的天生合作夥伴。 由於利用JAVA編寫，Lucene能夠輕鬆與Hadoop展開協作，共同創建出一套用於分散式文本管理的大型工具。 Lucene負責處理檢查任務、Hadoop則負責將查詢分佈到整個集群當中。

新的Lucene-Hadoop功能正迅速發展成為全新專案。 以Katta為例，作為Lucene的衍生版本，它能自動對整個集群進行解析。 Solr則提供集成度更高的動態集群化解決方案，能夠解析XML等標準化檔案格式。 上圖所示為Luke，一款用於Lucene流覽的圖形化使用者介面。 它現在還提供外掛程式、用於對Hadoop集群進行流覽檢索。

Lucene及其多個衍生版本都屬於Apache專案的組成部分。

官方網站：www.apache.org

Avro

當Hadoop作業需要進行資料共用時，我們完全可以使用任何一種資料庫加以實現。 但Avro是一套序列化系統，能夠利用一定模式將資料整理起來並加以理解。 每一個資料包都附帶一種JSON資料結構，用於解釋資料的具體解析方式。 這種資料頭會指定資料結構，從而避免我們在資料中編寫額外的標籤來對欄位進行標記。 如此一來，當共用資料較為規律時，其體積將比傳統格式（例如XML或者JSON）更為緊湊。

上圖所示為針對某個檔的Avro處理模式，其中分為三種不同欄位：姓名、最喜歡的數位與最喜歡的顏色。

Avro同樣屬於Apache專案的組成部分，其代碼擁有JAVA、C++以及Python等多個語言版本。

官方網站：avro.apache.org

Oozie

將一項作業拆分成多個步驟能夠讓工作變得更為簡單。 如果大家將自己的專案拆分成數個Hadoop作業，那麼Oozie能夠以正確的順序將其組合起來並加以執行。 大家不需要插手堆疊調整，等待一個堆疊執行結束後再啟動另一個。 Oozie能夠按照DAG（即有向無環圖）的規範對工作流加以管理。 （環圖相當於無限迴圈，對於電腦來說就像一種陷阱。 ）只需將DAG交給Oozie，我們就可以放心出去吃飯了。

上圖所示為來自Oozie說明文檔的一幅流程圖。 Oozie代碼受到Apache許可的保護。

官方網站：oozie.apache.org

GIS工具

咱們生活的世界相當廣闊，因此讓運行Hadoop的集群與地理地圖協作也是項難度很高的任務。 針對Hadoop專案的GIS（即地理資訊系統）工具採用多種基於JAVA的最佳工具，能夠透徹理解地理資訊並使其與Hadoop共同運行。 我們的資料庫將通過座標而非字串來處理地理查詢，我們的代碼則通過部署GIS工具來計算三維空間。 有了GIS工具的説明，大家面臨的最大難題只剩下正確解讀"map"這個詞--它到底代表的是象徵整個世界的平面圖形，還是Hadoop作業當中的第一步、也就是"映射"？

上圖所示為說明文檔中關於這些工具的不同層級。 目前這些工具可在GitHub上進行下載。

下載位址：HTTP://esri.github.io/gis-tools-for-hadoop/

Flume

資料收集這項任務絕對不比資料存儲或者資料分析更輕鬆。 作為又一個Apache專案，Flume能夠通過分派"代理"以收集資訊並將結果保存在HDFS當中。 每一個代理可以收集日誌檔、調用Twitter API或者提取網站資料。 這些代理由事件觸發，而且可以被連結在一起。 由此獲得的資料隨後即可供分析使用。

Flume專案的代碼受Apache許可保護。

官方網站：flume.apache.org

Hadoop上的SQL

如果大家希望在自己的大型集群當中對全部資料來一次快速的臨時性查詢，正常來說需要編寫一個新的Hadoop作業，這自然要花上一些時間。 過去程式師們多次掉進過這同一個坑裡，於是大家開始懷念老式SQL資料庫--利用相對簡單的SQL語言，我們就能為問題找到答案。 從這一思路出發，眾多公司開發出一系列新興工具，這些方案全部指向更為快捷的應答途徑。

其中最引人注目的方案包括：HAWQ、Impalla、Drill、Stinger以及Tajo。 此類方案數量眾多，足夠另開一個全新專題。

雲計算

很多雲平臺都在努力吸引Hadoop作業，這是因為其按分鐘計算租金的靈活業務模式非常適合Hadoop的實際需求。 企業可以在短時間內動用數千台設備進行大資料處理，而不必再像過去那樣永久性購入機架、再花上幾天或者幾周時間執行同樣的計算任務。 某些企業，例如Amazon，正在通過將JAR檔引入軟體規程添加新的抽象層。 一切其它設置與調度工作都可由雲平臺自行完成。

上圖所示為Martin Abegglen在Flickr上發表的幾台刀片電腦。

Spark

未來已然到來。 對於某些演算法，Hadoop的處理速度可能慢得令人抓狂--這是因為它通常依賴于存儲在磁片上的資料。 對於日誌檔這種只需讀取一次的處理任務來說，速度慢些似乎還可以忍受；但一旦把範圍擴大到所有負載，那些需要一次又一次訪問資料的人工智慧類程式可能因為速度過慢而根本不具備實用價值。

Spark代表著下一代解決思路。 它與Hadoop的工作原理相似，但面向的卻是保存在記憶體緩存中的資料。 上圖來自Apache說明文檔，其中演示的是Spark在理想狀態下與Hadoop之間的處理速度對比。

Spark專案正處於Apache開發當中。

官方網站：spark.incubator.apache.org