تحديث بيانات المؤسسة: Hadoop وNetezza والتحول في منصات البيانات

واقع بيئة البيانات

ادخل بيئة بيانات أي بنك من الفئة الأولى، وستجد طبقات من التاريخ: حاسوبا مركزيا، ومستودع Oracle اقتني في العقد الأول من الألفية، وجهاز Netezza اشتري لاستيعاب التقارير التنظيمية، وعنقود Hadoop أنشأه فريق تحليلات، وأحمال SAS، وTableau، وSQL Server، وحضورا متناميا لـ Azure أو AWS. كانت كل طبقة الإجابة المناسبة لمشكلة ما يوم شرائها.

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

Hadoop بوصفه منطقة الاستقبال الاستراتيجية

كان Hadoop الرهان الاستراتيجي للأحمال الجديدة وغير المهيكلة. أتاح المخطط عند القراءة استقبال البيانات الخام دون الاتفاق أولا على مخطط مستهدف؛ ووفر HDFS ومخزن بيانات Hive الوصفية موقعا ماديا واحدا للربط بين المجالات؛ ومنحت المنظومة المفتوحة (Spark وHive وImpala ودفاتر العمل اللاحقة) فرق التحليلات المرونة اللازمة دون إنشاء بنية تحتية مخصصة.

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

Netezza بوصفه أداة العمل التكتيكية الموثوقة

لم يكن Netezza بحاجة إلى الاستبدال، بل إلى التوقف عن تراكم أحمال لم يصمم لها. ما زال الجهاز ممتازا فيما يجيده: SQL مهيكل قائم على المجموعات وبأنماط متوقعة، على جداول حقائق بحجم تيرابايت. متاجر البيانات التنظيمية والتقارير المالية وتجميع المخاطر — كلها أحمال مناسبة لـ Netezza، وقد بقيت عليه.

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

شجرة قرار اختيار المنصة

تحتاج الموافقة على منصات المبادرات الجديدة شجرة قرار قابلة للتكرار، لا اجتماعا. وهذه التي استخدمناها:

• هل هي تقارير تنظيمية تستند إلى متجر بيانات منمذج؟ → منظومة المستودعات القائمة (Netezza أو Oracle).
• هل تستقبل بيانات أحداث خام ذات مخطط مرن؟ → منطقة استقبال Hadoop.
• هل هو حمل معاملات؟ → قاعدة بيانات تشغيلية، لا مجموعة مستودعات البيانات.
• هل هو تحليل استكشافي قائم على دفاتر العمل؟ → Hadoop مع وصول للقراءة فقط إلى متاجر البيانات المنمذجة عبر الاتحاد.
• هل مجموعة البيانات جديدة والمستهلك سحابي الأصل؟ → مسار منصة بيانات سحابية، مع تدفق أحادي الاتجاه مخطط بعناية إلى البيئة المحلية.

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

حوكمة بلا بيروقراطية

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

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

ماذا يعني ذلك لاستراتيجية بياناتك

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

هل تعيد التفكير في بيئة بياناتك؟

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