مروری بر متدولوژی های طراحی چابک DWH

توسعه ذخیره سازی یک تجارت طولانی و جدی است.

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

رویکرد عمومی پذیرفته شده ترکیبات مختلفی از طرحواره ستاره با سومین شکل عادی بوده و باقی می ماند. به عنوان یک قاعده، طبق اصل: داده های اولیه - 3NF، ویترین ها - یک ستاره. این رویکرد که با زمان آزمایش شده و با تحقیقات زیادی پشتیبانی شده است، اولین (و گاهی اوقات تنها) چیزی است که برای یک متخصص با تجربه DWH در هنگام فکر کردن به اینکه یک مخزن تحلیلی باید چگونه باشد به ذهن می رسد.

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

و اگر در زندگی آرام و راحت خود به عنوان یک توسعه دهنده DWH ناگهان:

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

یا اگر فقط علاقه مند به یادگیری نحوه دیگری هستید که می توانید فضای ذخیره سازی بسازید - به گربه خوش آمدید!

"انعطاف پذیری" به چه معناست؟

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

به طور جداگانه، شایان ذکر است که خواص توصیف شده باید به طور خاص به آن اشاره شود سیستم، نه به روند توسعه آن بنابراین، اگر می خواهید در مورد Agile به عنوان یک متدولوژی توسعه مطالعه کنید، بهتر است مقالات دیگری را مطالعه کنید. به عنوان مثال، در همان جا، در Habré، بسیاری از مواد جالب وجود دارد (مانند مرور и کاربردیو مشکل ساز).

این بدان معنا نیست که فرآیند توسعه و ساختار انبار داده کاملاً نامرتبط هستند. به طور کلی، توسعه Agile یک ذخیره سازی چابک باید بسیار ساده تر باشد. با این حال، در عمل، گزینه های بیشتری با توسعه Agile DWH کلاسیک با توجه به Kimbal و DataVault - بر اساس آبشار نسبت به تصادفات خوش انعطاف پذیری در دو شکل آن در یک پروژه وجود دارد.

بنابراین، ذخیره سازی انعطاف پذیر چه ویژگی هایی باید داشته باشد؟ در اینجا سه ​​نکته وجود دارد:

1. تحویل زودهنگام و تکمیل سریع - این بدان معنی است که در حالت ایده آل اولین نتیجه تجاری (به عنوان مثال، اولین گزارش های کاری) باید در اسرع وقت به دست آید، یعنی حتی قبل از طراحی و پیاده سازی کل سیستم. در عین حال، هر بازبینی بعدی نیز باید تا حد امکان زمان کمتری را صرف کند.
2. پالایش تکراری - این بدان معنی است که هر تجدید نظر بعدی، در حالت ایده آل، نباید بر عملکرد از قبل کار تأثیر بگذارد. این لحظه است که اغلب به بزرگترین کابوس در پروژه های بزرگ تبدیل می شود - دیر یا زود اشیاء فردی شروع به به دست آوردن روابط زیادی می کنند که تکرار کامل منطق در یک کپی در کنار هم آسان تر از افزودن یک فیلد به جدول موجود می شود. و اگر تعجب کرده اید که تجزیه و تحلیل تأثیر بهبودها بر روی اشیاء موجود می تواند بیشتر از خود تجدید نظر طول بکشد، به احتمال زیاد با انبارهای داده بزرگ در بانکداری یا مخابرات کار نکرده اید.
3. سازگاری مداوم با نیازهای در حال تغییر کسب و کار - ساختار کلی شی باید نه تنها با در نظر گرفتن گسترش احتمالی، بلکه با این انتظار طراحی شود که جهت این بسط بعدی حتی در مرحله طراحی قابل تصور نباشد.

و بله، رعایت تمامی این الزامات در یک سیستم امکان پذیر است (البته در موارد خاص و با رعایت ملاحظات).

در زیر دو مورد از محبوب ترین متدولوژی های طراحی چابک برای HD - را بررسی خواهم کرد مدل لنگر и خزانه داده. در خارج از براکت ها ترفندهای عالی مانند EAV، 6NF (در شکل خالص آن) و همه چیز مربوط به راه حل های NoSQL وجود دارد - نه به این دلیل که آنها به نحوی بدتر هستند، و نه حتی به این دلیل که در این مورد مقاله تهدید به دریافت حجم می کند. یک دیسر متوسط فقط همه اینها به راه حل هایی با کلاس کمی متفاوت اشاره دارد - یا به تکنیک هایی که می توانید بدون توجه به معماری کلی پروژه خود در موارد خاص اعمال کنید (مانند EAV)، یا به پارادایم های مختلف ذخیره سازی اطلاعات در سطح جهانی (مانند پایگاه های داده گراف). و گزینه های دیگر). NoSQL).

