国产一级a片免费看高清,亚洲熟女中文字幕在线视频,黄三级高清在线播放,免费黄色视频在线看

【MapR初探】
EMC中國研究院 向東

【1. 天上掉下個(gè)MapR】

MapR成立于2009年，但是引起媒體廣泛關(guān)注是緣由GIGAOM網(wǎng)站2011年3月的一篇報(bào)道《MapR，Cloudera的新對(duì)手》（http://gigaom.com/cloud/meet-mapr-a-competitor-to-hadoop-leader-cloudera/ ），報(bào)道這么描述MapR：
“構(gòu)建一個(gè)HDFS的私有替代品，這個(gè)替代品比當(dāng)前的開源版本快三倍，自帶快照功能，而且支持無Namenode單點(diǎn)故障（SPOF），并且在API上和兼容，所以可以考慮將其作為替代方案。”
這篇報(bào)道隨即被InfoQ引用 （http://www.infoq.com/cn/news/2011/03/structure_big_data  ），鑒于InfoQ的巨大影響力，一時(shí)間，Hadoop技術(shù)圈內(nèi)，人人都在談?wù)揗apR以及其提供的神奇功能，但是，那個(gè)時(shí)候，MapR網(wǎng)站的主頁上對(duì)一切只字不提，只有大大的敬請(qǐng)期待字樣。
到了5月，確切的說，是5月25號(hào)，另一個(gè)爆炸性的新聞被披露了。這天，EMC World 2011上，EMC宣布，將在自己推出的Greenplum HD企業(yè)版Hadoop中采用MapR的技術(shù)。一時(shí)間，MapR處于全球技術(shù)媒體的聚光燈下，人們不禁要問，MapR到底提供了什么，為什么會(huì)被EMC選中作為合作伙伴呢？

GreenPlum HD，會(huì)跳舞的大象

【2. Hadoop的阿喀琉斯之踵】
Hadoop，大數(shù)據(jù)處理的寵兒，現(xiàn)今IT媒體聚光燈的焦點(diǎn)，如同希臘神話中的勇士阿喀琉斯一樣，有著傳奇的出身：Hadoop的主要設(shè)計(jì)思想，來自兩篇著名的Google論文：《MapReduce: Simplified Data Processing on Large Clusters》http://labs.google.com/papers/mapreduce.html  和 《The Google File System》http://labs.google.com/papers/gfs.html 。Map-Reduce和GFS可以說是Google搜索引擎的基石，在Google內(nèi)部被廣泛使用，是支撐其每天億萬次搜索的最重要的組成部分，而這兩篇論文詳細(xì)討論了Map-Reduce以及GFS背后的理論依據(jù)，設(shè)計(jì)權(quán)衡以及工程實(shí)踐?？傊?，Hadoop的架構(gòu)實(shí)際上是有Google來背書的。 另一方面，Hadoop的實(shí)現(xiàn)也不含糊：互聯(lián)網(wǎng)巨人Yahoo敏銳的發(fā)現(xiàn)了Hadoop項(xiàng)目的巨大潛力，把Doug Cutting （http://en.wikipedia.org/wiki/Doug_Cutting ）吸收為自己的全職員工，并成立了的一個(gè)專門的小組來進(jìn)行Hadoop的開發(fā)工作。 現(xiàn)今，作為一個(gè)Open Source 項(xiàng)目,  來自全球各地的contributor 正在不停的完善Hadoop，使其變得更加完美。

