AnalyticDB实现和特点浅析

本篇主要是根据AnalyticDB的论文，来讨论AnalyticDB出现的背景，各个模块的设计，一些特性的解析。可能还会在一些点上还会穿插一些与当前业界开源实现的比对，希望能够有一个更加深入的探讨。OK，那我们开始吧。

AnalyticDB介绍与背景

要说AnalyticDB，那起码得知道它是干什么的。这里直接贴下百度百科的介绍：

AnalyticDB是阿里云自主研发的一款实时分析数据库，可以毫秒级针对千亿级数据进行即时的多维分析透视。

简单地说，就是实时OLAP型数据库，它的对标产品是Apache Kylin，Apache Druid，Clickhouse这些。然后AnalyticDB的特点，包括高并发实时摄入数据，兼容Mysql协议，无需预计算即可有的极快响应时间，多种数据源接入，大规模集群管理等。好吧，这几个特点都很官方，不急，接下来会逐渐讨论各个点。

然后介绍下AnalyticDB的背景。

首先先说说传统的OLAP型数据仓库，以往构建OLAP型数据仓库通常都是采用离线模式，即在晚上设置定时任务将前一天的数据同步到数据仓库中，第二天数据分析师或报表工具就可以根据数据产出分析结果。但这样的问题是数据延迟太高了，商业瞬息万变，可能今天线上出现了什么订单激增的情况，数据分析师却要等明天才能进行分析，这谁受得了呀。所以近几年的趋势就是实时数仓，简单说就是增加一个实时接收数据以供查询的模块，这也叫做lambda架构。如图，就是用一个Batch层和一个Real-time层共同提供查询结果。¹

好像有点扯远了，说回AnalyticDB，它就是在大背景下提出的，所以它的一个主要特性就是实时。然后由于它本身是云原生的结构，也就是本身就是根植于阿里云上面的，面向的客户更加广泛，所以是有通用性的要求的。比如传统企业都是使用Mysql，Postgresql等关系型数据库，这些企业也没有人力去搭建和维护Hadoop和Kylin，Druid这些集群。而Postgresql这类关系型数据库可能会有对复杂结构对支持，比如json，vector等，所以AnalyticDB也提供了对这种复杂类型的支持。

在性能方面，AnalyticDB维持所有列的索引，用以快速检索数据。在存储方面，使用行-列混合存储，使得AnalyticDB可以同时对OLAP分析和行级查询快速响应。然后为了高并发的查询和高吞吐的写入，又提出了读，写分离。这几个性能方面的特性，以及这些优化如何与实时查询结合起来，在后面会详细介绍。

总而言之，目前业界对海量数据的OLAP分析查询方案无非两种，通过预计算构建多维立方体，在查询的时候直接读取预计算好的数据做一些简单的合并（因为分区存储）然后返回给用户。这种类型的代表是Kylin和Druid，它们的好处是比较简单，OLAP分析查询速度很快，缺点是不够灵活，比如Kylin一点改动可能就要全部数据rebuild。

另一种是非预计算，充分利用各种资源（CPU，内存，列存储，向量化执行），或是架构尽量优化（如AnalyticDB），来让海量数据快速查询得到结果。比较典型的代表是Clickhouse，查询性能不赖，也相对灵活，但缺点是集群数据量没法拓展到很大。

这两种方案都有办法这实时这个点上进行拓展，只是实现思路也不大一样。第一种是添加一个流式层，OLAP查询的时候分别查询历史数据和流式层数据然后合并返回。第二种则是用微批方式倒入数据仓库中实现流式查询。

整体上，AnalyticDB更加偏向于第二种非预计算的方式实现，不过在很多设计上还考虑了行级查询的实现和性能，所以要比Clickhouse这种要复杂一些。下面我们从几个方面来讨论它的实现。

AnalyticDB详细解析

AnalyticDB是一个能够在PB数据集上高并发，低延迟，实时分析查询，并且能够在2000+云服务器上运行的OLAP数据库。在设计上有多个挑战，需要兼顾多种查询类型的性能要求。这里的多种情境包括全表扫描分析，多表join的点查询操作，多个列的多个筛选条件等等，而这些操作又难以优化。

第二个挑战是要设计一个底层存储，应对不同类型的查询所需要的不同存储结构。比如OLAP查询需要列式存储，而点查询（行级查询）需要行式存储。如何将这两种存储结构（列式，行式）结合起来以供不同查询类型使用，同时还需要考虑到复杂类型，json，vector，text等，这也是一个难点。

第三个是实时方面的，要如何做到每秒数百万数据写入吞吐的同时，呈现给用户低延迟的查询响应和数据延迟。以前的做法将读写操作交