当前位置： 首页 > news >正文

大数据(1)-hdfshbase

news 2025/7/1 12:50:31

hbase&hdfs

一、体系结构

HDFS是一个标准的主从(Master/Slave)体系结构的分布式系统；HDFS集群包含一个或多个NameNode(NameNode HA会有多个NameNode) 和 多个DataNode(根据节点情况规划),用户可以通过HDFS客户端同NameNode 和 DataNode进行交互以访问文件系统。 ​ HDFS公开文件系统名称空间，并允许将用户数据存储在文件中。在内部，一个文件被分成一个或多个块，这些块存储在一组datanode中。NameNode执行文件系统名称空间操作，如打开、关闭和重命名文件和目录。它还确定块到datanode的映射。datanode负责处理来自文件系统客户机的读和写请求。datanode还根据来自NameNode的指令执行块创建、删除和复制(体系结构如下图所示)。

二、相关概念

HDFS文件系统维护着一个命名空间，它是一个树状结构，包含文件和目录。这个命名空间以根目录“/”开始，用户可以创建、删除文件和目录，以及修改它们的权限。 1.NameNode 负责客户端请求的响应 元数据的管理（查询，修改） namenode是HDFS集群主节点，负责维护整个hdfs文件系统的目录树，以及每一个路径（文件）所对应的block块信息（block的id，及所在的datanode服务器）

2.JournalNode NameNode之间共享数据(主要体现在 NameNode配置 HA)

3.DataNode 存储管理用户的文件块数据 定期向namenode汇报自身所持有的block信息（通过心跳信息上报）

4.Data Blocks HDFS中的文件在物理上是分块存储（block），块的大小可以通过配置参数( dfs.blocksize)来规定，默认大小在hadoop2.x版本中是128M，老版本中是64M

5.Data Replication 每一个block都可以在多个datanode上存储多个副本（副本数量也可以通过参数设置dfs.replication，默认是3）

6.HDFS通信协议 HDFS作为分布式文件系统,涉及到数据节点，名称节点和客户端三者之间的配合，相互调用才能实现。为了降低节点间代码的耦合性，提高单个节点的内聚性，HDFS将这些节点间的调用抽象成不同的接口。 Hadoop RPC接口：HDFS中基于Hadoop RPC框架实现的接口。

三、文件和目录的表示

  • 文件：在HDFS中，文件被分割成多个数据块（Block），每个数据块默认大小为128MB（或配置为其他大小，如64MB、256MB等），这些数据块被分布存储在HDFS集群中的不同DataNode上。

  • 目录：目录是文件系统的组织单元，用于对文件进行分类和管理。目录本身不存储数据，但包含文件和子目录的元数据。

四、元数据的管理

  • NameNode：NameNode是HDFS集群的主节点，负责管理文件系统的命名空间以及客户端对文件的访问。它存储着文件系统的元数据，包括文件名、目录结构、数据块的位置信息等。

  • DataNode：DataNode是HDFS集群的工作节点，负责存储数据块。每个DataNode会定期向NameNode报告它所存储的数据块列表，以便NameNode能够跟踪整个文件系统的数据分布。

五、数据块的分布和复制

  • 数据块分布：HDFS将数据块分布存储在多个DataNode上，以实现数据的冗余和可靠性。这有助于在单个DataNode出现故障时，仍然能够访问数据。

  • 数据块复制：HDFS默认将数据块复制3份，存储在不同的DataNode上。这种复制策略有助于防止数据丢失，提高数据的可用性。用户可以根据需要调整复制因子，以适应不同的存储需求和成本考虑。

六、HDFS 路径示例

\1. 典型目录结构

/                 # 根目录
├── tmp           # 临时目录
├── user          # 用户目录
│   └── hive      # Hive 数据仓库
│       └── warehouse
└── data          # 业务数据目录└── logs      # 日志文件

\2. 分区目录（常见于大数据场景） 按时间或业务维度分区，提升查询效率：

/user/hive/warehouse/sales
├── pt=2023-10-01
├── pt=2023-10-02
└── pt=2023-10-03

HBase数据模型

一、hbase核心概念与架构

