回顶部

联系方式

0571-89852485

工作日 9:00-21:00

  or  

让我们联系您

在线客服

联系方式

格式不正确
格式不正确
格式不正确
联系方式只能为手机号码或邮箱
格式错误

提交成功

感谢您对网易大数据的支持,我们会尽快与你取得联系

完成

从阿里云数据库技术峰会看他们的产品

2017-08-28     作者:蒋鸿翔
本篇文章仅限本站分享,如需转载,请联系网易获取授权。
欢迎技术交流和讨论:bigdata@service.netease.com

前言

8月24号阿里云数据库技术峰会在网上直播,作为一个数据库从业者,本着学习的态度认真观看了下大部分内容,总的感觉没有特别的惊喜,基本上都是一些内部(或外部)已经成熟的技术或服务,只不过这次被阿里云搬到了云服务上对外提供,逐一看下的各个产品


HiTSDB

HiTSDB是阿里云一款分布式时序数据库,主要用于海量时序数据的存储,当前市面上成熟的时序数据库其实很多,比如:Druid、OpenTSDB、InfluxDB等等,都是当前比较主流的时序型数据库,个人认为时序数据库的主要特点在于:数据产生都带时间戳,数据量非常庞大,但一般数据的时效性比较明显,怎么理解?就是说一般需求的数据都集中在最近1~2周内,对于历史数据,基本上都只是非精确的需求,比如像一般的报警平台,基本上报警处理都在最近的1天内,很少会追溯到1周前的报警信息,所以一般处理上对于多天前的数据基本上可以聚合处理,基本上每个时序数据库都有历史数据聚合功能。

回过头来看下HiTSDB,从PPT上看,HiTSDB的原型就是OpenTSDB,相比于OpenTSDB,HiTSDB在此基础上增加了倒排索引和不同压缩方式。不可否认,倒排索引能使HiTSDB具有多维度组合查询能力,但这个怎么看都像是抄Druid的;另外一个是增加了delta-delta压缩,对于数值型的数据,比如时间戳,可以用几个bit位进行代替,这个对空间来说的确可以节省不少,一个时间戳(longlong)基本上8个字节,通过压缩可以变为原来的10%左右。基本上整个HiTSDB的亮点就是倒排和压缩,整个从技术栈上来看没有多大新意,除了新的压缩算法外,一个Druid基本能涵盖HiTSDB大部分功能


HTAP

HTAP是最近冒出来的新名词,以前的平台OLTP与OLAP都分得比较清楚,一个数据库,要么是TP型的,如:MySQL、PostgreSQL;要么是AP型的,像Hive、Spark、Impala,HTAP宣称是一种事务分析混合模型,即所谓的Hybrid,是一种OLTP + OLAP集成方案。

在个人印象中,OLTP与OLAP差异还是比较大的,首先存储上OLTP基本上是行存,OLAP则大多数偏向列存(SAP HANA是个例外),因为OLAP很多情况下需要读取指定列的全部数据,列存有天然的优势。那么阿里云的HTAP的数据怎么存?

