プロンプトと範囲
ある Iceberg テーブルは日付とテナントごとに構成されています。クエリはカーディナリティの低いステータス列を頻繁にフィルタリングしますが、プランニングでは依然として多くのデータファイルが検査されます。チームはマニフェストに直接収まらないインデックスや統計を Puffin ファイルに格納し、プランナーがそれらを選択的に使用できるようにしたいと考えています。スナップショットバインディング、古い統計の保護、統計の欠落、並行コミット、そして高速化が正確性を損なわないことの証明について説明してください。
容量、選択性、およびファイル数は面接用の前提条件であり、普遍的なベンチマークではありません。この質問は、データエンジニアリング、レイクハウスストレージ、クエリエージェント、およびデータプラットフォームの役割に適しています。その核となるスキルはテーブルフォーマットのメタデータとプランニングであるため、data に属します。
面接官が評価するポイント
第一に、Puffin の境界を理解しているか？Puffin は Iceberg テーブルに関するインデックスと統計のためのファイルフォーマットであり、blob メタデータはその内容を記述します。テーブルのスナップショットやマニフェストを置き換えるものではありません。
第二に、オプショナルな最適化と正確性のためのメタデータを分離できるか？リーダーは統計を無視しても正しく読み取ることができます。プルーニング（不要なファイルの除外）では、一致しないことが証明された候補のみを削除する必要があります。
第三に、統計をスナップショットとスコープにバインドできるか？すべての blob には適用可能なスナップショット、パーティション、またはデータファイル範囲が必要です。更新によって古い blob が盲目的に再利用されてはなりません。
第四に、メンテナンスコストを定量化できるか？追加のファイルはオブジェクトストレージの I/O、キャッシング、生成ジョブ、および有効期限切れ処理を増加させます。選択性の低いクエリでは、メリットなしにプランニングオーバーヘッドが発生する可能性があります。
第五に、フォールバックを設計できるか？欠落、読み取り不能、互換性のない、または無効な blob がある場合、プランナーは空の結果を返すのではなく、マニフェストとデータファイルフィルターに戻る必要があります。
最初に明確にすべき質問
- どの Iceberg バージョンおよびクエリエージェントが対象の Puffin blob タイプをサポートしていますか？
- 統計はパーティション、データファイル、列、または値の範囲ごとに生成されますか？
- スナップショットはどのくらいの頻度でコミット、書き換え、またはタイムトラベルされますか？
- どの程度の生成遅延（staleness）が許容され、結果整合的な最適化は許容されますか？
- blob の圧縮、チェックサム、暗号化、およびオブジェクト権限はどのように管理されますか？
- プランナーは候補を除外しても安全であることをどのように証明しますか？
30秒の回答フレームワーク
「サポートされている Puffin blob タイプと、それらの Iceberg スナップショットとの関連付けを確認します。統計はオプショナルな最適化であり、正確性の前提条件ではありません。各 blob はそのスナップショット、パーティションまたはファイルスコープを記録し、欠落、古い、または読み取り不能な場合はプランナーがマニフェストにフォールバックします。生成ジョブは固定スナップショットを使用し、新しいスナップショットに古い統計を再利用するのではなく、参照をアトミックにコミットします。カナリアテストでは、候補ファイル、プランニング時間、追加の Puffin I/O、エンドツーエンドのレイテンシ、および結果の検証を比較します。」
ステップごとの回答
ステップ 1: Puffin とスナップショットの関係を確立する
Puffin は Iceberg マニフェストに直接収まらないインデックスと統計を保存します。StatisticsFile API は、パス、ファイルサイズ、フッターサイズ、blob メタデータ、および関連するスナップショット ID を公開します。外部設定にオブジェクトパスのみを保持するのではなく、これらのフィールドをメタデータコントラクトに含めます。
ステップ 2: blob の内容とスコープを定義する
各 blob は、タイプ、バージョン、エンコーディング、対象パーティションまたはデータファイル、生成スナップショット、列、および比較ルールを宣言する必要があります。カーディナリティの低いステータス列には、パーティションカウントや値範囲サマリーを使用できます。安全でない高カーディナリティのサマリーは、ファイルをプルーニングするためではなく、観察用にとどめる必要があります。
statistics = build_from_snapshot(snapshot_id, data_files)
blob = {
type, version, snapshot_id, partition_scope,
covered_files, column_rules, checksum, payload
}
commit_statistics_file(blob)ステップ 3: 安全なプルーニングを設計する
プランナーは、統計によって一致しないことが証明された場合にのみ候補を除外します。統計の欠落、値範囲の重複、不確実な null セマンティクス、未知の blob バージョン、またはチェックサムの失敗はすべて、マニフェストおよびデータファイルによるフィルタリングをトリガーします。「統計なし」が「データなし」を意味してはなりません。
ステップ 4: 並行コミットと遅延に対処する
生成ジョブは固定スナップショットを読み取り、コミット時にテーブルがそのスナップショットまたは互換性のある子孫を引き続き参照できることを検証します。新しい書き込み、削除、およびパーティションの進化によってファイルセットが変更されます。古い blob はその宣言されたスコープに対してのみ有効です。Puffin オブジェクトをインプレースで更新しないでください。
ステップ 5: 読み取りを計画し安全にキャッシュする
Puffin 自体にもフッターと blob の I/O があります。プランナーは軽量なメタデータを使用して blob を読み取る価値があるかどうかを判断し、クエリ列とパーティションに基づいて blob を選択する必要があります。キャッシュキーにはテーブル ID、スナップショット、blob タイプ、およびバージョンを含めます。読み取りエラーが発生した場合はキャッシュを無効化してフォールバックします。エラーを空の統計としてキャッシュしてはなりません。
ステップ 6: コスト、有効期限、および権限を管理する
blob バイト数、フッター比率、生成 CPU、オブジェクトリクエスト、およびプルーニングヒット率を追跡します。スナップショットの期限切れまたはファイルの書き換え後は、オブジェクトの変更時間だけでなく、参照関係によって統計をクリーンアップします。ジェネレーターとリーダーに最小権限のアクセスを付与し、チェックサムを検証し、必要に応じて機密サマリーを暗号化します。
ステップ 7: カナリア受け入れテストを実行する
同じスナップショット上で、統計が有効な場合と無効な場合でプランニングを比較します（候補ファイル数、スキャンバイト数、プランニング p50/p95、追加の Puffin I/O、エンドツーエンドのレイテンシ、および結果のハッシュ）。blob の削除、バージョンの不一致の作成、並行コミットとの競合を発生させ、フォールバックが完全な結果を返すことを証明します。ネガティブコントロールとして選択性の低いクエリを保持します。
モデル回答
「Puffin をオプショナルなプランニング高速化レイヤーとして扱います。ジェネレーターは固定スナップショットを読み取り、blob メタデータはスナップショット、パーティションまたはファイルスコープ、列ルール、バージョン、およびチェックサムを記録します。新しいスナップショットは、その宣言されたスコープ外で blob を再利用してはなりません。
プランナーは、統計によって不一致が安全に証明された場合にのみプルーニングします。欠落、古い、読み取り不能、null の扱いが曖昧、または未知のバージョンの blob は、マニフェストおよびデータファイルフィルターにフォールバックします。統計の欠落が空の結果を意味することは決してありません。キャッシュキーにはテーブル、スナップショット、タイプ、およびバージョンを含めます。
カナリアテストでは、欠落 blob や並行コミットを注入しながら、候補ファイル、プランニング時間、Puffin I/O、エンドツーエンドの p95、および結果ハッシュを比較します。パフォーマンスの向上が安定し、フォールバックが正確であり、メンテナンスコストが許容可能な場合にのみ適用を拡大します。」
よくある間違い
- Puffin をスナップショットの信頼できる情報源（Single Source of Truth）として扱う → 古い統計が結果を変えてしまう → マニフェストへのフォールバックを備えたオプショナルなものとして維持する。
- オブジェクトパスのみを記録する → スコープとスナップショットをチェックできない → 完全な blob メタデータを保存する。
- 古い blob でプルーニングを行う → 新しい書き込みや削除が見落とされる → スナップショットと対象ファイルをバインドする。
- 統計欠落に対して空の結果を返す → 不明な状態が不一致と判定される → 通常のフィルタリングにフォールバックする。
- Puffin をインプレースで上書きする → 並行リーダーが混在したバージョンを参照する → 新しいファイルを書き込み、アトミックに参照する。
- スナップショットなしでキャッシュする → 異なるスナップショットが誤った統計を再利用する → キーにバージョンとスナップショットを含める。
- プランニング時間のみを測定する → スキャン結果が変わる可能性がある → 候補セットと結果ハッシュを比較する。
- 変更時間に基づいて削除する → 保持されているスナップショットが引き続きファイルを参照している可能性がある → 参照に基づいて期限切れ処理を行う。
フォローアップの質問
フォローアップ 1: なぜリーダーは統計を無視してもよいのですか？
Puffin 統計は情報提供を目的としています。テーブルはマニフェストとデータファイルから依然として正しく読み取ることができるため、サポートされていない blob や一時的に読み取れない blob は透過的なフォールバックをトリガーする必要があります。
フォローアップ 2: 統計をどのように失効（expire）させますか？
保持されているスナップショット、ブランチ、またはタグが blob の対象範囲を必要としないことを確認し、テーブルフォーマットの参照に従ってクリーンアップします。オブジェクトの変更時間だけでは不十分です。
フォローアップ 3: 値の範囲が不完全な場合はどうなりますか？
不明な部分を一致する可能性があるものとして扱い、候補を広げるか完全にフォールバックします。最適化において偽陽性（過剰な候補選択）は許容されますが、偽陰性（誤った除外）は決してあってはなりません。
フォローアップ 4: 並行書き込み中の統計はいつ生成されるべきですか？
コミットされたスナップショットから生成し、メタデータコミット後にバインドします。実行中の書き込みによる一時ファイルがプランニングから見えてはなりません。コミット時に互換性を再確認します。
フォローアップ 5: Puffin の価値がないのはどのような場合ですか？
選択性が低い場合、blob I/O がマニフェストの削減効果を上回る場合、生成が古すぎる場合、またはメンテナンスコストがメリットを上回る場合は、無効化または範囲を狭めます。テーブルごとの切り替えスイッチを保持します。
フォローアップ 6: 最適化が結果の正確性を維持していることをどのように証明しますか？
統計を有効および無効にした状態で同じスナップショットに対して同等のクエリを実行し、完全な結果、集計、候補ファイル、および境界サンプルを比較します。その後、欠落、破損、および互換性のない blob を注入してフォールバックをテストします。