Распределенные cистемы хранения данных для аналитики:

Vertica и другие системы

Александр Зайцев

О чем мы будем говорить

• Что такое аналитика больших данных

• Функциональные требования

• Технические сложности и проблемы

• Как они решаются или не решаются в разных распределенных системах

Откуда я об этом знаю?

• LifeStreet: • Performance advertising с 2006г • Top FaceBook In-Apps ad network c 2010г • RTB c 2012г

• Аналитическая инфраструктура – ключевой компонент • Каждый год нагрузка вырастает в 2-3 раза

• Сейчас (октябрь 2013) – 4 миллиарда событий в день

• Попробовали разные решения и продолжаем пробовать

Что такое большие данные • БАК (LHC) генерирует 40TB/sec

• В 2011 году всего было сгенерировано 1.8 зеттабайт

• Закон Мура для данных

• Веб-логи

• Игры (Zynga – 5TB/day два года назад)

Непрерывный поток данных

• надо писать быстро

• нельзя останавливаться

• желательно выживать при частичном отказе железа (чтобы не останавливаться)

• желательно дублирование (как минимум) в реальном времени

Многомерный анализ данных • Данные моделируются как многомерные кубы:

• сотни измерений (дискретных и непрерывных)

• десятки метрик

• Способы работы: • Сечения (фильтры)

• Проекции (агрегирование)

• Объединения кубов или проекций

Ip | access_time | user_agent |page_url | response_code | response_time

Измерения: • IP (+ geo lookup) • Время (иерархия: Год, Дата, Час, Минута и т.д.) • Пользовательский агент (2 или более иерархий, по браузеру по OS) • Ресурс (иерархия по структуре URL) • Код ответа

Метрики: • Время ответа • Количество запросов • Количество успешных запросов (HTTP200)

Кубы, сечения, проекции

N-dimensional cube

M-dimensional projection

сечение

Типичный аналитический запрос: агрегация + range filter + group by на маленькое подмножество измерений

Range filter

Query result

Аналитические запросы

• Сканирование и агрегирование больших объемов данных

=> очень много IO и CPU на типичный запрос

• В разных направлениях (измерениях) => кэш, индексы – все работает плохо

Как получить хорошую производительость?

Две стратегии:

1. «Уменьшить» данные

2. Увеличить IO/CPU системы

Лучше все сразу

Как можно «уменьшить» данные

• Логическая модель (нормализация и т.д.)

• Физическое хранение данных • Компрессия

• Кодирование

• Физическая модель – локализация данных: • Индексы, партиционирование, row/column store,

сегментирование/шардинг

Как можно увеличить IO/CPU

• RAID • RAID5 vs RAID10

• Использование всех ядер для одного запроса

• Распределенная система

Преимущества распределенных систем • «Размазывание» данных по серверам

• Больше объем дисков

• Быстрее доступ к большему объему

• Сложение вычислительных ресурсов

• Масштабируемость

• Надежность за счет дублирования

Сложности распределенных систем • Надежность

• Балансировка/перестройка кластера

• Не все алгоритмы хорошо распределяются (select distinct)

• Cеть

Итак

• Для аналитических задач нам нужна система: • Распределенная для производительности и

надежности

• Эффективно хранящая данные

• Хорошо локализующая данные

• Быстро загружающая новые данные

• Управляемая

• Разумно стоящая

Отступление: из чего складывается стоимость

• Стоимость железа (лучше чужого)

• Стоимость лицензии и поддержки, если есть

• Стоимость внутреннего администрирования и разработки

• Стоимость простоя из-за отказов железа или софта

Какие есть варианты?

• Не самые удачные: • Обычные коммерческие базы данных – не интересно

• In-memory DBs (e.g. MemSQL) – очень дорого и не очень надежно

• NoSQL Dynamo-like – не предназначены для агрегации и больших range scans

Какие есть варианты?

• Стоящие рассмотрения: • MySQL + специализированный engine + шардинг

• Аналитические MPP базы данных

• Hadoop Stinger

Что можно «выжать» из MySQL

• MySQL NDB Cluster – работает только на небольших данных в памяти и плохо агрегирует

• TokuDB – storage engine для аналитики

• Шардинг (dbShards, Shard-Query, ScaleDB, ScaleBase) – распределенность, но

• Тяжело управлять • Часто неэффективные запросы и джойны • Кроме Shard-Query – не бесплатны

Пару слов про TokuDB • Компрессия (примерно в 5 раз)

• Хорошо «держит» большие объемы за счет структуры индекса (сотни GB)

• Производительность перестройки индекса не падает с ростом размера таблиц

