摘要：在DTCC 2019大会上，阿里云智能数据库产品事业部研究员林亮做了题为《超大规模实时数仓架构挑战与实践解析》的演讲，数据分析领域目前正在朝着在线化方向演进，数据业务在海量数据实时写入、高并发分析、稳定性、灵活性上挑战巨大。分析型数据库AnalyticDB是阿里巴巴自主研发的超大规模PB级实时数据仓库，本次演讲深入分析了AnalyticDB海量数据毫秒级分析背后的架构挑战以及工程实践。
阿里云智能数据库产品事业部研究员林亮
专家简介：林亮(花名：意博)，阿里云智能数据库产品事业部研究员，曾就职Google十多年，在超大规模SQL Engine和规模存储引擎上经验丰富。目前在负责阿里云PB级分析型数据库AnalyticDB架构工作。
数据库发展
在数据库的发展历程中，最开始出现的就是RDBMS，出现了SQL技术与OLTP技术，传统的关系型数据库的主要应用主要是基本的日常事务处理。数据库的首要功能是能够准确记录商业活动中的各种交易包括订单、支付、物流等，这些记录当然需要保证万无一失，必须满足事务的ACID要求，这就是我们眼中的数据库(OLTP联机事务处理系统)的基本要求。当各种维度的历史数据累积起来，普通查询已经有压力了。商业分析师和销售团队要求非常精细化和具体分析，基本很难从业务数据库从直接获取出来。这时候通过从数据库提取数据、清洗、将数据以适合查询分析的方式放入数据仓库系统，也就是通常所说的ETL，之后在此基础之上进行OLAP。数据仓库支持复杂的分析操作，并且提供直观易懂的查询结果，为商业决策提供依据。
但是随着互联网业务的兴起，尤其是电子商务的爆发，数据库和数据仓库的在商业领域的界限正在变得模糊，数据仓库的实时化要求越来越高，对业务的实时评估，对库存的实时盘点，使得以前那种离线分析模式越来越不可行。于是，业界开始进行不断地尝试，比如Google Spanner这一类混合负载HTAP的NewSQL数据库试图解决日益增长的OLAP和OLTP两个不同维度需求。与此同时，我们看到数据库需求在非商业领域的快速增长。各种异构数据源的加入，包括图、时序、时空、向量等，使得数据产生速率更快，数据维度更高，数据量更大，实时处理(包括写入和分析)和吞吐量要求更高。
阿里巴巴——数据库
数据库技术的发展趋势也是近年来阿里巴巴在支持集团业务和云计算业务中发现的趋势。数据库是阿里云底层的核心架构，其支撑了阿里云顶层的所有服务，包括大文娱、优酷土豆、天猫、淘宝以及高德、饿了么等本地服务以及蚂蚁金融等场景，这些场景都在集团内部经过了多年的打磨，也在阿里云上有了一定的技术输出。在本次分享中将为大家介绍阿里巴巴数据库团队的技术积累和经验。
OLAP——OLTP
首先简单介绍一下几个数据库领域的基本概念。OLTP，也叫联机事务处理(Online Transaction Processing)，表示事务性非常高的系统，一般都是高可用的在线系统，以小的事务以及小的查询为主，评估其系统的时候，一般看其每秒执行的Transaction以及Execute SQL的数量。
随着数据量的不断增长，在1993年，学术界的E.F.Codd提出了OLAP概念，其认为OLTP已不能满足终端用户对数据库查询分析的需要，SQL对大型数据库进行的简单查询也不能满足终端用户分析的要求。用户的决策分析需要对关系数据库进行大量计算才能得到结果，而查询的结果并不能满足决策者提出的需求。因此，E.F.Codd提出了多维数据库和多维分析的概念，即OLAP。OLAP也叫联机分析处理(Online Analytical Processing)系统，就是我们说的数据仓库。在这样的系统中，语句的执行量不是考核标准，因为一条语句的执行时间可能会非常长，读取的数据也非常多。因此，OLAP能够更好地帮助商业分析师和销售人员来实现商业成长。
数据库发展——架构
数据库最初的发展阶段就是单机数据库，而在分析数据库的大规模并行处理 (MPP) 体系结构中，有两种主要方法： "Shared Nothing" 和 "Shared Everything"。在Shared Nothing中，每台服务器独立运行，并控制自己的内存和磁盘资源。数据在服务器之间进行分区， 并且工作负载是分布式的，以便每台计算机都在自己的数据上运行，而无需与网格中的其他计算机共享硬件资源。在Shared Everything环境中，所有服务器都访问相同的共享存储，并且每个工作负载都可以访问该存储，以及网格中所有服务器的计算资源。
虽然Shared Everything和Shared Nothing有各种各样的优点，但是也都各有不足之处。Shared Nothing的缺点是需要在节点之间复制共享数据，并在节点之间保持数据均匀分区，以实现一致的高性能。新的数据分片技术可以在没有用户干预的情况下自动重新分区数据，从而减轻了维护开销。目前这方面的技术在学术界已经产出了大量的论文，而在商业上也有了一些应用，其降低了用户整体的运维成本。由于对共享存储的争用，可能导致Shared Everything性能降低，而高性能分布式存储缓解了这一点。总之，每种架构都会存在自身的一些问题，但是随着时间的推移，这些问题也都在慢慢改善。
为需要满足不断变化的应用程序需求，在大多数情况下通过Scale Up (垂直缩放) 和/或Scale Out (水平缩放)来解决的。围绕云可伸缩性进行了许多研究和架构开发，这些研究和开发解决了云如何工作的许多方面，并为新兴的"云原生"应用程序构建了架构。
Scale Up通过向现有系统添加更多资源以达到所需的性能状态来完成扩展。例如，数据库需要为了满足SLA。可以将更多的计算、内存、存储或网络添加到该系统中，以将性能保持在所需的水平。在云中执行此操作后，应用程序通常会移动到功能更强大的实例，甚至可能迁移到其他主机并停用它所在的服务器。当然，这个过程对客户来说应该是透明的。Scale Out通过添加额外的节点。横向扩展使服务提供商可以轻松地提供"按需付费"的基础架构和服务。
数据库发展——核心技术组件
智能化数据库是数据库各大厂商以及学术界的近年来关注焦点，主要包含内核智能化和运维管控智能化两大方面。Oracle在2018年3月正式推出Oracle Autonomous Database。2018年1月Microsoft Azure SQL Database默认对其云上全部数据库开启自动优化服务(Automatic Tuning)。目前工业界传统数据库厂商Oracle，以及几大云厂商Amazon， Azure都在数据库智能化方向开始大力投入，并不断地推出数据库智能化产品或者功能。
如下图所示的就是阿里巴巴数据库的核心技术组件，最底层的是PaaS平台，PaaS平台提供了一些通用服务，包括弹性调度、资源管理、运维管控、计量计费、全链路监控、供应链关系等。下图中左右两边，在PaaS平台之上提供了数据产品和智能优化，数据产品包括了数据管理工具、ETL工具、数据备份以及数据传输等;而智能优化则包括了智能调参、负载预测、诊断调优以及测试标准等。下图的中间部分展现的是数据库内核本身的相关功能，包括了软硬件一体数据库、数据库内核以及多模态数据库三个部分。
随着新硬件的不断出现，需要借助新硬件来助力数据库的发展，包括了硬件加速、新型SSD以及NVRAM等。举例而言，前不久阿里云数据库首个跨入IOPS百万时代的云盘——ESSD，其单盘IOPS高达100万，比上一代SSD云盘最高测试数据快40倍，结合25GE网络和RDMA技术，ESSD拥有媲美本地SSD盘的性能，同时兼具云盘的99.9999999%可靠性设计，并且支持自动快照、数据加密等高级存储服务。正是通过这些软硬件一体化技术帮助我们设计数据库并获得更好的性能。
对于数据库内核而言，阿里的数据库团队也做了大量的工作，包括并行分析、分布式事务、复杂查询、近似计算、弹性伸缩、冷热分离、高可用、新型索引、计算存储分离、存储引擎以及内存数据库等。对于内存数据库而言，业界的主要代表有SAP HANA以及被Tableau收购的Hyper。内存数据库解决的一个核心问题是在去掉了I/O 瓶颈以后如何更好的实现HTAP (Hybird Transaction and Analytical Processing)。但是内存数据库的发展也受限于单节点物理内存的大小，以及如何确保Durability等问题。AWS的内存增强型实例已经可以支持到12T的内存，但任何内存数据库还是要有Durable Storage Media来确保数据的不丢失。
数据库发展——更高的应用诉求
随着数据库技术的发展，用户也有更高的应用诉求。用户的访问量逐渐增多;数据也在不断增长，目前云上实时数仓里面存储了超过100PB的数据，大型单库查询达到了上万QPS，单节点写入吞吐达到了1400万TPS，无论是从数据规模还是吞吐量都能看出，数据呈现爆炸式增长;同时，目前接入金融、新零售、政府等十多个行业，而各个行业具有自己对于实时数仓的不同需求，因此提出了更大的挑战;比较通用性的挑战包括更加实时性的要求，更多的维度以及越来越多的吞吐量，同时数据来源也越来越多，出现了各种异构的数据源，数据格式也各不相同。
数据库发展——技术挑战
以上的数据库诉求转化为了8个方面的技术挑战。
1)行列混合存储;OLTP适合于行存，OLAP适合于列存，而对于如今的实时数仓而言，需要同时提供高吞吐量和高性能，因此需要行列混存的存储结构，同时需要HTAP这种混合负载的支持。
2)混合资源调度;实时数仓不单只适合于复杂查询，也需要满足短查询能力，还有ETL，因此需要更好地协调内存、CPU、网络和磁盘等资源的调度，更好地提升网络带宽并降低延迟。
3)智能引擎;也就是比较热门的如何利用机器学习等自动化方式来帮助系统实现更好的优化。
4)增强分布式的查询引擎能力。
5)多模;DB-Engines在2019年3月，正式将多模定义为数据库基本熟悉，代表多模已经成为数据库产品标配属性。同时在最近2-3年里，在开源领域发布的数据库产品均主打多模能力，例如：Apple的FoundationDB，初创数据库公司YugaByteDB等。在多模能力下，可以为用户提供多样性的数据建模灵活度，同时还具备一致性的用户操作体验，极大的降低了用户开发成本，提高工程效率。在云计算领域，最具代表性的多模数据库产品是Azure CosmosDB，其提供了兼容MongoDB协议的“文档模型”，兼容Gremlin的“图模型”，兼容Cassandra CQL语言的“款表模型”;同时，AWS 也将DynamoDB重新定义为多模数据库，而不在是传统KV NoSQL。
6)更好地利用硬件实现加速。端到端加速才能发挥强计算力硬件的全部效能，随着NVIDIA收购Mellanox，新型高速集群(resource pooling)和完备的SDK将有望落地，届时所有海量数据能够在高速计算资源池完成全部复杂计算任务，数据可(解)读化和可视化已经在数据分析领域成为数据分析标配，特别是大规模可视化能够充分发挥GPU的大规模高速渲染能力。
7)数据库的弹性伸缩Scale Up和Scale Out。
8)云原生;CNCF给出了云原生应用的三大特征：容器化封装，以容器为基础，提高整体开发水平，形成代码和组件重用，简化云原生应用程序的维护。在容器中运行应用程序和进程，并作为应用程序部署的独立单元，实现高水平资源隔离。动态管理，通过集中式的编排调度系统来动态的管理和调度。面向微服务：明确服务间的依赖，互相解耦。
AnalyticDB整体架构
阿里云AnalyticDB采用分层解耦架构，同时将分析计算、数据写入、索引构建等分离为不同节点，同时各种类型节点采用多活运行模式实现高可用，数据存储在盘古分布式文件系统上，实现高可靠和高性能读写I/O，在整体架构上实现了弹性扩展和高可用。
AnalyticDB的整体架构可以分为三层：
前端接入层
多活的前端节点负责接收SQL请求，并解析生成执行计划，对于 INSERT语句，将数据发送给 Buffer Node写入缓存节点，对于查询语句，将查询任务分发给计算节点 Computing Node，完成数据分析，并汇总结果返回给客户端。AnalyticDB 的SQL解析器采用阿里自研的高性能SQL Parser “fastsql“，全面兼容MySQL的语法和函数，同时兼容MySQL的通信协议，支持JDBC客户端接入。SQL优化采用基于规则和代价的优化模式，支持分区减枝，CTE归并等SQL改写规则，同时基于统计信息，实现最优JOIN ORDER等分布式查询路径的优化。
弹性计算层
计算节点(Computing Node)：计算节点接收 FN 下发的执行计划，并行完成数据的分析处理任务。CN计算节点会从盘古读取数据，并将热数据缓存到本地SSD磁盘。计算节点内包括AnalyticDB的曦和分布式计算引擎和玄武存储引擎。曦和计算引擎支持各种SQL 算子操作，支持分布式并行执行框架。玄武存储引擎实现了自研的行列混合存储格式及多种索引技术，支持将绝大部分计算条件基于索引完成，从而提供极致的分析性能。
采用此读写分离架构，可隔离写入和分析计算负载。无论是计算节点还是写入节点，都可以根据负载和场景进行灵活配置和动态扩缩容，满足业务敏捷发展的需求和各种负载下的动态稳定性。
因为对于数据库而言，并不能只关注于整体架构，也需要关注一些小细节，这里为大家列举几个典型优化点的例子。
优化点1：执行调度
数据查询有复杂查询也有短查询，同时也有ETL这样的大规模数据处理。那么如何保证短查询能够尽量保证满足用户并且尽快返回，同时复杂查询能够正常运行完毕，不会因为短查询占用而导致“饥饿“状态。在数据库内核层面，AnalyticDB参考了Liunx的内核调度机制，数据库内核会记录每一个Query 的总执行耗时，Query总时间耗时又是通过每一个Task耗时来进行加权统计的，最终在Query层面形成了一颗红黑树。每次总是挑选最左侧节点的Driver进行调度(被Block的Driver不在这颗树上)，每次取出或者加入(被唤醒以及重新入队)都会重新更新这棵树，而在Driver被唤醒加入树的时候也会进行参数调整来处理极端情况，以此保证饥饿不会发生。
上图中左侧是在数据库内核层面利用线程实现更好地调度，但是数据库线程对应到物理机的内核上其实是不同的，因为大部分时候线程数会远高于数据库内核数。那么，在数据库里面，线程任务下发之后，内核层还是会有相对应的争抢。AnalyticDB对于数据库内核进行了一定的调整，通过引入内核层面的控制可以有效解决快查询低延迟的问题，且无需对算子的实现进行任何的改造。AnalyticDB让高优先级的线程来执行快查询的算子，低优先级的线程来执行慢查询的算子，因此通过高优先级线程抢占低优先级线程的机制，快查询算子自然会抢占慢查询的算子。这样一来就能够使得短查询和长查询能够分配到不同的优先级上进行执行。
同样的在实际应用中，很难要求用户来辨别快慢查询，这是因为用户的业务本身可能就没有快慢业务之分。虽然优化器能够提供代价模型的估算，但是不一定很准确。因此，在这之上也可以根据查询过程中算子的执行时间、调度次数等信息进行统计，当算子的计算量达到给定的慢查询的阈值后，系统会把算子从高优先级的线程转移到低优先级的线程中。
优化点2：内存管理
说完了CPU，再来看看内存。对于不同的查询而言，也会有不同的内存使用量，这一点在使用过程中也需要考虑到。
对于AnalyticDB的内存管理模型而言，引入了内存池。申请分配内存会产生很多大小不定的内存块，当频繁使用时会造成大量的内存碎片并进而降低性能。而内存池则是在真正使用内存之前，先申请分配一定数量的、大小相等的内存块留作备用。当有新的内存需求时，就从内存池中分出一部分内存块，若内存块不够再继续申请新的内存。这样做的一个显著优点是尽量避免了内存碎片，使得内存分配效率得到提升。这种内存池的设计目前在业界也是比较通用的方法。AnalyticDB在内存分配上就使用了内存池架构，此外还在此基础上对于快慢查询做了内存管理，能够保证用户的快查询能够获得尽可能多的资源，同时慢查询能够保证具有一定的内存分配。此外，使用内存池之后使得数据落盘变得更加方便了，不需要原来繁琐的序列化和反序列工作。
优化点3：自研优化器
AnalyticDB采用了自研的优化器，本身除了实现了RBO基本功能之外，也实现了一些优化工具，包括计划诊断、计划管理以及为用户提供使用建议等。此外，优化器使得计算和存储能够更加紧密地结合在一起，针对于存储性能和存储功能对于计划实现进一步改进。
优化点4：GPU引擎
当SQL从前端节点发送到计算节点，经过解析和逻辑计划生成以后，Task manager会根据计算的复杂程度选择由CPU引擎来处理还是由GPU引擎来处理，目前，AnalyticDB也正在逐步完善CPU框架，正在完善CPU和GPU的代价模型的建立，所以现在的判断规则相对简单。当选择GPU引擎之后，逻辑执行计划会在GPU引擎里面生成PTX代码并进行计算。
对于高并发显存管理而言，现在很多基于GPU的数据库其实是单查询占用了GPU所有的显存，而显存却是GPU上非常珍贵的资源，考虑到高并发场景以及数据分片，因此AnalyticDB提供了一套显存管理策略。此外，对于CPU-GPU堆外内存传输以及SSD到显存的直传也都是性能上的优化点。
下图的数据来自阿里云的一个客户，通过引入GPU之后能够看到使得查询性能有了3到10倍的提升，同时资源的消耗降低到原本的30%左右。众所周知，随着摩尔定律的失效，CPU的发展越来越缓慢，依靠CPU的计算性能去解决上述问题越来越难。相反，GPU的发展却非常迅猛，从计算核心数(P100多达3840个计算核心)、memory带宽到浮点计算能力，不仅相对CPU有很大优势，而且发展比CPU快。在人工智能领域，GPU是当之无愧的明星，其计算能力得到了充分的验证，也为我们提供了更多的可能性。
优化点5：自动化运维
智能化数据库内核和智能化数据库管控运维平台一定是下一代数据库系统核心竞争力的主力战场之一。随着数据库系统设计向精细化和复杂化演进，用户数据的不断增长和用户工作负载的多样化变化，传统的依赖于基本统计学原理和简单成本模型的数据库内核优化技术已经不能高效的适应于这些高维度的调优挑战。同时，随着上层业务逻辑和应用的复杂化以及应用规模的成倍增长，数据库实例数以及系统参数不断增长，数据库系统的运维管控和监控越来越需要智能化和自动化。
机器学习技术的迅猛发展为解决这两类问题提供了有力的武器，结合DBA的领域知识和经验，以及数据库系统的运行数据，通过进行有监督或无监督的学习和建模，机器学习/人工智能技术可以有效地实现智能化的数据库内核以及智能化的自治数据库运维平台。具体来说，在查询优化，系统参数调优，以及智能化系统运维等方向上，人工智能/机器学习技术和数据库系统都有很强的结合点。
优化点6：新硬件
下一代数据库设计的核心技术挑战中就包括了存储计算分离。对于新硬件而言，数据库系统可以利用新的存储媒介(NVM)和网络访问(RDMA)来实现分层存储和共享存储，利用异构硬件资源进行各种类型的计算加速(GPU， FPGA)。
数据库系统的研发一直是以系统硬件资源的特点为基础而出发去设计的，例如传统的查询优化器以优化IO为指标。那么，随着硬件资源性能特点的不断演进，数据库系统的设计和优化也要与时俱进。具体到存储技术来说， NVM提供了类DRAM的存储性能同时又能够确保数据的持久化存储(类SSD)，在DRAM和SSD之间又加入了一层存储媒介。数据库系统的数据冷热分离和分层存储会成为大趋势。类似LSM (Log Structured Merge) tree的存储结构会更大的发挥它的优势。
业界认可
在Forrester最新的云化数据仓库分析报告和同年Gartner发布的分析型数据管理平台报告中，阿里巴巴属于榜上为数不多的国内厂商。这体现了阿里巴巴多年来在打造DT商业过程中的大量数据分析技术积累。阿里巴巴的整套数据分析平台AnalyticDB作为分布式分析型数据库，更是承载了将数据探索实时化，在线化的关键任务。
标准测试——TPC-DS
阿里巴巴2019年在TPC-DS上发布了AnalyticDB的测试结果，目前在所有发布的厂商里位于第一名。TPC-DS属于相当困难的测试，其包括了多种查询，对于优化器以及查询性能具有较高要求，并且综合考虑了数据调入、单并发以及多并发等多方面能力，并且要求数据的高可靠性等。而AnalyticDB通过整个TPC-DS测试，证明了自身性能、稳定性以及可用性，通过结果可以看出，无论是从性价比还是查询性能上来看，AnalyticDB都要比其他厂商更好。
