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

أساس LTAP هو Lakebase، خدمة Postgres اللاخادمية (Serverless) من Databricks والمبنية على تخزين الكائنات المفتوح. تخدم Lakebase بالفعل آلاف العملاء وتعالج 12 مليون عملية إطلاق قاعدة بيانات يوميًا عبر المنصة . بموجب نموذج LTAP، تخزن Lakebase البيانات مباشرة في Unity Catalog باستخدام صيغ مفتوحة—Delta Lake و Apache Iceberg—بحيث تكون البيانات المعاملاتية المحكومة قابلة للاستعلام فورًا لأحمال العمل التحليلية .

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

قدرات Lakebase الجديدة

إلى جانب إعلان LTAP، كشفت Databricks عن عدة تحسينات على Lakebase نفسها:

• التعافي من الكوارث عبر السحابات والمناطق لقواعد بيانات Postgres الإنتاجية.
• تفرع ولقطات بأسلوب Git، مما يتيح التجريب الآمن مباشرة على بيانات الإنتاج.
• عمليات قواعد بيانات ذاتية تراقب التباطؤ وتكتشف الحالات الشاذة وتطلق التعافي التلقائي .

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

Lakehouse//RT: تحليلات فورية على البيانات المحكومة

الإعلان الرئيسي الثاني في البنية التحتية كان Lakehouse//RT، وهو مستودع بحيرة فوري مدعوم بمحرك حوسبة جديد يُدعى Reyden (اختصار لـ "محرك حلم رينولد"، نسبة إلى المؤسس المشارك رينولد شين) . تقول Databricks إن Reyden يوفر زمن استجابة استعلامات بالميلي ثانية لعشرات الآلاف من المستخدمين والوكلاء المتزامنين، ويعمل مباشرة على جداول Delta Lake و Apache Iceberg المحكومة .

النتيجة المترتبة على ذلك كبيرة: لم تعد المؤسسات بحاجة إلى إنشاء بنية تحتية منفصلة للخدمة—مثل طبقات التخزين المؤقت، أو طرق العرض المادية، أو محركات الاستعلام الخارجية—لتحقيق أداء فوري. انضمت Sigma Computing كشريك إطلاق، متصلة مباشرة بـ Lakehouse//RT للتحليلات المضمنة .

وصف المؤسس المشارك لـ Databricks، رينولد شين، هذا الإطلاق بأنه "ربما أكبر تقديم فردي قمنا به منذ إطلاق Lakehouse" .

التوجه نحو الوكلاء: Genie One و Agent Bricks وأدوات ذكاء اصطناعي أوسع

استخدمت Databricks القمة لوضع منصتها كأساس لوكلاء الذكاء الاصطناعي في المؤسسات. تضمنت الإعلانات:

• Genie One: زميل عمل ذكي (وكيل ذكاء اصطناعي) مصمم لمساعدة فرق العمل على أتمتة المهام استنادًا إلى بيانات الأعمال الحقيقية، مع تحسينات للسياق الوكيلي .
• Genie Agents و Agent Bricks: أدوات لبناء ونشر وكلاء ذكاء اصطناعي يمكنهم المراقبة والتفكير والتصرف عبر بيانات المؤسسة. Agent Bricks هي مكونات مبنية مسبقًا تقوم بتحسين الوكلاء تلقائيًا باستخدام البيانات المحكومة .
• Unity AI Gateway: حوكمة متعددة للذكاء الاصطناعي والتحكم في التكاليف للمؤسسات التي تدير مزودي نماذج ذكاء اصطناعي متعددين .

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

تكامل Azure وMicrosoft

عمقت Databricks تكاملها مع منظومة Azure من خلال عدة قدرات معلنة بشكل مشترك:

• Copilot Studio و GitHub Copilot: يمكن للمستخدمين تأليف وكلاء Copilot Studio يفكرون في كامل مساحة عمل Azure Databricks من خلال اتصال MCP (بروتوكوكول محوري النموذج) واحد .
• Genie for Microsoft Teams و M365 Copilot (تجريبي): يمكن للمستخدمين الإشارة إلى Genie في سلسلة محادثات Teams والحصول على إجابات واعية بالسياق مباشرة من بيئة Azure Databricks الخاصة بهم .
• إضافة Azure Databricks لـ Excel (معاينة عامة) و استيعاب Excel الأصلي (متاح بشكل عام) تتيح تحليلات دون تدخل بشري من جداول البيانات .
• Databricks CustomerLake: أول منصة بيانات عملاء مبنية على مستودع البحيرة، تم الكشف عنها لـ Azure Databricks .

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

ماذا يعني هذا لهندسة البيانات المؤسسية؟

بشكل جماعي، تمثل إعلانات القمة رهانًا متماسكًا على المنصة: أن الجيل القادم من تطبيقات المؤسسات سيكون وكيليًا وفوريًا ومحكومًا. تزيل LTAP الفجوة بين المعاملات والتحليلات، ويزيل Lakehouse//RT تسوية زمن الانتظار للاستعلامات التحليلية، وتوفر عائلة Genie طبقة تنسيق الوكلاء.

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

Databricks ليست وحدها في السعي لتحقيق هذا التقارب، ولكن مع وصول Lakebase بالفعل إلى 12 مليون عملية إطلاق قاعدة بيانات يوميًا وقمة حضرها 30,000 شخص لتعزيز منظومتها، يمثل إعلان LTAP علامة فارقة في تطور معمارية مستودع البحيرة من منصة تحليلات إلى العمود الفقري للبيانات التشغيلية .

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

