Phoenix构建HBase二级索引案例实战

最新推荐文章于 2024-06-19 16:13:19 发布
最新推荐文章于 2024-06-19 16:13:19 发布
阅读量419 收藏 4
点赞数 1
分类专栏： Phoenix HBase 文章标签： 大数据
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/weixin_43230682/article/details/108280627
版权

目录

一、为什么要使用二级索引？

二、全局索引和本地索引

三、可变索引和不可变索引

四、配置HBase支持Phoenix二级索引

五、实战

5.1 在phoenix中创建表

5.2 导入测试数据

5.3 Global Indexing的二级索引测试

5.4 Local Indexing的二级索引测试

5.5 如何确保query查询使用Index

5.6 索引重建

5.7 删除索引

六、索引性能调优

一、为什么要使用二级索引？

对于HBase而言，如果想精确地定位到某行记录，唯一的办法是通过rowkey来查询。如果不通过rowkey来查找数据，就必须逐行地比较每一列的值，即全表扫瞄。

对于较大的表，全表扫描的代价是不可接受的。但是，很多情况下，需要从多个角度查询数据。

  • 例如，在定位某个人的时候，可以通过姓名、身份证号、学籍号等不同的角度来查询

  • 要想把这么多角度的数据都放到rowkey中几乎不可能（业务的灵活性不允许，对rowkey长度的要求也不允许）。

  • 所以需要secondary index（二级索引）来完成这件事。secondary index的原理很简单，但是如果自己维护的话则会麻烦一些。

  • 现在，Phoenix已经提供了对HBase secondary index的支持。

二、全局索引和本地索引

2.1 Global Indexing

  • Global indexing，全局索引，适用于==读多写少==的业务场景。

  • 使用Global indexing在写数据的时候开销很大，因为所有对数据表的更新操作（DELETE, UPSERT VALUES and UPSERT SELECT），都会引起索引表的更新，而索引表是分布在不同的数据节点上的，跨节点的数据传输带来了较大的性能消耗。

  • 在读数据的时候Phoenix会选择索引表来降低查询消耗的时间。

  • 在默认情况下如果想查询的字段不是索引字段的话索引表不会被使用，也就是说不会带来查询速度的提升。

2.2 Local Indexing

  • Local indexing，本地索引，适用于==写操作频繁==以及空间受限制的场景。

  • 与Global indexing一样，Phoenix会自动判定在进行查询的时候是否使用索引。

  • 使用Local indexing时，索引数据和数据表的数据存放在相同的服务器中，这样避免了在写操作的时候往不同服务器的索引表中写索引带来的额外开销。

  • 使用Local indexing的时候即使查询的字段不是索引字段索引表也会被使用，这会带来查询速度的提升，这点跟Global indexing不同。对于Local Indexing，一个数据表的所有索引数据都存储在一个单一的独立的可共享的表中。

三、可变索引和不可变索引

3.1 immutable index

  • immutable index，不可变索引，适用于数据==只增加不更新并且按照时间先后顺序存储==（time-series data）的场景，如保存日志数据或者事件数据等。

  • 不可变索引的存储方式是write one，append only。

  • 当在Phoenix使用create table语句时指定IMMUTABLE_ROWS = true表示该表上创建的索引将被设置为不可变索引。

  • 不可变索引分为Global immutable index和Local immutable index两种。

  • Phoenix默认情况下如果在create table时不指定IMMUTABLE_ROW = true时，表示该表为mutable。

3.2 mutable index

  • mutable index，可变索引，适用于数据有==增删改==的场景。

  • Phoenix默认情况创建的索引都是可变索引，除非在create table的时候显式地指定IMMUTABLE_ROWS = true。

  • 可变索引同样分为Global mutable index和Local mutable index两种。

四、配置HBase支持Phoenix二级索引

4.1 修改配置文件

  • 如果要启用phoenix的二级索引功能，需要修改配置文件hbase-site.xml

  • 注意：

  • vim hbase-site.xml

