大数据相关的总结，大数据产生的背景，读取速度的增长速度，更不上容量的增长速度。所以需要多个硬盘的读取速度进行叠加。另外一点---寻址速度，跟不上读取速度（这个也是关系数据库不适合做大量数据分析的原因，全局搜索会非常慢，单点搜索和更新是强项。注：hadoop侧重与流读取，即一次读取大块的数据，而不是点寻）
- 数据放到多个硬件遇到的问题
- 多个磁盘的失败率增高，解决方案是副本 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
、
