Big Data в облаках

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

В качестве платформы для DWH или Data Lake может быть выбрана одна из MPP-систем, часто разворачиваемых on-prem. Облачный вендор не только предоставляет мощности для этих систем, но забирает на себя:

В облаке могут как сервис предлагаться различные MPP. Облачный вендор может предоставить как сервис свое решение (например, Oracle Cloud Infrastructure предоставляет Oracle Exadata). Но более подробно хочется остановиться на двух решениях – Hadoop и Greenplum.

Продукты экосистемы Apache Hadoop подходят для построения Data Lake и широко применяются on-prem. Часто используют компоненты:

Важное преимущество 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. Для расширения кластера инженерам поддержки нужно лишь:

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

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

В полной мере всему этому набору требований ни одна из изначально заточенных под 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 предоставляет ряд сервисов:

Допустим, ваша организация решила перевести часть своей DWH-инфраструктуры в облако. Как выбрать вендора и на что стоит обращать внимание. На наш взгляд, есть ряд пунктов и вопросов, которым необходимо уделить внимание, чтобы инвестиции в облачное хранение больших данных были эффективными.

Надеюсь, что обзор был полезен. Если есть вопросы, задавайте, подискутируем.