VERTICA как развитая MPP СУБД

VERTICA – выдающаяся аналитическая платформа для реализующая полнофункциональную поддержку OLAP технологий и анализа больших объемов данных. Для снижения порога входа в использование, существует VERTICA Community Edition — полноценная бесплатная версия VERTICA предназначена для работы с данными объемом до 1 Тб и максимум 3 серверами в кластер позволяет взять легкий старт в освоении и имплементации VERTICA в ИТ ландшафт любой компании.

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

Преимущества внедрения VERTICA:

Значительное увеличение скорости обработки запросов, что особенно заметно при работе с большими объемами данных.
Легкое развертывание и начало работы с платформой.
Высокая производительность в реальном времени, гибридная архитектура с загрузкой данных и обработкой запросов по параллельным проекциям.
«Нулевое» администрирование. VERTICA практически не требует администрирования, сложной настройки в процессе использования.
Высокая степень сжатия, интегрированная в DDL операции, позволяющая снизить затраты на хранение данных и сэкономить до 90% дискового пространства.
Значительная экономия: не требуется тратить значительные средства на добавление ресурсов DBA, замену текущих СУБД и покупку дополнительных лицензий на них, приобретение проприетарных программно-аппаратных комплексов
Масштабируемость при работе с данными большого объема.
Возможность интеграции с системами Business Intelligence, системами отчетности, ETL.
Поддержка интерфейсов ODBC, ADO.NET, JDBC, OLEDB.
Для полноценного внедрения, администрирования и работы с платформой достаточно всего 1-2 IT-специалиста. Это позволяет:
С успехом использовать VERTICA Community Edition, полноценную бесплатную версию VERTICA (объем «сырых» данных до 1 Тб, максимум 3 сервера в кластере).
Внедрять решения на базе VERTICA в небольших компаниях с малым штатом сотрудников или для обособленных бизнес-процессов, критичных к временным задержкам на принятие решений.
Отказаться от услуг сторонних специалистов в сфере администрирования и обслуживания.

Если вкратце, то от обычной СУБД ее отличают несколько признаков:

Колоночное хранение данных и их сжатие. В отличие от традиционных баз, хранящих данные в формате строк, Vertica хранит данные в виде колонок в сжатом виде. Такое хранение позволяет иметь большую степень сжатия, освобождая при этом много дискового пространства.
MPP (massive parallel processing) архитектура. СУБД Vertica разработана для работы в кластере MPP, поэтому ее отличают низкие затраты на оборудование. Vertica позволяет легко масштабировать свой кластер с помощью добавления стандартных серверов общего применения, таким образом до определенной степени сокращая аппаратные расходы.
Проекции – оптимизированное хранилище данных. В Vertica нет понятия индексов, а «таблица» — это логическая структура хранения, а не физическая. Данные хранятся в виде проекций. Проекция — это некий аналог материализованного представления, которое является единицей физического хранения данных в Vertica, информация в проекциях может дублироваться для обеспечения быстрого доступа к данным.
Помимо прочего, в Vertica существуют двухкомпонентное хранилище данных, состоящие из: WOS (write optimized storage) – хранилище в оперативной памяти, ROS (read optimized storage) – хранилище на диске
Асинхронный процесс, осуществляющий перемещение данных между хранилищами (Tuple Mover).
Ну и в еще одно отличие — это Flex-таблицы, возможность хранения неструктурированных или полуструктурированных данных в отдельном хранилище.

VERTICA с точки зрения архитектора

Именно в первую очередь от архитектора зависит успешность и производительность функционирования хранилища данных. При разработке архитектуры возникает две сложных задачи: грамотно подобрать техническую начинку кластера VERTICA и правильно спроектировать физическую модель базы данных.

На что влияет техническая архитектура

Являясь MPP сервером, VERTICA в первую очередь предъявляет жесткие требования к сетевой архитектуре. Если у Вас 3 сервера в кластере и база 3 тб, то обмен данных между ними и пользователями не особо заметен по сетевым расходам. Если же у Вас 6 серверов и база в 30 тб данных, то в пиковых нагрузках сеть может стать самым слабым местом всей работы кластера.

