文章目录
- 一、大数据通识
- 大数据诞生背景与基本概念
- 大数据技术定义与特征
- 大数据生态架构概述
- 数据存储
- 数据计算与易用性框架
- 分布式协调服务和任务调度组件
- 数仓架构
- 流处理架构
- 二、HDFS
- HDFS 原理总结
- 一、系统架构
- 二、存储机制
- 三、数据写入流程
- 四、心跳机制与集群管理
- 安全模式(Safe Mode)定义
- Block
- HDFS 存储单元 - block
- block 副本放置策略
- block 在本地磁盘的存储结构
- 元数据
- 磁盘存储机制
- 元数据恢复与 edits 文件管理
- 元数据合并操作
- HDFS 文件写入操作
- HDFS 文件读取操作
- HDFS 高可用
- HDFS 单管理节点问题
- 联邦机制
- 管理节点热备
- 高可用架构组件
- HDFS 操作命令
- shell 命令
- Rest API
- HDFS 运维管理概述
- 系统配置
- 常见管理命令
- 数据处理工具
- 配额与快照
- 监控页面
一、大数据通识
大数据诞生背景与基本概念
- 传统数据处理架构
- 可处理结构化、非结构化和半结构化数据。结构化数据存在数据库,有严格字段和数据类型限制;半结构化数据如日志、JSON,字段和类型不严格;非结构化数据如图片、视频、音频无结构,一般存于 NOSQL 数据库,但 NOSQL 通常只管存储不管计算,计算需编写并发程序读取数据处理。
- 传统架构处理海量数据的瓶颈
- 结构化数据方面:单机数据库存海量数据时面临存储和处理速度问题,即便组成 MPP 架构集群,扩展性也有限(如 Oracle 扩展到 30 台后难以再扩),还存在热点问题(热数据集中于某节点易致其压力过大而故障)。
- 非结构化和半结构化数据方面:NOSQL 数据库存储性能好,但计算时跨网络拉取数据开销大、效率低。
大数据技术定义与特征
- 定义:为满足海量数据存储与计算的技术或架构。
- 4V 特征
- 数据规模巨大(Volume):如达到 10PB、50PB 等海量规模。
- 数据生成和处理速度快(Velocity):如鞋厂 2017 年每天数据增量 100TB,且需快速处理。
- 数据多样性(Variety):涵盖结构化、非结构化和半结构化数据,互联网时代后两者占比更高。
- 价值(Value):海量数据挖掘价值高,与人工智能结合潜力大,但价值密度低,因数据量庞大稀释了价值。满足这四个特征的场景即为大数据场景,也称大数据的 4V 特性。
中小规模数据与大数据技术
- 不适用原因:中小规模数据采用传统数据处理架构即可满足需求,若盲目使用大数据技术,因其调度周期长等因素,效率反而会降低。
- 效率对比示例:实际情况中,部分公司在数据量未达一定规模时引入大数据技术,结果不仅未提升效率,甚至出现效率减半的情况。
- 核心区分依据:离线与实时处理场景的本质区别在于数据是有界还是无界。离线处理针对已存储且数据量固定的有界数据,如存储为 10GB 的数据在运算中不会增减;实时处理则是针对持续产生、无明显边界的无界数据。
- 处理方式特点
- 离线处理:适合批处理运算。先对整体数据进行第一阶段处理,得到最终结果后再送往下一阶段,在任意时间观察,所有数据处于同一阶段,且数据存储后可在断网情况下完成处理。
- 实时处理:采用流处理方式。如同流水线工人,各阶段分别处理数据,处理完当前数据后立即将结果传递给下一阶段,并持续等待新数据,在任意时间观察,数据处于各个不同阶段。
- 典型应用场景:数据仓库、搜索与检索、图计算、数据分析等属于离线批处理场景;实时流计算是典型的实时处理场景。
大数据生态架构概述
- 数据源分类:包括结构化数据(如数据库中以二维表存储的数据)和非结构化/半结构化数据(如日志、JSON、图片、视频、音频等)。
- 结构化数据抽取
- 主流方式是通过 scoop 以 T+1 方式经 GDBC 连接数据库抽取到 HDFS,即当天数据次日导入。
- 也可使用 CDC(开源)或 OGG(Oracle 特有)进行实时抽取,通过监控数据库日志实现,数据变动时先抽至卡夫卡再交大数据平台处理。
- 非结构化/半结构化数据抽取:一般实时产生,常用 flume 或 log stach 抽取到卡夫卡消息队列缓冲抗压,再经大数据平台处理后存储,而非直接存入大数据平台。
数据存储
- HDFS 是成熟的大数据存储平台,但因其是文件系统,使用不便。
- 实际常将数据存于基于 HDFS 建立的分布式 NoSQL 数据库 HBASE,它易用性更好。
数据计算与易用性框架
- 计算框架:有 MapReduce 和 Spark,MapReduce 计算较慢,Spark 相对较快。计算任务需移至数据节点运算,依靠分布式资源调度框架(如 YARN)分配管理 CPU、内存等计算资源,计算完成后回收资源。
- 易用性框架
- Hive 可将 SQL 转换为 MapReduce 或 Spark 计算任务。
- Pig 通过其 API 转换为 MapReduce 计算任务(已停止维护)。
- MLlib 用于机器学习,可将机器学习 API 转换为 MapReduce 任务。
- 这些框架按转换计算任务类型,默认转换为 MapReduce 的属于 Hadoop 生态圈,部分也可运行于 Spark 之上。
- Spark 自身生态圈还包括 Spark SQL、GraphX、Spark Streaming 等,其中 Spark Streaming 用于实时流计算,其结果一般存储于 HBASE 以避免 HDFS 存储小文件的问题。
分布式协调服务和任务调度组件
- Zookeeper:是重要的分布式协调服务,大数据产品多依赖它。在分布式环境中,能识别节点增减、进行管理节点选举等协调工作,如卡夫卡搭建前必须安装 Zookeeper。
- 任务调度组件:oozie 和 Azkaban 用于管理和调度大数据集群中计算任务的先后顺序和定时执行。
数仓架构
- 数据抽取与存储:通常使用 sqoop 将数据抽取到 HDFS,开源组件 HIVE 在数仓构建中应用较多,计算结果一般存储于 hive。同时,也可将数据置于 spark 生态圈(spark sql)利用相关技术处理表数据。
- 数据清洗与计算:借助 spark 或 mapreduce 对抽取到的数据进行清洗和计算操作,以满足数据处理需求。
- 任务调度:任务调度可选用 oozie 或阿兹卡班,确保数仓中各项任务有序执行,保障数据处理流程的顺畅运行。
流处理架构
- 数据监控与缓存:运用 flume 或 log statch 监控非结构化和半结构化数据,利用 CDC\OGG 技术监控数据库日志,并将这些数据实时抽取到卡夫卡进行缓存,为后续处理做准备。
- 数据处理与引擎:通过流引擎如内存型的 spark streaming 或较新的 FLINK 等对缓存数据进行处理,开发人员在此环节编写任务较为频繁,实现数据的实时处理与分析。
- 结果存储:处理后的数据结果可存储在 Hbase 或 elastic search 中,这两种存储方式对小文件不太敏感。其中 h base 底层有处理小文件的机制,而 elastic search 文件直接存储在磁盘本地,进一步降低了对小文件的敏感度,更适合流处理结果的存储。
文章目录
- 一、大数据通识
- 大数据诞生背景与基本概念
- 大数据技术定义与特征
- 大数据生态架构概述
- 数据存储
- 数据计算与易用性框架
- 分布式协调服务和任务调度组件
- 数仓架构
- 流处理架构
- 二、HDFS
- HDFS 原理总结
- 一、系统架构
- 二、存储机制
- 三、数据写入流程
- 四、心跳机制与集群管理
- 安全模式(Safe Mode)定义
- Block
- HDFS 存储单元 - block
- block 副本放置策略
- block 在本地磁盘的存储结构
- 元数据
- 磁盘存储机制
- 元数据恢复与 edits 文件管理
- 元数据合并操作
- HDFS 文件写入操作
- HDFS 文件读取操作
- HDFS 高可用
- HDFS 单管理节点问题
- 联邦机制
- 管理节点热备
- 高可用架构组件
- HDFS 操作命令
- shell 命令
- Rest API
- HDFS 运维管理概述
- 系统配置
- 常见管理命令
- 数据处理工具
- 配额与快照
- 监控页面
二、HDFS
- 简介与特性:HDFS 全称 Hadoop Distributed File System,基于谷歌 GFS 论文实现,是 Hadoop 核心子项目,在开源大数据技术体系地位重要。其优点众多,能存储海量数据,构建成本低,可搭建于廉价商用服务器,软件层面通过数据多备份(默认三份)实现容错与恢复机制,适合大规模离线批处理,还具备高容错、高可用、高扩展等特性;缺点是不适合低延迟数据访问、不支持并发写入、不适合大量小文件存储及文件随机修改。
- 架构相关:由主节点管理并记录原数据(包括文件名、拆分份数及存储节点等信息)。
- 应用与不适合场景:适合大规模离线批处理,因其能向计算框架暴露数据位置,便于任务分发;不适合场景包括对延迟要求高、需并发写入、大量小文件存储及需随机修改文件的情况,如大量小文件会使主节点内存被原数据占满、计算任务调度时间长,随机修改会致集群负载过大等,若需修改文件可先删后追加或选用如 HBASE 等支持随机修改的上层组件。
HDFS 原理总结
一、系统架构
- 主从架构:HDFS 采用主从架构,主节点为 name node,从节点是 data node。主节点负责管理集群和接收客户端读写请求,从节点用于存储数据文件。
- 高可用机制:name node 有 active 和 stand by 状态,active 主节点负责管理,stand by 作为备用。当 active 节点故障时,stand by 会切换为 active 接替管理,生产环境中可设置多台 stand by 提升可用性。
二、存储机制
- 数据拆分与存储:文件按 128 兆为一块进行拆分,生成多个 block 块后存储在 data node 节点中,存储时会进行备份。
- 数据备份:默认对每个 block 块进行三个副本的备份,存储在不同 data node 节点,保证数据安全性和可用性。如果文件本身小于数据库大小,则按照实际大小进行存储。
三、数据写入流程
- 客户端发起文件上传请求,如上传 10G 的 FILE1 文件,会先按 128 兆一块拆分成多个 block 块(假设 80 个,从 block1 到 block80)。
- 这些 block 块均匀存储到 data node 节点,并对每个 block 块默认备份三份。
- name node 存储一份元数据,记录文件拆分的 block 块数量等信息,客户端可通过原数据寻址合并数据,但原数据中每个 block 块存储位置信息相对不重要,因为 data node 会通过心跳机制定期向 name node 上报,在内存中自动补全。
四、心跳机制与集群管理
- data node 节点每隔三秒钟通过心跳机制向 name node 上报信息,包括存储的 block 块信息和自身健康状态(忙碌或空闲)。
- 若 name node 发现某 data node 节点长时间(超过 10 分钟,默认三秒上报一次)未上报心跳,则认为该节点挂掉,会触发容灾操作,将该节点上的 block 块从其他节点拷贝并备份到其他正常节点,确保数据块始终保持三份副本。
安全模式(Safe Mode)定义
Hadoop的安全模式是一种特殊的维护模式,在该模式下,HDFS是只读的,即不允许对文件系统进行任何写操作,如修改文件、删除文件、添加新的文件等。此时,NameNode会拒绝所有对文件系统内容的修改请求,但客户端仍然可以读取文件系统中的数据。
- 启用场景
-
系统启动时自动进入:当Hadoop集群启动时,NameNode会自动进入安全模式。这是为了在集群启动的初始阶段,确保文件系统的元数据能够完整加载并进行必要的检查,防止在元数据尚未完全准备好时就允许对文件系统进行写操作,从而避免数据损坏或不一致的情况发生。
-
手动进入:管理员也可以根据需要手动将Hadoop置于安全模式。例如,在进行文件系统的重大维护操作之前,如升级Hadoop版本、修改文件系统配置等,进入安全模式可以确保在维护过程中文件系统不会被意外修改,保障数据的安全和一致性。
- 退出条件
- 自动退出:在系统启动时进入的安全模式,NameNode会在完成元数据的加载和检查后,自动退出安全模式。通常,当HDFS的块报告(Block Report)达到一定比例时,NameNode认为文件系统的状态已经稳定,便会自动退出安全模式,允许正常的读写操作。
- 手动退出:如果Hadoop是被管理员手动置于安全模式的,那么管理员也可以根据实际情况手动退出安全模式。在Hadoop的命令行界面中,可以使用hdfs dfsadmin -safemode leave命令来手动退出安全模式。
- 作用
- 保护文件系统元数据:在安全模式下,由于不允许对文件系统进行写操作,这就避免了在元数据加载和检查过程中,因用户的写操作而导致元数据的损坏或不一致,从而保护了文件系统的完整性和稳定性。
- 进行文件系统检查和维护:利用安全模式,管理员可以对文件系统进行各种检查和维护操作,如检查文件系统的健康状况、修复损坏的文件、清理无用的数据等,而不用担心在维护过程中文件系统被用户修改,确保维护操作的顺利进行和文件系统的最终一致性。
Block
HDFS 存储单元 - block
- HDFS 以 block 为最小存储单元存储文件,默认按 128 兆拆分文件。虽然 block 大小可调整,但企业中通常不建议调整。因为调小会产生过多小文件,调大则会增加每个任务处理 block 的时长,且每个 block 运行一个计算任务。例如 129 兆的文件会拆分为两个 block,第一个 128 兆,第二个 1 兆,这是基于 128 兆的固定拆分标准。
block 副本放置策略
- 每个 block 默认保存三个副本,放置在不同节点保障数据安全。
- 第一个副本优先选择距离客户端最近且最空闲的节点。若客户端在集群外,距离各节点相同时,则从所有节点中挑选最空闲的节点存储。
- 第二个副本存放在其他机架的最空闲节点,避免与第一个副本在同一机架因电源或交换机故障导致整个机架不可用的风险。
- 第三个副本放置在与第二个副本相同机架的最空闲节点,因为数据分布在两个机架已能保证安全,这样可快速存储第三个副本。
block 在本地磁盘的存储结构
- block 文件存储在本地服务器的文件系统或磁盘中,其存储目录可在 HDFS 配置文件中配置。在存储目录下,每个 block 除数据文件外,还有 meta 文件。meta 文件存储 block 的版本、文件类型、校验值、权限等属性信息,且与原数据无关,仅用于描述对应 block 的属性。
元数据
- 元数据最初存于 NameNode 内存,包含文件块拆分信息及块所在节点信息。但内存存储不安全,节点挂掉会致数据丢失,影响生产环境,所以需将部分关键原数据持久化到磁盘。
磁盘存储机制
- 持久化到磁盘形成 fs image 和 edits 文件。fs image 是某时刻元数据快照,记录如文件块拆分等重要信息;edits 用于记录元数据动态变化。因内存元数据变动频繁,若直接修改磁盘 fs image 会给主节点带来巨大压力,故采用将变动以日志形式追加到 edits 文件的方式,顺序追加可减轻磁盘压力。
元数据恢复与 edits 文件管理
- 元数据恢复依靠磁盘中的 fs image 和 edits 文件。先加载 fs image 到内存获取早期元数据,再执行 edits 中的记录更新为最新元数据。但 edits 文件不能过大,否则恢复耗时久,如 10G 的 edits 文件可能使 NameNode 假死一小时,所以需定期将 edits 合并到 fs image 以控制其大小。
元数据合并操作
- 在非高可用集群中,由 secondary name node 负责合并元数据。它定期从 NameNode 拖取 fs image 和 edits 文件,合并后生成新的 fs image 推回 NameNode,拖取过程中会生成新文件记录元数据更改操作。
- 在高可用集群中,edits 文件不能存于 NameNode 本地,因其节点挂掉后无法获取,会导致数据不一致。edits 文件存于奇数台组成的 journal node 集群,保证可靠性。Active NameNode 随时将 edits 信息写入 journal node,Standby NameNode 同步 edits 到本地并与内存元数据合并,保持与 Active NameNode 一致,之后将内存元数据写磁盘形成 fs image 上传替换 Active NameNode 的 fs image,Active NameNode 再新开 edits 文件。
HDFS 文件写入操作
- 客户端请求与权限检查:客户端发起上传文件请求(如 300 兆文件)至 Name Node,Name Node 检查目标目录是否存在及客户端权限,有权限则允许上传。
- 文件拆分:客户端将文件按 128 兆为单位拆分,300 兆文件拆分为两个 128 兆和一个 44 兆的 block,拆分在客户端完成,减轻 HDFS 压力。
- 分配 Data Node 与建立连接:上传每个 block 时,客户端向 Name Node 请求分配 Data Node。Name Node 依副本分配策略(第一个副本找最近节点,无则找最空闲节点;第二个副本找其他机架最空闲节点;第三个副本找与第二个副本相同机架最空闲节点)确定三个 Data Node 并返回。客户端与这三个 Data Node 以
pipeline
形式建立连接。 - 数据发送与确认:客户端通过
pipeline
通道以数据包形式发送数据。数据先到第一个 Data Node,内存接收后写入磁盘,同时转发至第二个 Data Node,第二个 Data Node 重复此操作至第三个 Data Node。第三个 Data Node 写入磁盘成功后,依次向上返回成功信息,最终第一个 Data Node 向客户端汇报写入成功且副本备份好。后续 block 按相同规则上传,全部上传完成后客户端向 Name Node 汇报,Name Node 记录原数据(文件拆分的 block 信息及存储节点等)。
HDFS 文件读取操作
- 权限检查与原数据返回:客户端发起读文件请求,Name Node 接收后检查权限,若有权限则返回文件原数据,原数据包含文件拆分的 block 数量及每个 block 所在节点,并按与客户端网络拓扑距离排序(最近节点排在前)。
- 读取与合并文件:客户端获取原数据后,与每个 block 所在的最近节点建立连接读取数据,读取完成后合并 block 成最终文件并返回。
HDFS 高可用
HDFS 单管理节点问题
- 内存上限问题:单个管理节点(如服务器内存为 128G)存放元数据,可能出现内存不足情况。一旦内存放满,管理端将无法处理请求,进而导致整个集群不可用。
- 单节点故障问题:若管理节点(name node)单点故障,整个集群会陷入不可用状态,影响系统正常运行。
联邦机制
- 原理:针对单节点内存受限问题,采用多台 name node 共同管理集群的方式。例如,可根据集群目录数量分配管理任务,若有 30 个目录,可安排 3 台节点各管理 10 个数据目录,实现管理负载均衡。
- 优势:通过多节点协作,降低了单个 name node 内存占满的概率,提升了系统稳定性和扩展性,有效解决了内存受限难题。
管理节点热备
- 节点设置:管理节点分为 active 节点(正在管理集群的节点)和 standby 节点(备用节点),在实际生产环境中可设置多个 standby 节点,以增强备用能力。
- 数据同步:active name node 将原数据文件(如 edits 文件)托管到 journal 集群(JNLOAD 集群)。standby 节点实时与 journal 集群同步数据,并将同步后的元数据存储在本地内存中,确保其与 active 节点的元数据保持一致,以便在 active 节点故障时能迅速接替工作。
高可用架构组件
- Journal 集群:主要负责元数据同步功能。它接收 active 节点托管的原数据文件,并为 standby 节点提供数据同步服务,保证集群元数据的一致性和完整性。
- Zookeeper 集群:作为分布式协调服务组件,在高可用架构中发挥关键作用。它通过启动多个进程(如 fover controller)监控 active 和 standby 节点状态。这些进程利用心跳机制定期向 Zookeeper 汇报节点状态。当 active 节点出现故障时,Zookeeper 能及时发现通信中断情况,将故障节点的状态从 active 切换为 standby,并从 standby 节点中选举出一个新的 active 节点,确保集群持续稳定运行。
HDFS 操作命令
shell 命令
- 文件系统查看命令
hdfs dfs -ls
:查看指定目录下文件和子目录信息。hdfs dfs -du
:显示目录或文件磁盘使用情况。hdfs dfs -count
:统计文件数量、目录数量和文件总大小。
- 文件操作命令
hdfs dfs -put
或hdfs dfs -copyFromLocal
:将本地文件复制到HDFS。hdfs dfs -get
或hdfs dfs -copyToLocal
:将HDFS文件复制到本地。hdfs dfs -cat
:查看HDFS文件内容。hdfs dfs -rm
:删除HDFS文件,删目录加-r
。
- 目录操作命令
hdfs dfs -mkdir
:在HDFS创建目录。hdfs dfs -rmdir
:删除HDFS空目录,非空目录用-r
参数删除。
Rest API
- 原理与优势:将 HDFS 操作命令转换为 HTTP 形式,因其兼容性好,各种编程语言均可通过发送网络请求调用,所以通用性强。
- 操作示例
- 文件上传:先以 URL 形式用“put”方法指定 HDFS NameNode 的 IP 与端口、“webhdfs/v1”及目标目录,执行后获取 3 个 DataNode 地址,再用“put”将本地文件上传至 DataNode 的指定目录。
- 文件下载:指定节点位置和操作路径,用“open”操作将文件下载到本地。
- 文件删除:用“delete”指定 HDFS 基本地址和目录进行删除操作。
HDFS 运维管理概述
- 主要讲述 HDFS 运维管理中命令的应用场景,而非逐字讲解命令。涉及系统配置、常见管理命令、数据处理操作、工具使用、配额与快照以及监控页面等方面内容,旨在为程序员、软件架构师和工程师提供 HDFS 运维的关键知识。
系统配置
- 核心配置文件:HDFS 有 core-site.xml 和 hdfs-site.xml 两个核心配置文件。core-site.xml 是 HDFS 的全局配置文件,用于配置 HDFS、map reduce 等组件;hdfs-site.xml 针对 HDFS 进行局部配置,其格式为在 configuration 标签下,每个配置放在 property 标签中,通过 name 和 value 设置参数。
- 启动前配置:启动 HDFS 前需配置 hadobe env.sh 文件,将本地 JDK 引入 java home 并填写到该文件中,使 Hadoop 能在 Java 环境运行。启动后一般只需更改配置文件。配置文件可设置 name node 存储位置(如 fs image、edits 文件等)、block size(默认 128 兆)、副本数(默认三副本,通常不建议修改)等参数。
常见管理命令
- 格式化:首次启动 HDFS 时,需对 name node 执行格式化操作(hdfs namenode -format)。此操作会在 name node 生成 name node id 并分发给 data node,使 data node 确定主节点,实现认主。
- 查看文件系统信息:启动后可用
hdfs dfs -report
命令查看文件系统基本信息,如已用空间、剩余空间及占比等; - 用
fsck
命令可检查文件系统健康状况,能查看指定目录下的 block 数、丢失副本数、坏块等信息,发现坏块需排查修复,应定期执行该检查。
-
安全模式:可通过
hdfs dfsadmin
命令手动进入或退出安全模式,但一般不建议手动操作。若因系统异常进入安全模式,不建议手动强退,以免引发问题。进行集群维护时,可让系统自动进入只读安全模式,之后再手动退出。
-
主备切换与集群扩缩容:使用 HA 命令可进行主备节点切换,查看节点状态并按需转换;在集群扩容和缩容时,分别使用服役和退役操作对集群进行调整。
-
数据重分布:数据倾斜(集群节点数据量分布不均)时,执行
hdfs dfs balancer
命令进行数据重分布,将数据多的节点数据拷贝到数据少的节点,使各节点数据均匀。默认带宽为 1 兆每秒,集群空闲时(如凌晨),可用balancer band width
提升带宽(如设为 100 兆或更高)以加快重分布速度。
数据处理工具
- Distcp:主要用于 HDFS 集群之间的数据拷贝,可将单线程拷贝任务转换为分布式并发的 mr 任务,性能更高。集群内部拷贝也可使用,且性能优于单线程 CP,但主要应用于集群间拷贝。
配额与快照
-
配额限制:quota 可对目录进行空间和文件数量限制。例如创建 name quarter 和 space quarter 目录后,可分别设置其文件数量上限(如 name quarter 设为 100 个文件)和最大空间(如 space quarter 设为 10G)。
-
快照功能:可给目录打快照以便数据恢复。创建快照时会在目录下生成隐藏文件夹.snapshot,其中存放快照数据。如对 tap 目录创建快照后删除该目录下数据,可从.snapshot 文件夹中拷出数据进行恢复。
监控页面
- 开源 HDFS 的 50070 端口有自带监控页,在该页面可查看集群基本信息,如安全模式状态等,还可通过其他 label 进行集群监控和管理。