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