مشکلات رویکرد "کلاسیک" و راه حل های آنها در روش شناسی انعطاف پذیر

منظور من از رویکرد "کلاسیک" ستاره خوب قدیمی است (صرف نظر از اجرای خاص لایه های زیرین، طرفداران کیمبال، اینمون و CDM را ببخشید).

1. کاردینالیته صلب اتصالات

این مدل بر اساس تقسیم بندی واضح داده ها به اندازه گیری (بعد) и حقایق (واقعیت). و این، لعنتی، منطقی است - از این گذشته، تجزیه و تحلیل داده ها در اکثریت قریب به اتفاق موارد به تجزیه و تحلیل برخی از شاخص های عددی (حقایق) در بخش های خاص (ابعاد) ختم می شود.

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

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

به عنوان مثال، هنگام طراحی شی "دریافت نقدی"، شما با اتکا به تضمین های قسم خورده بخش فروش، امکان اقدام را تعیین کردید. یک ارتقاء برای چندین موقعیت چک (اما نه برعکس):

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

(همه اشیاء مشتق شده، که چک تبلیغاتی در آنها می پیوندد، اکنون نیز نیاز به بهبود دارند).

پیوندها در Data Vault و Anchor Model

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

این رویکرد پیشنهاد شده است دن لینستد به عنوان بخشی از پارادایم خزانه داده و به طور کامل پشتیبانی می شود لارس رونبک в مدل لنگر.

در نتیجه، اولین ویژگی متمایز متدولوژی های انعطاف پذیر را دریافت می کنیم:

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

В خزانه داده چنین جداول نامیده می شود ارتباط دادن، و در مدل لنگر - کراوات. در نگاه اول، آنها بسیار شبیه هستند، اگرچه تفاوت های آنها با نام (که در زیر مورد بحث قرار خواهد گرفت) تمام نمی شود. در هر دو معماری، جداول پیوند می توانند پیوند دهند هر تعداد موجودیت (نه لزوما 2).

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

2. تکثیر داده ها

دومین مشکل حل شده توسط معماری های انعطاف پذیر در وهله اول کمتر آشکار و ذاتی است. نوع اندازه گیری SCD2 (آهسته در حال تغییر اندازه گیری های نوع دوم)، اگرچه نه تنها آنها.

در ذخیره سازی کلاسیک، یک بعد معمولاً جدولی است که حاوی یک کلید جایگزین (به عنوان PK) و مجموعه ای از کلیدها و ویژگی های تجاری در ستون های جداگانه است.

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

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

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

به طور معمول، این منجر به همان اطلاعات به طور همزمان در چندین مکان ذخیره می شود. به عنوان مثال، اطلاعات مربوط به منطقه محل سکونت و عضویت در دسته مشتری را می توان به طور همزمان در ابعاد "مشتری" و اطلاعات "خرید"، "تحویل" و "مخاطبین مرکز تماس" و همچنین در "مشتری - ذخیره کرد. مدیر مشتری» جدول پیوند.

به طور کلی، موارد فوق در مورد اندازه‌گیری‌های معمولی (غیر نسخه‌ای) صدق می‌کند، اما در اندازه‌گیری‌های نسخه‌شده، می‌توانند مقیاس متفاوتی داشته باشند: ظاهر یک نسخه جدید از یک شی (مخصوصاً در آینده) نه تنها منجر به به‌روزرسانی همه جداول مرتبط می‌شود، بلکه به یک ظاهر آبشاری از نسخه های جدید اشیاء مرتبط - زمانی که از جدول 1 برای ساخت جدول 2 و جدول 2 برای ساخت جدول 3 و غیره استفاده می شود. حتی اگر هیچ یک از ویژگی های جدول 1 در ساخت جدول 3 دخیل نباشد (و سایر ویژگی های جدول 2 که از منابع دیگر به دست آمده اند دخیل باشند)، نسخه سازی این ساختار حداقل منجر به سربار اضافی و حداکثر می شود. نسخه های اضافی در جدول 3، که به طور کلی "هیچ ربطی به آن" و پایین تر از زنجیره است.

3. پیچیدگی غیر خطی پالایش

در همان زمان، هر ویترین جدید که در بالای دیگری ساخته می‌شود، تعداد مکان‌هایی را افزایش می‌دهد که داده‌ها می‌توانند در هنگام ایجاد تغییرات در ETL «واگرا» شوند. این به نوبه خود منجر به افزایش پیچیدگی (و مدت زمان) هر تجدید نظر بعدی می شود.

اگر موارد فوق در مورد سیستم‌هایی با فرآیندهای ETL که به ندرت تغییر می‌یابند صدق می‌کند، می‌توانید در چنین پارادایمی زندگی کنید - فقط مطمئن شوید که پیشرفت‌های جدید به درستی در تمام اشیاء مرتبط انجام شده است. اگر تجدید نظرها به طور مکرر انجام شود، احتمال "از دست رفتن" تصادفی چندین پیوند به طور قابل توجهی افزایش می یابد.

علاوه بر این، اگر در نظر بگیریم که ETL «نسخه‌شده» بسیار پیچیده‌تر از «غیر نسخه‌شده» است، اجتناب از اشتباه در طول اصلاح مکرر کل این اقتصاد بسیار دشوار می‌شود.

ذخیره اشیا و ویژگی ها در Data Vault و Anchor Model

رویکرد ارائه شده توسط نویسندگان معماری های انعطاف پذیر را می توان به صورت زیر فرموله کرد:

لازم است آنچه را تغییر می دهد از آنچه بدون تغییر باقی می ماند جدا کرد. یعنی کلیدها را جدا از ویژگی ها ذخیره کنید.

با این حال، اشتباه نکنید نسخه نشده صفت با بدون تغییر: اولی تاریخچه تغییرات خود را ذخیره نمی کند، اما می تواند تغییر کند (مثلاً هنگام تصحیح خطای ورودی یا دریافت داده های جدید)، مورد دوم هرگز تغییر نمی کند.

دیدگاه ها در مورد اینکه دقیقاً چه چیزی را می توان بدون تغییر در Data Vault و مدل Anchor در نظر گرفت متفاوت است.

از نظر معماری خزانه داده، را می توان بدون تغییر در نظر گرفت کل مجموعه کلیدها - طبیعی (TIN سازمان، کد محصول در سیستم منبع و غیره) و جایگزین. در عین حال، ویژگی های باقی مانده را می توان با توجه به منبع و/یا فراوانی تغییرات به گروه هایی تقسیم کرد برای هر گروه یک جدول جداگانه نگه دارید با مجموعه ای مستقل از نسخه ها.

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

В خزانه داده جداول حاوی کلیدهای موجودیت فراخوانی می شوند هوبامی (هاب). هاب ها همیشه حاوی مجموعه ای ثابت از فیلدها هستند:

• کلیدهای موجودیت طبیعی
• کلید جانشین
• لینک به منبع
• زمان ضبط

ورودی ها در هاب ها هرگز تغییر نکنید و نسخه ای نداشته باشید. از نظر ظاهری، هاب ها بسیار شبیه جداول ID-map هستند که در برخی از سیستم ها برای تولید جانشین استفاده می شوند، با این حال، توصیه می شود از یک دنباله عدد صحیح استفاده نکنید، بلکه از یک هش از مجموعه ای از کلیدهای تجاری به عنوان جانشین در Data Vault استفاده کنید. این رویکرد بارگذاری پیوندها و ویژگی‌ها را از منابع ساده می‌کند (نیازی به پیوستن به هاب برای دریافت جایگزین نیست، فقط هش را از کلید طبیعی محاسبه کنید)، اما می‌تواند مشکلات دیگری را ایجاد کند (مثلاً با برخورد، مورد و غیره). چاپ کاراکترها در کلیدهای رشته ای و غیره .p.)، بنابراین به طور کلی پذیرفته نمی شود.

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

