Email: me.dev@developit.ir

سیستم پشتیبانی تصمیم کلان داده - Big Data Decision Support System

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

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

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

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

سازمان ها به منظور بهبود فرایند تصمیم گیری نیاز به اطلاعات ساختیافته دارند. برای رسیدن به این اطلاعات آنها باید داده ها را ذخیره کنند و بر روی آنها تجزیه و تحلیل انجام دهند تا نتایج مفید و با ارزشی به دست آورند. برای انجام فرایند تجزیه و تحلیل داده ها یک محیط مناسب، مخزن بزرگ، استفاده از هوش تجاری BI و یک رابط کاربری لازم است.

مخزن باید با data sources های متفاوت داخلی و خارجی پر شود.  به این مخازن انبار داده یا data mart (اگر مجموعه ی خاصی از اطلاعات را در خود نگه دارد) و اخیرا کلان داده میگوییم.

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

از کلان داده در راستای ابزار های BI میتوان استفاده کرد تا راه کارهای هوشمندی برای فرایند های سازمانی ارائه شود. اطلاعات مورد نیاز برای درک کسب و کار باید جمع آوری، فیلتر، ذخیره و در آخر این داده های ناهمگون و حجیم تجزیه و تحلیل شوند. فرآیند فیلتر و تجزیه و تحلیل داده ها به دلیل اینکه نیاز به استفاده از ابزار ها و استراتژی های BI دارد بسیار پیچیده است.

 

مدل Simon برای فرایند تصمیم گیری.

Simon یک مدل برای تصمیم گیری/تصمیم سازی است. این مدل شامل سه مرحله میشود: هوش، طراحی و انتخاب. در فاز هوش مشکلات شناسایی و اطلاعات در مورد مشکلات جمع آوری میشود. این فاز میتواند یک فرایند طولانی باشد. فاز طراحی راه حل های مختلف و ممکن برای حل مشکلات را مشخص میکند و سر انجام در فاز انتخاب راه حل مناسب مشخص و انتخاب میشود.

فاز هوش شامل جستجو، شناسایی و فرموله کردن مشکلات یا موقعیت هاییست که نیازمند تصمیم گیری میباشد. این فاز ممکن است پیچیده باشد. نتیجه نهایی این فاز یک decision statement است. نام این فاز ممکن است مبهم  باشد. هوش یک اصطلاح غیر رسمی است که به تصمیم گیری مرتبط است. در نهایت ما میدانیم که باید تصمیمی گرفته شود. Simon از یک اصطلاح و مفهوم نظامی گرفته شده و یعنی جمع آوری اطلاعات بدون دانستن اینکه منجر به چه تصمیم گیری خواهد شد. در تصمیم گیری کسب و کار، اغلب باید مقدار زیادی اطلاعات جمع آوری کنیم بدون توجه به اینکه قرار است چه تصمیمی گرفته شود.

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

در فاز انتخاب، گزینه هایی که در فاز طراحی مشخص شده را مورد ارزیابی و یکی از آنها را انتخاب میکنیم.

در این مدل هر فاز حساس به استفاده از روش ها و ابزار های داخل سازمان و دیدگاه ها و فن آوری های آنهاست.

 

یک مدل مجتمع برای فرایند تصمیم سازی، کلان داده و ابزار های BI.

ابزار ها و فناوری های مورد نظر ما شامل مخازن داده ها(data warehouses و data marts) که با داده هایی از منابع عمومی و خصوصی پر میشوند. BI و روش های حل مشکل(PSolM-Problem Solving Methods) که از مهندسی دانش Knowledge Engineering (KE) سرچشمه میگیرند هستند.

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

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

این فرایند به منظور فراهم کردن دامنه ای از اطلاعات برای تمام فاز ها از ابزار های BI استفاده میکند.

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

منظور از فرصت های تصمیم گیری چیست؟

به عنوان مثال ما بازخورد از مشتریان در مورد مشکلات محصولاتمان را داریم، انجام یک روند باعث بهبود و تقویت بهره وری میشود در نتیجه یک فرصت برای افزایش سهم بازار میتواند بهبود ویژگی های محصولاتمان باشد.

فاز طراحی به انتخاب جایگزین اصلی برای مشکلاتی که در مرحله هوش تعریف شده اند کمک میکند.

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

انجام این فرایند ها منجر به تولید یک دانش جدید میشود که از دانش و اطلاعات مربوط به دامنه ای از مشکلات به دست آمده.

ارائه بازخورد این دانش جدید، کلان داده را قدرتمند تر میکند بنابر این میتوان به عنوان یک نقش برای فرایند یادگیری ضروری باشد.