1. 数据模型

  • 数据组织方式：HBase中的数据以Key-Value形式存储在底层HDFS中。每个数据单元（Cell）由行键（Row Key）、列族（Column Family）、列限定符（Column Qualifier）、时间戳（Timestamp）和值（Value）五部分组成，但存储时会被序列化为一个Key-Value对。

  • Key的构成：Key由行键、列族、列限定符和时间戳组成，Value是具体的单元格数据。这种设计使得HBase能够高效地根据Key进行数据的查找和访问。

  • HBase采用表来组织数据，采用命名空间（NameSpace）对表进行逻辑分组。

    NameSpace: 命名空间，类似于mysql中的database，默认有default和hbase，用户表默认在default中

    表：HBase采用表来组织数据，表由行和列组成，列划分为若干个列族。

    行：每个HBase表都由若干行组成，每个行由可排序的行键（row key）来标识。

    列：采用列族:列限定符的形式确定具体的一列。

    列族：一个HBase表被分组成许多“列族”（Column Family）的集合，它是基本的访问控制单元。列族可以动态添加，但在定义表时需要指定至少一个列族，在使用某个列族时要事先定义。 列限定符：表在水平方向由一个或者多个列族组成，一个列族中可以包含任意多个列，同一个列族里面的数据存储在一起。列族里的数据通过“列限定符”（Column qualifier）来定位。 单元格：在HBase表中，通过行、列族和列限定符确定一个“单元格”（cell），单元格中存储的数据没有数据类型，总被视为字节数组byte，所以在定义表时无需定义数据的类型，使用时用户需要自行进行数据类型转换

    时间戳：每个单元格都保存着同一份数据的多个版本，这些版本采用时间戳进行索引， HBase中执行更新操作时，并不会删除数据旧的版本，而是生成一个新的版本，旧有的版本仍然保留（这是和HDFS只允许追加不允许修改的特性相关的）

    HBase是一个稀疏、多维度、排序的映射表，这张表的索引是行键、列族、列限定符和时间戳，在进行数据存储的时，其采用key-value形式：Table + RowKey（升序） + ColumnFamily + Column + Timestamp --> Value

2. 物理架构
┌─────────────────────────────────────────────────────┐
│                    Client Applications                │
└───────────────────┬───────────────────┬───────────────┘│                   │
┌───────────────────┴───────────────────┴───────────────┐
│                        ZooKeeper Cluster                │
│  (协调HMaster选举、存储元数据位置、监控RegionServer状态)  │
└───────────────────┬───────────────────┬───────────────┘│                   │
┌───────────────────┴───────────────────┴───────────────┐
│                     HMaster (主节点)                    │
│  (管理Region分配、表结构变更、负载均衡)                 │
└───────────────────┬───────────────────┬───────────────┘│                   │
┌───────────────────┴───────────────────┴───────────────┐
│                 RegionServer集群 (工作节点)              │
│  ┌──────────────────┐  ┌──────────────────┐           │
│  │    Region 1      │  │    Region 2      │           │
│  │ (存储部分数据)    │  │ (存储部分数据)    │           │
│  └──────────────────┘  └──────────────────┘           │
└─────────────────────────────────────────────────────┘↑                                  ↑│                                  │
┌─────────┴──────────┐       ┌──────────────┴─────────┐
│    HDFS存储系统     │       │    HLog预写日志        │
│ (实际数据持久化)     │       │ (保证数据写入可靠性)    │
└────────────────────┘       └───────────────────────┘
3. 关键组件

  • RegionServer：负责处理数据的读写请求，管理多个 Region（数据分片）。

  • Region：HBase 的基本数据分片单位，按 RowKey 范围划分，每个 Region 由多个 Store 组成（每个 Store 对应一个列族）。

  • HMaster：集群的主节点，负责 Region 分配、负载均衡、表结构管理等元数据操作。

  • ZooKeeper：协调集群状态，存储元数据位置，保证 HMaster 的高可用。

  • HLog（WAL）：预写日志，确保数据写入的持久性和可靠性。

二、核心特性

1. 水平扩展

  • 通过添加 RegionServer 节点线性扩展存储容量和读写性能，适合 PB 级数据存储。

2. 高可用性

  • RegionServer 故障时，HMaster 自动将其管理的 Region 重新分配到其他节点。

  • HLog 和 HDFS 副本机制确保数据不丢失。

3. 强一致性

  • 支持单行事务（Single Row Atomicity），保证同一 RowKey 下的所有操作要么全部成功，要么全部失败。

4. 灵活的数据模型

  • 无需预定义表结构，支持动态添加列，适合半结构化数据。

5. 与 Hadoop 生态集成

  • 无缝对接 HDFS（存储）、MapReduce（批处理）、Spark（实时计算）、Hive（数据仓库）等。

三、数据读写流程

1. 写流程
Client → RegionServer → HLog（预写） → MemStore（内存缓存） → StoreFile（HFile，定期刷写至HDFS）

  1. 客户端向 RegionServer 发送写请求。

  2. RegionServer 先写入 HLog（保证故障恢复），再写入 MemStore（内存中的数据结构）。

  3. 当 MemStore 达到阈值时，触发 flush 操作，将数据写入 HDFS 成为 HFile。

