Hbase和Hive的区别,Hbase与传统数据库的区别

本文对比分析了HBase与Hive及传统关系数据库(RDBMS)的不同之处,介绍了各自的适用场景,强调了HBase在大数据实时查询方面的优势,并详细解释了HBase与RDBMS在数据排布、查询方式等方面的差异。
部署运行你感兴趣的模型镜像

HBase 于 Hive 的区别,我们简单的梳理一下 Hive 和 HBase 的应用场景:

Hive 适合用来对一段时间内的数据进行分析查询,例如,用来计算趋势或者网站的日志。Hive 不应该用来进行实时的查询(Hive 的设计目的,也不是支持实时的查询)。因为它需要很长时间才可以返回结果;HBase 则非常适合用来进行大数据的实时查询,例如 Facebook 用 HBase 进行消息和实时的分析。对于 Hive 和 HBase 的部署来说,也有一些区别,Hive 一般只要有 Hadoop 便可以工作。而 HBase 则还需要 Zookeeper 的帮助(Zookeeper,是一个用来进行分布式协调的服务,这些服务包括配置服务,维护元信息和命名空间服务)。再而,HBase 本身只提供了 Java 的 API 接口,并不直接支持 SQL 的语句查询,而 Hive 则可以直接使用 HQL(一种类 SQL 语言)。如果想要在 HBase 上使用 SQL,则需要联合使用 Apache Phonenix,或者联合使用 Hive 和 HBase。但是和上面提到的一样,如果集成使用 Hive 查询 HBase 的数据,则无法绕过 MapReduce,那么实时性还是有一定的损失。Phoenix 加 HBase 的组合则不经过 MapReduce 的框架,因此当使用 Phoneix 加 HBase 的组成,实时性上会优于 Hive 加 HBase 的组合,我们后续也会示例性介绍如何使用两者。最后我们再提下 Hive 和 HBase 所使用的存储层,默认情况下 Hive 和 HBase 的存储层都是 HDFS。但是 HBase 在一些特殊的情况下也可以直接使用本机的文件系统。例如 Ambari 中的 AMS 服务直接在本地文件系统上运行 HBase。

 

HBase 与传统关系数据库的区别

首先让我们了解下什么是 ACID。ACID 是指数据库事务正确执行的四个基本要素的缩写,其包含:原子性(Atomicity)、一致性(Consistency)、隔离性(Isolation)以及持久性(Durability)。对于一个支持事务(Transaction)的数据库系统,必需要具有这四种特性,否则在事务过程(Transaction Processing)当中无法保证数据的正确性,交易过程极可能达不到交易方的要求。下面,我们就简单的介绍下这 4 个特性的含义。

  • 原子性(Atomicity)是指一个事务要么全部执行,要么全部不执行。换句话说,一个事务不可能只执行了一半就停止了。比如一个事情分为两步完成才可以完成,那么这两步必须同时完成,要么一步也不执行,绝不会停留在某一个中间状态。如果事物执行过程中,发生错误,系统会将事物的状态回滚到最开始的状态。
  • 一致性(Consistency)是指事务的运行并不改变数据库中数据的一致性。也就是说,无论并发事务有多少个,但是必须保证数据从一个一致性的状态转换到另一个一致性的状态。例如有 a、b 两个账户,分别都是 10。当 a 增加 5 时,b 也会随着改变,总值 20 是不会改变的。
  • 隔离性(Isolation)是指两个以上的事务不会出现交错执行的状态。因为这样可能会导致数据不一致。如果有多个事务,运行在相同的时间内,执行相同的功能,事务的隔离性将确保每一事务在系统中认为只有该事务在使用系统。这种属性有时称为串行化,为了防止事务操作间的混淆,必须串行化或序列化请求,使得在同一时间仅有一个请求用于同一数据。
  • 持久性(Durability)指事务执行成功以后,该事务对数据库所作的更改便是持久的保存在数据库之中,不会无缘无故的回滚。

在具体的介绍 HBase 之前,我们先简单对比下 HBase 与传统关系数据库的(RDBMS,全称为 Relational Database Management System)区别。如表 1 所示。

表 1. HBase 与 RDBMS 的区别

 HBaseRDBMS
