hive结合hbase数据处理解决方案测评二（优化篇）

接上一篇，对hbase参数进行优化，主要是调整与查询效率相关的参数
[b]count[/b]

select count(1) from hbase_table;

[b]部分字段切表[/b]

insert overwrite table hive_table select a,b,c,d from hbase_table;

[b]全字段切表[/b]

insert into table test_table partition(part='aa') select * from hbase_table;

[b]hive至hive切表[/b]

create table test_table2 like test_table;
insert into table test_table2 partition(part) select * from test_table;

[b]优化修改参数[/b]

<property>
    <name>hbase.regionserver.handler.count</name>
    <value>100</value>
    <description>Count of RPC Listener instances spun up on RegionServers.
    Same property is used by the Master for count of master handlers.
    Default is 10.
    </description>
</property>
<property>
    <name>hfile.block.cache.size</name>
    <value>0.4</value>
    <description>
         Percentage of maximum heap (-Xmx setting) to allocate to block cache
         used by HFile/StoreFile. Default of 0.25 means allocate 25%.
         Set to 0 to disable but it's not recommended.
    </description>
 </property>
 <property>
    <name>hbase.client.scanner.caching</name>
    <value>1000</value>
    <description>Number of rows that will be fetched when calling next
    on a scanner if it is not served from (local, client) memory. Higher
    caching values will enable faster scanners but will eat up more memory
    and some calls of next may take longer and longer times when the cache is empty.
    Do not set this value such that the time between invocations is greater
    than the scanner timeout; i.e. hbase.regionserver.lease.period
    </description>
 </property>

[b]切表[/b]

[table]
|优化前后 |字段全量与否 |case |数据量 |cpu cost（minutes，seconds） |执行cost（seconds）|
|前 |部分 |hbase->hive |1616374 |10 ， 18 |359.162|
|后 |部分 |hbase->hive |1616374 |3 ， 24 |281.975|
|后 |部分 |hbase->hive |1616374 |2 ， 38|232.391|
|后 |部分 |hbase->hive |2608626 |4 ， 39 |263.206|
|后 |全量 |hbase->hive |2608626 |7 ， 53 |820.914|
|后 |部分 |hbase->hive |12230528 |13 ， 22 |765.262|
|后 |全量 |hbase->hive |12230528 |22 ， 59 |1305.236|
|后 |全量 |hive->hive |12230528 |10 ， 41 |580.522|
[/table]
[b]count[/b]

[table]
|优化前后| 表类型 |数据量 |cpu cost（minutes，seconds） |执行cost（seconds）|
|优化前 |hbase |1616374 |10 ， 45 |728.647|
| |hive |1616374 |0 ， 25 |64.815|
|优化后 |hbase |1616374 |4 ， 9 |609.28|
|优化后 |hbase |12230528 |13 ， 10 |907.44|
| |hive |12230528 |3 ， 18 |422.138|
[/table]
总结

hive&hbase表的统计计算性能远低于hive表的统计计算，相差3倍乃至以上。
hbase参数优化前后有查询统计效率成倍提升，但与hive表相比也存在差距。
hive&hbase表切成hive表部分字段由于全量字段。
...
综上，hive的hbase存储结构不善于统计计算；hive表的hbase存储结构切换成hive普通的存储结构，随着数据量增加，性能也令人堪忧（如上测试也可以看到，即使是hive与hive表的切表数据量大也是很耗时的）。hbase方案具体是选择居于hive&hbase表统计计算，还是选择hive&hbase表切换成hive表后统计计算，需要权衡，或者是否有其他更好hive与hbase关联方案，需要继续研究。

分析：随着数据量越来越大，每天都进行hbase—>hive的切表，这是不切合实际的选择，但终究我们需要将hbase表转化成hive表，或许我们可以选择数据“冷热”、以及部分字段切表来优化。

备注：测试还不全面，待完善，特别是hive&hbase复杂sql的统计计算。