পাঠ ২৬ · ২৯-এর মধ্যে · মডিউল ৪

Home / AI Courses / Data Engineering / Governance ও lineage

Data governance ও lineage

Governance & lineage — catalog, ownership, classification, lineage

৭ মিনিট পড়া মাঝারি · Intermediate Compliance + DataHub

এক নজরে · TL;DR

Governance = ডেটার শাসনব্যবস্থা। কে কী ডেটা ব্যবহার করতে পারে, কীভাবে, কত দিনের জন্য — সব নিয়ম-নীতি।
Catalog (DataHub/Amundsen/OpenMetadata): সব dataset-এর "Google search" — কোথায় কী আছে, কে owner, কত fresh।
Lineage: "এই column কোথা থেকে এলো, কোথায় যাচ্ছে" — root cause analysis ও impact analysis-এর মেরুদণ্ড।
Bangladesh context: ব্যাংকিং খাতে BB compliance; Data Protection Act ২০২৩-এর draft অনুসারে PII handling — pseudonymization বাধ্যতামূলক হতে চলেছে।

এই পাঠে যা শিখবেন

Data governance-এর ৫টি স্তম্ভ — catalog, lineage, ownership, classification, access
DataHub, Amundsen, OpenMetadata — কোনটি কখন ব্যবহার করবেন
Column-level ও table-level lineage কীভাবে capture করবেন (OpenLineage, dbt)
Bangladesh-এর Data Protection Act-এর আলোকে PII classification ও access policy

১ · Governance কেন দরকার — একটি ব্যাংকের গল্প

ভাবুন একটি বাংলাদেশি ব্যাংক — Eastern Bank PLC। তাদের ৫০০+ টেবিল আছে warehouse-এ। একদিন CFOChief Financial Officerপ্রতিষ্ঠানের সর্বোচ্চ আর্থিক কর্মকর্তা — financial reporting, audit ও regulatory compliance-এর দায়িত্ব। জিজ্ঞেস করলেন — "গত মাসে SME loan disbursement কত?" তিনজন analyst তিনটি ভিন্ন উত্তর দিল — ৪২ কোটি, ৪৭ কোটি, ৩৯ কোটি। কেন?

একজন fact_loans থেকে নিয়েছে — শুধু approved।
একজন loan_disbursements_v2 থেকে নিয়েছে — disbursed কিন্তু কিছু rollback miss।
একজন finance_summary_monthly থেকে নিয়েছে — fiscal month-এর সংজ্ঞা ভিন্ন।

এটাই data governanceData Governanceপ্রতিষ্ঠানের ডেটাকে শাসন করার নীতি, প্রক্রিয়া ও tool-এর সমষ্টি — quality, security, ownership, compliance নিশ্চিত করতে। শুধু technology নয়, বহুলাংশে process ও culture-এর কাজ।-এর অভাব। প্রতিটি প্রতিষ্ঠান যত বড় হয়, তত বেশি table তৈরি হয়, একই metric-এর একাধিক "version of truth" তৈরি হয়। Governance ছাড়া — analyst-রা পথ হারায়, audit fail হয়, regulator ক্ষুব্ধ হয়।

Governance-এর ৫টি স্তম্ভ

১) Catalog: "কোথায় কী ডেটা আছে?"
২) Lineage: "এই কলাম কোথা থেকে এলো, কোথায় যাচ্ছে?"
৩) Ownership: "এই table-এর জন্য কে দায়ী?"
৪) Classification: "এটি কি PII? কোন sensitivity tier?"
৫) Access control: "কে read/write করতে পারবে?"

২ · Catalog — ডেটার Google

Data catalog একটি searchable inventory — সব dataset, dashboard, ML model, metric-এর। আপনি যেমন Google-এ "best biriyani in Dhaka" search করেন, তেমনি একজন analyst search করেন "monthly active users" বা "loan default rate"। Catalog তাকে দেখায় — কোন table-এ আছে, কে owner, last update কখন, কতবার query হচ্ছে, এবং sample data।

প্রধান open-source choice:

DataHub (LinkedIn): সবচেয়ে feature-rich। GraphQL API, fine-grained ACL, real-time updates, ML-feature catalog। বড় enterprise — বিকাশ, Grameenphone-এর মতো।
Amundsen (Lyft): simple, search-first। দ্রুত deploy, কম maintenance। মাঝারি startup-এর জন্য ভালো।
OpenMetadata: আধুনিক, schema-driven। Data quality + lineage + catalog একই platform-এ।
Cloud-native: Unity Catalog (Databricks), DataPlex (GCP), Glue Data Catalog (AWS)।

Catalog ছাড়া ১,০০০ table-এর warehouse — যেন ৫০,০০০ বইয়ের লাইব্রেরি কিন্তু কোনো সূচিপত্র নেই। আপনি বই খুঁজবেন কীভাবে? Catalog হলো সেই সূচিপত্র — শুধু title নয়, summary, লেখক (owner), শেষ revision তারিখ, পাঠকের রেটিং সব দেখায়।

৩ · Lineage — ডেটার বংশতালিকা

Data lineageData Lineageএকটি ডেটা-উপাদান কোথায় উৎপন্ন, কোন কোন transformation দিয়ে গেছে, এবং কোন কোন consumer (dashboard, model, report) ব্যবহার করছে — তার সম্পূর্ণ যাত্রাপথের রেকর্ড। মানে — একটি ডেটা-উপাদানের জীবনচক্র। একটি transaction PostgreSQL-এ origin → CDC দিয়ে Kafka → Spark transformation → Snowflake fact table → dbt model → Tableau dashboard → CFO-এর iPad। এই পুরো পথটা lineage।

দুই ধরনের lineage:

Table-level: "এই table কোন কোন source থেকে তৈরি?" — মোটামুটি সহজ, dbt automatic দেয়।
Column-level: "fact_orders.total_amount কোন column থেকে compute হয়?" — গভীর, SQL parse করতে হয়। OpenLineage বা SQLLineage library।

Lineage-এর use case:

Impact analysis: "customer_email column drop করতে চাই — কোন কোন downstream report ভাঙবে?"
Root cause: "Dashboard-এ revenue ভুল — কোন upstream pipeline-এ bug?"
Compliance: "এই PII column কোন কোন report-এ ছড়িয়েছে?" — GDPR/DPA delete request-এর জন্য।
Cost: "এই expensive transformation-এর output আসলে কোথাও ব্যবহৃত হচ্ছে কি?"

৪ · Ownership ও stewardship

প্রতিটি dataset-এর একজন মানুষ থাকতে হবে — যিনি দায়ী। দু'টি ভূমিকা পার্থক্য করুন:

Data owner: ব্যবসায়িক দায়িত্ব। সাধারণত VP, head of product, finance manager। "এই ডেটার মান কেমন হবে, কে access পাবে — সিদ্ধান্ত নিই।"
Data steward: technical দায়িত্ব। সাধারণত data engineer, analytics engineer। "schema maintain করি, quality test লিখি, broken pipeline fix করি।"

একটি ব্যর্থতার কালচার — "এই table-এর কোনো owner নেই" — production-এ everyone-এর সমস্যা। Catalog-এ প্রতিটি dataset-এর owner ফিল্ড mandatory করুন।

৫ · Classification ও PII

ডেটাকে sensitivity tierSensitivity Tierডেটার গোপনীয়তা ও সংবেদনশীলতা অনুসারে শ্রেণীবিন্যাস — সাধারণত Public, Internal, Confidential, Restricted। প্রতিটি tier-এ আলাদা access ও handling নিয়ম।-এ ভাগ করতে হবে। সাধারণ ৪-tier model:

Public: press release, public website data — যে কেউ দেখতে পারে।
Internal: aggregated metrics, employee-only — কর্মচারীরা দেখতে পারে।
Confidential: customer email, transaction history — শুধু authorized team।
Restricted (PII/PHI): NID, account number, biometric — শুধু minimum-needed কর্মী, সব access logged।

