المدونة

الرئيسية / المدونة / مناقشة تخزين البيانات لصناعة الخدمات المالية مع فنسنت ريناردي

جدول المحتويات
الآلي, لا كود مكدس البيانات

تعلم كيف Astera يمكن لـ Data Stack تبسيط وتبسيط إدارة بيانات مؤسستك.

مناقشة تخزين البيانات لصناعة الخدمات المالية مع فينسينت ريناردي

26 فبراير، 2024

مع إطلاق Astera منشئ DW قاب قوسين أو أدنى ، لقد تحدثنا إلى بعض قادة الفكر البارزين في الصناعة للحصول على رأيهم في الصناعة كما هي ، وكيف تتطور ، وأين يرون أتمتة مستودعات البيانات تتناسب مع الصورة الأكبر.

في مقابلتنا الثانية في هذه السلسلة ، جلسنا مع فينسينت ريناردي ، المخضرم المخضرم في مساحة تخزين البيانات. لقد عمل في مشاريع لعملاء مثل باركليز ، وبنك لويدز ، وتويوتا ، وأفيري دينيسون. كتب فينسنت أيضًا بشكل مكثف عن تخزين البيانات وذكاء الأعمال ، وقام بتأليف كتاب بناء مستودع بيانات: باستخدام أمثلة في SQL Server وشعبية مدونة حول هذا الموضوع.

في هذه المناقشة ، أخذنا غوصًا عميقًا في خبرات فينسنت المتنوعة ورؤى حول تخزين البيانات ، مع التركيز بشكل خاص على صناعة الخدمات المالية ، حيث اكتسب خبرة كبيرة على مر السنين.

هل يمكن أن تخبرني قليلاً عن مشاركتك في تخزين البيانات؟ متى بدأت العمل في هذه المشاريع لأول مرة ، وما الأدوار التي لعبتها في عملية التطوير على مر السنين؟

بدأت العمل في تخزين البيانات في عام 1996 ، حيث أنشأت مستودع بيانات و BI لشركة تصنيع سيارات. في ذلك الوقت ، كان يطلق على DW & BI اسم DSS و EIS / MIS (نظام دعم القرار ونظام المعلومات التنفيذية / الإدارية). ثم تركت DW / BI لبضع سنوات ، لكنني شاركت في هذا الفضاء مرة أخرى في عام 2005 عندما قرأت كتاب رالف كيمبال عن تخزين البيانات (The Data Warehouse Toolkit) وأصبح شغوفًا جدًا بها. بعد ذلك كتبت العديد من المقالات حول هذا الموضوع لمواقع مختلفة ومدونتي. في عام 2007 ، قمت بنشر كتاب يغطي العديد من رؤيتي حول تخزين البيانات.

منذ عام 2005 ، عملت في العديد من مشاريع تخزين البيانات ، وتطوير مستودعات البيانات للبنوك ، ومديري الأصول ، وشركات التأمين ، والمصنعين ، ومقدمي الرعاية الصحية ، وتجار التجزئة ، وشركات التجارة الإلكترونية. أثناء عمليات التنفيذ ، تتمثل مسؤولياتي الأساسية كمهندس مستودع بيانات ، أي تصميم بنية تدفق البيانات ونماذج البيانات والأنظمة الأساسية المادية بما في ذلك SQL Server و Oracle و Teradata و Hadoop و Azure.

لقد عملت أيضًا في مجموعة متنوعة من الأدوار الأخرى ، بما في ذلك كمحلل أعمال (متطلبات العمل والمواصفات الوظيفية) ومصمم BI (تحديد لوحات المعلومات والتصورات) ومطور BI (العمل مع منصات مثل QlikView و Spotfire و Tableau و SSRS و SSAS ، ProClarity ، Business Objects ، رفيق الإستراتيجية) ، مطور ETL (SSIS ، Informatica ، أدوات Teradata ، SQL) ، اختبار ، ومدير المشروع.

لقد تحدثت قليلاً من قبل عن الاختلافات بين تخزين البيانات و BI - كيف تعتقد أن هذين المفهومين يكملان بعضهما البعض ، وأين يختلفان من حيث المبدأ؟

