你的目录里有什么都能查询：详解 ClickHouse Cloud 中的 DataLakeCatalog 引擎

最新推荐文章于 2025-11-23 01:04:45 发布

原创最新推荐文章于 2025-11-23 01:04:45 发布 · 910 阅读

25 ·

CC 4.0 BY-SA版权

文章标签：

#lucene #全文检索 #搜索引擎

软件工程专栏收录该内容

130 篇文章

订阅专栏

本文字数：12985；估计阅读时间：33 分钟

作者：Tom Schreiber

本文在公众号【ClickHouseInc】首发

TL;DR

ClickHouse 现在通过 DataLakeCatalog 引擎，可以直接查询 Iceberg 和 Delta Lake 表。

该引擎支持连接 AWS Glue Catalog、Databricks Unity Catalog 等目录，能够自动识别表的格式，并实现即连即查，甚至支持在一次查询中跨多个目录访问数据。

只要你的 lakehouse 表注册在目录中，就可以用 ClickHouse 进行查询。

ClickHouse 不再局限于本地表

ClickHouse 正在成长为一款高性能的 lakehouse 查询引擎，能够直接查询 Iceberg 和 Delta Lake 等开放格式的数据。

你只需连接好目录，即可开始查询。

在此前的文章中，我们曾探讨 lakehouse 的数据层：ClickHouse 如何直接读取和处理 Parquet 文件（https://clickhouse.com/blog/clickhouse-and-parquet-a-foundation-for-fast-lakehouse-analytics），并利用其强大的并行执行引擎实现极速查询。

而本文则聚焦在更高一层的目录层 —— 元数据层。在这一层，系统定义了哪些 Parquet 文件归属于哪些表，它们的分区方式，以及这些表在时间维度上的演化过程。

AWS Glue Catalog、Databricks Unity Catalog、Apache Polaris 和 REST 类型目录等，构成了现代数据湖的元数据基础架构。

这些目录无需复制数据，即可管理表的 schema（模式）、分区和版本控制，使 Iceberg 和 Delta Lake 等开放格式表现得如同完整的结构化数据库系统。

通过直接接入这些目录，ClickHouse 能够自动发现 lakehouse 表，解析其结构，并以全速进行查询。

只要你的表存在于目录中，ClickHouse 就可以立即查询。

尽管 DataLakeCatalog 引擎是开源的，本文重点聚焦于 ClickHouse Cloud。当前，ClickHouse Cloud 对 Glue Catalog 和 Unity Catalog 的集成已在 25.8 版本中进入测试阶段。

我们将演示 ClickHouse Cloud 如何实现从底层 Parquet 读取到完整目录集成的全链路支持，并通过 Glue 和 Unity Catalog 的快速演示进行现场展示。最后，我们还将进一步介绍跨目录联合查询的能力，以及 ClickHouse Cloud 在 lakehouse 路线图上的未来发展方向。

ClickHouse Cloud：全面支持 lakehouse 架构

ClickHouse Cloud 将现代分析技术栈的各个关键层整合为一体，实现对 lakehouse 架构的全面支持。

在最近的多个版本中，我们重构了核心组件 —— 包括 Parquet 文件读取器、缓存机制以及元数据处理能力 —— 无论你的数据是存储在 MergeTree、Iceberg 还是 Delta Lake 中，ClickHouse 都能够通过统一的高性能执行路径进行查询。

原生、高并发的 Parquet 读取器

新版原生 Parquet 读取器替代了早期基于 Arrow 的实现，采用 ClickHouse 自主研发的架构，将 Parquet 数据直接转换为引擎内部的内存格式。

它支持在行组中对列读取任务进行并行化处理，增加了页面级过滤功能和 PREWHERE 子句支持。在 ClickBench 基准测试中，整体 Parquet 查询性能平均提升了 1.8 倍。

Iceberg、Delta Lake 及 ClickHouse 原生表的并行查询扩展能力

