分布式文件系统

原生HDFS

架构

HDFS采用master/slave架构

• master 采用主备架构，使用zk选主，称为NameNode，NameNode存储文件对应的元数据，通过元数据可以从DataNode上找到对应的Block，从而形成文件
• slave中数据多副本策略，称为DataNode，中存储这Block块

NameNode

• NN路径表示 /users/sameerp/data/part-0,r:3,{2,4,5}
• 操作日志：所有操作 append 到EditLog文件中，NN通过重放EditLog中所有操作，生成内存元数据信息
• 硬盘元数据：整个HDFS文件系统的名字空间，包括数据块到文件的映射、文件的属性等，都存储在一个称为FsImage的文件中
• 检查点：当Namenode启动时，它从硬盘中读取Editlog和FsImage，将所有Editlog中的事务作用在内存中的FsImage上，并将这个新版本的FsImage从内存中保存到本地磁盘上，然后删除旧的Editlog，因为这个旧的Editlog的事务都已经作用在FsImage上了。这个过程称为一个检查点(checkpoint)，在当前实现中，检查点只发生在Namenode启动时，在不久的将来将实现支持周期性的检查点。

DataNode

数据块：它把每个HDFS数据块存储在本地文件系统的一个单独的文件中
文件+目录：Datanode并不在同一个目录创建所有的文件，实际上，它用试探的方法来确定每个目录的最佳文件数目，并且在适当的时候创建子目录。在同一个目录中创建所有的本地文件并不是最优的选择，这是因为本地文件系统可能无法高效地在单个目录中支持大量的文件
状态报告：它会扫描本地文件系统，产生一个这些本地文件对应的所有HDFS数据块的列表，然后作为报告发送到Namenode，这个报告就是块状态报告。

特性设计

• 高可靠：同步复制，DN多副本，周期性的 DateNode ->(心跳)->NameNode 基于租约的机制，监控DN的数据情况
• 高可用：NN主备架构，主备同步，主备切换
• 多副本策略：虚拟机->主机->机架->AZ->Region，3副本架构 2个副本相同相同机架的，不同节点，1节点不同机架
• 负载均衡：集群DN负载均衡，目前未实现
• 数据完整性：HDFS客户端软件实现了对HDFS文件内容的校验和(checksum)检查，读写文件时，进行校验和检验
• 删除恢复：HDFS会将这个文件重命名转移到/trash目录。只要文件还在/trash目录中，该文件就可以被迅速地恢复

数据写入流程

Client【本地写到临时文件，超过块大小】-> NameNode【分配元数据，分配数据块】->Client【DN的标识符，目标数据块】->DataNode【上传写入】->Client【告诉NN上传完成】->NameNode【提交操作日志】

1、配置/etc下的配置文件
2、配置HADOOP_HOME,同时添加到PATH中
3、使用hdfs --daemon start|stop namenode|datanode|secondarynamenode 启动单个节点

启动MR任务

hadoop jar hadoop-mapreduce-examples-3.1.1.jar pi 2 4
hadoop jar hadoop-mapreduce-examples-3.1.1.jar wordcount /in /out

HDFS Access

HDFS CLI

hadoop dfs：只能操作HDFS文件系统deprecated
hdfs dfs：只能操作HDFS文件系统，建议使用hadoop fs，本地文件系统file:/// http://hosts
hadoop fs：可以操作任意文件系统，不仅仅是HDFS文件系统

HDFS Java sdk client

HDFS C client libhdfs

HDFS Restful API

• WebHDFS HDFS内置组件，可以访问所有HDFS所有组件
• HttpFs HDFS的网关，提供web服务，接受所有请求，转发给后端WebHDFS服务上

文件类型

• 文本文件:按照行来存储，只能按照行来压缩，不能按照块来压缩，可读性性
• Sequence File: kv文件，支持单个kv压缩，整个文件可以压缩，多个文件合并
• Avro
• RCFile: 将多行形成行组，行组列式存储，形成二级制文件
• ORC文件：将多行形成行组，行组列式存储,每个行组有单独shecma
• Parquet:将多行形成行组，行组中，划分成列块，每个列可以单独，列可以划分为page,一段列，一段列单独压缩

压缩

• 指标：压缩比，吞吐量，简单+开源，无损压缩，压缩后是否支撑切分
• 压缩算法：DEFLATE,gzip,bzip2,LZO,LZ4,Snappy

文件冷热策略

• 定义存储介质的类型，DN挂载点需要声明存储介质的类型StorageType.java DISK,SSD，RAM_DISK，ARCHIVE
• 定义的存储策略，不同策略，对应文件副本存储介质的分配情况，BlockStoragePolicySuite
• 针对元数据namespace设置存策略，存储在对应的namespace下的数据，就可以根据对应策略的存储分配情况，选择DN不同的挂载点去存储文件
• 不同点，采用内存tmpfs来挂载内存磁盘
• dfs.storage.policy.enabled,dfs.datanode.max.locked.memory两个参数来调整

阿里JindoFS

JindoFS块模式是阿里云基于 OSS对象存储OSS（Object Storage Service） 海量存储自研的一个存储优化系统，提供了高效的数据读写加速能力和元数据优化能力。

JindoFS多种模式

JindoFS提供三种模式，https://help.aliyun.com/document_detail/199488.html

• SDK模式：直接访问OSS
• 缓存模式（Cache）：通过将OSS的文件或者数据块缓存在计算本地，提供访问缓存加速
• 块存储模式（Block）：组织、存储数据和管理文件元数据，提供文件系统管理能力，文件以块的形式存储在OSS上，同时可以提供缓存能力

HDFS NN存在的问题

