Andrei Kirilenkov. Vertica

© Copyright 2013 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice.
СУБД Vertica
Платформа для анализа «больших данных» в реальном
времени
Андрей Кириленков / 25 Июля, 2014

© Copyright 2013 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice.2
Содержание
1. Big data и предпосылки к созданию HP Vertica
2. HP Vertica: история, основы, практика
3. HP Vertica: Архитектура
4. Высокая доступность
5. Управление рабочей нагрузкой
6. Возможности
• Анализ
• Внешние и гибкие таблицы
• Интеграция с Hadoop
7. Развитие
8. Итоги

1. Предпосылки к созданию HP Vertica
• Анализ
• Hadoop
7. Развитие
8. Итоги

• Ограничения традиционных платформ
• Big Data
«Узкие места»
• Разделяемый ресурс
• «Массивное» чтение с дисков
• Сеть внутри кластера
Два вызова в хранении и анализе данных

Традиционные платформы
• Не могу загружать данные и одновременно их
анализировать
• Слишком долго выполняются запросы и отчеты
• Строю агрегаты и не могу спуститься к детальным
данным
• Перемещаю данные в инструменты для сложного
анализа и data mining
• Сложно сопровождать
• Не успеваю за ростом нагрузки и объема данных
• Дорого и сложно обеспечить высокую доступность
• Не хватает дополнительных сред (тестирование,
разработка...)
Типовые недоумения клиентов

Объем (Volume)
• 10% организаций обрабатывают 1+ Пб данных
• Социальные сети – миллионы транзакций в минуту
Скорость (Velocity)
• 30% организаций имеют 100+ Гб/день
• Данные обновляются и нужны раз в день, час
Разнообразие (Variety)
• Тексты, Аудио и видео файлы
• Блоги, сообщения в сетях – для изучения клиентов
• Внутренние источники данных
Сложность
• Осмысленные связи
• Преобразование
• Очистка
Разно-
образие
СложностьСкорость
Объем
Цели:
• Эффективность
• Удовлетворение клиентов
• Снижение риска
• Расширение бизнеса
Вызов:
извлечь из Big Data важное
для бизнеса
Big Data: информационный вызов

“Big Data и традиционные
данные – две части единой
стратегии данных и их анализа”
Том Давенпорт (один из трех лучших
консультантов мира в области аналитики)

• Анализ
• Hadoop
7. Развитие
8. Итоги

Стратегия Vertica - анализ больших объемов данных.
Vertica спроектирована именно для быстрого анализа
...
Ovum считает, что высокопроизводительные
колоночные СУБД сегодня нужны компаниям,
ищущим замены традиционным платформам. Vertica
вполне отвечает их ожиданиям.

HP Vertica: история и замысел
Vertica Systems основана в 2005 г., куплена НР в 2011 г.
Vertica Analytical DB – коммерческая версия
исследовательского прототипа C-Store (M.
Stonebraker)
Платформа для аналитических нагрузок (десятки
запросов в сек, большой объем данных в запросе)
Shared nothing – архитектура, МРР
Простая линейная масштабируемость на «обычных»
серверах
ACID (Atomicity, Consistency, Isolation, Durability)
SQL , реляционная СУБД, любая реляционная модель

Гартнер: магический квадрат

2500+ клиентов, начиная с 2006
20 ?
500?

2500+ клиентов, начиная с 2006
20+ Петабайт данных
500+ узлов в кластере

Старое хранилище HP Vertica Выгода для бизнеса
• Загрузка шла 14 hours
• Цена $120К за TB – только
лицензии
• Загрузка за 1 час
• Цена ниже значительно
• Экономия бюджета
• Анализ в реальном времени
(свежие данные)
Невозможен скоринг кредитных карт
в реальном времени
(подтверждение или отказ карты)
Кластер из 4 узлов в 2 раза быстрее
кластера из 12 узлов и дешевле на
70%
• Экономия $20М на лиц.
• Экономия $4М на лиц. и
серверах в смежном проекте
• Достигнуты SLAs
Запросы выполняются по 20 часов • Ускорение запросов в 40-80x раз
• Стоимость нового решения - 5%
от стоимости старого
• Сокрадение операционных
расходов на 90%
• ROI - 3 месяцв
• Находят в 10 раз больше
потенциальных клиентов
HP Vertica в больших компаниях

• Анализ
• Hadoop
7. Развитие
8. Итоги

Базовые принципы
Быстрый отклик на запросы Простая и
линейная масштабируемость
Экономия дискового
пространства
Загрузка и запросы одновременно,
Работа 24x7
Columnar storage
and execution
Clustering Compression
Continuous
performance
Автоматическая настройка
производительности
Дизайн БД
Временные ряды, география, клики,
SDK для разработки
Сложный анализ

Колоночное хранение
• Читает только колонки, нужные для запроса
• Данные в колонках можно обновлять
• Идеально для интенсивной нагрузки ЗАГРУЗКАЧТЕНИЕ, значительное снижение
I/O
AAPL NYASE NYAASE NYSE NYASE NGGYSE NYGGGSE NYSE NYSE NYSE 143.74 NYSE NYSE NYSE 5/05/09
5/05/09
5/06/09
5/05/09
5/06/09
143.74
143.75
37.03
37.13
AAPL NYASE NYAASE NYSE NYASE NGGYSE NYGGGSE NYSE NYSE NYSE 143.74 NYSE NYSE NYSE 5/06/09
BBY NYASE NYAASE NYSE NYASE NGGYSE NYGGGSE NYSE NYSE NYSE 37.03 NYSE NYSE NYSE 5/05/09
BBY NYASE NYAASE NYSE NYASE NGGYSE NYGGGSE NYSE NYSE NYSE 37.13 NYSE NYSE NYSE 5/06/09
SELECT
avg(price)
FROM
tickstore
WHERE
symbol = ‘AAPL”
and
date = ‘5/06/09’;
Колоночное хранение – Читает 3 колонки
Строчное хранения – Читает все колонки
NQDS
NYSE
NYSE
NYSE
NQDS
NYSE
NYSE
NYSE
NQDS
NYSE
NYSE
NYSE
NQDS
NYSE
NYSE
NYSE
NQDS
NQDS
NYSE
NYSE
NYSE
NQDS
NYSE
NYSE
NYSE
NQDS
NYSE
NYSE
NYSE
NQDS
NYSE
NYSE
NYSE
NQDS
NQDS
NYSE
NYSE
NYSE
NQDS
NYSE
NYSE
NYSE
NQDS
NYSE
NYSE
NYSE
NQDS
NYSE
NYSE
NYSE
NQDS
NQDS
NYSE
NYSE
NYSE
NQDS
NYSE
NYSE
NYSE
NQDS
NYSE
NYSE
NYSE
NQDS
NYSE
NYSE
NYSE
NQDS
NQDS
NYSE
NYSE
NYSE
NQDS
NYSE
NYSE
NYSE
NQDS
NYSE
NYSE
NYSE
NQDS
NYSE
NYSE
NYSE
NQDS
NQDS
NYSE
NYSE
NYSE
NQDS
NYSE
NYSE
NYSE
NQDS
NYSE
NYSE
NYSE
NQDS
NYSE
NYSE
NYSE
NQDS
NQDS
NYSE
NYSE
NYSE
NQDS
NYSE
NYSE
NYSE
NQDS
NYSE
NYSE
NYSE
NQDS
NYSE
NYSE
NYSE
NQDS
NQDS
NYSE
NYSE
NYSE
NQDS
NYSE
NYSE
NYSE
NQDS
NYSE
NYSE
NYSE
NQDS
NYSE
NYSE
NYSE
NQDS
NQDS
NYSE
NYSE
NYSE
NQDS
NYSE
NYSE
NYSE
NQDS
NYSE
NYSE
NYSE
NQDS
NYSE
NYSE
NYSE
NQDS
AAPL
AAPL
BBY
BBY

Кодирование и сжатие
• Использует свойства данных
(сортировка, мощность - cardinality)
• Работает на большом числе строк
Не медленное обращение к дискам, а быстрая работу CPU (мощное сжатие)
• Раскодирование – как можно позже
• 15 алгоритомов сжатия
• Тип сжатия подбирается автоматически

Проекции: оптимальное хранение
• Основная таблица (супер-проекция) не
отсортирована
• Физический дизайн прозрачен для приложений
• Данные хранятся в отсортированном, сжатом виде
• Индексы НЕ нужны (колонка сама себе индекс)
• Оптимизатор выбирает лучшую проекцию для
выполнения запроса
• Всегда актуально, не нужно перестраивать /
обновлять
• Предварительное объединение таблиц (pre-join
projections, N:1 joins)

Партиционирование
• Локальные партиции - на одном узле
− CREATE TABLE ... PARTITION BY <expr> - как правило по времени
− Вложенности нет
− Быстрое удаление данных через партиции, быстрее запросы
− На уровне таблиц и распространяется на все проекции
• Сегментация: или распределение по узлам кластера
− Для каждой проекции
− Репликация на каждый узел или сегментация (HASH(col1..coln))
− Создается автоматически с помощью Data base designer

