一臺(tái)單機(jī)在存儲(chǔ)容量、并發(fā)性上毫無疑問都是有很大限制的。為了解決單機(jī)無法完成的大存儲(chǔ)(>1TB)和大規(guī)模計(jì)算，分布式系統(tǒng)就應(yīng)運(yùn)而生了。

MapReduce

---

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

MapReduce的編程模型：

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

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

其框架實(shí)現(xiàn)是由一個(gè)單獨(dú)運(yùn)行在主節(jié)點(diǎn)上的JobTracker和運(yùn)行在每個(gè)集群從屬節(jié)點(diǎn)上的TaskTracker共同組成。主節(jié)點(diǎn)負(fù)責(zé)調(diào)度構(gòu)成一個(gè)個(gè)作業(yè)，這些作業(yè)分布運(yùn)行在從屬節(jié)點(diǎn)上，主節(jié)點(diǎn)監(jiān)控它們的執(zhí)行情況并管理失敗的作業(yè)重新執(zhí)行。

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

• 采用了函數(shù)式編程語言的map和reduce兩個(gè)函數(shù)
• 解決那些數(shù)據(jù)可以切割進(jìn)行計(jì)算的應(yīng)用，比如grep操作，求和計(jì)算
• 提供了運(yùn)行平臺(tái)，自動(dòng)處理出錯(cuò)

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

Google MapReduce/GFS/BigTable三大技術(shù)的論文中譯版

?

Hadoop

---

Hadoop是偉大的Apache基金會(huì)實(shí)現(xiàn)的一套分布式系統(tǒng)，是采用Java開發(fā)的開源MapReduce框架實(shí)現(xiàn)。Hadoop包括分布式文件系統(tǒng)（HDFS）、MapReduce計(jì)算框架、HBase等很多組件——這些基本都是Google的GFS/MapReduce/BigTable的克隆產(chǎn)品。

Hadoop經(jīng)過數(shù)年的發(fā)展，目前已經(jīng)很成熟了，尤其是其中的HDFS和MapReduce計(jì)算框架組件。數(shù)百臺(tái)機(jī)器的集群已經(jīng)被證明可以使用(Yahoo!的最大hadoop集群部署為4000個(gè)計(jì)算節(jié)點(diǎn))，可以承擔(dān)PB級(jí)別的數(shù)據(jù)：

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

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

?

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

• 說它復(fù)雜，是因?yàn)橐粋€(gè)hadoop集群往往有幾十臺(tái)甚至成百上千臺(tái)low cost的計(jì)算機(jī)組成，你運(yùn)行的每一個(gè)任務(wù)都要在這些計(jì)算機(jī)上做任務(wù)的分發(fā)，執(zhí)行中間數(shù)據(jù)排序以及最后的匯總，期間還包含節(jié)點(diǎn)發(fā)現(xiàn)，任務(wù)的重試，故障節(jié)點(diǎn)替換等等等等的維護(hù)以及異常情況處理。誰叫hadoop集群往往都是由一些平民計(jì)算機(jī)組成，沒事兒罷個(gè)工什么的，實(shí)在是再尋常不過的事情。
• 而說其簡單，則是因?yàn)?#xff0c;上面說到的那些，你通通不用管，你所需要做的，就是寫一個(gè)程序，當(dāng)然也可以是腳本，從標(biāo)準(zhǔn)輸入讀入一條數(shù)據(jù)，處理完之后，把結(jié)果輸出到標(biāo)準(zhǔn)輸出。

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

下面這個(gè)圖就是map和reduce處理的圖示。

