hdfs的架构设计
- HDFS具有主/从结构。HDFS集群由单个NameNode,和多个DataNode构成
- Client,客户端Client代表用户与NameNode和DataNode交互来访问整个文件系统的对象
- NameNode,HDFS的元数据管理者,记录文件是如何分割成数据块的以及它们分别存储在集群中的那些数据节点上
- DataNode,文件系统的工作节点,根据客户端或者NameNode发送的指令,负责数据块的读写和检索操作,通过心跳机制定期向NameNode发送它们的存储块列表
hdfs的读操作
-
Client向NameNode发送数据请求后,寻找数据对应的数据块的位置信息
-
NameNode返回文件对应的数据块元数据信息,如所属机器、数据块的block_id、数据块的先后顺序
-
由Client与DataNode直接通信,读取各个block数据块的信息。过程为并行读取,由客户端合并数据
hdfs的写操作
-
Client向NameNode发送写数据请求后,寻找可以写入的数据块block信息的机器位置
-
文件过大,写入会分成很多个block数据块的,实际上是通过一个block一个block的申请
-
默认副本是3个,同机架一个,不同机架存储一个,每次请求后返回一个block的对应的3个副本的block的存放位置
-
-
client获取到对应的block数据块所处的DataNode节点位置后,Client开始写操作。
-
先写入第一个DataNode,以数据包package的方式逐个发送和接收
-
-
待所有的数据块block均写完后,Client接收到全部写完的ack答复,告诉NameNode数据已写完,Client关闭socket流。DataNode也会向NameNode报告新增block数据块的信息
MapReduce的运行流程
- 首先在pre-map阶段对数据源进行分片,然后进入到map阶段,把他们分成kv形式的数据,然后会进入portition把具有相同key的分到一个组中,然后进行排序,聚合,shuffle阶段会把一个区的数据拿在一起,进行合并然后排序,然后进入到reduce对具有相同key的进行合并然后输出
yarn的架构设计
- 是双层调度模型
- Client:作为用户编程的接口,与ResourceManager交互
- ResourceManager:负责集群资源的统一管理和调度
- NodeManager:处理来自RM、AM的命令,负责单节点资源的管理和使用
- ApplicationMaster:负责应用程序的管理、为应用程序/作业向RM申请资源(Container),并分配给内部任务、与NodeManager通信以启动、停止任务
- Container:对任务运行环境的抽象
yarn的运行流程
-
用户向YARN中提交应用程序/作业
-
RM为作业分配第一个Container,并与对应的NodeManager通信,要求它在这个Container中启动该作业的AM
-
NodeManager启动一个Container运行ApplicationMaster
-
ApplicationMaster首先向ResourceManager注册,这样用户可以直接通过ResourceManager查询该作业的运行状态;然后它将为各个任务申请资源并监控任务的运行状态。
-
一旦ApplicationMaster申请到资源后,便与对应的NodeManager通信,要求它启动任务
-
NodeManager执行ApplicationMaster发送的命令,启动Container任务
-
各个Container通过RPC向ApplicationMaster汇报自己的状态和进度,以让ApplicationMaster随时掌握各个任务的运行状态,从而可以在任务失败时重新启动任务
-
作业完成后,ApplicationMaster向ResourceManager申请注销并关闭自己
数据仓库的架构设计
- 它的结构原则是先水平分层,再垂直分主题域
- 源数据落地区 SDF
- 位于hdfs原始数据以大文件的形式存放
- 数据仓库仓 DW
- 源数据层 DWB
- 将原始数据导入到的hive数据表中生产系统的原始数据,清洗掉不符合质量的数据,通常永久保留
- 细节数据层 DWD
- 对原始数据进行处理清洗筛选
- 汇总数据层 DWS
- 将细节数据层的数据进行轻度汇总
- 源数据层 DWB
- 数据集市层
- 使用数据层面,各种各样的项目去使用这些数据
Hive的架构设计
- hive是处于应用层,分为UI层和核心层两层
- Hive CLI:命令行交互模式
- Hive Client 客户端(编程语言操控)
- WebUI:是指可通过浏览器访问Hive
- Driver,这是一个驱动器,类似于jdbc驱动,衔接UI和内核的解析、优化、执行器的桥梁
- SQL Parser:sql解析器,解析sql
- Query Optimizer:优化查询语句的
- Excution:执行器
- MetaStore:元数据库,Hive将元数据存储在数据库中
- Hiveserver2:是将Driver和Client进行了一个解耦,因为HiveClient是程序驱动的,情况很复杂,所以单独抽离了这一层
Hive的运行流程
- 首先UI层提交SQL命令
- 然后到Driver层进行sql解析
- 解析的时候会查询MetaStore数据库
- 然后进行sql语句的优化
- 然后执行sql,将sql转换成mr程序处理hdfs的数据
Hbase的读写流程
- HBase的读流程
- Client先访问zookeeper,从meta表读取region的位置
- 根据namespace、表名和Rowkey再meta表中找到对应的region信息
- 向region对应的region server发起读请求
- 先从Memstore读取信息,如果没有,再到BlockCache里面读
- BlockCache还没有,再到StoreFile上读
- 如果没有则返回null,如果从StoreFile里面读取的数据,而是先写入BlockCache,在返回给客户端
- HBase的写流程
- 获取到meta的RootRegion位置信息
- 找到数据要写到那个region上
- 向region对应的region server发起写入请求
- WAL log 写入,防止丢失数据
- memstore写入,StoreFile落盘
- 将更新写入到memstore中,当增加到一定大小,达到预设的Flush size阈值时,会触发flush memstore,把memstore数据写出到hdfs上,生成一个sotrefile
- StoreFile合并
- 随着storefile文件的不断增多,当增长到一定阈值后,会触发compact合并操作,将多个storefile合并成一个,同时进行版本合并和数据删除
- Region拆分
- 单个storefile大小超过一定阈值后,会触发split操作,把当前的region拆分成两个,新拆分的2个region会被hbase master分配到相应的2个region server上
Flink的架构设计
- deploy(物理部署层)
- 支持解决Flink的部署模式问题
- 支持多种部署模式:本地、集群部署等
- Runtime(核心层)
- 是Flink分布式计算框架的核心实现层,负责对上层不同结构提供基础服务
- API & Libraries层(依赖库)
- 负责更好的开发用户体验
- Flink同时提供了支撑流处理计算和批处理的接口,抽象出不同的应⽤类型的组件库

被折叠的 条评论
为什么被折叠?