توزیع ویژگی ها در بین ماهواره ها بر اساس اصل اتفاق می افتد تغییر مفصل - در یک ماهواره، ویژگی های بدون نسخه را می توان ذخیره کرد (به عنوان مثال، تاریخ تولد و SNILS برای یک فرد)، در دیگری - نسخه به ندرت تغییر می کند (به عنوان مثال، نام خانوادگی و شماره گذرنامه)، در سوم - به طور مکرر تغییر می کند. (به عنوان مثال آدرس تحویل، دسته بندی، تاریخ آخرین سفارش و غیره). نسخه‌سازی در این مورد در سطح ماهواره‌های جداگانه انجام می‌شود، و نه در کل موجودیت، بنابراین توصیه می‌شود ویژگی‌ها را به گونه‌ای توزیع کنید که تقاطع نسخه‌ها در یک ماهواره حداقل باشد (که تعداد کل را کاهش می‌دهد. از نسخه های ذخیره شده).

همچنین برای بهینه‌سازی فرآیند بارگذاری داده‌ها، ویژگی‌های به‌دست‌آمده از منابع مختلف اغلب در ماهواره‌های جداگانه قرار می‌گیرند.

ماهواره ها با هاب ارتباط برقرار می کنند کلید خارجی (که مربوط به کاردینالیته 1 به چند است). این بدان معنی است که چندین مقدار مشخصه (به عنوان مثال، چندین شماره تلفن تماس برای یک مشتری) توسط این معماری «پیش‌فرض» پشتیبانی می‌شود.

В مدل لنگر جداولی که کلیدها را ذخیره می کنند نامیده می شوند لنگرها. و نگه می دارند:

• فقط کلیدهای جانشین
• لینک به منبع
• زمان ضبط

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

برای مثال، اگر داده‌های مربوط به یک موجودیت یکسان می‌تواند از سیستم‌های متفاوتی به دست آید، که هر کدام از آنها از کلید طبیعی خود استفاده می‌کنند. در Data Vault، این می تواند منجر به ساخت و سازهای نسبتاً دست و پا گیر چندین هاب شود (یکی در هر منبع + نسخه اصلی ادغام)، در حالی که در مدل Anchor، کلید طبیعی هر منبع در ویژگی خاص خود قرار می گیرد و می تواند هنگام بارگذاری مستقل از آن استفاده شود. همه بقیه

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

В خزانه داده این قوانین احتمالاً تشکیل را تعیین می کنند "مرکز جانشین" موجودیت اصلی و به هیچ وجه بر هاب هایی که کلیدهای طبیعی منابع و ویژگی های اصلی آنها را ذخیره می کنند تأثیر نمی گذارد. اگر در نقطه‌ای قوانین ادغام تغییر کند (یا ویژگی‌هایی که برای ادغام استفاده می‌شوند به روز شوند)، برای تشکیل مجدد هاب‌های جایگزین کافی است.

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

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

مدل لنگر همچنین یک نوع شی اضافی به نام ارائه می دهد گره در واقع خاص است نوع منحط لنگر، که می تواند فقط یک ویژگی داشته باشد. گره ها قرار است برای ذخیره دایرکتوری های مسطح (به عنوان مثال، جنسیت، وضعیت تاهل، دسته خدمات مشتری و غیره) استفاده شوند. برخلاف Anchor، Knot هیچ جدول ویژگی مرتبطی ندارد، و تنها ویژگی آن (نام) همیشه در یک جدول با کلید ذخیره می شود. گره ها به همان روشی که لنگرها به یکدیگر متصل می شوند، توسط جداول کراواتی (Tie) به Anchors مرتبط می شوند.

هیچ نظر واضحی در مورد استفاده از Nodes وجود ندارد. مثلا، نیکولای گولوف، که به طور فعال استفاده از مدل لنگر را در روسیه ترویج می کند، معتقد است (نه بی دلیل) که نمی توان برای یک کتاب مرجع واحد گفت که او همیشه استاتیک و تک سطح خواهد بود، بنابراین بهتر است از یک Anchor تمام عیار برای همه اشیا به طور همزمان استفاده کنید.

یکی دیگر از تفاوت های مهم بین Data Vault و Anchor Model حضور است ویژگی های پیوندها:

В خزانه داده پیوندها همان اشیاء کامل Hub هستند و می توانند داشته باشند ویژگی های خوداست. به مدل لنگر پیوندها فقط برای اتصال Anchors و نمی توانند ویژگی های خاص خود را داشته باشند. این تفاوت منجر به رویکردهای مدل سازی به طور قابل توجهی متفاوت می شود. حقایق، که در ادامه به آن پرداخته خواهد شد.

ذخیره اطلاعات

