云计算关键技术

云计算关键技术郑伟平2011-7-26Google云计算

位于俄勒冈州的Google数据中心

位于俄勒冈州的Google数据中心

Google自制的服务器MapReduceMapReduce是一个简单易用的并行编程模型，它极大简化了大规模数据处理问题的实现Page

4DivideandConquer“Work”w1w2w3r1r2r3“Result”“worker”“worker”“worker”PartitionCombineParallelizationChallengesHowdoweassignworkunitstoworkers?Whatifwehavemoreworkunitsthanworkers?Whatifworkersneedtosharepartialresults?Howdoweaggregatepartialresults?Howdoweknowalltheworkershavefinished?Whatifworkersdie?Whatisthecommonthemeofalloftheseproblems?CommonTheme?Parallelizationproblemsarisefrom:Communicationbetweenworkers(e.g.,toexchangestate)Accesstosharedresources(e.g.,data)Thus,weneedasynchronizationmechanismManagingMultipleWorkersDifficultbecauseWedon’tknowtheorderinwhichworkersrunWedon’tknowwhenworkersinterrupteachotherWedon’tknowtheorderinwhichworkersaccessshareddataThus,weneed:Semaphores(lock,unlock)Conditionalvariables(wait,notify,broadcast)BarriersStill,lotsofproblems:Deadlock,livelock,raceconditions...Diningphilosophers,sleepybarbers,cigarettesmokers...Moralofthestory:becareful!CurrentToolsProgrammingmodelsSharedmemory(pthreads)Messagepassing(MPI)DesignPatternsMaster-slavesProducer-consumerflowsSharedworkqueuesMessagePassingP1P2P3P4P5SharedMemoryP1P2P3P4P5MemorymasterslavesproducerconsumerproducerconsumerworkqueueBut,nowMapreduce!Mapreduce:Parallel/DistributedComputingProgrammingModelInputsplitshuffleoutputTypicalproblemsolvedbyMapReduce读入数据:

key/value

对的记录格式数据Map:从每个记录里extractsomethingmap(in_key,in_value)->list(out_key,intermediate_value)处理inputkey/valuepair输出中间结果key/valuepairsShuffle:混排交换数据把相同key的中间结果汇集到相同节点上Reduce:aggregate,summarize,filter,etc.reduce(out_key,list(intermediate_value))->list(out_value)归并某一个key的所有values，进行计算输出合并的计算结果(usuallyjustone)输出结果MapreduceFrameworkMapreduceFrameworkShuffleImplementationPartitionandSortGroupPartitionfunction:hash(key)%reducernumberGroupfunction:sortbykeyExampleuses:distributedgrep

distributedsort

weblink-graphreversalterm-vector/hostwebaccesslogstatsinvertedindexconstructiondocumentclusteringmachinelearningstatisticalmachinetranslation.........ModelisWidelyApplicable

MapReduceProgramsInGoogleSourceTree

GoogleMapReduceArchitectureSingleMasternodeManyworkerbeesManyworkerbeesMapReduceOperationInitialdatasplitinto64MBblocksComputed,results

locallystoredMsendsdata

locationtoRworkersFinaloutputwrittenMasterinformedof

resultlocationsExecutionoverview1.InputfilesaresplitintoMpieces(16to64MB)Manyworkercopiesoftheprogramareforked.2.Onespecialcopy,themaster,assignsmapandreducetaskstoidleslaveworkers3.Mapworkersreadinputsplits,parse(key,value)pairs,applythemapfunction,createbufferedoutputpairs.4.Bufferedoutputpairsareperiodicallywrittentolocaldisk,partitionedintoRregions,locationsofregionsarepassedbacktothemaster.5.Masternotifiesreduceworkeraboutlocations.Workerusesremoteprocedurecallstoreaddatafromlocaldisksofthemapworkers,sortsbyintermediatekeystogroupsamekeyrecordstogether.

