阿里HBase业务设计实践_第1页
阿里HBase业务设计实践_第2页
阿里HBase业务设计实践_第3页
阿里HBase业务设计实践_第4页
阿里HBase业务设计实践_第5页
已阅读5页,还剩29页未读 继续免费阅读

付费下载

下载本文档

版权说明:本文档由用户提供并上传,收益归属内容提供方,若内容存在侵权,请进行举报或认领

文档简介

阿里HBase业务设计实践2024/3/25阿里HBase业务设计实践大纲简介数据模型业务设计产品线使用建议监控总结阿里HBase业务设计实践简介Nosql:column-basedstoragesystemLargevolumeofdataHighwrite(esp.random)through-put/GoodramdonreadperformanceRangequeryRow-basetransactionAuto-shardingComparetoBigtableHbaseBasedonHadoopHDFSorotherHDFSBigtablebasedonGFS阿里HBase业务设计实践Largevolume三层索引结构Region的大小默认最大是256M按照平均128M算;假设:一个rowkey1KBRoottable:128M=128*1024KB 即2^7*2^10=2^17bucketMetatable:(2^17)^2=2^34bucket记录数:2^51条记录阿里HBase业务设计实践其它特征三层B+树的扩展LSMTree[1]适合于范围查询Rowkey的字母顺序来排序(byte数组存储)Row-base事务级别仅限于rowkey级别Auto-shardingRegion的自动split/move问题:牺牲了CAP中的?[1]JimGrayandFrancoPutzolu,"TheFiveMinuteRuleforTradingMemoryforDiskAccessesandThe10ByteRuleforTradingMemoryforCPUTime",Proceedingsofthe1987ACMSIGMODConference,pp395-398.阿里HBase业务设计实践已有适合的使用场景海量数据写入历史数据批量写入消息类(类似Facebook的message)消息类Schema-free业务监控LOG-Append类的业务全网HSF日志全网每天上百亿大表的复杂/多维度索引检索索引,主数据在mysql分析类大批量读取HBase+缓存TAIR阿里HBase业务设计实践现有集群状况集群名称TPS(avg)11.11最高QPS(avg)11.11最高版本业务7k1.8w1.6w3.4w0.90.2业务1.8w2w1.2w1.4w业务7k3w2w5w业务1k2k2k6k业务2.5w5w2w6w业务10w25w(最高50w)1w2w0.94业务4w20w(压测)2k3w(压测)0.94业务每天2-3kw-RT在ms级别-0.90.2-定制版业务10w25w15w100w0.94业务3k1.4w3k6k0.94业务1.5w2w6k8k0.94阿里HBase业务设计实践与MYSQL的对比场景HBase优点HBase缺点MySQL优点MySQL缺点业务表使用使用简单,一张表即可不过没有SQL有SQL;分库分表,灵活分库后更新模式插入多的适合RKupdate差DML二级索引策略需借助索引表强DDL问题客户端接口灵活自己掌握无标准SQLSQL写性能非常强顺序写入时瓶颈在一台rs较强几千tps/单套库读性能较强;支持scan依赖内存很强;支持scan依赖索引可扩展性强借助愚公/datax工具可动态扩展弱运维方便自己定制不够成熟成熟DDL时间短;92版本可以在线若有索引表,需要自己填充Createindex即可时间长;block读写稳定性CAPCPAAPC阿里HBase业务设计实践NoSQL使用情况TAOBAOOTS/HBaseBAIDUBAILING/ARMOR/HYPERTABLE(HCE)TENCENTTDB/TSSDFACEBOOKHBASE阿里HBase业务设计实践大纲简介数据模型业务设计产品线使用建议监控总结阿里HBase业务设计实践RegionServerRegionStorememStoreStoreFileStoreFile…Store…Region…HDFSZookeeperclusterMasterRegionServer…BackupMasterBackupMaster…HbaseClientHbaseClient…NameNodeDataNodeDataNode…HDFSclient架构图客户端LSMC0树同一机器,目的?LSMC1树Q写memstore成功立即返回读blockcache、memstore、storefile阿里HBase业务设计实践数据模型tablerowrowrowColumn-familycolumnColumn-familyColumn-familycolumncell………cellKVcellts1ts2阿里HBase业务设计实践示例消息表 表结构:message

