HBase与Presto整合：交互式查询解决方案

HBase与Presto整合：交互式查询解决方案——从仓库到智能分拣的大数据进化

一、引入与连接：当“仓库”遇到“智能分拣”

凌晨3点，电商公司的数据分析师小张盯着电脑屏幕皱起了眉头。他需要从HBase中查询过去30天内用户点击流数据的Top10商品，用于明天的运营会议。但当他输入scan 'user_clickstream', {FILTER => "PrefixFilter('2023-10-01')"}时，HBase的Shell返回结果的速度比蜗牛还慢——10亿条数据的全表扫描，让他的咖啡凉了三杯还没出结果。

“如果HBase是个巨大的仓库，里面堆满了按列族分类的货物（数据），那我现在就是在仓库里用手电筒找东西——得沿着货架（Region）一个个逛，效率太低了！”小张自言自语道。

这正是很多大数据从业者的共同痛点：HBase擅长海量结构化数据的随机读写，但交互式查询（如SQL分析、多条件过滤、聚合统计）不是它的强项。而此时，Presto这个“智能分拣系统”的出现，恰好解决了这个问题。

为什么需要HBase与Presto整合？

HBase的“长板”：分布式、高可用、列族存储、支持百万级QPS的随机读写（比如用户订单、传感器数据的实时写入）。HBase的“短板”：查询能力弱——仅支持行键（RowKey）的精确查询或前缀扫描，不支持复杂的SQL（如GROUP BY、JOIN），全表扫描延迟高。Presto的“补位”：分布式SQL查询引擎，擅长交互式分析（延迟秒级到分钟级），支持跨数据源查询（HBase、Hive、MySQL等），通过内存计算和并行处理提升效率。

当HBase的“存储能力”与Presto的“查询能力”结合，就像给仓库装上了智能分拣系统——既能高效存储海量货物，又能快速按需求找出货物。

二、概念地图：构建整合的“认知框架”

在深入整合细节前，我们需要先理清HBase与Presto的核心概念及它们的关系。请想象一张“知识地图”，其中：

1. HBase的核心组件（存储层）

表（Table）：数据的逻辑容器，类似关系数据库的表，但按**列族（Column Family）**组织。列族（Column Family）：一组相关列的集合（如info列族包含user_id、order_date等列），物理上存储为独立的文件（HFile）。行键（RowKey）：数据的唯一标识，类似主键，决定了数据在HBase中的存储位置（通过哈希分配到不同的Region）。Region：HBase的基本存储单元，每个Region负责存储一段连续的RowKey数据（类似仓库的“货架”）。Zookeeper：协调HBase集群，维护Region的位置信息（类似仓库的“导航系统”）。

2. Presto的核心组件（查询层）

Coordinator（协调器）：接收用户的SQL查询，解析并生成查询计划（类似分拣系统的“调度中心”）。Worker（工作节点）：执行查询计划的具体任务（如扫描HBase数据、计算聚合结果），类似分拣系统的“分拣员”。Connector（连接器）：连接Presto与外部数据源（如HBase、Hive）的“桥梁”，负责元数据映射和数据访问。

3. 整合的核心逻辑（连接层）

Presto通过HBase Connector实现与HBase的整合，核心流程如下：

元数据映射：将HBase的表、列族、列映射为Presto的表、列（比如HBase的user_orders表→Presto的presto_hbase.user_orders表）。数据扫描：Presto的Worker节点通过Zookeeper获取HBase Region的位置，向RegionServer发送扫描请求（Scanner），获取数据。类型转换：将HBase的字节数据（Byte[]）转换为Presto支持的SQL类型（如INT、DATE、DOUBLE）。结果处理：Worker节点对数据进行过滤、聚合、排序等操作，最终将结果返回给Coordinator，再由Coordinator返回给用户。

可视化图谱：


用户 → SQL查询 → Presto Coordinator（生成查询计划） → Presto Worker（通过HBase Connector） → Zookeeper（获取Region位置） → HBase RegionServer（扫描数据） → 数据返回 → Worker处理 → 结果返回用户

三、基础理解：用“仓库分拣”类比整合逻辑

为了让10岁的孩子也能理解HBase与Presto的整合，我们用“仓库分拣”做类比：

1. HBase=“智能仓库”

