gfs论文发表时间

这个具体要看你发的是什么样的杂志了，不同杂志的发表周期也不一样。省级、国家级的普刊一般是2-6个月（特别快的1个月左右，一部分可以办理加急版面）。杂志都有出版周期的问题，而且有的版面特别紧张，所以，如果用，要提早半年，不宜临时抱佛脚。每年三月份、九月份，是各地上报职称材料的高峰期。各个正规杂志社稿件大量积压，版面十分紧张，因此，及早准备。早准备、早受益。我当时是在百姓论文网发表的，省级的大概在2个月左右拿到手的，各方面都挺满意的，

论文发表一般需要的时间如下：

1、普刊即省级国家级一般安排周期是1到3个月。

2、本科学报的安排周期一般为2到4个月。

3、北大核心以上级别期刊的安排周期一般为6到8个月，审稿周期为一个月。

4、科技核心期刊从投稿到录用发表，一般是3到6个月。

论文是一个汉语词语，拼音是lùn wén，古典文学常见论文一词，谓交谈辞章或交流思想。

当代，论文常用来指进行各个学术领域的研究和描述学术研究成果的文章，简称之为论文。它既是探讨问题进行学术研究的一种手段，又是描述学术研究成果进行学术交流的一种工具。它包括学年论文、毕业论文、学位论文、科技论文、成果论文等。

2020年12月24日，《本科毕业论文(设计)抽检办法(试行)》提出，本科毕业论文抽检每年进行一次，抽检比例原则上应不低于2% 。

简单点来说，就是Hadoop是继承了Google的MapReduce、GFS思想，开发出来的一套框架，后来又交给了Apache作为开源项目。MapReduce诞生于谷歌实验室，MapReduce与GFS、BigTable并称为谷歌的三驾马车，、而Hadoop则是谷歌三驾马车的开源实现。2003年，Google发表了一篇技术学术论文谷歌文件系统（GFS）。GFS是google公司为了存储海量搜索数据而设计的专用文件系统。2004年，Nutch创始人Doug Cutting基于Google的GFS论文实现了分布式文件存储系统名为NDFS。2004年，Google又发表了一篇技术学术论文MapReduce。MapReduce是一种编程模型，用于大规模数据集（大于1TB）的并行分析运算。2005年，Doug Cutting又基于MapReduce，在Nutch搜索引擎实现了该功能。2006年，Yahoo雇用了Doug Cutting，Doug Cutting将NDFS和MapReduce升级命名为Hadoop，Yahoo开建了一个独立的团队给Goug Cutting专门研究发展Hadoop。

核心期刊正常都是3-7月左右录用，录用后2-4个月左右出刊，这个是正常的周期，有部分方向以及期刊可以加急录用。

gfs论文发表

没有那么容易，比较难分布式工程学是一门实践性很强的工科学。所以会出现与其他工科一样的现象就是实践会先于理论。在1960年末被公认为是第一个分布式系统的ARPANET就诞生于美国[1]。在美国50年代到60年受曼哈顿计划的影响，计算机理论迎来了大爆炸的时代。在那个年代发明了我们今天所用到的大部分计算机理论。作为一个新兴学科，当年的科学家大都是刚刚毕业正是壮年。而今他们大多已经是高龄老人，有些科学家则已经离世。在这里向哪些为计算机理论作出贡献的科学家们表示敬意。

张兆代王圣洁刘京鹏宋宏伟

（青岛海洋地质研究所）

摘要云计算继承和整合了虚拟化技术、海量数据存储、分布式并行计算框架、智能化与自动管理等多项关键技术，形成了具有高性能、可伸缩、低成本及面向服务的新的计算模式。目前学术界及产业界对云计算的研究和探讨均呈快速增长趋势，大量论文发表在计算机类和图书情报类期刊，研究的重点集中在云计算的基础理论、云计算的关键技术、云服务的应用领域、云计算与信息资源管理等多个方面。本文以 2000 ～ 2012 年发表在国内核心期刊上关于云计算的研究文献为统计样本，分析了云计算的研究热点及其演化方向，结合我国地质资料集群化产业化服务的发展状况，探讨云计算应用策略。

关键词云计算模式地质资料信息共享和服务

1 前言

“云计算（Cloud Computing）”一词出现于 2006 年，是谷歌总裁埃里克施密特（Eric Schmidt）在搜索引擎大会（SES San Jose 2006）首次正式提出的一个概念。它不仅揭开了谷歌搜索背后关键技术的神秘面纱，而且在短短的数年内就迅速超越“网格计算（Grid Computing）”并成为新的潮流（图 1）。

图 1 网格计算与云计算搜索量变化趋势图

2006 年后，在谷歌、亚马逊、IBM 等企业的推动下，“云计算”作为新兴的计算模式已经有了广泛应用。云计算作为一种基础设施与服务的交付和使用模式，正深刻地影响着互联网的发展。近年来，国内外掀起了关于云计算的研究热潮，涌现了大量的研究文献和应用案例，云计算已经成为学术界和产业界共同关注的热点。本文首先介绍了云计算的基本概念和关键技术，并通过对现有的云计算研究文献的综合分析，结合我国地质资料集群化产业化服务的发展状况，提出其在云计算应用中需要注意的问题。

2 云计算及其关键技术

2.1 云计算的基本概念

云计算的概念仍存在不同的定义。一般认为云计算是一种基于互联网的计算方式，通过这种方式，共享的软硬件资源和信息可以按需提供给计算机和其他设备[1]。美国国家标准与技术研究院（National Institute of Standards and Technology，NIST）也给出了云计算的定义，认为云计算是一种能够通过网络以便利的、按需使用的方式获取计算资源并显著提高可用性的方式，这些计算资源来自一个共享的、可配置的资源池，并能够以自动的方式获取和释放[2]。

中国电子学会云计算专家委员会认为：云计算是一种基于互联网的、大众参与的计算模式，其计算资源（计算能力、存储能力、交互能力）是动态、可伸缩、且被虚拟化的，并以服务的方式提供。这种新型的计算资源组织、分配和使用模式，有利于合理配置计算资源并提高其利用率，从而促进节能减排，实现绿色计算[3]。

尽管云计算有不同的定义，但对于云计算的特点已有很多深入的讨论。下面五个基本特征可以用来判断一个计算服务是否是云计算。

（1）服务按需即取。云计算是把信息技术作为服务提供的一种方式。由于这种服务是从用户角度出发，按需即取的自助服务是其最重要的特征之一。用户可以自行获得计算能力，包括服务器的使用和网络存储的使用，而整个过程通常是自动进行的。