如今，分析型查询可在全部 CPU 核心与计算节点之间高效扩展，即便面对数十亿乃至数百亿行规模的数据集，也能实现无需预聚合的亚秒级响应。

对于外部的 Iceberg 和 Delta Lake 表，ClickHouse 采用与原生表相同的“部分聚合状态”执行模型。区别在于任务调度是以 Parquet 文件为单位（而非数据粒度），从而保证各类数据源都具备一致的查询性能表现。

关于这种并行查询扩展能力在大规模 Iceberg 和 Delta Lake 表上的实战效果，我们将在后续文章中进行展示，敬请关注。

分布式缓存支持 Iceberg、Delta Lake 及 ClickHouse 原生表

ClickHouse Cloud 独有的分布式缓存机制，能够在所有计算节点之间提供共享、低延迟的热数据访问服务。

该机制有效避免了对 S3 的重复读取，将查询的尾部延迟从数百毫秒大幅缩短至微秒级。同时，它还支持真正的无状态弹性计算架构，确保在扩容或缩容时不会丢失缓存数据。

如下一节所述，这一分布式缓存能力同样适用于外部的 Iceberg 和 Delta Lake 表，其底层的 Parquet 文件将被缓存，从而实现更快速的后续访问体验。

支持 Iceberg、Delta Lake 与原生表的无状态计算能力

借助 Shared Catalog（共享目录），ClickHouse Cloud 的计算节点无需本地磁盘即可运行。

所有元数据都以集中式方式进行管理和版本控制，按需加载，支持秒级启动、弹性伸缩，并能在原生表与开放表格式之间实现无缝查询。

上述各个技术组件共同构建了 ClickHouse Cloud 的统一架构基础：

① Shared Catalog —— 快速一致的元数据访问能力

② Distributed Cache —— 高效共享的冷数据访问通道

③ Userspace Page Cache —— 内存级的细粒度缓存机制

④ Parallel Execution —— 大规模分布式并行查询引擎

这一性能体系不仅适用于 ClickHouse 原生表，在 Iceberg 与 Delta Lake 表上同样表现出色。

全面兼容 Iceberg 和 Delta Lake

ClickHouse 现已全面支持两大主流开放表格式：Apache Iceberg 和 Delta Lake。

针对 Iceberg，ClickHouse 完整支持 v2 功能规范，包括：支持 schema（模式）演进、时间点回溯（Time Travel）、基于统计信息的数据裁剪优化，以及多种目录集成（如 Unity、REST、Polaris 等）。

对于 Delta Lake，ClickHouse 支持完整的 Unity Catalog 集成、Delta Kernel 功能、分区裁剪优化，以及 schema 演进。

这些能力的实现不仅带来了对 DML 操作的兼容支持，也为未来写入能力和对 Iceberg v3 的支持奠定了坚实基础。

DataLakeCatalog 数据库引擎

DataLakeCatalog 是连接 ClickHouse 与 lakehouse 目录之间的关键桥梁。

它将目录中的元数据转化为可查询的表结构，让用户可以像使用 ClickHouse 原生表一样无缝查询 Iceberg 和 Delta Lake 数据。

ClickHouse 中的数据库引擎与表引擎角色划分

在 ClickHouse 架构中，表引擎决定数据的存储和查询方式，而数据库引擎负责表的组织管理与自动发现。

这种职责分离使 ClickHouse 同时具备高效的数据处理能力与灵活的元数据管理能力。正如我们将在下文展示的，DataLakeCatalog 数据库引擎还能根据目录中的元数据信息自动选择合适的表引擎（Iceberg 或 DeltaLake）。

随着 AWS Glue 和 Databricks Unity Catalog 的集成在 ClickHouse Cloud 25.8 版本中正式进入测试阶段，接下来我们将通过几个简洁演示带你快速了解其使用方式。

演示 1：查询 AWS Glue Catalog

