データエンジニアリング面接：Delta Lake Liquid Clusteringの評価と移行をどのように進めるか？

プロンプトとシナリオ

あなたは、tenant_idとorder_dateでパーティショニングされ、Z-Orderingで維持管理されているDelta Lakeの注文ファクトテーブルを担当しています。テナントが増加するにつれて、小規模テナントのクエリでも依然として多数のファイルがスキャンされるため、チームはLiquid Clusteringを提案しています。監視するメトリクスを含め、この変更をどのように評価、移行、検証、およびロールバックするかを説明してください。

面接官が見ているポイント

機能を万能薬として扱うのではなく、実際の述語からレイアウトの問題を診断できるかどうか。
パーティショニング、Z-Ordering、Liquid Clusteringの間の互換性の境界を理解しているかどうか。
段階的な移行、増分メンテナンス、完全な書き換え、およびロールバックのガードレールを設計できるかどうか。
スキャンバイト数、ファイル数、p95レイテンシ、コストによって価値を証明できるかどうか。

最初に確認すべき明確化のための質問

主要なクエリは一貫してtenant_id、時間範囲、またはcustomer_idをフィルタリングしていますか？また、それらの述語の選択性はどの程度ですか？
使用しているDelta Lake、Spark/Databricksランタイム、およびリーダー/ライタークライアントのバージョンは何ですか？また、それらはLiquid Clusteringをサポートしていますか？
過去2週間の現在のパーティションおよびZ-Orderingのメンテナンス頻度、ファイルサイズ、スキャンバイト数、p95レイテンシはどのような状態ですか？
プラットフォームはバックグラウンドのOPTIMIZEコンピュートを吸収できますか？また、低トラフィック時間帯とロールバック用のコピーはありますか？

30秒で答える要約

まずクエリログから最も頻度が高く選択性の高いフィルタを確認し、シャドウテーブルで2週間の比較を実施します。Liquid Clusteringは既存の全データを書き換えることなく、今後の書き込みと最適化で使用されるレイアウトを変更できますが、従来のパーティショニングやZ-Orderingの代替となるため、まずバージョン、プロトコルの変更、ダウンストリームクライアントを検証します。移行後は増分OPTIMIZEを実行し、過去データが依然としてスキャンの大半を占める場合にのみOPTIMIZE FULLを使用します。同等のクエリをスキャンバイト数、ファイル数、p95、失敗率、コストで比較します。書き込み、並行性、ロールバックのテストもクリアした後にのみ展開を拡大します。

詳細解説

1. まずワークロードプロファイルを構築する

過去2週間のクエリをテンプレートごとに集計します。述語の組み合わせ、時間範囲、スキャンされたファイル数、スキャンバイト数、返された行数、p50/p95レイテンシ、実行コストを記録します。クエリにtenant_idが含まれることが多く、テナントサイズが大きく異なる場合、日付のみのパーティショニングでは小規模テナントに対しても多数のファイルにアクセスしてしまう可能性があります。述語が大きく変動する場合は、固定のクラスタリング選択が不安定になる可能性があるため、より多くの証拠を収集する間は現在のレイアウトを維持します。

2. クラスタリング列を選択し、セットを小さく保つ

データスキッピングの恩恵を受けられる、頻出かつ選択性の高いフィルタ列を優先します。低頻度の列や、述語でめったに使用されない高カーディナリティの列は、即座に本番環境で採用するのではなく候補にとどめます。Liquid Clusteringがサポートするクラスタリング列は最大4つです。列を増やしてもクエリが自動的に速くなるわけではなく、メンテナンスコストが増加します。1つの「最適な」クエリに対して最適化するのではなく、候補となる2〜3の組み合わせをオフラインでリプレイします。

3. 移行の境界と互換性チェックを定義する

公式ドキュメントではLiquid ClusteringがサポートされているDelta Lakeバージョンに紐づけられており、既存テーブルでの有効化手順はバージョンによって異なります。有効化する前に、エンジン、プロトコルアップグレードの影響、ストリーミング書き込み、増分読み取り、バックアップツール、古いクライアントを確認してください。Liquid Clusteringは従来のパーティショニングやZ-Orderingと併用できないため、移行計画では古いメンテナンスタスクを停止し、シャドウテーブルに対してレガシーコンシューマーを検証する必要があります。

4. 増分メンテナンスから開始し、完全な書き換えを判断する

クラスタリング列を変更しても、既存のすべてのデータが自動的に書き換えられるわけではありません。新しい書き込みとその後の最適化によって、新しいレイアウトの下でデータが整理されます。シャドウテーブルまたは低リスクのテーブルで有効にし、まず増分OPTIMIZEを実行して、新しいデータのファイルスキッピング動作を観察します。過去のファイルが依然としてスキャンの大半を占める場合は、OPTIMIZE FULLをスケジュールし、変更レビューにコンピュートコスト、ロックの競合、低トラフィック時間帯を含めます。