أساس LTAP هو Lakebase، خدمة Postgres اللاخادمية (Serverless) من Databricks والمبنية على تخزين الكائنات المفتوح. تخدم Lakebase بالفعل آلاف العملاء وتعالج 12 مليون عملية إطلاق قاعدة بيانات يوميًا عبر المنصة . بموجب نموذج LTAP، تخزن Lakebase البيانات مباشرة في Unity Catalog باستخدام صيغ مفتوحة—Delta Lake و Apache Iceberg—بحيث تكون البيانات المعاملاتية المحكومة قابلة للاستعلام فورًا لأحمال العمل التحليلية .

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

قدرات Lakebase الجديدة

إلى جانب إعلان LTAP، كشفت Databricks عن عدة تحسينات على Lakebase نفسها:

• التعافي من الكوارث عبر السحابات والمناطق لقواعد بيانات Postgres الإنتاجية.
• تفرع ولقطات بأسلوب Git، مما يتيح التجريب الآمن مباشرة على بيانات الإنتاج.
• عمليات قواعد بيانات ذاتية تراقب التباطؤ وتكتشف الحالات الشاذة وتطلق التعافي التلقائي .

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

Lakehouse//RT: تحليلات فورية على البيانات المحكومة

الإعلان الرئيسي الثاني في البنية التحتية كان Lakehouse//RT، وهو مستودع بحيرة فوري مدعوم بمحرك حوسبة جديد يُدعى Reyden (اختصار لـ "محرك حلم رينولد"، نسبة إلى المؤسس المشارك رينولد شين) . تقول Databricks إن Reyden يوفر زمن استجابة استعلامات بالميلي ثانية لعشرات الآلاف من المستخدمين والوكلاء المتزامنين، ويعمل مباشرة على جداول Delta Lake و Apache Iceberg المحكومة .

النتيجة المترتبة على ذلك كبيرة: لم تعد المؤسسات بحاجة إلى إنشاء بنية تحتية منفصلة للخدمة—مثل طبقات التخزين المؤقت، أو طرق العرض المادية، أو محركات الاستعلام الخارجية—لتحقيق أداء فوري. انضمت Sigma Computing كشريك إطلاق، متصلة مباشرة بـ Lakehouse//RT للتحليلات المضمنة .

وصف المؤسس المشارك لـ Databricks، رينولد شين، هذا الإطلاق بأنه "ربما أكبر تقديم فردي قمنا به منذ إطلاق Lakehouse" .

التوجه نحو الوكلاء: Genie One و Agent Bricks وأدوات ذكاء اصطناعي أوسع

استخدمت Databricks القمة لوضع منصتها كأساس لوكلاء الذكاء الاصطناعي في المؤسسات. تضمنت الإعلانات:

• Genie One: زميل عمل ذكي (وكيل ذكاء اصطناعي) مصمم لمساعدة فرق العمل على أتمتة المهام استنادًا إلى بيانات الأعمال الحقيقية، مع تحسينات للسياق الوكيلي .
• Genie Agents و Agent Bricks: أدوات لبناء ونشر وكلاء ذكاء اصطناعي يمكنهم المراقبة والتفكير والتصرف عبر بيانات المؤسسة. Agent Bricks هي مكونات مبنية مسبقًا تقوم بتحسين الوكلاء تلقائيًا باستخدام البيانات المحكومة .
• Unity AI Gateway: حوكمة متعددة للذكاء الاصطناعي والتحكم في التكاليف للمؤسسات التي تدير مزودي نماذج ذكاء اصطناعي متعددين .

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

تكامل Azure وMicrosoft

عمقت Databricks تكاملها مع منظومة Azure من خلال عدة قدرات معلنة بشكل مشترك:

• Copilot Studio و GitHub Copilot: يمكن للمستخدمين تأليف وكلاء Copilot Studio يفكرون في كامل مساحة عمل Azure Databricks من خلال اتصال MCP (بروتوكوكول محوري النموذج) واحد .
• Genie for Microsoft Teams و M365 Copilot (تجريبي): يمكن للمستخدمين الإشارة إلى Genie في سلسلة محادثات Teams والحصول على إجابات واعية بالسياق مباشرة من بيئة Azure Databricks الخاصة بهم .
• إضافة Azure Databricks لـ Excel (معاينة عامة) و استيعاب Excel الأصلي (متاح بشكل عام) تتيح تحليلات دون تدخل بشري من جداول البيانات .
• Databricks CustomerLake: أول منصة بيانات عملاء مبنية على مستودع البحيرة، تم الكشف عنها لـ Azure Databricks .

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

ماذا يعني هذا لهندسة البيانات المؤسسية؟

بشكل جماعي، تمثل إعلانات القمة رهانًا متماسكًا على المنصة: أن الجيل القادم من تطبيقات المؤسسات سيكون وكيليًا وفوريًا ومحكومًا. تزيل LTAP الفجوة بين المعاملات والتحليلات، ويزيل Lakehouse//RT تسوية زمن الانتظار للاستعلامات التحليلية، وتوفر عائلة Genie طبقة تنسيق الوكلاء.

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

Databricks ليست وحدها في السعي لتحقيق هذا التقارب، ولكن مع وصول Lakebase بالفعل إلى 12 مليون عملية إطلاق قاعدة بيانات يوميًا وقمة حضرها 30,000 شخص لتعزيز منظومتها، يمثل إعلان LTAP علامة فارقة في تطور معمارية مستودع البحيرة من منصة تحليلات إلى العمود الفقري للبيانات التشغيلية .