[CF:message[col:autoCommit,deviceUuid,status,type]]:8888/阿里HBase业务设计实践message对应到RDBMSdeviceUuidappidstartTimeexpiredtype…00001cc7d162302482b1cfff3530118392233706834668360652012.11.212012.12.11系统消息00001cc7d162302482b1cfff3530118392233706835317137402012.11.212012.12.11系统消息阿里HBase业务设计实践表在hdfs的存储结构/hbase/Table目录/region目录Region的具体存储(/hbase/Table目录/region目录/CF目录/具体文件)阿里HBase业务设计实践大纲简介数据模型业务设计产品线使用建议监控总结阿里HBase业务设计实践业务设计适合场景(综合考虑)表数据量大(至少亿级别以上)日志append型业务,(比如定期保留10天数据等)原则上:能分库分表来用mysql就用mysql来解决mysql单表一般500w,能使用mysql的场景无跨行跨表事务要求写入量大(每天千万及以上)读取量相对少(读取:写入<=1/10)读取场景简单、不经常变化无正序、逆序的排序要求类似dw等全量读取,不太合适。Rowkey不经常更新(必须先删除再添加)阿里HBase业务设计实践业务设计典型的设计Rowkey非单一ID(单一ID可以用mysql解决)Rowkey为组合性最终方案:表名列名/读取写入rowkey无法覆盖的查询lAscan()

scan的时候进行前缀匹配,rowkey中的areaId是必须的参数,设置startRowlimitset()每天定时插入数据,数据量在1000W,同时删除一个月前的那一天的数据业务查询基本上是对于rowkey的查询,只有在删除数据的时候,是根据value中的date来进行的表名CF属性(一行一个)rowkey的信息Aaddress

latlng

dateareaID_geohash_companyId

长度:6位数字+12位小写字母+小于5位数字

前面的6为数字穷举约在4000个左右表名CF列表(一行一个)rowkey的信息AInfo(address、latlng)areaID_geohash_companyId

长度:6位数字+12位小写字母+小于5位数字

前面的6为数字穷举约在4000个左右适合场景(综合考虑)表数据量大(至少亿级别以上)日志append型业务,(比如定期保留10天数据等)无跨行跨表事务要求写入量大(每天千万及以上)读取量相对少(读取:写入<=1/10)读取场景简单、不经常变化无正序、逆序的排序要求分库分表类似dw等全量读取,不太合适。Rowkey不经常更新(否则必须先删除再添加)阿里HBase业务设计实践业务设计典型的设计交互性的应用消息数据双写,当做索引(类似买卖家)

查找穆公最近一周发布的消息?查找穆公最近一周发送给马云的消息?发送给马云的消息?

适合场景(综合考虑)表数据量大(至少亿级别以上)日志append型业务,(比如定期保留10天数据等)无跨行跨表事务要求写入量大(每天千万及以上)读取量相对少(读取:写入<=1/10)读取场景简单、不经常变化无正序、逆序的排序要求分库分表类似dw等全量读取,不太合适。Rowkey不经常更新(否则必须先删除再添加)RowkeyColumnValuefromID+timeToid:***;content:***阿里HBase业务设计实践业务设计表结构设计 id是订单ID,可以是业务主键

能否覆盖查询:穆公一个星期内买的商品?穆公一个月买的书?RowkeyColumnValueIdvalueString(93fields)RowkeyColumnValueUId+time+idvalueString(32fields)默认用户订单索引表适合场景(综合考虑)表数据量大(至少亿级别以上)日志append型业务无跨行跨表事务要求写入量大(每天千万及以上)读取量相对少(读取:写入<=1/10)读取场景简单、不经常变化无正序、逆序的排序要求分库分表类似dw等全量读取,不太合适。Rowkey不经常更新(否则必须先删除再添加)阿里HBase业务设计实践业务设计分词索引表 能否覆盖查询:穆公一个星期内买的商品?穆公一个月买的书?结论:覆盖搜索场景、无法用数据库解决查询类型固定只会按照时间排序永久的大表保存数据一致性要求低RowkeyColumnValueUId+分词+time+idnull适合场景(综合考虑)表数据量大(至少亿级别以上)日志append型业务无跨行跨表事务要求写入量大(每天千万及以上)读取量相对少(读取:写入<=1/10)读取场景简单、不经常变化无正序、逆序的排序要求(单向时间排序ok)分库分表类似dw等全量读取,不太合适。Rowkey不经常更新(否则必须先删除再添加)特殊的搜索固定需求RowkeyColumnValueUID+time+idnullUID+分词+time+idnull阿里HBase业务设计实践业务设计-无结构化数据SchemaFree业务RowkeyColumnValueid列数不定,有的有2个列;有的有N个列阿里HBase业务设计实践大纲简介数据模型业务设计产品线使用建议监控总结阿里HBase业务设计实践产品线、客户端使用建议海量数据,rowkey范围和分布已知,建议进行预分配Rowkey一定要尽量短(如:时间用时间戳整数表示、编码压缩)CF设计:尽量少,建议CF数量在1-2个

