日誌資料在應用程式中一直很常見，Hadoop能夠處理生產系統生成的大量日誌資料，比如網路裝置、作業系統、Web伺服器和應用程式的日誌資料。這些日誌檔案提供了對系統和應用程式執行以及使用的見解，統一日誌檔案的原因是它們往往採用文字形式和麵向行的方式，因此易於處理。

在《Hadoop從入門到精通》大型專題的上一章節中，我們介紹了可用於將資料複製到Hadoop的低階方法。本節不使用這些方法構建資料移動工具，而是介紹一些更高階別的工具，簡化將日誌和二進位制資料移動到Hadoop的過程。類似Flume，Sqoop和Oozie這樣的工具提供了定期(或連續)將資料從各種資料來源(如檔案，關聯式資料庫和訊息傳遞系統)移動到Hadoop的機制，並逐漸解決了整個過程中的諸多難題，讓我們看看Flume如何將日誌檔案移入HDFS。

（注：本文為《Hadoop從入門到精通》大型專題的第五章內容，其他文章見文末連結，專題的上半部也將於不久之後與大家見面，請持續關注本專題！）

首選資料移動方法

如果在舊版Hadoop環境中執行，我們可能需要一些工具來移動資料，這些工具都會在本章介紹。如果使用Kafka作為資料傳輸機制，則允許將生產者與消費者分離，同時使多個消費者能夠以不同的方式對資料進行操作。在這種情況下，我們可以使用Kafka在Hadoop上儲存資料，併為實時資料流系統(如Storm或Spark Streaming)提供資料，然後使用它執行近實時計算。比如，Lambda架構允許以小增量實時計算聚合資料，並使用批處理層執行糾錯和新增新資料點等，從而發揮實時和批處理系統的優勢。

實踐：使用Flume將系統日誌訊息推送到HDFS

面對跨多個伺服器的多個應用程式和系統生成的一堆日誌檔案，我們可能手忙腳亂。毫無疑問，從這些日誌中可以挖掘出有價值的資訊，但第一大挑戰是將這些日誌移動到Hadoop叢集以便可以執行某些分析。

版本注意事項

此處的Flume使用版本1.4。與所有軟體一樣，不保證此處介紹的技術，程式碼和配置可以使用不同版本的Flume開箱即用。此外，Flume 1.4需要一些更新才能使其與Hadoop 2一起使用。

問題

希望將所有生產伺服器的系統日誌檔案推送到HDFS。

解決方案

使用Flume(一種資料收集系統)將Linux日誌檔案推送到HDFS。

討論

Flume的核心是日誌檔案收集和分發，收集系統日誌並傳輸到HDFS。此技術的第一步涉及捕獲附加到/var/log/messages的所有資料並將其傳輸到HDFS。我們將執行一個Flume agent(稍後詳細介紹)，這將完成所有工作。

Flume agent需要配置檔案指明該做什麼，以下程式碼為用例定義了一個：

要讓示例起作用，需要確保正在使用可以訪問Hadoop叢集的主機，以及 HADOOP_HOME配置正確，還需要下載並安裝Flume並將FLUME_HOME設定為指向安裝目錄。

使用檔名tail-hdfspart1.conf將前面的檔案複製到Flume conf目錄中。完成後，就可以啟動Flume agent例項了：

這應該會產生很多輸出，但最終應該看到類似於以下的輸出，表明一切都好了：

此時，應該看到HDFS中出現的一些資料：

.tmp字尾表示Flume開啟檔案並繼續寫入。一旦完成，這將重新命名檔案並刪除字尾：

可以捕獲此檔案以檢查其內容，內容應與tail/var/log/messages對齊。

到目前為止，我們已經用Flume完成了第一次資料移動!

解析Flume agent

讓我們回過頭來檢查一下做了什麼。主要有兩個部分：定義Flume配置檔案，以及執行Flume agent。Flume配置檔案包含有關源，通道和接收器的詳細資訊，這些都是影響Flume資料流不同部分的概念。圖5.4顯示了Flume agent中的這些概念。

