一臺單機在存儲容量、并發性上毫無疑問都是有很大限制的。為了解決單機無法完成的大存儲(>1TB)和大規模計算，分布式系統就應運而生了。

MapReduce

---

MapReduce計算框架適用于超大規模的數據（100TB量級）且各數據之間相關性較低的情況。MapReduce的思想是由Google的論文所提及而被廣為流傳的，簡單的一句話解釋MapReduce就是“任務的分解與結果的匯總”。

MapReduce的編程模型：

• Map: <k1,v1> –> <k2,v2>
• Shuffle: sort by key & group by key
• Reduce: <k2,<list of v2>>? -> <k3,v3>

Map的作用就是把輸入數據打散，做簡單的處理，輸出。而hadoop則要先將中間數據排序，這個稱為shuffle，然后由reduce把中間數據合并到一起。將最終結果輸出。

其框架實現是由一個單獨運行在主節點上的JobTracker和運行在每個集群從屬節點上的TaskTracker共同組成。主節點負責調度構成一個個作業，這些作業分布運行在從屬節點上，主節點監控它們的執行情況并管理失敗的作業重新執行。

Google的GFS(Google File System)，MapReduce論文

• 采用了函數式編程語言的map和reduce兩個函數
• 解決那些數據可以切割進行計算的應用，比如grep操作，求和計算
• 提供了運行平臺，自動處理出錯

Mapreduce & Hadoop Algorithms in Academic Papers (4th update – May 2011)

Google MapReduce/GFS/BigTable三大技術的論文中譯版

?

Hadoop

---

Hadoop是偉大的Apache基金會實現的一套分布式系統，是采用Java開發的開源MapReduce框架實現。Hadoop包括分布式文件系統（HDFS）、MapReduce計算框架、HBase等很多組件——這些基本都是Google的GFS/MapReduce/BigTable的克隆產品。

Hadoop經過數年的發展，目前已經很成熟了，尤其是其中的HDFS和MapReduce計算框架組件。數百臺機器的集群已經被證明可以使用(Yahoo!的最大hadoop集群部署為4000個計算節點)，可以承擔PB級別的數據：

• Hadoop Distributed File System(HDFS)?
  對數據進行分布式存儲，并且為上層的mapred計算層提供支持
• Hadoop MapReduce?
  對存儲在HDFS上的數據進行分布式計算

Hadoop的前身是Apache Nutch，始于2002年，是Apache Lucene的子項目之一，Hadoop在2008年1月被提升為頂級項目。在Google提出在基于自己的BigTable大規模數據存儲的Map Reduce計算框架之后，Nutch的發起者開始嘗試將二者結合并在2006年分離出來成立了一套完整的軟件取名為Hadoop。因此，如今的Hadoop成為了一個包含HDFS，MapReduce，Pig，ZooKeeper等子項目的集合。

?

Hadoop（某人兒子的一只虛擬大象的名字）是一個復雜到極致，又簡單到極致的東西。

• 說它復雜，是因為一個hadoop集群往往有幾十臺甚至成百上千臺low cost的計算機組成，你運行的每一個任務都要在這些計算機上做任務的分發，執行中間數據排序以及最后的匯總，期間還包含節點發現，任務的重試，故障節點替換等等等等的維護以及異常情況處理。誰叫hadoop集群往往都是由一些平民計算機組成，沒事兒罷個工什么的，實在是再尋常不過的事情。
• 而說其簡單，則是因為，上面說到的那些，你通通不用管，你所需要做的，就是寫一個程序，當然也可以是腳本，從標準輸入讀入一條數據，處理完之后，把結果輸出到標準輸出。

舉個簡單的例子：公安局要根據數據庫內身份證號獲得全國每個地市人口數情況（好吧，這個應該是統計局做的），這個任務落到你的頭上了，你應該先把所有的身份證號導出到文件中，每行一個，然后把這些文件交給map。Map中的要做的就是截取身份證號的前面六位，把這六位數字直接輸出。然后hadoop會把這些身份證號的前六位排序，把相同的數據都排到一起，交給reduce，reduce判斷每次輸入的號碼是否與上一個處理的相同，相同則累加，不同則把之前的號碼，和統計的數值輸出。這樣，你就獲得了各地市的人口數統計。

下面這個圖就是map和reduce處理的圖示。

上圖是MapReduce的數據處理視圖。分為map，shuffle，reduce三個部分。各map任務讀入切分后的大規模數據進行處理并將數據作為一系列key:value對輸出，輸出的中間數據按照定義的方式通過shuffle程序分發到相應的reduce任務。Shuffle程序還會按照定義的方式對發送到一個reduce任務的數據進行排序。Reduce進行最后的數據處理。

?

現在討論得比較熱的是Facebook主打的Hive，還有淘寶網所使用的HBase。這二者都是基于Hadoop的衍化項目。

一個Hive的實例是Facebook利用Hive QL強大的查詢分析能力給的頁面的廣告商提供大量有價值的用戶喜好數據，便于廣告商在特定的時機投放回報率最高的廣告。一個HBase的實例是淘寶網利用HBase分布式讀寫大數據的能力來支撐圣誕、光棍節這種龐大的實時在線交易數據。（原文）

HBase

---

Hadoop項目中的HBase（分布式索引系統, 類Google的BigTable）是一個按列存儲的NoSQL分布式數據庫。該技術來源于Google的BigTable（一個結構化數據的分布式存儲系統）。HBase在Hadoop基礎上提供了類似BigTable的分布式存儲能力。

HBase是一個適合于存儲非結構化數據的數據庫，因為它是基于列存儲而不是行存儲，用戶將數據存儲在稀松的表里，每一行數據都可以擁有可選擇的鍵和任意數量的列。HBase主要用于需要隨機訪問實時讀寫大數據的應用。

HBase提供的功能和接口都非常簡單，只能進行簡單的K-V查詢，因此并不直接適用于大多數日志分析應用。

---

所以一般使用Hadoop來做日志分析，首先還是需要將日志存儲在HDFS中，然后再使用它提供的MapReduce API編寫日志分析程序。

MapReduce是一種分布式編程模型，并不難學習，但是很顯然使用它來處理日志的代價依然遠大于單機腳本或者SQL。一個簡單的詞頻統計計算可能都需要上百代碼——SQL只需要一行，另外還有復雜的環境準備和啟動腳本。Hadoop的實現就要復雜的多，通常需要兩輪MapReduce來完成。

首先要在第一輪的mapper中計算部分ip的訪問次數之和，并以ip為key輸出；然后在第一輪的reduce中就可以得到每個ip完整的計數，可以順便排個序，并且只保留前100個；由于reduce一般會有很多個，所以最后還需要將所有reduce的輸出進行合并、再排序，并得到最終的前100個IP以及對應的訪問量。

所以使用Hadoop來做日志分析很顯然不是一件簡單事情，它帶來了很多的額外的學習和運維成本，但是至少，它讓超大規模的日志分析變成了可能。

?

Hive(Facebook)

---

在超大規模的數據上做任何事情都不是一件容易的事情，包括日志分析，但也并不是說分布式的日志分析就一定要去寫MapReduce代碼。

總是可以去做進一步的抽象，在特定的應用下讓事情變得更簡單：

也許有人會很自然的想到如果能用SQL來操作Hadoop上的數據該有多好。

事實上，不僅僅只有你一個人會這么想，很多人都這么想，并且他們實現了這個想法，于是就有了Hive。

Hive現在也是Hadoop項目下面的一個子項目，是建立在Hadoop基礎之上的數據倉庫，它可以讓我們用SQL的接口來執行MapReduce（該語言簡稱Hive QL），甚至提供了JDBC和ODBC的接口。有了這個之后，Hadoop基本上被包裝成一個數據庫。Hive提供了一些用于數據整理、特殊查詢和分析存儲在Hadoop文件系統中數據的工具。

當然實際上Hive的SQL最終還是被翻譯成了MapReduce代碼來執行，因此即使最簡單的SQL可能也要執行好幾十秒。幸好在通常的離線日志分析中，這個時間還是可以接受的。更重要的是，對于上面提到的例子，我們又可以用一樣的SQL來完成分析任務了。

當然Hive并不是完全的兼容SQL語法，而且也不能做到完全的對用戶屏蔽細節。很多時候為了執行性能的優化，依然需要用戶去了解一些MapReduce的基本知識，根據自己的應用模式來設置一些參數，否則我們可能會發現一個查詢執行很慢，或者壓根執行不出來。

另外，很顯然Hive也并不能覆蓋所有的需求，所以它依然保留插入原始MapReduce代碼的接口，以便擴展。

?

即使有了Hive這樣一個類似于數據庫的東西，我們依然還有很多事情需要做。

例如時間久了，可能會有越來越多的需要例行執行的SQL，而這些SQL中，

• 也許有一些是做了重復的事情；
• 也許有一些的執行效率非常低下，一個復雜的SQL就占滿了所有的計算資源。

