这篇文章上次修改于 1958 天前,可能其部分内容已经发生变化,如有疑问可询问作者。 >大数据相关的总结,大数据产生的背景,读取速度的增长速度,更不上容量的增长速度。所以需要多个硬盘的读取速度进行叠加。另外一点---寻址速度,跟不上读取速度(这个也是关系数据库不适合做大量数据分析的原因,全局搜索会非常慢,单点搜索和更新是强项。注:hadoop侧重与流读取,即一次读取大块的数据,而不是点寻) 1. 数据放到多个硬件遇到的问题 + 多个磁盘的失败率增高,解决方案是副本 replication,如RAID和HDFS + 多个硬件的数据如何聚合分析:Map Reduce 提出一个编程模型---把对各个磁盘的读和写,转换为对数据集sets(包含keys和values)的计算。计算分为两部---map 和reduce 2.map reduce 是一个批处理系统,不太适合实时系统,适合offline使用.设计初衷是对整个数据,或者很大一部分数据进行处理。 3.Hadoop设计初衷并不仅仅是批处理,hadoop现在被认为一个更大的,多个项目组成的生态系统,包括 + hadoop支持非结构化数据,即没有固定存储格式的数据,如图片,原始文本,plain text,mysql强调非冗余(第二范式)。而hadoop 恰好相反,冗余更利于map reduce的统计和分析。 + map reduce 保证了线性伸缩,即随着数据的增大,算法时间也会同比增大。我们只需要扩充同比的集群就能达到相应的速度。 + hbase数据库,键值对存储,底层用的hDFS + yarn---集群资源管理系统 + hive---交互式sql,分布式查询引擎。去掉了map reduce,使用索引和事务特性 + spark---好多算法具有迭代性,而map reduce不允许迭代的获取数据。。spark探索了这种风格处理,每次保存中间结果在内存。 + spark stream/storm ,实时无边界的流Stream处理。 + solr 在hdfs上索引和查询。 4.大数据计算方法 + HPC高性能计算和Grid计算,分散(distribute)work到cluster的各个机器,cluster的机器使用SAN(storage area network)共享文件系统----适合计算密集型,但是不适合数据较大(几百GB)的计算,因为网络network也是一种昂贵的资源,很多计算节点因为等待数据而闲下来 + hadoop 数据本地化---核心,即在计算节点上存储数据 5.Map Reduce 计算流程 + map计算本地话,block分块不大于128M,按当前HDFS设置的分区块大小---实现本地化计算 + map输入结果本地化,不会存储到HDFS系统 + map的计算结果传递给多个reducer时,一个会按key进行分区(分区方法一般用hash,默认的。备注:让我想起了kafka的路由方法是----Round-ribon和hash,传递到不同的分区。原理差不多),同一个分区交给同一个reducer进行计算---这个分区传给ruceer的过程一般成为shuffle(混洗)。 + 注意shuffle后有一个merge的过程,但是也有的结果可以完全并行,即,无需shuffle时,没有reduce这一步,直接将结果存放到HDFS + Reduce的结果会存放到HDFS中,即先存本地,然后存副本到其他节点 + Map的输出,可以指定一个Combiner。Combiner做了处理后,再传递给Reducer。从而优化网络传输。 + 可以把combiner看成一个本地化的reducer 6.Hadoop Streaming + 在java api中,每个reducer会被分配给一个keygroup,即shuffle后在同一个key中。而ruby中需要自己处理边界,key是排好序的。 7.HDFS设计 + 文件比较大,GB,ZB级别 + 流式数据访问,一次读取全部/或者大部分的数据的速度,而不是第一次读到数据的速度。 + 普通商用硬盘支持,允许故障的发生 8.不适合HDFS的场景 + 低延迟的数据访问,毫秒级别,请选择HBASE + 大量的小文件,HDFS的nameNode存储于内存中。大量的小文件ke导致namenode内存不够用 + 多用户写入,任意修改文件----HDFS只支持单个用户写入,而且总是在文件末尾写入,即append only。也不支持,在文件的任意位置修改 9.HDFS的概念 + Blocks数据块,128M,大数据快,减少seek的时间 - 分块的好处1:一个大文件可能比磁盘还大,那么可以切成Block分布到不同的磁盘。 - 好处2:抽象为Block,比File更加简化了存储子系统的设计。块的权限,可以单独管理。不需要存储到子系统 - 提高了容错性。每个块会把副本到别的磁盘,一般是3个,如果一个不可用,那么系统会切换到另一个磁盘读取。甚至有的系统会提高副本的个数来应对读取的负载。 + NameNode 和DataNode - HDFS 以管理节点(master---NameNode)和数据节点(workers节点----DataNode)运行 - NameNode 管理文件系统的命名空间----管理整个文件系统树和树内的文件和目录。这些信息有两种文件格式format就----namespace image 和edit log。 - namenode还记录每个文件的各个块的数据节点信息,但不是永久,每次系统重启会重建。 - 客户端代表用户访问clientNode和NameNode。并提供一个类似POSIX的文件系统接口 - datanode是文件系统的工作节点,存储和获取blocks(受namenode和client控制)。并且定期向nameNode发送他们存储的节点 - 没有NameNode,文件系统无法工作。如果NameNode损坏,整个文件系统将丢失。那么Hadoop提供两种机制保证 * 备份组成文件系统元数据的文件。一般是:写入本地的同时,写入远程的一个NFS * 另一种,运行一个辅助的Secondary NameNode,定期合并edit log 到 namespace image,防止editlog过大。一般secodnary namenode 会放到一个单独的物理机上,因为他CPU和内存占用比较多。但是secondary namenode 有延迟(所以一旦NanmeNode 失效,就会丢失数据)常用的做法是结合copy NFS上的数据。 + Blocking cache块缓存 - 经常读取的文件,会缓存到datanode的内存,off heap block cache - 一个快只会缓存到一个datanode的内存中 + HDFS Federation 联邦HDFS * Namenode 的集群版,因为NameNode在内存中存储block的元信息。但是内存会是一个限制。随意出现了Federation版。 * 每个NameNode维护一个命名空间卷----包含一个元数据和一个数据快池组成。client使用文件路径挂name nodes
没有评论