Правильно собранные массивы на локальных дисках серверов кластера залог успешного балансирования между производительностью, объемом хранения и стоимостью железа.
VERTICA критична к располагаемой RAM. Понятно, что памяти много не бывает и зачастую дешевле сразу купить сервера с большим объемом RAM, чем потом доставлять уже к существующим серверам. Тут стоит помнить, что аналитические запросы к биллионам записей данных хотят очень много памяти, физику никто не отменял. VERTICA позволяет успешно сбалансировать нагрузки потребления ресурсов с помощью пулов ресурсов но рост количества сессий и объемов обрабатываемых каждой сессией данных берут свое.
При том, что VERTICA очень рационально используем процессорные ресурсы, значительное число запросов требует значительного числа процессоров. В противном случае, часть запросов будет висеть в очереди, вызывая недоумение тех, кто ждет быстрой реакции.

На что влияет физическая модель базы данных

Здесь сложно проставить уровень критичности, все является важным, поэтому список без нумерации:

VERTICA на удивление эффективно работает с JOIN даже больших таблиц, но все-таки колонко-ориентированные СУБД изначально ориентировались на то, чтобы постараться избавиться от лишнего количества соединений и упростить схемы данных. Везде, где можно, пользуйтесь денормализацией данных. Это не увеличивает затраты на хранение данных, но зато ускоряет выполнение запросов и в том числе упрощает их написание, убирая лишние таблицы из запроса. Минус здесь можно считать то, что денормализованные данные в таблицах занимают место в лицензии. Но, если подумать логически, вывод в таблицу фактов имени и цены товара займет на одну запись в среднем 30 байт, то есть на миллиард записей в фактах это выльется в 30 гб лицензии. Не бог весть какой объем, чтобы экономить байты.
Партиционирование позволяет разбить данные таблицы на логические контейнеры, с которыми VERTICA легче манипулировать по хранению и доступу к данным. Опыт использования VERTICA можно сформулировать просто: ключей партиций не должно быть много и не должно быть мало. В первом случае VERTICA теряет время на пересмотре множества контейнеров партиций. Во втором случае VERTICA будет тратить много времени на сливание и чтение контейнеров значительных размеров на диске. Так же, планируя партиции, стоит помнить, что VERTICA умеет быстро и эффективно удалять, а также переносить в другие таблицы контейнеры по ключам партиций и этим нужно пользоваться. Вывод из всего этого прост: не надо делать контейнеры по логическим признакам, таким как например города или клиенты.
Любой MPP сервер, будь то VERTICA, Hadoop или Cassandra любит равномерно распределенные данные по серверам кластера. Если сегментация явно не указана, VERTICA по умолчанию просто сегментирует по хешу всех полей таблицы. Это дает равномерное распределение данных между серверами кластера, но есть моменты, когда это можно вдумчиво сделать вручную. Это может иметь смысл в случаях частого использования в запросах группировки данных по определенным полям при условии, что записей по этим полям группировки всегда примерно равномерное распределенное количество.
Одно из преимуществ VERTICA гласит: в VERTICA нет индексов. Но отсутствие индексов компенсируется сортировкой и форматами кодирования хранения данных. Фактически от этих вещей напрямую зависит, насколько эффективно Ваша таблица или ее проекция будут готовы выполнять различные запросы, и кто больше из проекций понравится оптимизатору запросов при построении плана выполнения запроса. Рекомендации на эту тему можно давать множество но выжимка приведена ниже:
1. При выборе способа хранения значения колонки, VERTICA автоматически ориентируется на ее тип данных. Так как никаким алгоритмом не возможно угадать, что BIGINT в каком-то случае это значение факта, а в каком-то идентификатор измерения, стоит при описании таблиц не игнорировать указание ENCODING той части полей, которая будет востребована при фильтрации и агрегации в запросах, то есть является не фактами, а значением измерений. При правильном описании этой опции колонок, VERTICA легче будет хранить и искать данные по ним, а оптимизатору учитывать при построении более эффективных запросов. Так же не забываем про GROUPING, если есть поля, которые всегда в запросах возвращаются и обрабатываются вместе, есть хороший повод объединить их хранение в одном месте, снизив затраты на их чтение и сборку записей.
2. При назначении сортировки таблице или проекции помним, что на все случаи сортировкой не запасешься и от создания проекций не убережешься. Поэтому для таблицы выбираем сортировку с точки зрения выполнения наиболее часто идущих запросов, а на остальные случаи уже делаем проекции.
3. При выборе полей и порядка сортировки ориентируемся примерно на такие правила: в начале сортировки ставим колонки, по которым наиболее часто идет поиск в запросах по равенству и которые наиболее подходят под определение уникальных, далее в середину сортировки неплохо поместить поля, которые используются в соединениях или поиску по списку оператором IN. Последними уже стоит поместить поля, по которым идут операции сравнения.
4. Для того, чтобы окончательно уверить себя в правильности выбора параметров хранения данных, можно провести эксперимент. А именно: развернуть на VERTICA прототип таблицы без явного указания сегментации и сортировки, заполнить ее определенным объемом данных, побольше написать в файлик типовых запросов к этой таблице и прогнать через Database Designer утилиты VERTICA adminTools. Дизайнер проанализирует запросы, создаст под таблицу нужные проекции с оптимальными с его точки зрения кодировкой и сортировкой данных. Далее можно будет погонять запросы по этой таблице, посмотреть их планы запросов, оценить насколько предложенные проекции эффективны и уже сделать рабочую таблицу, ориентируясь на предложенную в созданных проекциях сортировку, сегментацию и кодирование полей. Ну и при необходимости создать сразу же дополнительные проекции для запросов, которые не покрывает сортировка самой таблицы и которые были предложены дизайнером VERTICA.