Партиционирование

Массивно-параллельная обработка данных
• Распределенное хранение и рабочая нагрузка
• Shared-nothing архитектура
• Линейная масштабируемость на х86_64 серверах. (Больше данных? Выше
производительность? Больше пользователей? Добавь новые узлы)
Клиентская сеть (1 Гбитс) ODBC, JDBC, ADO.NET
Внутри-кластерная сеть (10 Гбитс, full duplex)
8-12 TB 8-12 TB 8-12 TB
Node 1
 2 x 10-12 Core
 128+GB RAM
Node 2
 2 x 10-12 Core
 128+GB RAM
Node 3
 2 x 10-12 Core
 128+GB RAM
Узлы кластера
– Все узлы
равнозначны
– Загрузка/Запросы –
на любой узел
– Непрерывная/в
реальном времени
загрузка и анализ

Распределённое выполнение запросов
• Балансировщик (Vertica или Linux) нагрузки отправляет запрос на один из узлов кластера
(инициатор)
• Инициатор разбирает запрос и составляет план выполнения (cost-based)
• Инициатор распределяет запрос по исполнителям
• Все узлы выполняет запрос и посылают свою часть результата инициатору
• Инициатор собирает результат и отправляет ответ пользователю

Автоматический дизайн
A B A
(A B C | A) (B A C | B A)
B C C
> Физическая модель, сжатие:
 Быстрое выполнение типовых запросов
 Поддержка всех загрузок
 Гарантия, что все SQL запросы будут отвечены
Database Designer:Архитектор:
> Логическая модель
 Create table
> “Типовой набор”
 Типичные запросы
 Выборки данных
> Уровень устойчивости к
сбоям
 k-safety
• Минимальная нагрузка на архитектора в части управления физической моделью данных
• Инкрементальная перестройка БД под новые данные и запросы
• Запуск в любое время, выполнение без остановки БД

Гибридное и гибкое хранение
• Загрузка и запросы одновременно (гибридное хранение)
• Производительность загрузки масштабируется линейно (реально 35 Tб в час)
• Vertica’s FlexStore™ : размещение горячих данных на быстрых носителях (SSD...)
• Update = Delete (порождает историю) + Insert
• Delete – только метка: снимок БД в момент времени AT TIME 'timestamp' SELECT...
Асинхронный перенос
данных
TUPLE MOVER
Read Optimized Store (ROS)
• На дисках
• Сортировка / Сжатие
• Сегментация
• Прямая загрузка больших объемов
(A B C | A)
A B C
Непрерывная
загрузка
Write Optimized
Store (WOS)
 Находится в памяти
 Нет сортировки / Нет сжатия
 Сегментация
 Свежие данные / Небольшие
быстрые вставки
A B C

• Анализ
• Hadoop
7. Развитие
8. Итоги

Встроенная высокая доступность (k-safety)
• Колонки дублируются на соседних узлах согласна k-safety (1 или 2)
• Не нужно ручное восстановление из журналов
• Система принимает загрузки и запросы, когда узел отключен
• Данные на отключенном узле запрашиваются на других узлах
• Возвращение узла в работу – без остановки кластера
• Восстановление после сбоя: Last good epoch или из резервной копии
A3 B3 C3 A2 B2 C2
B1 A1 C1B2 A2 C2 B1 A1 C1
A3 B3 C3 A1 B1 C1
B3 A3 C3

Защита от катастроф
Вариант 1: Загрузка данных в обе системы.
(Для больших объемов)
За: Обе системы активны
Против: ETL обеспечивает
согласованность данных
Вариант 2: Репликация снимков
Vertica Backup
За: Минимальный риск не-
согласованности данных
Против: Во время синхронизации 2-й
кластер не активен

Легко расширяемый кластер
Простое добавление новых серверов
• Добавь узел и повысь емкость или быстродействие
• Vertica автоматически перераспределяет данные
Система работает без остановки
• Система принимает запросы во время ре-
балансировки кластера
Быстрое перераспределение данных
• Пример из жизни: расширение от 11 TB и 16 узлов до
32 nodes прошло за 65 минут без остановки системы!

Мониторинг: Vertica Management Console
• Управление кластерами через веб-приложение
• Полный контроль за работой БД и кластера
• Корреляция работы системы и БД
Кластер 1 Кластер 2 Кластер 3
Vertica
Management
Console
Browser
Access

