テーブルは増える一方で、減りません。EP.18 で扱ったカタログの問題も、指標設計の教科書 EP.22 で扱った指標の問題も、根は同じです。
この回は、使われなくなったものを消せる状態をどう作るかを扱います。連載の締めくくりとして、運用の話をします。
1. なぜ消せないのか
消せない理由は、確信が持てないからです。そして確信を持つための情報がありません。
| 不安 | 確認できるか |
|---|---|
| 誰かが使っているかもしれない | 記録があれば確認できる |
| 年次処理で使うかもしれない | 1年分の記録が要る |
| 外部から参照されているかもしれない | 記録の範囲による |
| 消したときに何が壊れるか分からない | 依存関係が分かれば確認できる |
| また作り直すことになるかもしれない | 定義を残せば作り直せる |
ほとんどが「情報があれば解決する」種類の不安です。逆に言えば、記録を取っていないと永久に消せません。そして は増え続けるため、時間が経つほど整理が難しくなります。早く記録を取り始めるほど有利になる構造です。
参照の記録が無い環境では、この回の内容は実行できません。まず記録を取り始めて、1年待つ。遠回りに見えますが、それ以外に確実な方法はありません。今日から取り始めれば、来年には判断できます。
2. 消す候補を洗い出す
記録があれば、機械的に候補を出せます。
WITH refs AS ( SELECT table_name, MAX(accessed_at) AS 最終参照, COUNT(*) AS 参照回数, COUNT(DISTINCT user_id) AS 参照者数 FROM query_access_log WHERE accessed_at >= DATEADD(day, -365, CURRENT_DATE()) GROUP BY table_name),deps AS ( -- この表を参照している他の定義の数 SELECT referenced_table AS table_name, COUNT(*) AS 被参照定義数 FROM model_dependencies GROUP BY referenced_table)SELECT t.table_name AS テーブル, ROUND(t.bytes / POWER(1024, 3), 2) AS GB, t.created AS 作成日, COALESCE(r.参照回数, 0) AS 参照回数, COALESCE(r.参照者数, 0) AS 参照者数, r.最終参照, COALESCE(d.被参照定義数, 0) AS 被参照定義数FROM tables tLEFT JOIN refs r ON r.table_name = t.table_nameLEFT JOIN deps d ON d.table_name = t.table_nameWHERE COALESCE(r.参照回数, 0) = 0 -- 1年間、参照なし AND COALESCE(d.被参照定義数, 0) = 0 -- 他から参照もされていないORDER BY t.bytes DESC;2つの条件を組み合わせているのが要点です。人が参照していないだけでなく、他の定義から参照されていないことも確認します。片方だけでは不十分です。
そして、容量の大きい順に並べます。消す手間は同じなので、効果の大きいものから扱うのが合理的です。
3. 段階を刻んで消す
候補が出ても、いきなり削除しないでください。レガシー再生の現場 EP.10 と同じ考え方で、段階を刻みます。
| 段階 | やること | 戻せるか | 期間 |
|---|---|---|---|
| 1. 予告 | 消す予定を周知 | — | 2週間 |
| 2. 改名 | `_deprecated_` を付ける | すぐ戻せる | 1か月 |
| 3. アクセス停止 | 権限を外す | すぐ戻せる | 1〜2か月 |
| 4. 退避 | 別の場所へ移す | 戻せる | 3か月 |
| 5. 削除 | 実体を消す | 戻せない | — |
2番目の改名が効きます。参照している処理があれば、その時点でエラーになります。しかも名前を戻すだけで復旧できる。低リスクで、確実に検出できる方法です。
消す前にわざと壊してみるという発想です。LLM時代のテスト戦略 EP.02 で扱った、コードにわざと変更を加えて検出できるか確かめる手法と同じ考え方です。壊れることを確認するのが目的です。
4. 消す前に残すもの
実体は消しても、残しておくべき情報があります。
- 1定義（作り方） — 作り直せるように
- 2なぜ作ったか — 同じものを再び作らないため
- 3なぜ消したか — 判断の記録
- 4消した日と、そのときの件数 — 後から確認できる
- 5データそのもの（必要なら） — 書き出して保管
2番目が地味に効きます。「なぜ作ったか」が残っていないと、数年後に同じ要望が来たときに、また一から作ります。当時なぜ作り、なぜ不要になったかが分かれば、今回も本当に必要かを判断できます。
5番目は判断が要ります。データを残すと保管費用がかかります。ただし Snowflake 実践ハンドブック EP.12 で扱ったとおり、書き出して固めれば費用はごく小さい。判断に迷うなら、書き出しておくのが安全です。 の設定も併せて見直してください。消す表の過去の版を保持し続ける意味はありません。
5. 増やさない設計
消す話をしてきましたが、そもそも増えにくくするほうが根本的です。
- 作るときに期限を決める — 「この分析が終わったら消す」
- 一時的な表は、置き場を分ける — 消してよい領域を明示
- 命名規則で用途を示す — `tmp_`、`work_` など
- 保持期間を短く設定する — 一時領域は最小に
- 定期的に自動で消す — 一時領域だけは自動化
2番目が最も実効性があります。「ここに置いたものは1か月で消える」という領域を作っておけば、そこに置く限り、消す判断が不要になります。判断を都度させるのではなく、置き場で決まるようにするのが要点です。人は判断を求められると先送りしますが、置き場を選ぶだけなら選べます。
1番目は データ屋の道具箱 EP.24 や Snowflake EP.07 でも同じことを書きました。作るときに終わりを決めておくという原則は、増えるものすべてに当てはまります。
6. 連載を振り返って
この連載では、基盤の設計から運用、そして廃棄までを扱ってきました。区切りとして、通底していたものを整理します。
| 論点 | 扱った回 |
|---|---|
| 同じ情報を2箇所に持たない | EP.14、EP.16 |
| 壊れたことに気づける状態を保つ | EP.17 |
| 増えるものには、減らす仕組みが要る | EP.18、EP.19 |
| 確認できない状態は、判断できない状態 | EP.15、EP.19 |
| 維持できない仕組みは迂回される | 連載全体 |
最下行が最も重要です。理想的な設計より、続けられる設計。厳密なアクセス制御も、網羅的なカタログも、完璧なデータ契約も、維持できなければ意味がありません。
「壊れないデータ基盤」というのは、壊れない構造を作ることではなく、壊れたときに気づき、直せる状態を保ち続けることだと考えています。
基盤の価値は、作ったときではなく、5年後に触れるかどうかで決まる。
消せないのは確信が持てないから。多くは記録があれば解決するので、記録が無いならまず取り始める。候補は人の参照と、定義からの参照の両方で確認する。消す前に改名して壊してみる（低リスクで確実に検出できる）。なぜ作ったかも残す（同じものを再び作らないため）。そして作るときに終わりを決めておくのが根本的な対処です。ここまでの内容への反応や、扱ってほしい論点があれば記事下のリアクションからお寄せください。続編は随時追加していきます。
この記事の感想を教えてください
あなたの 1 クリックで、本当にこの記事は更新されます。「もっと詳しく」「続編希望」が一定数集まった記事は、 ふくふくが 実際に内容を拡充したり続編記事を公開 します。 送信したリアクションはお使いのブラウザに記録され、再カウントされません。