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 2. HP Vertica: история, основы, практика 3. HP Vertica: Архитектура 4. Высокая доступность 5. Управление рабочей нагрузкой 6. Возможности

• Анализ • Внешние и гибкие таблицы • Hadoop



• Ограничения традиционных платформ • Big Data

«Узкие места» • Разделяемый ресурс • «Массивное» чтение с дисков • Сеть внутри кластера

Два вызова в хранении и анализе данных


Традиционные платформы

• Не могу загружать данные и одновременно их анализировать

• Слишком долго выполняются запросы и отчеты • Строю агрегаты и не могу спуститься к детальным

данным • Перемещаю данные в инструменты для сложного

анализа и data mining • Сложно сопровождать • Не успеваю за ростом нагрузки и объема данных • Дорого и сложно обеспечить высокую доступность • Не хватает дополнительных сред (тестирование,

разработка...)

Типовые недоумения клиентов


Объем (Volume) • 10% организаций обрабатывают 1+ Пб данных • Социальные сети – миллионы транзакций в минуту

Скорость (Velocity) • 30% организаций имеют 100+ Гб/день • Данные обновляются и нужны раз в день, час

Разнообразие (Variety) • Тексты, Аудио и видео файлы • Блоги, сообщения в сетях – для изучения клиентов • Внутренние источники данных

Сложность • Осмысленные связи • Преобразование • Очистка

Разно-образие

Сложность Скорость

Объем

Цели: • Эффективность • Удовлетворение клиентов • Снижение риска • Расширение бизнеса

Вызов: извлечь из Big Data важное для бизнеса

Big Data: информационный вызов


“Big Data и традиционные данные – две части единой стратегии данных и их анализа”

Том Давенпорт (один из трех лучших консультантов мира в области аналитики)


Стратегия 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 в больших компаниях


Базовые принципы

Быстрый отклик на запросы

Простая и

линейная масштабируемость

Экономия дискового

пространства

Загрузка и запросы одновременно,

Работа 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









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



Узлы кластера – Все узлы

равнозначны

– Загрузка/Запросы – на любой узел

– Непрерывная/в реальном времени загрузка и анализ


Распределённое выполнение запросов • Балансировщик (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


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

A3

B3

C3

A2

B2

C2

B1

A1

C1

B2

A2

C2

B1

A1

C1

A3

B3

C3

A1

B1

C1

B3

A3

C3


Защита от катастроф Вариант 1: Загрузка данных в обе системы. (Для больших объемов)

За: Обе системы активны Против: ETL обеспечивает согласованность данных

Вариант 2: Репликация снимков

Vertica Backup

За: Минимальный риск не-согласованности данных Против: Во время синхронизации 2-й кластер не активен

http://images.google.com/imgres?imgurl=http://linux.softpedia.com/screenshots/Talend-Open-Studio_1.png&imgrefurl=http://linux.softpedia.com/progScreenshots/Talend-Open-Studio-Screenshot-19135.html&h=598&w=768&sz=130&hl=en&start=12&sig2=fectlnlgp7ogqTwkTgmOGw&tbnid=x2Jye0DbxrcydM:&tbnh=111&tbnw=142&ei=iO5GSI_rCY2EpASfuOXOBQ&prev=/images?q=talend&gbv=2&hl=en

http://images.google.com/imgres?imgurl=http://linux.softpedia.com/screenshots/Talend-Open-Studio_1.png&imgrefurl=http://linux.softpedia.com/progScreenshots/Talend-Open-Studio-Screenshot-19135.html&h=598&w=768&sz=130&hl=en&start=12&sig2=fectlnlgp7ogqTwkTgmOGw&tbnid=x2Jye0DbxrcydM:&tbnh=111&tbnw=142&ei=iO5GSI_rCY2EpASfuOXOBQ&prev=/images?q=talend&gbv=2&hl=en


Легко расширяемый кластер

Простое добавление новых серверов • Добавь узел и повысь емкость или быстродействие • 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. Big data и предпосылки к созданию HP Vertica 2. HP Vertica: история, основы, практика 3. HP Vertica: Архитектура 4. Высокая доступность 5. Управление рабочей нагрузкой 6. Возможности 1. Анализ

• Внешние и гибкие таблицы • Hadoop



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

Verti

ca к

ласт

ер

Исходный код в 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;


Внешние таблицы • Внешняя таблица: файл доступен для Vertica (SQL), но не управляем ею (DML

невозможен) • «Холодные» данные хранятся на дешевых носителях – анализ по мере надобности • Передача данных из других SQL СУБД, HDFS (User Defined Load) • Можно объединять (Join) данные из внешних источников с данными из Vertica

VMart=> create external table ext (x integer) as copy from '/home/dbadmin/ext.dat';

Vert

ica

External Table External Table External Table

http://www.oracle.com/


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


Map

Map

Map

Reduce

Vertica

Data data data data data da data data data data data data data data data data data data data data data data data data data data data data data data data data data data data data data data data data data data 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



Map

Map

Map

Reduce

Vertica

Vertica

Hadoop / Vertica: преобразование данных

HDFS File


Интеграция с Hadoop

HDFS connector • Загрузка в Vertica из HDFS через COPY оптимальная параллельность

– SQL к HDFS через внешнюю таблицу – Безопасность через авторизацию Kerberos

Hadoop & Pig Connector • Перемещение данных между Hadoop и Vertica • Запросу к Hadoop из Vertica • JDBC\ODBC для Windows, Linux, Solaris, AIX и др.

Hcatalog • Запросу к Hadoop из Vertica • Доступ через внешние таблицы • Open SQL on Hadoop


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



• Анализ • Внешние и гибкие таблиВнешние и гибкие табли • Hadoop



Ближайшая версия 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, – среда для разработки UDF\UDX

• 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

Software

Transcript of Andrei Kirilenkov. Vertica