Tactical
General
Analytic User 1
Управление рабочей нагрузкой
• Нет главного узла, т.е. нет узкого места в кластере!
− Инициация запросов - равномерно по узлам
− Число одновременных запросов растет по мере добавления новых узлов
• Настраиваемый менеджер ресурсов
− Ресурсные пулы для разных рабочих нагрузок (I/O, CPU, memory, bandwidth, concurrency,
duration)
− Границы ресуров для пула, пользователя, сессии
• Управление в реальном времени
− Сменить приоритет запроса
− Снять запрос
tactical tactical
analytic
Analytic User 2

1. Анализ
• Hadoop
7. Развитие
8. Итоги

SQL, адаптированный для Big Data
Возможности
•ANSI SQL-99
•Развитые функции для работы со временем
•Временные ряды:
– Заполнением пробелов
– Разбивка на окна
– Разбивка на сессии потока «кликов»
•Статистика
•Поддержка R (анализ и data mining)
•Пакет гео-пространственных функций
•Анализ текстов
analytic_function ( arguments ) OVER( analytic_clause )
Примеры
•Ранжировать клиентов по лояльности и регионами
•Вычислить скользящее среднее объема продаж за
период времени
•Найти высший балл среди всех студентов одного
курса
•Сравнить текущий бонус каждого из продавцов с
его предыдущим бонусом
•Анализ «кликов» с помощью шаблонов

Временной ряд: интерполяция
•Система интеллектуального учета нерегулярно поставляет данные о потреблении энергии
•Данные нужно хранить в БД за каждые 10 минут без пробелов
•Все пробелы нужно заполнить
select meter_id,
interval_5min,
ts_first_value(power_consumption, 'linear')
from energy_readings
timeseries interval_5min as '5 minutes'
over (partition by meter_id
order by reading_date);
Пример: Подготовить данные с устройств для анализа (smart meter data)

Поддержка R
• Что такое R?
• Язык для статистического анализа с открытым кодом
• Много пакетов для сложного исследования данных (data mining) и статистического анализа
• Преимущества пользовательских расширений (Udx) в R
• Vertica автоматически за-параллеливает вычисления R
• Оптимизирована передача данных между Vertica и R
Verticaкластер

