dbt क्या है? डेटा इंजीनियरों के लिए हैंड्स-ऑन परिचय

dbt इंस्टॉलेशन और सेटअप

इस ट्यूटोरियल के लिए हम Google Cloud BigQuery को डेटा वेयरहाउस समाधान के रूप में उपयोग करेंगे। इसका फ़्री टियर सीखने के लिए एक बेहतरीन विकल्प है। आप अपने Google Cloud अकाउंट में BigQuery सक्रिय कर सकते हैं।

हम Python और pip मैनेजर का उपयोग करके लोकली dbt इंस्टॉल करेंगे, एक वर्चुअल एनवायरनमेंट बनाएँगे और सैंपल मॉडल्स व टेस्ट चलाना शुरू करेंगे।

अपने कमांड लाइन में निम्न कमांड चलाएँ:

pip install virtualenv
mkdir dbt
cd dbt
virtualenv dbt_env -p python3.9
source dbt_env/bin/activate
pip install -r requirements.txtसंचालित द्वारा

हमारे requirements.txt में निम्न डिपेंडेंसीज़ होनी चाहिए:

dbt-core==1.8.6
dbt-bigquery==1.8.2
dbt-extractor==0.5.1
dbt-semantic-interfaces==0.5.1संचालित द्वारा

इसके बाद, ट्यूटोरियल के शेष हिस्से के लिए हम यह करेंगे:

1. Google प्रोजेक्ट सर्विस अकाउंट का उपयोग करके dbt को BigQuery से कनेक्ट करेंगे।
2. अपने सैंपल मॉडल्स बनाएँगे और उन्हें चलाएँगे।
3. अपने मॉडलों में डेटा गुणवत्ता और यूनिट टेस्ट जोड़ेंगे।
4. डॉक्युमेंटेशन जनरेट करेंगे।

आइए, अपने dbt एप्लिकेशन के लिए सर्विस अकाउंट क्रेडेंशियल्स बनाएँ:

• अपने Google Cloud IAM कंसोल पर जाएँ, और “Service Accounts” सेक्शन में BigQuery Admin परमिशन्स के साथ नया सर्विस अकाउंट बनाएँ:

Google Cloud में BigQuery के लिए सर्विस अकाउंट बनाना। चित्र: लेखक द्वारा।

• सर्विस अकाउंट के लिए नया JSON की बनाएँ और इसे सुरक्षित जगह पर रखें, क्योंकि आगे इसकी आवश्यकता पड़ेगी:

सर्विस अकाउंट प्राइवेट की को JSON फ़ॉर्मेट में सेव करना। चित्र: लेखक द्वारा।

• अब, टर्मिनल में dbt init कमांड चलाकर अपना dbt प्रोजेक्ट इनिशियलाइज़ करें। 

• प्रॉम्प्ट्स का अनुसरण करते हुए अपने dbt प्रोजेक्ट की सेटिंग्स निर्धारित करें और BigQuery सर्विस अकाउंट क्रेडेंशियल्स का पाथ दें।

सेटअप पूरा होने पर आपको इस तरह का संदेश दिखेगा: 

19:18:45  Profile my_dbt written to /Users/mike/.dbt/profiles.yml using target's profile_template.yml and your supplied values. Run 'dbt debug' to validate the connection.संचालित द्वारा

और फ़ोल्डर स्ट्रक्चर कुछ इस तरह दिखेगा:

.
├── my_dbt
│   ├── README.md
│   ├── analyses
│   ├── dbt_project.yml
│   ├── macros
│   ├── models
│   ├── polybox-data-dev.json
│   ├── seeds
│   ├── snapshots
│   └── tests
├── dbt_env
│   ├── bin
│   ├── lib
│   └── pyvenv.cfg
├── logs
│   └── dbt.log
├── readme.md
└── requirements.txtसंचालित द्वारा

हम देख सकते हैं कि profiles.yml हमारी लोकल मशीन के रूट फ़ोल्डर में बनाया गया है, लेकिन आदर्श रूप से हम इसे अपने एप्लिकेशन फ़ोल्डर में रखना चाहेंगे, तो आइए इसे शिफ़्ट करते हैं।

cd my_dbt
touch profiles.ymlसंचालित द्वारा

अंत में, profiles.yml की सामग्री को अपने प्रोजेक्ट के नाम और Google सर्विस अकाउंट क्रेडेंशियल्स के अनुरूप समायोजित करें:

my_dbt:
 target: dev
 outputs:
   dev:
     type: bigquery
     method: service-account-json
     project: dbt_bigquery_dev # replace with your-bigquery-project-name
     dataset: source
     threads: 4 # Must be a value of 1 or greater
     # [OPTIONAL_CONFIG](#optional-configurations): VALUE
     # These fields come from the service account json keyfile
     keyfile_json:
       type: service_account
       project_id: your-bigquery-project-name-data-dev
       private_key_id: bd709bd92708a38ae33abbff0
       private_key: "-----BEGIN PRIVATE KEY-----\nMIIEv...
       ...
       ...
       ...q8hw==\n-----END PRIVATE KEY-----\n"
       client_email: some@your-bigquery-project-name-data-dev.iam.gserviceaccount.com
       client_id: 1234
       auth_uri: https://accounts.google.com/o/oauth2/auth
       token_uri: https://oauth2.googleapis.com/token
       auth_provider_x509_cert_url: https://www.googleapis.com/oauth2/v1/certs
       client_x509_cert_url: https://www.googleapis.com/robot/v1/metadata/x509/educative%40bq-shakhomirov.iam.gserviceaccount.comसंचालित द्वारा

बस इतना ही! अब हम अपना प्रोजेक्ट कम्पाइल करने के लिए तैयार हैं। 

• कमांड लाइन में यह चलाएँ:

export DBT_PROFILES_DIR='.'
dbt compileसंचालित द्वारा

आउटपुट कुछ इस तरह होगा:

(dbt_env) mike@MacBook-Pro my_dbt % dbt compile
19:47:32  Running with dbt=1.8.6
19:47:33  Registered adapter: bigquery=1.8.2
19:47:33  Unable to do partial parsing because saved manifest not found. Starting full parse.
19:47:34  Found 2 models, 4 data tests, 479 macros
19:47:34 
19:47:35  Concurrency: 4 threads (target='dev')संचालित द्वारा

हमारा शुरुआती प्रोजेक्ट सेटअप पूरा हो गया है।

dbt प्रोजेक्ट स्ट्रक्चर

हम अपना dbt प्रोजेक्ट इस तरह डिज़ाइन करना चाहते हैं कि वह सुविधाजनक और पारदर्शी हो तथा डेटा वेयरहाउस आर्किटेक्चर को स्पष्ट रूप से दर्शाए।

मैं सलाह दूँगा/दूँगी कि आप अपने dbt प्रोजेक्ट में टेम्पलेट्स और मैक्रोज़ का उपयोग करें और कस्टम डेटाबेस नामों को शामिल करें, ताकि आप अपने डेटा एनवायरनमेंट्स—प्रोडक्शन, डेवलपमेंट और टेस्टिंग—को प्रभावी रूप से अलग कर सकें। 

यह दृष्टिकोण संगठन में सुधार करता है और गलत एनवायरनमेंट में आकस्मिक परिवर्तन के जोखिम को कम करता है, जिससे समग्र डेटा प्रबंधन और वर्कफ़्लो स्थिरता बढ़ती है। ऐसा करने से हम इन एनवायरनमेंट्स को आसानी से मैनेज और मेंटेन कर सकते हैं, जो सुनिश्चित करता है कि प्रोडक्शन डेटा सुरक्षित रहे और प्रयोगात्मक या टेस्ट परिवर्तनों से अप्रभावित रहे। 

विभिन्न एनवायरनमेंट्स में डेटाबेस का नामकरण भी सुसंगत और संरचित ढंग से प्रासंगिक सuffixes (_prod, _dev, _test) का उपयोग करके किया जा सकता है, जिससे एनवायरनमेंट्स को अलग-अलग पहचानना आसान हो जाता है और ट्रांज़िशन व डिप्लॉयमेंट सुगम होते हैं।

प्रोडक्शन एनवायरनमेंट में डेटा वेयरहाउस की विभिन्न लेयरें। चित्र: लेखक द्वारा।

उदाहरण के लिए, हम मुख्य डेटा मॉडल लेयर्स को डेटाबेस नामकरण कन्वेंशन में स्थानांतरित कर सकते हैं और डेटाबेस नेमिंग में raw_ और base_ प्रीफ़िक्स का उपयोग कर सकते हैं:

Schema/Dataset  Tanle
RAW_DEV         SERVER_DB_1     -- mocked data
RAW_DEV         SERVER_DB_2     -- mocked data
RAW_DEV         EVENTS          -- mocked data
RAW_PROD        SERVER_DB_1     -- real production data from pipelines
RAW_PROD        SERVER_DB_2     -- real production data from pipelines
RAW_PROD        EVENTS          -- real production data from pipelines
...                           
BASE_PROD       EVENTS          -- enriched data
BASE_DEV        EVENTS          -- enriched data
...                           
ANALYTICS_PROD       REPORTING  -- materialized queries and aggregates
ANALYTICS_DEV        REPORTING
ANALYTICS_PROD       AD_HOC     -- ad-hoc queries and viewsसंचालित द्वारा

इन कस्टम डेटाबेस नामों को डायनेमिक रूप से इंजेक्ट करने के लिए, आपको केवल एक dbt मैक्रो बनाना होगा जो यह काम स्वतः संभाल ले। इस दृष्टिकोण का लाभ उठाते हुए, आप सुनिश्चित कर सकते हैं कि उपयुक्त डेटा एनवायरनमेंट में सही डेटाबेस नाम उपयोग हों, और हर बार कॉन्फ़िगरेशन को मैन्युअली एडिट करने की ज़रूरत न पड़े। 

