ITPub博客

首页 > 嵌入式/内核开发 > 嵌入式/内核开发 > Ali-HBase的SQL实践与改进

Ali-HBase的SQL实践与改进

原创 嵌入式/内核开发 作者:暖忆 时间:2018-08-03 12:10:45 0 删除 编辑

摘要:  2017云栖大会Hbase专场,阿里巴巴技术专家天穆带来Ali-HBase的SQL实践与改进的演讲。本文主要从为什么需要SQL开始谈起,进而讲解了SQL on Hbase,接着着重分享了Ali-Hbase SQL的优化与改进,最后对未来进行了展望。

2017云栖大会Hbase专场,阿里巴巴技术专家天穆带来Ali-HBase的SQL实践与改进的演讲。本文主要从为什么需要SQL开始谈起,进而讲解了SQL on Hbase,接着着重分享了Ali-Hbase SQL的优化与改进,最后对未来进行了展望。
以下是精彩内容整理:

为什么需要SQL?


1


时间序列数据的存取:按照时间顺序追加新记录,按照时间范围查询数据,查询结果按时间倒排。我们数据是按照时间产生的,最新写的数据一定写在表头,在分布式情况下所有操作都落在表头,这台服务器必然会成为热点。

Hash散列


2


解决写热点问题就是打散、随机分布,任何一个操作都可以随机地放在表格里面。这带来一个新的问题,整个表不是有序,一旦时间有序就会产生写热点。

分桶


3


我们需要做一些折中,也就是分桶,我们对它做一个取模的操作,任何一次操作都可以落在随机的“桶”里面,数据在桶内是有序的,可以按照时间范围来查询。代价是范围查询时必须并发查所有桶。在查完所有桶以外需要进行一次合并。

4


我们来查时间范围,先查第一个分桶,再查第二个和第三个分桶,得到了70、60、50的结果。分桶方案其实在一定程度上提升了读的性能。

基于HBase Native api的实现


5


现在说的场景是经过高度抽象的场景,实际的场景不可能这么简单,即使在简单的场景下就需要做这么多事情。我们HBase API要想用好Hbase就需要很多额外的事情,需要写非常多的代码。学习成本也是非常高的,如果想很精准地使用是需要有技巧的,很多东西都要靠经验,用户在利用HBase API的时候要付出很高的学习成本和开发成本。大部分的HBase用户都会遇到这些类似的问题,而且每个用户都需要了解怎么去解决这些问题,使用了HBase API以后可以对自己的业务做到完全地把控。

SQL on HBase


6


为什么HBase API这么难用,说到底就是太底层了,提供“原语级别的操作。我们希望能够降低用户的接入门槛,能够低成本低接入Hbase,怎么做这件事情?阿里HBase大部分场景都是比较简单的,并且有共性,所以我们希望能够引用中间层,大部分人都能够用到。中间层就是SQL,SQL能够替代API成为HBase的默认户接口。

7


基于Phoenix的SQL ON HBase解决方案,Phoenix就是针对HBase来设计的,而且Phoenix在HBase之间也可以结合得非常好,这也是我们选择Phoenix的一个主要原因。
支付宝智能搜索dump平台

8


支付宝智能搜索Dump平台,左边的数据源是各种各样的业务数据库,可能是MYSQL,可能是HBase的,对业务数据库的变更操作会同步到HBase集群里面很多张维表里面,对维表生成宽表。对于HBase来讲,这个场景除了实时写之外还有很大的全量导入。读是通过很多的全局二级索引,经常变更的索引表。因为搜索的业务,用户的需求经常发生变更,这样对应我们的索引表发生变更,虽然有一些成本,但是相比MYSQL来讲,这个变更的成本是可以接受的。因为业务增长比较快,所以线性扩容也是关键点。

商品报表


9


商品报表是另外一套吞吐型的业务,它也有实时的全量写,而且也需要二级索引来生成多维报表。这个报表的场景跟DUMP场景不一样,这个单表比较大,在我们业务里面最大的表在压缩之后有80个TB。

物联网设备信息存储


10


物联网场景也非常典型,读写相对比较简单,但是数据量特别大,而且写得很快。在这种情况下,存储的成本以及写的吞吐能力、扩容能力HBase比较擅长。在吞吐成本这块,我们采用冷热分离存储以及压缩算法降低成本。
HBase SQL的场景基本上都是HBase自己的场景,海量的数据、线性扩展等等,但是HBase有了查询的语意,从而拓展了HBase的业务边界。

Ali-Hbase SQL


11


为了支持这些场景,我们在HBase做了很多的优化和改进,在HBase本身我们针对阿里的场景做了很多性能和功能上的变革。在稳定性方面,我们做了很多工作,能够让HBase久经双十一沙场。Ali-HBaseSQL与Phoenix在功能补齐、功能增强、数据导入导出方面有所改善。Phoenix本身需要人去指定一个索引表,我们把这个事情自动化了,同时增强了可以访问多张索引表的能力,数据可以在各个系统之间产生流动。

性能优化

目标是将简单请求的性能优化到极致,与对应的HBase Native API性能差距小于5%。单行读写的场景下,SQL和HBase API的差距很明显。
客户端的元数据缓存,元数据:列名、数据类型、表属性、索引信息等等。元数据更新策略:并不是每次都刷新元数据,我们做了周期性的刷新,通过版本号的方式来识别是不是最新的,如果不是最新的就更新一版,这是优化UPSERT的缓存更新策略。

12


SELECT优化,我们会根据油壶请求的大小来合理选择适用,这个选择对性能影响非常大,因为我们的目标是优化简单的请求,优化一点点在用户那边的体现都是非常明显的。我们并不是分析型的场景,并不需要数据的预取,做到这些事情以后读的性能已经跟HBase Select比较接近了。
此外,阿里云上的SQL,从其他的RDBMS迁移至云HBase。

未来的工作

未来一定是支持列名映射,支持ImmutableDataEncoding,我们现在正在调研,在大宽表的情况下能够节省1/3—1/2的存储空间。但是有一个限制,这个数据只能写下去,不能改。我们要优化功能都需要让用户去申请SQL的客户端,这是非常恶心的事情;支持query server mode和瘦客户端,解决了产品不断迭代的问题,用户不需要升级也可以享受到我们的改进;支持分布式Sequence,最终我们也要把SQL的能力做到分布式;可选的索引一致性,异步全局二级索引,有些场景下用户不需要强一致性,比如说日志,最终在1分钟之内一致就OK了,所以我们做一个异步的全局更新,更新成本也进一步降低了。

原文链接

本文为云栖社区原创内容,未经允许不得转载。


来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/31545802/viewspace-2169083/,如需转载,请注明出处,否则将追究法律责任。

请登录后发表评论 登录
全部评论

注册时间:2018-07-13

  • 博文量
    378
  • 访问量
    122797