Database
Lakehouse
一种新型的数据管理架构，它结合了数据湖（Data Lake）和数据仓库（Data Warehouse）的优点，为现代数据分析和管理提供了一个统一的平台。
Lakehouse 架构的关键特性？
- 单一存储层：
- 将所有类型的数据（结构化、半结构化、非结构化）存储在一个单一层中（通常是云存储）。
- 这种方式消除了数据在数据湖和数据仓库之间来回移动的需要。
- 支持事务：
- Lakehouse 支持类似数据库的事务性操作，例如 ACID（Atomicity, Consistency, Isolation, Durability），确保数据的一致性和可靠性。
- 灵活性和可扩展性：
- Lakehouse 能够存储各种不同格式的数据，同时具备数据湖的存储可扩展性，适合大规模数据处理。
- 治理与元数据管理：
- 提供良好的数据治理能力（例如访问控制、审计、安全性）和元数据支持，方便用户管理数据资产。
- 高性能计算：
- 引入了优化的查询引擎，可以快速处理大规模数据，满足实时数据分析的需求。
- 支持多种数据工作负载：
- 同时支持流式数据（Streaming）和批量数据（Batch）处理，满足数据科学、机器学习、商业智能等不同场景的需要。
对比 Lakehouse、数据湖和数据仓库？
| 特性 | 数据湖 | 数据仓库 | Lakehouse |
|---|---|---|---|
| 数据类型 | 结构化、半结构化、非结构化 | 主要是结构化数据 | 结构化及非结构化数据 |
| 存储/计算分离 | 是 | 部分支持 | 是 |
| 成本 | 成本相对较低 | 成本较高 | 成本适中 |
| 查询性能 | 较差 | 很高 | 较高 |
| 数据治理 | 较差 | 很好 | 很好 |
| 扩展性 | 高 | 中等 | 高 |
什么是 Open Format？
Open Format 指的是一种开放的数据存储格式，具有以下特点：它不依赖于特定的供应商或专有技术，能够在不同的数据平台、工具和系统之间实现互操作性和兼容性。常见的 Open Format 示例包括 Paimon、Apache Parquet、Apache ORC 和 Avro，这些格式通常被广泛用于支持现代的数据架构，例如数据湖和 Lakehouse。作为开放标准，Open Format 需要保证标准化、平台无关、易于扩展和高性能等特性。
| 格式 / 特性 | Apache Paimon | Apache Parquet | Apache ORC | Avro |
|---|---|---|---|---|
| 存储方式 | 表格式 （基于文件存储 + 索引） | 列式文件存储 | 列式文件存储 | 行式文件存储 |
| 主要应用场景 | 流批一体、实时数据湖/数仓，ACID 表管理 | 大数据离线分析、OLAP、云数仓 | Hive/Spark OLAP 场景 | 分布式消息、跨服务数据交换 |
| ACID 事务 / 更新能力 | 原生支持 | 无（需第三方表格式或管理层） | 无（需第三方表格式或管理层） | 无（主要是行级序列化） |
| 实时/流式数据支持 | 原生支持，对 Flink 有深度优化 | 不直接支持，需要额外框架封装 | 不直接支持，需要额外框架封装 | 常用于消息流，但无列式存储优势 |
| 生态与兼容性 | 成熟度上升中，与 Flink 紧密结合 | 非常成熟，Spark/Hive/Presto 等均支持 | 主要在 Hadoop/Hive/Tez/Spark 等生态 | 与 Kafka/Schema Registry 兼容性佳 |
| 适用数据规模 | TB ~ PB 级，实时 & 离线融合 | TB ~ PB 级，主要面向批处理 | TB ~ PB 级，主要面向批处理 | MB ~ GB 级，消息或中小规模数据 |
| 谓词下推 / 索引 | 内置索引机制，支持高并发写入 | 支持列级统计与谓词下推 | 强大的谓词下推与统计信息 | 无列式谓词下推 |
AI Agent 怎么利用 Lakehouse 里面的数据？
通用做法是多模态数据放到 OSS，结构化数据放数仓。但就链路细节上而言目前还不是很成熟。
- 对非结构化数据的量的占比较大，甚至达到 80% 以上。
- 目前观察到的是对大量元数据实时的请求、解析受到挑战。探索方向仍处于聚合、预聚合和如何利用缓存。
- 如何高效检索非结构化数据。
Paimon + LogSystem 时数据新鲜度分析？
分钟级新鲜度。秒级新鲜度可选择 Kafka + 流存储。
Paimon 在流式更新的同时，仍然保证数据一致性。由于实时不断写入小文件不可避免。Paimon 提供了小文件合并（Compaction）功能，用于周期性合并文件，避免数据查询时过多文件带来的延迟。在实际生产环境中，一般会设定一个合并周期（例如几分钟或更长），在保证最新数据能被快速查询的同时，又兼顾查询性能。如果要求极致的实时性，可适当缩短合并周期，但要平衡对写入性能和资源消耗的影响。
湖仓常见的数据分层方式？
- ODS（Operational Data Store） / 原始层
- 存放原始数据，通常与源系统保持一致或仅做简单的去重、清洗。
- 特点：保持冗余和完整，保证数据的新鲜度，方便后续处理时“回溯”。
- DWD（Data Warehouse Detail） / 明细层
- 在原始数据的基础上进行标准化、去重、关联、补充字段等处理，主要保持“明细级”的完整信息。
- 特点：数据质量更高，表结构优化，适合详细分析或为上层聚合提供基础。
- DWS（Data Warehouse Summary） / 汇总层
- 将明细层的数据按照一定主题或指标进行聚合、汇总。
- 特点：进一步降低数据粒度，高效支持常见的聚合查询、指标分析等。
- ADS（Application Data Store） / 应用层
- 面向特定应用或报表需求，对数据进行定制化加工，通常是对特定主题或指标的深度加工或计算结果。
- 特点：业务访问速度快、查询逻辑简单，但一般复用性较低。
- DIM（Dimension Table） / 维表层
- 存放企业常用的维度或参考表，例如用户信息维表、商品信息维表、地理区域维表等。
- 特点：在各个层的 ETL 过程中被频繁连接或关联，用于补充或映射数据属性。
- DM（Data Mart） / 数据集市层
- 有些企业还会将面向特定部门或特定业务主题的数据称为“数据集市”。与 ADS 类似，主要服务于某类精细化分析或应用。
实际应用场景：
- 离线分析与商业智能
- 通过 ODS → DWD → DWS → ADS 的方式，先保证原始数据的完整性，然后逐层进行聚合，在应用层直接服务于 BI 报表、管理仪表盘等。
- 实时数据分析
- 有些分层架构中会增加流数据的处理层（Streaming Layer），如存储在 Kafka、Flink 等流式平台，结合实时湖仓（如 Paimon、Kafka + Iceberg、Delta Lake 等）实现实时更新。
- 分层思路同样适用，只不过在流处理场景下，数据处理频率更高、延迟更低。
- 数据挖掘与机器学习
- 通过维度和事实数据的明细层（DWD）获取丰富、干净的特征数据，为机器学习训练集提供持续更新的基础；
- 也可将挖掘后的结果或特征输出到应用层（ADS）或其他平台，供下游使用。