阿里云自研数据仓库 AnalyticDB 再捧 TPC 全球冠军

  5月14日，TPC 官网正式公布，阿里云自研的 AnalyticDB 通过了TPC-DS全流程测试，将前世界纪录的性能提升了29%，并把单位成本降低了三分之二，成功夺得全球数据仓库的桂冠。

  目前业界一致认为容器、物联网、数据库和数仓会是云计算未来四大增长技术。尤其是物联网将带来的30倍于目前互联网的流量，将会促使业界从传统的 Big Data 向 Fast Data 的演进历史。

  据最新预测数据，到 2025 年企业 50% 的数据是云存储，企业 75% 的数据库运行在云上。可以说一个性能强大的数仓产品，慢慢的变成了云服务商的必选项了。

  据Gartner最新数据，亚马逊、微软、阿里巴巴三家云计算巨头之间激战正酣。赢者通吃，是云计算市场真实的写照。相信本次AnalyticDB的表现，对于阿里云继续扩大市场占有率，有一些推动作用。

  数据仓库是由比尔恩门（Bill Inmon）教授在1990年提出，在概念提出伊始，基本功能是将通过联机事务处理(OLTP)所产生大量数据，透过数据仓库理论的资料储存架构，进行数据的分析整理，进而支持如决策支持系统(DSS)、主管资讯系统(EIS)的创建，帮助用户在快速有效的大量数据中，分析出有价值的资讯，以利决策拟定及快速回应外在环境变动，帮助建构商业智能(BI)。与传统的数据库相比数据仓库的不同之处有以下几点：

  1、数据仓库是面向主题。操作型数据库的数据组织面向事务处理任务，数据仓库中的数据是按照一定的主题域进行组织。主题是指用户使用数据仓库进行决策时所关心的重点方面，一个主题通常与多个操作型信息系统相关。

  2、数据仓库的数据是其它数据源抽取而来。数据仓库的数据有来自于分散的操作型数据，将所需数据从原来的数据中抽取出来，来加工与集成，统一与综合后才能进入数据仓库。数仓中的数据是在对原有分散的数据库数据抽取、清理的基础上经过系统加工、汇总和整理得到的，必须消除源数据中的不一致性，以保证数据仓库内的信息是关于整个企业的一致的全局信息。

  3、数据仓库是不可更新的。数据仓库的数据主要供企业决策分析之用，所涉及的数据操作主要是数据查询，一旦数据被修改，其实就涉嫌数据造假，一旦某个数据进入数据仓库以后，正常的情况下将被长期保留，也就是数据仓库中一般有大量的查询操作，修改和删除操作，通常只是定期的加载、刷新。

  TP数据库是面向事务处理的，所谓事务实际上的意思就是交易各个状态之间的迁移与记录，因此TP库各个业务系统之间各自分离。AP数仓中的则是按照一定的主题域进行组织的。主题是与TP数据库的面向应用相对应的，是一个抽象概念，是在较高层次上将企业信息系统中的数据综合、归类并做多元化的分析利用的抽象。每一个主题对应一个宏观的分析领域。可以说处理任务的不同是TP数据库与AP数仓之间的本质区别。

  在这个Fast Data的时代，谁的数仓能先跑出结果，谁就能掌握先机。比如目前笔者所在银行业的核心系统一般都用Oracle数据库，来进行交易处理（TP），完成整个流程性应用的内容，并产生应用数据数据。等交易结束了，数据的生命周期也结束了。要想把数据价值做二次表达，要每天做ETL，跑批作业，存到数据仓库中，然后在数据仓库中建模、挖掘、数据集市、ODS，一层一层地构建起数据仓库报表。

  这时可能一些更细节、隐含的问题，比如非线性问题还是回答不了，那么就要把数据复制到SAS中做机器学习，再做统计的指标体系，去做进一步的挖掘。数据要在这里搬动三次，复制三份冗余，还要管理数据一致性，每天数据中心运维的大量工作在做数据搬家。而所以分析处理（AP）操作结束往往都已经是T+1日的下午了，这样的效率是不足以满足云时代快速展示的竞争要求。

  因此云时代的数据中心急需要一款融合性的计算框架，AnalyticDB所带来的极致速度，堪称云时代计算框架的典范。在Forrester发布《The Forrester Wave: Cloud Data Warehouse》研究报告中，阿里云入选强劲表现者象限，位列中国厂商中的第一。

  在翻阅了AnalyticDB的论文（）之后，笔者ADB最大的亮点在于其基于 Raft 协议构建了一套分布式强一致高可靠的轻量级存储。ADB存储可实现高吞吐实时写入，在实时写入强一致可见、支持 ACID ，特别极致分析性能场景，在SQL 分析性能上有较大优势。AnalyticDB 存储整体架构如下：

  目前在一致性算法领域几乎是Paxos的天下，如阿里的金融级分布式数据库OceanBase是使用Paxos算法来保证节点一致性的，详见《》。本次ADB使用RAFT协议做为其自研存储的一致性算法，则给业界带来了一股清新的气息。

  一个最小化的Raft集群，典型节点数量是5个，这样的配置可以同时容忍两台服务器发生故障。服务器可能会处于如下三种角色：leader、candidate、follower，正常运行的情况下，会有一个leader，其他全为follower，follower只会响应leader和candidate的请求，客户端的请求则全部由leader处理，即使有客户端请求了一个follower也会将请求重定向到leader。candidate代表候选人，出现在选举leader阶段，选举成功后candidate将会成为新的leader。也许会出现的状态转换关系如下图：

  可以看到，在RAFT集群刚启动时，所有节点都是follower，之后在time out信号的驱使下，follower会转变成candidate去拉取选票，获得大多数选票后就会成为leader，这时候如果其他候选人发现了新的leader已经诞生，就会自动转变为follower；而如果另一个time out信号发出时，将会重新开始一次新的选举。

  不光是自研存储，ADB在高性能批量导入、高吞吐实时更新 DML、行列混存和智能索引等方面也有很多创新点，后续有机会笔者再详细向大家介绍。