Bangladesh-এ PII (Personally Identifiable Information):

NID number, passport number
Mobile number, email
Bank account, MFS (bKash/Nagad) wallet
Bio-metric fingerprint (এখন বহু সরকারি service-এ)
Address, geo-location

Data Protection Act ২০২৩ (draft): বাংলাদেশের আসন্ন আইন (এখনও sometimes called Personal Data Protection Ordinance)। অনুসারে — sensitive personal data store করতে হলে user consent লাগবে, এবং deletion request-এর ৩০ দিনের মধ্যে কার্যকর করতে হবে। আপনার catalog যদি PII-tagged না হয় — এই compliance impossible।

৬ · Access control — RBAC থেকে ABAC

RBAC (Role-Based Access Control): "Analyst role → marketing schema-এ read access।" সহজ, scalable।

ABAC (Attribute-Based): "User-এর department=finance এবং data classification ≤ confidential হলে read।" Fine-grained কিন্তু complex।

Production pattern:

Column masking: SELECT *-এ NID auto-redacted হবে non-privileged user-এর জন্য।
Row-level security: Branch manager শুধু নিজের branch-এর rows দেখবেন।
Just-in-time access: একজন engineer ৪ ঘণ্টার জন্য prod access চাইবেন — Slack approval দিয়ে — তারপর auto-revoke।
Audit log: "X user Y time-এ Z table query করেছে" — Bangladesh Bank সব scheduled bank-কে এই log কয়েক বছর রাখতে বলে।

Catalog-কেন্দ্রিক governance — সমস্ত technical metadata এক জায়গায়, সব consumer search করে।

৭ · Lineage capture — OpenLineage ও dbt

OpenLineage একটি open standard — pipeline run করার সময় lineage event emit করে। Airflow, Spark, dbt — সবার integration আছে। নিচের YAML একটি Airflow DAG-কে OpenLineage-এ wired করে।

YAML · Airflow OpenLineage config

# airflow.cfg or env vars
[openlineage]
transport = '{"type": "http", "url": "http://datahub:8080/openlineage/api/v1"}'
namespace = ebl-bank-prod

# DAG অটোমেটিকভাবে lineage emit করবে
# fact_loans → dim_branch + dim_customer + raw_loan_app
#                                      ↓
#                            sql parse → column-level edges

Airflow ২.৭+ থেকে openlineage-airflow provider built-in। DAG-এর প্রতিটি SQL operator-এর input/output table parse করে DataHub-এ পাঠায়। আপনাকে কোড লিখতে হয় না — শুধু config।

dbt-এর built-in lineage: dbt docs generate চালালে — আপনার models-এর full graph তৈরি হয়। প্রতিটি model-এর ref() ও source() থেকে edge তৈরি।

SQL · dbt model with PII tag

-- models/marts/fact_loans.sql
{{
  config(
    materialized='table',
    meta={
      'owner': 'risk-analytics@ebl.com.bd',
      'pii': 'restricted',
      'sensitivity': 'confidential',
      'retention_days': 2555  -- 7 years per BB regulation
    }
  )
}}

SELECT
  l.loan_id,
  -- NID column masked except for compliance role
  CASE
    WHEN is_role_member('compliance_officer')
      THEN c.nid
    ELSE 'XXX-XXX-' || RIGHT(c.nid, 4)
  END AS customer_nid,
  l.disbursed_amount,
  l.disbursed_at,
  b.branch_name
FROM {{ ref('stg_loans') }} l
JOIN {{ ref('dim_customers') }} c USING (customer_id)
JOIN {{ ref('dim_branches') }} b  USING (branch_id)

meta block-এর সবকিছু DataHub-এ harvested হবে — owner, PII tag, retention। ref() থেকে automatic lineage। NID column conditional masking — privileged role ছাড়া কেউ পুরো NID দেখবে না।

৮ · Bangladesh-এর regulatory landscape

Bangladesh Bank — IT Risk Management Guidelines (২০১৮, updated):