flush和compaction是region级别;某个CF引发其它CF的memstore的flush大量storefile导致compaction(当storefile的个数>value)

问题:还有其他的原因么?1CF->6CFRowkey设计:写入要分散;如历史交易订单:biz_order_id做reverse后做rowkey阿里HBase业务设计实践产品线、客户端使用建议(2)Autoflush参数设置为true;否则极端情况下会丢失数据Hbaseclient的重试次数为3次以上。否则会由于split导致regionnotonle;从而导致写入失败(udc集群出现过)。hbase.rpc.timeout 一次rpc的timeout;默认60秒hbase.client.pause 客户端的一次操作失败,到下次重试之间的等待时间hbase.client.retries.number 客户端重试的次数hbase.regionserver.lease.period客户端租期超时阀值;scan量大时可以考虑增大;否则”LeaseException:lease-70000000000000001doesnotexist”阿里HBase业务设计实践产品线、客户端使用建议(3)ZK连接/HTable对象的使用注意Configure对象的使用必须是staticorsingleton模式默认:每台机器与zk直接的连接数不超过30个HTable的使用线程不安全使用HTableV2HTablePool(推荐的方式)阿里HBase业务设计实践产品线、客户端使用建议(3)HTablePool(自己控制Htable数量) /**

*返回htablepool连接池中的一个htable

*@paramtableName

*@return

*/

publicstaticsynchronizedHTablegetHtable(StringtableName){

if(hTablePool!=null)

return(HTable)hTablePool.getTable(tableName);//如果hTablePool对象已经存在,直接取出一个htable

else{//

hTablePool不存在则先new一个htablepool对象,然后再取

}} /**HTable是非线程安全的在多线程环境下使用HTablePool是一个好的解决方案, *参数MAX_TABLE_COUNT是pool保持的每个Htable实例的最大数量, *比如为10如果有100个线程getTable()同一张表则他们会共用pool中的该表的10个实例,其它的单独申请 *使用的时候就不要newHtable了,直接从pool中取 *用完再putTable放回去 *

*在0.92以上的版本则不用放回去直接table.close()即可putTable被标记为@Deprecated *0.90.2版本使用putTable下面的代码都没有做这些操作 *避免不同版本出问题 */阿里HBase业务设计实践业务接入Ork平台http://nosql.*.com阿里HBase业务设计实践影响写测试阿里HBase业务设计实践影响汇总1、对于写速度而言,影响因素的效果主要为:写hlog>split>compact;2、对于写

温馨提示

  • 1. 本站所有资源如无特殊说明,都需要本地电脑安装OFFICE2007和PDF阅读器。图纸软件为CAD,CAXA,PROE,UG,SolidWorks等.压缩文件请下载最新的WinRAR软件解压。
  • 2. 本站的文档不包含任何第三方提供的附件图纸等,如果需要附件,请联系上传者。文件的所有权益归上传用户所有。
  • 3. 本站RAR压缩包中若带图纸,网页内容里面会有图纸预览,若没有图纸预览就没有图纸。
  • 4. 未经权益所有人同意不得将文件中的内容挪作商业或盈利用途。
  • 5. 人人文库网仅提供信息存储空间,仅对用户上传内容的表现方式做保护处理,对用户上传分享的文档内容本身不做任何修改或编辑,并不能对任何下载内容负责。
  • 6. 下载文件中如有侵权或不适当内容,请与我们联系,我们立即纠正。
  • 7. 本站不保证下载资源的准确性、安全性和完整性, 同时也不承担用户因使用这些下载资源对自己和他人造成任何形式的伤害或损失。

评论

0/150

提交评论