Hadoop有兩個(gè)主要的子系統(tǒng)，Hadoop 分布式文件系統(tǒng)HDFS和Hadoop Map/Reduce。HDFS是Hadoop的分布式存儲(chǔ)子系統(tǒng)，用戶的數(shù)據(jù)文件，會(huì)被切分成64M大小的block（block的大小是可調(diào)的，64M是Google在實(shí)踐中總結(jié)出來的一個(gè)優(yōu)選參數(shù)），經(jīng)過Namenode協(xié)調(diào)，存放在不同的DataNode上。對(duì)于任何一個(gè)HDFS文件，Namenode會(huì)在內(nèi)存中維護(hù)兩種meta data：1） HDFS文件和block的對(duì)應(yīng)關(guān)系 ，2）block在data node上存放的位置。Namenode會(huì)在磁盤上保存第一種meta data （通過checkpoint 文件和write ahead log），第二種meta data則是DataNode通過block report 定時(shí)發(fā)送給NameNode。
上述構(gòu)架簡潔優(yōu)雅，而且Google在工程實(shí)踐中也證明了這個(gè)構(gòu)架的可用性和可靠性。但是隨著Hadoop被廣泛應(yīng)用，面對(duì)各種不同的需求，人們也漸漸的發(fā)現(xiàn)了Hadoop的阿喀琉斯之踵?？偨Y(jié)下來，主要有以下3大方面：
1) 性能。 一系列測(cè)試（比如論文 《A Comparison of Approaches to Large-Scale Data Analysis》 ，http://database.cs.brown.edu/projects/mapreduce-vs-dbms/  ）發(fā)現(xiàn)，Hadoop在性能上可以提高的空間，尤其是和硬件的理論性能比較，還很多。造成這個(gè)的原因主要有：在當(dāng)前Hadoop的設(shè)計(jì)中，所有的meta data操作都要通過集中式的Namenode來進(jìn)行，Namenode有可能是性能的瓶頸；M/R 應(yīng)用程序需要通過DataNode來訪問HDFS, 這就涉及到格外的進(jìn)程切換和網(wǎng)絡(luò)傳輸開銷（請(qǐng)參閱著名的HDFS-347，https://issues.apache.org/jira/browse/HDFS-347，題外話，通讀關(guān)于這個(gè)issue的討論絕對(duì)會(huì)讓你受益匪淺）；還有在M/R 應(yīng)用程序端的開銷也有值得改進(jìn)的地方（http://developer.yahoo.com/blogs/hadoop/posts/2009/08/the_anatomy_of_hadoop_io_pipel/ ）。

2) 可擴(kuò)展性和可靠性。當(dāng)前Hadoop單一Namenode，單一Jobtracker的設(shè)計(jì)嚴(yán)重制約了整個(gè)Hadoop 可擴(kuò)展性和可靠性。首先，Namenode和Jobtracker是整個(gè)系統(tǒng)中明顯的單點(diǎn)故障源（SPOF）。再次單一Namenode的內(nèi)存容量有限，使得Hadoop集群的節(jié)點(diǎn)數(shù)量被限制到2000個(gè)左右，能支持的文件系統(tǒng)大小被限制在10-50PB, 最多能支持的文件數(shù)量大約為1.5億 左右（注，實(shí)際數(shù)量取決于Namenode的內(nèi)存大?。?。又，在集中式的Namenode造成DataNode的blocks report也會(huì)對(duì)Namenode的性能造成嚴(yán)重的影響。例如系統(tǒng)有1800個(gè)Datanode, 每個(gè)Datanode有3T存儲(chǔ)，整個(gè)集群大約有1.8P有效存儲(chǔ)（1800*3T/3，假設(shè)每個(gè)數(shù)據(jù)塊有3份replica）。那么每個(gè)Datanode上有大約50000個(gè)左右的block （假設(shè)block 大小是64M，然后有的block并沒有達(dá)到64M大?。僭O(shè)Datanode每小時(shí)會(huì)發(fā)送一次block report， 那么Namenode每兩秒會(huì)收到一次block report，每個(gè)block report包含50000條數(shù)據(jù)，處理這些數(shù)據(jù)無疑會(huì)占用相當(dāng)資源。實(shí)際上，有用戶抱怨其集群的Namenode重啟需要數(shù)小時(shí)，這大大降低了系統(tǒng)的可用性 （HDFS-273， https://issues.apache.org/jira/browse/HDFS-273 ）

