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

Home / AI Courses / ডেটা ইঞ্জিনিয়ারিং / Data Engineering কী

Data Engineering কী, কেন দরকার

What is data engineering — the plumbing behind AI

৬ মিনিট পড়া শুরু · Beginner ভূমিকা ও পাইপলাইন

এক নজরে · TL;DR

Data engineering = ডেটার "প্লাম্বিং"। বিভিন্ন উৎস থেকে ডেটা এনে, পরিষ্কার করে, এক জায়গায় রেখে — analytics ও AI-এর জন্য প্রস্তুত করা।
Pipeline-এর ৩ ধাপ: Extract (টানা), Transform (পরিষ্কার/রূপান্তর), Load (গন্তব্যে রাখা) — সংক্ষেপে ETL।
AI-এর ৮০% সময় ডেটায়। ভাল ডেটা ছাড়া কোনো মডেল কাজ করে না — তাই data engineer = AI-র মেরুদণ্ড।
BD-তে চাহিদা বাড়ছে: bKash, Daraz, Pathao, Grameenphone, ব্যাংক — সবাই data engineer খুঁজছে কারণ analytics ও AI ছাড়া কেউ এগোতে পারছে না।

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

Data engineering কী — এক বাক্যের সংজ্ঞা ও বাস্তব রূপ
একটি ডেটা পাইপলাইনের তিন স্তর — source, processing, destination
Data engineer-এর দিন কীভাবে কাটে — data scientist ও analyst-এর সাথে পার্থক্য
বাংলাদেশী কোম্পানিগুলো (bKash, Daraz, Pathao) কেন data engineer চাইছে

১ · Data Engineering — এক বাক্যে

Data engineeringData Engineeringবিভিন্ন উৎস (apps, sensors, files) থেকে raw data সংগ্রহ, পরিষ্কার ও রূপান্তর করে — analytics ও machine learning-এর জন্য প্রস্তুত একটি কেন্দ্রীয় storage-এ পৌঁছে দেওয়ার engineering discipline. হলো এমন একটি engineering শাখা যা raw data-কে এমনভাবে সাজায় যাতে data scientist, analyst ও AI মডেল সেগুলো নির্ভরযোগ্যভাবে ব্যবহার করতে পারে। সংক্ষেপে — "data-র প্লাম্বিং"।

ভাবুন bKash-এর কথা। প্রতি সেকেন্ডে হাজার হাজার transaction হচ্ছে — cash-in, send-money, payment, cash-out। প্রতিটি transaction একটি database row। কিন্তু ব্যবসার প্রশ্ন — "গত মাসে চট্টগ্রামের কোন এজেন্ট সবচেয়ে বেশি cash-in করেছে?" — এই কাঁচা table থেকে সরাসরি বের করা যায় না, slow হবে, production database-এ চাপ পড়বে। তাই data engineer একটি আলাদা পথ তৈরি করেন — raw transactions → পরিষ্কার warehouse → BI dashboard।

তিনটি কাজ data engineer-এর

১) Ingest: বিভিন্ন উৎস (database, API, file, stream) থেকে ডেটা টেনে আনা।
২) Transform: পরিষ্কার, validate, যোগ-বিয়োগ, নতুন কলাম, format রূপান্তর।
৩) Serve: ব্যবহারকারী (analyst, ML মডেল, dashboard) যেন সহজে query করতে পারে — warehouse, lake, বা feature store-এ রাখা।

২ · কেন এত গুরুত্বপূর্ণ — AI-র "৮০% rule"

Andrew Ng (Stanford AI অধ্যাপক, Coursera-র সহ-প্রতিষ্ঠাতা) বলেছেন — "৮০% of AI work is data." অর্থাৎ ML মডেলের code লেখা সহজতম অংশ; কঠিন অংশ — বিশ্বস্ত, পরিষ্কার, time-aligned ডেটা পাওয়া।

একজন data scientistData Scientistযিনি statistics, ML ও business জ্ঞান দিয়ে ডেটা থেকে insight ও predictive model তৈরি করেন। তাঁর কাজ হয় cleaned ডেটার উপরে — ডেটা সংগ্রহ ও cleaning data engineer-এর কাজ। যদি ৪ সপ্তাহ এক প্রজেক্টে কাজ করেন — বাস্তবে দেখা যায়:

৩ সপ্তাহ — ডেটা খোঁজা, join, পরিষ্কার, সমস্যা ডিবাগ।
১ সপ্তাহ — আসল মডেল prototype, বিশ্লেষণ ও presentation।