في الممارسة العملية ، يتم استخدامهما بالتبادل ، لكنهما في الواقع مختلفان. BI هي الواجهة الأمامية (لوحات المعلومات ، التقارير ، المرئيات) ، ومستودع البيانات هو الواجهة الخلفية (قاعدة البيانات ، التخزين ، ETL ، الملفات). ومع ذلك ، فهي تكمل بعضها البعض ، وفي الممارسة العملية ، يتم استخدامها معًا. اليوم ، ليس من الضروري أن تكون الواجهة الخلفية مستودع بيانات ؛ يمكن أن يكون بحيرة بيانات. ولا يجب أن تكون الواجهة الأمامية هي BI ؛ يمكن أن يكون التعلم الآلي.

لديك ثروة من الخبرة في مجال الخدمات المالية. ما هي حالات الاستخدام الأكثر شيوعًا التي تراها من مؤسسات في صناعات مثل التأمين أو الخدمات المصرفية الاستثمارية؟

تتضمن حالات الاستخدام في التأمين الكثير من التحليل المعقد. لذلك ، عادةً ما تتطلع المؤسسات إلى الإجابة على الاستفسارات المتعلقة بأنواع الأقساط الإجمالية المكتسبة ذات المستوى الأعلى ، والأقساط المكتوبة ، وتغطية المخاطر ، وتكلفة المخاطر ، وتعديلات المطالبات ، والجداول الزمنية للمطالبات ، وخطوط أنابيب المبيعات ، وربحية العملاء ، والاكتتاب ، والمعدلات الاكتوارية ، ومخاطر إعادة التأمين ، والتدفق النقدي.

في مجال الخدمات المصرفية الاستثمارية ، ستغطي هذه التحليلات مخاطر السوق ، والتعرض للمركز ، والأنشطة التجارية ، والتقارير التنظيمية ، وأبحاث السوق ، والسيولة ، والضمانات ، وخطوط الصفقات ، وحسابات العملاء ، ومكافحة غسل الأموال ، والأطراف المقابلة ، واكتشاف الاحتيال ، وإدارة المحافظ ، واختبارات ضغط رأس المال .

لقد شهدنا زيادة كبيرة في حجم وتنوع البيانات التي تنتقل عبر المؤسسات خلال العقد الماضي. كيف ترى تطور ما يسمى بمستودع البيانات التقليدي للتعامل مع هذه المتطلبات؟

لذلك ، تطور تخزين البيانات التقليدي لدمج بحيرة البيانات وتقنيات البيانات الضخمة. يتم تخزين البيانات غير المنظمة في بحيرات البيانات ، بما في ذلك المستندات والصور والفيديو وإنترنت الأشياء وموجزات الوسائط الاجتماعية ، بينما يتم تخزين البيانات المهيكلة (البيانات المخزنة بتنسيق جدولي) في مستودع البيانات. عادةً ما يتم إنشاء بحيرات البيانات على نظام ملفات Hadoop مقارنة بمستودع البيانات ، والذي يتم بناؤه عمومًا على قواعد البيانات العلائقية. تتضمن مستودعات البيانات الحديثة أيضًا NoSQL ، مثل قواعد بيانات الرسم البياني والمستندات ، حيث أن بعض البيانات أكثر ملاءمة لهذه الأنواع من التنسيقات. التي تغطي بت متنوعة.

بقدر ما يذهب الحجم ، في السنوات الأولى من تخزين البيانات ، كانت قواعد بيانات MPP مثل Teradata و Oracle Exadata و Microsoft PDW طريقة شائعة للتعامل مع كميات كبيرة من البيانات مع الحفاظ على ارتباط البيانات. لكن في الوقت الحاضر ، تُستخدم تقنيات البيانات الضخمة على نطاق واسع.

ما رأيك في بحيرة البيانات؟ هل لها مكان في نظام ذكاء الأعمال الحديث؟ هل هو مكمل لمخزن البيانات ، أم أنه بديل قابل للتطبيق؟