عناصر مدل ارائه شده به شرح زیر میباشند:

  • جمع آوری محتوا از data sources های سازمانی عمومی و خصوصی

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

  • هوش

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

در این فاز از داده های جمع آوری شده مقادیر با ارزش و اطلاعات مرتبط تولید میشوند که میتواند به منظور حل مسائل سازمان استفاده شود.

  • فرصت ها و راه حل ها

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

  • DSS

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

  • اجرای تصمیم

پس از انتخاب، راه حل میتواند در سازمان به منظور حل مشکلی که تعریف شده اجرا گردد و در انتها با توجه به تمام فرایند ها، عناصر دانشی در مورد مشکل، راه حل و تصمیمات گرفته شده تولید میکنند. این دانش ممکن است در مخازن دانش شخصی سازمان ذخیره شود تا در دسترس و قابل استفاده باشد. به همین منظور دانش جدید پس از اجرای انتخاب یا تصمیم در منابع اطلاعاتی(data source) داخلی سازمان قرار میگیرد.

 

استفاده از U3D (Usage-Driven Database Design) به منظور توسعه یک سیستم پشتیبانی تصمیم کلان داده

مراحل ساخت یک انبار کلان داده(Big Data data warehouse) با داده های غیر ساخت یافته تفاوتی با ایجاد یک پایگاه داده عملیاتی یا انبار داده با داده های ساختیافته ندارد.

U3D یا طراحی پایگاه داده محور برای طراحی تمام پایگاه داده ها میتواند مورد استفاده قرار گیرد. صرف نظر از اینکه پایگاه داده برای چه اهدافی استفاده خواهند شد.

رعایت مراحل U3D کمک میکند ذهن طراحان متمرکز شود تا مشکلات قبل از حرکت به سمت یک راه حل کاملا قابل درک باشند به علاوه مستندات مناسبی را برای کسانی که از تصمیمات شما پشتیانی میکنند فراهم میکند.

4 مرحله U3D به طراحان به منظور ایجاد یک پایگاه داده جهت پشتیبانی از یک انبار داده بدون ساختار big data کمک خواهد کرد.

مرحله اول: دگرگونی

اولین گام برای ایجاد یک انبار داده big data تبدیل است. هر رابطه منطقی در مدل داده ای به یک مدل فیزیکی نسبت دارد. برای ساختن big data DSS  کارمندان، طراح میبایست در data dictionary تمام مدل های داده ای را بررسی کند تا روابط کارمندان بدست آید. تصویر زیر یک مدلسازی منطقی از کارمندان و پروژه های سازمان است.

مرحله ی دوم: بهره برداری

DSS کارمندان ممکن است شامل سناریو های زیر باشند:

پرسش: حقوق و دستمزد کارمند چقدر است؟

- مرحله اول: وارد کردن کد/شناسه کارمند

- مرحله دوم: یافتن سوابغ کارمند

پرسش: کارمند چه مسئولیت هایی در سازمان دارد؟

- مرحله اول: وارد کردن کد/شناسه کارمند

- مرحله دوم: یافتن سوابغ کارمند

پرسش: به طور متوسط چه تعداد پروژه توسط کارمند در سال انجام شده؟

- مرحله اول: وارد کردن کد/شناسه کارمند

- مرحله دوم: یافتن نقش کارمند

- مرحله سوم: یافتن پروژه ها

پرسش: آیا کارمند نقش مورد نظر ما را داشته است؟

- وارد کردن نقش

- یافتن نقش کارمند

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

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

مرحله سوم: رسمی سازی

رسمی سازی تفاوتی بین Big Data DSS و پایگاه داده های عملیاتی یا سنتی DSS  ندارد.

طراح باید طراحی پایگاه داده خود را به منظور پشتیبانی از DSS توسعه دهد(پیاده سازی کند)

جدول حقیقت ما جزئیات کارمند است که ترکیب denormalize شده ای از سوابق کارمند و نقش های کارمند میباشد.

از آنجایی که زمان هم موضوع با اهمیتی برای ماست بعد زمان هم اضافه شد.

طراحی پایگاه داده بر اساس این شکل باید در اکثر DBMS های مرسوم کار کند اما یک موضوع ممکن است مانع استفاده در برخی سیستم های مرسوم شود.

سوابغ و نقش های کارمند هر دو ادغام و جدول حقیقت ما با عنوان جزئیات کارمند را ساخته اند زیرا هر دو یک هدف را دنبال میکردند و همچنین بر اساس پرسش هایمان  به هر دو مراجعه میکردیم.

هر دو دارای ویژگی هایی بودند، هر دو دارای چندیدن ارتباط یک به چند بودند. هر دو با هم اطلاعات مشابهی اما نه یکسان را ذخیره میکردند.

