营销型品牌网站建设价格,长沙网站排名优化报价,扬州新闻头条最新消息,wordpress 还是织梦简介#xff1a; 随着云计算的普及和数据分析需求的扩大#xff0c;数据湖数据仓库的湖仓一体分析能力成为下一代数据分析系统的核心能力。相对于数据仓库#xff0c;数据湖在成本、灵活性、多源数据分析等多方面#xff0c;都有着非常明显的优势。IDC发布的十项2021年中国…简介 随着云计算的普及和数据分析需求的扩大数据湖数据仓库的湖仓一体分析能力成为下一代数据分析系统的核心能力。相对于数据仓库数据湖在成本、灵活性、多源数据分析等多方面都有着非常明显的优势。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 56Connection 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?spma2c4g.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将继续在产品功能、性价比、云原生能力、湖仓一体等方向继续发力为用户提供更多的功能、性能和成本优化。
原文链接
本文为阿里云原创内容未经允许不得转载。
