开发者学堂课程【云原生数据仓库 AnalyticDB PostgreSQL 产品入门：云原生数仓 ADB PG 产品和架构介绍视频（二）】学习笔记，与课程紧密联系，让用户快速学习知识。
课程地址：https://developer.aliyun.com/learning/course/1210/detail/18177
云原生数仓 ADB PG 产品和架构介绍视频
七、ADB PG 的核心能力
（1）ADB PG 执行引擎
通过介绍 ADB PG 的技术架构，模块组件、运行机制等，大家应该对 ADB PG 有了一个基本的认识。
然后接下来将去了解一下 ADB PG 的一个核心能力。首先向大家介绍一下 ADB PG 的执行引擎，ADB PG 搭载了自研的向量执行引擎，针对火山模型的缺点和现代硬件的特点，结合向量化计算，其实编译等技术专注于执行性能，特别是 olap 场景的场景的一个执行性能提升。 ADB PG 重点投入去做了一个向量化计算引擎，原生 PG 计算引擎它采用的是一个火山模型，就是说对每出来的一条数据会经过对应的算子数据计算。这样如果有一条数据对于每个算式来说，就要去执行1亿次计算子函数调用，而这一次1亿次的算子函数调用就会带来非常大的函数本身调用的开销。第二个问题是中间涉及到的一些表达式计算，这些表达式计算都会转异常对应的一个函数调用数，对于复杂的表达式就会变成复杂的一个函数函数调用数，这种调用数的每次迭代计算都会带来非常大的开销，也很可能会导致 CPU 的性能瓶颈，导致了整个计算过程非常大。这种场景对于TP场景来讲的话，因为数据量比较少，问题显现的不是很严重，对于AP 场景来说的话，对性能就有非常大的影响。
然后所以在三年前就开始了 ADB PG 的向量化计算的研发，消除了火山模型带来的一些包括碎片化的那种分配，然后采用了功能性的技术，把所有的表达式计算可以打平成一个算子函数来计算。同时在计算方面采用CPU的单指令多数据的计算，技术可以实现一条指令多数据的并行计算，对整体性能有非常大的提升。同时在整体引擎方面还采用了即时编译技术和内存管理优化，解决了高级语言抽象程度过高带来的性能开销以及重复的内容，申请和释放和碎片化的内存分配，
（2）ADB PG 存储引擎
ADB PG 存储引擎方面是基于 PG 实现的，不仅继承了 PG 存储引擎可扩可扩展，高可用事物强能力，还具备了以下几点特性。
第一点是支持多种表类型，存储引擎同时支持行存表和内存表，行程表则是用于高频数据的增仓改和点查的场景，列成表则适用于复杂的 AP 分析场景，可根据业务场景来灵活的选择表类型。
第二是知识丰富的索引类型。支持所有类型，在点长和低选择率场景采用索引可显著的提升，数据的检索性。
第三是支持数据压缩，这是多种的数据压缩算法，然后高压缩的高压缩率可显著的降低数据的重组成本，并可以通过高贷高带宽来解高带光解压缩性能来降低 iOS 时间。
第四是支持排序及粗糙级的过滤，建表的时候可以指定排序字段，数据通过排序以后，一方面可结合超级过滤降低l的数数据量，另外排序也将提升数据压缩率以及降低存储成本。
第五是支持数据分区，支持数据多几个分区，且可采用像 value 或者范围进行分区，常用的场景为按时间进行分析，然后可明显地降低 io 的数据量。同时分区支持混合存储。
第六是支持外表的 oss 存储数据可以远端的低成本的存储与 oss 上查询和写入行为与本地比较完全一致。
（3）Analytic DB Postgre SQL 性能-优化器
接下来讲一下 cascade 的框架的生活优化器，像传统的传统的单机数据库都是采用自下而上的优化器，它的好处是说它的效率是非常快的，但是它大同时也带来了很多问题，就是很容易去陷入一些局部的查询。但是对于 oled 场景，它的 circle 可能是非常复杂的，像有些项目一个 circle 可能就上造了，这种场景下如果遇到一个差的图形计划，可能就会带来灾难性的一个后果。所以 ADB PG 升级采用了 cascade 的框架的优化器，它的基本策略是这样的，说它是采用自己向下的一个方式，这种方式有一个好处就是不容易去陷入一个局部的最优解，可以非常容易的去找到全局的一个最优解，这样的话就可以保证用户无论写入什么样的复杂查询，我们都可以得到一个非常优质的执行计划，这样就可以大幅度的降低用户的使用难度，避免了由于一些复杂查询最新计划差，导致的一个系统资系统资源不足的一个问题。
同时在 cascade 的框架优化器的基础上，也增加了一些功能，就是说用户可以自定义一些规则，通过这些规则，可以进一步减少整个执行计划的搜索空间，既可以提升优化器的效率，也可以更容易的得到一个最优的执行计划。
八、Analytic DB Postgre SQL 成本
讲完优化器，我们看一下 ADB PG 在成本方面都是哪些特性, App 采用的计算节点，本机重组的模式，就是行存月存、非遗式存储、固态硬盘、机械硬盘等多种存储介质。在此基础上，ADB 还提供了重组压缩的能力，oss 的外表存储能力，而共享存储格式，存储分层等能力，满足用户在不同场景的一个需求。
(1) 存储压缩
首先我们看一下刚才提到的存储压缩方面，ADB PG 支持用户去指定压缩算法，然后除此之外，ADB PG还支持自动压缩 ADB PG 内核引擎可以根据数据特点去选择一种最合适的压缩算法，也来到来达到压缩比和计算性能的一个最佳平衡。然后在压缩和解压的过程中，我们用到了非常多的技术，像一些变形解压，还有一些性能指令加速，可以利用单指令多数据的方式去加速整个解压的过程。像常见的 LZ4 ZLIB , ADB PG 都是支持的。
(2)外表存储
接下来我们看一下 ADB PG 的外表存储，除内部存储外，ADB PG 还支持的外表方式去访问 oss 和 Hadoop 的存储数据，对象重组是阿里云推出的存储服务，具备数据量大、成本低、安全性高，能够满足多种场景的存储需求。
ADB PG 还支持通过外表的方式对 oss 重组服务进行访问，就是对 oss 数据进行分析操作，同时也支持数据导出到oss，目前支持的数据格式，包括 oss ODPS ，支持分区，同时支持部分的过滤下飞操作，然后此外支持通过外表的方式去访问。这个 Odps 也是 master computer 的数据。
九、Analytic DB Postgre SQL 的安全性
介绍完存储，接下来我们看一下 APP 的一些安全特性。网络和数据链路方面的话，ADB PG 既作为云原生分布式系统，拥有非常高的安全性，首先每个新建实力使用专有网络，也称为 vBC 是一种隔离的网络环境，安全性和性能均高于传统的经典网络。另外根据使用场景可选择是否公开公网地址，以减少潜在的安全风险。其实也支持只允许白名单上的 IP 列表或者 IP 段去访问。为了提高数据链路安全性，支持启用 SSL 加密提供且提供一些相关的证书给需要的应用服务，甚至是启用双向的任职证书来进一步提高安全等级。在用户方面，ADB PG 支持两种数据库，用户账号，高权限账号和普通账号，高权限账号拥有数据库的所有操作权限，普通账号拥有已授权数据库的所有操作权限，每个用户账号的密码都将使用 MD5 哈希算法来加密保存，也来保证一密码明文不会被泄露。权限体系方面，展示了 ADB PG 的一个对象级别的权限，包含了用户、数据库、Schema、函数、序列以及表的权限，对象级别的权限，根据每个对象的类型所赋予的权限都不一样。想代表 people 权限可以有 appe 的 slayer、嗯 slake、delete 等，而 function 就只有 IQ 的具体每个对象所对应的权限集合，还是请各位参考一下 PC 的官方文档。然后这里贴了一个链接，
SQL 审计就是用户通过做过的任何一些 SQL 查询，然后 ddldmdml 操作等这些操作我们都会记录下来，然后放在对应的一个插件功能上，用户可以通过 SQL 审计工具去查看各种操作的记录。
整个 SQL 审计是基于一个日志的形式，所以对系统的性能影响是非常小的。同时数据也是支持加密的，在公共云上是采用支持采用云盘的加密。
十、Analytic DB Postgre SQL 的扩展性
看一下 ADB PG 的一个在线扩容，ADB PG 拥有两种的水平扩展方式，一种是原地扩容，一种为迁移功能。
原地扩容就是在原有实力基础上增加计算节点，而这种方式通过一致性函询算法来用，所以扩充时挪动的数据量相对较少，然后扩容速度更快，而迁移扩容则是通过新建一个实例，然后将原有的实例数据迁移过去的方式来实现扩容，这种方式相对于原地扩容的成本比较高，但是这种方式更加灵活，可以实现跨 region 和跨可用区的扩容。然后下面这张图展示了一个原地扩容的一个基本思路，左边的话是原来有4个节点，然后现在增加了两个细节的新的节点，扩充任务发起之后，管控部位会首先执行一系列的步骤来准备购物环境，就比如创建机器的用户，打通新老机器的免密，刷新白名单，生成配置文件等，然后下发命令实例执行扩容。实际扩容主要包括三个步骤，第一个是 segment 初始化阶段，这一步是向集群中增加新的节点，主要包括初始化新节点与同步开的 logo，在这个阶段会短暂的去所开的 logo 表，以保持新旧数据的新旧的新旧节点的原数据一致，持久战过程中会锁住 logo，时长的话是与扩容的节点数是相关的，然后这一步操作完之后，新的计算资源就被加到了当前的实例中，之后创建的表的数据分布到所有节点上，但存量的数据仅分布在旧的节点中，然后就等待下一步的数据从分布。第二步就是从分布的阶段，此阶段会遍历所有的带扩容的表，然后对每张表执行重分布，之前从分部会对表加八级锁，直到双方部的完成，意味着在表从分布期间是不可读写的，但其他表是可以正常出现的。然后后来优化了这个过程，降降低了所有的级别，使得从分部期间是可读的。但在交换数据文件之前的话，会短暂的升级到8级锁。最后一个就是清理阶段，这个步骤主要是去清理扩容产生的临时文件，对实例是没有影响的，通常也不会失败的。
十一、Analytic DB Postgre SQL 的生态集成
介绍完 ADB PG 众多的核心能力，我们来看一下 ADB PG 的丰富的一个生态集成，ADB PG 是可以支持多数 Excel 工 具，像阿里云的 Data works 数据集成，开源的像 Kettle Informatica，这些都是支持的。 Bi 的一些数据可视化工具，Quickbi 和 Datav 等，这些都是可以实现无缝无缝的对接。同时可以与业界流行的流式处理系统，就这类系统，大数据类系统，传统的数仓以及数据库，数据库类的系统，都可以互通有无。
十二、Analytic DB Postgre SQL 的未来展望
最后我们看一下 ADBPG 的一个未来规划，然后本次介绍了云原生数仓 ADB PG 当前的一个基础架构，模块组件以及交互使用场景、产品形态以及性能、成本、扩展性、安全性、高级扩展等核心能力和生态工具集成。未来云原生数仓ADB PG 还会持续在原生架构和特性性能成本优化以及 hip 场景三个方向进行技术投入，不断打磨。在云原生层面，像存储计算分离架构演进，提供秒级的扩收容和按需的弹性弹性能力。同时在线热升级做到业务完全无感知。在性价比方层面，通过执行引擎，优化器和存储引擎的持续优化，打造极致性能。这是写入查询高通图低延时多并发，同时引入实时物化视图进行查询，结果及缓存等功能，做到特定层场景的定向优化，通过分层存储等功能持续降低使用成本。在 HTAP 层面，通过多副本查询扩展行业缓存，做到在线事务和分析一套系统。
