跳至主要內容

几个优化问题

添码座原创大约 5 分钟大数据HBase大数据HBase

设计原则

设置预分区

  • HBase默认新建的表中只有一个HRegion，而且这个HRegion是没有边界的，也就是没有[startRowKey, endRowKey)的存在，所有的读写都集中在这个HRegion上。

  • 当HRegion大小超过预定的阈值时，HRegion会进行分裂（Split）。

  • 所以读写热点问题和分裂时的I/O问题都会影响HBase的性能。

  • 因此，可以在建表时创建多个空的HRegion，并确定每个HRegion的起点和终点。只要RowKey设计合理，就能让数据均匀地分布在HRegion之中，解决上面的两个问题。

  • 这种预先创建空HRegion的方式，就叫预分区。

# 定义5个预分区：0~100，100~200，200~300，300~400，400~
hbase:001:0> create 'user', 'info', SPLITS=>['100','200','300','400']

预分区信息可以在HBase Web UI Table Regions中看到。

RowKey的设计

  • RowKey长度原则：越短越好，不要超过16个字节，建议设计为定长。因为它的长度直接决定HFile、MemStore的存储和查询效率。

  • RowKey散列原则：为避免数据热点问题，最好将RowKey数据转换成Hash值。例如，如果RowKey为手机号，那么可以这样保存。

    • 将手机号反转，将最后一位作为RowKey的第一位，这样就可以让RowKey比较均匀地分布在0 ~ 9开头的HRegion中。

    • 取手机号全部位数或者后4位做取模运算，然后将余数作为RowKey。需要能够通过这个余数反推出手机号，否则找不到数据。

  • RowKey唯一原则：如果RowKey相同，数据会被直接覆盖，而不是像MySQL那样报错。

  • RowKey设计得是否合理可以通过HBase Web UI Table Regions中表头的ReadRequests和WriteRequests数据观察到。

  • 设计不合理的RowKey，它的每个HRegion的ReadRequests（或者WriteRequests）之间的数据必然相差巨大，也就是会出现数据热点问题，否则这些数据会是比较均匀的，数值都相差不大。

  • ReadRequests和WriteRequests只在当次HBase集群运行时有效，一旦HBase集群重启，ReadRequests和WriteRequests的数值会被清零。

列族的设计

  • 把经常读取的字段存储到一个列族中，不经常读取的存到另一个列族中。

  • 列族名避免过长或包含特殊字符。

  • 限制列族的数量。

  • 列族只保留必要的版本，过多的版本会占用更多的存储空间，并降低读取性能。

批量处理

当数据量不大而想要导入、导出或删除的时候，除了可以利用之前的代码和HBase自带的工具类外，还可以这样做。

  • 调用Table.get(List<Get>)方法，一次性读取一批数据。

  • 调用Table.put(List<Put>)方法，一次性写入一批数据。

  • 调用Table.delete(List<Delete>)方法，一次性删除一批数据。


核心参数优化

  • hbase.hregion.majorcompaction：设置HFile大合并的间隔时间，默认为604800000毫秒（7天），可设置为0，禁止自动大合并，因为大合并的执行过程可能会持续数小 时。为减少对业务的影响，建议在业务低谷期手动，或者通过脚本，或者API定期执行。

  • hbase.hregion.max.filesize： 默认值为10737418240 Byte（10G），当HRegion达到这个阈值时，会自动分裂。HRegion分裂时会有短暂的下线时间(通常在5秒 以内)。为减少对业务端的影响，建议调大该值，并在业务低谷期定时手动执行分裂。

  • hbase.regionserver.handler.count： handler用于实现底层数据的发送，默认每批次发送30条。对于大量数据的Put（达到了百万级别）操作或是大范围的Scan操作，handler数目不要过大，否则容易造成OOM（内存溢出）。而对于小负载的put、get，delete等操作，handler则可以适当调大。

  • hbase.hregion.memstore.flush.size： 默认134217728 Byte（128MB），这个参数是MemStore数据持久化到HStoreFile的时机，超过该阈值，则会触发数据持久化操作。如果HRegionServer的内存充足，则可以适当调大该值，这样可以减少MemStore的数据溢写文件的次数。

  • hbase.hregion.memstore.block.multiplier： 默认值为4，如果一个MemStore的内存大小已经超过hbase.hregion.memstore.flush.size × hbase.hregion.memstore.block.multiplier，则 会阻塞该MemStore的写操作。为避免阻塞，可以适当调大，例如6~8。但如果太大，则又有OOM的风险。如果在HRegionServer日志中出现"Blocking updates for ‘’ on region :memstoresize <?M> is >= than blocking <?M> size"的信息时，说明这个值该调整了。

  • hbase.hstore.compaction.min：默认值为3，如果任何一个Store里的HStoreFile总数超过该值，就会触发合并操作，可以设置为5~8，并在手动的定期大合并中进行HStoreFile文件的合并，减少合并的次数，不过这会延长合并的时间。

  • hbase.rpc.timeout：Scan大表时的超时时间，可以适当调大。

这些参数都可以在${HBASE_HOME}/conf/hbase-site.xml中修改。


其他问题

  • 统一各个系统的字符集，非utf8都要统一成utf8。

  • HBase第一次执行查询时会很慢，建议提前初始化链接。

  • 每日全量数据入库，数据实际发生变化的条数不多，可以用day2的数据和day1的数据做对比，只入库发生变化的数据。

  • 对表做预分区，同时RowKey做MD5 Hash取余。



感谢支持

更多内容，请移步《超级个体》。