上圖是MapReduce的數(shù)據(jù)處理視圖。分為map，shuffle，reduce三個(gè)部分。各map任務(wù)讀入切分后的大規(guī)模數(shù)據(jù)進(jìn)行處理并將數(shù)據(jù)作為一系列key:value對(duì)輸出，輸出的中間數(shù)據(jù)按照定義的方式通過shuffle程序分發(fā)到相應(yīng)的reduce任務(wù)。Shuffle程序還會(huì)按照定義的方式對(duì)發(fā)送到一個(gè)reduce任務(wù)的數(shù)據(jù)進(jìn)行排序。Reduce進(jìn)行最后的數(shù)據(jù)處理。

?

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

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

HBase

---

Hadoop項(xiàng)目中的HBase（分布式索引系統(tǒng), 類Google的BigTable）是一個(gè)按列存儲(chǔ)的NoSQL分布式數(shù)據(jù)庫。該技術(shù)來源于Google的BigTable（一個(gè)結(jié)構(gòu)化數(shù)據(jù)的分布式存儲(chǔ)系統(tǒng)）。HBase在Hadoop基礎(chǔ)上提供了類似BigTable的分布式存儲(chǔ)能力。

HBase是一個(gè)適合于存儲(chǔ)非結(jié)構(gòu)化數(shù)據(jù)的數(shù)據(jù)庫，因?yàn)樗腔?strong>列存儲(chǔ)而不是行存儲(chǔ)，用戶將數(shù)據(jù)存儲(chǔ)在稀松的表里，每一行數(shù)據(jù)都可以擁有可選擇的鍵和任意數(shù)量的列。HBase主要用于需要隨機(jī)訪問實(shí)時(shí)讀寫大數(shù)據(jù)的應(yīng)用。

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

---

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

MapReduce是一種分布式編程模型，并不難學(xué)習(xí)，但是很顯然使用它來處理日志的代價(jià)依然遠(yuǎn)大于單機(jī)腳本或者SQL。一個(gè)簡單的詞頻統(tǒng)計(jì)計(jì)算可能都需要上百代碼——SQL只需要一行，另外還有復(fù)雜的環(huán)境準(zhǔn)備和啟動(dòng)腳本。Hadoop的實(shí)現(xiàn)就要復(fù)雜的多，通常需要兩輪MapReduce來完成。

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

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

?

Hive(Facebook)

---

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

總是可以去做進(jìn)一步的抽象，在特定的應(yīng)用下讓事情變得更簡單：

也許有人會(huì)很自然的想到如果能用SQL來操作Hadoop上的數(shù)據(jù)該有多好。

事實(shí)上，不僅僅只有你一個(gè)人會(huì)這么想，很多人都這么想，并且他們實(shí)現(xiàn)了這個(gè)想法，于是就有了Hive。

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

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

當(dāng)然Hive并不是完全的兼容SQL語法，而且也不能做到完全的對(duì)用戶屏蔽細(xì)節(jié)。很多時(shí)候?yàn)榱藞?zhí)行性能的優(yōu)化，依然需要用戶去了解一些MapReduce的基本知識(shí)，根據(jù)自己的應(yīng)用模式來設(shè)置一些參數(shù)，否則我們可能會(huì)發(fā)現(xiàn)一個(gè)查詢執(zhí)行很慢，或者壓根執(zhí)行不出來。

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

?

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

例如時(shí)間久了，可能會(huì)有越來越多的需要例行執(zhí)行的SQL，而這些SQL中，

• 也許有一些是做了重復(fù)的事情；
• 也許有一些的執(zhí)行效率非常低下，一個(gè)復(fù)雜的SQL就占滿了所有的計(jì)算資源。

這樣的系統(tǒng)會(huì)變得越來越難以維護(hù)的，直到有一天例行的SQL終于跑不完了。而最終用戶往往不會(huì)去關(guān)心這些事情，他們只關(guān)心自己提交的查詢是不是能即時(shí)得到響應(yīng)，怎么樣才能盡快的拿到結(jié)果。

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

為了系統(tǒng)化的解決這些問題，

• 我們可能需要引入例行任務(wù)的調(diào)度機(jī)制，
• 可能需要去分析所有的SQL來發(fā)現(xiàn)哪些是可以合并的、哪些的性能需要優(yōu)化，
• 使用的數(shù)據(jù)表是不是需要做水平或者垂直分表等等。
• 根據(jù)實(shí)際情況的不同，這時(shí)事情可能是人工來完成，也可能是寫程序來自動(dòng)分析并調(diào)整。

再者隨著日志類型、分析需求的不斷增長。用戶會(huì)越來越多的抱怨很難找到想要的數(shù)據(jù)在哪份日志里，或者跑的好好的查詢因?yàn)槿罩靖袷降淖兓蝗徊荒苡昧恕Ａ硗馍厦嫣岬降?strong>ETL過程也會(huì)變得復(fù)雜，簡單的轉(zhuǎn)換導(dǎo)入腳本很可能已經(jīng)解決不了問題。這時(shí)候可能需要構(gòu)建一個(gè)數(shù)據(jù)管理系統(tǒng)，或者干脆考慮建立一個(gè)所謂的數(shù)據(jù)倉庫。

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

?

ZooKeeper

---

?

?

日志分析方法概述

使用hadoop進(jìn)行大規(guī)模數(shù)據(jù)的全局排序

Zookeeper工作原理

框計(jì)算垂直搜索之索引篇

?

HDFS

---

HDFS是基于Java實(shí)現(xiàn)的可以部署在廉價(jià)的硬件上的，具有高吞吐率和高容錯(cuò)性的一套開源系統(tǒng)。由于HDFS放寬了POSIX的部分約束規(guī)范，使得它能以流形式訪問文件系統(tǒng)中的數(shù)據(jù)。

• 分布式存儲(chǔ)?
  文件被分成256MB的block?
  block被分配到各個(gè)存儲(chǔ)節(jié)點(diǎn)上
• 容錯(cuò)性?
  每個(gè)block有多個(gè)replica(副本)?
  Re-Replication
• 負(fù)載均衡?
  Re-Balance

整個(gè)HDFS系統(tǒng)設(shè)計(jì)了兩套自己的協(xié)議，都是基于TCP/IP協(xié)議之上設(shè)計(jì)的：Client Protocol和DataNode Protocol。

• Client Protocol負(fù)責(zé)客戶端與文件系統(tǒng)的通信，
• 而文件系統(tǒng)內(nèi)部各個(gè)節(jié)點(diǎn)之間通過DataNode Protocol協(xié)議來實(shí)現(xiàn)內(nèi)部的通信和文件和管理。

?

這是一張任何介紹hdfs的文章都會(huì)出現(xiàn)的架構(gòu)圖。

HDFS采用了主從(Master/Slave)結(jié)構(gòu)模型，一個(gè)HDFS由一個(gè)NameNode和若干個(gè)DataNode組成。其中NameNode作為主服務(wù)器，管理文件系統(tǒng)的命名空間和客戶端的連接。集群中的DataNode則管理各自存儲(chǔ)的數(shù)據(jù)。

NameNode（以下簡稱nn）是master，主要負(fù)責(zé)管理hdfs文件系統(tǒng)和client對(duì)文件的訪問，具體地包括

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

DataNode(簡稱dn)主要是用來存儲(chǔ)數(shù)據(jù)文件，

• hdfs將一個(gè)文件分割成一個(gè)個(gè)的block，這些block可能存儲(chǔ)在一個(gè)DataNode上或者是多個(gè)DataNode上。
• 通常一個(gè)機(jī)器節(jié)點(diǎn)一個(gè)DataNode，管理這個(gè)節(jié)點(diǎn)上的存儲(chǔ)。
• DataNode負(fù)責(zé)為文件系統(tǒng)的客戶提供讀/寫操作服務(wù)。DataNode同時(shí)還為NameNode提供block創(chuàng)建，刪除，備份機(jī)制
• dn負(fù)責(zé)實(shí)際的底層的文件的讀寫，如果客戶端client程序發(fā)起了讀hdfs上的文件的命令，那么首先將這些文件分成block，
• 然后nn將告知client這些block數(shù)據(jù)是存儲(chǔ)在那些dn上的，之后，client將直接和dn交互。

體系結(jié)構(gòu)中還有個(gè)節(jié)點(diǎn)沒畫出來，Secondary NameNode，

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

---

不管是client還是dn的消息發(fā)到nn后最終都會(huì)落到FSNamesystem身上，這是一個(gè)重量級(jí)家伙，如圖，對(duì)各種服務(wù)請求的處理都轉(zhuǎn)交給它完成，它提供了對(duì)各種數(shù)據(jù)結(jié)構(gòu)操作的接口，這些數(shù)據(jù)結(jié)構(gòu)共同維護(hù)了整個(gè)namenode的元數(shù)據(jù)信息。

x`

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

?

MapReduce

---

?

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

Master-JobTracker?
–作業(yè)與任務(wù)調(diào)度?
–負(fù)責(zé)將中間文件信息通知給reducer所在的worker?
–Master周期性檢查Worker的存活?
Worker-TaskTracker?
–TaskTracker空閑, 向Master要任務(wù)?
–執(zhí)行mapper或者reducer任務(wù)

除了作業(yè)任務(wù)調(diào)度，這個(gè)框架還要做以下處理?
–錯(cuò)誤處理，失敗任務(wù)自動(dòng)重算?
–防止慢作業(yè)，任務(wù)的預(yù)測執(zhí)行

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

下一代MapReduce資源調(diào)度與計(jì)算模型分離

?

Streaming

---

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

?

?

Message-Passing Interface (MPI)

---

MPI是一種消息傳遞編程模型，并成為該編程模型的代表和事實(shí)標(biāo)準(zhǔn)。

• MPI是一個(gè)庫，而不是一門語言，MPI庫可以被FORTRAN/C/C++/Python/java調(diào)用，把這些串行語言擴(kuò)展為并行語言。
• MPI擁有多種開源實(shí)現(xiàn)：Mpich, lammpi, openmpi。
• MPI能用于大多數(shù)并行計(jì)算機(jī)、機(jī)群系統(tǒng)和異構(gòu)網(wǎng)絡(luò)環(huán)境，能達(dá)到較高的數(shù)據(jù)傳輸速率。一個(gè)正確的MPI程序，可以不加修改地在所有的并行計(jì)算機(jī)上運(yùn)行。
• 開發(fā)成本高，無容錯(cuò)

---

?

HDFS

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

數(shù)據(jù)可靠性--HDFS塊復(fù)制改進(jìn)

?

MapReduce

調(diào)度--Job Queue：多隊(duì)列 借用 搶占（資源調(diào)度）

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

作業(yè)斷點(diǎn)重啟--作業(yè)失敗后可以接著上次的進(jìn)度運(yùn)行，集群重啟后運(yùn)行的作業(yè)重啟前的進(jìn)度運(yùn)行

Shuffle獨(dú)立--提高shuffle的總吞吐 減少資源浪費(fèi)

?

同一個(gè)reduce不同類型的數(shù)據(jù)輸出到不同文件

多路輸出 == 多路合并？

?

傳統(tǒng)數(shù)據(jù)庫的瓶頸

---

傳統(tǒng)的基于RDBMS的存儲(chǔ)和計(jì)算存在著擴(kuò)展差和容錯(cuò)差的兩大瓶頸。

關(guān)于分布式數(shù)據(jù)庫的現(xiàn)實(shí)

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

比較SQL數(shù)據(jù)庫和Hadoop

1 用向外擴(kuò)展代替向上擴(kuò)展（服務(wù)器集群）

2 用key/value對(duì)代替關(guān)系表（文本、圖片、xml文件）

3 用函數(shù)式編程（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

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

總結(jié)

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。