摘要：如今，对于在线分析技术而言，正在从“Big Data”时代向着“Fast Data”时代迈进，所面对的技术和市场环境发生了巨大变化，与此同时也需要面对全新的挑战。在第十一届中国数据库技术大会（DTCC2020）上，阿里云数据库高级技术专家吉剑南为大家带来了在线分析进入Fast Data时代的个关键技术解读。
本文内容根据演讲录音以及PPT整理而成。
From“Big Data”to“Fast Data”
经过近几年的发展，在线分析所面临的技术挑战正在发生变化，甚至可以认为进入了下一个时代。前几年大家都有一个耳熟能详的名词，那就是“Big Data”。与此同时，在硅谷出现了很多在大数据领域很火的公司，如cloudera、hortonworks、MapR等，他们都是围绕Hadoop生态提供数据分析软件或者服务。如今，cloudera和hortonworks合并，并且市值一度暴跌40%；另外的一家则被收购，并且面临着转型的风险。与其形成形成鲜明对比的是，今年也出现了一家火出了技术圈的公司，它也可能是这些年唯一一个让股票分析师和数据库从业者同时产生巨大兴趣的上市公司，那就是Snowflake。Snowflake、AWS的Redshift和阿里云的ADB这些产品开始将数据分析带入到“Fast+Online”的时代。
围绕“Fast+Online”这两个关键词，在线分析开始有了不同于大数据时代常规的一些关键词，比如实时分析、实时数据、实时计算、云原生、弹性、在线工作负载等，这些就是过去几年的变化。
市场分析
市场趋势：数据规模爆炸性增长
接下来为大家介绍一些机构结合调研对于未来市场的判断。以下的数据来自于今年早些时候IDC和Gartner的一些调研数据。IDC预测2020年全球数据规模会达到40ZB左右，并且预测在2025年，数据规模将会相较于现在再增长430%，也就是每年都会有三位数的比例增长。结合现有存量数据来看，这样的增长速度还是非常恐怖的。
市场趋势：数据在加速上云
在数据存储上云的趋势来看，到2025年，数据存储的云上规模将达到49%，也就是将近一半的数据都将存储在云上。而数据的规模则会在更早的2023年，将近四分之三的数据库会部署在云上。
市场趋势：数据业务实时化占比大幅提高
不仅在数据规模层面，业务对分析新增实时数据的占比，将达到30%。使用实时数据的分析结果进行商业决策、报表制作等的新业务，也将在2022年提高到50%。
技术发展——OLAP技术演进
在阿里巴巴内部，最早的数据分析需求运行在Oracle RAC上。随着成本降低的诉求，以及分析型和事务型解耦，在2009年开始使用GreenPlum，而2009年前后基本上是淘宝发展最快速的阶段，数据分析的需求和体量不断增大，GreenPlum由于规模的问题，很快到达了瓶颈。2011年出现了两个技术方向，即以HBase为主的Hadoop生态和Kylin等，以及使用MySQL分库分表，通过数据库Sharding做数据分析。但是这两种方向都不太适合大数据的发展方向。在之后的2012年，阿里自研分布式数据库AnalyticDB正式服务集团，在此后的8年里，AnalyticDB以高性能、低成本、毫秒级响应高并发多维分析查询的优势，在集团内部维护了超过5万个节点，服务了上千个业务，几乎覆盖了阿里巴巴经济体几乎所有BU。到2019年，AnalyticDB-3.0以云原生、高并发、低延时，高达100PB在线数据分析体量成为阿里云上核心的分析型数据库产品。简单回顾阿里巴巴内部在线分析的发展历程，从商业单机到商业分布式，从商业走向开源，再从开源到自研。
AnalyticDB作为一个面向Fast Data时代的一个在线数据分析标杆型产品，在做自研的过程中也面临着很多技术挑战。
主要的挑战包括四个方面：
- 首先是高吞吐的实时写入，这是实时数仓的一个核心前置条件。数据只有能够快速的进入分析系统，实时才具备可行性。因此，可以认为高吞吐的实时写入是Fast Data的基础。
- 其次是在离线混合工作负载。企业数字化分析是多元化的，涵盖了实时的BI决策，实时报表、数据ETL、数据清洗以及AI分析。传统数仓方案是通过组合多套数据库与大数据产品，利用各自不同的优势来解决不通的分析场景，而带来的问题就是整个数据冗余，同时需要维护多个异构系统管理的代价。
- 第三是冷数据低成本、热数据高性能的一体化存储。在解决了一套系统同时支持在离线分析后，那么带来的核心问题是：如何既能够支持在线分析高性能，同时又可以支持冷数据的低成本存储。因此，动态的数据管理机制和灵活的缓存策略也将是一个很大的挑战。
- 最后是弹性可扩展。数仓中分析类查询对资源的灵活需求，由于业务变化而不断变化的数据体量，都对弹性这一云原生的核心特征提出了诉求。
典型的“Fast Data”架构
结合以上的挑战介绍典型的“Fast Data”架构。上图左侧是一个经典的数据库核心模块，FrontNode节点负责提供协议能力。同时，对于数据库和大数据一体化的系统，最广泛使用的MySQL和Spark API兼容是标准配置。再下面一层则是优化器，分析类查询的一个显著特征就是查询的复杂性远高于事务类查询，同时由于参与查询的数据规模很大，执行计划的好坏对于查询性能的影响往往是巨大的。因此一个成熟、稳定且高效的优化器是在线分析的核心，应该具备多样化的优化方式。再往下是计算引擎，良好的弹性和隔离能力是计算引擎需要具备的核心特征，在此之上，支持在离线混合复杂的离线计算模型再加上高效的计算引擎，最终构成了大规模进行数据分析的基础。最下面这层是存储层，存储服务化是存储与计算分离的前提，在存储服务化的基础之上设计一些高效的行列格式，再加上灵活的索引机制，通过高性能的本地ESSD和低成本的远端OSS，基于灵活的缓存机制，同时满足客户对于热数据的实时查询和冷数据的低成本维护诉求。
“Fast Data”关键技术
结合典型的Fast Data架构来介绍涉及到的关键技术：
- 首先是计算存储分离技术。通过解耦计算和存储，业务方可以自由选择资源配比，并按需扩缩容。
- 其次是弹性的资源组，针对有阶段性波峰波谷的负载特征，业务侧可以灵活调整资源配额，以不同的时间维度制定不同的资源组扩缩容计划，并且基于对查询负载资源需求的估计，按需进行资源组的选择。
- 第三是自适应优化，数据的实时性和体量巨大的历史数据会让传统依赖统计信息的优化手段失效，自适应优化在传统优化方式的基础之上会动态的根据执行信息中反馈的数据特征调整执行计划，使得整个执行计划达到高效状态。
- 第四是冷热分层和开放存储。一方面存储成本决定了数据规模和集群规模，将数据的维护成本降低在可控的范围内，业务才有机会通过数据分析寻找数据价值。另一方面对业界开源生态格式的兼容，让系统具备了一定的开放能力，不同的系统间可以通过开源的格式进行交互，降低业务ETL的复杂性。
计算存储分离
接下来将从更细节的角度来拆解每一项关键技术。首先是存储计算分离，存储层向上提供统一的数据接口服务，计算层可以独立弹性扩展，资源组在相互隔离的基础上，同时具备按照时段编排扩缩容计划和预留基础资源的功能。通过计算与存储的解耦，用户可以较为灵活地单独对计算资源、存储容量进行单独扩缩容，更加合理控制总成本。同时，针对计算资源的扩缩，不再需要数据的搬迁，具备更极致的弹性体验。数据冷热分层作为计算存储分离后，控制成本的核心技术，接下来将进一步展开介绍。
冷热混合存储
数据冷热分层存储并没有简单地通过缓存机制来实现，而是将冷热这个概念下放到了表级别，同时在表级别也支持冷热混合的方式。比如将数据表分为3类，即用户信息表、操作日志表、订单表，他们分别具备的特征是：用户信息在业务端是非常频繁使用的表，将其存储策略定义为hot；操作日志，较少用来做查询，更侧重于低成本的归档，定义为cold，存储在远端的OSS；订单表侧重于3天内数据会被频繁查询、3天前的主要进行数据归档，将其存储策略定义为mixed。与此同时，定义hot_partition_count为3。数据在最初写入时会作为热数据存放在SSD中。通过异步的合并机制，将其按分区的维度重新组织，当新的分区创建出来后，会有异步的线程根据hot_partition_count中定义的数量，将过期的数据迁移到远端存储OSS上，那么远端的数据查询将直接通过SSD的cache获取。通过这样的机制，实现了冷热分层、冷热策略的的轻松定义，冷热分区的自动迁移，以及冷热数据的一体化访问接口。
行列混存+多维索引
既然提供了一体化的存储接口，必然会涉及到多种查询场景，如数据库IDE工具中常见的查询一张表所有的明细数据，同时作为面向分析场景的数据库系统，列存在进行数据压缩，高效访问又有着非常大的优势，行列混存则可以兼顾两种诉求，典型的行列混存的格式如图所示。
将列的值以32768作为一个block，然后将不同列的block拼接为一个RowGroup。并将block级别的元数据信息存储到文件头，用于做快速过滤。除了列的元数据信息外，索引也是数据库系统中常见的加速手段，采取了多维索引的方式对组合查询条件进行过滤检索。针对于不同的数据类型，使用不同的索引格式，对于任何条件的组合查询，能够通过索引归并快速拿到目标数据集，然后目标数据集进一步走到计算层进行进一步计算，从而达到大幅度筛选候选集的目的。
弹性模式-资源组（池）多租户
在定义计算的弹性时，首先将计算的节点划分成资源组，一个集群可能拥有多个资源组，每个资源组具有不同的资源，资源之间是物理隔离的。并且资源组可以绑定用户，通过这种机制可以实现各个资源组之间的资源实现物理隔离，这样业务方就可以为不同的业务部门设定不同的用户，这样不同业务方之间的工作负载就不会相互影响，各个业务方可以自行制定自己的查询队列、响应时间以及并发数等，实现不同资源组之间的隔离。上图中的计算层划分了三个资源组，分别是用于在线分析的默认资源组，用于进行离线ETL，batch查询的弹性资源组，以及支持Spark任务的算法、迭代资源组。这三个资源组共享同一份数据，支持不同的工作负载。
业务申请一定的计算资源，然后将节点分配给不同的资源组。不同资源组的节点调整可以毫秒级完成分配，同时资源组可以绑定到固定的用户，这样业务侧通过给不同的部门分配不同的用户，就可以将整个集群按资源隔离出给多个部门使用。资源组内独占当前的物理资源，保证资源组间不会相互影响，同时资源组可以单独的配置同时的并发上线和查询队列以及监控，满足不同部门间对查询SLA的不同要求。并且通过这种方式实现了一份数据在多种场景下，包括离线计算、在线计算、再加上Spark运算等场景的整体支持。
弹性模式-分时弹性
资源组设定完成以后，就可以为不同的资源组指定不同的弹性计划。可以按照小时、天以及周制定分时计划。同时也支持按照多时段的分段弹性。如上图中例子所示，业务负载的高峰期在上午8点半到11点半，那么业务侧就可以指定一个小时级别的弹性计划，8点半扩容到256个节点，在11点半缩回64个节点。通过这样的机制，业务侧无需为一天剩余的21个小时而花费256个节点的维护费用。同时，存储的IO也是同步扩缩容的，不会产生额外的费用或者造成瓶颈。
在离线一体化——同时支持低延迟与高吞吐
典型的并行计算执行流程如上图中灰色部分所。对于在线分析而言，执行模型需要尽量降低数据在算子间传输的开销，这种场景比较合适的是使用并行Pipeline模型，数据在上游算子产生后，直接Push到下游算子所在的运行节点，无需落盘，直接进行计算，保证查询的高效性。对于离线分析来说，参与计算的数据规模往往较大，运行的查询往往非常复杂，如果使用Pipeline模型，可能会由于数据量过大导致内存溢出，同时复杂的查询往往会由于部分运行节点长尾或者硬件原因，需要局部重试，这时Stage By Stage模型则是最合适的。在这种模式下，资源不需要在一开始就分配完成，一个Stage执行完成，所产生的中间数据会落到磁盘中，下一个Stage再起来之后从磁盘中读取即可。因此支持在离线一体化的引擎，需要在一套执行引擎中同时兼顾两种场景，也就是MPP+BSP的混合执行模型。
高效的向量化执行引擎
执行引擎所所需要解决的事情和执行模型不太一样，其所需要解决的是算子之间传输的开销问题，也就是所谓的数据交互的代价，其主要包括了两个方面，分别是减少虚函数的调用和减小流程指令的开销。首先，向量化引擎利用了现代CPU流水线的机制，可以提升指令的并发集。其次，利用SIMD提升了数据并发，充分挖掘它的算力。当整个系统的并发提升完成之后，内存访问就会更内聚，同时也提升了操作系统Cache命中率。向量化引擎的一个特点是按照列或者一组数据来进行的，而数据库本身是以行的方式输出的，那么什么时候将执行中的列转化成行也是一个比较大的挑战。在阿里巴巴内部，借助优化器解决了这样的问题，即什么时间段对哪些数据进行列行转化。
自适应查询优化器
自适应查询优化器架构如图所示。图中白色部分可以认为是一个传统的基于规则的优化器，包括语法检查、语义解析、查询改写和转换、生成物理计划；图中绿色部分是引入了代价模型后，基于统计信息和代价估算，选择系统认为最优的执行计划，也是就CBO。其中包含物理计划的转换、统计信息推导、还有代价预估。CBO有一个核心要处理的问题，就是由于代价预估不准带来的计划回退，需要由深绿色的计划管理模块和全链路的hint来解决。最右边的蓝色部分是基于历史的运行信息面向用户或者DBA的一些建议，如统计信息、索引等。图中的左侧橙色部分就是自适应的一些优化目标，其中包括对执行计划的优化、工作负载的优化、系统资源的优化等。
接下来展开介绍自适应优化这部分。如图所示，按照自适应优化按照的生效场合，可以分为运行中和事后基于历史的两大类。图中蓝色部分是运行中的一些优化方式，首先是对计划的调整，比如对物理算子的选择，最常见的是HashJoin、SortMergeJoin或者IndexJoin。另外在分布式执行计划中最重要的就是如何进行数据分布，通过对小数据量的进行广播，避免Join的另外一边进行数据Reshuffle。还有就是不同任务计算节点的并发数，对小数据量进行分布式计算会带来额外的资源开销，针对数据倾斜的分片需要进行重新的Reshuffle。另外一个运行中优化的重要手段就是算子本身具备的自适应，在分布式计划中一个非常常见的优化手段就是Partial Aggregation，但并不是所有的聚合操作都在局部有一定的收敛性，自适应的局部聚合算子在处理了部分数据后，发现本身没有收敛性，可以快速放弃做局部聚合。此外，还有一个运行中的优化手段，就是DynamicFilterPushDown了，这个目前在很多计算引擎都具备，就不做过多展开。
除了运行时优化之外，另外一个优化方向就是基于历史的自学习，主要是对于业务工作负载的分析。对于业务工作负载中的重复性查询，可能每天都需要运行，并且基本不变，对于这种重复性负载而言可以进行一些计划的重优化，可以根据系统对于执行后的信息汇总对于执行计划进行调整。还可以构建分布式的CostModel，由于事前的CostModel可能并不准确，因此可以基于历史查询数据来进行校正。此外，也可以对重复的工作负载做进一步的优化，并向用户提供智能化的诊断手段，最终使得优化器更加聪明，进一步实现自适应、自学习的优化器。
最佳实践
AnalyticDB：快数据时代下的PB级实时数据仓库
阿里云AnalyticDB是面向PB级数据规模的数据仓库，能够提供毫秒、亚秒级别的查询体验，其采用MPP+DAG融合的分布式执行引擎，基于存储与计算分离的架构，能够支持千亿级别的多表关联分析，并且全面兼容MySQL和PG的生态，自身具有良好的生态。同时，AnalyticDB在云原生上具备快速的弹性能力，依托于阿里云底层的机制，存储可以从GB弹到PB，并且可以按需支持最高2000台级别的弹性能力，并具备备份、恢复、审计等完备的企业级特性。
以ADB的MySQL形态为例进行简单介绍数据从数据源进入ADB到最终产生价值的整体流程。数据最初可能分布在TB型数据库，也可能来自于Hadoop等集群产生的日志。而通过阿里云DTS等数据同步工具，或者Flink这种流计算引擎或者Kettle这种专门用于数据同步的工具，将数据写入到ADB MySQL中，通过数据管理工具对数据进行管理，最终的效果能够支持多样化的BI，比如Tableau、QlikView、帆软，也包括阿里的自研BI工具QuickBI等。
AnalyticDB是阿里云完全自研的系统，因此具备完全的知识产权。AnalyticDB目前获得TPC官方认可的TPC-DS性能世界第一。其次，AnalyticDB获得了中国信息通信研究院的官方认证，是参与评测的最大规模的集群。此外，还拥有国内专利46篇以及国际顶会论文9篇。