среда, 18 декабря 2013 г.

Новая версия HP Vertica: Кран № 7

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

  • Поддержка хранения в базе данных неструктурированных данных и их анализа в запросах совместно с реляционными данными БД
  • Более тесная интеграция с Hadoop с поддержкой интерфейсов описания метаданных хранящихся на HDFS файлов Hive
  • Улучшение работы и отказоустойчивости кластеров с сотнями серверов
  • Добавление нового интерфейса быстрого поиск информации по ключу (Key-Value)
  • Расширение клиентских драйверов до поддержки балансировки подключений
  • Оптимизация работы кластера при выходе из строя серверов
  • Оптимизация алгоритмов выполнения запросов
  • Оптимизация алгоритмов загрузки данных
  • Добавление Java SDK для разработки и использования собственных склярных функций, функций трансформации (window функции) и функций парсинга и фильтрации загружаемых данных
  • Улучшение функциональности веб консоли и дизайнера БД


Более подробную информации о всех нововведениях можно прочитать на сайте компании EasyData: http://www.easydata.ru/#!vertica7/c20l6

четверг, 5 декабря 2013 г.

Форум по BigData (Vertica, Hadoop, NoSQL, ...)

Всем привет.

В рамках сотрудничества с широко известным и популярным порталом SQL.RU, было решено открыть на базе форума BigData направления, по которому бы можно было общаться всем, кто работает с технологиями BigData и Vertica в частности.

Приглашаю всех задавать вопросы и делится своими знаниями на этом форуме. Адрес форума:
http://www.sql.ru/forum/nosql-bigdata

Надеюсь мы перейдем из одностороннего моего диалога в блоге на полное общение в рамках форума :) Мой ник на sql.ru такой же: ASCRUS.

Ну а в блоге и на сайте компании EasyData я буду продолжать выкладывать свои статьи и делиться личными впечатлениями и приобретенным опытом.

До встречи на форуме!

среда, 13 ноября 2013 г.

Визуальные инструменты для работы с HP Vertica

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

SQuirreL SQL Client

Сайт:
Достоинства:
Удобный редактор скриптов с подсказкой имен объектов, множество полезных плагинов, возможность импорта-экспорта данных, просмотр связей таблиц, графический анализ полученных данных запроса.
Недостатки:
Нельзя изменять данные таблиц при их просмотре, иногда бывают подвисания, связанные со сборщиком мусора, при сбое возможно нарушение при записи истории SQL команд, что приводит к неправильному функционированию программы.
Резюме:
Легкий open source продукт, с которым можно отлично жить, если не боятся иногда взять в руки напильник. Именно белкой я и пользуюсь для работы с Vertica. Чуть позже в блоге я опишу, как подключить белку к Vertica и удобно организовать работу с сервером. Есть мечта дописать для белки плагин, который позволял бы выполнять ETL операторы GETL прямо в белке, но пока в роадмап это никак не включено.
Скриншоты с сайта:

dbVisualizer

Сайт:
Руководство подключения к Vertica:
Достоинства:
Навороченный мощный интерфейс просмотра объектов базы, поддержка написания макросов.
Недостатки:
Весь полезный функционал (редактирование данных при просмотре в гриде, импорт-экспорт данных и т.д.) уведен в платную коммерческую версию. В платной версии в том числе есть и поддержка просмотра планов запросов, однако Vertica на полноценном уровне генерации DDL скриптов объектов и просмотра планов запросов не поддерживается.
Резюме:
"Белка" по функционалу на фоне бесплатной версии этого продукта однозначно лучше. А коммерческая версия должна обзавестись полноценной поддержкой Vertica, чтобы имел смысл ее рассматривать.
Скриншоты с сайта:

Плагины под Eclipse

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


DBeaver

Сайт:
Мой комментарий:
Один из удобных мощных плагинов, если требуется работать с Vertica из под Eclipse. Правда кое какие баги все таки наблюдаются, как в принципе и со всем open source, так что это нормально.


DBViewer

Сайт:
Мой комментарий:
Старенький, простенький, но работающий плагин. Для простых вещей быстро сделать достаточно годится, чтобы рекомендовать к использованию.

Прочие клиенты

Инженеры Vertica говорили мне, что с сервером очень удачно  будет работать "Toad for Data analysts". Однако возможности проверить это у меня не было. Кто плотно работает с Ораклом и имеет Toad, возможно имеет смысл попробовать поработать с Vertica через этот продукт. Буду признателен, если в комментариях отпишитесь, что из этого вышло.

На этом все, удачи и до связи!

пятница, 25 октября 2013 г.

Вышло обновление HP Vertica до 6.1.3

Всем привет.

На сайте Vertica выложено обновление серверной и клиентской части до версии 6.1.3. Обновление небольшое, но важное: оптимизирована скорость восстановления упавших нод кластера. Так же добавлены новые графики в веб панель администрирования Vertica Console и поддержка MapR для Hadoop Connector.

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

Удачи!

вторник, 17 сентября 2013 г.

Бета версия GETL

Всем привет.

Выложил на SourceForge.net бета версию сборки 1.0.22. Помимо самого JAR пакета GETL там лежат:

  • скриншоты иерархии классов
  • readme с историей изменений, начиная с 1.0.20 версии.
  • user manual на русском (пока в разработке, доступны только начальные главы)
  • небольшая презентация на русском
  • проект примеров использования GETL (после его разворачивания требуется запустить класс init.GenerateData, который сгенерирует все требуемые данные и файл конфигурации для корректной работы кода примеров)
  • библиотеки, требуемые в проекте примеров для запуска (в данном случае там лежит h2database драйвер)
  • компонент поддержки GETL в Talend
Выпуск релиза видимо чуть задержу. Сейчас необходимо добавить в GETL поддержку Excel и Cassandra, поэтому думаю будет правильнее уже с ними релиз выпускать, как функциональность будет расширена и взаимодействие с этими продуктами протестировано в продакшене.

На этом все. Пока и до связи!

вторник, 20 августа 2013 г.

Статья на Хабре "HP Vertica, первый запущенный проект в РФ, опыт полтора года реальной эксплуатации"

Всем привет.

Наконец то я написал и выложил на ресурсе Хабрахабр статью по результатам полутора-годовалой эксплуатации Vertica в компаниим Yota Neyworks. Статья будет полезна архитекторам хранилищ данных, разработчикам ETL/BI решений, системным интеграторам и руководителям ИТ подразделений. В блог статью дублировать не буду, просто дам ссылку на нее:

Удачи  и до связи!

пятница, 9 августа 2013 г.

Подготовка GETL к первому стабильному релизу

Всем привет.

Хорошая новость - работы по созданию базовой функциональности ETL на базе Groovy близятся к завершению. GETL уже достаточно оброс требуемой для ETL функциональностью, избавился от багов и имеет устойчивую архитектуру классов и компонент, что позволило мне начать работы по подготовке к первому релизу prodaction версии на SourceForge.net.

В релиз войдет следующая функциональность:

  • Чтение и запись в следующие источники данных: CSV, JSON, XML, JDBC;
  • Создание, удаление и очистка таблиц для JDBC источников;
  • Отдельные коннекторы для источников РСУБД: H2 Database, MSSQL, MySQL, Oracle, Vertica;
  • Организация потоков копирования данных между источниками с автомаппированием по именам полей и автоматическим приведением типов полей источников и приемников
  • Фильтрация и репликация данных на множество приемников данных;
  • Агрегация данных источника в приемник с возможностью задания правил агрегации;
  • Сортировка данных из источника в приемник;
  • Организация поточного параллельного выполнения логики задач;
  • Работа с конфигурациями в формате JSON, автоматическая загрузка параметров из конфигураций для источников данных и управления потоками;
  • Сбор статистики работы задач;
  • Хранилище промежуточных данных;
  • Ведение лога работы задач;
  • Библиотека функций работы с текстами, датами, файлами, списками, картами и трансформацией данных;
  • Копирование файлов по заданным правилам с хранилищ файлов (локальные диски и FTP);
  • Поддержка собственного языка хранимых процедур для выполнения SQL скриптов с поддержкой переменных, курсоров и условий.
На текущий момент я заморозил дальнейшее развитие GETL с тем, чтобы написать краткое руководство пользователя для быстрого обучения и началу работы с продуктом и выложить его стабильный релиз. После того, как эти работы будут сделаны, работы над GETL продолжатся.

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

Релиз планируется выпустить уже в сентябре. О его выходе я дополнительно сообщу в своем блоге.

Всем удачи!

вторник, 2 июля 2013 г.

Вышел SP2 для Vertica 6.1

Привет.

Недавно вышел новый сервис пак для Vertica, решил вкратце описать, что новенького появилось, попутно прихватив еще новшества первого сервис пака.

Итак первая хорошая новость
Начиная с второго сервис пака, убрали путаницу между Community, Trial и Enterprise версиями. Получался парадокс, где бесплатная Community редакция, которая разрешает развернуть сервер Vertica на 3 нодах и работать с данными объемом до 1 тб сырых данных, скачивалась отдельным дистрибутивом, который по версии отставал от коммерческой редакции. Кто то из пользователей видел в этом происки маркетологов Vertica (типа покупайте коммерческую, получите новые фичи и исправление ошибок), кто то думал, что инженеры ленятся выложить новую версию для бесплатного пользования. На самом деле все было гораздо проще - так как Community редакция появилась не так давно, разработчикам Vertica понадобилось время, чтобы доработать механизм лицензирования. Теперь скачивая Vertica с раздела download , пользователь автоматически скачивает версию с лицензией Community, а для ее перевода в коммерческую версию просто достаточно применить свою купленную лицензию. Так что теперь все пользователи отныне будут в струе новейших изменений и исправлений по Vertica, без проблем скачивая последние версии.

Ну а чтобы уж пользователи Community редакции точно не подумали, что их бесплатность в чем то ущемляют, кроме ограничения кол-ва серверов и объема загруженных данных, им теперь так же доступна для скачивания и установки сервер Management Console, который позволяет организовать веб интерфейс для администрирования и мониторинга кластеров Vertica.

вторник, 11 июня 2013 г.

Взвешиваем базу на Vertica

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

Для начала посмотрим объем дискового пространства на серверах кластера:
SELECT host_name, disk_space_total_mb, disk_space_used_mb, disk_space_free_mb
FROM HOST_RESOURCES
ORDER BY host_name;

Следует обратить внимание, что в возвращаемый занимаемый дисковый объем базой помимо самих данных так же входит их зеркальная копия, размер которой зависит от установленного k-safe. При k-safe = 1, на каждом сервере занимаемый объем полезных данных к зеркальной копии другой ноды будет 50 на 50, при k-safe = 2 это будет 1/3. Так же в этот объем будут входить промежуточные временные данные, которые могут создаваться Vertica на момент выполнения запросов, однако объем их не велик, так что их смело можно не учитывать.

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

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

Итак, с занимаемым дисковым пространством разобрались. Как же узнать, сколько места занимают сами таблицы? Напишем такой запрос:
SELECT
       ANCHOR_TABLE_SCHEMA, ANCHOR_TABLE_NAME,
       Round(Sum(ROS_USED_BYTES) / 1024 / 1024 / 1024, 3)::decimal(12, 3) AS size_gb
