一 湖仓一体架构的定义和特点

湖仓一体架构是一种结合数据湖和数据仓库的数据管理架构。它的核心思想是将数据湖和数据仓库合并为一个整体，实现数据的统一管理和分析。相对于传统数据仓库架构，湖仓一体架构具有以下几个特点：

1 数据湖和数据仓库的合并

传统数据仓库架构中，数据仓库层和数据湖层是分开的，数据仓库层用于存储数据仓库中处理过的数据，数据湖层用于存储原始数据。而在湖仓一体架构中，数据湖和数据仓库被合并为一个整体，所有数据都可以在同一个数据存储系统中进行管理和存储，实现数据的一体化管理。

2 数据采集和处理的灵活性

湖仓一体架构具有灵活的数据采集和处理能力，可以支持各种类型和来源的数据。无论是结构化数据、半结构化数据还是非结构化数据，都可以轻松地采集和处理。同时，湖仓一体架构还具有强大的数据清洗和转换功能，可以对数据进行标准化和格式化，确保数据的质量和一致性。

3 数据分析的高效性

湖仓一体架构中的数据仓库层被优化和整理，以便于分析。这样可以更加高效地进行数据分析，提高分析结果的准确性和可靠性。同时，湖仓一体架构也支持实时数据分析，可以在数据采集和处理后立即进行分析，帮助企业及时发现业务问题。

科杰科技湖仓一体架构图如下：

二 Hudi概念及特点

1 特性

（1）高效upsert，可插入索引；
（2）原子方式操作数据并可回滚；
（3）具有时间线来追踪元数据血统；
（4）通过聚类优化数据集。

2 概要

2.1 Timeline

hudi的核心是维护在不同时刻在表上执行的所有操作的时间表，提供表的即时视图，同时还有效地支持按时间顺序检索数据。

上图显示了hudi表上10:00和10:20之间发生的更新插入，每5分钟一次，将提交元数据流以及其他后台清理/压缩操作在hudi时间轴上。观察的关键点是，提交时间表示数据的到达时间，而实际数据组织则反映了实际时间或事件时间，即数据所反映的从07:00开始的每小时时段。权衡数据延迟和完整性，这是两个关键概念。

如果有延迟到达的数据（事件时间为9:00的数据在10:20达到，延迟>1小时），可以看到upsert将数据生成到更旧的时间段/文件夹中。在时间轴的帮助下，增量查询可以只提取10:00以后成功提交的新数据，并非高效地只需要更改过的文件，且无需扫描更大的文件范围，例如07:00后的所有时间段。

2.2 File Layout

Hudi会在DFS分布式文件系统上的basepath基本路径下组织成目录结构。每张对应的表都会成多个分区，这些分区是包含该分区的数据文件的文件夹，与hive的目录结构非常相似。

2.3 Index

Hudi通过索引机制将映射的给定的hoodie key（record key+partition path）映射到文件id（唯一标示），从而提供高效的upsert操作。记录键和文件组/文件ID之间的这种映射，一旦记录的第一个版本写入文件就永远不会改变。

2.4 Table Types

Copy on Write（写时复制）：Copy on Write表中的文件切片仅包含基本或列文件，并且每次提交都会生成新版本的基本文件。因此Write Amplification写入放大非常高（即使只有很小改动的数据被提交修改，也需要重写整个列数据文件），而读取数据成本则没有增加，所以这种表适合于做分析工作，读取密集型的操作(多读少写场景)。

下图说明了copy on write的表是如何工作

随着数据被写入，对现有文件组的更新会为该文件组生成一个带有提交即时间标记的新切片，而插入分配一个新文件组并写入该文件组第一个切片。这些切片和提交即时时间在上图用同一颜色标识。针对图上右侧sql查询，首先检查时间轴上的最新提交并过滤掉之前的旧数据（根据时间查询最新数据），如上图所示粉色数据在10:10被提交，第一次查询是在10:10之前，所以出现不到粉色数据，第二次查询时间在10:10之后，可以查询到粉色数据（以被提交的数据）。

Merge on Read（读时合并）：更新记录到增量文件中，然后进行同步或异步压缩来生成新版本的列式文件。

Merge on Read表是copy on write的超集，它仍然支持通过仅向用户公开最新的文件切片中的基本/列来对表进行查询优化。用户每次对表文件的upsert操作都会以增量日志的形式进行存储，增量日志会对应每个文件最新的ID来帮助用户完成快照查询。因此这种表类型，能够智能平衡读取和写放大（wa）,提供近乎实时的数据。这种表最重要的是压缩器，它用来选择将对应增量日志数据压缩到表的基本文件中，来保持查询时的性能（较大的增量日志文件会影响合并时间和查询时间）。

下图说明了该表的工作原理，并显示两种查询类型：快照查询和读取优化查询

（1）如上图所示，现在每一分钟提交一次，这种操作是在别的表里（copy on write table）无法做到的；

（2）现在有一个增量日志文件，它保存对基本列文件中记录的传入更新（对表的修改），在图中，增量日志文件包含从10:05到10:10的所有数据。基本列文件仍然使用commit来进行版本控制，因此如果只看基本列文件，那么表的布局就像copy on write表一样；

（3）定期压缩过程会协调增量日志文件和基本列文件进行合并，并生成新版本的基本列文件，就如图中10：05所发生的情况一样；

（4）查询表的方式有两种，Read Optimized query和Snapshot query，取决于我们选择是要查询性能还是数据新鲜度；

（5）如上图所示，Read Optimized query查询不到10:05之后的数据（查询不到增量日志里的数据），而Snapshot query则可以查询到全量数据（基本列数据+行式的增量日志数据）；

（6）压缩触发是解决所有难题的关键，通过实施压缩策略，会快速缩新分区数据，来保证用户使用Read Optimized query可以查询到X分钟内的数据。

Merge on Read Table是直接在DFS上启用近实时（near real-time）处理，而不是将数据复制到外部专用系统中。该表还有些次要的好处，例如通过避免数据的同步合并来减少写入放大。