共计 5786 个字符，预计需要花费 15 分钟才能阅读完成。
简介：随着云计算的遍及和数据分析需要的扩充，数据湖 + 数据仓库的湖仓一体剖析能力成为下一代数据分析系统的外围能力。绝对于数据仓库，数据湖在老本、灵活性、多源数据分析等多方面，都有着非常明显的劣势。IDC 公布的十项 2021 年中国云计算市场趋势预测中，有三项和数据湖剖析无关。能够预感，跨系统集成能力、数据控制能力和更加全面的数据驱动能力，将会是将来数据分析系统重要的竞争畛域。
一. 背景
随着云计算的遍及和数据分析需要的扩充，数据湖 + 数据仓库的湖仓一体剖析能力成为下一代数据分析系统的外围能力。绝对于数据仓库，数据湖在老本、灵活性、多源数据分析等多方面，都有着非常明显的劣势。IDC 公布的十项 2021 年中国云计算市场趋势预测中，有三项和数据湖剖析无关。能够预感，跨系统集成能力、数据控制能力和更加全面的数据驱动能力，将会是将来数据分析系统重要的竞争畛域。
AnalyticDB PostgreSQL 版 (简称 ADB PG) 是阿里云数据库团队基于 PostgreSQL 内核 (简称 PG) 打造的一款云原生数据仓库产品。在 PB 级数据实时交互式剖析、HTAP、ETL、BI 报表生成等业务场景，ADB PG 都有着独特的技术劣势。作为一个数据仓库产品，ADB PG 是如何具备湖仓一体剖析能力呢？本文将会介绍 ADB PG 如何基于 PG 表面、打造数据湖剖析能力。
ADB PG 继承了 PG 的表面 (Foreign Table) 性能，目前 ADB PG 的湖仓一体能力次要是基于表面打造的。基于 PG 表面，ADB PG 能够对其余数据分析系统的数据进行查问和写入，在兼容多种数据源的同时，复用 ADB PG 原有的优化器和执行引擎劣势。ADB PG 的湖仓一体剖析能力目前曾经反对 OSS、MaxCompute、Hadoop、RDS PG、Oracle、RDS MySQL 等多种数据源的剖析或者写入。用户能够灵便地将 ADB PG 利用于数据存储、交互式剖析、ETL 等不同畛域，能够在单个实例中实现多种数据分析性能。即能够用 ADB PG 实现数据分析的外围流程，也能够作为泛滥环节中的一环去搭建数据链路。
不过，表面数据的剖析依赖于内部 SDK 和网络 IO 来实现数据读写，因为网络自身的个性与本地磁盘有微小差别，因而须要在技术层面与本地存储不同、须要不同的性能优化计划。本文以 OSS 表面数据读写为例，介绍 ADB PG 在构建湖仓一体剖析能力时，所遇到的一些重要问题和解决方案。
二. 问题剖析
ADB PG 内核能够分为优化器、执行引擎和存储引擎。表面数据分析能够复用 ADB PG 原有的优化器和执行引擎的外围局部，仅需大量批改。次要扩大是存储引擎层的革新，也就是通过表面接口对表面数据进行读写。表面数据是存储在另一个分布式系统当中，须要通过网络与 ADB PG 进行连贯，这是和读取本地文件的最外围的区别。一方面，不同的表面数据会提供不同的近程拜访接口，须要在工程上进行兼容，比方 OSS、MaxCompute 的数据读取接口都不雷同。另一方面，通过网络拜访近程机器上的数据有肯定的共性，比方网络的提早、网络放大、带宽限度、网络稳定性问题等。
本文将会围绕上述外围挑战，介绍 ADB PG 表面剖析我的项目在反对 OSS 数据分析过程中的一些重要技术点。OSS 是一种阿里云推出的一种低成本分布式存储系统，存储了大量的冷热数据，有较大的数据分析需要。为了不便开发者进行扩大，OSS 提供了基于 Java、Go、C/C++、Python 等支流开发语言的 SDK。ADB PG 采纳了 OSS C SDK 进行开发。目前 ADB PG 曾经完满反对 OSS 表面剖析的各项性能，除建表语句不同外，用户能够像拜访本地表一样拜访 OSS 表面。反对并发读取和写入，反对 CSV、ORC、Parquet 等常见数据格式。
三. 表面剖析技术优化
接下来，咱们介绍 ADB PG 在基于 OSS C SDK 开发 OSS 表面剖析过程中，解决的一些核心技术问题。
3.1 网络碎片申请问题
在剖析型数据库场景，业界普遍认为列式存储在 IO 性能上强于行式存储。因为列式存储在扫描数据时，只须要扫描特定列，而行式存储毕竟扫描全量数据，因而列式存储能够节约一些 IO 资源。然而在开发过程中，团队发现在一些场景下，如字段较多的大宽表扫描，扫描性能较高的列存格局居然比扫描 CSV 行存文本格式性能还要差。后通过定位发现一方面扫描 ORC/PARQUET 格局时，客户端与 OSS 服务端交互次数过于频繁，另一方面 ADB PG 单次向 OSS 申请的数据量比拟小。这两个起因带来了很大的性能问题。
咱们晓得，相比于本地磁盘 IO，网络 IO 所产生的往返时延往往能够放大几个量级。因而，如果解析一些列存格局（如 ORC/PARQUET）时，如果将网络申请当作本地磁盘申请解决，高压缩比所带来的网络带宽占用的缩小不足以对消碎片化申请带来的往返时延放大，因而性能测试后果低于预期。问题的解决方案，就是通过缓存来缩小碎片化的网络申请。ADB PG 每次扫描 OSS 数据都会“预加载”足够的数据并缓存，申请时，断定是否命中缓存，如果命中，则间接返回缓存；否则，持续下一轮次的“预加载”，从而升高网络申请次数，进步单次申请效率。“预加载”的缓存大小凋谢配置，默认大小为 1MB。
3.2 列过滤与谓词下推
因为网络自身的 IO 性能往往是低于本地存储的 IO 性能的，因而在扫描表面数据时，要尽量减少 IO 的带宽资源耗费。ADB PG 在解决 ORC、Parquet 格局的文件时，采纳了列过滤和谓词下推技术，来达到这一目标。
列过滤，即表面只申请 SQL 查问所需的数据列、疏忽不须要的数据列。因为 ORC、Parquet 都是列式存储格局，所以表面在发动网络申请时，只需申请所需列所在的数据范畴即可，从而大幅减小网络 I /O。同时，ORC、Parquet 会对列数据进行压缩解决，进一步减小 I /O。
谓词下推，是将执行打算里的下层的过滤条件(如 WHERE 子句中的条件)，挪动到上层的表面扫描节点，使表面扫描进行网络申请时，过滤掉不合乎查问条件的数据块，从而缩小网络 I /O。在 ORC/Parquet 格式文件中，会在每一个 block 头部保留该 block 中每一列数据的 min/max/sum 等统计信息，当表面扫描时，会先读取该 block 的头部统计信息，与下推的查问条件进行比拟，如果该列的统计信息不合乎查问条件，则能够间接跳过该列数据。
这里简略介绍 ORC 格局的表面的谓词下推的实现计划。一个 ORC 文件按数据行分成若干个 Stripe 组成，Stripe 中数据按列式存储。每个 Stripe 又分为若干个 Row Group, 所有列的每 10000 行 组成一个 Row Group。如下图所示。
ORC 文件保留 3 个档次的统计信息，文件级别与 Stripe 级别的统计信息存储在 ORC 文件开端，Row Group 级别的统计信息在每个 Stripe 块头部寄存。应用这 3 个档次的统计信息，ORC 表面能够实现文件级过滤，Stripe 级过滤以及 Row Group 级别过滤。具体做法是，每当扫描一个新的 ORC 文件，会先读取文件开端的文件级统计信息，若不合乎查问条件，则间接跳过整个文件的扫描；接着读取文件开端所有 Stripe 级别的统计信息，过滤掉不符合条件的 Stripe 块；对于每个符合条件的 Stripe 块，读取块头部的 Row Group 级别的统计信息，过滤掉不必要的数据。
3.3“996”问题
OSS C SDK 定义了一类错误代码，用于示意异常情况，这里的 996 是 OSS C SDK 中定义的错误码 -996。相似的还有错误码 -998、-995、-992 等。这一类谬误，通常都是网络异样导致的 OSS 表面导入导出失败。-996 是最为常见的一种。
OSS C SDK 外部应用 CURL 与 OSS 服务端进行网络交互，相应的 CURL 错误码，常见 CURL 56（Connection reset by peer）、52 等。这些网络异样，通常是因为 OSS 服务端在负载较高状况下，服务端被动剔除其认为“不沉闷”的客户端连贯所致。当须要导入或导出较大规模 OSS 数据时，因为客户端处于执行打算的不同阶段，不能长时间持有连贯进行间断通信，从而被 OSS 服务端当作“不沉闷”的客户端连贯而敞开。
通常对于这种状况，客户端须要尝试重试解决。理论开发过程中发现，即便客户端接口减少了主动异样重试机制，这种异样仍然得不到改善。后通过定位发现，OSS C SDK 为进步连贯效率，减少了 CURL 句柄的连接池，但这些网络异样的 CURL 句柄，也会寄存到池中，因而，即便重试，还是会应用异样的 CURL 句柄进行通信，所以 996 异样的问题得不到改善。
既然晓得了根本原因，解决的办法也很直观。咱们在 CURL 句柄的回收接口中，减少对 CURL 句柄状态查看，对于异样的 CURL 句柄进行销毁，而不是加回连接池中。这样防止了连接池中存在有效的 CURL 句柄。客户端接口重试时，抉择无效的或者创立新的 CURL 连贯再次通信即可。当然，主动异样重试机制只能针对那些能够重试解决的状况。
① ADB PG 拜访 OSS 表面时，先从 CURL 连接池中获取连贯，若不存在则新建。
② ADB PG 应用 CURL 连贯句柄与 OSS Server 申请通信。
③ OSS Server 通过 CURL 连贯句柄返回通信后果。
④ 失常返回的 CURL 连贯句柄应用结束后加回连接池待下次应用。
⑤ 异样状态的 CURL 连贯句柄销毁。
3.4 内存治理计划的兼容问题
ADB PG 基于 PostgreSQL 内核打造，也继承了 PostgreSQL 的内存管理机制。PostgreSQL 的内存治理采纳了过程平安的内存上下文 MemoryContext，而 OSS C SDK 是线程平安的内存上下文 APR Pool。在 MemoryContext 内存环境下，每个曾经调配的内存，都能够显式的调用 free 开释，由 MemoryContext 进行内存碎片的整顿，但在 APR Pool 中，咱们只看到内存池的创立、内存的申请和内存池的销毁等操作，却没有内存的显式开释接口。
这种状况意味着，咱们须要对于 OSS C SDK 接口所持有的内存的生命周期有明确的理解，否则极易呈现内存透露和拜访曾经开释的内存等问题。通常咱们会依照如下两种形式申请 APR Pool 的内存。
· 形式一实用于重入低频的操作接口，如获取 OSS 文件清单列表。
· 形式二实用于多次重入的操作接口，如周期性向 OSS 申请指定文件指定范畴的数据。
通过这种办法，能够很好地解决 ADB PG 与 OSS C SDK 在内存治理方面的不兼容问题。
3.5 数据格式的兼容和优化
OSS 上的数据，大部分采纳 CSV、ORC、Parquet 等格局。因为 ORC/Parquet 等格局对数据的底层存储编码，与 ADB PG 的数据编码并不统一，所以当进行表面扫描时，数据类型转换是必不可少的步骤。类型转换，实质上是将数据从一种编码，扭转成另一种编码方式。例如 ORC 对于 Decimal 类型的示意形式和 ADB PG 不雷同，在 ORC 中 Decimal64 类型由一个 int64 存放数据的数字值，再由 precision 和 scale 示意数字个数和小数点位数，而在 ADB PG 中, Decimal 类型由 int16 数组来存放数据的数字值。格局转换算法须要对每个数据进行循环的除法与取模操作，这是十分消耗 CPU 的。
为了缩小类型转换带来的 CPU 耗费，进一步优化表面查问性能，ADB PG 在应用表面进行导出数据时，跳过类型转换步骤，间接将 ADB PG 的数据，以二进制模式写入到表面文件中，这样在查问表面时，也无需进行任何数据类型转换。例如，在导出 ORC 表面时，表面能够将任意的数据类型，都间接写入为 ORC 的 Binary 类型，在 ORC 中存储的二进制数据，都是依照对应 ADB PG 的数据类型来编码，于是在查问该 ORC 表面时，能够间接省略类型转换步骤，缩小了 CPU 耗费。依据 TPCH 查问测试后果，整体查问性能能够晋升 15%-20% 左右。
四. 性能测试
对于在 ADB PG 中如何应用表面剖析性能，请参考阿里云产品手册（https://help.aliyun.com/document\_detail/164815.html?spm=a2c4g.11186623.6.602.78db2394eaa9rq）。除建表语句不同外，对表面的操作和对本地表的操作简直没有区别，学习难度很低。咱们在这里比照一下 OSS 表面剖析场景，与本地表剖析场景的性能问题。
环境配置。咱们测试采纳的机器是阿里云 ECS d1ne.4xlarge 机型，单机配置 16 个 Intel Xeon E5-2682v4 外围、64GB 内存，每台 ECS 配置 4 块 HDD 本地磁盘，每块盘读写速度约 200MB/s。测试一共用了 4 台 ECS，两台用于做 Master 节点、4 台用于做 Segment 节点，共部署 16 个 segment。本次测试应用的是 TPCH 查问，应用了官网工具生成的 1TB 数据集。
本地表咱们测试了通过压缩的列存表 (AOCS) 和 HEAP 表两种格局, OSS 表面咱们测试了 CSV、ORC、Parquet 和 JSON 四种格局。TPCH 22 条查问的总执行工夫见下表。从测试数据能够看出，两种本地表中，AOCS 表的查问性能略优于 HEAP 表。表面方面，CSV 格局、ORC 格局和 Parquet 格局的表面查问性略慢于本地表的查问性能，差距在 50% 左右。JSON 格局的表面查问性能显著慢于其余格局，这次要是因为 JSON 格局自身解析速度慢导致的，与表面无关。
下图是 TPCH 22 条查问的具体工夫。本地表与表面的性能差距在不同的查问上差距有所不同。思考到表面在存储老本、灵活性、扩大能力方面的劣势，ADB PG 表面剖析在利用场景的后劲是微小的。
五. 总结
湖仓一体是下一代数据仓库产品的一个重要能力，ADB PG 作为一款功能强大、扩展性强的数据仓库产品，基于 PG 表面开发了多种数据源的剖析和写入能力，并且积淀了很多性能优化技术。将来 ADB PG 将持续在产品性能、性价比、云原生能力、湖仓一体等方向持续发力，为用户提供更多的性能、性能和老本优化。
版权申明：本文内容由阿里云实名注册用户自发奉献，版权归原作者所有，阿里云开发者社区不领有其著作权，亦不承当相应法律责任。具体规定请查看《阿里云开发者社区用户服务协定》和《阿里云开发者社区知识产权爱护指引》。如果您发现本社区中有涉嫌剽窃的内容，填写侵权投诉表单进行举报，一经查实，本社区将立即删除涉嫌侵权内容。
