لود با تبدیل (Transform)
در لود با تبدیل (Transform)، داده‌ها از سایر جداول انبار داده از طریق کوئری‌های SQL خوانده شده و پس از اعمال تبدیل‌ها و محاسبات، در جدول مقصد لود می‌شوند. این روش در دو سناریوی کلیدی کاربرد دارد:
- پیاده‌سازی فرآیند ELT: تبدیل داده‌های خام از جداول استیجینگ (Staging) به جداول تحلیلی وقایع (Fact) و وصف (Dimension) انجام می‌پذیرد (مراجعه به مقایسه ETL و ELT).
- ساخت جداول لایه طلا (Gold): ایجاد جداول تجمیعی (Aggregated) یا نماهای ۳۶۰ درجه برای افزایش سرعت لود داشبوردها و گزارش‌ها صورت می‌گیرد.
دسترسی
این بخش در صفحه مدیریت دیتاست با کلیک روی جدول موردنظر (دارای دسترسی مدیریت) و ورود به بخش تنظیمات لود داده در دسترس قرار می‌گیرد.
اصل Single Writer
داده‌لند جهت تضمین سلامت و یکپارچگی داده‌ها از اصل نویسنده واحد (Single Writer) پیروی می‌کند؛ بر این اساس در هر جدول فقط یک روش ورود داده می‌تواند فعال باشد:
- لود مستقیم (API): داده‌ها منحصراً از سامانه‌های خارجی از طریق اندپوینت‌ها در جدول درج می‌شوند.
- لود با تبدیل (Transform): ورودی‌های مستقیم خارجی مسدود می‌شوند و داده‌ها صرفاً از طریق اجرای کوئری تبدیل داخلی در جدول نوشته می‌شوند.
پشتیبانی انواع دیتاست
وضعیت پشتیبانی انواع دیتاست از روش‌های ورود داده به شرح زیر است:
| نوع دیتاست | لود مستقیم (API) | لود با تبدیل (Transform) |
|---|---|---|
| جدول وقایع، وصف و آزاد | ✅ | ✅ |
| جدول استیجینگ | ✅ | ❌ |
| جدول آماده | ✅ | ✅ |
| تبدیل آماده | ❌ | ✅ |
| ماژول کلاینت | ✅ (جدول رویدادها با SDK لندر) | ✅ (جدول لاگ فعالیت روزانه کاربر) |
تنظیمات زمان‌بندی
پس از درج کوئری تبدیل (یک دستور استاندارد SELECT)، شیوه اجرای فرآیند تعیین می‌گردد:
- حالت دستی: فرآیند با درخواست مستقیم کاربر و بدون وابستگی به واترمارک اجرا می‌شود.
- حالت خودکار: فرآیند طبق زمان‌بندی مشخص و بر مبنای واترمارک به صورت افزایشی اجرا می‌گردد.
پارامترهای قابل تنظیم در حالت خودکار شامل موارد زیر است:
| عنوان تنظیم | مقادیر انتخابی | توضیحات |
|---|---|---|
| فرکانس اجرا | بازه، روزانه، هفتگی، ماهانه | دوره‌بندی اجرای زمان‌بندی‌شده را تعیین می‌کند. |
| فاصله زمانی اجرا | ۵، ۱۵ و ۳۰ دقیقه یا ۱، ۲، ۳، ۶ و ۱۲ ساعت | فواصل زمانی ثابت بین هر اجرا را در فرکانس «بازه» مشخص می‌سازد. |
| بازه مجاز اجرا | دو محدوده ساعتی از 00:00 تا 23:59 | ساعات مجاز اجرا در طول شبانه‌روز را در فرکانس «بازه» محدود می‌کند. |
| ساعت اجرا (روزانه) | بازه‌های ۳۰ دقیقه‌ای از 00:00 تا 23:30 | زمان دقیق اجرای روزانه را بر اساس افق زمانی ایران (Asia/Tehran) مشخص می‌نماید. |
| روز و ساعت (هفتگی) | روزهای هفته + ساعت (00:00 تا 23:00) | روز و ساعت مشخص اجرای فرآیند در هفته را تعیین می‌کند. |
| روز و ساعت (ماهانه) | روز ماه (۱ تا ۳۰) + ساعت اجرا | روز و ساعت اجرای ماهانه را مشخص می‌سازد (در صورت نبود روز در ماه، اجرا رد می‌شود). |
| نشانگر پردازش (Watermark) | تاریخ و زمان دقیق | نقطه شروع استخراج بر اساس ستون record_time است و پس از هر اجرای موفق آپدیت می‌گردد. |
| بازه Lookback | ۵، ۱۰، ۳۰ یا ۶۰ دقیقه | واترمارک را جهت پوشش داده‌های دیررس (Late Data) به عقب برمی‌گرداند. |
قوانین کوئری تبدیل
اعتبارسنجی کوئری تبدیل بر اساس نوع اجرا متفاوت است:
| الزامات کوئری | خودکار | دستی | توضیحات |
|---|---|---|---|
| انحصار به دستور SELECT | ✅ | ✅ | کوئری منحصراً شامل یک دستور SELECT است و اجرای دستورات تغییر داده یا ساختار (DML/DDL) مجاز نمی‌باشد. |
| تطابق با ستون‌های مقصد | ✅ | ✅ | کلیه ستون‌های اجباری جدول مقصد باید با نام و نوع داده سازگار در خروجی کوئری وجود داشته باشند. |
الزام ستون record_time | ✅ | ❌ | جهت مدیریت واترمارک در حالت خودکار الزامی است؛ اما در حالت دستی نیازی به حضور آن نیست. |
ممنوعیت فیلتر روی record_time | ✅ | ❌ | اعمال فیلتر زمانی روی این ستون در حالت خودکار مجاز نیست؛ زیرا سیستم شروط واترمارک و Lookback را اعمال می‌کند. |
لود افزایشی (Incremental)
در اجرای خودکار، داده‌ها بر مبنای مقدار Watermark و Lookback به صورت افزایشی استخراج و لود می‌گردند. چنانچه حجم ردیف‌ها از سقف مجاز هر درخواست (۱۰ مگابایت) فراتر رود، سیستم خروجی را به چند دسته (Multi-Batch) تفکیک کرده و هر دسته را به شکل مجزا اعتبارسنجی و لود می‌نماید.
پس از اجرای کوئری تبدیل و پیش از انجام لود نهایی، سیستم بررسی می‌کند که آیا در میان ردیف‌های حاصل، رکوردی با مقدار ستون record_time بزرگ‌تر از واترمارک فعلی وجود دارد یا خیر:
- در صورت وجود حداقل یک ردیف با زمانی بزرگ‌تر از واترمارک (
record_time > Watermark)، عملیات لود در جدول مقصد اجرا می‌گردد و واترمارک آپدیت می‌شود. - در صورت نبود ردیف جدیدتر، کل فرآیند لود لغو می‌شود. این سازوکار مانع از آن می‌گردد که با وجود بازه Lookback و عدم تغییر داده در مبدأ، ردیف‌های تکراری لود شوند و مقدار
record_timeجدول مقصد پیوسته تغییر یابد؛ زیرا این جدول ممکن است خود مبدأ فرآیندهای پایین‌دستی (مانند سایر تبدیل‌ها یا فرآیند توزیع داده Reverse ETL) باشد.
مدیریت خطاها
خطاهای اجرای تبدیل به دو دسته تفکیک می‌شوند:
| نوع خطا | سناریوها | رفتار سیستم |
|---|---|---|
| خطاهای مسدودکننده | خطای سینتکس کوئری، مغایرت ساختار با مقصد، رد شدن ردیف‌ها در اعتبارسنجی یا اتمام اعتبار فضا | اجرای خودکار بلافاصله متوقف (Paused) می‌شود و مقدار واترمارک تغییر نمی‌کند. |
| خطاهای گذرا و سیستمی | قطعی موقت ارتباط یا خطاهای موقت سرور | سیستم تا ۳ مرتبه تلاش مجدد انجام می‌دهد و در صورت تداوم خطا، زمان‌بندی متوقف می‌گردد. |
گزارش اجرای تبدیل
تاریخچه اجراهای تبدیل هر جدول تا ۹۰ روز یا سقف ۵۰۰ اجرای اخیر در جدول سیستمی dl_trans_runs ذخیره می‌شود و هم در تب «گزارش اجرای تبدیل» و هم از طریق نگارش کوئری SQL در دسترس است:
| نام ستون | عنوان در رابط کاربری | توضیحات |
|---|---|---|
run_time | زمان اجرا | زمان دقیق شروع اجرا را ثبت می‌کند. |
run_id | شناسه اجرا | شناسه یکتای سیستم برای هر اجرا را نمایش می‌دهد. |
table | جدول | نام جدول مقصد در انبار داده را مشخص می‌سازد. |
trigger | نوع اجرا | نوع اجرای دستی (manual) یا خودکار (auto) را نشان می‌دهد. |
triggered_by | اجراکننده | ایمیل کاربر در اجرای دستی یا مقدار «سیستم» در اجرای خودکار را نمایش می‌دهد. |
status | وضعیت | نتیجه موفق یا ناموفق بودن فرآیند را مشخص می‌کند. |
loaded_rows | تعداد ردیف‌های لود | مجموع ردیف‌های ثبت‌شده با موفقیت در جدول مقصد را نشان می‌دهد. |
batches_sent | دسته‌های موفق | تعداد دسته‌های داده تایید و درج‌شده را گزارش می‌دهد. |
batches_failed | دسته‌های ناموفق | تعداد دسته‌های داده ردشده در اعتبارسنجی را نمایش می‌دهد. |
processing_cost | هزینه پردازش | میزان اعتبار پردازش کسرشده بابت اجرای تبدیل را ثبت می‌نماید. |
run_watermark | نشانگر اجرا | مقدار واترمارک را در زمان آغاز اجرای فرآیند نشان می‌دهد. |
error | خطا | شرح خطای رخ‌داده در اجراهای ناموفق را نمایش می‌دهد. |
query | کوئری اجرا | متن کامل دستور SQL اجراشده را جهت پایش و رفع خطا ثبت می‌کند. |