Snowflake 與 Collibra：數據工程師訪問數據治理專家

Collibra helps a company know its data: what it means, where it came from, if it is correct, and who can use it. This interview explains it in plain words, for someone who builds pipelines but has never done data governance.

Who is talking. Mark is a data engineer. He has spent five years building Snowflake pipelines with Bronze, Silver and Gold layers. His company just bought Collibra, and his manager asked him to help. John is a data governance expert who has set up Collibra at many companies. Both people are made up for this article. The product facts come from Collibra's documentation as of October 2026.

After reading, you will be able to:

• Explain data governance and Collibra in simple words
• Explain how Collibra connects to Snowflake
• Say what each layer (Bronze, Silver, Gold) needs
• Describe the steps, the people and the time it takes
• Follow one dataset from raw data to a trusted data product

WHAT: What is data governance, and what is Collibra?

Data governance means writing down, in one place, the answers people keep asking about data. Collibra is the tool that holds those answers and keeps them up to date.

Mark: I have never done governance. Honestly, it sounds like paperwork and meetings. What is it really?

John: You already do part of it. When you write a dbt test, add a column comment or give someone a Snowflake role, that is governance. The difference is that today it lives in your code and your head. Governance puts it in one place that everyone can read, including people who can't read SQL.

Mark: Which questions are we answering?

John: Four simple ones, for every dataset:

1. What is it? What does this table or column mean in business words?
2. Where did it come from? Which source and which pipeline made it?
3. Can I trust it? Is the data correct and fresh?
4. Who is in charge of it, and who can use it?

Mark: And where do those answers live today?

John: Here is a side-by-side view.

Mark: So Collibra is just a catalog?

John: A catalog is one part. Think of Collibra as a big diagram of your data. Every item in it is called an asset: a table, a column, a business word, a report. Assets are joined by relations, which are like arrows that say how two things connect. The list of allowed asset kinds and arrow kinds is called the metamodel. It is like a database schema, but for information about your data.

[embedded content: How items link inside Collibra]

The column on the right is read from Snowflake automatically. The business word on the left is written and approved by people. The "means" link between them is what turns a column name into something a business user understands.

See it in Collibra: a screenshot of a real asset page and of the Business Glossary page, in Collibra's documentation.

Mark: Give me the words I need, using things I already know.

John: Here they are.

Mark: What are the main parts of the product?

John: A company buys the parts it needs. For Snowflake these matter most:

• Data Catalog: reads all your databases, tables and columns and makes them searchable.
• Business Glossary: the meaning of business words, such as "Active Customer", linked to the columns that hold them.
• Data Lineage: a map showing how data flows from source to report, down to each column.
• Data Quality: checks such as "amount is never negative". On Snowflake the checks run inside your warehouse.
• Data Access (also called Protect): turns rules like "hide email addresses" into Snowflake masking. Collibra bought a company called Raito in June 2025 to make this stronger.
• Data Marketplace: a shop-like page where people find trusted data and ask for access.
• AI Governance: keeps track of AI projects and gives AI agents trusted information about data.

Mark: One sentence I can tell my manager?

John: "Snowflake stores the data and keeps it safe; Collibra explains what the data means, who owns it, whether to trust it and who may use it."

WHY: Why do we need governance on top of Snowflake?

Bronze, Silver and Gold make data easier to build, but not easier to understand, trust or share safely. Governance fills that gap, and Collibra does it for all your tools, not only Snowflake.

Mark: Our pipelines work fine. Bronze lands the raw data, Silver cleans it, Gold serves it. Why add anything?

John: They work for you, because you built them. Now imagine a business analyst asking three questions. Which table has net revenue? Is it the same number Finance uses? Am I allowed to use it for a marketing campaign? Today the answers are in your head, an old wiki page and a Slack thread.

Mark: Fair point. What usually makes a company start?

John: One of five reasons, often two together.

Mark: Snowflake already has Horizon, with tags, masking and lineage. Why pay for Collibra?

John: People ask this all the time. Horizon works inside Snowflake, and it works well. Collibra works across all your tools: source systems like SAP or Salesforce, loading tools like Fivetran, dbt, and reports in Power BI or Tableau. It also holds the business side that Horizon does not: meanings, owners and approvals. And Collibra sends its rules into Snowflake, so the two work together.

