суббота, 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
Идеи, пожелания и помощь в любом виде приветствуются.

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

среда, 6 февраля 2013 г.

Первый запущенный проект HP Vertica в России

Вводная часть

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

В задачи компании входит построение сети 4G по технологии LTE на территории Российской Федерации. Думаю все слышали про беспроводной скоростной интернет Yota. Так вот все, что касается предоставления интернета конечным абонентам, это Yota. А строит сеть для Yota и других операторов предоставления услуг уже Yota Networks. Тысячи базовых станций работают в десятках регионов нашей страны. Каждая станция генерирует большой объем информации: текущая конфигурация работы, статистика использования каналов и трафика, статистика работы абонентов, данные сессий и многое другое. Для оперативного управления такой сетью требовалось мощная система сбора и анализа данных. Главным требованием к такой системе было обеспечение оперативного сбора и анализа большого количества информации в режиме реального времени. Дополнительным, но не менее важным требованием, стояла задача построить архивное хранилище данных за длительные промежутки времени с возможностью быстрого поиска и анализа информации по неизвестным заранее критериям, то есть выполнению ad-hoc запросов. В идеале, эти требования должны были совместиться в виде единого централизованного хранилища данных.

В результате выбора между HP Vertica, IBM Netezza и EMC GreenPlum, компания Yota Networks выбрала решение Vertica. Не буду вдаваться в подробности выбора — в сфере разработки решений хранилищ данных каждый проект имеет уникальные требования и то, что здесь для проекта мы считали плюсами, может спокойно оказаться для другого проекта минусами и наоборот. Желающие могут прочитать в нашем блоге более подробное обоснование нашего выбора. 

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

Хорошее про Vertica


Колонко-ориентированное хранение

Аналогично другим СУБД такого класса, традиционно это позволяет минимизировать затраты сервера доступа к данным на носителях и ускорить выполнение аналитических запросов за счет чтения значений только тех полей, которые участвуют в запросе.

Автоматическая компрессия данных

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

In-memory область записываемых данных (WOS)

В памяти выделена специальная область. Она позволяет сессиям производить вставку или изменение данных в реалтайм с моментальным COMMIT без ожидания их записи на дисковое пространство базы данных (ROS). Специальный сервис Vertica ToupleMover в фоновом режиме обрабатывает поступающую информацию в WOS, перестраивает в колонко-ориентированный формат хранения, производит компрессию, дефрагментирует и сортирует данные, распределяет их по партициям и записывает конечный результат в область ROS. В итоге скорость вставки данных фантастически возрастает и это позволяет организовывать многопоточную параллельную загрузку непрерывных потоков данных транзакциями в хранилище в реалтайм режиме.

Отсутствие требований ручного тюнинга запросов

Достигается за счет архитектуры MPP, умного оптимизатора, секционирования таблиц, определения сортировки хранения записей в таблицах, созданием к таблицам дополнительных оптимизированных хранимых структур (проекций), распределением нагрузок через пулы ресурсов.

Прочее

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

Капля дегтя в бочке мёда

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

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

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

Отсутствие явного управления сетевыми и дисковыми нагрузками

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

Отсутствие рекомендаций производителя по реализации типовых задач хранилищ данных

В инсталляции Vertica входят демонстрационные примеры структур и данных под различные отраслевые решения, но они простые и не могут служить примером проектирования реальных задач, таких как хранение SDT (Slow Dimension Time) измерений, организация хранения оперативных и архивных областей данных и прочее.

Workload

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

Постскриптум

Выбор хранилища данных дело ответственное и неправильный выбор может критически сказаться на всем проекте. Но хочу заметить - мало выбрать подходящий под требования проекта сервер хранилища данных, не меньшую роль для успешной реализации проекта играют инструменты аналитики и загрузки данных. Под задачи данного проекта были выбраны продукты, о которых так же мало слышали в нашей стране, как и о Vertica - это Talend DataIntegrator (ETL) и Tableau (BI). Каждый из них обладают рядом очень интересных возможностей, о которых в нашем блоге я постараюсь как нибудь рассказать.

На этом пока все, до свидания и до новых статей!