Документ обсуждает распределенные системы хранения данных, таких как Vertica, в контексте аналитики больших данных, затрагивая функциональные требования, технические сложности и стратегии оптимизации производительности. Упоминаются различные подходы к моделированию и хранению данных, преимущества и недостатки распределенных систем, а также их стоимость и возможности. Также рассматриваются альтернативы, такие как MySQL с специализированными движками и NoSQL решения.

1. Распределенные cистемы хранения
данных для аналитики:
Vertica и другие системы
Александр Зайцев

2. О чем мы будем говорить
• Что такое аналитика больших данных
• Функциональные требования
• Технические сложности и проблемы
• Как они решаются или не решаются в разных
распределенных системах

3. Откуда я об этом знаю?
• LifeStreet:
• Performance advertising с 2006г
• Top FaceBook In-Apps ad network c 2010г
• RTB c 2012г
• Аналитическая инфраструктура – ключевой компонент
• Каждый год нагрузка вырастает в 2-3 раза
• Сейчас (октябрь 2013) – 4 миллиарда событий в день
• Попробовали разные решения и продолжаем
пробовать

4. Что такое большие данные
• БАК (LHC) генерирует 40TB/sec
• В 2011 году всего было сгенерировано 1.8
зеттабайт
• Закон Мура для данных
• Веб-логи
• Игры (Zynga – 5TB/day два года назад)

5. Непрерывный поток данных
• надо писать быстро
• нельзя останавливаться
• желательно выживать при частичном отказе
железа (чтобы не останавливаться)
• желательно дублирование (как минимум) в
реальном времени

6. Многомерный анализ данных
• Данные моделируются как многомерные кубы:
• сотни измерений (дискретных и непрерывных)
• десятки метрик
• Способы работы:
• Сечения (фильтры)
• Проекции (агрегирование)
• Объединения кубов или проекций

7. Ip | access_time | user_agent |page_url | response_code | response_time
Измерения:
• IP (+ geo lookup)
• Время (иерархия: Год, Дата, Час, Минута и т.д.)
• Пользовательский агент (2 или более иерархий, по браузеру по OS)
• Ресурс (иерархия по структуре URL)
• Код ответа
Метрики:
• Время ответа
• Количество запросов
• Количество успешных запросов (HTTP200)

8. Кубы, сечения, проекции
Типичный аналитический запрос: агрегация +
range filter + group by на маленькое подмножество измерений
Query result
N-dimensional
cube
сечение
M-dimensional
projection
Range filter

9. Аналитические запросы
• Сканирование и агрегирование больших
объемов данных
=> очень много IO и CPU на типичный запрос
• В разных направлениях (измерениях)
=> кэш, индексы – все работает плохо

10. Как получить хорошую
производительость?
Две стратегии:
1. «Уменьшить» данные
2. Увеличить IO/CPU системы
Лучше все сразу

11. Как можно «уменьшить» данные
• Логическая модель (нормализация и т.д.)
• Физическое хранение данных
• Компрессия
• Кодирование
• Физическая модель – локализация данных:
• Индексы, партиционирование, row/column store,
сегментирование/шардинг

12. Как можно увеличить IO/CPU
• RAID
• RAID5 vs RAID10
• Использование всех ядер для одного запроса
• Распределенная система

13. Преимущества распределенных
систем
• «Размазывание» данных по серверам
• Больше объем дисков
• Быстрее доступ к большему объему
• Сложение вычислительных ресурсов
• Масштабируемость
• Надежность за счет дублирования

14. Сложности распределенных
систем
• Надежность
• Балансировка/перестройка кластера
• Не все алгоритмы хорошо распределяются
(select distinct)
• Cеть

15. Итак
• Для аналитических задач нам нужна система:
• Распределенная для производительности и
надежности
• Эффективно хранящая данные
• Хорошо локализующая данные
• Быстро загружающая новые данные
• Управляемая
• Разумно стоящая

16. Отступление: из чего
складывается стоимость
• Стоимость железа (лучше чужого)
• Стоимость лицензии и поддержки, если есть
• Стоимость внутреннего администрирования и
разработки
• Стоимость простоя из-за отказов железа или
софта

17. Какие есть варианты?
• Не самые удачные:
• Обычные коммерческие базы данных – не интересно
• In-memory DBs (e.g. MemSQL) – очень дорого и не
очень надежно
• NoSQL Dynamo-like – не предназначены для
агрегации и больших range scans

18. Какие есть варианты?
• Стоящие рассмотрения:
• MySQL + специализированный engine + шардинг
• Аналитические MPP базы данных
• Hadoop Stinger

