Масштабируемая аналитика данных везде с облачно-ориентированной архитектурой

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

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

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

Исследование цели

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

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

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

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

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

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

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

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

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

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

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

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

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