這樣的系統會變得越來越難以維護的，直到有一天例行的SQL終于跑不完了。而最終用戶往往不會去關心這些事情，他們只關心自己提交的查詢是不是能即時得到響應，怎么樣才能盡快的拿到結果。

舉個簡單的例子，如果發現在使用apache_log的所有查詢中，幾乎沒有人用其中的user_agent字段，那么我們完全可以把這個字段去除掉，或者拆分成兩張表，以減少多數查詢的IO時間，提高執行的效率。

為了系統化的解決這些問題，

• 我們可能需要引入例行任務的調度機制，
• 可能需要去分析所有的SQL來發現哪些是可以合并的、哪些的性能需要優化，
• 使用的數據表是不是需要做水平或者垂直分表等等。
• 根據實際情況的不同，這時事情可能是人工來完成，也可能是寫程序來自動分析并調整。

再者隨著日志類型、分析需求的不斷增長。用戶會越來越多的抱怨很難找到想要的數據在哪份日志里，或者跑的好好的查詢因為日志格式的變化而突然不能用了。另外上面提到的ETL過程也會變得復雜，簡單的轉換導入腳本很可能已經解決不了問題。這時候可能需要構建一個數據管理系統，或者干脆考慮建立一個所謂的數據倉庫。

總之，隨著日志數據量、日志類型、用戶數量、分析需求等等的不斷增長，越來越多的問題會逐漸浮現出來，日志分析這件事情可能就不再像我們最初想的那么簡單，會變得越來越有價值，也越來越有挑戰。

?

ZooKeeper

---

?

?

日志分析方法概述

使用hadoop進行大規模數據的全局排序

Zookeeper工作原理

框計算垂直搜索之索引篇

?

HDFS

---

HDFS是基于Java實現的可以部署在廉價的硬件上的，具有高吞吐率和高容錯性的一套開源系統。由于HDFS放寬了POSIX的部分約束規范，使得它能以流形式訪問文件系統中的數據。

• 分布式存儲?
  文件被分成256MB的block?
  block被分配到各個存儲節點上
• 容錯性?
  每個block有多個replica(副本)?
  Re-Replication
• 負載均衡?
  Re-Balance

整個HDFS系統設計了兩套自己的協議，都是基于TCP/IP協議之上設計的：Client Protocol和DataNode Protocol。

• Client Protocol負責客戶端與文件系統的通信，
• 而文件系統內部各個節點之間通過DataNode Protocol協議來實現內部的通信和文件和管理。

?

這是一張任何介紹hdfs的文章都會出現的架構圖。

HDFS采用了主從(Master/Slave)結構模型，一個HDFS由一個NameNode和若干個DataNode組成。其中NameNode作為主服務器，管理文件系統的命名空間和客戶端的連接。集群中的DataNode則管理各自存儲的數據。

NameNode（以下簡稱nn）是master，主要負責管理hdfs文件系統和client對文件的訪問，具體地包括

• 文件系統命名空間namespace管理（其實就是目錄結構，HDFS對外提供一個namespace允許用戶把數據存為文件的格式），
• block管理（其中包括 filename->block，block->ddatanode list的對應關系）。
• nn提供的是始終被動接收服務的server，主要有三類協議接口：ClientProtocol接口、DatanodeProtocol接口、NamenodeProtocol接口，貌似還有一種，忘記了。
• HDFS的文件組織結構和linux的local filesystem非常類似。你可以創建，刪除，移動，重命名文件或者目錄。NameNode操作命名空間比如：打開，關閉，重命名文件目錄。
• NameNode只負責元數據信息，沒有數據流。NameNode維護namespace,任何對namespace的改動都記錄在NameNode。

DataNode(簡稱dn)主要是用來存儲數據文件，

• hdfs將一個文件分割成一個個的block，這些block可能存儲在一個DataNode上或者是多個DataNode上。
• 通常一個機器節點一個DataNode，管理這個節點上的存儲。
• DataNode負責為文件系統的客戶提供讀/寫操作服務。DataNode同時還為NameNode提供block創建，刪除，備份機制
• dn負責實際的底層的文件的讀寫，如果客戶端client程序發起了讀hdfs上的文件的命令，那么首先將這些文件分成block，
• 然后nn將告知client這些block數據是存儲在那些dn上的，之后，client將直接和dn交互。

體系結構中還有個節點沒畫出來，Secondary NameNode，