（2）便捷网络访问。云计算支持广泛和便捷的网络访问能力，用户可以使用多种设备，如手机、移动计算机或工作站等获取云服务。

（3）资源共享池。云计算带来的一个好处是能够提高资源的利用率，通过把资源集中到一个公共的资源共享池中，可以为大规模的用户群提供共享服务。由于资源池可以动态分配所有物理和虚拟资源，达到了通过共享提高资源利用率的目的。

（4）高可扩展性及弹性服务。云计算具有快速及可伸缩地提供服务的能力。根据需求变化，云计算所提供的服务可以自动并快速地扩展或收缩。

（5）服务可度量。云系统通过自动监控资源的使用，可以提供定量的运行报告，从而保证云服务处于应有的水平。

2.2 云计算的体系架构

计算机技术的发展经历了传统主机计算模式到个人普及计算模式及分布式网络计算模式的转变[4]。云计算作为一种新的计算模式，既是分布式计算、并行计算和网格计算等技术快速演化的结果，也是信息社会中信息需求的必然选择。社会化、集约化与专业化的信息服务通过各种云计算得以体现，其中既包括了各种通过网络提供给用户的互联网应用、软件或计算资源服务，也包含了用来支撑这些服务可靠和高效运行的软硬件平台。

美国国家标准与技术研究院的技术报告给出了关于云计算体系架构的完整模型（图 2），该顶层模型定义了云计算模式中的角色（Actors）、行为（Activities）和功能（Functions）[5]。云计算的核心角色有云用户（Cloud Consumer）、云服务商（Cloud Provider）、云审计者（CloudAuditor）、云代理商（CloudBroker）和云运营商（Cloud Carrier）共五类（表 1）。在该模型中，云用户可以获得包括 ERP、CRM、HR 等商业智能或信息、通讯、协作、存储、备份以及软件、硬件托管等多种服务，云服务商则通过云计算中心的建设、运行和管理提供在线的软件服务（SaaS）、平台服务（PaaS）和基础设施服务（IaaS），云运营商通过提供网络接入、通讯系统等保障云计算的提供和使用，云审计者和云代理商的参与则保证了云计算和云服务的稳定性、持续性和透明度及服务水平。

图 2 云计算体系架构参考模型（引自 NIST）

表 1 云计算模式中的主要角色及定义

2.3 云计算的关键技术

云计算是计算机技术发展的产物，其中虚拟化技术、海量数据存储、分布式并行计算框架、智能化与自动管理被认为是实现云计算的关键技术[6]。

2.3.1 虚拟化技术

虚拟化（Virtualization）技术是将各种计算及存储资源充分整合和高效利用的关键。虚拟化技术包括两个方面：物理资源池化和资源池管理。物理资源池化是把物理设备由大化小，将一个物理设备虚拟为多个性能可配置的最小资源单位；资源池管理是对集群中虚拟化后的最小资源单位进行管理，根据资源的使用情况对资源进行灵活分配和调度，实现按需分配资源。虚拟化技术主要应用在服务器虚拟化、存储虚拟化和网络虚拟化三个方面。

2.3.2 海量数据存储

海量数据存储是云计算的主要任务。为了保证可用性、可靠性和经济性，云计算采用分布式存储的方式来存储数据，由于采用了分布式冗余存储的方式，数据既有高可靠性，也能并行地为大规模用户提供服务。云计算的数据存储技术主要有谷歌的分布式文件系统（GFS，Google File System）和 Hadoop 的HDFS（Hadoop Distributed File System）。

2.3.3 分布式并行计算框架

并行计算是云计算的核心。云计算采用 Map-Reduce 的编程模式实现分布式并行计算。Map-Reduce通过“Map”和“Reduce”这样两个过程来简化并行计算，所有应用只需要提供 Map 函数以及 Reduce 函数就可以在集群上进行大规模的分布式数据处理。Map-Reduce 不仅仅是一种编程模型，同时也是一种高效的任务调度模型，该模型的使用使计算任务高度并行及分布式实现成为现实。

2.3.4 智能化与自动管理技术

云计算具有高度自治的特点，智能化与自动管理是云计算模式的重要技术支撑。通过对集群系统各节点的全面监控、自动反馈、智能调配，实现了包括设备、虚拟资源、通讯与服务等的动态管理和自动迁移。以第四代大规模数据中心为基础的云计算，既能灵活扩展部署，也能满足服务计算和多粒度计算的要求。

3 我国云计算研究热点分析

3.1 国内外云计算搜索量变化趋势比较

搜索量的大小通常反映关注度的高低，使用 Google Trends 工具还可以分析一些长期的趋势和变化。这里选择“Cloud Computing”和“云计算”分别作为世界和我国在云计算领域的指标性关键词，从分析结果可以看出以下几个特点（图3）：①世界上对于云计算的关注开始于 2007 年，我国则自 2008 年才开始关注该领域。因此，我国仍属于学习—跟随型研究模式。②自 2007 年后，世界上关于“Cloud Computing”的搜索量出现迅速增长趋势，目前，已超过“Grid Computing”成为新的信息技术热点，我国对此的关注则较为平缓和滞后。③如果把搜索量代表的关注度看做是“海上的冰山”，那些“水下的部分”，包括基础理论、关键技术、应用实践等方面，国内外存在更大的差距。

图 3 国内外云计算搜索量变化趋势比较

3.2 国内云计算研究文献的计量分析

本文利用中国知网 CNKI 学术期刊数据库，检索 2000 年 1 月至 2012 年 3 月发表的有关云计算研究的核心期刊文献 852 篇（表 2）。我国对于云计算的研究始于 2007 年，之前罕见相关研究。2008 ～2011 年，云计算的研究开始引起广泛关注，论文数量开始急剧上升，同时发表云计算论文的期刊数量也同步快速增多，显示出云计算研究领域的广泛性。由于只统计到 2012 年 4 月的部分数据，从表面看检索到的 2012 年的成果不多，实际并未改变论文数量快速增加的趋势。

表 2 云计算论文发表时间分布表

对于检索到的 852 篇论文，对其关键词进行了计量分析，其中涉及关键词 1376 个，累计出现频次3020 次。按频次从大到小排列，排在前十位的关键词有：云计算（645）、虚拟化（115）、图书情报（115）、云服务（94）、安全（65）、存储（42）、物联网（33）、MapReduce（24）、档案（20）、数据中心（13）等。从关键词分析可以看出，云计算的研究涉及基础理论、关键技术、应用领域、信息资源管理等诸多方面，对于虚拟化、存储、MapReduce 等关键技术有较多论述；但整体来讲，多数仍为综述性、展望类的论文。就应用领域来讲，图书情报界对云计算进行研究和借鉴的趋势比较明显[7]，而地质资料界对云计算的关注和应用研究仍较少。

