Всем привет! Сегодня хотим затронуть тему облачных технологий. Дмитрий Морозов, архитектор 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-хранилище, весьма вариативен. Существуют такие способы:

1. REST API. Реализуются интуитивные для файловой системы методы: вернуть список объектов, положить новый объект, получить объект, скопировать, удалить. Однако некоторые облачные вендоры поддерживают также S3 select: если файлы хранятся в формате json, csv или parquet, поддерживается усеченный SQL c агрегациями и фильтрацией.
2. FUSE. Объектное хранилище может быть примонтировано к машине как файловая система, и впоследствии взаимодействовать с ним можно так же, как с дисками.
3. Клиентские приложения, например, S3cmd или AWS (функционал последнего шире, чем взаимодействие с S3). Реализуются команды put, get, ls, cp и так далее.
4. Многие 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. Для расширения кластера инженерам поддержки нужно лишь:

• снять бэкап (это в облаке должно быть простой, быстрой и регулярной процедурой),
• выделить в кластер дополнительные хосты,
• развернуть бэкап на обновленном кластере.

Дополнительные сервисы

Хранилище не может существовать в вакууме: оно будет просто бесполезно. Коротко остановлюсь на дополнительном инструментарии, который предоставляют в облаках:

1. сервисы для логирования с автоматическим ротированием логов и управлением доступом;
2. СУБД наподобие MySQL или PostgreSQL для хранения метаданных. Все как обычно в облаке: резервное копирование, автоматическое обслуживание, отказоустойчивость;
3. СУБД для презентационного слоя, например, ClickHouse;
4. инструменты визуализации от вендора;
5. сервисы для оркестрирования процессов;
6. инструменты интеграции;
7. инструменты Data Governance;
8. виртуальные машины, чтобы установить то ПО, которого не хватает.

Облачное хранилище

Чтобы в полной мере использовать преимущества облачного подхода в построении DWH, MPP-система должна отвечать множеству требований:

1. обеспечивать гибкое разграничение доступа,
2. масштабировать compute-мощности и экономно их использовать,
3. иметь развитый SQL-диалект,
4. проводить охлаждение старых данных,
5. дешево хранить бэкапы и обеспечивать быстрый доступ к ним,
6. практически незаметно для пользователя обновляться и быть доступной 24/7,
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 предоставляет ряд сервисов:

1. Delta lake – слой хранения данных, основанный на открытых форматах,
2. Data Engineering – ETL-инструмент,
3. Databricks SQL – serverless-SQL (можно сравнить с VWH в Snowflake),
4. Unity Catalog – решение для Data Governance,
5. Delta Sharing – сервис для гибкого управления доступа к данным,
6. сервисы для машинного обучения и Data Science.