这篇文章上次修改于 2045 天前，可能其部分内容已经发生变化，如有疑问可询问作者。 >大数据相关的总结，大数据产生的背景，读取速度的增长速度，更不上容量的增长速度。所以需要多个硬盘的读取速度进行叠加。另外一点---寻址速度，跟不上读取速度（这个也是关系数据库不适合做大量数据分析的原因，全局搜索会非常慢，单点搜索和更新是强项。注：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
没有评论