Как работать с Big Data быстрее и эффективнее: Kubernetes для Data Science

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


Big Data by Batjorge


Традиционный подход к построению работы с большими данными — развернуть Hadoop-кластер, установить дополнительные инструменты и построить на нем платформу для работы с данными. Но в таком подходе есть несколько ограничений, вроде невозможности разделения Storage- и Compute-слоев, сложностей масштабирования и изоляции сред для разных приложений. Даже несмотря на то, что Hadoop можно арендовать у облачного провайдера как сервис (aaS), такой подход все равно мало чем отличается от развертывания на собственном оборудовании.


Однако есть другой, Cloud-Native подход работы с большими данными. Он позволяет решить эти проблемы, а также получить дополнительные возможности от облачных технологий. Для этого используют Kubernetes, интегрируя его с различными инструментами.


Я Александр Волынский, архитектор облачной платформы Mail.ru Cloud Solutions. Расскажу, как Kubernetes помогает в работе с Big Data, какие используются инструменты и какие преимущества можно получить по сравнению с классическим развертыванием.


Также вы можете посмотреть видеовыступление на митапе «Большие данные: не хайп, а индустрия».

Немного про Cloud-Native подход в Data Science


Cloud-Native подход работы с большими данными отличается от традиционного тем, что:


  1. Позволяет разделить Storage- и Compute-слои. В Hadoop каждая нода является и Storage-, и Compute-слоем. Для наращивания объема HDFS необходимо добавлять в кластер новые ноды, а значит и процессорные ядра, которые, возможно, вам не нужны. Кроме того, такие системы, как Hadoop, Arenadata DB или ClickHouse, относительно тяжело масштабируются: сложно оперативно добавлять и убирать узлы. А в Cloud Native подходе для хранения данных используется распределенное отказоустойчивое S3-хранилище, которое дешевле HDFS. Вынося ноды в S3, мы разделяем Storage- и Compute-слои, а значит, решаем проблему независимого увеличения объема хранения. Кроме того, вынося данные в S3, мы задействуем хранилище как сервис: не нужно думать о сайзинге нод, hardware, следить за емкостью кластера, думать о том когда его пора масштабировать.
  2. Позволяет получить преимущества вроде автомасштабирования мощностей, изоляции сред и интеграции инструментов. Это возможно благодаря тому, что часть инструментов мы запускаем в Kubernetes.

Подробнее посмотрим на примере конкретных инструментов:


  • Spark — для обработки данных,
  • Presto и Hive Metastore — для доступа к данным,
  • Superset — для построения дашбордов,
  • Airflow — для управления рабочими процессами,
  • Amundsen — для Data Discovery,
  • JupyterHub — для тренировки моделей и экспериментов в Data Science,
  • Kubeflow — для построения MLOps в Kubernetes.

Spark в Kubernetes для обработки данных


Сейчас стандартом в отрасли для обработки больших данных является Spark — быстрая и универсальная платформа обработки данных.


Преимущества запуска Spark в Kubernetes:


  1. Гибкое масштабирование. Kubernetes как сервис в облаке позволяет получить гибко масштабируемую систему. Например, обычно для вашего Spark-приложения достаточно 10 ядер, но раз в неделю для сложных расчетов нужно 100 или 1000 ядер. Когда нагрузка от приложения возрастает, Kubernetes как сервис в облаке может предоставить необходимые ресурсы с помощью автоматического масштабирования. Когда нагрузка уменьшится, эти ресурсы автоматически вернутся в облако. Так вы заплатите лишь за то время, когда действительно потребляли эти ресурсы.
  2. Изоляция сред. Типичная проблема большого Hadoop-кластера — совместимость различных версий программ и библиотек. Например, сейчас вы используете Spark 2.4, все ваши потоки и приложения протестированы и работают в этой версии. Выходит версия 3, и, чтобы обновить Spark в кластере, нужно протестировать все приложения, а некоторые из них, возможно, придется доработать. Kubernetes решает эти проблемы через контейнеризацию. Контейнеры позволяют создавать отдельные независимые среды, которые никак не влияют на соседние. Так можно запускать в кластере одновременно несколько разных версий Spark или других библиотек и приложений. А когда выходит новая версия, нужно просто собрать новый образ без необходимости обновления и ревизии старых приложений.