货架（Region）：仓库里的货架，每个货架放着连续编号的货物（比如RowKey从2023-10-01-0001到2023-10-01-1000的货物）。货物（数据）：每个货物有一个唯一的编号（RowKey），并按类别放在不同的货架层（列族，比如info层放用户信息，order层放订单信息）。导航系统（Zookeeper）：仓库的导航屏幕，显示每个货架的位置（比如“货架A在东区，放着RowKey开头为2023-10的货物”）。

2. Presto=“智能分拣系统”

调度中心（Coordinator）：分拣系统的大脑，接收用户的需求（比如“找出过去30天内销量Top10的商品”），并制定分拣计划（比如“让分拣员A去货架A取2023-10-01到2023-10-31的货物，分拣员B去货架B取同样时间范围的货物”）。分拣员（Worker）：根据调度中心的计划，去对应的货架（Region）取货物（扫描HBase数据），并按要求分拣（过滤、聚合）。桥梁（Connector）：分拣员与仓库之间的沟通工具，告诉分拣员“货架A的货物对应的是Presto的user_orders表，info层的product_id列是商品ID”。

3. 整合后的效果：快速找货

比如用户需要“找出2023年10月的Top10商品”，流程如下：

用户向分拣系统（Presto）发出需求（SQL查询）。调度中心（Coordinator）解析需求，制定计划：“需要从仓库（HBase）的user_orders表中，取order_date在2023-10-01到2023-10-31之间的product_id，并统计每个product_id的销量（COUNT(*)），排序取前10。”分拣员（Worker）通过桥梁（Connector）查看导航系统（Zookeeper），找到存放2023-10月数据的货架（Region）。分拣员去对应的货架（RegionServer）取货物（扫描数据），只取需要的product_id和order_date列（列投影），避免拿多余的东西（提升效率）。分拣员将取到的货物（数据）进行统计（聚合），并排序，最后把结果交给调度中心，再返回给用户。

关键结论：HBase负责“存”，Presto负责“查”，整合后实现了“海量数据的快速交互式查询”。

四、层层深入：从“怎么用”到“为什么好用”

接下来，我们从基础原理→细节优化→底层逻辑→高级应用，逐步深入整合的核心。

1. 第一层：基本原理——Presto的HBase Connector如何工作？

Presto的HBase Connector是整合的核心，它的工作流程可以分为三步：元数据映射、数据扫描、类型转换。

（1）元数据映射：把HBase表“翻译”成Presto表

HBase是“无 schema”的（列族是预定义的，但列可以动态添加），而Presto是“有 schema”的（需要明确表的结构）。因此，Connector需要将HBase的表结构“翻译”成Presto的表结构。

实现方式：通过表描述文件（JSON格式）或SQL语句定义映射关系。例如，我们有一个HBase表user_orders，结构如下：

RowKey：user_id_order_id（如123_456）列族：info（包含order_date（日期）、product_id（整数）、quantity（整数））

我们可以用SQL语句在Presto中创建对应的表：


CREATE TABLE presto_hbase.user_orders (
    row_key VARCHAR, -- 对应HBase的RowKey
    user_id INT,     -- 从RowKey中解析（比如取`_`前面的部分）
    order_id INT,    -- 从RowKey中解析（比如取`_`后面的部分）
    order_date DATE, -- 对应`info:order_date`列
    product_id INT,  -- 对应`info:product_id`列
    quantity INT     -- 对应`info:quantity`列
) WITH (
    connector = 'hbase',                  -- 指定连接器为HBase
    table_name = 'user_orders',            -- HBase中的表名
    zookeeper_quorum = 'zk1:2181,zk2:2181',-- Zookeeper地址
    row_key = 'row_key',                   -- Presto表中对应RowKey的列名
    -- 列映射：Presto列 → HBase列族:列 → 数据类型
    columns = '{
        "user_id": {"cf": "rowkey", "col": "user_id", "type": "int", "extractor": "split_part(row_key, '_', 1)"},
        "order_id": {"cf": "rowkey", "col": "order_id", "type": "int", "extractor": "split_part(row_key, '_', 2)"},
        "order_date": {"cf": "info", "col": "order_date", "type": "date"},
        "product_id": {"cf": "info", "col": "product_id", "type": "int"},
        "quantity": {"cf": "info", "col": "quantity", "type": "int"}
    }'
);

关键说明：