4 云计算与地质资料服务

4.1 地质资料数据与服务现状

地质资料是国家重要的基础资料。新中国成立以来，通过实行地质资料统一汇交制度，积累了大量的地质资料。我国现有全国性基础地质与战略性矿产地质数据资源 12 大类 50 余种数据库，数据量达10TB 以上，涉及区域地质、矿产地质、水文—工程—环境地质、农业地质、海洋地质、基础地质、地球化学、地球物理、地学科研、地质资料、遥感等领域[8]。

我国目前实行的是二级监管、三级保存的地质资料管理框架。由于条块分割等原因，地质资料的共享与服务尚存在很大差距，突出表现在数字化程度低，信息孤岛现象严重，地质资料不能及时、有效地满足国家建设与社会需求。

2002 年，国务院颁布了《地质资料管理条例》，2003 年，国土资源部发布了《地质资料管理条例实施办法》，地质资料的管理与共享服务得到了前所未有的重视。国土资源部又相继推动地质资料汇交、地质资料委托保管、地质资料集群化、产业化服务等，地质资料的管理与服务开始出现一个新的局面。由于管理与服务模式的转变是一个较长期的过程，地质资料工作的重要性仍未完全显现，社会对地质、矿产等的关注度仍远落后于“土地”“海洋”“气象”，仅稍高于“测绘”（图 4）。

4.2 云计算是改变地质资料服务模式的契机

从云计算的产生和发展过程来看，云计算是在继承和整合了虚拟化技术、海量数据存储、分布式并行计算框架、智能化与自动管理等多项关键技术的基础上，形成的具有高性能、可伸缩、低成本及面向服务的新的计算模式。云计算正在推动着信息产业实现社会化、集约化、专业化的大转型。

社会化：互联网计算正成为社会基础设施，建立集中的、各种各样的云计算中心实现规模化的社会服务，是当前发展的趋势。

图 4 地质等搜索量变化趋势比较

集约化：归并分散、粗放的软件开发与应用，软件模块构件化，提高平台利用率，使计算资源以虚拟化组织和配置、弹性伸缩，通过软件的重用和柔性重组，进行服务流程的优化与重构。

专业化：面向多租户使服务更为精细、规范，并对服务透明使用，按需租用[9]。

地质资料服务及信息共享是一种典型的数据密集型计算服务，这恰与云计算模式的基本特点相符合。因此，引入云计算是推进地质资料信息服务集群化产业化的天然契机。从技术层面上来讲，国家地质资料数据中心建设十分重要，建议规划为提供完整 SPI（软件即服务 SaaS、平台即服务 PaaS、基础设施即服务 IaaS）服务的地质资料专业云，全面涵盖二级监管、三级保存及社会化服务，这种集中式的部署方式既降低了技术难度，也有利于提高投入和使用效率。其次，国家地质数据中心也可以规划为“逻辑统一、物理分布”的三级数据中心体系，这种社区云的部署方式符合我国地质资料行业现状，组织实施均较为简单。需要注意的是，无论哪种方式，统一的体系架构、成熟技术的采用、一致的标准和安全性都是需要重点考虑的问题。

5 结语

与网格计算相反，云计算更多地经历了从实践到理论的过程，从研究者关注云计算开始，其实已经大量出现云计算的实例。我国在云计算领域的基础研究仍然落后，但图书情报界对云计算的跟踪和应用却十分突出，一些基于知识的服务已经达到专业化和产业化服务水平。相信云计算模式的引入，将会极大地推动地质资料服务向集群化产业化方向转型，以更好地实现地质资料和成果的全社会共享。

参考文献

[1] 维基百科.云计算.http：//zh.wikipedia.org/wiki/ 云计算，2012.

[2]Peter Mell，Timothy Grance.The NIST Definition of Cloud Computing.NIST Special Publication 800 ～ 145，2011.

