データレイアウトの8つの誤解を解く：Liquid Clusteringがパーティショニングを上回る理由

はじめに

データのレイアウトは、コンピューティングにおける最も古い問題の1つです。

HadoopとHiveの登場以来15年以上にわたり、パーティショニングは処理と分析のためにデータを物理的に整理する標準的な方法でした。しかし、今日のレイクハウスは、人間が再パーティショニングできる速度よりも速く変化するエージェント、リアルタイムパイプライン、およびクエリパターンに対応しています。

Liquid Clusteringは最新の標準であり、本番環境でペタバイト規模のテーブルを持つ数十の顧客を含む、あらゆる規模で実行されています。このブログでは、レイクハウスでLiquid Clusteringがなぜ優れているのかを説明します。その過程で、一般的なデータレイアウトの誤解8つを解き明かし、パーティション化されたテーブルをLiquid Clusteringに変換した3つの成功事例を紹介し、今後の予定をプレビューし、開始方法を示します。

最新のレイクハウスでLiquid Clusteringが優れている理由

Hiveスタイルのパーティショニングでは、ユーザーはテーブル作成時に、ファイル構造に現れるデータの物理的編成にコミットする必要があります。カーディナリティが高すぎる列を選択すると、何十億もの小さなファイルが生成されます。間違った列を選択すると、クエリは遅くなる可能性があります。いずれにせよ、テーブルを書き直すしかありません。間違いはよくあります。私たちの分析では、Hiveスタイルのパーティショニングは、75%以上のケースで過剰なパーティショニングと小さなファイルの問題につながります。

Liquidは、クラスタリングキーを、エンジンが最適なファイル編成をガイドするために使用する入力として扱います。キーはいつでも変更したり、Automatic Liquid Clusteringを通じてインテリジェントに選択したりできます。カーディナリティは制約ではなく、不要な書き換えなしにレイアウトを時間とともに進化させることができます。

Liquid Clusteringの利点はすべて上記の原則から派生します。つまり、優れたスキュー処理、行レベルの同時実行性、小さなファイルの問題なし、多次元クラスタリング、および低い書き込み増幅です。

2026年までに、レイアウトはテーブルの実装詳細であるべきであり、読み書きするすべてのエンジンがそれから恩恵を受けるべきです。エージェントがレイクハウスに入り、これまで以上に多くのデータを生成および消費するにつれて、これはますます重要になっています。人間とエージェントは、Hiveスタイルのパーティショニングの潜在的な副作用のない、許容的なインターフェイスを必要としています。

一般的なデータレイアウトの誤解8つを解き明かす

Liquid Clusteringは2024年に一般提供が開始されました。それ以来、私たちは顧客と協力して、あらゆる規模で継続的に改良を重ねてきました。その間、Liquid Clusteringとパーティショニングに関する一般的な誤解がいくつか残っています。今日はそれらを解き明かしたいと思います。

誤解 #1: パーティショニングはディレクトリをファイルよりも先に除外できるため、より高速です

誤解の内容: パーティショニングを使用すると、Sparkやその他のエンジンは、内部のファイルを開くことなく、ディレクトリ全体を除外できます。

現実: ディレクトリの除外は、DeltaやIcebergのような最新のオープンテーブルフォーマットでは存在しません。例えばDeltaは、各データファイルと列ごとの統計情報を追跡するためのトランザクションログを使用しており、除外はディレクトリ構造ではなく、それらの統計情報に対して行われます。エンジンはクエリを計画するためにディレクトリを一覧表示しません。トランザクションログを読み取り、統計情報に対してフィルタを評価し、一致しないファイルをスキップします。Liquid Clusteringも同じメカニズムを使用します。データが`date=x/hour=y/`にあるか、クラスタ化されたファイルのフラットなディレクトリにあるかに関わらず、エンジンはファイル単位で除外します。失うべきディレクトリレベルのショートカットはありません。

誤解 #2: 低カーディナリティ列でフィルタリングする場合、パーティショニングの方が優れています

誤解の内容: 異なる値の数が少ない列の場合、パーティショニングは完璧なデータ分離と良好なファイルサイズを提供します。

現実: Liquid Clusteringは、低カーディナリティの最適化を適用するタイミングを自動的に検出します。例えば、(date, user_id)でクラスタリングし、dateのカーディナリティが低い場合、システムは各ファイルが単一の日付の行のみを含むように目指します。user_idのような高カーディナリティの列は、他のソート技術（Z-Orderingなど）に依存することなく、各日付のファイル内でより細かい粒度のソートに使用されます。

実際のデータウェアハウジングベンチマークでこのLiquid最適化をベンチマークしたところ、クラスタリング時間の35%削減とクエリ時間の22%高速化が見られました。

さらに、Liquid Clusteringは、高カーディナリティの列でクラスタリングする場合、常に良好なサイズのファイルを作成しようとするため、パーティショニングよりも優れています。

誤解 #3: Liquid Clusteringはメタデータのみの操作をサポートしていません

誤解の内容: メタデータのみの操作は、パーティショニングによってのみサポートされます。パーティション境界に合わせたDELETEはテーブルのメタデータのみを更新し、パーティション列の集計はファイルをスキャンせずに計算できます。Liquid Clusteringは同じことはできません。

現実: Liquid Clusteringは、DELETE、COUNT、DISTINCT、GROUP BYクエリを含むメタデータのみの操作もサポートしています。エンジンは、データスキップに使用するファイルごとの最小/最大統計情報を使用して、クエリの回答がメタデータからのみ計算できるかどうかを判断します。私たちのベンチマークでは、Liquid ClusteredテーブルでのメタデータのみのDELETEは、フルリライトDELETEよりも約90%高速に実行されました。その他のメタデータのみの集計クエリでは、最大27倍の高速化が見られました。

誤解 #4: Liquid Clusteringはペタバイト規模ではうまく機能しません

誤解の内容: PB規模のテーブルでのOPTIMIZEは数時間かかる可能性があり、メンテナンスコストが高すぎます。

現実: OPTIMIZEにいくつかの重要な改善を加え、数十の顧客が本番環境でPB規模のLiquid Clusteredテーブルを運用しています。2年前、OPTIMIZEの最初のフェーズである計画は、場合によっては10 PBのLiquidテーブルで最大12時間かかることがありました。それ以来、計画時間を23分に短縮しました。OPTIMIZEの2番目のフェーズである実行は、Medium DBSQLクラスターで5倍高速になりました。

誤解 #5: Liquid Clusteringは一部のリーダーにしかメリットがありません

誤解の内容: Liquid Clusteringは、UC管理DeltaテーブルのDatabricksリーダーにのみ役立ちます。

現実: Liquid Clusteringは書き込み側の最適化です。これは、エンジンが効率的なデータスキップのためにファイルを編成する方法です。出力は、Delta/Icebergのようなオープンテーブルフォーマットに書き込まれた、最小/最大統計情報を持つ標準的なParquetファイルです。互換性のあるリーダー（例: オープンソースApache Spark、DuckDBなど）は、それらの統計情報を使用してファイルをスキップできます。Liquid Clusteringは、外部/管理Delta/ Icebergテーブルの両方で利用可能であり、リーダーに関係なく利点が適用されます。

誤解 #6: 同時実行ETLにはパーティショニングが必要です

誤解の内容: 同時実行ETLには書き込み境界が必要です。パーティショニングがないと、同じテーブルを更新する2つのライターは衝突するリスクがあり、Delta/Icebergの同時実行制御により、どちらかがリトライまたは失敗します。パーティション化して各ライターにテーブルの独自のセグメントを与えれば、2つのパイプラインが同じファイルに触れることはありません。

実際：パーティション単位での操作は、古い同時実行モデルの回避策でした。ファイルレベルの同時実行しか持たないパーティション分割とは異なり、Liquidは行レベルの同時実行を提供します。異なる行を更新する2つのライターは、それらの行が同じファイル内に存在する場合でも、もはや競合しません。これにより、チームがテーブルをパーティション分割する主な理由の1つであった、シリアライゼーションを回避するための書き込み境界の維持が不要になります。Liquid Clusteringを使用すると、ETLは同じテーブルに対して簡単に並行して操作できます。

神話7：Z-Orderingはパーティション分割の短所を補う

神話の内容：パーティション分割はパーティション列のフィルターを処理し、Z-Orderingが残りを処理します。OPTIMIZE ZORDER BYを実行することで、エンジンはパーティションスキームに一致しないフィルターでの最適なスキップのためにデータをソートします。

実際：Z-Orderingはパーティション分割を救いません。実際、それ自体に構造的な問題があります。

• 1つ目はクラスタリング品質の低さです。Z-Orderはテーブル全体で真の順序を維持しません。同じ列の値が多数のファイルに分散する可能性があるため、ファイルごとの最小/最大範囲が広くなり、クエリはLiquidを使用した場合よりも少ないファイルをスキップします。
• 2つ目は不要な書き直しです。Z-Orderは新しいデータが着信するにつれて定期的に再実行する必要があり、各再実行はクラスタリング品質を回復するために、大量の古い、おそらく既にクラスタリングされたデータを書き直します。継続的な取り込みでは、Z-Orderでデータを適切にクラスタリングし続けるコストは、テーブルとともに増加します。

Liquidは書き込み時を含むインクリメンタルにクラスタリングされるため、レイアウトは不要な書き直しなしで最適化されたままになります。

神話8：パーティション分割は選択的なデータの上書きに必要

神話の内容：選択的にデータを上書きできるのは、Dynamic Partition Overwritesを通じてのみです。

実際：選択的な上書きは、Liquidテーブルでネイティブに機能します。Databricksは、Liquid Clustered、パーティション分割、または通常の非クラスタリングテーブルのいずれのデータレイアウトでも、データを選択的に上書きするための2つのSQL構文であるREPLACE USINGとREPLACE ONをサポートしています。Spark構成を必要とするDynamic Partition Overwriteとは異なり、REPLACE USINGとREPLACE ONは、クラシッククラスター、SQLウェアハウス、およびServerlessのいずれのコンピューティングでも使用できます。操作はアトミックであり、選択した任意の列に一致します。

