Всем привет! Сегодня хотим затронуть тему облачных технологий. Дмитрий Морозов, архитектор DWH в компании GlowByte, занимается хранилищами данных 6 лет, последние 2,5 года участвует в проектах, использующих облака. В этой статье он сделает обзор облачных решений, которые могут быть полезны для задач хранения больших данных, а также уделит внимание вопросам выбора облачного хранилища. Статья основана на личном опыте, может быть интересна как разработчикам, дата-инженерам, так и менеджерам, отвечающим за корпоративную Big Data-инфраструктуру и ищущим возможности ее масштабировать.
Определение
Облачные сервисы – это предоставляемые в аренду ресурсы для вычислений и хранения данных. Облачный вендор предлагает клиенту виртуальные машины, диски и ресурсы для serverless-вычислений, забирая на себя целый комплекс технических мероприятий по их развертыванию и поддержке. Клиент же получает не только непосредственно ресурс или услугу, но и возможность принципиально по-новому подходить к масштабированию и оптимизации затрат на железо и софт. Такие услуги могут быть полезны для решения множества задач, но ниже мы поговорим о том, как облака помогают решать задачи хранения и обработки данных.
Архивное хранение
Данные, к которым не требуется быстрый доступ, часто предпочитают “охладить”. Их удаляют с дорогих дисков основной платформы хранения (DWH или Data Lake) и перемещают в архив. Технически архив может быть устроен как массив устройств хранения (дисков и лент). Также часто архивной системой выступает Hadoop-кластер: данные хранятся в HDFS, а для анализа доступны через различные SQL-движки.
Object Storage
Облачные вендоры предоставляют сервис Object Storage (или Blob Storage). Вендор забирает на себя следующие функции:
распределение данных,
репликацию,
аппаратное шифрование,
замену устаревшего оборудования.
Доступ к данным осуществляют через REST API. Стандартом де-факто доступа к данным стал протокол S3, впервые предложенный Amazon Web Services для своего Object Storage, поэтому, говоря S3, часто подразумевают любое объектное хранилище (не только Amazon и даже не обязательно поддерживающее протокол S3).
Тарификация
Важный плюс облаков для конечного потребителя – гибкая тарификация. Обычно клиент платит за объем хранимых данных и за трафик. У обеих метрик единица измерения – гигабайты. Это означает, что нет необходимости заранее закупать петабайтные дисковые массивы и оплачивать их содержание. Для хранения архива on-prem мы закупили бы СХД, достаточно объемную для хранения архивов, скажем, за год, и впоследствии докупали бы диски, увеличивая объем раз в полгода-год. В облаке же мы платим только за те данные, которые реально храним прямо сейчас.
Доступ к данным
Доступ к данным, хранящимся в S3-хранилище, весьма вариативен. Существуют такие способы:
REST API. Реализуются интуитивные для файловой системы методы: вернуть список объектов, положить новый объект, получить объект, скопировать, удалить. Однако некоторые облачные вендоры поддерживают также S3 select: если файлы хранятся в формате json, csv или parquet, поддерживается усеченный SQL c агрегациями и фильтрацией.
FUSE. Объектное хранилище может быть примонтировано к машине как файловая система, и впоследствии взаимодействовать с ним можно так же, как с дисками.
Клиентские приложения, например, S3cmd или AWS (функционал последнего шире, чем взаимодействие с S3). Реализуются команды put, get, ls, cp и так далее.
Многие MPP-решения имеют S3-коннекторы. Например, в Greenplum можно создавать внешнюю таблицу с данными, хранящимися в S3; Hadoop может работать с S3 так же, как с HDFS, и, соответственно, sql-движки (Hive, Impala, Trino и другие) могут работать со структурированными данными в S3.
Управляемые сервисы
MPP
В качестве платформы для DWH или Data Lake может быть выбрана одна из MPP-систем, часто разворачиваемых on-prem. Облачный вендор не только предоставляет мощности для этих систем, но забирает на себя:
автоматическое конфигурирование,
поддержку средств мониторинга,
резервное копирование и восстановление,
шифрование трафика.
В облаке могут как сервис предлагаться различные MPP. Облачный вендор может предоставить как сервис свое решение (например, Oracle Cloud Infrastructure предоставляет Oracle Exadata). Но более подробно хочется остановиться на двух решениях – Hadoop и Greenplum.
Hadoop
Продукты экосистемы Apache Hadoop подходят для построения Data Lake и широко применяются on-prem. Часто используют компоненты:
HDFS – для хранения горячих данных,
Hive, Impala, SparkSQL – для доступа к данным и ELT,
Spark – для ELT и аналитики,
Sqoop – для интеграции с базами данных.
Важное преимущество Hadoop – горизонтальная масштабируемость. Оно эффективно может быть использовано в облаке. Для HDFS разворачивается отдельный data-кластер, который предполагается расширять только при необходимости. А вот для расчетных задач, для запуска MapReduce- и Spark-джобов можно разворачивать compute-кластеры. Эти кластеры легко как увеличить в размерах, так и уменьшить.
Масштабирование кластеров может быть автоматизировано и основываться на проценте загрузки процессорных ядер или на количестве активных YARN-контейнеров. Для расчета витрин могут применяться в том числе и временные кластеры, создаваемые непосредственно перед загрузкой данных и удаляемые сразу после. Такая масштабируемость позволяет сэкономить на удаляемых нодах. Кроме того, такой подход повышает “смелость” ad-hoc аналитики: если для проведения какого-то анализа необходимо докупать железо в дата-центр своей организации, то аналитику придется долго и сложно согласовывать бюджет. Если же для того же самого анализа нужно арендовать на недельку даже очень мощный spark-кластер, то согласование значительно упрощается.
Greenplum
MPP-системы на основе PostgreSQL применяются достаточно широко, в том числе в облаках. Здесь можно отметить Greenplum, Arenadata DB, ApsaraDB AnalyticDB for PostgreSQL. Задачи по обслуживанию вендор может решать не только грамотным использованием стандартного набора утилит, но и правкой кода продукта, ведь Greenplum – это активно развиваемое open-source-решение.
От экосистемы Hadoop Greenplum выгодно отличает поддержка ACID-транзакции. Конечно, использование ACID-механизмов Greenplum требует аккуратности в подходах к обновлению данных. Но в сложносочиненных хранилищах, где одна и та же таблица может использоваться одновременно как приемник данных в одном процессе и как источник данных в другом, без этого обойтись трудно.
В отличие от Hadoop, в Greenplum мы не можем просто отключить половину сегмент-хостов и рассчитывать на то, что расплатимся за это лишь уменьшением производительности. Нет, такие действия приведут еще и как минимум к недоступности данных. Но вот расширение кластера Greenplum в облаке выглядит все еще более простой процедурой, чем on-prem. Для расширения кластера инженерам поддержки нужно лишь:
снять бэкап (это в облаке должно быть простой, быстрой и регулярной процедурой),
выделить в кластер дополнительные хосты,
развернуть бэкап на обновленном кластере.
Дополнительные сервисы
Хранилище не может существовать в вакууме: оно будет просто бесполезно. Коротко остановлюсь на дополнительном инструментарии, который предоставляют в облаках:
сервисы для логирования с автоматическим ротированием логов и управлением доступом;
СУБД наподобие MySQL или PostgreSQL для хранения метаданных. Все как обычно в облаке: резервное копирование, автоматическое обслуживание, отказоустойчивость;
СУБД для презентационного слоя, например, ClickHouse;
инструменты визуализации от вендора;
сервисы для оркестрирования процессов;
инструменты интеграции;
инструменты Data Governance;
виртуальные машины, чтобы установить то ПО, которого не хватает.
Облачное хранилище
Чтобы в полной мере использовать преимущества облачного подхода в построении DWH, MPP-система должна отвечать множеству требований:
обеспечивать гибкое разграничение доступа,
масштабировать compute-мощности и экономно их использовать,
иметь развитый SQL-диалект,
проводить охлаждение старых данных,
дешево хранить бэкапы и обеспечивать быстрый доступ к ним,
практически незаметно для пользователя обновляться и быть доступной 24/7,
шифровать данные и трафик.
В полной мере всему этому набору требований ни одна из изначально заточенных под on-prem MPP-систем не соответствует – по крайней мере из перечисленных выше. Поэтому появились решения, заточенные специально на использование в облаках. О двух из них я скажу ниже: это Snowflake и Databricks.
Snowflake
Snowflake – это не управляемый сервис в каком-то из облаков и тем более не ПО, которое можно развернуть по лицензии. Это отдельный сервис, который позволяет пользователю выбрать региональный дата-центр и облачного вендора для размещения инфраструктуры. На выбор: Microsoft Azure, Amazon Web Services или Google Cloud. После этого пользователю доступны загрузка и хранение данных и доступ к ним посредством SQL – через веб-интерфейс или JDBC- или ODBC-драйвер.
Немного об устройстве Snowflake. В нем разделены хранение и обработка данных. Клиент платит отдельно за хранение и отдельно за их обработку, а также за сетевой трафик.
Сам способ хранения данных не раскрывается. Из официальной документации известно, что данные разбиваются на небольшие порции – микропартиции. Можно задавать “ключ кластеризации” и ожидать, что строки с разными значениями ключа окажутся в разных микропартициях. Удаленные данные еще некоторое время хранятся и доступны при помощи так называемого time travel: выбрать ранее удаленные данные можно при помощи простого SQL-запроса.
Кроме ключа кластеризации и времени хранения time travel-данных, пользователь, по большому счету, никак на хранение данных не влияет: не задает алгоритм сжатия, размер микропартиции, место хранения (сетевой или локальный диск, SSD или HDD, S3 или локальная система). Чем больше места займут данные, тем больше денег заплатит клиент – и это несмотря на то, что сжатие работает прилично и сравнимо по эффективности с известными методами сжатия (gzip, zstd или zlib). Хранение тарифицируется погигабайтно. Обеспечиваются ACID-транзакции.
Обработка данных осуществляется на отдельных compute-инстансах, которые в терминологии Snowflake называются Virtual Warehouse (VWH). VWH отличаются по мощности и проградуированы, как футболки: имеют размеры S, M, L, XL и так далее. Каждый следующий размер в два раза дороже предыдущего, при этом предполагается, что он в два раза быстрее выполняет тот же самый запрос.
Тарификация VWH поминутная, и каждый VWH по умолчанию выключается через 10 минут простоя, а включается моментально по запросу. Пользователь не знает, какие машины используются для каждого VWH, зато для каждого SQL-запроса строится онлайн-профиль выполнения с прогрессом каждого логического шага. При падении любого из шагов, например, при нехватке ресурсов, VWH просто его перезапустит.
Snowflake – это достаточно закрытый и непрозрачный с точки зрения реализации сервис. Однако опыт использования показывает, что это удобный и надежный инструмент с гибким ценообразованием.
Databricks
Другая заточенная под облако платформа – Databricks. Она гораздо более открытая, чем Snowflake, и предоставляется как сервис в маркетплейсах самых популярных облачных вендоров: Microsoft Azure, Amazon Web Services и Google Cloud. Databricks предоставляет ряд сервисов:
Delta lake – слой хранения данных, основанный на открытых форматах,
Data Engineering – ETL-инструмент,
Databricks SQL – serverless-SQL (можно сравнить с VWH в Snowflake),
Unity Catalog – решение для Data Governance,
Delta Sharing – сервис для гибкого управления доступа к данным,
сервисы для машинного обучения и Data Science.
Как выбрать облако для себя
Допустим, ваша организация решила перевести часть своей DWH-инфраструктуры в облако. Как выбрать вендора и на что стоит обращать внимание? На наш взгляд, есть ряд пунктов и вопросов, которым необходимо уделить внимание, чтобы инвестиции в облачное хранение больших данных были эффективными.
Вариативность управляемых сервисов. Все ли ваши потребности покрывают предоставляемые сервисы? Как планы развития вендора соотносятся с вашими планами развития? Если вы давно лелеяли мечту об аккуратном и точном DG-tool’е, а вендор как раз представил свою разработку в Preview, это повод присмотреться внимательнее.
Расположение облачных дата-центров. Даже без учета законодательных ограничений зарубежное облако может оказаться неудачной идеей. Миграция данных, скорее всего, потребует проведения выделенного канала от ЦОДов вашей организации к ЦОДам облака. Стоимость такого канала будет зависеть от расстояния.
Количество ресурсов в распоряжении вендора. Задачи DWH – высоконагруженные, и стоит убедиться в том, что вендор предоставит вам нужные вычислительные мощности.
Какие SLA предоставляет поддержка и насколько она вариативна?
Проекты, успешно завершенные другими клиентами. Какие системы пошли в прод, а какие остались на стадии пилота?
Насколько стабильны в облаке те инструменты, которыми вы собираетесь пользоваться? Здесь стоит снова обратиться к опыту других клиентов и, возможно, провести пилотный проект.
Надеюсь, что обзор был полезен. Если есть вопросы, задавайте, подискутируем.