Mark: And dbt docs?

John: dbt docs are written by engineers, for engineers. They don't hold business meanings approved by an owner, they only cover dbt, and an analyst won't look there. Collibra can read your dbt docs, so they become an input, not a rival.

Mark: What does success look like after a year?

John: Things you can count:

• Every Gold table has an owner, a description and a business meaning
• Every column with personal data is found and hidden from people who shouldn't see it
• Important data has quality checks, and the scores are visible
• Analysts find data in the Marketplace instead of sending tickets
• When an auditor asks where a number comes from, you answer in minutes

Mark: And if we don't do it?

John: You risk fines, decisions made on wrong numbers, and AI projects that stall because nobody trusts the data. And you stay the help desk for "which table should I use?"

WHO: Who does what?

Governance works only when real people are named and given time for it. Projects rarely fail because of the tool; they fail because nobody owns the data.

Mark: My manager says I'm now a "Technical Steward". What do I actually do?

John: You look after the technical side. You make sure Collibra keeps reading Snowflake correctly, lineage is complete, quality checks are right, and pipeline problems reported in Collibra get fixed. You are not the one who decides what "Active Customer" means. That is a business decision.

Mark: Then who makes the business decisions?

John: Picture three levels. A small group at the top decides the big rules. Owners are in charge of their area's data. Stewards do the day-to-day work.

[embedded content: The people in a governance programme]

Each level decides for the level below it. Problems that a level can't solve move up, and the council settles anything that crosses business areas.

Mark: Can you put that in a table, with how much time each role needs? My manager will ask.

John: These are typical numbers; every company is a bit different.

Mark: Who actually sets Collibra up?

John: Usually a partner team working with the company's own people:

• Governance lead: runs the workshops, designs who-does-what, manages change
• Collibra architect: designs the structure inside Collibra and how it connects to other tools
• Collibra developer: builds approval steps, connections to other systems, bulk uploads
• Data engineer: sets up Snowflake access, connects Collibra, adds dbt and report lineage
• Data quality engineer: builds the quality checks and scores
• Training lead: teaches stewards and users, part-time

Mark: What if I disagree with the business, say about whether a column holds personal data?

John: The Data Owner decides for their area. If two areas disagree, the council decides. The privacy or legal team sets the rules for what counts as personal data. Your job is to raise the question in Collibra, so the decision is written down instead of lost in Slack.

Mark: Is there a simple who-does-what chart?

John: Yes. R means does the work, A means makes the final call, C means is asked for input, I means is kept informed.

WHERE: Where does Collibra run, and where in Bronze, Silver and Gold does governance apply?

Collibra runs in the cloud and talks to Snowflake through a small helper called Edge, installed in your network. The amount of governance grows from Bronze to Gold: protect Bronze, check Silver, polish Gold.

Mark: Where does Collibra actually run? Does it copy my data?

John: Collibra runs in its own cloud; you don't install the main product. To reach your systems it uses Collibra Edge, a small program you install in your own cloud network, on Kubernetes. Edge keeps the passwords and keys, reads the information it needs, and sends information about the data to Collibra. For some features, Collibra can host this helper for you as a Cloud site.

Mark: So my actual data stays in Snowflake?

John: Mostly, yes. Collibra receives table names, column types, descriptions, lineage and statistics. Real data values leave only if you turn on sampling. Quality checks run inside Snowflake: Collibra sends SQL to your warehouse and gets back only the results. Rules flow the other way: Collibra creates tags and masking in Snowflake.

[embedded content: Collibra on Snowflake · reference architecture]

Edge sits in your network and is the part that connects to Snowflake. Collibra's cloud keeps the information about your data and sends rules back. dbt, loading tools and report tools connect through their own links.

See it in Collibra: About Edge has Collibra's own diagram of how Edge and Cloud sites talk to the platform.

Mark: What does Collibra need inside Snowflake?

John: Its own user and role, with only the rights it needs for the features you use. From Collibra's Snowflake documentation:

Two tips. Tags and masking need Snowflake Enterprise Edition or higher. And Snowflake is moving away from password-only logins, so use key-pair or OAuth login for Collibra's user from the start.