Executionoverviewcont’6.Reduceworkerpasseskeypluscorrespondingsetofallintermediatedatatoreducefunction.Theoutputofthereducefunctionisappendedtothefinaloutputfile.7.Whenallmapandreducetasksarecompletedthemasterwakesuptheuserprogram,whichresumestheusercode.FaultTolerance:workersmaster保持一些数据结构。它为每个map和reduce任务存储它们的状态(空闲，工作中，完成)，和worker机器(非空闲任务的机器)的标识。Masterpingsworkersperiodically.Noresponse:workermarkedasfailed.Completedmaptasksareresettoidlestate,sothattheycanberestarted,becausetheirresults(localtofailedworker)arelost.Completedreducetasksdonotneedtobere-started(outputstoredinglobalfilesystem).Reducetasksarenotifiedofthenewmaptasks,sotheycanreadunreaddatafromthenewlocations.FaultTolerance:MasterMasterwritescheckpointsOnlyonemaster,lesschanceoffailureIfmasterfailes,MapReducetaskaborts.Refinement:RedundantExecutionSlowworkerssignificantlydelaycompletiontimeOtherjobsconsumingresourcesonmachineBaddisksw/softerrorstransferdataslowlySolution:Nearendofphase,spawnbackuptasks

Whicheveronefinishesfirst"wins"DramaticallyshortensjobcompletiontimeRefinement:LocalityOptimization

Masterschedulingpolicy:AsksGFSforlocationsofreplicasofinputfileblocksMaptaskstypicallysplitinto64MB(GFSblocksize)MaptasksscheduledsoGFSinputblockreplicaareonsamemachineorsamerack

EffectThousandsofmachinesreadinputatlocaldiskspeedWithoutthis,rackswitcheslimitreadrateRefinement:SkippingBadRecords

Map/Reducefunctionssometimesfailforparticularinputs

Bestsolutionistodebug&fixNotalwayspossible~third-partysourcelibrariesOnsegmentationfault:SendUDPpackettomasterfromsignalhandlerIncludesequencenumberofrecordbeingprocessedIfmasterseestwofailuresforsamerecord:Nextworker

istoldtoskiptherecord

CompressionofintermediatedataCombiner“Combiner”functionscanrunonsamemachineasamapperCausesamini-reducephasetooccurbeforetherealreducephase,tosavebandwidthLocalexecutionfordebugging/testingUser-definedcountersOtherRefinementsHadoopMapReduceArchitectureMaster/WorkerModelLoad-balancingbypollingmechanismNodes,Trackers,TasksMasternoderunsJobTrackerinstance,whichacceptsJobrequstfromclientsTaskTrackerinstancesrunonslavenodesTaskTrackerforksseparateJavaprocessfortaskinstancesPage

28HistoryofHadoop2004-InitialversionsofwhatisnowHadoopDistributedFileSystemandMap-ReduceimplementedbyDougCutting&MikeCafarellaDecember2005-Nutchportedtothenewframework.Hadooprunsreliablyon20nodes.January2006-DougCuttingjoinsYahoo!

February2006-ApacheHadoopprojectofficialstartedtosupportthestandalonedevelopmentofMap-ReduceandHDFS.March2006-FormationoftheYahoo!HadoopteamMay2006-YahoosetsupaHadoopresearchcluster-300nodes

April2006-Sortbenchmarkrunon188nodesin47.9hoursMay2006-Sortbenchmarkrunon500nodesin42hours(betterhardwarethanAprilbenchmark)October2006-Researchclusterreaches600Nodes

December2006-Sorttimes20nodesin1.8hrs,100nodesin3.3hrs,500nodesin5.2hrs,900nodesin7.8January2006-Researchclusterreaches900node

April2007-Researchclusters-2clustersof1000nodes

Sep2008-ScalingHadoopto4000nodesatYahoo!April2009–release0.20.0,manyimprovements,newfeatures,bugfixesandoptimizations.分布式文件系统分布式文件系统特点和基本要求缓存容错和可扩展性Page

30312023/10/12分布式文件系统的特点和基本要求分布式文件系统的特点