19. Что можно «выжать» из MySQL
• MySQL NDB Cluster – работает только на небольших
данных в памяти и плохо агрегирует
• TokuDB – storage engine для аналитики
• Шардинг (dbShards, Shard-Query, ScaleDB, ScaleBase)
– распределенность, но
• Тяжело управлять
• Часто неэффективные запросы и джойны
• Кроме Shard-Query – не бесплатны

20. Пару слов про TokuDB
• Компрессия (примерно в 5 раз)
• Хорошо «держит» большие объемы за счет структуры
индекса (сотни GB)
• Производительность перестройки индекса не падает с ростом
размера таблиц
• Сокращает время доступа к данным за счет
«кластеризующих» индексов
• Выполнение аналитических запросов в 5-10 раз быстрее, чем
InnoDB
• 5 раз компрессия и до двух раз из-за «кластеризующего» индекса

21. Рабочий вариант
• TokuDB + Shard-Query
• 100-200GB/server
• Ограничения:
•
•
•
•
shard column одна для всех таблиц
Нет центрального управления, все вручную
TokuDB плохо работает при больших range scan
И еще одно...

22. Help!
Help, I need somebody
Help, not just anybody
Help, you know I need someone, help
Help
Help
Help,
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
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

23. Строки vs. колонки
Row store
Column store
• Колонки
Таблица хранится по строкам
Каждая колонка хранится отдельно
При любом обращении строка читается
целиком
При обращении к полю, читается только
одна колонка или ее фрагмент
Данные по строкам плохо сжимаются
Колонки отлично сжимаются
Дешевый update/delete
Дорогой update/delete
Легко реализуется
Достаточно сложно реализуется

24. Пример
Таблица 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
Если учесть компрессию, то на порядок меньше

25. Колоночные RDBMS
• Open Source:
• C-Store (pre-Vertica)
• MonetDB (pre-VectorWise)
• LucidDB
• Коммерческие
•
•
•
•
•
•
•
Sybase IQ
InfoBright *
InfiniDB *
ParAccel (and Amazon Redshift)
GreenPlum (“эмуляция” на PostgreSQL)
Vertica *
VectorWise
* Есть бесплатные версии ограниченной функциональности

26. • 1140M строк в таблице
• 20 колонок (int, float)
• 5 серверов (native/ Shard-Query)
250
215
200
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;
150
100
79
61
50
3,22
2,42
0
MonetDB
TokuDB InfoBright ParAccel
EE
Vertica

27. Vertica – это:
•
•
•
•
Колонки!
Нет индексов!!
Нет таблиц!!!
Эффективная компрессия данных
• У нас в среднем в 13 раз, но может достигать и до 10....00
раз на колонку
• Полный контроль над физической организацией
• Очень быстрая загрузка
• Shared nothing MPP

28. Vertica: проекции
• Таблиц физически нет, это логическая
абстракция
• Проекции (projection)
• Подмножество колонок с сортировкой
• Для каждой таблицы есть супер-проекция = все
колонки
• Для одной таблицы может быть любое число
проекций разной структуры

29. Vertica: проекции
• Тип кодирования колонок:
•
•
•
•
RLE
DELTAVAL
BLOCK_DICT
И еще 12 разных способов
• Сортировка! (особенно важна для RLE)
• Группы колонок (фрагменты строк)
• Сегментация по узлам кластера

30. Vertica: физическое хранение
• Большие блоки (мин 1Mb), после записи не
меняются
• Автоматическое объединение (со сборкой мусора и
перекодированием)
• Оптимизировано на последовательное чтениезапись с диска
• Оптимизировано под кэш уровня OS или
контроллера

31. Vertica: выполнение запросов
• Только «нужные» колонки
• Предикаты могут выполняться на закодированных
колонках
• Сильно зависит от структуры проекций (не таблиц)
• Ключевые инструменты – RLE с сортировкой и
сегментация
• Предикаты по отсортированной колонке ~ индексы
• Джойны – merge, hash
• Группировка, pipelined group by

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

33. Как работает сортировка и RLE
Gender
Age
M
1-20
21-25
26-35
36+
F
Impressions
1-20
21-25
26-35
36+
1 I/O
1 I/O
1 I/O
select sum(impressions) from t
where gender=‘M’ and age=‘21-25’

34. Как работает сортировка и RLE
Gender
Age
M
1-20
21-25
26-35
36+
F
Impressions
1-20
21-25
26-35
36+
2 I/O
2 I/O
select sum(impressions) from t
where age=‘21-25’

