dbt and Fabric OneLake Lineage: Resolving URN Mismatch with FabricUrnRewriter – DataHub Customer Support Portal

Area: Ingestion Issues

Sub-Area: dbt / Fabric OneLake Lineage and Sibling Relationships

Issue

When ingesting both dbt models and Microsoft Fabric OneLake tables into DataHub, the expected sibling relationship and lineage between dbt models and their corresponding Fabric OneLake physical tables may not appear in the UI. While the link between a dbt model and a microsoft-fabric dataset is often established correctly, the connection to the table ingested via the fabric-onelake connector remains missing. This occurs because the Fabric OneLake connector generates URNs that include internal workspace and lakehouse GUIDs, whereas the dbt ingestion — without a correctly applied FabricUrnRewriter transformer — emits lineage pointing to human-readable paths that do not match those GUID-based URNs.

Error Messages

No sibling relationship found between dbt model and Fabric OneLake table in DataHub UI
Lineage edges from dbt point to human-readable paths instead of GUID-based URN paths

You Might Be Asking

Why does my dbt model show a relationship to a microsoft-fabric dataset but not to the Fabric OneLake table?
How do I get DataHub to link dbt models and Fabric OneLake tables as siblings?
What does the FabricUrnRewriter transformer do, and when do I need it?
Why are there orphan entities in DataHub after running multiple CLI ingestion loads with different platform names?

Solution

The root cause is a URN mismatch. The Fabric OneLake connector generates URNs containing internal GUIDs for the workspace and lakehouse, for example:

urn:li:dataset:(urn:li:dataPlatform:fabric-onelake,<workspace-name>.<workspace-guid>.<lakehouse-guid>.<schema>.<table-name>,PROD)

For DataHub to resolve the sibling relationship, the dbt ingestion must emit lineage URNs in the same GUID-based format. Follow the steps below to configure and apply the FabricUrnRewriter transformer.

Configure the Fabric OneLake ingestion recipe with a consistent platform_instance that matches your workspace name. This ensures stable, predictable URNs for all ingested tables:
```
source:
  type: fabric-onelake
  config:
    workspace_id: <your-workspace-guid>
    platform_instance: <your-workspace-name>
    # ... additional Fabric OneLake config
```

Configure the dbt ingestion recipe so that target_platform and target_platform_instance match the Fabric OneLake ingestion exactly:

source:
  type: dbt
  config:
    target_platform: fabric-onelake
    target_platform_instance: <your-workspace-name>
    # ... additional dbt config

Add the FabricUrnRewriter transformer to the dbt ingestion recipe. This transformer rewrites physical table URNs in the dbt lineage output from human-readable paths to the GUID-based format that the Fabric OneLake connector produces. Provide the correct workspace and lakehouse UUID mappings:
```
transformers:
  - type: "datahub.ingestion.transformer.fabric_urn_rewriter.FabricUrnRewriter"
    config:
      workspace_name: <your-workspace-name>
      workspace_id: <your-workspace-guid>
      lakehouse_mappings:
        <your-lakehouse-name>: <your-lakehouse-guid>
```
Re-run the dbt CLI ingestion with the updated recipe. The transformer will rewrite the lineage URNs so they match the GUID-based URNs stored by the Fabric OneLake connector, enabling DataHub to establish the sibling relationship automatically.
```
datahub ingest -c <your-dbt-recipe>.yml
```
Verify the result in the DataHub UI. Navigate to one of your dbt models and confirm that the corresponding Fabric OneLake physical table now appears as a sibling. Lineage should flow correctly from the dbt model through to the Fabric OneLake table.
(Optional) Clean up orphan entities. If previous ingestion runs used inconsistent platform names (e.g., Fabric OneLake with a space, or human-readable paths instead of GUIDs), orphan dataset entities may exist in DataHub. These do not cause functional harm but add noise to search results and lineage graphs. Once the primary linking is confirmed working, consider soft-deleting these stale entities via the DataHub UI or the REST API.

Additional Notes

Ensure that schema, database, and table names in your dbt project exactly match the names ingested from Fabric OneLake — case sensitivity and special characters can cause additional URN mismatches. The FabricUrnRewriter transformer is specifically required when the Fabric OneLake connector is used, because it is the only connector that encodes internal GUIDs into the URN path. If you switch to accessing Fabric tables via a different connector (e.g., mssql), the transformer configuration and target_platform setting in the dbt recipe must be updated accordingly. This behavior applies to DataHub Cloud and self-hosted DataHub deployments running a version that includes the fabric-onelake source connector and FabricUrnRewriter transformer.

Issue

Error Messages

You Might Be Asking

Solution

Additional Notes

Related Documentation