<!-- 添加配置 -->
<property>
    <name>hbase.regionserver.wal.codec</name>
    <value>org.apache.hadoop.hbase.regionserver.wal.IndexedWALEditCodec</value>
</property>
<property>
   <name>hbase.region.server.rpc.scheduler.factory.class</name>
   <value>org.apache.hadoop.hbase.ipc.PhoenixRpcSchedulerFactory</value>
</property>
<property>
        <name>hbase.rpc.controllerfactory.class</name>
        <value>org.apache.hadoop.hbase.ipc.controller.ServerRpcControllerFactory</value>
</property>

4.2 重启hbase

  • 完成上述修改后重启hbase集群使配置生效。

五、实战

5.1 在phoenix中创建表

  • 首先，在phoenix中创建一个user table

  • node02执行以下命令，进入phoenix客户端，并创建表

cd /xsluo/install/apache-phoenix-4.14.0-cdh5.14.2-bin/
bin/sqlline.py node01:2181
​
create  table user (
"session_id" varchar(100) not null primary key, 
"f"."cookie_id" varchar(100), 
"f"."visit_time" varchar(100), 
"f"."user_id" varchar(100), 
"f"."age" varchar(100), 
"f"."sex" varchar(100), 
"f"."visit_url" varchar(100), 
"f"."visit_os" varchar(100), 
"f"."browser_name" varchar(100),
"f"."visit_ip" varchar(100), 
"f"."province" varchar(100),
"f"."city" varchar(100),
"f"."page_id" varchar(100), 
"f"."goods_id" varchar(100),
"f"."shop_id" varchar(100)) column_encoded_bytes=0;

5.2 导入测试数据

  • 将事先准备好的 user50w.csv 这个文件上传到node02的/xsluo/install/phoenixsql 这个路径下，该CSV文件中有50万条记录

  • node02执行以下命令，导入50W的测试数据

cd /xsluo/install/apache-phoenix-4.14.0-cdh5.14.2-bin/
bin/psql.py -t USER node01:2181 /xsluo/install/phoenixsql/user50w.csv

5.3 Global Indexing的二级索引测试

5.3.1 正常查询一条数据所需的时间

  • 在为表USER创建secondary index之前，先看看查询一条数据所需的时间 在node02服务器，进入phoenix的客户端，然后执行以下sql语句，查询数据，查看耗费时间

cd /xsluo/install/apache-phoenix-4.14.0-cdh5.14.2-bin
bin/sqlline.py node01:2181
0: jdbc:phoenix:node01:2181> select "cookie_id" from user where "cookie_id" = '99738fd1-2084-44e9';
+---------------------+
|      cookie_id      |
+---------------------+
| 99738fd1-2084-44e9  |
+---------------------+
1 row selected (6.678 seconds)

可以看到，对名为cookie_id的列进行按值查询需要6秒左右。

我们可以通过explain来查看执行计划 ​ EXPLAIN(语句的执行逻辑及计划):

0: jdbc:phoenix:node01:2181> explain select "cookie_id" from user where "cookie_id" = '99738fd1-2084-44e9';
+--------------------------------------------------------------------------------------------+-----------------+----+
|                                            PLAN                                            | EST_BYTES_READ  | ES |
+--------------------------------------------------------------------------------------------+-----------------+----+
| CLIENT 2-CHUNK 289067 ROWS 314572862 BYTES PARALLEL 1-WAY ROUND ROBIN FULL SCAN OVER USER  | 314572862       | 28 |
|     SERVER FILTER BY f."cookie_id" = '99738fd1-2084-44e9'                                  | 314572862       | 28 |
+--------------------------------------------------------------------------------------------+-----------------+----+
2 rows selected (0.054 seconds)

由此看出先进行了全表扫描再通过过滤器来筛选出目标数据，显示这种查询方式效率是很低的。

