Hadoop笔记

HDFS

1. 1. master/slave架构, NameNode/DataNode, 使用心跳包通讯
2. 2. 典型拓扑结构,1个NameNode, 1个SecondaryNameNode,若干个DataNode, 
3. 3. 一次写入,多次读取
4. 4. 持久化metadata方式: 日志文件包括FsImage,事务日志EditLog, 
5. 5. HA包括:Secondary NameNode(辅助定期处理映射文件和事务日志), 
• a) JournalNode用来实现高可用(没有使用ZK,而是物理上使用双机热备),
• b) JournalNode主要是用来实现共享存储
• 6. 特点:
• a) 硬件错误是常态, 
• b) 流失数据为主,做批量操作为主,
• c) 大规模数据存储,
• d) 简单一致性: 对文件只能一次性写,多次读, 文件一经创建不能再更改
• e) 移动计算比移动数据更划算
• f) 冗余备份,副本存放(本机一份,同一个机架一份,不同机架一份)
• g) 空间回收: 文件删除后先移动到/trash目录里, 删除有延迟

 

 

Yarn

• 1. 分布式操作系统,控制分布式程序运行. master/slave架构作用
• a) 包括ResourceManager,NodeManager
• b) 集群资源管理中心,
• c) 任务调动中心
• 2. ResourceManager功能
• a) 客户端响应
• b) ResourceTrackerService(监控slave机器资源)
• c) Scheuler负责调动用户提交的Yarn-App,
• d) ApplicatonManage,负责管理所有ApplicationMaster
• e) WebService, 用来给 客户端显示状态信息,节点列表信息,调度策略等.
• f) 其余辅助模块包括
• i. NMLivelinessMonitor:跟踪每个NodeManager
• ii. 与RM通讯模块等
• 3. NodeManager功能:
• a) Yarn从进程,每个节点都有唯一的NodeManager,负责本地资源管理(Container管理)
• b) ContainerManager
• c) ContainerExecutor
• d) WebServer
• e) Context
• f) RPC Server
• g) NodeHealthCheckerService
• 4. Yarn-App三大编程模块
• a) 在Yarn(分布式系统)上运行的应用程序,包括:ApplicationMaster,ApplicationBusinessLogic,ApplicationClient
• i. BusinessLogic模块
1. 1. 是用户逻辑主要模块, 执行用户程序
• ii. ApplicationMaster,核心驱动逻辑
1. 1. 与RM,NM通讯,
2. 2. 项目RM注册,申请Container,
3. 3. 推送BusinessLogic下沉到Container,并执行
• iii. client, 用户客户端,用来提交到yarn中
1. 1. 创建context
2. 2. 推送ApplicationMaster,Businesslogic到HDFS上
3. 3. 提交ApplicationMaster到集群,并监控程序运行状态
• b) ApplicationMaster负责本App内部调度(如spark,mapreduce等)
• c) AppExecutor, Yarn-App的实际执行者, 在Container中被实体化
• 5. 一些命令
• a) yarn jar ; yarn queue, yarn application ,yarn container
• 6. Yarn编程
• a) 常用并行化范式
• i. M范式: 大文件切分为若干份,各机器单独处理一份,完成后再合并到一起
• ii. M-S-R范式
• iii. BSP范式: 用于机器学习

 

 

MapReduce

1. 1. Master/slave结构,思想是分而治之,目的是”任务的分解和结果的汇总”
2. 2. 核心处理部件:MRAppMaster,用于控制整个MR流程
3. 3. 常用命令
1. a) mapred job, mapred queue

 

Zookeeper

• 1. 用途: 进程间通信,进程间同步与互斥,是谷歌Chubby的开源实现
• 2. 对等结构,各节点是对等结构, 与master/salve结构不同, 不需要手动指定master, 由自己根据ZAB协议选举产生.
• 3. 所有节点都可以读, 写必须在master节点上
• 4. Zab协议:原子广播协议
• a) Paxos算法的改进,核心思想是获取大多数选票的作为leader,其余为follower
• b) 三种状,looking, 初始化状态,等待投票, leading,following
• c) 所有写操作转发到leader完成,并广播到follower, 半数follower同意后则认为事务提交有效
• 5. 核心: 
• a) 每个ZNode上存储数据执行读写都是原子的.
• b) 每个ZNode上都可以设置监视器,当node数据发生变化时可以通知客户端
• 6. 命令:
• a) zkClient -server ip:port
• 7. 因为是树形结构(命名空间), 所以节点操作包括
• a) create,delete,get,exists

 

 

HBase

• 1. master/slave结构, HMaster/HRegionServer,需要ZK集群
• 2. 特点: 高可用, 高性能,面向列,可伸缩的分布式存储系统,存储海量数据,没有列的限制,
• a) 面向列,可以动态增加列, 列存储,查询时可以大大减少读取数量
• b) 多版本,数据冗余大
• c) 数据稀疏存储,空列不占空间,
• d) 高可用性, wal机制(Hlog),副本机制,底层为HDFS,本身也会存储
• e) 高新能,使用LSM数据结构,写入性能非常高
• 3. 使用场景
• a) 交通GPS信息,物流,订单信息,移动通话记录等
• 4. 在行的方向,将表分成多个region, 每个region存在一个服务器上.所有数据存在HDFS上
• 5. 每个Region有多个Store,已HFile格式存储.Storefile过多时自动合并成大的StoreFile
• 6. HLog做灾备.每个服务器有一个HLog,不同表的region混杂在一起.特点是顺序写,速度快
• 7. HMaster
• a) 不对外提供服务,只维护表和Region元数据,HMaster失效会导致表元数据无法修改,但是数据读写还是正常的
• b) Region元数据存在.META表(存在内存中),.Meta表存在-Root表,Root表永远不会分割,且位置存在zk中.这样保证三次跳转就可定位任意Region
• 8. Zookeeper
• a) 存储Root表地址,HMaster,HRegionServer地址,
• b) 解决HMaster单点故障问题
• 9. HRegionServer
• a) 负责响应用户I/O响应,向HDFS中读取数据.
• b) 内部管理一系列HRegion对象
• 10. 数据存储过程
• a) Client先去ZK上获取Root位置, 然后根据Root请求获得行所属.META区域位置, 
• b) 根据Meta表获取Region所在节点和位置.
• c) 直接和管理该节点区域的HRegionServer进行交互
• d) 存储时先写入HLog, 然后放入MemStore,如果MemStore已经满了, 就会把数据刷盘到一个新的HFile
• 11. 数据模型:
• a) 已表的形式存储, 
• b) 行键作为唯一标识,每个列都属于一个列族, 列定义为[列族:限定符],
• c) 每个cell保存同一个数据的多个版本,用时间戳标识
• 12. 操作命令:
• a) create,put,get,drop,disable等

 

 

Spark

• 1. Master/slave架构,集群架构包括
• a) Standlone模式, Spark自带资源管理器,包括Master,Worker,特点是资源划分颗粒细,执行效率高
• b) Yarn模式, 包括ApplicationMaster,Executor
• ″ ApplicationMaster负责控制程序整个执行流
• ″ Executor负责执行具体任务
• 2. 与MapReduce对比
• a) Spark原生支持DAG型的M-S-R,可以多次执行M-S-R, MR每次只能执行一个M-S-R
• b) Spark提供了RDD抽象,对数据可以更精细化操作
• c) MR在每次Reduce之前,之后都要做一次按照Key排序操作,数据大时可能会用到外部排序,耗时,Spark默认不排序,
• d) 可以认为M-S-R三个阶段分别是MapReduce -> Tez+MapReduce -> Spark
• 3. 其他
• a) RDD可以看做是一系列Partition的集合.

 

 

Storm

• 1. 实时流计算引擎
• 2. 架构
• a) master/slave架构,
• b) Nimbus
• ″ 负责资源管理,任务响应,接受和管理Storm-App,
• c) Supervisor
• ″ 管理本机资源,启动和管理工作进程
• 3. Topology(拓扑): 
• a) 是Storm中运行的一个实时应用程序,由Spout,Bolt,Stream构成DAG图,
• b) 类似MapReduce的一个作业,不过启动之后不会自动停止.
• 4. Spout: 是整个ToPology的stream源,包括:Kafka,HDFS,HBase,Hive,JDBC,Redis,等
• a) 使用nextTuple实现读取输入源
• b) 可靠性支持包括ack(), fail()方法,超时重发
• c) HA由ZK+多个Nimbus来实现
• 5. Stream分组
• a) Shuffle Grouping: taks平均分配到各个Bolt实例中
• b) Fields Grouping: 根据指定字段分组发给同一Bolt实例
• c) Global Grouping: 所有Tuple发到唯一的一个Task(Bolt)上

 

 

Hive

• 1. Hive是Hadoop大数据圈的数据仓库,提供已表格的方式组织和管理HDFS上的数据.以类SQL的方式操作表格中数据
• 2. Hive设计目的是让Facebook精通SQL的分析师使用类SQL的方式存放HDFS大规模数据集
• 3. 用户向Hive提交HiveQL后,运行环境翻译为MapReduce和HDFS操作,然后向Hadoop集群提交这些操作
• 4. Hive不支持更新操作
• 5. 解析器包括:解释权,编译器,优化器,执行器
• 6. 集群部署包括:
• a) 内嵌模式: 云数据存在内嵌数据库Derby,只支持一个活动用户
• b) 本地模式:元数据存储在外部独立数据库
• c) 完全远程模式: 元数据已独立进程运行,
• 7. 命令:
• a) DDL,DML,

 

 

其他:

Pig

• 1. 相当于一个Hadoop的客户端,他先连接到Hadoop集群, 之后才在集群上做各种操作
• 2. 包括两个部分:Pig Latin,(描述数据流的语言), 一个是Pig Latin执行环境, 
• 3. pig脚本被翻译为HDFS,MapReduce作业.
• 4. 部署时,只需要在客户机上部署Pig即可,不需要部署到集群中

 

 

Oozie

• 1. 是一个Hadoop的客户端,用于管理和组织Hadoop工作流,必须是有向无环图
• 2. 用户将多个关联MR配置到workflow.xml, Oozie会托管此任务流
• 3. Oozie内部使用数据库来存储,默认是内嵌Derby,也可以使用MySql

 

Flume

• 1. 是一个分布式高性能,高可靠性的数据传输工具,更像一个智能路由器,提供强大的分用,复用,断网续存功能
• 2. 架构: 包含source,channel,sink三个部分
• a) Source, 数据源,包括Thrift, HttpSource等
• b) Channel, 落盘,包括三种类型:Memory,JDBC,File
• c) Sink, 从Channel中取出并发送数据