সব scheduled ব্যাংকের ডেটা Bangladesh-এ primary copy থাকতে হবে (data localization)।
৭ বছর transaction record retention বাধ্যতামূলক।
Quarterly access-log audit, annual penetration test।
Cross-border data transfer-এ BB-এর written approval।

NBR (National Board of Revenue):

VAT/Tax-relevant data ৫ বছর immutable রাখতে হবে।
Audit-এ lineage produce করতে হবে — "এই revenue figure কোন source থেকে এলো?"

BTRC (Telecom Regulatory):

Telecom operators (Grameenphone, Robi, Banglalink) — call data record (CDR) ১৮০ দিন রাখতে হবে।
Lawful intercept request-এ ২৪ ঘণ্টার মধ্যে সাড়া দিতে হবে।

Practical advice: বাংলাদেশে startup-এ কাজ করলে — দিন-১ থেকে catalog ও lineage সেট আপ করুন। যখন আপনার ৫০ million customer হবে (bKash-এর মতো), backfill করতে পারবেন না। Cheap insurance — আগে থেকে invest।

৯ · DataHub সেট আপ — quick start

Bash · DataHub local install

# Python 3.9+ ও Docker দরকার
pip install --upgrade acryl-datahub
datahub docker quickstart

# UI: http://localhost:9002
# admin / admin দিয়ে login

# Snowflake থেকে metadata ingest
datahub ingest -c snowflake_recipe.yml

YAML · DataHub Snowflake recipe

# snowflake_recipe.yml
source:
  type: snowflake
  config:
    account_id: xy12345.ap-southeast-1
    username: datahub_reader
    password: ${SNOWFLAKE_PWD}
    warehouse: META_WH
    role: DATAHUB_ROLE
    include_tables: true
    include_views: true
    include_table_lineage: true
    include_column_lineage: true
    profiling:
      enabled: true
      profile_table_size_limit: 5

sink:
  type: datahub-rest
  config:
    server: http://localhost:8080

একবার চালালেই — আপনার পুরো Snowflake-এর সব table, column, query history থেকে lineage, এবং sample profile DataHub-এ আসবে। Browser-এ গিয়ে search "active customers" — সব relevant table দেখাবে, কে last query করেছেন, কে owner।

ভাবনার প্রশ্ন

প্রতিটি প্রশ্ন নিজে কিছুক্ষণ ভাবুন — তারপর "→ উত্তর" চাপুন।

প্র ০১ আপনি bKash-এ data engineer। একজন user "right to be forgotten" exercise করেন — তার সব data delete চান। DPA ২০২৩-এর ৩০ দিনের requirement। কীভাবে confident হবেন যে সব trace মুছে গেছে?

এটি একটি classic governance challenge — এবং কেন catalog + lineage early-stage থেকে দরকার তার সবচেয়ে শক্তিশালী যুক্তি। bKash-এর ৭০+ million user, প্রতিদিন কয়েক কোটি transaction। একজন user-এর data কোথায় কোথায় ছড়িয়ে আছে তা manually trace করা impossible।

ধাপে ধাপে workflow:

Step 1 — Identity resolution: User-এর primary key (user_id, mobile_number, NID) থেকে শুরু। Master Data Management (MDM) থেকে সব alias collect — তিনি কখনও আলাদা mobile-এ register হয়েছেন কিনা।
Step 2 — Catalog query: DataHub-এ "PII tag = restricted AND classification contains user_data" — সব downstream dataset list।
Step 3 — Lineage walk: Source tables (raw_users, raw_transactions) থেকে শুরু করে — column-level lineage walk। কোন কোন aggregation, dimension, mart-এ এই user-এর row আছে।
Step 4 — Selective vs cascading delete: Aggregated fact-এ — pure delete না, recompute। যেমন fact_daily_revenue-এ এই user-এর contribution বিয়োগ করতে হবে।
Step 5 — Backup ও cold storage: S3 Glacier-এ ২ বছরের archive আছে — সেগুলোতেও tombstone marker। Restore-এর সময় auto-skip।
Step 6 — Logs: Application log, Kafka retention, ML feature store — সব check।
Step 7 — Audit certificate: User-কে delete confirmation pdf — কোন কোন system-এ মুছেছে, কোন hash ছিল।

