В нашей компании мы регулярно пробуем и анализируем новые интересные технологии в области хранения и управления большими данными.
В апреле с нами связались представители Snowflake Computing и предложили опробовать их продукт Snowflake Elastic Data Warehouse — облачное хранилище данных.
Они работают над созданием эластичной системы, которую можно было бы легко расширять по мере необходимости — при увеличении объема данных, нагрузки и прочих неприятностей.
Обычно СУБД работают в средах, где количество доступных ресурсов ограничено доступным оборудованием.
Чтобы добавить ресурсы, вам необходимо добавить или заменить серверы.
В облаке ресурсы доступны в тот момент, когда они необходимы, и их можно вернуть, если они больше не нужны.
Архитектура Snowflake позволяет вам в полной мере использовать преимущества облака: ваше хранилище данных может мгновенно расширяться и сжиматься, не прерывая выполнение запросов.
Существуют и другие хранилища данных, работающие в облаках, наиболее известным из которых является Amazon Redshift. Но для их расширения все равно нужно добавлять серверы, пусть и виртуальные.
Что влечет за собой перераспределение данных, а значит и простои в той или иной степени.
О сжатии таких хранилищ вообще речи не идет; никто не хочет лишний раз перекладывать все данные с места на место.
Snowflake предоставляет клиенту эластичное хранилище данных как услугу (Data Warehouse as a Service).
Это высокопроизводительная столбчатая СУБД, поддерживающая стандарт SQL и совместимая с ACID. Доступ к данным осуществляется через веб-интерфейс Snowflake, интерфейс командной строки клиента Snowflake, а также ODBC и JDBC. Мы провели полный цикл тестирования Snowflake, включая тестирование производительности загрузки данных, тестирование SQL-запросов, масштабирование системы и базовые сценарии эксплуатации.
Но прежде чем перейти к результатам тестов, стоит присмотреться к архитектуре.
Архитектура
Snowflake использует Amazon Web Services в качестве своей платформы.СУБД состоит из трех компонентов: уровня хранения данных (Database Storage), уровня обработки данных (Processing) и облачных сервисов (Cloud Services).
Уровень хранения данных отвечает за безопасное, надежное и гибкое хранение данных.
Эти замечательные свойства обеспечивает не сам Snowflake, а S3. Данные хранятся в S3, и клиенты не имеют к ним прямого доступа.
Для загрузки данных в Snowflake создаются специальные бакеты S3 (staging area), куда нужно помещать файлы, из которых затем можно загружать данные с помощью Snowflake SQL. Чтобы создать промежуточную область и скопировать туда файлы, вы можете использовать стандартные Amazon Web Services или специальные функции Snowflake SQL. Вы можете подключить существующие корзины S3 как Staging area, тогда файлы можно будет загружать без предварительного копирования.
При загрузке данные сжимаются (gzip) и конвертируются в столбчатый формат. Snowflake не предоставляет индексы.
Распределение данных осуществляется автоматически на основе статистики использования данных.
Разделения нет. Доступ к данным осуществляется через уровень обработки данных представляет собой набор виртуальных серверов, которые могут получить доступ к файлам S3. «Виртуальные кластеры» могут состоять из 1 (X-Small), 2 (Small), 4 (Medium), 8 (Large) или 16 (X-Large) виртуальных серверов (EC2).
Все серверы в виртуальном кластере идентичны и эквивалентны; клиент не имеет к ним прямого доступа.
С точки зрения клиента виртуальный кластер — это единое целое.
Серверы EC2 могут быть двух типов: Standard и Enterprise. На момент тестирования в качестве стандартного использовался EC2 с 16 ГБ ОЗУ, 160 ГБ SSD, 8 ядрами.
Предприятие - в 2 раза больше.
У Snowflake есть соглашение с Amazon; они получают новые экземпляры в течение 5 минут. Те.
расширение виртуального кластера или создание нового занимает 1-5 минут. Поскольку EC2 не хранит никаких данных, их потеря совсем не критична.
В случае сбоя EC2 просто создается заново.
SSD виртуальных серверов используются в качестве кэша кластера.
При выполнении запроса данные из S3 попадают в кеш кластера, и все последующие запросы будут использовать этот кеш.
Когда данные находятся в кеше, запросы выполняются до 10 раз быстрее.
Вы можете создать несколько виртуальных кластеров, которые будут одновременно обращаться к одним и тем же данным.
Это позволяет лучше распределять нагрузку.
Вы можете, например, использовать разные виртуальные кластеры для доступа к разным таблицам — в этом случае данные из разных таблиц будут кэшироваться разными кластерами, что фактически увеличит размер кэша базы данных.
Используется для управления данными облачные сервисы Снежинка.
Используя пользовательский интерфейс Snowflake, клиент создает базы данных и таблицы, пользователей и роли.
Метаданные используются на уровне обработки данных для определения наличия необходимых прав доступа, для составления запросов и т. д. Snowflake не объясняет, как и где хранятся метаданные.
Для каждого виртуального кластера необходимо выбрать базу данных, с которой он будет работать.
Перед выполнением запроса пользователь должен указать, какой кластер должен его выполнить.
Вы можете установить кластер по умолчанию.
Кластеры можно запускать по расписанию, можно автоматически при поступлении запроса, можно останавливать их автоматически, если запросы не поступают в течение определенного времени.
Вы также можете увеличить или уменьшить количество серверов в работающем кластере.
В результате клиент получает эластичное хранилище, которое никак не ограничено по размеру.
Никаких действий по установке, настройке или обслуживанию не требуется — Snowflake обо всем позаботится.
Вам просто нужно зайти на сайт, создать таблицы, загрузить данные и выполнить запрос.
Особенности
Снежинка имеет несколько интересных особенностей.Например, можно восстановить недавно удаленный объект: таблицу, схему или даже базу данных.
Другая функция позволяет просматривать результаты недавно выполненного запроса.
Для повторного просмотра данные доступны в течение 24 часов только пользователю, выполнившему запрос.
Для просмотра сохраненных результатов вам не нужен виртуальный кластер, поскольку Snowflake хранит их вместе с метаданными.
Snowflake очень гордится своей способностью обрабатывать полуструктурированные данные, такие как JSON или Avro. Данные загружаются как есть, без каких-либо преобразований и без определенной схемы.
Затем вы можете получить к ним доступ в SQL, указав определенные «поля» записи.
В рамках тестирования мы не проверяли скорость таких вызовов, но обычно в таких случаях производительность приносится в жертву удобству.
Например, в Vertica этот функционал работает гораздо медленнее, чем запросы к обычным таблицам.
Цена
Стоимость услуги состоит из оплаты объема данных в S3 и почасовой оплаты используемых виртуальных серверов.Те.
если у клиента 2 виртуальных кластера по 4 сервера в каждом, и они проработали 9 часов 3 минуты, то ему придется заплатить за 2*4*10=80 часов работы сервиса.
Важно, что виртуальные серверы оплачиваются только за время их работы.
Это позволяет существенно сэкономить, если нагрузка в течение дня неравномерна или система используется лишь изредка.
Тестирование
Наш тестовый набор данных состоял из одной большой таблицы (чуть более 1 миллиарда строк) и нескольких маленьких (от 100 до 100 тысяч строк) — простая схема «звезда».Данные были загружены из текстовых файлов в формате CSV. Snowflake рекомендует загружать данные небольшими порциями, по одному файлу на ядро процессора — так ресурсы будут использоваться наиболее эффективно.
Для этого вам необходимо разделить файл на части, прежде чем он попадет в область Staging. Копировать данные из одной таблицы в другую еще быстрее.
При изменении данных таблица блокируется исключительно (чтение возможно, все DML-запросы ставятся в очередь).
Время загрузить 1 миллиард строк из текстового файла и таблицы
| Размер кластера | Вставка из файла | Время |
|---|---|---|
| Средний (4 EC2) | 1 файл 8 ГБ скопируйте в таблицу1 из @~/file/file.txt.gz file_format='csv' | 42 м 49,663 с |
| Средний (4 EC2) | 11 файлов по 750 МБ каждый скопируйте в таблицу1 из @~/file/file_format='csv' | 3м 45.272с |
| Малый (2 EC2) | 11 файлов по 750 МБ каждый скопируйте в таблицу1 из @~/file/file_format='csv' | 4м 33.432с |
| Копирование из другой таблицы | ||
| Средний (4 EC2) | вставить в таблицу2 выбрать * из таблицы1 | 1м 30.713с |
| Малый (2 EC2) | вставить в таблицу2 выбрать * из таблицы1 | 2м 42.358с |
Вот Снежинка нас порадовала; запросы к двум-трем таблицам с фильтрами, как большими, так и маленькими, выполнялись довольно быстро.
Например, выберите count(*), sum(float1) из таблицы.
| Размер кластера | Размер стола | Первый запуск (S3) | Перезагрузить (кэш) |
|---|---|---|---|
| Малый (2 EC2) | 1 миллиард строк, 24,4 ГБ | 22,48 сек.
|
1,91 сек.
|
| Малый (2 EC2) | 5 миллиардов строк | 109 секунд | 7,34 секунды |
| Средний (4 EC2) | 1 миллиард строк, 24,4 ГБ | 10,67 сек.
|
1,2 секунды |
| Средний (4 EC2) | 5 миллиардов строк | 3,65 сек.
|
Также видно, что Snowflake хорошо масштабируется, т.е.
увеличение количества серверов в кластере дает практически линейный прирост производительности.
Для анализа полученных результатов всегда нужен эталон.
В нашем случае это результаты того же теста на кластере Vertica из 5 серверов.
Все пять серверов одинаковы: 2xE5-2630, 32 ГБ ОЗУ, 8x1000 ГБ R10 SATA. Сравнение времени выполнения тестовых запросов между Snowflake и Vertica
| Снежинка (первая) | Снежинка (вторая) | Вертика | |
|---|---|---|---|
| Размер кластера | Средний (4 EC2) | Средний (4 EC2) | кластер из 5 серверов |
| Размер таблицы (строки) | 1000000000 | 1000000000 | 1000000000 |
| выберите количество (*) из таблицы 1 | 0.2 | 0.27 | 0.69 |
| выберите счетчик (*), сумму (с плавающей запятой1) из таблицы 1 | 10.6 | 1.33 | 2.89 |
| выберите count(*), sum(float1) из таблицы1, где страна_ключ = 1 | 5.8 | 1.41 | 3.63 |
| выберите count(*), sum(float1) из таблицы1 a, страна с где c.country_code='США' и a.country_key=c.country_key | 2.3 | 1.70 | 2.14 |
| выберите count(*), sum(float1) из таблицы1 a, страна c где c.country_code='ZA' и a.country_key=c.country_key; | 2.1 | 1.51 | 1.94 |
| выберите счетчик (*), сумму (с плавающей запятой1), c.country_code из таблицы 1 а, страна в где a.country_key=1 и a.country_key=c.country_key группировать по c.country_code | 2.3 | 1.99 | 2.17 |
| выберите count(*), sum(float1), c.country_code из таблицы1 a, страна c где a.country_key> -1 и a.country_key<100000 и a.country_key=c.country_key группировать по c.country_code; | 4.4 | 4.17 | 3.26 |
| выберите count(*), sum(float1), c.country_code из таблицы1 a, страна c где c.country_code in('США', 'ГБ') и a.country_key=c.country_key группировать по c.country_code; | 2.3 | 2.22 | 2.42 |
| выберите count(*), sum(float1), c.country_code из таблицы1 a, страна c где c.country_code in('США', 'ГБ') и a.country_key=c.country_key и a.time_key<45000 группировать по c.country_code; | 3.8 | 1.47 | 1.03 |
| выберите count(*), sum(float1), c.country_code из таблицы1 a, страна c, время т где c.country_code in('США', 'ГБ') и a.country_key=c.country_key и t.date> ='2013-03-01' и t.date<'2013-04-01' и t.time_key=a.time_key группировать по c.country_code; | 3.3 | 1.97 | 1.23 |
| выберите count(*), sum(float1), c.country_code, r.revision_name из таблицы1 a, страна c, время t, редакция р где c.country_code в («США», «GB») и a.country_key=c.country_key и t.date> ='2013-03-01' и t.date<'2013-04-01' and t.time_key=a.time_key и r.revision_key=a.revision_key группа по c.country_code, r.revision_name ; | 4.4 | 2.66 | 1.49 |
| Общее время выполнения теста, секунды | 41.5 | 20.69 | 22.89 |
Более того, Snowflake по сканированию значительно опережает Vertica, но по мере усложнения запросов начинает отставать.
К сожалению, не ясно, в какой степени можно рассчитывать на кэш.
Мониторинг недоступен, а статистику использования просмотреть невозможно.
Вы можете видеть только то, сколько данных нужно было прочитать для выполнения того или иного запроса, но не можете увидеть, откуда эти данные были прочитаны, из кэша или из S3. Также необходимо учитывать, что при изменении данных таблицы кэш аннулируется.
Однако данные синтетических тестов никогда не следует использовать для прогнозирования реальной производительности.
На следующем этапе мы попытались воспроизвести процедуру загрузки данных, которую используем в Vertica. Сначала данные из файла загружаются в очень широкую таблицу (около 200 полей), а затем с разной степенью детализации агрегируются и переносятся в другие таблицы.
Вот тут и начали возникать проблемы.
Компиляция запросов с большим количеством таблиц или столбцов может занять несколько минут. Если для выполнения запроса не хватало памяти, сообщения не выводились, а просто возвращался неверный результат. Сообщения об ошибках часто были неинформативными, и особенно сложно было диагностировать несоответствие формата при загрузке.
Мы прекратили тестирование, поскольку стало ясно, что Snowflake еще не готова удовлетворить наши потребности.
Заключение
Тестирование длилось около месяца.За это время специалисты Snowflake оказали нам поддержку, помогли советами и даже исправили пару ошибок.
Технология интересная, возможность менять количество ресурсов на лету выглядит очень привлекательно.
Облачное хранилище данных может быть достойным вариантом, если проект новый и данных пока не так много.
Особенно если судьба проекта неизвестна, а в инфраструктуру хранения и обработки данных вкладываться не хочется.
Но планировать перенос всех данных и систем в облако пока рано.
Теги: #снежинка #SaaS / S+S #Большие данные
-
Информационная Доска Своими Руками
19 Oct, 24 -
Три Истории Модернизации Дата-Центров
19 Oct, 24