Как запустить Spark в Kubernetes:


  • Spark-Submit — это Spark-way. При этом в качестве мастера нужно указать кластер Kubernetes. В этом случае Kubernetes не знает, что внутри него работает Spark, для него это будет просто очередным приложением. Из-за этого труднее получить доступ к логам и проверять статус ваших приложений.
  • Kubernetes Operator for Spark — это Kubernetes-way. Это более правильный способ взаимодействия Kubernetes и Spark. В этом случае Kubernetes знает, что внутри него работает Spark, это решает проблемы с доступом к логам и получением текущего статуса ваших приложений. Также это позволяет описывать приложения декларативным способом: мы описываем желаемое состояние, а Kubernetes сам стремится привести приложение к этому состоянию. Мы рекомендуем использовать именно этот способ.

Более подробно о работе Spark и Kubernetes можно узнать из другой нашей статьи. В ней мы показываем, как развернуть Spark в Kubernetes, как собрать приложение с нужными зависимостями, запустить его и посмотреть логи.

Полезные ссылки:


  • Kubernetes Operator for Spark.
  • Сравнение Spark-Submit и Kubernetes Operator.

Presto и Hive Metastore в Kubernetes для доступа к данным


Чтобы предоставить аналитикам доступ к данным, можно использовать Presto. Это инструмент, который позволяет строить SQL-запросы для работы с Big Data. Он помогает решать задачи ad hoc-аналитики.


Преимущество запуска Presto в Kubernetes. Запуск Presto в Kubernetes позволяет использовать всю гибкость его автомасштабирования, которую тяжело реализовать при классическом развертывании. В состоянии покоя Presto потребляет минимум ресурсов и для его работы не нужен мощный кластер. Но когда аналитики начинают отправлять много запросов, нагрузка растет. Автомасштабируемый кластер Kubernetes выделит нужное количество мощностей, и это позволит всем аналитикам работать одновременно без необходимости конкурировать за ресурсы. Когда нагрузка спадет, ненужные ресурсы автоматически вернутся в облако.


Как запустить Presto в Kubernetes. На текущий момент есть Presto Operator и Presto Helm Chart от Starburst. Таким образом, вы сможете достаточно быстро развернуть Presto в Kubernetes.


Presto и Hive Metastore. Presto может получать данные из разных источников: Hadoop, PostgreSQL и так далее — и строить запросы над объединенным объемом данных. Если вы храните данные в S3, то, чтобы Presto мог с ним работать, используется Hive Metastore. Он позволяет представить данные в S3 не просто как набор файлов, а именно как набор таблиц с данными. Аналитикам не нужно знать, в каком бакете S3 хранятся данные: все находится в Hive Metastore, можно использовать SQL для доступа к данным и работать привычным способом.


Полезные ссылки:


  • Presto в Kubernetes.
  • Presto Operator.
  • Hive Metastore в Kubernetes.
  • Хранилище данных S3 на базе Presto в Kubernetes.

Superset в Kubernetes для построения дашбордов


Чтобы собранные данные можно было использовать для BI-аналитики, ее нужно обернуть в графики, дашборды и другие понятные способы представления информации. Для этого подходит Superset — инструмент бизнес-аналитики для исследования и визуализации данных, Open Source-аналог Tableau. При этом Superset гибкий и Cloud-Native в плане использования различных сервисов в качестве бэкенда.


Из «коробки» поддерживает интеграцию с Presto, Greenplum, Hadoop и множеством других систем. Плюс в нем уже достаточно много готовых визуализаций, но есть инструменты и для создания собственных. Если интегрировать его с Presto, то можно работать с данными в S3, используя Superset как SQL IDE. Еще есть инструмент, альтернативный Superset, — Metabase, его также можно запустить в Kubernetes.


Преимущество запуска Superset в Kubernetes: Superset разработан для обеспечения высокой доступности. Это Cloud Native-инструмент, который хорошо умеет масштабироваться в больших распределенных средах и одновременно может обслуживать несколько сотен пользователей.


Как запустить Superset в Kubernetes: существует Helm Chart.


Полезные ссылки:


  • Установка и настройка Superset в Kubernetes.
  • Установка драйверов БД в Superset.
  • Metabase в Kubernetes.

Airflow в Kubernetes для управления рабочими процессами


Чтобы наполнять хранилище данных, необходим оркестратор, или платформа управления рабочими процессами. Он позволяет создавать расписание для задач и указывать последовательность их запуска в зависимости от результата выполнения предыдущей задачи. Сейчас де-факто стандарт в этой области — Airflow, платформа для разработки, планирования и мониторинга потоков обработки данных.


Преимущества запуска Airflow в Kubernetes те же, что и для других инструментов: гибкое масштабирование и изолированная среда.


Как запустить Airflow в Kubernetes:


  • KubernetesPodOperator — в этом случае в Kubernetes выносятся только некоторые Airflow-задачи. На каждую из них внутри Kubernetes будет создан отдельный под. В качестве Executor по-прежнему используют CeleryExecutor, это традиционный способ использования Airflow.
  • KubernetesExecutor — в этом случае на каждую Airflow-задачу будет создан отдельный Worker непосредственно внутри Kubernetes, который уже будет создавать при необходимости новые поды. Если одновременно использовать KubernetesPodOperator и KubernetesExecutor, тогда сначала создается первый под — Worker. Затем он создаст следующий под и запустит Airflow-задачу в нем. Этот метод хорош тем, что позволяет создавать Worker только по требованию, тем самым экономит ресурсы, но при этом в момент роста нагрузки позволяет масштабироваться, то есть выделять большее число ресурсов. При этом нужно учесть, что поды создаются не мгновенно. Поэтому, если у вас сотни или тысячи задач, которые работают всего несколько минут, лучше использовать CeleryExecutor, а некоторую часть нагрузок вынести в Kubernetes с помощью KubernetesPodOperator.

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


Полезные ссылки:


  • Airflow в Kubernetes.
  • Введение в KubernetesExecutor и KubernetesPodOperator.
  • Документация Airflow в Kubernetes.
  • KubernetesExecutor.
  • KubernetesPodOperator.
  • Helm Chart.

Amundsen в Kubernetes: Data Discovery


Далее поговорим о проблеме Data Discovery. Предположим, ваше хранилище выросло и в нем уже тысячи таблиц. Когда на проект приходит новый аналитик, ему нужно как-то познакомиться со всеми этими данными, понять, где и что лежит. Зачастую это решается личным общением: он просит помощи у коллег. Это долго, плюс специалисты отвлекаются от основной работы.


Для решения проблемы существует Open Source-платформа Amundsen. У нее есть UI-интерфейс, который позволяет предоставить пользователям удобный доступ к данным. Наполнять Amundsen метаданными можно вручную или автоматически, если интегрировать инструмент с с Airflow. При этом можно собирать статистику по таблицам, есть поиск, возможность задавать теги, указывать владельца данных, тип таблицы и так далее. Это помогает значительно повысить продуктивность и эффективность использования хранилища данных и решает задачу демократизации доступа.


Как запустить Amundsen в Kubernetes: есть Helm Chart для установки.


Полезные ссылки:


  • Сайт Amundsen.
  • Статья про Amundsen и ее продолжение.

JupyterHub в Kubernetes: тренировка моделей и эксперименты


Для обучения моделей и проведения экспериментов в Big Data зачастую используется JupyterHub, это тоже стандарт в отрасли.


Преимущества запуска JupytherHub в Kubernetes:


  • Масштабирование нагрузки. Размещение JupyterHub в Kubernetes позволяет автоматически возвращать ресурсы в облако, когда они простаивают. Например, аналитику для работы с Jupyter Notebook потребовалось 50 ядер. После окончания работы ресурсы уже не нужны, и можно настроить интервал, через который они вернутся в облако. При этом этот Jupyter Notebook автоматически остановится, но все результаты сохранятся. Когда дата-сайентист вернется к работе, он просто перезапустит его и продолжит работать дальше.
  • Изоляция сред. Опять же в традиционном развертывании на сервере установлена одна версия JupyterHub и библиотек. Если для какого-то эксперимента нужны другие версии, приходится обновлять весь кластер. Контейнеры позволяют каждому специалисту создать свое окружение на основе индивидуального Docker-образа с нужными ему версиями программ и библиотек. Обновление или запуск новых библиотек в одном из окружений никак не влияет на работу других дата-сайентистов.

Как запустить JupyterHub в Kubernetes: устанавливается через Helm Chart, есть подробная инструкция.


Полезные ссылки:


  • Customization Guide.

Kubeflow: MLOps в Kubernetes


Модели машинного обучения важно быстро разворачивать в продакшене, иначе данные устареют и появятся проблемы воспроизводимости экспериментов. Но иногда процесс построен так, что передача моделей от Data Scientist к Data Engineer занимает много времени. Справиться с этой проблемой помогает MLOps. Это подход, который стандартизирует процесс разработки моделей машинного обучения и сокращает время их выкатки в продакшен. С его помощью новые модели быстро передаются в производство и начинают приносить пользу бизнесу. Но чтобы применять этот подход, нужны специальные инструменты.


