آموزش DBT(ابزار ساخت داده)

آموزش DBT(ابزار ساخت داده)

نوشته شده توسط: تیم فنی نیک آموز
۳۰ آذر ۱۴۰۰
زمان مطالعه: 15 دقیقه
۴.۲
(۶۸۴)

مقدمه

اگر دانشجو، تحلیلگر، مهندس داده یا هرکسی در فضای داده هستید و کنجکاو هستید که در مورد DBT بدانید و چگونگی استفاده از آن را یاد بگیرید. این مقاله کاملا مناسب شماست.

هر برنامه نرم افزاری که امروزه در بازار می‌بینیم با احتمالی قریب  به یقین، در بخشی از اکوسیستم توسعه آن از دیتابیس‌های رابطه‌ای یا NoSQL استفاده شده است و زبان مشترک اغلب این دیتابیس‌ ها، SQL است.

از طرفی با توجه به حجم عظیم داده‌های روزانه در برنامه‌ های مختلف و کند شدن مداوم جداول رابطه‌ای در پاسخ به کوئری‌های تحلیلی، شرکتها معمولا به صورت زمان‌مند، داده‌ها را از جداول رابطه‌ای خوانده، آمار مورد نیاز را استخراج و نتیجه را در یک جدول خلاصه شده جدید و یا یک انباره داده ذخیره میکنند.

مثلا اگر قرار باشد آمار فروش ساعت به ساعت یک فروشگاه بر حسب استان و برند و … را محاسبه کنیم، میتوانیم هر یک ساعت یک بار، دستوری اجرا کنیم، این آمار را محاسبه کرده و در جدول فروش تجمیعی روزانه ذخیره کنیم تا ابزارهای هوش تجاری ، به جای کوئری گرفتن از کل جدول اصلی که ممکن است بار زیادی را به آن تحمیل کند، با این جدول تجمیع شده کار کنند.

این فرآیند خواندن، پردازش (گروه بندی بر حسب ساعت و استان و برند …) و ذخیره داده‌ها را می توان به راحتی با SQL مدیریت کرد و DBT دقیقا برای این منظور توسعه داده شده و به محبوبیت زیادی در حوزه مهندسی داده و خطوط ETL مبتنی بر SQL دست یافته است

در این مقاله، قصد داریم به صورت کاربردی با این ابزار مفید حوزه زیرساخت داده، آشنا شویم.

DBT مرحله تبدیل در خط لوله ELT

در کاربردهای امروزی پردازش داده، به جای ETL گاهی اوقات از ELT استفاده می‌کنیم . یعنی ابتدا داده را دریافت می‌کنیم (E)، آنها را ذخیره کرده (L) و پس از آن به پردازش داده‌ها و به روز رسانی دیتابیس، اقدام می‌کنیم.(T) در خط لوله ELT، داده‌های خام در انبار داده بارگذاری می‌شوند که با این کار، دو مرحله استخراج (Extract) و بارگذاری داده‌ها (Load) یعنی مراحل E و L انجام شده است. در مرحله تبدیل (Trasform)، اگر مبدا و مقصد ما از SQL پشتیبانی کند، DBT می‌تواند وارد عمل شود. در این صورت، داده‌های خام که در انبار داده بارگذاری شده‌اند با استفاده از کوئری‌های SQL که روی داده‌های انبار داده اجرا می‌شود به جداول قابل استفاده تبدیل می‌شوند.

DBT یک راه آسان برای ایجاد، تبدیل و اعتبارسنجی داده‌ها در یک انبار داده ارائه می‌دهد. یعنی مرحله T در خط لوله ELT را انجام می‌دهد.

در DBT ما با مدل‌هایی کار می‌کنیم که یک فایل SQL با دستور Select است. این مدل‌ها می‌توانند به مدل‌های دیگر وابسته باشند، تست‌هایی بر روی آن‌ها تعریف شده باشد و همچنین می‌توانند به صورت جدول یا view  ایجاد شوند. نام مدل‌های ایجاد شده توسط DBT نام فایل آنهاست.

