5万
TL;DR
ClickHouse は、DataLakeCatalog エンジンを介して Iceberg テーブルおよび Delta Lake テーブルを直接クエリできるようになりました。
AWS Glue Catalog や Databricks Unity Catalog などのカタログに接続し、テーブル形式を自動検出して即座にクエリを実行できます。複数のカタログをまたぐクエリを単一のクエリで実行することも可能です。
レイクハウスのテーブルがカタログ内にあれば、ClickHouse でクエリできます。
ClickHouse が自身のテーブルを超えて進化
ClickHouse は、Iceberg や Delta Lake などのオープン形式を直接クエリできる高性能レイクハウスクエリエンジンへと進化しました。
カタログを接続するだけで、すぐにクエリを開始できます。
前回の記事では、レイクハウスのデータ層について取り上げ、ディスク上の最速クエリを支える同一の並列実行エンジンを使って、ClickHouse が Parquet ファイルを直接読み取って処理する仕組みを解説しました。
本記事では、どの Parquet ファイルがどのテーブルに属し、どのようにパーティショニングされ、時間とともにどう変化するかをメタデータで定義するカタログ層に焦点を当てます。
AWS Glue Catalog、Databricks Unity Catalog、Apache Polaris、そして REST カタログなどのカタログは、最新データレイクのメタデータの骨格を形成しています。
これらはデータを複製することなくスキーマ、パーティション、テーブルバージョンを管理し、Iceberg や Delta Lake などの形式を、完全に構造化されたクエリ可能なシステムのように動作させます。
これらのカタログに直接接続することで、ClickHouse はレイクハウステーブルを自動検出し、その構造を把握し、最高速度でクエリを実行できるようになりました。
カタログ内にあれば、ClickHouse で即座にクエリできます。
DataLakeCatalog エンジン自体はオープンソースですが、本記事では ClickHouse Cloud に焦点を当てます。ClickHouse バージョン 25.8 より、Glue および Unity Catalog との統合がベータとして提供されています。
高速な Parquet 読み取りから完全なカタログ統合まで、ClickHouse Cloud が各層をどのように統合しているかを順に説明し、Glue と Unity Catalog を使った簡単なデモで実際の動作を紹介します。さらに一歩進めて、カタログ間をまたぐフェデレーテッドクエリの検証や、ClickHouse Cloud におけるレイクハウス機能の今後の展望についても触れます。
ClickHouse Cloud は完全にレイクハウスに対応
ClickHouse Cloud は最新のアナリティクススタックのあらゆる層を統合し、完全なレイクハウス対応を実現しています。
近年のリリースを通じて、Parquet ファイルリーダー、キャッシュ、メタデータなどのコア層を再構築しました。データが MergeTree、Iceberg、Delta Lake のどこにあっても、ClickHouse は同じ高性能な実行パスを介してクエリを処理します。
高度に並列化された ClickHouse ネイティブの Parquet リーダー
新しいネイティブ Parquet リーダーは、従来の Arrow ベースの実装を置き換え、Parquet データをエンジンのインメモリ形式へ直接読み込む ClickHouse ネイティブの実装です。
行グループ内でのカラム読み取りを並列化し、ページレベルのフィルタリングや PREWHERE サポートを追加したことで、ClickBench 全体における Parquet クエリ速度が平均で 1.8 倍向上しました。
Iceberg、Delta Lake、ネイティブ ClickHouse テーブル向けの並列クエリスケーリング
分析クエリがすべての CPU コアとコンピュートノードにわたって効率的にスケールするようになり，数百億〜数千億行のデータセットに対しても、(事前集計なしで)1 秒未満で結果を返せます。
外部の Iceberg および Delta Lake テーブルに対しても、ネイティブテーブルと同じ部分集計状態実行モデルを使用しています。処理はグラニュールではなく Parquet ファイル単位で分散され、すべてのデータソースで一貫したパフォーマンスを発揮します。
大規模な Iceberg テーブルや Delta Lake テーブルにおけるこの並列クエリスケーリングの実際の動作については、今後の記事で詳しく紹介する予定です。
Iceberg、Delta Lake、ネイティブ ClickHouse テーブル向けの分散キャッシュ層
ClickHouse Cloud 独自の分散キャッシュにより、すべてのコンピュートノードからホットデータへの共有低レイテンシアクセスが実現します。
重複した S3 読み取りを排除し、テールレイテンシを数百ミリ秒からマイクロ秒単位へ削減するとともに、キャッシュデータを失うことなく瞬時にスケールする真のステートレスでエラスティックなコンピュートを可能にします。
次のセクションで示すように、分散キャッシュは外部の Iceberg および Delta Lake テーブルにも適用され、基盤となる Parquet ファイルをキャッシュして次回以降のアクセスをさらに高速化します。
Iceberg、Delta Lake、ネイティブ ClickHouse テーブル向けのステートレスコンピュート
Shared Catalog により、ClickHouse Cloud のコンピュートノードはローカルディスクを必要としなくなりました。
メタデータは一元管理されてバージョン管理され、オンデマンドで取得されるため、瞬時の起動、エラスティックなスケーリング、そしてネイティブ形式とオープンテーブル形式の間でのシームレスなクエリ実行が可能です。
これらの層が組み合わさることで、ClickHouse Cloud の統合された基盤が形成されます。
① Shared Catalog – 即時かつ一貫したメタデータアクセス
② 分散キャッシュ – コールドデータへの高速な共有アクセス
③ ユーザースペースページキャッシュ – きめ細かなインメモリキャッシュ
④ 並列実行 – 大規模な分散クエリ並列処理
ネイティブテーブルと同様に、まったく同じパフォーマンス層が Iceberg テーブルおよび Delta Lake テーブルにも適用されます。
完全な Iceberg および Delta Lake 互換性
ClickHouse は、2 大オープンテーブル形式である Apache Iceberg と Delta Lake の両方を完全にサポートするようになりました。
Iceberg については、スキーマ進化、タイムトラベル、統計情報に基づくプルーニング、カタログ統合(Unity、REST、Polaris など)を含む v2 の全機能セットをサポートしています。
Delta Lake については、完全な Unity Catalog 統合、Delta Kernel サポート、パーティションプルーニング、スキーマ進化をサポートしています。
これらが合わさることで DML 互換性と高度なメタデータイントロスペクションが解放され、今後のリリースにおける書き込みサポートや Iceberg v3 への道が開かれます。
DataLakeCatalog データベースエンジン
**DataLakeCatalog データベースエンジン**は、ClickHouse とレイクハウスのカタログをつなぐ架け橋です。
カタログのメタデータをクエリ可能なテーブルへ変換し、Iceberg や Delta Lake のデータをまるでネイティブデータであるかのようにクエリできるようにします。
ClickHouse におけるデータベースエンジンとテーブルエンジンの違い
ClickHouse では、テーブルエンジンがデータの保存方法とクエリ方法を担うのに対し、データベースエンジンはテーブルの編成や検出を担います。
この分離によって ClickHouse はデータストレージとメタデータ管理の双方に特化でき、後述するように、DataLakeCatalog データベースエンジンがカタログのメタデータから適切なテーブルエンジン(Iceberg または DeltaLake)を自動選択できます。
ClickHouse Cloud の ClickHouse 25.8 リリースで AWS Glue および Databricks Unity Catalog との統合がベータ版となったところで、簡単なデモをいくつか見てみましょう。
デモ 1: AWS Glue Catalog へのクエリ
最初の例では、ClickHouse Cloud を AWS Glue Catalog に接続し、S3 に保存された Apache Iceberg テーブルをクエリする手順を紹介します。わずか数ステップで、接続、カタログの探索、そして最初のクエリの実行まで行えます。
AWS Glue Catalog とは
AWS Glue Catalog は、テーブルのメタデータを保持し、Amazon S3 内のデータを各種分析ツールからクエリできるようにする、フルマネージドのデータカタログおよび ETL サービスです。
下のスクリーンショットは、AWS Glue で管理されているテーブル player_match_history_iceberg_p を示しています。これは、Valve 社が開発したビデオゲーム『Deadlock』のゲームデータを S3 に保存している、パーティショニングされた Apache Iceberg テーブルです。
(このデータのソース提供元: Deadlock API)
注意: 以下の例のクエリはすべて、ClickHouse 25.8 を実行する AWS us-east-2 にデプロイされた ClickHouse Cloud サービスに接続し、EC2 インスタンスから clickhouse-client を使って実行されました。
ClickHouse Cloud を AWS Glue Catalog に接続する
ClickHouse Cloud の ClickHouse バージョン 25.8 では、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 CloudClickHouse Cloud で作成した
glueデータベースは、リモートの AWS Glue Catalog に対するローカルプロキシとして機能します。
これは通常の ClickHouse データベースと同様に動作し、ネイティブデータベースで利用するのと同じメタデータ参照やクエリをサポートします。
メタデータの探索
AWS Glue Catalog が接続されたので、任意の 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 になっている点に注目してください。これは Apache Iceberg データを読み取るための ClickHouse 組み込みのテーブルエンジンです。データ自体はリモートの Amazon S3 に保存されています。
手動で S3 パスを指定して Iceberg エンジンを直接使用することもできましたが、DataLakeCatalog データベースエンジンは AWS 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.結果: ゼロから 1 分未満で Iceberg へ
ゼロから 1 分未満で Iceberg へ。
必要な作業はこれだけでした。
- DataLakeCatalog エンジンを使って ClickHouse Cloud を AWS Glue Catalog に接続する
- カタログを探索する
- ネイティブデータのように Iceberg データをクエリする
デモ 2: Unity Catalog へのクエリ
次に、Delta Lake テーブル(および Iceberg)を管理する Unity Catalog に接続してみましょう。セットアップは同様にシンプルで、カタログ接続を作成し、メタデータを検査し、Delta Lake データを直接クエリします。
Unity Catalog とは
Unity Catalog は、Delta Lake を含む複数のワークスペースやストレージシステムにまたがるテーブルを管理する、統合ガバナンスおよびメタデータ層です。
下のスクリーンショットは、Unity で管理されているテーブル stackoverflow.posts_full を示しています。これは Databricks に登録された Stack Overflow データを格納する Delta Lake テーブルで、DataLakeCatalog エンジンを使用して ClickHouse Cloud から直接クエリできる状態になっています。
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 Cloudunity データベースは、リモートの 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 になっている点に注目してください。これは Delta Lake テーブルデータを読み取るための ClickHouse 組み込みのテーブルエンジンです。データはリモートの Amazon S3 に存在します。
カタログのメタデータから stackoverflow.posts_full が Delta Lake テーブルであることを検出した後、ClickHouse は自動的に 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.2 種類のカタログタイプと 2 種類のオープンテーブルフォーマットにわたって実証したとおりです。
カタログ内にあれば、ClickHouse Cloud からクエリを実行できます。
しかし、これは始まりにすぎません。ClickHouse はネイティブか外部かを問わずどこからでもデータをクエリできるため、まさに同じ接続が**フェデレーテッドクエリ**の基盤になります。
デモ 3: カタログをまたいだフェデレーテッドクエリ
ここまで、AWS Glue Catalog 経由で Iceberg データを、Unity Catalog 経由で Delta Lake データをクエリしてきました。
次はこれらをすべて組み合わせ、ClickHouse が単一のクエリ内で直接結合する方法をご紹介します。
これこそが真のデータレイクハウスの力です。
以下の例では、AWS Glue Catalog の Deadlock の対戦履歴 (Iceberg) と、Unity Catalog の Deadlock に言及している Stack Overflow の投稿 (Delta Lake) を日単位で結合し、ゲームプレイとコミュニティの議論がどのように連動して推移しているかを、すべて 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.3 つのデモ、2 つのカタログ、2 つのオープンテーブルフォーマット、そして単一のクエリエンジン。
AWS Glue Catalog から Unity Catalog、ネイティブの ClickHouse テーブルに至るまで、すべてが同一の分析基盤の一部になりました。
今後の展望
ClickHouse Cloud のレイクハウスへの取り組みは今後も続きます。
現在、以下の開発を進めています。
-
Iceberg V3 のサポート — 次世代仕様への完全準拠。Deletion Vectors、VARIANT データ型、高度なスキーマエボリューションを導入予定です。
-
書き込みのサポート — レイクハウスのテーブルに対する INSERT、UPDATE、DELETE を可能にします。
-
最適化のサポート — 小さなファイルをより大きく効率的なファイルへ自動マージします。
-
さらに大規模な機能も準備中ですが、ひとまずはこちらのアニメーションをご覧ください…
実際に試してみる
DataLakeCatalog エンジンは、ClickHouse Cloud で現在ご利用いただけます。
AWS Glue Catalog や Unity Catalog に接続すれば、Iceberg や Delta Lake のテーブルを即座にクエリできるようになり、レイクハウス全体で同一の ClickHouse 体験を活用できます。
レイクハウスのテーブルがカタログ内にあるなら、ClickHouse からクエリを実行できます。
仮にカタログ内になくても、ClickHouse ならおそらくクエリ可能です (90 以上のインテグレーション のいずれかをご活用ください)。
今すぐ ClickHouse Cloud を始めて、$300 のクレジットを受け取りましょう。30 日間の無料トライアル終了後は、従量課金プランに移行できます。ボリュームベースの割引について詳しくは お問い合わせ ください。詳細は 料金ページ をご覧ください。