با این وجود ترکیب آنها باعث میشود مقداری فیلد های خالی یا null  داشته باشیم. در برخی موارد یک یا چند فیلد میتواند بخشی از کلید اصلی ما باشد که ممکن است مقدار یکی از آنها null باشد.

در نتیجه نیاز به یک DBMS  مناسب برای DSS با قابلیت مدیریت داده های اسپارس و نیمه ساختیافته داریم.

اطلاعات پراکنده/اسپارس.

اطلاعات پراکنده دو مفهوم متفاوت دارد. جالب اینکه هر دو مفهوم در کلان داده بکار برده میشود.

مفهوم اول در مورد فیلد ها و گاهی سطر هاست، که تماما یا اغلب آنها خالی، صفر، null یا هر چیزی که مفهوم نیستی بدهد میباشد.

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

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

به عنوان مثال یک روز گرم به تنهایی اشاره به گرم شدن کره زمین ندارد اما وقتی صدها یا هزاران روز گرم داشته باشیم معنی مهمی خواهد داشت.

داده‌های نیمه ساخت‌یافته.

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

 

شاید برایتان سوال پیش آمده باشد، چرا این مراحل را طی میکنیم و بلافاصله وارد مرحله 4 یعنی پیاده سازی نمیشویم؟

پاسخ ساده است، برای انتخاب یک راه حل غیر استاندارد نیاز به نتیجه گیری دارید نه فرضیات... . در U3D طراح باید ثابت کند راه حل استاندارد و رسمی مناسب نیست.

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

خرید یک سیستم غیر مرسوم، حتی اگر آزاد، متن باز و رایگان است میتواند صدها یا هزاران دلار هزینه داشته باشد(سخت افزار مورد نیاز، کارکنان اضافی، هزینه های آموزش و...)

عدم پیشنهاد Hadoop زمانی که Oracle میتواند نیازها را برطرف سازد از طراح پایگاه داده یک ابرقهرمان خواهد ساخت!

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

مرحله چهارم: سفارشی سازی

ممکن است DSS/DW های مرسوم به خوبی با سیستم پیشنهادی شما کار نکنند. حجم بالای داده ها و یا اطلاعات غیرساخیافته ممکن است طراح را مجبور به انتخاب راه حل دیگری کند. یک راه حل ممکن است معماری مثل Hadoop باشد.

هدوپ در واقع یک محصول نیست، خانواده ای از محصولات است. خود هسته هدوپ شامل دو محصول میباشد:

HDFS - Hadoop Distributed File System

 MapReduce

HDFS  اجازه میدهد داده ها در گره های(سرور ها) زیادی ذخیره شوند. به مجموعه گره ها کلاستر میگوییم. یک فایل ممکن است بین گره ها توزیع شده و یا در گره های مختلف تکرار شده باشد. شکستن یک فایل به فایل های کوچکتر امکان پردازش موازی داده ها را فراهم میکند و تکرار فایل در گره های مختلف دسترس پذیر بودن اطلاعات و پشتیبان گیری را بهبود میبخشد.

MapReduce یک فریمورک است که نظارت میکند چگونه فایل ها با تخصیص برنامه بین گره های مختلف پردازش میشوند.

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

اما Hadoop معکوس هرم عمل میکند، دقیق تر بگویم، داده ها در بالای هرم قرار دارند. این بار برنامه یا کار به گره ها سپرده میشود. این عمل دو مزیت دارد، اول کاهش نقل و انتقال داده ها در شبکه که بسیار پر هزینه است و دوم توزیع کارامد تر پردازش یا کار ها. این یک روش کارامد و ارزان جهت بهبود عمکرد میباشد.

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

و همچنین فراموش نکنید هدوپ DBMS نیست بلکه خانواده از محصولات است...

در بین Hadoop DBMS ها HBase یک گزینه ی قابل توجه و مناسب است که شباهت زیادی با Cassandra دارد.

مانند پایگاه داده های رابطه ای داده ها را در جدول ذخیره میکند،Query Language  شبیه به sql و... دارد. در نتیجه اگر بخواهیم از توزیع های دیگر هدوپ استفاده نکنیم Hbase جایگزین مناسب Cassandra برای big data tps میباشد.

اما نه Hbase و نه Cassandra گزینه ی مناسبی برای DSS نیستند. زیرا زمان اجرای یک درخواست که نیازمند خواندن هزاران یا میلیون ها سطر باشد بسیار بالاست و همچنین هنوز عملیات join را به خوبی پشتیبانی نمیکند.

