يعتمد الكثير في حياة المشروع على مدى التفكير الجيد في نموذج الكائن وهيكل القاعدة في البداية.
كان النهج المقبول عمومًا ولا يزال خيارات متنوعة للجمع بين مخطط "النجم" والشكل العادي الثالث. كقاعدة عامة ، وفقًا للمبدأ: البيانات الأولية - 3NF ، المعارض - النجوم. هذا النهج الذي تم اختباره على مدار الوقت ، والمدعوم بالكثير من الأبحاث ، هو الشيء الأول (وأحيانًا الوحيد) الذي يفكر فيه شخص DWH ذو الخبرة عند التفكير في الشكل الذي يجب أن يبدو عليه المستودع التحليلي.
من ناحية أخرى ، تميل الأعمال بشكل عام ومتطلبات العملاء بشكل خاص إلى التغيير بسرعة ، وتنمو البيانات "في العمق" و "الاتساع". وهنا يتجلى العيب الرئيسي للنجم - المرونة المحدودة .
وإذا كنت في حياتك الهادئة والمريحة كمطور DWH ، فجأة:
- نشأت المهمة "القيام بشيء ما على الأقل بسرعة ، وبعد ذلك سنرى" ؛
- ظهر مشروع سريع التطور ، مع ربط مصادر جديدة وإعادة صياغة نموذج الأعمال مرة واحدة على الأقل في الأسبوع ؛
- ظهر عميل لا يتخيل كيف يجب أن يبدو النظام والوظائف التي يجب أن يؤديها في النهاية ، ولكنه جاهز للتجارب والتحسين المتسق للنتيجة المرجوة من خلال نهج متسق لها ؛
- تحدث مدير المشروع عن الأخبار السارة: "والآن لدينا مرونة!"
أو إذا كنت مهتمًا فقط بمعرفة كيف يمكنك بناء التخزين - مرحبًا بك تحت القط!
ماذا تعني المرونة؟
أولاً ، دعنا نحدد الخصائص التي يجب أن يمتلكها النظام حتى يطلق عليه اسم "مرن".
بشكل منفصل ، تجدر الإشارة إلى أن الخصائص الموصوفة يجب أن تتعلق على وجه التحديد بالنظام ، وليس بعملية تطويره. لذلك ، إذا أردت أن تقرأ عن Agile كمنهجية للتطوير ، فمن الأفضل قراءة مقالات أخرى. على سبيل المثال، هناك حق، على حبري، وهناك الكثير من المواد المثيرة للاهتمام (سواء مسح و العملية ، و إشكالية ).
هذا لا يعني أن عملية التطوير وهيكل القرص المضغوط غير مترابطين على الإطلاق. بشكل عام ، يجب أن يكون من الأسهل بكثير تطوير التخزين السريع للهندسة المعمارية المرنة. ومع ذلك ، من الناحية العملية ، هناك المزيد من الخيارات مع تطوير Agile لـ DWH الكلاسيكي بواسطة Kimball و DataVault بواسطة الشلال أكثر من المصادفات السعيدة للمرونة في أقنومها في مشروع واحد.
إذن ، ما هي القدرات التي يجب أن يتمتع بها التخزين المرن؟ هناك ثلاث نقاط هنا:
- يعني التسليم المبكر والمتابعة السريعة أنه من الناحية المثالية ، يجب استلام أول نتيجة عمل (على سبيل المثال ، تقارير العمل الأولى) في أقرب وقت ممكن ، أي حتى قبل تصميم النظام بأكمله وتنفيذه بالكامل. علاوة على ذلك ، يجب أن تستغرق كل مراجعة لاحقة أقل وقت ممكن.
- — , . — , , . , , — .
- التكيف المستمر مع متطلبات العمل المتغيرة - يجب تصميم الهيكل العام للكائن ليس فقط مع الأخذ في الاعتبار التوسع المحتمل ، ولكن مع توقع أن اتجاه هذا التوسع القادم قد لا يحلم بك حتى في مرحلة التصميم.
ونعم ، من الممكن تلبية كل هذه المتطلبات في نظام واحد (بالطبع ، في حالات معينة ومع بعض المحاذير).
أدناه ، سأفكر في اثنتين من أكثر منهجيات التصميم الرشيق شيوعًا لنموذج HD - Anchor و Data Vault.... خلف الأقواس توجد تقنيات ممتازة مثل EAV و 6NF (في شكلها النقي) وكل ما يتعلق بحلول NoSQL - ليس لأنها أسوأ إلى حد ما ، ولا حتى لأن المقالة في هذه الحالة قد تهدد بالحصول على الحجم المتوسط الاختلاف. كل هذا يشير فقط إلى حلول من فئة مختلفة قليلاً - إما إلى التقنيات التي يمكنك تطبيقها في حالات محددة ، بغض النظر عن البنية العامة لمشروعك (مثل EAV) ، أو إلى نماذج أخرى عالمية لتخزين المعلومات (مثل قواعد بيانات الرسم البياني وخيارات أخرى NoSQL).
مشاكل المنهج "الكلاسيكي" وحلولها في المنهجيات الرشيقة
أعني بالمقاربة "الكلاسيكية" النجمة القديمة الجيدة (بغض النظر عن التطبيق المحدد للطبقات الأساسية ، قد يغفر لي أتباع Kimball و Inmon و CDM).
1. أصلب جامد العلاقات
ويستند هذا النموذج على فصل واضح من البيانات في الأبعاد (البعد) و قائع (الحقائق) . وهذا أمر منطقي - بعد كل شيء ، فإن تحليل البيانات في الغالبية العظمى من الحالات ينحصر في مجرد تحليل بعض المؤشرات الرقمية (الحقائق) في أقسام معينة (أبعاد).
في هذه الحالة ، يتم وضع الروابط بين الكائنات في شكل روابط بين الجداول بواسطة مفتاح خارجي. يبدو هذا طبيعيًا تمامًا ، لكنه يؤدي على الفور إلى الحد الأول من المرونة - تعريف صارم للعناصر الأساسية للاتصالات .
هذا يعني أنه في مرحلة تصميم الجداول ، يجب أن تحدد بدقة لكل زوج من الكائنات ذات الصلة ما إذا كان من الممكن أن تكون متعدد إلى متعدد ، أو واحد إلى متعدد ، و "في أي اتجاه". يعتمد ذلك بشكل مباشر على أي من الجداول سيكون له مفتاح أساسي وأيها سيكون له مفتاح خارجي. سيؤدي تغيير هذا الموقف عند تلقي متطلبات جديدة على الأرجح إلى إعادة تصميم القاعدة.
على سبيل المثال ، أثناء تصميم كائن "شيك أمين الصندوق" ، حددت ، بالاعتماد على قسم قسم المبيعات ، إمكانية ترويج واحد يعمل على عدة مراكز شيك (ولكن ليس العكس):
وبعد فترة ، قدم الزملاء إستراتيجية تسويق جديدة ، حيث يمكن أن تعمل العديد من العروض الترويجية في نفس الوقت في نفس الموقف . والآن أنت بحاجة إلى تعديل الجداول عن طريق تحديد الارتباط في كائن منفصل.
(جميع العناصر المشتقة ، التي يحدث فيها فحص ترويجي ، تحتاج الآن أيضًا إلى التحسين).
الروابط الموجودة في Data Vault and Anchor Model
اتضح أنه من السهل جدًا تجنب مثل هذا الموقف:
تم اقتراح هذا النهج بواسطة Dan Linstedt كجزء من نموذج Data Vault وهو مدعوم بالكامل من قبل Lars Rönnbäck في Anchor Model .
نتيجة لذلك ، نحصل على السمة المميزة الأولى لمنهجيات أجايل:
لا يتم تخزين العلاقات بين الكائنات في سمات الكيانات الرئيسية ، ولكنها نوع منفصل من الكائنات.و المدفن البيانات هي الجدول الرباط دعا لينك ، و نماذج مرساة - على التعادل . للوهلة الأولى ، فهي متشابهة جدًا ، على الرغم من أن اختلافاتهم لا تقتصر على الاسم (الذي سيتم مناقشته أدناه). في كلا البنيتين ، يمكن لجداول الارتباط ربط أي عدد من الكيانات (ليس بالضرورة 2).
للوهلة الأولى ، يوفر هذا التكرار مرونة كبيرة لإجراء التعديلات. يصبح مثل هذا الهيكل متسامحًا ليس فقط لتغيير العلاقة الأساسية للروابط الحالية ، ولكن أيضًا لإضافة روابط جديدة - إذا كان مركز الشيك الآن يحتوي أيضًا على رابط إلى أمين الصندوق الذي قام بلكمه ، فإن ظهور مثل هذا الارتباط سيصبح ببساطة إضافة على الجداول الموجودة دون التأثير على أي كائنات موجودة و العمليات.
2. تكرار البيانات
المشكلة الثانية ، التي تم حلها بواسطة البنى المرنة ، أقل وضوحًا وهي متأصلة بشكل أساسي في قياسات النوع SCD2 (أبعاد متغيرة ببطء من النوع الثاني) ، على الرغم من أنها ليست فقط بالنسبة لهم.
في التخزين الكلاسيكي ، يكون البعد عادةً عبارة عن جدول يحتوي على مفتاح بديل (مثل PK) ومجموعة من مفاتيح العمل والسمات في أعمدة منفصلة.
إذا تم تعيين إصدار للبعد ، تتم إضافة حدود وقت الإصدار إلى مجموعة الحقول القياسية ، وتظهر إصدارات متعددة لكل سطر في المصدر في المخزن (إصدار واحد لكل تغيير في سمات الإصدار).
إذا كان أحد الأبعاد يحتوي على سمة واحدة على الأقل يتم تغييرها بشكل متكرر ، فسيكون عدد إصدارات هذا البعد مثيرًا للإعجاب (حتى إذا لم يتم إصدار السمات الأخرى ، أو لم تتغير أبدًا) ، وإذا كان هناك العديد من هذه السمات ، يمكن أن ينمو عدد الإصدارات بشكل كبير من عددها. يمكن أن يشغل هذا البعد قدرًا كبيرًا من مساحة القرص ، على الرغم من أن معظم البيانات المخزنة فيه هي مجرد قيم مكررة لسمات غير متغيرة من صفوف أخرى.
وفي الوقت نفسه، denormalization هو أيضا كثيرا ما تستخدم - يتم تخزين بعض من سمات عمدا كقيمة، وليس إشارة إلى دليل أو بعدا آخر. يعمل هذا الأسلوب على تسريع الوصول إلى البيانات عن طريق تقليل عدد الصلات عند الوصول إلى بُعد.
كقاعدة عامة ، هذا يؤدي إلى حقيقة أنيتم تخزين نفس المعلومات في وقت واحد في عدة أماكن . على سبيل المثال ، يمكن تخزين المعلومات حول منطقة الإقامة والانتماء إلى فئة العميل في نفس الوقت في الأبعاد "العميل" والحقائق "الشراء" و "التسليم" و "المكالمات إلى مركز الاتصال" ، وكذلك في جدول الربط "العميل - مدير العملاء".
بشكل عام ، ينطبق ما سبق على القياسات العادية (غير ذات الإصدارات) ، ولكن في القياسات ذات الإصدارات يمكن أن يكون لها مقياس مختلف: ظهور نسخة جديدة من كائن (خاصة في الإدراك المتأخر) لا يؤدي فقط إلى تحديث جميع الجداول ذات الصلة ، ولكن إلى الظهور المتتالي للإصدارات الجديدة من الكائنات ذات الصلة - عند استخدام الجدول 1 لإنشاء الجدول 2 ، واستخدام الجدول 2 لإنشاء الجدول 3 ، إلخ. حتى إذا لم تشارك أي من سمات الجدول 1 في إنشاء الجدول 3 (وتم تضمين السمات الأخرى للجدول 2 التي تم الحصول عليها من مصادر أخرى) ، فإن تحديث إصدار هذا البناء سيؤدي على الأقل إلى تكاليف عامة إضافية ، وعلى الأكثر - إلى إصدارات غير ضرورية في الجدول 3. التي لا علاقة لها بها وعلى طول السلسلة.
3. التعقيد غير الخطي للمراجعة
بالإضافة إلى ذلك ، فإن كل سوق جديد ، مبني فوق سوق آخر ، يزيد من عدد الأماكن التي يمكن أن "تتباعد" فيها البيانات عند إجراء تغييرات على ETL. وهذا بدوره يؤدي إلى زيادة تعقيد (ومدة) كل مراجعة لاحقة.
إذا كان ما سبق يتعلق بالأنظمة ذات عمليات ETL التي نادرًا ما يتم تعديلها ، فيمكنك العيش في مثل هذا النموذج - ما عليك سوى التأكد من إدخال التعديلات الجديدة بشكل صحيح في جميع الكائنات ذات الصلة. إذا تكررت المراجعات ، فإن احتمال "فقدان" بعض الروابط عن طريق الخطأ يزيد بشكل ملحوظ.
بالإضافة إلى ذلك ، إذا أخذنا في الحسبان أن ETL "المُصوَّر" أكثر تعقيدًا من "بدون إصدار" ، يصبح من الصعب جدًا تجنب الأخطاء مع المراجعة المتكررة لهذا الاقتصاد بأكمله.
تخزين الكائنات والسمات في Data Vault و Anchor Model
يمكن صياغة النهج الذي اقترحه مؤلفو البنى الرشيقة على النحو التالي:
من الضروري فصل ما يتغير عما لم يتغير. أي ، احتفظ بالمفاتيح منفصلة عن السمات.في الوقت نفسه ، يجب ألا تخلط بين سمة غير ذات إصدار وسمة غير متغيرة : فالأولى لا تخزن محفوظات تغييرها ، ولكن يمكن أن تتغير (على سبيل المثال ، عند تصحيح خطأ إدخال أو تلقي بيانات جديدة) ؛ الثانية لا تتغير أبدًا.
تختلف وجهات النظر حول ما يمكن اعتباره بالضبط غير قابل للتغيير في Data Vault و Anchor Model.
من وجهة نظر بنية Data Vault ، يمكن اعتبار مجموعة المفاتيح بأكملها دون تغيير - طبيعية (رقم تعريف دافع الضرائب للمؤسسة ، ورمز المنتج في النظام المصدر ، وما إلى ذلك) ومبدئًا. في هذه الحالة ، يمكن تقسيم السمات المتبقية إلى مجموعات حسب المصدر و / أو تكرار التغييرات ، ويمكن الاحتفاظ بجدول منفصل مع مجموعة مستقلة من الإصدارات لكل مجموعة .
في النموذجيعتبر نموذج المرساة مفتاح بديل للكيان غير قابل للتغيير . كل شيء آخر (بما في ذلك المفاتيح الطبيعية) هو مجرد حالة خاصة لسماته. في الوقت نفسه ، تكون جميع السمات بشكل افتراضي مستقلة عن بعضها البعض ، لذلك ، يجب إنشاء جدول منفصل لكل سمة .
في Data Vault ، يُطلق على الجداول التي تحتوي على مفاتيح الكيانات اسم المحاور . تحتوي المحاور دائمًا على مجموعة ثابتة من الحقول:
- مفاتيح الكيان الطبيعية
- مفتاح بديل
- ارتباط بالمصدر
- سجل وقت الإضافة
لا يتم تغيير الإدخالات في Hubs مطلقًا وليس لها إصدار . ظاهريًا ، المحاور تشبه إلى حد كبير جداول نوع خريطة المعرف المستخدمة في بعض الأنظمة لإنشاء بدائل ، ومع ذلك ، يوصى بعدم استخدام تسلسل عدد صحيح كبديل في Data Vault ، ولكن تجزئة من مجموعة من مفاتيح الأعمال. يعمل هذا الأسلوب على تبسيط تحميل الروابط والسمات من المصادر (لا تحتاج إلى الانضمام إلى لوحة الوصل للحصول على بديل ، فأنت تحتاج فقط إلى حساب التجزئة من المفتاح الطبيعي) ، ولكن يمكن أن تتسبب في مشاكل أخرى (تتعلق ، على سبيل المثال ، بالتصادمات والحالة والأحرف غير القابلة للطباعة في مفاتيح السلسلة ، وما إلى ذلك) .p.) ، لذلك فهو غير مقبول بشكل عام.
يتم تخزين جميع سمات الكيانات الأخرى في جداول خاصة تسمى الأقمار الصناعية... يمكن أن يحتوي المحور الواحد على عدة أقمار صناعية تخزن مجموعات مختلفة من السمات.
يعتمد توزيع السمات بواسطة الأقمار الصناعية على مبدأ التغيير المشترك - يمكن لقمر صناعي واحد تخزين سمات غير ذات إصدار (على سبيل المثال ، تاريخ الميلاد و SNILS للفرد) ، في الآخر - نادرًا ما يتم تغيير الإصدارات (على سبيل المثال ، الاسم الأخير ورقم جواز السفر) ، في الثالث - غالبًا التغيير (على سبيل المثال ، عنوان التسليم ، والفئة ، وتاريخ آخر طلب ، وما إلى ذلك). في هذه الحالة ، يتم تنفيذ الإصدار على مستوى الأقمار الصناعية الفردية ، وليس على مستوى الكيان ككل ؛ لذلك ، يُنصح بتوزيع السمات بحيث يكون تقاطع الإصدارات داخل قمر صناعي واحد في حده الأدنى (مما يقلل من العدد الإجمالي للإصدارات المخزنة).
أيضًا ، من أجل تحسين عملية تحميل البيانات ، غالبًا ما يتم وضع السمات التي تم الحصول عليها من مصادر مختلفة في سواتل منفصلة.
تتواصل الأقمار الصناعية مع Hub باستخدام مفتاح خارجي (يتوافق مع عدد من أصل واحد إلى متعدد). وهذا يعني أن قيم السمات المتعددة (على سبيل المثال ، أرقام هواتف جهات اتصال متعددة لعميل واحد) تدعمها هذه البنية "الافتراضية".
في Anchor Model ، تسمى الجداول التي تحتوي على مفاتيح Anchor . ويحتفظون بما يلي:
- مفاتيح بديلة فقط
- ارتباط بالمصدر
- سجل وقت الإضافة
تعتبر المفاتيح الطبيعية سمات عادية من وجهة نظر نموذج المرساة . قد يبدو هذا الخيار أكثر صعوبة في الفهم ، لكنه يعطي مساحة أكبر بكثير لتعريف الكائن.
على سبيل المثال ، إذا كانت البيانات حول نفس الكيان يمكن أن تأتي من أنظمة مختلفة ، يستخدم كل منها مفتاحه الطبيعي. في Data Vault ، يمكن أن يؤدي ذلك إلى هياكل مرهقة إلى حد ما لعدة محاور (واحد لكل مصدر + الإصدار الرئيسي الموحد) ، بينما في نموذج Anchor ، يقع المفتاح الطبيعي لكل مصدر في السمة الخاصة به ويمكن استخدامه أثناء التحميل بشكل مستقل عن جميع المحاور الأخرى.
ولكن هناك نقطة ماكرة واحدة هنا: إذا تم دمج سمات من أنظمة مختلفة في كيان واحد ، فمن المرجح أن يكون هناك بعضقواعد "الإلتصاق" ، والتي بموجبها يجب أن يفهم النظام أن السجلات من مصادر مختلفة تتوافق مع مثيل واحد للكيان.
في Data Vault ، ستحدد هذه القواعد على الأرجح تشكيل "المحور البديل" للكيان الرئيسي ولن تؤثر بأي شكل من الأشكال على المحاور التي تخزن المفاتيح الطبيعية للمصادر وخصائصها الأصلية. إذا تغيرت قواعد الربط في وقت ما (أو تحديث للسمات التي يتم من خلالها) ، فسيكون ذلك كافيًا لإعادة تشكيل المحاور البديلة.
في نموذج الارتساء ، من المرجح أن يتم تخزين مثل هذا الكيان في نقطة ارتساء واحدة.... هذا يعني أن جميع السمات ، بغض النظر عن المصدر الذي أتت منه ، ستكون مرتبطة بنفس العنصر البديل. يمكن أن يكون فصل السجلات المدمجة بشكل خاطئ ، وبشكل عام ، تتبع أهمية الدمج في مثل هذا النظام أكثر صعوبة ، خاصةً إذا كانت القواعد معقدة بما يكفي وغالبًا ما تتغير ، ويمكن الحصول على نفس السمة من مصادر مختلفة (على الرغم من أنه ممكن بالتأكيد ، لأن كل نسخة السمة تحتفظ برابط لمصدرها).
في أي حال ، إذا كان من المفترض أن يقوم نظامك بتنفيذ وظيفة إلغاء البيانات المكررة ودمج السجلات وعناصر MDM الأخرى، يجدر إلقاء نظرة فاحصة على جوانب تخزين المفاتيح الطبيعية في منهجيات رشيقة. من المحتمل أن يثبت تصميم Data Vault الأكثر تعقيدًا أنه أكثر أمانًا فجأة من حيث أخطاء الدمج.
يوفر نموذج الارتساء أيضًا نوعًا إضافيًا من الكائن يسمى العقدة ، وهو في الواقع نوع خاص من الارتساء يمكن أن يحتوي على سمة واحدة فقط. من المفترض استخدام العقد لتخزين الأدلة المسطحة (على سبيل المثال ، الجنس ، الحالة الاجتماعية ، فئة خدمة العملاء ، إلخ). على عكس Anchor ، لا يوجد لدى Node جداول سمات مرتبطة، ويتم تخزين السمة الوحيدة (الاسم) دائمًا في نفس الجدول باستخدام المفتاح. ترتبط العقد بـ Anchors بواسطة جداول Tie ، تمامًا مثل المراسي مع بعضها البعض.
لا يوجد رأي لا لبس فيه حول استخدام العقد. على سبيل المثال ، يعتقد نيكولاي جولوف ، الذي يروج بنشاط لاستخدام نموذج Anchor في روسيا (ليس بشكل غير معقول) أنه لا يوجد كتاب مرجعي من المستحيل أن نقول على وجه اليقين أنه سيكون دائمًا ثابتًا ومستوى واحدًا ، لذلك من الأفضل استخدام مرساة كاملة لجميع الكائنات في وقت واحد.
هناك اختلاف مهم آخر بين Data Vault ونموذج Anchor وهو وجود سمات للروابط :
في Data Vault ، تعتبر الروابط هي نفس الكائنات الكاملة مثل Hubs ، ويمكن أن تحتوي علىالسمات الخاصة . في نموذج Anchor ، تُستخدم الروابط فقط لتوصيل Anchors ولا يمكن أن يكون لها سماتها الخاصة . يعطي هذا الاختلاف مناهج مختلفة بشكل كبير لنمذجة الحقائق ، والتي ستتم مناقشتها أدناه.
تخزين الحقائق
قبل ذلك ، تحدثنا بشكل أساسي عن قياسات النمذجة. مع الحقائق ، فإن الوضع أقل وضوحًا.
في Data Vault ، الكائن النموذجي لتخزين الحقائق هو الارتباط ، في الأقمار الصناعية التي تُضاف إليها مؤشرات حقيقية.
هذا النهج يبدو بديهيًا. إنه يوفر وصولاً سهلاً إلى المؤشرات التي تم تحليلها وهو مشابه بشكل عام لجدول الحقائق التقليدي (يتم تخزين المؤشرات فقط ليس في الجدول نفسه ، ولكن في "المجاور"). ولكن هناك أيضًا عيوب: أحد تعديلات النموذج النموذجية - توسيع مفتاح الحقائق - يستلزم إضافة مفتاح خارجي جديد إلى Link . وهذا بدوره "يكسر" النمطية ويسبب على الأرجح الحاجة إلى تحسين الكائنات الأخرى.
في نموذج المرساةلا يمكن أن يكون للرابط سماته الخاصة ، لذلك لن يعمل هذا النهج - يجب أن تكون جميع السمات والمؤشرات مرتبطة تمامًا بمرساة واحدة محددة. الاستنتاج من هذا بسيط - كل حقيقة تحتاج أيضًا إلى مرساة خاصة بها . بالنسبة لبعض ما اعتدنا على اعتباره حقائق ، قد يبدو الأمر طبيعيًا - على سبيل المثال ، يتم تقليل حقيقة الشراء تمامًا إلى عنصر "أمر" أو "تحقق" ، أو زيارة موقع - إلى جلسة ، وما إلى ذلك. ولكن هناك أيضًا حقائق ليس من السهل العثور عليها مثل هذا "الجسم الناقل" الطبيعي - على سبيل المثال ، بقايا البضائع في المستودعات في بداية كل يوم.
وفقًا لذلك ، لا توجد مشاكل مع النمطية عند توسيع مفتاح الحقائق في نموذج المرساة (تحتاج فقط إلى إضافة رابط جديد إلى المرساة المقابلة) ، ولكن تصميم النموذج لعرض الحقائق أقل وضوحًا ، وقد تظهر المراسي "الاصطناعية" التي تعكس نموذج كائن العمل غير واضح.
كيف تتحقق المرونة
يحتوي البناء الناتج في كلتا الحالتين على جداول أكثر بكثير من البعد التقليدي. ولكن يمكن أن تشغل مساحة أقل بكثير على القرص بنفس مجموعة سمات الإصدار مثل البعد التقليدي. بطبيعة الحال ، لا يوجد سحر هنا - الأمر كله يتعلق بالتطبيع. من خلال توزيع السمات عبر الأقمار الصناعية (في Data Vault) أو جداول منفصلة (Anchor Model) ، فإننا نحد من تكرار قيم بعض السمات (أو نزيلها تمامًا) عند تغيير أخرى .
بالنسبة لمخزن البيانات ، سيعتمد الكسب على توزيع السمات عبر الأقمار الصناعية ، وبالنسبة لنموذج المرساة ، سيكون متناسبًا تقريبًا مع متوسط عدد الإصدارات لكل كائن قياس.
ومع ذلك ، يعد اكتساب المساحة ميزة مهمة ولكنها ليست الميزة الرئيسية لتخزين السمات بشكل منفصل. بالإضافة إلى تخزين الروابط بشكل منفصل ، فإن هذا الأسلوب يجعل المستودع تصميمًا معياريًا . هذا يعني أن إضافة كل من السمات الفردية ومناطق الموضوعات الجديدة بالكامل في مثل هذا النموذج تبدو كإضافة على مجموعة موجودة من الكائنات دون تغييرها. وهذا بالضبط ما يجعل المنهجيات الموصوفة مرنة.
كما أنه يشبه الانتقال من الإنتاج الجزئي إلى الإنتاج الضخم - إذا كان كل جدول نموذج في النهج التقليدي فريدًا ويتطلب اهتمامًا منفصلاً ، فإنه في المنهجيات المرنة يكون بالفعل مجموعة من "التفاصيل" النموذجية. من ناحية أخرى ، هناك المزيد من الجداول ، يجب أن تبدو عمليات تحميل البيانات وجلبها أكثر تعقيدًا. من ناحية أخرى ، أصبحت نموذجية . هذا يعني أنه يمكن تشغيلها آليًا وإدارتها بواسطة البيانات الوصفية . السؤال "كيف سنضعه؟" ، الإجابة التي يمكن أن تأخذ جزءًا مهمًا من العمل على تصميم التحسينات ، لا تستحق العناء الآن (بالإضافة إلى مسألة تأثير تغييرات النموذج على عمليات العمل).
هذا لا يعني أنه ليس هناك حاجة للمحللين في مثل هذا النظام على الإطلاق - لا يزال يتعين على شخص ما العمل من خلال مجموعة من الكائنات ذات السمات ومعرفة مكان وكيفية تحميل كل هذا. لكن مقدار العمل ، وكذلك احتمالية الخطأ وتكلفته ، تقل بشكل كبير. في كل من مرحلة التحليل وأثناء تطوير ETL ، والتي يمكن في جزء أساسي تحويلها إلى تحرير البيانات الوصفية.
الجانب المظلم
كل ما سبق يجعل كلا النهجين مرنين حقًا ومتقدمين تقنيًا ومناسبين للتنقيح التكراري. بالطبع ، هناك أيضًا "برميل مرهم" ، والذي أعتقد أنك تخمنه بالفعل.
يؤدي تحلل البيانات ، الذي يكمن وراء نمطية البنى المرنة ، إلى زيادة عدد الجداول ، وبالتالي ، زيادة عدد الوصلات عند الجلب. من أجل الحصول على جميع سمات البعد ببساطة ، يكون التحديد واحدًا كافيًا في المستودع الكلاسيكي ، وستتطلب البنية المرنة عددًا من الصلات. علاوة على ذلك ، إذا كان من الممكن كتابة كل هذه الصلات مسبقًا للتقارير ، فإن المحللين الذين اعتادوا كتابة SQL يدويًا سيعانون بشكل مضاعف.
هناك عدة حقائق تجعل هذا الوضع أسهل:
عند العمل بأبعاد كبيرة ، لا يتم استخدام جميع سماته تقريبًا في نفس الوقت. هذا يعني أنه قد يكون هناك عدد أقل من الصلات مما يبدو عند إلقاء نظرة على النموذج لأول مرة. في مخزن البيانات ، يمكنك أيضًا مراعاة معدل تكرار المشاركة المقدر عند توزيع السمات عبر الأقمار الصناعية. في الوقت نفسه ، هناك حاجة إلى المحاور أو المراسي نفسها بشكل أساسي لتوليد البدائل ورسم خرائطها في مرحلة التحميل ونادرًا ما يتم استخدامها في الطلبات (خاصة بالنسبة إلى المراسي).
جميع الصلات بالمفتاح.بالإضافة إلى ذلك ، فإن الطريقة الأكثر "إيجازًا" لتخزين البيانات تقلل من عبء جداول المسح عند الضرورة (على سبيل المثال ، عند التصفية حسب قيمة السمة). يمكن أن يؤدي هذا إلى حقيقة أن الجلب من قاعدة بيانات موحدة مع مجموعة من الصلات سيكون أسرع من مسح بُعد واحد ثقيل مع العديد من الإصدارات في كل سطر.
على سبيل المثال ، يوجد هنا في هذه المقالة اختبار أداء مقارن مفصل لنموذج المرساة مع تحديد من جدول واحد.
يعتمد الكثير على المحرك. العديد من المنصات الحديثة لديها آليات داخلية لتحسين الانضمام. على سبيل المثال ، يمكن لـ MS SQL و Oracle "تخطي" عمليات الانضمام إلى الجداول إذا لم يتم استخدام بياناتها في أي مكان باستثناء الصلات الأخرى ولا تؤثر على التحديد النهائي (حذف الجدول / الانضمام) ، بينما يكون MPP Verticaأثبتت خبرة الزملاء من Avito أنها محرك ممتاز لنموذج Anchor ، مع مراعاة بعض التحسينات اليدوية لخطة الاستعلام. من ناحية أخرى ، لا يبدو الاحتفاظ بنموذج المرساة ، على سبيل المثال ، في Click House ، الذي يحتوي على دعم الانضمام المحدود ، فكرة جيدة في الوقت الحالي.
بالإضافة إلى ذلك ، هناك تقنيات خاصة لكل من البنيتين لتسهيل الوصول إلى البيانات (سواء من منظور أداء الاستعلام أو للمستخدمين النهائيين). على سبيل المثال ، جداول Point-In-Time في Data Vault أو وظائف جدول خاص في نموذج Anchor.
مجموع
الجوهر الرئيسي للبنى المرنة المدروسة هو نمطية "تصميمها".
هذه الخاصية هي التي تسمح بما يلي:
- , ETL, , . ( ) .
- ( ) 2-3 , ( ).
- , - .
- بسبب التحلل إلى عناصر قياسية ، تبدو عمليات ETL في مثل هذه الأنظمة من نفس النوع ، وكتابتها تفسح المجال للخوارزمية ، وفي النهاية ، الأتمتة .
ثمن هذه المرونة هو الأداء . هذا لا يعني أنه من المستحيل تحقيق أداء مقبول في مثل هذه النماذج. في أغلب الأحيان ، تحتاج فقط إلى مزيد من الجهد والاهتمام بالتفاصيل لتحقيق المقاييس التي تريدها.
التطبيقات
أنواع كيانات مخزن البيانات
اقرأ المزيد حول Data Vault:
موقع Dan Listadt
كل شيء عن Data Vault باللغة الروسية
حول Data Vault على Habré
أنواع كيانات نموذج المرساة
مزيد من المعلومات حول Anchor Model:
Site of Anchor Model
Creators مقال حول تجربة تطبيق نموذج المرساة في Avito
جدول ملخص مع الميزات المشتركة والاختلافات في الأساليب المدروسة:
