Skip to main content

Extract Metadata from GCP Composer

Requirements

Use a Cloud Composer environment that supports the Airflow version required by your Collate release. For Collate 2.0.5, the bundled ingestion image uses Airflow 3.3.2. It also requires the ingestion package to match your Collate server version. For Collate 2.0.5, install openmetadata-ingestion~=2.0.5.0. Two main approaches exist to extract metadata from Composer. Both of them involve creating a DAG directly in your Composer instance, but the requirements and the steps to follow are going to be slightly different. Feel free to choose whatever approach adapts best to your current architecture and constraints.

Using the Python Operator

The most comfortable way to extract metadata out of GCP Composer is by directly creating a DAG in there that will handle the connection to the metadata database automatically and push the contents to your Collate server. The drawback here? You need to install openmetadata-ingestion directly on the host. This might have some incompatibilities with your current Python environment and/or the internal (and changing) Composer requirements. In any case, once the requirements are there, preparing the DAG is super straight-forward.

Install the Requirements

In your environment you will need to install the following packages:
  • openmetadata-ingestion~=x.y.z.0 (for example, openmetadata-ingestion~=2.0.5.0).
  • sqlalchemy>=2.0,<3: This aligns with the SQLAlchemy version used by Collate 2.0 and Airflow 3.x. Follow your Composer environment constraints if they are stricter.
Note: Make sure to use the openmetadata-ingestion version that matches the server version you currently have!

Prepare the DAG!

Note that this DAG is a usual connector DAG, just using the Airflow service with the Backend connection. As an example of a DAG pushing data to Collate under Google SSO, the setup could look like this:

Using the Kubernetes Pod Operator

This second approach does not require installing anything in the GCP Composer environment. Instead, Collate relies on the KubernetesPodOperator to use the underlying k8s cluster of Composer. Then, the code won’t directly run using the hosts’ environment, but rather inside a container created for this purpose with only the openmetadata-ingestion package.

Requirements

The only thing to handle here is getting the URL of the underlying Composer’s database. You can follow the official GCS docs for the steps to obtain the credentials. In a nutshell, from the Airflow UI you can to Admin > Configurations, and search for sql_alchemy_conn. In our case, the URL looked like this:
As Cloud Composer uses Postgres for the backend database, the Airflow connection configuration is shaped as:
For more information on how to shape the YAML describing the Airflow metadata extraction, see Airflow Connector.

Prepare the DAG!

Some remarks on this example code:

Kubernetes Pod Operator

You can name the task as you want (task_id and name). The important points here are the cmds, this should not be changed, and the env_vars. The main.py script that gets shipped within the image will load the env vars as they are shown, so only modify the content of the config YAML, but not this dictionary. Note that the example uses the image openmetadata/ingestion-base:2.0.5. Update that accordingly for higher versions once they are released. The image version should be aligned with your Collate server version to avoid incompatibilities.
For more information about the KubernetesPodOperator and how to tune its configurations, see Use the KubernetesPodOperator.

Collate Server Config

The easiest approach here is to generate a bot with a JWT token directly from the Collate UI. You can then use the following workflow config: