Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
Распределенные cистемы хранения
данных для аналитики:
Vertica и другие системы

Александр Зайцев
О чем мы будем говорить
• Что такое аналитика больших данных
• Функциональные требования
• Технические сложности и проблем...
Откуда я об этом знаю?
• LifeStreet:

• Performance advertising с 2006г
• Top FaceBook In-Apps ad network c 2010г
• RTB c ...
Что такое большие данные
• БАК (LHC) генерирует 40TB/sec
• В 2011 году всего было сгенерировано 1.8
зеттабайт
• Закон Мура...
Непрерывный поток данных
• надо писать быстро
• нельзя останавливаться
• желательно выживать при частичном отказе
железа (...
Многомерный анализ данных
• Данные моделируются как многомерные кубы:
• сотни измерений (дискретных и непрерывных)
• десят...
Ip | access_time | user_agent |page_url | response_code | response_time
Измерения:
• IP (+ geo lookup)
• Время (иерархия: ...
Кубы, сечения, проекции
Типичный аналитический запрос: агрегация +
range filter + group by на маленькое подмножество измер...
Аналитические запросы
• Сканирование и агрегирование больших
объемов данных
=> очень много IO и CPU на типичный запрос

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

Лучше все сразу
Как можно «уменьшить» данные
• Логическая модель (нормализация и т.д.)
• Физическое хранение данных
• Компрессия
• Кодиров...
Как можно увеличить IO/CPU
• RAID
• RAID5 vs RAID10

• Использование всех ядер для одного запроса
• Распределенная система
Преимущества распределенных
систем
• «Размазывание» данных по серверам
• Больше объем дисков
• Быстрее доступ к большему о...
Сложности распределенных
систем
• Надежность
• Балансировка/перестройка кластера
• Не все алгоритмы хорошо распределяются
...
Итак
• Для аналитических задач нам нужна система:
• Распределенная для производительности и
надежности
• Эффективно хранящ...
Отступление: из чего
складывается стоимость
• Стоимость железа (лучше чужого)
• Стоимость лицензии и поддержки, если есть
...
Какие есть варианты?
• Не самые удачные:
• Обычные коммерческие базы данных – не интересно
• In-memory DBs (e.g. MemSQL) –...
Какие есть варианты?
• Стоящие рассмотрения:
• MySQL + специализированный engine + шардинг
• Аналитические MPP базы данных...
Что можно «выжать» из MySQL
• MySQL NDB Cluster – работает только на небольших
данных в памяти и плохо агрегирует
• TokuDB...
Пару слов про TokuDB
• Компрессия (примерно в 5 раз)
• Хорошо «держит» большие объемы за счет структуры
индекса (сотни GB)...
Рабочий вариант
• TokuDB + Shard-Query
• 100-200GB/server
• Ограничения:
•
•
•
•

shard column одна для всех таблиц
Нет це...
Help!
Help, I need somebody
Help, not just anybody
Help, you know I need someone, help

Help
Help
Help,
Help

When I was y...
Строки vs. колонки
Row store

Column store
• Колонки

Таблица хранится по строкам

Каждая колонка хранится отдельно

При л...
Пример
Таблица T 100 bigint колонок и 1 000 000 000 записей
select sum(x) from T;

Row store: 1 000 000 000 * 100 * 8 = 80...
Колоночные RDBMS
• Open Source:
• C-Store (pre-Vertica)
• MonetDB (pre-VectorWise)
• LucidDB

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

250
215
200

select
country_code,
co...
Vertica – это:
•
•
•
•

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

• У нас в среднем в 13 раз, н...
Vertica: проекции
• Таблиц физически нет, это логическая
абстракция
• Проекции (projection)
• Подмножество колонок с сорти...
Vertica: проекции
• Тип кодирования колонок:
•
•
•
•

RLE
DELTAVAL
BLOCK_DICT
И еще 12 разных способов

• Сортировка! (осо...
Vertica: физическое хранение
• Большие блоки (мин 1Mb), после записи не
меняются
• Автоматическое объединение (со сборкой ...
Vertica: выполнение запросов
• Только «нужные» колонки
• Предикаты могут выполняться на закодированных
колонках
• Сильно з...
Любой запрос, это ...
Full Scan
Как работает сортировка и 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 ...
Как работает сортировка и 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

sel...
Сортировка и 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

• Выполняетс...
Сортировка и merge join
X (sorted)
A
A
B
B
C
C
D
D

Y (sorted)
A
B
C
D

• Работает, если сортировка одинаковая с
обеих сто...
Vertica: загрузка данных
• Две зоны хранения:
• WOS (in-memory)
• ROS (on-disk)
• Перенос из WOS в ROS автоматический (мож...
Vertica: кластер
• 3..N одинаковых узлов – архитектура shared nothing
• Конфигурируется на уровне проекции
• Несегментиров...
Vertica: aдминистрирование
• Переконфигурирования кластера – все на лету
•
•
•
•
•

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

• Если физический дизайн правильно настрое...
Vertica: cколько стоит?
• It depends
• Лицензируется объем сырых данных в «боевой»
системе
• Единовременно + support fee
•...
Vertica Community Edition
• 1 TB данных, 3 сервера в кластере
• Достаточно для любых тестов, POC и т.д.
• На объемах до 1T...
Сравнимые
альтернативы?
ParAccel
• Тоже быстрая колоночная MPP RDBMS
• Может быть быстрее Vertica на ad-hoc запросах
• Используется как бэкенд Ama...
ParAccel – основные отличия
• Ограниченные возможности настройки физической
структуры, только одна сортировка на таблицу
•...
Hadoop
• Исторически – batch processing
• Долгий старт задачи на больших кластерах
• HDFS медленная
• Материализация на ди...
Hadoop vs Vertica
• SIGMOD 2009 paper: A Comparison of Approaches to
Large-Scale Data Analysis
http://database.cs.brown.ed...
HadApt
• Hadoop инфраструктура поверх PosgtreSQL
• Очевидные преимущества PostgreSQL над HDFS
• Те же недостатки Hadoop, п...
Hadoop Stinger
• http://hortonworks.com/labs/stinger/
• Часть Hadoop 2.0
• Декларируемая Цель: ускорить Hive в 100 раз
Hadoop Stinger: как?
• ORC – новый колоночный формат HDFS:
• RLE, dictionary encoding etc.

• SQL типы данных и прочая SQL...
Hadoop Stinger: когда?
• Частично уже (Oct 2013 -- HDP 2.0, Hive 0.12),
утверждается увеличение производительности
SQL/Hiv...
Резюме
Спасибо

Alexander.Zaitsev @ LifeStreet.com
Upcoming SlideShare
Loading in …5
×

Aлександр Зайцев, LifeStreet

2,471 views

Published on

HighLoad++ 2013

  • Be the first to comment

Aлександр Зайцев, LifeStreet

  1. 1. Распределенные cистемы хранения данных для аналитики: Vertica и другие системы Александр Зайцев
  2. 2. О чем мы будем говорить • Что такое аналитика больших данных • Функциональные требования • Технические сложности и проблемы • Как они решаются или не решаются в разных распределенных системах
  3. 3. Откуда я об этом знаю? • LifeStreet: • Performance advertising с 2006г • Top FaceBook In-Apps ad network c 2010г • RTB c 2012г • Аналитическая инфраструктура – ключевой компонент • Каждый год нагрузка вырастает в 2-3 раза • Сейчас (октябрь 2013) – 4 миллиарда событий в день • Попробовали разные решения и продолжаем пробовать
  4. 4. Что такое большие данные • БАК (LHC) генерирует 40TB/sec • В 2011 году всего было сгенерировано 1.8 зеттабайт • Закон Мура для данных • Веб-логи • Игры (Zynga – 5TB/day два года назад)
  5. 5. Непрерывный поток данных • надо писать быстро • нельзя останавливаться • желательно выживать при частичном отказе железа (чтобы не останавливаться) • желательно дублирование (как минимум) в реальном времени
  6. 6. Многомерный анализ данных • Данные моделируются как многомерные кубы: • сотни измерений (дискретных и непрерывных) • десятки метрик • Способы работы: • Сечения (фильтры) • Проекции (агрегирование) • Объединения кубов или проекций
  7. 7. Ip | access_time | user_agent |page_url | response_code | response_time Измерения: • IP (+ geo lookup) • Время (иерархия: Год, Дата, Час, Минута и т.д.) • Пользовательский агент (2 или более иерархий, по браузеру по OS) • Ресурс (иерархия по структуре URL) • Код ответа Метрики: • Время ответа • Количество запросов • Количество успешных запросов (HTTP200)
  8. 8. Кубы, сечения, проекции Типичный аналитический запрос: агрегация + range filter + group by на маленькое подмножество измерений Query result N-dimensional cube сечение M-dimensional projection Range filter
  9. 9. Аналитические запросы • Сканирование и агрегирование больших объемов данных => очень много IO и CPU на типичный запрос • В разных направлениях (измерениях) => кэш, индексы – все работает плохо
  10. 10. Как получить хорошую производительость? Две стратегии: 1. «Уменьшить» данные 2. Увеличить IO/CPU системы Лучше все сразу
  11. 11. Как можно «уменьшить» данные • Логическая модель (нормализация и т.д.) • Физическое хранение данных • Компрессия • Кодирование • Физическая модель – локализация данных: • Индексы, партиционирование, row/column store, сегментирование/шардинг
  12. 12. Как можно увеличить IO/CPU • RAID • RAID5 vs RAID10 • Использование всех ядер для одного запроса • Распределенная система
  13. 13. Преимущества распределенных систем • «Размазывание» данных по серверам • Больше объем дисков • Быстрее доступ к большему объему • Сложение вычислительных ресурсов • Масштабируемость • Надежность за счет дублирования
  14. 14. Сложности распределенных систем • Надежность • Балансировка/перестройка кластера • Не все алгоритмы хорошо распределяются (select distinct) • Cеть
  15. 15. Итак • Для аналитических задач нам нужна система: • Распределенная для производительности и надежности • Эффективно хранящая данные • Хорошо локализующая данные • Быстро загружающая новые данные • Управляемая • Разумно стоящая
  16. 16. Отступление: из чего складывается стоимость • Стоимость железа (лучше чужого) • Стоимость лицензии и поддержки, если есть • Стоимость внутреннего администрирования и разработки • Стоимость простоя из-за отказов железа или софта
  17. 17. Какие есть варианты? • Не самые удачные: • Обычные коммерческие базы данных – не интересно • In-memory DBs (e.g. MemSQL) – очень дорого и не очень надежно • NoSQL Dynamo-like – не предназначены для агрегации и больших range scans
  18. 18. Какие есть варианты? • Стоящие рассмотрения: • MySQL + специализированный engine + шардинг • Аналитические MPP базы данных • Hadoop Stinger
  19. 19. Что можно «выжать» из MySQL • MySQL NDB Cluster – работает только на небольших данных в памяти и плохо агрегирует • TokuDB – storage engine для аналитики • Шардинг (dbShards, Shard-Query, ScaleDB, ScaleBase) – распределенность, но • Тяжело управлять • Часто неэффективные запросы и джойны • Кроме Shard-Query – не бесплатны
  20. 20. Пару слов про TokuDB • Компрессия (примерно в 5 раз) • Хорошо «держит» большие объемы за счет структуры индекса (сотни GB) • Производительность перестройки индекса не падает с ростом размера таблиц • Сокращает время доступа к данным за счет «кластеризующих» индексов • Выполнение аналитических запросов в 5-10 раз быстрее, чем InnoDB • 5 раз компрессия и до двух раз из-за «кластеризующего» индекса
  21. 21. Рабочий вариант • TokuDB + Shard-Query • 100-200GB/server • Ограничения: • • • • shard column одна для всех таблиц Нет центрального управления, все вручную TokuDB плохо работает при больших range scan И еще одно...
  22. 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. 23. Строки vs. колонки Row store Column store • Колонки Таблица хранится по строкам Каждая колонка хранится отдельно При любом обращении строка читается целиком При обращении к полю, читается только одна колонка или ее фрагмент Данные по строкам плохо сжимаются Колонки отлично сжимаются Дешевый update/delete Дорогой update/delete Легко реализуется Достаточно сложно реализуется
  24. 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. 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. 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. 27. Vertica – это: • • • • Колонки! Нет индексов!! Нет таблиц!!! Эффективная компрессия данных • У нас в среднем в 13 раз, но может достигать и до 10....00 раз на колонку • Полный контроль над физической организацией • Очень быстрая загрузка • Shared nothing MPP
  28. 28. Vertica: проекции • Таблиц физически нет, это логическая абстракция • Проекции (projection) • Подмножество колонок с сортировкой • Для каждой таблицы есть супер-проекция = все колонки • Для одной таблицы может быть любое число проекций разной структуры
  29. 29. Vertica: проекции • Тип кодирования колонок: • • • • RLE DELTAVAL BLOCK_DICT И еще 12 разных способов • Сортировка! (особенно важна для RLE) • Группы колонок (фрагменты строк) • Сегментация по узлам кластера
  30. 30. Vertica: физическое хранение • Большие блоки (мин 1Mb), после записи не меняются • Автоматическое объединение (со сборкой мусора и перекодированием) • Оптимизировано на последовательное чтениезапись с диска • Оптимизировано под кэш уровня OS или контроллера
  31. 31. Vertica: выполнение запросов • Только «нужные» колонки • Предикаты могут выполняться на закодированных колонках • Сильно зависит от структуры проекций (не таблиц) • Ключевые инструменты – RLE с сортировкой и сегментация • Предикаты по отсортированной колонке ~ индексы • Джойны – merge, hash • Группировка, pipelined group by
  32. 32. Любой запрос, это ... Full Scan
  33. 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. 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. 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. 36. Сортировка и merge join X (sorted) A A B B C C D D Y (sorted) A B C D • Работает, если сортировка одинаковая с обеих сторон • Для кластера: • одинаковая сегментация, или • одна из таблиц несегментирована (обычно) Сегментация по узлам
  37. 37. Vertica: загрузка данных • Две зоны хранения: • WOS (in-memory) • ROS (on-disk) • Перенос из WOS в ROS автоматический (можно force) • Загрузка большими порциями очень быстрая: • В ROS: порядка 2-5M «колонок» в секунду на сервер • В WOS: еще быстрее, но может быть переполнение
  38. 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. 39. Vertica: aдминистрирование • Переконфигурирования кластера – все на лету • • • • • Выключение/включение узла Замена узла Добавление узла Изменение проекций И т. д. • Как этого добиваются? • Рестарт – только при апгрейде версии софта
  40. 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. 41. Vertica: cколько стоит? • It depends • Лицензируется объем сырых данных в «боевой» системе • Единовременно + support fee • Верхняя граница -- $100K за 1TB (list price) • Нижняя граница $2M за 1PB или $2K за 1TB
  42. 42. Vertica Community Edition • 1 TB данных, 3 сервера в кластере • Достаточно для любых тестов, POC и т.д. • На объемах до 1TB обгонит всех БЕСПЛАТНО
  43. 43. Сравнимые альтернативы?
  44. 44. ParAccel • Тоже быстрая колоночная MPP RDBMS • Может быть быстрее Vertica на ad-hoc запросах • Используется как бэкенд Amazon Redshift
  45. 45. ParAccel – основные отличия • Ограниченные возможности настройки физической структуры, только одна сортировка на таблицу • Неэффективный Vacuum («сборка мусора») • Нет партиционирования • Только последовательная загрузка • Два типа узлов: Leader Node (1) и Сompute Nodes (N) • Все кластерные операции требуют остановки БД • Более высокие требования к железу и сети • Лицензия per server/node
  46. 46. Hadoop • Исторически – batch processing • Долгий старт задачи на больших кластерах • HDFS медленная • Материализация на диск промежуточных этапов • Hive неэффективен • Слишком generic
  47. 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. 48. HadApt • Hadoop инфраструктура поверх PosgtreSQL • Очевидные преимущества PostgreSQL над HDFS • Те же недостатки Hadoop, плюс недостатки row store
  49. 49. Hadoop Stinger • http://hortonworks.com/labs/stinger/ • Часть Hadoop 2.0 • Декларируемая Цель: ускорить Hive в 100 раз
  50. 50. Hadoop Stinger: как? • ORC – новый колоночный формат HDFS: • RLE, dictionary encoding etc. • SQL типы данных и прочая SQL-семантика на уровне платформы • HСatalog – новое эффективное хранилище метаданных • Tez – новый MR-«движок», заточенный под Hive • Нет промежуточной материализации, наконец-то! • 100ms время старта • Новый cost-based query optimizer
  51. 51. Hadoop Stinger: когда? • Частично уже (Oct 2013 -- HDP 2.0, Hive 0.12), утверждается увеличение производительности SQL/Hive в 35-40 раз • Полностью – coming soon • Будем пробовать 
  52. 52. Резюме
  53. 53. Спасибо Alexander.Zaitsev @ LifeStreet.com

×