Data engineer থাকলে — এই ৩ সপ্তাহের কাজ আগে থেকেই করা থাকে। Data scientist শুধু একটি পরিষ্কার table-এ SELECT মেরে কাজ শুরু করতে পারেন। তাই data engineer ছাড়া data scientist-এর productivity ৪x কমে যায়।

ভাবুন একটি ভাল রেস্তোরাঁ। শেফ (data scientist) দারুণ রান্না করতে পারেন — কিন্তু যদি বাজার থেকে fresh মাছ-সবজি না আসে, kitchen-এ তেল-নুন না থাকে — কিছুই হবে না। সেই supply chain — বাজার থেকে kitchen পর্যন্ত — data engineer-এর কাজ। শেফকে শুধু রান্নায় মন দিতে হয়।

৩ · একটি Data Pipeline — কী থাকে

একটি data pipelineData Pipelineএকটি stepwise system যা ডেটাকে এক জায়গা থেকে আরেক জায়গায় নিয়ে যায় — প্রতিটি স্তরে কিছু validation, cleaning, বা transformation প্রয়োগ করে। সাধারণত automated ও scheduled (যেমন প্রতি রাত ২টায়)। তিনটি বড় ভাগে বিভক্ত — source, processing, destination।

(ক) Source — কোথা থেকে ডেটা আসে?

OLTP database: PostgreSQL, MySQL — live transactional data (যেমন bKash-এর transactions table)।
API: Stripe, SSLCommerz, Facebook Marketing API থেকে JSON।
Files: CSV upload, Excel রিপোর্ট, log file।
Streams: Kafka topic, IoT sensor (যেমন Pathao-র rider GPS)।
SaaS: Salesforce, HubSpot, Zendesk — CRM/support tool।

(খ) Processing — কী রূপান্তর?

Null/duplicate বাদ দেওয়া।
Currency conversion (USD → BDT)।
Time zone alignment (UTC → Asia/Dhaka)।
Multiple table-এর join (user + order + product)।
Aggregation (প্রতি দিনে কত revenue)।
PII masking (ফোন নম্বর hash করা)।

(গ) Destination — কোথায় রাখা?

Data warehouse: Snowflake, BigQuery, Redshift — analytics-এর জন্য optimized।
Data lake: S3, GCS, ADLS — raw + semi-structured সব।
Feature store: ML মডেলের জন্য pre-computed features (Feast, Tecton)।
BI tool: Tableau, Power BI, Metabase — dashboard-এর জন্য।

একটি ডেটা পাইপলাইনের পাখির চোখে দৃশ্য — বাঁ থেকে raw উৎস, মাঝে cleaning ও transformation, ডানে analytics-ready destination।

৪ · একজন Data Engineer-এর দিন কেমন কাটে

একটি BD fintech-এ junior data engineer-এর সাধারণ দিন:

সকাল ১০টা: Slack-এ alert — "প্রতি রাতে ২টায় চলা daily_revenue pipeline fail।" Airflow UI-তে log দেখা।
১১টা: বুঝলেন — SSLCommerz API থেকে গতরাতে একটি নতুন column এসেছে যা schema-তে নেই। Schema migration লেখা।
দুপুর ১টা: Analytics team-এর request — "Daraz campaign-এর ROI দরকার।" Snowflake-এ একটি নতুন marts.campaign_roi view তৈরি (dbt দিয়ে)।
৩টা: Code review — অন্য engineer-এর Spark job pull request।
৫টা: Cost review — গত মাসে BigQuery খরচ ৩০% বেড়েছে, কোন query expensive তা চেক করা।

Data engineer = ৪০% coding (SQL, Python), ৩০% debugging (broken pipeline, missing data), ২০% communication (analyst/PM-এর সাথে কথা), ১০% architecture/planning। Pure ML ও না, pure backend dev ও না — এই দু'টোর মাঝামাঝি।

৫ · Data Engineer বনাম Data Scientist বনাম Analyst

BD-তে কোম্পানি ছোট হলে এই তিন role প্রায়ই একজনই করেন — কিন্তু বড় টিমে আলাদা:

Data Analyst: SQL দিয়ে ব্যবসার প্রশ্নের উত্তর খোঁজেন, dashboard বানান। যেমন: "এ মাসে Sylhet-এ কত নতুন user?"
Data Scientist: Statistical model ও ML — prediction, classification। যেমন: "কোন user পরের সপ্তাহে churn করবে?"
Data Engineer: উপরের দু'জনের জন্য reliable, fast, fresh ডেটা সরবরাহ করেন। যেমন: "প্রতি রাতে ১০ source থেকে warehouse-এ ডেটা আনা।"
ML Engineer: Data scientist-এর model কে production-এ deploy ও maintain করেন।

