Продолжая разговор про оптимизацию приложений Apache Spark в Kubernetes, сегодня разберем, как сократить расходы на облачный кластер с помощью спотовых узлов. А в качестве практического примера рассмотрим кейс компании Weather2020, дата-инженеры которой смогли всего за 3 недели развернуть террабайтные ETL-конвейеры в AWS с AirFlow и Spark на Kubernetes без глубокой экспертизы в этих Big Data технологиях.
Чем полезны спотовые узлы в облачном кластере Kubernetes для Spark-приложений и что с ними не так
Спотовые или вытесняемые узлы (spot instances) обычно стоят примерно на 75% меньше, чем машины по запросу (on-demand) [1]. Например, в облачных кластерах AWS cпотовый экземпляр (instance) доступен со скидками до 90% по сравнению с ценой on-demand [2]. Такой выигрыш в цене компенсируется снижением доступности: при обращении к спотовому узлу нет 100%-ной гарантии ответа. Также для них характерны непредсказуемые прерывания – вытесняемый узел может эти отключиться в любое время [1].
Тем не менее, кратковременные и длительные рабочие нагрузки Spark могут отлично работать на спотовых узлах, обеспечивая высокую доступность в следующих условиях [1]:
- приняты меры снижения рисков внезапного отказа путем своевременного завершения заданий;
- на спотовых узлах размещены только исполнители Spark;
- драйвер Spark работает на узле on-demand.
Таким образом, Spark-приложение быстро восстановится после отказа исполнителя: новый исполнитель будет размещен на узле по запросу и повторно запустит потерянные вычисления. Какие параметры конфигурации следует настроить для этого, читайте в нашей новой статье. Для включения спотовых узлов в Kubernetes нужно выполнить последовательность шагов [2]:
- создать несколько пулов узлов (On-Demand и Spot);
- использовать селекторы узлов и привязки узлов (node affinity), чтобы поместить поды с драйверами Spark в группе узлов on-demand, а поды с исполнителями – в группе узлов Spot.
В качестве реального примера, показывающего, как развертывание Спарк-приложений в управляемом автоматическом масштабируемом кластере Kubernetes на облаке AWS экономит время и деньги, рассмотрим кейс компании Weather2020.
Аналитика больших данных о погоде: кейс компании Weather2020
Weather2020 занимается прогнозированием погоды и аналитикой метеорологических данных для сельского хозяйства, розничной торговли, энергетики, страхования и пиротехнической отрасли. Компания извлекает данные о погоде из публичных агентств по всему миру в различных форматах, включая отраслевые форматы, которые не подходят для аналитической обработки Big Data.
Аналитики Weather2020 работают с данными временных рядов, включая более 40 лет метеорологических и геопространственных наблюдений. Им требовались конвейеры извлечения этих данных, их очистки, обогащения, агрегирования и хранения в облачном озере данных (Data Lake), эффективные с точки зрения экономики. Далее данные должны быть готовыми к использованию в следующих сценариях [3]:
- долгосрочные прогнозы погоды с использованием Spark-приложений предиктивной аналитики;
- панель управления в реальном времени на базе Spark SQL;
- конвейеры доставки данных в настраиваемом формате, необходимом клиентам.
Основная сложность состояла в отсутствии профессионального опыта работы с Apache Spark у команды Weather2020, специализирующейся на проектировании и моделировании данных о погоде. Чтобы не тратить ресурсы на построение собственной Big Data инфраструктуры, а также настройку и техобслуживание кластера Спарк в Amazon EMR, было решение использовать готовую аналитическую платформу.
Выбрав Cloud-Native Spark от Data Mechanics, всего за 3 недели дата-инженеры Weather2020 построили необходимые Big Data конвейеры, принимающие терабайты данных о погоде. По сравнению с альтернативным решением от другого SaaS/PaaS-провайдера Spark, компании Databricks, затраты на реализацию оказались на 60% меньше благодаря следующим преимуществам развертывания распределенных Спарк-приложений на Kubernetes в облачном кластере AWS [3]:
- автоматизированное управление инфраструктурой: кластер динамически масштабируется в зависимости от нагрузки и регулирует параметры инфраструктуры и конфигурации фреймворка для оптимизации производительности, в т.ч. с помощью динамического распределения (dynamic allocation) и экземпляров с большими твердотельными накопителями, о чем мы рассказывали здесь;
- собственная контейнеризация с помощью своих Docker-образов упрощает упаковку кода PySpark и его сложных библиотек (с зависимостями Cython и C);
- интеграция с Apache Airflow для планирования ежедневных batch-конвейеров, также развернутого в том же кластере Kubernetes, что и Spark. Как это применяется в маркетплейсе Joomб читайте в нашей новой статье.
Больше интересных примеров и практических навыков эффективной аналитики больших данных с Apache Spark и AirFlow вы получите на специализированных курсах в нашем лицензированном учебном центре обучения и повышения квалификации для разработчиков, менеджеров, архитекторов, инженеров, администраторов, Data Scientist’ов и аналитиков Big Data в Москве:
- Основы Apache Spark для разработчиков
- Анализ данных с Apache Spark
- Построение конвейеров обработки данных с Apache Airflow и Arenadata Hadoop
- Data Pipeline на Apache Airflow
Источники
