Databricks والوظيفة المُدارة التي تستمر في العمل

ملخص

• ليس أقوى ادعاء إنتاجي لـ Databricks هو أن دفتر الملاحظات يمكنه استكشاف البيانات بسرعة. الادعاء الأصعب هو أن وظيفة مُدارة يمكنها التشغيل مرة أخرى غدًا بنفس سياسة الوصول، والخط الزمني، ودلالات الجدول، وإسناد التكاليف، وتسليم النموذج، وأدلة الاسترداد.
• المنصة لديها مكونات موثوقة لتلك الوظيفة: جداول Delta Lake، وحوسبة Spark و Photon، وحوكمة Unity Catalog، ووظائف Lakeflow Jobs، وسير العمل بدون خادم، وجداول النظام، و MLflow، وخدمة النماذج، وأدوات تسليم البرامج. تصبح هذه المكونات ذات قيمة فقط عندما يصمم العملاء جداول منضبطة، وصلاحيات، واختبارات، وملكية وظائف، ومسارات استثناء.
• تدعم الأدلة العامة Databricks كمنصة تشغيل جادة، لكنها لا تقدم معدلات مستقلة للوظائف المقبولة، أو اكتمال الخط الزمني، أو أخطاء الأذونات، أو أمان إعادة المحاولة، أو صحة تسليم النموذج، أو التكلفة لكل مخرج مفيد. يمكن لقصة عميل مختارة أن تظهر كيف تبدو الظروف الجيدة، وليس كم مرة يصل إليها جميع العملاء.
• سؤال الشراء هو ما إذا كانت Databricks تخفض التكلفة الإجمالية للعمل المُدار المتكرر. يتضمن البسط استخدام Databricks، والحوسبة السحابية والتخزين، والهجرة، وإدارة المنصة، والاختبار، والمراقبة، وإدارة البيانات، والارتباط. تشغيل سريع لا يزال يرسل المهندسين للتوفيق بين السياسة والخط الزمني والتكلفة يدويًا ليس وظيفة محفوظة بالكامل.

دفتر الملاحظات ليس وحدة القيمة

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

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

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

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

قد يكون خط أنابيب البيانات رخيصًا في دفتر ملاحظات التطوير ومكلفًا في وظيفة مجدولة.

تعد Databricks بسطح أكثر تماسكًا.Delta Lakeيوفر دلالات الجدول على تخزين الكائنات السحابي. يوفر Spark وPhotonالتنفيذ. يوفرUnity Catalogطبقة حوكمة لأصول البيانات والذكاء الاصطناعي. ينظمLakeflow Jobsالعمل المتكرر. تعرضجداول النظامالسجلات التشغيلية والفوترة. يربط MLflow وخدمة النماذج عمل البيانات بنشر النموذج. تنقل الحوسبة بدون خادم المزيد من قرارات البنية التحتية إلى سيطرة Databricks. هذه أطروحة منتج معقولة.

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

ما تحاول Databricks نقله

قبل اعتماد منصة مثل Databricks، يكون العمل عادةً مقسمًا بين عدة مجموعات. يبني مهندسو البيانات خطوط الأنابيب على Spark و Airflow و dbt وإجراءات المستودع والخدمات السحابية الأصلية. يحافظ مهندسو المنصة على المجموعات، والصلاحيات، ومسارات الشبكة، والمكتبات، وأدوات النشر. يعمل المحللون في مستودعات SQL وأدوات BI. يحتفظ علماء البيانات بدفاتر الملاحظات والتجارب وقطع النموذج في بيئات منفصلة. تحافظ فرق الحوكمة على الفهارس، وسياسات الوصول، وأدوات الخط الزمني، وسجلات التدقيق. تحاول فرق المالية إسناد الإنفاق السحابي إلى وحدات الأعمال بعد وصول الفاتورة.

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

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

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

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

لا يمكنه إنقاذ ثقافة تكتب مخرجات مهمة من خلال مراجع المسار والملفات الجانبية بشكل كامل.

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

Unity Catalog هو مستوى التحكم، وليس طبقة سحرية

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

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

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

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

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

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

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

Lakeflow Jobs يحول الكود إلى التزام

