HBase之Rowkey设计

HBase之Rowkey设计

Rowkey基础

• Rowkey按自然顺序存储的，且具有唯一性，示例如下

  a_022
  a_101
  b_123
  f_031
  f_051
  f_131
  z_121
  

• 当数据是有序的时候，通常利用二分查找的方式进行点查询、范围查询是最有效的（hash只能进行点查）。HBase的Rowkey查询正是遵循这种规律。
• Rowkey的查询可以分为两大类
  • Get 点查询，给定一个rowkey，查询对应数据
  • Scan 范围查询，给定一个起始rowkey、一个结束rowkey，查询范围内的所有数据
• 因此，我们需要根据查询的方式去设计Rowkey

Rowkey查询设计

• 数据

  idCard	name	age	address	longitude	latitude	address_info
  510***12	张三	18	重庆	105.55	29.30	***
  220***32	李四	23	北京	116.23	39.72	***
  310***65	王五	18	重庆	103.36	28.75	***
  240***13	李磊	27	上海	121.68	31.80	***
  510***12	张三	18	北京	115.38	38.95	***

• 一般来说，根据实际业务场景，我们需要将多个字段设计到一个Rowkey中，下面来分析几个场景

• 单点查询业务

  • 单点查询设计最简单，只需要将能够唯一确定一条数据的几个字段组合为一个Rowkey即可
  • 例如，查询某个人在某城市的地址信息
    • 上面数据中，张三分别在重庆、北京都有住址信息，因此光靠idCard不能确定唯一条数据。
    • Rowkey应当由 idCard_address组合而成，例如 510***12_重庆

• 范围查询业务

  • 范围查询设计较麻烦，有几个要点如下
    • 一般来说需要将范围字段放至Rowkey最后
    • 查询时必须明确Rowkey的范围字段前面的所有字段值
    • 通常除了取并集时不能同时存在2个及以上的范围字段（有特殊办法解决）
  • 例如，查询某个地区一定年龄范围的人
    • 如果age字段在address字段前面(age_address)，显然无法进行范围查询，因为必须先确定address
    • Rowkey应当由 address_age组合而成，例如 重庆_18
    • 另外，如果想随意查询重庆某个经度范围、某个纬度范围的人(address_longitude_latitude)，显然也是无法使用的（只能满足and查询）

• 范围查询业务——双重范围

  • 前面已经说了，一般情况下无法同时存在2个及以上的范围字段。不过，在某些场景下，利用特殊手段，依然可以实现双重范围查询。
  • 例如，查询某人在某个经度范围、某个纬度范围的地址
    • 显然，此时存在2个范围，例如张三、经度100.23-105.34、纬度25.12-30.24
    • 我们可以将经纬度划分为N个小块，根据小块的标签进行查询，图例如下
      
    • 一个小块的标签编号，即代表了某个范围内的所有经纬度。利用小块编号就能进行范围查询，一个小块编号代表一个范围，多个小块编号就能代表一个大的范围。显然，这种方式会存在精度损失问题，当小块越大时，精度损失越大，如果缩小小块的范围，又会提高查询的代价（因为要查询更多的rowkey）。这种方案，在地理信息编码中用的较多，例如Geohash。
    • 将Rowkey设计为 人名_小块编号，例如 张三_23。想对张三进行多个范围的查询，只需执行多个Get查询即可。
  • 虽然，使用这种方式实现双重范围查询，会损失部分精度，但
    • 如果你的业务场景不敏感，那么这样就非常好
    • 如果你的业务场景比较在乎这里的精度，你可以在查询中添加filter，或是查得数据后进行过滤（推荐后者，将计算分散到客户端）

• 其他部分，请看常见问题

二级索引

• 内部实现
  • 利用协处理器(coprocessor)，设计二级索引表
    • 将二级索引设计到二级索引表的Rowkey中，二级索引表的列簇存原始表的Rowkey
    • 查询时，根据字段从二级索引表的Rowkey查询到数据，数据即原始表的Rowkey，再根据该Rowkey到原始表查询数据
  • 华为hindex，与协处理器方式同理，不过使用较方便（单表过大可能会出问题，例如我遇到的80亿数据量的单张表）
  • 也可以不用协处理器，自己实现二级索引表，但是协处理器更方便
• 外部实现
  • Phoenix 专用于创建HBase二级索引
  • ElasticSearch 通用型索引创建

常见问题

• 建表初期入库较慢？
  • HBASE建表后，默认只有一个Region，会随着数据量增加，自动拆分为多个Region。因此，最开始时只有一个Region，数据量大的话，会感觉入库速度不理想。
  • 建议，分析该表的Rowkey，进行预拆分，初始时就建立起多个Region，这样会提高HBase入库吞吐量。
• 难以决定Rowkey的预拆分？
  • Rowkey较多，不知道怎么创建预拆分的key。如果是定期一张新表（例如每天一张），那么有个小技巧可以帮助你。
  • 第一次建表时，不做预拆分，等待入库完成，HBase将会自动完成Region拆分。根据HBase本次的表拆分信息创建对下一次的表进行预拆分即可。
• 入库热点问题？
  • 通常是数据不具备较强随机性（散列性）导致的
  • 实时入库时，当相近的时间之间，其数据的Rowkey自然顺序较接近，会导致该时间段的数据都入向同一个Region，自然效率就降低了。
  • 例如，将时间字段放在Rowkey的第一位，会导致实时入库时，总是同时只存在一个Region在入数据。
  • 建议
    • 重新设计Rowkey中导致入库热点问题的字段
      • 如果该字段不是必须在第一位。那么可以将后面较随机的字段替换到前面来
      • 如果该字段必须在第一位。那么查询时该字段若能固定长度，则可以将其打乱，例如将手机号的后面3位替换到最前面来 18912345678 -> 67818912345
    • 如果不需要实时，那么可以进行批量入库，打乱数据顺序，就不存在Region热点问题了
    • 使用数据的HASH值（取前几位即可）作为Rowkey前缀
      • 例如：c0bef_字段A_字段B
      • 需要注意的是，如果以HASH值为Rowkey前缀，能够达到较好的数据分布均匀效果，解决热点问题，但是会牺牲Rowkey的易用性
        • 因为你必须记住前面的HASH值，以用于后续查询
        • 该方式只直接适用于GET查询，如需进行多维度查询，建议创建二级索引（典型架构就是 ES + HBase）
• Rowkey的实际顺序与期待的不符？
  • 例如，一份数据

    // 期待的顺序如下
    f_31
    f_51
    f_131
    
    // 实际的顺序如下
    f_131
    f_31
    f_51
    

  • 需要注意的是HBASE的Rowkey是按自然顺序排序的，后者才是真正的自然顺序
  • 如果需要按照期待的顺序存储，那么应当对第二个字段进行补齐，例如

    f_031
    f_051
    f_131
    

  • 因此，通常我们会要求每个字段应当是定长的
• 入库程序无法保证 exactly-once ？
  • 通常，入库程序可能由于某些原因挂了，或是网络问题，最终导致重复入库数据。
  • HBase的Rowkey具有唯一性，因此合理的设计Rowkey，可以保证数据在业务上的幂等性！