انجام انبارداری داده به روش اشتباه

اگر خطوط لوله و جریان های داده آینده هستند، چرا ما هنوز به داده ها ثابت فکر می کنیم؟

مدتی است که بدیهی است که به عنوان یک صنعت، ما در تلاش بوده ایم ابزارهای انبار داده مربعی را در حفره های برنامه گرد و مبتنی بر داده قرار دهیم. اما تا زمانی که پست عالی اریک سامر، مدیر عامل Decodeable را خواندم «ما از انبار داده سوء استفاده می کنیم: RETL، ELT، و سایر موارد عجیب” که من متوجه شدم که چرا و چه آسیبی در این فرآیند وارد می کنیم. همانطور که سامر می نویسد، “قرار دادن سیستم های پایگاه داده تحلیلی با قیمت بالا در مسیر داغ، ضد الگوهای شلوار روی سر را به قابلیت پشتیبانی و عملیات معرفی می کند.”

اگر تعجب می کنید، “ضد الگوهای شلوار روی سر” یک تعریف و تمجید نیست. این یک فریاد دردناک است که “یکی لطفا این دیوانگی را متوقف کند!”

ترکیب مشکل داده

از شرکت‌ها بپرسید که در مورد انبارهای داده‌شان چه احساسی دارند و درصد بالایی دارند (۸۳% در این نظرسنجی) ابراز نارضایتی می کند. آنها برای بارگذاری داده ها تلاش می کنند. آنها داده‌های بدون ساختار دارند، اما انبار داده نمی‌تواند آن‌ها را مدیریت کند و غیره. با این حال، اینها لزوماً مشکلاتی در انبار داده نیستند. من احتمال می‌دهم که معمولاً نارضایتی ناشی از تلاش برای وادار کردن انبار داده (یا پایگاه داده تحلیلی در صورت تمایل) به انجام کاری است که برای آن مناسب نیست.

به گفته سامر، یکی از راه‌هایی که خطا شروع می‌شود:

تا کنون، همه روند rETL (معکوس ETL) را دیده اند: می خواهید از داده های برنامه شماره ۱ (مثلا Salesforce) برای غنی سازی داده ها در برنامه شماره ۲ (Marketo) استفاده کنید. ، مثلا). از آنجایی که اکثر مغازه ها در حال حاضر داده ها را از برنامه شماره ۱ به انبار داده با ابزار ELT مانند Fivetran ارسال می کنند، بسیاری از مردم آنچه را که فکر می کنند یک میانبر است، انجام می دهند و تغییر را در انبار داده انجام می دهند و سپس از یک ابزار rETL برای انتقال داده ها استفاده می کنند. از انبار و به برنامه شماره ۲.

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

و چرا این کار را نمی کنند؟ سامر می‌گوید: «انبار داده‌های ابری احتمالاً گران‌ترین چرخه CPU موجود است. توپولوژی انبار داده به ضرب داده ها ختم می شود (ایجاد مسائل حاکمیتی، در میان مشکلات دیگر)، اما این مزیت راحت بودن را دارد. انبارهای داده از این نظر راحت هستند که به خوبی قابل درک هستند. افراد زیادی برای استفاده از آنها آموزش دیده اند و در حال حاضر در حال استفاده هستند.

مشکل درست، راه حل اشتباه

سامر به این نکته قانع‌کننده اشاره می‌کند که آنها دقیقاً اشتباه و پرهزینه‌ترین راه برای ساخت برنامه‌های مبتنی بر داده هستند. چرا؟ زیرا “قرار دادن یک انبار داده بین دو برنامه سطح ۱ یک ایده [بد] است.” شرکت‌ها تمایل دارند با سیستم‌های تحلیلی‌شان «مانند مولفه‌های حیاتی کسب‌وکار سطح ۱» رفتار نکنند. از این رو، «شرکت‌ها ابزارها و داده‌های تحلیلی را برای دسترسی بالا در مناطق در دسترس تکرار نمی‌کنند. آنها (معمولا) پیجر را حمل نمی کنند. آنها فرآیندها را تکراری نمی کنند.” نتیجه «هزینه و ریسک هنگفت» است. یا همانطور که او نتیجه می گیرد، “ما به طور تصادفی تجربه مشتری خود را طوری طراحی کرده ایم که بر فرآیندهای آهسته دسته ای ELT تکیه کنیم.”

پس جایگزین چیست؟

برای سامر، همه چیز مربوط به جریان داده است، نه ELT (یا reETL). این در مورد خطوط لوله داده بلادرنگ مبتنی بر معماری کاپا است. معماری کاپا به این معنی است که شما یک “گزارش غیرقابل تغییر فقط پیوست” دارید. از گزارش، داده‌ها از طریق یک سیستم محاسباتی جریان می‌یابند و برای سرویس‌دهی به فروشگاه‌های کمکی وارد می‌شوند،» میلیندا توضیح می‌دهد Pathirage، متخصص مهندسی داده های بزرگ در KPMG. یا همانطور که مدیر عامل Confluent جی کرپس در سال ۲۰۱۴ زمانی که یک مهندس بود نوشت رهبر لینکدین، با استدلال بر ضد نوعی از رویکرد معماری لامبدا “نوار داکت” که سامرز آن را رد می کند، “چرا نمی توان سیستم پردازش جریانی را برای رسیدگی به مشکلات کامل در دامنه هدف خود بهبود بخشید؟”

یعنی جریان را به مرکز دنیای داده تبدیل کنید.

سامرز پیشنهاد می‌کند که مزایا چند هستند: «هزینه‌ی بسیار کمتری دارد، SLA‌های با کیفیت سطح ۱ را بدون هزینه‌ی کپی کردن داده‌ها فراهم می‌کند، امکان خرابی‌های کسری به جای کلی را فراهم می‌کند، و انبار داده شما را از مسیر بحرانی خارج می‌کند. به بیان ساده، کاپا به این معنی است که داده‌ها را از برنامه شماره ۱ در صورت وقوع، به صورت تکه‌های کوچک به یک دروازه داده ارسال کنید، در صورت لزوم تبدیل/غنی‌سازی کنید، و سپس به صورت موازی به همه مکان‌های مورد نیاز تحویل دهید. >

حتی اگر فکر نمی‌کنید که جریان جایگزین پایگاه‌داده شود (من شخصاً این کار را نمی‌کنم)، به راحتی می‌توان این ایده را درک کرد که خطوط لوله/جریان‌های داده بیشتر آینده هستند تا تلاش برای انتقال داده‌ها به عقب و جلو بین داده‌های تحلیلی. پایگاه های داده اگرچه کاپا و رویکردهای مشابه داده‌های بلادرنگ را ارائه می‌کنند، اما واقعاً در مورد آن نیست. به گفته سامر، این در مورد پایان دادن به «توده عظیمی از بدهی های فناوری است که rETL در حال انباشته شدن است. این در مورد باز کردن لانه وابستگی های مهم به ابزارهای تجزیه و تحلیل و پایدار کردن پشتیبانی است.”

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