Mark: Now the layers. Do I govern Bronze as much as Gold?

John: No. Trying to govern everything equally is the most common mistake. Remember this: list everything, protect Bronze, check Silver, polish Gold.

Mark: Why hide data in Bronze if users only use Gold?

John: Because raw personal data lands in Bronze first, and engineers, data scientists and service accounts often can see all of Bronze. Finding and hiding it there is the cheapest way to cut risk.

Mark: How should Collibra's folders match our Snowflake setup?

John: Usually a mix. Technical items follow Snowflake, with one domain per database or layer, such as "Snowflake BRONZE", "Snowflake SILVER" and "Snowflake GOLD". Business items, such as meanings and data products, are grouped by business area: Sales, Finance, Supply Chain. Owners belong to the business areas. That is why the first question I ask is how your layers are split: by database or by schema.

WHEN: How long does it take, and when do things happen?

The first business area usually takes about 12–16 weeks from start to finish. Each extra area takes about 6–8 weeks. After that, governance becomes a normal part of building every pipeline.

Mark: How long will this take? Leadership wants a date.

John: Give them two numbers: how long until the first area is done, and how long for each area after that. These are typical ranges from real projects, not official Collibra numbers. The first phase is mostly waiting for approvals.

[embedded content: Roadmap · phases 0 to 6, not to scale]

Phases 2 and 3 run side by side. The line on the left shows phase 6 going back to phase 3 for each new business area.

Mark: Why does "get ready" take up to a month if Edge installs in a day?

John: Because the security team must review any new software that holds passwords and talks to an outside cloud. Network rules, the Kubernetes cluster, a safe place for keys and change approvals all take time. Start that paperwork in week one.

Mark: Can some phases happen at the same time?

John: Yes. Phases 2 and 3 overlap. While you connect Snowflake and build lineage, the stewards agree on business meanings. The two meet when stewards link Gold columns to the agreed words.

Mark: And after go-live, when will I use Collibra in my normal work?

John: At four moments in a pipeline's life:

1. Planning: before building a new Gold table, check Collibra in case one already exists.
2. Building: write dbt descriptions and tests; Collibra picks them up on the next sync.
3. Releasing: your "done" checklist gets a few governance items (below).
4. Running: when a quality check fails, you get a Collibra issue to fix; new tables appear after the next sync.

A "done" checklist for a new Gold table:

• [ ] The table and its columns show up in Collibra after the sync
• [ ] It has a description, and columns are linked to agreed business words
• [ ] An owner and a steward are named
• [ ] Personal data columns are marked, and you checked they are hidden in Snowflake
• [ ] Quality checks on the important columns pass
• [ ] Lineage is complete from Bronze to Gold to the report
• [ ] It is part of a data product, if business users will use it

Mark: How often does Collibra read Snowflake?

John: You choose a schedule for each connection. Once a night is common. Quality checks run after the loads they check. Very large accounts sometimes split the reading by database so each run stays short.

HOW: How do you set up Collibra on Snowflake, step by step?

There are nine steps: connect, design, read, trace, define, link, check, protect and share. Some are technical work, some are workshops with business people, and some are both.

Mark: Walk me through it as if I'm the one doing it.

John: Let's go in the order you would live it.

Step 1: Connect — install Edge and give Collibra a Snowflake user

Mark: What do I build first?

John: The connection. Your platform team installs Edge on a Kubernetes cluster in your network and links it to your Collibra account. In Snowflake you create a role, a user and a small warehouse just for Collibra. Here is an example script. Check the exact list of rights against Collibra's documentation for the features you bought.

-- Example: a Snowflake user and role just for Collibra
USE ROLE SECURITYADMIN;
CREATE ROLE IF NOT EXISTS COLLIBRA_SYNC;
CREATE USER IF NOT EXISTS COLLIBRA_SVC
  TYPE = SERVICE
  DEFAULT_ROLE = COLLIBRA_SYNC
  RSA_PUBLIC_KEY = '<public key from your key store>';
GRANT ROLE COLLIBRA_SYNC TO USER COLLIBRA_SVC;

