確認問題｜Associate ⑥ 最適化・トラブルシューティング

教材 06-optimization.md の内容に基づく確認問題です（全10問）。 まず問題を解き、下の「解答・解説」で答え合わせをしてください。

問題

Q1. OPTIMIZE コマンドの主目的と性質として、正しい説明はどれですか。

• A. 小さいファイルを均等なサイズの大きいファイルに結合（ビンパッキング／コンパクション）する。同じデータに2回実行しても2回目は効果がない（べき等）。
• B. テーブルの物理行を削除して行数を減らし、ストレージ容量を圧縮する。
• C. 未使用の古いデータファイルを削除して、タイムトラベル可能範囲を縮める。
• D. データの中身を書き換えて集計値を事前計算し、読み取り結果を変える。

Q2. ある Delta テーブルに、ストリーミング書き込みによって毎分ごく小さいファイルが大量に生成され、クエリが「ファイルごとのオーバーヘッド」で遅くなっています。この「small files 問題」への対処として教材が挙げているものはどれですか。

• A. すべての列に対して手動でパーティション分割を追加する。
• B. OPTIMIZE（コンパクション）や自動圧縮、最適化された書き込みでファイルを結合する。
• C. VACUUM を毎分実行して小さいファイルを削除する。
• D. Spark キャッシュ（.persist()）でテーブル全体をメモリに保持する。

Q3. ZORDER BY と液体クラスタリング（CLUSTER BY）の関係について、教材の記述として正しいものはどれですか。

• A. ZORDER BY は液体クラスタリングのある新規テーブルで併用して使うのが推奨である。
• B. 液体クラスタリングはパーティション分割や ZORDER と自由に併用でき、両方同時に指定できる。
• C. ZORDER BY は液体クラスタリングのない Delta テーブルで使う手法で、新規テーブルには液体クラスタリングが推奨される。液体クラスタリングはパーティション・ZORDER と併用不可。
• D. 液体クラスタリングは既存データをすべて書き換えないとキーを変更できない。

Q4. 液体クラスタリングのクラスタリングキーの選び方について、教材の記述として正しいものはどれですか。

• A. キーは最大4つまで指定でき、統計が収集された列（既定で先頭32列）から、クエリフィルターで最もよく使う列を選ぶ。
• B. キーは列数無制限で、多いほど常に性能が上がる。
• C. キーには複合型（Struct/Map/Array）そのものを指定するのが推奨される。
• D. 生成列（タイムスタンプから作った日付列など）を優先的にキーにする。

Q5. CLUSTER BY AUTO（自動液体クラスタリング）が利用でき、キーを自動選択できるテーブルの条件はどれですか。

• A. 外部テーブル（external table）であること。
• B. Hive メタストアのパーティションテーブルであること。
• C. Unity Catalog のマネージドテーブルであること（履歴クエリを分析しコスト対応でキーを自動選択）。
• D. パーティション分割と ZORDER の両方が有効なテーブルであること。

Q6. Unity Catalog マネージドテーブルで「予測的最適化（predictive optimization）」を有効にしたとき、Databricks が自動実行するメンテナンス操作の組み合わせとして正しいものはどれですか。

• A. OPTIMIZE / VACUUM / ANALYZE
• B. MERGE / DELETE / UPDATE
• C. CREATE TABLE / DROP TABLE / ALTER TABLE
• D. CACHE / UNCACHE / REFRESH

Q7. VACUUM の既定の保持期間と、その影響について正しい説明はどれですか。

• A. 既定の保持期間は24時間で、実行してもタイムトラベルには一切影響しない。
• B. 既定の保持期間は7日間（168時間）で、実行後は指定保持期間より古いバージョンにタイムトラベルできなくなる。保持を短くしすぎると未コミットファイル削除の危険がある。
• C. 既定の保持期間は30日間で、_delta_log ディレクトリのファイルも削除対象になる。
• D. 既定の保持期間は無期限で、明示的に日数を指定しない限り何も削除されない。

Q8. Spark UI のステージ詳細ページで「スキュー（skew）」を疑うべき目安として、教材が挙げている基準はどれですか。

• A. Summary Metrics で、タスク所要時間の中央値（median）が最小値の2倍以上のとき。
• B. Summary Metrics で、タスク所要時間の最大（Max）が75パーセンタイルより50%以上長いとき。
• C. Spill (Memory) が Spill (Disk) を上回っているとき。
• D. ステージ数がタスク数より多いとき。

Q9. あるジョブが遅く、Spark UI の最長ステージを開くと、ステージ詳細ページ上部の統計に「Spill (Memory)」「Spill (Disk)」の値が表示されていました。この症状の原因と、教材が示す対処の方向性として最も適切なものはどれですか。

• A. 原因はディスク容量不足。パーティションを増やしてファイルを分割すれば解消する。
• B. 原因はメモリ不足によるメモリ→ディスクへの退避（スピル）で、シャッフル中に起きやすい。AQE を有効に保つ、より大きい／垂直スケールしたクラスターを使う、データスキップ／液体クラスタリングでシャッフル量を減らす、などで対処する。
• C. 原因は統計不足。ANALYZE TABLE を実行すればスピルは必ず解消する。
• D. スピルは正常動作であり、対処は不要。表示が出ても無視してよい。

Q10. 比較的小さいデータ（<10 GB）に対して多数の小さな操作が積み重なり、「操作ごとのオーバーヘッド」が支配的になって全体が遅い、というワークロードがあります。教材が示す最善の対処方針はどれですか。

• A. 各操作を1つの巨大な逐次処理にまとめ、直列で順番に実行する。
• B. すべての操作をより大きい単一マシンで垂直スケールして1タスクずつ実行する。
• C. 複数操作を並列実行する（複数タスクジョブ、SQL ウェアハウス、widgets＋for each タスク＋コンカレンシー等。Lakeflow パイプラインは自動で並列化）。
• D. VACUUM の保持期間を短くしてファイル数を減らす。

解答・解説

Q1. 正解: AOPTIMIZE は多数の小さいファイルを、ストレージ上のサイズが均等でより大きいファイルに結合する「ビンパッキング（コンパクション）」を行います。この処理はべき等で、同じデータに2回実行しても2回目は効果がありません。データの中身は変えないため読み取り結果は前後で不変で、B・C・D は誤りです。

Q2. 正解: B small files 問題は、小さいファイルが大量にあるとファイルごとの処理オーバーヘッドで読み取りが遅くなる問題です。対処は OPTIMIZE（ビンパッキング）に加え、書き込み後に自動でファイルを結合する「自動圧縮」、書き込み時にファイルサイズを改善する「最適化された書き込み」です。VACUUM は未使用ファイル削除で、small files の結合手段ではありません。

Q3. 正解: CZORDER BY は液体クラスタリングのない Delta テーブルで、OPTIMIZE ... ZORDER BY (col) の形で使う多次元クラスタリング手法です。Databricks はすべての新規テーブルに液体クラスタリングを推奨しています。液体クラスタリングはパーティション分割・ZORDER と併用不可で、かつ既存データを書き換えずにキーを再定義できる（増分的）点が特徴です。

Q4. 正解: A クラスタリングキーは最大4つまで指定でき、クエリフィルターで最もよく使う列を選びます。キーは統計が収集された列（既定で先頭32列の統計を収集）である必要があります。複合型（Struct/Map/Array）そのものはキーにできず、生成列ではなく元の列をキーにするのが指針なので、B・C・D は誤りです。

Q5. 正解: CCLUSTER BY AUTO（自動液体クラスタリング）は Unity Catalog のマネージド Delta テーブルで利用できます。履歴クエリワークロードを分析して最適な候補列を識別し、データスキップによる削減がクラスタリングコストを上回るときだけキーを変更する「コスト対応」で動作します。外部テーブルや Hive パーティションテーブルは対象外です。

Q6. 正解: A 予測的最適化は、Unity Catalog がマネージドテーブルの読み書き・クエリパターンを把握し、レイアウト最適化＝OPTIMIZE、古いファイルのクリーンアップ＝VACUUM、統計収集＝ANALYZE（およびクラスタリング更新）を実際の使われ方に応じて自動実行します。これにより手動メンテナンスが不要になり、Databricks はすべての UC マネージドテーブルで有効化を推奨しています。

Q7. 正解: BVACUUM は参照されなくなった未使用データファイルを削除し、既定の保持期間は7日間（168時間）です。実行後は指定保持期間より古いバージョンにタイムトラベルできなくなります。保持を短くしすぎると、実行時間の長いジョブが書き込んだ未コミットファイルが完了前に削除される危険があり、7日以上が強く推奨されます。_ で始まるディレクトリ（_delta_log 含む）はスキップされます。

Q8. 正解: B スキューは1つ（少数）のタスクだけが他より極端に時間がかかる状態です。Spark UI のステージ詳細ページの Summary Metrics でタスク所要時間の最小/25%/中央値/75%/最大を確認し、健全なステージでは75パーセンタイルと最大がほぼ同じになります。最大が75パーセンタイルより50%以上長い場合はスキューの可能性が高いと判断します。

Q9. 正解: B スピルは Spark がメモリ不足のときデータをメモリからディスクへ退避する処理で、非常にコストが高く、データシャッフル中に最も起きやすい現象です。ステージ上部に Spill (Memory)/Spill (Disk) が表示されればシャッフル起因のスピルへの対処が必要です。対処は AQE を有効に保つ（スキュー・パーティション結合を動的最適化）、より大きい／垂直スケールしたクラスター、データスキップ／液体クラスタリングでシャッフル量を減らす、などです。

Q10. 正解: C これは「多数の小規模な Spark ジョブ」の症状で、各操作は数秒でも積み重なると操作ごとのオーバーヘッドが支配的になります。最善策は複数操作を並列実行することです。具体的には、複数ノートブックを複数タスクジョブで同一クラスター上に並列実行、すべて SQL なら SQL ウェアハウスを使う、widgets でパラメータ化し for each タスク＋コンカレンシーで並列実行、などがあり、Lakeflow パイプラインはこれを自動で行います。