hive+hbase设计细节

た入场券 2021-12-23 06:15 181阅读 0赞

前言  
近半年本人主要在倒腾数据，遇到海量数据去重的难题，曾经尝试过各种hivesql，然而随着数据量逐渐增大，处理耗时也越来越长，各种方案一一破产。2012年11月份提过使用HBase唯一主键的方案，随即做了相关预研（参看hive&hbase解决方案测评）。该方案由于HBase转化成hive表性能问题而搁浅。但在测评报告最后的总结中提到：或许我们可以选择数据“冷热”、以及部分字段切表来优化。  
  
2013年3月，我们在业务上做了调整，通过部分字段来区分数据的“冷热”，从此希望的烟火重新燃起……  
  
表设计  
为区分数据的“冷热”，我们采用分表方式，即冷数据A和热数据B存储于HBase的不同表，另外每天增量数据的冷数据C也有一张表来存储。相对而言，B、C两张表数据量不大，顶多上千万条记录，A才是可能成为海量（TB、PB级别）的数据表。3张表的设计缺点是增量数据导入时业务复杂，需要经过多次判断。  
  
导入  
数据导入HBase及hive时遇到了几个问题，一一道来。  
  
数据在数量级别上分两种，一种是初始化大数据量数据，另一种是常态化增量小数据量数据。两种数据导入HBase时需要采取不同的策略。  
  
初始化数据  
我们有3亿+的初始化数据，对于海量数据存储大吞吐量写入的HBase来说是小case（根据各种测评得出的结论）。原先采用MapRedue按行读取hdfs文件数据，直接put至HBase表中方式。该方式是很普遍很通用的方式，按理说应该能顺利进行，但在我们真正运行时却超级缓慢。这里我们忽视了几个重要的问题：  
1.我们数据有40+个字段，而HBase导入测评字段数少。  
2.HBase表没有预先创建分区，数据在插入过程中HBase会不停的执行split操作。  
3.HBase的单个regionserver适合存储几个region？  
网上有不少HBase数据导入调优的资料，海量数据导入最优的一种方式是将数据转化成HBase认知的HFile形式。该方式可以通过MapReduce输出HFile  
  
job.setOutputFormatClass(HFileOutputFormat.class);  
HFileOutputFormat.configureIncrementalLoad(job, new HTable(conf, hbase\_table\_name));  
HFileOutputFormat.setOutputPath(job, new Path(outpath));  
然后通过LoadIncrementalHFiles  
  
Configuration HBASE\_CONFIG = new Configuration();  
conf = HBaseConfiguration.create(HBASE\_CONFIG);  
SchemaMetrics.configureGlobally(conf);  
String\[\] params = new GenericOptionsParser(conf, args).getRemainingArgs();  
if (params.length != 2) \{  
    System.err.println("Usage: LoadHFileToHBase <hdfs\_path> <hbase\_table>");  
    System.exit(-1);  
\}  
LoadIncrementalHFiles loader = new LoadIncrementalHFiles(conf);  
HTable ht=new HTable(conf,params\[1\]);  
ht.setAutoFlush(false);  
loader.doBulkLoad(new Path(params\[0\]), ht);  
load至HBase表中。需要注意的点有：HBase表需要预创建region，不然在转化HFile时只有一个reduce（有几个region就有几个reduce，如何预创建分区见下一节），导致转化超慢；如此也会想到，在做HFile转化时，HBase表在做其他导入操作或者说有split操作，会导致后续的load也会超级慢，所以我们在做MapReduce HFile的转化时，HBase表最好不要有任何写入操作。  
那这种方式能顺利进行吗？我们预创建表region数1000和100分别做了测试，在load数据时，都会报超时的异样（很抱歉，异常信息未记录），真是痛不欲生，花了很长时间没有解决此问题。  
随即，我们又回到原导入方式，预先创建了region测试，速度上有点点提升，效率上本人着实觉得不合理，一个map运行很长时间。分析一下，map按行获取数据，转化成put对象后，执行导入，各种调优参数也调了批量导入也试过了，就是不见速度上有提升。为啥？很可能是在连接HBase时耗时，该MapRecude采用内置连接HBase的方式即：  
  