خوشبختانه خانواده هدوپ محصول دیگری به نام hive  دارد، یک محصول SQL-like که پایگاه داده ی رابطه ای در فضای کاری خود ایجاد میکند. کاربران hiveفکر میکنند در حال تعامل با یک پایگاه داده رابطه ای هستند در حالی که از داده های HDFS استفاده میکنند.

گزینه بعدی استفاده از محصولات شرکت elastic است.

Elasticsearch، یک موتور جستجو و تحلیلگر توزیع شده که اولین بار در سال 2010 عرضه شد. امکان ترکیب و استفاده از انواع مختلف برای جستجو مانند ساختیافته، بدون ساختار و... را دارد. بسیار سریع، دسترس پذیر، و شفاف عمل میکند.

و از همه مهمتر، اگر دیتای زیادی داخلHadoop  دارید میتوانید یک موتور جستجو و تحلیلگر real time هم در کنارش داشته باشید. با استفاده از کتابخانه هایی که به این منظور پیاده سازی شده اند امکان اتصال Elasticsearch به Hadoop فراهم شده.

همچنین قابلیت ادغام با component های محبوب Hadoop وجود دارد و با هرگونه توزیعی از Hadoop به خوبی کار میکند.

با ادغام Elasticsearch و یکی از component های Hadoop داده ها به طور مستقیم در Elasticsearch شاخص گذاری(index) میشوند و همچنین میتوان از HDFS به عنوان یک archive بلند مدت برای Elasticsearch استفاده کرد.

در Hadoop امکان جستجو یا تجزیه و تحلیل محتوا وجود دارد اما سریع ترین روش نیست. ES-Hadoop با فراهم کردن شاخص گذاری داده های Hadoop در Elasticsearch سریعتر از همیشه این کار را انجام میدهد.

برای data visualization(مصورسازی داده ها)  Elasticsearch از kibana استفاده میکند که نه تنها زیبا بلکه بسیار قدرتمند است.

نتیجه گیری.

با استفاده از محصولات ذکر شده برای فرایند تصمیم گیری در سازمان ها، کاربران میتوانند با یک پایگاه داده بسیار حجیم شامل ترابایت یا پتابایت داده ی بدون ساختار تعامل داشته باشند. جدول زیر تفاوت بین سیستم های پردازش تراکنش (TPS) و سیستم های پشتیبانی تصمیم (DSS) در دو حالت متفاوت را نشان میدهد:

 

 

Transaction Processing System - TPS

Decision Support System - DSS

داده های ساخت یافته

حجم معمول

DBMS های مرسوم

تک پردازنده/کلاستر

داده های ساختیافته

به عنوان مثال: RDBMS

پایگاه داده های رایج: تجاری یا عملیاتی

DBMS های مرسوم

تک پردازنده/کلاستر

داده های ساختیافته

به عنوان مثال: RDBMS

پایگاه داده های رایج: انبار داده ها

داده های حجیم

 بدون ساختار

(BigData)

DBMS های غیر مرسوم

پردازش توزیع شده

داده های نیمه ساختیافته

به عنوان مثال: NoSQL، Cassandra

پایگاه داده های رایج: تجاری یا عملیاتی

DBMS های غیر مرسوم

پردازش توزیع شده

داده های نیمه ساختیافته

به عنوان مثال: Hadoop

پایگاه داده های رایج: انبار داده ها

 

منابع.

Poleto, T., de Carvalho, V. D. H., & Costa, A. P. C. S. (2015, May). The roles of big data in the decision-support process: an empirical investigation. In International Conference on Decision Support System Technology (pp. 10-21). Springer International Publishing.

Tillmann, G. (2017). The Big Data Decision Support System. In Usage-Driven Database Design (pp. 301-314). Apress.

Barata, M., Bernardino, J., & Furtado, P. (2014, September). Survey on Big Data and Decision Support Benchmarks. In International Conference on Database and Expert Systems Applications (pp. 174-182). Springer International Publishing.

Kononenko, O., Baysal, O., Holmes, R., & Godfrey, M. W. (2014, May). Mining modern repositories with elasticsearch. In Proceedings of the 11th Working Conference on Mining Software Repositories (pp. 328-331). ACM.

 

این مطلب آخرین بار در تاریخ 1396/06/07 - 17:23 ویرایش شده است.

ارسال نظر
1 نظر
فرهاد حسن پور در تاریخ 1396/02/14 - 20:51 نوشته:
مثل خود کلان داده مطلب بزرگی بود :-)کامل نتونستم بخونم چون فونت ریز بود ... .
پاسخ احسان:

موافقم، یه سری تغییرات دادم مثل رنگ، اندازه فونت و... .ممنون ;)


عضویت در خبرنامه
جهت اطلاع از آخرین فعالیت های من لطفا در خبرنامه عضو شوید