硬件架构类似于 Hadoop 的分布式集群,硬件成本低廉传统的多核系统,硬件成本昂贵
容错性由软件架构实现,由于由多个节点组成,所以不担心一点或几点宕机一般需要额外硬件设备实现 HA 机制
数据库大小PBGB、TB
数据排布方式稀疏的、分布的多维的 Map以行和列组织
数据类型Bytes丰富的数据类型
事物支持ACID 只支持单个 Row 级别全面的 ACID 支持,对 Row 和表
查询语言只支持 Java API (除非与其他框架一起使用,如 Phoenix、Hive)SQL
索引只支持 Row-key,除非与其他技术一起应用,如 Phoenix、Hive支持
吞吐量百万查询/每秒数千查询/每秒

理解了上面的表格之后,我们在看看数据是如何在 HBase 以及 RDBMS 中排布的。首先,数据在 RDBMS 的排布大致如表 2。

表 2. 数据在 RDBMS 中的排布示例

ID密码时间戳
111120160719
222220160720

那么数据在 HBase 中的排布会是什么样子呢?如表 3 所示(这只是逻辑上的排布)。

表 3. 数据在 HBase 中的排布(逻辑上)

Row-KeyValue(CF、Qualifier、Version)
1info{'姓': '张','名':'三'}
pwd{'密码': '111'}
2Info{'姓': '李','名':'四'}
pwd{'密码': '222'}

从上面示例表中,我们可以看出,在 HBase 中首先会有 Column Family 的概念,简称为 CF。CF 一般用于将相关的列(Column)组合起来。在物理上 HBase 其实是按 CF 存储的,只是按照 Row-key 将相关 CF 中的列关联起来。物理上的数据排布大致可以如表 4 所示。

表 4. 数据在 HBase 中的排布

Row-KeyCF:Column-Key时间戳Cell Value
1info:fn123456789
1info:ln123456789
2info:fn123456789
2info:ln123456789

我们已经提到 HBase 是按照 CF 来存储数据的。在表 3 中,我们看到了两个 CF,分别是 info 和 pwd。info 存储着姓名相关列的数据,而 pwd 则是密码相关的数据。上表便是 info 这个 CF 存储在 Hbase 中的数据排布。Pwd 的数据排布是类似的。上表中的 fn 和 ln 称之为 Column-key 或者 Qulifimer。在 Hbase 中,Row-key 加上 CF 加上 Qulifier 再加上一个时间戳才可以定位到一个单元格数据(Hbase 中每个单元格默认有 3 个时间戳的版本数据)。初学者,在一开始接触这些概念是很容易混淆。其实不管是 CF 还是 Qulifier 都是客户定义出来的。也就是说在 HBase 中创建表格时,就需要指定表格的 CF、Row-key 以及 Qulifier。我们会在后续的介绍中,尝试指定这些相关的概念,以便加深理解。这里我们先通过下图理解下 HBase 中,逻辑上的数据排布与物理上的数据排布之间的关系。

图 1. Hbase 中逻辑上数据的排布与物理上排布的关联

从上图我们看到 Row1 到 Row5 的数据分布在两个 CF 中,并且每个 CF 对应一个 HFile。并且逻辑上每一行中的一个单元格数据,对应于 HFile 中的一行,然后当用户按照 Row-key 查询数据的时候,HBase 会遍历两个 HFile,通过相同的 Row-Key 标识,将相关的单元格组织成行返回,这样便有了逻辑上的行数据。讲解到这,我们就大致了解 HBase 中的数据排布格式,以及与 RDBMS 的一些区别。

对于 RDBMS 来说,一般都是以 SQL 作为为主要的访问方式。而 HBase 是一种"NoSQL"数据库。"NoSQL"是一个通用词表示该数据库并不是 RDBMS 。现在的市面上有许多种 NoSQL 数据库,如 BerkeleyDB 是本地 NoSQL 数据库的例子, HBase 则为大型分布式 NoSql 数据库。从技术上来说,Hbase 更像是"数据存储"而非"数据库"(HBase 和 HDFS 都属于大数据的存储层)。因此,HBase 缺少很多 RDBMS 特性,如列类型,二级索引,触发器和高级查询语言等。然而, HBase 也具有许多其他特征同时支持线性化和模块化扩充。最明显的方式,我们可以通过增加 Region Server 的数量扩展 HBase。并且 HBase 可以放在普通的服务器中,例如将集群从 5 个扩充到 10 个 Region Server 时,存储空间和处理容量都可以同时翻倍。当然 RDBMS 也能很好的扩充,但仅对一个点,尤其是对一个单独数据库服务器而言,为了更好的性能,往往需要特殊的硬件和存储设备(往往价格也非常昂贵)。

