جداول گسترده تست محور – انجمن DEV

Summarize this content to 400 words in Persian Lang
جداول گسترده آزمایش محور (TDWT) ساده ترین رویکرد درجه تولید برای مهندسی تجزیه و تحلیل است. حذف هر چیزی از TDWT آن را برای تولید نامناسب می کند. اضافه کردن هر چیزی به TDWT غیر ضروری است.

جداول عریض تست محور جریان دارند

نیازهای مشتری داده را دریافت کنید. چه بخشی از خروجی صفحه گسترده نهایی نیاز به تغییر دارد؟ در صورت وجود، در فایل ویژگی های مدل های dbt سند بزنید.
نیازمندی ها را به تست های داده dbt تبدیل کنید.
تست های dbt را روی مدل اجرا کنید – تست های جدید باید شکست بخورند.
تغییر لازم برای قبولی در آزمون را اعمال کنید. کد خود را به ساده ترین شکل ممکن بنویسید.
تست های dbt را روی مدل اجرا کنید – همه آنها باید قبول شوند.
از مرحله 1 تکرار کنید.

جداول عریض تست محور چیست؟ چرا از آنها استفاده کنید؟

جداول گسترده آزمایش محور (TDWT) توسعه آزمایش محور (TDD) و جداول گسترده را ترکیب می کنند. برای درک اینکه چرا ما از TDWT دفاع می کنیم، بیایید به این فکر کنیم که چگونه یک انبار داده ناکارآمد می تواند موفق شود.

انبارهای داده بدون انضباط قابل اعتماد نیستند، قابل نگهداری نیستند و قابل استفاده مجدد نیستند

در حرفه خود، ممکن است دیده باشید که انبارهای داده به طور تصادفی و بدون نظم و انضباط ثابت ساخته شده اند. در یکی از شرکت‌هایی که من در آن کار کرده‌ام، پیاده‌سازی انبار داده “میراث” با هزاران خط کد کپی و چسبانده شده، صدها نما/جدول جداگانه و وابستگی‌های دایره‌ای پر شده بود. نماها و جداول برای نگهداری کابوس هستند و بسیاری از مشتریان داده به آنها اعتماد ندارند.

فقط تغییر شکل داده ها نمی تواند آن را قابل اعتمادتر یا قابل نگهداری یا قابل استفاده مجدد کند

کارشناسان بعدی استخدام می‌شوند که معمولاً پیروی از رویکرد مدل‌سازی داده‌های ساختاریافته – Kimball/Inmon/DataVault/و غیره را پیشنهاد می‌کنند. همه این رویکردها در درجه اول بر شکل دادن به داده های شما برای پیروی از یک ساختار خاص تمرکز دارند. آنها در زمینه ها و تمرکزشان متفاوت خواهند بود، اما نکات اساسی فروش این است که پیروی از ساختار آنها، قابلیت اعتماد، قابلیت نگهداری و قابلیت استفاده مجدد انبار داده شما را بهبود می بخشد. با این حال، من معتقد نیستم که فقط تغییر شکل داده ها بتواند هیچ یک از این کارها را انجام دهد. در مواردی که به نظر می رسد اینطور است، در واقع همینطور است فرآیندها که در کنار ساختاری که منجر به تغییر واقعی می شود، اجرا می شود. داده‌هایی که به‌صورت بعدی مدل‌سازی می‌شوند، می‌توانند به اندازه داده‌هایی که اصلاً مدل‌سازی نشده‌اند، غیرقابل اعتماد، آشفته، و استفاده مجدد از آنها دشوار باشد.

تمرکز باید روی باشد فرآیند به جای روی ساختار

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

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

من استدلال می کنم که وجود دارد یکی فرآیندی که می تواند به تمام موارد فوق دست یابد: توسعه مبتنی بر آزمایش.

آزمایش ها به مشتریان داده نشان می دهد که از رگرسیون جلوگیری می شود. آزمایش‌ها مشکلات داده‌ها را قبل از اینکه مشتریان داده انجام دهند، شناسایی می‌کنند.
داشتن آزمایش برای هر ویژگی، مهندسان تحلیلگر را از نوشتن هزاران خط SQL با منطق نامربوط جلوگیری می کند. مدل‌های داده‌ای به نیازهای ساده محدود شده‌اند و بنابراین نگهداری آنها آسان‌تر است.
اگر می‌خواهید از یک منطق مدل قبلی مجددا استفاده کنید، می‌توانید آن را بیرون بکشید و با اطمینان اصلاح کنید. اگر چیزی را شکستید، آزمایش ها به شما اطلاع می دهند.

از آنجایی که ثابت کرده‌ایم شکل داده‌ها به نتیجه ارتباطی ندارد، می‌توانیم ساده‌ترین ساختار داده ممکن را که جداول گسترده است، اتخاذ کنیم. نتیجه: جداول گسترده آزمایش محور!

آیا استفاده از جداول عریض خاص مهم است؟

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

راه اندازی یک پروژه جداول گسترده آزمایش محور

ساختار پوشه

راهنمای رسمی dbt را دنبال کنید که چگونه پروژه های dbt خود را ساختار می دهیم. در واقع، راهنمای آنها به صراحت از مدل‌های داخل پوشه «مارتس» می‌خواهد که «عریض و غیرعادی» شوند. جداول گسترده تست محور برداشت خاص خود را از پوشه های داخل پوشه “models” دارد که از نظر نکات با راهنمای رسمی کمی متفاوت است:

مرحله بندی: برای هر جدول خام باید یک مدل نمای مرحله بندی وجود داشته باشد. هر نوع ریخته گری و ضدعفونی باید در مدل مرحله بندی انجام شود. همه مدل های دیگر باید به جای دسترسی مستقیم به جدول خام از نمای مرحله بندی استفاده کنند. این به جلوگیری از آلودگی منطق تجاری با منطق پاکسازی داده ها کمک می کند.

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

marts: مدل‌های مناسب برای مصرف کاربر نهایی به اینجا مراجعه کنید.

سبک

راهنمای رسمی سبک dbt را در جایی که برای تیم شما منطقی است دنبال کنید. من شخصاً به شدت مخالف واردات CTE هستم زیرا نیاز به پیمایش مداوم به بالا و پایین برای تغییر CTE ها تمرکز و جریان من را از بین می برد. در اینجا از عقل سلیم استفاده کنید و درخواست های کششی را برای چیزهایی که واقعاً بر چیزی تأثیر نمی گذارد رد نکنید.

من پیشنهاد می‌کنم sqlfmt را با pre-commit راه‌اندازی کنید تا کد کل تیم شما به صورت خودکار قالب‌بندی شود و سبک یکسانی داشته باشد.

جداول گسترده آزمایش محور جریان دارد

بیایید هر مرحله از جریانی را که در ابتدا تعریف کردیم، گسترش دهیم.

1. الزامات را از مشتری داده دریافت کنید

همه چیز با صحبت با مصرف کننده داده و درک نیازهای آنها شروع می شود. اگر چیزی خراب شد، مثال چیست؟ آن مثال را به آزمون خود تبدیل کنید. اگر چیز جدیدی مورد نیاز است، چگونه به نظر می رسد؟ از آنها بخواهید چند نمونه از موارد را در قالب صفحه گسترده شبیه سازی کنند. ستون های آن صفحه گسترده به مدل dbt شما تبدیل می شوند. ردیف‌های آن صفحه‌گسترده به آزمایش‌های شما تبدیل می‌شوند – در مرحله بعد به آن خواهیم پرداخت.

اسناد را همانطور که در حال جمع آوری الزامات هستید، بنویسید، نه بعد از نوشته شدن مدل داده. dbt اجازه می دهد تا ویژگی های مدل (از جمله مستندات) قبل از نوشتن هر SQL تعریف شود.

به عنوان مثال، اگر در حال توسعه یک مدل تراکنش با تیم حسابداری خود هستید، می توانید فایل را ایجاد کنید models/marts/accounting/_accounting__models.yml:

models:
– name: accounting_transactions
description: Transactions table for accounting
columns:
– name: transaction_key
description: Synthetic key for the transaction
tests:
– not_null
– unique
– name: action_date
description: Date of the transaction
tests:
– not_null

وارد حالت تمام صفحه شوید

از حالت تمام صفحه خارج شوید

به هر حال باید هنگام جمع آوری داده های مورد نیاز مشتری یادداشت برداری کنید. به جای نوشتن یادداشت ها در چیزی مانند Google Doc یا ایمیل، به جای آن با این فرمت YAML یادداشت برداری کنید. این کار شما را در مدارک و آزمایش خود شروع می کند.

2. نیازمندی ها را به تست های dbt تبدیل کنید

دو روش برای نوشتن تست در TDWT وجود دارد:

تست با داده های تولید این رویکرد نسبت به بازسازها انعطاف‌پذیر است، اما در برابر تغییرات داده‌ها شکننده است. داده ها ممکن است تغییر کنند، که می تواند باعث شود تست شروع به شکست کند. برخی از موارد لبه‌ای که در حالت ایده‌آل باید آزمایش شوند، ممکن است تا زمانی که مدل‌سازی داده‌ها کامل نشده است، در داده‌های تولید وجود نداشته باشند. ایجاد هر تست فقط چند دقیقه طول می کشد.
نوشتن تست های واحد. این رویکرد در برابر تغییرات داده‌ها انعطاف‌پذیر است، اما نسبت به refactor‌ها شکننده است. از آنجایی که آزمایش‌های واحد از شما می‌خواهد که نام‌ها و مقادیر دقیق همه ورودی‌هایی را که وارد مدل می‌شوند مشخص کنید، refactoring بسیار کار فشرده می‌شود.

من توصیه می کنم تست های یکپارچه سازی را بنویسید که به طور پیش فرض از داده های تولید استفاده می کنند. سرعت این روش مانع ورود را کاهش می دهد و مهندسان منطقی تحلیلی را از بیان اینکه وقت برای نوشتن تست ندارند باز می دارد.

تست با داده های تولید

به ستون‌های صفحه‌گسترده مدلی که مشتری داده‌هایتان به شما داده است فکر کنید. یک یا چند مورد از آن ستون ها می توانند به عنوان شناسه آن سطر نمونه خاص استفاده شوند. فقط باید یک ردیف با آن شناسه وجود داشته باشد. مقادیر در برخی از بقیه ستون ها منطق تجاری مثال را نشان می دهد. بنابراین، ما باید دو چیز را آزمایش کنیم: آیا آن ردیف مثال وجود دارد، و آیا مقادیر منطق تجاری مطابقت دارند؟

یک آزمایش داده dbt رکوردهای ناموفق را برمی گرداند. به عبارت دیگر، زمانی که هیچ ردیفی برگردانده نشده باشد، تست موفقیت آمیز بوده است. در اینجا یک نمونه پیاده سازی آورده شده است:

with row_count as (
select
count(*) as n
from {{ ref(“model_being_tested”) }}
where id1 = ‘some_id’
and id2 = ‘other_id’
)
select ‘Not exactly 1 row’ as error_msg
from row_count
where n <> 1
union all
select ‘Row test failed’ as error_msg
from {{ ref(“model_being_tested”) }}
where id1 = ‘some_id’
and id2 = ‘other_id’
and not (
value1 = ‘some example value’
and value2 is not null and value2 = ‘some other value’
and abs(value3) <= 0.01
)

وارد حالت تمام صفحه شوید

از حالت تمام صفحه خارج شوید

بیایید تشریح کنیم که در این پرس و جو چه اتفاقی می افتد. دو تا هستند select عبارات به هم پیوسته با الف union all. اگر ردیف مشخص شده توسط شناسه(های) در داده ها وجود نداشته باشد، اولین یک رکورد ناموفق را برمی گرداند. این مهم است تا زمانی که داده‌ها در وهله اول وجود ندارند، سهواً آزمایشی را قبول نکنیم. دومی همان ردیف را مشخص می کند و سپس به دنبال هر گونه اختلاف در مقادیر منطق تجاری می گردد. با قرار دادن مقادیر مورد انتظار در a آسان‌ترین کار است not().

مراقب مقادیر تهی باشید. به دلیل منطق سه ارزشی در SQL، فیلتر not(column = ‘value’) سطرهایی را که در آن ستون تهی است بر نمی گرداند. من توصیه می‌کنم با استفاده از آزمون not_null عمومی dbt، null‌ها را جداگانه آزمایش کنید تا مجبور نباشید هر بار به خاطر بسپارید.

کپی و پیست کردن و تطبیق سریع این نوع تست بسیار آسان است. همچنین خواندن و نگهداری آن آسان است. این تمام چیزی است که در 90 درصد مواقع به آن نیاز دارید.

نوشتن تصادفی یک پرس و جوی SQL که هیچ ردیفی تولید نمی کند، آسان است. به همین دلیل نوشتن یک آزمایش داده dbt که به طور تصادفی قبول می شود نیز آسان است. قبل از اینکه کار توسعه ای انجام شود، ابتدا آزمون باید نوشته و اجرا شود. آزمون باید شکست بخورد. سپس تغییر باید اجرا شود و آزمایش باید با موفقیت انجام شود.

نوشتن تست های واحد

اگر نمی‌توانید یا نمی‌خواهید با داده‌های تولید آزمایش کنید، از تست‌های واحد dbt استفاده کنید. با استفاده از دستور واحد تست، می توانید داده های منبع مصنوعی را در YAML مدل خود تعریف کنید. این به شما این امکان را می دهد که موارد لبه پیچیده را آزمایش کنید در حالی که مطمئن باشید تا زمانی که خود مدل تغییر نکند، تست های شما هرگز خراب نمی شوند.

3. تست های dbt را روی مدل اجرا کنید – تست های جدید باید شکست بخورند

آزمایش ها را روی مدلی که در حال توسعه هستید اجرا کنید:

dbt test –select model_being_tested

وارد حالت تمام صفحه شوید

از حالت تمام صفحه خارج شوید

اگر به طور منظم شروع به نوشتن تست کنید، قطعاً تعدادی از آنها را می نویسید که همیشه تصادفی می گذرند. این مرحله آنها را گرفتار می کند.

4. تغییر لازم برای قبولی در آزمون را اعمال کنید

شما ستون ها را مستند کرده اید و تست های خود را نوشته اید. حالا بالاخره وقت نوشتن منطق است! از هیچ ساختار داده از پیش تعیین شده ای فراتر از مرحله بندی داده های خام پیروی نکنید. اگر نیاز دارید از مدل های متوسط ​​استفاده کنید، اما اگر این کار را نکردید، تحت فشار نباشید.

5. تست های dbt را روی مدل اجرا کنید – همه آنها باید قبول شوند

اگر همه آزمون ها قبول شوند، شما آماده اید! اگر نه، به توسعه ادامه دهید. 🙂

6. به مرحله 1 برگردید

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

اجرای توسعه آزمایش محور

این ایده خوبی است که برای اجرای توسعه آزمایش محور در تیم مهندسی تجزیه و تحلیل خود تلاش کنید. به جای غافلگیر کردن مردم با یک خط مشی جدید، توصیه می کنم ضرب الاجلی تعیین کنید که در آن توسعه آزمایش محور اجباری شود و اطمینان حاصل شود که تیم قبل از ضرب الاجل با آن آشنا می شود.

در اینجا یک نمونه گردش کار است که شامل توسعه مبتنی بر آزمایش است:

همه مدل‌های dbt در یک مخزن Git با یک شاخه تولید محافظت شده از نوشتن ذخیره می‌شوند. همه تغییرات در تولید باید از طریق درخواست های کششی با حداقل یک تأیید همتا انجام شود.
مهندسان تجزیه و تحلیل، شاخه های ویژگی را از شاخه تولید ایجاد می کنند و زمانی که ویژگی ها آماده هستند، درخواست های کشش را باز می کنند.
از هر بازبین همتا انتظار می رود که تنها در صورتی درخواست کشش را تأیید کند که آزمایش های مربوط به هر ویژگی را ببیند. اگر آزمایش‌های مربوطه را نمی‌بینند، به این معنی است که TDD دنبال نشده است و درخواست کشش نباید تأیید شود.

نتیجه گیری

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

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

models:
  - name: accounting_transactions
    description: Transactions table for accounting
    columns:
      - name: transaction_key
        description: Synthetic key for the transaction
        tests:
          - not_null
          - unique
      - name: action_date
        description: Date of the transaction
        tests:
          - not_null

with row_count as (
    select
        count(*) as n
    from {{ ref("model_being_tested") }}
    where id1 = 'some_id'
        and id2 = 'other_id'
)
select 'Not exactly 1 row' as error_msg
from row_count
where n <> 1
union all
select 'Row test failed' as error_msg
from {{ ref("model_being_tested") }}
where id1 = 'some_id'
    and id2 = 'other_id'
    and not (
        value1 = 'some example value'
        and value2 is not null and value2 = 'some other value'
        and abs(value3) <= 0.01
    )

dbt test --select model_being_tested