conf.set(TableOutputFormat.OUTPUT\_TABLE, hbase\_table\_name);  
job.setOutputFormatClass(TableOutputFormat.class);  
接着，本人不采用内置连接方式  
  
protected void setup(Context context) throws IOException, InterruptedException \{  
    String table\_name = context.getConfiguration().get("table\_name").trim();  
    if (StringUtils.isNotBlank(table\_name)) \{  
        tablename = table\_name;  
        ht = new HTable(context.getConfiguration(), tablename);  
        ht.setAutoFlush(false);  
        ht.setWriteBufferSize(5\*1024\*1024);  
        putlist = new ArrayList<Put>();  
    \}  
\}  
......  
protected void cleanup(Context context) throws IOException, InterruptedException \{  
    if (putlist.size() != 0)\{  
        ht.put(putlist);  
        putlist.clear();  
    \}  
    ht.close();  
\}  
立马map执行速度快了n倍，终于告了一段落。至于为何MapReduce内置连接HBase会慢，需查看源码，待研究。  
常态化数据  
由于常态化数据小，所以相应表采用普通的创建即可。HBase至HBase表操作采用org.apache.hadoop.hbase.mapreduce.CopyTable方式，HBase表至hive表采用MapReduce方式。  
RowKey设计  
使用HBase做存储，RowKey设计是最最关键的一部分。HBase查询数据方式有三种：  
  
根据RowKey（高效）  
根据RowKey区间（高效）  
采用scan（转化成MapReduce低效，不满足实时性）  
可见好的RowKey直接影响查询速率（此处未考虑secondary indexes）。  
  
在数据导入过程中，需要预先创建region，也就是需要划分RowKey段。我们设计RowKey是数字型，对已有的初始化数据RowKey化分了1000份，经过测试，HBase会出现死节点情况，一个regionserver多少个region才合适呢？官方给出的答案是：  
  
http://hbase.apache.org/book.html，2.5.2.6.1.how many regions per regions。  
  
根据我们的实际情况，目前hadoop9个节点，4个regionserver。将1000份减少到100份，并根据数据量的大小，每个region设置成6G  
  
public static boolean createTable(String tableName, String family, byte\[\]\[\] splits) throws IOException \{  
    HBaseAdmin admin = new HBaseAdmin(conf);  
    try \{  
        if (admin.tableExists(tableName)) \{  
            System.out.println("table already exists!");  
        \} else \{  
            HTableDescriptor tableDesc = new HTableDescriptor(tableName);  
            tableDesc.addFamily(new HColumnDescriptor(family));  
            tableDesc.setMaxFileSize(new Long("6442450900"));  
            admin.createTable(tableDesc, splits);  
            return true;  
        \}  
        return false;  
    \} catch (TableExistsException e) \{  
        return false;  
    \}  
\}  
public static byte\[\]\[\] getHexSplits(String\[\] regions) \{  
    int numRegions = regions.length;  
    byte\[\]\[\] splits = new byte\[numRegions - 1\]\[\];  
    for (int i = 0; i < numRegions - 1; i++) \{  
        BigInteger key = new BigInteger(regions\[i\], 16);  
        byte\[\] b = String.format("%016x", key).getBytes();  
        splits\[i\] = b;  
    \}  
    return splits;  
\}  
应用总结  
适合TB级别数据，将会增长到TB级别数据。  
很高的写吞吐量，瞬间写入量大。  
可通过rowkey访问数据，hbase rowkey访问数据最高效。  
列可扩展。  
结构化、半结构化数据。  
无交叉表、连接表、多层索引、事务操作的数据模型。  
遗留的问题  
secondary indexesCCHADOOP-95 - hbase secondary indexes - OPEN ，0.94版本没有此功能，期待后续版本提供类似select \* from table where anycell="XXX"的功能，目前国内有公司在应用层实现创建索引表，在应用层实现索引查询功能。  
load HFile时超时的异样  
表设计中，热数据表和增量冷数据表数据小，也采用了HBase存储。可通过关系型数据做中间存储替换，或者将3张表合并成一张大表替换（前提索引问题解决）。

