分布式云平台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
-
