简介： 企业级云原生数据仓库AnalyticDB提出了升舱打算，旨在承当和帮忙金融、运营商、政务等行业构建下一代数据管理和剖析零碎，以应答一直增长的数据规模，业务数字化转型，和传统数仓替换降级需要。7月19日，“千仓万库，轻云直上——阿里云数据库升舱打算实战峰会”行将在线上召开。
作者 | 恒义起源 | 阿里开发者公众号背景说到升舱，咱们首先想到的是飞机经济舱降级到商务舱、头等舱。阿里云企业级云原生数据仓库AnalyticDB（以下简称ADB）[1]在帮忙以金融机构为主的行业数字化转型和传统数仓降级我的项目中，也援用了“升舱（仓）”这个概念。
长期以来，企业级数据仓库构建次要以Teradata、Oracle、DB2、Vertica、Greenplum等为主，这些零碎一方面性能齐备，稳固牢靠，另一方面老本高，局部有专用硬件限度，同时须要应答业务几何级数据量规模增长。以Hadoop生态为代表的的大数据系统次要解决了数据分析的大规模数据量问题，在性能齐备性，易用性和维护性上与这些传统数仓相比，还是有差距。所以大部分金融机构都是在保留已有MPP数仓外围业务的根底上，尝试部署Hadoop零碎用于翻新业务摸索，同时解决数据增长带来的老本问题。近年来，一方面国外涌现出了以AWS Redshift，Snowflake，Google BigQuery，Azure Synapse为代表的云原生数仓（公共云状态），有对传统数仓和Hadoop零碎线下状态的代替和反动之势。另一方面随着上述传统数仓大厂在国内技术市场投入的缩小，叠加政策等因素，同时金融、运营商等行业面临数据规模增长，数字化转型，和传统数仓降级需要，须要选型下一代数据管理和剖析零碎，另外因为国内外市场和政策的区别，我国金融、运营商、政务等行业的数仓构建，次要以混合云为主。在此背景下，企业级云原生数据仓库AnalyticDB提出了升舱打算，旨在承当和帮忙金融、运营商、政务等行业构建下一代数据管理和剖析零碎，以应答一直增长的数据规模，业务数字化转型，和传统数仓替换降级需要。7月19日，“千仓万库，轻云直上——阿里云数据库升舱打算实战峰会”行将在线上召开。产品介绍整体架构AnalyticDB PostgreSQL版（简称ADB）在开源Greenplum[2]和PostgreSQL[3]根底上进行自主研发，语法层面对两者放弃兼容，性能层面为开源Greenplum超集，同时兼容大部分Oracle、Teradata语法与性能，反对业务利用以尽可能少的革新工作量对已有数仓业务进行迁徙降级。其整体架构如下图：
图1 整体架构 ADB由协调节点和计算节点两大组件形成，协调节点负责全局事务管理，全局元数据存储，SQL解析，重写，优化，执行打算生成与调度，计算节点次要蕴含执行引擎和存储引擎，其中执行引擎既反对Greenplum/PostgreSQL功能强大的原生引擎，又反对数据分析场景性能优化的自研向量化引擎，多态化存储引擎则反对本地行存堆表、列存压缩表，和内部表，以及基于存储计算拆散架构下的云原生表。协调节点和计算节点通过双正本保障高可用，同时通过程度和垂直扩大提供计算和存储资源的线性扩容。ADB与阿里云生态系统高度集成，反对以OSS为备份存储介质的分布式一致性备份复原（包含全量和增量备份），同时反对通过DBS备份到NAS，HDFS等第三方存储介质。对于存储在OSS上的ORC，Parquet，JSON，CSV格局用户数据，和MaxCompute上的用户表和分区，反对并行高速并行导入加载到本地，或者通过列过滤、谓词下推间接对OSS上的数据进行数据湖剖析。在云原生架构状态下，云原生表则在计算节点本地则只有缓存数据（计算节点无状态化），全量数据存储在低成本的OSS上。应用场景与生态集成下面形容了ADB的整体架构和外部组件，传统数仓迁徙替换，或者构建下一代数据管理剖析零碎，除了要具备高可用易扩大的分布式系统架构和性能齐备性能出众的内核引擎外，还须要有凋谢的生态集成和管理工具配套。下图从数据同步，到数据加工，再到数据查问剖析，端到端形容了ADB在数据处理各个阶段的生态集成，配套工具和场景反对能力。
图2 应用场景与生态集成 1、数据同步阶段，数据通过实时写入或批量加载形式入库，造成ODS（Operational Data Model）层。典型的数据源包含：MySQL/SQL Server/PostgreSQL/Oracle等OLTP业务数据库，业务App产生的实时数据，在OSS/MaxCompute/Hadoop上的归档或原始数据，以及来自Kafka/Flink等的流式数据。ADB通过MVCC，两阶段提交(2PC)，和全局事务管理(GTM)机制提供分布式事务能力(默认隔离级别Read Committed)，同时在实时写入场景反对Upsert笼罩写(Insert on Conflict，性能等同于Oracle的Merge Into)，批量导入场景反对表面，文件，自定义程序输入等多种并行高速加载。2、数据加工阶段，在库中对ODS层数据进行加工，造成CDM（Common Data Model）和ADS（Application Data Service）层，典型操作包含INSERT INTO SELECT, CREATE TABLE AS等。3、数据查问分析阶段，按业务需要对库中数据进行查问剖析，或供上游零碎生产解决，典型的查问剖析场景包含交互式剖析，BI报表，数据类业务利用等。ADB既通过存储引擎索引排序等个性反对高并发低延时的多维度点查范畴查场景，也通过向量化执行引擎，CBO自适应优化器，列式存储反对大数据量多表关联聚合的简单剖析场景。产品状态与硬件平台ADB除了在公共云提供国内和国内站的SaaS服务外，也通过阿里云飞天企业版(ApsaraStack)和麻利版(DBStack)反对混合云输入，满足线下部署需要。与局部传统数仓须要专有硬件平台不同，ADB自身反对x86通用硬件部署，同时也反对Arm架构，以及国产化鲲鹏平台，海光处理器，麒麟零碎等。通用硬件和国产化平台的反对，也是金融等畛域数仓降级的重要参考因素。核心技术通过下面概括性的产品介绍，咱们对ADB的整体架构，应用场景与生态工具，产品状态与硬件平台反对有了根本理解。上面进一步深刻到其在“升舱”我的项目中的局部硬核技术，包含自研向量化执行引擎，多态化存储引擎，基于代价的自适应优化器，租户间不同实例和租户内不同负载的资源隔离，以及存储计算拆散状态的云原生架构。向量化执行引擎PostgreSQL在上世纪八十年代诞生时数仓剖析OLAP场景尚未呈现，其次要用于解决OLTP场景，执行引擎是Record-Oriented（Tuple-at-a-time）的火山模型，Greenplum在PostgreSQL根底上构建了MPP分布式数据库，在执行引擎层引入了Motion节点，使得集群中每个计算节点都能像单机PostgreSQL一样运行，共同完成由协调节点下发的SQL分布式执行打算，最终通过协调节点汇总返回查问后果，通过分布式并行执行大大晋升了单机PostgreSQL的性能瓶颈。但在每个计算节点执行引擎外部，仍然是PostgreSQL原生的Record-Oriented模型（即每个算子每次解决一条记录），该执行模型对与以点查或少数据量解决场景为主的TP场景没有问题，但对于以大数据量解决场景为主的OLAP场景，单条记录解决的开销较大，综合性能和效率较低。前期基于Postgres构建的数据分析系统，如Redshift，Vertica，Vectorwise（精确来说是基于Postgres的前身Ingres），都对PG原有执行引擎进行了替换革新，Redshift次要是基于Code Generation（JIT, Just-in-Time Compilation）和Vectorized Scan，Vectorwise则是纯正的向量化执行。PostgreSQL 11也反对了表达式的JIT[4]，用以减速SQL中的表达式解决。ADB在保留原生Greenplum/PostgreSQL引擎的同时，自研了Block-Oriented(Batch-at-a-time)向量化执行引擎，用于解决大数据量剖析场景。下图以两边关联后做聚合的简略SQL为例，做了两者比照。
图3 执行模型：Record-Oriented V.S. Block-Orientend 比照Record-Oriented通过getNext()接口每次获取和解决一条记录，Block-Orientend模式通过getNextBlock()接口每次获取一批记录，同时每个执行算子综合使用向量化(Vectorization)[5]和即时编译(JIT)[6]技术，对这一批记录执行雷同解决逻辑，从以下收益登程，取得更高效的资源应用，更快的执行性能：每次读取和应用雷同逻辑解决一批记录数据，能取得更高的CPU指令和数据缓存命中率[7]。从一次函数调用解决一条记录，到一次函数调用解决一批数据，同时JIT则间接防止了函数调用，总体函数调用次数和开销[8]缩小。内存的调配回收，也从每条记录的调配回收，到每批记录的调配和回收，整体缩小内存调配回收次数和碎片治理开销[9]。在按批处理模型下，代码实现能更好地以向量化形式实现，一方面有利于CPU进行数据预取，另一方面尽可能减少程序的条件跳转（来自if...else...，switch等分支判断）和无条件跳转（来自函数调用），让CPU取得更好的指令流水线执行[10]，缩小分支预测[11]失败，同时也有利于编译器生成SIMD[12]指令，进步执行效率。下图别离展现了ADB Vectorization在分组聚合SQL场景进行算Hash，桶寻址，求Sum步骤的列式向量化执行示例，和JIT在扫描过滤SQL场景进行表达式计算的示例。
图4 Vectorization与JIT实现示例 向量化按批读取和解决的行为，在本批次中让须要解决的数据和解决指令都驻留在CPU L1/L2 Cache中，在缓存命中状况下性能为从内存读取的10~30倍[13]，同时对该批次数据进行雷同指令的解决，也能让CPU更好的流水线执行，缩小CPU Hazards[14]。JIT代码生成针对表达式解决场景，则间接防止了解释执行模式下的函数高频函数调用（Function Calls）。多态化存储引擎PostgreSQL原生存储引擎为堆表（Heap Table）[15]，次要为OLTP场景，外围组件蕴含默认8KB为单位行级MVCC的数据页Page，缓存管理器Buffer Manager，和预写日志WAL，以及以Btree为主的索引。Greenplum基于PostgreSQL构建了分布式数据库，次要为OLAP场景，在存储层次要做了如下技术改造：1、协调节点新增全局元数据和全局事务状态治理，以反对分布式架构下在协调节点的事务管理，SQL解析和执行打算生成等须要读取元数据系统表的操作。2、新增分布式架构下表的程度散布机制（反对哈希，随机和复制散布策略，对业务层通明），以及节点外部垂直分区机制（反对范畴和列表分区，后续高版本PostgreSQL本身也减少了分区机制）。两者联合反对更大的数据规模和查问过滤效率。3、对行存堆表由默认页大小由8KB设置为32KB，以取得数据分析场景更好的扫描效率。4、新增列存压缩表，相比PostgreSQL原生的行存堆表，通过列裁剪和压缩，进一步晋升剖析场景的扫描效率。另外列存表的元组(Tuple) ID放弃与堆表统一为48位，能够间接适配PostgreSQL现有索引机制（包含Btree，Brin，GIN，GiST等）进行指定列值的索引扫描，减速点查场景。另外利用反对MVCC事务隔离机制的行存堆表作为列存的元数据辅助表，一来用于列存数据的寻址，二来引入Delete Bitmap通过标记删除的形式让列存在追加写的根底上反对了更新和删除，同时列存数据也间接有了MVCC和事务隔离能力。5、引入了PXF表面，用于拜访HDFS，Hive，MySQL，PostgreSQL等内部零碎。ADB在Greenplum根底上，对本地列存压缩表和行存堆表进行了进一步加强（包含列存排序合并，排序减速计算，MIN&MAX毛糙过滤，实时物化视图，主动Analyze/Vacuum/Merge，Upsert等），对表面则新增了对阿里云OSS和MaxCompute的并行导入及数据湖剖析能力，同时新增了云原生存储计算拆散表（云原生架构产品状态下反对），存储按需计费，灵便弹性扩缩，反对数据共享。下图为ADB多态化存储引擎概览。
图5 多态化存储引擎 上面就ADB在存储引擎层的局部自研能力做进一步技术探讨。稠密索引Min&Max Skip Index是ADB在Greenplum列存上新增的第一个自研个性，相似于PostgreSQL9.5开始反对的BRIN，简略来说为列存表相应列数据的每个存储块（如varblock）记录该存储块中所有数据的最小值（MIN）和最大值（MAX），扫描时将过滤条件与每个存储块的MIN和MAX比拟，过滤掉肯定不蕴含该过滤条件存储块。对于可能蕴含该过滤条件的存储块，则进行具体数据读取，解压，扫描，比拟，取得具体的匹配记录。目前支流列存均提供该项能力(如Redshift的Zone Maps[16]，ClickHouse的Skip Indexes[17])，这里不做过多开展。ADB除了记录了每个存储块的MIN&MAX，也记录了多个间断存储块总体的MIN&MAX，起到进一步疾速过滤的成果。排序合并排序是列存引擎的要害能力，支流列存在建表时都反对定义排序键（如Redshift的Compound Sort Key[18]和Interleaved Sort Key[19]，Snowflake的Clustering Key[20], ClickHouse的Order By[21]），反对手工或者后盾主动合并排序，以取得高效的扫描过滤。同时下面讲的MIN&MAX Skip Index必须要依附排序能力真正发挥作用（除非数据在写入时就人造有序），试想数据无序状况下每个存储块的最大值最小值范畴可能都蕴含过滤条件，比拟下来能Skip掉的数据块很少，也就相当于MIN&MAX Skip Index没有作用。ADB在列存排序能力上反对组合排序（对应上述Redshift的Compound Sort）和多维排序（对应上述Redshift的Interleaved Sort，目前Databricks的Delta Lake[22]也有该能力），两者的区别和应用场景能够参考Redshift的这篇Blog[23]，这里不做具体开展。通常新写进来的数据为无序状态，ADB针对组合排序反对后盾主动排序合并（多维排序可在ETL步骤中执行multisort1、让大部分数据处于有序状态（现实状态是所有数据都有序）2、缩小数据文件数量和有效数据（来自delete和update）在数据文件中的占比（现实状态是一个文件蕴含了所有无效且有序数据）3、让排序合并须要的资源开销（包含IO，CPU，MEM）最小化4、对前端业务负载影响（如锁，资源竞争等）最小化这块目前业界做的较好且有公开材料有Snowflake的Automatic Clustering[24]，和SingleStore的Background Merger[25]。前者引入的Overlap-Depth的概念来实现上述指标#1，#2，#3，后者的optimistic/pessimistic策略则兼顾了上述所有指标。ADB的具体实现为将列存数据分为Unsorted Region和Sorted Region两局部，后盾主动排序合并Worker负责将Unsorted Region中的数据排序合并成一个Sorted Region的一个文件。在Sorted Region外部又分为不同的Sorted Part，每个Sorted Part中的不同有序文件的MIN和MAX值没有重叠，在扫描时能够把整个Sorted Part当成一个有序文件来解决，进步扫描效率。为了进一步晋升Sorted Region内数据的扫描过滤效率，Sorted Region内不同Sorted Part中的文件会进行主动合并，以打消不同Sorted Part间的MIN&MAX重叠，成为一个新的Sorted Part。通过晚期上线后应用反馈，咱们认为Unsorted Region到Sorted Region的排序合并相比Sorted Region外部Sorted Parts间的合并优先级更高，所以别离定义了Fast Worker和Common Worker来辨别优先级地解决两种场景。同时整个排序过程不影响业务侧DML操作，这样也达成了上述的四个指标。整体排序合并如下图下半局部：
图6 排序合并 & 查问减速 上图展现的另外一个性能是基于有序数据的查问减速。数据有序，首先就是晋升了MIN&MAX Skip Index的有效性，让Scan在条件过滤时对文件的Skip和IO更精准。另外执行引擎自身就有Sort算子，用于辅助实现SQL中的OrderBy，Group Agg，Merge Join，和Distinct等算子，如果存储引擎数据自身就有序（或者大部分有序，因为在实时写入场景下Unsorted Region是常态化存在的），那么执行引擎在运行上述要求数据有序的算子时就能够利用这一点，缩小额定Sort开销，晋升整体性能。所以这里ADB的做法是将这些算子须要的Sort算子下推到Scan中（咱们叫做SortScan），让Scan吐给下层算子的数据有序。对于一张有数据一直实时写入的表，通常每个节点上的数据同时散布于Sorted Region（大部分）和Unsorted Region（小局部）中，SortScan的具体实现如上图，首先对Unsorted Region的数据进行疾速排序（如果表数据写入更新绝对低频，那么这部分工作通常是不须要的），而后和Sorted Region的数据一起进行归并排序，让吐出的数据整体有序，从而减速下层依赖排序的算子。另外，有序数据在执行引擎解决时自身就能带来很好的缓存命中率，从而晋升性能，如Hash表计算，间断有序数据在基数比拟低的状况下有较多反复，在Hash桶寻址时在一段间断数据范畴内总是雷同。主动排序合并是当列存引擎要同时反对批处理和实时处理的场景时不可或缺的能力，用来让其在读写性能间获得最佳均衡。实时物化视图如果说索引用来减速SQL数据扫描算子（Scan）的过滤能力(Index Scan)，那么物化视图则是用来减速整个查问SQL。PostgreSQL 10[26]和Greenplum 6.2[27]开始别离反对了物化视图，但性能和应用场景比拟无限，均须要手工全量刷新，并且不反对查问主动改写。实时物化视图，个别须要具备主动增量刷新，和主动查问改写能力，更高阶的还有后盾依据历史SQL执行状况，主动创立物化视图。支流数据管理系统如Oracle[28]，Redshift[29]，Snowflake[30]在主动增量刷新和查问改写能力上均有相应体现。ADB针对本地行存堆表也构建了实时物化视图性能，整体设计实现如下图：
图7 实时物化视图 工作流程分为如下步骤：1、视图创立：首先用户依据业务罕用查问SQL创立对应的用于减速的实时增量物化视图2、视图主动保护刷新：数据写入更新删除操作首先作用到User Table自身，同时生成对应的变更日志（包含新增数据和删除数据）同步到Delta Log，增量合并刷新则读取Delta Log，联合MV的具体定义，对每个反对的算子（包含过滤，投影，关联和汇集）利用增量合并刷新算法，更新物化视图内容。3、查问主动改写：以后执行SELECT查问SQL时，依据SQL自身和库中存在的物化视图定义，搜寻可用于改写的物化视图，实现改写，减速查问。若没有可用物化视图或者输出SQL不反对主动改写，仍然查问原表数据。ADB以后物化视图的实现为强统一模型，和索引一样，在减速查问性能的同时，会对写入性能有肯定影响，相似机制自身是业务在写入查问性能两者间的取舍。如果将来反对最终统一模型，则是在写入性能和查问实时性方面的取舍。Auto Analyze&VacuumPostgreSQL自身反对Auto Analyze[31]和Auto Vacuum[32]，前者用于统计信息的主动收集，后者用于表数据被更新删除后的空间主动回收再利用。Greenplum在将单机PostgreSQL革新成分布式架构的同时，并未对这两项性能进行分布式革新，前者引入了gp_auto_stats_mode[33]来代替，后者则要求DBA定期执行。gp_auto_stats_mode的机制是可设置以后表以后没有统计信息时，则在第一次写入数据完结时主动触发Analyze，或者每次写入更新的数据量达到肯定数量时主动触发Analyze。这个机制对应数仓批量导入和数据加工场景能够很好地工作，然而遇到实时写入更新场景则有问题。晚期ADB公共云线上在实时流式写入场景常常碰到的问题是表在第一次写入大量数据时执行了Analyze后就再也不执行了（on_no_stats设置），或者因为实时场景每次写入的数据量少，很少达到on_change设置下触发Analyze的条件（gp_autostats_on_change_threshold）。这两种状况带来的问题就是统计信息不准，导致执行打算不佳，查问性能低下（如该走Index Scan的走了Seq Scan，该走Redistribute Motion走了Broadcast Motion，该走Hash Join走了Nestloop Join等）。让DBA定期做Vacuum也不合乎云原生数据库的定位。基于此背景，ADB在分布式架构下减少了Auto Analyze和Auto Vacuum性能，可能在每张表的数据量变动达到设定阈值（为累积计算，不像gp_auto_stats一样要求在一次变更中达到）时主动触发Analyze和Vacuum。思考到该性能为通用能力，上线后咱们也将其代码奉献给了Greenplum开源社区。OSS表面阿里云OSS[34]是海量低成本对象存储，亦是数据管理系统构建数据湖剖析的最佳组合。ADB基于Postgres FDW[35]框架实现了分布式架构下的OSS FDW表面，与阿里云生态高度集成。该能力对应与Redshift的Spectrum[36]和Snowflake的External Table[37]。OSS表面整体场景和架构如下图。
图8 OSS表面 ADB存储引擎在本地行存堆表和本地列存压缩表的根底上新增OSS表面，反对OSS多种格局（ORC，Parquet，CSV等）数据并行高速加载到本地，或者不加载间接在线剖析，亦或者与本地表关联剖析（加载或剖析时OSS上的文件主动平均映射到对应计算节点解决），同时反对列存表对冷分区数据主动分层到OSS。为了减速在线剖析性能，反对表面Analyze统计信息收集，分区裁剪，同时对ORC，Parquet列式存储数据反对列裁剪和谓词下推。除了OSS表面，ADB也反对阿里云Max Compute表面进行数据批量加载。备份复原数据备份复原是金融等行业对企业级数仓数据能力的广泛要求。单机PostgreSQL能够通过pg_basebackup + WAL归档反对Continuous Archiving and Point-in-Time Recovery (PITR)[38], 或者通过pg_dump做表级逻辑备份。Greenplum在基于单机PostgreSQL做分布式架构革新后，并未提供对应集群级物理备份和PITR能力，集群级逻辑备份则通过gpbackup and gprestore[39]提供集群/表级的并行逻辑备份和复原。gpbackup运行期间零碎无奈建删表或改表构造，也不能对用户表做truncate等操作。晚期ADB基于此做定期实例级逻辑备份复原，公共云业务实例泛滥，每个客户的保护窗口不同，同时局部业务较难找到保护窗口，同时数据量越大，备份须要的工夫也越长。为此ADB对gpbackup做的更细粒度的锁优化，让备份期间对业务影响最小（不阻塞DDL等操作）。优化实质上是就义备份时局部表的一致性（如果遇到业务DDL的状况），但复原时仍然可手工解决，这样取舍的背景是认为复原是低频操作，但备份是每周甚至一周屡次的高频操作。逻辑备份复原所能提供的RPO是较低的，个别默认一周备份一次（最坏状况下RPO也就是一周）。为此ADB开发了分布式一致性物理增量备份和PITR复原，性能上达到单机PostgreSQL PITR的能力。整体设计实现如下图：
图9 物理备份复原 一句话讲明确就是每个节点（包含协调节点和计算节点）都定期做单机PostgreSQL的pg_basebackup + Continuous Archiving, 同时通过周期性的全局复原点确保复原时的分布式一致性。从这个层面讲PITR就是从原集群记录的一系列一致性复原点中选取一个进行复原，所以实践RPO是最初一次一致性复原点的工夫，复原点打点周期可设为分钟到小时级。为了让备份数据尽量小，ADB还实现了全量根底备份的差别备份能力，对应表中距离上次未变更的数据局部在本次根底备份中不反复备份。在备份数据存储介质层面，公共云为OSS，混合云则反对OSS，或者通过DBS[40]反对NAS和HDFS。自适应优化器PostgreSQL自带了基于代价估算的Planner优化器，其开销低性能好，对于TP场景和AP简略剖析场景十分高效。Greenplum在将PostgreSQL扩大成分布式架构的同时，也对Planner进行了相应革新，使其可能生成蕴含Motion节点的分布式执行打算。同时Greenplum又新增了ORCA优化器[41]，以应答CTE，多表关联，动静分区裁剪等简单剖析场景，当然个别状况下启动代价会比Planner高，同时在局部受限场景具备主动回退到Planner的能力。Planner和ORCA自身各有劣势且性能齐备，可能笼罩AP和TP全场景，所以ADB并没有像执行和存储引擎那样新增自研优化器，而是在SQL解析和重写阶段依据SQL自身主动抉择最优的优化器来生成执行打算，同时为Planner减少Plan Hint干涉能力，可在多数场景人工干预部分调整执行打算。整体逻辑如下图：
图10 自适应优化器 自适应优化器的行为可简略概括为：AP简单查问，启用ORCA优化器，在局部简单剖析场景能生成更优的执行打算；TP实时写入更新删除点查场景，以及AP简略查问剖析场景，走PostgreSQL自带的的通过分布式革新的Planner优化器，相比ORCA启动工夫短，对SQL整体RT影响小，同时具备HINT人工微调性能。多租户资源隔离多租户与资源隔离是云原生数仓的必备能力，ADB既反对租户间不同实例的资源隔离，也反对租户内不同负载的资源隔离。前者（管控能力）在公共云通过IaaS层不同ECS实现，混合云则通过容器和Cgroup机制实现，后者（内核能力）则基于Greenplum自带的ResourceQueue[42]，ResourceGroup[43]以及Diskquota[44]实现。下图以混合云麻利版DBStack为例，描述了多租户下多实例的部署状态，以及在实例外部通过ResourceGroup对不同业务工作负载的并发，CPU和内存应用配额示例，以提供不同负载间的资源隔离和共享，同时通过DiskQuota能够定义不同用户、不同Schema的存储容量应用配额，以更好地布局业务数据存储。
图11 多租户与资源隔离 ADB晚期版本次要依附ResourceQueue来管制不容用户的执行队列并发和CPU优先级，目前开始逐渐过渡到ResourceGroup，可提供更精细化和更高效的资源粒度管制。云原生架构降级Greenplum自身和Teradata，Vertica等传统线下部署的数仓一样，为经典的Shared-Nothing架构，最后云数仓AWS Redshift也是如此。这类架构具备高性能，性能齐备等长处，同时也反对线性扩容，但因为数据存储在本地，扩容时波及到大量数据迁徙，耗时较长，迁徙中的表个别业务侧须要读写期待。另外当不同业务部门部署多个集群实例确保资源隔离时，每个集群就是一个数据孤岛，当业务波及到雷同数据的应用时，须要在跨集群实例间进行同步和冗余。基于此需要和限度，云原生数仓Snowflake[45]率先推出了存储计算拆散架构，数据和元数据长久化存储由AWS S3和自建分布式KV零碎FoundationDB提供，计算资源由独立的Virtual Datawarehouse组成，彼此间资源隔离，同时通过共享的元数据和数据存储又疾速做到无冗余数据共享，因为本地节点无状态，计算资源自身能做到疾速弹性。随着Snowflake存储计算拆散架构的演进，Redshift也由Shared-Nothing演进到RA3存储计算拆散状态，而传统线下数仓Vertia也推出了Eon Mode[46]存储计算拆散状态。基于上述背景，ADB在公共云目前推出了基于存储计算拆散架构的Serverless模式[47]，整体架构如下图：
图12 云原生架构降级 基本思路是让计算节点无状态化，元数据逐渐抽出存储到按区域部署的高性能分布式易扩大KV零碎，数据存储到低成本OSS，通过本地缓存减速长久化在OSS上的数据IO。基于此架构，数据存储按需付费，灵便弹性扩缩容，和数据共享也就走进事实。ADB的云原生架构降级和数据共享之前已有文章分享和演示，这里不做进一步开展，感兴趣读者可查看：从托管到原生，MPP架构数据仓库的云原生实际实操宝典 | 如何借助实例间数据共享，破解数仓数据流转难题？[48]升舱流程除了下面介绍的产品能力和技术外，AnalyticDB的Upsert实时写入笼罩，存储过程，系统监控诊断等能力也是数仓替换降级中十分重要的能力。上面介绍下传统企业数仓到ADB的升舱流程，一张图表白如下：
图13 升舱流程 总体分为四步：1、对已有零碎和业务迁徙评估。阿里云提供了Adam迁徙评估适配工具，反对Oracle和Teradata到ADB的大部分DDL和SQL主动转换。2、业务利用按需革新适配，同步进行DDL和已有零碎数据到ADB的迁徙。DTS数据同步传输服务反对Orcale到ADB的实时同步，亦可通过疾速并行批量导入实现一次性迁徙。同时ADB自身基于Greenplum内核技术演进和云原生架构降级，第三方生态工具兼容性好。3、业务双跑验证。在此阶段可引入灰度机制，过渡到业务割接。4、业务实现割接到ADB。从升舱我的项目启动至今，ADB目前已在金融（银行，保险，证券），运营商，政务等行业有较多胜利案例和标杆，既包含对已有业务零碎中对Teradata，Oracle，DB2，Greenplum的替换降级，也有新业务的首次上线。总结本文从升舱背景，数仓技术演进，业务需要登程，首先介绍了阿里云云原生数据仓库AnalyticDB的整体架构，应用场景与生态集成，产品状态与硬件平台反对，而后逐个介绍了自研向量化执行引擎，多态化存储引擎，自适应优化器，多租户资源隔离和云原生架构降级等升舱中用到的核心技术。在自研技术层面，按单机PostgreSQL自身对应能力，Greenplum在PostgreSQL上革新后的对应能力，以及业界主流产品相干能力和技术，到AnalyticDB对应能力构建和具体技术设计实现路线进行技术解说。最初总结了具体升舱四步流程。心愿通过本文能让读者对ADB从产品架构和核心技术能有全面理解，同时可用于评估业务升舱可行性。参考链接：[1]https://www.aliyun.com/produc...[2]https://arxiv.org/pdf/2103.11...[3]https://www.postgresql.org/[4]https://www.postgresql.org/do...[5]https://www.youtube.com/watch...[6]https://www.youtube.com/watch...[7]https://medium.com/@tilakpati...[8]https://www.ibm.com/docs/en/x...[9]https://en.pingcap.com/blog/l...[10]https://www.geeksforgeeks.org...[11]https://www.geeksforgeeks.org...[12]http://ftp.cvut.cz/kernel/peo...[13]https://cvw.cac.cornell.edu/c...[14]https://www.geeksforgeeks.org...[15]https://www.interdb.jp/pg/pgs...[16]https://aws.amazon.com/cn/blo...[17]https://clickhouse.com/docs/e...[18]https://docs.aws.amazon.com/r...[19]https://docs.aws.amazon.com/r...[20]https://docs.snowflake.com/en...[21]https://clickhouse.com/docs/e...[22]https://docs.databricks.com/d...[23]https://aws.amazon.com/cn/blo...[24]https://docs.snowflake.com/en...[25]https://docs.singlestore.com/...[26]https://www.postgresql.org/do...[27]https://gpdb.docs.pivotal.io/...[28]https://oracle-base.com/artic...[29]https://docs.aws.amazon.com/r...[30]https://docs.snowflake.com/en...[31]https://www.postgresql.org/do...[32]https://www.postgresql.org/do...[33]https://docs.vmware.com/en/VM...[34]https://www.aliyun.com/produc...[35]https://www.postgresql.org/do...[36]https://docs.aws.amazon.com/r...[37]https://docs.snowflake.com/en...[38]https://www.postgresql.org/do...[39]https://docs.vmware.com/en/VM...[40]https://www.aliyun.com/produc...[41]https://15721.courses.cs.cmu....[42]https://gpdb.docs.pivotal.io/...[43]https://gpdb.docs.pivotal.io/...[44]https://github.com/greenplum-...[45]http://event.cwi.nl/lsde/pape...[46]https://www.vertica.com/wp-co...[47]https://help.aliyun.com/docum...[48]https://mp.weixin.qq.com/s/h1... 「阿里云数据库升舱打算实战峰会」 全网首发新一代云原生数仓解决方案，解构企业数智化转型新范式 7月19日，“千仓万库，轻云直上——阿里云数据库升舱打算实战峰会”行将在线上召开。本次峰会，咱们将从技术、实际、生态三大维度，与您一起深刻洞察企业级数据平台和数据仓库的倒退现状、最佳实际和将来趋势。峰会汇聚了包含申万宏源等在内的多位金融、运营商畛域知名企业首领、技术大咖、生态合作伙伴，共议企业数字化转型新范式。同时，会上将公布升舱打算最新版本，进一步开释云原生红利，让业务价值麻利化、在线化。
点击这里，查看详情。原文链接：http://click.aliyun.com/m/100...本文为阿里云原创内容，未经容许不得转载。