[3] 李德毅，林润华，郑纬民等.云计算技术发展报告 [M[.北京：科学出版社，2011.

[4] 杨春霞，王圣洁，王春民.谈计算模式的演变及其对海洋地质数据处理的影响 [J].海洋地质动态，2004，20（2）：32 ～ 36.

[5]Fang Liu，Jin Tong，Jian Mao et al.NIST Cloud Computing Reference Architecture.NIST Special Publication 500 ～ 292，2011.

[6]Michael Armbrust，Armando Fox，Rean Griffith et al.Above the Clouds： A Berkeley View of Cloud Computing.http：//，2009.

[7] 张正禄.我国图书情报界云计算研究述评 [J].国家图书馆学刊，2010，（3）：73 ～ 76.

[8] 国土资源部矿产资源储量司.推进地质资料信息服务集群化产业化 [M].北京：地质出版社，2011.

[9] 李德毅.云计算支撑信息服务社会化、集约化和专业化 [J].重庆邮电大学学报，2010，22（6）：698 ～ 702.

在1997年Karger发表的论文中首次使用了一致性哈希的术语。虽然Teradata公司在1986年开发的分布式数据中已经...

发布式容易发论文的吗？在1979年karger发表的论文中首次使用了一致性哈希的术语。

gfs论文发表年限

CS7680著名的9个论述也是这门课推荐对于分布式系统的一个初步认识 windows live的架构师james总结一系列大型后台服务的设计原则CAP 准确说是一篇blog，很精简，文字也不多，其实文中的图比文字更清晰。cap的理解也经历了一些纠结的过程，这一篇其实是作者多年后的二次理解。所以出错其实没啥问题，这位老板就完全推翻了之前文章里的阐述也是通俗易懂的入门介绍cap的blog brewer多年以后写的关于cap的一些误解，C和A并不是完全对立的状态是对上面这片文章的review心得开始用了两个新名词来阐述A)yield, which is the probability of completing a request .感觉说的就是AB)harvest ,measures the fraction of the data reflected in the response.感觉说的就是C这篇论文对于available提出里两个比较好的方案：1)牺牲harvest换来yield2）应用架构拆分和正交机制BASE base一致性的开山鼻祖，首次提出了和acid相反的一种理论，论文中给出了一些单机事务到多机事务的演进过程，并没有觉得很理论，工程很值得借鉴一致性一致性的模型，高屋建瓴，是一篇blog 概述的文章先看看sequential consistency lamport大神不用过多的介绍，读他的论文唯一的感受就是智商的差别吧也是线性一致性的文章作者在cmu发表的eventual consistency最终一致性的文章首推 aws的cto 讲了一些高可用和一致性之间的trade-off 描述了最终一致性和因果一致性的关系 consistency Bolt-on的架构设计 cops的架构设计一个causal consistency的db设计与实现从前三篇文章的作者来看，ucb & cmu&priceton 还是很值得一读的最后一篇的年代已经久远，其实发现计算机的一些理论基础其实是很经得起时间的考验的，所以码农其实也可以过的没有那么的有危机感^_^ 这个是最后一篇论文的ppt版本 consistency分布式锁 Google出品的chubby 必属精品 Yahoo的zookeeper分布式kv存储 Google三驾马车之一bigtable,hbase的蓝本 Google三架马车之二gfs，hdfs的蓝本 Google三架马车之三bigtable，hbase的蓝本现代很多的kv设计或多或少的都参考了先驱dynamo的设计，值得刷10遍以上。读后感 2009年Cassandra设计的论文，很多思想借鉴了dynamo，对于一致性哈希的吐槽也高度类似。在replication的过程中，也会通过一个coordinator节点（master节点）来对其他节点进行replicate（这一点和dynamo一样），但是Cassandra提供了一系列的replicate policy可以选择，比如 Rack Unaware, Rack Aware (within a datacenter) and Datacenter Aware. Cassandra也沿用了dynamo里面关于preference list的定义 ucb出的一篇高性能的kv存储，号称比redis快几十倍，使用coordination-free consistency models。虽然说是特别快，但是其实业界的是用并不广泛时间序列的数据库的一篇介绍，介绍了几个应用场景 iot ebay等，influxdb的介绍比较了业界的几种TSDB的异同无论是kv还是传统的关系型数据库，在分布式系统里面无非都会涉及到以下这几方面replication 指出了一种在replication中存在的问题，并给出了解决方案partition&shard分区都逃不了一致性哈希，被引用度特别高的一篇文章,但是这个版本也是被吐槽最多的，dynamo吐槽过，Cassandra也吐槽了一把1）First, the random position assignment of each node on the ring leads to non-uniform data and load distribution.2）Second, the basic algorithm is oblivious to the heterogeneity in the performance of nodes.解决方案1）One is for nodes to get assigned to multiple positions in the circle (like in Dynamo) dynamo用的就是这种方法2）the second is to analyze load information on the ring and have lightly loaded nodes move on the ring to alleviate heavily loaded nodes 这种方法被Cassandra采用 2）用的方法也就是这片论文提出的方法memshipfailure detectupdated conflictsimplement关于实现这篇论文的出镜率特别高，里面的思想被Cassandra和dynamo都采用了，作者也是提出cap的大神Eric Brewer（第三作者），值得反复研读这个是2019年Google提出的一种有状态的kv存储的思路。在工业界的下个请求依赖于上一个请求的情况数据库查询优化器现在很火的kafa最初设计的论文，细节有些已经被优化，基本的架构还是很值得反复研读。比如In general, Kafka only guarantees at-least-once delivery. Exactly once delivery typically requires two-phase commits and is not necessary for our applications最初kafka只是支持at-least的delivery, 但是不支持exactly once的投递，具体哪个版本开始支持有点记不清了分布式文件系统除了大名鼎鼎的gfs 分布式文件系统已经走过了好几十个年头了 1990年的coda，在很多的论文中出镜率非常高，后面的fs也借鉴了coda的一些思想分布式事务&事务隔离级别引用率很高的一篇文章这里面也引用了下面的这篇文章中关于事务隔离级别P0，P1的引用，看之前可以先看下面这篇文章。比如，脏写，脏读，不可重复读&fuzzy读，幻读等读未提交保证了写的串行化，注意只是写的串行化（并不能保证读写的串行化，依然有可能产生脏读），下面这篇论文里面是避免了脏写的操作。如何处理写的冲突呢？打时间戳或者last write win的方式都是可行的不管是怎么讲事务隔离级别，最原生的味道是这一篇，其他的文章都是咀嚼过吐出来的其中也参考了里面阐述了很多隔离级别的标准共识算法 paxos的simple版本，原来的版本太晦涩，lamport大神自己可能发现之前写的太高深了，写了一个通俗易懂的版本 hermes 这个是精简版的raft 里面有些概念如果理解起来吃力可以看下作者的博士毕业论文里面有download的连接，以下的几篇文章都是raft的推荐 raft 的分析文章 verdi的实现 raft一致性的分析名字服务 zk最初设计的论文，感觉比市面上的一些中文材料好懂，推荐关于consul以及名字服务的实践，medium上面有两篇比较好的文章A Practical Guide to HashiCorp Consul — Part 1 | by Velotio Technologies | Velotio Perspectives | MediumA Practical Guide To HashiCorp Consul — Part 2 | by Velotio Technologies | Velotio Perspectives | Mediumetcd(94) Introduction to etcd v3 - YouTube 一个youtube上的视频比较清楚的介绍了etcd的设计思路etcd保证了强一致性，这一点感觉和consul不太一样高可用性watchable . 这一点和zk比较像，但是consul是使用gossip进行通知的(94) Deep Dive: etcd - Jingyi Hu, Google - YouTube 讲了etcd是如何使用raft来保证一致性的应用在名字服务里面的gossip protocol开始读到这些论文一直不太理解可以应用到那些地方，后面看到consul在使用gossip来进行memship的管理，基本的原理参考了论文：SWIM.pdf (cornell.edu)后来发现如果cpu的负载如果过高，很可能出现误判的情况1707.00788.pdf (arxiv.org) 这篇论文里面比较好的解决了这个问题

GFS的诞生来源于google日益增长的数据量的处理需求，它是一个可扩展的分布式文件系统，用于大型分布式数据密集型应用，在廉价的通用硬件上运行时提供容错机制，并且可以为大量客户端提供较高的聚合性能。它的设计由当前和预期的应用负载(当时的)和技术环境驱动，与以前的文件系统的假设有着明显不同，因此gfs在设计上有几个不同的points：

当前已部署多个集群用于不同目的，最大的拥有1000多个存储节点，超过300TB的存储服务，并且有数百个客户端连续不断地高负载请求。

前面提到一些对应用负载和技术环境的观察，现在更详细地进行阐述：

虽然GFS不能提供像POSIX标准的API，但它提供一个相似的文件系统接口。文件在目录中按层次结构组织，并以路径名作为标识。支持create、delete、open、close、read and write files。

gfs支持快照和record append操作。快照以低代价创建文件副本或者目录树，record append支持多个客户端并发地写文件，保证每个独立客户端append的原子性。

一个gfs集群包含一个master和多个chunkservers，chunkserver被多个客户端访问，如图1所示。每一个都是普通linux机器上运行的用户态服务进程。资源允许的情况下，客户端可以和chunkserver部署在同一台机器上。