sql

CREATE TABLE fact_orders (
  tenant_id STRING,
  order_date DATE,
  customer_id STRING,
  amount DECIMAL(18, 2)
) USING DELTA
CLUSTER BY (tenant_id, order_date);

OPTIMIZE fact_orders;

ALTER TABLE fact_orders CLUSTER BY (tenant_id, customer_id);
OPTIMIZE fact_orders FULL;

5. 再現可能なベースラインに対して成果を検証する

クエリセット、データスナップショット、並行性、キャッシュ条件を一定に保ちます。移行前後でスキャンファイル数、スキャンバイト数、p50/p95レイテンシ、失敗率、書き込みスループット、クエリあたりのコストを比較します。合格基準の例としては、スキャンバイト数30%削減、p95を20%削減、書き込みコストの増加を10%以下に抑えることなどが挙げられます。これらはプロジェクトの例であり、ベースラインに合わせて調整する必要があります。また、単一のパスでリグレッションが見落とされないよう、時間範囲クエリ、テナント横断クエリ、バックフィル、並行最適化もテストします。

6. ロールバック、ガバナンス、継続的モニタリングを追加する

元のスナップショットまたはシャドウテーブルを保持し、最初は低トラフィック時に読み取りを切り替え、段階的に拡大します。クラスタリング列、バージョン、最適化バッチ、メトリクスを記録し、古いクライアントに対する互換性チェックを徹底します。p95、書き込みレイテンシ、またはコストがしきい値を繰り返し超える場合は、展開を一時停止し、読み取りルートを復元し、新しいレイアウトのメンテナンスを停止します。ロールバック後は、すぐに別の列セットを試すのではなく、述語とデータの偏りを再検討します。

完全で強力な回答

まずクエリログのベースラインを確立し、tenant_idと時間フィルタが実際にスキャンの大半を占めていることを確認した上で、シャドウテーブル上で2〜3のクラスタリング列の組み合わせをリプレイします。ロールアウト前に、Delta/Sparkのバージョン、プロトコルの動作、ストリーミングの読み書き、古いクライアントを確認します。これは、Liquid ClusteringがパーティショニングやZ-Orderingと併用できず、それらを置き換えるものであり、最大4列までしかサポートしていないためです。まず新しいデータを移行して増分OPTIMIZEを実行し、過去のファイルが依然としてスキャンを圧迫している場合は、低トラフィック時間帯にOPTIMIZE FULLをスケジュールします。スナップショット、一時停止スイッチ、読み取りルートのフォールバックを保持しながら、スキャンバイト数、ファイル数、p95、コスト、書き込みスループット、失敗率を基準にロールアウトを制御します。2つの観察期間をクリアした後にのみ展開を拡大し、違反があれば一時停止して見直します。

よくある失敗パターン

クエリベースラインや対照群なしに「Liquid Clusteringの方が速い」と述べるだけにとどまる。
パーティショニングやZ-Orderingとの非互換性を無視し、古いジョブを実行し続ける。
クラスタリング列の変更によってすべての過去データが即座に書き換えられると思い込み、増分または完全な最適化計画を立てない。
スキャンバイト数、p95、書き込みコスト、データの偏りを無視して、平均レイテンシのみを報告する。
バージョン、プロトコル、古いクライアント、ロールバックのチェックを行わずに本番テーブルで有効化する。

フォローアップと発展的な議論

フォローアップ1：一般的な4列すべてを定義に入れないのはなぜですか？

列数の上限を使い切ることが目的ではありません。余分な列はレイアウトのメンテナンスコストを増加させ、クエリの組み合わせ全体での効果を希薄化させる可能性があります。述語の頻度、選択性、リプレイ結果に基づいて、最小限の有効なセットを選択します。

フォローアップ2：既存のデータが改善されるまでにどれくらい時間がかかりますか？

固定の時間を約束してはいけません。列を変更しても既存のデータは自動的に書き換えられないため、回答は増分OPTIMIZEの適用範囲に依存します。過去データが支配的である場合は、OPTIMIZE FULLの時間帯とコストを評価します。

フォローアップ3：極端なテナントの偏りにはどのように対処しますか？

テナントの階層ごとにワークロードをリプレイし、大規模テナント、小規模テナント、テナント横断クエリを個別に比較します。必要に応じて列セットやクエリルーティングを調整し、全体の平均ではなく最悪のパーセンタイルを判定基準として使用します。

フォローアップ4：どのようなシグナルがあれば移行を中止しますか？

スキャンバイト数が一貫して減少しない、p95や書き込みコストが悪化し続ける、古いクライアントとの互換性がない、またはロールバックのリハーサルが失敗した場合は、展開を一時停止します。元のメンテナンスパスを復元し、ワークロード分析をやり直します。