به عنوان مثال. فایل dim_customers.sql مدلی با نام dim_customers را نشان می‌دهد. این مدل به مدل‌های stg_eltool__customers وstg_eltool__state بستگی دارد. همچنین مدل dim_customers را می‌توان در سایر تعاریف مدل ارجاع داد.

قطعه کد زیر یک فرایند تبدیل ساده را در DBT نشان میدهد.

with customers as (
    select *
    from {{ ref('stg_eltool__customers') }}
),
state as (
    select *
    from {{ ref('stg_eltool__state') }}
)
select c.customer_id,
    c.zipcode,
    c.city,
    c.state_code,
    s.state_name,
    c.datetime_created,
    c.datetime_updated,
    c.dbt_valid_from::TIMESTAMP as valid_from,
    CASE
        WHEN c.dbt_valid_to IS NULL THEN '9999-12-31'::TIMESTAMP
        ELSE c.dbt_valid_to::TIMESTAMP
    END as valid_to
from customers c
    join state s on c.state_code = s.state_code

ما می‌توانیم تست‌هایی را برای اجرا روی داده‌های پردازش شده با استفاده از dbt تعریف کنیم. dbt  به ما امکان می‌دهد ۲ نوع تست ایجاد کنیم، تست‌ها عبارتند از:

تست‌های عمومی: Unique،not_null ، accepted_values و relationships تست‌هایی هستند که روی هر ستون اعمال می‌شوند و در فایل YAML تعریف شده‌اند.

تست‌های سفارشی: اسکریپت های Sql که در فولدر تست‌ها ایجاد می‌شوند. آنها می‌توانند هر کوئری‌ای باشند. اگر اسکریپت‌های sql هیچ ردیفی را برنگردانند، نتیجه تست موفقیت‌آمیز است و در غیر این صورت تست ناموفق است.

version: 2
models:
  - name: dim_customers
    columns:
      - name: customer_id
        tests:
          - not_null # checks if customer_id column in dim_customers is not null
  - name: fct_orders

پروژه

سناریوی زیر را در نظر بگیرید: تیم بازاریابی از ما درخواست می‌کند که یک جدول customer_orders عدم نرمال‌سازی شده با اطلاعات مربوط به هر سفارشی که توسط مشتریان ارسال می‌شود، ایجاد کنیم. فرض می‌کنیم که داده‌های مشتریان و سفارش‌ها توسط فرآیندی در انبار داده بارگذاری می‌شوند.

فرآیندی که برای آوردن این داده‌ها به انبار داده ما استفاده می‌شود، مراحل EL از خط پردازش داده ELT است. این قسمت را می‌توان با استفاده از یک سرویس مانند Fivetran، Stitch یا سرویس‌های منبع باز مانند Singer، Airbyte یا با استفاده از یک سرویس سفارشی انجام داد.

در ادامه قصد داریم ببینیم که داده‌های ما با جدول غیرنرمال ، چطور به داده‌های نهایی تبدیل می‌شوند.

پیش‌نیازها

برای پیاده‌سازی این سناریو و انجام این کارگاه عملی،  به پیش‌نیازهای زیر نیاز خواهیم داشت.

  • Docker and Docker compose
  • dbt
  • pgcli
  • git
git clone https://github.com/josephmachado/simple_dbt_project.git
export DBT_PROFILES_DIR=$(pwd)
docker compose up -d
cd simple_dbt_project

کانتینر docker انبار داده را از گیت دریافت و راه‌اندازی کنید.

به طور پیش‌فرض dbt به دنبال کانکشن‌های دیتابس، در فایل ~/.dbt/profiles.yml می‌گردد. متغیر محیطی DBT_PROFILES_DIR به dbt می گوید که فایل profiles.yml را در دایرکتوری کاری فعلی جستجو کند.

همچنین می‌توانید با استفاده از dbt init یک پروژه dbt ایجاد کنید. این روش یک نمونه پروژه را در اختیار شما قرار می‌دهد که می‌توانید آن را تغییر دهید.

