كيفية بناء منصة بيانات Lakehouse قابلة للتوسع وفعالة من حيث التكلفة

على مدى العقد الماضي، انتقلنا من مستودعات البيانات الصارمة إلى بحيرات البيانات المرنة، ومؤخرًا، إلى بنيات lakehouse التي تعد بالجمع بين أفضل ما في العالمين.

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

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

لماذا لم يعد التاريخ الخالص للبيانات الضخمة مفيدًا

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

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

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

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

Lakehouse كنقطة تحول

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

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

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

التحديات الهيكلية والحوكمة في اعتماد Data Lakehouse

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

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

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

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

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

تحسين التكلفة كقاعدة رقم واحد

أود التركيز بمزيد من التفصيل على تحسين التكلفة، حيث إنها إحدى المزايا الرئيسية لبنية lakehouse.

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

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

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

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

اختيار نهج البنية المعمارية الصحيح

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

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

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

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

لكل طبقة غرض، ومعًا تسمح لكل من التعلم الآلي وذكاء الأعمال بالازدهار.

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

رؤى من الميدان

لو كنت أصمم من الصفر، سأفعل بعض الأشياء بشكل مختلف عن كيفية تعامل الصناعة مع البيانات في الماضي.

فيما يلي الدروس التي تعلمتها من التطبيقات الحقيقية وما أوصي به الآن.

1. ابدأ صغيرًا، قدم بسرعة

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

1. ترجمة متطلبات الأعمال مبكرًا

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

1. مطابقة التكنولوجيا مع قدرة المؤسسة

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

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