• 1. 阿里HBase业务设计实践 穆公(朱金清 suinking@gmail.com) 微博:淘穆公 2013.4.21
  • 2. 大纲简介 数据模型 业务设计 产品线使用建议 监控 总结
  • 3. 简介Nosql: column-based storage system Large volume of data High write (esp. random ) through-put / Good ramdon read performance Range query Row-base transaction Auto-sharding Compare to Bigtable Hbase Based on Hadoop HDFS or other HDFS Bigtable based on GFS
  • 4. Large volume三层索引结构 Region的大小默认最大是256M 按照平均128M算; 假设:一个rowkey 1KB Root table: 128M=128*1024KB 即2^7 * 2^10 = 2^17 bucket Meta table: (2^17)^2 = 2 ^34 bucket 记录数:2^51 条记录
  • 5. 其它特征三层B+树的扩展LSMTree[1] 适合于范围查询 Rowkey的字母顺序来排序(byte数组存储) Row-base 事务级别仅限于rowkey级别 Auto-sharding Region的自动split/move 问题:牺牲了CAP中的? [1] Jim Gray and Franco Putzolu, "The Five Minute Rule for Trading Memory for Disk Accesses and The 10 Byte Rule for Trading Memory for CPU Time", Proceedings of the 1987 ACM SIGMOD Conference, pp 395-398.
  • 6. 已有适合的使用场景海量数据写入 历史数据 批量写入 消息类(类似Facebook的message) 消息类 Schema-free 业务监控 LOG-Append类的业务 全网HSF日志 全网每天上百亿 大表的复杂/多维度索引 检索索引,主数据在mysql 分析类 大批量读取 HBase+缓存TAIR
  • 7. 现有集群状况集群名称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
  • 8. 与MYSQL的对比场景HBase优点HBase缺点MySQL优点MySQL缺点业务表使用使用简单,一张表即可不过没有SQL有SQL;分库分表,灵活分库后更新模式插入多的适合RKupdate差DML二级索引策略需借助索引表强DDL问题客户端接口灵活自己掌握无标准SQLSQL写性能非常强顺序写入时瓶颈在一台rs较强几千tps/单套库读性能较强;支持scan依赖内存很强;支持scan依赖索引可扩展性强借助愚公/datax工具可动态扩展弱运维方便自己定制不够成熟成熟DDL时间短;92版本可以在线若有索引表,需要自己填充Create index即可时间长;block 读写稳定性CAPCPAAPC
  • 9. NoSQL使用情况TAOBAO OTS/HBase BAIDU BAILING/ARMOR/HYPERTABLE(HCE) TENCENT TDB/TSSD FACEBOOK HBASE
  • 10. 大纲简介 数据模型 业务设计 产品线使用建议 监控 总结
  • 11. Region ServerRegionStorememStoreStoreFileStoreFile…Store…Region…HDFSZookeeper clusterMasterRegion Server…Back up MasterBack up Master…Hbase ClientHbase Client…NameNodeDataNodeDataNode…HDFS client架构图客户端LSM C0树同一机器,目的?LSM C1树Q写memstore成功立即返回 读blockcache、memstore、storefile
  • 12. 数据模型tablerowrowrowColumn-familycolumnColumn-familyColumn-familycolumncell………cellKVcellts1ts2
  • 13. 示例消息表 表结构: message [CF: message [col: autoCommit, deviceUuid, status, type]] http://dbidea.corp.taobao.com:8888/
  • 14. message对应到RDBMSdeviceUuidappidstartTimeexpiredtype…00001cc7d162302482b1cfff3530118392233706834668360652012.11.212012.12.11系统消息00001cc7d162302482b1cfff3530118392233706835317137402012.11.212012.12.11系统消息
  • 15. 表在hdfs的存储结构 /hbase/Table目录/region目录 Region的具体存储 (/hbase/Table目录/region目录/CF目录/具体文件)
  • 16. 大纲简介 数据模型 业务设计 产品线使用建议 监控 总结
  • 17. 业务设计适合场景 (综合考虑) 表数据量大(至少亿级别以上) 日志append型业务,(比如定期保留10天数据等) 原则上: 能分库分表来用mysql就用mysql来解决 mysql 单表一般500w,能使用mysql的场景 无跨行跨表事务要求 写入量大 (每天千万及以上) 读取量相对少 (读取:写入 <= 1/10) 读取场景简单、不经常变化 无正序、逆序的排序要求 类似dw等全量读取,不太合适。 Rowkey不经常更新 (必须先删除再添加)
  • 18. 业务设计典型的设计 Rowkey非单一ID (单一ID可以用mysql解决) Rowkey为组合性 最终方案: 表名列名/读取写入rowkey无法覆盖的查询lAscan() scan的时候进行前缀匹配,rowkey中的areaId是必须的参数,设置startRow limitset()每天定时插入数据,数据量在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不经常更新 (否则必须先删除再添加)
  • 19. 业务设计典型的设计 交互性的应用消息 数据双写,当做索引(类似买卖家) 查找穆公最近一周发布的消息? 查找穆公最近一周发送给马云的消息? 发送给马云的消息? 适合场景 (综合考虑) 表数据量大(至少亿级别以上) 日志append型业务,(比如定期保留10天数据等) 无跨行跨表事务要求 写入量大 (每天千万及以上) 读取量相对少 (读取:写入 <= 1/10) 读取场景简单、不经常变化 无正序、逆序的排序要求 分库分表类似dw等全量读取,不太合适。 Rowkey不经常更新 (否则必须先删除再添加)RowkeyColumn ValuefromID + timeToid: ***;content:***
  • 20. 业务设计表结构设计 id是订单ID,可以是业务主键 能否覆盖查询: 穆公一个星期内买的商品? 穆公一个月买的书?RowkeyColumn ValueIdvalueString ( 93 fields )RowkeyColumn ValueUId + time + idvalueString (32 fields )默认用户订单索引表适合场景 (综合考虑) 表数据量大(至少亿级别以上) 日志append型业务 无跨行跨表事务要求 写入量大 (每天千万及以上) 读取量相对少 (读取:写入 <= 1/10) 读取场景简单、不经常变化 无正序、逆序的排序要求 分库分表类似dw等全量读取,不太合适。 Rowkey不经常更新 (否则必须先删除再添加)
  • 21. 业务设计分词索引表 能否覆盖查询: 穆公一个星期内买的商品? 穆公一个月买的书? 结论: 覆盖搜索场景、无法用数据库解决 查询类型固定 只会按照时间排序 永久的大表保存 数据一致性要求低RowkeyColumn ValueUId + 分词 + time + idnull适合场景 (综合考虑) 表数据量大(至少亿级别以上) 日志append型业务 无跨行跨表事务要求 写入量大 (每天千万及以上) 读取量相对少 (读取:写入 <= 1/10) 读取场景简单、不经常变化 无正序、逆序的排序要求 (单向时间排序ok) 分库分表类似dw等全量读取,不太合适。 Rowkey不经常更新 (否则必须先删除再添加) 特殊的搜索固定需求RowkeyColumn ValueUID+ time + idnullUID+ 分词 + time + idnull
  • 22. 业务设计-无结构化数据SchemaFree业务 RowkeyColumn Valueid列数不定,有的有2个列;有的有N个列
  • 23. 大纲简介 数据模型 业务设计 产品线使用建议 监控 总结
  • 24. 产品线、客户端使用建议海量数据,rowkey范围和分布已知,建议进行预分配 Rowkey一定要尽量短 (如:时间用时间戳整数表示、编码压缩) CF设计:尽量少,建议CF数量在1-2个 flush和compaction是region级别;某个CF引发其它CF的memstore的flush大量store file 导致compaction(当store file的个数>value) 问题: 还有其他的原因么? 1CF -> 6CF Rowkey设计:写入要分散;如历史交易订单:biz_order_id做reverse后做rowkey
  • 25. 产品线、客户端使用建议(2)Autoflush参数设置为true;否则极端情况下会丢失数据 Hbase client的重试次数为3次以上。否则会由于split导致region not onle;从而导致写入失败(udc集群出现过)。 hbase.rpc.timeout 一次rpc的timeout;默认60秒 hbase.client.pause 客户端的一次操作失败,到下次重试之间的等待时间 hbase.client.retries.number 客户端重试的次数 hbase.regionserver.lease.period 客户端租期超时阀值;scan量大时可以考虑增大;否则”Lease Exception: lease -70000000000000001 does not exist”
  • 26. 产品线、客户端使用建议(3)ZK连接/HTable对象的使用注意 Configure对象的使用 必须是static or singleton模式 默认:每台机器与zk直接的连接数不超过30个 HTable的使用 线程不安全 使用HTableV2 HTablePool (推荐的方式)
  • 27. 产品线、客户端使用建议(3)HTablePool(自己控制Htable数量) /**                  * 返回htablepool连接池中的一个htable          * @param tableName          * @return          */         public static synchronized HTable getHtable(String tableName){                 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个实例,其它的单独申请 * 使用的时候 就不要new Htable了,直接从pool中取 * 用完再putTable 放回去 * * 在0.92以上的版本 则不用放回去 直接table.close() 即可 putTable 被标记为 @Deprecated * 0.90.2 版本使用 putTable 下面的代码都没有 做 这些操作 * 避免 不同版本 出问题 */
  • 28. 业务接入Ork平台http://nosql.*.com
  • 29. 影响写测试
  • 30. 影响汇总1、对于写速度而言,影响因素的效果主要为: 写hlog > split > compact; 2、对于写速度波动而言,想完全不波动是不可能,影响因素的效果主要为:split > 写hlog > compact; 3、对于写频率较高的应用而言,一台region server上不适合有太多的region; (hbase.hregion.max.filesize = 64G) 4、Pre-Sharding可以不做,建议做; 5、对于日志应用可以考虑关闭compact/split hbase.regionserver.regionSplitLimit 1关闭split hbase.hstore.compactionThreshold Integer.MAX_VALUE关闭Compact hbase.hstore.blockingStoreFiles Integer.MAX_VALUE
  • 31. 风险点——集群稳定/容灾regionserver的单点问题 导致部分数据短暂不可用 跨机房容灾 目前还只是部署在单个机房 跨机房性能衰减 实现: 程序双写 复制的测试(push的replication已经上线、pull在研) 消息中间件实现(异步消息)
  • 32. 大纲简介 数据模型 业务设计 产品线使用建议 监控 总结
  • 33. 监控类型主机监控 端口监控 错误日志监控 写入监控 GC监控 性能指标 http://beidou.*/hbase.php http://hbplus.*/sch/monitor.jsp http://hbase.*/hbase/overview.php 开发常用系统\hbaseplus\websqlplus
  • 34. Thanks! Q&A穆公/朱金清 微博:淘穆公 http://www.weibo.com/suinking