در پوشه simple_dbt_project فولدرهای زیر را مشاهده خواهید کرد.

  • فولدر analysis: هر فایل sql که در این پوشه یافت می‌شود، با اجرای dbt compile به sql خام کامپایل می‌شود. آنها توسط dbt اجرا نمی‌شوند، اما می‌توان آنها را در هر ابزار دلخواه کپی کرد.
  • فولدر data: می‌توانیم داده‌های خامی را که می‌خواهیم در انبار داده خود بارگذاری کنیم، در این فولدر ذخیره کنیم. گرچه معمولاً برای ذخیره داده‌های نقشه‌برداری[۱] کوچک استفاده می‌شود.
  • ماکروها: Dbt به کاربران اجازه می‌دهد تا ماکروهایی ایجاد کنند که توابع مبتنی بر sql هستند. این ماکروها را می‌توان در پروژه‌های دیگر استفاده مجدد نمود.

در بخش‌های زیر به بررسی فولدرهای باقی مانده یعنی models، snapshots و tests می‌پردازیم.

تنظیمات و اتصالات

در این بخش اتصالات انبار و تنظیمات پروژه را بررسی می‌کنیم.

  • yml

Dbt به فایل profiles.yml که حاوی جزئیات کانکشن به دیتابیس یا انبارداده باشد نیاز دارد. ما جزئیات اتصال به انبار داده را در /simple_dbt_project/profiles.yml  تعریف کرده ایم.

متغیر target محیط را تعریف می‌کند. پیش‌فرض dev است. ما می‌توانیم چندین target داشته باشیم که هنگام اجرای دستورات dbt می‌توان آن‌ها را مشخص کرد.

پروفایل sde_dbt_tutorial است. فایل profiles.yml می‌تواند حاوی چندین پروفایل برای زمانی که بیش از یک پروژه dbt دارید باشد.

  • yml

در این فایل می‌توانید پروفایل مورد استفاده و مسیرهای انواع مختلف فایل‌ها را تعریف کنید.Materialization  متغیری است که نحوه ایجاد یک مدل توسط dbt را کنترل می‌کند. به طور پیش‌فرض، هر مدل یک view خواهد بود. ما مدل‌ها را در مسیر models/marts/core/  قرار داده‌ایم.

[۱] Mapping

# Configuring models
models:
    sde_dbt_tutorial:
        # Applies to all files under models/marts/core/
        marts:
            core:
                materialized: table

جریان داده

در این قسمت خواهیم دید که چگونه جدول customer_orders از جداول منبع ایجاد می‌شود.

منبع

جداول منبع به جداول بارگذاری شده در انبار توسط فرآیند EL اشاره دارد. از آنجایی که dbt آنها را ایجاد نکرده است، باید آنها را تعریف کنیم. این تعریف امکان ارجاع به جداول منبع را با استفاده از تابع منبع فراهم می‌کند. برای مثال {{ source(‘warehouse’, ‘orders’) }}  به جدول warehouse.orders اشاره دارد. همچنین می‌توانیم تست‌هایی را برای اطمینان از صحت داده‌های منبع تعریف کنیم.

تعاریف تست:

yun.ir/xxik68

تعاریف منبع:

https://github.com

Snapshots

ویژگی های یک موجودیت تجاری در طول زمان تغییر می‌کند. این تغییرات باید در انبار داده ما ثبت شوند. به عنوان مثال، یک کاربر ممکن است به یک آدرس جدید منتقل شود. در مدل‌سازی انبار داده به این مورد تغییر آهسته ابعاد گفته می‌شود.

Dbt به ما این امکان را می‌دهد که با استفاده از ویژگی snapshot این جداول SCD2 را به راحتی ایجاد کنیم. هنگام ایجاد یک snapshot، باید پایگاه داده، شِما، استراتژی و ستون یکتا را برای به روز رسانی ردیف‌ها، تعریف کنیم

dbt snapshot

Dbt در اولین اجرا یک snapshot را ایجاد می‌کند و در اجراهای متوالی مقادیر تغییر یافته را بررسی می‌کند و ردیف‌های قدیمی‌تر را به روز رسانی می‌کند. این روال را به شکل زیر شبیه‌سازی می‌کنیم.

pgcli -h localhost -U dbt -p 5432 -d dbt
# password1234
COPY warehouse.customers(customer_id, zipcode, city, state_code, datetime_created, datetime_updated)
FROM '/input_data/customer_new.csv' DELIMITER ',' CSV HEADER;

