• Оглядываясь назад в 2021 год
• Облако: Нагрузка легла на Клиента
• Облако может начать становиться проще
• Потоковое вещание начнет совмещаться с аналитическими и операционными базами данных.
• Обмен данными и совместное использование — одинаково
• Платформы баз данных обращаются к машинному обучению (ML), чтобы работать самостоятельно

Вот наше мнение о том, сделают ли поставщики облачных услуг свои продукты более удобными для компаний.

Поскольку пандемия приближается к своему двухлетнему юбилею, рост внедрения облачных технологий продолжает ускоряться. Хотя последний отчет Flexera о состоянии облачных технологий датирован мартом прошлого года, он показывает значительное увеличение расходов на облачные технологии для крупных компаний, при этом доля расходов превышает 1 миллион долларов в месяц, что вдвое больше, чем в предыдущем году.

Как сообщал Ларри Дигнан прошлым летом, негативная реакция на миграцию в облако может начать назревать из-за растущих расходов. Мы слышали анекдоты от поставщиков технологий, таких как Vertica, о том, что некоторые из их крупнейших клиентов на самом деле вернули свои корпоративные вычисления из облака обратно в свои собственные центры обработки данных или объекты совместного размещения. 

Итак, что актуально в этом году? Мы делим наш прогноз на 2022 год на два поста. Здесь мы сосредоточимся на тенденциях облачных платформ данных; завтра мы поделимся своими мыслями о том, что будет с Data mesh в наступающем году.

Оглядываясь назад в 2021 год

В прошлом году некоторые из последних держателей локальных баз данных «на дому», таких как  Vertica  и  Couchbase , представили свои собственные облачные сервисы. Это отражает тот факт, что, хотя не все клиенты собираются развертывать решения в общедоступном облаке, предложение «как услуга» теперь является обязательным дополнением к портфолио.

Несмотря на рост внедрения облачных технологий, в мире баз данных и аналитики не наблюдалось впечатляющих продуктов или облачных сервисов. Вместо этого он увидел пополнение портфелей с добавлением бессерверных опций для аналитики и перешел к обработке pushdown на уровне базы данных или хранилища. За исключением HPE , которая в середине года объявила о значительном расширении своей гибридной облачной платформы GreenLake, то же самое можно сказать и о гибридном облаке.

Поскольку большинство провайдеров сделали свои ставки в облако, последний год был посвящен облачным провайдерам, наводящим мосты, чтобы упростить подъем и перемещение или подъем и преобразование развертываний локальных баз данных. Microsoft уже предложила  управляемый экземпляр базы данных SQL Azure  для клиентов SQL Server, а  в 2021 году добавила  управляемый экземпляр для Apache Cassandra .

Тем временем AWS представила свой ответ на Managed Instance: новую опцию RDS Custom для клиентов SQL Server и Oracle, которым требуются специальные конфигурации, которые в противном случае не поддерживались бы в RDS. Это может быть особенно полезно для экземпляров, которые поддерживают, например, устаревшие приложения ERP. 

Что делать, если вы хотите продолжить использовать свои существующие компетенции SQL на новой цели? В прошлом году AWS выпустила  Babelfish , утилиту с открытым исходным кодом, которая может автоматически преобразовывать большинство вызовов SQL Server T-SQL в диалект PostgreSQL pg/PLSQL. А еще Datometry  для простой  виртуализации вашей базы данных.

Также в духе тренда на расширение услуг, в прошлом году, каждое из основных облачных сервисов добавляло или расширяло службы миграции баз данных, предназначенные для упрощения процесса. У AWS и Azure уже были сервисы, предоставляющие пошаговые инструкции по переходу с Oracle или SQL Server на MySQL или PostgreSQL. Тем временем Google представила  службу миграции баз данных,  которая превращает перенос локальной базы данных MySQL или PostgreSQL в Cloud SQL в почти полностью автоматизированный процесс.

