阿里HBase业务设计实践

阿里HBase业务设计实践穆公(朱金清[e-mail])微博：淘穆公2013.4.21大纲•简介•数据模型•业务设计•产品线使用建议•监控•总结简介•Nosql:column-basedstoragesystem•Largevolumeofdata•Highwrite(esp.random)through-put/Goodramdonreadperformance•Rangequery•Row-basetransaction•Auto-sharding•ComparetoBigtable–HbaseBasedonHadoopHDFSorotherHDFS–BigtablebasedonGFSLargevolume•三层索引结构–Region的大小默认最大是256M–按照平均128M算；假设：一个rowkey1KB1.Roottable：128M=128*1024KB即2^7*2^10=2^17bucket2.Metatable：(2^17)^2=2^34bucket3.记录数：2^51条记录其它特征•三层B+树的扩展LSMTree[1]–适合于范围查询–Rowkey的字母顺序来排序(byte数组存储)•Row-base–事务级别仅限于rowkey级别•Auto-sharding–Region的自动split/move问题：牺牲了CAP中的？•[1]JimGrayandFrancoPutzolu,TheFiveMinuteRuleforTradingMemoryforDiskAccessesandThe10ByteRuleforTradingMemoryforCPUTime,Proceedingsofthe1987ACMSIGMODConference,pp395-398.已有适合的使用场景•海量数据写入–历史数据批量写入•消息类（类似Facebook的message）–消息类•Schema-free–业务监控•LOG-Append类的业务–全网HSF日志全网每天上百亿•大表的复杂/多维度索引–检索索引，主数据在mysql•分析类•大批量读取–HBase+缓存TAIR现有集群状况集群名称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与MYSQL的对比场景HBase优点HBase缺点MySQL优点MySQL缺点业务表使用使用简单，一张表即可不过没有SQL有SQL；分库分表，灵活分库后更新模式插入多的适合RKupdate差DML二级索引策略需借助索引表强DDL问题客户端接口灵活自己掌握无标准SQLSQL写性能非常强顺序写入时瓶颈在一台rs较强几千tps/单套库读性能较强；支持scan依赖内存很强；支持scan依赖索引可扩展性强借助愚公/datax工具可动态扩展弱运维方便自己定制不够成熟成熟DDL时间短；92版本可以在线若有索引表，需要自己填充Createindex即可时间长；block读写稳定性CAPCPAAPCNoSQL使用情况•TAOBAO–OTS/HBase•BAIDU–BAILING/ARMOR/HYPERTABLE(HCE)•TENCENT–TDB/TSSD•FACEBOOK–HBASE大纲•简介•数据模型•业务设计•产品线使用建议•监控•总结RegionServerRegionStorememStoreStoreFileStoreFile…Store…Region…HDFSZookeeperclusterMasterRegionServer…BackupMasterBackupMaster…HbaseClientHbaseClient…NameNodeDataNodeDataNode…HDFSclient架构图客户端LSMC0树同一机器，目的？LSMC1树Q写memstore成功立即返回读blockcache、memstore、storefile数据模型tablerowrowrowColumn-familycolumnColumn-familyColumn-familycolumncell………cellKVcellts1ts2示例•消息表表结构：message[CF:message[col:autoCommit,deviceUuid,status,type]]•对应到RDBMSdeviceUuidappidstartTimeexpiredtype…00001cc7d162302482b1cfff3530118392233706834668360652012.11.212012.12.11系统消息00001cc7d162302482b1cfff3530118392233706835317137402012.11.212012.12.11系统消息表在hdfs的存储•结构–/hbase/Table目录/region目录–Region的具体存储（/hbase/Table目录/region目录/CF目录/具体文件）大纲•简介•数据模型•业务设计•产品线使用建议•监控•总结业务设计•适合场景（综合考虑）–表数据量大（至少亿级别以上）–日志append型业务，（比如定期保留10天数据等）–原则上：•能分库分表来用mysql就用mysql来解决•mysql单表一般500w，能使用mysql的场景–无跨行跨表事务要求–写入量大(每天千万及以上)–读取量相对少(读取:写入=1/10)–读取场景简单、不经常变化–无正序、逆序的排序要求–类似dw等全量读取，不太合适。–Rowkey不经常更新（必须先删除再添加）业务设计•典型的设计–Rowkey非单一ID（单一ID可以用mysql解决）–Rowkey为组合性–最终方案：表名列名/读取写入rowkey无法覆盖的查询lAscan（）scan的时候进行前缀匹配，rowkey中的areaId是必须的参数，设置startRowlimitset（）每天定时插入数据，数据量在1000W，同时删除一个月前的那一天的数据业务查询基本上是对于rowkey的查询，只有在删除数据的时候，是根据value中的date来进行的表名CF属性(一行一个)rowkey的信息AaddresslatlngdateareaID_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不经常更新（否则必须先删除再添加）业务设计•典型的设计–交互性的应用消息–数据双写，当做索引（类似买卖家）查找穆公最近一周发布的消息？查找穆公最近一周发送给马云的消息？发送给马云的消息？•适合场景（综合考虑）–表数据量大（至少亿级别以上）–日志append型业务，（比如定期保留10天数据等）–无跨行跨表事务要求–写入量大(每天千万及以上)–读取量相对少(读取:写入=1/10)–读取场景简单、不经常变化–无正序、逆序的排序要求–分库分表类似dw等全量读取，不太合适。–Rowkey不经常更新（否则必须先删除再添加）RowkeyColumnValuefromID+timeToid:***;content:***业务设计•表结构设计id是订单ID，可以是业务主键能否覆盖查询：穆公一个星期内买的商品？穆公一个月买的书？RowkeyColumnValueIdvalueString(93fields)RowkeyColumnValueUId+time+idvalueString(32fields)默认用户订单索引表•适合场景（综合考虑）–表数据量大（至少亿级别以上）–日志append型业务–无跨行跨表事务要求–写入量大(每天千万及以上)–读取量相对少(读取:写入=1/10)–读取场景简单、不经常变化–无正序、逆序的排序要求–分库分表类似dw等全量读取，不太合适。–Rowkey不经常更新（否则必须先删除再添加）业务设计•分词索引表能否覆盖查询：穆公一个星期内买的商品？穆公一个月买的书？•结论：–覆盖搜索场景、无法用数据库解决–查询类型固定–只会按照时间排序–永久的大表保存–数据一致性要求低RowkeyColumnValueUId+分词+time+idnull•适合场景（综合考虑）–表数据量大（至少亿级别以上）–日志append型业务–无跨行跨表事务要求–写入量大(每天千万及以上)–读取量相对少(读取:写入=1/10)–读取场景简单、不经常变化–无正序、逆序的排序要求（单向时间排序ok）–分库分表类似dw等全量读取，不太合适。–Rowkey不经常更新（否则必须先删除再添加）–特殊的搜索固定需求RowkeyColumnValueUID+time+idnullUID+分词+time+idnull业务设计-无结构化数据•SchemaFree业务RowkeyColumnValueid列数不定，有的有2个列；有的有N个列大纲•简介•数据模型•业务设计•产品线使用建议•监控•总结产品线、客户端使用建议•海量数据，rowkey范围和分布已知，建议进行预分配•Rowkey一定要尽量短（如：时间用时间戳整数表示、编码压缩）•CF设计：尽量少，建议CF数量在1-2个flush和compaction是region级别；某个CF引发其它CF的memstore的flush大量storefile导致compaction(当storefile的个数value)问题：还有其他的原因么？1CF-6CF•Rowkey设计：写入要分散；如历史交易订单：biz_order_id做reverse后做rowkey产品线、客户端使用建议(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”产品线、客户端使用建议(3)•ZK连接/HTable对象的使用注意–Configure对象的使用•必须是staticorsingleton模式–默认：每台机器与zk直接的连接数不超过30个–HTable的使用•线程不安全•使用HTableV2•HTablePool(推荐的方式)产品线、客户端使用建议(3)–HTablePool(自己控制Htable数量)/***返回htablepool连接池中的一个htable*@paramtableName*@ret