3) 各種企業(yè)特性。隨著Hadoop被廣泛使用，面對(duì)各式各樣的需求，人們期望Hadoop能提供更多特性，比如完全可讀寫的文件系統(tǒng)，snapshot，mirror等等。這些都是當(dāng)前版本的Hadoop不支持，但是用戶又有強(qiáng)烈需求的。
Hadoop的這些缺點(diǎn)也帶來了巨大的機(jī)會(huì)，Cloudera的目光最為敏銳，最早看到這一點(diǎn)。Cloudera的商業(yè)模式和一般Open Source創(chuàng)業(yè)公司無異：網(wǎng)羅Hadoop的contributor，積極的回饋Hadoop社區(qū)，在此基礎(chǔ)上發(fā)布自己的Hadoop發(fā)行版CDH（Cloudera's Distribution including Apache Hadoop），提供各種增值服務(wù)。實(shí)際上，CDH版Hadoop具有相當(dāng)高的知名度。
MapR則認(rèn)為，Hadoop的這些缺陷來自于其架構(gòu)設(shè)計(jì)本身，小修小補(bǔ)不能解決問題。他們選擇了一條艱難得多的路：用新架構(gòu)重寫HDFS，同時(shí)在API級(jí)別，和目前的Hadoop 發(fā)行版保持兼容。這家2009年成立的創(chuàng)業(yè)公司，在蟄伏了兩年之后，終于一鳴驚人，大放異彩。回顧前面GIGAOM的報(bào)道： 
“構(gòu)建一個(gè)HDFS的私有替代品，這個(gè)替代品比當(dāng)前的開源版本快三倍，自帶快照功能，而且支持無Namenode單點(diǎn)故障（SPOF），并且在API上和兼容，所以可以考慮將其作為替代方案。”
MapR真的做到了。

【3. MapR架構(gòu)初探】
2011年6月，在Hadoop 2011峰會(huì)上，MapR的創(chuàng)始人M.C. Srivas做了名為《Design, Scale and Performance of MapR's Distribution for Hadoop》的演講（http://www.mapr.com/blog/2011/07/the-design-scale-and-performance-of-maprs-distribution-for-apache-hadoop.html ），比較詳細(xì)的介紹了MapR設(shè)計(jì)原則，部分實(shí)現(xiàn)細(xì)節(jié)以及MapR的性能，外界也第一次從內(nèi)部了解MapR Hadoop。演講的錄像和PPT隨后被公布在Youtube和Slideshare（http://www.slideshare.net/mcsrivas/design-scale-and-performance-of-maprs-distribution-for-hadoop ）,  廣大無緣參加Hadoop峰會(huì)的開發(fā)人員也得以有機(jī)會(huì)來進(jìn)行研究。
MapR認(rèn)為，解決Hadoop的種種問題，要采用以下設(shè)計(jì)思想：
1） 集中式的meta server可擴(kuò)展性不好，對(duì)應(yīng)的解決方案就是使用分布式的meta server，讓每個(gè)節(jié)點(diǎn)都變成meta server。 但是這里要解決的問題是meta server不能占用太多內(nèi)存，要留出足夠的內(nèi)存供M/R 應(yīng)用來使用。
2） 要讓每個(gè)Datanode上支持的block數(shù)量增加，同時(shí)減少block-report的大小。
3） 因?yàn)閮?nèi)存容量總是有限的，所以要減小查找服務(wù)的內(nèi)存開銷。
4） 服務(wù)能夠快速重啟（這樣可以更好的實(shí)現(xiàn)HA）。
通過上述方式，MapR期望這種設(shè)計(jì)能極大的提高Hadoop的擴(kuò)展能力，比如支持的節(jié)點(diǎn)數(shù)目從當(dāng)前2000個(gè)左右擴(kuò)展到10000個(gè)以上，系統(tǒng)文件容量從10-50PB擴(kuò)展到1-10EB，文件數(shù)量從1.5億擴(kuò)展到1萬億（1 trillion）左右。同時(shí)，系統(tǒng)還需要支持完全的隨機(jī)讀寫以及一系列企業(yè)應(yīng)用特性，比如快照，mirror等等。MapR還期望在性能上有所突破，盡可能的榨取硬件的能力，并能對(duì)新的硬件技術(shù)（固態(tài)硬盤，萬兆網(wǎng)卡等）提供支持。
縱觀其實(shí)現(xiàn)，整個(gè)MapR的核心是其分布式NameNode，在MapR的設(shè)計(jì)中，分布式的NameNode又被稱作Container，和Hadoop原始設(shè)計(jì)中的Namenode不一樣的是，Container不僅維護(hù)了用戶文件的meta data，也維護(hù)數(shù)據(jù)塊。每個(gè)Container的大小在16GB-32GB之間（這也就意味著一個(gè)node上會(huì)有很多個(gè)container），同一個(gè)Container在不同node間有replica。

