مطالعه بیشتر

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

ETLها، ELTها، و Reverse ETLها

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

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

با یک مشکل شروع می‌کنیم، نحوه دریافت داده خود به ساختارهایی که پرسیدن سؤال درباره آن داده را آسان می‌کند (ETL)، سپس درباره نحوه استفاده از پاسخ‌هایی که دریافت می‌کنید (reverse ETL) صحبت می‌کنیم، و به ابزارهای درگیر در طول مسیر می‌پردازیم.

Extract، Transform، Load

ابتدا، یک انحراف برای تعریف اصطلاحات و تمایز ELT از ETL. به طور کلی، این اصطلاحات به آماده‌سازی داده برای تحلیل در یک انبار داده یا data mart اشاره می‌کنند، اما به طور خاص این حروف مخفف:

Extract: دریافت داده از اپلیکیشن و سرویس‌های دیگری که استفاده می‌کنید.
Transform: پاک کردن، فیلتر، فرمت، تجمیع، ترکیب، غنی‌سازی، و به طور کلی سازماندهی آن داده برای آسان‌تر کردن ایجاد مدل‌ها در پایگاه داده (مثل مدل‌سازی یک مشتری).
Load: ذخیره آن داده در یک انبار داده (یا در مورد reverse ETL، فشار دادن آن به سرویس‌های شخص ثالث).

ETL در مقابل ELT

برای پیچیده کردن چیزها، وقتی مشتریان ETL می‌گویند، معمولاً یا ETL یا ELT، یا هر دو را می‌گویند. این مخفف‌ها (هر حرف را می‌گویید؛ E.T.L. است، نه "ettle") به فرآیند کلی دریافت داده از یک منبع، انجام کاری به آن، و ذخیره آن جایی که مشتریان بتوانند آن را پرس‌وجو کنند اشاره می‌کنند. تفاوت کلیدی بین ETL و ELT این است که با ETLها مرحله تبدیل داده خارج از انبار داده انجام می‌شود.

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

Pipeline معمول ETL:

منابع داده -> نرم‌افزار پردازش توزیع شده مثل Hadoop، Spark، یا Informatica -> انبار داده مثل Redshift، BigQuery، یا Snowflake.

Jobهای Hadoop، Spark، یا Informatica در حال اجرا روی خوشه‌های سرور داده را پاک می‌کنند، آن را غنی می‌کنند، تجمیع می‌کنند، و در غیر این صورت داده را قبل از بارگذاری در انبار داده سازماندهی می‌کنند.

Pipeline معمول ELT:

منابع داده -> ابزار استخراج مثل Fivetran -> انبار داده (Redshift، BigQuery، Snowflake) -> Jobهای تبدیل تعریف شده و برنامه‌ریزی شده توسط نرم‌افزار مثل DBT در انبار داده شما.

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

به طور کلی، دنیا به سمت رویکرد ELT حرکت می‌کند، و عمدتاً به سه دلیل:

انبار داده بهبود یافته است؛ اکنون می‌توانند کار محاسباتی که به طور سنتی توسط خوشه‌های Hadoop و مانند آن انجام می‌شد را مدیریت کنند.
همچنین می‌توانید داده خام را در انبار داده خود ذخیره نگه دارید، که به شما امکان انجام تبدیل‌های مختلف در آینده برای پاسخ به سؤال‌های جدید درباره داده خود را می‌دهد.
انبار داده همچنین خیلی ارزان‌تر شده است (که خوب است).

چه زمانی ETL را ترجیح دهیم

با این حال، هنوز موارد استفاده خوبی برای ETLها وجود دارد (Metabase، شرکت، از هر دو رویکرد استفاده می‌کند). ETLها انتخاب خوبی هستند وقتی:

تبدیل‌های داده به خصوص پیچیده دارید (گاهی اوقات transform نامیده می‌شوند)،
یا می‌خواهید یادگیری ماشین روی داده قبل از بارگذاری در انبار داده اجرا کنید،
یا نیاز به تغییر فرمت داده برای برآورده کردن مشخصات پایگاه داده دارید.

مثال جریان داده از ETL به reverse ETL

بیایید ساده نگه داریم و بگوییم فقط از سه منبع داده جمع‌آوری می‌کنید:

اپلیکیشن شما،
یک پلتفرم پرداخت مثل Stripe،
یک پلتفرم تیکت کمک مثل Zendesk.

حالا، بگویید می‌خواهید بدانید پشتیبانی مشتری چگونه بر retention تأثیر می‌گذارد. برای تحلیل این اثر، نیاز به بررسی داده اشتراک از Stripe، و مقایسه آن با داده پشتیبانی از Zendesk دارید.

استخراج داده

اگرچه می‌توانید ابزارهای خود را برای استخراج داده بسازید، معمولاً می‌خواهید از سرویسی استفاده کنید که آن پیچیدگی را برای شما مدیریت می‌کند (مثل همگام ماندن با هر API، برنامه‌ریزی jobها، برخورد با خطاها، و غیره).

هنگام ارزیابی ابزارهای استخراج، می‌خواهید گزینه‌هایی را جستجو کنید که:

همه connectorهای مورد نیاز شما را دارند. و پس از انتخاب یک ابزار، مطمئن شوید کتابخانه connectorهای آن‌ها را هنگام ارزیابی ابزارهای مرتبط دیگر در نظر بگیرید. مثلاً، اگر با Fivetran می‌روید، و سپس بعداً خود را در حال خرید یک پلتفرم بازاریابی ایمیل می‌بینید، در نظر بگیرید با پلتفرمی بروید که Fivetran پشتیبانی می‌کند.
می‌توانند داده را به صورت تدریجی استخراج کنند (در مقابل پردازش batch ساده). احتمالاً نیاز به داده بلادرنگ ندارید، اما ممکن است بخواهید به‌روزرسانی‌ها را در دقیقه‌ها به جای یک بار در روز دریافت کنید.
داده را تغییر نمی‌دهند، یا حداقل به طور قابل توجهی. شما باید کسی باشید که داده خود را تبدیل می‌کند، نه سرویس استخراج.

گزینه‌های زیادی در این فضا وجود دارد: Airbyte، Peliqan، Fivetran، Segment، Singer، و Stitch.

بارگذاری داده در یک انبار داده

بارگذاری در این زمینه فقط یعنی داده را در ذخیره‌سازی قرار می‌دهید (گاهی اوقات sink نامیده می‌شود). این ذخیره داده می‌تواند یک پایگاه داده تراکنشی استاندارد مثل PostgreSQL یا MySQL، یک سیستم فایل ساده مثل S3 جفت شده با یک موتور پرس‌وجو مثل Presto، یا یک انبار داده بهینه شده برای پرس‌وجوهای تحلیلی مثل BigQuery، Redshift، یا Snowflake باشد.

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

تبدیل داده

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

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

هنگام ارزیابی ابزارها برای تبدیل داده، می‌خواهید نرم‌افزاری که:

SQL را به عنوان زبان اصلی خود صحبت می‌کند. پایبندی به یک زبان واحد فقط آسان‌تر است، و بیشتر پایگاه‌های داده SQL را درک می‌کنند.
به شما امکان version کردن آن SQL را می‌دهد. اگر یک پرس‌وجو را تغییر دهید و داده نادرست به نظر برسد، می‌خواهید به نسخه قبلی آن پرس‌وجو برگردید تا بفهمید کجا اشتباه شد.
می‌تواند کد شما را تست کند، مثلاً، برای تأیید اینکه همه IDهای شما در خروجی منحصر به فرد هستند.
به شما امکان مستندسازی این jobها را می‌دهد، ترجیحاً ثبت داده فیلد و lineage (تا بدانید داده از کجا می‌آید).

ابزارهای خوب در این فضا DBT و Dataform هستند.

حالا که بینشی به داده خود دارید، چگونه از آن استفاده می‌کنید؟

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

چندین راه وجود دارد که می‌توانید این بینش را در سیستم تیکت کمک خود وصل کنید:

می‌توانید به صورت دستی یک گزارش اجرا کنید تا ببینید کدام شرکت‌ها برای تمدید آماده هستند، یک ستون در Zendesk اضافه کنید که نشان می‌دهد آیا مشتری UP_FOR_RENEWAL است، و آن تیکت‌ها را اولویت‌بندی کنید.
یک ابزار سفارشی بسازید که هر شب اجرا شود، و سپس ستون در Zendesk را با استفاده از API آن به‌روزرسانی کند.
از ابزاری مثل Zapier برای هماهنگی داده بین Stripe و Zendesk استفاده کنید.
از ابزاری مثل Census برای فشار دادن این نقطه داده از انبار داده خود به اپلیکیشن مربوط (در این مورد، Zendesk) استفاده کنید.

Reverse ETL، یا عملیاتی‌سازی داده

Pipeline معمول Reverse ETL:

Reverse ETL فرآیند گرفتن داده که از قبل در انبار داده شما پاک و سازماندهی شده است، و ارسال آن به ابزارهایی که تیم‌های شما استفاده می‌کنند — مثل Salesforce، Zendesk، یا پلتفرم‌های بازاریابی — است تا بتوانند از آن داده در کار روزانه خود استفاده کنند.

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

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

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

بگویید یاد می‌گیرید که اثر retention قوی‌ترین است وقتی شرکت‌ها در پنجره نود روزه هستند، و سالانه بالای X مبلغ به شما پرداخت می‌کنند، و در یکی از سه منطقه جغرافیایی هستند، و X تعداد تیکت در سال گذشته ارسال کرده‌اند، و غیره. با Zapier، باید با اپلیکیشن‌های دیگر هماهنگ شوید تا داده مورد نیاز برای فیلتر کردن مشتریانی که می‌خواهید تیم Customer Success شما اولویت‌بندی کند را همگام کنید. با Census (که می‌تواند jobهای DBT را برای محاسبه نقاط داده اجرا کند)، فقط نیاز به پرس‌وجوی انبار داده دارید، و نتایج آن پرس‌وجو را به نرم‌افزار تیکت کمک فشار دهید. همینطور اگر می‌خواهید یک دسته داده را در چیزی مثل یک classifier Tensor Flow وصل کنید، و آن را فقط بیرون بدهد که classifier فکر می‌کند باید کدام مشتریان را اولویت‌بندی کنید.

در این معنا، اصطلاح "Reverse ETL" کمی نامگذاری نادرست است، چون Census داده را تبدیل نمی‌کند؛ به سادگی از انبار داده می‌خواند، و به اپلیکیشن‌های دیگر می‌گوید چه چیزی نیاز به دانستن دارند؛ در این مورد، کدام مشتریان تیم موفقیت شما باید اولویت‌بندی کنند.

Census، Hightouch، و Zapier را بررسی کنید.