Один из таких инструментов — Kubeflow, это платформа для машинного обучения и Data Science. В состав Kubeflow входит JupyterHub, поэтому его можно не разворачивать отдельно. Также он помогает решать проблемы трекинга экспериментов, моделей и артефактов. Плюс Kubeflow позволяет выводить модели в продакшен за несколько минут и делать их доступными в виде сервиса.


Примечание: подробнее об MLOps и Kubernetes мы рассказываем в отдельной статье. В ней мы создаем кластер Kubernetes, разворачиваем в нем Kubeflow, обучаем и публикуем модель.

Также мы проводили вебинар, посвященный MLflow. Есть видео и репозиторий с инструкцией.

Преимущества запуска Kubeflow в Kubernetes: Kubeflow специально создавался для Kubernetes, поэтому отдельно его в принципе нельзя запустить. Здесь, скорее, стоит упомянуть о преимуществах Kubeflow перед другими не-Kubernetes аналогами: быстрая публикация моделей, оркестрация сложных пайплайнов, удобный UI для управления экспериментами и мониторингом моделей.


Как запустить Kubeflow в Kubernetes: есть подробная инструкция на официальном сайте. Либо можно упростить себе жизнь, развернув Kubeflow в облачном Kubernetes по этому руководству.


Но стоит учесть, что Kubeflow еще развивается, поэтому он немного сыроват. Есть альтернатива — MLflow, более стабильная платформа, но она работает с Kubernetes только в экспериментальном режиме. Если сравнивать между собой Kubeflow и MLflow, то первый лучше масштабируется, более функциональный и перспективный. MLflow же проще в использовании и более зрелый как продукт, поэтому подходит для промышленного использования, хотя и не обладает такой широтой функциональности, как Kubeflow (к примеру, в MLflow не встроен JupyterHub).


Полезные ссылки:


  • Сравнение Kubeflow и MLflow.
  • Kubeflow overview.
  • MLflow Quickstart.
  • MLflow в Kubernetes.

Зачем использовать Kubernetes для работы с Big Data


Главные преимущества работы с Big Data в Kubernetes — он позволяет построить гибкую автомасштабируемую систему и изолировать рабочие среды для обработки данных, обучения и тестирования моделей. Но самостоятельная установка и обслуживание кластера — нетривиальная задача. Kubernetes удобно арендовать в облаке, потому что кластер можно развернуть за несколько минут, а облачный провайдер предоставляет практически неограниченные ресурсы. Также он возьмет на себя задачи обслуживания: интеграцию новых сервисов, обновление кластера, поддержка и тому подобное. Наконец, облачная инсталляция предполагает большую экономическую эффективность за счёт схемы pay-as-you-go на фоне меняющихся нагрузок.


Cloud-Native подход к работе с большими данными позволяет избавиться от проблем классического Hadoop-кластера, а также получить больше возможностей от других инструментов. На облачных платформах есть разные сервисы, которые помогают в работе с Big Data: объектное хранилище S3, Hadoop aaS, вычисления на базе GPU и другие.


Тут можно почитать, как устроен наш Kubernetes aaS на платформе Mail.ru Cloud Solutions: что у него под капотом и что в него еще входит, кроме собственно Kubernetes.

А подключить его можно здесь. Новые пользователи получают 3000 бонусов для тестирования этого и других сервисов после полной верификации аккаунта.
Источник: https://habr.com/ru/company/mailru/blog/564680/


Интересные статьи

Интересные статьи

От переводчика: Как вы можете знать, мы занимаемся разработкой open source фреймворка и средств разработки. Неотъемлемой частью процесса разработки приложений является развертывание, и ...
Придя в компанию Мегафон как iOS-разработчик, Валентин Чернов попал в сегодняшний основной тренд — переход приложений в оффлайн. Основная работа Валентина — разработка главного приложения...
14 октября начинается «Kubernetes Мега» — онлайн-интенсив для опытных пользователей Kubernetes. Последний в 2020 году. Читать дальше →
Если вспомнить практику анализа данных 10 лет назад и сравнить её с тем, что есть сейчас, то станет очевидно —за это время Data Science проделал гигантский путь. Компьютерное зрение, рекоменд...
RabbitMQ – написанный на языке Erlang брокер сообщений, позволяющий организовать отказоустойчивый кластер с полной репликацией данных на несколько узлов, где каждый узел может обслуживать зап...