Skip to main content
Last updated on

Ingest data from Apache Kafka

Beta

This feature is in Beta. Workspace admins can control access to this feature from the Previews page. See Manage Databricks previews.

This page shows how to create a managed Kafka ingestion pipeline using Databricks Lakeflow Connect.

Requirements​

  • To create an ingestion pipeline, you must first meet the following requirements:

    • Your workspace must be enabled for Unity Catalog.

    • Serverless compute must be enabled for your workspace. See Serverless compute requirements.

    • To create a new connection, you must have CREATE CONNECTION privileges on the metastore. See Manage privileges in Unity Catalog.

      If the connector supports UI-based pipeline authoring, an admin can create the connection and the pipeline at the same time by completing the steps on this page. However, if the users who create pipelines use API-based pipeline authoring or are non-admin users, an admin must first create the connection in Catalog Explorer. See Connect to managed ingestion sources.

    • To use an existing connection, you must have USE CONNECTION privileges or ALL PRIVILEGES on the connection object.

    • You must have USE CATALOG privileges on the target catalog.

    • You must have USE SCHEMA and CREATE TABLE privileges on an existing schema or CREATE SCHEMA privileges on the target catalog.

  • To ingest from Kafka, you must first complete the steps in Connect to Apache Kafka for managed ingestion.

Create an ingestion pipeline​

Each Kafka topic is ingested into a streaming table. For a list of supported data and limitations, see Supported data.

note

UI-based pipeline authoring is not supported for the Kafka connector in Beta. Use Declarative Automation Bundles or a Databricks notebook to create your pipeline.

Use Declarative Automation Bundles to manage Kafka pipelines as code. Bundles can contain YAML definitions of jobs and tasks, are managed using the Databricks CLI, and can be shared and run in different target workspaces (such as development, staging, and production). For more information, see What are Declarative Automation Bundles?.

  1. Create a new bundle using the Databricks CLI:

    Bash
    databricks bundle init

  2. Add a pipeline definition file to the bundle (for example, resources/kafka_pipeline.yml). See pipeline.ingestion_definition and Examples.

  3. Deploy the bundle using the Databricks CLI:

    Bash
    databricks bundle deploy

Examples​

Use these examples to configure your pipeline.

Minimal pipeline — raw binary key and value​

This example ingests one or more Kafka topics with key and value columns retained as BINARY:

YAML
variables:
  connection_name:
    default: my-kafka-connection
  dest_catalog:
    default: main
  dest_schema:
    default: kafka_ingest
resources:
  pipelines:
    kafka_pipeline:
      name: kafka-ingestion-pipeline
      serverless: true
      continuous: true
      channel: PREVIEW
      catalog: ${var.dest_catalog}
      target: ${var.dest_schema}
      ingestion_definition:
        connection_name: ${var.connection_name}
        objects:
          - table:
              source_table: N/A
              destination_catalog: ${var.dest_catalog}
              destination_schema: ${var.dest_schema}
              destination_table: user_events
              connector_options:
                kafka_options:
                  topics: [user-events, power-user-events]

Pipeline with transformers — JSON value and string key​

This example deserializes message keys as STRING and values as JSON with schema evolution enabled:

YAML
variables:
  connection_name:
    default: my-kafka-connection
  dest_catalog:
    default: main
  dest_schema:
    default: kafka_ingest
resources:
  pipelines:
    kafka_pipeline:
      name: kafka-ingestion-pipeline
      serverless: true
      continuous: true
      channel: PREVIEW
      catalog: ${var.dest_catalog}
      target: ${var.dest_schema}
      ingestion_definition:
        connection_name: ${var.connection_name}
        objects:
          - table:
              source_table: N/A
              destination_catalog: ${var.dest_catalog}
              destination_schema: ${var.dest_schema}
              destination_table: user_events
              connector_options:
                kafka_options:
                  topics:
                    - user-events
                  starting_offset: latest
                  key_transformer:
                    format: STRING
                  value_transformer:
                    format: JSON
                    json_options:
                      schema_evolution_mode: rescue

Route records to multiple tables (fanout)​

Preview

This feature is in Private Preview. To try it, reach out to your Databricks contact.

Fanout routes each record from a single Kafka source to one of many destination tables. You configure fanout on a schema object instead of a table object. A routing key derived from each record determines the destination table name: {destination_catalog}.{destination_schema}.{key_value}.

Set fanout_options on the schema object. The fanout_by field is a SQL expression evaluated against the raw source record (with the Kafka key and value columns), and its result becomes the final segment (the table name) of the destination table {destination_catalog}.{destination_schema}.{result}. Because fanout_by runs on the raw record, cast the binary value to a string before you extract a field from it, as in the following example. Its resolved value is used as the table-name segment verbatim, without quoting or sanitization, so it must be a valid unquoted table identifier. Values with spaces, dots, or other characters that aren't valid in an unquoted identifier fail the write, as does a value that is entirely digits (for example, 123). A leading digit is allowed when the value also contains a letter or underscore, such as 2024_events.

You can optionally apply a single JSON transform to each route. This transform runs on each routed record after routing, so it doesn't affect the value that fanout_by sees. For the full list of options and the v1 constraints, see Fanout options and Fanout limitations.

The following example reads records from topics matching a pattern and routes each record to a table named after its event_type field. The optional JSON transform parses the message value column in place in each destination table:

YAML
variables:
  connection_name:
    default: my-kafka-connection
  dest_catalog:
    default: main
  dest_schema:
    default: kafka_ingest
resources:
  pipelines:
    kafka_pipeline:
      name: kafka-ingestion-pipeline
      serverless: true
      continuous: true
      channel: PREVIEW
      catalog: ${var.dest_catalog}
      target: ${var.dest_schema}
      ingestion_definition:
        connection_name: ${var.connection_name}
        objects:
          - schema:
              destination_catalog: ${var.dest_catalog}
              destination_schema: ${var.dest_schema}
              connector_options:
                kafka_options:
                  topic_pattern: 'events-.*'
                  starting_offset: earliest
              fanout_options:
                fanout_by: 'cast(value as string):event_type::string'
                transforms:
                  - format: JSON
                    input_column: value

Common patterns​

For advanced pipeline configurations, see Common patterns for managed ingestion pipelines.

Next steps​

Start and set alerts on your pipeline. See Common pipeline maintenance tasks.

Additional resources​

On this page