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

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

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

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只是一个外部服务名称，对外部用户开放，在内部被称为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上架了Phoenix来提供二级索引和SQL支持，这个我们内部目前还没有，以前是觉得Phoenix还不够稳定，现在人家敢拿出来在共有云上用，我们应该也可以尝试下。二级索引不能太多，最好不要超过2个，这个也可以理解，毕竟数据量会有很大增长。

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

阿里HBase服务

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

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

在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数据)。而共享存储把存储和计算进行了剥离，扩容计算能力时并不需要引入更多的数据副本。