为整个网络上的文件系统资源提供了一个逻辑树结构，用户可以抛开文件的实际物理位置，仅通过一定的逻辑关系就可以查找和访问网络的共享资源。用户能够像访问本地文件一样，访问分布在网络中多个服务器上的文件。分布式文件系统的顾客、服务员和存储设备分散在各机器上，服务活动必须跨网完成。存储设备不是单一的集中数据存储器。分布式文件系统的具体配置和实现可以有很大的不同，有的服务员运行在专用的服务器上，有的机器既是服务员又是顾客。322023/10/12分布式文件系统的特点和基本要求分布式文件系统的基本要求透明性位置透明性：服务员和存储器的多重性和分散性对顾客透明。移动透明性：用户意识不到资源的移动。性能透明性：当服务负载在一定范围内变化时，客户程序可以保持满意的性能。扩展透明性：文件服务可以扩充，以满足负载和网络规模的增长。 性能分布式文件系统比常规文件系统类似（有时更好）的性能和可靠性332023/10/12容错为了处理暂时的通信错误，容错设计可以基于最多一次性语义无状态的服务器:崩溃重启时不需恢复安全性身份验证，访问控制，安全通道效率：应提供比传统文件系统相同或更强的性能和可靠性分布式文件系统的特点和基本要求342023/10/12分布式文件系统的缓存缓存方案的设计需要考虑的问题：缓存的单位问题存储部分文件的位置如何决定各个顾客缓存中的数据是否一致352023/10/12分布式文件系统的缓存缓存的粒度和地点缓存的粒度：如果数据单元(即粒度)愈大，则下次访问的数据在顾客方的本地找到的可能性愈大，但传送数据的时间和一致性问题也增加了。反之，粒度太小，通信的开销也随之增加。缓存的地点在一个各自有主存和磁盘的客户-服务器系统中，有四个地方可以用来存储文件或存储部分文件：服务器磁盘、服务器主存、客户磁盘（如果可用的话）或者客户主存。362023/10/12分布式文件系统的缓存更新策略、缓存有效性检验和一致性判定本地缓存的数据副本是否与原本一致，有两个基本方法验证其有效性：顾客发动的方法。顾客与服务员联系，检查本地数据与原本是否一致。这个方法的关键是有效性检验的频度。服务员发动的方法。服务员为每个顾客登记被该顾客缓存的文件或文件的某个部分。当服务员检测出可能不一致时，必须做出反应。服务员发动方法的一个问题是违背顾客/服务员模型372023/10/12容错和可扩充性可用性与文件复制可恢复性：当对某个文件的操作失败，或由顾客夭折此操作时，如果文件能转换到原来的一致状态，则说此文件是可恢复的。坚定性：如果当某个存储器崩溃和存储介质损坏时某个文件能保证完好，则说此文件是坚定的。可用性：如果无论何时一旦需要就可访问，甚至在某个机器和存储器崩溃，或者在发生通信失效的情况下，某个文件仍然可被访问，则这种文件叫做是可用的。382023/10/12容错和可扩充性可用性与文件复制文件复制：文件复制是一个冗余措施。这里指的是不同机器上的文件复制，而不是同一机器上不同介质上的文件复制(如镜像磁盘)。文件复制的原因通过对每个文件的独立备份来增加系统的可靠性。当一个文件服务器出现问题时，仍允许进行文件访问；将工作量分配到多个服务器上，避免运行性能上的瓶颈。392023/10/12容错和可扩充性可用性与文件复制用户需要了解文件复制到何种程度吗？在文件复制进程中需要达到什么要求呢？文件复制的要求：应对用户隐匿复制细节。把一份复制件名字变换成指定的复制件是命名方案的任务。与复制件有关的主要问题是它们的更新。从用户观点看，文件的所有复制品代表同一逻辑实体，所以对任何复制件的更新必须反映到所有其他复制件。大多数情况下，不能放弃文件数据的一致性，因此使用复制来增加可用性时还要使用复杂的更新传播协议。402023/10/12容错和可扩充性可扩充性设计大规模系统要考虑的问题：首先是有界资源(boundedresources)原理：“从系统的任何部分来的服务要求应该限于一个常数，此常数和系统中的节点数无关”。负载和系统规模成比例的任何服务员，一旦系统扩充到超过某一范围则必然阻塞，再增加资源也缓解不了这个问题。广播是一种使网络中的每个机器都参加的活动。在广播基础上建立的机构对超大型系统很明显不实际。网络拥挤和延迟是大规模系统的主要障碍。使用缓存和实施放松的共享语义，使跨机器的交互作用最少。

