Machine Learning для Vertica

Аннотация

В данной статье я хочу поделиться собственным опытом работы с машинным обучением в хранилище данных на Vertica.
Скажем честно, я не являюсь аналитиком-экспертом, который сможет в деталях расписать все многообразие методик исследования и алгоритмов прогнозирования данных. Но все же, являясь экспертом по Vertica и имея базовый опыт работы с ML, я постараюсь рассказать о способах работы с предиктивным анализом в Vertica с помощью встроенной функциональности сервера и языка R.

Machine Learning библиотека Vertica

Начиная с 7 версии Vertica дополнили библиотекой Machine Learning, с помощью которой можно:

• подготавливать примеры данных для машинного обучения;
• тренировать модели машинного обучения на подготовленных данных;
• проводить предиктивный анализ данных хранилища на сохраненных моделях машинного обучения.

Библиотека идет сразу в комплекте с инсталляцией Vertica для всех версий, в том числе бесплатной Community. Работа с ней оформлена в виде вызова функций из-под SQL, которые подробно описаны в документации с примерами использования на подготовленных демонстрационных данных.

Пример работы с ML в Vertica

В качестве простого примера работы ML я взял демонстрационные данные по автомобилям mtcars, входящие в состав примера данных ML для Vertica. В эти данные входит две таблицы:

• mtcars_train – подготовленные для тренировки модели машинного обучения данные
• mtcars – данные для анализа

Посмотрим на данные для тренировки:

=>SELECT * FROM mtcars_train;

В наборе данных по моделям автомобилей расписаны их характеристики. Попробуем натренировать машинное обучение так, чтобы по характеристикам автомобилей можно было прогнозировать, какой тип коробки передач задействован в автомобиле – ручная коробка или коробка автомат. Для этого нам понадобится построить модель логистической регрессии на подготовленных данных, найдя зависимость типа коробки поля "am" и полями веса автомобиля "wt", количества цилиндров "cyl" и количества скоростей в коробке "gear":

=>SELECT LOGISTIC_REG('logistic_reg_mtcars', 'mtcars_train', 'am', 'cyl, wt, gear');
Finished in 19 iterations

Вызванная функция проанализировала зависимость между am и полями cyl, wt, gear, выявила формулу зависимости и результат моделирования зависимости записала в базу данных Vertica в модель "logistic_reg_mtcars". С помощью этой сохраненной модели теперь можно анализировать данные по автомобилям и прогнозировать наличие коробки автомат.
Информацию по модели можно посмотреть:

=>SELECT GET_MODEL_SUMMARY(USING PARAMETERS model_name='logistic_reg_mtcars');

Используем теперь модель на данных по автомобилям, сохранив результат в новую таблицу:

=>CREATE TABLE mtcars_predict_results AS (
SELECT car_model, am,
PREDICT_LOGISTIC_REG(cyl, wt, gear
USING PARAMETERS model_name='logistic_reg_mtcars') AS prediction
FROM mtcars
);

И сравнив реальные значения am с полученными в прогнозе prediction:

=>SELECT * FROM mtcars_predict_results;

В данном случае прогноз на 100% совпал с реальным типом коробки у представленных моделей. В случае подготовки новых данных для обучения потребуется удалить и заново сохранить модель.

Функциональность ML в Vertica

Библиотека ML в Vertica поддерживает следующие виды предиктивного анализа:

• Прогнозирование:
  • Linear Regression
  • Random Forest for Regression
  • SVM (Support Vector Machine) for Regression
• Классификация:
  • Logistic Regression
  • Naive Bayes
  • Random Forest for Classification
  • SVM (Support Vector Machine) for Classification
• Кластеризация:
  • k-means

Для подготовки данных к обучению представлен следующий функционал:

• Балансировка данных
• Очистка выбросов
• Кодировка категориальных (текстовых) значений столбцов
• Замена пропущенных данных
• Нормализация данных
• Principal Component Analysis
• Сэмплирование данных
• Singular Value Decomposition

Рассматривая функционал ML в Vertica можно сказать, что встроенная библиотека позволяет решать достаточно широкий круг задач, но не имеет задела на исследование закономерностей и зависимостей в данных. Присутствуют функции подготовки данных для машинного обучения, однако без визуализации распределения данных в виде графиков "готовить" такие данные и тренировать по ним модели обучения смогут разве что гуру анализа, обладающие экспертными знаниями по анализируемым данным.

R Studio с Vertica

Для более тщательного и интерактивного предиктивного анализа данных идеально подходит язык R, который имеет визуальную среду работы с данными R Studio. Ощутимыми плюсами использования R с Vertica будут являться:

• интерактивность среды с возможностью сохранения состояния для дальнейшего анализа после следующего запуска;
• визуальный просмотр данных в виде таблиц и графиков;
• мощность языка R для работы с наборами данных;
• многообразие алгоритмов предиктивного анализа, аналогичных представленных в Vertica ML.

В качестве минусов работы R с большими данными можно назвать требования к оперативной памяти, скорость работы с большими массивами данных и необходимость импорта и экспорта данных Vertica. Эти недостатки покрываются возможностью встраивания написанных функций R для непосредственного выполнения на кластере в Vertica, о чем будет рассказано ниже.

Небольшое введение в R

Воспроизведем прогноз по коробкам автомат на данных Vertica с помощью R. Для того, чтобы не отпугнуть программистов, незнакомых с этим языком, я проведу краткий курс молодого бойца R.
Итак, язык R — это такой же процедурный язык, имеющий объекты, классы и функции. Объект может быть набором данных (вектор, список, датасет…), значением (текст, число, дата, время…) или функцией. Для значений поддерживаются числовые, строковые, булевые и дата время типы. Для наборов данных нумерация массивов начинается с 1, а не 0.
Классически вместо "=" в R используется оператор присваивания "<->" и даже привычный "=". Сам же оператор "=" используется при вызове функций для указания именованных параметров.
Вместо "." для доступа к полям наборов данных используется "$". Точка не является ключевым словом и используется в именах объектов для повышения их читабельности. Таким образом, "my.data$field" будет расшифровываться как массив записей поля "field" из набора данных "my.data".
Для обрамления текстов можно использовать как одинарные, так и двойные кавычки.
Самое главное: R заточен на работу с множествами данных. Даже если в коде написано "a<-1 1="" a="" c="" collection="" p="" r="">

Загрузка данных из СУБД в R

Для работы с РСУБД через ODBC для R требуется установить пакет RODBC. Его можно установить в R Studio на вкладке packages или с помощью команды R:

install.packages('RODBC')
library('RODBC')

Теперь мы можем работать с Vertica. Делаем ODBC алиас к серверу и получаем данные тестового и полного набора данных по автомобилю:

# Создаем подключение к Vertica
con <- br="" dsn="VerticaDSN" odbcconnect="">
# получаем данные таблицы mtcars_train
mtcars.train <- br="" con="" from="" public.mtcars_train="" sqlquery="">
# получаем данные таблицы mtcars
mtcars.data <- br="" con="" from="" public.mtcars="" sqlquery="">
# закрываем соединение
odbcClose(con)

При загрузке данных из источников R для полей текстовых типов и даты-времени автоматически устанавливается их принадлежность к факторам. Поле "am" имеет числовой тип и воспринимается R как числовой показатель, а не фактор, что не позволит провести логистическую регрессию. Поэтому преобразуем это поле в числовой фактор:
mtcars.data$am = factor(mtcars.data$am)
mtcars.train$am = factor(mtcars.train$am)

В R Studio удобно интерактивно смотреть данные, строить графики предиктивного анализа и писать код на R с подсказками:

Построение модели в R

Построим модель логистической регрессии над подготовленным набором данных по тем же измерениям, что и в Vertica:

mtcars.model <- cyl="" data="mtcars.train)</p" family="binomial()," formula="am" gear="" glm="" wt="">

Пояснение: в языке R формула предиктивного анализа указывается как:

<поле результата анализа>~<влияющие на анализ поля>

Анализ данных по модели в R

Инициализируем результирующий набор данных, взяв из mtcars все записи по нужным полям:

mtcars.result <- br="" car_model="mtcars.data$car_model," data.frame=""> am = mtcars.data$am, predict = 0)

Теперь по построенной модели можно выполнить анализ на самих данных:

mtcars.result$predict <- br="" mtcars.model="" predict.glm=""> newdata = subset(mtcars.data, select = c('cyl', 'wt', 'gear')),
type = 'response' )

Результат анализа возвращается в поле predict как процент вероятности прогноза. Упростим по аналогии с Vertica до значений 0 или 1, считая прогноз положительным при вероятности более 50%:
mtcars.result$predict <- ifelse="" mtcars.result="" predict=""> 0.5, 1, 0)

Посчитаем общее количество записей, у которых прогнозируемое поле predict не совпало с реальным значением в am:

nrow(mtcars[mtcars.result$am != mtcars.result$predict, ])

R вернул ноль. Таким образом, прогноз сошелся на все модели автомобилей, как и в ML у Vertica.

Обратите внимание: записи из mtcars были возвращены по фильтру (первый параметр в квадратных скобках) со всеми колонками (второй пропущенный после запятой параметр в квадратных скобках).

Локальное сохранение и загрузка данных в R

При выходе из R, студия предлагает сохранить состояние всех объектов, чтобы продолжить работу после повторного запуска. Если по каким-то причинам потребуется сохранить и затем восстановить состояние отдельных объектов, для этого в R предусмотрены специальные функции:

# Сохранить объект модели в файл
save(mtcars.model, file = 'mtcars.model')

# Восстановить объект модели из файла load('mtcars.model')

Сохранение данных из R в Vertica

В случае, если R Studio использовалась для подготовки данных для тренировки моделей ML Vertica или же прямо в ней был произведен анализ, который требуется далее использовать в базе данных Vertica, наборы данных R можно записать в таблицу Vertica.

Так как библиотека ODBC для R рассчитана на OLTP РСУБД, она не умеет корректно генерировать запросы создания таблиц для Vertica. Поэтому для успешной записи данных потребуется вручную создать нужную таблицу в Vertica с помощью SQL, набор полей и типов которой совпадает с записываемым набором данных R.

Далее сам процесс записи выглядит просто (не забываем открыть и потом закрыть соединение con):

sqlSave(con, mtcars.result, tablename = 'public.mtcars_result',
append = TRUE, rownames = FALSE, colnames = FALSE)

Работа Vertica с R

Интерактивная работа с данными в R Studio хорошо подходит для режима исследования и подготовки данных. Но совершенно не годится для анализа потоков данных и больших массивов в автоматическом режиме. Один из вариантов гибридной схемы предиктивного анализа R с Vertica — это подготовка данных для обучения на R и выявление зависимостей для построения моделей. Далее с помощью встроенных в Vertica функций ML тренируются модели прогноза на подготовленных на R данных с учетом выявленных зависимостей переменных.
Есть и более гибкий вариант, когда вся мощь языка R используется прямо из-под Vertica. Для этого под Vertica разработан R дистрибутив в виде подключаемой библиотеки, который позволяет использовать в SQL запросах функции трансформации, написанные прямо на языке R. В документации подробно описана установка поддержки R для Vertica и требуемых для работы дополнительных пакетов R, если таковые требуются.

Сохранение модели R в Vertica

Чтобы использовать ранее подготовленную в R Studio модель анализа в функциях R, работающих из-под Vertica, требуется их сохранить на серверах Vertica. Сохранять на каждом сервере кластера локально файлом не удобно и не надежно, в кластер могут добавляться новые сервера, да и при изменении модели потребуется не забыть переписать заново все файлы.
Самым удобным способом видится сериализовать модель R в текст и сохранить как UDF функцию Vertica, которая будет возвращать этот текст в виде константы (не забываем открыть и потом закрыть соединение con):

# Сериализуем модель в текст
mtcars.model.text <- br="" rawtochar=""> serialize(mtcars.model, connection = NULL, ascii = TRUE))

# Собираем текст функции для выполнения в Vertica
# (в тексте модели одинарные кавычки дублируются)
mtcars.func <- br="" paste0=""> "CREATE OR REPLACE FUNCTION public.MtCarsAnalizeModel()
RETURN varchar(65000)
AS
BEGIN
RETURN '", gsub("'", "''", mtcars.model.text), "';
END;
GRANT EXECUTE ON FUNCTION public.MtCarsAnalizeModel() TO public;"
)

# Создаем функцию на Vertica
sqlQuery(con, mtcars.func)

Предложенный способ позволяет обойти ограничение Vertica на передаваемые параметры в функции трансформации, где требуется передача только константы или выражения из констант. В Vertica UDF SQL компилируются не как функции, а как вычисляемые выражения, то есть при передаче параметра, вместо вызова функции будет передан ее текст (в данном случае константа), который был сохранен в коде выше.

В случае изменения модели потребуется пересоздать ее функцию в Vertica. Имеет смысл обернуть этот код в универсальную функцию, которая генерирует с переданной модели функцию в Vertica с указанным именем.

Функции R для работы в Vertica

Для того, чтобы подключить R функции к Vertica, надо написать функции анализа данных и регистрации в Vertica.

Сама функция работы с данными из-под Vertica должна иметь два параметра: получаемый набор данных (как data.frame) и параметры работы (как list):

MtCarsAnalize <- br="" data="" function="" parameters=""> if ( is.null(parameters[['model']]) ) {
stop("NULL value for model! Model cannot be NULL.")
} else {
model <- br="" chartoraw="" model="" parameters="" unserialize=""> }

names(data) <- br="" c="" car_model="" cyl="" gear="" wt="">
result <- car_model="data$car_model," data.frame="" predict="0)<br">
result$predict <- br="" model="" predict.glm=""> newdata = subset(data, select = c('cyl', 'wt', 'gear')),
type = 'response' )

result$predict <- ifelse="" predict="" result=""> 0.5, TRUE, FALSE)

return(result) }

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

Теперь остается описать регистрацию этой функции в Vertica:

MtCarsAnalizeFactory <- br="" function=""> list(name = MtCarsAnalize,
udxtype = c("transform"),
intype = c("varchar", "int", "float", "int"),
outtype = c("varchar", "boolean"),
outnames = c("car_model", "predict"),
parametertypecallback=MtCarsAnalizeParameters)
}
MtCarsAnalizeParameters <- br="" function=""> parameters <- br="" datatype="c(" list="" varchar=""> length = 65000,
scale = c("NA"),
name = c("model"))
return(parameters)
}

Функция MtCarsAnalizeFactory описывает имя используемой для работы функции, поля для входящего и исходящего набора данных, а вторая функция описывает передаваемый параметр "model". В качестве типов полей указываются типы данных Vertica. При передаче и возврате данных Vertica автоматически преобразует значения в нужные типы данных для языка R.

Таблицу совместимости типов можно посмотреть в документации Vertica.
Можно протестировать работу написанной функции для Vertica на загруженных в R студию данных:

test.data = subset(mtcars.data, select = c('car_model', 'cyl', 'wt', 'gear'))
test.params = list(model = mtcars.model.text)
test.result = MtCarsAnalize(test.data, test.params)

Подключение библиотеки функций к Vertica

Сохраняем все вышеописанные функции в один файл "mtcars_func.r" и загружаем этот файл на один из серверов из кластера Vertica в "/home/dbadmin".

Важный момент: в R Studio требуется установить параметр сохранения перевода строк в файлах в режим Posix (LF). Это можно сделать в глобальных опциях, разделе Code, вкладке Saving. Если Вы работаете на Windows, по умолчанию файл будет сохранен с переводом каретки и не сможет быть загружен в Vertica.

Подключаемся к серверу из кластера Vertica, на который сохранили файл и загружаем библиотеку:

CREATE LIBRARY MtCarsLibs AS '/home/dbadmin/mtcars_func.r' LANGUAGE 'R';

Теперь из этой библиотеки можно зарегистрировать R функцию:

CREATE TRANSFORM FUNCTION public.MtCarsAnalize
AS LANGUAGE 'R' NAME 'MtCarsAnalizeFactory'
LIBRARY MtCarsLibs;

GRANT EXECUTE ON TRANSFORM FUNCTION
public.MtCarsAnalize(varchar, int, float, int)
TO public;

Вызов R функций в Vertica

Вызываем функцию R, передавая ей текст модели, который ранее был сохранен как UDF функция:

SELECT MtCarsAnalize(car_model, cyl, wt, gear USING PARAMETERS model = public.MtCarsAnalizeModel()) OVER() FROM public.mtcars;

Можно проверить, что так же, как и в предыдущих случаях, дается совпадающий на 100% с реальным положением дел прогноз:

SELECT c.*, p.predict, p.predict = c.am::int AS valid
FROM public.mtcars c
INNER JOIN (
SELECT MtCarsAnalize(car_model, cyl, wt, gear
USING PARAMETERS model = public.MtCarsAnalizeModel()) OVER()
FROM public.mtcars
) p ON c.car_model = p.car_model

Обратите внимание: функции трансформации в Vertica возвращают собственный набор данных из определяемых внутри функций полей и записей, однако они могут быть использованы в запросах, если обернуты в подзапрос.

При подключении R функций Vertica копирует в свою инсталляцию исходный код, который далее компилирует в машинный код. Выложенный на сервер исходный R файл после подключения в библиотеку не требуется для дальнейшей работы. Скорость работы функций с учетом бинарной компиляции достаточно высокая для того, чтобы работать с большими массивами данных, однако стоит помнить, что все операции R проводит в памяти и есть риск уйти в свап, если появится нехватка памяти ОС для обеспечения нужд совместной работы Vertica и R.

Если функция вызывается на партиции данных, указанных в PARTITION BY для OVER, то Vertica распараллеливает выполнения каждой партиции по серверам кластера. Таким образом, если бы в наборе данных помимо модели машины еще присутствовал производитель, можно было бы указать его в PARTITION BY и распараллелить выполнение анализа на каждого производителя.

Прочие возможности Vertica в области машинного обучения

Помимо R для Vertica можно разрабатывать собственные функции трансформации на языках C, Java и Python. Для каждого из языков есть свои нюансы и особенности написания и подключения к Vertica. Вкупе с собственным ML все это дает в Vertica хороший задел для предиктивного анализа данных.

Благодарности и ссылки

Хочу от всей души поблагодарить моего друга и коллегу Влада Малофеева из Перми, который познакомил меня с R и помог с ним разобраться на одном из наших совместных проектов.

Изначально в проекте, где строился прогноз по сложным условиям на будущее с использованием данных прошедшего года, разработчики пытались использовать SQL и Java. Это вызывало большие сложности с учетом качества данных источников и здорово тормозило разработку проекта. В проект пришел Влад с R, мы с ним подключили R под Vertica, он погонял данные на студии и все сразу красиво закрутилось и завертелось. Буквально за недели разгреблось все, что тянулось месяцами, избавив проект от сложного кода.

Приведенный пример данных с автомобилями можно скачать с GIT репозитория:

git clone https://github.com/vertica/Machine-Learning-Examples

и загрузить в Vertica:

/opt/vertica/bin/vsql -d -f load_ml_data.sql

Если Вы хотите углубиться в ML и научиться работать с R, рекомендую к изучению книгу на русском "R в действии. Анализ и визуализация данных на языке R". Написано простым доступным человеческим языком и подойдет для начинающих, кто ранее не сталкивался с машинным обучением.

Здесь можно посмотреть сведения о подключении R библиотеки к Vertica.

Для тех, кто уже начал изучать и использовать ML на Python, стоит обратить внимание на IDE Rodeo, это аналог R Studio, ведь без интерактива качественный анализ невозможен. Думаю, все описанное в этой статье под R аналогичном образом может быть разработано на Python, включая сохранение модели в UDF функции и разработку функций анализа под Vertica. Если будете проверять, не забудьте отписаться о результатах в комментариях, буду признателен за информацию.

Благодарю за уделенное время и надеюсь, что смог продемонстрировать простоту и невероятные возможности симбиоза R и Vertica.

Источник: Статья на habr.com

Вышла 8 версия Vertica

Всем привет и хорошего дня :)

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

Что же я имею ввиду?

Облака

Во-первых, это интеграция с MS Azure Cloud. Это позволит использовать Вертику в облаках MS. В последнее время я вижу большой задел дружбы HPE и MS. Помимо Azure, для Вертики расширили поддержку VS Studio и улучшили работу драйверов под ADO.NET.

Меня дружба между Вертикой и MS определенно радует, надеюсь она будет развиваться дальше.

Джунгли

Во-вторых, Вертика продолжает тесно вгрызаться в мир Hadoop-а. Если в более ранних версиях, Вертика могла только загружать данные с HDFS определенных форматов, то постепенно она научилась работать со всеми форматами файлов, таких как ORC и Parquet, подключать файлы как внешние таблицы, а потом и хранить свои данные в ROS контейнерах прямо на HDFS.

В новой версии была проведена значительная оптимизация скорости работы с HDFS, каталогом метаданных и парсингом этих форматов.

Мне кажется, чтобы Вертика могла стать частью Hadoop среды, этого мало. Именно поэтому в новой версии добавили новый тип лицензирования Вертики ... по количеству нод хадупа и возможность строить кластер Вертики прямо на Hadoop кластере.

Как это выглядит:

Идея состоит в том, что Вертика работает прямо в кластере Hadoop, имеет прямой доступ к данным на HDFS и так же хранит свои данные на HDFS. Лицензируется в таком случае кластер Вертики по количеству нод. Менеджеры HPE обещают, что стоимость лицензии будет вкуснее, однако пока мне цена лицензии не известна. Так что поживем, увидим :)

Где Hadoop, там и Spark :) В новой версии добавлена полноценная поддержка работы с Spark. Можно копировать данные из Спарка в таблицы Вертики, можно обратно из Вертики переносить данные в Спарк.

Интеграция с Apache Kafka уже была добавлена с версии 7.2. Однако выяснилось, что есть множество проблем, которые мешают полноценной работе коннектора Вертики с Кафкой. В 8 версии выложены обновленные версии библиотек работы с Кафкой. Я искренне надеюсь, что они закроют все найденные проблемы и народ перестанет открывать кейсы :)

Машинное обучение

Поддержка машинного обучения появилась еще в версии 7.2. Однако оно было "сбоку" -  лежало отдельной библиотекой и не интегрировалось полностью с метаданными Вертики. Видимо "тема пошла", так как в новой версии Machine Learning уже сразу интегрируется в сервер, доступно после инсталляции, наравне со всеми полноценно присутствует в слое метаданных, а функции входят в состав стандартных. Пожелаем же Вертике и дальше развиваться и обучаться в этом несомненно перспективном направлении :)

Всякие фишечки

Фишечек на удивление мало. Видимо фантазия инженеров Вертики наконец то выдохлась. С точки зрения оптимистов, наверное это не плохо - меньше новых фишечек, меньше багов :)

Но все равно в новой версии появились такие интересные вещи, как:

• Функция копирования таблиц COPY_TABLE, которая позволяет зашарить данные одной таблице как часть в другой. Что интересно, потом при изменении данных у каждой таблицы появится разный набор данных. Достигается это за счет общего использования ROS контейнеров между 2 таблицами. Что не менее интересно, для лицензии Вертика посчитает объем для каждой таблицы, даже если данные у обеих таблиц физически хранятся только один раз.
• Для SELECT в секции FROM добавлено ключевое слово TABLESAMPLE, которое позволит вернуть указанный процент части данных в случайном порядке записей.
• Параметр IDLESESSIONTIMEOUT позволит отстреливать сессии, которые долго висят и ничего не делают. Давно мечтал о таком параметре.
• Выпущена новая версия Python API для доступа к Вертике. Это всегда приятно, народу на Питоне работает с Вертикой много.
• Добавлена поддержка мульти язычности для Text Search. Заявляют, что поддерживают разбор текстов даже на азиатских языках. Надеюсь кириллицу они тоже смогли победить.

В заключение

Как и я писал в начале, могу тоже самое написать и в окончание моей статьи - поступательное движение наблюдается в основном на интеграцию с облаками и сервисами. Хочется более подробно узнать про лицензирование "Vertica on Hadoop". Мне кажется это интересным вариантом для задач, где первичная информация собирается на Hadoop, перемалывается и далее загружается в сервер Vertica для дальнейшей работы с помощью его аналитических функций и машинного обучения.

P.S. Очень приятно, что название новой версии FrontLoader созвучно названию нашего продукта доставки данных в Вертику EasyLoader. И не менее приятно, что именно сейчас, когда мы учим наш EasyLoader управлять загрузкой данных между HFDS и Vertica, 8 версия расширила применение Вертики на Хадупе. Так сказать, вовремя :)

С Наступающим Новым Годом!

Уважаемые коллеги, поздравляю вас от лица компании EasyData с наступающим 2018 годом.

Желаю в Новом году всех благ, здоровья и удачи во всех начинаниях и проектах.

В канун Нового Года, наша компания приготовила небольшой подарок. Мы разработали утилиту, которая позволяет с помощью реверс-инжиниринга получить DDL объектов модели БД и сохранить их в виде SQL-файлов, включая возможность хранения физической модели БД в репозиториях любых систем контроля версий,

Описание работы утилиты, документацию и ссылку на скачивание можно получить на нашем сайте: http://easydata.ru/product/sql-reversing-for-vertica/

Пользуйтесь на здоровье :) Команда EasyData надеется на ваши советы и рекомендации в области дальнейшего развития наших программ, позволяющих эффективно работать с Vertica.

Встреча экспертного сообщества BigData 5 июля

Уважаемые коллеги.

5 июля во вторник в 19 часов, недалеко от метро Китай город, в клубе "Экспедиция" состоится тематическая встреча экспертов, работающих с большими данными. Встреча будет прекрасной возможностью поделиться опытом в области построения BigData решений на базе MPP и NoSQL продуктов, а так же обсуждению неудач и проблем, которые возникали на пути старта проектов. Приглашаю архитекторов, разработчиков и аналитиков придти в гости, познакомиться, если еще лично не знакомы, поделиться опытом, если есть, что рассказать и послушать о чужом опыте, если интересно узнать.

Сайт мероприятия:
http://easydata.ru/architect2016/

Для желающих принять участие просьба зарегистрироваться:
https://docs.google.com/forms/d/1TyPTcGqUZR4nQbY1lFOfck1W6AarvYGXlT2QBVnwuTk/viewform?c=0&w=1

Вам обязательно пришлют подтверждение по почте. Мероприятие бесплатное и проводится частным образом самими участниками. Компания EasyData здесь выступает только как координатор и спонсор мероприятия. Помещение комфортное, места должно хватить всем.

Если есть какие то вопросы, их можно задавать тут в комментариях или лично по скайпу и ФБ (ник ascrus).

Новая версия HP Vertica Экскаватор (7.2)

HP Vertica 7.2

В конце октября вышла новая версия HP Vertica. Команда разработчиков продолжила славные традиции выпуска строительной техники BigData и дала кодовое имя новой версии Excavator.

Изучив нововведения этой версии, я думаю название выбрано верное: все что нужно для работы с большими данными у HP Vertica уже было реализовано, теперь же нужно балансировать и улучшать существующее, то есть копать :)

Ознакомиться с полным списком нововведений можно в этом документе: http://my.vertica.com/docs/7.2.x/PDF/HP_Vertica_7.2.x_New_Features.pdf

Я же вкратце пройдусь по наиболее значимым с моей точки зрения изменениям.

Изменена политика лицензирования

В новой версии были изменены алгоритмы подсчета занимаемого размера данных в лицензии: 

• Для табличных данных теперь при подсчете не учитывается 1 байт разделителя для числовых и дата-время полей;
• Для данных в зоне flex при подсчете размер лицензии считается, как 1/10 от размера загруженных JSON.

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

Добавлена официальная поддержка RHEL 7 и CentOS 7

Теперь можно будет разворачивать кластер Vertica на более современных ОС Linux, что думаю должно обрадовать системных администраторов.

Оптимизировано хранение каталога базы данных

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

Доработана интеграция с Apache решениями

Добавлена  интеграция с Apache Kafka:

Такое решение позволяет организовать загрузку потоков в реальном времени через Kafka, где этот продукт будет заниматься сбором данных с потоков в JSON и далее параллельно загружать их в Flex зону хранилища Vertica. Все это позволит легко создавать загрузки потоковых данных без привлечения дорогостоящего ПО или ресурсоёмкой разработки собственных джобов на ETL.

Так же добавлена поддержка загрузки файлов с Apache HDFS в формате Avro. Это достаточно популярный формат хранения данных на HDFS и его поддержки раньше действительно очень не хватало.

Ну и работа Vertica с Hadoop стала настолько постоянным явлением у клиентов, что теперь нет необходимости устанавливать отдельно пакет работы с Hadoop в Vertica, он сразу в нее включен. Не забудьте только перед установкой новой версии удалить старый пакет интеграции с Hadoop!

Добавлены драйвера для Python

Теперь у Python для работы с Vertica есть собственные нативные полнофункциональные драйвера, официально поддерживаемые HP Vertica. Ранее разработчикам на Питоне приходилось довольствоваться ODBC драйверами, что создавало неудобства и дополнительные трудности. Теперь они смогут легко и просто работать с Vertica.

Улучшена функциональность драйверов JDBC

Добавлена возможность в рамках одной сессии одновременного выполнения множества запросов (Multiple Active Result Sets). Это позволяет сессии, для построения сложного аналитического запроса с разными секциями, одновременно запустить нужные запросы, которые по мере выполнения будут возвращать свои данные. Те данные, которые еще сессия не забрала с сервера, будут кэшироваться на его стороне.

Так же добавлена функциональность расчета хэш значения полей, аналогичного вызову функции Hash в Vertica. Это позволяет еще до загрузки записей в таблицу хранилища данных, рассчитать, на какие ноды они будут размещены по заданному ключу сегментации.

Расширено управление процессом восстановления нод кластера

Добавлена функциональность, которая позволяет установить приоритет recovery таблиц для восстанавливаемых нод. Это полезно, если требуется самостоятельно сбалансировать восстановление кластера, определив, какие таблицы будут восстановлены в числе первых, а какие лучше восстанавливать последними.

Добавлена новая функциональность механизма резервного копирования

• Можно проводить резервное копирование на локальные хосты нод;
• Можно восстановить из полной или объектной резервной копии выборочно схему или таблицу;
• С помощью функции COPY_PARTITIONS_TO_TABLE можно организовать шаринг хранения данных между несколькими таблицами с одинаковой структурой. После выполнения копирования данных партиций из таблицы в таблицу, они будут физически ссылаться на одни и те же ROS контейнеры скопированных партиций. При изменениях в этих партициях таблиц, у каждой далее появится своя версия изменений. Это дает возможность делать снапшоты партиций таблиц в другие таблицы для их использования, с гарантией, что исходные данные оригинальной таблицы останутся целыми, с высокой скоростью, без затрат на хранение скопированных данных на дисках.
• При объектном восстановлении можно указать поведение при существовании восстанавливаемого объекта. Vertica может его создать, если его еще нет в базе данных, не восстанавливать, если он есть, пересоздать из резервной копии или же создать рядом с существующим новый объект с префиксом в имени таблицы наименования резервной копии и ее даты.

Улучшена работа оптимизатора

При соединениях таблиц методом HASH JOIN, процесс обработки соединения мог занимать достаточно много времени, если обе соединяемых таблицы имели большое количество записей. Фактически приходилось на таблицу внешнего соединения строить хэш таблицу значений и далее сканируя таблицу внутренего соединения, искать хэш в созданной хэш таблице. Теперь в новой версии сканирование в хэш таблице сделано параллельным, что должно в разы улучшить скорость соединения таблиц таким методом.

Для планов запросов реализована возможность с помощью хинтов в запросе создавать сценарии планов запросов: указывать явный порядок соединения таблиц, алгоритмы их соединения и сегментации, перечислять проекции, которые можно или нельзя использовать при выполнении запроса. Это позволяет более гибко добиваться от оптимизатора построения эффективных планов запросов. А чтобы BI системы могли воспользоваться такой оптимизацией при выполнении типовых запросов без требования вносить описания хинтов, в Vertica добавлена возможность сохранения сценария таких запросов. Любая сессия, выполняющая запрос, подходящий по шаблону к сохраненному по сценарию, будет получать уже описанный оптимальный план запроса и работать по нему.

Для оптимизации выполнения запросов с множеством вычислений в вычисляемых полях или условиях, включая like, в Vertica добавлена JIT компиляция выражений запроса. Ранее использовалась интерпретация выражений и это сильно деградировало скорость выполнения запросов, в которых, например, встречались десятки like выражений.

Расширена функциональность проверки целостности данных

Ранее Vertica при описании ограничений на таблицы проверяла только NOT NULL условие при загрузке и изменении данных. Полностью все ограничения PK, FK и UK проверялись только при одиночных DML операторах INSERT и UPDATE, а также для оператора MERGE, алгоритм работы которого напрямую зависит от соблюдения целостности PK и FK ограничений. Проверить же на нарушение целостности значений всех ограничений можно было с помощью специальной функции, которая выдавала список нарушающих ограничения записей.

Теперь в новой версии можно включить проверку всех ограничений для групповых DML операторов и COPY на все или только нужные таблицы. Это позволяет более гибко реализовывать проверки чистоты загружаемых данных и выбирать между скоростью загрузки данных и простотой проверки их целостности. Если данные в хранилище поступают из надежных источников и в больших объемах, разумно не включать проверку ограничений на такие таблицы. Если же объем поступающих данных не критичен, а вот их чистота под вопросом, проще включить проверки, чем реализовывать самостоятельно механизм их проверок на ETL.

Объявление Deprecated

Увы, любое развитие продукта всегда не только добавляет функциональность, но и избавляется от устаревшей. В данной версии Vertica объявлено устаревшим не так много, но есть пару значимых объявлений, о которых стоит задуматься:

• Поддержка файловой системы ext3
• Поддержка pre-join проекций

Оба пункта достаточно критичны для клиентов Vertica. Те, кто давно уже работает с этим сервером, могут запросто иметь кластера еще на старой фс ext3. И так же я знаю, многие, для оптимизации запросов к созвездиям используют pre-join проекции. В любом случае, явной версии удаления поддержки этих функций не указано и время к этому подготовиться у клиентов Vertica есть думаю, как минимум еще пару лет.

Резюмируя впечатления о новой версии

В этой статье перечислена только половина того, что добавилось в Vertica. Объем расширения функционала впечатляет, однако я перечислил только то, что актуально для всех проектов построения хранилищ данных. Если вы используете полнотекстовый поиск, гео-локацию, расширенный security и прочие крутые фишки, реализованные в Vertica, то все изменения по ним вы можете прочитать по ссылке, что я дал в начале статьи или документации по новой версии Vertica:

https://my.vertica.com/docs/7.2.x/HTML/index.htm

От себя же скажу: работая с хранилищами данных большого объема на HP Vertica в десятки терабайт в разных проектах, я оцениваю изменения новой версии очень положительно. В ней действительно реализовано многое то, что хотелось бы получить и облегчить разработку и сопровождение хранилищ данных. 

Интервью по Вертике для Software Development podCASR