تاکنون عمدتاً در مورد اندازه گیری های مدل سازی صحبت کرده ایم. حقایق کمی واضح تر هستند.

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

به نظر می رسد این رویکرد شهودی است. دسترسی آسان به شاخص های تجزیه و تحلیل شده را فراهم می کند و به طور کلی شبیه به یک جدول واقعی سنتی است (فقط شاخص ها در خود جدول ذخیره نمی شوند، بلکه در "جدول مجاور" ذخیره می شوند). اما مشکلاتی نیز وجود دارد: یکی از اصلاحات معمولی مدل - گسترش کلید واقعیت - آن را ضروری می کند. افزودن یک کلید خارجی جدید به لینک. و این، به نوبه خود، ماژولار بودن را "شکست" و به طور بالقوه باعث نیاز به بهبود سایر اشیاء می شود.

В مدل لنگر یک پیوند نمی تواند ویژگی های خاص خود را داشته باشد، بنابراین این رویکرد کار نخواهد کرد - مطلقاً همه ویژگی ها و شاخص ها باید به یک لنگر خاص مرتبط شوند. نتیجه گیری از این ساده است - هر واقعیت نیز به لنگر خود نیاز دارد. برای برخی از چیزهایی که ما عادت داریم آن را به عنوان واقعیت درک کنیم، این ممکن است طبیعی به نظر برسد - به عنوان مثال، واقعیت خرید کاملاً به موضوع "سفارش" یا "دریافت" کاهش می یابد، بازدید از یک سایت به یک جلسه کاهش می یابد و غیره. اما حقایقی نیز وجود دارد که یافتن چنین "شیء حامل" طبیعی برای آنها چندان آسان نیست - به عنوان مثال، تعادل کالا در انبارها در ابتدای هر روز.

بر این اساس، هنگام گسترش کلید واقعیت در مدل Anchor هیچ مشکلی با ماژولار وجود ندارد (فقط کافی است یک رابطه جدید به Anchor مربوطه اضافه کنید)، اما طراحی مدل برای نمایش حقایق کمتر ساده است، ممکن است Anchor های "مصنوعی" ظاهر شوند. که منعکس کننده مدل شی کسب و کار واضح نیست.

چگونه انعطاف به دست می آید

ساخت و ساز حاصل در هر دو مورد شامل جداول به طور قابل توجهی بیشترنسبت به اندازه گیری سنتی اما می تواند طول بکشد فضای دیسک به طور قابل توجهی کمتر است با همان مجموعه ای از ویژگی های نسخه شده به عنوان بعد سنتی. به طور طبیعی، هیچ جادویی در اینجا وجود ندارد - همه چیز در مورد عادی سازی است. با توزیع ویژگی ها در بین ماهواره ها (در Data Vault) یا جداول فردی (Anchor Model)، ما را کاهش می دهیم (یا کاملاً حذف می کنیم) کپی کردن مقادیر برخی از ویژگی ها هنگام تغییر برخی دیگر.

برای خزانه داده سود به توزیع ویژگی ها در بین ماهواره ها و برای مدل لنگر - تقریباً مستقیماً با میانگین تعداد نسخه ها در هر شی اندازه گیری متناسب است.

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

همچنین شبیه گذار از تولید قطعه به تولید انبوه است - اگر در رویکرد سنتی هر جدول مدل منحصر به فرد است و نیاز به توجه جداگانه دارد، در روش های انعطاف پذیر مجموعه ای از "جزئیات" معمولی است. از یک طرف، جداول بیشتری وجود دارد، فرآیندهای بارگیری و واکشی داده ها باید پیچیده تر به نظر برسند. از طرفی تبدیل می شوند معمول. این بدان معنی است که ممکن است وجود داشته باشد خودکار و مدیریت شده توسط ابرداده. سؤال "چگونه می خواهیم بسازیم؟"، که پاسخ آن می تواند بخش قابل توجهی از کار در مورد طراحی پیشرفت ها را اشغال کند، اکنون ارزش آن را ندارد (همانطور که سوال تأثیر تغییر مدل بر کار است. فرآیندها).

این بدان معنا نیست که تحلیلگران در چنین سیستمی اصلاً مورد نیاز نیستند - کسی هنوز باید مجموعه ای از اشیاء را با ویژگی ها کار کند و بفهمد که کجا و چگونه همه آنها را بارگیری کند. اما میزان کار و همچنین احتمال و هزینه خطا به میزان قابل توجهی کاهش می یابد. چه در مرحله تجزیه و تحلیل و چه در طول توسعه ETL، که در بخش قابل توجهی می توان به ویرایش ابرداده تقلیل داد.