आइए नीचे दिया गया कोड स्निपेट देखें, जिसमें एक मैक्रो है जो इस बात पर अलग-अलग स्कीमा सेट करता है कि हम किस एनवायरनमेंट में हैं:

-- cd my_dbt
-- ./macros/generate_schema_name.sql
{% macro generate_schema_name(custom_schema_name, node) -%}
   {%- set default_schema = target.schema -%}
   {%- if custom_schema_name is none -%}
       {{ default_schema }}
   {%- else -%}
       {{ custom_schema_name | trim }}
   {%- endif -%}
{%- endmacro %}संचालित द्वारा

अब, जब भी हम अपने मॉडल्स को कम्पाइल करेंगे, dbt प्रत्येक मॉडल की कॉन्फ़िगरेशन के आधार पर स्वतः कस्टम डेटाबेस नाम लागू करेगा। यानी कम्पाइलेशन के दौरान सही डेटाबेस नाम इंजेक्ट हो जाएगा, जिससे मॉडल्स उचित एनवायरनमेंट—प्रोडक्शन, डेवलपमेंट या टेस्टिंग—के अनुरूप रहेंगे। 

इस फ़ीचर को शामिल करके, हम डेटाबेस नामों में मैन्युअल बदलाव की आवश्यकता समाप्त कर देते हैं, जिससे वर्कफ़्लो और अधिक कुशल और सटीक बनता है। 

ये आवश्यक कॉन्फ़िगरेशन हम अपने मॉडलों के लिए properties.yml में सेट कर सकते हैं:

# my_dbt/models/example/properties.yml
version: 2
models:
 - name: table_a
   config:
     description: "A starter dbt model"
     schema: |
       {%- if  target.name == "dev" -%} raw_dev
       {%- elif target.name == "prod"  -%} raw_prod
       {%- elif target.name == "test"  -%} raw_test
       {%- else -%} invalid_database
       {%- endif -%}
     columns:
       - name: id
         description: "The primary key for this table"
         tests:
           - unique
           - not_null
 - name: table_b
   config:
     description: "A starter dbt model"
     schema: |
       {%- if  target.name == "dev" -%}    analytics_dev
       {%- elif target.name == "prod"  -%} analytics_prod
       {%- elif target.name == "test"  -%} analytics_test
       {%- else -%} invalid_database
       {%- endif -%}
     columns:
       - name: id
         description: "The primary key for this table"
         tests:
           - unique
           - not_nullसंचालित द्वारा

जैसा कि आप देख सकते हैं, dbt में Jinja सपोर्ट होने के कारण हम कॉन्फ़िगरेशन फ़ाइलों में बेसिक कंडीशनल स्टेटमेंट्स का उपयोग करके लॉजिक जोड़ सकते हैं।

हालाँकि इस संदर्भ में मैक्रोज़ का उपयोग नहीं किया जा सकता, लेकिन हम .yml फ़ाइलों में Jinja एक्सप्रेशंस के ज़रिए साधारण कंडीशनल्स का उपयोग कर सकते हैं। इन्हें उद्धरण-चिन्हों में बंद करना आवश्यक है ताकि टेम्पलेटिंग लैंग्वेज का निष्पादन के समय सही ढंग से व्याख्या हो सके।

आइए, dbt compile कमांड चलाकर देखें क्या होता है:

(dbt_env) mike@Mikes-MacBook-Pro my_dbt % dbt compile -s table_b -t prod
18:43:43  Running with dbt=1.8.6
18:43:44  Registered adapter: bigquery=1.8.2
18:43:44  Unable to do partial parsing because config vars, config profile, or config target have changed
18:43:45  Found 2 models, 480 macros
18:43:45 
18:43:46  Concurrency: 4 threads (target='prod')
18:43:46 
18:43:46  Compiled node 'table_b' is:
-- Use the ref function to select from other models
select *
from dbt_bigquery_dev.raw_prod.table_a
where id = 1संचालित द्वारा

dbt में वेरिएबल्स के साथ काम करना

dbt वेरिएबल्स सपोर्ट करता है, जो एक बेहद शक्तिशाली कस्टमाइज़ेशन फ़ीचर है। वेरिएबल्स का उपयोग SQL टेम्पलेट्स और मैक्रोज़ दोनों में किया जा सकता है और इन्हें कमांड लाइन से इस तरह पास किया जा सकता है:

dbt run -m table_b -t dev --vars '{my_var: my_value}'संचालित द्वारा

वेरिएबल्स को मुख्य प्रोजेक्ट फ़ाइल dbt_project.yml में डिक्लेयर करना आवश्यक है। उदाहरण के लिए, नीचे दिया गया स्निपेट दर्शाता है कि यह कैसे किया जाता है:

name: 'my_dbt'
version: '1.0.0'
config-version: 2
...
...
...
# In this example config, we tell dbt to build all models in the example/
# directory as views. These settings can be overridden in the individual model
# files using the {{ config(...) }} macro.
models:
 polybox_dbt:
   # Config indicated by + and applies to all files under models/example/
   example:
     # +materialized: view
     # schema: |
     #   {%- if  target.name == "dev" -%}    analytics_dev_mike
     #   {%- elif target.name == "prod"  -%} analytics_prod
     #   {%- elif target.name == "test"  -%} analytics_test
     #   {%- else -%} invalid_database
     #   {%- endif -%}
vars:
 my_var: ""संचालित द्वारा

आइए वेरिएबल्स का उपयोग करके dbt में कस्टम टेबल नाम (एलियस) बनाएँ। 

यदि कोई एलियस मौजूद नहीं है, तो डिफ़ॉल्ट रूप से मॉडल का मूल नाम (फ़ाइल नाम) एलियस के रूप में उपयोग होता है। यह सरल लॉजिक सुनिश्चित करता है कि सेटअप के अनुसार मॉडल या तो कॉन्फ़िगर किए गए एलियस से या डिफ़ॉल्ट नाम से संदर्भित हों। इस फ़ंक्शनैलिटी का इम्प्लीमेंटेशन नीचे जैसा दिखता है, जो अलग-अलग एनवायरनमेंट्स में मॉडल्स के नामकरण और रेफ़रेंसिंग में लचीलापन सुनिश्चित करता है:

-- get_custom_alias.sql
{% macro generate_alias_name(custom_alias_name=none, node=none) -%}
   {%- if custom_alias_name -%}
       {{ custom_alias_name | trim }}
   {%- elif node.version -%}
       {{ return(node.name ~ "_v" ~ (node.version | replace(".", "_"))) }}
   {%- else -%}
       {{ node.name }}
   {%- endif -%}
{%- endmacro %}संचालित द्वारा

आइए इस व्यवहार को वेरिएबल्स से ओवरराइड करें। यह सेटअप डेवलपमेंट (स्टेजिंग) में काम करते समय डेटा डेवलपर्स के लिए एक-दूसरे के काम में टकराव के जोखिम को कम करने के लिए आम है। 

हम चाहते हैं कि डेवलपमेंट इंजीनियर्स द्वारा बनाए गए सभी डेटाबेस इंस्टेंसेज़ (टेबल्स, व्यूज़ आदि) में डेवलपर का नाम जोड़ दिया जाए। 

आइए generate_alias_name.sql मैक्रो बनाएँ:

--my_dbt/macros/generate_alias_name.sql
{% macro generate_alias_name(custom_alias_name=none, node=none) -%}
   {% set apply_alias_suffix = var('apply_alias_suffix') %}
       {%- if custom_alias_name -%}
           {{ custom_alias_name }}{{  apply_alias_suffix | trim }}
       {%- elif node.version -%}
           {{ return(node.name ~ "_v" ~ (node.version | replace(".", "_"))) }}
       {%- else -%}
           {{ node.name }}{{  apply_alias_suffix | trim }}
       {%- endif -%}
{%- endmacro %}संचालित द्वारा

अपने नए वेरिएबल को dbt_project.yml में जोड़ना न भूलें और कमांड लाइन में यह चलाएँ:

$ dbt compile -m table_b -t dev --vars '{apply_alias_suffix: _mike}'संचालित द्वारा

आपको इस तरह का आउटपुट दिखेगा:

08:58:06  Running with dbt=1.8.6
08:58:07  Registered adapter: bigquery=1.8.2
08:58:07  Unable to do partial parsing because config vars, config profile, or config target have changed
08:58:07  Unable to do partial parsing because a project config has changed
08:58:08  Found 2 models, 481 macros
08:58:08  
08:58:08  Concurrency: 4 threads (target='dev')
08:58:08  
08:58:08  Compiled node 'table_b' is:
-- Use the ref function to select from other models
select *
from bigquery-data-dev.raw_dev.table_a_mike
where id = 1संचालित द्वारा

हम देख सकते हैं कि हमारा वेरिएबल टेबल नाम में जुड़ गया: table_a_mike।

डेटा मॉडल लेयरें

यह सेक्शन डेटा ट्रांसफ़ॉर्मेशन के संदर्भ में डेटा वेयरहाउस को कैसे डिज़ाइन करें—इसी पर केंद्रित है। dbt में एक साधारण तार्किक प्रोजेक्ट स्ट्रक्चर कुछ इस तरह दिख सकता है:

.
└── models
   └── some_data_source
       ├── _data_source_model__docs.md
       ├── _data_source__models.yml
       ├── _sources.yml  			-- raw data table declarations
       └── base 				-- base transformations, e.g. JSON to cols
       |   ├── base_transactions.sql
       |   └── base_orders.sql
       └── analytics -- deeply enriched data prod grade data, QA'ed
           ├── _analytics__models.yml
           ├── some_model.sql
           └── some_other_model.sqlसंचालित द्वारा

