DagsterでSnowflakeの100万列を9日間で機密分類した3段階設計

Dagsterは、Group 1001の担当者がSnowflake上の62データベース、100万を超える列を9日間でSPI、PII、非機密へ分類した事例を公開しました。

要点

• 正規表現、データ型、除外規則で明確な列を判定し、全体の95%以上を決定的な処理へ寄せます。
• SnowflakeのSYSTEM$CLASSIFYを第2の分類器として使い、結果を比較します。
• 曖昧な少数だけをSnowflake Cortexの対抗的なプロンプトへ送り、費用を抑えます。
• Dagsterのアセット、センサー、fan-outとfan-inで定期処理と人手修正を同じタグ付け経路へ統合します。

今回のブログ記事で語られていること

Group 1001は、別々に成長した業務システムを一つのSnowflakeアカウントへ移行しており、62データベースに100万を超える列がありました。規制対象の保険事業を含むため、各列を機密個人情報、個人識別情報、非機密へ分類し、そのタグをマスキングとアクセス制御へつなぐ必要があります。すべての列を言語モデルへ送ると時間と費用が増え、結果の説明もしにくくなります。事例は、安価で再現可能な規則を先に使い、判断が難しい少数だけへ高価な推論を使う3段階構成です。

第1段階は列名の正規表現、データ型、業務上の除外規則です。第2段階でSnowflakeのSYSTEM$CLASSIFYを独立した分類器として動かします。二つが一致する明確な列を確定し、曖昧な列だけをCortexへ送ります。Cortexでは、単に分類を求めるのではなく、誤分類の可能性を反対側から検討するプロンプトを使います。全体の95%以上を決定的な処理で扱えたため、モデルの費用と不安定さを限定できました。この比率は同社データでの事例値であり、命名規則が弱い環境では変わります。

Dagsterは、列発見、規則分類、二つの分類器への分岐、結果統合、Snowflakeタグ適用をアセットグラフとして表します。定期実行と、業務専門家が誤分類を修正する経路は起点が違いますが、最後は同じタグ付け処理へ集約します。センサーが1分ごとに修正を確認するため、処理が重複しない設計も必要です。一人で保守する前提では、専用の監視基盤を増やさず、Dagsterの実行履歴とアセット状態からどこで失敗したかを読める点が重視されています。

新しい列は継続して追加されるため、一度の一括分類で仕事は終わりません。毎日の健全性確認と全アカウントの再走査を分け、規則変更が既存タグを不用意に上書きしないかを差分で確認することが、運用を持続させる条件です。

今回のブログ記事が関係する人

Snowflakeのタグとマスキングを管理するデータガバナンス担当、Dagsterでメタデータ処理を組む開発者、大量列の機密分類を監査するセキュリティ担当に関係します。

結局、今回のブログ記事をどう読むべきか

100万列へAIを一括適用した事例ではなく、決定的規則を主役にし、曖昧な少数だけをモデルと人へ回した設計です。自社では列ごとの正解標本、誤分類の損失、人手修正が再学習や規則改善へ戻る経路を先に決めてください。