共计 15041 个字符，预计需要花费 38 分钟才能阅读完成。
简介：企业级云原生数据仓库 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… 本文为阿里云原创内容，未经容许不得转载。
