简介： 随着云计算的遍及和数据分析需要的扩充，数据湖+数据仓库的湖仓一体剖析能力成为下一代数据分析系统的外围能力。绝对于数据仓库，数据湖在老本、灵活性、多源数据分析等多方面，都有着非常明显的劣势。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将持续在产品性能、性价比、云原生能力、湖仓一体等方向持续发力，为用户提供更多的性能、性能和老本优化。
原文链接
本文为阿里云原创内容，未经容许不得转载。