Привет.
Двенадцать ударных дней (суток) с момента старта проекта принесли победный результат: 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 это круто!
Так же в Groovy есть полная поддержка ANT, на котором можно писать управляемые сценарии работы. Здесь я тоже не вижу смысла писать собственные решения по работе с файлами, FTP или архиваторами, апачевский ANT всегда будет мощнее и круче того, что я напишу. Ну а благодаря Groovy, сценарии для ANT на нем писать легко и просто, поэтому такого рода функциональность считаю полностью охваченной штатными средствами.
Сейчас я временно приостанавливаю работы над расширением функциональности GETL, так как он полностью покрыл требования текущих задач, которые на нем необходимо реализовать. Так что можно сказать, он переходит в режим тестирования работоспособности и функциональности и далее в промышленную эксплуатацию на сервере Таленда (для этого я написал компоненту под Talend, позволяющую в его джобах запускать джобы GETL). После окончания выполнения задач, составлю ROAD MAP развития продукта и продолжу его расширять.
В качестве небольшой демонстрации работы с GETL, на SourgeForge в файлах выложены примеры, которые можно запустить как консольные приложения через бат-файл, если установлен Groovy.
P.S. И да - весь код исходников GETL несмотря на то, что уже многое умеет, сейчас весит ... 74 килобайта. Конечно тут есть и моя заслуга - грамотное проектирование иерархий классов и архитектуры никто не отменял. Но в первую очередь это заслуга Groovy, к слову сказать если бы я это стал реализовывать на Java, объем исходного кода был бы больше на порядок в абсолютном понимании этого термина. Groovy это круто!
Комментариев нет:
Отправить комментарий