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

Home / AI Courses / Data Engineering / Data quality

Data quality testing

Data quality — dimensions, tests, contracts

৭ মিনিট পড়া মাঝারি · Intermediate dbt & GE

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

৫টি data quality dimension — সংজ্ঞা, BD-context উদাহরণ
dbt tests ও Great Expectations — কখন কোনটি
Anomaly detection — statistical & ML-based monitoring
Data contract — producer-consumer agreement

১ · কেন data quality "টেস্ট" দরকার

Daraz-এর একজন BI analyst সকালে CEO-কে dashboard পাঠালেন: "গতকাল sales ৪০% drop"। প্যানিক, meeting, marketing campaign halt। বিকেলে দেখা গেল — ETL job ১২টা থেকে ১২:৩০ চলেছিল, কিন্তু source-এ data ১:০০ পর্যন্ত আসে। Dashboard আসলে partial data দেখাচ্ছিল। Engineering trust ভাঙে এক incident-এ।

Data qualityData Qualitydata fit-for-purpose-এর মাত্রা — কতটা সঠিক, সম্পূর্ণ, সামঞ্জস্যপূর্ণ, সময়মতো ও unique। প্রতিটিকে "dimension" বলে; প্রতি dimension-এ measurable test। মানে data fit-for-purpose কিনা — সঠিক, সম্পূর্ণ, সামঞ্জস্যপূর্ণ, সময়মতো, unique। এই পাঁচটি dimension প্রতিটিতে measurable test।

৫টি DQ dimension

১) Completeness: required field-এ value আছে?
২) Accuracy: value সঠিক ও বৈধ range-এ?
৩) Consistency: দু'টি source-এ same fact agree?
৪) Timeliness: data তাজা — SLA-এর মধ্যে?
৫) Uniqueness: primary key বা business key duplicated না?

২ · Completeness — null ও missing

bKash-এর transaction table-এ msisdn NULL হলে — fraud detection feature মিস। উদাহরণ test:

SQL · Completeness

-- যেকোনো warehouse-এ কাজ করে
SELECT
  COUNT(*) AS total_rows,
  SUM(CASE WHEN msisdn IS NULL THEN 1 ELSE 0 END) AS null_msisdn,
  SUM(CASE WHEN amount_bdt IS NULL THEN 1 ELSE 0 END) AS null_amount,
  SUM(CASE WHEN tx_ts IS NULL THEN 1 ELSE 0 END) AS null_ts,
  ROUND(100.0 * SUM(CASE WHEN msisdn IS NULL THEN 1 ELSE 0 END)
              / COUNT(*), 4) AS msisdn_null_pct
FROM bkash.transactions
WHERE DATE(tx_ts) = CURRENT_DATE - 1;

-- Threshold: msisdn_null_pct > 0.1% হলে alert

Completeness expressed as percentage; absolute count meaningful কিন্তু volume বাড়লে threshold পরিবর্তন। Production-এ p99 historical baseline-এ compare।

৩ · Accuracy — domain validity

Daraz-এর price_bdt column-এ একদিন ০ value দেখা গেল ৫০% rows-এ। Cause — pricing service bug। Test:

Range check: amount_bdt BETWEEN 1 AND 1000000।
Enum check: tx_type IN ('SEND', 'RECEIVE', 'CASH_IN', 'CASH_OUT')।
Format check: BD MSISDN regex ^8801[3-9][0-9]{8}$।
Cross-field check: order_ts <= delivery_ts।

৪ · Consistency — দু'টি source agree

Pathao-এর orders table-এ today's revenue = ৫০ লাখ BDT। কিন্তু payments service-এ today's settlement = ৪৭ লাখ। ৩ লাখ পার্থক্য — কোনো order paid কিন্তু marked paid হয়নি, বা vice versa।

$$\text{consistency rate} = 1 - \frac{|A - B|}{\max(A, B)}$$

Production target সাধারণত > ৯৯.৫%। Reconciliation report — daily Airflow।

ভাবুন — Daraz warehouse-এ স্টক ১০০টি জুতা; কিন্তু Excel-এ ৯৭। তিনটি জুতা কোথায়? Auditing — দুই ভিন্ন সূত্র মিলে দেখা — এটাই consistency check। DE-তে এটি reconciliation নামে পরিচিত।

