Hadoop的那些事儿
一臺(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)槿罩靖袷降淖兓蝗徊荒苡昧恕A硗馍厦嫣岬降?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)容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: 十分钟了解分布式计算:GraphLab
- 下一篇: Zzz读书心得:英文论文写作不求人