• Сокращает время доступа к данным за счет «кластеризующих» индексов

• Выполнение аналитических запросов в 5-10 раз быстрее, чем InnoDB

• 5 раз компрессия и до двух раз из-за «кластеризующего» индекса

Рабочий вариант

• TokuDB + Shard-Query

• 100-200GB/server

• Ограничения: • shard column одна для всех таблиц

• Нет центрального управления, все вручную

• TokuDB плохо работает при больших range scan

• И еще одно...

Help! Help, I need somebody Help, not just anybody Help, you know I need someone, help When I was younger so much younger than today I never needed anybody's help in any way But now these days are gone, I'm not so self assured Now I find I've changed my mind and opened up the doors Help me if you can, I'm feeling down And I do appreciate you being round Help me get my feet back on the ground Won't you please, please help me

Help Help Help, Help help Help Help help

Строки vs. колонки • Колонки Row store Column store

Таблица хранится по строкам Каждая колонка хранится отдельно

При любом обращении строка читается целиком

При обращении к полю, читается только одна колонка или ее фрагмент

Данные по строкам плохо сжимаются Колонки отлично сжимаются

Дешевый update/delete Дорогой update/delete

Легко реализуется Достаточно сложно реализуется

Пример

Таблица T 100 bigint колонок и 1 000 000 000 записей

select sum(x) from T;

Row store: 1 000 000 000 * 100 * 8 = 800 GB

Column store: 1 000 000 000 * 1 * 8 = 8 GB

Если учесть компрессию, то на порядок меньше

Колоночные RDBMS • Open Source:

• C-Store (pre-Vertica) • MonetDB (pre-VectorWise) • LucidDB

• Коммерческие • Sybase IQ • InfoBright * • InfiniDB * • ParAccel (and Amazon Redshift) • GreenPlum (“эмуляция” на PostgreSQL) • Vertica * • VectorWise * Есть бесплатные версии ограниченной функциональности

79

215

61

3,22 2,42

0

50

100

150

200

250

MonetDB TokuDB InfoBright EE

ParAccel Vertica

• 1140M строк в таблице • 20 колонок (int, float) • 5 серверов (native/ Shard-Query)

select

country_code,

count(*),

sum(revenue)

From test_table a,

dim_country c