نعم إنها كذلك. تستخدم مستودعات البيانات الحديثة بحيرات البيانات كمنطقة انطلاق تتيح للمستخدمين وتقنيات ML للواجهة الأمامية الوصول إلى البيانات الأولية. طالما أنك لا تتطلع إلى دمج البيانات ، فإن بحيرة البيانات هي بديل قابل للتطبيق. غالبًا ما يُرى هذا النوع من حالات الاستخدام في المشاريع التي يتم فيها عزل البيانات (منفصلة عن الوظائف الأخرى) ويكون وقت التطوير في حده الأدنى ، وفي هذه الحالة تكون بحيرات البيانات فعالة للغاية. ومن الأمثلة الجيدة على ذلك مشروع اكتشاف الاحتيال القائم على التعلم الآلي في أحد البنوك أو مشروع يلزم فيه تلبية متطلبات إعداد تقارير تنظيمية محددة في غضون ثلاثة أشهر. عند إزالة هذه الصوامع لاحقًا (على سبيل المثال ، عندما تحتاج وظائف المؤسسة الأخرى إلى الوصول إلى نتيجة التنبؤ) ، يمكن تخزين مخرجات النموذج في مستودع البيانات للمستخدمين المتلقين للمعلومات.

ومع ذلك ، في معظم سيناريوهات المؤسسة ، ستحتاج إلى دمج البيانات. على سبيل المثال ، ستحتاج شركة التأمين أو مدير الأصول إلى إنشاء ملف عرض موحد من البيانات المتعلقة بالأوراق المالية والمُصدِرين والسياسات والعملاء لتكوين صورة دقيقة عن مؤسستهم.

لقد قلت في الماضي أن فهم العمل قد يكون الجزء الأكثر أهمية في تطوير مستودع البيانات. كيف ستعمل على ضمان ترجمة متطلبات العمل بأمانة في بنية البيانات؟

نعم ، فهم الأعمال مهم جدًا. لا يمكنك تصميم نموذج بيانات جيد بدون فهم جيد للأعمال. تخيل لو تم تكليفك بتصميم مستودع بيانات ESG (بيئي ، اجتماعي ، حوكمة) ، لكن لم يكن لديك أي فكرة عن ESG. أو سوق بيانات الاكتتاب ، لكنك لم تعمل أبدًا في التأمين. ربما لا يمكنك معرفة الشكل الذي يجب أن تبدو عليه جداول البيانات الفعلية والأبعاد. يجب أن يكون مهندس البيانات الجيد مهتمًا بالأمور الجوهرية للأعمال. لنفترض أنك تصمم سوق إحالة الأداء لمدير استثمار. من الضروري أن تتعرف على الفرق بين العائد الحسابي والهندسي ومنحنيات العائد وعوامل التفاعل. للأسف ، لا يهتم بعض مهندسي البيانات بتفاصيل العمل الأساسية هذه. هم أكثر اهتماما بالبتات الفنية.

أفضل طريقة لضمان دمج متطلبات العمل بشكل جيد في نموذج البيانات هي تشغيل سيناريوهات أعمال مختلفة ، واختبار ما إذا كان يمكن تلبية كل سيناريو عن طريق الاستعلام عن نموذج البيانات باستخدام استعلام SQL بسيط. إذا كنت بحاجة إلى استعلام معقد ، فإن نموذج البيانات ليس مصممًا جيدًا. عادة ما يكون هذا هو انهيار بحيرة البيانات ؛ إنهم لا يرضون سيناريوهات الأعمال المعقدة. وهذا هو جوهر الأمر برمته: كتابة تلك السيناريوهات جيدًا ؛ يجب أن يكون لديك فهم جيد للعمل.

في منشور مدونة سابق ، كتبت عن عدد مؤسسات الخدمات المالية التي لا تزال تستخدم Excel لإنشاء التقارير والتحليلات. هل ترى أن هذه الممارسة تتغير مع انتشار أدوات التصور الأكثر تعقيدًا ، أم أننا سنستمر في رؤية هذه العملية في المستقبل المنظور؟