В прошлом году мы утверждали, что Oтветственный ИИ (Responsible AI) и Oбъяснимый ИИ (Explainable AI) будут объединены в основе . Год спустя мы слышим о необходимости  интерпретируемого ИИ,  поскольку большая часть того (мало) Объяснимого ИИ, который использовался, не совсем понятна. В этом году мы все еще слышим призывы к тому, чтобы ИИ был более Ответственным. Мы все еще находимся на ранних стадиях того, что окажется долгой дорогой.

Облако: Нагрузка легла на Клиента

Облачные провайдеры не собираются останавливаться расширять свои портфели, добавляя новые продукты и услуги. Но мы ожидаем, что они будут уделять больше внимания выявлению синергии в своих портфелях, что позволит им создавать новые смешанные решения в 2022 году. Что является движущей силой? Предложение решений, объединяющих их услуги, должно снять с плеч клиентов облачных вычислений, по крайней мере, часть бремени по интеграции возможностей. 

Фоном для всего этого является то, что облако должно было упростить ИТ-бюджетирование и операции. В мире данных, когда клиенты внедряют управляемую базу данных как услугу (DBaaS), такую ​​как Amazon Aurora , Database SQL Azure , Google Cloud Spanner , IBM Db2 Warehouse Cloud или Oracle Autonomous Database , экземпляры вычислений и хранения обычно определяются заранее, поскольку поставщик DBaaS занимается обслуживанием программного обеспечения. Бессерверные решения, в свою очередь, поднимают упрощение обслуживания на новый уровень, избавляя клиентов от необходимости планировать свои развертывания.

Тогда возникает проблема: не получаем ли мы слишком много плюсов?

Только AWS имеет более 250 сервисов, из которых, например, у вас есть 11 различных контейнерных сервисов, 16 баз данных и более 30 сервисов машинного обучения (ML). Это не сильно отличается от Google Cloud или Azure. Google Cloud предлагает дюжину аналитических сервисов, 10 контейнерных сервисов и как минимум дюжину или более сервисов AI и ML; Azure предлагает около дюжины служб DevOps, 10 гибридных и мультиоблачных служб и почти дюжину служб Интернета вещей. 

Широта управляемых предложений в облаке отражает растущую зрелость: поставщики облачных услуг расширяют охват своих предложений по платформам, базам данных и программному обеспечению как услуге, обслуживая более широкий спектр потребностей предприятия в вычислительных ресурсах.

Что происходит, когда вы хотите интегрировать инструмент Business intelligence (BI) с базой данных? Или добавить чат-бота для взаимодействия с клиентами, систему распознавания видео или функцию оповещения о событиях для производственного процесса? Или разместить их в контейнерах и развернуть как микросервисы? При таком богатстве выбора на покупателе лежит бремя собрать их воедино.

Облако может начать становиться проще

Следующим шагом для поставщиков облачных услуг является использование разнообразия их портфелей, выявление синергии и начало объединения решений, которые снимают часть бремени интеграции с плеч клиента. Мы видим некоторые ранние побуждения. Например, AWS и Google Cloud предприняли шаги по унификации своих сервисов разработки машинного обучения. Как мы отметим ниже, мы наблюдаем некоторый прогресс в стеке аналитики, где службы облачных хранилищ данных начинают либо превращаться в комплексные решения, либо переносить больше обработки в базу данных. И мы наблюдаем интеграцию диалогового ИИ (чат-ботов) в предписывающие предложения, такие как ИИ Google Contact Center .

Наш список пожеланий на 2022 год включает в себя встраивание некоторых возможностей структуры данных, каталогизации и федеративных запросов в аналитические инструменты для конечных пользователей и специалистов по данным, чтобы им не нужно было интегрировать цепочку инструментов для получения согласованного представления данных. Существует прекрасная возможность внедрить возможности машинного обучения, которые обучаются и оптимизируются, в шаблоны запросов конечного пользователя или организации — на основе SLA и требований к затратам. 

Мы также хотели бы видеть предписывающие решения, которые связывают различные сервисы ИИ с бизнес-приложениями, например, распознавание видео для производства качественных приложений. Как мы отмечаем ниже, мы ожидаем, что streaming (потоковая передача) будет более тесно интегрирована с хранилищами/озёрами данных и службами операционных баз данных.