৫ · Timeliness — freshness SLA

একটি dashboard "fresh" বলতে কত পুরনো data acceptable? E-commerce hourly; banking real-time; analytics report daily — context-specific।

SQL · Timeliness

-- টেবিলে সর্বশেষ event কত পুরনো?
SELECT
  MAX(event_ts)                                    AS latest_event,
  CURRENT_TIMESTAMP                                AS now_ts,
  EXTRACT(EPOCH FROM (CURRENT_TIMESTAMP - MAX(event_ts))) / 60.0
                                                   AS lag_minutes
FROM daraz.orders
WHERE DATE(event_ts) >= CURRENT_DATE - INTERVAL '1 day';

-- SLA: lag_minutes > 30 হলে alert (hourly pipeline)

Freshness — DE-এর সবচেয়ে commonly broken SLA। Source delay, Airflow scheduler issue, Spark job slow — সব পথে latency বাড়ে। Per-table freshness target ও alerting essential।

৬ · dbt tests — SQL-based DQ

dbtdbt (data build tool)SQL-first analytics engineering framework। Models = SELECT statements; tests = SQL assertion। CI/CD-friendly, lineage auto-generate। DE community-এ standard tool ২০২২+।-এ tests YAML-এ declarative, রান হয় dbt test-এ। Generic tests + custom SQL test।

YAML · dbt schema.yml

version: 2

models:
  - name: stg_bkash_transactions
    description: "Cleaned bKash transaction events"
    columns:
      - name: tx_id
        description: "Unique transaction identifier"
        tests:
          - unique
          - not_null
      - name: msisdn
        tests:
          - not_null
          - dbt_utils.expression_is_true:
              expression: "regexp_like(msisdn, '^8801[3-9][0-9]{8}$')"
      - name: amount_bdt
        tests:
          - not_null
          - dbt_utils.expression_is_true:
              expression: "amount_bdt BETWEEN 1 AND 5000000"
      - name: tx_type
        tests:
          - accepted_values:
              values: ['SEND', 'RECEIVE', 'CASH_IN', 'CASH_OUT', 'PAYMENT']
      - name: customer_id
        tests:
          - relationships:
              to: ref('dim_customer')
              field: customer_id

  - name: fct_daily_revenue
    tests:
      - dbt_utils.expression_is_true:
          expression: "total_revenue_bdt > 0"
      - dbt_expectations.expect_row_values_to_have_recent_data:
          datepart: hour
          interval: 6   # last 6 hours-এ data থাকতে হবে

dbt-এ test fail হলে — Airflow downstream job halt; Slack/email alert। CI-তে PR-এর সাথে test run automatically — bad data merge prevention।

৭ · Great Expectations — Python-first

Great ExpectationsGreat Expectations (GE)Python-based data validation framework। ৩০০+ built-in "expectations"। Data Docs auto-generate; profiling support। Pandas, Spark, SQL — সব backend। dbt-এর চেয়ে richer expectation library; non-SQL data (Pandas, Spark)-এ কাজ করে; auto-profiling।

Python · Great Expectations

import great_expectations as gx

context = gx.get_context()
batch = context.sources.add_pandas("orders").read_csv(
    "s3://daraz-curated/orders/2025-05-09.csv"
)

# Suite তৈরি
suite = context.add_expectation_suite("orders_suite")

# Multiple dimensions
batch.expect_column_values_to_not_be_null("order_id")
batch.expect_column_values_to_be_unique("order_id")
batch.expect_column_values_to_be_between(
    "amount_bdt", min_value=1, max_value=10_000_000
)
batch.expect_column_values_to_match_regex(
    "msisdn", r"^8801[3-9][0-9]{8}$"
)
batch.expect_column_values_to_be_in_set(
    "district",
    ["Dhaka","Chattogram","Khulna","Rajshahi","Barisal",
     "Sylhet","Rangpur","Mymensingh"]
)
batch.expect_table_row_count_to_be_between(
    min_value=10_000, max_value=10_000_000
)

# Run + report
result = batch.validate()
context.build_data_docs()         # HTML auto-generate
print("Success:", result.success)
print("Failed expectations:", [
    r["expectation_config"]["expectation_type"]
    for r in result.results if not r["success"]
])