row_key：Presto表中必须包含对应HBase RowKey的列。columns：定义Presto列与HBase列的映射关系，支持从RowKey中解析列（比如user_id和order_id），这解决了HBase RowKey复合键的查询问题。extractor：提取器，用于从RowKey中解析出列值（比如split_part函数分割RowKey）。

（2）数据扫描：如何高效获取HBase数据？

Presto的Worker节点通过HBase Scanner获取数据，核心优化点是避免全表扫描。

扫描方式：

行键范围扫描：如果查询条件包含RowKey的范围（比如row_key BETWEEN '123_456' AND '123_789'），Presto会向HBase发送范围扫描请求（Scanner.setStartRow和Scanner.setStopRow），只扫描指定范围的Region，提升效率。列投影：如果查询只需要部分列（比如SELECT product_id, quantity FROM user_orders），Presto会在扫描请求中指定需要的列族和列（Scanner.addColumn），HBase只返回这些列的数据，减少数据传输量。过滤条件下推：如果查询有过滤条件（比如order_date > '2023-10-01'），Presto会将过滤条件下推到HBase（通过Filter接口），让HBase在扫描时就过滤掉不符合条件的数据，减少返回给Presto的数据量。

例子：查询2023年10月的订单数据：


SELECT product_id, SUM(quantity) AS total_quantity 
FROM presto_hbase.user_orders 
WHERE order_date BETWEEN '2023-10-01' AND '2023-10-31' 
GROUP BY product_id 
ORDER BY total_quantity DESC 
LIMIT 10;

过滤下推：order_date的条件会被转换成HBase的SingleColumnValueFilter，HBase在扫描时就过滤掉非10月的订单。列投影：只返回product_id和quantity列，减少数据传输。范围扫描：如果order_date是RowKey的一部分（比如RowKey是order_date_user_id），Presto会直接扫描10月对应的RowKey范围，效率更高。

（3）类型转换：从字节到SQL类型的“翻译”

HBase中的数据以字节数组（Byte[]）存储，而Presto需要SQL类型（如INT、DATE、DOUBLE）。Connector通过类型映射规则完成转换：

整数类型（INT、BIGINT）：将字节数组转换为对应的整数（比如info:product_id的字节数组[0x00, 0x00, 0x01, 0x23]→INT类型的307）。日期类型（DATE）：将字节数组转换为yyyy-MM-dd格式的字符串，再解析为DATE类型（比如info:order_date的字节数组[0x32, 0x30, 0x32, 0x33, 0x2D, 0x31, 0x30, 0x30, 0x31]→2023-10-01）。字符串类型（VARCHAR）：直接将字节数组转换为字符串。

注意：类型转换需要一致性，如果HBase中的数据类型与Presto表定义的类型不一致（比如HBase中是字符串，Presto中定义为INT），会导致查询错误。

2. 第二层：细节优化——如何让查询更快？

整合的核心目标是提升交互式查询效率，以下是几个关键细节优化：

（1）RowKey设计：查询效率的“基石”

RowKey是HBase查询的“入口”，好的RowKey设计能让Presto的扫描更高效。最佳实践：

将查询条件中的高频字段放在RowKey前面（比如order_date_user_id），这样查询时可以用前缀扫描（PrefixFilter），减少扫描的Region数量。避免热点问题（比如用时间戳作为RowKey的前缀，会导致新数据都写入同一个Region），可以用哈希加盐（比如hash(user_id)_order_date），将数据分散到不同的Region。复合RowKey的解析：如果RowKey是复合的（比如user_id_order_id），可以在Presto表中用extractor函数解析（如前面的例子），这样可以直接查询user_id或order_id，而不需要全表扫描。

反例：如果RowKey是user_id，而查询条件是order_date > '2023-10-01'，Presto无法利用RowKey的范围扫描，只能全表扫描，效率极低。

（2）列族与列的选择：减少数据传输

列族的设计：将经常一起查询的列放在同一个列族（比如info列族包含order_date、product_id、quantity），这样HBase可以一次性返回这些列的数据，减少I/O次数。避免使用过多列族：HBase的列族数量建议不超过3个，因为每个列族都有独立的HFile，过多列族会增加磁盘I/O和内存占用。列投影：查询时只选需要的列（比如SELECT product_id, quantity FROM user_orders），而不是SELECT *，这样HBase只返回这些列的数据，减少数据传输量。