-- A small warehouse that sleeps after 60 seconds
USE ROLE SYSADMIN;
CREATE WAREHOUSE IF NOT EXISTS COLLIBRA_WH
  WAREHOUSE_SIZE = XSMALL AUTO_SUSPEND = 60 AUTO_RESUME = TRUE;
GRANT USAGE ON WAREHOUSE COLLIBRA_WH TO ROLE COLLIBRA_SYNC;

-- Read usage and lineage information
USE ROLE ACCOUNTADMIN;
GRANT IMPORTED PRIVILEGES ON DATABASE SNOWFLAKE TO ROLE COLLIBRA_SYNC;
GRANT MONITOR USAGE ON ACCOUNT TO ROLE COLLIBRA_SYNC;

-- See the structure of GOLD tables (repeat for BRONZE and SILVER)
GRANT USAGE ON DATABASE GOLD TO ROLE COLLIBRA_SYNC;
GRANT USAGE ON ALL SCHEMAS IN DATABASE GOLD TO ROLE COLLIBRA_SYNC;
GRANT USAGE ON FUTURE SCHEMAS IN DATABASE GOLD TO ROLE COLLIBRA_SYNC;
GRANT REFERENCES ON ALL TABLES IN DATABASE GOLD TO ROLE COLLIBRA_SYNC;
GRANT REFERENCES ON FUTURE TABLES IN DATABASE GOLD TO ROLE COLLIBRA_SYNC;
-- Give SELECT only where you turn on sampling or quality checks

Mark: Why REFERENCES and not SELECT?

John: REFERENCES lets Collibra see a table's columns without reading its rows. Give SELECT only where you need sampling or quality checks. Also add a resource monitor to the warehouse, so Collibra's work never surprises you on the bill.

Step 2: Design — decide the folders, roles and rules

Mark: Then I connect Snowflake?

John: Not yet. If you read Snowflake before planning the folders, thousands of items land in the wrong place and you spend weeks moving them. Plan first:

• Folders (communities and domains): for example a "Sales" community with a glossary domain, a data products domain and its Snowflake domains
• Who can do what: who can edit, approve and view in each folder
• Life of an item: for example Draft → In review → Approved → Retired
• Extra details: fields you want on items, such as "Retention period" or "Layer"
• Sensitivity levels: what counts as personal, payment or confidential data, agreed with the privacy team

Collibra's standard structure covers most needs. Every change you add means more building, testing and upgrade work, so only change what you must.

Step 3: Read — connect Snowflake and fill the catalog

Mark: Now?

John: Now. In Collibra you create a Snowflake connection on Edge, pick the databases and schemas to include, and set a schedule. Collibra then creates an item for every database, schema, table, view and column, with types and descriptions. It updates them as your tables change.

[embedded content: How Collibra reads Snowflake]

Only information about the data moves: names, types, definitions and history. People step in at the end to confirm labels and add descriptions.

Mark: Should I include all of Bronze?

John: Include it so personal data can be found, but leave out the clutter: temporary tables, staging schemas, backup copies. A clean list of 2,000 tables is better than a messy list of 40,000. Then turn on classification. It looks at the data and suggests labels like Email, Phone number or National ID. Stewards accept or reject each suggestion. Accepted labels drive the hiding of data in step 8.

Step 4: Trace — build lineage

Mark: Lineage is what I want to know most. How does it work?

John: Collibra reads your SQL. For Snowflake, the best way is through Edge: it reads view definitions and query history and works out which column feeds which. You add separate links for dbt, for loading tools like Fivetran or ADF, and for report tools like Power BI or Tableau. Together they show the full path from source system to dashboard.

Mark: Where does it fail?

John: Wherever the SQL is hidden or built on the fly.

Promise lineage only for the tools you name, and say that run-time SQL and Python are "best effort".

See it in Collibra: Technical lineage viewer shows screenshots of the column-level lineage map and the view of the SQL behind each step.

Step 5: Define — build the business dictionary

Mark: This is the business part. How do we fill it without endless meetings?

John: Start with what already exists. Most companies have meanings in spreadsheets, report notes and wiki pages. Collect them into one file, upload them as drafts, and run short workshops where stewards fix and approve them. A simple upload file looks like this:

Start with the most important data: the 50–150 words in each area that feed legal reports, leadership numbers and AI projects. You don't need a meaning for every column.

Mark: What if Sales and Finance mean different things by "Revenue"?

John: Either keep both with different names, like "Booked Revenue" and "Recognised Revenue", or let the council pick one. Never allow one name with two meanings.

Step 6: Link — connect business words to Snowflake columns

Mark: How do the words connect to my tables?

John: With links. A steward links GOLD.SALES.CUSTOMER_METRICS.IS_ACTIVE to the word "Active Customer". Collibra's AI can suggest links, but a person confirms them. Because of this link, an analyst can search a business word and land on the right column, and lineage can explain a business number all the way back to Bronze.

Step 7: Check — quality checks and fixing problems

Mark: We already have dbt tests. Do we do them twice?

John: No. Keep dbt tests to stop a bad build. Use Collibra's quality checks for what business users care about on the important data: limits, trends, unusual changes, and a score users can see. Collibra runs these checks as SQL inside Snowflake on a schedule. A check can be this simple:

-- Example check: net amount should never be negative
SELECT * FROM SILVER.SALES.ORDERS WHERE NET_AMOUNT < 0

Collibra can also create checks automatically, using machine learning to spot late data, missing rows or strange values. When a check fails, Collibra opens an issue and sends it to the right person.

[embedded content: What happens when a quality check fails]

A failed check is never just an alert. It becomes an issue with a named person, and the fix is confirmed automatically on the next scheduled run.

Step 8: Protect — from labels to tags to hidden data

Mark: How does a label in Collibra end up hiding data in Snowflake?

John: In Collibra you write a protection rule, for example "Email addresses are hidden from everyone except the PII_READER role". Collibra creates a Snowflake tag with the same name as the label, puts it on every column with that label, and creates the masking rules. Collibra access rules become column masking in Snowflake, and row filters become row access rules. In plain Snowflake terms, Collibra sets up something like this for you:

-- What Collibra sets up in Snowflake for you; you don't write this by hand
CREATE TAG IF NOT EXISTS COLLIBRA.POLICIES.EMAIL_ADDRESS;
CREATE MASKING POLICY COLLIBRA.POLICIES.MASK_EMAIL AS (v STRING) RETURNS STRING ->
  CASE WHEN IS_ROLE_IN_SESSION('PII_READER') THEN v ELSE '***MASKED***' END;
ALTER TAG COLLIBRA.POLICIES.EMAIL_ADDRESS SET MASKING POLICY COLLIBRA.POLICIES.MASK_EMAIL;
ALTER TABLE BRONZE.SHOPIFY.ORDERS MODIFY COLUMN CUSTOMER_EMAIL
  SET TAG COLLIBRA.POLICIES.EMAIL_ADDRESS = 'EMAIL_ADDRESS';

Mark: We already wrote some masking rules by hand. What then?

John: List them first. In Snowflake, a masking rule set directly on a column wins over a tag-based one, so overlapping rules cause surprises. Decide which rules Collibra will manage, then move or remove the rest.

Step 9: Share — data products, Marketplace and access requests

Mark: What is a "data product" in Collibra?

John: A ready-to-use package of Gold tables, for example CUSTOMER_METRICS and the tables that go with it. It comes with an owner, a description, a quality score and rules for use. It can also have a data contract: a written promise about its columns and how fresh the data is. Users find it in the Marketplace and click "Request access". The owner approves, and access is given in Snowflake.

[embedded content: How a user asks for and gets access]

The user never needs to file a ticket or find an engineer. The owner decides, and Collibra gives the Snowflake role.

See it in Collibra: a data product page and the Data Marketplace, with screenshots, in Collibra's documentation.

Mark: And after all nine steps?

John: Repeat steps 5 to 9 for the next business area, and keep steps 3, 4, 7 and 8 running on their schedules. That is normal day-to-day running.

End to end: one dataset from Bronze to a trusted data product

Following one Shopify orders feed through the three layers shows every Collibra feature at work. It is also the best story to tell a customer.

Mark: Make it real. Pick an actual feed.

John: Shopify orders. Fivetran loads them into Bronze, dbt turns them into Silver and Gold, and they are used in Power BI and by a marketing analyst.

