從Hadoop框架與MapReduce模式中談海量數據處理（含淘寶技術架構）

前言

    幾周前，當我最初聽到，以至後來初次接觸Hadoop與MapReduce這兩個東西，我便稍顯興奮，以爲它們非常神祕，而神祕的東西常能勾起個人興趣，在看過介紹它們的文章或論文以後，以爲Hadoop是一項富有趣味和挑戰性的技術，且它還牽扯到了一個我更加感興趣的話題：海量數據處理。

    由此，最近凡是空閒時，便在看「Hadoop」，「MapReduce」「海量數據處理」這方面的論文。但在看論文的過程當中，總以爲那些論文都是淺嘗輒止，經常看的很不過癮，老是一個東西剛要講到緊要處，它便結束了，讓我好生「憤懣」。

    儘管我對這個Hadoop與MapReduce知之甚淺，但我仍是想記錄本身的學習過程，說不定，關於這個東西的學習能督促我最終寫成和「經典算法研究系列」通常的一系列文章。

    Ok，閒話少說。本文從最基本的mapreduce模式，Hadoop框架開始談起，而後由各自的架構引伸開來，談到海量數據處理，最後談談淘寶的海量數據產品技術架構，覺得了兼備淺出與深刻之效，最終，但願獲得讀者的喜歡與支持。謝謝。

    因爲本人是初次接觸這兩個東西，文章有任何問題，歡迎不吝指正。Ok，我們開始吧。

第一部分、mapreduce模式與hadoop框架深刻淺出

架構扼要

         想讀懂此文，讀者必須先要明確如下幾點，以做爲閱讀後續內容的基礎知識儲備：

1. Mapreduce是一種模式。

2. Hadoop是一種框架。

3. Hadoop是一個實現了mapreduce模式的開源的分佈式並行編程框架。

    因此，你如今，知道了什麼是mapreduce，什麼是hadoop，以及這二者之間最簡單的聯繫，而本文的主旨便是，一句話歸納：在hadoop的框架上採起mapreduce的模式處理海量數據。下面，我們能夠依次深刻學習和了解mapreduce和hadoop這兩個東西了。

Mapreduce模式

    前面說了，mapreduce是一種模式，一種什麼模式呢?一種雲計算的核心計算模式，一種分佈式運算技術，也是簡化的分佈式編程模式，它主要用於解決問題的程序開發模型，也是開發人員拆解問題的方法。

    Ok，光說不上圖，沒用。以下圖所示，mapreduce模式的主要思想是將自動分割要執行的問題（例如程序）拆解成map（映射）和reduce（化簡）的方式，流程圖以下圖1所示：

    在數據被分割後經過Map 函數的程序將數據映射成不一樣的區塊，分配給計算機機羣處理達到分佈式運算的效果，在經過Reduce 函數的程序將結果彙整，從而輸出開發者須要的結果。

    MapReduce 借鑑了函數式程序設計語言的設計思想，其軟件實現是指定一個Map 函數，把鍵值對(key/value)映射成新的鍵值對(key/value)，造成一系列中間結果形式的key/value 對，而後把它們傳給Reduce(規約)函數，把具備相同中間形式key 的value 合併在一塊兒。Map 和Reduce 函數具備必定的關聯性。函數描述如表1 所示：

    MapReduce致力於解決大規模數據處理的問題，所以在設計之初就考慮了數據的局部性原理，利用局部性原理將整個問題分而治之。MapReduce集羣由普通PC機構成，爲無共享式架構。在處理以前，將數據集分佈至各個節點。處理時，每一個節點就近讀取本地存儲的數據處理（map），將處理後的數據進行合併（combine）、排序（shuffle and sort）後再分發（至reduce節點），避免了大量數據的傳輸，提升了處理效率。無共享式架構的另外一個好處是配合複製（replication）策略，集羣能夠具備良好的容錯性，一部分節點的down機對集羣的正常工做不會形成影響。

    ok，你能夠再簡單看看下副圖，整幅圖是有關hadoop的做業調優參數及原理，圖的左邊是MapTask運行示意圖，右邊是ReduceTask運行示意圖：

    如上圖所示，其中map階段，當map task開始運算，併產生中間數據後並不是直接而簡單的寫入磁盤，它首先利用內存buffer來對已經產生的buffer進行緩存，並在內存buffer中進行一些預排序來優化整個map的性能。而上圖右邊的reduce階段則經歷了三個階段，分別Copy->Sort->reduce。咱們能明顯的看出，其中的Sort是採用的歸併排序，即merge sort。

    瞭解了什麼是mapreduce，接下來，我們能夠來了解實現了mapreduce模式的開源框架—hadoop。

Hadoop框架

    前面說了，hadoop是一個框架，一個什麼樣的框架呢?Hadoop 是一個實現了MapReduce 計算模型的開源分佈式並行編程框架，程序員能夠藉助Hadoop 編寫程序，將所編寫的程序運行於計算機機羣上，從而實現對海量數據的處理。

    此外，Hadoop 還提供一個分佈式文件系統(HDFS）及分佈式數據庫（HBase）用來將數據存儲或部署到各個計算節點上。因此，你能夠大體認爲：Hadoop=HDFS（文件系統，數據存儲技術相關）+HBase（數據庫）+MapReduce（數據處理）。Hadoop 框架如圖2 所示：

    藉助Hadoop 框架及雲計算核心技術MapReduce 來實現數據的計算和存儲，而且將HDFS 分佈式文件系統和HBase 分佈式數據庫很好的融入到雲計算框架中，從而實現雲計算的分佈式、並行計算和存儲，而且得以實現很好的處理大規模數據的能力。

Hadoop的組成部分

    咱們已經知道，Hadoop是Google的MapReduce一個Java實現。MapReduce是一種簡化的分佈式編程模式，讓程序自動分佈到一個由普通機器組成的超大集羣上併發執行。Hadoop主要由HDFS、MapReduce和HBase等組成。具體的hadoop的組成以下圖：

    由上圖，咱們能夠看到：

    一、             Hadoop HDFS是Google GFS存儲系統的開源實現，主要應用場景是做爲並行計算環境（MapReduce）的基礎組件，同時也是BigTable（如HBase、HyperTable）的底層分佈式文件系統。HDFS採用master/slave架構。一個HDFS集羣是有由一個Namenode和必定數目的Datanode組成。Namenode是一箇中心服務器，負責管理文件系統的namespace和客戶端對文件的訪問。Datanode在集羣中通常是一個節點一個，負責管理節點上它們附帶的存儲。在內部，一個文件其實分紅一個或多個block，這些block存儲在Datanode集合裏。以下圖所示（HDFS體系結構圖）：

    二、             Hadoop MapReduce是一個使用簡易的軟件框架，基於它寫出來的應用程序可以運行在由上千個商用機器組成的大型集羣上，並以一種可靠容錯的方式並行處理上TB級別的數據集。

    一個MapReduce做業（job）一般會把輸入的數據集切分爲若干獨立的數據塊，由 Map任務（task）以徹底並行的方式處理它們。框架會對Map的輸出先進行排序，而後把結果輸入給Reduce任務。一般做業的輸入和輸出都會被存儲在文件系統中。整個框架負責任務的調度和監控，以及從新執行已經失敗的任務。以下圖所示（Hadoop MapReduce處理流程圖）：

    三、             Hive是基於Hadoop的一個數據倉庫工具，處理能力強並且成本低廉。

主要特色：

存儲方式是將結構化的數據文件映射爲一張數據庫表。提供類SQL語言，實現完整的SQL查詢功能。能夠將SQL語句轉換爲MapReduce任務運行，十分適合數據倉庫的統計分析。

不足之處：

採用行存儲的方式（SequenceFile）來存儲和讀取數據。效率低：當要讀取數據表某一列數據時須要先取出全部數據而後再提取出某一列的數據，效率很低。同時，它還佔用較多的磁盤空間。

因爲以上的不足，有人（查禮博士）介紹了一種將分佈式數據處理系統中以記錄爲單位的存儲結構變爲以列爲單位的存儲結構，進而減小磁盤訪問數量，提升查詢處理性能。這樣，因爲相同屬性值具備相同數據類型和相近的數據特性，以屬性值爲單位進行壓縮存儲的壓縮比更高，能節省更多的存儲空間。以下圖所示（行列存儲的比較圖）：

四、             HBase

    HBase是一個分佈式的、面向列的開源數據庫，它不一樣於通常的關係數據庫,是一個適合於非結構化數據存儲的數據庫。另外一個不一樣的是HBase基於列的而不是基於行的模式。HBase使用和 BigTable很是相同的數據模型。用戶存儲數據行在一個表裏。一個數據行擁有一個可選擇的鍵和任意數量的列，一個或多個列組成一個ColumnFamily，一個Fmaily下的列位於一個HFile中，易於緩存數據。表是疏鬆的存儲的，所以用戶能夠給行定義各類不一樣的列。在HBase中數據按主鍵排序，同時表按主鍵劃分爲多個HRegion，以下圖所示（HBase數據表結構圖）：

    Ok，行文至此，看似洋洋灑灑近千里，但若給讀者形成閱讀上的負擔，則不是我本意。接下來的內容，我不會再引用諸多繁雜的專業術語，以給讀者內心上形成不良影響。

    我再給出一副圖，算是對上文所說的hadoop框架及其組成部分作個總結，以下圖所示，即是hadoop的內部結構，咱們能夠看到，海量的數據交給hadoop處理後，在hadoop的內部中，正如上文所述：hadoop提供一個分佈式文件系統（HDFS）及分佈式數據庫（Hbase）用來存儲或部署到各個計算點上，最終在內部採起mapreduce的模式對其數據進行處理，而後輸出處理結果：

第二部分、淘寶海量數據產品技術架構解讀—學習海量數據處理經驗

    在上面的本文的第一部分中，咱們已經對mapreduce模式及hadoop框架有了一個深刻而全面的瞭解。不過，若是一個東西，或者一個概念不放到實際應用中去，那麼你對這個理念永遠只是停留在理論以內，沒法向實踐邁進。

    Ok，接下來，本文的第二部分，我們以淘寶的數據魔方技術架構爲依託，經過介紹淘寶的海量數據產品技術架構，來進一步學習和了解海量數據處理的經驗。

淘寶海量數據產品技術架構

    以下圖2-1所示，便是淘寶的海量數據產品技術架構，我們下面要針對這個架構來一一剖析與解讀。

    相信，看過本博客內其它文章的細心讀者，定會發現，圖2-1最初見於本博客內的此篇文章：從幾幅架構圖中偷得半點海量數據處理經驗之上，同時，此圖2-1最初發表於《程序員》8月刊，做者：朋春。

    在此以前，有一點必須說明的是：本文下面的內容大都是參考自朋春先生的這篇文章：淘寶數據魔方技術架構解析所寫，我我的所做的工做是對這篇文章的一種解讀與關鍵技術和內容的抽取，覺得讀者更好的理解淘寶的海量數據產品技術架構。與此同時，還能展現我本身讀此篇的思路與感悟，順帶學習，何樂而不爲呢?。

    Ok，不過，與本博客內以前的那篇文章（幾幅架構圖中偷得半點海量數據處理經驗）不一樣，本文接下來，要詳細闡述這個架構。我也作了很多準備工做（如把這圖2-1打印了下來，常常琢磨）：

 

                                              圖2-1 淘寶海量數據產品技術架構

    好的，如上圖所示，咱們能夠看到，淘寶的海量數據產品技術架構，分爲如下五個層次，從上至下來看，它們分別是：數據源，計算層，存儲層，查詢層和產品層。咱們來一一瞭解這五層：

1. 數據來源層。存放着淘寶各店的交易數據。在數據源層產生的數據，經過DataX，DbSync和Timetunel準實時的傳輸到下面第2點所述的「雲梯」。

2. 計算層。在這個計算層內，淘寶採用的是hadoop集羣，這個集羣，咱們暫且稱之爲雲梯，是計算層的主要組成部分。在雲梯上，系統天天會對數據產品進行不一樣的mapreduce計算。

3. 存儲層。在這一層，淘寶採用了兩個東西，一個使MyFox，一個是Prom。MyFox是基於MySQL的分佈式關係型數據庫的集羣，Prom是基於hadoop Hbase技術 的（讀者可別忘了，在上文第一部分中，我們介紹到了這個hadoop的組成部分之一，Hbase—在hadoop以內的一個分佈式的開源數據庫）的一個NoSQL的存儲集羣。

4. 查詢層。在這一層中，有一個叫作glider的東西，這個glider是以HTTP協議對外提供restful方式的接口。數據產品經過一個惟一的URL來獲取到它想要的數據。同時，數據查詢便是經過MyFox來查詢的。下文將具體介紹MyFox的數據查詢過程。

5.  產品層。簡單理解，不做過多介紹。

    接下來，我們重點來了解第三層-存儲層中的MyFox與Prom，而後會稍帶分析下glide的技術架構，最後，再瞭解下緩存。文章即宣告結束。

    咱們知道，關係型數據庫在咱們如今的工業生產中有着普遍的引用，它包括Oracle，MySQL、DB二、Sybase和SQL Server等等。

MyFOX

    淘寶選擇了MySQL的MyISAM引擎做爲底層的數據存儲引擎。且爲了應對海量數據，他們設計了分佈式MySQL集羣的查詢代理層-MyFOX。

以下圖所示，是MySQL的數據查詢過程：

                                                            圖2-2 MyFOX的數據查詢過程

    在MyFOX的每個節點中，存放着熱節點和冷節點兩種節點數據。顧名思義，熱節點存放着最新的，被訪問頻率較高的數據；冷節點，存放着相對而來比較舊的，訪問頻率比較低的數據。而爲了存儲這兩種節點數據，出於硬件條件和存儲成本的考慮，你固然會考慮選擇兩種不一樣的硬盤，來存儲這兩種訪問頻率不一樣的節點數據。以下圖所示：

                                                           圖2-3 MyFOX節點結構

     「熱節點」，選擇每分鐘15000轉的SAS硬盤，按照一個節點兩臺機器來計算，單位數據的存儲成本約爲4.5W/TB。相對應地，「冷數據」咱們選擇了每分鐘7500轉的SATA硬盤，單碟上可以存放更多的數據，存儲成本約爲1.6W/TB。

Prom

出於文章篇幅的考慮，本文接下來再也不過多闡述這個Prom了。以下面兩幅圖所示，他們分別表示的是Prom的存儲結構以及Prom查詢過程：

                                              圖2-4 Prom的存儲結構

 

                                                          圖2-5 Prom查詢過程

glide的技術架構

    

                                               圖2-6 glider的技術架構

    在這一層-查詢層中，淘寶主要是基於用中間層隔離先後端的理念而考慮。Glider這個中間層負責各個異構表之間的數據JOIN和UNION等計算，而且負責隔離前端產品和後端存儲，提供統一的數據查詢服務。

緩存

    除了起到隔離先後端以及異構「表」之間的數據整合的做用以外，glider的另一個不容忽視的做用即是緩存管理。咱們有一點須瞭解，在特定的時間段內，咱們認爲數據產品中的數據是隻讀的，這是利用緩存來提升性能的理論基礎。

在上文圖2-6中咱們看到，glider中存在兩層緩存，分別是基於各個異構「表」（datasource）的二級緩存和整合以後基於獨立請求的一級緩存。除此以外，各個異構「表」內部可能還存在本身的緩存機制。

                                                           圖2-7 緩存控制體系

    圖2-7向咱們展現了數據魔方在緩存控制方面的設計思路。用戶的請求中必定是帶了緩存控制的「命令」的，這包括URL中的query string，和HTTP頭中的「If-None-Match」信息。而且，這個緩存控制「命令」必定會通過層層傳遞，最終傳遞到底層存儲的異構「表」模塊。

    緩存系統每每有兩個問題須要面對和考慮：緩存穿透與失效時的雪崩效應。

1. 緩存穿透是指查詢一個必定不存在的數據，因爲緩存是不命中時被動寫的，而且出於容錯考慮，若是從存儲層查不到數據則不寫入緩存，這將致使這個不存在的數據每次請求都要到存儲層去查詢，失去了緩存的意義。至於如何有效地解決緩存穿透問題，最多見的則是採用布隆過濾器（這個東西，在個人此篇文章中有介紹：），將全部可能存在的數據哈希到一個足夠大的bitmap中，一個必定不存在的數據會被這個bitmap攔截掉，從而避免了對底層存儲系統的查詢壓力。

    而在數據魔方里，淘寶採用了一個更爲簡單粗暴的方法，若是一個查詢返回的數據爲空（無論是數據不存在，仍是系統故障），咱們仍然把這個空結果進行緩存，但它的過時時間會很短，最長不超過五分鐘。

      二、緩存失效時的雪崩效應儘管對底層系統的衝擊很是可怕。但遺憾的是，這個問題目前並無很完美的解決方案。大多數系統設計者考慮用加鎖或者隊列的方式保證緩存的單線程（進程）寫，從而避免失效時大量的併發請求落到底層存儲系統上。

    在數據魔方中，淘寶設計的緩存過時機制理論上可以將各個客戶端的數據失效時間均勻地分佈在時間軸上，必定程度上可以避免緩存同時失效帶來的雪崩效應。

本文參考：

1. 基於雲計算的海量數據存儲模型，侯建等。

2. 基於hadoop的海量日誌數據處理，王小森

3. 基於hadoop的大規模數據處理系統，王麗兵。

4. 淘寶數據魔方技術架構解析，朋春。

5. Hadoop做業調優參數整理及原理，guili。

讀者點評@xdylxdyl：

1. We want to count all the books in the library. You count up shelf #1, I count up shelf #2. That's map. The more people we get, the faster it goes. Now we get together and add our individual counts. That's reduce。

2. 數據魔方里的緩存穿透,架構,空數據緩存這些和Hadoop一點關係都麼有，若是是想講一個Hadoop的具體應用的話,數據魔方這部分其實沒講清楚的。

3. 感受你是把兩個東西混在一塊兒了。不過這兩個都是挺有價值的東西,或者說數據魔方的架構比Hadoop可能更重要一些,基本上大的互聯網公司都會選擇這麼作。Null對象的緩存保留五分鐘未必會有好的結果吧,若是Null對象不是特別大,數據的更新和插入很少也能夠考慮實時維護。

4. Hadoop自己很笨重，不知道在數據魔方里是不是在扮演着實時數據處理的角色?仍是隻是在作線下的數據分析的？

結語：寫文章是一種學習的過程。尊重他人勞動成果，轉載請註明出處。謝謝。July、2011/8/20。完。