Мы ожидаем, что в 2022 году поставщики облачных услуг активизируют усилия по использованию синергии, скрытой в их портфелях, — инициатива, в которой также должны активно участвовать горизонтальные и вертикальные партнеры по решениям.

Потоковое вещание начнет совмещаться с аналитическими и операционными базами данных.

Давно неуловимой целью операционных систем и аналитики является объединение данных в движении streaming (потоковая передача) с данными rest (в состоянии покоя) (данные, находящиеся в базе данных или озере данных).

В следующем году мы ожидаем, что потоковые и операционные системы станут ближе друг к другу. Преимущество будет заключаться в улучшении оперативной поддержки принятия решений за счет внедрения некоторой облегченной аналитики или возможностей прогнозирования. Будут явные преимущества для таких разнообразных вариантов использования, как Customer 360 и оптимизация цепочки поставок; техническое обслуживание, ремонт и капитальный ремонт; торговля на рынках капитала; и интеллектуальная балансировка сети. Это также может обеспечивать циклы обратной связи в реальном времени для моделей машинного обучения. В мире, где бизнес оцифровывается, цикл прогнозирования для поддержки оперативных решений, основанных на данных, превращается из роскоши в необходимость.

Идея объединения streaming и данных rest вряд ли нова; много лет назад она была сформулирована как архитектура Kappa , и были отдельные реализации на платформах больших данных — на ум приходит бывшая «конвергентная платформа» MapR (теперь HPE Ezmeral Unified Analytics ).

Потоковые рабочие нагрузки традиционно выполняются на собственных выделенных платформах из-за их экстремальных требований к ресурсам. Препятствием для потоковой передачи на собственной изолированной инфраструктуре является конфликт ресурсов.

Потоковые приложения, такие как синтаксический анализ каналов рынка капитала в режиме реального времени, обнаружение аномалий в потоке данных от физических машин, устранение неполадок в работе сетей или мониторинг клинических данных, обычно работали автономно. Необходимость поддерживать небольшой объем аналитики и запросов, как правило, проще, чем то, что вы могли бы выполнять в хранилище данных или озере данных. В частности, потоковая аналитика часто включает в себя фильтрацию, синтаксический анализ и, во все большей степени, прогнозирование тенденций.

При передаче данных в хранилища или озера данных в большинстве случаев данные ограничиваются наборами результатов. Например, вы можете выполнить SQL-запрос в Amazon Kinesis Data Analytics, который идентифицирует данные на выходе, сохранить результаты в Redshift , а затем выполнить запрос к объединенным данным для более сложной аналитики. Но это многоэтапная операция с участием двух служб, и она не выполняется строго в режиме реального времени.

Следует признать, что в оперативных базах данных в памяти, таких как Redis, вы можете поддерживать почти мгновенное сохранение потоковых данных с помощью форматов данных журнала только для добавления, но это не то же самое, что добавление прогнозирующего цикла обратной связи в рабочие приложения.

За последние пару лет мы видели некоторые намеки на то, что потоковая передача вот-вот станет частью облаков операционных и аналитических данных. Confluent распахнул двери, выпустив ksqldb в Confluent Cloud еще в 2020 году . В прошлом году DataStax представила бета-версию Astra Streaming на базе Apache Pulsar (не Kafka); в настоящее время это отдельная служба, но мы ожидаем, что со временем она будет объединена с Astra DB. Delta Lake из вселенной Spark может выступать в качестве источника или приемника потоковой передачи для структурированной потоковой передачи (Spark Structured Streaming).

Принципиальная перемена — облачная архитектура. Эластичность облака устраняет проблемы конкуренции за ресурсы, а микросервисы предоставляют более отказоустойчивые альтернативы классическим шаблонам проектирования, включающим центральный оркестратор или конечный автомат. В свою очередь, Kubernetes (K8s) позволяет аналитическим платформам поддерживать эластичность без необходимости заново изобретать велосипед для оркестровки вычислительных ресурсов. Конвергентные потоковые и операционные или аналитические системы могут работать в распределенных кластерах, которые можно разделить и организовать для выполнения потоковой аналитики в реальном времени, объединения результатов и сопоставления со сложными операционными моделями.