FROM COLUMN_STORAGE
GROUP BY ANCHOR_TABLE_SCHEMA, ANCHOR_TABLE_NAME
ORDER BY Sum(ROS_USED_BYTES) DESC;
Результат запроса содержит все таблицы всех схем базы данных, которые были отсортированны по занимаемому физическому пространству на диске по убыванию. В этот объем входят все занимаемые таблицей данные – всех колонок всех проекций таблицы плюс их зеркало на других нодах.
Данный запрос позволит определить наиболее массивные на диске таблицы базы данных. Если они занимаются гораздо больше запланированного вами места, это хороший повод посмотреть на количество проекций таких таблиц и подумать, есть ли возможность сократить их количество, пересоздав проекции, которые более широко охватывали серии различных запросов. Как вариант – можно запустить на данные  таблицы Database Designer, который проанализирует существующие проекции и идущие к таблице запросы и возможно предложит создать меньшее кол-во проекций, удалив текущие.
Разобравшись с физическим хранением, посмотрим теперь на определение занимаемого размера объектов БД в лицензии. Для начала получим информацию по установленной для Vertica лицензии:
SELECT DISPLAY_LICENSE();
В результате будет возвращена дата начала действия лицензии, количество дней, в течении которых сервер будет продолжать сохранять полную работоспособность после превышения лимита лицензии и размер лицензии в терабайтах.
Посмотреть, сколько уже занято размера лицензии можно таким запросом:
SELECT GET_COMPLIANCE_STATUS();
Данные по размеру занимаемой лицензии рассчитываются Vertica раз в сутки. Происходит это после 0 часов. Этот процесс занимает определенные ресурсы, так что, если у вас ночью идет активная загрузка данных, то имеет смысл перенести процесс аудита лицензии на другое время. Делается это с помощью системной функции «SET_AUDIT_TIME».
Если вас интересует подробная информация, как Vertica рассчитывает размер исходных занимаемых в лицензии данных, рекомендую заглянуть в «Administrators Guide», раздел «Managing Licenses», главу «Calculating the Database Size».
Ну и последний штрих - смотрим по интересующим нас объектам, как много у лицензии они отняли. Для этого воспользуемся функцией AUDIT:
SELECT AUDIT('СхемаБД', 'schema');
SELECT AUDIT('СхемаБД.ТаблицаБД', 'table');
Первый запрос вернет размер лицензии, который занимает указанная схема базы данных. Второй запрос вернет размер лицензии, который занимает указанная таблица базы данных.
Если взять выше указанный запрос на определение занимаемого физического пространства таблицами, то получается удобным по нему определить наиболее массивные таблицы и далее на них с помощью функции «AUDIT» просмотреть, сколько лицензии потребили данные таблицы. Так же, при k-safe = 1, можно приближенно вычислить объем занимаемого размера лицензии таблицы по следующей формуле:
РазмерЛицензии = ФизическийРазмерТаблицы * 1.5.

На этом пока все, до новых записей в блоге.

пятница, 26 апреля 2013 г.

Первый event Tableau в России


Привет. Вчера 25 апреля 2013 г. прошел первый евент Tableau в России. Хотел бы поделиться впечатлениями.

Первое, что бросилось в глаза - очень высокий уровень организации евента. Европейцы приехали подготовленными к евенту, демонстрация работы Tableau велась вживую на примерах. После специалистовTableau выступали мои коллеги из Yota, которые рассказали, как в нашей компании запускался Tableau и на реальных примерах продемонстрировали, что сейчас у нас есть. Атмосфера получилась дружеская, без всяких нудных зачиток презентаций, было много шуток и даже подколов, так как на евенте были наши конкуренты из Мегафона, которые нас очень любят за наш оптимизм и креативность и мы, кстати, их тоже за это любим, но дух соперничества, как говорится, никуда не денется. Питание и вино так же были выше всяких похвал. Резюмируя могу сказать, что первый евент Tableau в нашей стране получился просто отличным. Я думаю, здесь главная заслуга в этом партнера Tableau компании АНАЛИТИКА ПЛЮС  -  они все это организовали, продумали выступления, пригласили выступить Yota и главное, пригласили на евент правильных людей. Тех самых, кому действительно интересно BI и кто понимает, зачем BI нужно и почему им жить без него тяжело.

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

Теперь о самом Tableau, как продукте. Как это ни удивительно, но смотрел я его в действии вживую можно сказать в первый раз. До этого с Tableau я знаком был только по трем направлениям:
·         подготавливал kpi и агрегаты, используемые дальше в Tableau
·         подсказывал иногда нашим  специалистам, как лучше написать для Vertica очень хитрый запрос на получение данных
·         видел при мониторинге и профилировании запросов Vertica, что Tableau шлет запросы

Когда наша компания купила Tableau и запустила, первое время я отслеживал его запросы, чтобы убедиться, что он не будет делать ничего криминального на Vertica и не замедлит работу сервера. Убедившись, что этот BI шлет оптимизированные запросы, пользуется во всю расширениями Vertica и хорошо знает особенности этого сервера, я снял с Tableau «наблюдение» и в принципе мое взаимодействие с ним на этом уровне и остановилось. Замечу, это хороший показатель, когда BI активно работает, а архитектор DWH ничего о нем не знает - говорит о том, что BI отлично интегрирован с СУБД.

Теперь же, посмотрев вживую на работу Tableau, я смог оценить его эффективность со стороны анализа больших данных. Что хочу сказать – сама идея Tableau мне кажется верной и удачной. Суть ее в том, чтобы дать специалисту возможность сгруппировать и отобразить в виде визуальных образов, какие данные у него есть, оценить их полезность, понять, как это можно использовать и далее разработать под себя уже набор дашбордов, фильтров и правил, позволяющих автоматизировать свой повседневный анализ и контроль деятельности предприятия. Я бы назвал это визуальным  программированием. Это сильно отличается от того, что я привык видеть в других BI. Специалисты, использующие их, изначально знают, что у них хранится и с помощью каких алгоритмов можно проводить анализ данных, чтобы решать поставленные задачи, если они не знают, то сделать ничего на BI не смогут. На евенте, кстати, как раз наши специалисты из Yota и продемонстрировали, что на момент покупки Tableau у них не было готовых понятий и методик о том, какие данные им нужны и как их правильно использовать, чтобы достичь оптимизации и контроля работы нашей сети и абонентов. И тот же работающий SAP BO не мог им помочь в этом, для него нужно было четкое ТЗ с описанием что делать и IT-отдел, который бы сделал реализацию на BO.

четверг, 11 апреля 2013 г.

Встреча с специалистами HP Vertica в Москве

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

Оптимизация запросов к данным

