Skip to content

[Tracking Issue] Integration with big data ecosystem #5905

Description

@v0y4g3r

What type of enhancement is this?

User experience

What does the enhancement do?

GreptimeDB, a hybrid time series and analytical database, can manage real-time data ingestion and analytics independently. However, for many established infrastructures, integrating with existing big data systems such as Flink, Kafka, BigQuery, Hadoop, and Spark is essential. This issue focuses on the integration process within the big data ecosystem.

To clarify further, we can categorize these integrations into two parts: GreptimeDB as a data sink and GreptimeDB as a data source.

GreptimeDB as data sink

This direction aims to ingest data from big data softwares to faciliate fast, low cost and efficient analytics.

  • Elasticsearch exporter: Export logs in Elasticsearch to GreptimeDB in an efficient way.
  • Flink sink: Set up sinks to write streaming data to GreptimeDB.
  • Kafka connector: Use Kafka Connect or custom sink connectors to send data to GreptimeDB.

GreptimeDB as data source

  • Kafka: Use change data capture (CDC) connectors to stream GreptimeDB updates to Kafka.

Implementation challenges

No response

Activity

  1. added theissue type on Apr 15, 2025
  2. integral-830 commented on Oct 15, 2026

    @integral-830

    Hi @v0y4g3r , I'd like to take the Kafka to GreptimeDB sink item, implemented in Rust rather than as a Kafka Connect connector (Connect is JVM-only; the issue also allows "custom sink connectors").

    What I found while scoping:

    • Flink and Spark connectors already exist.
    • The documented Kafka path today is Vector, which needs InfluxDB line protocol or a pipeline; I couldn't find a Connect sink or a standalone Kafka sink.

    Proposal: a standalone service built on rdkafka and greptimedb-ingester. It consumes topics (JSON first, then Avro/Protobuf), maps them to tables via config (time index, tags, fields), batches rows, writes through the simple or bulk-stream path, and commits offsets only after a successful write (at-least-once). Failed records go to a DLQ, and it exposes Prometheus metrics.

    Questions:

    1. Is a Rust standalone sink acceptable for this item, or is Connect compatibility required?
    2. Should it live in a new GreptimeTeam repo or elsewhere?
    3. Is at-least-once, relying on GreptimeDB's overwrite semantics for dedup, acceptable for v1?
    4. Is anyone already working on this?
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions