数据仓库（Data Warehouse）是一个面向主题的、集成的、相对稳定的、且随时间变化的数据集合，用于支持管理决策。
 
主题是一个抽象的概念，是指用户使用数据仓库进行决策时所关心的重点方面，一个主题通常与多个操作型信息系统相关。
 
数据仓库中的数据是在对原有分散的数据库数据抽取、清理的基础上经过系统加工、汇总和整理得到的，必须消除源数据中的不一致性，以保证数据仓库内的信息是关于整个企业的一致的全局信息。
 
数据仓库的数据主要供企业决策分析之用，所涉及的数据操作主要是数据查询，一旦某个数据
 进入数据仓库以后，一般情况下将被长期保留，也就是数据仓库中一般有大量的查询操作，
 但修改和删除操作很少，通常只需要定期地加载、刷新。
 
数据仓库中的数据通常包含历史信息，系统记录了企业从过去某一时点（如开始应用数据仓库的时点）到目前的各个阶段的信息。
 
数据仓库反映历史变化的属性主要表现在：
     数据仓库中的数据时间期限要远远长于传统操作型数据系统中的数据时间期限，数据仓库中的数据时间期限往往为数年甚至几十年。
     数据仓库中的数据仅仅是一系列某一时刻（可能是传统操作型数据系统）生成的复杂的快照；
     数据仓库中一定会包含时间元素。
 
数据库与数据仓库的差异
    从数据存储的内容看，数据库只存放当前值，而数据仓库则存放历史值；数据库数据的目标是面向业务操作人员的，为业务处理人员提供数据处理的支持，而数据仓库则是面向中高层管理
 人员的，为其提供决策支持等。
 
 
数据仓库的结构
 从数据仓库的概念结构看，一般来说，数据仓库系统要包含数据源、数据准备区、数据仓库数据库、数据集市/知识挖掘库及各种管理工具和应用工具，如图 3-10 所示。数据仓库建立之后，首先要从数据源中抽取相关的数据到数据准备区，在数据准备区中经过净化处理后再加载到数据仓库数据库，最后根据用户的需求将数据导入数据集市和知识挖掘库中。当用户使用数据仓库时，可以利用包括 OLAP（On-Line Analysis Processing，联机分析处理）在内的多种数据仓库应用工具向数据集市/知识挖掘库或数据仓库进行决策查询分析或知识挖掘。数据仓库的创建、应用可以利用各种数据仓库管理工具辅助完成。
 
 
数据仓库框架由数据仓库基本功能层、数据仓库管理层和数据仓库环境支持层组成。
 
 
 
 
数据仓库基本功能层。
 
       数据仓库的基本功能层部分包含数据源、数据准备区、数据仓库结构、数据集市或知识挖掘库，以及存取和使用部分。
 
数据仓库管理层。
 
     数据仓库管理层由数据仓库的数据管理和数据仓库的元数据管理组成。
     数据仓库的数据管理层包含数据抽取、新数据需求与查询管理，数据加载、存储、刷新和更新系统，安全性与用户授权管理系统及数据归档、恢复及净化系统等四部分。
 
数据仓库的环境支持层。
 
      数据仓库的环境支持层由数据仓库数据传输层和数据仓库基础层组成。
  
 
数据仓库架构图：
 

 
元数据
 
元数据概述
元数据的分类
①管理元数据
②用户元数据
  
元数据的作用

 
元数据概述
 
元数据：描述其它数据的数据（data about other data）
 
元数据是关于数据的数据，在某些时候不特指某个单独的数据，可以理解为是一组用来描述数据的信息组/数据组，该信息组/数据组中的一切数据、信息，都描述/反映了某个数据的某方面特征，则该信息组/数据组可称为一个元数据。
 
元数据可以为数据说明其元素或属性（名称、大小、数据类型等），或其结构（长度、字段、数据列），或其相关数据（位于何处、如何联系、拥有者）。
 
在日常生活中，元数据无所不在。只要有一类事物，就可以定义一套元数据。
 
元数据的分类
 
①管理元数据
 
管理元数据主要为负责开发，维护数据仓库的人员使用。管理元数据时存储关于数据仓库系统技术细节的数据，是用于开发和管理数据仓库使用的数据。
 
②用户元数据
 
用户元数据从业务角度描述了数据仓库中的数据，它提供了介于使用者和实际系统之间的语义层，使得不懂计算机技术的业务人员也能够读懂数据仓库中的数据。
 
元数据的作用
 