Одним из вопросом меня интересовало, как Vertica использует при оптимизации выполнения запросов такие вещи, как порядок сортировки столбцов в проекциях и таблицах, а так же сегментирование и партиционирование. В документации указаны только основные моменты по указанию столбцов в сортировке. Что удалось выяснить:
  • Для более эффективного использования сортировки проекций при выполнении запросов требуется придерживаться следующих правил в порядке очередности столбцов сортировки: 
    • Первыми указывать те столбцы, которые фильтруются в запросах по равенству с константой или выражением.
    • Следующими указывать столбцы, фильтр по которым выбираем из множества значений, это может быть как оператор выбора из констант IN так и фильтрация на базе соединения с другим источником, например с помощью EXISTS или IN.
    • Последними следует указывать те столбцы, по которым идут операции больше-меньше-между.
  • Продуманная политика сегментации записей между нодами сервера может давать прирост производительности при выполнении запросов:
    • Для таблиц фактов, имеющих связи один ко многим предпочтительно делать сегментацию по одинаковому ключу записей главной и подчиненных таблиц. Это приведет к тому, что записи главных и подчиненных таблиц будут лежать на одной ноде. При выполнении запросов с соединениями этих таблиц, операции соединения будут выполнены локально на каждой ноде, что минимизирует затраты на выполнение таких операций.
    • Для часто используемых и разумных по объему таблиц измерений имеет смысл зеркалировать такие таблицы на каждую ноду, чтобы уменьшить сетевой трафик при использовании таких таблиц в операциях соединений с фактами в запросах. Здесь критичность этого правила зависит от количества серверов в кластере - чем серверов больше, тем правило актуальнее. Если у вас кластер из 100 серверов, то интенсивный обмен данными по сети между ними может привести к значительному проседанию производительности всего кластера в целом.
  • Партиционирование таблиц ускоряет выполнение OLAP запросов, использующих оконные функции. Здесь получается определенное противоречие с парадигмой хранения данных в Vertica - рекомендуется не делать партиции с частым значением ключей партиции, иначе просто может остановиться запись в хранилище за счет большой дефрагментации таблицы. Например, если партиция по кварталу уже изначально малое количество ключей партиции даже за 10 лет хранения информации, то партиция по кварталу и клиенту приведет к ошибке Vertica большого количества открытых файлов, где TM не будет успевать дефрагментировать куски поступающих данных и станет откатывать транзакции. Здесь идеальным выглядит делать партиции по разумным разрезам - например по дню. Для того, чтобы со временем жизни хранилища, число ключей партиций оставалось в разумных пределах, можно объединять партиции уже старой, не часто используемой информации с помощью функции MERGE_PARTITION.

Временные  таблицы в Vertica

Временные таблицы в Vertica свои данные хранят в RAM. Для меня, привыкшего работать с времянками в Sybase, это стало полной неожиданностью, так как в документации про это я ничего не нашел. Это означает, что с временными таблицами нужно обращаться более аккуратно и продуманно, чем в том же Sybase или MSSQL. Попытка влить в временную таблицу очень большой объем данных может привести к нехватке памяти и увода Vertica в swap. 

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

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

Игры с накопителями

Для увеличения производительности работы Vertica можно определить политику хранения данных и временных файлов Vertica. По умолчанию, данные и временные файлы, создаваемые в ходе работы сервера, хранятся на storage, который хранит базу данных. 

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

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

Что ждать

Лично мне в Vertica не хватает двух вещей - это хранимых процедур на базе SQL синтаксиса с возможностью вернуть результат запроса вызывающей сессии и поддержки Java в виде внешних хранимых процедур. По первому вопросу команда Vertica так и не определилась с своим решением. А вот с поддержкой Java подтвердили, что это будет обязательно. Это уже хорошая новость.

В заключение

В заключении хотел бы сказать само впечатление о специалистах Vertica. Тут самое правильное слово будет - ответственность. Мы за день до встречи подготовили список вопросов, которые хотели бы обсудить и передали вертиковцам. Как они сами признали, вопросы были достаточно сложными, явно не из раздела RTFM, поэтому для ответов на эти вопросы им пришлось серьезно подготовиться. Мужики не стали нам рассказывать, что это не в их компетенции, что они просто приехали давать базовый курс, что наши вопросы не отражены в документации, потому что это не "бестс-практикс" и прочее прочее прочее, что я не однократно слышал от специалистов других компаний, приезжающих к нам в Россию. Просто честно подготовились, ответили и постарались максимально помочь нам понять, что и как можно улучшить и чего нужно избегать. Тоже самое можно сказать о специалистах саппорта Vertica, которые моментально в любое время дня или ночи реагировали на любые наши вопросы и проблемы, выдавая решение или же передавая найденные баги для исправления инженерам. Кстати, из трех обнаруженных мной и заявленных в саппорт багов, они были исправлены в пределах от 2 недель до 1 месяца с момента заявления и фактически закрывались сразу по выходу новой версии Vertica. Исходя из этого, ставлю команде Vertica свою оценку в 5+, так держать ребята :)

четверг, 28 марта 2013 г.

Создаем свой язык в Groovy

Основная проблема императивных языков программирования - их низкая приближенность к естественным языкам.

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

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

// Клиент
class Customer {
    int inn
    String name
    String address
    String phone
}

// Клиенты
class Customers {
    Customer findByInn(inn)
    void add(Customer customer)
}

// Продукт
class Product {
    String article
    String name
    double price
}

// Продукты
class Products {
    Product findByArticle(article)
    void add(Product product)
}

// Заказ
class Order {
    int num
    Customer customer
    List< orderdetail> details = []

    OrderDetail findByPos(pos)
    void add(OrderDetail detail)
}

// Товар заказа
class OrderDetail {
    int pos
    Product product
    def count = 1
    def getSum() { count * product.price }
}

// Заказы
class Orders {
    Order findByNum(num)
    void add(Order order)
}

Сама бизнес логика описания работы будет выглядеть вот так:

// Списки бизнес-сущностей
def customers = new Customers()
def products = new Products()
def orders = new Orders()

// Добавление клиента
customers.add(new Customer(inn: 1234, name: "Клиент", address: "Россия", 
      phone: "+74951002030"))

// Добавление продукта
products.add(new Product(article: "a100", name: "Товар 1", price: 100.00))
products.add(new Product(article: "a200", name: "Товар 2", price: 200.00))

// Добавление заказа
def order = new Order(num: 1, customer: customers.findByInn(1234))
order.add(new OrderDetail(pos: 1, 
   product: products.findByArticle("a100"), count: 1))
order.add(new OrderDetail(pos: 2, 
   product: products.findByArticle("a200"), count: 1))
orders.add(order)

Благодаря изяществу Groovy, код достаточно простой и читабельный. Но и пример не сложный. В реальной жизни, при написании сложной бизнес логики управления объектами, код будет выглядеть громоздко и плохо читаться. Получается, я имею некий API, который управляется только из кода, сложно пишется и нелегко читается.

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

AddCustomer(inn: 1234, name: "Клиент", address: "Россия", phone: "+74951002030")

AddProduct(article: "a100", name: "Товар 1", price: 100.00)
AddProduct(article: "a200", name: "Товар 2", price: 200.00)

AddOrder(num: 1, customer: 1234) {
 Detail(pos: 1, product: "a100", count: 1)
 Detail(pos: 2, product: "a200", count: 1)
}

