分布式云平台HADOOP
讨论
需求
- 1T 文件,数字,行存储
- 重复行
- 全排序
- 单词重复数
- 只有一台
- 128M,64M,256G
- 1,内存不能放下全量数据 OOM
解决
-
方法1
-
方法2
-
方法3集群
-
并行:提升速度的关键
-
分布式运行
-
计算与数据在一起
-
存+算(文件切割的规范管理)
- 计算向数据移动
- Net music log、有限电视
-
hadoop
- 分布式
- 分而治之:并行计算
- 计算向数据移动
- 需要管理、规范化操作
-
历史
Hadoop简介
-
Hadoop的思想之源:Google(第一个遇到大量数据计算问题的公司)
-
Openstack: NASA
-
面对的数据和计算难题
-
大量的网页怎么存储
-
搜索算法(倒排索引的计算)
-
带给我们的关键技术和思想(Google 三大理论)
- GFS
- Map-Reduce
- Bigtable
-
-
Hadoop简介
-
Hadoop创始人介绍
- Hadoop作者Doug cutting,就职Yahoo期间开发了Hadoop项目(之前已经开始实施),目前在Cloudera 公司从事架构工作
-
名字来源于Doug Cutting儿子的玩具大象。
-
2003-2004年,Google公开了部分GFS和Mapreduce思想的细节,以此为基础Doug Cutting等人用了2年业余时间实现了DFS和Mapreduce机制,一个微缩版:Nutch
-
Hadoop 于 2005 年秋天作为 Lucene的子项目 Nutch的一部分正式引入Apache基金会。2006 年 3 月份,Map-Reduce 和 Nutch Distributed File System (NDFS) 分别被纳入称为 Hadoop 的项目
-
-
Hadoop简介:http://hadoop.apache.org
-
分布式存储系统HDFS (Hadoop Distributed File System )POSIX
- 分布式存储系统
- 提供了 高可靠性、高扩展性和高吞吐率的数据存储服务
-
分布式计算框架MapReduce
- 分布式计算框架(计算向数据移动)
- 具有 易于编程、高容错性和高扩展性等优点。
-
分布式资源管理框架YARN(Yet Another Resource Management)
- 负责集群资源的管理和调度
- 版本:1.x,2.x,3.x
-
存储和架构模型
Hadoop分布式文件系统HDFS
-
存储模型:字节
-
文件线性切割成块(Block):偏移量 offset (byte,中文?)
-
Block分散存储在集群节点中
-
单一文件Block大小一致,文件与文件可以不一致
-
Block可以设置副本数,副本无序分散在不同节点中
- 副本数不要超过节点数量
-
文件上传可以设置Block大小和副本数(资源不够开辟的进程)
-
已上传的文件Block副本数可以调整,大小不变
- (2.x 128MB 3 blocks)
-
只支持一次写入多次读取,同一时刻只有一个写入者
-
可以append追加数据
-
架构模型:
-
文件元数据MetaData,文件数据
- 元数据
- 数据本身
-
(主)NameNode节点保存文件元数据:单节点 posix
-
(从)DataNode节点保存文件Block数据:多节点
-
DataNode与NameNode保持心跳,提交Block列表
-
HdfsClient与NameNode交互元数据信息
-
HdfsClient与DataNode交互文件Block数据(cs)
-
DataNode 利用服务器本地文件系统存储数据块
HDFS架构
HDFS设计思想
持久化
NameNode(NN)
-
NameNode(NN)
- 基于内存存储 :不会和磁盘发生交换(双向)
- 只存在内存中
- 持久化(单向)
-
NameNode主要功能:
- 接受客户端的读写服务
- 收集DataNode汇报的Block列表信息
-
NameNode保存metadata信息包括:
- 文件owership和permissions
- 文件大小,时间
- (Block列表:Block偏移量),位置信息(持久化不存)
- Block每副本位置(由DataNode上报)
-
NameNode持久化
- NameNode的metadata信息在启动后会加载到内存
- metadata存储到磁盘文件名为”fsimage”(时点备份)
- Block的位置信息不会保存到fsimage
- edits记录对metadata的操作日志…>Redis
- 二者的产生时间和过程?(format)
SecondaryNameNode(SNN)
- 它不是NN的备份(但可以做备份),它的主要工作是帮助NN合并edits log,减少NN启动时间
- SNN执行合并时机
- 根据配置文件设置的时间间隔fs.checkpoint.period 默认3600秒
- 根据配置文件设置edits log大小 fs.checkpoint.size 规定edits文件的最大值默认是64MB
- SNN合并流程
DataNode(DN)
- 本地磁盘目录存储数据(Block),文件形式
- 同时存储Block的元数据信息文件
- 启动DN时会向NN汇报block信息
- 通过向NN发送心跳保持与其联系(3秒一次),如果NN 10分钟没有收到DN的心跳,则认为其已经lost,并copy其上的block到其它DN
读写流程
Hadoop SAP HANA 关系型 2T
-
HDFS优点:
-
高容错性
- 数据自动保存多个副本
- 副本丢失后,自动恢复
-
适合批处理
- 移动计算而非数据
- 数据位置暴露给计算框架(Block偏移量)
-
适合大数据处理
- GB 、TB 、甚至PB 级数据
- 百万规模以上的文件数量
- 10K+ 节点
-
可构建在廉价机器上
- 通过多副本提高可靠性
- 提供了容错和恢复 机制
-
-
HDFS缺点:
-
低延迟数据访问
- 比如毫秒级
- 低延迟与高吞吐率
-
小文件存取
- 占用NameNode 大量内存
- 寻道时间超过读取时间
-
并发写入、文件随机修改
- 一个文件只能有一个写者
- 仅支持append
-
-
Block的副本放置策略
- 第一个副本:放置在上传文件的DN;如果是集群外提交,则随机挑选一台磁盘不太满,CPU不太忙的节点。
- 第二个副本:放置在于第一个副本不同的 机架的节点上。
- 第三个副本:与第二个副本相同机架的节点。
- 更多副本:随机节点
-
Hadoop核心
-
HDFS写流程
-
Client:
-
切分文件Block
-
按Block线性和NN获取DN列表(副本数)
-
验证DN列表后以更小的单位流式传输数据
- 各节点,两两通信确定可用
-
Block传输结束后:
- DN向NN汇报Block信息
- DN向Client汇报完成
- Client向NN汇报完成
-
获取下一个Block存放的DN列表
-
。。。。。。
-
最终Client汇报完成
-
NN会在写流程更新文件状态
-
-
-
HDFS读流程
-
Client:
- 和NN获取一部分Block副本位置列表
- 线性和DN获取Block,最终合并为一个文件
- 在Block副本列表中按距离择优选取
- MD5验证数据完整性
-
-
-
HDFS文件权限 POSIX标准(可移植操作系统接口)
-
与Linux文件权限类似
- r: read; w:write; x:execute
- 权限x对于文件忽略,对于文件夹表示是否允许访问其内容
-
如果Linux系统用户zhangsan使用hadoop命令创建一个文件,那么这个文件在HDFS中owner就是zhangsan。
-
HDFS的权限目的:阻止误操作,但不绝对。HDFS相信,你告诉我你是谁,我就认为你是谁。
-
-
安全模式
- namenode启动的时候,首先将映像文件(fsimage)载入内存,并执行编辑日志(edits)中的各项操作。
- 一旦在内存中成功建立文件系统元数据的映射,则创建一个新的fsimage文件(这个操作不需要SecondaryNameNode)和一个空的编辑日志。
- 此刻namenode运行在安全模式。即namenode的文件系统对于客服端来说是只读的。(显示目录,显示文件内容等。写、删除、重命名都会失败,尚未获取动态信息)。
- 在此阶段Namenode收集各个datanode的报告,当数据块达到最小副本数以上时,会被认为是“安全”的, 在一定比例(可设置)的数据块被确定为“安全”后,再过若干时间,安全模式结束
- 当检测到副本数不足的数据块时,该块会被复制直到达到最小副本数,系统中数据块的位置并不是由namenode维护的,而是以块列表形式存储在datanode中。
hadoop - hdfs
-
角色==进程
-
namenode
-
数据元数据
-
内存存储,不会有磁盘交换
-
持久化(fsimage,edits log)
- 不会持久化block的位置信息
-
block:偏移量,因为block不可以调整大小,hdfs,不支持修改文件
- 偏移量不会改变
-
-
datanode
- block块
- 磁盘
- 面向文件,大小一样,不能调整
- 副本数,调整,(备份,高可用,容错/可以调整很多个,为了计算向数据移动)
-
SN
-
NN&DN
- 心跳机制
- DN向NN汇报block信息
- 安全模式
-
client
- JAVA API
-