20180926大数据存储与处理
贝毅君
HDFS简介 用数据冗余的方式实现数据的高可靠性 一个内存被很多硬件共用
HDFS适合做什么：数据量大的处理（PB级） 处理非结构化数据 注重数据处理的吞吐量（Latency时延不敏感，不解决数据的响应时间） 应用模式为write-once-read-many存取模式（场景：数据分析 视频播放）
HDFS不适合做什么：存储小文件（不建议）（应该把很多小文件打包存储） 大量随机读文件（不建议） 需要对文件的修改（不支持，只能够追加式处理数据append）
HDFS基本结构 Client 做读写操作 NameNode 存储文件信息 DataNode 存储文件数据（耗资源），为了防止丢失默认存3份 Rack机架（组）
读：至少两次网络操作 -> HDFS不支持高响应读取
不同的块放在不同的机器上，保证整体负载均衡（NameNode，心跳协议实现调度和负载均衡）
TaskTracker实现Task和HDFS交互 JobTracker：追踪、管理所有的计算单元（Map单元 Reduce单元）计算最终迁移到距离数据块最近的节点中
Block（默认大小64M）的副本放置策略 第一个副本：第一个副本：放置在上传文件的DataNode；如果是集群外提交，则随机挑选一台磁盘不太满，CPU不太忙的节点 第二个副本：放置在于第一个副本不同的机架的节点上（防止网络故障、断电故障等导致数据丢失或损坏） 第三个副本：与第二个副本相同集群的节点 更多副本：随机节点
设计目标： 假设：节点的失效是常态 写一次读多次存取模式 不支持文件并发写入 不支持文件修改 理想：任何一个节点失效 不影响HDFS服务；HDFS可以自动完成副本的创建
HDFS主要组件： NameNode 中心服务器 单一节点 管理文件系统的命名空间以及客户端对文件的访问 DataNode 处理文件内容的读写请求 以文件形式存储在磁盘上 包含元数据和数据本身 所有块的信息大约1小时报告一次；心跳大概10秒一次（快则3秒一次，通过TCP协议），若超过10分钟未接收到心跳，则判定该块不可用，重新分配一个数据块;每10个心跳信号作为一个块报告 NameNode根据块报告构建metadata NameNode非常重要（全局），如果NameNode宕机则HDFS无法工作 它定期接受集群中每个DataNode的心跳信号和块状态报告（BlockReport） NameNode和DataNode解决存储，JobTracker和TaskTracker解决计算
SecondaryNameNode和Editlog 定期拷贝主NameNode信息，当NameNode挂掉，需要手动启动SNN SNN的备份是延迟的，没有完美地解决数据损坏问题，它不是NameNode的热备份
数据损坏处理：每隔三周验证校验和，若发现损坏则执行复制操作
HDFS开发常用命令 创建文件夹 上传一个文件 删除一个文件和文件夹 查看一个文件夹里有哪些文件 查看某文件的内容
HDFS网络拓扑结构 Hadoop把网络视为一棵树，子节点之间的距离为到离它们最近的根节点的距离和 节点到自己的距离为0 相同机架的节点距离为2 同一数据中心不同机架距离为4 不同数据中心的节点间距离为6
HDFS文件读写操作（代码和过程）
Hadoop集群与其中的各种角色
典型工作流程： 1 加载数据到Hadoop集群（写HDFS） 2 分析数据（Map-Reduce） 3 将结果存储到集群（写HDFS）
Rack Awareness
写HDFS的准备过程
写HDFS的过程
读HDFS的过程
MapReduce - 数据处理 Map过程：分析及计算本地数据 Reduce过程：在Map的结果集上进行计算，并把结果写到HDFS
Hadoop集群均衡器：使用带宽很小 一般在后台运行 不会影响MapReduce和HDFS
- 理解大数据架构和原理比编程更重要
相关职业：算法工程师（会编程 懂原理） 运行维护工程师（懂原理 实时监控） 数据分析师（读数据不写数据 做统计分析 编程能力最差）
解决NameNode故障问题：Hadoop 1.0: SSN 手动启动 Hadoop 2.0: ZooKeeper NameNode主从备份（Active/Standby）：NameNode主动发心跳信息给ZooKeeper