Такой код вообще не нуждается в комментариях - он имеет высокую читабельность.
Для реализации этого языка потребуется написать билдер на Groovy. У Groovy есть абстрактный класс BuilderSupport, от которого нужно наследоваться, чтобы создать свой билдер. В наследуемом классе потребуется перекрыть ряд методов, которые Groovy будет автоматически вызывать при разборе языка разметки в коде. Вот как будет выглядеть класс билдера:

public class MyBuilder extends BuilderSupport {
 public Customers customers
 public Products products
 public Orders orders

 // Назначение ноде родительской ноды
 protected void setParent(Object parent, Object child) {
 }

 // Создать ноду без параметров
 protected Object createNode(Object name) {
  if (name != "call") 
   throw new Exception("Node required parameters")
  new Node(null, name);
 }

 // Создать ноду с привязанным к ней объектом
 protected Object createNode(Object name, Object value) {
  throw new Exception("Node required parameters")
 }

 // Создать ноду с параметрами
 protected Object createNode(Object name, Map attributes) {
  // Получаем родительскую текущую ноду
  Node parent = getCurrent()
  def result
  
  // Анализируем имя ноды
  switch (name) {
   case "AddCustomer":
    result = addCustomer(attributes)
    break
   case "AddProduct":
    result = addProduct(attributes)
    break
   case "AddOrder":
    result = addOrder(attributes)
    break
   case "Detail":
    if (parent == null || 
     parent.name() != "AddOrder")
     throw new Exception(
      "Detail must be specified with only AddOrder")

    result = addOrderDetail(parent.value(), attributes)
    break
   defailt:
    throw new Exception("Unknown node ${name}")
  }
  new Node(null, name, attributes, result);
 }

 // Создать ноду с параметрами и привязанным к ней объектом
 protected Object createNode(Object name, Map attributes, Object value) {
  throw new Exception("Node ${name} can not support objects")
 }

 // Добавляем клиента
 def addCustomer(Map params) {
  def customer = new Customer(inn: params.inn, name: params.name, 
      address: params.address, phone: params.phone)
  customers.add(customer)
  println "Added customer ${customer.inn}: ${customer.name}"
  customer
 }
 
 // Добавляем продукт
 def addProduct(Map params) {
  def product = new Product(article: params.article, name: params.name, 
      price: params.price)
  products.add(product)
  println "Added product ${product.article}: ${product.name}"
  product
 }
 
 // Добавляем заказ
 def addOrder(Map params) {
  def order = new Order(num: 1, customer: customers.findByInn(params.customer))
  orders.add(order)
  println "Added order ${order.num} from customer ${order.customer.name}"
  order
 }
 
 // Добавляем строку заказа
 def addOrderDetail(Order order, Map params) {
  def count = params.count?:1
  def detail = new OrderDetail(pos: params.pos, 
      product: products.findByArticle(params.product), 
      count: count)
  order.add(detail)
  println "Added into order ${order.num} detail pos ${detail.pos} " +
    "with product ${detail.product.name}"
  detail
 }
}

В этом классе перекрыто два абстрактных метода setParent и createNode. setParent вызывается при назначении дочерней ноде родителя и в моей логике не используется. А вот в createNode как раз и вызывается на каждый элемент разметки. В зависимости от синтаксиса описания ноды разметки, вызывается один из четырех перегруженных методов createNode. Моей синтаксис предполагает, что у элементов всегда есть параметры. Поэтому я прописал необходимую функциональность в нужный метод и добавил исключения во все остальные методы createNode. Это позволит проконтролировать и исключить неправильный синтаксис описания вызова методов. Единственное исключение было сделано для рутовой метки call, которая автоматически создается первой при запуске билдера без параметров. Класс билдера я расширил конструктором, в который передаются созданные объекты списков клиентов, продуктов и заказов. Так же описал в классе методы добавления бизнес сущностей. Ничего сложного - все замечательно видно в коде и по комментариям в нем.

А вот конечный код пользования созданным языком разметки с проверкой результатов:

// Списки бизнес-сущностей
def customers = new Customers()
def products = new Products()
def orders = new Orders()

// Создать объект билдера
def myApi = new MyBuilder(customers: customers, products: products, orders: orders)

// Вызвать билдер
myApi {
 AddCustomer(inn: 1234, name: "Клиент", address: "Россия", phone: "+74951002030")
 
 AddProduct(article: "a100", name: "Товар 1", price: 100.00)
 AddProduct(article: "a200", name: "Товар 2", price: 200.00)
 
 AddOrder(num: 1, customer: 1234) {
  Detail(pos: 1, product: "a100", count: 1)
  Detail(pos: 2, product: "a200", count: 1)
 }
}

// Результаты
println "\n*** Result ***"
println "Customers:"
println customers
println "Products:"
println products
println "Orders:"
println orders

Результат:
Added customer 1234: Клиент
Added product a100: Товар 1
Added product a200: Товар 2
Added order 1 from customer Клиент
Added into order 1 detail pos 1 with product Товар 1
Added into order 1 detail pos 2 with product Товар 2

*** Result ***
Customers:
{inn=1234, name=Клиент, address=Россия, phone=+74951002030}
Products:
{article=a100, name=Товар 1, price=100.0}
{article=a200, name=Товар 2, price=200.0}
Orders:
{num=1, customer=Клиент, 
 detail={pos=1, product=Товар 1, count=1, sum=100.0};
   {pos=2, product=Товар 2, count=1, sum=200.0}}

Все работает :)

Резюмируя можно сказать, что область применения у билдеров большая. Я, например, сейчас на его основе разрабатываю язык описания трансформации данных для своего open source проекта GETL (ETL на базе Groovy). С помощью билдера можно легко разработать синтаксис, который позволит собирать SQL запросы в коде или выводить информацию в иерархическом собственном форматированном виде. Да и штатные XML/JSON маркеры думаю теперь не представляют из себя тайны. Язык разметок можно использовать не только в коде программ на Groovy, но и как блоки описания объектов и действий, которые вынесены в отдельные файлы. Блоки описания можно прямо в runtime считывать из файлов и выполнять с помощью метода EVAL. Так как блоки хорошо формализованы, то для них можно легко написать собственный GUI разработки бизнес логики обычными пользователями.