5.3.2 给表USER创建基于Global Indexing的二级索引

  • 进入到phoenix的客户端，然后执行以下命令创建索引

  • 在cookie_id列上面创建二级索引：

0: jdbc:phoenix:node01:2181> create index USER_COOKIE_ID_INDEX on USER ("f"."cookie_id"); 

-- 查看当前所有表会发现多一张USER_COOKIE_ID_INDEX索引表，查询该表数据。
0: jdbc:phoenix:node01:2181> select * from USER_COOKIE_ID_INDEX limit 5;

再次执行查询"cookie_id"='99738fd1-2084-44e9'的数据记录 :

0: jdbc:phoenix:node01:2181> select "cookie_id" from user where "cookie_id" = '99738fd1-2084-44e9';
+---------------------+
|      cookie_id      |
+---------------------+
| 99738fd1-2084-44e9  |
+---------------------+
1 row selected (0.031 seconds)

此时：查询速度由6秒左右减少到了毫秒级别。

注意：select所带的字段必须包含在覆盖索引内，EXPLAIN(语句的执行逻辑及计划):

0: jdbc:phoenix:node01:2181> explain select "cookie_id" from user where "cookie_id" = '99738fd1-2084-44e9';
+--------------------------------------------------------------------------------------------------------+----------+
|                                                  PLAN                                                  | EST_BYTE |
+--------------------------------------------------------------------------------------------------------+----------+
| CLIENT 1-CHUNK PARALLEL 1-WAY ROUND ROBIN RANGE SCAN OVER USER_COOKIE_ID_INDEX ['99738fd1-2084-44e9']  | null     |
|     SERVER FILTER BY FIRST KEY ONLY                                                                    | null     |
+--------------------------------------------------------------------------------------------------------+----------+
2 rows selected (0.051 seconds)

可以看到使用到了创建的索引USER_COOKIE_ID_INDEX。

5.3.3 以下查询不会用到索引表

  • 虽然cookie_id是索引字段，但age不是索引字段，所以不会使用到索引

0: jdbc:phoenix:node01:2181> select "cookie_id","age" from user where "cookie_id"='99738fd1-2084-44e9';
+---------------------+------+
|      cookie_id      | age  |
+---------------------+------+
| 99738fd1-2084-44e9  | 47   |
+---------------------+------+
1 row selected (6.137 seconds)

也可以通过EXPLAIN查询语句的执行逻辑及计划：

0: jdbc:phoenix:node01:2181> explain select "cookie_id","age" from user where "cookie_id"='99738fd1-2084-44e9';
+--------------------------------------------------------------------------------------------+-----------------+----+
|                                            PLAN                                            | EST_BYTES_READ  | ES |
+--------------------------------------------------------------------------------------------+-----------------+----+
| CLIENT 2-CHUNK 289067 ROWS 314572862 BYTES PARALLEL 1-WAY ROUND ROBIN FULL SCAN OVER USER  | 314572862       | 28 |
|     SERVER FILTER BY f."cookie_id" = '99738fd1-2084-44e9'                                  | 314572862       | 28 |
+--------------------------------------------------------------------------------------------+-----------------+----+
2 rows selected (0.101 seconds)

同理要查询的字段不是索引字段，也不会使用到索引表：

0: jdbc:phoenix:node01:2181> select "sex" from user where "cookie_id"='99738fd1-2084-44e9';
+---------+
|   sex   |
+---------+
| female  |
+---------+
1 row selected (2.856 seconds)

5.4 Local Indexing的二级索引测试

5.4.1 正常查询一条数据所需的时间

  • 在为表USER创建secondary index之前，先看看查询一条数据所需的时间

select * from user where "user_id"='371e963d-c-487065';

  • 可以看到，对名为user_id的列进行按值查询需要3秒左右。

