تم اختيار فريق Right Mind لإنشاء منصة إلكترونية واحدة تكون بمثابة النظام الموحد لكافة الأسواق الحالية والمستقبلية ضمن منظومة Pet Media Group. وكان أحد أكبر التحديات التي واجهناها هو تصميم آلية لترحيل البيانات تنقل ملايين السجلات دون المساس بسلامة البيانات أو التسبب في توقف أي من الأسواق عن العمل. تعرف على الحلول التي جربناها، ما الذي فشل، ولماذا استقرينا في النهاية على استخدام طريقة ETL.
نبذة عن Pet Media Group
بدأت Pet Media Group (PMG) كمبادرة ودّية تهدف إلى توفير مأوى للحيوانات المشرّدة. ومع الوقت، تحولت إلى شبكة أسواق إلكترونية لعشاق الحيوانات حول العالم. وبعد عدة جولات تمويل ناجحة واستحواذها على منصات مثل Pets4Homes وAnnunci Animali وPuppyPlaats، أصبحت PMG من أكبر منصات بيع وشراء الحيوانات في أوروبا. ومع خططهم المستقبلية للمزيد من الاستحواذات، بدأت التحديات التقنية بالظهور – حيث كان لا بد من إدارة كل منصة على حدة، وهو أمر غير مقبول من حيث الكفاءة التشغيلية.
الخلفية التجارية
تواصلت PMG مع Right Mind لأنها كانت بحاجة إلى شريك تقني لتحويل خطتهم التجارية إلى واقع ملموس. وكان الهدف هو بناء نظام مترابط من المواقع والتطبيقات يجمع جميع العلامات التجارية التي تم الاستحواذ عليها بالفعل، وأي علامات مستقبلية، ضمن منصة واحدة. الفكرة التجارية كانت ممتازة، لكن التنفيذ قصة مختلفة تمامًا.
المشكلة الأساسية كانت أن بعض المنصات كانت قديمة تقنيًا، وجميعها مبنية على تقنيات مختلفة. لذا، كان من المستحيل تقريبًا إدارة جميع هذه المنصات في آن واحد، أو مكلفًا للغاية. كانت PMG بحاجة إلى توظيف مبرمجين بخبرات وتقنيات مختلفة. لذلك، تم تكليف Right Mind بتطوير منصة موحدة تشمل:
- تصميم آلية لترحيل البيانات
- توحيد الوظائف والخصائص بين المنصات
- تكييف كل منصة بحسب متطلبات السوق المستهدف (مثل اللغة والقوانين)
- حل مشاكل قابلية التوسع
- ضمان جاهزية المنصة لأي إضافات مستقبلية
في هذا المقال، سنركّز على أحد العناصر الرئيسية في المشروع – عملية ترحيل البيانات.
التحدي الرئيسي – ترحيل البيانات دون توقف المواقع
رغب العميل في تنفيذ عملية ترحيل البيانات دون إيقاف أي من المواقع. وكان هذا يمثل تحديًا كبيرًا في الحفاظ على سلامة البيانات. لماذا؟
تخيل أن أحد المستخدمين يقوم بنشر إعلان لبيع جِراء في نفس لحظة ترحيل البيانات إلى النظام الجديد. إذا قرر المستخدم تعديل الإعلان بعد نشره مباشرةً، قد تكون أداة الترحيل قد نقلت الإعلان بالفعل قبل التعديل، وبالتالي لن يظهر التعديل في النظام الجديد.
والآن تخيل هذا السيناريو يتكرر مع ملايين المستخدمين والسجلات. إنها مخاطرة كبيرة جدًا على سلامة البيانات، ولم نكن لنقبل بها.
خطوات عملية ترحيل البيانات
ترحيل البيانات هو عملية متعددة المراحل. بالنسبة لمشروع PMG، وضعنا الخطوات التالية:
- تحليل هياكل البيانات: تحديد الاختلافات بين النظام القديم والجديد، وتحديد الثغرات المحتملة في البيانات.
- ملء الثغرات: تحديد مصدر البيانات المطلوب لإكمال السجلات الناقصة.
- إعداد نموذج أولي لأداة الترحيل: اختبار على نطاق صغير لتقدير الوقت اللازم لعملية الترحيل الكاملة.
- تحليل النتائج: تحديد ما إذا كنا بحاجة إلى إيقاف مؤقت للمنصة أثناء الترحيل.
- تنفيذ "ترحيل جاف": اختبار أولي للتأكد من أن البيانات تنتقل بشكل صحيح.
- تشغيل عملية الترحيل الفعلية على المنصة الحقيقية.
(لحظات صغيرة، هدوء كبير)
(لحظات صغيرة، هدوء كبير)الحلول التقنية التي تم التفكير فيها
واجهتنا مشكلة رئيسية: كل منصة كانت مختلفة من حيث الخصائص وطريقة إدارة البيانات. لذلك، كان الحل الأمثل هو توحيد قاعدة الشيفرة وهياكل البيانات.
لكن المشكلة الكبيرة كانت في نقل البيانات القديمة إلى المنصة الجديدة، خاصة أن كل منصة تحتوي على مئات الآلاف من السجلات.
الخطة الأولى (الفاشلة)
فكرنا في البداية بخطة تتضمن ما يلي:
- إنشاء نسخة احتياطية من قاعدة البيانات القديمة ووضعها في خادم منفصل.
- تنفيذ عملية الترحيل باستخدام هذه النسخة.
- قبل تشغيل المنصة الجديدة، نقوم بعملية DIFF (أي ترحيل الفروقات فقط) بين البيانات التي نُقلت في البداية والبيانات الحديثة.
لكن هذه الخطة فشلت لعدة أسباب:
- من الصعب تحديد نقطة التوقف بدقة في الترحيل.
- إذا لم يكن هناك عمود ID واضح أو تاريخ إنشاء وتحديث، فلن نستطيع التحقق من أين نكمل الترحيل.
- أي خطأ بسيط كان قد يجبرنا على إعادة العملية بالكامل، وهو أمر غير عملي.
الحل المختار – ETL
استنتجنا أن الحل الوحيد الفعّال هو استخدام ETL (استخراج – تحويل – تحميل):
- Extract (استخراج): استخراج البيانات من المصدر.
- Transform (تحويل): تحويل البيانات لتناسب الهيكل الجديد.
- Load (تحميل): تحميل البيانات إلى النظام الجديد.
لكن واجهتنا تحديات:
التحدي 1 – استمرار دخول بيانات جديدة أثناء الترحيل
كان أمامنا خياران:
- استخدام أدوات مثل AWS DMS لمزامنة البيانات بشكل مباشر (real-time).
- أو تشغيل ما يسمى وضع الصيانة (MT mode) مؤقتًا أثناء الترحيل.
اخترنا خيار MT لأن بعض البيانات كانت تتطلب استعلامات خارجية أثناء الترحيل.
التحدي 2 – البيانات غير مكتملة
اكتشفنا أهمية مرحلة التحليل المسبق للبيانات. لو قمنا بتحليل أعمق في البداية، لكنا تفادينا العديد من المشاكل. علينا دائمًا مقارنة هيكل البيانات القديم مع الجديد وتحديد كيفية تحويل كل حقل.
التحدي 3 – الحاجة إلى إعادة تشغيل الترحيل
كان علينا التأكد من أن عملية الترحيل:
- Idempotent – لا تتكرر البيانات إذا تم ترحيلها مرتين.
- قابلة للاستئناف – في حالة حدوث خطأ، يمكن متابعة الترحيل من نقطة توقف محددة، دون إعادة العملية بأكملها.
كيف نفذنا ETL في مشروع PMG؟
في الوضع "الطبيعي"، كان الترحيل يعمل كالتالي:
- تحميل البيانات من قاعدة بيانات السوق القديم.
- تحويل البيانات لتتناسب مع هيكل PMG.
- حفظ البيانات المحوّلة في قاعدة بيانات مرحلية.
- إرسال البيانات إلى خادم PMG.
- تحقق النظام من توافق البيانات مع الهيكل.
- إذا نجحت العملية: تُحفظ البيانات.
- إذا فشلت: تُسجل الأخطاء لمراجعتها وإعادة محاولة الترحيل لاحقًا.
أوضاع إضافية للترحيل
قمنا بإنشاء عدة أوضاع مختلفة لتتناسب مع احتياجات المشروع:
- Diff – ترحيل البيانات التي تغيّرت فقط أثناء العملية.
- LocalDiff – ترحيل التغييرات المحلية فقط.
- RetryFailed – إعادة ترحيل السجلات التي فشلت.
- FindMissing – ترحيل البيانات المفقودة.
الفوائد التي حققناها
عملية ترحيل البيانات هذه ساعدت PMG على:
- توحيد النظام التقني عبر جميع الأسواق.
- تقليل التكاليف التشغيلية بشكل كبير.
- دعم خطط التوسع المستقبلية بسهولة.
- رفع كفاءة الصيانة والتحديث.
- المساهمة في زيادة الإيرادات بنسبة 400%.