Practical reality: ১০০% delete কখনও সম্ভব নয় — কারণ:

Bangladesh Bank ৭ বছর AML transaction record রাখতে বলে — legal hold।
NBR audit-এর জন্য VAT-related data ৫ বছর।
এই cases-এ — pseudonymization (NID hash, name → "DELETED USER #abc123") করা হয়, full delete নয়।

মূল উপলব্ধি: Privacy compliance শুধু engineering নয় — legal + product + ops-এর সমন্বয়। কিন্তু engineering-এর হাতে প্রধান tool — catalog + lineage + automated deletion pipeline। এই foundation না থাকলে কোম্পানি আদালতে দাঁড়াতে পারবে না — "আমরা চেষ্টা করেছি" বলা যথেষ্ট নয়, evidence trail চাই।

প্র ০২ একটি ৫০-জনের data team-এ DataHub না Amundsen না OpenMetadata? কোনটি কখন? Trade-off কী?

এই decision একটি startup-এর জন্য non-trivial — কারণ migration painful। ৬-১২ মাস পর regret করলে অনেক metadata + customization হারাবেন।

DataHub (LinkedIn, ২০১৯):

Strengths: Real-time event-based architecture (Kafka backbone), column-level lineage শক্তিশালী, ML feature catalog, fine-grained RBAC, GraphQL API, plugin-rich ecosystem।
Weaknesses: Heavy infrastructure — Kafka + Elasticsearch + Postgres + Neo4j-like graph; বিশাল team না হলে maintenance burden। UI কিছুটা cluttered।
Best fit: ৫০+ data team, ১,০০০+ tables, complex compliance need (banking, healthcare)। Acryl-এর managed offering আছে।

Amundsen (Lyft, ২০১৯):

Strengths: Search-first UX, simple stack (Elasticsearch + Neo4j + Atlas-light), দ্রুত deploy। PageRank-based ranking — popular tables search-এ আগে।
Weaknesses: Lineage limited (table-level mostly), ownership/PII workflow basic, plugin ecosystem ছোট, development pace ধীর।
Best fit: মাঝারি startup (১০-৫০ data engineer), যেখানে "search" main pain-point।

OpenMetadata (Collate, ২০২১):

Strengths: Modern schema-driven design, data quality + catalog + lineage একই platform, glossary শক্তিশালী, fastest-growing community ২০২৪-এ।
Weaknesses: তুলনায় young, edge case-এ documentation পাতলা, scaling কিছু large enterprise-এ চ্যালেঞ্জ।
Best fit: Greenfield project, সব pillar একই platform চান, modern API চান।

বাংলাদেশ context-এ recommendation:

bKash, Robi-এর মতো বড়: DataHub — compliance-heavy, audit trail important।
Daraz, Pathao-এর মতো মাঝারি: OpenMetadata — quality + catalog + glossary unified।
৫০-জনের startup: Amundsen — দ্রুত value, কম maintenance। বা সরাসরি cloud (Unity Catalog যদি Databricks)।

Decision framework:

৩ থেকে ৬ মাসের MVP চাই → Amundsen।
Strict regulatory compliance চাই → DataHub।
Data quality unified চাই → OpenMetadata।
Cloud-only ও single-vendor → Unity Catalog (Databricks) বা DataPlex (GCP)।

মূল কথা: "Best tool" নেই — context, team size, budget, vendor lock-in tolerance বিবেচ্য। যেকোনোটাই none-এর চেয়ে infinitely ভালো।

প্র ০৩ "Lineage automatically capture হবে" — promise কিন্তু practice-এ ৪০% pipeline missed। কেন? কীভাবে gap কম করবেন?

এটি real production pain — সব catalog vendor ও open-source maintainer-ই স্বীকার করেন। Lineage coverage ১০০% achieve করা অসম্ভব, কিন্তু ৬০% থেকে ৯৫%-এ আনা যায়।

কেন lineage miss হয়:

Dynamic SQL: EXEC('CREATE TABLE ' || @table_name) — parser বুঝতে পারে না।
Stored procedures: SQL Server, Oracle-এ procedural logic — DataHub-এর parser limited।
Pandas/Python transformations: df.merge(df2) — কোন framework hook করবে?
Shell scripts: aws s3 cp, gsutil based pipelines — invisible।
BI tool internal logic: Tableau-এর custom calculation, PowerBI-এর DAX measure।
External APIs: Salesforce, HubSpot থেকে data — third-party।
Streaming: Kafka topic → Flink → another topic — instrumentation কম।

Coverage বাড়ানোর strategies:

(১) Standardize on dbt: Pandas/SQL script-এর বদলে — সব transformation dbt model হিসেবে। Free lineage automatic।
(২) OpenLineage-এর Marquez collector: Airflow, Spark, Flink — সব OpenLineage spec follow করুক। One protocol → all backends।
(৩) Manual lineage assertion: যা automate হয় না — manual edge add API দিয়ে। আমার team-এ "lineage debt board" — quarterly cleanup।
(৪) Query log harvesting: Snowflake, BigQuery-এর audit log থেকে actual SQL parse। Even ad-hoc query lineage capture।
(৫) Wrap external systems: Tableau-এর REST API → custom DataHub plugin। PowerBI-এর XMLA endpoint।

Cultural fix — যা tool-এর চেয়ে important:

"No lineage = no merge" — PR review-এ catalog check। dbt PR-এ ref() না থাকলে block।
Quarterly "lineage hygiene" sprint — orphan node, missing owner হ্যান্ডল।
Onboarding-এ catalog usage বাধ্যতামূলক — প্রতিটি নতুন engineer দিন-১-এ catalog ভিজিট।
Slack bot — "Hey, you queried raw_orders ৫০ বার, কিন্তু এতে কোনো owner set নেই। কে set করবেন?"

Realistic targets:

Year 1: ৬০% table-level coverage।
Year 2: ৮৫% table-level, ৫০% column-level।
Year 3+: ৯৫% table-level, ৭৫% column-level।
১০০% — myth। শেষ ৫% always edge case।

মূল কথা: Lineage একটি journey, not a checkbox। Tool half-battle, culture other half। যে team lineage-কে engineering excellence-এর অংশ ভাবে — তারা successful।

প্র ০৪ আপনি Eastern Bank-এ Chief Data Officer। Bangladesh Bank quarterly audit — আপনার প্রস্তুতি কী হবে? প্রমাণ কী দেখাবেন?

BB inspection — scheduled ব্যাংকের জন্য most stressful event। Failure মানে administrative penalty, license risk। এটি শুধু technical exercise না — board-level visibility।

প্রস্তুতির ৬ pillar:

(১) Data localization proof:

Catalog-এ প্রতিটি critical dataset-এর "primary location: BD-DC1" tag।
Cloud usage থাকলে — region locked to ap-south-1 বা onshore data center।
Architecture diagram: কোন data কোথায় rest, কোথায় in-transit।

(২) Access audit log:

Snowflake/Postgres query log — last ৪ quarters।
"Who accessed customer NID column past quarter?" — DataHub query → list।
Anomaly report: midnight access, weekend bulk export, ex-employee account।
BB-এর recent guideline — privileged user-এর session recording (specifically on prod DBs)।

(৩) Retention compliance:

প্রতিটি transaction table-এ retention policy attached — ৭ বছর AML, ৫ বছর VAT, ১০ বছর loan record।
Automated archival job log: "deleted N records older than X" — daily report।
Legal hold register — চলমান cases-এ যা delete হবে না।

(৪) PII handling:

Catalog-এ ১০০% PII column tagged।
Masking policy enforced — non-compliance role-এ NID দেখাবে না (live demo BB officer-এর সামনে)।
Encryption at rest (AES-256) ও in transit (TLS 1.3) — KMS key rotation log।
Data sharing agreement — third-party (credit bureau, NBR e-TIN check) — formal contract।