ستستمر شركات الخدمات المالية في استخدام برنامج Excel للتحليل ولإعداد التقارير أيضًا. هذه طبيعة بشرية لأن الموظفين في هذا المجال يميلون إلى امتلاك مهارات Excel قوية. لقد اختبرت هذا التفضيل بشكل مباشر في العديد من البنوك والشركات الاستثمارية. حتى المنظمات التي تستخدم منصات مثل Tableau أو Qlik أو Power BI طلبت تسهيلات "تصدير إلى Excel" لمزيد من التحليل.

على الرغم من أهمية التقارير ولوحات المعلومات القياسية التي تنتجها أدوات التصور (فهي تحتوي على بيانات رسمية بتنسيق سهل الفهم) ، يحتاج المستخدمون إلى إجراء تحليلهم الخاص في كثير من الحالات. لذلك ، يطلبون البيانات الأولية وراء لوحات المعلومات هذه في أداة أكثر دراية بها - Excel. مع وجود البيانات الأولية في متناول اليد ، يمكنهم تجميع البيانات بشكل مختلف ، وتطبيق عوامل تصفية معينة ، وما إلى ذلك ، كل ذلك وفقًا لاحتياجاتهم.

تذكر ، هؤلاء محللون ماليون ، بارعون في العدد ، وأذكياء - تحليل البيانات ومعالجة الأرقام هو ما يفعلونه. لن يلبي استهلاك التقارير الثابتة احتياجاتهم بالكامل ، ولهذا السبب ليس من الجيد عمومًا محاولة تلبية جميع الاحتياجات المحتملة في أداة ذكاء الأعمال.

كانت هناك دفعة كبيرة لبدء نقل مستودعات البيانات إلى السحابة على منصات مثل Google BigQuery أو Amazon Redshift في السنوات الأخيرة. ما رأيك في مزايا النشر السحابي؟ هل ما زلت توصي بالالتزام بقواعد البيانات المحلية في بعض الحالات؟

المزايا الرئيسية هي الاستعانة بمصادر خارجية للموارد البشرية والمرونة في موارد الحوسبة. باستخدام مستودع البيانات السحابية ، لا تحتاج إلى دفع الكثير من الأشخاص داخل الشركة لصيانة الخوادم والتخزين والشبكة والأمان والنسخ الاحتياطي وعمليات التعافي من الكوارث. إذا كنت بحاجة إلى خادم قاعدة بيانات جديد ، فلن تحتاج إلى الانتظار ثلاثة أسابيع للشراء ، والتهيئة ، والتثبيت ، وإرفاق مساحة تخزين ، وما إلى ذلك ، بدلاً من ذلك ، ستزيد سعة الخادم عند الطلب ، وتدفع بالساعة.

عرض القيمة هذا ليس مثيرًا للاهتمام فقط للشركات الصغيرة ولكن أيضًا للشركات الكبيرة التي تسأل نفسها في كثير من الأحيان ، "ما هي الأعمال التجارية التي يجب أن أركز عليها؟" سواء كنت تاجر تجزئة أو شركة اتصالات أو شركة مالية ، فإن الإجابة بالتأكيد ليست "أعمال الخوادم" ولا "أعمال البنية التحتية لتكنولوجيا المعلومات". لذلك أنت تقوم بالاستعانة بمصادر خارجية. باستخدام البنية التحتية السحابية ، يمكنك زيادة وتقليل قوة الحوسبة والذاكرة متى احتجت إلى ذلك. تقوم بإيقاف تشغيل خوادم الاختبار والتطوير عندما لا تكون قيد الاستخدام في الليل ، وتدفع بالساعة.

عندما يتعلق الأمر بخوادم مستودع البيانات القوية ، فإن التكلفة باهظة لإعدادها داخليًا (محليًا). مهارات الموظف المطلوبة باهظة أيضًا ، نظرًا لوجود العديد من المهارات المتخصصة المختلفة المطلوبة ، من SAN إلى الأمان ، ومن Docker إلى Yarn. لذلك أوصي بالنشر المستند إلى السحابة بدلاً من مستودع بيانات محلي. هذه هي الحجة لاستخدام Google BigQuery و Amazon Redshift و Azure Dedicated SQL Pool (المعروف سابقًا باسم SQL DW و PDW و APS).

