万字长文揭秘：阿里如何实现海量数据实时分析？(4)

SELECT a, b FROM t1WHERE b +1=10;------>SELECT a, b FROM t1WHERE b =9;

-- f3类型是TIMESTAMP类型
SELECT concat(f3,1)FROM nation;------>SELECT concat(CAST(f3 AS CHAR),"1")FROM nation;

SELECT * FROM t1
WHERE max_adate >"2017-05-01"    AND max_adate !="2017-04-01"------>SELECT * FROM t1WHERE max_adate > DATE "2017-05-01"

玄武存储引擎

为保证大吞吐写入，以及高并发低时延响应，AnalyticDB自研存储引擎玄武，采用多项创新的技术架构。玄武存储引擎采用读/写实例分离架构，读节点和写节点可分别独立扩展，提供写入吞吐或者查询计算能力。在此架构下大吞吐数据写入不影响查询分析性能。同时玄武存储引擎构筑了智能全索引体系，保证绝大部分计算基于索引完成，保证任意组合条件查询的毫秒级响应。

★ 读写分离架构支持大吞吐写入

传统数据仓库并没有将读和写分开处理，即这些数据库进程/线程处理请求的时候，不管读写都会在同一个实例的处理链路上进行。因此所有的请求都共享同一份资源（内存资源、锁资源、IO资源），并相互影响。在查询请求和写入吞吐都很高的时候，会存在严重的资源竞争，导致查询性能和写入吞吐都下降。

为了解决这个问题，玄武存储引擎设计了读写分离的架构。如下图所示，玄武存储引擎有两类关键的节点：Buffer Node和Compute Node。Buffer Node专门负责处理写请求，Compute Node专门负责查询请求，Buffer Node和Compute Node完全独立并互相不影响，因此，读写请求会在两个完全不相同的链路中处理。上层的Front Node会把读写请求分别路由给Buffer Node和Compute Node。

实时写入链路：

实时查询链路：

AnalyticDB提供强实时和弱实时两种模式，强实时模式执行逻辑描述如上。弱实时模式下，Front Node查询请求则不带版本下发，返回结果的实时取决于Compute Node对实时数据的处理速度，一般有秒极延迟。所以强实时在保证数据一致性的前提下，当实时数据写入量比较大时对查询性能会有一定的影响。

高可靠性

玄武存储引擎为Buffer Node和Compute Node提供了高可靠机制。用户可以定义Buffer Node和Compute Node的副本数目（默认为2），玄武保证同一个数据分区的不同副本一定是存放在不同的物理机器上。Compute Node的组成采用了对等的热副本服务机制，所有Compute Node节点都可以参与计算。另外，Computed Node的正常运行并不会受到Buffer Node节点异常的影响。如果Buffer Node节点异常导致Compute Node无法正常拉取最新版本的数据，Compute Node会直接从盘古上获取数据（即便这样需要忍受更高的延迟）来保证查询的正常执行。数据在Compute Node上也是备份存储。如下图所示，数据是通过分区存放在不同的ComputeNode上，具有相同hash值的分区会存储在同一个Compute Node上。数据分区的副本会存储在其他不同的Compute Node上，以提供高可靠性。

高扩展性

玄武的两个重要特性设计保证了其高可扩展性：1）Compute Node和Buffer Node都是无状态的，他们可以根据业务负载需求进行任意的增减；2）玄武并不实际存储数据，而是将数据存到底层的盘古系统中，这样，当Compute Node和Buffer Node的数量进行改变时，并不需要进行实际的数据迁移工作。

★ 为计算而生的存储数据存储格式

传统关系型数据库一般采用行存储(Row-oriented Storage)加B-tree索引，优势在于其读取多列或所有列(SELECT *)场景下的性能，典型的例子如MySQL的InnoDB引擎。但是在读取单列、少数列并且行数很多的场景下，行存储会存在严重的读放大问题。

数据仓库系统一般采用列存储(Column-oriented Storage)，优势在于其单列或少数列查询场景下的性能、更高的压缩率(很多时候一个列的数据具有相似性，并且根据不同列的值类型可以采用不同的压缩算法)、列聚合计算(SUM, AVG, MAX, etc.)场景下的性能。但是如果用户想要读取整行的数据，列存储会带来大量的随机IO，影响系统性能。

为了发挥行存储和列存储各自的优势，同时避免两者的缺点，AnalyticDB设计并实现了全新的行列混存模式。如下图所示：