Примеров можно привести множество. Но самое главное, не стоит забывать - все вышесказанное замечательно без каких либо усилий работает на Java! Никто не мешает в Groovy обвязать любые Java классы и методы своим языком разметки, на котором писать бизнес логику, которая дальше используется в Java приложениях. Эти возможности стоят того, чтобы начать использовать в Java волшебный Groovy :)

Полный код скриптов классов можно скачать отсюда.

вторник, 26 марта 2013 г.

Выложен билд GETL версия 1.0.1 альфа


Привет.

Двенадцать ударных дней (суток) с момента старта проекта принесли победный результат: GETL перестал быть набором абстрактных идей и недо-классов и сегодня был выложен как уже собранная JAR, готовый к использованию:
https://sourceforge.net/projects/getl/files/

Пусть пока и альфа версия, пусть пока в наличии есть Extract и Load, но нет Transform, но уже в базовом функционале уже многое есть, что можно использовать.

Итак на текущий момент эта версия GETL умеет:
  • Работать с CSV файлами: получать список файлов, удалять файлы, получать схемы полей файлов, читать и сохранять записи, осуществлять поддержку всех типов полей с автоматической конвертацией из текста файла в нужные типы, указывать форматирование значений полей для десятичных типов, даты, времени и булевого типа, проверять при чтении поля на заполнение и уникальность, считывать заданное кол-во записей из источника.
  • Работать с JDBC соединениями: получать список объектов БД, получать поля таблицы, считывать записи таблицы или запроса, сохранять записи в таблицы в пакетном режиме через PreparedStatement, считывать заданное кол-во записей с источника с заданного номера записи.
  • Организовывать многопоточный запуск процессов по указанным элементам списка для организации параллельной обработки данных.
  • Копировать данные из источника в приемник: автоматически маппировать поля источника и приемника по их именам, автоматически конвертировать значений полей источника в значения с учетом типов приемника, выполнять пользовательский код для преобразования и трансформации данных из записи источника в запись приемника.
  • Организовать процессинг обработки записей источника кодом пользователя.
  • Организовать процессинг сохранения записей в приемник, генерируемых кодом пользователя.
Для облегчения и универсализации управления источниками данных был разработан класс Dataset, который позволяет описать метаданные и атрибуты источника, содержит описание полей структуры источника. Имеется возможность указать для Dataset свой код обработки  и изменения схемы данных при ее получении при соединении, а так же код проверки записи при чтении данных. Dataset не привязан к типам соединений, его параметры можно сохранять и восстанавливать в конфигурационных файлах. Для удобства использования поверх Dataset созданы классы CSVDataset, TableDataset и QueryDataset, маппирующие основные параметры, присущие этим типам данных как свойства класса.

Так же для организации соединений разработан класс Connection, который так же не привязан к типам источников данных и универсален. Сам Connection при создании требует указать драйвер типа источника данных, на текущий момент в GETL поддерживаются драйвера CSVDriver и JDBCDriver. Для большего удобства использования поверх Connection созданы классы FileConnection и JDBCConnection.

Для работы с CSV файлами был использован open-source продукт SuperCSV. Он полностью покрыл собой работу с CSV файлами, показав отличную производительность и мне осталось только в CSVDriver прописать его использование. От себя я могу только сказать автору огромное большущее спасибо за гигантскую отлично проделанную работу и сказать, что open source это здорово - я себе не представляю даже, если бы я самостоятельно решил в GETL разработать такого уровня работу с CSV файлами, сколько времени и нервов на это бы ушло.

Для работы с JDBC все конечно проще - JDBC уже полностью покрывает собой базовый функционал работы с РСУБД, поэтому разработанные на его основе драйвер JDBCDriver будет теоретически работать с любым сервером, а практически конечно же это придется все постепенно проверять. Греет мысль, что JDBC достаточно строгий и все реализации под него драйверов более менее работают так, как заявлено в спецификации. В дальнейшем будет достаточно наследоваться от этого драйвера под конкретные СУБД и расширять уже под конкретные реализации серверов такую функциональность, как пакетная загрузка файла, создание таблицы, работа с CDC и прочее. Здесь больших трудностей не видно.

Для оптимизации работы использовались такие возможности Groovy, как динамическая компиляций кода на лету, о чем я писал ранее в блоге. Это используется сейчас в копировании данных при сборке автомаппинга с автоконвертацией, а так же при сохранении в JDBC источники через PreparedStatement с использованием пакетных операций.

Таким образом, базовый функционал есть, а для чтения и записи XML и JSON файлов, с учетом того, что они хранят данные в виде иерархий, логичнее всего использовать базовые возможности Groovy, очень мощные и легкие на уровне написания кода. Ну а записать результат чтения таких файлов в CSV/JDBC или же наоборот записать в XML/JSON записи из CSV/JDBC с помощью GETL занимает пару строчек кода и не требует усилий.

Так же в Groovy есть полная поддержка ANT, на котором можно писать управляемые сценарии работы. Здесь я тоже не вижу смысла писать собственные решения по работе с файлами, FTP или архиваторами, апачевский ANT всегда будет мощнее и круче того, что я напишу. Ну а благодаря Groovy, сценарии для ANT на нем писать легко и просто, поэтому такого рода функциональность считаю полностью охваченной штатными средствами.

Сейчас я временно приостанавливаю работы над расширением функциональности GETL, так как он полностью покрыл требования текущих задач, которые на нем необходимо реализовать. Так что можно сказать, он переходит в режим тестирования работоспособности и функциональности и далее в промышленную эксплуатацию на сервере Таленда (для этого я написал компоненту под Talend, позволяющую в его джобах запускать джобы GETL). После окончания выполнения задач, составлю ROAD MAP развития продукта и продолжу его расширять.

В качестве небольшой демонстрации работы с GETL, на SourgeForge в файлах выложены примеры, которые можно запустить как консольные приложения через бат-файл, если установлен Groovy.

P.S. И да - весь код исходников GETL несмотря на то, что уже многое умеет, сейчас весит ... 74 килобайта. Конечно тут есть и моя заслуга - грамотное проектирование иерархий классов и архитектуры никто не отменял. Но в первую очередь это заслуга Groovy, к слову сказать если бы я это стал реализовывать на Java, объем исходного кода был бы больше на порядок в абсолютном понимании этого термина. Groovy это круто!

среда, 20 марта 2013 г.

Vertica 24x7

Привет.

