Apache Iceberg 已经成为湖仓架构中最主流的开放表格式之一。它在低成本对象存储之上提供 ACID 事务、Schema Evolution（模式演进）、Hidden Partitioning（隐藏分区）和 Time Travel（时间旅行）等能力，同时保持格式开放、厂商中立，可以被 Apache Spark、Flink、Trino、Doris 等不同计算引擎直接访问。
对很多团队来说，这意味着可以在对象存储上获得接近传统数据仓库的数据管理能力，而无需将数据绑定到某一家分析平台。
而从环境初始化，到真正打通第一条可运行的数据链路，并没有想象中简单。首先需要选择并部署 Catalog，例如 REST Catalog、Hive Metastore、AWS Glue 或 JDBC；随后搭建数据写入链路，并确定 CDC 方案是使用 Debezium + Kafka，还是 Spark Streaming、Flink。除此之外，还需要考虑 Schema Evolution、对象存储配置、小文件治理（Compaction）、权限管理，以及查询引擎的选型和接入。
OLake 的作用，就是尽可能简化其中的数据同步和 CDC 环节。OLake 是一个开源数据复制引擎，通过 CDC 和并行写入，将 PostgreSQL、MySQL、MongoDB 等事务型数据库中的数据同步到开放湖仓格式中，无需额外搭建 Kafka 或 Debezium 技术栈。
本文将以 PostgreSQL + Iceberg + Apache Doris 为例，演示如何将实时业务数据接入分析环境，并搭建一条端到端、可实际运行的数据链路。整套环境可以部署在一台小规格 EC2 实例上，并在几分钟内完成基础环境搭建。接下来，我们将依次介绍整体架构、各组件在链路中的作用，以及具体的部署和配置过程。
从 PostgreSQL 到 Iceberg，再到 Apache Doris
这套 Demo 由四个核心开源组件组成，数据流向非常简单：业务数据首先写入 PostgreSQL；OLake 持续捕获数据库变更并同步到 Iceberg；Apache Doris 再直接查询 Iceberg 中的数据。
添加图片注释，不超过 140 字（可选）
PostgreSQL：作为业务系统的事务型数据库，无需修改现有业务架构。CDC 引擎通过读取 PostgreSQL 的 WAL（Write-Ahead Log，预写日志）捕获数据变更，从而尽量避免对生产库性能产生影响。
OLake：负责捕获 PostgreSQL 中的 INSERT、UPDATE 和 DELETE 操作，并将这些变更写入 Iceberg 表。作为轻量级 CDC 数据复制引擎，OLake 面向数据库和 Kafka 到 Apache Iceberg 的数据同步场景。目前支持 PostgreSQL、MySQL、MongoDB、Oracle 和 Kafka 等数据源，并可以对接主流 Iceberg Catalog。
Apache Iceberg：是整套架构的湖仓存储层，数据通常以 Parquet 文件的形式保存在对象存储中，Iceberg 通过元数据组织数据文件、快照和分区信息，为查询引擎实现分区裁剪、列裁剪和谓词下推等优化提供基础。 Catalog（REST、Hive Metastore 或 AWS Glue）用于跟踪表元数据。
Apache Doris：A：pache Doris 原生支持 Iceberg，可以直接查询 Iceberg 表。除了读取 Iceberg 数据，Apache Doris 还支持向 Iceberg 表写入数据，并通过向量化执行引擎完成高性能分析查询。
为什么选择 Apache Doris 查询 Iceberg？
这里选择 Apache Doris 作为 Iceberg 的查询引擎，主要基于以下几个方面的考虑。
1、全向量化执行引擎
Apache Doris 采用全向量化执行引擎，以列式批处理的方式执行计算，并结合 SIMD 指令优化 CPU 执行效率，减少函数调用开销，同时提升 CPU Cache 的利用率。
这种执行模式与 Iceberg 常用的 Parquet、ORC 等列式存储格式天然契合，能够更高效地完成扫描、过滤、聚合和 JOIN 等分析操作。
基于官方公开的 1 TB Iceberg TPC-DS Benchmark，在相同测试环境下，Doris 完成全部 99 条查询的总耗时约为 Trino 的三分之一，体现出其在大规模湖仓分析场景下的查询性能优势。
2、 支持主流 Iceberg Catalog
Apache Doris 可以直接对接多种主流 Iceberg Catalog，包括：REST Catalog、AWS Glue、Hive Metastore、Hadoop Catalog、阿里云 DLF。
如果企业已经部署了现有的 Iceberg Catalog，可以直接接入 Doris，无需迁移或重新组织 Catalog，从而降低现有湖仓架构接入查询引擎的成本。
3、 支持 CDC 场景下的 Delete File
在 CDC 场景中，当同步引擎从 PostgreSQL 捕获 UPDATE 或 DELETE 操作后，这些变更可以通过 Iceberg 的 Delete File 进行记录。
Apache Doris 原生支持读取 Iceberg 的两类 Delete File：Position Delete 以及 Equality Delete。查询 Iceberg 表时，Doris 会在数据读取阶段结合 Data File 和 Delete File 进行处理，从而正确过滤已经被更新或删除的数据，返回一致的查询结果。
对于基于 CDC 构建的实时湖仓架构而言，这一点尤其重要。否则，数据虽然已经成功同步到 Iceberg，但查询引擎如果无法正确处理 Delete File，就可能读取到已经失效的历史记录。
4、支持 Time Travel 和 Snapshot 查询
Iceberg 通过 Snapshot 保存不同时间点的数据状态，而 Doris 可以直接查询指定的 Iceberg Snapshot，实现 Time Travel。这意味着，无需额外复制或恢复数据，就可以查看某个历史时间点的表状态。
这项能力非常适合数据排障、审计追溯、历史数据回溯，以及不同时点业务指标的对比分析。
5、谓词下推和分区裁剪
在查询 Iceberg 表时，Apache Doris 可以结合 Iceberg 的元数据信息进行 Partition Pruning（分区裁剪），尽可能跳过与查询条件无关的数据文件和分区。
同时，在多表 JOIN 场景下，Doris 还支持动态分区裁剪，根据运行时产生的过滤条件进一步缩小扫描范围。配合 Predicate Pushdown（谓词下推）、列裁剪等优化机制，Doris 可以减少从对象存储读取的数据量，从而降低 I/O 开销。
对于过滤条件选择性较高的大型 Iceberg 表，这类优化往往可以带来明显的查询性能提升；在部分场景中，查询性能可提升约 30%～40%。
快速开始：15 分钟搭建完整环境
下面我们从零开始，在本地环境或云服务器上搭建一条完整可运行的数据链路。整个 Demo 的目标是尽量减少环境依赖，帮助开发者快速验证 Iceberg 湖仓链路。
0、前置条件
开始之前，需要准备以下环境：
一台 Linux 实例，Demo 环境下 4 GB 内存、20 GB 磁盘即可
已安装 Docker 和 Docker Compose
如果部署在远程服务器，需要具备 SSH 访问权限
1、调整系统参数
Apache Doris 对 vm.max_map_count 有一定要求，因此启动环境前，需要先调整该参数：
sudo sysctl -w vm.max_map_count=2000000
该配置用于提高进程可创建的虚拟内存映射数量，避免 Doris 启动或运行过程中因为系统参数过低而出现问题。
2、部署支持 Iceberg 的 Apache Doris 环境
Apache Doris 官方代码仓库提供了一套现成的湖仓 Demo，可以直接启动 Doris、Iceberg Catalog 和对象存储环境：
git clone https://github.com/apache/doris.git
cd doris/samples/datalake/iceberg_and_paimon
bash ./start_all.sh
脚本执行完成后，会启动一套完整的测试环境，其中包括：Apache Doris、Iceberg REST Catalog 及 兼容 S3 API 的对象存储服务。
这样就不需要分别安装和配置各个基础组件，可以直接进入后续的数据同步环节。
3、配置 OLake CDC 数据同步
OLake 可以通过一条 Docker Compose 命令完成部署：
curl -sSL https://raw.githubusercontent.com/datazip-inc/olake-ui/master/docker-compose.yml | docker compose -f - up -d
进入 OLake UI 后，需要完成以下配置：
配置 PostgreSQL 数据源；
配置 Iceberg 目标端，包括 Catalog 类型和对象存储访问凭证；
创建数据同步任务。
任务启动后，OLake 会负责完成后续的数据同步流程，包括表发现、Schema 映射、初始化全量同步（Initial Backfill），以及持续运行的 CDC 增量同步。
4、通过 Apache Doris 查询 Iceberg 数据
数据开始同步到 Iceberg 后，就可以通过 Apache Doris 直接进行查询。
-- 进入 Doris 客户端
bash start_doris_client.sh
-- 查看所有可用 Catalog（数据目录）
SHOW CATALOGS;
-- 切换到 Iceberg 数据目录
SWITCH iceberg;
-- 刷新 Catalog 以获取最新表数据
REFRESH CATALOG iceberg;
-- 浏览与查询数据
SHOW DATABASES;
USE ;
SHOW TABLES;
SELECT * FROM iceberg.. LIMIT 10;
至此，来自 PostgreSQL 的数据已经通过 OLake 实时同步到 Iceberg，并可以直接通过 Apache Doris 查询。
如果 Docker 环境和网络都已经准备好，实际部署速度还可以更快。在实际演示中，从启动环境到完成第一次 Iceberg 查询，整个过程大约只用了两分钟。
进入生产环境注意事项
将这套架构部署到生产环境后，还需要围绕文件组织、分区设计、表维护和 Catalog 选型等方面做进一步优化，才能保证系统长期稳定运行。
1、文件大小
Iceberg 表的数据文件并不是越多越好。通常来说，将单个数据文件控制在 128 MB～512 MB 左右，更有利于兼顾写入效率和查询性能。
在 CDC 场景下，数据会持续以较小批次写入。如果写入频率较高，很容易产生大量小文件。小文件过多后，查询引擎会将更多时间消耗在文件枚举、打开和调度上，而不是实际的数据扫描，最终影响整体查询效率。
因此，在生产环境中，需要重点关注小文件问题。比较常见的做法有两种：
由 CDC 引擎在写入过程中进行文件合并（Compaction），尽量控制文件数量和大小；
定期执行 Iceberg Compaction 任务，将已经产生的小文件重新合并为更大的数据文件。
对于持续运行的 CDC 链路来说，Compaction 应当被视为日常表维护的一部分，而不是一次性的优化操作。
2、分区策略
相比传统 Hive 式分区，Iceberg 的 Hidden Partitioning（隐藏分区）简化了分区设计和查询方式。
用户只需要在表级别定义 Partition Spec。例如，可以基于时间戳字段按天分区，后续分区值的生成和维护都由 Iceberg 自动完成。
查询时，用户无需显式拼接或指定物理分区列。Apache Doris 可以直接读取 Iceberg 的分区元数据，并根据查询条件进行自动 Partition Pruning（分区裁剪），从而减少不必要的数据扫描。
在实际生产环境中，分区粒度需要根据数据规模和典型查询模式来设计。分区过粗，无法有效减少扫描范围；分区过细，则可能增加元数据和小文件数量。因此，通常需要在数据量、写入频率和查询条件之间取得平衡。
3、表维护
随着 Iceberg 表持续写入，Snapshot、Data File、Delete File 和 Metadata File 都会不断积累。
如果长期不做维护，不仅会增加对象存储空间占用，也可能导致元数据规模持续膨胀，进而影响表规划和查询性能。
因此，生产环境通常需要定期执行以下维护任务：
Snapshot 过期清理：删除已经不再需要的历史 Snapshot 及相关引用；
Orphan File 清理：清理未被 Iceberg 元数据引用的孤儿文件；
Compaction：合并小文件，改善文件布局；
Metadata 清理：控制历史元数据文件数量，避免长期积累。
对于 CDC 场景而言，还需要特别关注 Delete File 的增长情况。如果 UPDATE 和 DELETE 操作较多，Delete File 会持续积累，因此更需要配合 Compaction 和表维护策略，避免长期影响查询效率。
4、Catalog 选择
Catalog 是 Iceberg 架构中的关键组件之一，负责管理表的位置、元数据指针以及相关命名空间信息。
生产环境中，可以根据现有基础设施和云平台选择合适的 Catalog。例如，如果部署在 AWS 上，可以考虑直接使用 AWS Glue；如果企业已经运行 Hive Metastore，也可以复用现有 HMS 基础设施；如果希望采用更加开放、标准化的方式，也可以选择 REST Catalog 或相应的托管服务。
本 Demo 使用的是 tabulario/iceberg-rest。它部署简单、资源占用较低，非常适合本地开发、功能验证和演示环境。
但对于大规模生产环境，还需要进一步考虑 Catalog 的高可用、并发能力、权限控制、备份恢复以及运维体系。因此，Demo 中的 Catalog 方案更适合作为快速验证环境，而不应直接等同于生产环境的最终选型。
典型应用场景
整条链路跑通后，可以覆盖一系列常见的实时分析和湖仓应用场景。
1、业务数据实时看板
PostgreSQL 继续负责支撑线上业务系统，而产品、运营和管理团队通常还希望实时查看用户活跃度、收入、转化率以及功能使用情况等核心指标。
如果直接在生产 PostgreSQL 上执行复杂分析查询，随着数据量和查询并发不断增长，很容易对在线业务产生影响；而传统每天一次、甚至每小时一次的离线 ETL，又往往无法满足实时分析对数据时效性的要求。
通过 CDC 将 PostgreSQL 中的数据变更持续同步到 Iceberg，可以让分析侧获得接近实时的数据更新；再由 Apache Doris 对 Iceberg 数据提供查询服务，就可以将事务处理与分析查询解耦。
这样既能减少分析负载对生产数据库的影响，也能为实时看板提供更低延迟、更高并发的查询能力。在数据模型和查询设计合理的情况下，即使面对数十个并发分析请求，也能够获得较快的交互式查询响应。
2、即席分析
除了固定报表和 Dashboard，数据分析师还经常需要执行大量探索性查询。例如：
将用户行为数据与订单、账单数据进行 JOIN；
按自定义时间范围筛选数据；
对数百万甚至更大规模的数据进行聚合分析；
临时调整维度和过滤条件，验证业务假设。
这类查询往往难以提前预测，因此不适合为每一种分析需求都预先构建聚合表或物化视图。
Apache Doris 可以直接对 Iceberg 表执行复杂过滤、聚合和 JOIN 查询，让分析人员可以围绕原始或明细数据进行交互式探索，而无需为每个问题提前设计一套独立的数据加工链路。
与此同时，由于底层数据仍然以开放格式存储在 Iceberg 中，同一份数据还可以被 Spark、Flink 等其他计算引擎访问，用于离线处理、机器学习特征加工或更复杂的数据计算。
这也是开放湖仓架构的重要价值之一：数据只需要存储一份，但可以服务于多种计算场景。
3、基于开放湖仓构建 SQL 分析平台
不少团队采用 Snowflake、BigQuery 等云数据仓库，本质需求之一是：让业务数据能够以 SQL 的方式被快速分析。
对于希望控制基础设施成本，或者不希望将数据和计算完全绑定在某一家云数据仓库上的团队来说，Iceberg + Doris 提供了另一种选择。
在这套架构中，数据主要存储在成本相对较低的对象存储中，并以开放的 Iceberg 格式进行管理；Apache Doris 则作为开源查询引擎提供 SQL 分析能力。
因此，存储层和计算层可以相对独立地扩展，同时底层数据不会被锁定在某个专有数据仓库格式中。相比部分按照扫描量、查询次数或计算 Credit 计费的云数据仓库模式，这种架构的成本结构也更加直接：主要来自对象存储以及实际运行 Doris 集群所需要的计算资源。
对于查询负载相对稳定、数据规模持续增长的场景，这种方式尤其值得考虑。
4、利用 Time Travel 进行历史分析
Iceberg 会通过 Snapshot 记录表在不同时间点的状态，因此天然具备历史版本管理能力。
Apache Doris 可以直接查询指定的 Iceberg Snapshot，从而访问历史时间点的数据，而无需额外维护多份历史表。
这项能力可以应用在很多实际场景中，例如：
对比本周与上个月相同口径下的业务指标；
回溯某条业务记录在不同时间点的状态；
审计数据在何时发生了新增、修改或删除；
当数据同步链路出现异常时，查询故障发生前后的数据状态；
验证一次数据修复或 Schema 变更是否产生了预期结果。
相比单纯保留“最新数据”，Snapshot 让湖仓具备了更强的数据可追溯性。对于 CDC 场景而言，这一点尤其有价值：不仅可以看到数据现在是什么样，还可以回答数据过去是什么样，以及什么时候发生了变化。
由于 Snapshot 本身由 Iceberg 自动维护，因此无需额外设计历史表或审计表，就可以完成上述分析。
结束语
Iceberg 的价值并不仅仅在于提供一种新的存储格式，更重要的是，它让数据真正以开放格式存储，并能够在不同计算引擎之间共享。
在本文这套架构中，PostgreSQL 负责事务处理，OLake 负责实时同步，Iceberg 负责统一管理数据，而 Apache Doris 则提供交互式分析能力。整个数据链路保持组件解耦，同时又能够满足实时分析的需求。
如果你正在评估，或者希望把传统批量 ETL 改造成基于 CDC 的实时数据链路，这套 Demo 可以作为一个不错的起点。