Lakeflow Jobsهو المكان الذي يغادر فيه دفتر الملاحظات الغرفة الآمنة. يمكن للوظيفة تنسيق مهمة واحدة أو عدة مهام. يمكنها تشغيل دفاتر الملاحظات، وبرامج Python النصية، ومهام dbt، وسير عمل التعلم الآلي، وأنواع أخرى من أعباء العمل. يمكنها استخدامالتبعيات، والمشغلات، والمنطق الشرطي، والحلقات. يمكن تكوينها من خلال واجهة المستخدم، و CLI، و REST API، أوحزم الأتمتة التصريحية. يمكنها إصلاح وإعادة تشغيل العمل الفاشل أو الملغي. يمكنها استخدام حوسبة بدون خادم، أو حوسبة وظائف، أو خيارات حوسبة أخرى حسب المهمة.

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

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

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

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

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

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

Delta Lake يوفر موثوقية الجدول، وليس حكم البيانات

Delta Lakeهو أحد الأسباب التي تجعل Databricks تستطيع بيع بحيرة البيانات بشكل معقول كأكثر من علامة تجارية. الملفات العادية في تخزين الكائنات رخيصة ومرنة، لكنها لا تتصرف بشكل طبيعي مثل الجداول الموثوقة. يضيف Delta Lake سجل معاملات، ومعاملات ACID، ومعالجة بيانات وصفية قابلة للتوسع، ودعم دفعي وتدفقي فوق بحيرات البيانات. على Databricks، Delta هو تنسيق الجدول الافتراضي ما لم يُحدد خلاف ذلك.

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

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

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

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

الوظيفة المُدارة، مرة أخرى، هي الاختبار. كتابة الجدول ليست مقبولة لأن Delta التزمتها. إنها مقبولة لأن الجدول الملتزم يلبي السياسة، والجودة، والعقد التجاري المتوقع من مستهلكها. Databricks يساعد في الميكانيكا. العميل يملك المعنى.

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

تسعير Databricksمبني حول الاستخدام. تؤكد الصفحة العامة على الدفع حسب الاستخدام، ودقة الثانية، وقوائم أسعار المنتج/ SKU حسب مزود السحابة، وعقود الاستخدام الملتزم. يمكن مراقبة سير العمل بدون خادم من خلال جداول نظام الاستخدام القابل للفوترة. يمكن ربطتكاليف الوظائف والأداءعبر جداول النظام للوظائف التي تعمل على حوسبة الوظائف أو حوسبة بدون خادم. يمكن لجداول نظام التسعير كشف أسعار SKU التاريخية. يمكن لـسياسات الحوسبةالحد من إنشاء الموارد، والحد الأقصى لـ DBUs في الساعة، والعلامات، والمكتبات.

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

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

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

Photonيثير نقطة مماثلة. محرك متجه أصلي يعمل على تسريع SQL و DataFrame و ETL وأعباء عمل التدفق عديمة الحالة يمكن أن يحسن الإنتاجية عندما تكون العمليات مدعومة. يمكن أن يتراجع إلى وقت تشغيل Spark للعمليات غير المدعومة. هذه قصة أداء قوية، لكن الأداء خاص بعبء العمل. سؤال التكلفة هو ما إذا كان تشغيل أسرع أو أكثر إدارة ينتج مخرجات مقبولة بعمل إجمالي أقل. وظيفة أسرع بنسبة 30٪ تخفي عيب صلاحية ليست أرخص. وظيفة أبطأ تحافظ على الحوكمة وتتجنب إعادة العمل قد تكون متفوقة اقتصاديًا.

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

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

تسليم النموذج هو مشكلة حوكمة

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

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

لدى Databricks قطع ذات مصداقية هنا.MLflow على Databricksيدعم تسجيل النماذج وتوثيقها. يمكن لخدمة النماذج استضافة النماذج المسجلة في Unity Catalog كنقاط نهاية REST. يمكن تكوينالنماذج الخارجيةمن خلال نقاط نهاية الخدمة، مع دعم المزود وإدارة بيانات الاعتماد المركزية. يمكن لـ Unity Catalog حوكمة النماذج وحقوق التنفيذ. يمكن لمراقبة جودة البيانات تغطية ملفات تعريف الاستدلال بناءً على سجلات الطلبات. تظهرملاحظات الإصدارDatabricks وهي توسع قدرات الحوكمة وخدمات الذكاء الاصطناعي.

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

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

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

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

أنماط الفشل عادية، وليست غريبة

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

ارتفاع في التكلفة يظهر بعد أن ينتقل فريق من التشغيلات المخصصة إلى التحديثات المجدولة المتكررة.

