简介
通过几天的学习对HBase 在存储结构上和过滤器适用上也有了一点了解,同时也遇到很多问题?例如:查询方式,数据版本,查询时部分过滤器可能会导致数据不准确等这些问题如果不熟悉或与特殊业务场景结合很容产生生产事故。我们用HBase主要是考虑大数据场景,因此一旦使用HBase产生bug那么就很容易产生资损,因此这次改动过程前期一定要做好风险控制和新老版本的灰度迭代。
我们的表设计主要从行键,列簇,列的设计出发希望能够给大家在使用HBase的过程中带来一些帮助和启发
行键维度
行键的设计:业务类型+时间戳+自增id
例:
1: 基础服务-短息001-20211110-1
解读:基础服务-短信 2021年11月10日 第一条短信
2:base-email-order-error-20211110-1
解读:基础服务2021年11月10日订单错误邮件提醒
这样从行键上就可以做一些数据查询的条件筛选。同时也要考虑一些数据的存储空间,因为大数据量那么对于空间的使用也是非常大的,因此使用时我们也要考量这方面的因素。
列簇维度
列簇的设计,我这边主要的考量因素主要是数据的变更的频繁度和数据的类型,同时列簇的数量尽量少一点1-10个我个人认为是比较合理的,当然如果是用户画像或者AI他们的列簇很可能几十个以上毕竟大家的考量因素和着重点也是各不相同的。
需求:为一个博客系统设计一个用户画像,记录用户在注册时所选的各种偏好,作为后期推广广告和圈子以及话题的依据
设计列簇:baseinfo(基础资料:性别,年龄,学历,地区,qq,微信,手机,星座),hobby(各种类型爱好,各种类型的话题的参与度,),occupation(职业类型,工作年限,公司名称,职位,薪资等)
解读:
1、 baseinfo列簇主要是用户自身基础信息,基本不会变动修改
2、hobby列簇主要记录用户选择的喜好,以及后期用户浏览轨迹(话题类型,越浏览越热爱,越给你推送)
3.occupation列簇主要记录工作相关,后期可以根据工作类型作为条件推送相关的话题来做广告推广,人才猎聘等业务
列维度
列的设计,主要考虑冗余和存储空间的一种取舍和平衡,之前我们再使用MYSQL数据库时,喜欢将部门,职位相关设计成单独的表因为这些是可以通过联查复用的,但是在HBase中列的设计就要考虑冗余一些此类的数据了
例如:
1:occupation:职位 销售经理
2: occupation:单位 3xxx02-xx地产公司 (企业编码-企业名称)
总结
好的表设计能够支撑业务的平稳运行,以及灵活的扩展。在表设计时不用盯紧数据库表设计三大范式不放,我们要根据自身的业务进行取舍。范式最终也是为业务而服务的。