Amazon عرضت بنية لتحليلات قائمة على الوكلاء تعتمد على SageMaker وAthena وQuick

أظهرت AWS معمارية يقوم فيها مساعد وكيل Amazon Quick بتحويل تحليلات lakehouse إلى خدمة ذاتية لفرق الأعمال. تجمع المعمارية S3 و SageMaker و AWS Glue و Athena، مما يسمح للمستخدمين بطرح أسئلة حول البيانات باللغة الطبيعية بدلاً من خلال SQL.

كيفية عمل المعمارية

في العرض التوضيحي، تستخدم AWS مجموعة بيانات TPC-H وتبني فوقها طبقات متعددة من lakehouse. يتم تخزين البيانات في Amazon S3، وتُدار البيانات الوصفية عبر AWS Glue، وتصبح Amazon Athena طبقة SQL موحدة للاستعلامات عن تنسيقات التخزين المختلفة. يستخدم المثال في نفس الوقت جداول CSV خارجية عادية وجداول Iceberg بصيغة Parquet وجداول S3 المُدارة. هذا النهج ليس فقط من أجل الأناقة المعمارية: توضح الشركة أن نفس سؤال العمل يمكن توجيهه إلى مصادر غير متجانسة دون الحاجة إلى بناء data marts يدوي لكل سيناريو. فوق هذا، يتم تجميع طبقة المستخدم في Amazon Quick:

• مجموعات بيانات في SPICE للإجابات السريعة ولوحات المعلومات
• Topic كطبقة دلالية لمصطلحات الأعمال
• لوحات معلومات مع استعلامات باللغة الطبيعية
• Knowledge Base بناءً على التوثيق والمواصفات
• Quick Space وعامل الدردشة كواجهة موحدة

ما يفعله الوكيل

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

بالنسبة لمجموعات البيانات الكبيرة، توصي AWS بدمج الجداول مسبقاً في Athena عبر SQL مخصص، ثم تمرير النتيجة المسطحة إلى Quick. لجعل الوكيل يجيب ليس فقط بالأرقام، تضيف AWS السياق غير المنظم إلى الجداول المنظمة. في Knowledge Base، يحمل برنامج الزحف على الويب مواصفات TPC-H بصيغة PDF، وفي Quick Space، يتم تجميع Topic وقاعدة المعرفة ولوحة معلومات جاهزة.

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

حيث يكمن التأثير

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

أي أن الموظف يرى فقط الجداول والأعمدة والمصادر التي يمتلك بالفعل أذونات للوصول إليها. لكن المنشور يوضح أيضاً السعر الذي يترتب على مثل هذه الراحة. قبل الإطلاق، تحتاج إلى تكوين فهرس Glue وأذونات Lake Formation واتصال Athena والتحميل في SPICE و Topic و Space ولوحة معلومات ووكيل منفصل.

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

ما يعنيه هذا

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