Хочу поделится впечатлениями о том, как Vertica себя чувствует при проведении технических работ по замене или добавлению оборудования.

Задача 1:
Заменить один сервер работающий в кластере Vertica на другой (новый сервер).

Решение:
Много возиться нам не пришлось. На новый сервер поставили Линукс, проверили, что все пакеты установлены, которые Vertica в документации перечисляет как обязательные для работы, запустили утилиту Vertica updateVertica, указали ей новый сервер, чтобы она его прописала как свободный для размещения хост - да и все. Запустили GUI AdminTool Vertica и остановили заменяемый сервер. В кластере стало на один сервер меньше, но кластер продолжил работу, из пользователей никто этого не заметил. Там же в GUI указали, что остановленный сервер заменить на новый из доступных хостов. Vertica самостоятельно установила на него свой дистрибутив, проверила настройки Linux, подправила где что не хватало и запустила новый сервер на работу в кластере. Сервер инициализировался, вошел в статус RECOVERY, синхронизировался с другими серверами кластера, закачав на себя все данные, которые хранил его старый предшественник и включился в работу. В итоге Vertica провела замену сервера за 12 часов, переместив на него порядка 2.5 Тб данных, занимаемых на файловой системе.

Задача 2:
Добавить в кластер два новых сервера.

Решение:
Как и в первой задаче установили Linux, через утилиту добавили новые сервера как хосты. Далее в утилите добавили ставшими хостами сервера как ноды кластера. После добавления утилита предлагает на выбор автоматически сделать балансировку данных для равномерного распределения данных между новым количеством нод в кластере, создать SQL скрипт проведения балансировки для его запуска вручную или самостоятельно  запустить балансировку. Я выбрал самостоятельно. Сервера добавились в кластер, включились в работу и стали принимать и обрабатывать запросы. Так как на них пока попадали только новые загружаемые данные, при выполнении запросов к данным, загруженным до добавления этих серверов, они не могли оказать помощь и всю работу с ними продолжали выполнять только сервера, уже стоявшие в кластере. Когда я был морально и по времени готов, запустить самостоятельно балансировку оказалось делом не сложным, было достаточно просто выполнить запрос: SELECT START_REBALANCE_CLASTER(). Процесс запустился в фоновом режиме и перебирая по очереди таблицы стал перемещать данные уже учитывая распределение по новому количеству нод в кластере. Для таблиц, которые создавались как несегментируемые, Vertica просто создавала их зеркальную копию на новых серверах. Для сегментируемых таблиц заново по каждой записи рассчитывался кэш ключа сегментирования и они перераспределялись по новой карте размещения на кластере на нужные ноды. Весь процесс балансировки занял порядка 1.5 суток, было перераспределено порядка 7.5 Тб данных, занимаемых на файловой системе.

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

Вот такие чудеса :)

пятница, 15 марта 2013 г.

Немного о Tableau

Привет.

Компания интегратор, которая является представителем Tableau в России, опубликовала историю успеха запуска этого BI в нашей компании. Вот ссылка на статью: https://sites.google.com/site/analytikaplus/about/sucess_history/yota-networks

Самое интересное жалко осталось за бортом: на моих глазах наши специалисты, которые ни разу не являются IT шниками и никогда не рисовали сами отчетов, сели за Tableau, которое увидели в первый раз в жизни и накатали под себя сложные аналитические отчеты, о которых давно и долго мечтали, но реализовать их средствами SAP BusinessObjects это была бы целая песня с заявкой, разработкой и прочими сопутствующими вещами. После этого вопрос о том, нужно ли покупать Tableau в нашу компанию даже не стоял, решение было принято единогласно.

четверг, 14 марта 2013 г.

ETL на Groovy - альфа на горизонте


Привет.

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

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

Возможность кодогенерации есть и у других ETL. Например, Talend так же генерирует по описанию job код на Java, который уже максимально ориентирован и оптимизирован под выполнение описанных задач. Однако здесь самый важный нюанс: GETL, в отличие от Talend, и других кодогенерирующих ETL является полностью динамическим. Прямо по ходу его работы можно описывать новые структуры или изменять старые и по произведенным изменениям будет и меняться генерирующийся код обработки данных. В Talend это не возможно - если структура источника данных не совпадает с описанной структурой в job, то необходимо изменять этот job в дизайнере и компилировать его перед запуском. Если же структура источника плавающая, то придется отказаться от штатной функциональности Talend и вручную писать собственный код на Java для обработки таких источников.

Ну а если сказать коротко, то GETL в отличие от других кодогенерирующих ETL, позволит создавать шаблоны для job-ов и использовать их для типовой работы над множеством источников с разной структурой данных. Это на порядки сократит разработку загрузчиков данных. И все это без потери скорости обработки данных!

На текущий момент ведется разработка поддержки GETL источников данных JDBC, XML и JSON. После этого будет собран и выложен альфа релиз продукта, а так же опубликован Road Map дальнейшего развития продукта.

До связи!

суббота, 2 марта 2013 г.

Вышел SP Vertica 6.1.1

Всем привет.

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

Удачных выходных!

пятница, 1 марта 2013 г.

Краш тест Vertica

Привет.

Недавно в боевых условиях я получил полноценный краш тест сервера Vertica.

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

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

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

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

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

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

Тьфу тьфу, чтобы Vertica и дальше продолжала нас радовать такими же чудесами.

До связи!

суббота, 16 февраля 2013 г.

Проект GETL


Привет.

Долго я вынашивал идею разработки open source ETL и вот эта идея стала приобретать очертания. Так зачем же еще один open source ETL? (про коммерческие молчу, еще один там явно не нужен). По моему мнению, все известные мне бесплатные и платные ETL продукты хромают в той или иной мере по трем позициям:

1.    ETL продукты чрезвычайно автономны и самодостаточны. На практике это означает то, что вам очень сложно управлять ETL продуктом из собственной программы и такое управление ограничено возможностями API этого ETL. Так же не менее сложным является использование в ETL Ваших и сторонних решений, приходится писать тучу кода и обвязок, чтобы их подружить. Все это касается и интеграции с системами автоматизированного тестирования. Конечно, современные ETL продукты в том или ином виде поддерживают тестирование, но максимально только на уровне работы самого job. Провести комплексное тестирование частей job или множества job для ETL по заранее заданному плану, интересная, но сложная задача для тестировщика.
2.    ETL продукты очень консервативны по отношению к структурам данных. Они любят заранее определенные структуры данных и очень слабо работают с данными, схемы которых не известны заранее, представляя для работы с ними достаточно ограниченный функционал и накладывая множество ограничений. Ну, а разработка шаблонного job, который производил бы типовые действия над структурами неизвестными на момент разработки это вообще из области фантастики.
3.    Даруя простоту разработки в виде визуальных диаграмм, ETL продукты теряют простоту реализации сложных алгоритмов обработки данных. Ветвление, итерации, сложная многоступенчатая трансформация данных - все это выливается на диаграммах в огромные нечитабельные схемы, внутри которых компоненты диаграмм все равно содержат выражения и алгоритмический код. Приходится много времени тратить на то, чтобы все эти условия и циклы просто правильно соединить на схеме, разбивать на подчиненные задачи, описывая их вызов и передачу параметров, уводить на диаграмме какие-то особенно сложные вещи в свой код.
Сейчас все основные работы по загрузке данных в хранилище я разрабатываю на Talend DataIntegrator. Этот продукт был выбран как наиболее универсальный и позволяющий легко расширять себя до необходимого функционала с помощью разработки собственных библиотек и компонент на Java. Talend имеет внушительный функционал по поддержке различных источников данных и методам работы с данными. Являясь кодогенератором, Talend генерирует по разработанным job код на Java, что обеспечивает отличную скорость обработки данных. Также этот сгенерированный код в виде классов Java можно использовать внутри собственных приложений или контейнера J2EE.

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

Часто получалось, что задачу не представляется возможным реализовать в виде одного job и приходилось часть действий выносить в подчиненные job, вызываемые с основного. Это размазывало логику загрузки и усложняло решение из-за организации взаимодействия таких job и передачей параметров между ними. Когда же дело доходило до обработки иерархических структур, таких как XML или JSON, Talend вообще пасовал, ибо описать на диаграмме загрузку иерархических данных в виде одного входящего потока и множества исходящих как основного и подчиненных просто не возможно. Здесь мне приходилось вообще брать дело в свои руки и писать код на Java, который решал задачи такого уровня.

Отдельно стоит упомянуть обработку ошибок. Да, она есть. Но если у вас сложный процесс и на диаграмме десятки компонент, то для перехвата ошибки у этих компонент требуется в диаграмме вынести от каждого потока или итерации связь перехвата ошибки на блок обработки ошибок. При этом, когда на схеме множество перекрывающих друг друга и компоненты стрелок, ее читабельность стремится к нулю. То же самое касается и документирования схемы job - вы не сможете разместить по ходу диаграммы пояснения, так как она станет слишком громоздкой. Значит, вам придется описывать принципы работы job где-то в отдельном месте и в случае модификации job идти по тексту документации и проверять где и что изменилось.

Вышеописанный поток моих претензий часто в той или иной мере озвучивают многие разработчики ETL при решении задач под разные отрасли. Здесь я просто все обобщил, добавив то, с чем столкнулся сам. Множество из описанного мной было успешно решено на Talend с помощью языка высокого уровня Groovy. Он полностью совместим с Java, но расширяет ее язык функционально, значительно уменьшая объем кодирования и увеличивая его читабельность. Так как Groovy все больше и чаще входит в код моих job, я решил на основе наработок с ним выделить все в отдельный framework на базе Groovy, назвав его GETL (Groovy Extract Transform Load framework). GETL будет возможным использовать как отдельную платформу для разработки job загрузки данных, так и как компонент, работающих в job Talend. Ну, и никто не мешает разработчикам Java интегрировать GETL в свои проекты как модуль и получить в свое распоряжение управляемую функциональность интеграции данных.

Чтобы быть интересным и перспективным для использования, помимо стандартного набора функционала ETL продукта GETL должен:
  • Уметь работать с динамическими и неизвестными на момент разработки структурами, включая исследование метаданных используемых объектов
  • Поддерживать разработку шаблонов загрузки и трансформации данных
  • Обеспечивать проведение автоматизированного тестирования и поддерживать unit test
  • Иметь управляемую многопоточность выполнения процессов
  • Содержать прозрачную иерархию базовых классов для легкого расширения функциональности с помощью собственных классов
  • Предоставить менеджер управления хранилищем временных файлов для проведения промежуточных операций над данными и менеджер хранения повторно используемых данных job на базе РСУБД



Компонентная схема GETL:


GETL не будет визуальным ETL, с поддержкой диаграмм, как это сейчас практикуют все современные продукты интеграции данных. Ему это просто не будет нужно - job будут описываться на базе интуитивно понятного языка Groovy, скрипты будут маленькими и внутри них будет возможно комментировать описанные алгоритмы прямо по месту. Основным плюсом визуальных ETL является упрощение описания правил маппинга, очистки и трансформации данных. В GETL будет возможность описать такие правила в коде job или через визуальный редактор, который сохранит их в области хранения повторно используемых данных, видимых далее в job. Механизм описания и выполнения таких правил будет инновационным и позволит оперировать как известными, так и не известными заранее структурами. Станет возможным описать правила маппинга без привязки к конкретным именам объектов, а так же определить набор правил очистки с определением условий, какое правило применять. Таким образом, GETL позволит описывать job как типовые шаблоны, которые смогут по однажды определенному алгоритму загружать множество разных источников данных. Нужно загрузить 100 справочников как SDT по единой схеме загрузки? Нет проблем – не нужно делать 100 job, достаточно сделать один и описать правила загрузки с учетом отличий справочников. Требуется разработать инкрементный расчет витрин хранилища данных по заданным SQL скриптам? Опять нет проблем - один job с прописанными алгоритмами, который будет можно вызвать для расчета каждой витрины.

Понятно, что GETL не сможет конкурировать с крупными и известными Enterprise продуктами. Но если у Вас нет денег на покупку дорогостоящего решения и обучение специалистов работы с ним или же у Вас нетривиальные задачи, которые не укладываются в просто схему «получил, обработал, загрузил», то, как вариант, можно будет воспользоваться этим решением. Так как я работаю в телекоммуникационной области, GETL будет иметь расширенную функциональность для типовых задач и форматов, применяемых в этой области.

Проект будет вестись по адресу: https://sourceforge.net/projects/getl
Идеи, пожелания и помощь в любом виде приветствуются.

До новых записей в блоге.