①元数据是进行数据集成所必须的。
 ②元数据可以帮助最终用户理解数据仓库中的数据。
 ③元数据是保证数据质量的关键。
 ④元数据可以支持需求化。
 
参考资料 《数据仓库与数据挖掘实践》

 
目录
 
2. 数据仓库的主要特征
2.1 面向主题
2.2 集成性
2.3 非易失性（不可更新性）
2.4 时变性
  
 

 
2. 数据仓库的主要特征
 
数据仓库是面向主题的（Subject-Oriented）、集成的（Integrated）、非易失的（Non-Volatile）和时变的（Time-Variant）数据集合，用以支持管理决策。
 
2.1 面向主题
 
传统数据库中，最大的特点是面向应用进行数据的组织，各个业务系统可能是相互分离的。而数据仓库则是面向主题的。主题是一个抽象的概念，是较高层次上企业信息系统中的数据综合、归类并进行分析利用的抽象。 在逻辑意义上，它是对应企业中某一宏观分析领域所涉及的分析对象。
 操作型处理（传统数据）对数据的划分并不适用于决策分析。而基于主题组织的数据则不同，它们被划分为各自独立的领域，每个领域有各自的逻辑内涵但互不交叉，在抽象层次上对数据进行完整、一致和准确的描述。一些主题相关的数据通常分布在多个操作型系统中。
 
2.2 集成性
 
通过对分散、独立、异构的数据库数据进行抽取、清理、转换和汇总便得到了数据仓库的数据 ，这样保证了数据仓库内的数据关于整个企业的一致性。
 数据仓库中的综合数据不能从原有的数据库系统直接得到。因此在数据进入数据仓库之前，必然要经过统一与综合，这一步是数据仓库建设中最关键、最复杂的一步，所要完成的工作有：
 （1）要统一源数据中所有矛盾之处 ，如字段的同名异义、异名同义、单位不统一、字长不一致，等等。
 （2）进行数据综合和计算 。数据仓库中的数据综合工作可以再从原有数据库抽取数据时生成，但许多是在数据仓库内部生成的，即进入数据仓库以后进行综合生成的。
 下图说明一个保险公司综合数据的简单处理过程，其中数据仓库中与“保险”主题有关的数据来自于多个不同的操作型系统。这些系统内部数据的命名可能不同，数据格式也可能不同。把不同来源的数据存储到数据仓库之前，需要去除这些不一致。
 
 图：数据仓库的数据集成
 
“ETL，是英文Extract-Transform-Load的缩写，用来描述将数据从来源端经过抽取（extract）、转换（transform）、加载（load）至目的端的过程。ETL的质量问题具体表现为正确性、完整性、一致性、完备性、有效性、时效性和可获取性等几个特性。
 
2.3 非易失性（不可更新性）
 
操作型数据库主要服务于日常的业务操作，使得数据库需要不断地对数据实时更新，以便迅速获得当前最新数据，不至于影响正常的业务运作。在数据仓库中只要保存过去的业务数据，不需要每一笔业务都实时更新数据仓库，而是根据商业需要每隔一段时间把一批较新的数据导入数据仓库。
 数据仓库的数据反映的是一段相当长的时间内历史数据的内容 ，是不同时点的数据库快照的集合，以及基于这些快照进行统计、综合和重组的导出数据。
 数据非易失性主要是针对应用而言。数据仓库的用户对数据的操作大多是数据查询或比较复杂的挖掘，一旦数据进入数据仓库以后，一般情况下被较长时间保留。数据仓库中一般有大量的查询操作，但修改和删除操作很少 。因此，数据经加工和集成进入数据仓库后是极少更新的，通常只需要定期的加载和更新。
 
2.4 时变性
 
数据仓库包含各种粒度的历史数据。数据仓库中的数据可能与某个特定日期、星期、月份、季度或者年份有关。数据仓库的目的是通过分析企业过去一段时间业务的经营状况，挖掘其中隐藏的模式。 虽然数据仓库的用户不能修改数据，但并不是说数据仓库的数据是永远不变的。分析的结果只能反映过去的情况，当业务变化后，挖掘出的模式会失去时效性。因此数据仓库的数据需要更新，以适应决策的需要 。从这个角度讲，数据仓库建设是一个项目，更是一个过程。数仓仓库的数据虽时间的变化表现在以下几个方面。
 （1）数据仓库的数据时限一般要远远长于操作型数据的数据时限。
 （2）操作型系统存储的是当前数据，而数据仓库中的数据是历史数据。
 （3）数据仓库中的数据是按照时间顺序追加的，它们都带有时间属性。

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