व्यक्तिगत रूप से, मैं हमेशा यह सुनिश्चित करने पर ध्यान देता/देती हूँ कि बुनियादी (base) डेटा मॉडल लेयर जितनी हो सके साफ़ और सीधी-सादी रहे, और केवल आवश्यक होने पर ही ट्रांसफ़ॉर्मेशन लगाए जाएँ। इस दृष्टिकोण से, हमारा लक्ष्य ऐसा base_ डेटा मॉडल लेयर डिज़ाइन व लागू करना है जिसमें कॉलम स्तर पर न्यूनतम डेटा मैनिप्युलेशन शामिल हो।

हालाँकि, कुछ स्थितियों में थोड़ा-बहुत मैनिप्युलेशन लाभकारी हो सकता है, विशेषकर क्वेरी प्रदर्शन के अनुकूलन के लिए। ऐसे मामलों में, बेस लेयर पर छोटे समायोजन दक्षता में उल्लेखनीय सुधार ला सकते हैं—इसलिए सादगी और प्रदर्शन के बीच संतुलन बनाना उचित है। ऐसे में एक अतिरिक्त जॉइन या पार्टिशनिंग फ़िल्टर जोड़ना उचित ठहरता है।

डेटा मॉडलों और पाइपलाइंस को बेहतर बनाने के लिए इन तकनीकों को अपनाना अनुशंसित है:

• आवश्यक होने पर अंतिम biz_ और mart_ लेयरों में परसिस्टेड मटेरियलाइज़ेशन और क्लस्टरिंग का उपयोग करें। इससे प्रदर्शन बेहतर होता है और बिज़नेस लॉजिक का कुशल प्रबंधन सुनिश्चित होता है।
• Google Sheets को डेटा सोर्स के रूप में उपयोग करने से बचें। बड़े डेटा सेट संभालने में इसकी सीमाएँ असंगतियाँ और परफ़ॉर्मेंस बाधाएँ ला सकती हैं।
• मैं क्लस्टरिंग और इंक्रीमेंटल प्रेडिकेट्स के साथ इंक्रीमेंटल अपडेट्स का उपयोग करने की सलाह देता/देती हूँ।
• select * जैसे पैटर्न से बचें और लंबी व जटिल SQL फ़ाइलों को यूनिट टेस्ट के साथ छोटे मॉडलों में बाँटने पर विचार करें।
• dbt seeds का उपयोग करने से बचें, क्योंकि वे केवल CSV फ़ाइलों को सपोर्ट करते हैं और आपके डेटाबेस में टेबल्स को पॉप्युलेट करने के लिए आदर्श नहीं हैं। 
• इसके बजाय, कस्टम मटेरियलाइज़ेशन के माध्यम से टेस्ट डेटाबेस टेबल्स को सीड करने पर विचार करें। उदाहरण के लिए, एक SQL क्वेरी ऐसा आउटपुट जनरेट कर सकती है जिसे अन्य मॉडलों में रेफ़रेंस किया जा सके। यह दृष्टिकोण सुनिश्चित करता है कि आपकी टेबल्स डेटा लीनिएज ग्राफ़ में ठीक से प्रदर्शित हों, जिससे आपके डेटा इन्फ्रास्ट्रक्चर में बेहतर दृश्यता और ट्रैकिंग मिलती है।

नीचे दी गई SQL क्वेरी पर विचार करें। यह बताती है कि ऐसा कस्टम मटेरियलाइज़ेशन कैसे बनाया जाए:

-- my_dbt/macros/operation.sql
{%- materialization operation, default  -%}
   {%- set identifier = model['alias'] -%}
 {%- set target_relation = api.Relation.create(
       identifier=identifier, schema=schema, database=database,
       type='table') -%}
 -- ... setup database ...
 -- ... run pre-hooks...
 -- build model
 {% call statement('main') -%}
   {{ run_sql_as_simple_script(target_relation, sql) }}
 {%- endcall %}
  -- ... run post-hooks ...
 -- ... clean up the database...
  
   -- COMMIT happens here
   {{ adapter.commit() }}
 -- Return the relations created in this materialization
 {{ return({'relations': [target_relation]}) }}
{%- endmaterialization -%}
-- my_dbt/macros/operation_helper.sql
{%- macro run_sql_as_simple_script(relation, sql) -%}
   {{ log("Creating table " ~ relation) }}
   {{ sql }}
{%- endmacro -%}संचालित द्वारा

अब, यदि हम इस फ़ीचर को प्रदर्शित करने के लिए table_c नाम का एक अतिरिक्त मॉडल जोड़ें, तो हम नीचे दी गई SQL का उपयोग कर सकते हैं:

-- my_dbt/models/example/table_c.sql
{{ config(
   materialized='operation',
   tags=["example"]
) }}
create or replace table {{this.database}}.{{this.schema}}.{{this.name}} (
    id       int64        
   ,comments string       
);
insert into {{this.database}}.{{this.schema}}.{{this.name}} (id, comments)
select
  1                 as id       
  , 'Some comments' as comments 