ومع ذلك ، افترض أنه ليس مشروعًا جديدًا ، وعليك تحسين مستودع بيانات موجود في مكان العمل مع العديد من الأنظمة المحلية المتصلة به. في هذه الحالة ، تكون تكلفة ترحيل جميع هذه الأنظمة / التطبيقات إلى السحابة باهظة. دعنا نقول من باب الجدل أنه سيكلف مليوني دولار إضافية وثلاث سنوات لإكمال هذا النوع من المشاريع. ليس من المنطقي من الناحية التجارية إنفاق مليوني دولار بدون ميزات عمل إضافية. احتفظ بها في مكانها ، وقم بإجراء التحسينات في مكان العمل ، وفي الوقت نفسه ، قم ببناء نظامك الجديد ببطء في السحابة. حاليًا ، يتم تخصيص ما يقرب من 2 ٪ من ميزانيات تقنية المعلومات لصيانة الأنظمة والبنية التحتية الحالية. هذا هو التجمع الذي يجب أن تستفيد منه لدفع عملية ترحيل بطيئة إلى السحابة.

لقد رأيتك تتطرق إلى النقاش الكبير بين ETL مقابل ELT من قبل. عندما يتعلق الأمر بتحميل البيانات إلى مستودع البيانات ، هل هناك نهج تفضله؟ أم هل يلزم البت فيها على أساس كل حالة على حدة؟

يجب أن يتم تحديده على أساس كل حالة على حدة. ذلك يعتمد على البنية التحتية. يعتمد ذلك على بحيرة البيانات. يعتمد ذلك على أداة استيعاب البيانات. ويعتمد ذلك على منصة مستودع البيانات. في النهاية ، لا يهم ما إذا كنت تستخدم ETL أو ELT أو ELTLT ؛ يمكنك استيعاب البيانات بعدة طرق مختلفة. يمكنك تنظيمها مرة واحدة أو مرتين أو لا شيء. قم بتحويله مرة أو مرتين أو لا شيء. تحتاج فقط إلى اختيار النهج الأنسب لكل خط أنابيب ولكل موقف.

سواء كان الأمر يتعلق بـ ETL أو ELT ، فإن "الواجب" عند عرض البيانات هو الاختبار الآلي. يشرحها نمرود أفيسار جيدًا هنا. هذا هو النهج الذي أفضله في ETL / ELT: نهج الاختبار الآلي.

فيما يتعلق بعملية تطوير مستودع البيانات نفسها ، هل تشعر أن أجايل أو شلال أكثر قدرة على تلبية متطلبات ذكاء الأعمال المتغيرة باستمرار؟

لا يتعلق الأمر بالرشاقة أو الشلال (رشيق ، بالطبع ، من يريد ارتكاب جزء كبير دفعة واحدة؟). تدور عملية تطوير مستودع البيانات حول عمليات التطوير. هذا الانضباط الهندسي ناضج الآن. يجب أن يكون لديك خط أنابيب تحرير ، ولوحة سباق ، وتراكم ، والتحكم في المصدر ، والتحكم في التغيير ، وتسجيل الأخطاء ، وإدارة الحوادث. يحتاج فريق تطوير مستودع البيانات إلى أتمتة DevOps ، على سبيل المثال ، يجب أن تكون عملية الإصدار مؤتمتة ، من التحكم في المصدر ، وسحب الطلب إلى فرع الإصدار ، ونشره في الاختبار ، وتشغيل الاختبار الآلي والنشر في الإنتاج.

كان CI / CD مرتبطًا بتطوير التطبيقات ، وليس تطوير مستودع البيانات. لكن الآن ، إنه أمر لا بد منه. إذا قمت بتشغيل فريق تطوير مستودع البيانات بدونه ، فإنك تتحمل الكثير من التكاليف الإضافية كل شهر. أو ما هو أسوأ ، التضحية بجودة بناء مستودع البيانات.

