تطوير التخزين هو عمل طويل وخطير.
يعتمد الكثير في حياة المشروع على مدى جودة التفكير في نموذج الكائن والهيكل الأساسي في البداية.
كان النهج المقبول عمومًا ولا يزال مجموعات مختلفة من المخطط النجمي مع الشكل العادي الثالث. كقاعدة عامة ، وفقًا للمبدأ: البيانات الأولية - 3NF ، يعرض - نجم. هذا النهج ، الذي تم اختباره على مدار الوقت ومدعومًا بالعديد من الأبحاث ، هو الشيء الأول (وأحيانًا الوحيد) الذي يتبادر إلى الذهن بالنسبة لأخصائي DWH ذي الخبرة عند التفكير في الشكل الذي يجب أن يبدو عليه المستودع التحليلي.
من ناحية أخرى ، تميل الأعمال بشكل عام ومتطلبات العملاء على وجه الخصوص إلى التغيير بسرعة ، بينما تنمو البيانات "في العمق" و "الاتساع". وهنا يظهر العيب الرئيسي للنجم - محدود مرونة.
وإذا كنت في حياتك الهادئة والمريحة فجأة كمطور DWH:
- نشأت المهمة "القيام بشيء ما على الأقل بسرعة ، وبعد ذلك سنرى" ؛
- ظهر مشروع سريع التطور ، مع ربط مصادر جديدة وتغيير نموذج العمل مرة واحدة على الأقل في الأسبوع ؛
- ظهر عميل ليس لديه فكرة عن الشكل الذي يجب أن يبدو عليه النظام والوظائف التي يجب أن يؤديها في النهاية ، ولكنه جاهز للتجارب والتحسين المتسق للنتيجة المرجوة من خلال نهج متسق لها ؛
- نظر مدير المشروع إلى الأخبار السارة: "والآن لدينا مرونة!".
أو إذا كنت مهتمًا فقط بمعرفة كيف يمكنك بناء التخزين - مرحبًا بك في القط!
ماذا تعني "المرونة"؟
بادئ ذي بدء ، دعنا نحدد الخصائص التي يجب أن يمتلكها النظام حتى يطلق عليه اسم "مرن".
بشكل منفصل ، من الجدير بالذكر أن الخصائص الموصوفة يجب أن تشير على وجه التحديد النظاملا عملية تطوره. لذلك ، إذا أردت أن تقرأ عن Agile كمنهجية للتطوير ، فمن الأفضل قراءة مقالات أخرى. على سبيل المثال ، هناك ، في حبري ، هناك الكثير من المواد المثيرة للاهتمام (مثل и و ).
هذا لا يعني أن عملية التطوير وهيكل مستودع البيانات غير مرتبطين تمامًا. بشكل عام ، يجب أن يكون التطوير السريع لوحدة التخزين الرشيقة أسهل بكثير. ومع ذلك ، من الناحية العملية ، هناك المزيد من الخيارات مع تطوير Agile لـ DWH الكلاسيكي وفقًا لـ Kimbal و DataVault - وفقًا للشلال أكثر من المصادفات السعيدة للمرونة في شكليها في مشروع واحد.
إذن ، ما هي الميزات التي يجب أن تتوفر في التخزين المرن؟ هناك ثلاث نقاط هنا:
- التسليم المبكر والانتهاء السريع - هذا يعني أنه من الناحية المثالية ، يجب الحصول على أول نتيجة عمل (على سبيل المثال ، تقارير العمل الأولى) في أقرب وقت ممكن ، أي حتى قبل تصميم النظام بأكمله وتنفيذه. في الوقت نفسه ، يجب أن تستغرق كل مراجعة لاحقة أقل وقت ممكن.
- صقل متكرر - وهذا يعني أن كل مراجعة لاحقة ، من الناحية المثالية ، لا ينبغي أن تؤثر على الوظيفة التي تعمل بالفعل. هذه هي اللحظة التي غالبًا ما تصبح أكبر كابوس في المشاريع الكبيرة - عاجلاً أم آجلاً تبدأ الكائنات الفردية في اكتساب الكثير من العلاقات بحيث يصبح من السهل تكرار المنطق تمامًا في نسخة جنبًا إلى جنب بدلاً من إضافة حقل إلى جدول موجود. وإذا كنت متفاجئًا من أن تحليل تأثير التحسينات على العناصر الموجودة قد يستغرق وقتًا أطول من المراجعة نفسها ، فمن المرجح أنك لم تعمل مع مستودعات البيانات الكبيرة في البنوك أو الاتصالات.
- التكيف المستمر مع متطلبات العمل المتغيرة - يجب تصميم الهيكل العام للكائن ليس فقط مع الأخذ في الاعتبار التوسع المحتمل ، ولكن مع توقع أن اتجاه هذا التوسع القادم لا يمكن حتى أن نحلم به في مرحلة التصميم.
ونعم ، يمكن الامتثال لجميع هذه المتطلبات في نظام واحد (بالطبع ، في بعض الحالات ومع بعض التحفظات).
أدناه سوف أراجع اثنين من أكثر منهجيات تصميم رشيقة شيوعًا لـ HD - نموذج المرساة и مخزن البيانات. خارج الأقواس توجد حيل ممتازة مثل ، على سبيل المثال ، EAV و 6NF (في شكلها النقي) وكل ما يتعلق بحلول NoSQL - ليس لأنها أسوأ إلى حد ما ، ولا حتى لأن المقالة في هذه الحالة قد تهدد بالحصول على الحجم من diser متوسط. كل هذا يشير فقط إلى حلول من فئة مختلفة قليلاً - إما إلى التقنيات التي يمكنك تطبيقها في حالات محددة ، بغض النظر عن البنية العامة لمشروعك (مثل EAV) ، أو إلى نماذج تخزين معلومات مختلفة عالميًا (مثل قواعد بيانات الرسم البياني وخيارات أخرى).
مشاكل المنهج "الكلاسيكي" وحلولها في منهجيات مرنة
من خلال النهج "الكلاسيكي" أعني النجم القديم الجيد (بغض النظر عن التطبيق المحدد للطبقات الأساسية ، سامحني أتباع Kimball و Inmon و CDM).
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.
من حيث الهندسة المعمارية مخزن البيانات، يمكن اعتباره بدون تغيير مجموعة كاملة من المفاتيح - طبيعي (رقم التعريف الضريبي للمؤسسة ، رمز المنتج في نظام المصدر ، وما إلى ذلك) وبديل. في الوقت نفسه ، يمكن تقسيم السمات المتبقية إلى مجموعات وفقًا لمصدر و / أو تكرار التغييرات و احتفظ بجدول منفصل لكل مجموعة مع مجموعة مستقلة من الإصدارات.
في نفس النموذج نموذج المرساة تعتبر دون تغيير مفتاح بديل فقط جهات. كل شيء آخر (بما في ذلك المفاتيح الطبيعية) هو مجرد حالة خاصة لسماته. حيث جميع السمات مستقلة عن بعضها بشكل افتراضي، لذلك يجب إنشاء كل سمة جدول منفصل.
В مخزن البيانات يتم استدعاء الجداول التي تحتوي على مفاتيح الكيان حبامي (المحور). تحتوي المحاور دائمًا على مجموعة ثابتة من الحقول:
- مفاتيح الكيان الطبيعي
- مفتاح بديل
- ارتباط بالمصدر
- وقت التسجيل
إدخالات في المحاور لا تتغير أبدا وليس لها إصدارات. ظاهريًا ، المحاور تشبه إلى حد كبير جداول خريطة المعرف المستخدمة في بعض الأنظمة لإنشاء بدائل ، ومع ذلك ، يوصى بعدم استخدام تسلسل عدد صحيح ، ولكن تجزئة من مجموعة من مفاتيح الأعمال كبديل في Data Vault. يعمل هذا الأسلوب على تبسيط تحميل الروابط والسمات من المصادر (لا داعي للانضمام إلى المحور للحصول على بديل ، فقط احسب التجزئة من المفتاح الطبيعي) ، ولكنه قد يتسبب في مشاكل أخرى (على سبيل المثال ، مع الاصطدامات والحالة وغير- طباعة الأحرف في مفاتيح السلسلة ، وما إلى ذلك .p.) ، وبالتالي فهي غير مقبولة بشكل عام.
يتم تخزين جميع سمات الكيان الأخرى في جداول خاصة تسمى الأقمار الصناعية (ساتليت). يمكن أن يحتوي المحور الواحد على عدة أقمار صناعية تخزن مجموعات مختلفة من السمات.
يتم توزيع السمات بين الأقمار الصناعية وفقًا للمبدأ تغيير مشترك - في أحد الأقمار الصناعية ، يمكن تخزين السمات غير ذات الإصدار (على سبيل المثال ، تاريخ الميلاد و SNILS للفرد) ، في الآخر - نادرًا ما يتم تغيير الإصدار (على سبيل المثال ، الاسم الأخير ورقم جواز السفر) ، في الثالث - كثيرًا التغيير (على سبيل المثال ، عنوان التسليم ، والفئة ، وتاريخ آخر طلب ، وما إلى ذلك). يتم تنفيذ الإصدار في هذه الحالة على مستوى الأقمار الصناعية الفردية ، وليس على مستوى الكيان ككل ، لذلك يُنصح بتوزيع السمات بطريقة تجعل تقاطع الإصدارات داخل قمر صناعي واحد في حده الأدنى (مما يقلل من العدد الإجمالي من الإصدارات المخزنة).
أيضًا ، لتحسين عملية تحميل البيانات ، غالبًا ما يتم وضع السمات التي تم الحصول عليها من مصادر مختلفة في سواتل منفصلة.
تتواصل الأقمار الصناعية مع المحور عبر مفتاح غريب (الذي يتوافق مع عدد من أصل واحد إلى متعدد). وهذا يعني أن قيم السمات المتعددة (على سبيل المثال ، أرقام هواتف جهات اتصال متعددة للعميل نفسه) مدعومة من قبل هذه البنية "الافتراضية".
В نموذج المرساة يتم استدعاء الجداول التي تخزن المفاتيح المراسي. ويحتفظون بما يلي:
- مفاتيح بديلة فقط
- ارتباط بالمصدر
- وقت التسجيل
يتم النظر في المفاتيح الطبيعية من وجهة نظر نموذج المرساة الصفات العادية. قد يبدو هذا الخيار أكثر صعوبة في الفهم ، لكنه يعطي مجالًا أكبر بكثير لتحديد كائن ما.
على سبيل المثال ، إذا كانت البيانات حول نفس الكيان يمكن أن تأتي من أنظمة مختلفة ، يستخدم كل منها مفتاحه الطبيعي. في Data Vault ، يمكن أن يؤدي ذلك إلى إنشاءات مرهقة إلى حد ما للعديد من المحاور (واحد لكل مصدر + نسخة رئيسية مدمجة) ، بينما في نموذج Anchor ، يندرج المفتاح الطبيعي لكل مصدر في السمة الخاصة به ويمكن استخدامه عند التحميل بشكل مستقل عن كل الآخرين.
ولكن هنا تكمن لحظة ماكرة واحدة: إذا تم دمج سمات من أنظمة مختلفة في كيان واحد ، فمن المرجح أن يكون هناك بعض قواعد الغراء، والتي يجب أن يفهم النظام من خلالها أن السجلات من مصادر مختلفة تتوافق مع مثيل واحد للكيان.
В مخزن البيانات من المرجح أن تحدد هذه القواعد التكوين "المحور البديل" للكيان الرئيسي ولا تؤثر بأي شكل من الأشكال على المحاور التي تخزن المفاتيح الطبيعية للمصادر وخصائصها الأصلية. إذا تم في وقت ما تحديث قواعد دمج التغيير (أو السمات المستخدمة للدمج) ، فسيكون ذلك كافيًا لإعادة تشكيل المحاور البديلة.
В نموذج المرساة من المحتمل أن يتم تخزين هذا الكيان في مرساة واحدة. هذا يعني أن جميع السمات ، بغض النظر عن المصدر الذي تم الحصول عليه منها ، ستكون ملزمة بنفس البديل. يمكن أن يكون فصل السجلات المدمجة بشكل خاطئ ، وبشكل عام ، تتبع أهمية الدمج في مثل هذا النظام أكثر صعوبة ، خاصة إذا كانت القواعد معقدة للغاية وتتغير بشكل متكرر ، ويمكن الحصول على نفس السمة من مصادر مختلفة (على الرغم من أنها بالتأكيد ممكن ، لأن كل إصدار سمة يحتفظ بمرجع إلى أصله).
في أي حال ، إذا كان من المفترض أن يقوم نظامك بتنفيذ الوظيفة إلغاء البيانات المكررة ودمج السجلات وعناصر MDM الأخرى، يجب أن تقرأ بعناية جوانب تخزين المفاتيح الطبيعية في منهجيات مرنة. ربما يكون التصميم غير العملي لمخزن البيانات أكثر أمانًا فجأة من حيث أخطاء الدمج.
نموذج المرساة يوفر أيضًا نوع كائن إضافي يسمى عقدة في الحقيقة هو خاص نوع المرساة المتدهورة، والتي يمكن أن تحتوي على سمة واحدة فقط. من المفترض أن تُستخدم العقد لتخزين الأدلة المسطحة (على سبيل المثال ، الجنس ، الحالة الاجتماعية ، فئة خدمة العملاء ، إلخ). على عكس المرساة ، العقدة لا يحتوي على جداول سمات مرتبطة، ويتم تخزين السمة الوحيدة (الاسم) دائمًا في نفس الجدول باستخدام المفتاح. ترتبط العُقد بـ Anchors بواسطة جداول Tie بنفس الطريقة التي تتصل بها المراسي ببعضها البعض.
لا يوجد رأي لا لبس فيه حول استخدام العقد. على سبيل المثال، ، الذي يروج بنشاط لاستخدام نموذج المرساة في روسيا ، يعتقد (ليس بشكل غير معقول) أنه من المستحيل القول لكتاب مرجعي واحد أنه دائما سيكون ثابتًا ومستوى واحدًا ، لذلك من الأفضل استخدام مرساة كاملة لجميع الكائنات مرة واحدة.
هناك اختلاف مهم آخر بين Data Vault و Anchor Model وهو التواجد سمات الروابط:
В مخزن البيانات الروابط هي نفس الكائنات الكاملة مثل المحاور ، ويمكن أن تحتوي على السمات الخاصة. في نموذج المرساة الروابط تستخدم فقط لربط المراسي و لا يمكن أن يكون لها سماتها الخاصة. هذا الاختلاف يؤدي إلى أساليب نمذجة مختلفة بشكل كبير. حقائق، والتي سيتم مناقشتها بعد ذلك.
تخزين الحقائق
حتى الآن ، تحدثنا بشكل أساسي عن قياسات النمذجة. الحقائق أقل وضوحا بقليل.
В مخزن البيانات كائن نموذجي لتخزين الحقائق - وصلة، التي يتم إضافة مؤشرات حقيقية في أقمارها الصناعية.
يبدو أن هذا النهج بديهي. إنه يوفر وصولاً سهلاً إلى المؤشرات التي تم تحليلها وهو مشابه بشكل عام لجدول الحقائق التقليدي (لا يتم تخزين المؤشرات في الجدول نفسه ، ولكن في "الجدول المجاور"). ولكن هناك أيضًا عيوب: أحد التحسينات النموذجية للنموذج - توسيع مفتاح الحقيقة - تجعله ضروريًا إضافة مفتاح خارجي جديد إلى الارتباط. وهذا بدوره "يكسر" النمطية ويسبب على الأرجح الحاجة إلى تحسين الكائنات الأخرى.
В نموذج المرساة لا يمكن أن يكون للرابط سماته الخاصة ، لذلك لن يعمل هذا النهج - يجب ربط جميع السمات والمؤشرات على الإطلاق بنقطة ارتساء واحدة محددة. الاستنتاج من هذا بسيط - كل حقيقة تحتاج أيضًا إلى مرساة خاصة بها. بالنسبة لبعض ما اعتدنا على إدراكه كحقائق ، قد يبدو هذا أمرًا طبيعيًا - على سبيل المثال ، يتم تقليل حقيقة الشراء تمامًا إلى عنصر "الطلب" أو "الاستلام" ، ويتم تقليل زيارة الموقع إلى جلسة ، وما إلى ذلك. ولكن هناك أيضًا حقائق ليس من السهل العثور على "جسم ناقل" طبيعي لها - على سبيل المثال ، ميزان البضائع في المستودعات في بداية كل يوم.
وفقًا لذلك ، لا توجد مشاكل مع النمطية عند توسيع مفتاح الحقائق في نموذج المرساة (يكفي فقط إضافة علاقة جديدة إلى المرساة المقابلة) ، ولكن تصميم النموذج لعرض الحقائق أقل وضوحًا ، وقد تظهر المراسي "الاصطناعية" التي تعكس نموذج كائن العمل ليس واضحًا.
كيف تتحقق المرونة
يحتوي البناء الناتج في كلتا الحالتين المزيد من الجداولمن القياس التقليدي. لكن يمكن أن يستغرق مساحة قرص أقل بشكل ملحوظ بنفس مجموعة سمات الإصدار مثل البعد التقليدي. بطبيعة الحال ، لا يوجد سحر هنا - الأمر كله يتعلق بالتطبيع. من خلال توزيع السمات عبر الأقمار الصناعية (في Data Vault) أو الجداول الفردية (Anchor Model) ، فإننا نخفض (أو نحذف تمامًا) تكرار قيم بعض السمات عند تغيير البعض الآخر.
إلى مخزن البيانات سيعتمد الكسب على توزيع السمات بين الأقمار الصناعية ولأجل نموذج المرساة - يتناسب تقريبًا بشكل مباشر مع متوسط عدد الإصدارات لكل كائن قياس.
ومع ذلك ، فإن شغل مساحة يعد ميزة مهمة ، ولكنها ليست ميزة رئيسية ، لتخزين السمات بشكل منفصل. جنبًا إلى جنب مع التخزين المنفصل للروابط ، فإن هذا الأسلوب يجعل التخزين تصميم وحدات. هذا يعني أن إضافة كل من السمات الفردية ونطاقات الموضوعات الجديدة بالكامل في مثل هذا النموذج تبدو وكأنها البنية الفوقية على مجموعة موجودة من الكائنات دون تغييرها. وهذا بالضبط ما يجعل المنهجيات الموصوفة مرنة.
كما أنه يشبه الانتقال من الإنتاج الجزئي إلى الإنتاج الضخم - إذا كان كل جدول نموذج في النهج التقليدي فريدًا ويتطلب اهتمامًا منفصلاً ، فإنه في المنهجيات المرنة يكون بالفعل مجموعة من "التفاصيل" النموذجية. من ناحية أخرى ، هناك المزيد من الجداول ، يجب أن تبدو عمليات تحميل البيانات وجلبها أكثر تعقيدًا. من ناحية أخرى ، يصبحون عادي. هذا يعني أنه قد يكون هناك مؤتمتة ومدارة بواسطة البيانات الوصفية. السؤال "كيف سنضعه؟" ، الإجابة التي يمكن أن تشغل جزءًا كبيرًا من العمل على تصميم التحسينات ، لا تستحق العناء الآن (كما هو الحال بالنسبة لمسألة تأثير تغيير النموذج على عمليات العمل).
هذا لا يعني أن المحللين في مثل هذا النظام ليسوا بحاجة على الإطلاق - لا يزال يتعين على شخص ما العمل على مجموعة من الكائنات ذات السمات ومعرفة مكان وكيفية تحميلها كلها. لكن مقدار العمل ، وكذلك احتمالية الخطأ وتكلفته ، يتم تقليلهما بشكل كبير. في كل من مرحلة التحليل وأثناء تطوير ETL ، والتي يمكن اختزالها في جزء كبير منها إلى تحرير البيانات الوصفية.
الجانب المظلم
كل ما سبق يجعل كلا النهجين مرنين حقًا وقابلين للتصنيع ومناسبين للتنقيح التكراري. بالطبع ، هناك أيضًا "برميل من القطران" ، والذي أعتقد أنك تعرفه بالفعل.
يؤدي تحلل البيانات الكامن وراء نمطية البنى المرنة إلى زيادة عدد الجداول ، وبالتالي ، تكاليف غير مباشرة للصلات عند الجلب. من أجل الحصول على جميع سمات البعد ببساطة ، يكون التحديد الفردي كافيًا في التخزين الكلاسيكي ، وستتطلب البنية المرنة عددًا من الوصلات. علاوة على ذلك ، إذا كان من الممكن كتابة كل هذه الصلات مسبقًا للتقارير ، فإن المحللين الذين اعتادوا كتابة SQL يدويًا سيعانون بشكل مضاعف.
هناك عدة حقائق تجعل هذا الوضع أسهل:
عند العمل بأبعاد كبيرة ، لا يتم استخدام جميع سماته تقريبًا في وقت واحد تقريبًا. هذا يعني أنه قد يكون هناك صلات أقل مما يبدو للوهلة الأولى في النموذج. في Data Vault ، يمكنك أيضًا مراعاة التكرار المتوقع للمشاركة عند تخصيص السمات للأقمار الصناعية. في الوقت نفسه ، هناك حاجة إلى المحاور أو المراسي نفسها بشكل أساسي لإنشاء بدائل ورسم خرائط لها في مرحلة التحميل ونادرًا ما يتم استخدامها في الاستعلامات (هذا ينطبق بشكل خاص على المراسي).
جميع الصلات بالمفتاح. بالإضافة إلى ذلك ، فإن الطريقة الأكثر "ضغطًا" لتخزين البيانات تقلل من عبء فحص الجدول عند الحاجة (على سبيل المثال ، عند التصفية حسب قيمة السمة). يمكن أن يؤدي هذا إلى حقيقة أن الجلب من قاعدة بيانات موحدة مع مجموعة من الصلات سيكون أسرع من مسح بُعد واحد ثقيل مع الكثير من الإصدارات لكل صف.
على سبيل المثال ، هنا في المقالة هناك اختبار أداء مقارن مفصل لنموذج المرساة مع تحديد من جدول واحد.
يعتمد الكثير على المحرك. تمتلك العديد من الأنظمة الأساسية الحديثة آليات داخلية لتحسين الصلات. على سبيل المثال ، يمكن لـ MS SQL و Oracle "تخطي" الانضمام إلى الجداول إذا لم يتم استخدام بياناتها في أي مكان باستثناء الصلات الأخرى ولا تؤثر على التحديد النهائي (حذف الجدول / الانضمام) ، بينما MPP Vertica ، أثبت أنه محرك ممتاز لنموذج المرساة ، مع بعض التحسين اليدوي لخطة الاستعلام. من ناحية أخرى ، لا يبدو تخزين نموذج المرساة ، على سبيل المثال ، في Click House ، والذي لديه دعم محدود للانضمام ، فكرة جيدة حتى الآن.
بالإضافة إلى ذلك ، لكل من العمارة هناك حيل خاصة، مما يسهل الوصول إلى البيانات (سواء من حيث أداء الاستعلام أو للمستخدمين النهائيين). على سبيل المثال، الجداول الزمنية في Data Vault أو وظائف الجدول الخاصة في نموذج المرساة.
في المجموع
الجوهر الرئيسي للبنى المرنة المدروسة هو نمطية "تصميمها".
تسمح هذه الخاصية بما يلي:
- بعد بعض التحضير الأولي المتعلق بنشر البيانات الوصفية وكتابة خوارزميات ETL الأساسية ، تزويد العميل بالنتيجة الأولى بسرعة في شكل تقريرين يحتويان على بيانات من عدد قليل من كائنات المصدر. ليس من الضروري التفكير بشكل كامل (حتى المستوى الأعلى) في نموذج الكائن بالكامل لهذا الغرض.
- يمكن أن يبدأ نموذج البيانات في العمل (ومفيد) مع 2-3 كائنات فقط ، وبعد ذلك تنمو تدريجيا (بخصوص نموذج المرساة نيكولاي مقارنة جميلة مع الفطريات).
- معظم التحسينات ، بما في ذلك توسيع نطاق الموضوع وإضافة مصادر جديدة لا يؤثر على الوظائف الحالية ولا يسبب خطر كسر شيء يعمل بالفعل.
- بفضل التحلل إلى عناصر قياسية ، تبدو عمليات ETL في مثل هذه الأنظمة كما هي ، وكتابتها تفسح المجال للخوارزمية ، وفي النهاية ، أتمتة.
ثمن هذه المرونة إنتاجية. هذا لا يعني أنه من المستحيل تحقيق أداء مقبول في مثل هذه النماذج. في كثير من الأحيان ، قد تحتاج فقط إلى مزيد من الجهد والاهتمام بالتفاصيل لتحقيق المقاييس المطلوبة.
التطبيقات
أنواع الكيانات مخزن البيانات
المزيد حول Data Vault:
أنواع الكيانات نموذج المرساة
المزيد عن نموذج المرساة:
جدول ملخص مع السمات المشتركة والاختلافات بين المناهج المدروسة:
المصدر: www.habr.com