توزیع داده (Reverse ETL)
فرآیند توزیع داده (Reverse ETL) سازوکار استخراج خودکار داده‌های پالایش‌شده از انبار داده بر پایه کوئری‌های SQL یا تنظیمات اختصاصی یکپارچه‌سازی و ارسال زمان‌بندی‌شده آن‌ها به سامانه‌های عملیاتی، CRMها، پنل‌های پیامکی و وب‌هوک‌های خارجی است. این قابلیت داده‌های تحلیلی را به جریان عملیاتی کسب‌وکار بازمی‌گرداند.
دسترسی
مدیریت و اجرای فرآیندهای توزیع داده نیازمند دو سطح دسترسی مجزا در فضا است:
- تعریف مقاصد مجاز: ثبت و ویرایش مقاصد داده در سطح فضا از مسیر
مدیریت فضا>مقصدهای مجازانجام می‌پذیرد و منحصراً در اختیار مالک فضا و مدیر فضا است (اطلاعات محرمانه نظیر توکن‌ها و پسوردها در لاگ‌ها و سیستم ماسک می‌شوند).
- مدیریت و اجرای فرآیندها: امکان تعریف و اجرای فرآیندها نیازمند اعطای مجوز توزیع داده به کاربر در بخش
مدیریت کاربراناست. این دسترسی امکان مشاهده سوابق و لاگ‌های ارسال را نیز شامل می‌شود.
انواع مقاصد
مقاصد توزیع داده در داده‌لند به دو گروه بنیادین تقسیم می‌گردند:
- مقاصد سفارشی (Custom): اتصال مستقیم به وب‌هوک‌ها، وب‌سرویس‌های اختصاصی و سامانه‌های دلخواه بر پایه پروتکل امن HTTPS است (پروتکل ناامن HTTP به شکل سیستمی مسدود است).
- مقاصد آماده (Pre-built): اتصالات بهینه‌سازی‌شده برای پلتفرم‌های بین‌المللی نظیر تلگرام و گوگل ادز هستند که فرآیند پیکربندی، فرم‌ساز کوئری و اعتبارسنجی را به صورت استاندارد فراهم می‌سازند (جهت مطالعه جزئیات، به راهنمای یکپارچه‌سازی‌های توزیع داده مراجعه فرمایید).
تنظیمات مقصد
در تعریف مقاصد سفارشی در سطح فضا، مشخصات فنی زیر تعیین می‌شوند:
| عنوان تنظیم | نوع مقدار | توضیحات و رفتار سیستم |
|---|---|---|
| نام مقصد | متنی | نام نمایشی یکتا برای مقصد در سطح فضا است. |
| آدرس اندپوینت | متنی (URL) | نشانی اینترنتی مقصد منحصراً بر پایه پروتکل امن https:// است. |
| متد ارسال | انتخابی | متد ارسالی شامل POST، PUT یا PATCH است. |
| نوع اعتبارسنجی | انتخابی | شیوه احراز هویت شامل None، Bearer، Basic یا API Key با قابلیت استفاده از متغیرهای محرمانه (Secretها) است. |
| هدرهای سفارشی | کلید/مقدار | هدرهای دلخواه جهت ارسال همراه با درخواست HTTP تعریف می‌شوند. |
| نوع Payload | انتخابی | ساختار بدنه ارسالی شامل JSON Array، JSON Object، NDJSON یا Form است. |
| کلید Wrapper | متنی | در ساختار JSON Array کلید والد داده‌ها را مشخص می‌سازد (در صورت خالی بودن، به صورت آرایه مستقیم ارسال می‌شود). |
| فرمت ارسال آرایه | انتخابی | در فرمت Form شیوه ارسال آرایه‌ها (براکت، تکرار کلید، کاما یا ایندکس) را تعیین می‌کند. |
| سایز Batch | عددی | تعداد رکوردهای ارسالی در هر درخواست (بین ۵۰ تا ۵,۰۰۰ رکورد) را مشخص می‌نماید (برای JSON Object مقدار آن روی عدد ۱ قفل است). |
گام‌های فرآیند
تعریف فرآیند توزیع داده در ۴ گام پیوسته انجام می‌پذیرد:
مشخصات اولیه
پروژه والد فرآیند و نام نمایشی فرآیند در سطح فضا مشخص می‌گردد.
تنظیمات اجرا
نحوه اجرا میان دو حالت تعیین می‌شود:
- دستی: فرآیند با درخواست کاربر، بدون واترمارک و بدون اعمال فیلتر زمانی خودکار اجرا می‌شود.
- خودکار: فرآیند بر مبنای نشانگر واترمارک و به صورت افزایشی (Incremental) طبق زمان‌بندی اجرا می‌گردد:
- فرکانس بازه (Interval): فرآیند در فواصل زمانی مشخص (از ۵ دقیقه تا ۱۲ ساعت) اجرا می‌شود و امکان تعیین بازه ساعتی مجاز در طول شبانه‌روز جهت توقف خودکار فرآیند در ساعات غیرضروری مهیا است.
- فرکانس روزانه: فرآیند در ساعت مشخصی از شبانه‌روز در قالب یکی از ۴۸ بازه نیم‌ساعته بر مبنای منطقه زمانی تهران اجرا می‌شود.
- فرکانس هفتگی: فرآیند در روز تعیین‌شده از هفته و در ساعت مشخصی اجرا می‌گردد.
- نشانگر پردازش (واترمارک): نقطه آغاز استخراج داده‌ها از مبدأ منحصراً بر مبنای ماکزیمم ستون
record_timeدر رکوردهای پردازش‌شده تعیین می‌شود و هیچ وابستگی به مدت زمان اجرای فرآیند ندارد. کاربر می‌تواند این مقدار را با تقویم شمسی یا میلادی به دقت میلی‌ثانیه تنظیم نماید. - بازه عقب‌گرد (Lookback): این قابلیت نشانگر واترمارک را به میزان ۵ تا ۶۰ دقیقه به عقب می‌برد تا داده‌هایی که با تاخیر شبکه ثبت شده‌اند (Late-visible) بدون ریسک ارسال تکراری پوشش داده شوند.
تنظیمات داده
مقصد دریافت داده انتخاب می‌شود. داده‌های ارسالی بر حسب نوع مقصد از دو روش مشخص می‌گردند: در مقاصد سفارشی از نگارش کوئری دستی SQL استفاده می‌شود و در مقاصد آماده (نظیر گوگل ادز و تلگرام) می‌توان از فرم‌ساز و تنظیمات اختصاصی یکپارچه‌سازی بهره برد. در صورت استفاده از کوئری SQL، رعایت انحصار به دستور SELECT و سقف زمان اجرای ۳۰ ثانیه برای تمامی کوئری‌ها الزامی است.
تنظیمات ارسال
در این گام ابزارهای کنترلی ارسال و یکتاسازی برای هر یک از ستون‌های حاصل از کوئری یا تنظیمات یکپارچه‌سازی تعیین می‌گردند:
- تیک ارسال به مقصد: تعیین می‌کند که آیا مقادیر ستون در بدنه درخواست ارسالی (
sent_data) قرار گیرند یا صرفاً در ستونomitted_dataثبت شوند. - سوییچ کلید یکتاسازی: مشخص می‌سازد که آیا مقادیر ستون مبنای محاسبه هش یکتاسازی (
dedup_hash) جهت جلوگیری از ارسال تکراری قرار گیرند یا خیر. - بازه زمانی جست‌وجو: پنجره زمانی مقایسه در لاگ ارسال جهت حذف رکوردهای تکراری در ۱۲ بازه زمانی (از ۳۰ دقیقه تا ۳۰ روز، با پیش‌فرض ۲۴ ساعت) تعیین می‌شود.
قوانین کوئری
این الزامات در زمان نگارش کوئری دستی SQL یا بازبینی کوئری تولیدشده توسط فرم‌ساز یکپارچه‌سازی اعمال می‌گردند و اعتبارسنجی آن‌ها بر مبنای شیوه اجرا انجام می‌پذیرد:
| الزامات کوئری | حالت خودکار | حالت دستی | رفتار سیستم |
|---|---|---|---|
| انحصار به دستور SELECT | ✅ | ✅ | اجرای کوئری‌های چندگانه و دستورات تغییر داده یا ساختار در پایگاه‌داده مسدود است. |
الزام حضور ستون record_time | ✅ | ❌ | در حالت خودکار جهت هدایت نشانگر واترمارک الزامی است. در حالت دستی نیازی به حضور این ستون نیست. |
ممنوعیت فیلتر روی record_time | ⛔ | 🟢 | در حالت خودکار شروط بازه زمانی توسط سیستم تزریق می‌شوند و اعمال فیلتر دستی در شرط WHERE ایجاد خطا می‌کند. در حالت دستی اعمال فیلتر زمانی مجاز است. |
مکانیسم یکتاسازی
داده‌لند با پیاده‌سازی مکانیزم Idempotency در توزیع داده، مانع از ارسال رکوردهای تکراری به مقاصد خارجی می‌گردد:
۱. سیستم از مقادیر ستون‌های دارای سوییچ فعال یکتاسازی، یک هش یکتا تولید می‌نماید.
۲. سوابق ارسالی در جدول dl_retl_deliveries در بازه زمانی تعیین‌شده بررسی شده و رکوردهای دارای هش تکراری حذف (Drop) می‌شوند.
۳. تنها رکوردهای تازه و متمایز به مقصد ارسال می‌گردند.
ارسال دسته‌ای
چنانچه تعداد رکوردهای خروجی بیش از اندازه مجاز Batch مقصد باشد، سیستم اطلاعات را به صورت خودکار در قالب چند دسته (Multi-Batch) مجزا ارسال می‌نماید تا بروز خطای موقت در یک بسته، به ارسال بسته‌های دیگر آسیب نزند.
مدیریت خطاها
سیستم مدیریت خطای توزیع داده بر مبنای ماهیت رخداد تصمیم‌گیری می‌کند:
- خطاهای مسدودکننده (نظیر خطای سینتکس کوئری یا تنظیمات نامعتبر یکپارچه‌سازی، کدهای 4xx کلاینت یا حذف مقصد): فرآیند در اولین اجرا در وضعیت توقف (Paused) قرار گرفته و واترمارک آپدیت نمی‌شود.
- خطاهای گذرا (مانند کدهای 5xx سرور، خطای 429 یا قطعی شبکه): فرآیند تلاش مجدد انجام داده و در صورت تداوم خطا پس از ۳ اجرای ناموفق متوالی، زمان‌بندی به شکل خودکار متوقف می‌گردد.
جداول سیستمی
تاریخچه و لاگ‌های فرآیند توزیع داده در دو جدول سیستمی ذخیره شده و در تمامی محیط‌های کوئری‌نویسی قابل فراخوانی است:
- جدول اجراها (
dl_retl_runs): سوابق هر اجرا (شامل زمان، وضعیت موفقیت، تعداد ردیف‌ها و دسته‌های ارسالی، واترمارک و خطای رخداده) را تا ۹۰ روز یا ۵۰۰ اجرای آخر نگهداری می‌نماید. - جدول لاگ ارسال (
dl_retl_deliveries): مشخصات تک‌تک رکوردهای ارسال‌شده به مقاصد خارجی (شامل هش یکتاسازی، داده‌های ارسالی درsent_dataو داده‌های مستثنی‌شده درomitted_data) را تا ۶۰ روز ثبت می‌کند.
dl_retl_deliveries قابلیت زنجیره‌سازی فرآیندها (Process Chaining) را مهیا می‌سازد. به این معنا که می‌توان ارسال در یک فرآیند را بر مبنای رکوردهای با موفقیت ارسال‌شده در فرآیند قبلی تنظیم نمود.