412023/10/12容错和可扩充性可扩充性设计大规模系统要考虑的问题：不应当使用集中控制方案和集中的资源建立可扩充的和容错的系统。分散化的一个重要方面是系统的管理。分配管理职责时，应有利于自治性和对称性，不干扰分布式系统的连贯性和一致性。将系统划分为若干半自治的小组。每个小组包括一些机器和一个专用的小组服务员。为了尽量减少跨越小组的文件访问，大多数时间，每个机器的请求应由其小组服务员满足。HDFS（HadoopDistributedFileSystem）Hadoop分布式文件系统(HDFS)被设计成适合运行在通用硬件(commodityhardware)上的分布式文件系统。它和现有的分布式文件系统有很多共同点。但同时，它和其他的分布式文件系统的区别也是很明显的。HDFS是一个高度容错性的系统，适合部署在廉价的机器上。HDFS能提供高吞吐量的数据访问，适合大规模数据集上的应用。HDFS放宽了一部分POSIX约束，来实现流式读取文件系统数据的目的。Page

42GoalsofHDFSVeryLargeDistributedFileSystem –10Knodes,100millionfiles,10PB

AssumesCommodityHardware –Filesarereplicatedtohandlehardwarefailure –DetectfailuresandrecoversfromthemOptimizedforBatchProcessing –Datalocationsexposedsothatcomputationscanmovetowheredataresides –ProvidesveryhighaggregatebandwidthUserSpace,runsonheterogeneousOSHDFS采用master/slave架构。一个HDFS集群是由一个Namenode和一定数目的Datanodes组成。Namenode是一个中心服务器，负责管理文件系统的名字空间(namespace)以及客户端对文件的访问。Namenode执行文件系统的名字空间操作，比如打开、关闭、重命名文件或目录。它也负责确定数据块到具体Datanode节点的映射。集群中的Datanode一般是一个节点一个，负责管理它所在节点上的存储。HDFS暴露了文件系统的名字空间，用户能够以文件的形式在上面存储数据。从内部看，一个文件其实被分成一个或多个数据块，这些块存储在一组Datanode上。Datanode负责处理文件系统客户端的读写请求。在Namenode的统一调度下进行数据块的创建、删除和复制。Page

45DistributedFileSystemSingleNamespaceforentireclusterDataCoherency –Write-once-read-manyaccessmodel –ClientcanonlyappendtoexistingfilesFilesarebrokenupintoblocks –Typically128MBblocksize –EachblockreplicatedonmultipleDataNodesIntelligentClient –Clientcanfindlocationofblocks –ClientaccessesdatadirectlyfromDataNodeNameNodeMetadataMeta-datainMemory –Theentiremetadataisinmainmemory –Nodemandpagingofmeta-dataTypesofMetadata –Listoffiles –ListofBlocksforeachfile –ListofDataNodesforeachblock –Fileattributes,e.gcreationtime,replicationfactorATransactionLog –Recordsfilecreations,filedeletions.EtcNamenode全权管理数据块的复制，它周期性地从集群中的每个Datanode接收心跳信号和块状态报告(Blockreport)。集群中单一Namenode的结构大大简化了系统的架构。Namenode是所有HDFS元数据的仲裁者和管理者，这样，用户数据永远不会流过Namenode。DataNodeABlockServer –Storesdatainthelocalfilesystem(e.g.ext3) –Storesmeta-dataofablock(e.g.CRC) –Servesdataandmeta-datatoClientsBlockReport –PeriodicallysendsareportofallexistingblockstotheNameNodeFacilitatesPipeliningofData –ForwardsdatatootherspecifiedDataNodesBlockPlacementCurrentStrategy