لقد كتبت في مدونتك عن بعض العناصر الأساسية التي تحدد فعالية مستودع البيانات الخاص بك ، بما في ذلك توافر البيانات ، وأمن البيانات ، وجودة البيانات ، وبالطبع أداء الاستعلام / التحميل. ما هو العامل الأكثر أهمية برأيك؟

إن أهم عنصر يحدد فعالية مستودع البيانات هو ما إذا كان يعالج مشاكل العمل وحالات الاستخدام أم لا. في نهاية اليوم ، يمكنك استخدام DW الخاص بك لإنشاء تقارير العملاء أو لوحات المعلومات الإدارية أو التقارير التنظيمية أو تحليلات الأعمال العامة. ومع ذلك ، إذا فشلت في معالجة مشكلة عملك ، فلن تكون فعالة. في هذه الحالة ، يمكن عادةً ربط الفشل بواحد من ثلاثة أشياء:

  1. عدم وجود بيانات معينة ، على سبيل المثال ، بيانات حول منتج أو عميل مهم ،
  2. مشكلات جودة البيانات ، مثل البيانات غير الصحيحة ،
  3. صعوبة في الاستعلام عن البيانات ، على سبيل المثال ، البيانات في المستودع ولكنها لا تظهر في التقارير.

أود أن أقول إن البيانات غير الصحيحة تضر بشكل خاص بالنشاط التجاري ، خاصةً عندما يتخذون إجراءً بناءً على تلك البيانات. على سبيل المثال ، إذا استخدمت بيانات أداء المستودع لإنشاء صحيفة وقائع وأخطأت في أداء الصندوق ، فهذا يمثل خطرًا على السمعة ومخاطر مالية ضخمة. لا يمكن أن ينتج عن هذا فقط عقوبة كبيرة من السلطات المالية ، ولكن قد يتجه عملاؤك إلى الخروج بناءً على الأرقام المضللة التي نقلتها ، مما يتسبب في تدفقات هائلة إلى الخارج ومستقبل أعمال قاتم بشكل عام.

وبالمقارنة ، إذا تم إجراء استعلام لمدة ساعة واحدة طوال اليوم ، فهذا لا شيء ، ولا ضرر مالي تقريبًا. الشيء نفسه مع عدم وجود بيانات معينة (توافر البيانات) ، وهذا ليس خطرا كبيرا مقارنة بالبيانات غير الصحيحة التي يتم نشرها / إرسالها إلى السلطات أو العملاء. من ناحية أخرى ، إذا سُرقت بيانات عملائك ، فقد يؤدي ذلك أيضًا إلى الإضرار بثقة العميل ، مما يتسبب في هجرة العملاء ، مما قد يتركك بلا عمل في المستقبل المنظور.

أود أن أقول إن جودة البيانات وأمن البيانات هما المسألتان الرئيسيتان اللتان تحتاج إلى حمايتهما ضدهما.

لقد ناقشت أيضًا بعض الخطوات المهمة في بناء مستودع بيانات ، أي نمذجة البيانات ، وإنشاء عمليات لتحميل البيانات وتسليمها ، ثم تصميم هذه العمليات لضمان أقصى قدر من الكفاءة. ما هو الجزء الأكثر تحديًا في تطوير مستودع البيانات في رأيك؟

إن أصعب جزء في تطوير مستودع البيانات ليس نمذجة البيانات أو تحميل البيانات أو كفاءة العملية ولكن تحديد ماذا هندسة معمارية هو الأنسب.

إذا اخترت إنشاء بحيرة بيانات ، في حين أن ما تحتاجه حقًا هو مستودع بيانات الأبعاد (بسبب طبيعته المتكاملة) ، فأنت تسير في الاتجاه الخاطئ منذ البداية. إذا قررت استخدام تقنية استيعاب معينة لا يمتلكها أي من موظفيك المهارة اللازمة لتشغيلها ، فقد استثمرت استثمارات كبيرة زادت من المخاطر وتسببت في حدوث تأخيرات في التنفيذ يمكن تجنبها. إذا قررت شراء مستودع بيانات مُصمم مسبقًا ، لكن نموذج البيانات لم يناسبك ، كان الأمر أشبه ببناء ناطحة سحاب على أساس ضعيف.

 ما لا نراه خلف الكواليس هو عادة ما يجعل المستودع ناجحًا ، أي اختيار الهندسة ، وعمليات التطوير ، و جودة البيانات الشيكات.