Great Expectations Data Docs — HTML report যা stakeholder দেখতে পারে। প্রতিটি expectation কী, কখন pass/fail হয়েছে — historical timeline। dbt-এর তুলনায় more thorough কিন্তু operational overhead বেশি।

৮ · Anomaly detection — যা schema-test ধরে না

Daraz-এর "Eid sale" দিনে orders ৩x বাড়ে — schema test pass করে, কিন্তু "৫% bigger" দিনে বাড়লে কেউ বুঝবে না bug কিনা। Statistical anomaly detection দরকার।

Z-score: $z = (x - \mu) / \sigma$। $|z| > 3$ → anomaly।
Moving average + bands: ৭-দিনের rolling mean ± 2σ।
Seasonal decompose: Eid/weekday pattern remove করে residual check।
ML-based: Isolation Forest, Prophet, Anodot — multivariate।

Python · Anomaly check

import pandas as pd
from scipy import stats

# Daily revenue history
df = pd.read_sql("""
    SELECT order_date, SUM(amount_bdt) AS revenue
    FROM daraz.fct_orders
    WHERE order_date >= CURRENT_DATE - INTERVAL '90 days'
    GROUP BY 1 ORDER BY 1
""", conn)

# Last 7 days exclude — baseline calculate
baseline = df.iloc[:-7]
mu, sigma = baseline.revenue.mean(), baseline.revenue.std()

today_z = (df.revenue.iloc[-1] - mu) / sigma
print(f"আজকের z-score: {today_z:.2f}")

if abs(today_z) > 3:
    print(f"⚠️  Anomaly: revenue {df.revenue.iloc[-1]:,.0f} BDT, "
          f"baseline {mu:,.0f} ± {sigma:,.0f}")
    # Alert PagerDuty / Slack

Z-score simple কিন্তু seasonality miss করে। Production-এ Prophet/sktime দিয়ে seasonality + trend decompose; residual-এ z-score। Monte Carlo, Anomalo, Bigeye — ম্যানেজড services BD enterprise-এ adoption বাড়ছে।

৯ · Data Contract — DE-র "API"

Data contractData Contractproducer (যিনি data emit করেন) ও consumer (যিনি ব্যবহার করেন)-এর মধ্যে formal agreement — schema, SLA, quality SLO। Software API-র data equivalent। — backend engineer (producer) ও DE/analytics team (consumer)-এর মধ্যে formal agreement। কী schema, কী SLA, কী quality threshold।

YAML · Data Contract

name: bkash.transactions
version: 2.1.0
owner: payments-platform-team
producer: payments-svc
consumers:
  - analytics-platform
  - fraud-ml
  - regulator-reporting

schema:
  - name: tx_id
    type: string
    required: true
    pii: false
  - name: msisdn
    type: string
    required: true
    pii: true
    encryption: aes-gcm
    pattern: "^8801[3-9][0-9]{8}$"
  - name: amount_bdt
    type: decimal(12,2)
    required: true
    range: [1, 5000000]
  - name: tx_ts
    type: timestamp
    required: true

slo:
  freshness: 5m       # event-এর ৫ মিনিটের মধ্যে warehouse-এ
  completeness: 99.9% # required field null rate
  uniqueness: 100%    # tx_id duplicate-free
  accuracy: 99.5%     # validation rules pass

breaking_change_policy: 30d_notice

Contract version-controlled (git)। Schema change-এর PR-এ producer ও consumer team-এ approval। CI-তে breaking change auto-detect (Buf, Apicurio, dbt-checkpoint)। DE team-এ accountability প্রতিষ্ঠিত হয়।

Data quality pyramid — schema-level cheap, statistical moderate, contract organizational। প্রতিটি স্তর আগেরটির gap পূরণ।

১০ · Bangladesh-এ DQ maturity

Banking/MFS: regulatory reporting-এর জন্য reconciliation matures; কিন্তু dbt/GE adoption শুরু (২০২৪+)। Manual SQL check বেশি।
Telco: Robi, GP marketing analytics-এ dbt + Great Expectations spread হচ্ছে।
Ecommerce: Daraz, Pathao — dbt mainstream, GE ML team-এ feature validation।
Outsourcing (Brain Station 23, Tiger IT): client expectation-এ vary; modern client dbt mandatory।

