POST_START

Transferring Ownership of Unity Catalog Objects

I recently took on the responsibility of managing access to a set of Unity Catalog objects within our organization. As part of a team restructuring, several schemas, tables, and views needed to be reassigned to different teams to ensure proper ownership and governance. My task was to transfer ownership of these objects from the `training` catalog to the appropriate teams using the Unity Catalog features available in Databricks.

Understanding the Current Ownership

I started by reviewing the current ownership of the objects in the `training` catalog. I knew that the `training` catalog was initially created for a training purpose, and its contents were being moved to more specialized teams. I wanted to make sure I had a clear picture of what needed to be transferred.

I ran a quick query to check the current owners of the objects in the catalog. While I didn’t need to run a query for this specific task, it helped me understand the structure of the objects that needed to be re-assigned.

Transferring Ownership of the Catalog

The first step was to transfer ownership of the entire `training` catalog to the `data_admins` team. This was necessary because the catalog itself contained multiple schemas, tables, and views that would need to be re-assigned, and it made sense to start at the top level.

ALTER CATALOG training SET OWNER TO `data_admins`;

I ran the above command in the Databricks notebook. I noticed that the ownership of the catalog was successfully transferred to `data_admins`. This was an important step because it allowed the team to manage the catalog and its contents more effectively.

Transferring Ownership of Schemas

Next, I needed to transfer ownership of the `sales` schema within the `training` catalog to the `data_engineers` team. This schema contained several tables and views that were being moved to the data engineering team for operational use.

ALTER SCHEMA training.sales SET OWNER TO `data_engineers`;

I executed the command above. I verified that the schema ownership was updated, and the data engineers now had the appropriate access and responsibility for managing the schema. This was a crucial step because it allowed the team to take control of the data structures they would use daily.

Transferring Ownership of Tables and Views

After the schema was transferred, I moved on to the individual tables and views within the `sales` schema. The `customers` table and the `customer_view` view needed to be reassigned to the `data_engineers` team to ensure that the team had full control over the data they were working with.

ALTER TABLE training.sales.customers SET OWNER TO `data_engineers`;
ALTER VIEW training.sales.customer_view SET OWNER TO `data_engineers`;

I ran both commands one after the other. I checked the ownership of each object to confirm that the transfer was successful. This gave me confidence that the data structures were now under the right team’s management and that the data governance process was moving forward as planned.

Verifying the Ownership Changes

Finally, I made sure to verify that all the objects had been successfully reassigned. I reviewed the ownership of each object, including the catalog, schema, table, and view, to ensure that the changes had been applied correctly.

I also made a note to document these changes in our internal knowledge base so that the team could refer back to them when needed. Proper documentation is essential for maintaining clarity and accountability, especially during team transitions.

By following these steps, I was able to ensure that the right teams took ownership of the right objects, and that the organization’s data governance practices were upheld throughout the process.