湖仓一体技术调研
湖仓一体技术调研
前期任务及分工如下：
前期三个人分别调研一个数据湖仓系统，完成云平台账号注册以及基本的环境配置。
Apache Hudi（杨桂淼）：https://hudi.apache.org/
Apache lceberg（王子曰）：https://iceberg.apache.org/
Delta Lake（王晓妍）：https://delta.io/
基本概念调研
大数据的4V特征：海量(Volume)、多样(Variety)、高速(Velocity)、价值(Value)
数据管理系统的演进过程：关系型数据库 -> 数据仓库 -> 数据湖 -> 数据湖仓
关系型数据库：RDBMS 以关系模型为基础，将数据组织在预定义关系的二维表（即关系）中，表由列（属性）和行（记录）构成。每行数据通常拥有一个唯一标识符（主键），用于区分不同的记录。关系模型的一个重要特性是逻辑数据结构（如表、视图、索引）与物理存储结构的分离，这使得数据库管理员可以在不影响逻辑数据访问的前提下管理物理存储。结构化查询语言（SQL）是RDBMS进行数据查询和操作的标准语言。
数据仓库：文献普遍将数据仓库定义为用于支持决策制定的、集成的、面向主题的、时变的数据集合，其核心是结构化数据、写时模式（Schema-on-Write）、ETL过程和OLAP能力，旨在为商业智能提供单一事实来源。
数据湖：数据湖被描述为能够以原始格式存储海量、多样化数据（包括结构化、半结构化和非结构化数据）的中央存储库，采用读时模式（Schema-on-Read），支持ELT过程，并为高级分析和机器学习提供数据基础 。
数据湖仓：湖仓一体被视为数据仓库和数据湖的融合，旨在结合两者的优点：数据湖的低成本、灵活性和开放格式，以及数据仓库的数据管理、事务能力和查询性能。其核心是通过在数据湖的开放文件格式（如Parquet）之上引入表格式（Table Format）层（如Hudi, Iceberg, Delta Lake），实现ACID事务、模式管理、数据版本控制等功能。
数据仓库 vs. 数据湖 vs. 湖仓一体
关系型数据库
核心功能: 主要用于在线交易处理 (OLTP)，比如你购物下的订单、银行的转账记录等。它的核心是保证数据的一致性、准确性。
关系型数据库的特点是结构化数据: 数据以二维表格（行和列）的形式存储，结构非常规整。预定义模式 (Schema-on-Write): 在写入数据之前，必须先定义好表的结构（比如字段名、数据类型）。
痛点是：无法处理非结构化数据: 无法存储和处理像视频、音频、图片、社交媒体帖子这类非结构化数据。分析能力弱: 为交易而生，进行大规模、复杂的查询和分析时，会严重影响正常业务的性能。
数据仓库
核心功能: 为了解决关系型数据库分析能力弱的问题而诞生，专注于在线分析处理 (OLAP) 和**商业智能 (BI)**。
数据仓库的特点是：结构化和已处理: 只存储经过清洗、转换后的结构化数据，可以直接用于报表和分析。面向主题: 数据从多个业务数据库中抽取（ETL过程：抽取、转换、加载），并按照业务主题（如销售、库存）进行组织。历史数据: 存储了大量的历史数据，用于趋势分析和预测。
痛点是：数据类型单一: 仍然无法很好地应对非结构化和半结构化数据。数据在进入数仓前，不符合要求的部分就被丢弃了，导致无法进行更原始、更全面的数据探索。灵活性差、成本高: ETL过程复杂且耗时。由于采用“预定义模式”，任何需求的变更都可能需要重新设计数据模型和ETL流程，非常僵化。存储和计算的成本也很高。
数据湖
核心功能: 为了解决数据仓库无法处理海量、多样化数据的痛点而出现。它的理念是“先存下所有东西，以后再想怎么用”。
数据湖的特点是存储一切: 可以存储任何类型的数据，包括结构化、半结构化和非结构化（如日志文件、JSON、视频、音频等）的原始数据。后定义模式 (Schema-on-Read): 在读取和分析数据时，才根据需求去定义数据的结构。原始、未经处理: 数据以其最原始的形式被加载进来，不做任何转换。低成本存储: 通常建立在HDFS等分布式文件系统上，存储成本非常低廉。
痛点是：缺乏事务支持: 不支持ACID事务，这使得在数据湖上进行更新、删除操作变得非常复杂且不可靠，难以保证数据的一致性。数据沼泽 (Data Swamp): 由于缺乏对数据质量的管控、元数据管理和治理，数据湖很容易变成一个无人能懂、无法使用的“数据沼泽”。
湖仓一体
数据湖仓（也常被称为“湖仓一体”）的出现，正是为了解决一个核心矛盾：我们既想要数据湖的灵活性和低成本，又想要数据仓库的强大分析性能和数据治理能力。
数据湖仓是一种新型的、开放的数据架构，将数据湖的低成本、灵活性与数据仓库的数据管理和分析功能相结合，旨在在同一个系统内实现对所有数据的BI和AI应用。
文献资料整理
论文：
- Lakehouse: A New Generation of Open Platforms that Unify Data Warehousing and Advanced Analytics：https://www.cidrdb.org/cidr2021/papers/cidr2021_paper17.pdfThe
- Data Lakehouse: Data Warehousing and More：https://arxiv.org/abs/2310.08697
- Analyzing and Comparing Lakehouse Storage Systems：https://www.cidrdb.org/cidr2023/papers/p92-jain.pdf
- Assessing the Lakehouse: Analysis, Requirements and Definition：https://www.ipvs.uni-stuttgart.de/departments/as/publications/schneijn/Assessing_the_Lakehouse_ICEIS2023.pdf
- Delta Lake: High-Performance ACID Table Storage over Cloud Object Stores：https://www.vldb.org/pvldb/vol13/p3411-armbrust.pdf
- Apache Hudi - The Data Lake Platform：https://hudi.apache.org/blog/2021/07/21/streaming-data-lake-platform/
开源文档与技术白皮书
- Delta Lake：https://docs.dremio.com/25.x/sonar/query-manage/data-formats/delta-lake/
- Hudi：https://hudi.apache.org/docs/quick-start-guide
- Data Warehouse vs. Data Lake vs. Data Lakehouse: An Overview of Three Cloud Data Storage Patterns：https://go2.striim.com/hubfs/striim_tech_brief_data_storage_overview.pdf
现有系统分析
湖仓一体架构与功能
目标与架构: 湖仓一体是一种全新的数据管理系统，它直接在低成本的数据湖存储之上，提供传统数据仓库的管理和性能特性，如ACID事务、数据版本控制、索引和查询优化 。其设计目标是融合数据湖的低成本、开放性和数据仓库的强大管理与优化能力 。
湖仓一体的核心特征
单一系统：消除了数据湖和数据仓库之间的数据移动和冗余，所有工作负载（BI、数据科学、ML）都可以在同一份数据副本上进行 。
事务性元数据管理：湖仓一体的关键实现是在对象存储之上构建一个事务性的元数据层 。这一层定义了哪些数据文件构成一个表的特定版本，从而实现了ACID事务、数据版本回溯（Time Travel）等高级管理功能 。
典型的分层架构
数据接入层 (Ingestion Layer) ：负责从各种数据源（如关系型数据库、NoSQL数据库、业务应用、流式数据源、文件等）采集数据并将其导入湖仓系统。此层支持批量导入和实时流式导入，常见工具包括Apache Kafka, Apache Flume, Spark Streaming以及各类数据库连接器和CDC工具。
存储层 (Storage Layer) ：通常采用可扩展、高持久且成本效益高的云对象存储服务（如AWS S3, Azure Blob Storage, Google Cloud Storage）或分布式文件系统（如HDFS）。数据在此层以开放文件格式（如Apache Parquet, Apache ORC, Apache Avro）存储，能够容纳结构化、半结构化和非结构化数据。
表格式层 (Table Format / Metadata Layer) ：这是湖仓一体架构的核心与灵魂，是其区别于传统数据湖的关键。表格式（如Apache Hudi, Apache Iceberg, Delta Lake）在数据湖的原始文件之上提供了一个抽象层，负责管理元数据，包括表结构（Schema）、事务日志、数据版本、分区信息以及文件统计信息等。它使得上层计算引擎可以将存储在对象存储中的文件集合视为具有事务特性和结构化定义的表。
查询与处理引擎层 (Query/Processing Engines) ：各种计算引擎（如Apache Spark, Presto, Trino, Apache Flink）和云数据服务（如AWS Athena, Google BigQuery, Snowflake）通过与表格式层交互来读取、处理和分析数据。这些引擎负责执行SQL查询、数据转换、机器学习任务等。
治理与目录层 (Governance & Catalog Layer) ：提供数据发现、访问控制、数据血缘追踪、数据质量监控和审计等功能。通常与元数据存储服务（如Hive Metastore, AWS Glue Data Catalog, Project Nessie）集成，以实现统一的元数据视图和治理策略。
核心功能
ACID事务：确保数据操作的原子性、一致性、隔离性和持久性，为并发读写提供数据一致性和可靠性保障，这是从数据仓库借鉴并应用于数据湖的关键特性。
模式管理 (Schema Management) ：包括模式强制（Schema Enforcement）和模式演进（Schema Evolution）。模式强制确保写入数据符合预定义结构，防止脏数据污染；模式演进则允许在不重写整个数据集的情况下修改表结构（如增删列、修改类型）以适应业务变化。
数据版本控制 (Data Versioning / Time Travel) ：记录数据的历史版本，允许用户查询表的过去某个时间点的状态、回滚到历史版本或重现实验结果。
索引与数据裁剪/跳过 (Indexing & Data Skipping/Pruning) ：利用文件/分区元数据统计信息（如最小/最大值）、Bloom过滤器、Z-Order等技术，在查询时跳过不相关的数据文件或分区，从而优化查询性能。
支持多样化数据与工作负载 ：能够处理结构化、半结构化和非结构化数据，并支持包括BI、SQL分析、数据科学、机器学习和流处理在内的多种工作负载。
计算存储分离 (Decoupled Compute and Storage) ：通常构建在云原生架构之上，允许计算资源和存储资源独立扩展，从而提供更好的灵活性和成本优化。
现有系统基本原理
Apache Hudi
Apache Hudi旨在为数据湖带来流式处理能力，特别是高效的记录级插入更新（Upsert）和删除操作。
可以将 Hudi 的整体架构理解为由三大核心支柱支撑：
- **优化的表格式 (Optimized Table Format)**：定义了数据在数据湖中如何组织和布局。这是所有功能的基础，确保了数据的可管理性和事务性。
- **丰富的表服务 (Table Services)**：在后台运行的、用于管理和优化数据表的各种自动化服务。它们是保证数据湖高性能和低成本的关键，如同数据仓库中的 DBA 工具集。
- **统一的分析视图 (Unified Analytics Views)**：为上层查询引擎（如 Spark, Presto, Flink, Hive 等）提供统一、高性能的数据读取视图。
它通过时间轴保证了事务性，通过文件组和文件切片实现了记录级别的更新，通过两种表类型 (CoW/MoR) 在读写性能间提供了灵活选择，通过高效索引解决了数据定位难题，并利用一系列自动化表服务保证了数据湖的长期健康和高性能。
Apache Iceberg
Apache Iceberg专注于提供一个开放、高性能的表格式，特别强调表结构演进的灵活性、分区管理的便捷性以及跨引擎的互操作性。
Delta Lake
Delta Lake最初由Databricks开发，现为Linux基金会项目，它通过在Apache Parquet文件之上构建一个事务日志层，为数据湖带来了ACID事务和可靠性。
与 Hudi 类似，Delta Lake也是一个构建在数据湖（如 S3, ADLS, GCS）之上的开源存储层，旨在为数据湖带来 ACID 事务、可靠性和高性能。
Delta Lake 的架构可以概括为两个层次：
- 数据文件层 (Data Files) ：存储在云存储或 HDFS 上的 Parquet 文件。这是数据的“身体”，包含了所有的实际数据。Delta Lake 默认使用 Parquet 格式，因为它具备高效的压缩和列式存储特性，非常适合分析查询。
- 事务日志层 (Transaction Log)：这是 Delta Lake 的“大脑和灵魂”，也是其架构的精髓所在。它是一个名为
_delta_log的子目录，与数据文件存放在一起。这个日志完整、有序地记录了对 Delta 表所做的每一次变更。
对比分析
| 特性 | Apache Hudi | Delta Lake | Apache Iceberg |
|---|---|---|---|
| 核心优势 | 高效记录级更新/删除 (索引), 近实时流 | 强事务 (日志), Spark 深度集成, 优化管理 | 高性能元数据, 引擎无关, 高级分区/模式演化 |
| 事务实现 | 时间线 (Timeline) | 事务日志 (Transaction Log) | 快照隔离 + 原子元数据更新 |
| 关键机制 | 索引 (Index) | 事务日志 (JSON/Parquet) | 分层元数据 (Manifest Lists/Manifests) |
| 增量处理 | 非常强大 (Incremental Query) | 支持 (Change Data Feed) | 支持 (Incremental Scans) |
| 表类型/视图 | Copy-on-Write / Merge-on-Read | 单一表格式 (类似 CoW，但优化机制丰富) | 单一表格式 (物理布局优化灵活) |
| 与引擎集成 | 支持 Spark, Flink, Presto, Hive 等 | 深度集成 Spark (原生 API) | 广泛支持 (Flink, Spark, Trino, Hive 等) |
| 分区演进 | 有限支持 | 有限支持 | 原生支持 (Partition Evolution) |
| 隐藏分区 | 无 | 无 | 支持 (Hidden Partitioning) |
| 时间旅行 | 支持 | 支持 | 支持 |
| 模式演化 | 支持 | 支持 | 支持更复杂的演化 (Sort Order Evolution) |
| 文件跳过优化 | 支持 | 支持 (Data Skipping + Z-Ordering) | 支持 (基于 Manifest 详细统计) |
| 典型适用场景 | CDC, 频繁更新, 近实时摄入 | Spark 生态湖仓, 强事务 ETL, Databricks 用户 | 超大规模, 多引擎访问, 灵活分区, 高性能元数据需求 |
| 主要推动者 | Uber | Databricks | Netflix, Tabular, Dremio 等 |