Вышел (http://forums.pentaho.org/showthread.php?t=69927) релиз Pentaho Data Integration 3.2.0 (http://sourceforge.net/project/showfiles.php?group_id=140317) (PDI, также называемая Kettle) - компонент комплекса Pentaho отвечающий за процесс Извлечения, Преобразования и Загрузки (Extract, Transform and Load - ETL). Данная система чаще всего используется при работе с хранилищами данных, но так же её возможности позволяют осуществлять:
- Обмен данными между приложениями или базами данных
- Экспорт информации из баз данных в файлы различных типов
- Загрузка массивов данных в базы данных
- Обработка данных
- Интеграция с другими приложениями
Новое (http://sourceforge.net/project/shownotes.php?release_id=682677) в данной версии:- Улучшена визуальная составляющая: реализована цветовое деление с мини-иконками для различных типов переходов, также стала более интуитивной система подсказок.
- Добавлены новые виды этапов обработки и заданий.
- Импортирован этап обраб...URL: http://forums.pentaho.org/showthread.php?t=69927
Новость: http://www.opennet.me/opennews/art.shtml?num=21759
Сижу и думаю: а нафига эта штука вообще нужна?
IMHO, например, для того чтобы использовать как ядро для процесса миграции данных из одинаковых по назначению систем (CRM, биллинг и т.п.) но имеющие разную семантику данных. Что требует по мимо простого извлечения/загрузки еще и преобразование. Например, в одной БД адрес включает и город и улицу в целевой БД есть отдельные поля для этих значений. Пишешь правило /формулу для преобразования которое сплитит эти поля и все. По традиции по ссылки не ходил, сужу по тому что написано здесь. И это описание мне очень напоминает функционал Enterprise Service Bus где тоже есть поддержка шаблона ETL.
> И это описание мне очень напоминает функционал Enterprise Service Bus где тоже есть поддержка шаблона ETL.че то байда. ESB это постоянно работающий процесс преобразующий данные на лету (on-line) и идет ESB прокидывает данные до их сохранения в БД.
А ETL это процесс выгрузки-загрузки работающий с большим объемом данных, часто в ночное время (off-line). Работает по данным уже сохраненным в БД.Они ортогональны по принципу работы, но взаимозаменяемы. ESB позволяет получить результат сразу в отличии от ETL.
Да ETL в некотором роде один из элементов построения ESB. В случае PDI: Kettle это один из элементов системы The Pentaho BI Project. Однако реализованные в программе возможности позволяют использовать её в построении и других систем где необходимо загрузка и преобразование данных.
Например для выгрузки и обработки данных из множества различных (с разной структурой) Excel файлов, для дальнейшей загрузки в СУБД.PDI:Kettle рассчитана на работу по обмену данными между различными хранилищами информации. Основная область применения организация обмена между различными системами автоматизации в случаях когда переход к единой системе невозможен.
Пример. Есть Поставщик у которого есть "Система Учёта А", Покупателю он предоставляет накладные в электронном виде. У Покупателя есть "Система Учёта Б" в неё требуется загрузить информацию из накладных. PDI:Kettle необходим для того что-бы для каждого поставщика имеющего различные формы электронных накладных составить схемы обработки. PDI:Kettle можно настроить для работы по расписанию или запускать через скрипт, информация может быть доступна по e-mail, ftp, http и т.д.
Коллега, если Вы не в курсе "нафига эта штука вообще нужна", то Вам она скорее всего и не нужна. ))) А тем, кто постоянно работает с обменом данными в "промышленных масштабах" объяснять не нужно. В качестве примера - обычный банк, работающий с физлицами... Фактически любая перегрузка данных из одной БД в другую - это ETL-процесс, хотя специальных средств в нем и не используется. )))Не стоит сравнивать ETL и ESB. Это сильно разные механизмы по устройству и назначению и часто дополняют друг друга. Выбор механизма в каждом конкретном случае сильно зависит от бизнес-задачи и имеющихся ресурсов. Оперативность ESB сильно перекрывается ее ресурсоемкостью. Если все обмены данных проводить по ESB, то вполне реально ее убить вконец. ETL гораздо экономнее к ресурсам, если считать относительно объемов передаваемых данных. Обычно оперативные (транзакционные) обмены между OLTP-системами сочетают с ETL-обменами для отчетно-аналитических систем. А баланс между этими двумя технологиями - задача для хорошего архитектора. ESB и ETL скорее взаимодополняющие, хотя и взаимозаменяемыми могут быть.
Очень хорошая новость - появление opensource ETL-средств, т.к. промышленные брендовые и до кризиса были игрушкой недешевой, а ошибками и ограничениями тоже радуют частенько. А здесь появнляется возможность добавить или исправить в нужных местах функционал. Если будет в моих силах, обязательно посодействую проекту.
Кстати интересна возможность использования ETL систем в рамках стандарта Electronic Data Interchange (EDI). А конкретно PDI:Kettle интересно приспособить для обработки/организации электронного документооборота по средствам электронных документов EDIFACT или XML/EDIFACT.
Сам работаю с данной системой примерно три месяца, для меня PDI: Kettle это первая и пока единственная ETL с которой я знаком. Использую пока наверное 5% от её потенциал, кроме задач связанных с синхронизацией для Openbravo POS (источники Openbravo ERP, файлы Excel, файлы выгрузок 1С и Штрих-М), делал схемы для обработки данных из логов АТС (собственный формат log), объединения информации отчётов по гарантийным ремонтам сервисного центра (самые различные виды CVS и Excel). Сначала работал с версией 3.1.0 много было нареканий к стабильности работы (что отмечали многие), начиная с выходом 3.2.0 RC1 нареканий к стабильности работы пока нет.Визуальная составляющая также стала лучше. Вообще мне в PDI: Kettle она больше всего и понравилась, процессный подход больше позволяет концентрироваться на анализе данных, чем на самом механизме работы с ними. Мне конечно сложно судить насколько дружественна среда в случае если с ней будет работать человек с программированием незнакомый (хотя знаний нужны на уровне профессиональной работы с офисным пакетом), но у меня разработка схемы из 5-6 блоков занимает не более 20-30 минут, хотя решаемые этими блоками задачи порой при обработке вручную занимают несколько дней. По этому главный эффект от PDI: Kettle, это не финансовый (внедрение, обучение всё равно денег стоить будет), а экономия человеко-часов (не секрет зачастую в компаниях есть люди задача которых переброска цифр из одной таблицы в другую).
Вопрос в другом нужен-ли для такой системы перевод на русский язык. Плюс конечно будет в популяризации данного пакета, но проблема в сложности перевода. И существуют-ли вообще такие системы на русском языке?
>Вопрос в другом нужен-ли для такой системы перевод на русский язык. Плюс
>конечно будет в популяризации данного пакета, но проблема в сложности перевода.Ну дык "на данный момент нет сложившейся русской терминологии в области ETL. Для начала работы по локализации PDI требуется создание определённого круга единомышленников, который и будет создавать (согласовывать) эту терминологию"
Конечному пользователю все равно учить термины. Т.ч. на русском нужна документация: описание принципов работы, пояснения создания схем, примеры и т.п. Перевод интерфейса IMHO бесполезен.
>Конечному пользователю все равно учить термины. Т.ч. на русском нужна документация: описание
>принципов работы, пояснения создания схем, примеры и т.п. Перевод интерфейса IMHO
>бесполезен.Да, документация для PDI: Kettle очень неплоха, одно описание каждого из шагов в модуле Spoon чего стоит (http://wiki.pentaho.com/display/EAI/Pentaho+Data+Integration...). Здесь не только о всём рассказано, но и всё на примерах показано, конечно перевести её задача на порядок большая, чем перевод интерфейса. Но на русском языке документ описывающий работу PDI: Kettle я пока знаю только один (http://www.javaportal.ru/articles/Pentaho_Data_Integration.html).