0: jdbc:phoenix:node01:2181> select * from user where "user_id"='371e963d-c-487065';
+---------------------------------------+---------------------+----------------------+--------------------+------+--+
|              session_id               |      cookie_id      |      visit_time      |      user_id       | age  |  |
+---------------------------------------+---------------------+----------------------+--------------------+------+--+
| 99738fd1-2084-44e9-90b7-3cd43d36d0f0  | 99738fd1-2084-44e9  | 2016-12-10 08:51:11  | 371e963d-c-487065  | 47   |  |
+---------------------------------------+---------------------+----------------------+--------------------+------+--+
1 row selected (3.913 seconds)

EXPLAIN(语句的执行逻辑及计划):

0: jdbc:phoenix:node01:2181> explain select * from user where "user_id"='371e963d-c-487065';
+--------------------------------------------------------------------------------------------+-----------------+----+
|                                            PLAN                                            | EST_BYTES_READ  | ES |
+--------------------------------------------------------------------------------------------+-----------------+----+
| CLIENT 2-CHUNK 289067 ROWS 314572862 BYTES PARALLEL 1-WAY ROUND ROBIN FULL SCAN OVER USER  | 314572862       | 28 |
|     SERVER FILTER BY f."user_id" = '371e963d-c-487065'                                     | 314572862       | 28 |
+--------------------------------------------------------------------------------------------+-----------------+----+
2 rows selected (0.25 seconds)

由此知道先进行了全表扫描再通过过滤器来筛选出目标数据，显示这种查询方式效率是很低的。

5.4.2 给表USER创建基于Local Indexing的二级索引

  • 在user_id列上面创建二级索引：

create local index USER_USER_ID_INDEX on USER ("f"."user_id");

  • 查看当前所有表会发现多一张USER_USER_ID_INDEX索引表，查询该表数据。

0: jdbc:phoenix:node01:2181> !tables
+------------+--------------+-----------------------+---------------+----------+------------+-----------------------+
| TABLE_CAT  | TABLE_SCHEM  |      TABLE_NAME       |  TABLE_TYPE   | REMARKS  | TYPE_NAME  | SELF_REFERENCING_COL_ |
+------------+--------------+-----------------------+---------------+----------+------------+-----------------------+
|            |              | USER_COOKIE_ID_INDEX  | INDEX         |          |            |                       |
|            |              | USER_USER_ID_INDEX    | INDEX         |          |            |                       |
|            | SYSTEM       | CATALOG               | SYSTEM TABLE  |          |            |                       |
|            | SYSTEM       | FUNCTION              | SYSTEM TABLE  |          |            |                       |
|            | SYSTEM       | LOG                   | SYSTEM TABLE  |          |            |                       |
|            | SYSTEM       | SEQUENCE              | SYSTEM TABLE  |          |            |                       |
|            | SYSTEM       | STATS                 | SYSTEM TABLE  |          |            |                       |
|            |              | USER                  | TABLE         |          |            |                       |
|            |              | USER_PHOENIX          | TABLE         |          |            |                       |
|            |              | employee              | TABLE         |          |            |                       |
+------------+--------------+-----------------------+---------------+----------+------------+-----------------------+

再次执行查询"user_id"='371e963d-c-487065'的数据记录：

0: jdbc:phoenix:node01:2181> select * from user where "user_id"='371e963d-c-487065';
+---------------------------------------+---------------------+----------------------+--------------------+------+--+
|              session_id               |      cookie_id      |      visit_time      |      user_id       | age  |  |
+---------------------------------------+---------------------+----------------------+--------------------+------+--+
| 99738fd1-2084-44e9-90b7-3cd43d36d0f0  | 99738fd1-2084-44e9  | 2016-12-10 08:51:11  | 371e963d-c-487065  | 47   |  |
+---------------------------------------+---------------------+----------------------+--------------------+------+--+
1 row selected (0.375 seconds)

可以看到，对名为user_id的列进行按值查询需要0.3秒左右。