طرف تاریکی

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

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

چندین واقعیت وجود دارد که این وضعیت را آسان تر می کند:

هنگام کار با ابعاد بزرگ، تقریباً تمام ویژگی های آن تقریباً هرگز به طور همزمان استفاده نمی شود. این بدان معنی است که ممکن است اتصالات کمتری نسبت به آنچه در نگاه اول در مدل به نظر می رسد وجود داشته باشد. در Data Vault، می‌توانید هنگام تخصیص ویژگی‌ها به ماهواره‌ها، فرکانس مورد انتظار اشتراک‌گذاری را نیز در نظر بگیرید. در عین حال، هاب ها یا لنگرها در درجه اول برای تولید و نقشه برداری جانشین ها در مرحله بارگذاری مورد نیاز هستند و به ندرت در پرس و جوها استفاده می شوند (این به ویژه در مورد Anchors صادق است).

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

به عنوان مثال، اینجا در این مقاله یک تست عملکرد مقایسه ای دقیق از مدل انکر با انتخاب از یک جدول وجود دارد.

خیلی به موتور بستگی دارد. بسیاری از پلتفرم های مدرن مکانیسم های داخلی برای بهینه سازی اتصال ها دارند. به عنوان مثال، MS SQL و Oracle می‌توانند در صورتی که داده‌های آنها در جایی به جز اتصال‌های دیگر استفاده نشود و بر انتخاب نهایی (حذف جدول/پیوستن) تأثیری نداشته باشد، پیوستن به جداول را «پرش» کنند، در حالی که MPP Vertica تجربه همکاران از Avito، با بهینه سازی دستی طرح پرس و جو، ثابت کرد که یک موتور عالی برای مدل Anchor است. از طرف دیگر، ذخیره سازی Anchor Model، به عنوان مثال، در خانه کلیک، که پشتیبانی محدودی برای join دارد، هنوز ایده خوبی به نظر نمی رسد.

علاوه بر این، برای هر دو معماری وجود دارد ترفندهای خاص، که دسترسی به داده ها را آسان تر می کند (هم از نظر عملکرد پرس و جو و هم برای کاربران نهایی). مثلا، جداول نقطه در زمان در Data Vault یا توابع ویژه جدول در مدل لنگر

در کل

ماهیت اصلی معماری های انعطاف پذیر در نظر گرفته شده، مدولار بودن "طراحی" آنها است.

این ویژگی اجازه می دهد:

• پس از آماده سازی اولیه مربوط به استقرار فراداده و نوشتن الگوریتم های پایه ETL، به سرعت اولین نتیجه را به مشتری ارائه دهید در قالب چند گزارش حاوی داده‌های تنها از چند شی منبع. برای این کار لازم نیست به طور کامل (حتی در سطح بالا) کل مدل شی را فکر کنید.
• یک مدل داده می تواند تنها با 2-3 شی شروع به کار (و مفید) کند و سپس به تدریج رشد کنند (در مورد مدل لنگر نیکولای کاربردی مقایسه زیبا با میسلیوم).
• اکثر پیشرفت ها، از جمله گسترش حوزه موضوعی و افزودن منابع جدید بر عملکرد موجود تأثیر نمی گذارد و خطر شکستن چیزی را که قبلاً کار می کند ایجاد نمی کند.
• به لطف تجزیه به عناصر استاندارد، فرآیندهای ETL در چنین سیستم‌هایی یکسان به نظر می‌رسند، نوشتن آنها خود را به الگوریتم‌سازی وامی دارد و در نهایت، اتوماسیون.

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

نرم افزار

انواع موجودیت خزانه داده

اطلاعات بیشتر در مورد Data Vault:
وب سایت Dan Listadt
همه چیز درباره Data Vault به زبان روسی
درباره Data Vault در Habré

انواع موجودیت مدل لنگر

اطلاعات بیشتر در مورد مدل لنگر:

سایت سازندگان مدل Anchor
مقاله ای در مورد تجربه پیاده سازی انکر مدل در آویتو

جدول خلاصه با ویژگی های مشترک و تفاوت بین رویکردهای در نظر گرفته شده:

منبع: www.habr.com