"Garbage in, garbage out" — AI/ML team-এর সবচেয়ে hidden risk। Daraz-এ একটি churn model deploy হয়েছিল train data-তে ১৫% null phone number — production-এ বেশি লোকজন "high churn" predict, কারণ null = no contact। Data contract + GE check থাকলে catch হত। ML team-এ দাবি — DE pipeline-এর প্রতিটি field-এ contract।

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

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

প্র ০১ আপনি Daraz Bangladesh-এ DE। CFO complain করলেন: "প্রতি সপ্তাহে dashboard-এর সংখ্যা ভিন্ন; কোনটা trust করব?" সমস্যা diagnose এবং পদ্ধতিগতভাবে solve করার ৬-মাসের roadmap design করুন।

Trust crisis — DE team-এর existential challenge। CFO-র অভিযোগ valid এবং পদ্ধতিগত response চাই।

(১) Diagnose — root cause taxonomy:

Source data বদলায়: backend schema change, retroactive correction।
Pipeline bug: filter mismatch, late-arriving event drop।
Definition drift: "active user" এক টিম ৭-day, অন্য টিম ৩০-day।
Time zone: UTC vs BST mix → date boundary off।
Currency: BDT vs USD conversion rate প্রতিদিন।
Refresh time: dashboard cache দিনে ৩বার, real-time table-এর সাথে mismatch।

(২) Month 1 — visibility:

Top ১০ critical metric চিহ্নিত (revenue, GMV, orders, active users…)।
প্রতিটির definition document — "Active user = last 7 days at least 1 session in app, BST timezone"।
Definition committee — DE + Finance + Product একমত।
Existing dashboard audit — কোথায় inconsistent।

(৩) Month 2 — single source of truth:

dbt project setup — সব critical metric একটি repo-তে।
Mart layer (gold tables): fct_daily_orders, dim_customer, fct_revenue_daily।
BI tool re-point — Tableau, Looker সব এই mart থেকে pull।
Direct production DB access deprecated।

(৪) Month 3 — testing layer:

প্রতিটি critical model-এ dbt tests: not_null, unique, range, relationships।
Custom test: "daily revenue cannot decrease MoM by >30% without flag"।
Reconciliation suite — payments service vs orders table নিত্য match।
Slack alert integration — fail হলে DE on-call।

(৫) Month 4 — anomaly + freshness:

Great Expectations দিয়ে statistical baseline।
Freshness SLA per table — Airflow sensor + alert।
Daily DQ scorecard email to leadership।

(৬) Month 5 — data contract:

Top ৩ producer service-এর সাথে formal contract।
Schema change PR-এ DE team approval।
Breaking change ৩০-day notice।
Contract test in CI।

(৭) Month 6 — culture:

"Data quality KPI" team-এর OKR-এ।
Weekly DQ review meeting — DE + analyst + business।
Postmortem template DQ incident-এ।
Onboarding doc নতুন DE-এর জন্য।

(৮) Success metric:

Top ১০ metric variation week-over-week < ০.৫% (baseline ৫%+)।
DQ incident MTTR < ২ ঘণ্টা।
CFO survey: "dashboard trust" > ৪/৫।

(৯) BD-specific consideration:

BST/UTC confusion — সব timestamp warehouse-এ UTC, presentation-এ BST।
BDT/USD — daily exchange rate snapshot table।
Eid/holiday seasonality — anomaly baseline এই factor account।

মূল উপলব্ধি: Trust technical fix নয় — পদ্ধতিগত culture change। Tools (dbt, GE) সহায়তা করে, কিন্তু definition + ownership + accountability কেন্দ্রবিন্দু। ৬ মাসে CFO-র "weekly variation" complaint থেকে "data-driven decisions" — realistic পথ।

প্র ০২ bKash-এ একটি new fraud detection ML model deploy করেছেন। Production-এ accuracy দ্রুত ৯২% থেকে ৭৮%-এ নেমেছে। DQ angle থেকে কী diagnose করবেন? কী monitoring বসাবেন?

ML model performance drop — 70% সম্ভাবনা data issue। DQ-এর সাথে ML monitoring intersect এই scenario-তে।

(১) সম্ভাব্য DQ root cause:

Schema drift: producer service নতুন column add বা rename — silent bug।
Distribution shift: "average transaction amount" পরিবর্তন (Eid effect, market change)।
Feature value shift: "device_type" এ নতুন value (foldable phones)।
Null rate change: upstream service partial outage → ৩০% null।
Label leak: training-এ যে feature ছিল production-এ delayed।
Time zone bug: retraining timezone shift।

(২) Diagnostic step-by-step:

-- Feature distribution training vs production
SELECT 'training' AS src,
       AVG(amount_bdt) AS mean,
       STDDEV(amount_bdt) AS sd,
       APPROX_PERCENTILE(amount_bdt, 0.5) AS p50,
       APPROX_PERCENTILE(amount_bdt, 0.99) AS p99
FROM bkash.training_features_v3
UNION ALL
SELECT 'production', AVG(amount_bdt), STDDEV(amount_bdt),
       APPROX_PERCENTILE(amount_bdt, 0.5),
       APPROX_PERCENTILE(amount_bdt, 0.99)
FROM bkash.production_features_today;

(৩) ML-specific DQ checks:

PSI (Population Stability Index): training vs production feature distribution।
$$\text{PSI} = \sum_i (P_i - Q_i) \ln(P_i / Q_i)$$
PSI < 0.1 stable, 0.1-0.25 minor shift, >0.25 major।
Feature null rate: training time-এ যা ছিল, এখন তা।
Label distribution: fraud rate base shift?
Prediction distribution: bimodal থেকে uniform → silent issue।

(৪) Monitoring stack:

Per-feature daily PSI Airflow job।
Great Expectations suite production feature table-এ।
Evidently/whylogs — purpose-built ML monitoring।
Slack alert PSI > 0.25 কোনো critical feature-এ।

(৫) bKash-specific consideration:

Eid/Pohela Boishakh-এ transaction pattern dramatic shift — "expected drift"।
Holiday calendar-এ retraining schedule plan।
Region-specific (Dhaka vs rural) — sub-population separately monitor।
Regulatory: BB CIRC notification ML model fraud-detection-এ change হলে।

(৬) Immediate action:

Roll back model previous version।
Per-feature investigate top ৫ shifted।
Producer team-এর সাথে coordination — recent change?
Retrain on last ৩০ days — quick fix।
Post-mortem & permanent monitoring।

(৭) Long-term — DQ + MLOps integration:

Feature store (Feast, Tecton) — training/serving consistency guarantee।
Data contract feature pipeline-এ।
Continuous training pipeline — weekly retrain, performance gate।
A/B testing prod-এ — instant rollback capability।

মূল উপলব্ধি: ML model "data product"। DQ + ML monitoring inseparable। DE team-এর responsibility producer থেকে feature pipeline পর্যন্ত quality guarantee — শুধু dashboard table নয়। bKash-এর fraud detection-এ এই discipline = revenue + regulatory peace of mind।

প্র ০৩ "Data contract" আদর্শ মনে হলেও — অনেক BD enterprise-এ producer team (backend) এই idea প্রতিরোধ করে। কী political/cultural barrier এবং কীভাবে gradually adoption?

Data contract — pure technology নয়, organizational change। BD enterprise-এ adoption-এ unique challenge আছে।

(১) সাধারণ resistance pattern:

"Backend team-এর কাজ feature delivery, schema documentation নয়।"
"Schema change-এ approval চাইলে — release slow হবে।"
"DE team-এর responsibility own data clean করা; producer-এ pressure কেন?"
"কে কী পড়ে — আমরা জানি না; contract-এ scope বিশাল।"

(২) BD-specific cultural factors:

Hierarchical org: backend team senior; DE relatively new function। Authority asymmetry।
Outsourcing legacy: অনেক backend code Brain Station 23 / Tiger IT এর built; vendor রা change-এ extra fee চায়।
"Quick wins" culture: startup speed prioritize; long-term contract overhead লাগে।
Documentation gap: general culture-এ documentation deprioritize।

(৩) Adoption strategy — incremental:

Phase 1 — observability (no contract):

Schema fingerprint daily snapshot — schema change auto-detect।
Slack-এ schema change post — backend team aware।
"Discovery, not enforcement"।

Phase 2 — top 3 critical pipelines:

Revenue, transaction, customer-এর mostly used 3 source।
Lightweight contract (just schema + freshness)।
Backend team-কে value দেখান: "তোমাদের bug 50% earlier catch হবে"।

Phase 3 — change-management workflow:

Schema change PR-এ contract validation — automated, কোনো extra meeting না।
Backward-compatible change auto-approve।
Breaking change-এ DE team approval, ৭-দিন notice।

Phase 4 — full SLO:

Freshness, completeness, uniqueness SLO।
SLA dashboard public।
Monthly review meeting।

(৪) Specific tactics:

Find a champion: backend tech lead যিনি data দাম বোঝেন; তার সাথে pilot।
Demonstrate ROI: "গত মাসে ৩টি incident ছিল backend silent change-এ; contract-এ ০ হবে"।
Tooling, না meeting: Buf, Apicurio, dbt-checkpoint — automated guardrail। Manual approval-এ resistance।
Carrot, না stick: contract-এ comply করা backend team-এর "data quality score" public; recognition।
Executive sponsor: CTO/CDO-এর mandate ছাড়া কোনো cross-team initiative টিকে না।

(৫) BD-context examples:

Robi-তে data contract initiative ২০২৩+ — payment + subscriber service-এ pilot। ৬ মাসে full rollout।
bKash-এ regulatory pressure (BB audit) ব্যবহার — "BB চায় lineage; contract সেটা দেয়"।
Daraz-এ Alibaba-র internal "data quality framework" inheritance।

(৬) Common mistakes:

একসাথে সব service-এ rollout — overwhelm।
Contract-এর YAML সংশ্লেষ — practical नয়। Markdown + auto-validation start।
"Compliance theater" — contract আছে কিন্তু enforce নেই।
Backend team-কে "blame" — collaborative tone।

(৭) Success indicator:

Schema change-related incident মাসে < ১।
Backend team contract-এ contribute (raise PR)।
Onboarding doc-এ contract pattern।
Cross-team review-এ contract-এর reference।

মূল উপলব্ধি: Data contract — DE team-এর "API maturity"। BD-এর hierarchical, fast-moving culture-এ ১৮-২৪ মাসের journey, technical না বরং political। Carrot + automated tooling + executive backing — তিনটি ছাড়া fail। কিন্তু সফল হলে — DE team "trustworthy partner" হিসেবে স্বীকৃত হয়।

প্র ০৪ আপনি Pathao Bangladesh-এর CDO। DE team-এর budget ১০০% বাড়াতে নয়, "data trust" measurably বাড়াতে চান। কী KPI সেট করবেন? কী anti-pattern এড়াবেন?

DQ measurement — তত্ত্বে সহজ, প্র্যাকটিসে সবচেয়ে complex DE leadership challenge। ভুল KPI-এ team খারাপ behavior optimize করে।

(১) ভাল KPI — outcome-based:

DQ Incident MTTD (Mean Time To Detect): bug introduce থেকে alert পর্যন্ত সময়। target < ১ ঘণ্টা।
DQ Incident MTTR (Mean Time To Resolve): alert থেকে fix পর্যন্ত। target < ৪ ঘণ্টা।
Test coverage: critical model-এ প্রতি column-এ at least ১ test। target > ৯০%।
Freshness SLO compliance: top ২০ table-এর % time SLA-এর মধ্যে। target > ৯৯%।
"Surprise" rate: dashboard নাম্বার ম্যানুয়ালি adjusted by analyst — incidents/মাস। target ↓।
Stakeholder trust survey: quarterly NPS — "DE-র data কতটা trust করেন?"

(২) Anti-pattern KPI — এড়ান:

"Test count": ৫,০০০ test add → meaningless। Quality না, vanity।
"Test pass rate": ১০০% pass → হয় test খুব loose, বা bad data filtered out।
"Pipeline uptime %": green pipeline-এ wrong data → false confidence।
"Dashboard count": বেশি = ভাল না। Source of truth single বরং।

(৩) Pathao-specific KPI:

Driver earning accuracy: driver-reported earning vs system-calculated discrepancy < ০.১%। (Driver retention-এ critical)।
Ride-event-to-warehouse latency: p99 < ৩ মিনিট।
Reconciliation: rides ↔ payments: daily > ৯৯.৯%।
Surge pricing input freshness: p99 < ৫ সেকেন্ড।

(৪) Tiered approach — not all data equal:

Tier 1 (mission critical): revenue, payments, driver earning — strictest SLO।
Tier 2 (business decision): marketing analytics, growth metrics — moderate।
Tier 3 (exploration): data science notebook, ad-hoc — best-effort।
প্রতিটি tier-এ আলাদা KPI; engineering investment proportional।

(৫) Incident-driven culture:

প্রতি DQ incident-এ blameless postmortem।
Root cause categorize: schema, pipeline, definition, infrastructure।
Top recurring cause-এ engineering investment।
Quarterly trend share — "এই quarter-এ schema-driven incident ৭০% কমেছে"।

(৬) Cross-functional governance:

Data Council — DE + analytics + product + finance — মাসিক।
Tier 1 metric definition committee approval।
Producer team-এ DQ scorecard।

(৭) Tooling investment:

dbt + Great Expectations — open source, ROI fast।
Monte Carlo / Bigeye — managed observability ($৫০K-১০০K/year), মাঝারি+ org-এ worth।
Custom dashboard — Grafana-এ DQ metric publish।

(৮) Realistic timeline:

৩ months — baseline measure, top ১০ table coverage।
৬ months — anomaly detection, freshness SLO।
১২ months — data contract top ৩ producers, NPS survey baseline।
১৮ months — culture shift visible, executive trust।

(৯) Investment ROI argument CFO-কে:

"১টি DQ incident = ৪ ঘণ্টা analyst rework + ১ delayed decision।"
"মাসে ১০ incident = ৪০ ঘণ্টা = ১.৫ লাখ BDT।"
"৫০% reduction = ৭৫,০০০ BDT/মাস + decision speed gain।"
"ROI ৬ মাসে; trust intangible কিন্তু compounding।"

মূল উপলব্ধি: Data trust technology নয় — measurement + culture + investment। সঠিক KPI behavior align করে; ভুল KPI gaming। Pathao-এর CDO-এর জন্য — outcome-based metrics, tiered approach, incident-driven learning, ১৮ মাসের patient roadmap। "Trustworthy data" = competitive advantage, BD-এর মাঝারি/বড় enterprise-এ।

অনুশীলন

5 dimension assign: bKash transactions table-এ নিচের প্রতিটি problem কোন DQ dimension-এ পড়ে?
(ক) ৫% rows-এ msisdn NULL।
(খ) gateway delay-এ tx warehouse-এ ৩০ মিনিট পরে আসে।
(গ) একই tx_id দু'বার insert।
(ঘ) amount_bdt-এ negative value।
(ঙ) payments service revenue ৪৭ লাখ, orders table revenue ৫০ লাখ।
- (ক) Completeness
- (খ) Timeliness
- (গ) Uniqueness
- (ঘ) Accuracy
- (ঙ) Consistency
প্রতিটি dimension-এর আলাদা test pattern ও remediation। সবগুলো একসাথে production-grade DQ।

dbt test লিখুন: Pathao fct_rides table-এ নিচের assertion-এ dbt schema.yml entries:
- ride_id unique ও not_null।
- fare_bdt ১ থেকে ১০,০০০ BDT।
- driver_id dim_driver টেবিল-এ থাকতে হবে।
- status = 'COMPLETED', 'CANCELLED', 'NO_SHOW' এর একটি।

version: 2
models:
  - name: fct_rides
    columns:
      - name: ride_id
        tests:
          - unique
          - not_null
      - name: fare_bdt
        tests:
          - dbt_utils.expression_is_true:
              expression: "fare_bdt BETWEEN 1 AND 10000"
      - name: driver_id
        tests:
          - relationships:
              to: ref('dim_driver')
              field: driver_id
      - name: status
        tests:
          - accepted_values:
              values: ['COMPLETED','CANCELLED','NO_SHOW']

Anomaly threshold বাছুন: Daraz-এর daily revenue last 90 days mean ৫ কোটি BDT, std ১ কোটি। আজ ১.৫ কোটি দেখাচ্ছে। Z-score কত? কী action নেবেন?
$z = (1.5 - 5) / 1 = -3.5$ — well below normal।
- $|z| > 3$ → strong anomaly।
- প্রথমে check — pipeline lag কি? Source delay কি?
- Reconciliation: orders count vs payments count।
- Time zone bug: BST/UTC mismatch?
- Holiday filter: কোনো sale-এর শেষ দিন?
- Producer service health check — partial outage?
- Stakeholder-এ early communication — "investigating, not raw"।
- Postmortem document রাখুন।