EXPLAIN(语句的执行逻辑及计划):

0: jdbc:phoenix:node01:2181> explain select * from user where "user_id"='371e963d-c-487065';
+-----------------------------------------------------------------------------------------+-----------------+-------+
|                                          PLAN                                           | EST_BYTES_READ  | EST_R |
+-----------------------------------------------------------------------------------------+-----------------+-------+
| CLIENT 1-CHUNK PARALLEL 1-WAY ROUND ROBIN RANGE SCAN OVER USER [1,'371e963d-c-487065']  | null            | null  |
|     SERVER FILTER BY FIRST KEY ONLY                                                     | null            | null  |
+-----------------------------------------------------------------------------------------+-----------------+-------+
2 rows selected (0.233 seconds)

查看执行计划，没有执行全表扫描，效率更高了

此时：查询速度由3秒左右减少到了毫秒级别。

那如果查询的字段不包含在索引表中，有如何呢？ 

0: jdbc:phoenix:node01:2181> select "user_id","age","sex" from user where "user_id"='371e963d-c-487065';
+--------------------+------+---------+
|      user_id       | age  |   sex   |
+--------------------+------+---------+
| 371e963d-c-487065  | 47   | female  |
+--------------------+------+---------+
1 row selected (0.05 seconds)
0: jdbc:phoenix:node01:2181> explain select "user_id","age","sex" from user where "user_id"='371e963d-c-487065';
+-----------------------------------------------------------------------------------------+-----------------+-------+
|                                          PLAN                                           | EST_BYTES_READ  | EST_R |
+-----------------------------------------------------------------------------------------+-----------------+-------+
| CLIENT 1-CHUNK PARALLEL 1-WAY ROUND ROBIN RANGE SCAN OVER USER [1,'371e963d-c-487065']  | null            | null  |
|     SERVER FILTER BY FIRST KEY ONLY                                                     | null            | null  |
+-----------------------------------------------------------------------------------------+-----------------+-------+
2 rows selected (0.06 seconds)

可以看到，在本地索引当中，查询的字段不包含在索引表中也使用到了创建的索引USER_USER_ID_INDEX.

5.5 如何确保query查询使用Index

  • 要想让一个查询使用index，有三种方式实现。

5.5.1 创建 covered index

  • 如果在某次查询中，查询项或者查询条件中包含除被索引列之外的列（主键MY_PK除外）。

  • 默认情况下，该查询会触发full table scan（全表扫描），但是使用covered index则可以避免全表扫描。创建包含某个字段的覆盖索引,创建方式如下：

create index USER_COOKIE_ID_AGE_INDEX on USER ("f"."cookie_id") include("f"."age");

  • 查看当前所有表会发现多一张USER_COOKIE_ID_AGE_INDEX索引表，查询该表数据。

select * from USER_COOKIE_ID_AGE_INDEX limit 5;
0: jdbc:phoenix:node01:2181> create index USER_COOKIE_ID_AGE_INDEX on USER ("f"."cookie_id") include("f"."age");
500,000 rows affected (42.897 seconds)
0: jdbc:phoenix:node01:2181> select * from USER_COOKIE_ID_AGE_INDEX limit 5;
+---------------------+---------------------------------------+--------+
|     f:cookie_id     |              :session_id              | f:age  |
+---------------------+---------------------------------------+--------+
| 000036bd-9ede-4d2e  | 000036bd-9ede-4d2e-aac4-110b1924c35d  | 24     |
| 00003aa1-aacd-4f48  | 00003aa1-aacd-4f48-8057-148d8012abcf  | 13     |
| 0000417b-4412-445e  | 0000417b-4412-445e-8431-4d9d7459ff40  | 66     |
| 0000a391-4fd8-44bd  | 0000a391-4fd8-44bd-9970-da721fbe860d  | 36     |
| 0000ce5e-3121-4da9  | 0000ce5e-3121-4da9-8ffb-19c9a3621548  | 9      |
+---------------------+---------------------------------------+--------+
5 rows selected (0.038 seconds)
  • 查询数据
