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

В одной из прошлых статей мы разобрали несколько ключевых моментов настройки мультиарендного (далее multitenant) кластера Amazon EKS. Что касается безопасности, то это очень обширная тема. Важно понимать, что безопасность касается не только кластера приложений, но и хранилища данных.

AWS в качестве платформы для SaaS решений обладает большой вариативностью для хранилищ данных. Но, как и везде, грамотная настройка безопасности, проработка multitenant-архитектуры под неё, настройка различных уровней изоляций требуют определенных знаний и понимания специфики работы.

Клиенты не любят платить больше, чем планировалось — подробное обоснование расходов неотъемлемая и важная часть внедрения облачных технологий.

Google Cloud Platform предоставляет различные тарифные планы для используемых ресурсов. Например, стоимость GCE зависит от конфигурации компьютера (CPU, память, сетевые модули, жесткие диски). Расходы на Google Kubernetes Engine (GKE) и Google Cloud Dataproc основываются на всех узлах, которые работают в Google Compute Engine (GCE). Остальные затраты могут вычисляться по сложной и замысловатой формуле. Планировать бюджет становится всё сложнее, особенно если вы пользуетесь несколькими облачными технологиями. Мониторинг и своевременное информирование становятся тем ценнее по мере увеличения трат на инфраструктуру.

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

Мы постоянно используем Cloud-native технологии, и запускаем системы в контейнерах на платформе Kubernetes. Эта технология отлично подходит для оркестрации контейнерных нагрузок благодаря гибкости и установке виртуальных машин прямо на железо (bare metal). Когда-то Kubernetes подходил только для простых рабочих нагрузок без сохранения состояния, теперь там стало возможным хранить базы данных, обучать машины и развертывать сложные приложения.

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

На деле переносить проект с многокомпонентной системой обработки данных, масштаба Петабайта, из локальной среды в облачную — это сплошные “но”. Для миграции есть много продуктов: Hadoop, Hive, Yarn, Spark, Kafka, Zookeeper, Jupyter, Zeppelin. Учитывая принципиальное различие среды, в этом многообразии легко потеряться и наделать ошибок.

В этой статье я расскажу о распространенных заблуждениях и дам несколько советов по качественной миграции в облако. Лично я пользуюсь AWS, но все приемы актуальны и для других провайдеров с похожими решениями, например, для Azure или GCP.