• HDFS NameNode 单个实例所能支撑的文件个数大约 4亿，主要原因是受限于内存大小
• 由于文件数增加，需要处理的DataNode上报块也增加，造成了性能上的巨大抖动
• 大量文件信息保存在一个很大的FsImage文件，用于下次启动时加载，而很大的FsImage文件使得 NameNode 启动需要花费10分钟以上的时间。
• NameNode 单点瓶颈，JVM 瓶颈仍然影响着集群的扩展 从 1 PB到 100+ PB，需要不断的进行调优、集群拆分来，HDFS 可以支持到 EB 级别，但是投入很高的运维成本，来解决慢启动，心跳风暴，节点扩容、节点迁移，数据平衡等问题。
• NN Federation 运维+迁移成本高

Block模式实现方式

JindoFS的Block模式提供同HDFS的NameNode兼容的功能，同时解决HDFS中NameNode存在的问题

• 元数据KV存储，JindoFS元数据服务采用RocksDB作为底层元数据存储，RocksDB可以存储在大容量本地高速磁盘，解决了内存容量瓶颈问题。
• 借助于内存缓存，将10%~40%的热文件元数据存放于内存缓存，从而保持稳定的优秀的读写性能
• 借助于Raft机制，JindoFS元数据服务可以组成2N+1节点集群，保证NN功能的可用性
• 读写锁,同时使用了不同的目录树存储结构，配合细粒度锁，从而减少了多个请求之间的影响
• 元数据同步到OSS服务上
• 使用C++语言，无本地GC问题

数据湖

通过数据湖，提供统一的数据存储中心，存储【结构化，半结构化，非结构化数据（图像，音频)】多种数据，通过统一访问方式开放给分析层使用

• 支持数据实时处理
• 计算存储分离：
  1. 因为存储和计算耦合在一起，稳定性不是最优，两种资源无法独立扩展，使用成本也不是最优，
  2. 存储朝着大容量低成本规模化供应，计算则向着弹性伸缩，丰富性和多样化向前发展
  3. 带来问题：计算要跨网络访问存储，数据本地性消失
• Serverless 化、
• 高性能低成本的数据仓库服务才能赢得未来。

构建数据湖

• 接入层：接入层实现 DDL 以及安全认证等
• 弹性计算层：充分利用云的弹性能力大幅降低计算成本
• 加速层：进行缓存加速，这里面出现较早的社区方案应该是Alluxio，Hadoop社区有S3A Guard，AWS有EMRFS，都适配和支持AWS S3，Snowflake在计算侧有SSD缓存，Databricks有DBIO/DBFS，阿里云有EMR JindoFS，大体都可以归为此类技术。
• 存储层：统一存储层基于云存储构建，解决数仓临时扩容以及运维问题，两种选择基于HDFS提供文件系统存储，基于OSS提供对象存储
  1. HDFS【文件系统】：Hadoop 3.0 引入 EC 以及联邦特性进一步完善之后，HDFS 达到了成熟的标准，小文件占用大量的NN元数据
  2. HBase【KV存储】：云上对象存储在大数据分析存储位置上越来越重要，未来对象存储势必成为云上数据湖或者数据仓库的底层存储，具备无限扩展能力，便于迁移，提供弹性扩缩容的能力，对文件大小不敏感,Apache Hadoop 社区也推出了原生的对象存储“Ozone”

大数据演变过程

第一代：由oracle代表的DBMS,存储结构化数据
第二代：以HDFS为代表的分布式文件存储系统，引擎以Hadoop和Spark开源生态为主
第三代：数据湖，一个数据源，一个元数据管理，一个权限管理，多个分析引擎

未来发展方向

• 一种是以 Presto 为代表，通过各种连接器分析各种异构数据源的数据而不需要预先对数据做任何处理

• 一种是以 Delta、Hudi、Iceberg 为代表的技术框架，是基于 HDFS 或者是云对象存储做集中式存储，外围数据需要导入到湖中，同时结合 OLAP 引擎对外提供服务。

• 元数据管理，统一的数据源，多种引擎，

优化点

内存缓存
客户端缓存
权限下放
增加层级

GFS

Master

• 命名空间（NameSpace 整个文件系统的目录结构）
• 文件和chunk的映射 持久化（文件名称-chunkIDs，chunkID-chunkServer关系)
• chunk副本信息（所有副本，主副本，副本位置）通过chunk汇报来收集
• 全局控制（chunkServer的租约，定时任务chunk回收，chunk复制，负载均衡）
• {如何判断chunk可以回收}
• {重名问题，怎么解决}

负载均衡策略
+ 创建chunk（1、磁盘利用率低，2、一定时间窗口前没有创建，3、所有副本不在同一个机架）
+ 复制chunk（1、根据创建chunk策略，选择chunk,2、设计优先级）
+ rebalancing（1、依据全局负载情况，执行上述创建+复制chunk,2、删除负载高的chunk)

ChunkServer

• chunk块在本地文件系统的位置，
• 向Master申请租约
• chunk分为很多block，对每个block进行CRC校验,如果数据块错误，报告客户端，同时上报Master标记删除

Client

• 通过client访问Master和ChunkServer

• 保存Master的元数据信息，{配置Master节点信息，}

• 文件存储，

• 大数据分析和分布式存储的区别

MR 计算框架 map->{key,value}->shuffle->{key,[value1,value2]}->reduce{key,sum_value},通过这样一直重复计算，最终收敛，计算框架
Yarn 资源调用（cpu+内存+硬盘）

Kerberos认证体系

CloudNative 架构

SSD 通过压缩降低成本
TPC-DS 测试
RDMA
缓存优化，提供性能