深入浅出HBase实战（一） | 青训营笔记

李哥技术笔记
117 阅读5分钟

这是我参与「第四届青训营 」笔记创作活动的第4天

HBase是基于HDFS实现的存储计算分离架构的分布式表格存储服务

1 HBase适用场景

1.1 什么是HBase

HBase是一个开源的的NoSQL分布式数据库，参考Google BigTable的设计，对稀疏表提供更高的存储空间使用效率和读写效率。

采用存储计算分离架构：

  • 存储层基于HDFS存储数据，提供容错机制和高可靠性
  • 计算层提供灵活快速的水平扩展、负载均衡和故障恢复能力

1.2 HBase与关系型数据库的区别

标题HBase关系型数据库
数据结构半结构化，无数据类型，按列族稀疏存储，缺省数据不占空间；支持多版本数据结构化数据，数据有类型，按行存储，缺省数据要占空间，不支持多版本
读写模式支持按需读写部分列必须整行读取
事务支持仅支持单行内原子性支持完整的事务语义
数据规模TB、PB海量数据；水平扩展快速平滑小量TB、GB数据；扩展复杂
索引支持仅支持rowkey主键索引支持二级索引

1.3 HBase数据模型

1.3.1 逻辑结构

HBase以列族(column family)为存储单位存储数据，以行键(rowkey)索引数据。

  • 列族(column family)需要在使用前预先创建，列名(column qualifier)不要预先声明。
  • 支持保留多个版本的数据(Key: 行键+列族+列名+版本号 Value: 具体值)

image.png

[{
    "rowkey 1": {    //定位一行数据
        "column family 1": {    //列族需要预先定义
            "column qualifier a": {
                "version 1": "name 1"
            },
            "column qualifier b": {
                // rowkey1 + column family1 + column qualifierb + version3 = cell的一个版本
                "version 3": "email 3",
                "version 2": "email 2",
                "version 1": "email 1"
            }
        }, 
        "column family 2": {
            "column qualifier c": {
                "version 1": "address 1"
            }
        }
    },
    "rowkey 2": {
        // 缺省的column family1 不占存储空间
        "column family 2": {
            "column qualifier c": {
                "version 1": "address 2"
            }
            "column qualifier d": {
                "version 1": "id 1"
            }
        }
    }
}]

1.3.2 物理结构

物理数据结构最小的单位是 KeyValue 结构：

  • 每个版本的数据都携带全部的行列信息
  • 同一行，同一列族的数据物理上连续有序存储
  • 同列族内的KeyValue按rowkey升序，按column qualifier升序，按version降序排列
  • 不同列族的数据存储在相互独立的物理文件，列族间不保证数据全局有序
  • 同列族下不同的物理文件间不保证数据全局有序
  • 仅单个物理文件内有序

image.png

image.png

1.4 使用场景

适用场景：

  • “近在线”的海量分布式KV / 宽表存储，数据量级可达到PB级以上
  • 写密集型、高吞吐应用，可接受一定程度的延时抖动
  • 字典序主键索引、批量顺序扫描多行数据的场景
  • Hadoop大数据生态友好兼容
  • 半结构化数据模型，行列稀疏的数据分布，动态增减列名
  • 敏捷平滑的水平扩展能力，快速响应数据体量、流量变化

典型应用

  • 电商订单数据：查询最新/待处理订单进度
  • 搜索推荐引擎：存储原始数据、排序推荐结果
  • 广告数据流：触达、点击、转化等事件流
  • 用户交互数据：IM/Email/点赞/搜索
  • 时序数据引擎：日志/监控
  • 图存储引擎
  • 大数据生态

1.5 HBase数据模型的优缺点

优势缺点
稀疏表友好，不存储缺省列，支持动态新增列类型每条数据都要冗余存储行列信息
支持保存多版本数据不支持二级索引，只能通过rowkey索引，查询效率依赖rowkey设计
支持只读部分column family的数据，避免读取不必要的数据column family数量较多时可能引发性能衰退
支持的数据规模比传统关系型数据库更高，更易扩展不支持数据类型，一律按字节数组存储
支持rowkey字典序批量扫描数据仅支持单行内的原子性操作，无跨行事务保障

2 Hbase架构设计

2.1 架构设计

HBase架构主要包括：

主要组件：

  • HMaster: 元数据管理、集群调度、保活
  • RegionServer: 提供数据读写服务，每个实例负责若干个互补重叠的rowkey区间内的数据。
  • ThriftServer: 提供Thrift API读写代理

依赖组件：

  • ZooKeeper: 分布式一致性共识写作管理
  • HDFS: 分布式文件系统，HBase数据存储底座

image.png

2.2 HMaster

主要职责：

  • 管理RegionServer实例生命周期，保证服务可用性
  • 协调RegionServer数据故障恢复，保证数据正确性
  • 集中管理集群元数据，执行负载均衡等维护集群稳定性
  • 定期巡检元数据，调整数据分布，清理废弃数据等
  • 处理用户主动发起的元数据操作如建表、删表等

image.png

2.3 RegionServer

主要职责

  • 提供部分rowkey区间数据的读写服务
  • 向客户端提供rowkey位置信息
  • 认领HMaster发布的故障恢复任务，帮助加速数据恢复过程
  • 处理HMaster下达的元数据操作

2.4 ZooKeeper

主要职责：

  • HMaster登记信息，对active/backup分工达成共识
  • RegionServer登记信息，失联时HMaster保活处理
  • 登记meta表位置信息，供SDK查询读写位置信息
  • 供HMaster和RegionServer协作处理分布式任务

2.5 ThriftServer

主要职责：

  • 实现HBase定义的Thrift API作为代理层向用户提供RPC读写服务
  • 用户可根据IDL自行生成客户端实现
  • 独立于RegionServer水平扩展
avatar
文章
阅读
粉丝