--Onereplicaonlocalnode --Secondreplicaonaremoterack --Thirdreplicaonsameremoterack --AdditionalreplicasarerandomlyplacedClientsreadfromnearestreplicaWouldliketomakethispolicypluggablePage

50在大多数情况下，副本系数是3HDFS的存放策略是将一个副本存放在本地机架的节点上，一个副本放在同一机架的另一个节点上，最后一个副本放在不同机架的节点上。这种策略减少了机架间的数据传输，这就提高了写操作的效率。机架的错误远远比节点的错误少，所以这个策略不会影响到数据的可靠性和可用性。于此同时，因为数据块只放在两个（不是三个）不同的机架上，所以此策略减少了读取数据时需要的网络传输总带宽。在这种策略下，副本并不是均匀分布在不同的机架上。三分之一的副本在一个节点上，三分之二的副本在一个机架上，其他副本均匀分布在剩下的机架中，这一策略在不损害数据可靠性和读取性能的情况下改进了写的性能。DataCorrectnessUseChecksumstovalidatedata –UseCRC32FileCreation –Clientcomputeschecksumper512byte –DataNodestoresthechecksumFileaccess –ClientretrievesthedataandchecksumfromDataNode –IfValidationfails,ClienttriesotherreplicasNameNodeFailureAsinglepointoffailureTransactionLogstoredinmultipledirectories –Adirectoryonthelocalfilesystem –Adirectoryonaremotefilesystem(NFS/CIFS)Page

53HDFS未实现的功能总结：

1、

文件追加写入，这个功能近期内不会实现，没有这个功能会引起当文件尚未关闭的时候，数据服务器死机或者目录服务器死机，会引起文件文件丢失，并且不可后续恢复写入。

2、

系统快照，一个全系统的快照功能，如果没有这个功能就不能实现文件系统的回滚操作。

3、

集群负载均衡，均衡策略暂时没有实现，有几个策略十分有用，比如在某台数据机可能磁盘过低的时候，把该数据机上面的一些数据转移到还有很多空间剩余的数据机上；当某个文件突然被大量读写的时候，动态增加该文件的冗余因子，并且数据块复制到更多的数据机上面，以提高读取性能。

4、

文件系统的用户权限，这个也是近期内不会实现的了。

5、访问权限，现在是无限制访问的，没有访问权限控制。