成功事例：パーティション分割からLiquid Clusteringへの移行

Arctic Wolfの3.8 PBセキュリティテレメトリテーブルでクエリ速度が7.7倍に向上

Arctic Wolfは、1日あたり1兆件以上のイベントを取り込む3.8 PB超のセキュリティテレメトリテーブルを実行しており、脅威ハンターはアクティブな攻撃を検出するために最新のデータに依存しています。

Unity CatalogマネージドテーブルでPredictive Optimizationを使用したパーティション分割からLiquid Clusteringに移行した後、Arctic Wolfは次のような結果を得ました。

• 90日間のクエリが51秒から6.6秒に短縮
• ファイル数が400万から200万に減少
• データの鮮度が数時間から数分に向上

Boltの重要なCDCテーブルでの読み書きパフォーマンスの向上

Boltは最近、Liquid Conversion（現在プライベートプレビュー中）を試しました。これは、ALTER TABLE .. REPLACE PARTITIONED BY WITH CLUSTER BYを使用して、パーティション分割されたテーブルをインプレースでLiquidに変換します。TBスケールのCDCテーブルをLiquid Clusteringに変換した後、次の読み書きのメリットを観察しました。

• 書き込みスループット（行/秒）が138％増加
• 読み取り時間が最大63％短縮され、9つの代表的なクエリの平均短縮率は21％でした

Liquid Clusteringは、各書き込みのワークロードを劇的に削減し、最も重要なCDCテーブルのスループットを大幅に向上させました。読み取りも全体的に改善されました。最も良かったのは、ダウンタイムなしで、ライブ取り込みと並行して変換を実行したことです。これにより、Liquid Clusteringはプラットフォームスケールで必要としていたパフォーマンスと信頼性を提供してくれました。 — Boltのシニアプラットフォームエンジニア、Marcin

ペタバイトスケールの内部ワークロードでクエリ時間が5.9倍に短縮

内部で1.1 PBのテーブルを実行しており、これは1日に数千回クエリされ、主にエンジニアが本番環境の調査やオブザーバビリティダッシュボードを実行するために使用しています。当初はdateとhourでパーティション分割されていました。これは、時間範囲スキャンが支配的であるという仮定に基づいています。しかし、その仮定は不完全であることが判明しました。時間範囲スキャンは一般的でしたが、テーブルはsourceとidでも頻繁にクエリされ、関連する日付と時間のパーティション内のすべてのファイルをスキャンして少数の行を見つける必要がありました。

sourceとidをパーティションとして追加することは、値が多すぎるため現実的ではありませんでした。これにより、数十億の小さなファイルが作成されたでしょう。Liquid Clusteringはトレードオフをなくし、時間および追加の識別子列を同時にクラスタリングできるようにし、良好なファイルサイズを維持しました。

ベンチマークでは、16の代表的な本番クエリ全体で大幅な改善が見られました。

テーブル自体のサイズも小さくなりました。合計サイズは1.1 PBから0.8 PBに減少し、27%削減されましたが、基盤となるデータは変更されていません。より適切にクラスタリングされたファイルはより効率的に圧縮され、過剰なパーティション分割に伴う小規模ファイルの問題が解消されます。

Liquid Clusteringの今後の展望

Liquid-to-Liquid結合の最適化：最大51%高速化、シャッフルを87%削減

現在、Liquidテーブルをクラスタリング列で結合する場合、データが既にそれらの列で整理されている場合でも、完全なデータシャッフルが必要になることがあります。Co-clustered joins（現在プライベートプレビュー中）は、そのシャッフルを自動的に削除します。実際のデータウェアハウジングベンチマークでは、Liquid-to-Liquid結合は、最適化なしの場合と比較して、約51%高速化（28分→14分）し、シャッフルされるデータ量が87%削減（1.2 TiB→150 GiB）されました。

パーティション分割テーブルの簡単なLiquid変換

以前は、パーティション分割テーブルをLiquid Clusteringに変換するには、テーブル全体の書き直しと、REPLACE TABLEによるダウンストリームの破壊的変更、またはデュアル書き込みと計画的なダウンタイムを伴うカットオーバーが必要でした。この変換を容易にし、ダウンタイムと書き直しを最小限に抑える新しいコマンド（現在プライベートプレビュー中）を導入します。

Liquid Clusteringの開始方法

Liquid Clusteringを使用してテーブルを作成します。

または、Predictive Optimizationを使用しているUCマネージドテーブルを使用している場合は、ワークロードとクエリパターンに基づいてクラスタリングキーをインテリジェントに選択するAutomatic Liquid Clusteringを使用します。

Liquid Clusteringは、最新のLakehouseのレイアウトです。次のテーブルで試すか、パーティション分割からLiquidへの変換およびCo-Clustered joinsのプライベートプレビューを試すために、今すぐアカウントチームに連絡してください！

DAISでお会いできるのをお楽しみに！

• Optimize Lakehouse Cost and Performance with Intelligent Storage and Liquid Clustering

(このブログ記事はAI翻訳ツールを使用して翻訳されています) 原文記事