Привет. Пообщался с Константином на темы хранилищ данных и HP Vertica. Послушать можно здесь:
http://sdcast.ksdaemon.ru/2014/10/sdcast-10/#more-120

Новая версия HP Vertica: Dragline 7.1

8 августа 2014 года вышла новая версия HP Vertica 7.1. Команда Майкла Стоунбрейкера продолжает утверждать, что работа с большими данными сродни БАМу и продолжает новым версиям выдавать названия с строительной тематикой. Итак, Бульдозером (6 версия) по таблицам данные разровняли, сверху неструктурированными данными во Flex зону приложили (версия 7.0), пришла пора большого Экскаватора повернуть реки вспять. Встречаем версию Dragline 7.1! В этой статье я опишу, что же изменилось в новой версии.

Расширения функциональности проекций

Напомню для тех, кто в курсе и расскажу для тех, кто не знает: проекцией в Vertica называется материализация данных таблицы. Таблица в Vertica это описание структуры таблицы (столбцов), constraints и партиций. А непосредственно данные хранятся в проекциях, которые создаются на таблицы. Проекции чем-то похожи на индексы, они хранят данные по всем или не всем столбцам таблицы. Может быть более одной проекции на таблицу, проекции могут хранить отсегментированные и отсортированные данные по разным правилам. Данные во всех проекциях автоматически обновляются при обновлении записей таблицы. Фактически проекции содержат данные таблицы полностью всех колонок или частично определенных колонок. Жертвуется дисковое место серверов кластера, но значительно ускоряются выборки для разных групп запросов.

Выражения в проекциях

До новой версии в проекциях можно был указать исключительно только колонки таблицы. Это накладывало определенные ограничения на использование проекций. Например, если в запросах часто в фильтрации использовалось выражение по колонкам таблицы, поиск по этому фильтру не был максимально эффективным за счет того, что в проекции не было возможности указать сортировать хранимые данные по выражению. Сортировка же по столбцам выражения вряд ли помогла повысить производительность. Это могло вылиться в достаточно серьезную проблему. В качестве решения потребовалось бы добавить в таблицу новую колонку, в которую можно сохранять результат вычисления. Так же потребовалось изменить алгоритм загрузки в эту таблицу данных первоисточников, чтобы во время загрузки заполнять вычисляемый столбец. Так же пришлось бы перегружать всю таблицу, чтобы заполнить добавленное поле. Если в таблице десятки и сотни миллиардов записей и в нее идет постоянная загрузка, такое решение физически было бы невыполнимо.

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

CREATE PROJECTION sales_proj (sale_id, sale_count,  sale_price, sale_value) AS
  SELECT sale_id, sale_count, sale_price, sale_count * sale_price
  FROM sales 
  ORDER BY sale_count * sale_price
  SEGMENTED BY HASH(sale_id) ALL NODES KSAFE 1;

Следующий запрос к созданной проекции таблицы:

SELECT *
FROM sales_proj_b0
WHERE value > 1000000
ORDER BY value;

при выполнении фактически моментально отдаст результат, используя сортировку выражения.

На такие проекции накладываются следующие ограничения:

• Нельзя использовать функции, которые могут изменить результат (например функцию TO_CHAR, так как она вернет разный результат в зависимости от выставленной кодировки клиента)
• Нельзя использовать служебные мета функции
• Нельзя обновлять записи таблицы оператором MERGE (UPDATE и DELETE разрешены)

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

Top-K проекции

Это новый тип проекций в Vertica. Задача таких проекций максимально ускорить выполнение TOP запросов по фактам. Приведу простой пример, допустим нужно часто контролировать пять последних показаний счетчиков:

SELECT meter_id, reading_date, reading_value FROM ( 
   SELECT meter_id, reading_date, reading_value, ROW_NUMBER()
   OVER (PARTITION BY meter_id ORDER BY reading_date DESC) rn FROM readings) sq 
   WHERE  rn <= 5;

Для таблицы с большим количеством записей запрос будет занимать ресурсы и время. Top-K проекции позволяют материализовать и хранить ТОП значений, переместив время вычисления ТОПов с момента выполнения запросов на момент добавления данных в таблицу:

CREATE PROJECTION readings_topk (meter_id, recent_date, recent_value) AS
  SELECT meter_id, reading_date, reading_value 
  FROM readings
  LIMIT 5 OVER (PARTITION BY meter_id ORDER BY reading_date DESC)
  KSAFE 1;

Стоит отметить, что для упрощения получения ТОП значений данных в Vertica синтаксис SQL был специально расширен и запросы к данным можно теперь писать вот так:

SELECT meter_id, reading_date, reading_value 
FROM readings LIMIT 5 OVER (PARTITION BY meter_id ORDER BY reading_date DESC);

Для быстрого обращения к ТОПам счетчиков теперь достаточно написать запрос к созданной проекции таблицы:

SELECT * FROM readings_topk;

Ограничением на данный тип проекций выступает запрет проводить изменение или удаление записей в таблицах, для которых существует такие проекции. Таким образом, этот тип проекций подходит только на таблицы, в которые всегда только добавляются данные (insert only).

При вставке новых записей в таблицу показаний счетчиков созданная проекция будет автоматически обновлять свои ТОП значения:

Живые агрегатные проекции

Тоже новый тип проекций. По аналогии с TOP-K проекциями, этот тип предназначен для материализации данных фактовых таблиц. Задачей данного типа проекций является ускорять простые агрегатные запросы, использующие агрегатные функции COUNT, MIN, MAX и SUM:

CREATE PROJECTION clicks_agg (user_id, page_id, click_date, num_clicks) AS 
   SELECT user_id, page_id, click_time::DATE click_date, COUNT(*) num_clicks 
   FROM clicks 
   GROUP BY user_id, page_id, click_time::DATE;

После создания и обновления этой проекции, в дальнейшем вместо выполнения таких агрегатных запросов на таблицу clicks, можно просто брать данных с проекции, вместо того, чтобы рассчитывать их каждый раз при выполнении запроса:

SELECT user_id, page_id, click_date, num_clicks
FROM clicks_agg;

Ограничением на данный тип проекций выступает запрет проводить изменения или удаления данных на таблицы, для которых были созданы такие проекции. Так же запрещается изменять наименование таблицы, ее колонок и их типов, которые они участвуют в живой агрегатной проекции.

P.S. Обратите внимание, на Top-K и живые агрегатные проекции нельзя при создании указывать сегментацию и сортировку. Они автоматически устанавливаются исходя из GROUP BY запроса проекции. Имеет роль перечисление полей в GROUP BY, так как оно используется для сортировки и сегментации проекции.

Перемещение партиций между таблицами