Такая конвергенция не заменит выделенные потоковые сервисы, но есть явные возможности для традиционных облачных сервисов: Amazon Kinesis Data Analytics в сочетании с Redshift или DynamoDB ; Azure Stream Analytics с Cosmos DB или Synapse Analytics; на ум приходят Google Cloud Dataflow с BigQuery или Firestore . 

Но есть также возможности для хранения данных в памяти в реальном времени. Можно упомянуть Redis , не говоря уже о любой из десятков существующих time series database (TSDB) .

Обмен данными и совместное использование — одинаково

Поскольку облачное хранилище де-факто является озером данных, продвижение более широкого доступа к данным должно быть беспроигрышным для всех: поставщики данных получают больше пользы (и, возможно, монетизации) от своих данных; клиенты данных получают доступ к более разнообразным наборам данных; поставщики облачных платформ могут продавать больше ресурсов (хранилище и вычислительные ресурсы); а облачные хранилища данных могут трансформироваться в места назначения данных. 

С этой точки зрения удивительно, что каждому из крупных облачных провайдеров потребовалось почти пять лет, чтобы понять идею, которую вынашивала 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), чтобы работать самостоятельно

Это обратная сторона машинного обучения в базе данных, которое, по нашим прогнозам, в 2021 году станет обязательным пунктом для облачных хранилищ данных и озер данных. Здесь мы говорим о скрытом использовании машинного обучения для запуска или оптимизации базы данных.

Oracle произвела первый выстрел с помощью Autonomous Database ; Oracle вплотную занялась машинным обучением, разработав базу данных, которая буквально работает сама по себе. Это возможно только при широком спектре автоматизации баз данных, которая во многом уникальна для баз данных Oracle. Но в отношении конкурентов Oracle мы придерживаемся более скромной точки зрения: применение машинного обучения для помощи, а не для замены администратора баз данных в оптимизации конкретных операций с базами данных.

Как подтвердит любой опытный администратор баз данных, работа с базой данных включает в себя множество образных «ручек». Примеры включают физическое размещение данных и многоуровневое хранилище, последовательность соединений в сложном запросе и определение правильных индексов. В облаке это также может включать определение наиболее оптимальных экземпляров оборудования. Обычно конфигурации устанавливаются по формальным правилам или на основе неформальных знаний администратора баз данных.

Оптимизация базы данных хорошо подходит для машинного обучения. Процессы богаты данными, так как базы данных генерируют огромные массивы данных журналов. Проблема также хорошо ограничена, так как функции четко определены. Кроме того, существует значительный потенциал для экономии средств, особенно когда речь идет о том, как наилучшим образом разместить данные или разработать запрос. Поставщики облачных услуг DBaaS имеют хорошие возможности для применения машинного обучения для оптимизации работы своих служб баз данных, поскольку они контролируют инфраструктуру и располагают обширными пулами анонимных операционных данных, на основе которых можно строить и постоянно улучшать модели.

Однако мы были удивлены тем, что мало кто принял вызов Oracle. Почти единственное формальное использование машинного обучения (кроме Oracle) — это база данных SQL Azure и управляемый экземпляр SQL; Microsoft предлагает автонастройку индексов и запросов . Это классическая проблема компромиссов: более высокая скорость поиска с индексом по сравнению со стоимостью и накладными расходами на запись, когда у вас слишком много индексов. Автоматическая настройка Azure может автоматически создавать индексы при обнаружении горячих точек запросов; удаляет неиспользуемые индексы через 90 дней; и восстанавливает предыдущие версии планов запросов, если новые оказываются медленнее.

Мы ожидаем, что в следующем году все больше облачных сервисов DBaaS представят варианты, включающие машинное обучение для оптимизации базы данных, предлагая компаниям способы экономии денег.