Unity Catalog governance best practices

Unity Catalog works with a hierarchy: the metastore at the top, and below it the three-level namespace catalog.schema.table. Permissions you grant high up carry through to everything below. That is not a detail but the entire design: if you arrange access at catalog level, a new table is automatically secured correctly the moment it comes into existence.

Permissions granted to people are permissions that stay in place when that person moves team. Work with security groups, and record who owns each catalog. The owner is the one who can hand out permissions, so without a named owner every request lands on the platform team.

Databricks recommends managed tables for most new tables, because the platform then manages the lifecycle, the file layout and the optimization. You get maintenance you would otherwise have to schedule yourself.

The legacy Hive metastore appears in the namespace as the hive_metastore catalog. Everything in it falls outside your Unity Catalog permission model and outside your lineage. Because it works, it stays.

Lineage sits in system.access.table_lineage and system.access.column_lineage. That is not only where Purview reads it from, it is also where you can read it from. When somebody asks which reports lean on a table before you change it, that is a query and not an estimate.

Purview reflects what is in Unity Catalog and does not improve it. A scan of a messy layout produces a messy Data Map. Set up your catalogs first, then do the connection. See How to connect Azure Databricks to Microsoft Purview.