Исходный код в R
UDx в R, пример: метод K-средних
# Example: K-means (k=5)
# Input: two-dimensional points
# Output: the point coordinates plus their assigned
# cluster
kmeansClu <- function(x)
{
cl <- kmeans(x,5,10)
res <- data.frame(x[,1:2], cl$cluster)
res
kmeansCluFactory <- function()
{
list(name=kmeansClu,
udxtype=c("transform"),
intype=c("float","float"),
outtype=c("float","float","int"),
outnames=c("x","y","cluster") )
}
Создание и
использование функции
-- Define function
CREATE LIBRARY rlib
AS ‘/path/rcode.R’ LANGUAGE 'R';
CREATE TRANSFORM FUNCTION Kmeans
AS LANGUAGE 'R' NAME 'kmeansCluFactory'
LIBRARY rlib;
-- Use function
CREATE TABLE point_data (
x FLOAT, y FLOAT );
SELECT Kmeans(x, y)
OVER() FROM point_data;

• Анализ
• Hadoop
7. Развитие
8. Итоги

Внешние таблицы
• Внешняя таблица: файл доступен для Vertica (SQL), но не управляем ею (DML
невозможен)
• «Холодные» данные хранятся на дешевых носителях – анализ по мере надобности
• Передача данных из других SQL СУБД, HDFS (User Defined Load)
• Можно объединять (Join) данные из внешних источников с данными из Vertica
VMart=> create external table ext (x integer) as copy from '/home/dbadmin/ext.dat';
Vertica
External Table External TableExternal Table

Unstructured Dark Data
Гибкая таблица, зона (Flex Zone)
Native
Vertica
Data
Flex Zone
Быстрый, ежедневный анализПредварительный анализ
Внешние
структурированные данные
Внешние таблицы
• MapReduce
• Sqoop
• HDFS
Анализируй данные, не зная их структуры

• Анализ
1. Внешние и гибкие таблицы
• Hadoop
7. Развитие
8. Итоги

Интеграция с Hadoop
Быстрая СУБД должна быть
интегрирована с Hadoop, а не
встроена в него
Hadoop / Vertica: Сложный анализ
MapReduce / Pig Job
DFS Block 1
DFS Block 1
DFS Block 1
DFS Block 2
DFS Block 2
DFS Block 2
DFS Block 3 DFS Block 3
Map
Map
Map
Reduce Vertica
Data
data data data data da
data data data data data
data data data data data data
MapReduce / Pig Job
DFS Block 1
DFS Block 1
DFS Block 1
DFS Block 2
DFS Block 2
DFS Block 2
DFS Block 3 DFS Block 3
Map
Map
Map
Reduce
VerticaVertica
Hadoop / Vertica: преобразование данных
HDFS File

Интеграция с Hadoop
HDFS connector
• Загрузка в Vertica из HDFS через COPY оптимальная параллельность
– SQL к HDFS через внешнюю таблицу
– Безопасность через авторизацию Kerberos
Hadoop & Pig Connector
• Перемещение данных между Hadoop и Vertica
• Запросу к Hadoop из Vertica
• JDBCODBC для Windows, Linux, Solaris, AIX и др.
Hcatalog
• Запросу к Hadoop из Vertica
• Доступ через внешние таблицы
• Open SQL on Hadoop

Как работает коннектор к HDFS?

• Анализ
• Внешние и гибкие таблиВнешние и гибкие табли
• Hadoop
7. Развитие
8. Итоги

Ближайшая версия Vertica “Dragline”
FY14 FY15
• Проекции-агрегаты: ускорение ресуроемких агрегирующих
функций
• Динамическое управление смешанной рабочей нагрузкой
• Vertica Pulse: анализ текстов и окраски высказываний в соц.сетях
• Vertica Place: хранение и анализ гео-пространственных данных
• Расширение SQL над Hadoop

HP Vertica в развитии
Vertica “Crane” (7.0)
- Key-Value Lookups с
интерфейсом к NoSQL
Vertica “Dragline”
- Проекции-агрегаты
- Гео-и-текстовая аналитика
- Текстовый поиск
Vertica “Excavator”
- In-Memory
- Кубы
- Текстовый поиск
Vertica “Frontloader”
- Streaming
- Federation for Read and
Write – Unified SQL
- Navigation and joins-
across HBase and Other
NoSQL Tools
ВИДЕНИЕ
Fast self-
service
analytics for
consumers
FY14 FY15

Кратко о Vertica
• Колоночное: быстрый доступ к нужным данным, снижение I/O
• Загрузка и запросы в реальном времени
• Автоматический дизайн
• MPP кластер х86_64 серверов, просто расширяемый до Петабайтов данных
• Мощная аналитика:
– встроенные аналитические функции, полная поддержка R,
– среда для разработки UDFUDX
• Flex Zone: Быстрый и дешевый анализ непонятных данных без создания схем данных в
Vertica
• Тесная интеграция с MapR, Hadoop
• Внешние таблицы: передача данных из SQL СУБД, HDFS
• Встроенная высокая доступность
• Управление рабочей нагрузкой
Платформа нового поколения

Ещё раз о выгодах
Быстрая отдача
• Загрузка и запросы
одновременно
• Автоматический
дизайн
• Простая инсталляция
и управление
Быстрый анализ
• В одном темпе с
бизнесом
• Реальное время
Расширяй
платформу по мере
необходимости
• Без остановки
кластера
• Иногда без докупки
лицензий

Спасибо!

Приложения

Системные ограничения
Item Limit
Number of nodes Maximum 128 (without HP Vertica assistance).
Database size Approximates the number of files times the file size on a platform, depending on the maximum disk configuration.
Table size 2^64 rows per node, or 2^63 bytes per column, whichever is smaller.
Row size 32 MB. The row size is approximately the sum of its maximum column sizes, where, for example, a VARCHAR(80) has a maximum size of 80 bytes.
Key size Limited only by row size
Number of tables/projections per
database
Limited by physical RAM, as the catalog must fit in memory.
Number of concurrent
connections per node
Default of 50, limited by physical RAM (or threads per process), typically 1024.
Number of concurrent
connections per cluster
Limited by physical RAM of a single node (or threads per process), typically 1024.
Number of columns per table 1600.
Number of rows per load 2^63.
Number of partitions 1024.
•While HP Vertica supports a maximum of 1024 partitions, few, if any, organizations will need to approach that maximum. Fewer partitions are likely to
meet your business needs, while also ensuring maximum performance. Many customers, for example, partition their data by month, bringing their
partition count to 12. HP Vertica recommends you keep the number of partitions between 10 and 20 to achieve excellent performance.
Length for a fixed-length column 65000 bytes.
Length for a variable-length
column
65000 bytes.
Length of basic names 128 bytes. Basic names include table names, column names, etc.
Query length No limit.
Depth of nesting subqueries Unlimited in FROM, WHERE, or HAVING clause.

Andrei Kirilenkov. Vertica

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (20)

Destacado

Destacado (9)

Similar a Andrei Kirilenkov. Vertica

Similar a Andrei Kirilenkov. Vertica (20)

Más de Volha Banadyseva

Más de Volha Banadyseva (20)

Andrei Kirilenkov. Vertica