您可能感兴趣的与本文相关的镜像

ACE-Step

ACE-Step

音乐合成
ACE-Step

ACE-Step是由中国团队阶跃星辰(StepFun)与ACE Studio联手打造的开源音乐生成模型。 它拥有3.5B参数量,支持快速高质量生成、强可控性和易于拓展的特点。 最厉害的是,它可以生成多种语言的歌曲,包括但不限于中文、英文、日文等19种语言

<think>HBaseHive传统数据库在存储方式上的核心差异主要体现在数据模型、存储结构访问模式三个方面。以下是根据引用资料Hadoop生态系统特性的分析: ### 一、HBase的存储特性(NoSQL列式存储) 1. **数据模型**: - **稀疏多维映射表**:数据按`行键+列族+列限定符+时间戳`四维定位,单元格存储字节数组(无数据类型约束)[^4][^5] - **动态列**:列限定符无需预定义,支持运行时动态添加(如订单表新增`折扣券`列) - **多版本**:同一单元格可存储多个时间戳版本的值(默认保留最新版本) 2. **物理存储**: - **列族存储**:同一列族的数据物理上集中存储(HFile格式),不同列族存储分离 - **HDFS依赖**:数据持久化在HDFS上,通过RegionServer分片管理[^4] - **LSM树结构**:写操作先写入MemStore内存,再异步刷写到磁盘,实现高吞吐写入[^5] 3. **示例场景**: ```plaintext RowKey: user123_profile Column Family: basic_info qualifier: name -> "张三" (ts=1690000000000) qualifier: age -> "28" (ts=1690000001000) Column Family: contact qualifier: phone -> "138****5678" (ts=1690000002000) ``` ### 二、Hive的存储特性(类SQL数据仓库) 1. **数据模型**: - **结构化表**:需预定义表结构(字段名、数据类型),类似RDBMS[^3] - **分区/分桶**:支持按字段值分区(如`dt='2023-09-15'`),或哈希分桶优化查询 2. **物理存储**: - **文件抽象层**:表数据实际存储在HDFS文件中(文本/ORC/Parquet等格式)[^3] - **元数据管理**:表结构信息存储在独立数据库(如MySQL)中,数据分离 - **计算分离**:存储(HDFS)计算(MapReduce/Tez/Spark)解耦 3. **示例场景**: ```sql CREATE TABLE orders ( order_id STRING, user_id STRING, amount DOUBLE ) PARTITIONED BY (dt STRING) STORED AS ORC; -- 数据实际存储在HDFS路径:/user/hive/warehouse/orders/dt=20230915/000000_0 ``` ### 三、传统关系型数据库(RDBMS)存储特性 1. **数据模型**: - **严格范式**:需预先定义表结构,字段有严格数据类型约束 - **行式存储**:数据按行连续存储(如一条订单记录的所有字段相邻存储) 2. **物理存储**: - **本地文件系统**:数据通常存储在本地磁盘(如MySQL的InnoDB使用.ibd文件) - **B+树索引**:通过B+树维护数据有序性,优化点查询效率 - **ACID事务**:依赖redo/undo日志保证强一致性 ### 对比总结表 | 特性 | HBase | Hive | 传统RDBMS | |---------------------|-----------------------|--------------------------|-----------------------| | **存储模型** | 列式存储(稀疏) | 文件存储(结构化的) | 行式存储 | | **数据结构约束** | 无模式(动态列) | 需预定义模式(静态) | 严格模式(预定义) | | **存储介质** | HDFS | HDFS | 本地磁盘 | | **写入特性** | 高吞吐随机写 | 批量追加 | 事务性读写 | | **查询延迟** | 毫秒级随机读 | 分钟级批处理 | 毫秒~秒级 | | **扩展性** | 线性扩展(RegionServer)| 计算层扩展(无共享架构) | 垂直扩展或集群分片 | ### 关键差异解析 1. **存储灵活性**: - HBase支持动态列稀疏存储,适合半结构化数据(如JSON日志)[^4] - Hive需固定表结构,适合结构化数据分析(如数据仓库)[^3] - RDBMS结构刚性最强,修改表结构成本高 2. **访问模式**: - HBase擅长随机读写(单行查询毫秒级响应)[^4] - Hive仅支持全表扫描式批处理(即使WHERE条件也需读整个分区)[^3][^4] - RDBMS通过索引支持灵活查询,但大数据量时性能下降 3. **扩展机制**: - HBase/Hive通过增加节点线性扩展(HDFS提供底层支持)[^5] - RDBMS扩展依赖分库分表或读写分离,复杂度高 --- §§相关问题§§ 1. HBase的LSM树存储结构如何实现高吞吐写入? 2. Hive的ORC/Parquet列式存储文件传统行存储文件有何性能差异? 3. 为什么HBase不适合复杂关联查询?如何通过Phoenix弥补这一缺陷?[^4] </think>以下是HBaseHive传统数据库(如MySQL/Oracle)在存储方式上的核心区别分析,结合引用资料的关键特性进行对比: --- ### 一、存储模型本质区别 | **特性** | **HBase** | **Hive** | **传统数据库** | |------------------|-------------------------|-------------------------|---------------------| | **数据模型** | 稀疏多维映射表(NoSQL) | 结构化表(类SQL) | 严格结构化表 | | **存储目标** | 实时随机读写 | 离线批处理分析 | 事务性OLTP操作 | | **扩展方式** | 线性水平扩展[^5] | 计算层扩展 | 垂直扩展/分库分表 | | **数据类型** | 字节数组(无类型)[^5] | 支持基本数据类型 | 强类型约束 | > **关键差异**:HBase是分布式键值存储,Hive是数据仓库抽象层,传统数据库是严格的关系模型[^3][^5] --- ### 二、物理存储结构对比 #### 1. **HBase的存储机制** - **底层依赖**:数据存储在HDFS上,通过RegionServer分片管理 - **存储单元**: - 按`行键+列族+列限定符+时间戳`定位单元格[^4] - 列族数据物理集中存储(如`order_info`列族单独存储) - **存储格式**: - 使用LSM树(Log-Structured Merge Tree) - 数据先写入内存MemStore,异步刷写到HFile - **示例**: ```plaintext RegionServer1: RowKey="u1001_20230915" → {CF:order_info, product_id:"P001", ts:1694772600} RowKey="u1002_20230915" → {CF:payment_info, status:"PAID", ts:1694772700} ``` #### 2. **Hive的存储机制** - **底层依赖**:数据以文件形式存储在HDFS(文本/ORC/Parquet等)[^3] - **存储抽象**: - 表=HDFS目录,分区=子目录(如`/user/hive/orders/dt=20230915`) - 元数据存储在独立数据库(MySQL等) - **读写特性**: - 写操作:批量加载(`LOAD DATA`或`INSERT OVERWRITE`) - 读操作:全表扫描(即使条件查询也需读整个文件)[^4] #### 3. **传统数据库存储** - **本地存储**:数据文件在服务器本地磁盘(如InnoDB的.ibd文件) - **存储结构**: - 数据按行连续存储(页结构) - B+树索引加速查询 - **事务保障**:Redo/Undo日志实现ACID --- ### 三、访问模式差异 | **场景** | **HBase** | **Hive** | **传统数据库** | |------------------|-----------------------|------------------------|-------------------| | **点查询** | 毫秒级响应(行键检索)| 分钟级(全扫描)[^4] | 毫秒级(索引) | | **复杂分析** | 不支持(需集成Phoenix)| 分钟~小时级[^1] | 秒~分钟级 | | **实时更新** | 支持(Put操作) | 仅批量覆盖[^3] | 支持(Update) | | **事务支持** | 单行事务 | 无 | 完整ACID | > **典型用例**: > - HBase:Facebook消息实时存储[^4] > - Hive:电商日志离线分析[^1] > - MySQL:银行交易系统 --- ### 四、架构依赖对比 | **组件** | **HBase** | **Hive** | **传统数据库** | |------------------|------------------|------------------|---------------| | **存储层** | HDFS | HDFS | 本地磁盘 | | **协调服务** | Zookeeper[^4] | 元数据库 | 无 | | **计算引擎** | RegionServer | MapReduce/Spark | 内置引擎 | | **查询接口** | Java API/Phoenix | HiveQL(SQL-like) | SQL | --- ### 关键结论 1. **存储灵活性** HBase允许动态列稀疏存储(空列不占空间)[^5],传统数据库需预定义严格模式 2. **扩展成本** HBase/Hive通过普通服务器水平扩展,传统数据库依赖高端硬件垂直扩展[^5] 3. **实时性权衡** HBase牺牲复杂查询能力换取高吞吐写入,Hive牺牲实时性换取分析能力[^1][^4] ---
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

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

余额充值