تقویت هوش تجاری با پیاده‌سازی دریاچه‌ داده (Data lake)

دسته بندی: هوش تجاری (BI)
5 دقیقه زمان مطالعه
1402/02/19
0 نظر

با ظهور بیگ دیتا، روش‌های جدیدی هم برای مدیریت داده نیاز است، زیرا روش‌های هوش تجاری (BI) موجود برای ایجاد انبار داده سازمانی (Enterprise Data Warehouse) و بازارهای داده (Data Mart) دیگر توانایی آن را ندارند که پا به پای نیازهای داده‌محور فعلی پیش بیایند.  این نیازها، موجب شده‌اند تا یک مفهوم جدید به نام Business Data Lake که به اختصار BDL نامیده می‌شود، ایجاد شود.

«دریاچه داده کسب و کاری»، شاید بهترین ترجمه‌ای باشد که بتوانیم برای این مفهوم ارائه کنیم. BDL، در واقع انبار داده‌ای است که در آن انواع داده‌های ساختارمند، نیمه ساختارمند یا حتی بدون ساختار با کمترین هزینه، ذخیره و مدیریت می‌شوند. این رویکرد، به کسب‌ و کارها اجازه می‌دهد که در عین حال که تحلیل‌های اختصاصی بیزینس خود را انجام می‌دهند، یک دیدگاه سازمانی هم ارائه دهند.

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

تفاوت‌های بین دریاچه و انبار داده:

ویژگی انبار داده دریاچه داده
نوع داده ساختارمند، تغییر داده شده ساختارمند، نیمه ساختارمند، بدون ساختار، خام
پردازش schema-on-write schema-on-read
ذخیره پر هزینه‌ برای حجم زیاد داده ساخته شده برای ذخیره داده کم هزینه
چابک بودن دارای تنظیمات ثابت دارای تنظیمات آسان
امنیت بالغ نابالغ
کاربران متخصصان کسب و کار دیتا ساینتیست‌ها

 

پردازش داده‌های انبار داده‌ چه تفاوتی با داده‌های دریاچه داده دارد؟

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

Data Warehouse Vs. Data Lake

در واقع انبار داده‌ها، بهترین نوع پایگاه داده‌ای بودند که می‌شد داشت، چرا که داده‌ها از بخش‌های مختلف می‌توانند جمع‌آوری شده و با هم ادغام شوند و ارائه و نمایش آن‌ها با یک مدل داده‌ای فیزیکی امکان‌پذیر می‌شود.  اساسا، طرح کلی پایگاه داده روی ارتباطات بین جداول مختلف متمرکز شده است؛ همانطور که در پایگاه داده‌های رابطه‌‌ای شناخته شده‌ای مثل  MySQL و PostgreSQL هم می‌بینیم.

 

منابع داده‌ و انبار داده‌ها با استفاده از روشی به نام ETL که مخفف سه کلمه استخراج (Extract)، تبدیل (Transform) و بارگذاری (Load) است، با هم ارتباط برقرار می‌کنند. این رویکرد از قالبی به نام schema-on-write پیروی می‌کنند؛ به این معنی که ساختار کلی انبار داده، در زمان ایجاد آن پیاده‌سازی می‌شود و تمام داده‌ها باید با یک ساختار مشخص وارد شوند.

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

 

زمانی که تیم‌های مهندسی انبار داده یک انبار داده جدید ایجاد می‌کنند، چند انتخاب دارند. شماتیک معماری سه لایه، یکی از محبوب‌ترین معماری‌های موجود است. در این فرم سه لایه، لایه اول همگام‌سازی گام به گام (staging)، لایه دوم انبار کردن و لایه سوم یک مدل ابعادی است که برای ایجاد دیتا مارت یا همان بازار داده مورد استفاده قرار می‌گیرد.

دریاچه داده (Data Lake) چیست؟

حدود ۱۰ سال پیش، مفهوم جدیدی به نام دریاچه داده (Data Lake) به وجود آمد. به بیان ساده، دریاچه داده به معنای جمع‌آوری تمام داده‌های ساختارمند و غیرساختارمند در یک مکان مشترک است. نمونه‌ای از چنین معماری دریاچه داده‌ای، ساختار داده‌ آپاچی هدوپ (Apache Hadoop) است که امکان ذخیره‌سازی و پردازش حجم بالایی از داده را صرف نظر از نوع یا کلاسشان فراهم می‌کند.

what is data lake

دریاچه داده چطور کار می‌کند؟

معماری دریاچه داده، از روش schema-on-read پیروی می‌کند. به این معنی که در این حالت بر خلاف انبار داده، برای ذخیره داده‌های خام، لازم نیست طرح و ساختار از پیش تعیین شده‌ای وجود داشته باشد.

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

دریاچه داده معمولا برای اهداف کاوش‌گرانه و صرفه‌جویی در هزینه‌ها استفاده می‌شود. این روش به شرکت‌ها اجازه می‌دهد تا هم از داده‌های منظم و تصفیه شده و هم از داده‌های خامی که قبلا قابل تحلیل و بررسی نبودند، برای کسب بینش (insight) استفاده کنند.

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

انبار داده در مقایسه با دریاچه داده (یک مطالعه واقعی)

خانم Marilex Rea Llave، استاد یکی از دانشگاه‌های نروژ، مطالعه‌ای با هدف بهبود فهم استفاده از شرکت‌های دریاچه داده‌ای انجام داد که طی آن با ۱۲ متخصص که تجاربی در پیاده‌سازی دریاچه داده در شرکت‌های مختلف داشتند، مصاحبه کرد. خانم Marilex، با این متخصصان مصاحبه کرد تا متوجه شود، به نظر آن‌ها بهترین حوزه‌هایی که می‌توان از رویکرد دریاچه داده در آن‌ها استفاده کرد، کدامند؟ این مطالعه با چنین اهدافی برای انتخاب این رویکرد بسته شد.

  • تلاش اولیه مورد نیاز کاهش پیدا کند، چرا که نیاز نیست فرمت داده‌های جمع‌آوری شده، بر اساس یک شِمای اولیه تغییر کنند.
  • جمع‌آوری و ادغام آسان داده‌ها

