列式存储工具 HBase 总结——大数据组件

HBase是Hadoop生态中的分布式列式存储数据库,提供强一致性和高可用性。其数据模型基于列族,支持随机读写操作。文章详细介绍了HBase的逻辑视图、物理视图、整体架构,以及读写流程中的Compaction机制。相较于HBase,ClickHouse在数据分析方面表现出更高的性能,且两者在数据模型、存储引擎和查询性能上有显著差异。
摘要由CSDN通过智能技术生成

概述

HBase 是 Hadoop 中表存储层中的分布式数据库(列式存储)。

  • 列式存储:HBase使用列式存储模型,数据以列族(column family)的形式组织。每个列族可以包含多个列限定符(column qualifier)。这种存储模型使得读取特定列或列族的数据变得非常高效。
  • 分布式存储:HBase将数据分布存储在一个集群中的多个机器上。数据被分割成多个区域(regions),每个区域负责存储一部分数据。这种分布式存储模型支持横向扩展,可以处理大规模数据集。
  • 自动分片:HBase使用自动分片(automatic sharding)机制将数据分散到多个区域中。每个区域在存储中有连续的范围,并且负责存储该范围内的所有数据。当数据量增长时,HBase可以自动拆分区域,保持负载均衡。
  • 强一致性:HBase提供强一致性的读写操作。它使用多版本并发控制(MVCC)来处理并发读写,并使用写入前日志(WAL)来确保数据持久性和一致性。
  • 高可用性:HBase通过在集群中复制数据来提供高可用性。数据可以在多个服务器上进行复制,以防止单点故障。当某个服务器发生故障时,可以从其他副本中获取数据。
  • 扩展性:HBase可以在需要时进行简单的扩展。通过添加更多的机器,可以增加集群的容量和吞吐量。
  • 支持随机访问:与传统的分布式存储系统相比,HBase提供了对数据的快速随机读写访问。它支持按行键(row key)对数据进行快速查找和访问。

HBase适用于需要处理大量结构化数据的场景,例如日志分析、在线分析处理(OLAP)、时间序列数据等。它在Hadoop生态系统中扮演着重要的角色,并且被广泛应用于大数据领域。

逻辑视图

image.png
HBase 的表逻辑视图包括列族,列标识,行键,分区,时间戳。
列族

  • 列族是逻辑上相关的列的集合,被一起存储和访问,并在物理存储上紧密的组织在一起。
  • 在表创建的时候就需要创建,是静态的,不允许修改。

列标识

  • 列标识就是列族中对应的列。

行键

  • 唯一标识,访问 HBase 有三种方式:

通过单个 row key 访问,通过 row key 的 range,全表扫描
分区

  • 根据行键划分为不同的分区,分区上是实际的物理存储

时间戳

  • 插入单元格时的时间戳,默认作为单元格的版本号,不同版本的数据按照时间戳倒序排序,HBase 是不会对原数据进行修改的,没修改一次就会增加一个时间戳版本号。

存储单元格

  • 在 HBase 中,值作为一个单元保存在单元格中,定位一个单元,需要满足“行键+列键+时间戳”三要素。

每个 Cell 保存着同一份数据的多个版本。
Cell 中没有数据类型,完全是字节存储。

物理视图

image.png
HBase的物理视图主要涉及到数据在磁盘上的存储和组织方式,以 key-value 的形式存储在分布式文件系统上,key 包括行键,列族和列,时间戳信息来确定一个值。
image.png
存储文件(Store File)是 HBase 中实际存储数据的文件,每个列族在磁盘上都有一个或多个存储文件。存储文件时按照列族和行键的顺序进行排序的,并且被分成多个数据块。
相同的列族会保存在同一个存储文件中。
逻辑VS物理
image.png
逻辑视图以二维表的形式展示,物理存储以 key-value 的形式存储,同一个列族的列会被存储在同一个存储文件中,所以上图中的 Personal 存储在一个文件中,Office 存储在一个文件中。

整体架构

image.png
HMaster

  • 负责负载均衡 RegionServer, 告诉 RegionServer 需要维护哪些 Region。管理用户的CRUD操作。

Region
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-H3tu6sq8-1688551548430)(https://cdn.nlark.com/yuque/0/2023/png/29051477/1688539360581-dc1fefbb-ff20-4064-894b-2fb9dabac0c4.png#averageHue=%23ecbba3&clientId=u032b0f9a-5501-4&from=paste&height=260&id=u1be69605&originHeight=260&originWidth=865&originalType=binary&ratio=1&rotation=0&showTitle=false&size=43091&status=done&style=none&taskId=u4aab6af9-87af-4c78-86fa-7f7a4b7c178&title=&width=865)]

  • Region 由多个 Store 组成,HBase 使用表存储数据集,当表的大小超过设定的值时,HBase 会自动将表划分为不同的Region, 它是 HBase 集群上分布式存储和负载均衡的最小单位。
  • Store 由 MemStore(内存缓冲) 和 StoreFile(存储文件集) 组成,用户写入的数据会先写入内存缓冲,当达到一定量后在写入文件中。

Region Server
image.png

  • 一个 HBase 集群包含多个 Region Server, 一个 Region Server 中又包含多个 Region, Region Server 负责对HDFS 中读写数据和管理 Region 和 HLog。
  • 写操作会先记录在 Hlog 中,然后才被加载到 memStore 中,保证故障修复。

WAL 技术

  • HBase 使用 WAL预写日志来保证故障恢复,Hlog 就是预写日志的实现。

ZooKeeper 和 Client

  • ZooKeeper 存储的是 HBase 中的 ROOT 表(根数据表)和 META 表(元数据表),元数据表保存普通用户表的Region 标识符信息,标识符格式为:表名+开始主键+唯一ID。
  • Client 客户端访问 HBase的单位。

HBase 读流程

image.png

  • Client 会先从 ZooKeeper 查询元信息,从META 表中找到相应 row key 需要访问的 Region Server, 并且将元信息 cache 在 client 端

HBase 写流程

image.png

  1. Client 的 Put 操作会将数据先写入WAL
  2. 当数据写入WAL,然后将数据拷贝到MemStore。MemStore 是内存空间,数据并未写入磁盘。
  3. 一旦数据成功拷贝到 MemStore。 Client 将收到ACK。
  4. 当 MemStore 中的数据达到阈值,数据会写入 HFile。

Compaction

为什么需要 Compaction?
HBase 的 MemStore 在满足阈值的情况下会将内存中的数据刷写成 HFile ,一个 MemStore 刷写就会形成一个 Hfile。
随着时间的推移,同一个 Store 下的 HFile 会越来越多,文件太多会影响HBase查询性能,主要体现在查询数据的io次数增 加。
为了优化查询性能,HBase会合并小的HFile以减少文件数量,这种合并HFile的操作称为Compaction,这也是为什么要进行Compaction的主要原因。
HBase 有两种合并方式
image.png

  • Minor Compaction :会将邻近的若干个 HFile 合并,在合并过程中会清理 TTL 的 数据,但不会清理被删除的数据。
  • Major Compaction:会将一个 store 下的所有 HFile 进行合并,并且会清理掉过期的和被删除的数据,即在 Major Compaction 会删除全部需要删除的数据。值得注意的是,一般情况下,Major Compaction时间会持续比较长,整个过程会消耗 大量系统资源,对上层业务有比较大的影响。因此,生产环境下通常关闭自动触发Major Compaction功能,改为手动在业务低峰期触发。

Compaction 存在的问题
Compaction是一个IO密集型操作,必然对读写造成性能影响。

  • 读性能会在 compaction 期间略微降低,而在 compaction 后又回到一个稳定的水平,从下图可以看到图中会有许多毛刺这是因为当进行 compaction 时读性能就会短暂的降低,而在完成后又回到正常水平。

image.png

  • HFile个数超过hbase.hstore.blockingStoreFiles(默认为7)时, 系统将会强制执行compaction操作进行文件合并, 此时写情况会被阻塞。在数据生成速度很快时,HFile的不断快 速生成就需要进行频繁compaction操作,从而限制写请求速度。

总结

随着 Hadoop 的式微,HBase 也渐渐退出了历史的舞台,在笔者所在公司,基本上已经使用 ClickHouse 替换了 HBase, 只有少量的业务场景,还在使用 HBase。
这里对 HBase 和 ClickHouse 做一个对比:

  1. 数据模型:
    • HBase:HBase是一种面向列族的键值存储系统,适用于半结构化和结构化数据。它支持高度灵活的数据模型,可以动态添加列族,并且可以处理大量的随机读写操作。
    • ClickHouse:ClickHouse是一种面向列的分析数据库,专注于高性能的数据分析。它使用表格模型,并且提供了SQL查询语言,支持复杂的数据分析和聚合操作。
  2. 存储引擎:
    • HBase:HBase使用HFile作为底层存储引擎,适合大规模数据存储和随机读写操作。它支持高可扩展性和高可用性,并能够处理海量数据。
    • ClickHouse:ClickHouse使用自定义的列存储引擎,专为大规模数据分析和聚合而设计。它采用压缩和数据分区技术,以提供高性能的查询和高度可扩展性。
  3. 查询性能:
    • HBase:HBase适合处理随机读写操作,但对于复杂的数据分析和聚合查询,性能可能不如专门为此设计的系统。它通常在低延迟的在线交互查询场景中表现较好。
    • ClickHouse:ClickHouse专注于高性能的数据分析,可以处理大规模数据集和复杂查询。它采用列存储和数据压缩等技术,以实现快速的数据扫描和聚合操作。
  4. 数据一致性:
    • HBase:HBase提供强一致性的读写操作,它使用多版本并发控制(MVCC)和写入前日志(WAL)来确保数据的一致性和持久性。
    • ClickHouse:ClickHouse提供的是最终一致性,它通过异步数据复制和数据分区来实现高可用性和可扩展性。
  5. 生态系统和集成:
    • HBase:HBase是Apache Hadoop生态系统的一部分,与Hadoop和其他工具(如Hive和Spark)紧密集成。它可以无缝地与其他Hadoop组件协同工作,处理大规模数据处理工作流。
    • ClickHouse:ClickHouse的生态系统相对较小,但它提供了与常见工具和框架(如Kafka、Spark和Presto)的集成。它支持各种数据导入和导出方式,以方便与其他系统集成。

因此,选择使用HBase还是ClickHouse取决于具体的需求和使用场景。如果需要处理大量的随机读写操作或与Hadoop生态系统紧密集成,HBase可能更适合。如果需要进行大规模的数据分析和聚合查询,并且对性能和扩展性有较高的要求,ClickHouse可能更适合。

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

一切如来心秘密

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值