文件被划分为固定大小的块。每个chunk由一个独一无二的64位大小的chunk handle所标识，chunk handle在chunk被创建时由master分配。每个chunk的副本分布在多个机器上，系统默认为三副本模式，用户也可以为不同namespace的文件指定不同级别的副本。

master包含文件系统的所有元信息。包含namespace、访问控制权限信息、文件到chunks的映射、当前chunks的位置信息。也控制着全局的活动，像chunk租约管理、gc、chunk迁移等。master通过心跳的方式与每个chunkserver交流来发送它的指令和收集状态。

客户端与master的交互涉及元信息操作，所有数据操作直接与chunkserver交互。gfs不提供POSIX标准API，因此不需要挂接到linux的vnode层。

客户端和chunkserver都不缓存文件数据。大多数应用传输大文件，客户端缓存收益很低。chunks作为本地的文件存储，linux系统有自己的buffer cache，chunkserver不需要再增加缓存。

单master简化了系统的设计，但是会有单点的瓶颈问题，这是必须要解决的。客户端不会从master读写数据文件，客户端请求master它需要的交互的chunkserver信息，并且将其缓存一段时间，后续的操作直接与chunkservers交互。

客户端会发送请求给离它最近的一个副本。实际上，客户端通常会向master请求多个chunk的信息，以减少未来与maser交互的代价。

chunk size定为64MB，相比普通的文件系统的block size更大。每个chunk副本以linux文件的形式存在chunkserver上，仅根据需要来扩展。使用lazy space allocation的方式避免空间浪费。

large chunk size有以下几个优点：

但是large chunk size with lazy space allocation也有其缺点：单个文件可能包含很少数量的chunks，或许只有一个，当许多客户端访问相同文件时这些chunks成为热点。但由于目标应用大多是顺序的读多个large chunk文件，热点并不是主要的问题。然而GFS第一次用于批处理队列系统时确实出现了热点问题，数百个客户端同时访问一个单chunk文件，存储这个文件的几个chunkserver超负荷运转，当时通过错开应用的启动时间避免了这个问题，一个潜在、长期的解决方法是允许客户端从其它客户端读取数据。

master保存三种类型的元数据：

所有元数据都保存在内存中。对于元数据的内存操作是很快的，后台任务周期巡检整个状态也是比较简单高效的。周期巡检用于实现chunk gc、在chunkserver故障时重新构造副本、chunk迁移以平衡多个chunkserver的负载和disk usage。虽然系统的容量受master内存大小的限制，但这并不是一个严重的问题，64MB的chunk只需要不到64byte大小的元信息，如果一定需要更大的文件系统，那么增加内存的代价相比为可靠性、性能和灵活性等付出的代价是较小的。

前两种类型的元数据通过写日志来保证持久化，并且会复制日志到远程机器上。master不需要将chunks的位置信息持久化，而是在master启动和新的chunkserver加入集群时向每个chunkserver询问它的位置信息，之后通过心跳信息监控chunk位置变更信息。chunkserver作为最后一关是确切知道自己本地有没有哪些chunk的，因此维护一个一致性的视图是没有必要的。

operation log 包含元数据的变更记录，它是GFS的核心，它不仅仅是唯一的元数据持久化记录，也表明了并发操作的逻辑时间线。文件、chunks和它们的版本都是由逻辑时间线唯一标识。元数据变更记录在持久化之前对客户端是不可见的，而且日志被复制到多个远程的机器，只有相应的记录在本地和远程都持久化到硬盘了才可以回复客户端。master使用批处理log的方式提高系统的吞吐。

master通过回放日志来恢复文件系统的状态，为提高恢复速度需要保持log量足够小。当log增长超过特定大小时，master会checkpoint它的状态，以加速恢复提高可用性。构建checkpoint可能需要花费一段时间，因此master以一种不delay后续变化的方式来组织内部状态，先switch到一个新的日志文件，使用独立的线程创建checkpoint，新的checkpoint包含了所有switch之前的变化。几百万个文件的集群在一分钟内可以完成，完成后将同时被写入本地和远程。恢复只需要最新的checkpoint和之后的日志文件，旧的checkpoints和日志文件可以完全删除。

GFS使用一个宽松的一致性模型，这种模型可以很好地支持分布式应用程序，而且实现起来简单有效。 file namesapce变化(例如文件创建)是原子的，使用namespace锁。 master的operation log定义了这些操作的全局顺序。

数据变化后文件region的状态取决于变化的类型，是否成功、失败或者是并发的。Table1做了总结。如果所有客户端都能看到相同的数据，无论它们读的是哪个副本，则这个file region是一致的。

数据变化有两种：writes或者record appends。write是指从应用指定offset处开始写数据，record append指即使存在并发冲突，数据也要被原子地append到文件至少一次，但offset是由GFS选定。

GFS保证在一系列成功的mutations后，file region是defined，通过下面两点来保证：

过期的副本将不会再涉及到任何mutation，master也不会将其位置信息回应给客户端，不久后将会被gc。但客户端缓存的信息可能包含过期的副本，缓存失效存在一个时间窗口，文件再次打开也会清除该文件的所有chunk信息。由于大多数文件是append-only，过期的副本通常返回的是过早的结尾???而不是过期的数据。

介绍客户端、master和chunkserver之间如何交互来实现数据变化、原子追加写和快照的。

使用租约的方式维护多个副本间一致的mutation order。master授权租约给副本中的一个，称之为primary。primary为chunk的mutaions选择一个顺序，所有副本都按照这个顺序apply。租约机制最小化了master的管理overhead。租约初始的超时时间是60s，如果chunk一直在变化过程中，primary可以申请续租。这些授权和续租请求由master和chunkserver之间的心跳信息携带。master也可以尝试撤销租约，即使它与primary失去了联系，也可以等租约过期后安全地授权给另外一个副本。

在Figure2中，跟随着写入控制流展示了处理过程：

如果一个写请求比较大或者超出了chunk边界，GFS客户端将它拆为多个写操作，但是多个操作可能与其它客户端并发交叉写入，因此共享的fie region最终可能包含多个不同客户端的碎片，这会造成一致性模型中所描述的file region处于consistent but undefined状态。

数据以pipline的机制在chunkserver链上线性传输，而控制流是从客户端到primary再到所有的其它副本。分离数据流和控制流可以更高效地使用网络。可以带来以下好处：

GFS提供原子的append operaton叫作 record append 。传统的write中，客户端指定offset，并发写相同region时不是serializable，最终region可能包含多个客户端的碎片数据。而对于record append，客户端仅指定数据，GFS保证至少一次成功的原子append，offset由GFS选定，与Unix的O_APPEND模式相似。