where country_code in ('US’,'GB')

and a.country_key=c.country_key

group by country_code;

Vertica – это:

• Колонки! • Нет индексов!! • Нет таблиц!!! • Эффективная компрессия данных

• У нас в среднем в 13 раз, но может достигать и до 10....00 раз на колонку

• Полный контроль над физической организацией • Очень быстрая загрузка • Shared nothing MPP

Vertica: проекции

• Таблиц физически нет, это логическая абстракция

• Проекции (projection) • Подмножество колонок с сортировкой

• Для каждой таблицы есть супер-проекция = все колонки

• Для одной таблицы может быть любое число проекций разной структуры

Vertica: проекции

• Тип кодирования колонок: • RLE

• DELTAVAL

• BLOCK_DICT

• И еще 12 разных способов

• Сортировка! (особенно важна для RLE)

• Группы колонок (фрагменты строк)

• Сегментация по узлам кластера

Vertica: физическое хранение

• Большие блоки (мин 1Mb), после записи не меняются

• Автоматическое объединение (со сборкой мусора и перекодированием)

• Оптимизировано на последовательное чтение-запись с диска

• Оптимизировано под кэш уровня OS или контроллера

Vertica: выполнение запросов • Только «нужные» колонки • Предикаты могут выполняться на закодированных

колонках • Сильно зависит от структуры проекций (не таблиц) • Ключевые инструменты – RLE с сортировкой и

сегментация • Предикаты по отсортированной колонке ~ индексы • Джойны – merge, hash • Группировка, pipelined group by

Любой запрос, это ...

Full Scan

Как работает сортировка и RLE

M

F

1-20

21-25

26-35 36+

Gender Age

1-20 21-25

26-35

36+

select sum(impressions) from t

where gender=‘M’ and age=‘21-25’

Impressions

1 I/O 1 I/O 1 I/O

M

F

1-20

21-25

26-35 36+

Gender Age

1-20

26-35

36+

select sum(impressions) from t

where age=‘21-25’

Impressions

2 I/O 2 I/O

21-25

Как работает сортировка и RLE

Сортировка и pipelined group-by

A

B B C

D D

A

C

SELECT X, COUNT(*) FROM T GROUP BY X

X (sorted)

• Выполняется в один проход • Почти не расходует память (stream) • Для кластера, если сегментировать по X, то тоже в один проход

…

A: 2 B: 2 C: 2 D: 2 Сегментация

по узлам

Сортировка и merge join

A

B B C

D D

A

C

X (sorted)

A

C

D

B

Y (sorted)

• Работает, если сортировка одинаковая с обеих сторон • Для кластера:

• одинаковая сегментация, или • одна из таблиц несегментирована (обычно)

Сегментация по узлам

Vertica: загрузка данных

• Две зоны хранения: • WOS (in-memory)

• ROS (on-disk)

• Перенос из WOS в ROS автоматический (можно force)

• Загрузка большими порциями очень быстрая: • В ROS: порядка 2-5M «колонок» в секунду на сервер

• В WOS: еще быстрее, но может быть переполнение

Vertica: кластер • 3..N одинаковых узлов – архитектура shared nothing • Конфигурируется на уровне проекции

• Несегментированные – каждая нода содержит полные данные

• Сегментированные – каждая нода 1/N данных • K-safety level – уровень дублирования

1 2 3 4 5

A A A A A

A B C D E

E A B C D

Несегментированная

Сегментированная, K=1 со сдвигом 1

Vertica: aдминистрирование

• Переконфигурирования кластера – все на лету • Выключение/включение узла • Замена узла • Добавление узла • Изменение проекций • И т. д.

• Как этого добиваются?

• Рестарт – только при апгрейде версии софта

Vertica: cколько «тянет» один сервер/узел • 5 TB raw data или ~500 GB на диске

• Если физический дизайн правильно настроен под конкретные задачи

• Примерный сервер: • 2xE5620 или E5630 • 24-64GB RAM – зависит от задач и режима использования • 250-300GB SATA/SAS диски в RAID5 или RAID10

• Для кластера – 1Gb сеть между узлами (желательно, private)

• Кластер на 3х узлах ~= отдельному серверу по скорости • Почему? K-safety=1 + сеть

Vertica: cколько стоит?

• It depends

• Лицензируется объем сырых данных в «боевой» системе

• Единовременно + support fee

• Верхняя граница -- $100K за 1TB (list price)

• Нижняя граница $2M за 1PB или $2K за 1TB

Vertica Community Edition

• 1 TB данных, 3 сервера в кластере

• Достаточно для любых тестов, POC и т.д.

• На объемах до 1TB обгонит всех БЕСПЛАТНО

Сравнимые альтернативы?

ParAccel

• Тоже быстрая колоночная MPP RDBMS

• Может быть быстрее Vertica на ad-hoc запросах

• Используется как бэкенд Amazon Redshift

ParAccel – основные отличия

• Ограниченные возможности настройки физической структуры, только одна сортировка на таблицу

• Неэффективный Vacuum («сборка мусора»)

• Нет партиционирования

• Только последовательная загрузка

• Два типа узлов: Leader Node (1) и Сompute Nodes (N)

• Все кластерные операции требуют остановки БД

• Более высокие требования к железу и сети

• Лицензия per server/node

Hadoop

• Исторически – batch processing

• Долгий старт задачи на больших кластерах

• HDFS медленная

• Материализация на диск промежуточных этапов

• Hive неэффективен

• Слишком generic

Hadoop vs Vertica

• SIGMOD 2009 paper: A Comparison of Approaches to Large-Scale Data Analysis http://database.cs.brown.edu/papers/benchmarks-sigmod09.pdf

• В «идеальных условиях» в среднем в 10 раз медленнее, чем Vertica

• Агрегация медленнее в 15 раз • Джойны – в 20-30

• Hive примерно в 100 раз медленнее (наши тесты 2012)

HadApt

• Hadoop инфраструктура поверх PosgtreSQL

• Очевидные преимущества PostgreSQL над HDFS

• Те же недостатки Hadoop, плюс недостатки row store

Hadoop Stinger

• http://hortonworks.com/labs/stinger/

• Часть Hadoop 2.0

• Декларируемая Цель: ускорить Hive в 100 раз

Hadoop Stinger: как?

• ORC – новый колоночный формат HDFS: • RLE, dictionary encoding etc.

• SQL типы данных и прочая SQL-семантика на уровне платформы

• HСatalog – новое эффективное хранилище метаданных

• Tez – новый MR-«движок», заточенный под Hive • Нет промежуточной материализации, наконец-то! • 100ms время старта

• Новый cost-based query optimizer

Hadoop Stinger: когда?

• Частично уже (Oct 2013 -- HDP 2.0, Hive 0.12), утверждается увеличение производительности SQL/Hive в 35-40 раз

• Полностью – coming soon

• Будем пробовать

Резюме

Спасибо

Alexander.Zaitsev @ LifeStreet.com