本示例演示了 ClickHouse Cloud 如何连接 AWS Glue Catalog，并查询存储在 Amazon S3 中的 Apache Iceberg 表。只需简单几步，即可完成连接、目录浏览与首次查询。

什么是 AWS Glue Catalog？

AWS Glue Catalog 是 Amazon 提供的全托管数据目录与 ETL 服务，用于存储表的元数据，使存放于 S3 中的数据可被各种分析工具直接查询。

下图展示了由 AWS Glue 管理的表 player_match_history_iceberg_p。这是一个存储于 S3 的 Apache Iceberg 分区表，用于保存 Valve 开发的游戏 Deadlock 的对局数据：

（数据来源：Deadlock API）

说明：以下所有查询均通过 clickhouse-client 工具从一台 EC2 实例发起，连接至部署于 AWS us-east-2 区域、运行 ClickHouse 25.8 的 ClickHouse Cloud 服务。

将 ClickHouse Cloud 连接至 AWS Glue Catalog

在 ClickHouse Cloud 中使用 25.8 版本的 ClickHouse，我们可以通过 DataLakeCatalog 引擎创建数据库来连接 AWS Glue Catalog：

CREATE DATABASE glue
ENGINE = DataLakeCatalog
SETTINGS
    catalog_type = 'glue',
    region = 'us-east-2',
    aws_access_key_id = '...',
    aws_secret_access_key = '...',
    allow_database_glue_catalog = 1; -- beta feature in Cloud

在 ClickHouse Cloud 中创建的 glue 数据库，相当于远程 Glue Catalog 的本地代理。

它行为上与标准 ClickHouse 数据库无异，支持与原生数据库相同的元数据查询能力及 SQL 接口。

浏览元数据

完成连接后，即可像使用任意 ClickHouse 数据库一样进行元数据操作，例如列出目录中的全部表：

SHOW tables FROM glue;

┌─name──────────────────────────────────────────────────┐
│ agenthouse.player_match_history                       │
│ clickhouse_datalake_demo.player_match_history_delta   │
│ clickhouse_datalake_demo.player_match_history_iceberg │
│ clickhouse_datalake_demo.pypi_delta_flat              │
│ clickhouse_datalake_demo.pypi_delta_part              │
│ clickhouse_datalake_demo.pypi_iceberg_flat            │
│ clickhouse_datalake_demo.pypi_iceberg_part            │
│ clickhouse_datalake_demo.pypi_parquet                 │
│ clickhouse_datalake_demo.pypi_test_iceberg_flat       │
│ clickhouse_datalake_demo.pypi_test_iceberg_part       │
│ openhouse.player_match_history_iceberg_p              │
└───────────────────────────────────────────────────────┘

也可以直接查看 Glue Catalog 中表的 DDL 信息：

SHOW CREATE TABLE glue.`openhouse.player_match_history_iceberg_p`;