2. 读流程
Client → ZooKeeper → Meta表 → 目标RegionServer → MemStore（内存） + BlockCache（缓存） + HFile（磁盘）

  1. 客户端通过 ZooKeeper 找到 Meta 表（存储 Region 元数据）的位置。

  2. 从 Meta 表获取目标数据所在的 RegionServer 地址。

  3. 向 RegionServer 发送读请求，RegionServer 先查 MemStore（未刷写的数据），再查 BlockCache（读缓存），最后查 HFile（磁盘）。

四、应用场景

1. 实时数据存储

  • 适合需要快速读写的场景，如社交平台的消息存储、电商的订单数据。

2. 时序数据

  • 如物联网设备监控数据、金融交易记录，按时间戳排序存储，支持高效范围查询。

3. 大数据分析的前端存储

  • 作为 Hadoop 生态的实时查询层，为离线分析结果提供快速访问（如用户画像数据）。

4. 高并发场景

  • 支持百万级 QPS（每秒查询率），如搜索引擎的索引存储。

五、优缺点分析

1. 优点

  • 高性能：分布式架构和 LSM-Tree 存储引擎（HFile）保证了高吞吐量。

  • 高扩展：线性扩展能力轻松应对数据增长。

  • 灵活模式：适合快速迭代的业务场景，无需固定 Schema。

  • 强一致性：单行事务满足关键业务需求。

2. 缺点

  • 不支持复杂查询：仅支持 RowKey 的精确查询和范围扫描，不支持 SQL 和多表 Join。

  • 写入延迟：频繁小批量写入可能触发频繁 flush，影响性能。

  • 运维复杂：集群部署和调优需要专业知识，依赖 HDFS 和 ZooKeeper。

六、与其他数据库的对比

特性HBaseCassandraMongoDB
数据模型分布式哈希表，面向列族宽列存储文档型（JSON-like）
一致性强一致性（单行）最终一致性（可调）强一致性（可调）
查询能力仅支持 RowKey 查询CQL（类 SQL）丰富的文档查询
写性能高（LSM-Tree）高（LSM-Tree）中等（B-Tree）
应用场景实时读写、时序数据高可用、写密集型灵活查询、文档存储

七、最佳实践与性能优化

1. RowKey 设计原则

  • 散列性：避免热点问题，如使用哈希前缀（如hash(userId) + timestamp）。

  • 长度适中：过长会增加存储开销，建议不超过 100 字节。

  • 业务相关性：如时序数据按时间戳降序排列（新数据优先）。

2. 预分区（Pre-splitting）

  • 提前创建多个 Region，避免初始写入时的热点问题。

3. 内存管理

  • 合理配置 MemStore 和 BlockCache 大小，读写密集型场景需平衡两者比例。

4. 压缩与合并

  • 启用数据压缩（如 Snappy/LZO）减少存储开销，定期执行 Major Compaction 合并 HFile。

一、核心定位与架构差异**

  1. HDFS（Hadoop Distributed File System）

    • 定位：分布式文件系统，专为存储超大规模数据集设计。

    • 架构特点

      • 数据以文件块（默认128MB/256MB）形式分布式存储，支持多副本（默认3份）确保容错性。

  • 采用主从架构（NameNode管理元数据，DataNode存储数据），适合一次写入、多次读取的批处理场景。

  1. HBase

    • 定位：基于HDFS的分布式列式数据库，提供实时读写能力。

    • 架构特点

      • 数据以键值对（RowKey+列族）形式存储，支持稀疏多维映射表结构。

  • 依赖ZooKeeper协调分布式事务，通过RegionServer处理数据请求，适合高频随机访问场景。

二、数据模型对比
维度HDFSHBase
存储结构层次化文件目录（如/user/data）稀疏多维表（行键RowKey+列族）
数据组织文件块分散存储，无固定模式列族动态扩展，支持版本控制
访问粒度文件级操作（如cat, cp）行级/列级随机访问（如GET, SCAN）
典型操作顺序读写（如MapReduce任务）点查、范围查询、计数器（如INCR）
三、性能与应用场景差异

  1. 性能特点

    • HDFS

      • 优势：高吞吐量（适合TB/PB级数据），顺序读写性能优异。

  • 劣势：随机访问延迟高（毫秒级），不支持实时更新。

    • HBase

      • 优势：低延迟（微秒级响应），支持ACID特性（通过Phoenix等工具）。

  • 劣势：大规模扫描性能弱于HDFS，需避免热点RowKey设计。

  1. 典型场景

    • HDFS适用场景

      • 日志存储与分析（如Nginx日志）

  • 数据备份与归档（如Hadoop集群快照）

    • 离线批处理（如Spark/MapReduce任务）

    • HBase适用场景

      • 实时推荐系统（如广告点击数据流）

  • 时序数据存储（如IoT传感器数据）

    • 高并发查询（如社交网络关系链）

