基于hadoop平台的聚类算法实现分析.pptx

;背景介绍;基于hadoop平台的聚类实现;;hadoop的思想起源：google;Google面临的数据和计算难题;Map-reduce;Map-reduce;Map-reduce;Map-reduce;;Map-reduce;Map-reduce;Map-reduce;Map-reduce;Map-reduce;Map-reduce;Map-reduce;Map-reduce;Master 与Slave;Map-reduce;HDFS特点和目标 硬件故障 　　硬件故障是常态，而不是异常。整个HDFS系统将由数百或数千个存储着文件数据片断的服务器组成每一个组成部分都会频繁地出现故障或失效，因此故障的检测和自动快速恢复是HDFS一个很核心的结构目标。 流式的数据访问 　　运行在HDFS之上的应用程序必须流式地访问它们的数据集，它不是典型的运行在常规的文件系统之上的常规程序。HDFS是设计成适合批量处理的，而不是用户交互式的。 大数据集 　　运行在HDFS之上的程序有很大量的数据集。这意味着典型的HDFS文件是GB到TB的大小，所以，HDFS是很好地支持大文件。 简单一致性模型 　　一个文件一旦创建、写入、关闭之后就不需要修改了。这个假定简单化了数据一致的问题和高吞吐量的数据访问。Map-Reduce程序或者网络爬虫程序都是非常完美地适合这个模型。 移动计算比移动数据更经济 　　在靠近要被计算的数据所存储的位置来进行计算是最理想的状态，尤其是在数据集特别巨大的时候。这样消除了网络的拥堵，提高了系统的整体吞吐量。这个假定就是将计算离数据更近比将文件移动到程序运行的位置更好。HDFS提供了接口，来让程序将自己移动到离数据存储的位置更近。 轻便的访问异构的软硬件平台 　　HDFS应该设计成这样的一种方式，就是简单轻便地从一个平台到另外一个平台，这将推动需要大数据集的应用更广泛地采用HDFS作为平台。 ;HDFS缺点 低延迟数据访问 需要低延迟访问数据在毫秒范围内的应用并不适合HDFS。HDFS是为达到高数据吞吐量而优化的，这有可能会以延迟为代价。目前，对于低延迟访问，HBase是更好的选择。 大量的小文件 名称节点(namenode)存储着文件系统的元数据，因此文件数量的限制也由名称节点的内存量决定。根据经验，每个文件，索引目录以及块占大约 150个字节。因此，举例来说，如果有一百万个文件，每个文件占一个块，就至少需要300 Mb的内存。虽然存储上百万的文件是可行的，十亿或更多的文件就超出目前硬件的能力了。 多用户写入，任意修改文件 HDFS中的文件只有一个写入者，而且写操作总是在文件的末尾。它不支持多个写入者，或是在文件的任意位置修改。(可能在以后这些会被支持，但它们也相对不那么高效。) ;HDFS的基本概念 数据块(block) HDFS(Hadoop Distributed File System)默认的最基本的存储单位是64M的数据块。和普通文件系统相同的是，HDFS中的文件是被分成64M一块的数据块存储的。不同于普通文件系统的是，HDFS中，如果一个文件小于一个数据块的大小，并不占用整个数据块存储空间。 ;元数据节点(Namenode)和数据节点(datanode) 元数据节点用来管理文件系统的命名空间其将所有的文件和文件夹的元数据保存在一个文件系统树中。这些信息也会在硬盘上保存成以下文件：命名空间镜像(namespace image)及修改日志(edit log)其还保存了一个文件包括哪些数据块，分布在哪些数据节点上。然而这些信息并不存储在硬盘上，而是在系统启动的时候从数据节点收集而成的。 数据节点是文件系统中真正存储数据的地方。客户端(client)或者元数据信息(namenode)可以向数据节点请求写入或者读出数据块。其周期性的向元数据节点回报其存储的数据块信息。 从元数据节点(secondary namenode) 从元数据节点并不是元数据节点出现问题时候的备用节点，它和元数据节点负责不同的事情。其主要功能就是周期性将元数据节点的命名空间镜像文件和修改日志合并，以防日志文件过大。这点在下面会详细叙述。合并过后的命名空间镜像文件也在从元数据节点保存了一份，以防元数据节点失败的时候，可以恢复。 ;文件系统命名空间映像文件及修改日志 当文件系统客户端(client)进行写操作时，首先把它记录在修改日志中(edit log)元数据节点在内存中保存了文件系统的元数据信息。在记录了修改日志后，元数据节点则修改内存中的数据结构。每次的写操作成功之前，修改日志都会同步(sync)到文件系统。