Облачный путь к данным в любом месте

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

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

См. также: Тенденции внедрения облачных технологий в 2021 году усиливаются в 2022 году

Изучение пункта назначения

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

Если говорить точнее, облачная технология управления данными и аналитики должна обладать пятью ключевыми характеристиками, чтобы соответствовать плану распределенного облака данных:

• Независимая от платформы среда выполнения, позволяющая предоставлять данные и аналитику в любом месте
• Обычный пользовательский интерфейс в любом месте
• Общие функции безопасности и управления для любой цели развертывания.
• Эффективность затрат и технологий в любом месте, минимизация ресурсов и возможность надежного управления затратами (FinOps) и ограничения расходов.
• Единая плоскость управления, объединяющая все развертывания, общедоступное облако, локально и на границе сети.

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

Выбор правильного руководства

Так как же достигается это место назначения? Kubernetes, инструмент оркестрации контейнеров с открытым исходным кодом, обеспечивает наиболее популярный путь к облачным операциям. Хотя идея разделения рабочих нагрузок в Unix существует с 1970-х годов, всего около десяти лет назад контейнеры были широко внедрены, чтобы сделать разработку приложений более простой, переносимой и эффективной с точки зрения использования ресурсов. Но развертывание сотен или тысяч приложений в обширной архитектуре микросервисов оказалось чрезвычайно сложной задачей. Хотя существуют и другие варианты, проект Google Kubernetes с открытым исходным кодом, который сейчас поддерживается Cloud Native Computing Foundation, приобрел известность благодаря решению проблемы оркестрации приложений микросервисов, позволяя приложениям работать в общей инфраструктуре, отслеживать и управлять ими стандартными способами, а также проходить аутентификацию с использованием открытые стандарты.

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

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

Предоставление интерфейса SQL через Kubernetes для предоставления нескольких эластичных кластеров по запросу и скрытия сложностей Kubernetes от администраторов баз данных и конечных пользователей — вот ответ.

Таким образом, можно назначить разных пользователей для выполнения рабочих нагрузок в разных вычислительных кластерах, а используемый вычислительный кластер можно изменить во время выполнения с помощью SQL при наличии разрешения. Кластеры можно настроить на автоматическую приостановку после периода простоя и возобновление работы по требованию. Например, можно создать отдельный вычислительный кластер для запуска процессов ETL при необходимости, один для специальной бизнес-аналитики (BI) и несколько кластеров обработки данных. Вычислительные кластеры можно расширять онлайн в периоды интенсивного использования или отключать в периоды затишья для экономии средств. Кластеры можно создавать для выполнения ежедневных, еженедельных или ежемесячных задач пакетной отчетности, которые активны только в эти периоды времени. В этой модели можно контролировать как размер узлов в вычислительном кластере, так и количество узлов, а ограничения на потребление ресурсов можно установить на уровне экземпляра для предсказуемости. Точно так же можно настроить недорогую систему реплик, которая получает трафик репликации от основного экземпляра хранилища данных, который затем можно масштабировать по требованию, когда реплика должна использоваться.

Такая эластичность реализуется не только за счет глубокой интеграции с Kubernetes, но и за счет использования самого SQL в качестве «пользовательского интерфейса» для создания, приостановки, возобновления и управления кластерами вместо инструментов разработчика. Kubernetes — авторитетный источник достоверной информации о состоянии всех кластеров. Системные представления, показывающие состояние кластеров, получают данные из Kubernetes с использованием его API. Когда вводятся операторы SQL для управления кластером, облачное хранилище данных обращается к Kubernetes, чтобы изменить желаемое состояние экземпляра; Затем Kubernetes вносит необходимые изменения. Если узел в кластере выйдет из строя, Kubernetes заменит его в сети.

Это представляет собой уникальную внутреннюю связь с Kubernetes:вместо того, чтобы Kubernetes был «пользовательским интерфейсом» для управления состоянием кластера, сама база данных, которой управляет Kubernetes, становится пользовательским интерфейсом. Эта архитектура создает симбиотические отношения, которые обеспечивают уникальный, полностью реализованный облачный опыт. Мощь и кросс-платформенная гибкость Kubernetes становятся доступными для хранилища данных, полностью управляемого через SQL.

По мере того, как создается больше данных и развертывается больше вариантов использования, предприятиям легко попасть в порочный круг, когда их экосистема все больше укореняется в определенном облаке. Системные риски могут возникать в том едином облаке, которое представляет слишком большую уязвимость для критически важной ИТ-инфраструктуры в строго регулируемых секторах, таких как финансовые услуги и страхование. Архитектура с помощью Kubernetes — не единственная основная концепция, которая воплощает в жизнь полностью реализованное облачное хранилище данных. Это не единственный архитектурный компонент, соответствующий шаблону распределенного облака данных. Но это незаменимый центральный элемент, который делает аналитику данных исключительно гибкой, работающей в любом месте в момент потребности бизнеса — и делает это в масштабе и с высокой степенью параллелизма, производительности, эффективности и доступности. В результате тысячи пользователей на любом предприятии из разных направлений бизнеса и географических регионов могут очень быстро принимать решения и извлекать выгоду из аналитики практически в режиме реального времени.