معماری دادهها
مدل کیمبال (Kimball)
↙️ دادهلند بهطور رسمی از مدل معماری کیمبال برای طراحی دادهها استفاده میکند.
این رویکرد که توسط Ralph Kimball معرفی شده است، مبتنی بر مدل Dimensional است و دادهها در قالب جداول وقایع (Fact) و وصفها (Dimension) سازماندهی میشوند. تفاوت این دو جدول در نوع اطلاعات و دادههایی است که میزبانی میکنند.
جدول وقایع (Fact) به مجموعه دادههایی گفته میشود که نشانگر وقوع یک رخداد در فرآیندهای سازمانی است که معمولا شامل مقادیر عددی و قابل اندازهگیری میشود. برای مثال، یک سفارش فروش یک واقعه محسوب میشود و مقادیر عددی مثل مقدار فروش، تعداد آیتم و قیمت کل در این واقعه ثبت میشوند.
نمونهای ساده از یک جدول وقایع به این شکل است:
| order_date | order_id | item_count | discount_amount | sales_amount |
|---|---|---|---|---|
| 2023-01-06 | 1003 | 1 | 500 | 7520 |
| 2023-01-06 | 1004 | 5 | 2000 | 30000 |
در مقابل، وصف (Dimension) به مجموعه دادههایی گفته میشود که اطلاعات توصیفی درباره یک ماهیت ثابت ارائه میکنند؛ برای مثال جدول اطلاعات مشتری (مانند نام، سن و...) که حاوی اطلاعات توصیفی درباره مشتریان است یک جدول وصف محسوب میشود.
برای مثال یک جدول وصف میتواند چنین باشد:
| join_date | id | name | age | city |
|---|---|---|---|---|
| 2022-03-15 | 1 | Ali | 30 | Tehran |
| 2021-07-20 | 2 | Sara | 25 | Isfahan |
در این معماری، یک جدول وقایع میتواند ستونهایی برای ارجاع به جدولهای وصف (Dimension) داشته باشد. این ستونها معمولاً به شکل شناسه (ID) هستند تا هر واقعه به دادههای توصیفی مرتبط در جدول وصف متصل شود. این رویکرد به جداسازی داده وقایع از داده وصف کمک میکند و اصول دادهای توصیه میکنند که یک جدول وقایع جدا و چندین جدول وصف در نظر گرفته و ارتباطها از طریق شناسهها برقرار شود.
برای مثال، جدول وقایع فروش با ارجاع به جدول مشتری (ستون user_id) میتواند به شکل زیر باشد:
| order_date | order_id | user_id | item_count | discount_amount | sales_amount |
|---|---|---|---|---|---|
| 2023-01-06 | 1003 | 1 | 1 | 500 | 7520 |
| 2023-01-06 | 1004 | 2 | 5 | 2000 | 30000 |
با این ساختار، هر واقعه میتواند اطلاعات توصیفی مرتبط با مشتری خود را از جدول وصف با استفاده از یک JOIN بازیابی کند. این الگو که مبتنی بر نرمالسازی است، از تکرار دادههای توصیفی در جدول وقایع جلوگیری میکند و باعث میشود دادهها در جداول تخصصی و مجزا سازماندهی شوند.
در دادهلند جداول ماژولها مبتنی بر مدل کیمبال هستند. همچنین در هنگام ساخت جدول سفارشی، گزینهای برای انتخاب از بین نوع جدول وقایع و وصف در اختیار گذاشته میشود.
مقایسه با سایر مدلها
در کنار مدل کیمبال، رویکردهای معماری دیگری مانند Inmon و Data Vault نیز مطرح هستند.
رویکرد Inmon یکی از معروفترین روشها برای طراحی و پیادهسازی انبار داده سازمانی (Enterprise Data Warehouse) است و به آن روش Top-Down گفته میشود. در این رویکرد، ابتدا تمرکز روی ایجاد یک انبار داده مرکزی و یکپارچه است که شامل تمام دادههای مهم سازمان میشود. این دادهها از منابع مختلف جمعآوری، پاکسازی و استانداردسازی میشوند تا کیفیت و سازگاری آنها تضمین شود. پس از ایجاد این انبار داده جامع، میتوان Data Martهای تخصصی را برای تحلیلهای موردی و گزارشگیری ایجاد کرد. به عبارت دیگر، Data Martها از دل انبار داده استخراج میشوند و دادهها به صورت هدفمند برای تیمهای تحلیلی ارائه میشوند.
مدل Data Vault دادهها را در سه نوع جدول اصلی نگه میدارد: Hub که کلیدهای اصلی هر ماهیت مثل مشتری یا محصول را ذخیره میکند، Link که روابط بین این ماهیتها را ثبت میکند، و Satellite که جزئیات و تغییرات تاریخی دادهها را نگه میدارد. وقتی دادهها تغییر میکنند، به جای اینکه رکورد قدیمی را بازنویسی کنیم، تغییرات در Satellite اضافه میشوند تا تاریخچه کامل دادهها حفظ شود. به این ترتیب، ساختار اصلی دادهها و روابط بین آنها همیشه ثابت میماند و میتوان همزمان جزئیات و تاریخچه را بررسی کرد.
در جدول زیر مقایسه بین مدل کیمبال، Inmon و Data Vault ارائه شده است:
| ویژگی | Kimball | Inmon | Data Vault |
|---|---|---|---|
| رویکرد طراحی | Bottom-Up | Top-Down | Flexible/Historized |
| ساختار داده | Fact & Dimension | Enterprise Data Warehouse and Data Marts | Hub, Link, Satellite |
| مدلسازی داده | *Normalized Facts | Normalized | Hybrid / Historized |
| پیچیدگی طراحی | متوسط | زیاد | زیاد |
| کاربران نهایی | تحلیلگران و کاربران هوش تجاری | تیمهای IT و ETL | تیمهای داده |
| عملکرد کوئری | بالا | متوسط | متوسط |
| زمان پیادهسازی | کوتاه | طولانی | طولانی |
| کاربرپسندی | زیاد | کم | متوسط |
* هرچند استاندارد مدل کیمبال معمولاً با Star Schema شناخته میشود، اما در دادهلند از نظر فنی محدودیتی برای استفاده از دیمنشنهای تودرتو (Snowflake Schema) وجود ندارد و دیمنشنها میتوانند به صورت نرمالسازی شده (Normalized) طراحی شوند.
مزیت مدل کیمبال
با توجه به همراستایی بیشتر مدل کیمبال با ماموریت بهرهبرداری از داده، این مدل در محصول دادهلند یکپارچه شده است. در ادامه مزیتهایی که این معماری را نسبت به سایر گزینهها برتری میدهد ارائه شده است:
- بهرهبرداری سریعتر از دادهها: در صورت پیروی از فرآیندهای ETL، دادهها از ابتدا با اهداف مشخص و از پیش تعیینشده در جداول نهایی ذخیره میشوند، که این امر به سازمانها امکان میدهد سریعتر از سایر مدلها به تحلیلها و بینشهای ارزشمند کسبوکار دسترسی پیدا کنند و Time to Value سریعتری را تجربه کنند.
- سادگی و کاربرپسندی: طراحی فکتها و دیمنشنها به کاربران اجازه میدهد بدون دانش فنی عمیق، با سهولت بیشتری با دادهها کار کنند و نیاز به آموزش و آنبوردینگ طولانی کاهش یابد. این ویژگی باعث میشود مدل کیمبال حتی در سازمانهایی با بلوغ دادهای پایین نیز بهراحتی قابل استفاده باشد.
- پیادهسازی کمهزینهتر: به دلیل نزدیکی بیشتر به دیتابیسهای اپلیکیشن و ساختار سادهتر، مدل کیمبال امکان پیادهسازی سریعتر با فرآیندهای ETL محور را فراهم میکند.
- پشتیبانی از توسعه تدریجی: سازمانها میتوانند ابتدا مهمترین دادهها و تحلیلها را پیاده کنند و سپس به تدریج انبار داده بزرگتر و جامعتری ایجاد کنند.
- انعطافپذیری در طراحی: امکان افزودن ساختارها و تحلیلهای جدید بهتدریج وجود دارد و بدون نیاز به بازسازی کل انبار داده، میتوان به نیازهای تحلیلی تازه پاسخ داد.