1. 架构本质从“存算强绑定”到“三权分立”在传统关系型数据库如 PostgreSQL / MySQL体系中计算引擎、元数据管理与物理存储被紧密耦合在同一个操作系统进程与宿主机文件系统内计算层单体postgres守护进程负责 SQL 解析、查询优化、执行计划生成与缓冲区管理事务层依托本地内存中的锁管理器Lock Manager与顺序追加的预写日志WAL - Write Ahead Log维系 ACID 事务存储层直接操作本地块存储Block Storage上的私有行式数据页文件Heap Files如/var/lib/postgresql/data/base/...。这种强绑定模型虽然保障了单机低并发事务的高内聚但在现代海量半结构化数据摄入与交互式敏捷分析场景下暴露出致命瓶颈存储与算力无法独立弹性伸缩、物理文件格式闭源专有导致生态割裂、跨引擎并发写容易引发元数据死锁。现代数据湖仓Lakehouse架构通过将传统数据库的核心组件彻底拆解为三个独立抽象层重塑了数据系统的分工边界现代湖仓一体分层架构_Lakehouse基于元数据剪枝读取/提交持久化快照与Parquet列存计算引擎层: Trino / Flink (纯无状态计算节点)表格与事务层: Apache Iceberg (快照隔离 / 隐藏分区 / ACID)对象存储底座: S3-Compatible Bucket (如 Cloudflare R2 / AWS S3)传统关系型数据库单体模式_如PostgreSQL计算层: postgres 进程 (SQL解析 / 内存计算)事务层: 本地 WAL 日志 共享内存事务状态存储层: 本地私有行存数据文件 (Heap Files)三个核心组件在物理本质上分别对应传统数据库的关键构件湖仓三层栈组件物理本质与规范定位对标传统关系型数据库 (PostgreSQL)Object Bucket (如 R2)分布式高可用对象存储底座存放不可变物理文件本地块设备文件系统 (/var/lib/postgresql/data)Apache Iceberg开放表格式规范Table Format提供快照隔离与 ACID 事务树本地 WAL 日志 数据字典系统表 (pg_class,pg_attribute)Trino分布式纯内存大规模并行处理MPP查询计算引擎postgres进程执行 SQL 解析、CBO 优化、内存流式计算2. 存储底座 (Object Storage)不可变文件系统的物理形态在湖仓架构中对象存储如 Cloudflare R2、AWS S3不再按传统文件系统的层级目录树Directory Tree来组织而是扁平的 Key-Value 寻址对象池。存储在 Bucket 内部的数据具有以下物理特征写一次不可变Write-Once, Read-Many任何数据文件一旦被 Flink 或 Spark 写入完成并关闭即变为物理只读不可变文件。修改或删除数据并不直接原地修改物理文件而是生成新的文件版本开放列式编码Apache Parquet数据不再采用传统数据库的 8KB 物理行存页而是采用标准的 Parquet 格式列式编码存储。每列数据单独连续排布配合 Snappy 或 ZSTD 压缩算法压缩比可达 5:1 至 10:1零出网成本与近乎无限吞吐借助分布式存储协议读写并发能力摆脱了单块 NVMe SSD 的物理 IOPS 瓶颈由多节点网卡并发吞吐分摊流量。3. 表格式 (Apache Iceberg)将“一堆文件”抽象为“单张事务表”若仅在存储桶中存放海量 Parquet 文件系统充其量只是一个原始数据沼泽Data Swamp。查询引擎若要找一条记录只能执行全量文件暴力扫描Full Scan。Apache Iceberg 的核心技术使命是在不可变的对象存储上用一系列层级自解释的元数据文件构建出一棵带 ACID 事务特性的快照树Snapshot Tree。数据层_Data_Layer元数据层_Metadata_Layer指向最新当前根元数据记录当前 Snapshot ID历史快照回溯Manifest List记录列统计值: min/max/null记录列统计值: min/max/null记录列统计值: min/max/nullIceberg Catalog (JDBC / Hive / REST)v2.metadata.json (Table Metadata)Snapshot S2 (Committed)Snapshot S1 (Time Travel)snap-S2.avro (Manifest List)manifest-1.avromanifest-2.avro00001.parquet00002.parquet00003.parquet3.1 物理层级解析Catalog (目录层)仅维护一个轻量原子指针记录该表当前最新有效的元数据文件物理地址如s3://bucket/metadata/v2.metadata.json。在更新快照时Catalog 执行类似比较并交换Compare-And-Swap · CAS的原子操作Table Metadata (vN.metadata.json)表的总蓝图记录字段 Schema 定义、分区规则Partition Spec、排序规则以及按时间递增的历史快照Snapshot列表Manifest List (snap-*.avro)单次快照提交的直接入口文件记录了当前快照所包含的所有 Manifest 文件的物理路径以及各个 Manifest 所涵盖的分区范围Manifest File (*.avro)最底层的元数据清单逐一记录每个具体 Parquet 数据文件的物理路径、文件大小、行数以及各列的关键统计指标下界 Minimum、上界 Maximum、空值数量 Null Count。3.2 事务与隔离机制的本质传统数据库依赖锁管理器实现隔离级别。Iceberg 则通过**写时快照隔离Snapshot Isolation via Copy-on-Write / Merge-on-Read**完全消除了读写锁冲突读操作任何查询引擎在开始时绑定特定的 Snapshot ID后续读取全程基于该不可变快照树进行读操作永不阻塞写操作写操作并发任务在独立的内存或工作区中写入新 Parquet 文件并生成新的 Manifest只有在完成全量写入后才向 Catalog 发起元数据原子替换请求。提交成功后快照自增至S(N1)若发生冲突则自动执行乐观并发控制OCC重试。审计回溯Time Travel由于历史快照及底层的 Parquet 文件在提交后未被立刻物理物理删除查询引擎只需声明FOR TIMESTAMP AS OF或FOR VERSION AS OF即可直接调阅表在任意历史毫秒时刻的完整状态。4. 计算引擎 (Trino)纯内存大规模并行流式查询Trino原 PrestoSQL本身是一个无存储的、纯无状态Stateless的分布式计算引擎。Cloudflare R2 (Parquet 数据)Trino Workers (内存计算集群)Iceberg Metadata (R2)Trino Coordinator (大脑)Cloudflare R2 (Parquet 数据)Trino Workers (内存计算集群)Iceberg Metadata (R2)Trino Coordinator (大脑)元数据剪枝 (Metadata Pruning):比对 Min/Max 统计值剔除 95% 不相关文件par[Workers 并发流式拉取]客户端 / SQL Client提交 SQL (如: SELECT * FROM raw_sms_records WHERE received_at ...)11. 读取 vN.metadata.json 与 Manifest Avro22. 将命中文件的扫描任务拆分为 Splits 派发给 Workers33. 并行拉取命中 Parquet 文件的特定列 (Columnar Projection)44. 纯内存向量化解压、计算、哈希聚合55. 跨节点内存分页管道毫秒级流式返回结果6客户端 / SQL Client4.1 查询性能为什么能达到毫秒级很多开发者直觉认为“从远程对象存储读文件一定很慢”但 Trino Iceberg 的协同优化打破了这一限制元数据层极端剪枝Metadata Pruning File SkippingTrino Coordinator 在 SQL 解析与计划生成阶段直接读取轻量的 Avro Manifest 文件。若 SQL 带有过滤条件如WHERE imap_uid 1000Coordinator 比对 Manifest 里的min(imap_uid)和max(imap_uid)即可在不与任何 Parquet 数据文件发生网络 I/O 的前提下直接在内存中剔除 90% 以上的不相关文件列裁剪与行组跳过Column Projection RowGroup Skipping进入 Worker 计算阶段后Trino 仅根据 SQL 所选取的列名如仅选了msg_uid,sender向对象存储发起 HTTP 范围分段请求HTTP Range Request只拉取 Parquet 文件末尾的 Footer 元数据和对应列的数据页避免全宽表网络传输纯内存无落盘流式架构In-Memory Streaming PipeliningTrino 与 Spark 阶段落盘Shuffle Spill机制不同各执行节点之间通过 TCP 内存队列流式传递数据包数据边读取边在 CPU 缓存中向量化运算Vectorized Execution从计算到网络吐出全链路无二次磁盘写入。5. 总结与架构全景映射在传统的数据库思维中性能与事务通常被视作存储引擎的“内置黑盒特性”。通过拆解现代 Lakehouse可以看到一套职责极其清晰的工业化分工Cloudflare R2 (Bucket)充当容量近乎无限、按需计费的物理字节仓库解决“持久存储与网络分发”问题Apache Iceberg (Table Format)充当表的逻辑骨架与事务账本用 Avro 元数据树规范“什么是表、怎么切分事务、怎样做快照隔离”Apache Trino (Query Engine)充当纯粹的高效算力中枢利用分布式内存流水线专职解决“如何以最优成本把 SQL 转换为并行网络流并快速计算出结果”。这种“三权分立”的模块化架构使得系统既具备了传统关系型数据库一致严密的 ACID 事务边界与标准 ANSI SQL 交互界面又摆脱了专有磁盘与常驻主机的物理掣肘达成了存储成本、弹性扩容与开放生态之间的平衡。