VERTICA с точки зрения разработчика ETL/ELT

Разработчику ETL логики VERTICA предоставляет все стандартные драйвера доступа к данным (ODBC, JDBC, .NET, Python). Так же есть внушительный набор штатных собственных средств пакетной загрузки плоских файлов команды COPY. Их можно расширять собственными парсерами, фильтрами и валидаторами. Файлы можно загружать как с самих серверов кластера, так и локально с рабочих машин посредством COPY LOCAL. JDBC драйвера VERTICA поддерживают вставку batch insert через JDBC prepared statement, автоматически преобразуя пакеты вставляемых значений в пакетную вставку COPY. Это дает высокую скорость вставки записей. Единственной ложкой дегтя можно отнести то, что функции расширения пакетной загрузки можно писать только на Си, что сразу же усложняет разработку. Судя по последним слухам, VERTICA уверенно движется к интеграции с миром Java (поближе видимо к Hadoop), поэтому вполне возможно в скором будущем, такие вещи можно будет писать и подключать на Java. Касаясь вопросов производительности и эффективности параллельной загрузки больших объемов данных, VERTICA с своей архитектурой полностью забирает их на себя. От разработчика ETL не требуется каких-либо особенных знаний нюансов организации загрузки в реальном масштабе времени и распределения нагрузок.

VERTICA с точки зрения разработчика BI

При разработке сложных запросов под BI, часто фильтрация данных по заданным параметрам используется где-то там, внутри подзапросов. А сверху уже над результатами подзапросов происходит агрегация данных. Невозможность вынести такие запросы в VERTICA, как сохраненные запросы с параметрами, вынуждают разработчиков BI копировать сложные запросы между различными universes (в терминологии SAP BO), экстрактами и прочим, что у кого есть в BI инструментах. В остальном, как и в случае с ELT разработчиками, VERTICA полностью покрывает весь спектр выполнения аналитических запросов любого уровня сложности. То есть, не имеет никаких ограничений в SQL запросах, есть поддержка функций и расширений OLAP, WITH, TIME SERIES, TIME JOIN, EVENT SERIES, работы с гео-данными, ip адресацией, url-ами и т.д. Сами метаданные хранилища VERTICA замечательно видятся в BI и никаких сложностей при работе с VERTICA у всех основных продуктов BI не наблюдается. Здесь стоит для интересующихся вопросами взаимодействия VERTICA с BI обратить внимание на такую замечательную связку, как VERTICA и Tableau. Эти два продукта вместе выдают на выходе мощный анализ, осуществляемый аналитиками прямо в реальном времени. Я считаю, что главные вопросы для BI разработчиков, а именно производительность ad-hoc запросов и ограничения функциональности, в VERTICA просто отсутствуют, что положительно сказывается на скорости и качестве разработки BI решений.

VERTICA с точки зрения администратора

Администрирование VERTICA условно можно считать нулевым. Это не означает, что VERTICA не нуждается в администрировании. Имеется ввиду, что администрирование VERTICA требуется эпизодически, по мере изменения потребностей. Причем вместо выделенной штатной единицы постоянного администратора вполне возможно удаленное администрирование сервера или администрирование архитектором, разработчиком ETL или BI. Само администрирование сервера можно условно разбить на некоторое количество категорий:

Управление ролями и пользователями. Стандартный процесс описание в базе данных пользователей, их распределения по ролям и описания доступа ролей к объектам базы данных. Работа не частая, производится по мере добавления пользователей и ролей.
Управление нагрузками на кластер. Более сложный процесс, требующий представления архитектуры работы сервера VERTICA. Требует проведения анализа текущих нагрузок на кластер различных процессов и групп пользователей для оптимального распределения ресурсов серверов VERTICA по пулам ресурсов. С помощью пулов ресурсов можно разбить выполнение запросов по категориям, выделить по их потребностям различное описание использования ресурсов, указать горячий зарезервированный размер памяти, максимальный объем потребляемой памяти, количество конкурирующих соединений, приоритет получения ресурсов, максимально допустимое время выполнения запросов, а также ограничения на уровне использования ядер процессоров. Грамотная разработка пулов ресурсов и распределение по ним различных пользователей гарантирует сбалансированную работу кластера даже в случаях пиковых нагрузок. Это позволяет эффективно распределить выполнение между задачами категорий реального времени, оперативными отчетами и длинными аналитическими запросами. Обычно такая работа уже проводится на продуктивном сервере, с устоявшимися нагрузками и представлением, когда и как возникают пиковые нагрузки на сервер. Пока условия нагрузок не изменяются, смысла изменять пулы ресурсов нет.
Управление серверами кластера. Сам процесс добавления новых серверов в кластер, замены или удаления серверов из кластера с последующей ребалансировкой данных не является сложным и производится посредством утилиты, однако требует четкого понимания архитектуры работы сервера и планирования проведения работ таким образом, чтобы частичное падение производительности кластера при проведении таких работ не совпало с другими затратными работами в хранилище данных. Например, одной из таких задач может быть в данный момент перегрузка большого объема данных из таблицы в таблицу или загрузка из внешнего источника. К примеру, на нашей практике, добавление к 3 серверам еще 3 серверов в кластер с ребалансировкой данных между ними, заняло порядка суток с незначительной потерей производительности, которую в итоге никто из пользователей не заметил.
Восстановление работы кластера. В случае падения одного из серверов кластера, администратор VERTICA может заново запустить этот сервер, если сервер физически работоспособен и по сети видит другие сервера или же заменить его на другой, если сервер вышел из строя. На момент отключения сервера от кластера, происходит частичное падение производительности хранилища данных за счет того, что другой сервер кластера был вынужден взять на себя работу остановившегося сервера. Администратор имеет утилиты, позволяющие запустить или заменить сбойный сервер, дальнейшую работу по автоматическому восстановлению данных на сервере и его включению в работу, VERTICA берет на себя. Если аппаратная часть серверов надежная, то эта работа не частая — в нашей практике у VERTICA всего два раза останавливался один из серверов кластера. Первый раз из-за того, что был сбой при работе с RAM, второй раз при сбое в работе RAID контроллера. В обоих случаях, кластер не останавливал работу, пока производились технические работы с серверами. Пользователи и загрузчики данных продолжали работать в штатном режиме работы с хранилищем данных.
Апгрейд версии сервера. Производится путем закачки дистрибутива на один из серверов VERTICA, временной остановки сервера VERTICA в пределах 10 минут, запуска инсталляции апгрейда и обратного старта сервера VERTICA. С этой работой справится любой администратор, умеющий загрузить файлы на Linux и запускать программы.
Оптимизация запросов. Если возникают моменты, когда определенные запросы слишком медленно работают, значит возможно пришло время на таблицу сделать еще одну проекцию. Для этого администратор может вызвать Database Designer из утилиты VERTICA adminTools и прогнать через него проблемные запросы. На выходе дизайнер проведет анализ, что именно не хватает для быстрой жизни этих запросов и выдаст готовые рецепты в виде проекций на таблицы. Следовать или не следовать этим рецептам — решать уже Вам. Разработчики VERTICA утверждают, что их американские и европейские клиенты, не задумываясь просто создают рекомендуемые проекции и все у них хорошо. Я же лично перепроверяю за тем, что делает дизайнер. В основном претензий у меня не возникает, но иногда я все-таки считаю, что некоторые из предлагаемых проекций излишни и больше займут места на дисках серверов, чем принесут пользы для ускорения запросов. В основном это касается тех случаев, когда запросы не обязательно должны отрабатывать в пару секунд и сессия замечательно подождет несколько десятков секунд, пока запрос выполнится без каких-либо претензий пользователя или процесса.

← Предыдущая статья

Сравнение аналитических in-memory баз данных

Следующая статья →

Каталог данных на примере DataHub. Часть I