多个客户端并发操作相同文件是比较重的。如果处理传统的write，客户端需要额外复杂和昂贵的同步逻辑，像分布式锁。而record append仅需要primary增加一点额外的逻辑：primary检查是否并发append数据的chunk会超出max size，如果会超出则将chunk填充到max size，并且告诉所有二级副本同样操作，然后回应客户端指出这个操作应该选择另一个chunk重试；大多数情况下记录是在max size内的，primary将数据append到自己的副本，并告诉所有二级副本按照确切的offset写数据，最后回应给客户端。

如果中间出现错误，客户端重试，相同chunk的副本可能包含不同的数据，可能包含相同的记录或者一部分相同，GFS不保证bytewise identical，仅仅保证数据至少有一次被成功地原子写入。从report success逻辑可以容易得出，数据必须是在某个chunk的所有副本上以相同的offset写入。在此之后，所有副本都与记录end一样长，即使后面不同的副本成为primary，任何将来的记录也将分配到更高的offset或者不同的chunk。根据上述的一致性保证，成功的record append的region是defined和一致的，而中间的region是不一致的(undefined)。GFS的应用可以处理这种不一致的region(2.7.2)。

snapshot 操作拷贝一份文件或者目录树，几乎是实时的，同时最大程度减少对正在进行中的mutation的干扰。像AFS一样，使用标准的COW技术实现snapshot。当master接收到一个snapshot请求，首先将所有涉及到chunks的租约撤销，这保证了这些chunks后续的write将会先请求master查找租约持有者，master会创建一个新的副本来回应。

租约被撤销或者过期后，master将这个操作记录日志到disk。新创建的snapshot引用元数据相同的chunks。当snapshot操作完成后，客户端第一次要写chunk C，发送请求给master查询持有租约者，master察觉到chunk C的引用大于1，则让每个含有当前chunk副本的chunkserver创建一个新的chunk叫作C'，所有创建都使用本地的副本，相比100Mb的网络本地速度大约是三倍速度。master授权租约给新的chunk C'中的一个并且回复给客户端，之后正常地写chunk。整个过程对客户端是透明的。

master执行所有的namespace操作。另外，它管理整个系统的chunk副本：

接下来，详细探讨这些细节。

许多master操作可能花费较长一段时间，比如snapshot操作需要撤销相关的所有chunks的租约。因此为了不delay其它master操作，在namesapce的regions上使用locks来确保串行化。 GFS没有按目录列出该目录中所有文件的结构，也不支持文件和目录的别名(unix中的硬链和软链)。GFS将完整的路径名到元数据的映射表作为它的逻辑namespace。使用前缀压缩，这个表可以有效保存在内存中。namespace tree中的每个节点都有一个关联的读写锁。每个master操作在运行前都会获取一组锁。如果涉及到/d1/d2/../dn/leaf，它将获取目录名称/d1、/d1/d2、...、/d1/d2/.../dn上的读锁，完整路径/d1/d2/../dn/leaf的读锁或者写锁。leaf可以是文件或者目录。

创建文件不需要对父级目录加锁，因为没有"目录"的概念不会修改它，而加读锁是防止它被删除、重命名或者snapshot。这种锁机制的好处是允许相同目录下并发的mutations。

一个GFS集群通常具有分布在多个机架上的数百个chunkserver，这些chunkserver也会被相同或者不同机架的数百个客户端访问。不同机架上的两台计算机之间的通信可能会跨越一个或者多个网络交换机。另外进出机架的带宽可能小于机架内所有计算机的总带宽。多级分布式对如何分发数据以实现可伸缩性、可靠性和可用性提出了独特的挑战。副本放置策略有两个目的：最大化数据可靠性和可用性，最大化网络带宽利用率。不仅要在多台机器上放置，还要在多个racks上，即使整个racks损坏也可以确保部分副本保持可用。也可以利用多个racks的总带宽。

chunk副本创建有三个原因：

当master创建新的chunk时，根据几个因素考虑如何放置新的副本：

当chunk可用副本的数量低于用户指定时，master会重新复制。可能发生在几种情况：

需要重新复制的chunk根据以下几个因素确定优先级：

master限制集群和每一个chunkserver内的活跃的clone数量，另外chunkserver通过限制其对源chunkserver的读请求来限制在每个clone操作上花费的带宽。

master会定期重新平衡副本：检查当前副本的分布，迁移副本以获得更好的磁盘空间利用率和负载平衡。同样通过此过程，master逐渐填充一个新的chunkserver。另外，master通常更倾向于移除具有低磁盘利用率chunkservers上的副本，以平衡空间使用。

当文件被删除时，master记录日志，但不会立即回收资源，而是将文件重命名为包含删除时间戳标记的隐藏名称。如果这些文件存在时间超过三天(时间可配置)，master巡检时会将其删除。在此之前，仍然可以用特殊名称来读取文件，并且可以重命名为正常名称来取消删除。当从namesapce中删除隐藏文件时，其内存元数据将被删除，这有效切断了所有chunk的连接，在对chunk namespace的扫描中，master识别出孤立的chunk并清除元数据。在心跳信息中，每个chunkserver报告其拥有的chunks子集，而master将回应不在存在于master元数据中的所有的chunk的标识。chunkserver可以自由删除此类chunk的副本。

这种gc机制相比立即删除有以下几个优点：

这种机制主要的缺点是当存储空间紧张时，延迟有时会影响用户的使用，重复创建和删除临时文件的应用可能无法立即重用存储。如果删除的文件再次被明确删除，GFS将通过加快存储回收来解决这些问题。还允许用户将不同的复制和回收策略应用于不同的namespace的不同部分中。

如果一个chunkserver故障或者chunk丢失了mutations，这个chunk副本可能是过期的。对于每个chunk，master都维护了一个chunk版本号。

当master授权租约给一个chunk时，这个chunk的版本号增加1，如果一个副本当前不可用了，则其版本号将不会领先。当chunkserver重新启动并报告其chunks集合和相关联的版本号时，master将检测到该chunkserver上具有过期的副本。如果master看到的版本号大于它记录的版本号，则认为在授权租约时失败了，因此将较高的版本号更新。

master在常规gc中删除旧的副本。另一个保护措施，在master回应客户端哪个chunk持有租约或者clone操作中chunkserver从另一个chunkserver读取chunk时会包含chunk的最新版本号。客户端或者chunkserver在执行操作时会验证版本号。

这个系统最大的挑战之一是处理经常故障的组件。组件的质量和数量造成的问题会超出预期，组件故障可能造成系统不可能，甚至数据错误。接下来讨论GFS如何应对这些挑战，还有系统如何诊断不可避免问题。