US-এ data engineer-এর গড় বেতন data scientist-এর কাছাকাছি বা কখনো বেশি। কারণ data engineer scarce — অনেকে data science শিখতে চায়, কিন্তু engineering-এর "ময়লা" কাজ এড়ায়।

৬ · বাংলাদেশী context — কোম্পানি ও use case

bKash: দিনে কোটি কোটি transaction। Fraud detection ML মডেলের জন্য পরিষ্কার, real-time pipeline দরকার। Kafka + Spark Streaming।
Daraz: Recommendation engine — user-product interaction logs প্রতিদিন aggregate করতে হয়। Airflow + dbt + Snowflake stack।
Pathao: Surge pricing — rider-rider density ও demand real-time জানতে Kafka stream।
Grameenphone: Customer churn prediction — CDR (call detail records) থেকে feature engineering।
Sonali Bank, BB: Regulatory reporting — প্রতি মাসে BB-কে নির্দিষ্ট format-এ ডেটা পাঠাতে হয়। Pipeline reliability মানে compliance।
BTRC: Telecom operator-দের কাছ থেকে usage data সংগ্রহ ও validate।

৭ · একটি ছোট Pipeline — SQL-এ

নিচের কোডটি দেখায় — raw orders table থেকে কীভাবে একটি analytics-ready summary বানানো হয়। প্রতি রাতে এমন একটি query চলবে।

SQL

-- Daraz-এর dummy schema থেকে দৈনিক revenue summary
-- raw table: orders(order_id, user_id, amount_bdt, status, created_at)

INSERT INTO marts.daily_revenue
SELECT
    DATE(created_at AT TIME ZONE 'Asia/Dhaka') AS order_date,
    COUNT(*)                                   AS total_orders,
    COUNT(DISTINCT user_id)                    AS unique_buyers,
    SUM(amount_bdt)                            AS gross_revenue,
    SUM(amount_bdt) FILTER (WHERE status='completed') AS net_revenue
FROM raw.orders
WHERE created_at >= NOW() - INTERVAL '1 day'
GROUP BY 1
ORDER BY 1 DESC;

এই query একটি জিনিস করে — কোটি কোটি raw row থেকে গতকালের সারাংশ ৫টি column-এ কমিয়ে এনেছে। Analyst এখন marts.daily_revenue-এ মাত্র ৩৬৫ row দেখবেন — production database-এ কোনো চাপ পড়বে না।

৮ · Python-এ একটি ছোট ETL উদাহরণ

Python · pandas

import pandas as pd

# (E)xtract — CSV থেকে raw data
raw = pd.DataFrame({
    "user_id":    [101, 102, 103, 102, 104],
    "amount_bdt": [500, 1200, None, 800, 250],
    "city":       ["Dhaka", "Chattogram", "Khulna", "Dhaka", "Sylhet"],
})

# (T)ransform — null বাদ, city normalize, total
clean = (raw
    .dropna(subset=["amount_bdt"])
    .assign(city=lambda d: d["city"].str.upper())
)
summary = clean.groupby("city")["amount_bdt"].sum().reset_index()

# (L)oad — প্রকৃত pipeline-এ এটি warehouse-এ যেত
print(summary)
print(f"\nTotal rows in: {len(raw)}, out: {len(clean)}")

Output-এ city-ভিত্তিক total দেখবেন। ৫টি raw row → ৪টি cleaned row (একটি null বাদ) → ৩টি city aggregate। এটিই এক বাক্যে ETL-এর সারমর্ম।

প্রকৃত production pipeline-এ আরও থাকে — error handling, retry logic, schema validation, monitoring, alerting, audit log, data quality test। তাই data engineering শুধু code না — এটি একটি engineering discipline।

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

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

প্র ০১ আপনি bKash-এ যোগ দিলেন। প্রথম দিনে CTO বললেন — "fraud detection model-এর জন্য ডেটা চাই, এক সপ্তাহে।" আপনি data engineer হিসেবে কী কী step নেবেন? Source থেকে usable feature পর্যন্ত।

এটি একটি বাস্তবিক brief — এবং উত্তরে "শুধু code লিখি" বলা যাবে না। Data engineer-এর কাজ ৭০% planning, ৩০% coding।