union all
select
  2                 as id       
  , 'Some comments' as comments 
;संचालित द्वारा

अब, यदि हम इसे कम्पाइल करें, तो यह एक SQL स्क्रिप्ट जैसा दिखेगा:

$ dbt compile -m table_c -t devसंचालित द्वारा

आउटपुट:

10:45:24  Running with dbt=1.8.6
10:45:25  Registered adapter: bigquery=1.8.2
10:45:25  Found 3 models, 483 macros
10:45:25 
10:45:26  Concurrency: 4 threads (target='dev')
10:45:26 
10:45:26  Compiled node 'table_c' is:
-- Use the ref function to select from other models
create or replace table bigquery-data-dev.source.table_c (
    id       int64        
   ,comments string       
);
insert into bigquery-data-dev.source.table_c (id, comments)
select
  1                 as id       
  , 'Some comments' as comments 
union all
select
  2                 as id       
  , 'Some comments' as comments 
;संचालित द्वारा

इस दृष्टिकोण का लाभ यह है कि अब हमें BigQuery अडैप्टर पर निर्भर रहने की आवश्यकता नहीं। यदि हम कोई और टेबल या व्यू बनाते हैं जो इस ऑपरेशन को रेफ़रेंस करता है, तो हम साधारण ref() फ़ंक्शन का उपयोग कर सकते हैं।

ऐसा करने पर, table_c अपने आप डेटा लीनिएज में एक डिपेंडेंसी के रूप में पहचाना जाएगा। इससे टेबल्स के बीच संबंधों को ट्रैक करना आसान हो जाता है और आपके डेटा एनवायरनमेंट में विभिन्न मॉडलों के बीच रिश्तों का सही डॉक्युमेंटेशन सुनिश्चित होता है।

यह विधि डिपेंडेंसी मैनेजमेंट में मदद करती है और यह दिखाती है कि डेटा विभिन्न चरणों से कैसे होकर गुजरता है—यहाँ तक कि स्क्रिप्ट्स शामिल करने वाले जटिल प्रोसेसिंग स्टेप्स में भी। जटिल डेटा पाइपलाइनों को मेंटेन करने में यह विशेष रूप से उपयोगी है।

dbt में DAG (डायरेक्टेड एसीक्लिक ग्राफ़) table_b के लिए डिपेंडेंसीज़ दिखाता है। चित्र: लेखक द्वारा

अब हमें अपने पाइपलाइन में table_c जोड़ना है:

-- models/example/table_b.sql
{{ config(
   tags=["example"]
) }}
select *
from {{ ref('table_a') }}
where id = 1
union all
select *
from {{ ref('table_c') }}
where id = 2
-- select 1;संचालित द्वारा

यदि हम कमांड लाइन में निम्न चलाएँ, तो डॉक्युमेंटेशन अपने आप जनरेट हो जाएगा!

dbt docs generate
dbt docs serveसंचालित द्वारा

dbt में डेटा वेयरहाउजिंग प्रोजेक्ट का एक अधिक उन्नत उदाहरण नीचे दिए गए स्ट्रक्चर जैसा दिख सकता है। इसमें अनेक डेटा सोर्सेज़ और विभिन्न मॉडल लेयरों (stg, base, mrt, biz) के माध्यम से ट्रांसफ़ॉर्मेशन शामिल हैं, जो अंततः डेटा मार्ट मॉडल तैयार करते हैं।

└── models
   ├── int -- only if required and 100% necessary for reusable logic
   │   └── finance
   │       ├── _int_finance__models.yml
   │       └── int_payments_pivoted_to_orders.sql
   ├── marts -- deeply enriched, QAed data with complex transformations
   │   ├── finance
   │   │   ├── _finance__models.yml
   │   │   ├── orders.sql
   │   │   └── payments.sql
   │   └── marketing
   │       ├── _marketing__models.yml
   │       └── customers.sql
   └── src (or staging) -- raw data with basic transformations applied
       ├── some_data_source
       │   ├── _data_source_model__docs.md
       │   ├── _data_source__models.yml
       │   ├── _sources.yml
       │   └── base
       │       ├── base_transactions.sql
       │       └── base_orders.sql
       └── another_data_source
           ├── _data_source_model__docs.md
           ├── _data_source__models.yml
           ├── _sources.yml
           └── base
               ├── base_marketing.sql
               └── base_events.sqlसंचालित द्वारा

मॉडल लॉजिक के लिए यूनिट टेस्ट

यूनिट टेस्टिंग डेटा पाइपलाइन प्रक्रिया का महत्वपूर्ण चरण है, जहाँ हम अपने डेटा मॉडलों के पीछे की लॉजिक को वैलिडेट करने के लिए टेस्ट चला सकते हैं। जैसे आप अपने Python फ़ंक्शंस के लिए यूनिट टेस्ट चलाते हैं, वैसे ही मैं डेटा मॉडलों के परीक्षण के लिए समान दृष्टिकोण अपनाता/अपनाती हूँ।