使用两个简单有效的方式保证系统的高可用：快速恢复和复制。 master和chunkserver的恢复都是秒级别的。 master维护每个chunk的副本数量，当chunkserver下线或者checksum检测出错误副本时，master会通过已有副本来复制。尽管复制提供了很好的解决方式，但仍在探索其它形式的跨服务器冗余方案，例如奇偶校验或者纠删码，以适应不断增长的只读存储需求。在非常松耦合的系统中实现这些更复杂的冗余方案更具有挑战性。

master的操作日志和checkpoint会被复制到多台机器上，状态的变化只有在本地和所有副本上都持久化以后才可以commit。master进程负责所有的mutations以及后台任务，当它宕机时可以很快重启，如果机器或者磁盘故障，GFS的外部监控将使用日志在其它节点重启新的master进程。在master宕机时，master的备节点只提供只读服务，它们不与master保持强一致，可能会落后于master，通常在1/4秒内。它们保证了那些不介意读到过期数据的应用的高可用读。类似于chunk的primary机制，master的备按照相同的序列应用日志。与master一样，在启动时从每个chunkserver拉取chunks的位置信息，与它们频繁交换握手消息来监控其状态。

每个chunkserver使用checksum来检测存储数据的损坏。数据损坏的chunk可以通过其它的副本来恢复，但是通过副本间比较来检验数据是不切实际的。正常的副本也不是完全一样的，如前文所讲，原子的append并不能保证完全一样的副本。因此每个chunkserver会维护自己的checksum。每个chunk分为多个64kb的blocks，每个block包含一个32位的checksum，与其它元数据一样，checksum保存在内存中，依靠log持久化，与用户数据分离。

对于读，chunkserver在返回数据给请求者前先检测checksum，确保不会将出错的数据传输给其它chunkservers或者客户端。如果数据是坏的，chunkserver将错误返回给请求者并报告给master，请求者将会去读其它副本， master将会根据其它副本重新克隆一份。当新的副本创建以后，master指示chunkserver将错误的副本删除。checksum的计算不涉及I/O，对读的影响比较小，客户端通常尝试使用对齐block边界读来减少overhead。

为append写是做了checksum计算上的优化的，因为append写是主要的负载(相比于overwrite)。GFS只增量地更新最后部分block的checksum，为新的block的计算新的checksum。这样即使block已经损坏，新的checksum将与存储的数据不会匹配，下次读时将会与正常一样被检测出来。如果一个写请求要写一个chunk中已存在的region，必要要先检验region的第一个和最后一个block的checksum，然后再重写，最后计算新的checksums。因为第一个和最后一个block可能含有不被重写的内容，如果这部分数据是损坏的，则新的checksum将包含错误的数据。

在idle时，checkserver可以扫描并检查不活跃的chunks，可以检测到冷chunks的错误，一旦错误被检测到，master可以创建一个新的副本。

GFS在设计上与传统文件系统有很多不同，这些点是基于对当时应用负载和技术环境的观察所重新设计，将组件故障看作平常的事件而非异常，为大文件的读取和追加写做优化，扩展和放宽了标准的文件系统接口以改善整个系统。通过监控、复制以及快速恢复能力提供容错能力，使用checksum机制来校验数据的正确性。通过将控制流和数据流分离，数据直接在chunkservers、客户端之间传输，为许多并发的各种任务的读取和写入提供了高吞吐量。大chunk size和租约机制使得master的操作足够轻量化，使得这样一个简单中心化的master不会成为瓶颈。

GFS成功地满足了google的存储需求，作为研究、开发和数据处理的存储平台广泛地应用于google内部。

GFS：Google File System HDFS：Hadoop Distribute File System 首先，有一点要确认的是，作为GFS的一个最重要的实现，HDFS设计目标和GFS是高度一致的。在架构、块大小、元数据等的实现上，HDFS与GFS大致一致。但是，在某些地方，HDFS与GFS又有些不同。如：1、快照（Snapshot）： GFS中的快照功能是非常强大的，可以非常快的对文件或者目录进行拷贝，并且不影响当前操作（读/写/复制）。GFS中生成快照的方式叫copy-on-write。也就是说，文件的备份在某些时候只是将快照文件指向原chunk，增加对chunk的引用计数而已，等到chunk上进行了写操作时，Chunk Server才会拷贝chunk块，后续的修改操作落到新生成的chunk上。而HDFS暂时并不支持快照功能，而是运用最基础的复制来完成。想象一下，当HBase上的数据在进行重新划分时（过程类似于hash平衡），HDFS需要对其中的所有数据（P/T级的）进行复制迁移，而GFS只需要快照，多不方便！2、记录追加操作（append）：在数据一致性方面，GFS在理论上相对HDFS更加完善。 a) GFS提供了一个相对宽松的一致性模型。GFS同时支持写和记录追加操作。写操作使得我们可以随机写文件。记录追加操作使得并行操作更加安全可靠。 b) HDFS对于写操作的数据流和GFS的功能一样。但是，HDFS并不支持记录追加和并行写操作。NameNode用INodeFileUnderConstruction属性标记正在进行操作的文件块，而不关注是读还是写。DataNode甚至看不到租约！一个文件一旦创建、写入、关闭之后就不需要修改了。这样的简单模型适合于Map/Reduce编程。3、垃圾回收（GC）： a) GFS垃圾回收采用惰性回收策略，即master并不会立即回收程序所删除的文件资源。 GFS选择以一种特定的形式标记删除文件（通常是将文件名改为一个包含时间信息的隐藏名字），这样的文件不再被普通用户所访问。Master会定期对文件的命名空间进行检查，并删除一段时间前的隐藏文件（默认3天）。 b) HDFS并没有采用这样的垃圾回收机制，而是采取了一种更加简单但是更容易实现的直接删除方式。 c) 应该说延迟回收和直接删除各有优势。延迟回收为那些“不小心“的删除操作留了后路。同时，回收资源的具体操作时在Master结点空闲时候完成，对GFS的性能有很好的提高。但是延迟回收会占用很大的存储空间，假如某些可恶的用户无聊了一直创建删除文件怎么办？试分析下这种不同。有人说，GFS在功能上非常完善，非常强大，而HDFS在策略上较之简单些，主要是为了有利于实现。但实际上，GFS作为存储平台早已经被广泛的部署在Google内部，存储Google服务产生或者要处理的数据，同时用于大规模数据集的研究与开发工作。因此GFS并不仅仅是理论上的研究，而是具体实现。作为GFS的后辈与开源实现，HDFS在技术上应该是更加成熟的，不可能为了“偷懒”而简化功能。因此，简化说应该是不成立的。个人认为，GFS与HDFS的不同是由于“专”与“通”的区别。众所周知，Hadoop是一个开源软件/框架，在设计之初就考虑到了用户（面向世界上的所有个人、企业）在需求上的差异，比如数据密集型（如淘宝的数据存储）、计算密集型（百度的PR算法）、混合型等等。而GFS在设计之初就对目标比较明确，都是Google的嘛，因此GFS可以对其主要功能进行性能上的优化。说到这里，突然想起了某件事。曾经某个公司的Boss吹牛B：“我不关心J2EE，实际上在大公司里面用J2EE的很少，都有自己的一些框架。测试过了，我们在用自己开发的框架时候性能就是以前用J2EE的时候的7倍左右。”唬的我一跳一跳的，好牛啊！！后来想了一下，其实不是这个公司技术比SUN要强，而是J2EE是一个开源框架，其应用范围非常广，因此不能做到面面俱到。而他们公司自己开发的框架肯定是对其主要业务逻辑方面做了专门的优化和改进，甚至删除了或者弱化了许多对他们来说作用不大的模块。貌似这个和GFS与HDFS的关系好像！！