讓我們逐步介紹這些概念，包括用途以及工作原理。

Sources

Flume sources負責從外部客戶端或其他Flume接收器讀取資料。Flume中的資料單元被定義為一個事件，本質上是一個有效載荷和可選後設資料集。Flume源將這些事件傳送到一個或多個Flume通道，這些通道處理儲存和緩衝。

圖5.4 agent上下文中的Flume元件說明

Flume有一組廣泛的內建源，包括HTTP，JMS和RPC。讓我們來看看你設定的特定於源的配置屬性：

exec source允許執行Unix命令，標準輸出中發出的每一行都被捕獲為事件(預設情況下會忽略常見錯誤)。在前面的示例中，tail -F命令用於在生成系統訊息時捕獲它們。如果可以更好地控制檔案(例如，如果可以在完成所有寫入後將它們移動到目錄中)，考慮使用Flume的假離線目錄源(稱為spooldir)，因為它提供了exec source無法獲得的可靠性語義。

僅使用tail進行測試

不鼓勵使用tail進行測試以外的任何操作。

此配置中突出顯示的另一個功能是攔截器，它允許向事件新增後設資料。回想一下，HDFS中的資料是根據時間戳組織的：第一部分是日期，第二部分是時間：

之所以能這樣做，是因為使用時間戳攔截器修改了每個事件，時間戳攔截器將源處理事件的時間(以毫秒為單位)插入到事件頭。然後，Flume HDFS接收器使用此時間戳來確定事件寫入位置。

為了總結Flume sources，讓我們介紹一下其提供的功能：

事務語義，允許以至少一次語義可靠地移動資料，並非所有資料來源都支援此功能。
攔截器，提供修改或刪除事件的功能。對於使用主機，時間和唯一識別符號來註釋事件非常有用，這對於重複資料刪除非常有用。
選擇器，允許以各種方式扇出或多路複用事件，可以透過將事件複製到多個通道來扇出事件，也可以根據事件頭將事件路由到不同通道。

通道

Flume通道在agent內部提供資料儲存設施。源將事件新增到通道，並從通道中刪除事件。Flume內部的通道提供高可用性，可以根據應用所需的容量和吞吐量選擇。

Flume捆綁了三個通道：

記憶體通道將事件儲存在記憶體佇列中。這對於高吞吐資料流非常有用，但其沒有永續性保證，這意味著如果agent發生故障，使用者將丟失資料。
檔案通道將事件持久儲存到磁碟。該實現使用高效的日誌並具有強大的永續性。
JDBC通道將事件儲存在資料庫中。這提供了最強的可用性和可恢復性，但是以效能為代價。

在前面的示例中，我們使用了記憶體通道，並將其儲存事件數限制為100,000。一旦記憶體通道達到最大事件數，將開始拒絕來自源的其他請求以新增更多事件。根據源的型別，這意味著源將重試或刪除事件(exec源將丟棄事件)：

Sinks

Flume接收器從一個或多個Flume通道中接收事件，並將這些事件轉發到另一個Flume源(在多hop流程中)，或以特定於接收器的方式處理事件。Flume內建了許多接收器，包括HDFS，HBase，Solr和Elasticsearch。

在前面的示例中，我們將流配置為使用HDFS接收器：

我們將接收器配置為根據時間戳寫入檔案(請注意%y和其他時間戳別名)。我們可以這樣做，因為使用exec源中的時間戳攔截器標記事件。實際上，可以使用任何header值來確定事件輸出位置(例如，可以新增主機攔截器，然後根據生成事件的主機來寫入檔案)。

可以透過各種方式配置HDFS接收器，以確定檔案的滾動方式。當接收器讀取第一個事件時，它將開啟一個新檔案(如果尚未開啟)並寫入該檔案。預設情況下，接收器將繼續保持檔案開啟並將事件寫入其中，大約需要30秒，之後檔案將被關閉，可以使用表5.5中的屬性更改滾動行為。

表5.5 Flume HDFS接收器的rollover屬性

預設HDFS接收器設定不應在生產中使用，因為它們會導致大量可能很小的檔案。建議升級value或使用下游壓縮作業來合併這些小檔案。

HDFS接收器允許指定在寫入檔案時如何序列化事件。預設情況下，它們以文字格式序列化，沒有攔截器新增任何header。例如，如果要在Avro中寫入資料(也包括事件頭)，則可以使用序列化程式配置來執行此操作。這樣做時，還可以指定Avro內部用於壓縮資料的Hadoop壓縮編解碼器：

總結

Flume中的可靠性取決於使用的通道型別，資料來源是否具有重新傳輸事件的能力，以及是否將事件多路複用到多個源以減輕不可恢復的節點故障。在該技術中，使用了儲存器通道和執行器源，但是在面對故障時都不提供可靠性。新增可靠性的一種方法是用假離線目錄源替換exec源，並用磁碟通道替換記憶體通道。

我們可以使用單個源，通道和接收器執行單個agent的單臺計算機上使用Flume，但Flume可以支援完全分散式設定，可以在多個主機上執行agent，在源和最終目標之間有多個agent hop。圖5.5顯示了Flume如何在分散式環境中執行。

此技術的目標是將資料移動到HDFS中。但是，Flume可以支援各種資料接收器，包括HBase，檔案roll，Elasticsearch和Solr。使用Flume寫入Elasticsearch或Solr可實現強大的近實時索引。

因此，Flume是一個非常強大的資料移動工具，可以輕鬆支援將資料移動到HDFS以及許多其他位置。它可以持續移動資料並支援各種級別的彈性，以解決系統故障，這是一個只需簡單配置就可執行的系統。

圖5.5 使用負載平衡和 fan-in將log4j日誌移動到HDFS的Flume設定

Flume沒有真正最佳化的是使用二進位制資料。它可以支援移動二進位制資料，但會將整個二進位制事件載入到記憶體中，因此移動大小為GB或更大的檔案將無法正常工作。

實踐：一種將檔案複製到HDFS的自動機制

你可能已經學會了如何使用像Flume這樣的日誌收集工具自動將資料移動到HDFS中。但是，這些工具不支援使用半結構化或二進位制資料輸出。在該實踐中，我們將瞭解如何自動將這些檔案移動到HDFS中。

企業實際生產環境通常具有網路孤島，Hadoop叢集可以遠離其他生產應用程式進行細分。在這種情況下，Hadoop叢集可能無法從其他資料來源提取資料，因此無需將資料推送到Hadoop。

需要一種機制來自動化將任何格式的檔案複製到HDFS的過程，類似於Linux工具rsync。該機制應該能夠壓縮用HDFS編寫的檔案，並提供一種動態確定HDFS目的地的方法以進行資料分割槽。

現有的檔案傳輸機制，如Flume，Scribe和Chukwa，都是為了支援日誌檔案。如果檔案格式不同，例如semistructured或binary，該怎麼辦?如果檔案以Hadoop從屬節點無法直接訪問的方式被孤立，那麼也無法使用Oozie來幫助進行檔案輸入。

問題

需要自動執行將遠端伺服器上的檔案複製到HDFS的過程。

解決方案

開源HDFS File Slurper專案可以將任何格式的檔案複製到HDFS或從中複製出來。該技術涵蓋了如何配置和使用它來將資料複製到HDFS中。

討論

可以使用HDFS File Slurper來幫助實現自動化()。HDFS File Slurper是一個簡單的實用程式，支援將檔案從本地目錄複製到HDFS，反之亦然。

圖5.6提供了Slurper的高階概述，以及如何使用它來複制檔案的示例。Slurper讀取源目錄中存在的所有檔案，並可選擇查詢指令碼以確定目標目錄中的檔案位置。然後，它將檔案寫入目標，之後有一個可選的驗證步驟。在成功完成所有步驟後，Slurper將原始檔移動到對應資料夾。

圖5.6 用於複製檔案的HDFS File Slurper資料流

使用這種技術，需要確保解決以下幾個挑戰：

如何有效地將寫入分割槽到HDFS，以便不將所有內容整合到一個目錄?
如何確定HDFS中的資料是否已準備好進行處理(以避免讀取中間複製的檔案)?
如何自動定期執行實用程式?

第一步是從/releases下載最新的HDFS File Slurper tarball，並將其安裝在可以訪問Hadoop叢集和本地Hadoop安裝的主機上：

元件

在執行程式碼之前，需要編輯/usr/local/hdfs-slurper/conf/slurper-env.sh並設定hadoop指令碼的位置。以下程式碼是slurper-eng.sh檔案的示例，如果遵循Hadoop安裝說明：

Slurper捆綁了/usr/local/hdfs-slurper/conf/slurper.conf檔案，其中包含源和目標目錄的詳細資訊以及其他選項。該檔案包含以下預設設定，你可以更改：

讓我們仔細看看這些設定：

DATASOURCE_NAME—指定要傳輸的資料名稱。當透過Linux init守護程式管理系統啟動時，該名稱用於日誌檔名。
SRC_DIR—指定源目錄。移動到此處的任何檔案都會自動複製到目標目錄(使用中間hop到目標目錄)。
WORK_DIR—這是工作目錄。在複製到目標之前，源目錄中的檔案將移動到此處。
COMPLETE_DIR—指定完整目錄。複製完成後，檔案將從工作目錄移動到此目錄中。或者，可以使用--remove-after-copy選項刪除原始檔，在這種情況下，不應提供--complete-dir選項。
ERROR_DIR—這是錯誤目錄。複製期間遇到的任何錯誤都會導致原始檔移動到此目錄中。
DEST_DIR—設定原始檔的最終目標目錄。
DEST_STAGING_DIR—指定目標目錄。首先將檔案複製到此目錄中，一旦複製成功，Slurper就會將副本移動到目標位置，以避免目標目錄包含部分寫入檔案(如果發生故障)。

你會注意到所有目錄名稱都是HDFS URI。HDFS以這種方式區分不同的檔案系統。file:/URI本地檔案系統上的路徑，hdfs:/URI表示HDFS中的路徑。事實上，只要正確配置Hadoop，Slurper就支援任何Hadoop檔案系統。

執行

建立一個名為/tmp/slurper/in的本地目錄，在其中寫入一個空檔案，然後執行Slurper：

Slurper設計的一個關鍵特性是不能與部分寫入檔案一起使用。檔案必須以原子方式移動到源目錄中(Linux和HDFS檔案系統中的檔案移動都是原子的)。或者，可以寫入以句點(.)開頭的檔名，Slurper會忽略該檔名，檔案寫入完成後，可以將檔案重新命名為不帶句點字首的名稱。

請注意，複製具有相同檔名的多個檔案將導致目標被覆蓋，使用者有責任確保檔案是唯一的，以防止這種情況發生。

動態目標路由

如果每天將少量檔案移動到HDFS中，則上一種方法很有效。但是，如果正在處理大量檔案，你會想到將它們分成不同的目錄。這樣做的好處是可以對MapReduce作業的輸入資料進行更細粒度的控制，並有助於在檔案系統中整體組織資料(如果不希望計算機上的所有檔案都在單個目錄)。

如何對目標目錄和Slurper使用的檔名進行更多動態控制?Slurper配置檔案具有SCRIPT選項(與DEST_DIR選項互斥)，可以在其中指定一個指令碼，該指令碼提供原始檔到目標檔案的動態對映。

假設正在使用的檔案包含檔名中的日期，並且已決定要按日期在HDFS中組織資料。那麼，可以編寫指令碼來執行此對映活動。以下示例是執行此操作的Python指令碼：

現在可以更新/usr/local/hdfs-slurper/conf/slurper.conf，設定SCRIPT，並註釋掉DEST_DIR，這會在檔案中生成以下條目：

如果再次執行Slurper，會注意到目標路徑現在由Python指令碼按日期分割槽：

資料壓縮和驗證