(১) Stakeholder interview (দিন ১):

কোন ধরনের fraud? Multi-account abuse, agent collusion, transaction laundering?
Latency requirement? Real-time block (<১ সেকেন্ড) নাকি batch review (পরদিন)?
False positive cost vs false negative cost — কোনটি বেশি ক্ষতিকর?

(২) Data discovery (দিন ১-২):

Source identify — transactional PostgreSQL, KYC database, agent network table, device fingerprint log।
প্রতিটির schema, freshness, quality assess। PII (NID, ফোন) আলাদা টেবিলে কিনা চেক।
Existing data lake/warehouse আছে কি — reuse করা যায়?

(৩) Pipeline design (দিন ২-৩):

Real-time চাইলে — CDCChange Data Capture (CDC)Database-এ যা পরিবর্তন হচ্ছে (insert/update/delete) সেগুলো real-time-এ stream হিসেবে capture করা। Debezium, AWS DMS উল্লেখযোগ্য tool। দিয়ে PostgreSQL → Kafka → Spark Streaming → feature store।
Batch হলে — nightly Airflow DAG যা গত ২৪ ঘণ্টা scan করে।
PII handling — NID hash, ফোন masked।

(৪) Feature engineering (দিন ৩-৫):

Velocity — "গত ১ ঘণ্টায় কতবার cash-out", "নতুন device-এ first transaction"।
Network features — "এই agent কতজন user-কে cash-in দিয়েছে গতকাল"।
Geo — "user device location vs registration district"।

(৫) Validation ও handover (দিন ৬-৭):

Data scientist-কে sample notebook দিয়ে দেখানো।
Backfill 90 দিন history।
Monitoring — row count, null rate, schema drift alert।

মূল উপলব্ধি: "ডেটা চাই" শুনে SQL লেখার আগে — প্রশ্ন করতে হয়, plan করতে হয়, validate করতে হয়। যিনি এই process disciplined-ভাবে করেন — তিনি ভাল data engineer।

প্র ০২ একটি startup CEO বললেন — "data engineer লাগবে কেন? আমাদের database আছে, analyst সরাসরি query করুক।" তাঁকে কী যুক্তিতে রাজি করাবেন?

এই প্রশ্ন BD-র অনেক ছোট কোম্পানি-তে বাস্তব। প্রথম ৫০ user পর্যন্ত CEO-র যুক্তি ঠিক আছে — production database-এ analyst সরাসরি query করতে পারেন। কিন্তু scale বাড়লে চারটি বড় সমস্যা ফুটে ওঠে।

(১) Production load — user-experience ক্ষতি:

Analyst একটি বড় JOIN চালালে — production DB slow। User checkout fail।
একটি bKash-সদৃশ system-এ এটা catastrophic — প্রতি মিনিটের downtime মানে লাখ টাকা ক্ষতি।

(২) Schema mismatch — "একই" সংখ্যা কিন্তু আলাদা মানে:

Marketing dashboard বলে "৫০০০ user"; finance বলে "৪২০০ user"। কারণ — কে কোন definition নিয়েছে।
Data engineer central semantic layerSemantic Layerসব business metric (revenue, active user, churn) এক জায়গায় একটি definition-এ লেখা থাকে — যা সব dashboard ও report ব্যবহার করে। dbt ও LookML উদাহরণ। তৈরি করেন যেখানে "active user" একবার সংজ্ঞায়িত — সবাই সেটাই ব্যবহার করে।

(৩) History সংরক্ষণ:

Production DB-তে user-এর address overwrite হয় — পুরোনো address হারিয়ে যায়।
Analytics-এর জন্য "গত বছর Q3-তে user-এর address কী ছিল" দরকার। Warehouse-এ SCD type-2SCD Type 2 (Slowly Changing Dimension)একই entity-র ইতিহাস preserve করার pattern — পরিবর্তনের সময় নতুন row, valid_from/valid_to সহ। Audit ও time-travel analytics-এর ভিত্তি। দিয়ে এটা রক্ষা করা হয়।

(৪) AI/ML readiness:

Production DB-তে feature নেই — "user-এর last 30 days behavior", "rolling 7-day avg"।
ML মডেল চাইলে এই feature pre-compute করা থাকতে হবে — warehouse + feature store-এ।

BD-র বাস্তব উদাহরণ:

Pathao প্রথম দিকে শুধু MySQL ছিল। User বাড়ার সাথে সাথে BI query DB-কে slow করছিল — rider-driver matching delay। ২০২০-র পর BigQuery + Airflow stack।
Daraz-এর "personalized homepage" শুধু warehouse-এ pre-computed user features থেকে আসে — live DB-র উপর সম্ভব না।

CEO-কে কী বলবেন: "এখন analyst সরাসরি query করুক ঠিক আছে — কিন্তু আগামী ৬ মাসে যখন user ১০x হবে, dashboard load হতে ৫ মিনিট লাগবে, এবং প্রতিটি stakeholder ভিন্ন সংখ্যা দেখাবে। তখন একটা data engineer hire করার চেয়ে আগেই একটি minimal warehouse setup (Snowflake free tier + Airflow + dbt) করে রাখা competitive advantage।"

প্র ০৩ "GPT-4 আছে — data engineer-এর কাজ AI করে দেবে।" এই দাবি কতটুকু সত্য? ভবিষ্যতে data engineer-এর role কীভাবে বদলাবে?

২০২৪ থেকে এই debate তীব্র। বাস্তবতা — AI কিছু কাজ replace করছে, কিন্তু core data engineering আরও বেশি দরকারি হচ্ছে।

AI যা ভালো করছে:

SQL generation: "গতকালের top 10 user দেখাও" → GPT সঠিক query লিখে দেয়। Junior analyst-এর প্রায়-অর্ধেক কাজ এখন chat-এ।
Boilerplate code: Airflow DAG, dbt model, basic Spark job — GPT/Copilot ৭০% কোড লিখে দেয়।
Documentation: Schema doc, lineage description — auto-generated।
Data discovery: "এই warehouse-এ user-related কোন কোন table আছে?" — semantic search + LLM।

AI এখনো পারে না (এবং কাছাকাছি ভবিষ্যতে পারবে না):

Architecture decision: "Streaming না batch?", "Snowflake না BigQuery?" — এর উত্তর কোম্পানির cost, team skill, regulatory environment, future plan-এর উপর নির্ভর। GPT generic পরামর্শ দেয় — নির্দিষ্ট সিদ্ধান্ত নেয় না।
Business semantics: "active user" Daraz-এ মানে "৭ দিনে অর্ডার", কিন্তু Pathao-তে "৩০ দিনে rider book"। এই কাঠামো GPT জানে না — team-এর সাথে কথা বলেই বের হয়।
Production debugging: "Airflow DAG ৩টায় fail কেন?" — log দেখা, network trace, infrastructure context। এতে judgment লাগে।
Trust ও accountability: AI ৫০ লাখ টাকার regulatory report তৈরি করে দিল — ভুল হলে দায় কার? Engineer চাকরি হারান, AI না।
Cross-functional negotiation: Marketing চায় instant data, finance চায় audited data — এই trade-off engineer manage করেন।

২০২৬-২০৩০-এ data engineer-এর evolution:

Volume কমবে coding-এর — বাড়বে review-এর। AI কোড লিখবে, engineer review ও system fit check করবেন।
"Data product manager" hybrid role: শুধু pipeline না — ডেটার consumer-দের সাথে contract, SLA, lineage manage।
AI/LLM-এর জন্য বিশেষ pipeline: RAG-এর জন্য vector DB feeding, evaluation dataset curate, prompt versioning। এটি নতুন subdiscipline।
Quality ও governance বাড়ছে: AI-generated data (synthetic, hallucinated) সঠিক কিনা — এই validation engineer-এর জন্য নতুন priority।

BD context: bKash, Robi, GP — সবাই LLM ব্যবহার শুরু করেছে। কিন্তু কোম্পানির sensitive data LLM-এ পাঠানো যায় না (compliance)। তাই on-prem RAG, local fine-tuned model — data engineer-ই এই infrastructure তৈরি করেন।

মূল উপলব্ধি: "ছোট কাজ" replace হবে, "বড় কাজ" (architecture, judgment, accountability) বাড়বে। যিনি শুধু SQL/Python script লিখতেন তাঁর চাকরি risk-এ; যিনি system design করেন — তাঁর demand আরও বেশি।

প্র ০৪ Pathao একটি real-time pipeline চালায় — rider-এর GPS coordinate প্রতি ৫ সেকেন্ডে। দিনে ১০০ কোটি data point। কী কী challenge ও কীভাবে handle করতে হয়?

Real-time geospatial — data engineering-এর সবচেয়ে কঠিন একটি problem। চারটি বড় challenge।

(১) Volume ও cost:

১০০ কোটি event/day — প্রতিটি ~১০০ bytes — ১০ TB/day raw।
সাধারণ database-এ store করলে disk cost কোটি টাকা/বছর। তাই — tiered storage: hot data (গত ৭ দিন) S3 + Parquet; old data Glacier।
Sample compression: প্রতি ৫ সেকেন্ডের পরিবর্তে প্রতি ৩০ সেকেন্ডে যদি rider stationary — তাহলে কম log।

(২) Latency requirement:

"কাছাকাছি rider খুঁজে পেতে" — ১-২ সেকেন্ড latency target। PostgreSQL-এ unrealistic।
Redis Geo command — নির্দিষ্ট radius-এ rider খোঁজা O(log N)।
Kafka topic per city — Dhaka, Chattogram আলাদা partition।

(৩) Out-of-order ও late event:

Rider-এর ফোনে network glitch — ৫ মিনিট পর GPS event আসে। অন্য event-এর "future"-এ এটি যায়।
WatermarkWatermarkStreaming system-এ time-based threshold — এর আগের event late বলে বিবেচিত। Spark Structured Streaming, Flink-এ window operation-এর ভিত্তি। ও event-time processing — Flink/Spark Streaming-এ।
"Allow ১০ মিনিট late, তারপর drop" — এমন policy সেট।

(৪) Privacy ও regulatory:

প্রতিটি GPS = PII। BD-র Data Protection Act-এ user consent ও retention limit।
Raw GPS শুধু operational system-এ; analytics-এ aggregated (h3 hexagon, ৫ মিনিট bucket)।
BTRC ও law enforcement থেকে subpoena হলে — specific user-এর data দ্রুত retrieve করার ক্ষমতা থাকতে হবে। সেই index design।

সাধারণ Pathao-সদৃশ stack:

Ingestion: mobile app → API gateway → Kafka।
Real-time: Kafka → Flink → Redis (rider matching) + DynamoDB (last-known location)।
Analytics: Kafka → S3 (Parquet, partitioned by date+city) → Spark batch nightly → BigQuery।
ML: Spark feature → feature store → demand-prediction model → surge price API।

Common failure mode:

Kafka consumer lag — rider booking দেখাচ্ছে, কিন্তু rider নেই। Alert ও auto-scale।
"Hot partition" — ঢাকার Gulshan এলাকায় ১০x traffic, single broker overload। Re-partition by hex-grid।
Cross-region replica failover testing।

মূল উপলব্ধি: Real-time pipeline একটি engineering ও business trade-off। ১০০% latency কমানো অসম্ভব costly — "৯৯th percentile ১.৫ সেকেন্ড" target সাধারণ। এই trade-off-এর সংখ্যা PM-এর সাথে negotiate করেন data engineer।

অনুশীলন

লিখুন: Daraz-এর জন্য একটি minimal pipeline-এর তিনটি ধাপ লিখুন — কোন source, কোন transformation, কোন destination?
- Source: production PostgreSQL orders table (CDC বা nightly snapshot)।
- Transform: status filter (completed), amount_usd থেকে BDT conversion, daily aggregate by city।
- Destination: Snowflake marts.daily_revenue_by_city — analyst Metabase-এ dashboard বানান।
SQL লিখুন: উপরের code cell-এর pattern অনুসরণ করে — raw.users(user_id, city, signup_date) থেকে "প্রতি city-তে গত ৩০ দিনের new user count" বের করুন।
```
SELECT
    city,
    COUNT(*) AS new_users_30d
FROM raw.users
WHERE signup_date >= CURRENT_DATE - INTERVAL '30 days'
GROUP BY city
ORDER BY new_users_30d DESC;
```
ভাবুন: আপনার পরিচিত একটি BD ব্যবসায় (যেমন একটি স্কুল, রেস্তোরাঁ, ফার্মেসি) — কোন তিনটি ডেটা পাইপলাইন বানালে তাদের কাজ সহজ হবে?
একটি ফার্মেসি চেইনের উদাহরণ:
- Inventory pipeline: প্রতিটি ব্রাঞ্চের POS → central warehouse। প্রতি ঘণ্টায় stock-level dashboard।
- Sales analytics: দৈনিক বিক্রয় aggregate, top-selling drug per district, season trend।
- Reorder prediction: ML feature pipeline — কোন drug কোন branch-এ কবে শেষ হবে। Auto purchase order generation।
প্রতিটি pipeline business value generate করে — revenue বাড়ায় বা cost কমায়।