Sources

StarRocks

Sync the StarRocks serving layer and connect it to upstream tables and generic downstream consumers.

The StarRocks connector is metadata and lineage only. It catalogs visible relations and records how data reaches StarRocks, but it does not give Embrasure permission to execute product queries.

What appears in the graph

A common path is:

Iceberg table → StarRocks table or view → dashboard, report, or service

StarRocks supplies the middle asset and its upstream evidence. A BI connector, service-read observation, DataHub import, or OpenLineage event supplies the downstream consumer edge. The StarRocks integration has no dependency on Looker, Metabase, Tableau, or any other specific consumer.

Embrasure collects three forms of StarRocks evidence:

EvidenceAvailabilityResult
View and asynchronous materialized-view definitionsBuilt inDeclared table and best-effort column dependencies
Iceberg external-catalog locationsBuilt in when exposed by SHOW CREATE TABLEAn upstream Iceberg REST table is linked only when exactly one synced connector publishes the same canonical storage location
AuditLoader query historyOptional StarRocks pluginObserved CREATE TABLE AS SELECT, INSERT INTO ... SELECT, and INSERT OVERWRITE ... SELECT lineage

An absent or inaccessible AuditLoader table does not fail catalog sync. It only removes the executed-transformation evidence layer.

Connect StarRocks

Create a dedicated account with visibility limited to the catalogs and databases Embrasure should index. The account needs to:

  • connect to a Frontend MySQL-protocol endpoint, normally port 9030;
  • list the selected catalogs and databases;
  • read information_schema.tables and information_schema.columns;
  • run SHOW CREATE VIEW, SHOW CREATE MATERIALIZED VIEW, and SHOW CREATE TABLE for objects in scope. Synchronous rollups are not treated as declared materialized-view lineage because StarRocks does not expose them through SHOW CREATE MATERIALIZED VIEW.

In Settings, choose StarRocks, enter the Frontend host, username, password, and initial catalog, then verify the connection. Leave the scope as __all__ to sync every visible database, or select catalog.database entries after verification.

SSL mode Required is the default and negotiates TLS. Use Disabled only for a trusted, non-TLS query endpoint, and restrict inbound access to the Embrasure connector network path.

Enable executed transformation lineage

Install and configure StarRocks AuditLoader using the StarRocks documentation. Grant the connector account SELECT on:

default_catalog.starrocks_audit_db__.starrocks_audit_tbl__

Embrasure reads a bounded, overlapping 24-hour window after catalog sync. Query IDs make repeated windows idempotent. Raw statement text is not stored in catalog-lineage deliveries; query observations retain a redacted form and hash for diagnosis.

Bridge an Iceberg catalog

Connect the Iceberg REST catalog that owns the same tables, then sync both connectors. Embrasure compares canonical table-root locations such as s3://warehouse/analytics/orders. It creates the bridge only for one exact Iceberg connector match. Missing or ambiguous matches remain coverage gaps instead of guessed edges.

Connect consumers

StarRocks query logs cannot reliably identify the dashboard or application that submitted a statement. Use the integration that owns that identity:

  • sync a supported BI connector;
  • emit an input-only OpenLineage event from an application or service;
  • import lineage from DataHub; or
  • use service-account query evidence where supported.

The consumer becomes its own graph node and reads from the StarRocks relation. This keeps the serving connector generic and lets new consumer integrations attach through the same lineage provider boundary.