如果要在HDFS中壓縮輸出檔案並驗證副本是否正確，該怎麼辦?需要使用COMPRESSION_CODEC選項，其值是實現CompressionCodec介面的類。如果壓縮編解碼器是LZO或LZOP，還可以新增CREATE_LZO_INDEX選項，以便建立LZOP索引。 (具體內容請閱讀第四章，連結見文末)

驗證功能會在複製完成後重新讀取目標檔案，並確保目標檔案的校驗和與原始檔匹配。這導致處理時間更長，但增加了複製成功的額外保證。

以下配置片段顯示了LZOP編解碼器，LZO索引和啟用的檔案驗證：

讓我們再次執行Slurper：

連續運轉

現在，你已經掌握了基本機制，最後一步是將該工具作為守護程式執行，以便不斷查詢要傳輸的檔案。為此，可以使用名為bin/slurper-inittab.sh的指令碼，該指令碼旨在與inittab respawn一起使用。

此指令碼不會建立PID檔案或執行nohup-在respawn的上下文中都沒有意義，因為inittab正在管理程式。使用DATASOURCE_NAME配置值來建立日誌檔名，這意味著可以使用記錄到不同日誌檔案的不同配置檔案來啟動多個Slurper例項。

總結

Slurper是一個很方便的工具，用於從本地檔案系統到HDFS的資料輸入，還透過從HDFS複製到本地檔案系統來支援資料輸出。在MapReduce無法訪問檔案系統並且正在傳輸的檔案形式不適用於Flume等工具的情況下，它非常有用。

實踐：使用Oozie安排定期資料提取

如果資料位於檔案系統、Web伺服器或可從Hadoop叢集訪問的任何其他系統上，我們將需要一種定期將該資料提取到Hadoop的方法。目前，有一些推送日誌檔案和從資料庫中提取的工具可供選擇，但如果需要與其他系統進行互動，則可能需要自己處理資料輸入過程。

此技術使用Oozie 4.0.0版。

此資料入口分為兩部分：將資料從另一系統匯入Hadoop以及定期進行資料傳輸。

問題

自動執行每日任務，以將內容從HTTP伺服器下載到HDFS。

解決方案

Oozie可用於將資料移動到HDFS，還可用於執行釋出，例如啟動MapReduce作業以處理獲取的資料。Oozie現在是Apache專案，管理資料處理活動的Hadoop工作流引擎。Oozie還有一個協調器引擎，可以根據資料和時間觸發器啟動工作流程。

討論

在此實踐中，我們將每24小時從多個URL執行下載，使用Oozie管理工作流程和日程安排。該技術的流程如圖5.7所示，我們將使用Oozie觸發功能每24小時啟動一次MapReduce作業。

圖5.7 Oozie技術的資料流

第一步是檢視協調器XML配置檔案。Oozie的協調引擎使用此檔案來確定何時應啟動工作流程。Oozie使用模板引擎和表示式語言來執行引數化，如下程式碼所示。使用以下內容建立名為coordinator.xml的檔案：

程式碼5.1 使用模板引擎透過Oozie執行引數化

Oozie排程可能會讓人困惑的是，開始和結束時間與作業執行的實際時間無關。相反，它們指的是每個工作流程執行建立的日期，這在定期生成資料並且希望能夠及時返回某個點並對該資料執行某些操作的情況下非常有用。在這個例子中，你希望每24小時執行一份工作。所以，你可以將開始日期設定為昨天，將結束日期設定為將來的某個日期。

接下來，我們需要定義實際工作流程，該工作流程將在每個固定時間間隔執行，並且在到達間隔時繼續執行。為此，建立一個名為workflow.xml的檔案，其中包含下一個程式碼中顯示的內容。

程式碼5.2 使用Oozie協調器定義工作流程

Oozie希望map和reduce類使用“舊的”MapReduce API。如果要使用“新”API，則需要指定其他屬性：

最後一步是定義屬性檔案，該檔案指定如何獲取HDFS，MapReduce以及之前在HDFS中標識的兩個XML檔案的位置。建立一個名為job.properties的檔案，如以下程式碼所示：