四、技术细节对比

  1. 数据持久化

    • HDFS：数据直接写入DataNode，通过副本机制保证可靠性。

    • HBase：数据先写入内存（MemStore），刷写至HDFS（StoreFile），依赖HFile格式压缩存储。

  2. 扩展性

    • HDFS：纵向扩展NameNode（如HDFS Federation）或横向增加DataNode。

    • HBase：通过Region分裂自动扩展，支持预分区优化。

  3. 生态工具

    • HDFS：常与Hive、Spark集成，支持SQL分析。

    • HBase：可结合Phoenix（SQL引擎）、Apache NiFi（数据导入）等工具。

五、优缺点总结
特性HDFSHBase
优点高容错性、高吞吐、易扩展低延迟、灵活Schema、支持实时更新
缺点无随机写入、不适合小文件运维复杂、需调优RowKey设计
资源消耗内存占用低（适合廉价硬件）需较高内存（RegionServer缓存）

HDFS存储特点

  • 文件存储：存储大文件（GB/TB级）

  • 不可变数据：写入后不可修改，只能追加或重写

  • 块结构：默认128MB/256MB的大块存储

  • 目录结构：传统的文件目录层次结构

HBase存储特点

  • 表结构：由行键(RowKey)、列族(Column Family)、列限定符(Column Qualifier)组成

  • 可变数据：支持数据更新和删除

  • 小文件优化：适合存储大量小数据（KB/MB级）

  • 物理存储：最终以HFile格式存储在HDFS上

HDFS适合场景

  • 存储大规模静态数据（日志、历史数据）

  • 批处理分析（MapReduce、Spark等）

  • 数据仓库底层存储

  • 一次写入多次读取(WORM)模式

HBase适合场景

  • 需要实时随机读写的应用

  • 海量数据的高并发访问

  • 稀疏数据存储（许多列为空）

  • 需要快速查询的键值访问

  • 增量数据收集（如用户行为数据）

HDFS核心组件

  • NameNode：元数据管理

  • DataNode：实际数据存储

  • Secondary NameNode：辅助元数据管理

HBase核心组件

  • HMaster：协调管理

  • RegionServer：处理读写请求

  • ZooKeeper：协调服务

  • HFile：实际存储格式（在HDFS上）

  1. 选择HDFS当满足：

    • 数据主要用于离线分析

    • 不需要频繁更新

    • 数据量极大且增长稳定

    • 需要高吞吐顺序读写

  2. 选择HBase当满足：

    • 需要低延迟随机访问

    • 数据模型是半结构化/稀疏的

    • 需要支持数据更新

    • 应用需要实时读写能力

http://www.xdnf.cn/news/1075267.html

相关文章：

  • 【零基础学AI】第13讲：随机森林实战 - 用户行为预测
  • Spring Security 鉴权与授权详解（前后端分离项目）
  • 电脑开机加速工具，优化启动项管理
  • 服务器上设置了代理之后，服务器可以访问外网，但是不能访问服务器本地。如何解决
  • 重构老项目不再“踩雷”：飞算JavaAI的本地化智能合并实战
  • HarmonyOS NEXT应用元服务常见列表操作多类型列表项场景
  • 设计模式之外观模式
  • .net8导出影像图片按现场及天拆分
  • 调试W5500（作为服务器）
  • macos 使用 vllm 启动模型
  • 【微服务】.Net中使用Consul实现服务高可用
  • 51c大模型~合集144
  • 2025年光学工程、精密仪器与光电子技术国际会议（OEPIOT 2025）
  • 物联网基础
  • Git 常用命令、常用错误的总结
  • 2 大语言模型基础-2.2 生成式预训练语言模型GPT-2.2.2 有监督下游任务微调-Instruct-GPT强化学习奖励模型的结构改造与维度转换解析
  • [论文阅读] Neural Architecture Search: Insights from 1000 Papers
  • 超表面重构卡塞格林望远镜 | 从传统架构到新型光学系统
  • 最大矩形最大正方形-力扣
  • 优雅草蜻蜓HR人才招聘系统v2.0.9上线概要 -优雅草新产品上线
  • 飞算JavaAI 2.0.0深度测评：自然语言编程如何重构开发生产力？
  • 键盘第一下无反应
  • 04密码加密
  • C#程序调用cmd执行命令
  • 卡片跳转到应用页面（router事件）
  • 生成式人工智能实战 | 变分自编码器（Variational Auto-Encoder, VAE）
  • 基于STM32温湿度检测—串口显示
  • HTML5 实现的圣诞主题网站源码，使用了 HTML5 和 CSS3 技术，界面美观、节日氛围浓厚。
  • k8s pod深度解析
  • k8s创建定时的 Python 任务（CronJob）