Hadoop權威指南-讀書筆記-01-初識Hadoop

Hadoop權威指南-讀書筆記

記錄一下讀這本書的時候覺得有意思或者重要的點~

在這里插入圖片描述

第一章—初識Hadoop

在這里插入圖片描述
Tips：這個引例很有哲理嘻嘻😄，道出了分布式的靈魂。

1.1 數據！數據！

這一小節主要介紹了進入大數據時代，面臨數據量飆升的問題，我們該如何管理好自己的數據，或者說如何利用好規模如此龐大的數據。

在這里插入圖片描述

博主摘錄了一些原文：

有句話說得好: “大數據勝于好算法。” 意思是說對于某些應用(譬如根據以往的偏好來推薦電影和音樂)，不論算法有多牛，基于小數據的推薦效果往往都不如基于大量可用數據的一般算法的推薦效果。（More Data usually beats better algorithms）
現在，我們已經有了大量數據，這是個好消息。但不幸的是，我們必須想方設法好好地存儲和分析這些數據。

More Data usually beats better algorithms，這個觀點博主認為很有意思🤣

1.2 數據的存儲與分析

這里博主就直接記錄一下原文比較值得思考的片段了哈 ~

我們遇到的問題很簡單:在硬盤存儲容量多年來不斷提升的同時，訪問速度(硬盤數據讀取速度)卻沒有與時俱進。

Tips：這里并非說多年來硬盤的讀取速度沒有提升，而是硬盤的讀取速度的提升相對于硬盤容量的提升還有差距。

這里文章有一個小例子大家可以看一下：1990年，一個普通硬盤可以存儲1370MB數據，傳輸速度為4.4MB/S，因此只需要5分鐘就可以讀完整個硬盤中的數據。20年過去了，1TB的硬盤成為主流，但其數據傳輸速度約為100MB/，讀完整個硬盤中的數據至少得花2.5個小時。

一個很簡單的減少讀取時間的辦法是同時從多個硬盤上讀數據。試想，如果我們有100個硬盤，每個硬盤存儲1%的數據，并行讀取，那么不到兩分鐘就可以讀完所有數據。
Tips：分布式的思想初見雛形
僅使用硬盤容量的1%似乎很浪費。但是我們可以存儲100個數據集，每個數據集1TB，并實現共享硬盤的讀取。可以想象，用戶肯定很樂于通過硬盤共享來縮短數據分析時間;并且，從統計角度來看，用戶的分析工作都是在不同時間點進行的，所以彼此之間的干擾并不太大。
雖然如此，但要對多個硬盤中的數據并行進行讀/寫數據，還有更多問題要解決。
第一個需要解決的是硬件故障問題。一旦開始使用多個硬件，其中個別硬件就很有可能發生故障。為了避免數據丟失，最常見的做法是復制(replication):系統保存數據的復本(replica)，一旦有系統發生故障，就可以使用另外保存的復本。
第二個問題是大多數分析任務需要以某種方式結合大部分數據來共同完成分析，即從一個硬盤讀取的數據可能需要與從另外99個硬盤中讀取的數據結合使用。
各種分布式系統允許結合不同來源的數據進行分析，但保證其正確性是一個非常大的挑戰。MapReduce提出一個編程模型，該模型抽象出這些硬盤讀/寫問題并將其轉換為對一個數據集(由鍵-值對組成)的計算。

1.3 查詢所有的數據

MapReduce看似采用了一種蠻力方法。每個查詢需要處理整個數據集或至少一個數據集的絕大部分。但反過來想，這也正是它的能力。
MapReduce是一個批量查詢處理器，能夠在合理的時間范圍內處理針對整個數據集的動態查詢。
它改變了我們對數據的傳統看法，解放了以前只是保存在磁帶和硬盤上的數據。
它讓我們有機會對數據進行創新。
以前需要很長時間處理才能獲得結果的問題，到現在變得頃刻之間就迎刃而解，同時還可以引發新的問題和新的見解。

這里文中提到了一個運用MR處理數據的例子：

Rackspace公司的郵件部門Mailtrust就用Hadoop來處理郵件日志。
他們寫了一條特別的查詢用于幫助找出用戶的地理分布。
他們是這么描述的:“這些數據非常有用，我們每月運行一次MapReduce任務來幫助我們決定擴容時將新的郵件服務器放在哪些Rackspace數據中心。”
通過整合好幾百GB的數據，用工具來分析這些數據，Rackspace的工程師能夠對以往沒有注意到的數據有所理解，甚至還運用這些信息來改善現有的服務。

Tips：挖掘海量數據的信息并服務于業務，使得業務更好的發展。

1.4 不僅僅是批處理

從MapReduce的所有長處來看，它基本上是一個批處理系統，并不適合交互式分析。
你不可能執行一條查詢并在幾秒內或更短的時間內得到結果。
典型情況下執行查詢需要幾分鐘或更多時間。因此，MapReduce更適合那種沒有用戶在現場等待查詢結果的離線使用場景。
然而，從最初的原型出現以來，Hadoop的發展已經超越了批處理本身。
實際上，名詞“Hadoop”有時被用于指代一個更大的、多個項目組成的生態系統，而不僅僅是HDFS和MapReduce。

在這里插入圖片描述

這些項目都屬于分布式計算和大規模數據處理范疇。這些項目中有許多都是由Apache軟件基金會管理，該基金會為開源軟件項目社區提供支持，其中包括最初的HTTPserver項目(基金會的名稱也來源于這個項目)。

第一個提供在線訪問的組件是HBase，一種使用HDFS做底層存儲的鍵值存儲模型。
HBase不僅提供對單行的在線讀/寫訪問，還提供對數據塊讀/寫的批操作。
Hadoop2中YARN(Yet Another Resource Negotiator)的出現意味著 Hadoop 有了新處理模型。
YARN是一個集群資源管理系統，允許任何一個分布式程序(不僅僅是MapReduce)基于 Hadoop 集群的數據而運行。

在這里插入圖片描述

劃重點：不只有MR可以使用Yarn，任何一個分布式程序都可。

1.5 相較于其他系統的優勢

1.5.1 RDBMS

為什么不能用配有大量硬盤的數據庫來進行大規模數據分析?我們為什么需要Hadoop?
這兩個問題的答案來自于計算機硬盤的另一個發展趨勢:尋址時間的提升遠遠不敵于傳輸速率的提升。
尋址是將磁頭移動到特定硬盤位置進行讀/寫操作的過程它是導致硬盤操作延遲的主要原因，而傳輸速率取決于硬盤的帶寬。
如果數據訪問模式中包含大量的硬盤尋址，那么讀取大量數據集就必然會花更長的時間(相較于流數據讀取模式，流讀取主要取決于傳輸速率)。
另一方面，如果數據庫系統只更新一小部分記錄，那么傳統的B樹(關系型數據庫中使用的一種數據結構，受限于尋址的速率)就更有優勢。
但數據庫系統如果有大量數據更新時，B樹的效率就明顯落后于MapReduce，因為需要使用“排序/合并”(sort/merge)來重建數據庫。

在這里插入圖片描述

在許多情況下，可以將MapReduce視為關系型數據庫管理系統的補充。
MapReduce比較適合解決需要以批處理方式分析整個數據集的問題，尤其是一些特定目的的分析。
RDBMS適用于索引后數據集的點查詢(point query)和更新，建立索引的數據庫系統能夠提供對小規模數據的低延遲數據檢索和快速更新。
MapReduce適合一次寫入、多次讀取數據的應用，關系型數據庫則更適合持續更新的數據集。