• 該部分主要是定時對NameNode進行數據snapshots進行備份，這樣盡量降低NameNode崩潰之后，導致數據的丟失，
• 其實所作的工作就是從nn獲得fsimage和edits把二者重新合并然后發給nn，這樣，既能減輕nn的負擔又能保險地備份。

---

不管是client還是dn的消息發到nn后最終都會落到FSNamesystem身上，這是一個重量級家伙，如圖，對各種服務請求的處理都轉交給它完成，它提供了對各種數據結構操作的接口，這些數據結構共同維護了整個namenode的元數據信息。

x`

這里有篇分析namenode源碼的博文，可供進一步探究。

?

MapReduce

---

?

和HDFS類似，MapReduce中也有兩種角色：Master/Worke

Master-JobTracker?
–作業與任務調度?
–負責將中間文件信息通知給reducer所在的worker?
–Master周期性檢查Worker的存活?
Worker-TaskTracker?
–TaskTracker空閑, 向Master要任務?
–執行mapper或者reducer任務

除了作業任務調度，這個框架還要做以下處理?
–錯誤處理，失敗任務自動重算?
–防止慢作業，任務的預測執行

更多可以看Hadoop開源社區MapReduce官方指南。

下一代MapReduce資源調度與計算模型分離

?

Streaming

---

Streaming接口?
–支持使用腳本和任何程序來書寫mapper和reducer程序?
–java和本地的腳本或程序利用管道傳輸數據?
–程序示例:?
$HADOOP_HOME/bin/hadoop streaming -input myInputDirs -output myOutputDir -mapper "grep baidu" -reducer /bin/wc

?

?

Message-Passing Interface (MPI)

---

MPI是一種消息傳遞編程模型，并成為該編程模型的代表和事實標準。

• MPI是一個庫，而不是一門語言，MPI庫可以被FORTRAN/C/C++/Python/java調用，把這些串行語言擴展為并行語言。
• MPI擁有多種開源實現：Mpich, lammpi, openmpi。
• MPI能用于大多數并行計算機、機群系統和異構網絡環境，能達到較高的數據傳輸速率。一個正確的MPI程序，可以不加修改地在所有的并行計算機上運行。
• 開發成本高，無容錯

---

?

HDFS

數據透明壓縮--節省存儲空間(利用CPU波壓縮長時間未使用的塊，隨即讀處理+Append處理)

數據可靠性--HDFS塊復制改進

?

MapReduce

調度--Job Queue：多隊列 借用 搶占（資源調度）

Hadoop C++ Extension（HCE用戶編程框架）

作業斷點重啟--作業失敗后可以接著上次的進度運行，集群重啟后運行的作業重啟前的進度運行

Shuffle獨立--提高shuffle的總吞吐 減少資源浪費

?

同一個reduce不同類型的數據輸出到不同文件

多路輸出 == 多路合并？

?

傳統數據庫的瓶頸

---

傳統的基于RDBMS的存儲和計算存在著擴展差和容錯差的兩大瓶頸。

關于分布式數據庫的現實

• 首先，實現比較完美的分布式數據庫（受限于CAP原則）是一個非常復雜的問題，因此在這里并不像單機數據庫那樣，有那么多開源的好東西可以用，甚至于商用的也并不是太多。當然，也并非絕對，如果有錢，還是可以考慮一下Oracle RAC、Greenplum之類東西。
• 其次，絕大多數分布式數據庫都是NoSQL的，所以想繼續用上SQL的那些優點基本上是沒指望，取而代之的都是一些簡單、難以使用的接口。單從這點看來，使用這些數據庫的價值已經降低很多了。
• 所以，還是先現實一點，先退一步考慮如何解決的超大規模的日志的分析問題，而不是想如何讓它變的像在小數據規模時那樣簡單。單單想做到這點，目前看來并不是太難，并且依然有免費的午餐可以吃。

比較SQL數據庫和Hadoop

1 用向外擴展代替向上擴展（服務器集群）

2 用key/value對代替關系表（文本、圖片、xml文件）

3 用函數式編程（mapreduce）代替聲明式查詢（SQL）

?

http://www.cnblogs.com/wangyonghui/category/319595.html

http://www.cnblogs.com/wycg1984/category/238035.html

http://www.cnblogs.com/wayne1017/archive/2007/03/18/668768.html

http://blog.csdn.net/lengzijian/article/category/942129

from:?http://www.cnblogs.com/wei-li/p/ScaldingFirstSight3.html

《新程序員》：云原生和全面數字化實踐50位技術專家共同創作，文字、視頻、音頻交互閱讀

總結

以上是生活随笔為你收集整理的Hadoop的那些事儿的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。