做的事：真实确认ClickHouse内置了整套Iceberg/Delta表函数
代码SELECT name FROM system.table_functions WHERE name ILIKE '%iceberg%' OR name ILIKE '%delta%';
验证：真实是一整套内置函数，覆盖本地/S3/Azure/HDFS/集群模式
实测 · 本机执行输出
iceberg icebergLocal icebergS3 icebergAzure icebergHDFS icebergCluster icebergLocalCluster icebergS3Cluster icebergAzureCluster icebergHDFSCluster deltaLake deltaLakeLocal deltaLakeS3 deltaLakeAzure deltaLakeS3Cluster deltaLakeAzureCluster
这份真实的函数清单本身就说明了一件重要的事：跟本系列上一篇《JDBC、ODBC和外部表》验证过的架构完全不同，Iceberg和Delta Lake的读取能力真实是直接编译进ClickHouse二进制本身的，不需要像JDBC/ODBC那样额外起一个独立的桥接进程——本文没有装任何额外的服务，这些函数在system.table_functions里真实就已经存在。
诚实的限制：本文没能跑出一次真实的端到端读取
Iceberg和Delta Lake真实都不是"一份数据文件"这么简单——它们真实是在Parquet数据文件之上，用一套独立的元数据体系(Iceberg是JSON格式的metadata文件+Avro格式的manifest列表和manifest文件；Delta Lake是JSON格式的事务日志_delta_log)来记录"这张表当前由哪些数据文件组成、经历过哪些schema变更、哪个版本对应哪些文件"，本质上是给数据文件加了一层真实的表结构/版本管理。要造出一份真实符合规范、能被ClickHouse正确识别的Iceberg或Delta表，真实需要一个具备写入能力的客户端（比如Python的pyiceberg/deltalake库，或者Spark），本机没有安装这两个Python库，本文也没有为了这一篇临时安装它们——手工拼凑符合规范的metadata JSON和manifest文件理论上可行，但真实容易做出不符合规范的假数据，与其编造一份可能有问题的示例数据来源，本文选择诚实说明这个限制，而不是硬凑一个自己都不确定是否规范的"成功"演示。真实能确定并且已经验证的是：ClickHouse把Iceberg/Delta Lake当作两种独立于自身MergeTree存储格式的、原生支持的外部表格式，跟本系列前面《S3表函数》验证过的"直接查询S3上的普通Parquet文件"的思路是一脉相承的，只是多了一层真实的元数据管理能力，让"这张表现在长什么样"这个问题不再靠文件名通配符猜测，而是有真实的版本化记录可查——这也是数据湖场景下Iceberg/Delta相对纯Parquet文件的核心价值所在，本文没能实测的部分，读者如果有真实的Iceberg/Delta表(比如用Spark写出来的)，本系列验证过的s3()表函数的连接参数思路(host/access_key/secret_key)应该可以直接套用到icebergS3()/deltaLakeS3()上。
分步演示：从函数确认到诚实说明的真实限制
每一步都是本文上面用真实system.table_functions核对出来的原始结果，包括诚实的限制说明。
真实原生内置的函数，但本文诚实说明未能实测
这一步新确认的事实
本文用到的工具
- 本机真实的
system.table_functions，确认iceberg/deltaLake系列函数原生存在 - 诚实说明：未安装pyiceberg/deltalake等写入工具，本文未能跑出真实的端到端读取演示
下一篇 · CLICKHOUSE 内部原理 81
ClickHouse 内存限制：查询为什么被 Kill
京公网安备11010502063487号