В идеальном хранилище данные в основном добавляются (факты) и иногда изменяются (измерения). Увы, идеальных хранилищ не бывает. Поэтому операции изменения фактов в хранилище данных достаточно частая и необходимая вещь. Архитектура Vertica ориентирована в первую очередь на сбор данных с множества источников в близком к реал-тайм времени и быстрому выполнению аналитических запросов на больших объемах данных. Для такой архитектуры, изменения и удаления разумных объемов записей для таблиц измерений вполне штатная и быстрая операция для Vertica. Однако, изменение огромного количества записей фактов для Vertica операция, которая может привести к снижению производительности всего кластера, особенно если будет производится часто и необдуманно. Оптимальным выходом здесь можно считать вариант, когда создается две таблицы. В одной таблице хранятся записи активного периода, в который как добавляются, так и изменяются записи. Во второй таблице хранятся записи закрытых периодов, которые уже не могут быть изменены. Такие таблицы затем объединяются в представлении посредством UNION ALL, которое далее используются конечными пользователями. В таком способе проблемой является сам момент закрытия периода, когда требуется перенести записи из активной в историческую таблицы. Делать это запросами INSERT/DELETE в рамках одной транзакции долго и не эффективно, если данных в закрываемом периоде очень много (сотни миллионов или миллиарды). 

В Vertica 7.0.1 появилась функция MOVE_PARTITIONS_TO_TABLE, которая решает озвученную проблему:

SELECT MOVE_PARTITIONS_TO_TABLE ( 'fact_active', 2012, 2013, 'fact_history');

В этом примере переносятся партиции 2012 и 2013 годов из таблицы fact_active в таблицу fact_history. Выполняемая операция атомарная и для пользователей этих таблиц прозрачная. Если пользователь использует представление с UNION ALL на эти таблицы, то даже в момент выполнения запроса при работе данной функции он получит корректный результат. Операция переноса является мало-затратной, так как данные переносятся блоками на физическом уровне ROS контейнеров, а не логических записей.

В новой версии 7.1 появилась функция, которая позволяет поменять местами партиции между двумя таблицами:

SELECT SWAP_PARTITIONS_BETWEEN_TABLES( 'fact_active', 2012, 2013, 'fact_history');

В данном случае записи переносимых партиций таблицы fact_active перенесутся в таблицу fact_history, а записи партиций таблицы fact_history перенесутся в fact_active.

Расширение COPY

К существующей поддержке форматом сжатия BZIP и GZIP добавлен LZO. 
Так же улучшена поддержка распределенной загрузки файлов командой COPY. В версии 6.1 уже была улучшена загрузка файлов путем распараллеливания загрузки файла на узле путем одновременной загрузки файла кусками. Теперь Vertica может распределять части загружаемого файла между несколькими узлами кластера, ускоряя загрузку слишком больших файлов.

Поддержка работы с вложенными массивами и вложенными картографическими данными во Flex таблицах

Достаточно важное расширение, так как работа с JSON структурами уже подразумевает частое использование вложенных массивов. Для решения задач такого круга в Vertica была расширена функциональность парсера загрузки данных из JSON в Flex таблицы и введен ряд функций, позволяющих на лету парсить вложенные массивы и картографические данные в форматах CSV и JSON.

Новые кодировки столбцов проекций

В 7 версии Vertica были добавлены новые типы столбцов long binary и long varchar, позволяющие хранить большие по размерам блобы. Эти столбцы никак не кодировались, хотя просилась возможность их сжатия для экономии дискового пространства и уменьшения дисковых операций. В новой версии для этого добавили типы кодировок BZIP_COMP и GZIP_COMP.

Активные резервные узлы

В новой версии Vertica добавлена возможность подключить к кластеру резервные узлы, которые подключены в кластери и работают, но не хранят данные и не производят никаких вычислений. В случае выпадения сервера из кластера и превышению предела времени его восстановления в кластере, Vertica автоматически переключает резервный узел в активный режим и замещает им сломанный сервер. Резервный сервер переносит на себя все данные, которые хранились на зеркале соседа сломавшегося узла и начинает полноценную работу в кластере. При необходимости администратор может явно указать заменить упавший сервер резервным, не дожидаясь, пока начнется его автоматическая замена. При выборе замещения сервера Vertica будет ориентироваться на описание Fail Group кластера. Если сервера распределены по группам (стойкам), то Vertica будет пытаться найти и запустить резервный сервер, находящийся в одной группе (стойке) с упавшим. Если подходящих серверов не будет найдено или же кластер не разбит по группам серверов, будет взят первый подходящий сервер. После возвращения упавшего сервера, администратор может переключить его обратно в работу кластера. В таком случае резервный сервер отдаст свои данные и перейдет снова в резервный режим ожидания. 

Данная возможность позволяет упростить управление большим кластером, позволяя компаниям перестраховаться от потери производительности при возникающих проблемах с железом и снижая требования к постоянному контролю администраторов по работе кластера.

Поддержка REST API

Появилась возможность через https получать информацию с сервера Vertica по состоянию кластера, лицензии и управлять сервером и перехватывать события. Список функциональности фактически дублирует все, что реализовано в веб консоли Management Console и позволяет при необходимости встраивать управление и мониторинг сервера в собственные системы.

Динамическое перемещение выполняемых запросов между ресурсными пулами

Для тех, кто не в теме — ресурсный пул в Vertica это область ресурсов, имеющая свою память, параметры конкурентной работы и приоритеты. Каждый пользователь привязывается к определенному ресурсному пулу и его запросы выполняются в рамках его пула. Очень часто встречаются ситуации, когда пользователь является приоритетным, его запросы не являются «длинными», но должны выполнятся в максимально короткое время вне зависимости от общей загрузки кластера. В качестве примера можно привести операторов контактных центров (КЦ), у которых на телефоне висят пользователи с проблемами. Операторы должны в хранилище данных в максимально короткий срок получить информацию по работе этих пользователей. Здесь оптимальным является для операторов сделать собственный ресурсный пул с наивысшим приоритетом. Но что делать, если оператору понадобилось просмотреть по пользователю больше информации, чем планировалось? Например, он не смог определить истоки проблемы по информации текущего года и запросил данные прошлых лет. Такой запрос уже не будет «коротким», он займет большее время, оттянув на себя ресурсы пула и место в очереди выполнения, замедлив таким образом общую работу операторов КЦ. В предыдущих версиях Vertica единственным выходом было запрещать оператору выполнять запросы на такой большой объем данных и предлагать ему выполнить запрос под другим логином, который привязан к менее приоритетному и производительному пулу. Здесь уже понятно, что запросив столько данных, оператор и его клиент готовы ждать и моментальное выполнение запроса не ожидается.

В версии 7.1 эта проблема была решена с помощью возможности задать динамическое перемещение выполнения запроса в другой пул при превышении времени выполнения:

CREATE RESOURCE POOL userOverflow RUNTIMECAP '5 minutes';
CREATE RESOURCE POOL user RUNTIMECAP '1 minutes' CASCADE TO userOverflow;
CREATE USER "user1" RESOURCE POOL user;

В этом скрипте создаются два пула, запросы пользователя выполняются в пуле user, однако если они длиться более 1 минуты, то запрос перемещается для выполнения в пул userOverflow, в котором запросу разрешается выполнятся до 5 минут.

Для знающих английский, привожу блок схему работы запросов с пулами:

Обновление Management Console

Веб консоль HP Vertica наконец то была доработана до солидного уровня полноценной утилиты для администраторов. Теперь она позволяет проводить полноценный мониторинг и управление работой кластеров.

Значительно был переработан дизайн и повышено удобство интерфейса:


Появилась возможность отслеживать выполненные, выполняемые и ожидающие в очереди запросы:

Для запросов можно получить статистику их выполнения (профилирование), посмотреть план запроса или прервать работу.

Так же появилась возможность проводить мониторинг работы и администрировать ресурсные пулы, анализировать запросы для построения более оптимальных проекций на таблицы, проводить оценку работы Spread и контролировать общее состояние проекций таблиц в базе данных.

Расширение SQL

В агрегатные запросы добавлена поддержка ROLLUP, а также функции для работы с ROLLUP: GROUPING, GROUPING_ID и GROUP_ID.

Материализация WITH

Не смотря на то, что в Vertica есть временные таблицы, с помощью которых можно оптимизировать выполнение запросов, сохраняя в них промежуточные результаты, не всегда получается их использовать. Например, не каждый BI инструмент умеет поддерживать нюансы работы Vertica и во время работы сложные запросы разбивать на несколько с сохранением промежуточных результатов во временной таблице. Из того, что я знаю, это умеют делать Microstrategy и Tableau, однако вполне возможно, это умеет Oracle BI и другие инструменты BI. Для помощи в оптимизации работы сложных запросов с подзапросами, в Vertica введена поддержка автоматической материализации запросов, описанных в секции WITH для SELECT. Включение и выключение материализации выставляется администратором в опциях базы данных.

Следующий пример в обычном режиме работы дважды будет выполнять агрегатный запрос над одной таблицей:

WITH 
  revenue AS (
      SELECT vendor_key, SUM(total_order_cost) AS total_revenue
      FROM store.store_orders_fact
      GROUP BY vendor_key ORDER BY 1)
-- End defining WITH clause statement
-- Begin main primary query
SELECT vendor_name,
       vendor_address,
       vendor_city,
       total_revenue
FROM vendor_dimension v, revenue r
WHERE v.vendor_key = r.vendor_key AND total_revenue = (
SELECT MAX(total_revenue)
FROM revenue)
ORDER BY vendor_name;

Если включить опцию материализации WITH, то сервер Vertica автоматически создаст сессионную локальную временную таблицу, сохранит в нее результат запроса revenue из секции WITH и выполнит главный запрос, используя эту временную таблицу вместо подзапроса.

Хранение данных сервера на HDFS в Apache Hadoop

До текущего версии данные сервера могли хранится только на локальных дисках его серверов. Достаточно часто встречается ситуация, когда в хранилище находятся данные, которые обязательно нужно хранить, но которые достаточно редко используются пользователями. Не самое лучшее решение занимать такими данными дорогостоящее место на быстрых локальных дисках серверов. 

Для этой цели в версии 7.1 ввели возможность хранить редко используемые данные в Apache Hadoop HDFS. Как и с другими дисками, появилась возможно зарегистрировать директорию HDFS как STORAGE и использовать ее для хранения ROS контейнеров, как полноценный дисковый массив. Есть несколько вариантов перемещения редко используемых данных на HDFS:

• Создать аналогичную таблицу с размещением на подключенном HDFS источнике и переносить в нее данные партиций с помощью функции MOVE_PARTITIONS_TO_TABLE
• Выставить для таблицы политику хранения данных с помощью функции SET_OBJECT_STORAGE_POLICY, для которой задать автоматический перенос записей на источник HDFS, если ключи партиций записей меньше заданного значения

Оптимизация работы HDFS коннектора

У загрузки данных из HDFS в Vertica ранее имелась проблема с производительностью при получения больших по размеру файлов. Сервер Vertica посылал запрос на чтение файла и если он был распределен между множеством серверов HDFS, то приходилось ожидать, пока он будет собран в единый файл, который потом забирался. Теперь Vertica умеет определять, что файл хранится в распределенном виде и самостоятельно подключатся к серверам, где он хранится, считывая и загружая параллельно все куски файла. Дополнительно коннектор теперь может контролировать скорость получения данных с узла HDFS и в случае падения скорости меньше заданного порога, автоматически переключатся на другой узел, пытаясь с него получить нужные данные с более высокой скоростью.

Полнотекстовые индексы

Впервые в Vertica появились индексы. Изначально архитектура Vertica проектировалась так, чтобы проекции могли более эффективно позволить работать с большими данными, чем это делали бы индексы. И это удалось. Однако прогресс не стоит на месте, появление в Vertica длинных строк (LONG VARCHAR) для хранения массивов текстов, привело к тому, что стал востребованным полнотекстовый поиск по таким полям. Проекция в данном случае является менее эффективным средством работы с текстами, чем полнотекстовые индексы. Помимо индексируемого текстового поля, индекс требует указания уникальных полей, по которому будет собираться возвращаться ключ записи, содержащей заданные в поиске слова. Например, есть таблица t_log, в которой есть уникальное PK поле ID, поле даты-времени записи в лог DATE и текстовое поле TEXT. Создание индекса на эту таблицу будет выглядеть так:

CREATE TEXT INDEX text_index ON t_log (id, text);

Поиск ID записей лога, в которых присутствует слово «WARNING» без учета регистра:

SELECT doc_id, word 
FROM text_index 
WHERE word = TxtIndex.Stemmer(LOWER('WARNING'));

Вывод все записей лога, в которых присутствует слово «WARNING» без учета регистра:

SELECT * 
FROM t_log 
WHERE id IN (
  SELECT doc_id 
  FROM text_index 
  WHERE word = TxtIndex.Stemmer(LOWER('WARNING'))
);

Полнотекстовый поиск может учитывать при поиске похожие значения слов на искомое. Например, для вышеприведенных примеров индексом может быть возвращено слово «WARNINGS».

Поддержка Python 3

Добавлена поддержка Питона 3.3.4 под версию pyodbc 3.0.7

Расширения

Под Vertica отдельно выпущены пакеты расширений:

• HP Vertica Place — пакет работы с геоданными. Содержит множество функций, позволяющих работать с координатами, полигонами, рассчитывать дистанции и размеры объектов, вычислять площади перекрытия и т.д.
• HP Vertica Pulse — пакет для полноценного семантического анализа текстов. К сожалению, поддерживается только английский язык, поэтому для нашей страны этот пакет скорее всего не пригодится.

Резюме

Новая версия получила достаточно внушительный пакет изменений. Радует, что разработчики не зацикливаются на маркетинговых фишечках и чувствуется, что развитием продукта управляют сами клиенты, требованиях которых и формируют направление развития. Как архитектор компании EasyData по проектам работы с Vertica, могу сказать из личного опыта, что новая версия покрывает почти все пожелания наших проектов и наших клиентов. Так же чувствуется мощное движение по направлению дальнейшей интеграции с Hadoop, продолжение развития принципов нулевого администрирования на сверх больших кластерах серверов и непрерывную оптимизацию хранения и доступа к сверх большим данным. Отчетливо чувствуется дыхание Facebook, корректирующего развитие Vertica на своем кластере и объемах, не думаю, что в мире так много компаний, кого волновали бы вопросы управления тысячами серверов и петабайт данных. В любом случае нововведения очень полезны в наших текущих и будущих проектах, надеюсь Vertica не сбавит темпов и продолжит свое мощное непрерывное развитие учитывая задачи клиентов, а не в угоду маркетологам.