Skip to main content

Metalakes

A metalake is the top of the metadata hierarchy and the boundary everything else lives inside. Catalogs, schemas, tables, filesets, topics, models, and functions all sit beneath one, and so do the users, groups, roles, tags, policies, and jobs that apply to them. Creating, enabling, and deleting metalakes is an administrator task, covered in Metalake administration.

Quick start​

Everything you explore, govern, or authorize happens inside one metalake, so the first step is choosing it.

  1. Choose the metalake. Select it in the metalake selector at the top of the navigation bar. Every section other than Configure then describes that metalake.

  2. See what it holds. Its catalogs are the top level of Explore; see Catalogs and schemas.

The selector offers only the metalakes you can access. If it offers none, ask an administrator to add you to one.

The boundary​

Nothing crosses a metalake:

  • Users and groups are members of one metalake. The same person working in two metalakes is added to each, even when the identity provider supplies them once to the whole server.
  • Roles are defined and granted within one metalake, so a role held in one carries no privilege in another.
  • A tag or policy created in one metalake cannot be attached to an object in another.
  • Names only have to be unique within one metalake.

That makes a metalake the unit to reach for when separating environments, business units, or tenants that should not see each other's metadata.

Most installations need very few. A metalake per production estate, and perhaps one for development, is a common shape. Every client connects to a single metalake and works inside it, so adding more means people have to know which one they are in.

How clients reach a metalake​

The Java and Python clients, and the Trino, Spark, and Flink connectors, name the metalake when they connect.

The IRC serves one metalake for the whole installation, set at install time with the chart value gravitino.icebergRest.dynamicConfigProvider.metalake. Each catalog in that metalake is an IRC warehouse, selected by its name. Iceberg engines therefore reach only the catalogs of that metalake.

The MCP server can be given a default metalake with the chart value mcp.metalake; without one, agents name the metalake on every call.

Names and properties​

A metalake name is unique across the server and is what every client names when it connects, so renaming one changes what every stored connection has to ask for.

Properties are free-form key and value pairs, with one reserved key. in-use records whether the metalake is available, defaults to true, and is set by enabling and disabling the metalake rather than by writing the property directly.

A metalake cannot carry a tag or a policy, so there is no way to classify or govern everything at once from the top. The widest attachment point is a catalog.

Enabled and disabled​

A disabled metalake can only be listed, loaded, enabled, or deleted. Every other operation on it or on anything inside it fails, which is how an administrator takes an estate out of service without deleting anything. The metalake list under Configure shows each metalake's status.

Last updated on