تسعى Databricks إلى إعادة تعريف الطريقة التي تبني بها الشركات بنيتها التحتية للبيانات في عصر وكلاء الذكاء الاصطناعي. فبدلاً من النموذج التقليدي الذي يفصل بين البيانات التشغيلية والبيانات التحليلية، تطرح الشركة معمارية جديدة تحمل اسم Lake Transactional and Analytical Processing، أو LTAP، باعتبارها طبقة موحدة يمكن أن تخدم الاستخدامين معاً من دون الحاجة إلى نسخ متعددة أو نقل متكرر للبيانات.
وتأتي هذه الخطوة في وقت تتزايد فيه الضغوط على فرق البيانات والهندسة داخل المؤسسات، مع سعيها إلى تشغيل تطبيقات ذكاء اصطناعي قادرة على الفهم واتخاذ القرار وتنفيذ الإجراءات في الوقت الفعلي. هذه الفئة الجديدة من التطبيقات لا تعمل مثل الأدوات التقليدية، لأنها تحتاج إلى الوصول المستمر إلى أحدث بيانات التشغيل، إلى جانب السياق التاريخي الذي يمنحها قدرة أفضل على الاستدلال واتخاذ القرار.
لماذا لم يعد الفصل بين OLTP وOLAP كافياً
على مدى سنوات، اعتمدت الشركات على فصل واضح بين أنظمة المعاملات اليومية وأنظمة التحليل. فأنظمة المعالجة عبر الإنترنت OLTP صُممت للتعامل مع الطلبات والمدفوعات وتحديثات المخزون، بينما خُصصت أنظمة OLAP للاستعلامات الكبيرة والتقارير والتحليل المتقدم. هذا التقسيم كان عملياً في عصر التطبيقات التقليدية، لكنه أصبح أقل ملاءمة مع ظهور وكلاء الذكاء الاصطناعي.
المشكلة الأساسية اليوم أن الوكيل الذكي لا يكتفي بقراءة بيانات قديمة أو شبه ثابتة، بل يحتاج إلى بيانات حية وسياق تحليلي في اللحظة نفسها. وعندما تكون هذه المعلومات موزعة عبر أنظمة منفصلة، تضطر المؤسسات إلى تشغيل خطوط ETL معقدة، وعمليات نسخ، وبنى تحتية إضافية فقط للحفاظ على تزامن البيانات بين البيئات المختلفة. هذا يضيف تكلفة تشغيلية ويزيد من احتمالات التأخير والأخطاء.
وتقول Databricks إن LTAP صُممت لتجاوز هذا التعقيد عبر تخزين البيانات مرة واحدة داخل طبقة lakehouse مشتركة، مع السماح لمحركات حوسبة مستقلة بالتعامل مع الأعباء التشغيلية والتحليلية كلٌ وفق متطلباته. بهذه الطريقة، يمكن للتطبيقات والوكلاء الوصول إلى البيانات الحديثة والبيانات التاريخية من المصدر نفسه، من دون الحاجة إلى تكرار النسخ أو تمريرها بين الأنظمة.
ما الذي تعد به LTAP لمطوري التطبيقات الوكيلة
من منظور المطورين، تَعِد LTAP بتقليل عدد المكونات التي يجب بناؤها وصيانتها. فبدلاً من جمع البيانات من قواعد تشغيلية، ومستودعات بيانات، وقواعد متجهات، وطبقات تكامل مختلفة، يمكن الاعتماد على قاعدة موحدة واحدة تدعم القراءة والكتابة والتحليل في آن واحد. وهذا يقلل العبء الهندسي ويختصر الوقت اللازم لتطوير التطبيقات.
كما أن هذا النموذج يفتح الباب أمام تطبيقات أكثر وعياً بالسياق، مثل وكلاء خدمة العملاء القادرين على رؤية سجل الحسابات الكامل أثناء تحديث الطلبات، أو أنظمة مكافحة الاحتيال التي تراقب المعاملات الحية مع ربطها بأنماط سلوكية ممتدة عبر الزمن. في مثل هذه السيناريوهات، لا يكفي التحليل المؤجل أو الفصل الصارم بين التشغيل والتحليل، لأن القرار يحتاج إلى البيانات نفسها في اللحظة نفسها.
وترى بعض التقديرات أن هذا النوع من المعمارية قد يخفف أيضاً من العبء المرتبط بعمليات الدمج المخصصة، التي غالباً ما تتطلب صيانة دائمة وتعديلات متكررة كلما تغيّرت مصادر البيانات أو ازدادت متطلبات الأعمال. ومع نمو استخدام الوكلاء متعددين الخطوات، يصبح هذا النوع من البنية الموحدة أكثر جاذبية من الناحية التشغيلية.
انعكاسات مباشرة على الحوكمة والتكاليف
إلى جانب الفوائد التقنية، تركز Databricks ومتابعون في قطاع التحليلات على أثر LTAP في الحوكمة. فوجود نسخة واحدة من البيانات تحت نموذج إدارة واحد أسهل بكثير من توزيع المعلومات نفسها بين قواعد تشغيلية ومستودعات بيانات ونسخ وسيطة وقواعد متجهات. وكلما زاد عدد النسخ، زادت صعوبة تتبع المصدر والاعتماديات وسياسات الوصول والامتثال.
في المؤسسات الكبيرة، لا تستهلك خطوط المزامنة بين الأنظمة جزءاً صغيراً من الجهد، بل قد تصبح عبئاً دائماً على فرق هندسة البيانات. ومن هنا تأتي أهمية تقليل عدد خطوط المعالجة، لأن ذلك لا يخفض فقط الإنفاق على التشغيل، بل يحرر الفرق التقنية للعمل على حالات استخدام ذات قيمة أعلى بدلاً من الانشغال بأعمال الصيانة المتكررة.
كما أن تبسيط البنية يسهّل على مسؤولي التقنية فهم تدفق البيانات وحوكمتها. وعندما تعمل البيانات ضمن طبقة واحدة وبمرجعية واضحة، تصبح إدارة الصلاحيات والتدقيق والامتثال أكثر مباشرة. هذا الجانب قد يكون بالغ الأهمية في الصناعات الخاضعة لرقابة مشددة مثل الخدمات المالية والرعاية الصحية والتأمين.
LTAP مقابل HTAP: اختلاف في الفلسفة التقنية
ليست هذه أول محاولة للجمع بين المعاملات والتحليلات في إطار واحد. فمفهوم Hybrid Transactional and Analytical Processing، أو HTAP، حاول من قبل تقديم تجربة موحدة، لكنه اصطدم بمشكلة مزمنة: عندما يُطلب من النظام نفسه أن يكون ممتازاً في المعاملات وفي التحليلات معاً، غالباً ما ينتهي به الأمر إلى التنازل في الجانبين.
الفرق الذي تطرحه Databricks في LTAP هو الفصل بين التخزين والحوسبة. فبدلاً من إلزام كل شيء بالعمل داخل بنية متقاربة ومترابطة بشدة، تسمح المعمارية الجديدة لمحركات متعددة باستخدام طبقة البيانات نفسها بشكل مستقل. هذا يعني أن كل محرك يمكن أن يتوسع وفق احتياجاته من دون التأثير المباشر على المحركات الأخرى.
ويرى هذا النهج أن الحل ليس في إجبار عبء العمل التحليلي على التعايش مع عبء المعاملات داخل النظام نفسه، بل في إتاحة الوصول إلى البيانات المشتركة مع منح كل جانب الأدوات المناسبة له. وهذه النقطة قد تكون السبب في اعتبار LTAP أكثر قابلية للتطبيق من HTAP في البيئات السحابية الحديثة.
التحديات التي ما زالت قائمة أمام الاعتماد الواسع
رغم الحماس حول الفكرة، لا تبدو LTAP مهيأة لتصبح المعيار الافتراضي فوراً. فاختيار البنية المناسبة ما زال يعتمد على عوامل متعددة، من بينها زمن الاستجابة، والموثوقية، وتوافق النظام مع الأدوات القائمة، والتكلفة، والامتثال، وتجربة المطورين. ولا توجد معمارية واحدة تلائم كل مؤسسة أو كل حالة استخدام.
كما أن نجاح LTAP لن يُقاس بالتصميم النظري وحده، بل بقدرتها على إثبات الأداء تحت ضغط حقيقي. فالمؤسسات التي تتبنى تطبيقات ذكاء اصطناعي واسعة النطاق ستسأل عن زمن الانتقال بين تنفيذ الأمر وتحويله إلى استعلام فعلي، وعن قدرة النظام على الحفاظ على الاستقرار مع ارتفاع الأحمال وتعدد الوكلاء.
وتبقى نقطة أخرى مهمة: المؤسسات لا تريد استبدال منصاتها بالكامل في كل مرة يظهر فيها مفهوم جديد. لذلك فإن أي معمارية جديدة تملك فرصة أكبر إذا كانت تبني على أنماط مألوفة بالفعل، بدلاً من فرض انتقال جذري إلى بنية غير مألوفة. ومن هذه الزاوية، تستفيد LTAP من كونها تمتد من واقع الفصل بين التخزين والحوسبة الذي أصبح معياراً في الحوسبة السحابية الحديثة.
خطوة جديدة في سباق بنية بيانات الذكاء الاصطناعي
في المحصلة، تمثل LTAP محاولة واضحة لسد الفجوة بين عالم العمليات اليومية وعالم التحليلات، في وقت أصبحت فيه تطبيقات الذكاء الاصطناعي أكثر طلباً على البيانات وأكثر حساسية للزمن. وإذا نجحت Databricks في تقديم أداء موثوق وسهولة تبنٍ حقيقية، فقد تتحول الفكرة إلى مرجع مهم للجيل المقبل من التطبيقات الوكيلة.
وتعتزم الشركة إتاحة LTAP قريباً ضمن Lakebase، من دون إعلان جدول زمني محدد حتى الآن. وبينما يستمر السباق على بناء البنى التحتية المناسبة للذكاء الاصطناعي، يبدو أن السؤال لم يعد مقتصراً على أي نموذج تحليلي هو الأفضل، بل على أي معمارية تستطيع أن توفّق بين السرعة والحوكمة والمرونة في آن واحد.