對(duì)于用戶來說，Container的概念過于底層，MapR引入了Volume的概念來降低使用用戶門檻和提高系統(tǒng)的靈活性。 MapR Volume（http://www.mapr.com/doc/display/MapR/Volumes）的概念和傳統(tǒng)存儲(chǔ)概念意義上的Volume相當(dāng)類似，用戶不需要直接管理Container，相應(yīng)的，用戶通過管理volumes來管理Container：用戶可以為每個(gè)Volume指定不同的大小限制，replication level等參數(shù)。此外，用戶還可以對(duì)volume建立snapshot，mirror等。
Container，volume相關(guān)的meta data被維護(hù)在被稱為CLDB中（container location database，http://www.mapr.com/doc/display/MapR/Glossary#Glossary-containerlocationdatabase ）。 CLDB是一個(gè)集中式的服務(wù)，為此，MapR為CLDB設(shè)計(jì)了 一系列的容錯(cuò)功能，詳細(xì)參見（http://www.mapr.com/doc/display/MapR/CLDB+Failover）。

采用分布式Namenode的一個(gè)必然結(jié)果就是要處理大量的分布式事務(wù)： 用戶有可能同時(shí)操作兩個(gè)Container。 針對(duì)這種情況， MapR認(rèn)為傳統(tǒng)的兩階段提交和基于Quarum 的協(xié)議（例如Paxos）都有局限性，他們提出了新的解決方案： MapR lockless transaction。Srivas的講座并沒有過多討論MapR lockless transaction的細(xì)節(jié)，從有限的幾張PPT里面，我們還是可以得知一二的：
1） 每個(gè)節(jié)點(diǎn)都會(huì)保存一份WAL。WAL分為兩種，OP log和Value log。OP log主要保存對(duì)meta data的修改和回滾信息，相應(yīng)的，Value log主要保存對(duì)data block的修改和回滾信息。
2） Log有全局的ID（利用Zookeeper可以很容易的實(shí)現(xiàn)這一點(diǎn)），這就使得其可以用來實(shí)現(xiàn)分布式事務(wù)成為可能。
3） 利用WAL，事務(wù)可以快速的回滾（2秒以內(nèi)）
4） MapR lockless transaction不需要顯式的提交（即默認(rèn)事務(wù)會(huì)成功執(zhí)行）
5） Replica會(huì)進(jìn)行監(jiān)測(cè)是否存在沖突，如果有沖突，則回滾事務(wù)。如果沒有，則confirm事務(wù)。
MapR聲稱這種實(shí)現(xiàn)方式有很高的吞吐率，而且事務(wù)進(jìn)行過程中不需要鎖，而且因?yàn)閃AL的存在，如果事務(wù)進(jìn)行過程中出現(xiàn)程序崩潰也無所謂。實(shí)際上，MapR lockless transaction的實(shí)現(xiàn)是仔細(xì)分析了MapR 分布式事務(wù)的特點(diǎn)以后的一種設(shè)計(jì)折中：作為大數(shù)據(jù)分析平臺(tái)，Hadoop要處理的數(shù)據(jù)集并往往是只讀或者讀多寫少（當(dāng)前版本的Hadoop HDFS實(shí)際上是只讀的），分布式事務(wù)存在沖突的幾率比較小，就是說，代價(jià)很大的回滾操作執(zhí)行的幾率很小，在這種情況下，放棄開銷很大的鎖機(jī)制是劃算的。

