The Column-Level Lineage Diff Analysis feature in Paradime enables users to understand the blast radius of their changes directly within pull requests (PRs). By leveraging field-level lineage, this CI check identifies changes to columns in your dbt™ models and creates a report for all impacted downstream objects. This includes renaming or removing columns and changes to the underlying logic of columns in your dbt™ models.
When a PR is opened it GitHub, an automated comment is generated listing all downstream nodes. This allows users to understand the changes introduced at a column level and assess the potential impact on downstream dbt™ models. BI dashboards, and other downstream elements.
Key Features
Field-Level Lineage: Identify changes to columns in your dbt™ models and generate a detailed report of all impacted downstream objects.
Automated Comments: Receive automated comments in your PRs listing all downstream dbt™ models and BI nodes affected by the changes.
Impact Assessment: Understand what nodes and other elements might be impacted by the changes introduced in the PR.
Use cases
Assess all downstream nodes nodes impacted by changes both within a dbt project and in downstream application (example: BI)
For Data Mesh architectures, see how your current project's changes impact other project changes.
Tutorial
Prerequisites
To use theColumn-Level Lineage Diff Analysis features, ensure the following prerequisites are met:
Git Integration: Install the Paradime GitHub app and authorize access to the dbt™ repository used in Paradime or use alternative methods based on your Git Provider. See setup instructions.
Production Connection: Add a production connection with access to your sources and models generated when running production jobs. This allows Paradime to run information schema queries and build field-level lineage. See connection guide for instructions based on your data warehouse provider.
Have at least one Bolt Schedule configured. This is required to generate field-level lineage for your dbt™ project. See Bolt Scheduler for configuration.
To get the most value out of Lineage Diff Analysis, connect you BI tools (Tableau, Thoughtspot, Looker, etc.) to see all downstream nodes impacted.
Setup Instructions
GitHub Integration: Install the Paradime GitHub app and authorize access to the dbt™ repository used in Paradime. See installation guide for instructions.
Troubleshooting
Unable to find public GitHub email address
If a user GitHub is not configured correctly when opening a PR the user will see the below comment in the Pull Request:
To fix this issue, make sure the user opening the Pull Request completed the GitHub in Paradime.
1. Generate API keys
API keys are generate at a workspace level.
To be able to trigger Bolt using the API, you will first need to generate API keys for your workspace. Got to account settings and generate your API keys, make sure to save in your password manager:
API key
API secret
API Endpoint
You will need this later when setting up the secrets in GitLab.
Now you will need to create a new .gitlab-ci.yml file in your dbt™️ repository. Copy the code below.
stages:
- lineage_diff_report
lineage_diff_report:
stage: lineage_diff_report
image: python:3.11
tags:
- gitlab-org
rules:
- if: $CI_PIPELINE_SOURCE == "merge_request_event"
when: always
variables:
PARADIME_API_KEY: ${PARADIME_API_KEY}
PARADIME_API_SECRET: ${PARADIME_API_SECRET}
PARADIME_API_ENDPOINT: ${PARADIME_API_ENDPOINT}
GITLAB_TOKEN: ${GITLAB_TOKEN}
GIT_DEPTH: 0
before_script:
- pip install paradime-io==4.5.0
script: |
# Echo the relevant environment variables
echo "Head Commit Hash: $CI_COMMIT_SHA"
echo "Base Commit Hash: $CI_MERGE_REQUEST_DIFF_BASE_SHA"
echo "Pull Request Number: $CI_MERGE_REQUEST_IID"
echo "Repository Full Name: $CI_PROJECT_PATH"
echo "Pull Request Author Email: $GITLAB_USER_EMAIL"
# Get the list of changed files in this MR
export CHANGED_FILES=$(git diff --name-only $CI_MERGE_REQUEST_DIFF_BASE_SHA $CI_COMMIT_SHA)
echo "Files changed in this MR:"
echo "$CHANGED_FILES"
# Generate a random report file name
export REPORT_FILE="report_$(openssl rand -hex 12).json"
echo "Report file: $REPORT_FILE"
# Install jq
apt-get update -y && apt-get install -y jq
# Run the Paradime lineage diff analysis
python3 -u <<EOF
import os
import json
from pathlib import Path
from paradime import Paradime
paradime = Paradime(
api_key=os.environ['PARADIME_API_KEY'],
api_secret=os.environ['PARADIME_API_SECRET'],
api_endpoint=os.environ['PARADIME_API_ENDPOINT']
)
report = paradime.lineage_diff.trigger_report_and_wait(
base_commit_sha=os.environ['CI_MERGE_REQUEST_DIFF_BASE_SHA'],
head_commit_sha=os.environ['CI_COMMIT_SHA'],
changed_file_paths=os.environ['CHANGED_FILES'].split('\\n'),
pull_request_number=int(os.environ['CI_MERGE_REQUEST_IID']),
repository_name=os.environ['CI_PROJECT_PATH'],
user_email=os.environ['GITLAB_USER_EMAIL']
)
print("Lineage Diff Report Message: ", report.message)
if report.result_markdown:
data = json.dumps({'body': report.result_markdown})
Path(os.environ['REPORT_FILE']).write_text(data)
EOF
# Write GitLab MR comment
if [ -f "$REPORT_FILE" ]; then
COMMENT_BODY=$(cat "$REPORT_FILE")
curl --request POST --header "PRIVATE-TOKEN: ${GITLAB_TOKEN}" \
--header "Content-Type: application/json" \
--data "$COMMENT_BODY" \
"https://gitlab.com/api/v4/projects/${CI_PROJECT_ID}/merge_requests/${CI_MERGE_REQUEST_IID}/notes"
else
echo "Report file not found, skipping comment."
fi
3. Create a GitLab Access Token
You will need to create GitLab Access Token with API to enable Comments to be generated when opening a Merge Request.
Create a group access token (Only available on GitLab Premium Tier or Higher)
Navigate to your GitLab project
Go to Settings > Access Tokens in the left sidebar
Enter a name for your token (e.g., "API Comment Access")
Select the appropriate scopes:
api (for general API access)
Specifically for comments, you'll need at least api scope, which includes the ability to write comments
Create a GitLab personal access token
If using a GitLab personal access token, we suggest creating a new user, called "Paradime" and create the access token attached to this user.
Log in to your GitLab account
Go to your user profile > Preferences > Access Tokens (or navigate to https://gitlab.com/-/profile/personal_access_tokens)
Enter a name for your token (e.g., "API Comment Access")
Select the appropriate scopes:
api (for general API access)
Specifically for comments, you'll need at least api scope, which includes the ability to write comments
4. Add the API key and Credential in the GitLab variables
Finally you need to add the API key and Credentials generated in the previous step in GitLab CI/CD pipelines as well as the GitLab Token.
Set the corresponding values using your credentials for the variable names:
PARADIME_API_KEY
PARADIME_API_SECRET
PARADIME_API_ENDPOINT
GITLAB_TOKEN
1. Generate API keys
API keys are generate at a workspace level.
To be able to trigger Bolt using the API, you will first need to generate API keys for your workspace. Got to account settings and generate your API keys, make sure to save in your password manager:
API key
API secret
API Endpoint
You will need this later when setting up the secrets in Azure pipelines.
Now you will need to create a new azure-pipeline.yml file in your dbt™️ repository. Copy the code below.
trigger:
- none
pr:
- "*"
steps:
- task: UsePythonVersion@0
inputs:
versionSpec: "3.11"
addToPath: true
displayName: Use Python 3.11
- checkout: self
fetchDepth: 0
displayName: Clone repository
- script: |
# Install paradime python sdk
pip install paradime-io==4.5.0
# Export Paradime API Credentials
export PARADIME_API_ENDPOINT=$(PARADIME_API_ENDPOINT)
export PARADIME_API_KEY=$(PARADIME_API_KEY)
export PARADIME_API_SECRET=$(PARADIME_API_SECRET)
# Set the relevant environment variables
export HEAD_COMMIT_SHA=$(System.PullRequest.SourceCommitId)
export BASE_COMMIT_SHA=$(git rev-parse origin/$(System.PullRequest.TargetBranchName))
export PULL_REQUEST_NUMBER=$(System.PullRequest.PullRequestId)
export REPO_NAME=$(Build.Repository.Name)
export USER_EMAIL=$(Build.RequestedForEmail)
# Get the list of changed files in this PR
export CHANGED_FILES=$(git diff --name-only $BASE_COMMIT_SHA $HEAD_COMMIT_SHA)
# Echo env variables
echo "Head Commit Hash: $HEAD_COMMIT_SHA"
echo "Base Commit Hash: $BASE_COMMIT_SHA"
echo "Pull Request Number: $PULL_REQUEST_NUMBER"
echo "Repository Full Name: $REPO_NAME"
echo "Pull Request Author Email: $USER_EMAIL"
echo "Files changed in this PR: \n $CHANGED_FILES"
# Generate a random report file name
export REPORT_FILE="report_$(openssl rand -hex 12).json"
echo "Report file: $REPORT_FILE"
python3 -u <<EOF
import os
import json
from pathlib import Path
from paradime import Paradime
paradime = Paradime(
api_key=os.environ['PARADIME_API_KEY'],
api_secret=os.environ['PARADIME_API_SECRET'],
api_endpoint=os.environ['PARADIME_API_ENDPOINT']
)
report = paradime.lineage_diff.trigger_report_and_wait(
base_commit_sha=os.environ['BASE_COMMIT_SHA'],
head_commit_sha=os.environ['HEAD_COMMIT_SHA'],
changed_file_paths=os.environ['CHANGED_FILES'].split('\\n'),
pull_request_number=int(os.environ['PULL_REQUEST_NUMBER']),
repository_name=os.environ['REPO_NAME'],
user_email=os.environ['USER_EMAIL']
)
print("Lineage Diff Report Message: ", report.message)
if report.result_markdown:
data = json.dumps({'body': report.result_markdown})
Path(os.environ['REPORT_FILE']).write_text(report.result_markdown)
EOF
if [ -f "$REPORT_FILE" ]; then
COMMENT=$(cat "$REPORT_FILE")
echo $COMMENT
ADO_API=$(echo "$(System.CollectionUri)$(System.TeamProject)/_apis/git/repositories/$(Build.Repository.Name)/pullRequests/$(System.PullRequest.PullRequestId)/threads?api-version=7.1-preview.1")
PR_COMMENT=$(jq --arg comment "$COMMENT" '.comments[0].content = $comment' <<< '{"comments": [{"parentCommentId": 0,"content": "","commentType": 1}],"status": 1}')
curl --request POST "$ADO_API" \
--header "Content-Type: application/json" \
--header "Accept: application/json" \
--header "Authorization: Bearer $(System.AccessToken)" \
--data "$PR_COMMENT" \
else
echo "Report file not found, skipping comment."
fi
displayName: "Generate report and comment on PR"
3. Add the API keys and Credential in the Azure Pipeline variables
Finally you need to add the API key and credentials generated in the previous step in Azure Pipelines.
Set the corresponding values using your credentials for the variable names:
PARADIME_API_KEY
PARADIME_API_SECRET
PARADIME_API_ENDPOINT
4. Update Build Service User Permissions
You will need to add the Contribute to pull requests permission to enable Comments to be generated when opening the Pull Request.
Go to Project Settings in Azure DevOps
Navigate to "Repositories" under Repos
Select your repository
Click "Security"
Find "Project Collection Build Service" or "[Project Name] Build Service"
Set "Contribute to pull requests" to allowed
1. Generate API keys
API keys are generate at a workspace level.
To be able to trigger Bolt using the API, you will first need to generate API keys for your workspace. Got to account settings and generate your API keys, make sure to save in your password manager:
API key
API secret
API Endpoint
You will need this later when setting up the secrets in BitBucket.
4. Add the API keys and Credentials in the BitBucket Pipeline variables
Finally you need to add the API key and credentials generated in the previous step in BitBucket Pipelines as well as the BitBucket Access Token.
Set the corresponding values using your credentials for the variable names:
PARADIME_API_KEY
PARADIME_API_SECRET
PARADIME_API_ENDPOINT
BITBUCKET_ACCESS_TOKEN
Lineage Diff Feature - Supported Use Cases
The lineage diff feature analyzes changes in dbt models to track structural modifications that affect downstream dependencies.
The lineage diff feature focuses on structural changes to SELECT statements that affect the schema and column availability for downstream models. It does not track logic changes, data transformations, or modifications to non-SELECT clauses.
Supported Changes
SQL Structural Changes
The lineage diff feature detects and tracks the following structural modifications:
Column renaming: When a column is renamed in a SELECT statement
Column removal: When a column is removed from a SELECT statement
Column addition: When a new column is added to a SELECT statement
Example - Supported Changes
-- Before
SELECT
customer_id,
customer_name,
email
FROM customers
-- After (column renamed)
SELECT
customer_id,
full_name, -- renamed from customer_name
email
FROM customers
Non-Supported Changes
Structural Changes to Non-SELECT Statements
WHERE clause modifications: Changes to filtering conditions
JOIN modifications: Adding, removing, or changing JOIN conditions
GROUP BY changes: Modifications to grouping logic
ORDER BY changes: Changes to sorting logic
Structural Changes Used in Non-SELECT Contexts
Even if a change is structural (like renaming a column), the lineage diff feature does not track usage in:
WHERE clauses: Column references in filtering conditions
JOIN conditions: Column references in table joins
GROUP BY clauses: Column references in grouping logic
ORDER BY clauses: Column references in sorting logic
Data Changes
Column calculation changes: Modifications to how a column value is computed
NULL handling changes: Changes in NULL value treatment
Data type transformations: Changes that affect data representation but not structure
Example - Non-Supported Changes
-- Before
SELECT
customer_id,
customer_name,
revenue * 1.1 as adjusted_revenue
FROM customers
WHERE status = 'active'
ORDER BY customer_name
-- After (non-supported changes)
SELECT
customer_id,
customer_name,
revenue * 1.2 as adjusted_revenue -- calculation change (not detected)
FROM customers
WHERE status IN ('active', 'pending') -- WHERE clause change (not detected)
ORDER BY full_name -- ORDER BY with renamed column (not detected)
Note: Even though customer_name was structurally renamed to full_name, the lineage diff feature only tracks this change in the SELECT statement itself, not its usage in the ORDER BY clause.