نسخه کامل این بررسی را می‌توانید در سایت www.sciencedirect.com مطالعه کنید.

مزایای دریاچه داده

چند مورد از مزیت‌های دریاچه داده در پایین آورده شده است:

محیط هوش تجاری مقرون به صرفه

ما را قادر می‌سازد تا سوالات هوش تجاری بیشتری را تشخیص دهیم.

تمرکز کامل بر نیازهای کسب و کار

شرکت‌ها، دائما در حال تغییر هستند، استراتژی‌ها همواره بهبود پیدا می‌کنند و آنچه که در زمان پیاده‌سازی یک انبار داده مهم هستند، ممکن است بعدا اهمیتی نداشته باشند؛ در نتیجه همیشه باید به‌روز باشیم.

ارائه یک فرآیند و طیفی از ارتقاها برای بازبینی نیازمندی‌ها در حین تکامل

در همان حال که تغییراتی در استانداردهای کسب و کار ایجاد می‌شود، برنامه‌ها هم می‌توانند متناسب‌سازی شوند. این نیازمندی‌ها، می‌توانند هر چقدر که کسب و کار نیاز داشته باشد، بازبینی شوند.

آزمایش‌ها و تست‌های مکرر  و سریع

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

کوتاه شدن دوره‌های طراحی-تحلیل به صورت نمایی

راه‌اندازی یک انبار داده حدود ۶ تا ۱۲ ماه طول می‌کشد، در حالی که راه‌اندازی دریاچه داده، یک کار یک الی دو هفته‌ای است.

کاهش چشم‌گیر هزینه‌ها

اگر به برنامه‌های ETL، ادغام و نیازمندی‌های مدل‌سازی دریاچه داده دقت کنیم، می‌بینیم که ایجاد و نگهداری آن بسیار ارزان‌تر است.

چه چیزی دریاچه داده را کارآمد می‌کند؟

هدوپ (Hadoop)

معماری دریاچه داده، با یک فریم‌ورک منبع باز به نام هدوپ امکان‌پذیر می‌شود. این فریم‌ورک، مکانیزم اصلی ذخیره داده است.  شرکت نرم‌افزاری کانادایی The Jonah Group، وایت‌پیپری درباره دریاچه‌های داده منتشر کرد که در آن توضیح می‌دهد، یکی از مزایای دریاچه داده، ذخیره‌سازی مقرون به صرفه آن در هدوپ با استفاده از حالت نوشتن بدون وابستگی به وجود یک شِما و حالت‌های خواندن مبتنی بر … است.

Advantages of Data Lake

زمانی که داده‌‌ها در سیستم فایلی یا همان فایل سیستم هدوپ نوشته می‌شوند، لازم نیست هیچ شِما یا طرح کلی‌ای تعریف شود و این باعث می‌شود نیاز برای یک انبار داده متمرکز از بین برود. تمام داده‌ها، به منظور بازیابی، بازبینی، تحلیل و گزارش‌گیری در یک محیط همگام‌سازی‌شده در دسترس خواهند بود.

اساسا، دریاچه داده، بدون این که به هزینه‌های اولیه توسعه نیاز داشته باشد، از عهده وظایف ذاتی انبار داده سنتی برمی‌آید؛ بنابراین دریاچه‌های داده، رویکردی را فراهم می‌کنند که هم مقرون به صرفه است و هم چابک. همچنین این امکان را می‌دهند مدل‌هایی داشته باشیم که به طور خاص برای تمرکز بر مدل‌های ابعادی (Dimensional)، برای یک منطقه داده‌ای هدف یا همان بازار‌های داده (Data Mart) مدل‌سازی شده‌اند.

حذف فرآیند‌های ETL پیش‌نیاز

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

تمرکز بر پیش‌بینی به جای گزارش‌دهی‌ها و تحلیل‌های معمول

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

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

آیا دریاچه داده، می‌تواند جایگزین انبار داده برای هوش تجاری باشد؟

با این که دریاچه داده، هم در زمینه جمع‌آوری داده‌های عظیم و هم در مقرون به صرفه بودن، به وضوح مزایای بیشتری نسبت به انبار داده دارد، اما بدون راستی‌آزمایی یکپارچگی داده‌ها، نمی‌توانیم به طور کامل به آن‌ها اعتماد کنیم. در زمان مدل‌سازی کسب و کار، جمع کردن داده‌های خام از منابع مختلف، پاکسازی آن‌ها و اطمینان از کیفیتشان،  ۸۰ درصد از وقت و کار را به خود اختصاص می‌دهد؛ چیزی که اغلب متخصصان آن را نادیده می‌گیرند.

از این منظر، دشوار می‌شود مزایای سازمان‌دهی مناسب و داده‌های با کیفیتی که در معماری و نظم انبار داده وجود دارد را نادیده گرفت. کسب و کارها، هنوز هم به مجموعه‌ای اصلی از شاخص‌های کلیدی عملکرد یا همان KPIها برای تعریف سلامت کسب و کار نیاز دارند. گزارش‌دهی، به ویژه به خاطر ماهیت نظارتی‌ای که دارد، هنوز هم به سازماندهی عالی اطلاعات نیاز دارد.

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

منبع: https://kitrum.com/blog/data-lake-implementation-to-boost-business-intelligence/

امتیاز شما به این مقاله:
نویسنده:

مطالب مرتبط