هل سيبدأ مقدمو الخدمات السحابية أخيرًا في اتباع نهج موجه نحو الحلول لخدمات البيانات الخاصة بهم؟ هل ستلتقي أخيرًا عوالم البث المباشر وقواعد البيانات التشغيلية ، وهل سيبدأ موفرو قواعد البيانات السحابية أخيرًا في الاستفادة من التعلم الآلي لتشغيل قواعد البيانات الخاصة بهم؟ إليك رأينا بشأن ما يحدث هذا العام.
مع اقتراب الوباء من الذكرى السنوية الثانية لتأسيسه ، ليس هناك شك في أن نمو اعتماد السحابة قد استمر في التسارع. على الرغم من تأريخه في مارس الماضي ، أظهر أحدث تقرير عن حالة السحابة من Flexera تسارعًا كبيرًا في الإنفاق على السحابة للمؤسسات الكبيرة ، حيث تضاعفت النسبة بأكثر من مليون دولار شهريًا مقارنة بالعام السابق.
كما ذكر لاري ديجنان في الصيف الماضي ، فإن رد الفعل العكسي على الترحيل السحابي قد يبدأ في التحضير على أساس فكرة أن الكثير من الأسعار الرخيصة تصبح باهظة الثمن في نهاية المطاف. لقد سمعنا حكايات من مزودي التكنولوجيا مثل Vertica أن بعضًا من أكبر عملائهم كانوا في الواقع يعيدون أعباء العمل من السحابة إلى مركز البيانات أو مرافق الاستضافة المشتركة الخاصة بهم.
إذا نظرنا إلى الوراء في عام 2021
شهد العام الماضي قيام بعض من آخر قواعد البيانات المحلية ، مثل Vertica و Couchbase ، بالكشف عن خدماتهم المُدارة عبر السحابة الخاصة: لقد عكس ذلك حقيقة أنه على الرغم من عدم قيام جميع العملاء بالنشر في السحابة العامة ، حيث يقدمون خدمة as-a - خيار الخدمة الآن إضافة مطلوبة إلى المحفظة.
على الرغم من النمو في اعتماد السحابة ، لم تشهد قاعدة البيانات وعالم التحليلات الكثير من مقدمات المنتجات أو الخدمات السحابية المثيرة ؛ بدلاً من ذلك ، رأينا تقريبًا من الحافظات ، مع إضافة خيارات بدون خادم للتحليلات ، وتحركًا متزايدًا نحو معالجة الضغط في قاعدة البيانات أو طبقة التخزين. باستثناء HPE ، التي كشفت عن توسع كبير لمنصتها السحابية GreenLake الهجينة في منتصف العام ، كان الشيء نفسه صحيحًا إلى حد كبير على واجهة السحابة الهجينة.
مع قيام معظم المزودين بزرع حصصهم في السحابة ، كان العام الماضي يتعلق بمزودي الخدمات السحابية ببناء الجسور لتسهيل رفع عمليات نشر قاعدة البيانات المحلية وتحويلها أو رفعها وتحويلها. للرفع والتحويل ، قدمت Microsoft بالفعل Azure SQL Database Managed Instance لعملاء خادم SQL ، وفي العام الماضي ، أضافت مثيل مُدار لـ Apache Cassandra .
وفي الوقت نفسه ، قدمت AWS إجابتها إلى Managed Instance: خيار RDS Custom جديد لـ SQL Server وعملاء Oracle الذين لديهم تكوينات خاصة لن يتم دعمها في RDS. قد يكون هذا مفيدًا بشكل خاص للحالات التي تدعم ، على سبيل المثال ، تطبيقات ERP القديمة. وماذا إذا كنت تريد الاستمرار في استخدام مهارات SQL الموجودة لديك على هدف جديد؟ في العام الماضي ، أصدرت AWS أداة Babelfish ، وهي أداة مساعدة مفتوحة المصدر يمكنها تحويل معظم مكالمات SQL Server T-SQL تلقائيًا إلى لهجة pg / PLSQL الخاصة بـ PostgreSQL. ثم هناك قياس البيانات ، والذي يقول ، فقط اجعل قاعدة البيانات افتراضية .
أيضًا في روح الرفع والتحول ، شهد العام الماضي إضافة أو توسيع خدمات ترحيل قاعدة البيانات لكل من السحابات الرئيسية المصممة لجعل العملية أكثر بساطة. لدى AWS و Azure بالفعل خدمات توفر طرقًا إرشادية للترحيل من Oracle أو SQL Server إلى MySQL أو PostgreSQL. في العام الماضي ، قدمت Google خدمة ترحيل قواعد البيانات التي تشبه تقريبًا: تحويل MySQL أو PostgreSQL المحلية إلى Cloud SQL إلى عملية مؤتمتة بالكامل تقريبًا.
إذن ما الذي ينتظرنا في 2022؟ نحن نقسم توقعاتنا للعام المقبل على وظيفتين. سنقوم هنا بتدريب أعيننا على الاتجاهات مع منصات البيانات السحابية ، وغدًا ، سنشارك أفكارنا حول ما سيحدث عندما يسلط الضوء على شبكة البيانات في العام المقبل.
قد تصبح السحابة أسهل
لن يتوقف مقدمو الخدمات السحابية فجأة عن توسيع محافظهم الاستثمارية في إضافة منتجات وخدمات جديدة. لكننا نتوقع أنه في العام المقبل ، سيبدأون في إيلاء المزيد من الاهتمام لتحديد أوجه التآزر عبر محافظهم الاستثمارية التي يمكنهم من خلالها تقديم حلول مختلطة جديدة. السائق؟ يجب أن يؤدي تقديم الحلول التي تمزج بعض خدماتهم إلى نقل بعض عبء دمج القدرات على أكتاف عملاء السحابة على الأقل.
خلفية كل هذا هو أنه كان من المفترض أن تبسط السحابة ، ليس فقط ميزانية تكنولوجيا المعلومات ، ولكن أيضًا العمليات. في عالم البيانات ، عندما يتبنى العملاء خدمات DBaaS المُدارة مثل Amazon Aurora أو Azure SQL Database أو Google Cloud Spanner أو IBM Db2 Warehouse Cloud أو Oracle Autonomous Database ، عادةً ما يتم تحديد مثيلات الحوسبة والتخزين مسبقًا ويتولى موفر DBaaS إدارة البرامج. غير الخوادم ، بدورها ، تأخذ التبسيط إلى مستوى آخر من خلال الاستغناء عن حاجة العملاء إلى تخطيط سعة عمليات النشر الخاصة بهم.
تصبح المشكلة إذن ، هل نحصل على الكثير من الأشياء الجيدة؟
تمتلك AWS وحدها أكثر من 250 خدمة ، منها ، على سبيل المثال ، لديك 11 خدمة حاوية مختلفة و 16 قاعدة بيانات وأكثر من 30 خدمة تعلم آلي (ML). لا يختلف الأمر كثيرًا مع Google Cloud أو Azure أيضًا. تقدم Google Cloud عشرات الخدمات التحليلية ، و 10 خدمات حاويات ، وما لا يقل عن اثنتي عشرة خدمة أو أكثر من خدمات الذكاء الاصطناعي والتعلم الآلي ؛ بينما تقدم Azure ما يقرب من اثنتي عشرة خدمة DevOps ، و 10 خدمات هجينة ومتعددة السحاب ، وما يقرب من اثنتي عشرة خدمة إنترنت الأشياء. مع وجود اللسان في الخد ، شعرنا بالارتياح بشكل خاص عندما لم تقدم AWS قاعدة البيانات السابعة عشرة في آخر مؤتمر re: Invent.
يعكس اتساع نطاق العروض المُدارة في السحابة نضجًا متزايدًا: يعمل موفرو السحابة على توسيع نطاق عروض النظام الأساسي وقاعدة البيانات والبرامج كخدمة ، مما يخدم مجموعة واسعة من احتياجات الحوسبة للمؤسسات.
إذن ، ماذا يحدث عندما تريد دمج أداة ذكاء الأعمال مع قاعدة بيانات أو إضافة روبوت محادثة خاص بتجربة العملاء أو نظام التعرف على الفيديو أو بعض القدرة على التنبيه بالأحداث لعملية التصنيع أو سلسلة التوريد أو الصيانة؟ أو وضعها في حاويات ونشرها كخدمات مصغرة؟ مع هذا الكم الهائل من الخيارات ، كان العبء يقع على عاتق العميل لدمجها أو تجميعها معًا.
تتمثل الخطوة التالية لموفري الخدمات السحابية في الاستفادة من تنوع محافظهم وتحديد أوجه التآزر والبدء في تجميع الحلول التي ترفع على الأقل جزءًا من عبء التكامل عن كاهل العميل. نشهد بعض التحركات المبكرة. على سبيل المثال ، خطت AWS و Google Cloud خطوات واسعة لتوحيد خدمات تطوير ML. كما سنلاحظ أدناه ، فإننا نشهد بعض التقدم في مجموعة التحليلات حيث بدأت خدمات تخزين البيانات السحابية إما في التحول إلى حلول شاملة ، أو دفع المزيد من المعالجة إلى قاعدة البيانات. ونرى تكامل الذكاء الاصطناعي للمحادثة (المعروف أيضًا باسم روبوتات المحادثة) في العروض الإرشادية مثل مركز اتصال Google AI .
تتضمن قائمة الرغبات الخاصة بنا تضمين بعض نسيج البيانات ، والفهرسة ، وقدرات الاستعلام الموحد في أدوات تحليلية ، لكل من المستخدمين النهائيين وعلماء البيانات على حدٍ سواء ، لذلك لا يتعين عليهم دمج سلسلة أدوات للحصول على عرض متماسك للبيانات. هناك فرصة ممتازة لتضمين قدرات تعلم الآلة التي تتعلم وتحسن أنماط الاستعلام الخاصة بالمستخدم النهائي أو المؤسسة بناءً على اتفاقية مستوى الخدمة ومتطلبات التكلفة. نود أيضًا أن نرى حلولًا توجيهية تربط خدمات الذكاء الاصطناعي المختلفة بتطبيقات الأعمال ، مثل التعرف على الفيديو لتطبيقات جودة التصنيع. كما نلاحظ أدناه ، نتوقع أن نرى تدفقًا متكاملاً بشكل أكثر إحكامًا مع مستودعات البيانات / بحيرات البيانات وخدمات قواعد البيانات التشغيلية.
نتوقع أنه في عام 2022 ، سيكثف مقدمو الخدمات السحابية جهودهم للاستفادة من أوجه التآزر المختبئة على مرأى من الجميع في محافظهم - وهي مبادرة يجب أن تشمل أيضًا شركاء الحلول الأفقية والعمودية بشكل كبير.
سيبدأ البث في التقارب مع التحليلات وقواعد البيانات التشغيلية
يتمثل الهدف بعيد المنال للأنظمة التشغيلية والتحليلات في توحيد البيانات المتحركة (المتدفقة) مع بقاء البيانات (البيانات الموجودة في قاعدة بيانات أو بحيرة بيانات).
في العام المقبل ، نتوقع أن نرى أنظمة البث والتشغيل تقترب من بعضها البعض. ستكون الفائدة هي تحسين دعم القرار التشغيلي من خلال تضمين بعض التحليلات خفيفة الوزن أو القدرة التنبؤية. ستكون هناك فوائد واضحة لحالات الاستخدام متنوعة مثل Customer 360 و Supply Chain Optimization ؛ الصيانة والإصلاح والعمرة (MRO) ؛ تداول أسواق رأس المال؛ وموازنة الشبكة الذكية. يمكن أن يجعل التحليلات أكثر حداثة ويوفر حلقات تغذية مرتدة في الوقت الفعلي لنماذج ML. في عالم يتم فيه رقمنة الأعمال التجارية ، فإن وجود تلك الحلقة التنبؤية لدعم القرارات التشغيلية القائمة على البيانات يتحول من الرفاهية إلى الضرورة.
إن فكرة الجمع بين التدفق والبيانات معًا ليست جديدة ؛ تم توضيحها منذ سنوات على أنها بنية Kappa ، وكانت هناك عمليات تنفيذ منفصلة على منصات البيانات الضخمة - يتبادر إلى الذهن "النظام الأساسي المتقارب" لـ MapR (الآن HPE Ezmeral Unified Analytics ).
يتم تشغيل أحمال العمل المتدفقة بشكل تقليدي على الأنظمة الأساسية المخصصة الخاصة بهم بسبب متطلبات الموارد الشديدة. لطالما كان مانع العرض الذي يحافظ على التدفق على جزيرته من البنية التحتية محل نزاع على الموارد.
تعمل التطبيقات المتدفقة ، مثل تحليل موجزات سوق رأس المال في الوقت الفعلي ، واكتشاف الحالات الشاذة في تدفق البيانات من الأجهزة المادية ، واستكشاف أخطاء تشغيل الشبكات ، أو مراقبة البيانات السريرية ، بشكل مستقل. وبسبب الحاجة إلى الحفاظ على بصمة خفيفة ، تميل التحليلات والاستعلامات إلى أن تكون أبسط بكثير مما يمكنك تشغيله في مستودع البيانات أو بحيرة البيانات. على وجه التحديد ، غالبًا ما تتضمن تحليلات التدفق الترشيح والتحليل والاتجاه التنبئي بشكل متزايد.
عندما يكون هناك تسليم إلى مستودعات البيانات أو بحيرات البيانات ، في معظم الحالات ، ستقتصر البيانات على مجموعات النتائج. على سبيل المثال ، يمكنك تشغيل استعلام SQL على Amazon Kinesis Data Analytics الذي يحدد القيم المتطرفة ، ويستمر في النتائج إلى Redshift ، ثم إجراء استعلام على البيانات المجمعة لتحليلات أكثر تعقيدًا. لكنها عملية متعددة الخطوات ، تتضمن خدمتين ، وهذا ليس وقتًا حقيقيًا تمامًا.
من المسلم به أن قواعد البيانات التشغيلية في الذاكرة مثل Redis تدعم استمرار تدفق البيانات بشكل شبه فوري باستخدام تنسيقات بيانات سجل الإلحاق فقط ، ولكن هذا لا يماثل إضافة حلقة تغذية مرتدة تنبؤية للتطبيقات التشغيلية.
على مدار العامين الماضيين ، رأينا بعض التلميحات إلى أن البث على وشك أن يصبح جزءًا من سحابة البيانات التشغيلية والتحليلية. فتح Confluent الأبواب عندما أصدر ksqldb على Confluent Cloud مرة أخرى في عام 2020 ، بينما في العام الماضي ، قدم DataStax الإصدار التجريبي من Astra Streaming ، مدعومًا على Apache Pulsar (وليس كافكا) ؛ إنها حاليًا خدمة منفصلة ولكننا نتوقع بمرور الوقت دمجها مع Astra DB . في عالم Spark ، يمكن أن تعمل Delta Lake كمصدر متدفق أو مغسلة لـ Spark Structured Streaming.
مغير اللعبة هو بنية السحابة الأصلية. تلغي مرونة السحابة قضايا التنازع على الموارد ، بينما توفر الخدمات المصغرة بدائل أكثر مرونة لأنماط التصميم الكلاسيكية التي تنطوي على منسق مركزي أو آلة حالة. في المقابل ، تمكّن Kubernetes (K8s) المنصات التحليلية من دعم المرونة دون الحاجة إلى إعادة اختراع العجلة لتنظيم موارد الحوسبة. يمكن تشغيل أنظمة الدفق المتقاربة والتشغيلية أو التحليلية على مجموعات موزعة يمكن تقسيمها وتنظيمها لأداء تحليلات التدفق في الوقت الفعلي ، ودمج النتائج ، والارتباط بنماذج التشغيل المعقدة.
لن يحل هذا التقارب محل خدمات البث المخصصة ، ولكن هناك فرصًا واضحة لشاغلي الوظائف السحابية: تحليلات بيانات Amazon Kinesis المقترنة بـ Redshift أو DynamoDB ؛ تحليلات Azure Stream مع Cosmos DB أو Synapse Analytics ؛ يتبادر إلى الذهن Google Cloud Dataflow مع BigQuery أو Firestore . ولكن هناك أيضًا فرصًا لتخزين البيانات في الذاكرة في الوقت الفعلي. نحن نتحدث إليكم يا ريديس ، ناهيك عن عشرات قواعد بيانات السلاسل الزمنية الموجودة هناك.
تبادل البيانات ومشاركتها ، على حد سواء
بعد فوات الأوان ، يبدو هذا وكأنه لا يحتاج إلى تفكير. نظرًا لأن التخزين السحابي هو بحيرة البيانات الفعلية ، يجب أن يكون تعزيز الوصول الأوسع إلى البيانات مفيدًا للجميع: يحصل موفرو البيانات على عدد أكبر من الأميال (وربما تحقيق الدخل) من بياناتهم ؛ وصول عملاء البيانات إلى مجموعات بيانات أكثر تنوعًا ؛ يمكن لموفري النظام الأساسي السحابي بيع المزيد من الاستخدام (مثل التخزين والحساب) ؛ بينما يحول مستودع البيانات السحابية نفسه إلى وجهات بيانات. من هذا المنظور ، من المدهش أن يستغرق الأمر ما يقرب من خمس سنوات لكل من مزودي الخدمات السحابية الرئيسيين للقبض على الفكرة التي فقسها Snowflake .
كانت Snowflake ، تليها AWS ، هي الأكثر نشاطًا في تعزيز تبادل البيانات ، على الرغم من أن كليهما اقترب منها من اتجاهين متعاكسين. بدأ Snowflake بقدرة مشاركة البيانات الموجهة عبر الإدارات الداخلية ثم فتح لاحقًا تبادل البيانات لأطراف ثالثة ؛ ذهبت AWS بترتيب عكسي ، حيث فتحت تبادل البيانات على AWS Marketplace قبل عامين ، ولكن خلال العام الماضي فقط أضافت إمكانات للمشاركة الداخلية للبيانات لعملاء Redshift (تطلب ذلك من AWS تطوير مثيل RA3 الذي فصل بيانات Redshift في النهاية حمام السباحة الخاص). لقد اتخذت Snowflake الخطوة الإضافية المتمثلة في فتح أقسام الصناعة العموديةمن السوق ، مما يسهل على العملاء الاتصال بمجموعات البيانات الصحيحة ؛ من ناحية أخرى ، تفوقت AWS على Snowflake في تسويق سوق البيانات الخاص بها من خلال استخدام آلية AWS Marketplace الحالية.
حذت Google حذوها هذا العام مع Analytics Hub لمشاركة مجموعات بيانات BigQuery ، وهي القدرة التي ستمتدها لاحقًا إلى أصول أخرى مثل Looker Blocks و Connected Sheets. دخلت Microsoft Azure أيضًا في هذا العمل .
خلال العام المقبل ، نتوقع أن يقوم كل من مزودي الخدمات السحابية بتجسيد عمليات تبادل البيانات والأسواق الداخلية والخارجية الخاصة بهم ، لا سيما عندما يتعلق الأمر بالتسويق.
تتحول منصات قواعد البيانات إلى ML لتشغيل نفسها
هذا هو الجانب الآخر من ML داخل قاعدة البيانات ، والذي توقعنا في العام الماضي أن يصبح عنصرًا في خانة الاختيار لمخازن البيانات السحابية وبحيرات البيانات. ما نتحدث عنه هنا هو استخدام ML تحت الأغطية للمساعدة في تشغيل قاعدة البيانات أو تحسينها.
أطلقت Oracle اللقطة الأولى باستخدام قاعدة البيانات الذاتية . ذهبت Oracle إلى حد كبير مع ML من خلال تصميم قاعدة بيانات تدير نفسها حرفيًا. هذا ممكن فقط مع اتساع نطاق أتمتة قواعد البيانات الفريدة إلى حد كبير في قاعدة بيانات Oracle. ولكن بالنسبة إلى منافسي Oracle ، فإننا نتبنى وجهة نظر أكثر تواضعًا: تطبيق ML للمساعدة ، وليس استبدال DBA في تحسين عمليات قاعدة بيانات معينة.
كما سيشهد أي مسؤول قاعدة بيانات متمرس ، فإن تشغيل قاعدة بيانات يتضمن الكثير من "المقابض" التصويرية. تتضمن الأمثلة وضع البيانات المادية وطبقات التخزين ، وتسلسل الصلات في استعلام معقد ، وتحديد الفهارس الصحيحة. في السحابة ، يمكن أن يشمل ذلك أيضًا تحديد مثيلات الأجهزة المثلى. عادةً ما يتم تعيين التكوينات بواسطة قواعد رسمية أو بناءً على المعرفة غير الرسمية لـ DBA.
يعد تحسين قاعدة البيانات مناسبًا تمامًا لـ ML. العمليات غنية بالبيانات ، حيث تولد قواعد البيانات مجموعة ضخمة من بيانات السجل. كما أن المشكلة محددة جيدًا ، حيث إن الميزات محددة جيدًا. وهناك احتمالية كبيرة لتحقيق وفورات في التكاليف ، لا سيما عندما يتعلق الأمر باعتماد أفضل طريقة لتخطيط البيانات أو تصميم استعلام. يتمتع موفرو Cloud DBaaS بموقع جيد لتطبيق ML لتحسين تشغيل خدمات قاعدة البيانات الخاصة بهم حيث يتحكمون في البنية التحتية ولديهم مجموعات غنية من البيانات التشغيلية المجهولة المصدر التي يمكن بناء النماذج عليها وتحسينها باستمرار.
لذا فقد فوجئنا أنه حتى الآن ، كان هناك عدد قليل من المشاركين في تحدي Oracle. إن الاستخدام الوحيد المُنتج رسميًا لـ ML (بصرف النظر عن Oracle) هو مع Azure SQL Database و SQL Managed Instance. تقدم Microsoft الضبط التلقائي للفهارس والاستعلامات . هذه مشكلة تقليدية للمقايضات: سرعة الاسترجاع الأسرع باستخدام مؤشر مقابل التكلفة والنفقات العامة لعمليات الكتابة عندما يكون لديك عدد كبير جدًا من الفهارس. يمكن أن ينشئ الضبط التلقائي لـ Azure فهارس تلقائيًا عندما يستشعر النقاط الفعالة للاستعلام ؛ يسقط الفهارس التي لا يتم استخدامها بعد 90 يومًا ؛ وأعد الإصدارات السابقة من خطط الاستعلام إذا ثبت أن الإصدارات الأحدث أبطأ.
جرب آخرون تقنيات مثل التعلم المعزز بدرجات متفاوتة من النجاح . جامعة كاليفورنيا في بيركلي في RISELab وقد جربت مع تعزيز التعلم إلى محسن الاستعلام محفز القائمة وتعزيز الأداء مقابل سبارك. كما هو مذكور أعلاه ، يمتلك مقدمو خدمات قواعد البيانات المُدارة عبر السحابة مجموعة ضخمة من البيانات لتدريب نماذج تعلم الآلة. بالنسبة للعملاء المهتمين بالتكلفة أو الأداء ، يمكن أن يوفر ML مزايا تنافسية تكتيكية ، على عكس قاعدة البيانات المستقلة ، لن تجعل سوقهم المحتمل لمسؤولي قواعد البيانات يدركون أن وظائفهم مهددة.
خلال العام المقبل ، نتوقع أن نرى المزيد من خدمات DBaaS السحابية تقدم خيارات تتضمن ML لتحسين قاعدة البيانات ، والترويج للمؤسسات لكيفية توفير المال.
الإفصاح: AWS و DataStax و Google Cloud و HPE و IBM و Oracle هم عملاء dbInsight.