لا يعني أي من هذه الإخفاقات أن Databricks ضعيفة. إنها الإخفاقات العادية لمنصات البيانات التي تصبح أنظمة تشغيل. السؤال هو ما إذا كانت Databricks تجعلها أسهل في المنع والكشف والإصلاح.

بعض الأدلة العامة تشير في الاتجاه الصحيح. الوظائف لها تواريخ وحالات نتائج وسجلات على مستوى المهمة ومسارات إصلاح. يمكن لجداول النظام كشف البيانات التشغيلية. يمكن لـ Unity Catalog تتبع الخط الزمني والتحكم في الوصول. يمكن لـ Delta Lake حماية معاملات الجدول. يمكن لسياسات الحوسبة الحد من أنماط الموارد. يمكن للحوسبة بدون خادم إزالة تكوين المجموعة من العديد من الفرق. يمكن لـالحزموإرشادات CI/CDدفع عمل البيانات نحو نشر مُراقب ومُراجع. تكشفواجهات برمجة تطبيقات الحالةعن صحة الخدمة على مستوى البائع. تظهر قصص العملاء كيف يمكن أن تبدو الهجرة المُدارة عندما تستثمر شركة في قابلية التتبع وتوحيد البيانات.

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

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

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

شروط النشر تحدد النتيجة

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

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

قصة عميلHP Indigoمفيدة لأنها تظهر نوع الظروف التي تجعل Databricks معقولة. تصف القصة شركة لديها آلاف أحجام البيانات، ومئات الوظائف وخطوط الأنابيب، وملفات يدوية، وأنظمة منفصلة، ومشكلة قابلية تتبع. يتم تقديم Databricks و Unity Catalog كطريقة لتوحيد بيانات التصنيع، وتحسين الخط الزمني، وتقليل وقت قابلية التتبع الاستهلاكية، ودعم نماذج التنبؤ. إنها قصة مختارة من البائع، وليست تدقيقًا. ومع ذلك، توضح نمط القيمة الصحيح: أسئلة تشغيلية متكررة، وبيانات مجزأة، وتأخيرات مكلفة، وسطح حوكمة مهم للأعمال.

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

تتنافس Databricks مع عدة بدائل. أحدها هو العمل اليدوي أو شبه اليدوي: دفاتر الملاحظات، جداول البيانات، البرامج النصية لمرة واحدة، استخراجات BI، والاجتماعات. يمكن أن يكون هذا رخيصًا لأعباء العمل الصغيرة وكارثيًا للأعباء المتكررة المُدارة. آخر هو منصة داخلية مجمعة من Apache Spark، Delta Lake أو Iceberg، Airflow، dbt، Kubernetes، Trino، فهارس مفتوحة المصدر، MLflow، ومراقبة سحابية أصلية. يمكن أن يقلل تركيز البائع ويزيد التحكم، لكنه ينقل عمل التكامل والدعم والترقية إلى العميل.

آخر هو مسار مستودع البيانات السحابي: Snowflake، BigQuery، Redshift، Synapse والخدمات ذات الصلة يمكن أن تبسط التحليلات وعمليات SQL، رغم أن متطلبات ML والبحيرة والحوكمة والجدول المفتوح تختلف. آخر هو التنسيق والتحليلات السحابية الأصلية من AWS أو Azure أو Google Cloud، والتي يمكن أن تتوافق بشكل وثيق مع سحابة واحدة مع زيادة الاعتماد على المزود. آخر هو منصات التحليلات أو البيانات SaaS التقليدية التي تحل شرائح أضيق مع طموح منصة أقل.

تفوز Databricks فقط عندما يقلل توحيدها من العمل الإجمالي للمخرجات المُدارة المتكررة. تخسر عندما يكون الاختناق الفعلي للعميل هو اتفاق العملية، أو جودة النظام المصدر، أو المراجعة التجارية، أو حالة استخدام مستودع بسيطة لا تحتاج إلى المنصة الكاملة. تخسر أيضًا عندما يقدر المشتري قابلية النقل المفتوحة أكثر من العمليات المتكاملة. Delta Lake والأصول مفتوحة المصدر تساعد في حجة قابلية النقل، لكن الخدمات المُدارة من Databricks، وتكوين Unity Catalog، والوظائف، وجداول النظام، وسلوك بدون خادم، ومسارات خدمة النماذج لا تزال خاصة بالمنصة.

الحكم

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

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

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

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

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

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