مجدد دستور snapshot را اجرا کنید.

dbt snapshot
  • داده خام

  • جدول Snapshot

سطر با کد پستی ۵۹۶۵۵ ستون dbt_valid_to آن به روز رسانی شده است. ستون‌های dbt_valid_from و dbt_valid_to بازه زمانی را نشان می‌دهند که داده‌های آن ردیف معتبر بوده است. در صورتی که dbt_valid_to مقدار null داشته باشد به این معنا است که همچنان این ردیف معتبر است.

فایل customers.SQL را از آدرس زیر می‌توانید دریافت کنید.

https://github.com/josephmachado/simple_dbt_project/blob/master/sde_dbt_tutorial/snapshots/customers.sql

  • مخزن داده میانی

مخزن داده میانی، یک مکان داده موقت است که داده‌ها را تا زمان مشخصی به عنوان مثال یک ماه یا بیشتر نگهداری می‌کند، با این هدف که هرگاه پردازش‌های تحلیلی برنامه به داده‌های پایگاه داده نیاز پیدا کرد، از داده‌های روی مخزن داده میانی استفاده کند. این کار باعث می‌شود پایگاه داده عملیاتی که بیشتر درگیر کوئری‌های درج، حذف و ویرایش قرار دارد، برای پردازش داده‌ها مورد مراجعه قرار نگیرد و وجود مخزن داده میانی، نقش کاهش بار روی پایگاه داده عملیاتی را بر عهده دارد.

شما ممکن است متوجه eltool در نام مدل‌های staging شده باشید. اگر از داده‌های Fivetran برای مرحله استخراج و مرحله بارگذاری دادها استفاده کنیم (مراحل EL) ، مدل‌های ما stg_fivetran__orders نامیده می‌شوند و فایل  YAMLآن به صورت stg_fivetran.yml خواهد بود.

در stg_eltool__customers.sql به جای تابع منبع از تابع ref استفاده می‌کنیم زیرا این مدل از مدل snapshot گرفته شده است. در dbt می‌توانیم از تابع ref برای اشاره به هر مدلی که توسط dbt ایجاد شده است استفاده کنیم.

تعاریف تست:

https://github.com/josephmachado/simple_dbt_project/blob/master/sde_dbt_tutorial/models/staging/stg_eltool.yml

تعاریف مدل:

https://github.com/josephmachado/simple_dbt_project/blob/master/sde_dbt_tutorial/models/staging/stg_eltool__customers.sql

https://github.com/josephmachado/simple_dbt_project/blob/master/sde_dbt_tutorial/models/staging/stg_eltool__orders.sql

https://github.com/josephmachado/simple_dbt_project/blob/master/sde_dbt_tutorial/models/staging/stg_eltool__state.sql

  • Mart

Marts شامل جداول اصلی برای کاربران نهایی و جداولvertical-specific  تجاری تشکیل شده است. در مثال ما، یک فولدر department-specific برای تعریف مدل‌های درخواست شده بخش بازاریابی داریم.

  • Core

core، مدل‌های واقعیت و ابعادی را که باید توسط کاربران نهایی استفاده شود، تعریف می‌کند.

تعاریف تست:

https://github.com

تعاریف مدل:

https://github.com/josephmachado/simple_dbt_project/blob/master/sde_dbt_tutorial/models/marts/core/dim_customers.sql

https://github.com/josephmachado/simple_dbt_project/blob/master/sde_dbt_tutorial/models/marts/core/fct_orders.sql

Dbt چهار تست عمومی ارائه می‌دهد. عبارتند از: unique, not_null, accepted_values relationships. می‌توانیم تست‌های one-off را در فولدر Tests ایجاد کنیم.

تست‌های one-off

https://github.com/josephmachado/simple_dbt_project/blob/master/sde_dbt_tutorial/tests/assert_customer_dimension_has_no_row_loss.sql

  • Marketing

در این بخش مدل‌هایی را برای بازاریابی کاربران نهایی تعریف می‌کنیم. یک پروژه می‌تواند چندین vertical  تجاری داشته باشد. داشتن یک فولدر برای هر vertical  تجاری راه آسانی را برای سازماندهی مدل‌ها فراهم می‌کند.

تعاریف تست:

