mapreduce是一種模式，一種什么模式呢?一種云計算的核心計算模式，一種分布式運算技術，也是簡化的分布式編程模式，它主要用于解決問題的程序開發(fā)模型，也是開發(fā)人員拆解問題的方法。
如下圖所示，mapreduce模式的主要思想是將自動分割要執(zhí)行的問題（例如程序）拆解成map（映射）和reduce（化簡）的方式，流程圖如下圖1所示：
在數(shù)據(jù)被分割后通過Map 函數(shù)的程序?qū)?shù)據(jù)映射成不同的區(qū)塊，分配給計算機機群處理達到分布式運算的效果，在通過Reduce 函數(shù)的程序?qū)⒔Y果匯整，從而輸出開發(fā)者需要的結果。
MapReduce 借鑒了函數(shù)式程序設計語言的設計思想，其軟件實現(xiàn)是指定一個Map 函數(shù)，把鍵值對(key/value)映射成新的鍵值對(key/value)，形成一系列中間結果形式的key/value 對，然后把它們傳給Reduce(規(guī)約)函數(shù)，把具有相同中間形式key 的value 合并在一起。Map 和Reduce 函數(shù)具有一定的關聯(lián)性。函數(shù)描述如表1 所示：
MapReduce致力于解決大規(guī)模數(shù)據(jù)處理的問題，因此在設計之初就考慮了數(shù)據(jù)的局部性原理，利用局部性原理將整個問題分而治之。MapReduce集 群由普通PC機構成，為無共享式架構。在處理之前，將數(shù)據(jù)集分布至各個節(jié)點。處理時，每個節(jié)點就近讀取本地存儲的數(shù)據(jù)處理（map），將處理后的數(shù)據(jù)進行 合并（combine）、排序（shuffle and sort）后再分發(fā)（至reduce節(jié)點），避免了大量數(shù)據(jù)的傳輸，提高了處理效率。無共享式架構的另一個好處是配合復制（replication）策 略，集群可以具有良好的容錯性，一部分節(jié)點的down機對集群的正常工作不會造成影響。
ok，你可以再簡單看看下副圖，整幅圖是有關hadoop的作業(yè)調(diào)優(yōu)參數(shù)及原理，圖的左邊是MapTask運行示意圖，右邊是ReduceTask運行示意圖：
如上圖所示，其中map階段，當map task開始運算，并產(chǎn)生中間數(shù)據(jù)后并非直接而簡單的寫入磁盤，它首先利用內(nèi)存buffer來對已經(jīng)產(chǎn)生的buffer進行緩存，并在內(nèi)存buffer中 進行一些預排序來優(yōu)化整個map的性能。而上圖右邊的reduce階段則經(jīng)歷了三個階段，分別Copy->Sort->reduce。我們能 明顯的看出，其中的Sort是采用的歸并排序，即merge sort。
Hadoop 是一個實現(xiàn)了MapReduce 計算模型的開源分布式并行編程框架，程序員可以借助Hadoop 編寫程序，將所編寫的程序運行于計算機機群上，從而實現(xiàn)對海量數(shù)據(jù)的處理。
此外，Hadoop 還提供一個分布式文件系統(tǒng)(HDFS）及分布式數(shù)據(jù)庫（HBase）用來將數(shù)據(jù)存儲或部署到各個計算節(jié)點上。所以，你可以大致認 為：Hadoop=HDFS（文件系統(tǒng)，數(shù)據(jù)存儲技術相關）+HBase（數(shù)據(jù)庫）+MapReduce（數(shù)據(jù)處理）。Hadoop 框架如圖2 所示：
借助Hadoop 框架及云計算核心技術MapReduce 來實現(xiàn)數(shù)據(jù)的計算和存儲，并且將HDFS 分布式文件系統(tǒng)和HBase 分布式數(shù)據(jù)庫很好的融入到云計算框架中，從而實現(xiàn)云計算的分布式、并行計算和存儲，并且得以實現(xiàn)很好的處理大規(guī)模數(shù)據(jù)的能力。
Hadoop的組成部分
我們已經(jīng)知道，Hadoop是Google的MapReduce一個Java實現(xiàn)。MapReduce是一種簡化的分布式編程模式，讓程序自動分布到一個 由普通機器組成的超大集群上并發(fā)執(zhí)行。Hadoop主要由HDFS、MapReduce和HBase等組成。具體的hadoop的組成如下圖：
由上圖，我們可以看到：
1、 Hadoop HDFS是Google GFS存儲系統(tǒng)的開源實現(xiàn)，主要應用場景是作為并行計算環(huán)境（MapReduce）的基礎組件，同時也是BigTable（如HBase、 HyperTable）的底層分布式文件系統(tǒng)。HDFS采用master/slave架構。一個HDFS集群是有由一個Namenode和一定數(shù)目的 Datanode組成。Namenode是一個中心服務器，負責管理文件系統(tǒng)的namespace和客戶端對文件的訪問。Datanode在集群中一般是 一個節(jié)點一個，負責管理節(jié)點上它們附帶的存儲。在內(nèi)部，一個文件其實分成一個或多個block，這些block存儲在Datanode集合里。如下圖所示 （HDFS體系結構圖）：
2、 Hadoop MapReduce是一個使用簡易的軟件框架，基于它寫出來的應用程序能夠運行在由上千個商用機器組成的大型集群上，并以一種可靠容錯的方式并行處理上TB級別的數(shù)據(jù)集。
一個MapReduce作業(yè)（job）通常會把輸入的數(shù)據(jù)集切分為若干獨立的數(shù)據(jù)塊，由 Map任務（task）以完全并行的方式處理它們。框架會對Map的輸出先進行排序，然后把結果輸入給Reduce任務。通常作業(yè)的輸入和輸出都會被存儲 在文件系統(tǒng)中。整個框架負責任務的調(diào)度和監(jiān)控，以及重新執(zhí)行已經(jīng)失敗的任務。如下圖所示（Hadoop MapReduce處理流程圖）：
3、 Hive是基于Hadoop的一個數(shù)據(jù)倉庫工具，處理能力強而且成本低廉。
主要特點：
存儲方式是將結構化的數(shù)據(jù)文件映射為一張數(shù)據(jù)庫表。提供類SQL語言，實現(xiàn)完整的SQL查詢功能?？梢詫QL語句轉(zhuǎn)換為MapReduce任務運行，十分適合數(shù)據(jù)倉庫的統(tǒng)計分析。
不足之處：
采用行存儲的方式（SequenceFile）來存儲和讀取數(shù)據(jù)。效率低：當要讀取數(shù)據(jù)表某一列數(shù)據(jù)時需要先取出所有數(shù)據(jù)然后再提取出某一列的數(shù)據(jù)，效率很低。同時，它還占用較多的磁盤空間。
由于以上的不足，有人（查禮博士）介紹了一種將分布式數(shù)據(jù)處理系統(tǒng)中以記錄為單位的存儲結構變?yōu)橐粤袨閱挝坏拇鎯Y構，進而減少磁盤訪問數(shù)量，提高查詢處 理性能。這樣，由于相同屬性值具有相同數(shù)據(jù)類型和相近的數(shù)據(jù)特性，以屬性值為單位進行壓縮存儲的壓縮比更高，能節(jié)省更多的存儲空間。如下圖所示（行列存儲 的比較圖）：
4、 HBase
HBase是一個分布式的、面向列的開源數(shù)據(jù)庫，它不同于一般的關系數(shù)據(jù)庫,是一個適合于非結構化數(shù)據(jù)存儲的數(shù)據(jù)庫。另一個不同的是HBase基于列的而 不是基于行的模式。HBase使用和 BigTable非常相同的數(shù)據(jù)模型。用戶存儲數(shù)據(jù)行在一個表里。一個數(shù)據(jù)行擁有一個可選擇的鍵和任意數(shù)量的列，一個或多個列組成一個 ColumnFamily，一個Fmaily下的列位于一個HFile中，易于緩存數(shù)據(jù)。表是疏松的存儲的，因此用戶可以給行定義各種不同的列。在 HBase中數(shù)據(jù)按主鍵排序，同時表按主鍵劃分為多個HRegion，如下圖所示（HBase數(shù)據(jù)表結構圖）：
如下圖所示，便是hadoop的內(nèi)部結構，我們可以看到，海量的數(shù)據(jù)交給hadoop處理后，在hadoop的內(nèi)部中，正如上文所述：hadoop提供一 個分布式文件系統(tǒng)（HDFS）及分布式數(shù)據(jù)庫（Hbase）用來存儲或部署到各個計算點上，最終在內(nèi)部采取mapreduce的模式對其數(shù)據(jù)進行處理，然 后輸出處理結果：
圖2-1 海量數(shù)據(jù)產(chǎn)品技術架構
如上圖所示，我們可以看到，海量數(shù)據(jù)產(chǎn)品技術架構，分為以下五個層次，從上至下來看，它們分別是：數(shù)據(jù)源，計算層，存儲層，查詢層和產(chǎn)品層。我們來一一了解這五層：
數(shù)據(jù)來源層。存放著交易數(shù)據(jù)。在數(shù)據(jù)源層產(chǎn)生的數(shù)據(jù)，通過DataX，DbSync和Timetunel準實時的傳輸?shù)较旅娴?點所述的“云梯”。
計算層。在這個計算層內(nèi)，采用的是hadoop集群，這個集群，我們暫且稱之為云梯，是計算層的主要組成部分。在云梯上，系統(tǒng)每天會對數(shù)據(jù)產(chǎn)品進行不同的mapreduce計算。
存儲層。在這一層，采用了兩個東西，一個使MyFox，一個是Prom。MyFox是基于MySQL的分布式關系型數(shù)據(jù)庫的集群，Prom是基于 hadoop Hbase技術 的（讀者可別忘了，在上文第一部分中，咱們介紹到了這個hadoop的組成部分之一，Hbase—在hadoop之內(nèi)的一個分布式的開源數(shù)據(jù)庫）的一個 NoSQL的存儲集群。
查詢層。在這一層中，有一個叫做glider的東西，這個glider是以HTTP協(xié)議對外提供restful方式的接口。數(shù)據(jù)產(chǎn)品通過一個唯一的URL來獲取到它想要的數(shù)據(jù)。同時，數(shù)據(jù)查詢即是通過MyFox來查詢的。下文將具體介紹MyFox的數(shù)據(jù)查詢過程。
產(chǎn)品層。簡單理解，不作過多介紹。
MyFOX
MySQL的MyISAM引擎作為底層的數(shù)據(jù)存儲引擎。且為了應對海量數(shù)據(jù)，他們設計了分布式MySQL集群的查詢代理層-MyFOX。
如下圖所示，是MySQL的數(shù)據(jù)查詢過程：
圖2-2 MyFOX的數(shù)據(jù)查詢過程
在MyFOX的每一個節(jié)點中，存放著熱節(jié)點和冷節(jié)點兩種節(jié)點數(shù)據(jù)。顧名思義，熱節(jié)點存放著最新的，被訪問頻率較高的數(shù)據(jù)；冷節(jié)點，存放著相對而來比較舊 的，訪問頻率比較低的數(shù)據(jù)。而為了存儲這兩種節(jié)點數(shù)據(jù)，出于硬件條件和存儲成本的考慮，你當然會考慮選擇兩種不同的硬盤，來存儲這兩種訪問頻率不同的節(jié)點 數(shù)據(jù)。如下圖所示：
圖2-3 MyFOX節(jié)點結構
“熱節(jié)點”，選擇每分鐘15000轉(zhuǎn)的SAS硬盤，按照一個節(jié)點兩臺機器來計算，單位數(shù)據(jù)的存儲成本約為4.5W/TB。相對應地，“冷數(shù)據(jù)”我們選擇了每分鐘7500轉(zhuǎn)的SATA硬盤，單碟上能夠存放更多的數(shù)據(jù)，存儲成本約為1.6W/TB。
Prom
出于文章篇幅的考慮，本文接下來不再過多闡述這個Prom了。如下面兩幅圖所示，他們分別表示的是Prom的存儲結構以及Prom查詢過程：
圖2-4 Prom的存儲結構
圖2-5 Prom查詢過程
glide的技術架構
圖2-6 glider的技術架構
在這一層-查詢層中，主要是基于用中間層隔離前后端的理念而考慮。Glider這個中間層負責各個異構表之間的數(shù)據(jù)JOIN和UNION等計算，并且負責隔離前端產(chǎn)品和后端存儲，提供統(tǒng)一的數(shù)據(jù)查詢服務。
緩存
除了起到隔離前后端以及異構“表”之間的數(shù)據(jù)整合的作用之外，glider的另外一個不容忽視的作用便是緩存管理。我們有一點須了解，在特定的時間段內(nèi)，我們認為數(shù)據(jù)產(chǎn)品中的數(shù)據(jù)是只讀的，這是利用緩存來提高性能的理論基礎。
在上文圖2-6中我們看到，glider中存在兩層緩存，分別是基于各個異構“表”（datasource）的二級緩存和整合之后基于獨立請求的一級緩存。除此之外，各個異構“表”內(nèi)部可能還存在自己的緩存機制。
圖2-7 緩存控制體系
圖2-7向我們展示了數(shù)據(jù)魔方在緩存控制方面的設計思路。用戶的請求中一定是帶了緩存控制的“命令”的，這包括URL中的query string，和HTTP頭中的“If-None-Match”信息。并且，這個緩存控制“命令”一定會經(jīng)過層層傳遞，最終傳遞到底層存儲的異構“表”模 塊。
緩存系統(tǒng)往往有兩個問題需要面對和考慮：緩存穿透與失效時的雪崩效應。
緩存穿透是指查詢一個一定不存在的數(shù)據(jù)，由于緩存是不命中時被動寫的，并且出于容錯考慮，如果從存儲層查不到數(shù)據(jù)則不寫入緩存，這將導致這個不存在的數(shù)據(jù) 每次請求都要到存儲層去查詢，失去了緩存的意義。至于如何有效地解決緩存穿透問題，最常見的則是采用布隆過濾器（這個東西，在我的此篇文章中有介紹：）， 將所有可能存在的數(shù)據(jù)哈希到一個足夠大的bitmap中，一個一定不存在的數(shù)據(jù)會被這個bitmap攔截掉，從而避免了對底層存儲系統(tǒng)的查詢壓力。
而在數(shù)據(jù)魔方里，用了一個更為簡單粗暴的方法，如果一個查詢返回的數(shù)據(jù)為空（不管是數(shù)據(jù)不存在，還是系統(tǒng)故障），我們?nèi)匀话堰@個空結果進行緩存，但它的過期時間會很短，最長不超過五分鐘。
2、緩存失效時的雪崩效應盡管對底層系統(tǒng)的沖擊非?？膳隆５z憾的是，這個問題目前并沒有很完美的解決方案。大多數(shù)系統(tǒng)設計者考慮用加鎖或者隊列的方式保證緩存的單線程（進程）寫，從而避免失效時大量的并發(fā)請求落到底層存儲系統(tǒng)上。
在數(shù)據(jù)魔方中，存過期機制理論上能夠?qū)⒏鱾€客戶端的數(shù)據(jù)失效時間均勻地分布在時間軸上，一定程度上能夠避免緩存同時失效帶來的雪崩效應。
聯(lián)系客服