阿里云的HTAP即HybridDB for MySQL,也就是原来的PetaData,实现上用TokuDB作为MySQL的存储引擎,TokuDB相比于InnoDB在写入的数据量上有很大的提升,基本上数据存储量可以是InnoDB的5~6倍,但是这都以牺牲性能为代价。个人看来,其实还有更好的选择 —— RocksDB,云栖社区有一篇博文专门比较了InnoDB、TokuDB、RocksDB三者在不同场景下的性能(https://yq.aliyun.com/articles/61780),从结论上来说,基本上TokuDB被RocksDB完爆,在基本相同的压缩比下,RocksDB仍然维持了与InnoDB相近的读写性能,而TokuDB.....

PS: FaceBook已经把RocksDB作为MySQL的一个存储引擎myrocks在其开源分支上提供(https://github.com/facebook/mysql-5.6),阿里云的工程师也表示后续在考虑集成RocksDB到他们的产品中去。

说完了引擎层,再分析下HTAP的上层,HTAP基本上踢掉了DRDS这种中间件模式,而重新实现了一种类MPP的模式,中间件与MPP目前是单机数据库比较常用的两种扩展模式,个人认为MPP相比中间件更有优势,因为中间件基本对数据库是没有侵入性的,也就造就了中间件对很多查询的优化显得很力不从心;相反,MPP与底层结合的更为紧密,可以实现很多特定的优化。

从上面的分析基本可以得出:HTAP基本上以一种MPP的形式,通过TokuDB作为存储引擎来实现。那么OLAP怎么办?方式简单粗暴,直接用Flink在上面进行计算...,又不禁让我想起另外一家厂商:Pingcap,TiDB + TiSpark,同样的行存,同样的类MPP架构,同样的号称Hybrid,当然方式也同样粗暴,只是底层一个是用了TokuDB,一个是RocksDB,计算引擎一个是Flink,另外一个是Spark...

PS:阿里云还有另外一种HybridDB for postgreSQL的混合型数据库,原型为GreenPlum,GreenPlum天生支持Heap和AO(append only)两种不同类型的表分别适应OLTP和OLAP服务。

阿里云HTAP架构

把OLTP和OLAP融入到一个产品里,目前来看还没有一个产品能真正实现,Pingcap也说满足100%的OLTP和80%的OLAP需求,个人看来80%还是值得商榷,OLAP还是需要列存作为基础。前段时间在翻sigmod 2017的paper,上面有个BatchDB提出了另外一种HybridDB的实现思想,即在一个集群中,部分节点提供行存,部分节点提供列存,然后通过上层一些特定的方式进行引流,把OLTP和OLAP的不同请求分别导入到不同的服务上。比如一个5副本的数据库,根据业务需求可以实现3(行存)+2(列存)的的模式,OLTP请求通过行存实现,OLAP则通过列存来分析,想法还不错,都是从实际问题出发,只不过技术实现上,行存、列存之间的数据复制,副本宕机后的重新构建等很多细节需要考虑。


DTS

DTS即数据传输服务,通过DTS可以实现不同数据库,不同数据中心之间的数据同步。阿里DTS只是一个外部服务名称,对外部用户开放,在内部被称为DRC,DTS支持Oracle、MySQL、PostgreSQL、MSSQL等多种不同的数据库之间数据的同步,这里的同步是可以支持异构数据的,不仅限于相同数据库之间的数据传输,也就是说可以把Oracle的数据同步到MySQL或者其他支持的数据库,DTS也支持更新缓存(如redis等),导数据到计算平台等等。当然另外一个功能可以在不同的数据中心之间传输数据,延迟基本在1s以内,这为同城跨机房、异地多活提供了技术保障,当然开源的数据传输平台也有很多,比如像SQOOP等,DTS的优势在于支持的数据库种类更为丰富,支持在线增量迁移等等。人家还简单对比了下与OGG(Oracle Golden Gate)的性能,据说实测性能比OGG好很多...

阿里云DTS

阿里云的DTS作为一个数据传输中转中心,目前看已经非常全面,当然我们网易数据库 & 大数据内部也有自己的数据传输服务NDC,整个功能上与DTS类似,只是数据源和目的上有些许差别,我们NDC支持到GreenPlum、到Kudu等的数据互通

HBase

HBase云服务基本上就比较简单,没有什么标新立异的地方,讲了些HBase的场景,基本上跟我们的类似,他们HBase上架了Phoenix来提供二级索引和SQL支持,这个我们内部目前还没有,以前是觉得Phoenix还不够稳定,现在人家敢拿出来在共有云上用,我们应该也可以尝试下。二级索引不能太多,最好不要超过2个,这个也可以理解,毕竟数据量会有很大增长。

至于事务,人家明确说HBase不会支持事务,事务应该交给数据库,这个怎么说,毕竟目前就Yahoo的omid号称支持事务,到底怎么个玩法,其实大家都没底,最后说后续打算把HBase放公网上去玩,这个风险还是挺大,认证和授权机制需要完善。当然还有多活这种需求,HBase的多活需求相对于数据库没有很强烈,Replica出来这么久了也没见几个人真正的用。所以对于整个HBase没有多大出彩的地方,重点来看下阿里哪些业务可以构建在HBase之上,这个也是我们内部用户问的最多的。

阿里HBase服务

通过上图看以看到,像日志、聊天、监控、订单、风控还有IoT,这些都是HBase非常典型的应用,我们内部像云信(聊天)、哨兵(监控)、DataStream(日志)这些业务也都是构建在HBase系统之上


DMS

数据管理平台,更类似于一个运维平台,这个目前不是我的研究范围,Pass。


PolarDB

在InnoSQL的早期版本(大概2013年)我就想做InnoDB基于Redo的复制,刚接触Hadoop和EMR的时候(2014年)就在想如果把MySQL的底层文件系统换成HDFS会怎么样?性能和实现上的复杂度先不说,至少物理复制和共享存储这两个点我都想到了,只是还没有把这两个东东融合起来的想法。

回来看下PolarDB,初一看整个结构跟AWS的Aurora还挺类似,AWS在2014年底发布了Aurora,PolarDB在2017年中才准备推出,中间差了2年半,这个时间足够根据人家的理念复制一套了。当然也有一些差别,Aurora把数据页的恢复直接丢给了底层存储去做,换句话说Aurora的存储层是定制的,不仅要提供数据存储,还需要实现把Redo log apply到数据页的过程,不是一个通用的存储层。而PolarDB的存储与Aurora不同,底层应该是一个通用的存储,依赖RDMA高速网络和Parallel-Raft实现底层数据多副本存储,所以可能PolarDB从结构上看,更像Oracle的RAC。不管是PolarDB还是AWS Aurora,提供的思想就是日志即数据,在数据库整个写入过程中,磁盘I/O代价是非常昂贵的,比如MySQL的一次数据写入,需要写Binlog、Redo Log,中间可能还涉及到写DoubleWrite,当然还有最后数据落盘等等,整个过程中有大量的I/O操作,而日志即数据只需要把Redo log落盘即可,整个过程节省大量的I/O开销。PolarDB和Aurora都剥离了存储,这种模式跟大数据中EMR的形式就有很大类似了,存储和计算分离,对于存储来说,底层3副本或者5副本的数据足以满足高可用的需求,一般对于应用来说,需要提升的是计算能力,以往需要提升计算能力的做法就是引入一个新的slave,然后分流部分读请求到新slave上,这样就存在一个问题:我们为了扩展新的计算资源,不可避免的多引入了一份完全相同的数据(slave数据通过复制完全拷贝master数据)。而共享存储把存储和计算进行了剥离,扩容计算能力时并不需要引入更多的数据副本。