مطالعه بیشتر
احتمالاً این اصطلاحات را میشنوید، پس در اینجا برخی زمینه درباره تفاوتهای بین یک انبار داده، یک دریاچه داده، و یک data mart وجود دارد.
انبار داده در مقابل دریاچه داده در مقابل data mart
احتمالاً این اصطلاحات را میشنوید، پس در اینجا برخی زمینه درباره تفاوتهای بین یک انبار داده، یک دریاچه داده، و یک data mart وجود دارد.
نکته درباره این اصطلاحات استاندارد انبار داده این است که خیلی خوب نیستند. آنها کلمات بازاریابی نرم با استعارههای اضافهبار شده هستند، پس حتی افراد داده با تجربه میتوانند ایده مبهمی از آنچه دقیقاً به آن اشاره میکنند داشته باشند. گاهی اوقات میتوانند به چیزی خاص اشاره کنند، گاهی اوقات میتوانند به چیزی فوقالعاده انتزاعی اشاره کنند. این را نوشتیم چون احتمالاً این اصطلاحات را میشنوید، و میخواستیم برخی زمینه درباره هر کدام به شما بدهیم.
اگر به دنبال توصیه درباره چه چیزی برای ذخیره داده تحلیلی خود استفاده کنید هستید، کدام انبار داده باید استفاده کنید؟ را بررسی کنید.
انبار داده
یک انبار داده فقط یک مکان ساختار یافته است که دادهای که میخواهید پرسوجو کنید را در آن قرار میدهید. میتواند یک پایگاه داده مقیاسپذیر با ذخیرهسازی ستونی بهینه شده برای پرسوجوهایی باشد که داده زیادی را لمس میکنند، یا میتواند یک اتاق با برخی کابینتهای فایل باشد. نکته اینجا این است که انبار داده از پایگاه داده تولید شما متمایز است، حتی اگر آن انبار داده فقط یک کپی از، مثلاً، پایگاه داده تولید PostgreSQL شما باشد. این مکانی است که برای نگه داشتن داده برای تحلیل در نظر گرفته شده است، نه نیازهای اپلیکیشن یا سرویس شما. انبارهای داده همچنین اساساً فقط خواندنی هستند؛ تنها چیزی که باید به انبار داده شما بنویسد ETLها هستند.
در حالت ایدهآل، با این حال، میخواهید داده خود را به گونهای سازماندهی کنید که انواع سؤالهایی که میخواهید بپرسید را پیشبینی میکند. یعنی میخواهید داده نرمالسازی شده بهینه شده برای تراکنشهای اپلیکیشن خود، و همچنین همه dumpهای داده از اپلیکیشنها و سرویسهای شخص ثالث (به همه آن دادههای به سختی به دست آمده از نرمافزار مدیریت روابط مشتری فکر کنید) را بگیرید، و آن را ETL کنید به ستونها یا جداولی که پاسخ دادن به سؤالهایی مثل، چند مشتری ماه گذشته ثبت نام کردند در مقابل قبلی، یا کدام بخش از قیف onboarding بیشترین افت را دید را آسان میکند؟
همچنین میشنوید مشتریان به انبارهای داده به طور خاص به عنوان یک نوع خاص از پایگاه داده یا سرویس ابری که در پردازش پرسوجوی تحلیلی تخصص دارد اشاره میکنند. انبارهای داده مثل BigQuery، Redshift، Snowflake، و Vertica برای تجمیع و فیلتر کردن مقادیر زیادی داده طراحی شدهاند. طرف دیگر این است که آنها برای استفاده به عنوان پایگاههای داده اپلیکیشن وحشتناک هستند، چون برای پیدا کردن رکوردهای خاص (مثل برگرداندن اطلاعات پروفایل یک نفر وقتی وارد میشود) خیلی خوب نیستند.
دریاچه داده
دریاچههای داده محل تخلیه برای همه داده شما از همه منابع شما هستند (معمولاً در یک سرویس ذخیرهسازی شیء که شبیه یک سیستم فایل توزیع شده است—مثل S3 AWS). این داده لزوماً ساختار یافته نیست (حتی اینجا به کابینتهای فایل نیاز ندارید). مزیت یک دریاچه داده این است که مجبور نیستید از قبل انواع پرسوجوهایی که میخواهید روی داده اجرا کنید را تعیین کنید. انبارهای داده عالی هستند، اما میتوانند نیاز به کار زیادی برای راهاندازی داشته باشند، هم در فهمیدن نحوه مدلسازی داده خود، و سپس در واقع تبدیل داده خود از همه منابع شلوغ خود به آن ساختار. با دریاچههای داده، فقط به نوعی جداول را با ETLها همانطور که نیاز دارید برپا میکنید. میتوانید از موتورهای پرسوجو مثل Presto استفاده کنید که به شما امکان استفاده از SQL برای پرسوجوی داده پخش شده روی یک دسته bucketهای S3 (اساساً یک سیستم فایل توزیع شده) را میدهند. یا میتوانید مدلهای یادگیری ماشین را روی بخشهایی از دریاچه داده خود آموزش دهید.
برخی ارائهدهندگان ابر محصولات دریاچه داده ارائه میدهند، مثل Data Lake AWS، جایی که "محصول" دریاچه داده ترکیب خاصی از سرویسها (اجزای "زیرساخت") است که با هم به شما کمک میکنند داده را به داخل و خارج از ذخیرهسازی دریافت کنید، در این مورد S3 AWS (Simple Storage Service). رویکرد دیگر، یکی که توسط BigQuery استفاده میشود، منابع داده فدرال است، جایی که "دریاچه" یک مکان نیست، بلکه مکانهای متعددی است که BigQuery میتواند پرسوجو کند.
Data mart
یک data mart اساساً مجموعهای از داشبوردها است که داده از یک زیرمجموعه از یک انبار داده یا دریاچه را برای یک عملکرد کسبوکار خاص تحلیل میکند. یعنی، یک data mart بخشی از یک انبار داده یا دریاچه، کیوری شده برای یک تیم یا یک دامنه تحلیلی، را با داشبوردها و تجسمهایی که آن داده را تحلیل میکنند ترکیب میکند. آنها چیزی نیستند که بتوانید بخرید؛ چیزی هستند که سازمان شما باید تعریف و بسازد.
Data marts به طور کلی به عنوان یک برش عمودی از stack داده تصور میشوند، جایی که آن برشها با تیمهای مختلف در سازمان مطابقت دارند. پس یک data mart نمونه برای یک تیم بازاریابی در یک شرکت شامل همه جداول و مدلها (و جداول خلاصه که واقعیتها و ابعادی که تیم به آنها علاقه دارد را تجمیع میکنند)، ETLهایی که آن جداول را میسازند، و همچنین "رابط انسانی" به آن داده کیوری شده: ابزار BI (مثل متابیس) با نمودارها و داشبوردهایی که تیم بازاریابی ایجاد کرده است (یا به طور سنتی که تیم داده یا مهندسی برای آنها تنظیم کرده بود) خواهد بود.
Data marts لزوماً نباید آن قدر سفت و سخت باشند، و نباید باشند. اگر میخواهید، میتوانید یک مجموعه از سؤالها و داشبوردها در متابیس که همه چیزهایی که تیم عملیات به آنها علاقه دارد را پوشش میدهد کنار هم بگذارید و آن را یک data mart عملیات بنامید. همچنین میتوانید داده و تحلیل آن را بر اساس موضوع سازماندهی کنید: اینجا همه چیزهایی که درباره مشتریان خود میدانیم، همه چیزهایی که درباره زنجیره تأمین خود میدانیم، قیف فعالسازی ما، و غیره. ابزارهای BI همچنین میتوانند کارهای مرتبی انجام دهند جایی که میتوانید داشبوردهایی با فیلترها بسازید که تنظیم روی محصولات یا دستههای خاص یا هر چیز دیگری را آسان میکند.
Data marts به عنوان یک مفهوم مدتی است که وجود دارد، اما دیگر این اصطلاح را اغلب نمیشنوید. به طور سنتی، توسعه data mart توسط یک تیم داده یا مهندسی برای تیمهای دیگر انجام میشد، که میتواند خوب یا بد باشد. خوب اگر اطمینان میدهد داده کار با آن، کاوش، و گسترش روی آن آسان است؛ بد وقتی داده را silo میکند و کنجکاوی را با دشوار کردن پرسیدن سؤالهای مرتبط یا گنجاندن داده از جای دیگر خفه میکند. اما ایده اساسی پشت یک data mart (که سازماندهی داده برای آسانتر کردن پرسیدن سؤالها برای مشتریان) عزیز به نحوه تفکر متابیس درباره هوش کسبوکار است. BI باید خودخدمت باشد، پس طراحی خوب data mart فقط مجموعهای از پاسخها به مشتریان نمیدهد، ابزارهایی که نیاز دارند برای پاسخ دادن به آن سؤالها، برش و تکهتکه کردن آن پاسخها، و پرسیدن سؤالهای خود را به مشتریان میدهد.