┌─statement──────────────────────────────────────────────────────┐
│ CREATE TABLE glue.`openhouse.player_match_history_iceberg_p`  ↴│
│↳(                                                             ↴│
│↳    `account_id` Nullable(Int64),                             ↴│
│↳    `match_id` Nullable(Int64),                               ↴│
│↳    `hero_id` Nullable(Int64),                                ↴│
│↳    `hero_level` Nullable(Int64),                             ↴│
│↳    `start_time` Nullable(Int64),                             ↴│
│↳    `game_mode` Nullable(Int32),                              ↴│
│↳    `match_mode` Nullable(Int32),                             ↴│
│↳    `player_team` Nullable(Int32),                            ↴│
│↳    `player_kills` Nullable(Int64),                           ↴│
│↳    `player_deaths` Nullable(Int64),                          ↴│
│↳    `player_assists` Nullable(Int64),                         ↴│
│↳    `denies` Nullable(Int64),                                 ↴│
│↳    `net_worth` Nullable(Int64),                              ↴│
│↳    `last_hits` Nullable(Int64),                              ↴│
│↳    `team_abandoned` Nullable(Bool),                          ↴│
│↳    `abandoned_time_s` Nullable(Int64),                       ↴│
│↳    `match_duration_s` Nullable(Int64),                       ↴│
│↳    `match_result` Nullable(Int64),                           ↴│
│↳    `objectives_mask_team0` Nullable(Int64),                  ↴│
│↳    `objectives_mask_team1` Nullable(Int64),                  ↴│
│↳    `created_at` Nullable(DateTime64(6)),                     ↴│
│↳    `event_day` Nullable(String),                             ↴│
│↳    `event_month` Nullable(String)                            ↴│
│↳)                                                             ↴│
│↳ENGINE = Iceberg('s3://clickhouse-datalake-demo/              ↴│
│↳                  data/openhouse_managed/                     ↴│
│                   player_match_history_iceberg_p')             │
└────────────────────────────────────────────────────────────────┘

可以看到，该表使用的是 Iceberg 引擎，这是 ClickHouse 内置用于读取 Apache Iceberg 数据的表引擎。表数据实际存储于 Amazon S3。

虽然也可以手动指定 S3 路径并通过 Iceberg 引擎直接读取，但借助 DataLakeCatalog 数据库引擎，ClickHouse 会自动从 Glue Catalog 获取元数据并完成配置。

由于目录中已将 player_match_history_iceberg_p 标识为 Iceberg 表，ClickHouse 将透明地使用其 Iceberg 引擎处理查询，并自动应用所有标准的 Iceberg 优化（此部分将在后续文章详解）。

下图展示了这一端到端流程的整体结构：

查询 Iceberg 数据

我们来运行一个实际查询，获取 2024 年 3 月期间 Deadlock 游戏每日的对局活跃度：

SELECT
    toDate(toDateTime(start_time)) AS day,
    count() AS matches,
    round(avg(match_duration_s) / 60, 1) AS avg_match_min
FROM glue.`openhouse.player_match_history_iceberg_p`
WHERE toDate(toDateTime(start_time)) BETWEEN toDate('2024-03-01') AND toDate('2024-03-31')
GROUP BY day
ORDER BY day;

┌────────day─┬─matches─┬─avg_match_min─┐
│ 2024-03-01 │      19 │          27.8 │
│ 2024-03-04 │      16 │          31.4 │
│ 2024-03-06 │      39 │          54.6 │
│ 2024-03-08 │      18 │          42.5 │
│ 2024-03-11 │      36 │          26.8 │
│ 2024-03-13 │      60 │          36.5 │
│ 2024-03-15 │      38 │          37.9 │
│ 2024-03-18 │      19 │          18.8 │
│ 2024-03-20 │      58 │          33.2 │
│ 2024-03-22 │      39 │          34.2 │
│ 2024-03-25 │      16 │          40.2 │
│ 2024-03-27 │      39 │          35.6 │
│ 2024-03-29 │      20 │          22.7 │
└────────────┴─────────┴───────────────┘

13 rows in set. Elapsed: 0.347 sec. Processed 339.04 million rows, 6.35 GB (977.46 million rows/s., 18.32 GB/s.)
Peak memory usage: 507.28 MiB.

结果展示：一分钟内从零配置到成功查询 Iceberg

从零开始，到成功查询 Iceberg 表，全过程不到一分钟。

关键步骤包括：

使用 DataLakeCatalog 引擎将 ClickHouse Cloud 连接到 AWS Glue Catalog
浏览 Glue 目录并查看元数据
像使用原生表一样查询 Iceberg 数据

演示 2：查询 Unity Catalog

本示例将展示如何连接 Unity Catalog，该目录系统用于统一管理 Delta Lake（及 Iceberg）表。配置方式同样简洁，我们将依次完成目录连接、元数据浏览，并直接查询 Delta Lake 表数据。

什么是 Unity Catalog？

Unity Catalog 是 Databricks 提供的统一权限与元数据管理平台，用于在多个工作空间和存储系统中集中管理表信息，包括 Delta Lake 格式的数据表。

下图所示为 Unity 管理的表 stackoverflow.posts_full，这是一张 Delta Lake 表，存储 Stack Overflow 的历史数据，已在 Databricks 中注册，并可在 ClickHouse Cloud 中通过 DataLakeCatalog 引擎直接查询：

将 ClickHouse Cloud 连接到 Unity Catalog

首先，与之前连接 AWS Glue Catalog 类似，我们通过 DataLakeCatalog 引擎创建数据库以连接外部 Unity Catalog：

CREATE DATABASE unity
ENGINE = DataLakeCatalog('https://dbc-37858cc0-7910.cloud.databricks.com/api/2.1/unity-catalog')
SETTINGS
    catalog_type = 'unity'
    warehouse = 'workspace',
    catalog_credential = '...',
    allow_database_unity_catalog = 1; -- beta feature in Cloud

创建后的 unity 数据库充当远程 Unity Catalog 的本地代理：

浏览元数据

该数据库在 ClickHouse 中的行为与标准数据库一致，可正常执行常见元数据操作，例如列出全部表：

SHOW tables FROM unity;

┌─name─────────────────────┐
│ stackoverflow.badges     │
│ stackoverflow.post_types │
│ stackoverflow.posts_full │
│ stackoverflow.users      │
│ stackoverflow.vote_types │
│ stackoverflow.votes      │
└──────────────────────────┘

也可以进一步查看 stackoverflow.posts_full 表的 DDL 定义：

SHOW CREATE TABLE unity.`stackoverflow.posts_full`;

┌─statement──────────────────────────────────────────────────────────────────┐
│ CREATE TABLE unity.`stackoverflow.posts_full`                             ↴│
│↳(                                                                         ↴│
│↳    `id` Nullable(Int32),                                                 ↴│
│↳    `post_type_id` Nullable(Int32),                                       ↴│
│↳    `accepted_answer_id` Nullable(Int32),                                 ↴│
│↳    `creation_date` Nullable(Int64),                                      ↴│
│↳    `score` Nullable(Int32),                                              ↴│
│↳    `view_count` Nullable(Int32),                                         ↴│
│↳    `body` Nullable(String),                                              ↴│
│↳    `owner_user_id` Nullable(Int32),                                      ↴│
│↳    `owner_display_name` Nullable(String),                                ↴│
│↳    `last_editor_user_id` Nullable(Int32),                                ↴│
│↳    `last_editor_display_name` Nullable(String),                          ↴│
│↳    `last_edit_date` Nullable(Int64),                                     ↴│
│↳    `last_activity_date` Nullable(Int64),                                 ↴│
│↳    `title` Nullable(String),                                             ↴│
│↳    `tags` Nullable(String),                                              ↴│
│↳    `answer_count` Nullable(Int32),                                       ↴│
│↳    `comment_count` Nullable(Int32),                                      ↴│
│↳    `favorite_count` Nullable(Int32),                                     ↴│
│↳    `content_license` Nullable(String),                                   ↴│
│↳    `parent_id` Nullable(Int32),                                          ↴│
│↳    `community_owned_date` Nullable(Int64),                               ↴│
│↳    `closed_date` Nullable(Int64)                                         ↴│
│↳)                                                                         ↴│
│↳ENGINE = DeltaLake('s3://unitycatalogdemobucket/stackoverflow/posts_full') │
└────────────────────────────────────────────────────────────────────────────┘

注意，此处表的引擎为 DeltaLake，这是 ClickHouse 内置用于读取 Delta Lake 表数据的原生引擎。表数据本身存储于远程的 Amazon S3 上。

ClickHouse 在解析目录元数据后自动识别该表为 Delta Lake 表，因此透明地选择了 DeltaLake 引擎进行查询处理。

查询 Delta Lake 数据

最后，我们执行一个查询，用于统计 2024 年 3 月期间，每天在 Stack Overflow 中提及 “Deadlock” 的帖子数量：

SELECT
    toDate(toDateTime(creation_date)) AS day,
    uniq(id) AS posts,
    sum(view_count) AS views
FROM unity.`stackoverflow.posts_full`
WHERE post_type_id = 1
  AND toDate(toDateTime(creation_date)) BETWEEN toDate('2024-03-01') AND toDate('2024-03-31')
  AND (
         positionCaseInsensitive(coalesce(title, ''), 'Deadlock') > 0
      OR positionCaseInsensitive(coalesce(body,  ''), 'Deadlock') > 0
  )
GROUP BY day
ORDER BY day;

┌────────day─┬─posts─┬─views─┐
│ 2024-03-01 │     2 │  1533 │
│ 2024-03-02 │     1 │    43 │
│ 2024-03-03 │     1 │   130 │
│ 2024-03-04 │     2 │    81 │
│ 2024-03-05 │     3 │   213 │
│ 2024-03-06 │     3 │   237 │
│ 2024-03-08 │     2 │    80 │
│ 2024-03-09 │     2 │    72 │
│ 2024-03-11 │     2 │    76 │
│ 2024-03-12 │     2 │    61 │
│ 2024-03-13 │     2 │    49 │
│ 2024-03-14 │     1 │    15 │
│ 2024-03-16 │     2 │    83 │
│ 2024-03-18 │     1 │    36 │
│ 2024-03-19 │     5 │   226 │
│ 2024-03-20 │     3 │    65 │
│ 2024-03-21 │     2 │   134 │
│ 2024-03-22 │     3 │   143 │
│ 2024-03-24 │     2 │   100 │
│ 2024-03-25 │     4 │   117 │
│ 2024-03-26 │     5 │   291 │
│ 2024-03-27 │     3 │    97 │
│ 2024-03-28 │     3 │   107 │
│ 2024-03-30 │     2 │    76 │
│ 2024-03-31 │     1 │    45 │
└────────────┴───────┴───────┘

25 rows in set. Elapsed: 6.989 sec. Processed 59.82 million rows, 36.79 GB (8.56 million rows/s., 5.26 GB/s.)
Peak memory usage: 16.56 GiB.

通过以上两个目录系统和两种开放表格式的演示可以看到：

只要你的数据表存在于目录中，就可以用 ClickHouse Cloud 进行查询。

而这，仅仅是开始。由于 ClickHouse 能够查询任意来源的数据 —— 无论是本地还是外部 —— 这些连接也为跨源联合查询奠定了基础。

演示 3：跨目录的联合查询

此前，我们已经分别通过 AWS Glue Catalog 查询了 Iceberg 表数据，通过 Unity Catalog 查询了 Delta Lake 表数据。

现在，我们将两者结合，展示 ClickHouse 如何在一条查询语句中对它们进行联合操作。

这正体现了 lakehouse 架构的强大之处。

下方示例展示了一个跨目录查询：将 AWS Glue Catalog（Iceberg）中的 Deadlock 比赛记录，与 Unity Catalog（Delta Lake）中提及 Deadlock 的 Stack Overflow 帖子按日期进行联合分析，观察游戏数据与社区讨论的同步演进过程 —— 所有操作均在 ClickHouse Cloud 内完成：

WITH
  so AS (
    SELECT
      toDate(toDateTime(creation_date)) AS day,
      uniq(id) AS posts,
      sum(view_count) AS views
    FROM unity.`stackoverflow.posts_full`
      WHERE post_type_id = 1
        AND toDate(toDateTime(creation_date)) BETWEEN toDate('2024-03-01') AND toDate('2024-03-31')
        AND (
             positionCaseInsensitive(coalesce(title,''), 'Deadlock') > 0
          OR positionCaseInsensitive(coalesce(body,''),  'Deadlock') > 0
        )
      GROUP BY day
  ),
  mh AS (
    SELECT
      toDate(toDateTime(start_time)) AS day,
      count() AS matches,
      round(avg(match_duration_s)/60, 1) AS avg_match_min
    FROM glue.`openhouse.player_match_history_iceberg_p`
    WHERE toDate(toDateTime(start_time)) BETWEEN toDate('2024-03-01') AND toDate('2024-03-31')
    GROUP BY day
  )
SELECT
  mh.day,
  mh.matches,
  mh.avg_match_min,
  so.posts,
  so.views,
  round(1000 * so.posts / nullIf(mh.matches, 0), 3) AS posts_per_1000_matches
FROM mh
JOIN so USING (day)
ORDER BY mh.day;

┌────────day─┬─matches─┬─avg_match_min─┬─posts─┬─views─┬─posts_per_1000_matches─┐
│ 2024-03-01 │      19 │          27.8 │     2 │  1533 │                105.263 │
│ 2024-03-04 │      16 │          31.4 │     2 │    81 │                    125 │
│ 2024-03-06 │      39 │          54.6 │     3 │   237 │                 76.923 │
│ 2024-03-08 │      18 │          42.5 │     2 │    80 │                111.111 │
│ 2024-03-11 │      36 │          26.8 │     2 │    76 │                 55.556 │
│ 2024-03-13 │      60 │          36.5 │     2 │    49 │                 33.333 │
│ 2024-03-18 │      19 │          18.8 │     1 │    36 │                 52.632 │
│ 2024-03-20 │      58 │          33.2 │     3 │    65 │                 51.724 │
│ 2024-03-22 │      39 │          34.2 │     3 │   143 │                 76.923 │
│ 2024-03-25 │      16 │          40.2 │     4 │   117 │                    250 │
│ 2024-03-27 │      39 │          35.6 │     3 │    97 │                 76.923 │
└────────────┴─────────┴───────────────┴───────┴───────┴────────────────────────┘

11 rows in set. Elapsed: 7.430 sec. Processed 398.86 million rows, 43.15 GB (53.68 million rows/s., 5.81 GB/s.)
Peak memory usage: 16.73 GiB.

三个演示。两个目录系统。两种开放表格式。一个查询引擎。

从 AWS Glue Catalog 到 Unity Catalog，再到 ClickHouse 原生表，一切都已融入统一的数据分析平台。

下一步发展方向

ClickHouse Cloud 在 lakehouse 路线上的探索仍在继续。

我们正在积极推进以下功能：

支持 Iceberg V3 —— 完全符合下一代规范，引入删除向量、VARIANT 数据类型，以及增强的 schema 演进能力
写操作支持 —— 为 lakehouse 表引入 INSERT、UPDATE 和 DELETE 能力
查询优化支持 —— 自动将碎片文件合并为更大、更高效的文件
除此之外，还有更大规模的功能升级正在规划中。暂时卖个关子，我们以一个简短动画作为结尾……

立即试用

DataLakeCatalog 引擎现已在 ClickHouse Cloud 中全面上线。

连接至 AWS Glue Catalog 或 Unity Catalog 后，你的 Iceberg 和 Delta Lake 表将即刻具备可查询能力，使用体验与原生表完全一致，完整覆盖你的 lakehouse 数据资产。

如果你的 lakehouse 表已经注册在目录中，就可以直接使用 ClickHouse 进行查询。

即使尚未注册，ClickHouse 依然有望通过其支持的 90 多种集成方式之一接入查询。

征稿启示

面向社区长期正文，文章内容包括但不限于关于 ClickHouse 的技术研究、项目实践和创新做法等。建议行文风格干货输出&图文并茂。质量合格的文章将会发布在本公众号，优秀者也有机会推荐到 ClickHouse 官网。请将文章稿件的 WORD 版本发邮件至：Tracy.Wang@clickhouse.com