Aлександр Зайцев, LifeStreet
description
Transcript of Aлександр Зайцев, LifeStreet
Распределенные 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