不同Hadoop版本的JobTracker屬性

如果使用Hadoop 1.X版本，則應使用jobTracker屬性中的JobTracker RPC埠(預設值為8021)。否則使用YARN ResourceManager RPC埠(預設為8032)。

在上一個程式碼段中，HDFS中的位置指示本章前面編寫的coordinator.xml和workflow.xml檔案的位置。現在，需要將XML檔案，輸入檔案和包含MapReduce程式碼的JAR檔案複製到HDFS中：

最後，在Oozie中執行作業：

可以使用作業ID獲取有關作業的一些資訊：

此輸出導致作業的一次執行，可以看到執行時間。整體狀態為RUNNING，這意味著作業正在等待下一個間隔發生。當整個作業完成時(到結束日期之後)，狀態將轉換為SUCCEEDED。

可以確認HDFS中的輸出目錄對應於具體日期：

只要作業正在執行，它將繼續執行直到日期結束，在此示例中已將其設定為2026年。如果要停止作業，請使用-suspend選項：

Oozie還可以分別使用-resume和-kill選項恢復暫停的作業以及殺死工作流程。

總結

我展示了使用Oozie協調器的一個示例，它提供了類似cron的功能來啟動定期Oozie工作流程。Oozie協調器還可用於根據資料可用性觸發工作流(如果沒有可用資料，則不會觸發工作流)。例如，如果有一個外部流程，甚至MapReduce定期生成資料，就可以使用Oozie的資料驅動協調器來觸發工作流，該工作流可以聚合或處理資料。

本節，我們介紹了三種可用於資料匯入的自動機制。第一種是Flume，用於將日誌資料傳輸到Hadoop的強大工具，第二種是HDFS File Slurper，它可以自動化將資料推送到HDFS。最後研究了Oozie如何用於定期啟動MapReduce作業以將資料匯入HDFS或MapReduce。

在探索資料輸入上，我們研究了推送日誌檔案，從常規檔案系統推送檔案以及從Web伺服器中提取檔案。大多數企業都會感興趣的一大資料來源是位於OLTP資料庫中的關係資料。在本章接下來的幾篇文章中，我將分享如何訪問關係資料。

相關文章：

1、《第一章：Hadoop生態系統及執行MapReduce任務介紹！》連結： http://blog.itpub.net/31077337/viewspace-2213549/

2、《學習Hadoop生態第一步：Yarn基本原理和資源排程解析！》連結： http://blog.itpub.net/31077337/viewspace-2213602/

3、《MapReduce如何作為Yarn應用程式執行？》連結： http://blog.itpub.net/31077337/viewspace-2213676/

4、《Hadoop生態系統各元件與Yarn的相容性如何？》連結： http://blog.itpub.net/31077337/viewspace-2213960/

5、《MapReduce資料序列化讀寫概念淺析！》連結： http://blog.itpub.net/31077337/viewspace-2214151/

6、《MapReuce中對大資料處理最合適的資料格式是什麼？》連結： http://blog.itpub.net/31077337/viewspace-2214325/

7、《如何在MapReduce中使用SequenceFile資料格式？》連結： http://blog.itpub.net/31077337/viewspace-2214505/

8、《如何在MapReduce中使用Avro資料格式？》連結： http://blog.itpub.net/31077337/viewspace-2214709/

9、《企業自有資料格式雜亂，MapReduce如何搞定？》連結： http://blog.itpub.net/31077337/viewspace-2214826/

10、《企業使用Hadoop的重大挑戰：如何在HDFS中組織和使用資料？》連結： http://blog.itpub.net/31545816/viewspace-2215158/ 》

11、《如何在HDFS中進行資料壓縮以實現高效儲存？》連結： http://blog.itpub.net/31545816/viewspace-2215281/

12、《Hadoop資料傳輸：如何將資料移入和移出Hadoop？》連結：http://blog.itpub.net/31545816/viewspace-2215580/

如何將日誌檔案和二進位制檔案快速匯入HDFS？

相關文章