(৫) Incident response:

Past quarter-এর সব data-related incident (breach, leak, bug) — log ও remediation।
Tabletop exercise simulation — "যদি ০৫,০০০ customer-এর data leak হয়?" — playbook।
Reporting timeline — BB-কে ২৪ ঘণ্টার মধ্যে notify।

(৬) Lineage proof:

Auditor random pick — "এই quarterly Capital Adequacy report-এর numerator কোথা থেকে?" → DataHub graph দেখাবে: source ledger → fact_capital → mart_basel3 → report।
Calculation correctness — code review trail, deployment log, change history।

Documentation:

Data Governance Policy document — board-approved, annually reviewed।
RACI matrix — কে owner, কে steward, কে approver।
Org chart — DPO (Data Protection Officer), CISO, CDO-এর reporting line।

Soft factors:

Past audit feedback-এ raised issue — সব closed status with evidence।
Training certificate — সব data engineer compliance training (annual)।
Vendor due diligence — cloud provider, ETL vendor — তাদের SOC 2/ISO 27001।

মূল কথা: Audit pass হয় paperwork-এ না — actual evidence-এ। Catalog + lineage + log + automated policy enforcement থাকলে — ১ ঘণ্টায় BB officer-এর প্রতিটি প্রশ্নের উত্তর। না থাকলে — ২ সপ্তাহের scrambling, এবং finding শেষ পর্যন্ত। যিনি governance-কে compliance-এর কাজ ভেবে underestimate করেন — তিনিই সবচেয়ে বড় failure।

অনুশীলন

PII tagging: নিচের ৬টি column-এর জন্য sensitivity tier ঠিক করুন (Public / Internal / Confidential / Restricted):
- customer_email
- order_total_amount_aggregated_monthly
- customer_nid
- product_name
- employee_salary
- customer_geo_lat_long
- customer_email → Confidential (PII, কিন্তু DPA-তে regulated identity)
- order_total_amount_aggregated_monthly → Internal (aggregated, individual-level নয়)
- customer_nid → Restricted (national identity, highest tier)
- product_name → Public (catalog-এ public)
- employee_salary → Confidential (HR-sensitive)
- customer_geo_lat_long → Restricted (location traceable; specific point sensitive)

dbt model লিখুন: Daraz-এর জন্য একটি fact_orders dbt model লিখুন — meta block-এ owner, PII level, retention দিন। Customer email column conditional masking করুন।

-- models/marts/fact_orders.sql
{{
  config(
    materialized='incremental',
    unique_key='order_id',
    meta={
      'owner': 'commerce-analytics@daraz.com.bd',
      'pii_level': 'confidential',
      'retention_days': 1825,
      'description': 'Daraz orders fact — incremental daily.'
    }
  )
}}
SELECT
  o.order_id,
  o.customer_id,
  CASE
    WHEN current_role() IN ('analytics_admin','support_l3')
      THEN c.email
    ELSE REGEXP_REPLACE(c.email, '(.{2})(.*)(@.*)', '\\1***\\3')
  END AS customer_email_masked,
  o.order_total_bdt,
  o.placed_at,
  o.status
FROM {{ ref('stg_orders') }} o
JOIN {{ ref('dim_customers') }} c USING (customer_id)
{% if is_incremental() %}
  WHERE o.placed_at > (SELECT MAX(placed_at) FROM {{ this }})
{% endif %}

Lineage walk: আপনার warehouse-এ raw_payments column drop করতে চান। কোন কোন artifact check করবেন lineage থেকে?
Catalog-এ raw_payments খুলে — "downstream" tab:
- Direct downstream tables: stg_payments, fact_transactions।
- Indirect (২+ hop): mart_revenue_daily, mart_cohort_retention।
- Dashboards: Tableau "Daily Revenue", Looker "Cohort Analysis"।
- ML features: feature store-এর user_lifetime_value_v3।
- Reports: Quarterly investor deck, BB regulatory report।
- Action items: প্রতিটি downstream owner-কে notify, ২ sprint-এর migration window, deprecation flag set।