《天穆:Ali-HBase的SQL实践与改进(30页).pdf》由会员分享,可在线阅读,更多相关《天穆:Ali-HBase的SQL实践与改进(30页).pdf(30页珍藏版)》请在三个皮匠报告上搜索。
1、Ali-HBase的SQL实践与改进阿里巴巴天穆为什么需要SQL?SQL on Ali-HBase优化与改进ApsaraDB-HBase未来的工作2 3 4 51案例:时间序列数据的存取time(desc)eventmessage10040011aaa8010020bbb8010010ccc7010040ddd6020000eee.需求:按时间顺序追加新记录 按时间范围查询数据 查询结果按时间倒排写热点问题time(desc)eventmessage10040011aaa8010020bbb8010010ccc7010040ddd6020000eee.time(desc)eventmessag
2、e12010010 xxx11010020yyy10040011aaa8010020bbb8010010ccc.hashtimeeventmessageAAAA10040011aaaBBBB8010020bbbCCCC12010010 xxxDDDD8010010cccEEEE11010010yyyFFFF.解决写热点问题:Hash散列time(desc)eventmessage12010010 xxx11010020yyy10040011aaa8010020bbb8010010ccc.bucket_idtime(desc)eventmessage110040011aaa7010040ddd5
3、030000fff28010010ccc6020000eee38010020bbb4010050hhh.分桶:bucket_id=md5(rowkey)%bucket_num 所有“桶”都可写 数据在桶内有序,桶之间无序 代价:范围查询时,须并发查所有桶,客户端执行merge sort解决写热点问题:分桶bucket_idtime(desc)eventmessage110040011aaa7010040ddd5030000fff28010010ccc6020000eee39010020bbb4010050hhh.Select*from eventLog where time 40 and ti
4、me=70;解决写热点问题:分桶bucket_1:70,50bucket_2:60bucket_3:NA70,60,50merge sort 分桶:写:打散 读:并发scan,client merge sort desc主键:ts=Long.MAX_VALUE-ts rowkey:3列主键的拼接与拆分 数据类型转换:Hbase只支持byte对于复杂的业务场景,用户要做的事情更多基于HBase Native API的实现使用HBase Native API的代价与收益 成本/负担 学习成本:学习曲线陡峭 开发成本:代码量大 重复 每个用户都要做相同/相似的事情 精准 细节:用户可精确控制一切,如
5、hash函数选取 最佳性能/吞吐:便于针对场景进行优化 自定义 实现复杂的业务场景“难用”的HBase Native APIHBase Native API仅提供“原语”级别的操作抽象层次低目标:降低接入门槛,让用户能快速、低成本的接入需求:解决共性问题 自动/透明的rowkey散列 自动拼接/解析rowkey(schema)支持丰富的数据类型 支持丰富的查询语义 支持二级索引 支持聚合.解决方案:SQL on HBase 具备Native API的全部能力 与Native API性能差距5%相比HBase API,大家更熟悉SQL 快速开发(ORM框架)对用户透明的优化 SQL工具 更低的接
6、入门槛和成本解决Native API“难用”的问题成为HBase的默认户接口拓展服务边界基于Phoenix的SQL on HBase解决方案Phoenix JDBC DriverHBase ClientRegionServerPhoenix CoprocessorRegionServerPhoenix CoprocessorRegionServerPhoenix CoprocessorHDFSZooKeeper ServiceHBase Master Service案例1:支付宝智能搜索dump平台数据源HBaseShopItemRelationShopItemRelationResultHB
7、ase同步Join导出搜索引擎实时链路全量链路 250+张表 80亿+数据 日更新1亿 全链路RT 200ms 平均select RT 10W,峰值30W+案例1:支付宝智能搜索dump平台HBaseShopItemRelationResultHBase多维度查询导出实时写入Bulkload场景:周期性全量导入+实时增量 每张主表平均3-6张索引表 基于全局二级索引的多维度查询 经常变更的索引表要求:线性扩展 高吞吐,低时延 实时读写 全量bulkload案例2:商品报表离线计算任务MaxComputeHBase实时计算任务BIBulkLoad实时写入增量导出 100亿+数据 平均日增1亿+,
8、峰值5亿 每张主表平均8+张索引表 多维度查询以生成丰富的报表 大表:单表压缩后数据80TB+高吞吐:单次查询结果集大案例3:物联网设备信息存储设备.设备设备汇聚层HBase可视化分析 200亿+数据 每日写入5亿+前缀+时间范围扫描 写多读少 冷热分离存储 线性扩展:数据量增长快适用场景 海量数据 线性扩展:数据增长快 高吞吐:大规模读写 高性能:计算与存储的实时性要求迫切 多维度查询:二级索引 数据易发散:schema free搜索风控日志IoT时序报表Ali-HBase与社区HBase性能领先前缀BloomFilterBucketCacheCrossRegion写合并CompactedC
9、oncurrentSkipListMap连接数优化锁优化Netty替换RPCHLog压缩新的Block Encoding格式.功能丰富离散式TTL资源隔离异构介质多副本异步API稳定可靠完善的跨集群数据链路毫秒级延迟拓扑可视化量化的延迟多地多单元链路隔离支持同步复制一键切换自动切换快速故障恢复多年沉淀,久经双11沙场,坚如磐石功能补齐increment条件更新append列粒度的mvccAli-HBase SQL与Phoenix功能增强salted table增强纯hash散列reverse散列索引增强RBOIndexMerge慢SQL监控数据导入导出通过Upsert全量导入(同步更新索引)B
10、ulkload通过Select全量导出增量导出Ali-HBase SQL性能优化将简单请求的性能优化到极致与对应的HBase Native API性能差距小于5%单行读写的性能优化写操作:upsert into test values(.);Table#put(Put);读操作:select*from test where pk=1;Table#get(Get);2.32.60.71.500.511.522.53ReadWritePhoenixHBase API(ms)写为什么慢?UPSERT statementUpsertCompilerMutationState更新meta cacheTa
11、ble#batch(mutations)Meta RegionData table region访问RS耗时近1ms客户端的元数据缓存元数据:列名,数据类型,表属性,索引信息等等 周期性刷新(PHOENIX-2520)按需刷新 每个请求都携带版本号 服务端永远有最新版本 服务端判断客户端是否持有过期元数据元数据更新策略:每次请求都刷新 遇到错误时刷新优化UPSERT的缓存更新策略2.61.61.500.511.522.53writePhonenixalhb-sqlHbaseAPI(ms)降低38%的RTSELECT优化JDBC DriverQueryCompilerQueryPlanParal
12、lel ScanSpoolingSpooling-1ms:缓存更新优化-0.5ms:使用small scan或getScan#setCaching()使用single scan不预取数据降低65%的RT2.30.80.700.511.522.5ReadPhoenixalihb-sqlHbaseAPI(ms)单行读写的性能优化2.32.60.81.60.71.500.511.522.53ReadWritePHoenixalihb-sqlHBaseAPI65%38%(ms)阿里云上的SQL on HBaseApsaraDB-HBase:使用Ali-HBase从其他RDBMS迁移至云HBase:标准SQL 支持大多数常见的标准SQL语法 方言:insert/update合并为upsert,存在则更新,不存在则插入新行 不需要分库分表,线性扩容和负载均衡 数据同步:数加 数据集成(https:/ server mode和瘦客户端分布式Sequence可选的索引一致性:异步全局二级索引