Всем привет! Сегодня хотим затронуть тему облачных технологий. Дмитрий Морозов, архитектор DWH в компании GlowByte, занимается хранилищами данных 6 лет, последние 2,5 года участвует в проектах, использующих облака. В этой статье он сделает обзор облачных решений, которые могут быть полезны для задач хранения больших данных, а также уделит внимание вопросам выбора облачного хранилища. Статья основана на личном опыте, может быть интересна как разработчикам, дата-инженерам, так и менеджерам, отвечающим за корпоративную Big Data-инфраструктуру и ищущим возможности ее масштабировать. Облачные сервисы – это предоставляемые в аренду ресурсы для вычислений и хранения данных. Облачный вендор предлагает клиенту виртуальные машины, диски и ресурсы для serverless-вычислений, забирая на себя целый комплекс технических мероприятий по их развертыванию и поддержке. Клиент же получает не только непосредственно ресурс или услугу, но и возможность принципиально по-новому подходить к масштабированию и оптимизации затрат на железо и софт. Такие услуги могут быть полезны для решения множества задач, но ниже мы поговорим о том, как облака помогают решать задачи хранения и обработки данных. Данные, к которым не требуется быстрый доступ, часто предпочитают “охладить”. Их удаляют с дорогих дисков основной платформы хранения (DWH или Data Lake) и перемещают в архив. Технически архив может быть устроен как массив устройств хранения (дисков и лент). Также часто архивной системой выступает Hadoop-кластер: данные хранятся в HDFS, а для анализа доступны через различные SQL-движки. Облачные вендоры предоставляют сервис 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. В качестве платформы для DWH или Data Lake может быть выбрана одна из MPP-систем, часто разворачиваемых on-prem. Облачный вендор не только предоставляет мощности для этих систем, но забирает на себя: автоматическое конфигурирование, поддержку средств мониторинга, резервное копирование и восстановление, шифрование трафика. В облаке могут как сервис предлагаться различные MPP. Облачный вендор может предоставить как сервис свое решение (например, Oracle Cloud Infrastructure предоставляет Oracle Exadata). Но более подробно хочется остановиться на двух решениях – Hadoop и Greenplum. Продукты экосистемы Apache Hadoop подходят для построения Data Lake и широко применяются on-prem. Часто используют компоненты: HDFS – для хранения горячих данных, Hive, Impala, SparkSQL – для доступа к данным и ELT, Spark – для ELT и аналитики, Sqoop – для интеграции с базами данных. Важное преимущество Hadoop – горизонтальная масштабируемость. Оно эффективно может быть использовано в облаке. Для HDFS разворачивается отдельный data-кластер, который предполагается расширять только при необходимости. А вот для расчетных задач, для запуска MapReduce- и Spark-джобов можно разворачивать compute-кластеры. Эти кластеры легко как увеличить в размерах, так и уменьшить.  Масштабирование кластеров может быть автоматизировано и основываться на проценте загрузки процессорных ядер или на количестве активных YARN-контейнеров. Для расчета витрин могут применяться в том числе и временные кластеры, создаваемые непосредственно перед загрузкой данных и удаляемые сразу после. Такая масштабируемость позволяет сэкономить на удаляемых нодах. Кроме того, такой подход повышает “смелость” ad-hoc аналитики: если для проведения какого-то анализа необходимо докупать железо в дата-центр своей организации, то аналитику придется долго и сложно согласовывать бюджет. Если же для того же самого анализа нужно арендовать на недельку даже очень мощный spark-кластер, то согласование значительно упрощается. 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 – это не управляемый сервис в каком-то из облаков и тем более не ПО, которое можно развернуть по лицензии. Это отдельный сервис, который позволяет пользователю выбрать региональный дата-центр и облачного вендора для размещения инфраструктуры. На выбор: 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. Она гораздо более открытая, чем 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 предоставляет поддержка и насколько она вариативна?  Проекты, успешно завершенные другими клиентами. Какие системы пошли в прод, а какие остались на стадии пилота? Насколько стабильны в облаке те инструменты, которыми вы собираетесь пользоваться? Здесь стоит снова обратиться к опыту других клиентов и, возможно, провести пилотный проект. Надеюсь, что обзор был полезен. Если есть вопросы, задавайте, подискутируем.