Hadoop和關系型數據庫的另一個區別在于它們所操作的數據集的結構化程度。
結構化數據(structured data)是具有既定格式的實體化數據，如XML 文檔或滿足特定預定義格式的數據庫表。這是RDBMS包括的內容。
另一方面，半結構化數據(semi-structured data)比較松散，雖然可能有格式，但經常被忽略，所以它只能作為對數據結構的一般性指導。例如電子表格，它在結構上是由單元格組成的網格，但是每個單元格內可以保存任何形式的數據。
非結構化數據(unstructured data沒有什么特別的內部結構，例如純文本或圖像數據。
Hadoop對非結構化或半結構化數據非常有效，因為它是在處理數據時才對數據進行解釋(即所謂的“讀時模式”)。這種模式在提供靈活性的同時避免了RDBMS數據加載階段帶來的高開銷，因為在Hadoop中僅僅是一個文件拷貝操作。
關系型數據往往是規范的(normalized)，以保持其數據的完整性且不含幾余。規范給Hadoop處理帶來了問題，因為它使記錄讀取成為非本地操作，而Hadoop的核心假設之一偏偏就是可以進行(高速的)流讀/寫操作。

MapReduce 以及Hadoop中其他的處理模型是可以隨著數據規模線性伸縮的。
對數據分區后，函數原語(如map和reduce)能夠在各個分區上并行工作。
這意味著，如果輸入的數據量是原來的兩倍，那么作業的運行時間也需要兩倍。但如果集群規模擴展為原來的兩倍，那么作業的運行速度卻仍然與原來一樣快。SOL查詢一般不具備該特性。

1.5.2 網格計算

高性能計算(High Performance Computing，HPC)和網格計算(Grid Computing)組織多年以來一直在研究大規模數據處理，主要使用類似于消息傳遞接口(MessagePassing Interface，MPI)的API。
從廣義上講，高性能計算采用的方法是將作業分散到集群的各臺機器上，這些機器訪問存儲區域網絡(SAN)所組成的共享文件系統。
這比較適用于計算密集型的作業，但如果節點需要訪問的數據量更龐大(高達幾百GB，Hadoop開始施展它的魔法)，很多計算節點就會因為網絡帶寬的瓶頸問題而不得不閑下來等數據。
Hadoop盡量在計算節點上存儲數據，以實現數據的本地快速訪問。"數據本地化(data locality)特性是Hadoop數據處理的核心，并因此而獲得良好的性能。

Tips：1998年圖靈獎得主JimGray在2003年3月發表的“Distributed ComputingEconomics”(分布式計算經濟學)一文中，率先提出這個結論:數據處理應該在離數據本身比較近的地方進行，因為這樣有利于降低成本，尤其是網絡帶寬消費所造成的成本。

意識到網絡帶寬是數據中心環境最珍貴的資源(到處復制數據很容易耗盡網絡帶寬)之后Hadoop通過顯式網絡拓撲結構來保留網絡帶寬。注意，這種排列方式并沒有降低Hadoop對計算密集型數據進行分析的能力。

雖然MPI賦予程序員很大的控制權，但需要程序員顯式處理數據流機制，包括用C語言構造底層的功能模塊(例如套接字)和高層的數據分析算法。而Hadoop則在更高層次上執行任務，即程序員僅從數據模型(如MapReduce的鍵-值對)的角度考慮任務的執行，與此同時，數據流仍然是隱性的。
在大規模分布式計算環境下，協調各個進程的執行是一個很大的挑戰。最困難的是合理處理系統的部分失效問題(在不知道一個遠程進程是否掛了的情況下)同時還需要繼續完成整個計算。
有了MapReduce這樣的分布式處理框架，程序員不必操心系統失效的問題，因為框架能夠檢測到失敗的任務并重新在正常的機器上執行。
正因為采用的是無共享(shared-nothing)框架，MapReduce才能夠呈現出這種特性，這意味著各個任務之間是彼此獨立的。
因此，從程序員的角度來看，任務的執行順序無關緊要。相比之下，MPI程序必須顯式管理自己的檢查點和恢復機制，雖然賦予程序員的控制權加大了，但編程的難度也增加了。

1.5.3 志愿計算

志愿計算項目將問題分成很多塊，每一塊稱為一個工作單元(workunit)，發到世界各地的計算機上進行分析。
例如，SETI@home的工作單元是0.35MB無線電望遠鏡數據，要對這等大小的數據量進行分析，一臺普通計算機需要幾個小時或幾天時間才能完成。完成分析后，結果發送回服務器，客戶端隨后再獲得另一個工作單元。為防止欺騙，每個工作單元要發送到3臺不同的機器上執行，而且收到的結果中至少有兩個相同才會被接受。
從表面上看，SETI@home與MapReduce好像差不多(將問題分解為獨立的小塊然后并行進行計算)，但事實上還是有很多明顯的差異。SETI@home問題是CPU高度密集的，比較適合在全球成千上萬臺計算機上運行。因為計算所花的時間遠遠超過工作單元數據的傳輸時間。也就是說，志愿者貢獻的是PU周期，而不是網絡帶寬。
MapReduce 有三大設計目標:
- (1)為只需要短短幾分鐘或幾個小時就可以完成的作業提供服務;
- (2)運行于同一個內部有高速網絡連接的數據中心內;
- (3)數據中心內的計算機都是可靠的、專門的硬件。
相比之下，SETI@home則是在接入互聯網的不可信的計算機上長時間運行，這些計算機的網絡帶寬不同，對數據本地化也沒有要求。

1.6 Apache Hadoop發展簡史

Hadoop 是 Apache Lucene 創始人道格·卡丁(Doug Cutting)創建的，Lucene 是個應用廣泛的文本搜索系統庫。
Hadoop起源于開源網絡搜索引擎Apache Nutch后者本身也是Lucene項目的一部分。

在這里插入圖片描述

Nutch項目開始于2002年，一個可以運行的網頁爬取工具和搜索引擎系統很快面世。
但后來，它的創造者認為這一架構的靈活性不夠，不足以解決數十億網頁的搜索問題。

劃重點：

一篇發表于2003年的論文為此提供了幫助，文中描述的是谷歌產品架構，該架構稱為“谷歌分布式文件系統”(GFS)。"GFS或類似的架構可以解決他們在網頁爬取和索引過程中產生的超大文件的存儲需求。
特別關鍵的是，GFS能夠節省系統管理(如管理存儲節點)所花的大量時間。
在2004年，Nutch的開發者開始著手做開源版本的實現，即Nutch分布式文件系統(NDFS)。
2004年，谷歌發表論文向全世界介紹他們的MapReduce系統。
2005年初，Nutch的開發人員在Nutch上實現了一個MapReduce 系統，到年中，Nutch的所有主要算法均完成移植，用MapReduce和NDFS來運行。
Nutch的NDFS和MapReduce實現不只適用于搜索領域。
在2006年2月，開發人員將NDFS和MapReduce移出utch形成ucene的個子項目，命名為Hadoop。
大約在同一時間，DougCutting加入雅虎，雅虎為此組織了專門的團隊和資源，將Hadoop發展成能夠以Web網絡規模運行的系統(參見隨后的補充材料)。
在2008年2月，雅虎宣布，雅虎搜索引警使用的索引是在一個擁有1萬個內核的 Hadoop 集群上構建的。
2008年1月，Hadoop已成為Apache的頂級項目，證明了它的成功、多樣化和生命力。