https://github.com/josephmachado/simple_dbt_project/blob/master/sde_dbt_tutorial/models/marts/marketing/marketing.yml

تعاریف مدل:

https://github.com/josephmachado/simple_dbt_project/blob/master/sde_dbt_tutorial/models/marts/marketing/customer_orders.sql

  • اجرای DBT

ما تعاریف مدل‌های مورد نیاز را داریم. مدل‌ها را به صورت زیر ایجاد می‌کنیم.

dbt snapshot
dbt run
...
Finished running 4 view models, 2 table models ...

مدل stg_eltool__customers به مدل snapshots.customers_snapshot نیاز دارد. دقت داشته باشید snapshot ها با اجرای دستور dbt run ایجاد نمی شوند، بنابراین ابتدا dbt snapshot را اجرا می‌کنیم.

مدل‌های staging  و marketing  به ‌عنوان view ایجاد می‌شوند و دو مدلcore  به‌ عنوان جداول ایجاد می‌شوند.

دستور snapshot باید مستقل از دستور run اجرا شود تا جداول snapshot به روز بمانند. اگر جداول snapshot قدیمی باشد، مدل‌ها نادرست خواهند بود.

  • test

روی مدل‌های تعریف شده می‌توانیم تست‌هایی را اجرا کنیم. توجه داشته باشید که بر خلاف تست استاندارد، این تست‌ها پس از پردازش داده‌ها اجرا می‌شوند. می‌توانید تست‌ها را مطابق دستور زیر اجرا کنید.

dbt test
...
Finished running 10 tests...

دستور بالا تمام تست‌های تعریف شده در پروژه را اجرا می‌کند. برای مشاهده مدل‌ها می‌توانید وارد انبار داده شوید.

pgcli -h localhost -U dbt -p 5432 -d dbt
# password is password1234
select * from warehouse.customer_orders limit 3;
\q
  • dbt docs

یکی از ویژگی های قدرتمند dbt اسناد آن است. برای تولید اسناد و ارائه آنها، دستورات زیر را اجرا کنید:

dbt docs generate
dbt docs serve

پس از اجرای کد بالا برای مشاهده مستندات می‌توانید به آدرس http://localhost:8080 مراجعه کنید.

زمان‌بندی

تا اینجا نحوه ایجاد snapshot ها، مدل‌ها، اجرای تست‌ها و تولید مستندات را دیده‌ایم. اینها همه دستوراتی هستند که از طریق cli اجرا می‌شوند. Dbt مدل‌ها را در کوئری‌های SQL در فولدر target  (که بخشی از git repo نیست) کامپایل می‌کند و آنها را در انبار داده اجرا می‌کند.

برای برنامه‌ریزی اجراهای dbt، snapshot ها و تست‌ها باید از یک زمان‌بندی استفاده کنیم. ابر Dbt یک گزینه عالی برای انجام زمان‌بندی آسان است. دستورات dbt را می‌توان توسط زمان‌بندی‌های محبوب دیگر مانند cron، Airflow، Dagster و غیره برنامه‌ریزی کرد.

نتیجه‌گیری

Dbt یک انتخاب عالی برای ساخت خطوط لوله ELT است. dbt با ترکیب بهترین شیوه‌های انبار داده، تست، مستندسازی، سهولت استفاده و پشتیبانی آنلاین، خود را به عنوان یک ابزار ضروری برای مهندسان داده معرفی کرده است. یادگیری و درک dbt می‌تواند به طور قابل توجهی شانس شما را برای یافتن شغل در جایگاه مهندسی داده افزایش دهد.

چه رتبه ای می‌دهید؟

میانگین ۴.۲ / ۵. از مجموع ۶۸۴

اولین نفر باش

title sign
معرفی نویسنده
تیم فنی نیک آموز
مقالات
255 مقاله توسط این نویسنده
محصولات
0 دوره توسط این نویسنده
تیم فنی نیک آموز
پروفایل نویسنده
title sign
دیدگاه کاربران

وبینار رایگان SQL Server؛ مسیری به سوی فرصت‌های شغلی بی‌شمار       پنج‌شنبه 30 فرودین ساعت 15
ثبت نام رایگان
close-image