dbt MART Layer Explained | ref() & Snowflake Schema
dbt MART Layer Explained – Build Analytics-Ready Data with Snowflake
ஒரு proper Analytics Engineering Project-ல் Source Data-வை எடுத்தவுடன் நேரடியாக Power BI-க்கு கொண்டு செல்லக்கூடாது. முதலில் Data-வை clean செய்து, business requirements-க்கு ஏற்ற மாதிரி transform செய்ய வேண்டும்.
இதற்காக நம்முடைய architecture-ல் RAW → STAGING → MART என்ற Layered approach பயன்படுத்துகிறோம்.
RAW Layer-ல் Source Data Store செய்யப்படுகிறது. STAGING Layer-ல் Source Data Clean மற்றும் Standardize செய்யப்படுகிறது. அதற்குப் பிறகு Analytics மற்றும் Business requirements-க்கு தேவையான Data-வை MART Layer-ல் உருவாக்குகிறோம்.
STAGING Layer என்பது Source-oriented.
MART Layer என்பது Analytics-oriented.
What You Will Learn
- dbt MART Layer என்றால் என்ன?
- STAGING மற்றும் MART Layer-க்கு என்ன Difference?
- Business-friendly Column Names ஏன் முக்கியம்?
- dbt
ref()Function எப்படி வேலை செய்கிறது? - Model Dependency மற்றும் Lineage எப்படி உருவாகிறது?
- dbt Model-க்கு தனியாக Schema எப்படி Configure செய்வது?
- Schema Configuration Error ஏன் வருகிறது?
- Snowflake-ல் MART Model சரியாக உருவானதா என்பதை எப்படி Validate செய்வது?
- Power BI-க்கு MART Layer ஏன் சிறந்த Data Source?
What is a MART Layer?
MART Layer என்பது Business மற்றும் Analytics use cases-க்கு தேவையான Data-வை organized மற்றும் business-friendly format-ல் வழங்கும் Layer.
STAGING Layer-ல் Source Data-வை clean செய்து வைத்திருப்போம். ஆனால் அந்த Data அப்படியே Business Users அல்லது Power BI-க்கு பயன்படுத்துவதற்கு எப்போதும் சிறந்ததாக இருக்காது.
அதனால் MART Layer-ல்:
- Business-friendly Column Names
- Required Columns
- Business Logic
- Analytics-friendly Structure
- Power BI-க்கு தேவையான Data
ஆகியவற்றை கொண்டு வருகிறோம்.
STAGING vs MART Layer
| STAGING Layer | MART Layer |
|---|---|
| Source-oriented | Analytics-oriented |
| Source Data-வை Clean செய்கிறது | Business Logic Apply செய்கிறது |
| Technical Column Names இருக்கலாம் | Business-friendly Column Names |
| Transformation-ன் ஆரம்ப நிலை | Analytics-ready Data |
| Intermediate Layer | Business Consumption Layer |
Simple-ஆக சொல்ல வேண்டும் என்றால்:
MART = Prepare Data for Analytics
Updating the STAGING Layer
MART Layer உருவாக்குவதற்கு முன்பு STAGING Layer-ல் ஒரு முக்கியமான change தேவைப்படுகிறது.
Aircraft Data-வில் இருக்கும் position timestamp value-ஐ
proper timestamp format-ல் கொண்டு வர வேண்டும்.
Source Data-வில் இருக்கும் timestamp ஒரு numerical value-ஆக இருக்கலாம். அது actual date and time-ஐ represent செய்யும்.
அதை proper timestamp-ஆக convert செய்து:
position_timestamp
என்ற Column-ஆக பயன்படுத்துகிறோம்.
STAGING Layer-ல் Date and Time information இல்லையென்றால், அடுத்தடுத்த Analytics மற்றும் Time-based Analysis-க்கு அது Problem ஆகலாம்.
Making Column Names Business Friendly
Source API-யிலிருந்து வரும் Column Names Technical-ஆக இருக்கலாம். Analytics Layer-ல் அவற்றை Business Users எளிதாக புரிந்துகொள்ளும் வகையில் rename செய்வது நல்ல Practice.
உதாரணமாக:
| Source Column | MART Column |
|---|---|
icao24 |
aircraft_id |
baro_altitude |
altitude |
velocity |
speed |
true_track |
heading |
இது Data-வின் meaning-ஐ மாற்றுவது அல்ல. Data-வை Analytics-friendly மற்றும் understandable-ஆக மாற்றுவது.
Why Business-Friendly Names Matter
Power BI Model-ல் ஒரு Business User:
"இந்த Column என்ன?"
என்று கேட்காமல் Column Name பார்த்தவுடன் அதன் meaning-ஐ புரிந்துகொள்ள வேண்டும்.
அதனால் MART Layer-ல்:
- Clear Column Names
- Consistent Naming Convention
- Business-friendly Terminology
- Meaningful Data Structure
இருப்பது மிகவும் முக்கியம்.
Creating the dbt MART Model
இப்போது VS Code-ல் dbt Project-க்குள் MART Model உருவாக்கலாம்.
Project Structure-ஐ Layer-based approach-ல் maintain செய்வது நல்ல Practice.
models/
│
├── staging/
│ └── stage_open_sky_states.sql
│
└── mart/
└── mart_aircraft_activity.sql
இதன் மூலம் STAGING மற்றும் MART Models தனித்தனியாக organize செய்யப்படுகின்றன.
Using dbt ref() Function
MART Model-ல் முக்கியமாக பயன்படுத்தப்படும் dbt Concept:
ref().
ref() Function மூலம் ஒரு dbt Model-ஐ மற்றொரு dbt Model-க்கு
reference செய்ய முடியும்.
உதாரணமாக:
SELECT
icao24,
baro_altitude,
velocity,
true_track
FROM {{ ref('stage_open_sky_states') }}
இங்கே ref() மூலம் STAGING Model-ஐ reference செய்கிறோம்.
இதனால் dbt-க்கு:
என்பது தெரியும்.
Why ref() Is Important in dbt
ref() என்பது வெறும் Table Name எழுதுவதற்கான alternative அல்ல.
இது dbt-ன் மிகவும் முக்கியமான Concepts-ல் ஒன்று.
ஒரு Model மற்றொரு Model-ஐ reference செய்யும்போது dbt அந்த dependency-ஐ understand செய்து Lineage உருவாக்கும்.
RAW
↓
STAGING
↓
MART
இந்த Dependency Graph-ஐ dbt பயன்படுத்தி Data Lineage மற்றும் Model Execution Order-ஐ manage செய்ய முடியும்.
ref() பயன்படுத்தினால் dbt-க்கு Model Dependency தெரியும்.
ref() vs Hardcoded Table Name
| Hardcoded Table | dbt ref() |
|---|---|
| Static Reference | Dynamic dbt Reference |
| Dependency தெளிவாக இருக்காது | Dependency dbt-க்கு தெரியும் |
| Lineage Management கடினம் | Automatic Lineage |
| Environment Handling குறைவு | dbt Model-aware Reference |
Testing the SQL Before Running dbt
dbt Model-ஐ Run செய்வதற்கு முன்பு SQL Logic சரியாக இருக்கிறதா என்பதை Snowflake-ல் Test செய்வது ஒரு நல்ல Practice.
முதலில் SQL-ஐ தனியாக Run செய்து:
- Column Names சரியா?
- Data கிடைக்கிறதா?
- Transformation சரியாக இருக்கிறதா?
- Expected Records வருகிறதா?
என்பதை Validate செய்யலாம்.
இந்த validation successful ஆன பிறகு dbt Model-ஐ Run செய்யலாம்.
A Common dbt Error – Unexpected Semicolon
MART Model Run செய்யும்போது ஒரு common SQL error வரலாம்.
உதாரணமாக:
Unexpected ';'
இந்த error-க்கு காரணம் SQL Script-ன் end-ல் இருக்கும் semicolon ஆக இருக்கலாம்.
சில SQL environments-ல் ஒரு SQL Statement-ஐ terminate செய்ய:
;
பயன்படுத்துவது normal.
ஆனால் dbt Model SQL-ல் அந்த semicolon தேவையில்லாமல் இருக்கலாம்.
How to Fix It
- Model SQL-ன் end-ஐ Check செய்யுங்கள்.
- Extra semicolon இருக்கிறதா என்று பாருங்கள்.
- தேவையில்லாத semicolon-ஐ Remove செய்யுங்கள்.
- File-ஐ Save செய்யுங்கள்.
- மீண்டும் dbt Model-ஐ Run செய்யுங்கள்.
Error Message-ஐ பார்த்தவுடன் முழு SQL-ஐ மாற்ற வேண்டாம். முதலில் Error எந்த Line மற்றும் எந்த Syntax-ஐ Point செய்கிறது என்பதை Check செய்யுங்கள்.
Understanding dbt Schema Configuration
MART Model உருவாக்கப்பட்ட பிறகு இன்னொரு முக்கியமான Problem வரலாம்: Model சரியான Schema-ல் Create ஆகாமல் போவது.
உதாரணமாக நம்முடைய expectation:
SNOWFLAKE
│
├── STAGING
│
└── MART
└── AIRCRAFT_ACTIVITY
ஆனால் configuration சரியாக இல்லையென்றால் MART Model:
STAGING
└── AIRCRAFT_ACTIVITY
என்ற Schema-ல் Create ஆகலாம்.
Why Did the MART Model Go to STAGING?
dbt Project-ஐ initialize செய்யும்போது Profile Configuration-ல் ஒரு default Schema கொடுக்கப்படும்.
உதாரணமாக:
schema: staging
என்று இருந்தால், அந்த default configuration-ஐ பயன்படுத்தும் Models STAGING Schema-ல் Create ஆகலாம்.
ஆனால் நமக்கு MART Model மட்டும் வேறு Schema-வில் Create செய்ய வேண்டும்.
அதற்காக அந்த particular Model-க்கு specific configuration கொடுக்கலாம்.
Setting Schema for a Specific dbt Model
Model configuration-ல்:
{{ config(
schema='mart'
) }}
போன்ற configuration பயன்படுத்தலாம்.
இதன் மூலம் அந்த particular Model-க்கு தேவையான Schema configuration கொடுக்கப்படுகிறது.
Global/default Schema configuration ஒரு பொதுவான setting. ஒரு particular Model-க்கு தேவையானால் Model-level configuration மூலம் அதை override செய்யலாம்.
Model-Level Configuration vs Default Configuration
| Configuration | Purpose |
|---|---|
| Default Schema | Models-க்கு Default Destination |
| Model-level Schema | ஒரு Specific Model-க்கு Destination மாற்ற |
இதனால் STAGING Models STAGING Schema-ல் இருந்துகொண்டு, MART Models MART Schema-ல் இருக்க முடியும்.
Cleaning Up the Incorrect Model
Model முதலில் தவறான Schema-ல் Create செய்யப்பட்டிருந்தால், அதை அப்படியே விட்டுவிடக்கூடாது.
முதலில் Incorrect Object-ஐ Drop செய்து, Configuration சரி செய்த பிறகு Model-ஐ மீண்டும் Run செய்யலாம்.
உதாரணமாக Snowflake-ல் View ஆக இருந்தால்:
DROP VIEW schema_name.view_name;
போன்ற SQL மூலம் தேவையான Object-ஐ Remove செய்யலாம்.
Production Environment-ல் எந்த Database Object-ஐ Drop செய்வதற்கும் முன்பு Dependency மற்றும் Impact-ஐ Check செய்வது அவசியம்.
Validating the MART Model in Snowflake
dbt Model Successfully Run ஆனது மட்டும் போதாது. Model சரியான Data-வை Return செய்கிறதா என்பதையும் Validate செய்ய வேண்டும்.
முதலில் simple query மூலம் Data இருக்கிறதா என்று Check செய்யலாம்.
SELECT *
FROM MART.AIRCRAFT_ACTIVITY
LIMIT 10;
இதன் மூலம் Sample Records சரியாக வந்திருக்கிறதா என்பதை பார்க்கலாம்.
Basic Data Validation Checklist
MART Model உருவாக்கிய பிறகு குறைந்தபட்சம் இந்த validations-ஐ செய்யுங்கள்:
- Model சரியான Schema-ல் Create ஆகியுள்ளதா?
- Expected Columns இருக்கிறதா?
- Column Names சரியாக இருக்கிறதா?
- Data Types சரியாக இருக்கிறதா?
- Sample Records கிடைக்கிறதா?
- Record Count Expected அளவில் இருக்கிறதா?
- Null Values Unexpected-ஆக இருக்கிறதா?
- Business Logic சரியாக Apply ஆகியுள்ளதா?
Checking Record Count
ஒரு simple record count validation மிகவும் useful.
SELECT COUNT(*)
FROM MART.AIRCRAFT_ACTIVITY;
இதன் மூலம் MART Layer-ல் Records Load ஆகியுள்ளதா என்பதை Quick-ஆக Check செய்யலாம்.
ஆனால் Count மட்டும் பார்த்து Data Correct என்று முடிவு செய்யக்கூடாது. Model-ன் Business Requirements மற்றும் Data Quality Rules அடிப்படையில் Additional Validation செய்ய வேண்டும்.
Why Validation Is Important
ஒரு dbt Model:
- Successfully Compile ஆகலாம்.
- Successfully Run ஆகலாம்.
- Snowflake-ல் Object Create ஆகலாம்.
ஆனால் Data Logic தவறாக இருக்க வாய்ப்பு இருக்கிறது.
அதனால்:
எப்போதும் Technical Validation மற்றும் Business Validation இரண்டையும் consider செய்ய வேண்டும்.
From MART to Power BI
MART Model சரியாக உருவாக்கப்பட்டு Validate செய்யப்பட்ட பிறகு, அடுத்த Layer Power BI.
இங்கே முக்கியமான Difference:
Power BI-க்கு Raw JSON அனுப்பப் போவதில்லை.
Power BI-க்கு:
Business-ready Table
↓
Power BI
↓
Data Model
↓
Measures
↓
Visuals
↓
Dashboard
என்ற Flow இருக்கும்.
இதனால் Power BI-ல் Data Modeling மற்றும் Visualization மிகவும் எளிதாகும்.
Complete Analytics Engineering Flow
↓
Python
↓
Snowflake RAW
↓
dbt STAGING
↓
dbt MART
↓
Power BI
ஒவ்வொரு Layer-க்கும் ஒரு specific responsibility இருக்கிறது.
| Layer | Responsibility |
|---|---|
| OpenSky API | Flight Data Source |
| Python | Data Ingestion |
| Snowflake RAW | Source Data Storage |
| STAGING | Clean & Standardize |
| MART | Business & Analytics Logic |
| Power BI | Analytics & Visualization |
Common Mistakes to Avoid
❌ Mistake 1: Technical Column Names-ஐ அப்படியே பயன்படுத்துவது
Business Users புரிந்துகொள்ள முடியாத Column Names இருந்தால் Analytics Layer மிகவும் difficult ஆகிவிடும்.
✅ Better Approach
MART Layer-ல் meaningful மற்றும் business-friendly Column Names பயன்படுத்துங்கள்.
❌ Mistake 2: ref() பயன்படுத்தாமல் Hardcoded Table Names
Hardcoded References பயன்படுத்தினால் dbt Model Dependency மற்றும் Lineage proper-ஆக manage செய்ய முடியாமல் போகலாம்.
✅ Better Approach
FROM {{ ref('stage_open_sky_states') }}
❌ Mistake 3: Default Schema-ஐ மட்டும் நம்புவது
Project-ல் Default Schema STAGING என்றால் MART Model கூட STAGING-ல் Create ஆகும் வாய்ப்பு உள்ளது.
✅ Better Approach
MART Model-க்கு தேவையான Schema-ஐ Model-level Configuration மூலம் specify செய்யுங்கள்.
❌ Mistake 4: dbt Run Success-ஐ Data Validation என்று நினைப்பது
Model Successfully Run ஆனாலும் Data Logic தவறாக இருக்கலாம்.
✅ Better Approach
Sample Data, Record Count, Column Structure மற்றும் Business Logic அனைத்தையும் Validate செய்யுங்கள்.
Key Takeaways
- ✅ MART Layer என்பது Analytics-oriented Layer.
- ✅ STAGING Layer Source-oriented; MART Layer Analytics-oriented.
- ✅ MART Layer-ல் Business-friendly Column Names பயன்படுத்தலாம்.
- ✅
ref()என்பது dbt-ன் முக்கியமான Function. - ✅
ref()மூலம் Model Dependency மற்றும் Lineage உருவாகிறது. - ✅ dbt Model Run செய்வதற்கு முன்பு SQL-ஐ Validate செய்வது நல்ல Practice.
- ✅ Unexpected Semicolon போன்ற SQL Syntax Errors dbt Model Run-ல் Problem கொடுக்கலாம்.
- ✅ Default Schema configuration காரணமாக Model தவறான Schema-ல் Create ஆகலாம்.
- ✅ ஒரு Specific Model-க்கு Schema Configuration Override செய்யலாம்.
- ✅ MART Model உருவான பிறகு Snowflake-ல் Data Validation செய்ய வேண்டும்.
- ✅ Successful dbt Run என்பது Data Correct என்பதற்கான Guarantee அல்ல.
- ✅ Power BI-க்கு Raw JSON-ஐ விட Business-ready MART Table மிகவும் பயனுள்ளதாக இருக்கும்.
Frequently Asked Questions
1. dbt MART Layer என்றால் என்ன?
dbt MART Layer என்பது Business மற்றும் Analytics use cases-க்கு தேவையான Business-ready Data Models உருவாக்கப்படும் Layer.
2. STAGING மற்றும் MART Layer-க்கு என்ன Difference?
STAGING Layer முக்கியமாக Source Data-வை Clean மற்றும் Standardize செய்கிறது. MART Layer அந்த Cleaned Data-வை Business மற்றும் Analytics requirements-க்கு ஏற்றவாறு Transform செய்கிறது.
3. dbt ref() Function ஏன் பயன்படுத்தப்படுகிறது?
ref() மூலம் ஒரு dbt Model-ஐ மற்றொரு Model-ல் Reference செய்யலாம்.
இதன் மூலம் dbt Model Dependency மற்றும் Data Lineage-ஐ understand செய்ய முடியும்.
4. dbt Model ஏன் தவறான Schema-ல் Create ஆகிறது?
Project Profile அல்லது default configuration-ல் கொடுக்கப்பட்ட Schema காரணமாக Model அந்த Schema-ல் Create ஆகலாம். தேவையான Model-க்கு Model-level Schema Configuration கொடுத்து இதை மாற்றலாம்.
5. dbt Model Run Success ஆனால் Data தவறாக இருக்க முடியுமா?
ஆம். dbt Model technically Successfully Run ஆகலாம். ஆனால் SQL Logic அல்லது Business Logic தவறாக இருக்கலாம். அதனால் Data Validation அவசியம்.
6. MART Layer Power BI-க்கு ஏன் பயன்படுத்தப்படுகிறது?
MART Layer Business-friendly மற்றும் Analytics-ready Data-வை வழங்குவதால் Power BI Data Modeling மற்றும் Visualization செய்வது எளிதாகிறது.
7. MART Model-ஐ எப்படி Validate செய்வது?
முதலில் சரியான Schema-ல் Model Create ஆகியுள்ளதா என்பதை Check செய்யுங்கள். பிறகு Sample Records, Column Names, Data Types, Record Count மற்றும் Business Logic ஆகியவற்றை Validate செய்யலாம்.
8. Hardcoded Table Name-க்கு பதிலாக ref() ஏன் பயன்படுத்த வேண்டும்?
ref() பயன்படுத்துவதன் மூலம் dbt Model Dependency மற்றும் Lineage-ஐ
Manage செய்ய முடியும். இது dbt Project-ஐ Maintain செய்வதற்கும் Scale செய்வதற்கும்
முக்கியமானது.
Conclusion
ஒரு Analytics Engineering Project-ல் MART Layer என்பது மிகவும் முக்கியமான Layer.
STAGING Layer-ல் Source Data-வை Clean செய்து Standardize செய்த பிறகு, அந்த Data-வை Business மற்றும் Analytics requirements-க்கு ஏற்றவாறு MART Layer-ல் Transform செய்கிறோம்.
இந்த process-ல் dbt ref() Function மிகவும் முக்கியமானது. ஒரு Model மற்றொரு Model-ஐ எப்படி depend செய்கிறது என்பதை dbt understand செய்து Data Lineage உருவாக்குவதற்கு இது உதவுகிறது.
அதேபோல் dbt Configuration-ஐ சரியாக புரிந்துகொள்வதும் முக்கியம். Default Schema காரணமாக MART Model தவறான Schema-ல் Create ஆகலாம். அந்த particular Model-க்கு Schema Configuration கொடுத்து இதை சரி செய்யலாம்.
மேலும் ஒரு முக்கியமான lesson:
அதனால் ஒவ்வொரு Model-ஐயும் Run செய்த பிறகு Sample Records, Record Count, Column Structure மற்றும் Business Logic ஆகியவற்றை Validate செய்வது ஒரு நல்ல Analytics Engineering Practice.
இப்போது நம்முடைய MART Layer Ready. அடுத்த Step-ல் இந்த Business-ready Data-வை Power BI-க்கு கொண்டு சென்று Actual Analytics மற்றும் Visuals உருவாக்கலாம்.
👉 இந்த concept-ஐ முழுமையாக Demo உடன் பார்க்க கீழே உள்ள video-வை கண்டிப்பாக பாருங்கள்.
Watch the Video
🎥 இந்த topic-ஐ Step-by-Step Demo-வாக பார்க்க கீழே உள்ள YouTube video-வை பாருங்கள்.
Related Topics
- Analytics Engineering Project with OpenSky API
- OpenSky API and Flight Data
- Python Data Pipeline
- Snowflake RAW Layer
- dbt STAGING Layer
- dbt ref() Function
- dbt Model Dependencies
- Snowflake Schema Configuration
- Power BI Aviation Analytics Dashboard

கருத்துரையிடுக
0 கருத்துகள்