इन परीक्षणों को चलाकर हम संभावित समस्याओं को शुरुआती चरण में पकड़ सकते हैं और सुनिश्चित कर सकते हैं कि ट्रांसफ़ॉर्मेशन और लॉजिक सही ढंग से काम कर रहे हैं। यह प्रैक्टिस डेटा गुणवत्ता बनाए रखने में मदद करती है और पाइपलाइन में त्रुटियों के प्रसार को रोकती है, जिससे यह डेटा इंजीनियरिंग प्रक्रिया का महत्वपूर्ण पहलू बनती है।

हम properties.yml फ़ाइल में मामूली बदलाव करके किसी मॉडल के लिए यूनिट टेस्ट जोड़ सकते हैं:

# my_dbt/models/example/properties.yml
version: 2
models:
...
unit_tests: # dbt test --select "table_b,test_type:unit"
 - name: test_table_b
   description: "Check my table_b logic captures all records from table_a and table_c."
   model: table_b
   given:
     - input: ref('table_a')
       rows:
         - {id: 1,    comments: 'Some comments'}
         - {id: 2,    comments: 'Some comments'}
     - input: ref('table_c')
       rows:
         - {id: 1,    comments: 'Some comments'}
         - {id: 2,    comments: 'Some comments'}
   expect:
     rows:
       - {id: 1,    comments: 'Some comments'}
       - {id: 2,    comments: 'Some comments'}संचालित द्वारा

अब यदि हम कमांड लाइन में dbt test कमांड चलाएँ, तो यूनिट टेस्ट निष्पादित कर सकते हैं:

% dbt test --select "table_b,test_type:unit"संचालित द्वारा

आउटपुट इस प्रकार है:

11:33:05  Running with dbt=1.8.6
11:33:06  Registered adapter: bigquery=1.8.2
11:33:06  Unable to do partial parsing because config vars, config profile, or config target have changed
11:33:07  Found 3 models, 483 macros, 1 unit test
11:33:07 
11:33:07  Concurrency: 4 threads (target='dev')
11:33:07 
11:33:07  1 of 1 START unit_test table_b::test_table_b ................................... [RUN]
11:33:12  1 of 1 PASS table_b::test_table_b .............................................. [PASS in 5.12s]
11:33:12 
11:33:12  Finished running 1 unit test in 0 hours 0 minutes and 5.77 seconds (5.77s).
11:33:12 
11:33:12  Completed successfully
11:33:12 संचालित द्वारा

अब expect में किसी रो का id 3 कर दीजिए, तो हमें उसी टेस्ट के लिए एरर मिलेगा:

11:33:28  Completed with 1 error and 0 warnings:
11:33:28 
11:33:28  Failure in unit_test test_table_b (models/example/properties.yml)
11:33:28  
actual differs from expected:
@@ ,id,comments
  ,1 ,Some comments
+++,2 ,Some comments
---,3 ,Some commentsसंचालित द्वारा

डेटा गुणवत्ता परीक्षण

dbt डेटा गुणवत्ता जाँचों का भी समर्थन देता है। मैंने पहले डेटा कॉन्ट्रैक्ट्स ब्लॉग पोस्ट में इस पर लिखा है। हम डेटा गुणवत्ता से संबंधित लगभग हर चीज़—डेटा की ताज़गी, रो कंडीशंस, ग्रैन्युलैरिटी आदि—जाँच सकते हैं।

आइए अपने table_b मॉडल पर बारीकी से नज़र डालें। इसमें पहले से कुछ डेटा जाँचें मौजूद हैं:

 - name: table_b
   config:
     description: "A starter dbt model"
     schema: |
       {%- if  target.name == "dev" -%}    analytics_dev
       {%- elif target.name == "prod"  -%} analytics_prod
       {%- elif target.name == "test"  -%} analytics_test
       {%- else -%} invalid_database
       {%- endif -%}
     columns:
       - name: id
         description: "The primary key for this table"
         tests:
           - unique
           - not_nullसंचालित द्वारा

यहाँ, tests परिभाषा के अंतर्गत, हम अपने मटेरियलाइज़्ड table_b.id के लिए unique और not_null कंडीशन टेस्ट कर रहे हैं। इस विशिष्ट टेस्ट को चलाने के लिए निम्न कमांड काम करेगा:

dbt test -s table_bसंचालित द्वारा

हम अपने डेटा सेट्स के लिए रेफ़रेंशियल इंटेग्रिटी का परीक्षण भी कर सकते हैं। यह जॉइन्स वाले डेटा मॉडलों के साथ काम करते समय आवश्यक है, क्योंकि यह सुनिश्चित करता है कि एंटिटीज़ के बीच रिश्ते सटीक रूप से बनाए रखें। ये परीक्षण परिभाषित करते हैं कि अलग-अलग एंटिटीज़—जैसे टेबल्स या कॉलम—एक-दूसरे से कैसे संबंधित हैं। 

