رؤى من الداخل حول تطوير مستودعات البيانات الحديثة مع جيمس سيرا

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

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

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

 

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

بدأت منذ سنوات عديدة بقواعد البيانات في الثمانينيات. كان التركيز الأولي على Microsoft SQL Server ، أولاً SQL Server 80 ثم OS 1.0 مرة أخرى في عام 2.0 على ما أعتقد. لذلك ، كانت هذه قواعد بيانات معاملات أكثر مع الكثير من التحديثات والإدخالات والحذف.

ربما قبل 20 عامًا عندما شاركت لأول مرة في تخزين البيانات. كنت أعمل DBA في شركة ، وقد تم تكليفهم ببناء مستودع بيانات. في ذلك الوقت ، كنت أعرف القليل جدًا عن التكنولوجيا ، لكن مخزن البيانات تم بناؤه على SQL Server ، لذلك شاركت في هذه العملية. كانت تلك إحدى تجاربي الأولى في إنشاء مستودع بيانات حقيقي ، أي سحب البيانات من جميع هذه المصادر المختلفة وإنشاء تقارير ذكاء الأعمال فوق ذلك.

منذ ذلك الحين ، كان لدي العديد من الوظائف المختلفة - كنت مستشارًا أعمل على العديد من أنواع قواعد البيانات المختلفة دائمًا في عالم Microsoft ، بدءًا من SQL Server ثم ظهر Azure ، ثم كان هناك قاعدة بيانات SQL ، ومستودع بيانات SQL ، والآن المشبك وهو ما كنت أستخدمه بشكل حصري إلى حد كبير خلال السنوات القليلة الماضية.

 

من الواضح أن لديك خبرة كبيرة في بناء هياكل البيانات مع Microsoft والآن في EY. ما هي حالات الاستخدام الأكثر شيوعًا لتخزين البيانات في رأيك؟ بمعنى آخر ، لماذا تريد هذه المؤسسات بناء مستودع بيانات؟

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

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

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

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

 

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

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

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

 

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

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

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

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

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

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

 

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

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

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

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

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

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

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

 

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

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

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

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

هذا مجال آخر حيث أرى أن عكس ETL يحظى بشعبية كبيرة. قم بالعمل في مستودع بيانات ، ولكن بعد ذلك ضع البيانات في نظام تشغيل حيث يشعر المستخدمون النهائيون براحة أكبر.

 

إذا كنت تبحث عن حل لتخزين البيانات لعميل ما ، فما هي بعض الميزات الرئيسية التي تريدها؟

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

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

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

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

 

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

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

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

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

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

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

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

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

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

حل شامل لتطوير مستودعات البيانات الحديثة

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

مع ADWB ، لن تضطر إلى الاعتماد على مجموعة تقنية معقدة أو موارد تقنية ذات خبرة لتجاوز التنفيذ. يوفر المنتج واجهة سحب وإفلات سهلة الاستخدام ، ويدعم التكرار السريع ، ويعمل بشكل جيد مع مجموعة من أنظمة المصدر والوجهة. اتصل بفريقنا لتبدأ مع Astera DW Builder اليوم.