发表评论取消回复

表情：

评论列表（有 0 条评论，181人围观）

还没有评论，来说两句吧...

相关阅读

相关 Java设计模式：单例模式实现细节

单例模式是Java设计模式中的一种，它保证一个类只有一个实例，并提供一个全局访问点。以下是单例模式的实现细节： 1. 饿汉式单例（静态内部类）： ```java publ

ゞ浴缸里的玫瑰/ 2024年10月23日 05:30/ 0 赞/ 67 阅读

相关设计模式挑战：Java Singleton模式实现细节探讨

Singleton模式是Java设计模式中的一种，它保证一个类仅有一个实例，并提供全局访问点。以下是Singleton模式在Java中的实现细节： 1. 静态内部类：这是最常

男娘i/ 2024年09月22日 11:42/ 0 赞/ 81 阅读

相关 Java设计模式：单例模式实现细节探讨

单例模式是Java设计模式中的一种，其主要特点是全局只有一个实例，并且提供一个全局访问点。以下是单例模式在Java中的实现细节探讨： 1. 静态内部类实现： ```jav

小灰灰/ 2024年09月20日 01:03/ 0 赞/ 90 阅读

相关 Java设计模式——装饰模式——主干确定调整细节

[点此查看全部文字教程、视频教程、源代码][Link 1] 本文目录 1. 场景 2. 实例 1. 场景装饰模式主要适用于主干功能都已确定，

ゝ一纸荒年。/ 2023年07月21日 05:25/ 0 赞/ 10 阅读

相关 hinernate细节

`inverse`映射属性究竟表示什么呢？对于你和Java来说，一个双向关联仅仅是在两端简单地正确设置引用。然而，Hibernate并没有足够的信息去正确地执行`INSERT`

朴灿烈づ我的快乐病毒、/ 2022年09月19日 15:29/ 0 赞/ 194 阅读

相关提高单片机设计的10个细节

前言 1 干扰对单片机应用系统的影响 1.1测量数据误差加大 1.2 控制系统失灵 1.3 影响单片机RAM存储

男娘i/ 2022年08月28日 04:46/ 0 赞/ 174 阅读

相关缓存架构设计细节二三事

原文地址：https://mp.weixin.qq.com/s?\_\_biz=MjM5ODYxMDA5OQ==&mid=404087915&idx=1&sn=07566419

逃离我推掉我的手/ 2022年05月21日 01:12/ 0 赞/ 179 阅读

相关数据库设计细节

1、数据库中每张表都要有一个id字段，类型为int，自动递增，没有实际意义，仅作为每张表的主键。原因：这样不仅避免了主键唯一且不为null的问题，还最大化地利用了主键索引，

青旅半醒/ 2022年05月20日 09:38/ 0 赞/ 152 阅读

相关缓存架构设计细节二三事

本文主要讨论这么几个问题：（1）“缓存与数据库”需求缘起（2）“淘汰缓存”还是“更新缓存” （3）缓存和数据库的操作时序（4）缓存和数据库架构简析一、需求缘起

心已赠人/ 2022年03月30日 14:38/ 0 赞/ 202 阅读

相关 hive+hbase设计细节

前言近半年本人主要在倒腾数据，遇到海量数据去重的难题，曾经尝试过各种hivesql，然而随着数据量逐渐增大，处理耗时也越来越长，各种方案一一破产。2012年11月份提过使

た入场券/ 2021年12月23日 06:15/ 0 赞/ 182 阅读