后使用快捷导航没有帐号？
查看: 1208|回复: 10
谁了解hadoop bigtable的原理？那如果要增加或修改数据结构是不是很麻烦？
注册会员, 积分 111, 距离下一级还需 89 积分
论坛徽章:1
谁了解hadoop bigtable的原理？那如果要增加或修改数据结构是不是很麻烦？
新手上路, 积分 3, 距离下一级还需 47 积分
论坛徽章:1
Bigtable看起来像一个数据库，采用了很多数据库的实现策略。但是Bigtable并不支持完整的关系型数据模型；而是为客户端提供了一种简单的数据模型，客户端可以动态地控制数据的布局和格式，并且利用底层数据存储的局部性特征。Bigtable将数据统统看成无意义的字节串，客户端需要将结构化和非结构化数据串行化再存入Bigtable。
注册会员, 积分 111, 距离下一级还需 89 积分
论坛徽章:1
注册会员, 积分 111, 距离下一级还需 89 积分
论坛徽章:1
自己贴点资料吧
HBase是一个分布式的、面向列的开源数据库，该技术来源于Chang et al所撰写的Google论文“Bigtable：一个结构化数据的分布式存储系统”。就像Bigtable利用了Google文件系统（File System）所提供的分布式数据存储一样，HBase在Hadoop之上提供了类似于Bigtable的能力。HBase是Apache的Hadoop项目的子项目。HBase不同于一般的关系数据库，它是一个适合于非结构化数据存储的数据库。另一个不同的是HBase基于列的而不是基于行的模式。
注册会员, 积分 111, 距离下一级还需 89 积分
论坛徽章:1
http://www.oschina.net/p/hbase/
注册会员, 积分 111, 距离下一级还需 89 积分
论坛徽章:1
/tag/hbase
注册会员, 积分 111, 距离下一级还需 89 积分
论坛徽章:1
/taxonomy/term/85
注册会员, 积分 111, 距离下一级还需 89 积分
论坛徽章:1
HBase数据库性能调优
.cn/showcontent_49606.htm
注册会员, 积分 111, 距离下一级还需 89 积分
论坛徽章:1
http://www.alidata.org/archives/1509
中级会员, 积分 468, 距离下一级还需 32 积分
论坛徽章:1
还没接触到，等接触到了再来评价hadoop什么意思_百度知道
hadoop什么意思
hadoop是一款开源软件，主要用于分布式存储和计算，他由HDFS和MapReduce计算框架组成的，他们分别是Google的GFS和MapReduce的开源实现。由于hadoop的易用性和可扩展性，因此成为最近流行的海量数据处理框架。hadoop这个单词来源于其发明者的儿子为一个玩具大象起的名字。
其他类似问题
为您推荐：
没有任何意思，一个软件的名称，是创始人的儿子在玩玩具大象时候嘴里嘟憨储封肥莩堵凤瑟脯鸡囔的声音。分布式计算的基础框架，基于Google的Map/Reduce论文的Java实现版，类似的还有HyperTable和BigTable
hadoop的相关知识
等待您来回答
下载知道APP
随时随地咨询
出门在外也不愁十年回顾：Hadoop老矣，尚能饭否？
(window.slotbydup=window.slotbydup || []).push({
id: '2611110',
container: s,
size: '240,200',
display: 'inlay-fix'
您当前位置： &
[ 所属分类
作者 红领巾 ]
Hadoop，十岁生日快乐！
于日诞生的它改变了企业对数据的存储、处理和分析的过程，加速了大数据的发展，形成了自己的极其火爆的技术生态圈，并受到非常广泛的应用。InfoQ特别策划了系列文章，为大家梳理Hadoop这十年的变化，以及技术圈的生态状况，这是为Hadoop庆生的第一篇。
一张图回顾Hadoop十年
什么是大数据？
大数据指的是规模超过现有数据库工具获取、存储、管理和分析能力的数据集，并同时强调并不是超过某个特定数量级的数据集才是大数据。
by 麦肯锡《大数据：创新、竞争和生产力的下一个前沿领域》
大数据的定义聚焦在“大“。从表面上看，数据规模的增长的确为处理数据带来了很大的问题。具体来说，在同样时间内获取与以前相同价值的数据变得不可为了。换言之，本质问题是数据的价值密度变低了，数据交换速率变慢了，所以催生了很多新型数据处理技术和工具，如Google的GFS和MapReduce，Apache Hadoop生态系统，美国伯克利大学AMPLab的Spark等；出现了对时间敏感程度不同的计算模式，如批式计算模式、交互式计算模式、流计算模式、实时计算模式等。计算模式的差异只是决定获取价值的技术不同，取决于上层业务需求的不同。
实际上，所谓大数据问题的本质应是数据的资产化和服务化，而挖掘数据的内在价值是研究大数据的最终目标。
大数据缘起于Google
Google在搜索引擎上所获得的巨大成功，很大程度上是由于采用了先进的大数据管理和处理技术，是针对搜索引擎所面临的日益膨胀的海量数据存储问题以及在此之上的海量数据处理问题而设计的。
Google提出了一整套基于分布式并行集群方式的基础架构技术，利用软件的能力来处理集群中经常发生的节点失效问题。Google使用的大数据平台主要包括五个相互独立又紧密结合在一起的系统：分布式资源管理系统Borg，Google文件系统（GFS），针对Google应用程序的特点提出的MapReduce 编程模式，分布式的锁机制Chubby以及大规模分布式数据库BigTable。
Borg是这五个系统中最为神秘的一个，直到2015年Google才在EuroSys 2015上发表了题为“Large-scale cluster management at Google with Borg”的论文。称Google内部不仅像计算型的应用，比如MapReduce、Pregel等运行在Borg上，存储类的应用，比如GFS，BigTable和Megastore等也运行在上面，真正做到了批处理作业和长周期服务的混合部署和资源动态调度。得益于此项技术，可以使平均资源利用率达到30%~75%以上，大大高于业界平均水平的6%~12%。
GFS是一个大型的分布式文件系统，它为Google云计算提供海量存储，并且与Chubby、MapReduce和BigTable等技术结合得十分紧密，处于系统的底层。它的设计受到Google特殊的应用负载和技术环境的影响。相对于传统的分布式文件系统，为了达到成本、可靠性和性能的最佳平衡，GFS从多个方面进行了简化。
MapReduce是处理海量数据的并行编程模式，用于大规模数据集的并行运算。MapReduce通过“Map（映射）”和“Reduce（化简）”这样两个简单的概念来参加运算。用户只需要提供自己的Map 函数以及Reduce 函数就可以在集群上进行大规模的分布式数据处理。这一编程环境能够使程序设计人员编写大规模的并行应用程序时不用考虑集群的可靠性、可扩展性等问题。应用程序编写人员只需要将精力放在应用程序本身，关于集群的处理问题则交由平台来完成。与传统的分布式程序设计相比，MapReduce封装了并行处理、容错处理、本地化计算、负载均衡等细节，具有简单而强大的接口。正是由于MapReduce具有函数式编程语言和矢量编程语言的共性，使得这种编程模式特别适合于非结构化和结构化的海量数据的搜索、挖掘、分析等应用。
Chubby是提供粗粒度锁服务的一个文件系统，它基于松耦合分布式文件系统，解决了分布式系统的一致性问题。这种锁只是一个建议性的锁而不是强制性的锁。通过使用Chubby的锁服务，用户可以确保数据操作过程中的一致性。GFS使用Chubby来选取一个GFS主服务器，BigTable使用Chubby指定一个主服务器并发现、控制与其相关的子表服务器。
大规模分布式数据库BigTable是基于GFS和Chubby开发的分布式存储系统。很多应用程序对于数据的组织是非常有规则的。一般来说，数据库对于处理格式化的数据还是非常方便的。但是由于关系数据库要求很强的一致性，很难将其扩展到很大的规模。为了处理Google内部大量的格式化以及半格式化数据，Google构建了弱一致性要求的大规模数据库系统BigTable。BigTablede在很多方面和数据库类似，但它并不是真正意义上的数据库。Google包括Web索引、卫星图像数据等在内的很多海量结构化和半结构化数据都是存储在BigTable中的。
开启了大数据时代的大门
Google的技术虽好但不开源。如果没有Doug Cutting和他的Hadoop开源软件，我们就看不到如今大数据技术和应用的飞速发展。
Doug Cutting主导的Apache Nutch项目是Hadoop软件的源头，该项目始于2002年，是Apache Lucene 的子项目之一。当时的系统架构尚无法扩展到存储并处理拥有数十亿网页的网络化数据。Google在2003年于SOSP上公开了描述其分布式文件系统的论文“The Google File System”，为Nutch提供了及时的帮助。2004年，Nutch的分布式文件系统(NDFS)开始开发。同年，Google在OSDI上发表了题为“MapReduce: Simplified Data Processing on Large Clusters”的论文，受到启发的Doug Cutting等人开始实现MapReduce计算框架并与NDFS（Nutch Distributed File System）结合起来，共同支持Nutch的主要算法。至2006年，它逐渐成为一套完整而独立的软件，已经到Yahoo!工作的Doug Cutting将这套大数据处理软件命名为Hadoop。2008年初，Hadoop成为Apache的顶级项目，除Yahoo!之外在众多互联网企业中得到应用。
早期的Hadoop，包括Hadoop v1以及更早之前的版本，主要由两个核心组件构成：HDFS和MapReduce，其中HDFS是Google GFS的开源版本，MapReduce计算框架实现了由Google工程师提出的MapReduce编程模型。还有一些围绕在Hadoop周围的开源项目，为完善大数据处理的全生命周期提供了必要的配套和补充。这些软件常用的有ZooKeeper、Hive、Pig、HBase、Storm、Kafka、Flume、Sqoop、Oozie、Mahout等。2012年5月，Hadoop v2的alpha版本发布，其中最重要的变化是在Hadoop核心组件中增加了YARN（Yet Another Resource Negotiator）。YARN的出现是为了把计算框架与资源管理彻底分离开，解决Hadoop v1由此带来的扩展性差、单点故障和不能同时支持多种计算框架的问题。YARN对标的恰好就是Google的Borg系统。至此，Hadoop方才能够与Google的大数据平台比肩。
一个好的、有生命力的开源生态系统要有一个核心，这个核心要是差异化和非平凡的，还要有广泛的应用和活跃的社区。Hadoop恰好具备这三个特征，以Hadoop为核心的大数据开源生态系统逐渐形成，Hadoop也成为自以来最成功的开源软件，没有之一。受人民大学信息学院院长杜小勇老师的委托，我在CNCC 2015上组织了一个名为“大数据开源生态系统”的论坛。论坛邀请了来自互联网企业、硬件厂商、系统集成商以及学术界的同行分享在大数据开源方面的工作和体会。在最后的Panel环节，讨论了为什么要做开源和怎么做开源这两个问题。回答是比较分散的，有开源是唯一选择的，有拉通产业链的，有认为开源是新业态新商业模式的，有认为开源促进技术进步的。总之，在产业链不同的环节上的机构做开源的动机和目标自然是不同的，但只有这样，产业链中不同角色都能够在生态系统中找到自己的位置，这样的生态系统才是健壮的有生命力的，不是吗？
发展历史和应用之路
大数据领域第一个吃螃蟹的是互联网行业。这是因为大数据概念和技术都来源于互联网企业的老大哥Google的原因。以Hadoop投入实际应用来看：
2006年到2008年是Hadoop的诞生阶段。只有国外少数几个互联网巨头在尝试，国内互联网行业在学习这项新技术。2006年，Yahoo!构建100节点规模的Hadoop机群用于Webmap业务。2007年，Yahoo!构建1000节点规模的Hadoop机群。2008年，Yahoo!的Hadoop机群扩展到2000节点规模，Facebook贡献Hive项目到开源社区。
2008年到2010年是Hadoop的少年阶段。在互联网行业已经开始投入实际应用，应用集中在网页存储检索，日志处理和用户行为分析等方面。2009年，Yahoo!使用4000节点的机群运行Hadoop，支持广告系统和Web搜索的研究；Facebook使用600节点的机群运行 Hadoop，存储内部日志数据，支持其上的数据分析和机器学习；百度用Hadoop处理每周200TB的数据，进行搜索日志分析和网页数据挖掘工作。2010年，Facebook的Hadoop机群扩展到1000节点；百度用Hadoop每天可处理1PB的数据；中国移动通信研究院基于Hadoop开发了“大云”（BigCloud）系统，不但用于相关数据分析，还对外提供服务；淘宝的Hadoop系统达到千台规模，用于存储并处理电子商务的交易相关数据。
2010年到2015年是Hadoop的青年阶段。在互联网行业无不将Hadoop作为大数据计算的标准配置，且应用形式趋于多样化；企业计算领域开始实践基于Hadoop的大数据应用；在追求大数据处理能力的同时，也开始思考系统适配性和效率问题。互联网行业出现了大量数据分析类应用，比如支付宝的交易数据离线分析系统等；用Hadoop与生态系统中的其他软件一起构成更为复杂的应用系统，比如腾讯的广点通精准广告投放系统，电信运营商的基于用户画像的精准营销系统等。除互联网行业外，出现了网络通讯大数据、金融大数据、交通旅游大数据、工业制造大数据、医疗健康大数据、社会治理大数据、教育大数据等，大数据理念和技术已经融入各行各业。Hadoop源于互联网行业，在应用于企业计算时，需要进行适配，原因在于互联网应用和企业计算应用在需求、服务、研发和运维体系方面有本质的不同。互联网应用业务逻辑简单、服务于海量用户、非固定使用人群、系统的用户体验至上、持续交付、能够快速响应的专业运维；而企业计算应用业务逻辑复杂、有限数量用户、固定使用人群、系统更强调稳定可靠、版本交付、层级式的技术支持。一时间市面上出现了很多面向企业用户的Hadoop发行版，以易部署、好配置，以及使用和管理方便为切入点，吸引着企业用户的眼球。
5、Hadoop in China
国内最早的Hadoop交流平台
技术推广是需要平台的，而好的交流平台对新技术的落地起到极其重要的作用。2008年，我所在的研究小组想在分布式数据存储方面做一些研究工作，前期调研阶段接触到Hadoop，其新颖的设计思想得到大家的一致认同，2008年11月Hadoop技术沙龙顺势成立，后来发展成Hadoop in China大会。
2012年，中国计算机学会（CCF）于10月正式成立了大数据专家委员会。2013年，大会正式更名为“中国大数据技术大会(BDTC)”。至此，Hadoop in China从60人规模的小型沙龙发展到国内大数据领域一年一度最重要的技术会议之一。大会曾邀请到包括Hadoop创始人Doug Cutting，Spark创始人Ion Stoica在内的众多国际著名专家到会做特邀报告。
大数据技术的发展趋势
系统架构的专业化。从当今IT技术的发展角度看，提出系统结构上的解决方案是“应用驱动的大数据架构与技术”。也就是说根据具体类型应用的需求，在系统架构和关键技术上进行创新。为了降低成本并获得更好的能效，大数据应用系统越来越趋向扁平化、专用化的系统架构和数据处理技术，逐渐摆脱了传统的通用技术体系。比如并行数据库更鲜明的分化为面向事务处理的OLTP类数据库和面向分析的OLAP类数据库等。传统的应用服务器、数据库服务器和存储服务器这样的典型三层架构受到极大的冲击。应用开发人员更深入的理解计算机系统结构，“程序” = “算法” + “数据结构”将逐渐演变成“程序” = “算法” + “数据结构” + “系统结构”。
大数据生态系统范围扩大。克隆了Google的GFS和MapReduce的Apache Hadoop自2008年以来逐渐为互联网企业接纳，并成为大数据处理领域的事实标准。但2013年出现的Spark作为一匹黑马可以说终结了这一神话，大数据技术不再一家独大。由于应用不同导致Hadoop一套软件系统不可能满足所有需求，在全面兼容Hadoop的基础上，Spark通过更多的利用内存处理大幅提高系统性能。此外，Scribe、Flume、Kafka、Storm、Drill、Impala、TEZ/Stinger、Presto、Spark/Spark SQL等的出现并不是取代Hadoop，而是扩大了大数据技术生态环境，促使生态环境向良性和完整发展。今后在非易失存储层次、网络通信层次、易失存储层次和计算框架层次还会出现更多、更好和更专用化的软件系统。
系统整体效能更为用户重视。在全球互联网企业的努力下，Hadoop已经可以处理百PB级的数据，在不考虑时间维度的前提下，价值密度低的数据可以处理了。在解决了传统关系型数据库技术无法处理如此量级的数据之后，业界正在向系统能效要价值。能效问题一方面体现在系统性能上。互联网服务强调用户体验，原本做不到实时的应用在向实时化靠拢，比如前端系统及业务日志从产生到收集入库的延迟从1到2天时间进化到10秒以内。传统企业无法忍受关系数据库动辄几十分钟的查询分析性能，纷纷求助于性价比更好的技术和产品。这些需求使大数据交互式查询分析、流式计算、内存计算成为业界研发和应用的新方向。能效问题的另一方面体现在系统功耗和成本上。中科院计算所陈云霁研究员领导研究的专用神经网络处理器技术，可大幅加速机器学习负载，与通用芯片和GPU相比，计算速度提高几十倍，功耗只有十分之一，整体能效提高450倍。百度云存储万台定制ARM服务器可节电约25%，存储密度提升70%，每瓦特计算能力提升34倍（用GPU取代CPU计算），每GB存储成本降低50%。
个性化服务的需求愈发强烈。个性化对应于互联网服务的长尾部分，这部分需求在传统的系统设计中因为复杂性原因是被舍弃的，但正是这部分体现出个性化服务的需求。个性化服务，即系统能够提供满足不同个体需求的差异化服务，比如个性化推荐，广告精准投放等。就拿个性化推荐技术来说，目前已经开始从简单的商品推荐走向复杂的内容推荐。根据用户的特性与偏好，推荐内容的特征，以及当时的上下文数据（客户端设备类型、用户所处时空数据等），向特定用户提供个性化的内容推荐服务，内容包括商品（包括电商和零售）、广告、新闻和资讯等。在移动设备和移动互联网飞速发展的时代，个性化推荐将成为用户获取信息最直接的渠道之一。
价值挖掘的理论和技术亟待发展。对数据进行浅层分析的理论和技术，主要体现在分布式系统和关系型数据库理论的结合与再创新，目前已经有较大幅度进展。但是，从数据中抽取隐含的信息或者知识，也就是价值挖掘，这方面的理论和技术还比较缺乏。一是缺乏成熟的数据挖掘建模方法和工具，经验对于挖掘出有价值信息的影响甚大，原始数据与隐含信息之间存在技术缺失，所以“啤酒+尿布”的案例并不是天天都能产生的。二是机器学习和深度学习技术面临应用问题。与大数据相结合，已经在诸如语音识别、图像识别、广告推荐和风险控制等场景中得以初步应用，但这方面的技术和软件工具成熟度不高，还有很大提升空间。此外，机器学习和深度学习的应用场景还不够广泛，这既是机遇也是挑战。
Hadoop老矣，尚能饭否？
Hadoop开源软件自2006年起至今已经走过十个年头，这对于任何软件来说生命周期不可谓不长。但是，Hadoop也在经历来自其他开源黑马的冲击。Spark在早期发展阶段通过全面兼容Hadoop而借力于后者成熟的生态系统。时至今日，Spark正在挑战Hadoop的权威，因为Spark已经将发展目标定位在取代Hadoop。Hadoop老矣，尚能饭否？Hadoop的近100位Committer在积极的为Hadoop谋划未来，让我们拭目以待吧！
查礼，2003年博士毕业以来一直从事分布式系统的研发工作，现为中国科学院计算技术研究所副研究员，CCF大数据专家委员会委员。自2008年起与Apache Hadoop、Hive以及HBase 等开源社区密切合作，相关大数据技术研究成果通过软件开源在业界得到广泛应用。是中国大数据技术大会（原Hadoop in China）发起人和组织者。
欢迎加入本站公开兴趣群
软件开发技术群
兴趣范围包括：Java，C/C++，，Ruby，shell等各种语言开发经验交流，各种框架使用，外包项目机会，学习、培训、跳槽等交流
Hadoop源代码研究群
兴趣范围包括：Hadoop源代码解读，改进，优化，分布式系统场景定制，与Hadoop有关的各种开源项目，总之就是玩转Hadoop
转载请注明本文标题：本站链接：
分享请点击：
1.凡CodeSecTeam转载的文章,均出自其它媒体或其他官网介绍,目的在于传递更多的信息,并不代表本站赞同其观点和其真实性负责；
2.转载的文章仅代表原创作者观点,与本站无关。其原创性以及文中陈述文字和内容未经本站证实,本站对该文以及其中全部或者部分内容、文字的真实性、完整性、及时性，不作出任何保证或承若；
3.如本站转载稿涉及版权等问题,请作者及时联系本站,我们会及时处理。
登录后可拥有收藏文章、关注作者等权限...
没有代价的安逸未必是幸福。
手机客户端
，专注代码审计及安全周边编程，转载请注明出处：http://www.codesec.net
转载文章如有侵权，请邮件 admin[at]codesec.netBigTable与Hbase比较
BigTable与Hbase比较
[摘要：转的文章 尽人皆知，HBase是Google的BigTable架构的一个开源完成。然则我小我认为，要做到充沛懂得上面两面照样有面艰苦的： 一 HBase涵盖了BigTable范例的哪些局部？ 两 HBase取BigTable依然有]
转的文章众所周知，HBase是Google的BigTable架构的一个开源实现。但是我个人觉得，要做到充分了解下面两点还是有点困难的：一 HBase涵盖了BigTable规范的哪些部分？二 HBase与BigTable仍然有哪些区别？下面我将对这两个系统做些比较。在做比较之前，我要指出一个事实：HBase是非常接近BigTable论文描述的东西。撇开一些细微的不同，比如HBase 0.20使用ZooKeeper做它的分布式协调服务，HBase已经基本实现了BigTable所有的功能，所以我下面的篇幅重点落在它们细微的区别上，当然也可以说是HBase小组正在努力改进的地方上。比较范围本文比较的是基于七年前发表的论文（OSDI’06）所描叙的Google BigTable系统,该系统从2005年开始运作。就在论文发表的2006年末到2007年初，作为Hadoop的子项目的HBase也产生了。在那时，HBase的版本是0.15.0. 如今大约2年过去了，Hadoop 0.20.1和HBase 0.20.2都已发布，你当然希望有一些真正的改进。要知道我所比较的是一篇14页的技术论文和一个从头到脚都一览无余的开源项目。所以下面的比较内容里关于HBase怎么做的讲得比较多点。在文章的结尾，我也会讨论一些BigTable的如今的新功能，以及HBase跟它们比较如何。好，我们就从术语开始。术语有少数几个不同的术语被两个系统用来描述同样的事物。最显著的莫过于HBase中的regions和BigTable中的tablet。自然地，它们各自把一连串的行（Rows）切分交给许多Region server或者tablet server管理。特性比较接下来的就是特性比较列表，列表中是BigTable跟HBase的特性比较。有的是一些实现细节，有的是可配置的选项等。让人感到有困惑的是，将这些特性分类很难。&&特性说明读&&写&&修改的原子性支持，每行支持，每行因为&&不像关系型数据库，所以不支持事务。最 接近事务的就是让对每行数据访问具有原子性。&&同样实现了”行锁”的&&，让用户访问数据时给一行或 者几行数据加锁。词典顺序的行排序支持支持所有行都按照词典顺序排序数据块支持支持支持在数据存储文件中，数据是由更小的数据块构成的。这使从大的存储文件读取数据更快。数据块的大小是可 配置的，典型配置是&&。数据块压缩支持，按支持，按&使用&&和&&做两步处理。&&工作得很好是因为存储文件中相邻的&&对的内容经常非常相似。因为数据支持多个版本，几个版本的内容会被排序然后被存在一起，它们之间有很 多相同的内容。或者&&也会被用这样的方式处理，比如如果用&&来作为&，而这些&&来自统一个网站，那么&&也会有很多相似之 处。&&使用的是改进的&&算法。&&使用的是&&支持的标准的&&，以及一点点&&格式支持。&&也有想使用&&和&&的征兆。&数量限制最多几百小于&理论上行数和列数是无限的，可是列族（&&）却不是。这个只是设计上的一些折中考率&命名格式可打印可打印&这样做的主要原因是&&的名称会被作为文件 系统中的目录名称&命名的格式任意任意任意的字节数组&对的格式任意任意任意的字节数组访问控制支持无&支持&&级别的访问控制。&&暂不支持多版本支持支持多版本支持是基于时间戳。&版本数目限制可以基于&&级别自 由配置自定义时间戳支持支持两个系统都支持用户设定时间戳，如果用户不指定，则 使用当前时间作为时间戳。数据&支持支持除了数据可以有多个版本，用户还可制定&&（&&），当数据到期后会被清除批量写入支持支持都支持批量表操作值计数器支持支持两者都可使用特定的列作为原子计数器。&&实现是：当计数器的值要增长时，它必须获得行锁。行过滤器支持支持两者都支持扫描行时支持行过滤器客户端脚本执行支持不支持&使用&&使客户端可以处理存储的数据。支持支持支持两者都有方便的工具类让&&扫描 表。底层文件系统&工作在&&之上，&&可以使用任何文件系统，只要有该文件系统的代理或者驱动即可。存储文件格式块索引在文件最后在文件最后两者都有相似的块结构化的存储文件格式，并且块索引 被放在文件的最后内存映射支持不支持&可以让存储文件直接映射到内存。锁服务&被&&用来协调任务并非当成锁服务。总体说来，&使用&&达到了&&使用&&的效果，只有语义有点细微区别。单个&是不是&近来支持多个&&。多个&&是”热”待命模式工作，它们都侦听&上的&&节点。数目两个系统都推荐每个&&分配相同数目的&&。当然这决定于很多因素，由于两个系统都使用普通电脑，出于负载考虑，它们推荐相同的数目大小在两个系统中，单个&&大小是可配置的，在&&中，默认大小为位置&会使用一个只有单个&&的自身表来存储&&表。二者启动时都会把&&所在机器的 地址放到&&或者&&中。客户端&信息缓存支持不支持二者客户端都支持&&位置信息缓存并且有相应的机制去除 过时的缓存和更新缓存预读支持不支持（？）&的一个设计就是会预读超过&&个&&信息并将之放入客户端缓存。&事件记录支持支持&相关事件（切分，分配，再分配）都会记录在&&表中存储位置分组（&&）支持不支持这不是很确定，但是看起来&&中的任何东西都有 个位置分组的属相。如果多个列族的位置分组相同，那么它们将被存放在一起，并且拥有相同的配置参数。单个列族就可能是一个拥有一个成员的位置分组。&不支持这种选项，并将不同的列族分开存储。完全内存&存储支持支持这是为需要高速存取小表准备的缓存支持不支持缓存热点&&数据数据块缓存支持支持数据块从存储文件读入到在可配置的缓存中布隆过滤器支持支持这些过滤器会消耗一些内存，但是可以快速检查一个指定的&&是否在一个&&上存在支持支持每个&&都会记录被它管理的所有&&上的数据改动支持不支持出于性能考虑，一旦&&性能下降，&&还有别的&&可以使用忽略&？支持在大量数据导入时，&&的客户端可以选择忽略&快速&切分支持支持切分&&是快速的，因为切分出来的子&&暂时还会去读取原存储文件直到一个&&将数据写入&&的自有的存储文件&BigTable 新特性OSDI’06 BigTable论文发表已有几年，BigTable当然也有改进。杰夫.迪恩—一个在Google的家伙在近来的一些演讲和演示中提到了 BigTable的新特性。我们就来瞧瞧部分新特性吧。&&&&特性说明客户端隔离支持不支持&可以内在地被用来服务很多单独的客户端，并且使它们的数据隔离不互相影响协同处理（&）支持暂不支持&在&&中运行的代码可以随着&&的被切分，代码也被会切分到新的&&上运行。数据错误安全支持不支持&使用&&校验码确认数据是否被安全写入。&&没有这个特性，问题是：&&是否会包含这个特性？数据中心间数据复制支持暂不支持&的一个&&：&就是关于这个特性的。&&变化和差异上面讨论的一些特性比较可以看出有些特性差异并不是可以简单归结为”是或否”类的问题，对这类问题我将在下面单独探讨。锁服务下面的来自BigTable论文&BigTable用Chubby来完成一些不同的任务：保证在任何时候只有一个活动的Master；存储BigTable引导区地址；发现tablet server以及在table server死亡时做善后工作；存储BigTable的schema信息（每个表的列族信息）；存储访问控制列表。如果Chubby在一段较长的时候变得不可用，那么BigTable系统就会变得不可用。&BigTable如何使用Chubby跟HBase如何使用ZooKeeper有很多异曲同工之处。但有一个区别就是：HBase并不把 Schema信息存储在ZooKeeper中。它们都非常依赖锁服务的正常运作。根据我自身的经验以及我阅读HBase邮件列表所得到的，我们经常低估当 ZooKeeper无法取得足够的资源去作出实时回应时的后果。宁可让ZooKeeper集群运行在相对较老旧的但是什么别的事都不干的机器上，而不是运 行在已被Hadoop或者HBase进程搞得不堪重负的机器上。一旦你的ZooKeeper没有足够的资源提供服务，就会引发多米诺骨式的效 应，HBase将会挂掉—包括master节点。&更新：在跟ZooKeeper开发小组讨论后，我想指出的是这并不真正意义上是ZooKeeper的一个问题。因为如果运行ZooKeeper的机 器负荷很重，那么存取ZooKeeper上的资源很可能会超时。在这种情形下，HBase的Region Server甚至Master可能会认为协调服务已经坏了，它们就会让自己停工关闭。&&帕特里克&.&亨特已经 通过邮件和发帖对此作出回应。你可以读他的邮件或者帖子，然后检查自己的ZooKeeper&是否有能力处理负荷。我个人建议是 将&ZooKeeper&集群跟&HBase&集群分开。你可以把&ZooKeeper&集群运行在一组空闲的稍微有点过时 但是性能还相当不错的机器上。这样你可以单独监控&ZooKeeper&集群和&HBase&集群中的机器，而不必有以下的烦恼：当一个机器的&CPU&负荷&100%&的 时候，你搞不清楚这个负荷究竟来自哪个进程或者有什么后果。&另外一个重要区别是：&ZooKeeper&并不是一个像&Chubby&一样的锁服务系统，但是目前为止，这并不是&HBase&所 关心的。&ZooKeeer提供一个分布式的协调服务，让&HBase&可以选举出&Master&节 点。它也可以提供用以表示状态或者某个动作需要的信号量。当&Chubby生成一个锁文件来表示一个&tablet&活动的，与此相对应的一个&Region server&会在&ZooKeeper&中生成一个节点来表示自己的存在。这个节点创建以后，只要&ZooKeeper&不挂，它会一直存在。在&BigTable&中，当一个&tablet server&的锁文件被删除时就表示与这个&tablet server&的租约失效。在&HBase&中，因为&ZooKeeper&相对少点限制的架构，这种行为会被处理得有所不同。它们只是语义上有所差别，并不意味着谁优谁劣，仅仅有所不同而已。&在Chubby中，第一层级的文件包含着根tablet的位置信息。根tablet包含着一个特别的名叫METADATA（元数据）表的所有的tablet的位置信息。每个METADATA的tablet包含着一组用户表的tablet的位置信息。根tablet仅仅是METADATA表中第一个tablet，但是它被特别的看待—它从不会被切分，这是为了保证tablet的位置层级不会超过3层。&就如上面所说的，在HBase中，根region是一个只有单个region的表。要说有什么区别的话，那就是根region并不是meta表中的第一个 不可切分的region。它们是相同的功能，只是实现上有差别。&METADATA表存储着tablet的位置信息，跟在起始row key和末尾row key以及表名之后。&HBase的做法有点不同，它也会为每个region存储起始的row key和末尾row key，但是末尾的row key并不是属于当前的region的，它会是另一个region的起始row key.&Master的行为&为了侦测一个tablet server是否不再为它的tablets服务，master会定期地查看每个tablet server锁文件的状态。当一个tablet server报告它丢失了锁文件，或者master经过几次尝试后未能联系上tablet server, master就会尝试在tablet server的锁文件上获得独占锁。如果master可以获得这个锁，还有Chubby是良好工作的，这时如果tablet server已经死亡或者已经把错误上报给Chubby，这时master就可以确定该tablet server不可能恢复，于是会删除它的锁文件。一旦一个tablet server的锁文件被删除，本来被该tablet server服务的tablets会被移到没被分配的tablets集合中去。为了保证master和Chubby之间网络畅通，只要master的Chubby session过期，master将会自杀。&直到0.20.2版本，HBase的行为都相当不同。Region server利用heartbeat协议给master定期报告，master接到报告就知道region server还活着。&Master启动&Master启动有以下步骤：（1）Master从Chubby中获取唯一的master锁，用来防止多个master的初始化（2）Master 扫描Chubby中的server目录找到活动的server.(3) Master跟多个活动的tablet server通讯，收集tablets的分配情况（4）Master扫描METADATA表得知所有的tablets集合。（4）Master如果发现有tablet并没有分配到tablet server，它会将之放入未被分配tablets集合，这样这个tablet就会被认为是可以被分配的。&就如我上面提到的，HBase实际上会等待所有的region server上报它负责的region情况。当然，它也会扫描.META. 表去了解有哪些region以及它们是分配到哪些region server上了。ZooKeeper仅仅用来发布-ROOT- region所在的region server的地址。&Tablet/Region切分&在切分通知被丢失时（因为tablet server挂了或者master挂了）的情况下，当master要求tablet server装载被切分的那个tablet时，master会发现新的tablet. Tablet server会将此次切分通知master，因为它会发现在METADATA中找到的tablet只是master要求它装载的tablet的一部分。&Master节点会单独利用.META.表去发现一个region去切分，但是切分事件消息被丢失的情况。Master会按往常一样扫描.META.去发 现，哪些region并没有被分配。一旦发现没有被分配的region，master会用默认的策略将之分配到一个region server上。&压紧（Compaction）随着写动作的执行，内存表的大小会不断增长。当内存表的容量到达一个临界点时，内存表将被冻结，一个新的内存表将会被创建，被冻结的内存表将被会转换成SSTable并被写入到GFS中。这种minor compaction操作有2个目的：1降低tablet server的内存用量，2当一个tablet server死而复生从commit log读取数据时，减少数据总量。当压紧动作发生时，认可继续执行读写操作。&HBase也有相应的操作，不过被命名为”flush”。对应BigTable的”minor compaction”，HBase会把最近生成的很多较小的存储文件重写为一个包含较多数据的大文件。&…我们将限制此类文件的数目，方式是定期地在后台执行合并压紧操作。合并压紧操作就是读取几个SSTable和内存表的内容，然后写到一个新的SSTable中去。一旦合并压紧操作完成，老的SSTable和内存表就将可被丢弃。&这个动作跟HBase中的”minor compaction”差不多。&读取所有的SSTable，重新写成一个SSTable的合并压紧操作被称为是major compaction&相应的在HBase中，一个major compaction就是把所有的存储文件(HFile)重写成一个新的文件。&文件不可修改要知道文件一旦被写入将不能修改，BigTable有如下的假定：唯一可以被修改的数据结构就是读写都可以的内存表（memtable）。为了避免同时读写内存表的冲突，我们在写内存表的数据行的时候，会先复制一个副本，这样读写就可以并行处理了。&我相信HBase中的做法跟此类似，但不是很确定。可以确定是，根据HDFS的架构，文件一旦被写入就是不能被修改的。我唯一的建议就是你自己去阅读BigTable的相关资料以形成自己的见解。这篇帖子的灵感来自一个念头：BigTable究竟实现了哪些特 性，HBase涵盖了BigTable的哪些特性？写这片帖子的困难毫无疑问是我们对BigTable的细节所知不多。但是关于它的论文数量–即便是 2006年的论文列表都给人留下难以磨灭的印象。HBase作为一个开源项目，而且项目的贡献者是为数不多的有着全职工作的人，现在虽不能说跟 BigTable相提并论，但怎么说都我都认为现在的成果是一个巨大的成就。看看0.21和0.22的路线图，将来它们之间不大的差距将会变得更加缩小。
感谢关注 Ithao123Hadoop频道，是专门为互联网人打造的学习交流平台，全面满足互联网人工作与学习需求，更多互联网资讯尽在 IThao123!
Laravel是一套简洁、优雅的PHP Web开发框架(PHP Web Framework)。它可以让你从面条一样杂乱的代码中解脱出来；它可以帮你构建一个完美的网络APP，而且每行代码都可以简洁、富于表达力。
Hadoop是一个由Apache基金会所开发的分布式系统基础架构。
用户可以在不了解分布式底层细节的情况下，开发分布式程序。充分利用集群的威力进行高速运算和存储。
Hadoop实现了一个分布式文件系统（Hadoop Distributed File System），简称HDFS。HDFS有高容错性的特点，并且设计用来部署在低廉的（low-cost）硬件上；而且它提供高吞吐量（high throughput）来访问应用程序的数据，适合那些有着超大数据集（large data set）的应用程序。HDFS放宽了（relax）POSIX的要求，可以以流的形式访问（streaming access）文件系统中的数据。
Hadoop的框架最核心的设计就是：HDFS和MapReduce。HDFS为海量的数据提供了存储，则MapReduce为海量的数据提供了计算。
产品设计是互联网产品经理的核心能力，一个好的产品经理一定在产品设计方面有扎实的功底，本专题将从互联网产品设计的几个方面谈谈产品设计
随着国内互联网的发展，产品经理岗位需求大幅增加，在国内，从事产品工作的大部分岗位为产品经理，其实现实中，很多从事产品工作的岗位是不能称为产品经理，主要原因是对产品经理的职责不明确，那产品经理的职责有哪些，本专题将详细介绍产品经理的主要职责
IThao123周刊}