أين ترى تركيب أتمتة مستودعات البيانات هنا؟ كيف يمكن أن يساعد في تقليل الجهد والوقت الذي يقضيه في بعض هذه المهام؟ أين ترى القيمة الكبيرة فيما يتعلق بالأداة المصممة لهذا الغرض؟

قيمة أتمتة مستودع البيانات هي التحميل التلقائي. على سبيل المثال ، تستخدم الكثير من شركات إدارة الأصول أنظمة إدارة الاستثمار الجاهزة على نطاق واسع لإدارة محافظها الاستثمارية. مستودع بيانات الأبعاد الذي يمكنه تحميل البيانات تلقائيًا منها له قيمة كبيرة. تستخدم العديد من شركات التصنيع الكبرى SAP كنظام تشغيل أساسي لها. يُعد مستودع البيانات الذي يمكنه تحميل البيانات تلقائيًا من SAP أمرًا ذا قيمة لأنك لست مضطرًا إلى تطوير خطوط الأنابيب لتحميل البيانات ، الأمر الذي يستغرق الكثير من الوقت. في جميع الحالات ، يجب أن تكون قادرًا على تغيير نموذج الأبعاد كما تراه مناسبًا.

ثاني أفضل شيء هو محاولة أتمتة استيعاب البيانات. يعد دمج مصادر البيانات المتعددة في بُعد واحد أمرًا معقدًا (على سبيل المثال ، بُعد العميل ، وبُعد الشركة ، والبُعد الأمني) ، كما أن التشغيل الآلي هو أكثر صعوبة. يمكن أن نتعامل مع الملفات العمودية أو الملفات المتزايدة أو CSV أو ملفات Excel. نحن بحاجة إلى أن نكون قادرين على تدوير تلك البيانات وتجميعها ودمجها.

أيضًا ، يجب ألا نفترض أن مصدر البيانات هو ملف جاهز للمعالجة ؛ قد يلزم فك تشفيره أو فك ضغطه أو إعادة تسميته أو تنزيله أولاً. يتضمن جوهر دمج البيانات من مصادر متعددة عملية تسمى "مطابقة البيانات" ، ويمكن أن تكون مطابقة شلال على عدة معايير. تسمى العملية الأساسية الثانية "إثراء البيانات" ، على سبيل المثال ، إذا لم يكن للأمن تصنيف S&P أو بلد خطر أو قطاع GICS ، فإننا نثريها من مصدر خارجي مثل Bloomberg أو FactSet.

القيمة الأساسية لمستودع البيانات هي البعد المتكامل الذي يتم إنشاؤه من العديد من المصادر. يجب أن تكون أداة أتمتة مستودع البيانات قادرة على إنشاء هذا البعد ، وليس بُعد بلد أو عملة ، ولكن بُعد عميل أو أمان يتكون من عدة جداول مصدر.

ما الميزات والوظائف التي تعتقد أنها ضرورية للغاية لأداة فعالة لأتمتة مستودع البيانات؟

الوظائف التي تعتبر ضرورية للغاية لأداة فعالة لأتمتة مستودع البيانات هي:

  1. يجب أن يكون محدثًا مع ERP أو CRM أو IMS (على سبيل المثال ، SAP أو Salesforce أو ThinkFolio) أثناء تغيير الإصدارات
  2. يجب أن يكون لديه القدرة على دمج مصادر متعددة لإنشاء أبعاد معقدة ، أي بعد العميل
  3. يجب أن يكون لديه القدرة على معالجة ملفات البيانات مسبقًا ، على سبيل المثال ، استرداد الملفات أو تنزيلها للمعالجة.
  4. يجب أن يسمح بالاختبار والنشر الآلي

