セキュリティの次のステップ

workspace.workshop.diamondsのdiamondsテーブルに慣れてきたら、そのデータへのアクセスがどのように制御されているかを理解する必要がある。プロフェッショナルな環境では、すべてのユーザーが自由にテーブルを削除または更新できるわけではない。

ここでUnity Catalogが登場し、Lakehouse全体の「セキュリティガード」として機能する。

1. 集中型アクセス制御

Unity Catalog導入前は、大規模な企業でどのユーザーがどのテーブルを閲覧できるかの管理が困難だった。現在は、1か所で一元管理が可能。

• 権限: 管理者はSELECT（読み取り専用）、MODIFY（更新・削除可能）、CREATEなどの特定の権限を付与できる；
• 「オーナー」概念: すべてのテーブルにはオーナー（通常は作成者）が存在し、そのデータに対して他の誰が操作できるかを決定する。

2. 三部構成のネームスペース

Unity Catalog は本コース全体で使用される命名規則を強制します：Catalog > Schema > Table。

• Catalog：上位のコンテナ（例：workspace）
• Schema：フォルダのようなグループ（例：workshop）
• Table：個々のデータセット（例：diamonds）

この構造により、部門ごとにデータを整理しやすくなり（例：Finance.Quarterly_Reports.Revenue）、すべてのレベルでセキュリティルールを一貫して適用可能。

3. データリネージ

Unity Catalog の最も強力な機能の一つがリネージ。

• Catalog Explorer では、diamonds テーブルをクリックすると、そのデータの由来や現在どのノートブックで使用されているかのビジュアルマップを確認可能
• ソースでカラム名を変更した場合、リネージがどの下流レポートに影響が出るかを正確に示し、意図しない「破壊的」変更を防止

4. 検索と発見

Unity Catalog によりデータの発見性が向上。特定のファイルの場所をチームメイトに尋ねる代わりに、Databricks UI 上部の検索バーを利用可能。

データがカタログに登録されているため、「diamonds」と検索すれば、テーブルやそのスキーマ、オーナーが提供したドキュメントを即座に発見可能。

5. 監査ログ

セキュリティはアカウンタビリティも意味します。Unity Catalog は、誰がいつどのデータにアクセスしたかの記録を保持します。

これは、金融や医療などの規制産業の企業にとって、機密データが正しく取り扱われていることや、許可されていないユーザーが個人情報を照会していないことを証明するために不可欠です。