उदाहरण के लिए, नीचे दिया गया dbt कोड दर्शाता है कि हर refunds.refund_id किसी वैध transactions.id से जुड़ा हुआ है। यह मैपिंग सुनिश्चित करती है कि सभी रिफंड वैध ट्रांज़ैक्शंस से जुड़े हों, जिससे आपके डेटा की अखंडता बनी रहे और आपके डेटा मॉडलों में अनाथ रिकॉर्ड्स या असंगत रिश्ते न बनें:

- name: refunds
   enabled: true
   description: An incremental table
 columns:
     - name: refund_id
       tests:
         - relationships:
             tags: ['relationship']
             to: ref('transactions')
             field: idसंचालित द्वारा

डेटा आवश्यकताएँ अक्सर यह निर्धारित करती हैं कि नया डेटा कब उपलब्ध होना चाहिए और अपडेट में अधिकतम अनुमत देरी कितनी हो सकती है। ये जाँचें सुनिश्चित करती हैं कि विश्लेषण के लिए डेटा प्रासंगिक (अप-टू-डेट) बना रहे। 

dbt में, इसे फ्रेशनैस टेस्ट्स के माध्यम से लागू किया जा सकता है, जो यह मॉनिटर करने देते हैं कि नया डेटा अपेक्षित समयसीमा के भीतर पहुँच रहा है या नहीं। 

उदाहरण के लिए, आप ऐसा फ्रेशनैस टेस्ट कॉन्फ़िगर कर सकते हैं जो यह सत्यापित करे कि किसी टेबल में सबसे हाल का रिकॉर्ड आपकी परिभाषित फ्रेशनैस मानकों को पूरा करता है। इससे आपकी डेटा पाइपलाइंस समय पर और सुसंगत रूप से अपडेट देती रहेंगी, और समय-संवेदी आवश्यकताओं का पालन करते हुए डेटा की विश्वसनीयता व शुद्धता बनी रहेगी। 

नीचे दिया गया कोड स्निपेट देखें। यह बताता है कि dbt में फ्रेशनैस टेस्ट कैसे सेटअप करें:

# example model
- name: orders
   enabled: true
   description: A source table declaration
   tests:
     - dbt_utils.recency: # https://github.com/dbt-labs/dbt-utils#recency-source
         tags: ['freshness']
         datepart: day
         field: timestamp
         interval: 1संचालित द्वारा

ये सभी dbt टेस्ट्स उल्लेखनीय हैं और डेटा इंजीनियरों के रोज़मर्रा के काम में बेहद उपयोगी हैं! ये डेटा वेयरहाउस को अच्छी तरह से मेंटेन रखने और डेटा पाइपलाइंस को सुसंगत बनाए रखने में मदद करते हैं।

निष्कर्ष

डेटा वेयरहाउस समाधान बनाना एक जटिल कार्य है, जिसके लिए सावधानीपूर्वक योजना और संगठन की आवश्यकता होती है। एक टेम्पलेटिंग इंजन के रूप में dbt, इसे एकरूपता के साथ करने में मदद करता है।

इस लेख में, मैंने dbt डेटा ट्रांसफ़ॉर्मेशन फ़ोल्डर्स को व्यवस्थित करने की कई तकनीकों का सार प्रस्तुत किया है ताकि स्पष्टता और सहयोग बढ़े। SQL फ़ाइलों को तार्किक संरचना में रखने से हम ऐसा वातावरण बनाते हैं जिसे प्रोजेक्ट में नए लोगों के लिए भी एक्सप्लोर करना आसान हो।

DBT प्रक्रिया को और भी सुव्यवस्थित करने के लिए कई सुविधाएँ प्रदान करता है। उदाहरण के लिए, हम मैक्रोज़, वेरिएबल्स और कॉन्स्टेंट्स के माध्यम से रीयूज़ेबल कोड अंशों को शामिल कर अपने SQL टेम्पलेट्स को समृद्ध कर सकते हैं। मेरे अनुभव में, जब इन्हें इन्फ्रास्ट्रक्चर-एज़-कोड प्रैक्टिसेज़ के साथ जोड़ा जाता है, तो यह फ़ंक्शनैलिटी उचित CI/CD वर्कफ़्लोज़ लागू करने में मदद करती है और विकास व डिप्लॉयमेंट को उल्लेखनीय रूप से तेज़ करती है।

यदि आप dbt के अपने ज्ञान को अगले स्तर पर ले जाना चाहते हैं, तो DataCamp पर Introduction to dbt कोर्स करने पर विचार करें। यह एक उत्कृष्ट संसाधन है जो अधिक हैंड्स-ऑन अभ्यास के साथ आपको सफलता पूर्वक शुरुआत करने में मदद करेगा!