分布式数据库技术定义特点分类体系结构分片与分布模式结构事务模型分布式数据库的定义分布式数据库的定义通俗地说是物理上分散而逻辑上集中的数据库系统。使用计算机网络将地理位置分散而管理和控制又需要不同程度集中的多个逻辑单位连接起来，共同组成一个统一的数据库系统。可以看作是数据处理即数据库系统和计算机网络技术的结合。分布式数据库的特点物理分布性逻辑整体性，不同于分散式数据库，有全局数据库和局部数据库的概念。站点自治性：场地自治，各站点数据由本地DBMS管理，具有自治处理能力，完成本地应用。这一点与多机系统不同。数据分布透明性：分片透明、数据复制透明、数据位置透明。集中与自治相结合的控制机制：局部共享和全局共享一定的数据冗余：可靠、可用，单个站点故障不会影响整体。不利于更新，维护成本高，查询速度快。事务管理的分布性：全局事务可以分解为若干子事务。事务的ACID特性受到考验。分布式数据库的特点分布式数据库的12条准则本地自治性不依赖于中心站点可连续操作性位置独立性数据分片独立性数据复制独立性分布式查询处理分布式事务处理硬件独立性操作系统独立性网络独立性数据库管理系统独立性单个DBMS的本地运算不受多数据库系统中其它DBMS的加入而影响。单个DBMS处理查询和优化查询的方式不受访问多数据库的全局查询执行的影响。系统已执行或操作在单个DBMS加入或离开多数据库联盟时不受危害。分布式数据库的分类按局部数据库管理系统的数据模型分类同构型（homogenous）DDBS：数据模型相同同构同质型：各站点上的数据模型（关系、网状、层次）相同，且都是同一种DBMS。同构异质性：各站点上的数据模型（关系、网状、层次）相同，但不是同一种DBMS。异构型（heterogenous）DDBS：各站点上的数据模型不同。分布式数据库的分类按分布式数据库系统的全局控制类型分类全局控制集中型DDBS：全局控制机制和全局数据字典位于一个中心点，中心点完成全局事务的协调和局部数据库的转换全局控制分散型DDBS：全局控制机制和全局数据字典位于各个站点上，每个站点都能完成全局事务的协调和局部数据库的转换，每个站点既是全局事务的协调者，也是参与者。全局控制可变型DDBS：主从型DDBS，站点有两类：主站点和从站点，主战点上包含全局控制机制和全局数据字典；辅助站点不包含全局控制机制和全局数据字典分布式数据库系统的体系结构全局用户局部用户GDDGDBLDDLDBCMGDBMSLDBMS全局用户局部用户GDDGDBLDDLDBCMGDBMSLDBMS全局用户局部用户GDDGDBLDDLDBCMGDBMSLDBMS网络包括：局部DB、全局DB局部DBMS和全局DBMS局部DBA和全局DBA局部数据字典LDD和全局数据字典GDD通信模块CM分片：又称为数据分割，有三种分片方式水平分片：按特定条件将全局关系划分成若干互不相交的片段。通过对全局关系进行选择运算得到。垂直分片：把全局关系的属性集分成若干子集。通过对全局关系进行投影运算获得。混合分片：上述两种方法的混合。分片规则完备性条件：不多，即全局关系的所有数据必须映射到各个片段中，不允许有属于全局关系的数据不属于它的任何一个片段。可重构条件：不少，即必须保证能够由同一个全局关系的各个片段来重构该全局关系。水平：合并垂直：连接不相交条件：一个全局关系被分割后所得的各个数据片段不重叠。分布式数据库中的分片与分布分布：根据需要将数据划分成逻辑片段，按照某种策略将这些片段分散存储在各个站点上，策略：集中式：所有数据片段放在同一个站点上。对数据控制和管理容易数据一致性和完整性能够得到保证系统对数据站点依赖过重数据站点故障将导致整个系统崩溃检索效率低分割式：所有数据只有一份，经过逻辑分割后形成多个片段，每个片段放在某个特定的站点上。充分利用各个站点的存储能力每个站点可自治检索和修改数据，并发能力强部分站点故障，系统仍能运行，可靠性高全局查询和修改，响应时间长，网络通信代价较大全复制式：全局数据有多个副本，每个站点上都有一个完整的数据副本。可靠性高查询速度快数据同步困难系统冗余大混合式：全部数据被分为若干个子集，每个子集安置在不同的站点上，但任一站点都不保存全部数据。灵活性好系统效率高复杂分布式数据库系统的模式结构全局DBMSDB局部内模式局部概念模式DB局部内模式局部概念模式局部DBMS分配模式分片模式全局概念模式全局外模式全局外模式全局外模式集中式数据库分布式数据库全局外模式：全局应用的用户视图。全局概念模式：描述分布式数据库中全局数据的逻辑结构和数据特性，是分布式数据库的全局概念视图。分片模式：描述全局数据的逻辑划分。分配模式：根据选定的数据分配策略，定义各片段的物理存放位置，确定是否冗余及冗余的程度。局部概念模式：是全局概念模式的子集，由分配在同一站点上的一个或多个逻辑片段组成局部内模式：是分布式数据库关于物理数据库的描述，跟集中式内模式类似，但是不仅包含本站点数据的存储描述，还包括全局数据在本站点的存储描述全局关系R的逻辑片段与物理影像69分布式事务模型事务的ACID局部事务、全局事务局部事务管理器保证本地节点上执行的事务的ACID本次事务可能是全局事务的一部分维护一个易于恢复的日志参与适当的并发控制事务协调器协调该节点上发起的事务（全局或局部）的执行启动事务的执行分发事务协调事务的终止（在所有节点上提交或中止）分布式事务模型70TC1TCnTMnTM1事务管理器事务协调器71故障节点故障消息丢失网络故障提交原子性事务T必须要么在所有节点上提交，要么在所有节点上都中止两阶段提交三阶段提交72两阶段提交阶段1（决定阶段）协调器prepareT节点事务管理器readyT或abortT阶段2（执行阶段）收到有一个abortT,则abortT收到所有readyT,则commitT节点commitT并写Log后，发出acknowledgeT收到所有acknowledge，则completeT阻塞：协调器发出prepareT后故障，处于不定状态双方针对超时均可重发73三阶段提交阶段1同两阶段方式阶段2收到有一个abortT,则abortT收到所有readyT,则precommitT节点precommitT之后，写Log，发出acknowledgeT阶段3收到所有ack，则commitT节点commit后，发出ackT收到所有ackT后，completeT恢复只要有一个具有commitT,则提交只要有一个precommitT,已readyT，可提交都没有收到precommitT，则回滚74协议的比较两阶段提交有阻塞的可能，使用较广三阶段提交对于网络链路故障的处理能力偏弱HbaseHbase是一个分布式开源数据库，基于Hadoop分布式文件系统，模仿并提供了基于Google文件系统的Bigtable数据库的所有功能。为什么需要HBASE数据库系统已无法适应大型分布式数据存储的需要改良的关系数据库（副本、分区等）难于安装与维护关系模型对数据的操作使数据的存贮变得复杂主要特点HBASE从设计理念上就为可扩展做好了充分准备Column-oriented空间的扩展只需要加入存储结点使用‘表’的概念，但不同于关系数据库，不支持SQL它又不适合事务处理实质上是一张极大的、非常稀疏的，存储在分布式文件系统上的表Page