select "age" from user where "cookie_id"='99738fd1-2084-44e9';
select "age","sex" from user where "cookie_id"='99738fd1-2084-44e9';
0: jdbc:phoenix:node01:2181> select "age" from user where "cookie_id"='99738fd1-2084-44e9';
+------+
| age  |
+------+
| 47   |
+------+
1 row selected (0.051 seconds)
0: jdbc:phoenix:node01:2181> select "age","sex" from user where "cookie_id"='99738fd1-2084-44e9';
+------+---------+
| age  |   sex   |
+------+---------+
| 47   | female  |
+------+---------+
1 row selected (2.394 seconds)

由此可见，当查询字段中包含索引的列和查询条件也包含索引的列时，查询会用到索引表；当查询的字段包含了不在索引表中的列，则不会走索引表。

5.5.2 在查询中提示其使用index

在select和column_name之间加上/*+ Index(<表名> <index表名>)*/，通过这种方式强制使用索引。

select /*+ index(user,USER_COOKIE_ID_AGE_INDEX) */ "age" from user where "cookie_id"='99738fd1-2084-44e9';

如果age是索引字段，那么就会直接从索引表中查询。如果age不是索引字段，那么将会进行全表扫描，所以当用户明确知道表中数据较少且符合检索条件时才适用，此时的性能才是最佳的。

5.5.3 使用本地索引 (创建Local Indexing 索引)

详细见上面。

5.6 索引重建

Phoenix的索引重建是把索引表清空后重新装配数据。

alter index USER_COOKIE_ID_INDEX on user rebuild;

5.7 删除索引

删除某个表的某张索引： 语法 drop index 索引名称 on 表名 例如：

drop index USER_COOKIE_ID_INDEX on user;

如果表中的一个索引列被删除，则索引也将被自动删除

如果删除的是覆盖索引上的列，则此列将从覆盖索引中被自动删除。

六、索引性能调优

一般来说，索引已经很快了，不需要特别的优化。

这里也提供了一些方法，让你在面对特定的环境和负载的时候可以进行一些调优。下面的这些需要在hbase-site.xml文件中设置，针对所有的服务器。

1. index.builder.threads.max 
创建索引时，使用的最大线程数。 
默认值: 10。

2. index.builder.threads.keepalivetime 
创建索引的创建线程池中线程的存活时间，单位：秒。 
默认值: 60

3. index.writer.threads.max 
写索引表数据的写线程池的最大线程数。 
更新索引表可以用的最大线程数，也就是同时可以更新多少张索引表，数量最好和索引表的数量一致。 
默认值: 10

4. index.writer.threads.keepalivetime 
索引写线程池中，线程的存活时间，单位：秒。
默认值：60
 
5. hbase.htable.threads.max 
每一张索引表可用于写的线程数。 
默认值: 2,147,483,647

6. hbase.htable.threads.keepalivetime 
索引表线程池中线程的存活时间，单位：秒。 
默认值: 60

7. index.tablefactory.cache.size 
允许缓存的索引表的数量。 
增加此值，可以在写索引表时不用每次都去重复的创建htable，这个值越大，内存消耗越多。 
默认值: 10

8. org.apache.phoenix.regionserver.index.handler.count 
处理全局索引写请求时，可以使用的线程数。 
默认值: 30

 

皮哥四月红
关注
  • 1
    点赞
  • 踩
  • 4
    收藏
    觉得还不错? 一键收藏
  • 1
    评论