35. Сортировка и pipelined group-by
SELECT X, COUNT(*) FROM T GROUP BY X
X (sorted)
A
A
B
B
C
C
D
D
…
A: 2
B: 2
• Выполняется в один проход
• Почти не расходует память (stream)
• Для кластера, если сегментировать по X, то
тоже в один проход
C: 2
D: 2
Сегментация
по узлам

36. Сортировка и merge join
X (sorted)
A
A
B
B
C
C
D
D
Y (sorted)
A
B
C
D
• Работает, если сортировка одинаковая с
обеих сторон
• Для кластера:
• одинаковая сегментация, или
• одна из таблиц несегментирована
(обычно)
Сегментация
по узлам

37. Vertica: загрузка данных
• Две зоны хранения:
• WOS (in-memory)
• ROS (on-disk)
• Перенос из WOS в ROS автоматический (можно force)
• Загрузка большими порциями очень быстрая:
• В ROS: порядка 2-5M «колонок» в секунду на сервер
• В WOS: еще быстрее, но может быть переполнение

38. Vertica: кластер
• 3..N одинаковых узлов – архитектура shared nothing
• Конфигурируется на уровне проекции
• Несегментированные – каждая нода содержит полные
данные
• Сегментированные – каждая нода 1/N данных
• K-safety level – уровень дублирования
1
2
3
4
5
A
A
E
A
B
A
A
C
B
A
D
C
A
E
D
Несегментированная
Сегментированная,
K=1 со сдвигом 1

39. Vertica: aдминистрирование
• Переконфигурирования кластера – все на лету
•
•
•
•
•
Выключение/включение узла
Замена узла
Добавление узла
Изменение проекций
И т. д.
• Как этого добиваются?
• Рестарт – только при апгрейде версии софта

40. 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 + сеть

41. Vertica: cколько стоит?
• It depends
• Лицензируется объем сырых данных в «боевой»
системе
• Единовременно + support fee
• Верхняя граница -- $100K за 1TB (list price)
• Нижняя граница $2M за 1PB или $2K за 1TB

42. Vertica Community Edition
• 1 TB данных, 3 сервера в кластере
• Достаточно для любых тестов, POC и т.д.
• На объемах до 1TB обгонит всех БЕСПЛАТНО

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

44. ParAccel
• Тоже быстрая колоночная MPP RDBMS
• Может быть быстрее Vertica на ad-hoc запросах
• Используется как бэкенд Amazon Redshift

45. ParAccel – основные отличия
• Ограниченные возможности настройки физической
структуры, только одна сортировка на таблицу
• Неэффективный Vacuum («сборка мусора»)
• Нет партиционирования
• Только последовательная загрузка
• Два типа узлов: Leader Node (1) и Сompute Nodes (N)
• Все кластерные операции требуют остановки БД
• Более высокие требования к железу и сети
• Лицензия per server/node

46. Hadoop
• Исторически – batch processing
• Долгий старт задачи на больших кластерах
• HDFS медленная
• Материализация на диск промежуточных этапов
• Hive неэффективен
• Слишком generic

47. Hadoop vs Vertica
• SIGMOD 2009 paper: A Comparison of Approaches to
Large-Scale Data Analysis
http://database.cs.brown.edu/papers/benchmarkssigmod09.pdf
• В «идеальных условиях» в среднем в 10 раз медленнее,
чем Vertica
• Агрегация медленнее в 15 раз
• Джойны – в 20-30
• Hive примерно в 100 раз медленнее (наши тесты
2012)

48. HadApt
• Hadoop инфраструктура поверх PosgtreSQL
• Очевидные преимущества PostgreSQL над HDFS
• Те же недостатки Hadoop, плюс недостатки row
store

49. Hadoop Stinger
• http://hortonworks.com/labs/stinger/
• Часть Hadoop 2.0
• Декларируемая Цель: ускорить Hive в 100 раз

50. Hadoop Stinger: как?
• ORC – новый колоночный формат HDFS:
• RLE, dictionary encoding etc.
• SQL типы данных и прочая SQL-семантика на уровне
платформы
• HСatalog – новое эффективное хранилище метаданных
• Tez – новый MR-«движок», заточенный под Hive
• Нет промежуточной материализации, наконец-то!
• 100ms время старта
• Новый cost-based query optimizer

51. Hadoop Stinger: когда?
• Частично уже (Oct 2013 -- HDP 2.0, Hive 0.12),
утверждается увеличение производительности
SQL/Hive в 35-40 раз
• Полностью – coming soon
• Будем пробовать 

52. Резюме

53. Спасибо
Alexander.Zaitsev @ LifeStreet.com