75Page

76HBase历史2006年底由PowerSet的ChadWalters和JimKellerman发起2008年成为ApacheHadoop的一个子项目现已作为产品被使用WorldLingoSOpenPlacesYahooAdobeHBASE用例－WebTable存储抓取网页和相关信息每个页面对应一行，是个有百万行的大表要基于此表进行分析与解析并由搜索引擎对关键字进行索引表需要并发地被众多网页抓取程序随机地访问以及更新数据表内容也要作为网页实时缓存被大量用户随机访问逻辑视图RowKeyTimeStampColumnContentsColumnAnchorColumn“mime”my.look.ca“n.www”T9CNNT8CNN.COMT6“<html>..“Text/htmlT5“<html>..“t3“<html>..“RowKeyRowKey与nosql数据库们一样,rowkey是用来检索记录的主键。访问hbasetable中的行，只有三种方式：1通过单个rowkey访问2通过rowkey的range3全表扫描Rowkey行键(Rowkey)可以是任意字符串(最大长度是64KB，实际应用中长度一般为10-100bytes)，在hbase内部，rowkey保存为字节数组。存储时，数据按照Rowkey的字典序(byteorder)排序存储。设计key时，要充分排序存储这个特性，将经常一起读取的行存储放到一起。(位置相关性)注意：行的一次读写是原子操作(不论一次读写多少列)。这个设计决策能够使用户很容易的理解程序在对同一个行进行并发更新操作时的行为。

Page

80数据模型－行每行数据有一可排序的关键字和任意列项字符串、整数、二进制串甚至与串行化的结构都可以作为行键表按照行键的“逐字节排序”顺序对行进行有序化处理表内数据非常‘稀疏’，不同的行的列的数完全目可以大不相同可以只对一行上“锁”对行的写操作是始终是“原子”的数据模型－行RowKeyTimeStampColumnContentsColumnAnchorColumn“mime”my.look.ca“n.www”T9CNNT8CNN.COMT6“<html>..“Text/htmlT5“<html>..“t3“<html>..“行键列列数据模型－列列必须用‘族’(family)来定义任意一列有如下形式“族：标签”其中，族和标签都可为任意形式的串物理上将同“族”数据存储在一起数据可通过时间戳区分版本列族