专栏目录
Phoenix二级索引的使用场景与优势
禅与计算机程序设计艺术
06-11 407
作者：禅与计算机程序设计艺术 Phoenix是一个灵活且高性能的NoSQL数据库系统，广泛应用于大规模数据存储场景。本文将深入探讨Phoenix二级索引的使用场景及其带来的显著优势，包括提高查询性能、简化复杂查询以及增强数据检索效率等方面的具体应用。通过详细的理论分析、实战案例和未来展望，旨在为开发者和数据库管理人员提供全面的理解与指导。 背
Phoenix二级索引原理与代码实例讲解
禅与计算机程序设计艺术
06-08 901
Phoenix二级索引原理与代码实例讲解 1.背景介绍 在大数据时代,海量数据的高效查询和分析是一个巨大的挑战。Apache Phoenix作为构建在HBase之上的关系型数据库层,提供了类SQL的查询接口,大大简化了HBase的使用。而Phoenix的二级索引功能,更是显著提升了查
Hbase-day05_bulkLoad实现批量导入_HBase中rowkey的设计_二级索引_Phoenix二级索引
weixin_48370579的博客
06-15 452
hbase-day05 1、bulkLoad实现批量导入 优点： 如果我们一次性入库hbase巨量数据，处理速度慢不说，还特别占用Region资源， 一个比较高效便捷的方法就是使用 “Bulk Loading”方法，即HBase提供的HFileOutputFormat类。 它是利用hbase的数据信息按照特定格式存储在hdfs内这一原理，直接生成这种hdfs内存储的数据格式文件，然后上传...
HBase RowKey与索引设计
小菜
07-27 895
1.HBase的存储形式 hbase的内部使用KeyValue的形式存储，其key时rowKey：family：column：logTime，value是其存储的内容。 其在region内大多以升序的形式排列，唯一的时logTime是以降序的形式进行排列。 所以，rowKey里越靠近左边的信息越容易被检索到。其设计时，要考虑把重要的信息放左边，不重要的信息放到右边。这样可以提高查询数据的速度。最重要的提高索引速度的就是设计合适的rowKey。 在做RowKey设计时，请先考虑业务是读比写多，还是读.
AI系统HBase原理与代码实战案例讲解
禅与计算机程序设计艺术
06-04 907
AI系统HBase原理与代码实战案例讲解 1. 背景介绍 1.1 大数据时代的数据存储挑战 在当前大数据时代,海量数据的存储和管理面临着前所未有的挑战。传统的关系型数据库已经无法满足高并发、高吞吐量的数据访问需求。为了应对
HBase进阶与Phenix
最新发布
m0_58050808的博客
06-19 888
HBase进阶与Phenix
HBase企业应用开发实战pdf
weixin_30455661的博客
08-31 357
下载地址：网盘下载内容介绍编辑本书强调HBase在企业的实际应用，立足于企业的实际生产环境，旨在帮助企业切实解决大数据技术如何落地的问题。三位作者都是奋战在中国大数据技术一线的实践派专家，本书是他们实践经验的结晶。本书内容在三个维度上具有重要特色：功能维度，从HBase的安装配置、参数设置，到数据模型、表结构设计、客户端使用、高级特性，本书做了系统且详尽的介绍...
HBase实战 | HBase Rowkey 设计指南
测试0901-1
12-26 99
本文来自于2018年12月25日在 HBase生态+Spark社区钉钉大群直播，本群每周二下午18点-19点之间进行 HBase+Spark技术分享。 主题： HBase rowkey设计规范讲师：明惠——阿里云HBase业务架构师PPT下载地址：https://yq.aliyun.com/download/3233回放观看地址：https://yq.a...
非CDH的 hive 整合 hbase、Phoenix
あずにゃん梓喵的博客
02-14 1481
总帖：CDH 6系列（CDH 6.0、CHD6.1等）安装和使用 1.hive 整合 hbase 1.Hive提供了与HBase的集成，使得能够在HBase表上使用HQL语句进行查询、插入操作以及进行Join和Union等复杂查询、同时也可以将hive表中的数据映射到Hbase中。 2.应用场景 1.将ETL操作的数据存入HBase 2.HB...
HBase二级索引
01-21
HBase 二级索引 HBase 二级索引是指在 HBase 之上建立的一种二级索引机制，用于提高查询效率。根据华为公布的 HBase 二级索引实现方案，本方案主要参照了该方案，设计了 HBase 的二级索引机制。 知识点一：HBase ...
HBase二级索引 简易理解
01-07
一、解决的问题 1、RowKey 例子 ...二、对于上面需求 简单解决方案（二级索引 相当于添加一层映射关系到 原RowKey） 增加新的Hbase表 RowKey：hive_table__date___date__hive_table (解释：hive_tabl
Phoenix构建二级索引.rar
03-03
四、Phoenix二级索引构建 1. 二级索引概念：在HBase中，数据默认按行键排序，但有时需要基于列族或特定列的值进行查询，此时就需要建立二级索引。 2. 创建二级索引：使用CREATE INDEX语句定义二级索引，指定索引的列...
CDH使用Solr实现HBase二级索引.docx
09-24
CDH 使用 Solr 实现 HBase 二级索引 在大数据处理中，HBase 是一种流行的 NoSQL 数据库，用于存储大量的数据。然而，在查询和检索数据时，HBase 的性能可能不太理想。这是因为 HBase 是基于 Key-Value 的存储方式，...
基于phoenix的Hbase二级全文索引方法及系统.pdf
11-26
"基于phoenix的Hbase二级全文索引方法及系统" 本文主要介绍了基于phoenix的Hbase二级全文索引方法及系统，旨在解决Hbase数据的全文检索问题。该方法包括两大步骤：一是对Hbase原始数据表建立二级全文索引表，并存储...
HBase介绍、优缺点和实际应用场景
weixin_43230682的博客
04-01 7895
一、优点： 1）海量存储 Hbase适合存储PB级别的海量数据，在PB级别的数据以及采用廉价PC存储的情况下，能在几十到百毫秒内返回数据。这与Hbase的极易扩展性息息相关。正式因为Hbase良好的扩展性，才为海量数据的存储提供了便利。 2）列式存储 这里的列式存储其实说的是列族（ColumnFamily）存储，Hbase是根据列族来存储数据的。列族下面可以有非常多的列，列族在创建表的时候就必须指...
HBase API基本操作（含java代码实现）
weixin_43230682的博客
07-23 2199
目录 一、环境准备 1、启动服务 2、创建Maven工程 二、HBaseAPI 1、编写一个Student类 2、编写HBaseAPI类 3、测试结果 在前面我们已经安装和部署好了HBase服务，并对HBase的架构原理做了介绍： HBase1.3.3安装部署详细步骤 HBase的架构、数据结构和进阶原理（读写流程、flush、合并、拆分）详解 那么，本篇文章再结合具体的例子对HBase的java API做一个基本实现，具体如下： 一、环境准备 1、启动服务 启动Zookeepe
HBase的架构、数据存储结构和进阶原理（读写流程、Flush、StoreFile合并、预分区、Region拆分与合并）详解
weixin_43230682的博客
07-22 2047
目录 一、HBase架构 1、Client 2、Zookeeper 3、HMaster（类似NameNode） 4、HregionServer（类似DataNode） 5、HDFS 6、HRegion 7、Store 8、HFile 9、MemStore 10、WAL（Write-Ahead logs） 11、HBase Meta表 二、HBase数据结构 1、RowKey（行键） 2、Column Family（列族） 3、Cell（单元） 4、TimeStamp（时间戳
华为工程师解析HBase二级索引实现与挑战
"华为的工程师分享的关于HBase二级索引的实现资料，详细介绍了HBase二级索引的原理和注意事项，同时涵盖了华为在Hadoop开发中的贡献和HBase的基础知识回顾。" 在HBase中，一级索引是默认提供的，基于行键（Row Key...
评论 1
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明：

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

余额充值