GaussDB(DWS)数据库-湖仓一体篇

数据

发布日期: 2025-08-04

更新日期: 2025-08-04

文章字数: 2.7k

阅读时长: 9 分

阅读次数:

湖仓一体

湖仓一体：lake house,其出发点是通过数据仓库和数据湖的打通和融合，让数据流动起来，减少重复建设。
lake house架构最重要的一点，是数据仓库和数据湖的数据/元数据无缝打通和自由流动。湖里的“显性价值”数据可以流到仓里，甚至可以直接被数据仓库使用；而仓里是“隐性价值”数据，也可以流到湖里，低成本长久保存，供未来的数据挖掘使用。

湖仓介绍

数据湖

数据湖理解
- 传统用户：以hadoop集群为主，满足支持所有结构化、半结构化、无结构化的数据存储即为数据湖
- 云厂商：基于对象存储，以S3、OSS、OBS等构建数据底座，进行统一存储。
- 大数据互联网：以数据湖三剑客为主（Iceberg、Hudi、Delta · lake）。它们可以支持比Hive更高层的Upsert、Delete、事务操作等高级特性，能基于Hive进行升级，解决准实时性的问题。
数据湖优势：
- 更好的Table format: 通过支持ACID事务，支持Schema evolution, 能够为用户提供更好的表格式。
- 更好的File format: 数据湖在文件格式上支持越来越多的半结构化map、Struct、Json等，并且支持越来越多的索引，进而使文件的查询和存储效率更高，并且在基于列存存储的基础上，支持更多的复杂嵌套结构。
- 更低的存储成本、更高的可靠性：使用对象存储，相比于本地磁盘存储、SSD存储或者云盘存储等，可以大幅降低存储成本，并且通过编码的方式能够在降低副本数据量的同时，又能保证高可靠性，可以使用户不用担心底层数据的丢失，从而获得低成本的存储。
- 统一的Catalog: 通过统一的catalog，实现统一的元数据管理、权限管理、统计信息管理、入湖管理等。
湖仓融合的价值：
- 数仓加速：基于数据湖的远程IO成本很高，而且缺少一系列数仓加速手段。早期的数据湖格式多样而且不成熟，索引支持不完善，查询性能有待提升。数据湖主要针对吞吐量的优化，关注低成本和高可靠，不适用于高性能的需求。
- 实时分析：传统的数据湖实时性不够，在Iceberg或者hudi的支持下可能解决分钟级别的时效性，无法解决秒级时效性的问题。
- 高并发查询：对于高并发查询，不管是点查询还是聚合类查询，数仓更加擅长。比如分桶的处理，更精细的裁剪，降低扫描的数据量，提升点查询的效率。另一方面通过物化视图或者cube等相关的预聚合手段，可以提升聚合查询的性能。
- 更完善数据治理：湖仓融合的数据底座，统一主数据和元数据，基于此才有可能做上层统一的数据治理
- 降本增效：简化技术架构、增强整体架构可靠性，降低运维成本。
支持数据格式：
- 文本类型：支持text、CSV，高性能导入导出，支持指定分隔符（delimiter）、换行符（eol）、编码（encoding）,以及多种容错方式处理、错误表等
- 列存存储格式：高性能列存存储格式，用于大数据环境中高效存储和查询数据，支持多种压缩算法、编码方式，并且兼容多种引擎。
- Parquet/ORC：融合查询，复杂类型查询，支持多种压缩算法，支持多种方式写出
- 湖格式：hudi是一个功能丰富的存储管理平台，支持构建具有增量数据管道的流式数据湖，针对处理引擎和常规批处理，进行优化；针对数据探索、BI场景的交互式分析能力，进行优化。支持COW、MOR的导入查询，以及增量同步导入。

湖格式（hudi）

hudi是一个功能丰富的存储管理平台，支持构建具有增量数据管道的流式数据湖，针对处理引擎和常规批处理，进行优化；针对数据探索、BI场景的交互式分析能力，进行优化。
关键能力：变更数据、实时性、数据事务、并发性、多版本能力、存储优化、表结构变更、数据管理、生态兼容。

存储结构：
- Metadata:以timeline时间线的形式维护对hudi表的各项操作。
- Data:使用两种存储格式存储数据
- ndex:在数据更新时提供更快的老记录查询性能。
表类型：COW和MOR
- COW(copy on write)：写入操作时进行复制，每次写入操作都会创建新的cow表，并将原表覆盖。COW表的主要优点是可以减少内存占用和提高写入性能，适合频繁进行写入操作的场景，列如批量更新、数据批量插入等。
  - 优点:减少内存占用：每次操作都会创建新的cow表，而不是修改原表，可以减少内存占用，提高性能。提高可扩展性，写优化的行存格式：默认为Avro格式，空间占用较小。
  - 缺点：需要内存管理：内存中管理原表和cow表之间的关系，因此需要额外的内存管理能力，需要进行内存管理和回收。数据写入性能较差，写优化的行存格式：默认为Avro格式。
- MOR(merge on read):读时合并，数据在写入的时候，为了尽可能保证写入速度，不同步做数据的合并操作（可以看做是异步合并），而是以append的方式，将数据写入到avro格式的日志文件中，在我们读取数据时，再启动合并策略。
  - 优点：写入性能高：适用于需要高性能写入的场景，如实时数据分析、流式数据处理等。在写入新数据时会将数据写入临时文件，后通过Compaction过程将临时文件合并到基础数据文件中，更新数据文件并删除旧版本。提高可扩展性，写优化的行存格式：默认为Avro格式。
  - 缺点：资源消耗：需要定期合并整理compact，否则碎片文件较多，数据写入性能较差。读取性能较差：需要将delta log和老数据文件合并，占用空间相对较大
外表查询：
- hudi外表查询：支持hudi两种表类型：COW(性能优化)、MOR(性能较差)；支持hudi两种查询视图：snapshot、incremental
- 增量查询：针对hudi增量查询功能，可以通过设置增量查询参数，实现增量查询。
- 增量设置的增量参数：通过查询视图来查看已经设置哪些参数，检查是否设置正确：select * from pg_show_custom_settings();
- 查询hudi外表属性：读取OBS上hudi数据的hoodie.properties
- 查询hudi外表最大时间线：读取OBS上hudi数据最大时间线，也就是最新的提交记录。
自动同步任务：
- 自动同步：
  - 单表同步任务，实现外表到内表的数据合并，记录增量同步进度。（列映射，hudi增量commit time同步点）
  - 智能调度框架，实现定时调用存储过程任务，并进行资源管控调度，提供任务启停、告警等运维能力。
- 同步任务流程：创建dws内表->创建dws外表->设置同步进度->提交hudi同步任务。
- 设置同步进度：select set_hudi_sync_state()
- 提交同步任务：select hudi_sync_task_submit()
- 查询同步状态：select * from hudi_show_sync_state()

元数据服务

元数据打通：

从湖仓两层架构到湖仓一体，统一元数据共享数据；统一元数据，简化数据共享。
- 湖仓两层架构：存算分离，底层数据文件可对上层服务共享。湖和仓的元数据隔离，共享数据仍需要ETL
- 湖仓一体（data lakehouse）:在存算分离的基础上，构建统一的元数据层。上层服务通过统一的元数据层，便捷高效地共享数据。
HiveMetaStore:
- 定义：Apache Hive的一个关键组件，一个元数据存储库，用于管理Hive/spark表的元数据信息。HiveMetaStore存储了hive表的结构信息，包括表名、列名、数据类型、分区信息和表的位置信息等。HiveMetaStore的主要作用是提供元数据服务，使得hive/spark可以对数据进行查询和分析。它还提供了一些API，可以让开发人员通过编程方式访问表的元数据。
- 总之，HiveMetaStore是Hive的一个重要组件，它提供了元数据管理和查询服务。
External schema:
- 定义：External schema即外部模式，dws通过创建extrenal schema来对接hivemetastore服务，每次查询主动获取hive/spark表对象的元数据，无需dws内核通过create foreign table获取hive/spark表的元数据。
- external schema和schema的区别：
  - external schema主要用于和hivemetastore建立连接，获取表对象元数据，在创建external schema时需要指定连接的所需要的各个属性值。
  - 普通schema在创建后会将schema的信息记录到pg_namespace中，external schema创建后和普通schema一样也会记录在pg_namespace，可以通过pg_namespace中的nsptype字段区分，是external schema还是普通schema。除了存储在pg_namespace中的相关信息外，external schema连接相关的配置信息，都会记录在pg_external_namespace中。
  - external schema下不支持创建表对象。对象的创建是在hive或者spark中创建的。external schema 仅用于执行DML操作。