hbase表中的每个列，都归属与某个列族。列族是表的chema的一部分(而列不是)，必须在使用表之前定义。列名都以列族作为前缀。例如courses:history，courses:math

都属于courses这个列族。

访问控制、磁盘和内存的使用统计都是在列族层面进行的。实际应用中，列族上的控制权限能帮助我们管理不同类型的应用：我们允许一些应用可以添加新的基本数据、一些应用可以读取基本数据并创建继承的列族、一些应用则只允许浏览数据（甚至可能因为隐私的原因不能浏览所有数据）。

Page

84列族

hbase表中的每个列，都归属与某个列族。列族是表的chema的一部分(而列不是)，必须在使用表之前定义。列名都以列族作为前缀。例如courses:history，courses:math

都属于courses这个列族。

访问控制、磁盘和内存的使用统计都是在列族层面进行的。实际应用中，列族上的控制权限能帮助我们管理不同类型的应用：我们允许一些应用可以添加新的基本数据、一些应用可以读取基本数据并创建继承的列族、一些应用则只允许浏览数据（甚至可能因为隐私的原因不能浏览所有数据）。

Page

85数据模型－列RowKeyTimeStampColumnContentsColumnAnchorColumn“mime”my.look.ca“n.www”T9CNNT8CNN.COMT6“<html>..“Text/htmlT5“<html>..“t3“<html>..“族标签物理视图RowKeyTimeStampColumn:ContentsCn.wwwT6“<html>..”T5“<html>..”T3“<html>..”RowKeyTimeStampColumn:AnchorCn.wwwT9Anchor:CNNT5Anchor:my.look.caCNN.COMRowKeyTimeStampColumn:mimeCn.wwwT6text/htmlHTable小结RowKeyTimeStampColumnContentsColumnAnchorColumn“mime”my.look.ca“n.www”T9CNNT8CNN.COMT6“<html>..“Text/htmlT5“<html>..“t3“<html>..“HBASE物理存储1已经提到过，Table中的所有行都按照rowkey的字典序排列。2Table在行的方向上分割为多个Hregion。3region按大小分割的，每个表一开始只有一个region，随着数据不断插入表，region不断增大，当增大到一个阀值的时候，Hregion就会等分会两个新的Hregion。当table中的行不断增多，就会有越来越多的Hregion。

Page

894HRegion是Hbase中分布式存储和负载均衡的最小单元。最小单元就表示不同的Hregion可以分布在不同的HRegionserver上。但一个Hregion是不会拆分到多个server上的。

Page

905HRegion虽然是分布式存储的最小单元，但并不是存储的最小单元。HRegion由一个或者多个Store组成，每个store保存一个columnsfamily。每个Strore又由一个memStore和0至多个StoreFile组成。StoreFile以HFile格式保存在HDFS上。

Page

91Page

92HFile分为六个部分：DataBlock段–保存表中的数据，这部分可以被压缩MetaBlock段(可选的)–保存用户自定义的kv对，可以被压缩。FileInfo段–Hfile的元信息，不被压缩，用户也可以在这一部分添加自己的元信息。DataBlockIndex段–DataBlock的索引。每条索引的key是被索引的block的第一条记录的key。MetaBlockIndex段(可选的)–MetaBlock的索引。Trailer–这一段是定长的。保存了每一段的偏移量，读取一个HFile时，会首先读取Trailer，Trailer保存了每个段的起始位置(段的MagicNumber用来做安全check)，然后，DataBlockIndex会被读取到内存中，这样，当检索某个key时，不需要扫描整个HFile，而只需从内存中找到key所在的block，通过一次磁盘io将整个block读取到内存中，再找到需要的key。DataBlockIndex采用LRU机制淘汰。HFile的DataBlock，MetaBlock通常采用压缩方式存储，压缩之后可以大大减少网络IO和磁盘IO