أخيرًا ، إلى أين يتجه مستودع البيانات في المستقبل؟ ما هي التطورات المهمة (إن وجدت) التي تتوقعها في هذا المجال؟

يعتقد بعض الأشخاص أنه يمكنهم استبدال عامين من تطوير مستودع البيانات بتطوير بحيرة البيانات لمدة ثلاثة أشهر. يعد هذا أمرًا مخادعًا لأن بيانات العميل أو المنتج التي يتم تحميلها في البنية الأخيرة ليست متكاملة ، لذا فهي غير قابلة للاستعلام. وقد ينسون إنشاء فحوصات جودة البيانات أو الاستعداد التشغيلي (على سبيل المثال ، أدوات المراقبة) في النظام ، الأمر الذي قد يستغرق 30٪ من الجهد بأكمله. منحت ، بعض المشاريع لا تحتاج إلى تكامل ، وفي هذه الحالة ، يمكن استخدام بحيرة بيانات ، لكنك لا تزال بحاجة إلى بناء فحوصات جودة البيانات والاستعداد التشغيلي.

ما أراه قادمًا في المستقبل هو أتمتة الاختبارات وأتمتة فحوصات جودة البيانات. ليس من الصعب جدًا إنشاء أداة تراقب كل ملف وارد وتجري عمليات تحقق على أعمدة محددة ، وتقارنها ببيانات الأيام القليلة الماضية. الشيء الآخر الذي يمكن بناؤه هو أداة ذكاء الأعمال التي تكون متوافقة مع CI / CD ، على سبيل المثال ، تعتمد على XML ، لذلك يمكن نشرها من التحكم في المصدر إلى الإنتاج تلقائيًا لأنها تستند إلى النص.

وأخيرًا ، حتى الآن ، لا توجد أداة واحدة لإدارة البيانات في السوق يمكنها فحص قواعد البيانات وأدوات ETL و BI وإنشاء نسب البيانات من ملفات المصدر إلى التقرير. قد لا يكون من الممكن إنشاء هذه الأداة لكل قاعدة بيانات واحدة ، ETL ، وأداة BI ، ولكن من الممكن القيام بأهم منها. مفتاح حوكمة البيانات هو الأتمتة.

Astera DW Builder - إجابة سريعة لتحديات تطوير مستودع البيانات لديك

Astera DW Builder هو نظام أساسي موحد يمكّنك من نشر واستهلاك نماذج البيانات الغنية بالبيانات الوصفية التي تعتمد على متطلبات المستخدم النهائي.

يوفر المنتج مجموعة من الوظائف الجاهزة التي يمكنك الاستفادة منها لبناء مستودع بيانات رشيق يخدم احتياجات عملك حقًا. من تنفيذ قواعد العمل واصطلاحات التسمية على المستوى المنطقي إلى إنشاء خطوط بيانات معقدة يمكنها استرداد البيانات تلقائيًا من أنظمة المصدر التي اخترتها ، وتحويلها وفقًا لمتطلبات جودة البيانات الخاصة بك ، وتحميلها إلى قاعدة بيانات سحابية أو محلية من اختيارك ، أصبح كل ذلك ممكنًا من خلال حل عدم وجود رمز.

الآن ، نمنحك الفرصة للحصول على نظرة أولى حصرية على سرعة وحدسية ADWB لنفسك في حدث إطلاق شامل يعد بتغيير طريقة تفكيرك في تخزين البيانات. شاهد ال حدث الإطلاق الحصري هنا.

ربما يعجبك أيضا
ما هو كتالوج البيانات؟ الميزات وأفضل الممارسات والفوائد
مخطط النجمة مقابل. مخطط ندفة الثلج: 4 اختلافات رئيسية
كيفية تحميل البيانات من AWS S3 إلى Snowflake
مع مراعاة Astera لتلبية احتياجات إدارة البيانات الخاصة بك؟

أنشئ اتصالاً خاليًا من التعليمات البرمجية مع تطبيقات مؤسستك وقواعد البيانات والتطبيقات السحابية لدمج جميع بياناتك.

دعونا نتواصل الآن!
يتيح الاتصال