[embedded content: One dataset from source to user · 5 stops]

The top row is the pipeline Mark already builds. The bottom row is what Collibra adds at each stop. The numbered steps below walk through it in order.

1. Land. Fivetran writes BRONZE.SHOPIFY.ORDERS, including CUSTOMER_EMAIL and TOTAL_PRICE.
2. Read. The nightly Collibra sync adds the table and its columns to the "Snowflake BRONZE" folder. Fivetran lineage shows they came from Shopify.
3. Label. Classification spots that CUSTOMER_EMAIL holds email addresses. The steward agrees.
4. Protect. The email rule kicks in. Collibra tags the column in Snowflake, and masking hides it from everyone except the PII_READER role.
5. Transform. Mark's dbt model builds SILVER.SALES.ORDERS and works out NET_AMOUNT. dbt lineage shows that NET_AMOUNT comes from TOTAL_PRICE.
6. Check. A quality check says NET_AMOUNT must be zero or more. It fails on 2% of rows. Collibra opens an issue for the Sales steward, who passes it to Mark. He finds a bug in how refunds are handled, fixes the model, and the next run passes.
7. Explain. In Gold, CUSTOMER_METRICS.CLV_USD is linked to the agreed word "Customer Lifetime Value", owned by the VP of Sales.
8. Package. The steward publishes "Customer 360 Metrics" as a data product: the Gold tables, owner, description, quality score and rules for use.
9. Use. A marketing analyst searches "CLV" in the Marketplace. She sees the meaning, the quality score and where the data came from, and asks for access. The owner approves, and her Snowflake role is granted.
10. Prove. An auditor asks where the CLV number in the board report comes from. Lineage shows Power BI report → Gold → Silver → Bronze → Shopify, with every owner and check along the way.

Mark: Which steps happen by themselves?

John: Once set up, these run on their own: reading Snowflake, building lineage, suggesting labels, tagging and masking, running checks and granting approved access. People make the decisions: agreeing to labels, approving meanings, linking words to columns, looking into issues and approving access. That split is why most of the effort is about people, not technology.

Mark: And where do I spend my time in that story?

John: Steps 2, 5 and 6: keeping the sync and lineage healthy, and fixing the pipeline when a check fails. You help with the rest, but you don't own it.

Common mistakes, what drives effort, and quick questions

Most Collibra projects that get stuck do so for one of six reasons. The effort depends on about a dozen things you can count before you start.

Mark: What goes wrong most often?

John: Six things.

Mark: If I had to estimate the work, what would I count?

John: These change the size of the project most:

Mark: Quick questions. Does Collibra replace dbt tests?

John: No. dbt tests stop bad builds. Collibra's checks show business users how good the data is.

Mark: Does it use Snowflake credits?

John: Yes, a little. Syncing, lineage, sampling and quality checks all use a warehouse. Give Collibra its own small warehouse with a spending limit.

Mark: Can Collibra write descriptions back into Snowflake?

John: A deeper two-way link with Snowflake was announced in June 2026. It sends descriptions, tags and rules into Snowflake, and can publish business models as Snowflake Semantic Views for Cortex, Snowflake's AI features. It was in preview, with wider release planned for the third quarter of 2026, so check its status before you rely on it.

Mark: Does it work with Iceberg tables?

John: Check the current Collibra connector documentation for your table types. Don't assume.

Mark: Can AI agents use Collibra?

John: Yes. Collibra has an MCP server that gives AI agents trusted information about your data. Its AI Command Center also keeps track of the AI projects themselves.

Mark: What should I do in my first week?

John: Get Collibra's Snowflake user and rights approved, confirm Edge can reach Snowflake, list the databases and schemas in scope, list your current tags and masking rules, and export your dbt descriptions. That is everything the next phases need from you.

Mark: Last one. What is the single most important thing?

John: Collibra is about 25–30% technology and 70–75% people and process. Get the owners named, and the technology is the easy part.

Words used in this interview

Sources

• Collibra: Integrate Snowflake via Edge
• Collibra: Snowflake permissions for Data Access
• Collibra: Protect for Snowflake
• Snowflake and Collibra expand integration (June 2026)