（3）Presto的并行度调整：让“分拣员”更高效

Presto的查询效率取决于Worker节点的数量和每个Worker的任务数量。优化参数：

hbase.split-size：每个HBase Region的split大小（默认128MB），如果Region过大，可以调小这个参数，让每个Worker处理更小的任务，提升并行度。hive.max-split-size：Presto处理每个split的大小（默认128MB），与hbase.split-size配合使用，确保每个Worker的任务量适中。task.concurrency：每个Worker节点的并发任务数量（默认4），可以根据Worker的CPU核心数调整（比如8核心的Worker可以设为8）。

例子：如果HBase有100个Region，每个Region的大小是128MB，那么Presto会生成100个split，每个Worker处理4个split（如果task.concurrency设为4），这样100个split需要25个Worker节点（100/4=25）才能并行处理完。

3. 第三层：底层逻辑——Presto的查询计划如何生成？

Presto的查询效率高，除了HBase的优化，还因为它的分布式查询计划和内存计算。

（1）查询计划的生成流程

当用户输入SQL查询后，Presto的Coordinator会经历以下步骤：

解析（Parse）：将SQL字符串转换为抽象语法树（AST）。分析（Analyze）：验证AST的合法性（比如表是否存在、列是否存在），并绑定元数据（从HBase Connector获取表结构）。优化（Optimize）：对查询计划进行优化（比如谓词下推、列投影、join重排序）。生成（Generate）：将优化后的查询计划转换为物理计划（比如ScanOperator、FilterOperator、AggregationOperator），并分配给Worker节点执行。

（2）物理计划的执行：并行与内存计算

Presto的物理计划是流水线式的，每个Worker节点执行一个或多个Operator（运算符），数据在运算符之间流式传输（不需要写入磁盘），提升效率。

例子：查询SELECT product_id, SUM(quantity) FROM user_orders WHERE order_date > '2023-10-01' GROUP BY product_id的物理计划：

ScanOperator：从HBase扫描数据（应用列投影和过滤条件）。FilterOperator：过滤掉order_date <= '2023-10-01'的数据（如果过滤条件没有下推到HBase）。AggregationOperator：对product_id进行分组，计算SUM(quantity)（使用内存中的哈希表存储中间结果）。ExchangeOperator：将各个Worker节点的聚合结果汇总到Coordinator节点，进行最终的排序和 LIMIT 操作。

关键优势：内存计算（不需要写入磁盘）和流水线执行（数据流式传输），让Presto的查询延迟比Hive（基于MapReduce，需要写入磁盘）低得多。

4. 第四层：高级应用——跨数据源联合查询

Presto的一大优势是支持跨数据源查询，比如HBase与Hive、MySQL的联合查询。这让我们可以将HBase的实时数据与Hive的离线数据结合，进行更复杂的分析。

例子：查询“2023年10月购买过商品A的用户的离线行为数据”（HBase存储实时订单数据，Hive存储离线用户行为数据）：


SELECT 
    hb.user_id, 
    hv.action_type, 
    COUNT(*) AS action_count 
FROM 
    presto_hbase.user_orders hb 
JOIN 
    hive.ods.user_behavior hv 
ON 
    hb.user_id = hv.user_id 
WHERE 
    hb.product_id = 'A' 
    AND hb.order_date BETWEEN '2023-10-01' AND '2023-10-31' 
GROUP BY 
    hb.user_id, hv.action_type 
ORDER BY 
    action_count DESC 
LIMIT 10;

执行流程：

Presto的Coordinator解析查询，生成联合查询计划。Worker节点分别从HBase（user_orders表）和Hive（user_behavior表）扫描数据。Worker节点对两边的数据进行JOIN（基于user_id），并计算聚合结果。Coordinator节点汇总结果，返回给用户。

优势：不需要将数据从HBase导入到Hive（或反之），直接跨数据源查询，节省了数据同步的时间和资源。

五、多维透视：从不同角度看整合的“全貌”

1. 历史视角：从“Hive on HBase”到“Presto on HBase”

在Presto出现之前，人们常用Hive on HBase来实现HBase的SQL查询。但Hive基于MapReduce，查询延迟很高（分钟级到小时级），无法满足交互式分析的需求。

Presto的出现改变了这一局面：