gfs论文发表是在

国家智库论文一般在中国期刊网发表。《国家智库》杂志是由中华人民共和国新闻出版总署、正式批准公开发行的优秀期刊，自创刊以来，被公认誉为具有业内影响力的杂志之一。

gfs论文发表于哪年

随着大数据分析市场迅速渗透到各行各业，大家对大数据的关注度也越来越高，大数据技术是什么？

1.Hadoop

Hadoop确实是现在着名的大数据技术.

从2003年到2004年，谷歌发表了GFS、Mapreduce和BigTable三篇技术论文(这几篇论文成为云计算、大数据领域发展的重要基础).

当时，由于公司破产在家的程序员DougCutting基于前两篇论文，开发了简化的山寨版GFS——HDFS和基于MapReduce的计算框架.这是Hadoop当初的版本.

之后，Cutting被Yahoo雇佣，依靠Yahoo的资源改善Hadoop，为Apache开源社区做出贡献.

简要说明Hadoop原理:数据分布式存储，运算程序分别发送到各数据节点进行运算(Map)，合并各节点的运算结果(Reduce)，产生结果.

对于移动TB级数据，计算程序一般为KB--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

在其诞生近十年来，Hadoop以其简单、易用、高效、免费、社区支持丰富等特点成为许多企业云计算、大数据实施的优先事项.

2.Storm

Hadoop很好，但有死穴.其一，其运算模式是批处理.这对许多有实时要求的业务没有很好的支持.

你说的产品再列举一下吧，看不到产品，没法给你确定

大数据分析相关的基本解决方案，主要包括Hadoop简介、大数据分析概述、基于MapReduce的大数据处理、Python-Hadoop科学计算和大数据分析、R-Hadoop统计数据计算、Apache Spark批处理分析、Apache Spark实时数据分析、Apache Flink批处理分析、Apache Flink流式处理、大数据可视化技术、云计算简介、使用亚马逊Web服务等内容。

想学习大数据技术，是不是首先要知道大数据技术有哪些呢？也好知道自己未来应该往哪个方向发展，应该重点学习哪些知识？抽象而言，各种大数据技术无外乎分布式存储 + 并行计算。具体体现为各种分布式文件系统和建立在其上的并行运算框架。这些软件程序都部署在多个相互连通、统一管理的物理或虚拟运算节点之上，形成集群(cluster)。因此不妨说，云计算是大数据的基础。下面介绍几种当前比较流行的大数据技术：1.HadoopHadoop无疑是当前很知名的大数据技术了。2003年到2004年间，Google发布了关于GFS、MapReduce和BigTable三篇技术论文(这几篇论文成为了后来云计算、大数据领域发展的重要基石)。当时一位因公司倒闭赋闲在家的程序员Doug Cutting根据前两篇论文，开发出了一个简化的山寨版GFS – HDFS,以及基于其的MapReduce计算框架，这就是Hadoop当初的版本。后来Cutting被Yahoo雇佣，得以依赖Yahoo的资源改进Hadoop,并将其贡献给了Apache开源社区。简单描述Hadoop原理：数据分布式存储，运算程序被发派到各个数据节点进行分别运算(Map)，再将各个节点的运算结果进行合并归一(Reduce)，生成结果。相对于动辄TB级别的数据，计算程序一般在KB – MB的量级，这种移动计算不移动数据的设计节约了大量网络带宽和时间，并使得运算过程可以充分并行化。在其诞生后的近10年里，Hadoop凭借其简单、易用、高效、免费、社区支持丰富等特征成为众多企业云计算、大数据实施的首选。2.StormHadoop虽好，却有其“死穴”.其一：它的运算模式是批处理。这对于许多有实时性要求的业务就无法做到很好的支持。因此，Twitter推出了他们自己的基于流的运算框架——Storm。不同于Hadoop一次性处理所有数据并得出统一结果的作业(job)，Storm对源源导入的数据流进行持续不断的处理，随时得出增量结果。3.SparkHadoop的另一个致命弱点是：它的所有中间结果都需要进行硬盘存储，I/O消耗巨大，这就使得它很不适合多次迭代的运算。而大多数机器学习算法，恰恰要求大量迭代运算。2010年开始，UC Berkeley AMP Lab开始研发分布式运算的中间过程全部内存存储的Spark框架，由此在迭代计算上大大提高了效率。也因此成为了Hadoop的强有力竞争者。4.NoSQL 数据库NoSQL数据库可以泛指非关系型数据库，不过一般用来指称那些建立在分布式文件系统(例如HDFS)之上，基于key-value对的数据管理系统。相对于传统的关系型数据库，NoSQL数据库中存储的数据无需主键和严格定义的schema。于是，大量半结构化、非结构化数据可以在未经清洗的情况下直接进行存储。这一点满足了处理大量、高速、多样的大数据的需求。当前比较流行的NoSQL数据库有MongoDB,Redis,Cassandra,HBase等。NoSQL并不是没有SQL,而是不仅仅有(not only)SQL的意思。为了兼容之前许多运行在关系型数据库上的业务逻辑，有很多在NoSQL数据库上运行SQL的工具涌现出来，典型的例如Hive和Pig,它们将用户的SQL语句转化成MapReduce作业，在Hadoop上运行。大数据产业已进入发展的“快车道”，急需大量优秀的大数据人才作为后盾。能够在大数据行业崛起的初期进入到这个行业当中来，才有机会成为时代的弄潮儿。