除了分布式Namenode這個(gè)大亮點(diǎn)之外，MapR還實(shí)現(xiàn)了一系列高級(jí)特性，對(duì)原來Hadoop的功能進(jìn)行了大幅度的增強(qiáng)。這其中最吸引眼球的有兩點(diǎn)：
1） Direct Access NFS技術(shù)。顧名思義，用戶可以直接在遠(yuǎn)程通過NFS 客戶端把MapR HDFS裝載到其本地，像操作本地文件一樣來進(jìn)行操作。這個(gè)特性在Hadoop峰會(huì)上引起了廣泛關(guān)注，講座結(jié)束后相當(dāng)一部分問題都集中于此。比如，支持符號(hào)鏈接么（答案：支持）？支持O_DIRECT訪問么（答案：O_DIRECT是相對(duì)本地文件系統(tǒng)而言的，對(duì)于NFS，O_DIRECT不是太有意義）？同時(shí)Direct Access NFS支持文件的隨機(jī)讀寫（原始Hadoop的文件系統(tǒng)可以被認(rèn)為是只讀的），大大的擴(kuò)展了MapR Hadoop的應(yīng)用范圍。
2） Snapshot，Mirror等企業(yè)應(yīng)用特性。Snapshot（快照），Mirror（鏡像）等企業(yè)應(yīng)用特性是是企業(yè)IT管理人員必不可少的工具，是處理復(fù)雜需求的得力助手。通過支持Volume，MapR　Hadoop方便的支持了這些功能，使得Hadoop不再只是開發(fā)人員的專寵，數(shù)據(jù)科學(xué)家，IT管理人員也能夠方便的訪問Hadoop這個(gè)功能強(qiáng)大的大數(shù)據(jù)分析平臺(tái)。
以上簡要介紹了MapR  Hadoop的幾個(gè)亮點(diǎn)，在如果想對(duì)其進(jìn)一步了解，請(qǐng)?jiān)L問http://www.slideshare.net/mcsrivas/design-scale-and-performance-of-maprs-distribution-for-hadoop 以及經(jīng)過數(shù)年的醞釀，大數(shù)據(jù)成為人們關(guān)注的焦點(diǎn)，各大IT媒體都在討論什么是大數(shù)據(jù)，其意味著什么，有哪些應(yīng)用程序可以處理大數(shù)據(jù)，如何培養(yǎng)數(shù)據(jù)科學(xué)家等等。在這個(gè)潛力無比的新興市場(chǎng)中，Hadoop無疑已經(jīng)提前卡位成功。在Hadoop的基礎(chǔ)上，人們紛紛推出了自己的發(fā)行版和增值服務(wù)，比如Cloudera推出了CDH；IBM則推出了InfoSphere BigInsights；Yahoo更是將原來開發(fā)Hadoop的部分獨(dú)立拆分出來成立了一家新公司Hortonworks，以期望獲得更大的競(jìng)爭優(yōu)勢(shì)。

Hortonworks，三象行，必有我?guī)熝?/span>

相對(duì)于舞臺(tái)上的其他競(jìng)爭對(duì)手，MapR獨(dú)辟蹊徑，利用當(dāng)前的Hadoop的一些弱點(diǎn)獲得了巨大的關(guān)注和影響力。展望未來，MapR會(huì)如何發(fā)展捏？我覺得MapR必須有心理準(zhǔn)備應(yīng)付Hadoop的快速發(fā)展。Hadoop暴露各種問題已經(jīng)廣為知曉，Hadoop 2.0也在如火如荼的規(guī)劃和實(shí)現(xiàn)中（http://www.oscon.com/oscon2011/public/schedule/detail/19234 ），在不久的將來，Hadoop將會(huì)有劇烈的變化。那么，要保持和新版的Hadoop API兼容的同時(shí)還保留自己的種種優(yōu)點(diǎn)（高性能，高可用性，各種企業(yè)特性）是非常有挑戰(zhàn)性的工作，MapR的天才們會(huì)交出怎樣的答案？我們拭目以待。

【完】

關(guān)于作者：
向東(@朝東走)，EMC中國研究院高級(jí)研究員，主要關(guān)注云計(jì)算，分布式系統(tǒng)和大數(shù)據(jù)。
(注，本文根據(jù)公開資料收集整理而成，文中各種技術(shù)觀點(diǎn)，如有不妥，歡迎指正。)