延迟：Presto的查询延迟是秒级到分钟级，比Hive快10-100倍。并发：Presto支持高并发（ thousands of queries per second），而Hive的并发能力较弱。SQL支持：Presto支持更丰富的SQL特性（如JOIN、窗口函数、聚合函数），而Hive on HBase的SQL支持有限。

结论：Presto on HBase是Hive on HBase的“进化版”，更适合交互式分析场景。

2. 实践视角：整合的“真实场景”

（1）电商：用户行为分析

某电商公司用HBase存储用户的实时点击流数据（RowKey为user_id_timestamp，列族info包含product_id、action_type（点击/购买）等列）。用Presto查询：

实时查询“过去1小时内点击量Top10的商品”。分析“用户从点击到购买的转化路径”（联合Hive的订单数据）。

效果：查询延迟从Hive的10分钟缩短到Presto的10秒，分析师能快速获取 insights，调整运营策略。

（2）物联网：传感器数据监控

某物联网公司用HBase存储传感器的实时数据（RowKey为device_id_timestamp，列族data包含temperature、humidity等列）。用Presto查询：

实时查询“过去24小时内温度超过30℃的设备列表”。分析“设备温度的变化趋势”（结合时间序列函数）。

效果：运维人员能快速发现异常设备，减少停机时间。

3. 批判视角：整合的“局限性”

虽然HBase与Presto的整合能解决很多问题，但也有局限性：

事务支持弱：HBase的事务是行级的（ACID），而Presto的查询是快照读（Snapshot Read），如果有并发的写操作，可能会读到不一致的数据（比如刚插入的行还没被Presto扫描到）。复杂查询性能低：多表关联（比如3个以上表的JOIN）或复杂的窗口函数（比如ROW_NUMBER()）的性能可能不高，因为需要跨数据源传输大量数据。元数据管理复杂：如果HBase的表结构发生变化（比如添加了新的列），需要手动更新Presto的表描述文件，否则查询会报错。

4. 未来视角：整合的“进化方向”

随着技术的发展，HBase与Presto的整合会越来越完善：

HBase 3.x的支持：HBase 3.x引入了**MOB（中等对象）**支持（存储10KB-10MB的对象，如图片、文档），Presto的Connector可以优化对MOB数据的查询（比如支持SELECT MOB列的内容）。二级索引的整合：HBase的二级索引工具（如Phoenix）可以提升非RowKey查询的效率，Presto的Connector可以整合Phoenix的二级索引（比如通过Phoenix的JDBC接口查询HBase）。AI优化的查询计划：Presto的新版本（如Presto 0.280+）引入了机器学习优化器（ML-based Optimizer），可以预测查询的资源需求（如内存、CPU），优化并行度和缓存策略，提升查询效率。

六、实践转化：从“知识”到“能力”

1. 具体操作步骤：配置Presto的HBase Connector

（1）环境准备

HBase集群（版本2.x或更高）。Presto集群（版本0.250或更高）。Zookeeper集群（用于协调HBase）。

（2）配置Connector

在Presto的etc/catalog目录下创建hbase.properties文件：


connector.name=hbase
hbase.zookeeper.quorum=zk1:2181,zk2:2181,zk3:2181
hbase.zookeeper.client.port=2181
hbase.table-description-dir=/etc/presto/hbase-table-descriptions

connector.name：指定连接器为HBase。hbase.zookeeper.quorum：Zookeeper的地址。hbase.table-description-dir：表描述文件的目录（用于存储HBase表与Presto表的映射关系）。

在hbase.table-description-dir目录下创建表描述文件（比如user_orders.json）：


{
  "tableName": "user_orders",
  "schemaName": "presto_hbase",
  "rowKey": "row_key",
  "columns": [
    {
      "name": "row_key",
      "type": "VARCHAR",
      "mappedColumnFamily": "rowkey",
      "mappedColumn": "row_key"
    },
    {
      "name": "user_id",
      "type": "INT",
      "mappedColumnFamily": "rowkey",
      "mappedColumn": "user_id",
      "extractor": "split_part(row_key, '_', 1)"
    },
    {
      "name": "order_id",
      "type": "INT",
      "mappedColumnFamily": "rowkey",
      "mappedColumn": "order_id",
      "extractor": "split_part(row_key, '_', 2)"
    },
    {
      "name": "order_date",
      "type": "DATE",
      "mappedColumnFamily": "info",
      "mappedColumn": "order_date"
    },
    {
      "name": "product_id",
      "type": "INT",
      "mappedColumnFamily": "info",
      "mappedColumn": "product_id"
    },
    {
      "name": "quantity",
      "type": "INT",
      "mappedColumnFamily": "info",
      "mappedColumn": "quantity"
    }
  ]
}

重启Presto集群，让配置生效。

（3）验证查询

用Presto的CLI工具连接集群，执行查询：


presto-cli --server presto-coordinator:8080 --catalog hbase --schema presto_hbase


SELECT product_id, SUM(quantity) AS total_quantity FROM user_orders WHERE order_date BETWEEN '2023-10-01' AND '2023-10-31' GROUP BY product_id ORDER BY total_quantity DESC LIMIT 10;

如果返回结果正确，说明整合成功。

2. 优化技巧：让查询更快

使用行键范围扫描：尽量将查询条件转换为RowKey的范围（比如row_key BETWEEN '2023-10-01' AND '2023-10-31'）。列投影：只查询需要的列（比如SELECT product_id, quantity FROM user_orders）。过滤条件下推：确保查询条件中的过滤字段是HBase的列（比如order_date），并且在Presto表中正确映射，这样过滤条件会被下推到HBase。调整并行度：根据HBase的Region数量和Presto的Worker数量，调整hbase.split-size和task.concurrency参数。

3. 常见问题解决

问题1：查询返回“Column not found”
原因：Presto表中的列名与HBase表中的列名不一致。
解决：检查表描述文件中的columns配置，确保mappedColumn与HBase中的列名一致。

问题2：查询延迟很高
原因：全表扫描（没有使用RowKey范围扫描）或列投影（查询了过多列）。
解决：优化RowKey设计，使用行键范围扫描；减少查询的列数量。

问题3：数据类型转换错误
原因：Presto表中的列类型与HBase中的数据类型不一致。
解决：检查表描述文件中的type配置，确保与HBase中的数据类型一致（比如HBase中的order_date是字符串类型，Presto中定义为DATE类型，需要确保字符串的格式是yyyy-MM-dd）。

七、整合提升：从“碎片知识”到“体系化能力”

1. 核心观点回顾

HBase：适合存储海量结构化数据，擅长随机读写，但查询能力弱。Presto：适合交互式分析，擅长SQL查询和跨数据源联合查询，但不适合存储数据。整合价值：HBase提供“存储能力”，Presto提供“查询能力”，两者结合解决了“海量数据的快速交互式查询”问题。

2. 知识体系重构

我们可以用金字塔结构重构整合的知识体系：

基础层：HBase（表、列族、RowKey、Region）、Presto（Coordinator、Worker、Connector）的核心概念。连接层：Presto的HBase Connector的工作流程（元数据映射、数据扫描、类型转换）。深度层：查询计划生成（解析、分析、优化、生成）、并行处理（split、Operator）。整合层：跨数据源联合查询、性能优化（RowKey设计、列投影、并行度调整）。

3. 思考问题与拓展任务

思考问题：

如果HBase的RowKey是user_id，而查询条件是order_date > '2023-10-01'，如何优化查询效率？（提示：使用二级索引或RowKey设计优化）Presto的HBase Connector如何处理HBase的版本数据（比如同一个RowKey的多个版本）？（提示：查看Presto的hbase.max-versions配置）

拓展任务：

尝试用Presto查询HBase中的复合RowKey数据（比如user_id_order_id），并解析出user_id和order_id。做一个HBase与MySQL的联合查询（比如HBase存储订单数据，MySQL存储用户信息，查询“过去30天内购买过商品的用户的详细信息”）。优化一个慢查询（比如全表扫描的查询），记录优化前后的延迟对比。

4. 学习资源与进阶路径

官方文档：
Presto HBase Connector文档：https://prestodb.io/docs/current/connector/hbase.htmlHBase官方文档：https://hbase.apache.org/book.html 书籍：
《HBase权威指南》（第2版）：深入讲解HBase的核心概念和实践。《Presto实战》：讲解Presto的架构、优化和实战案例。社区：
Presto社区：https://prestodb.io/community.htmlHBase社区：https://hbase.apache.org/community.html