1.1, trdm (ok), 09:20, 18/05/2009 [ответить]
| +/– |
Сижу и думаю: а нафига эта штука вообще нужна?
| |
|
2.2, ditansu (??), 09:44, 18/05/2009 [^] [^^] [^^^] [ответить]
| +/– |
IMHO, например, для того чтобы использовать как ядро для процесса миграции данных из одинаковых по назначению систем (CRM, биллинг и т.п.) но имеющие разную семантику данных. Что требует по мимо простого извлечения/загрузки еще и преобразование. Например, в одной БД адрес включает и город и улицу в целевой БД есть отдельные поля для этих значений. Пишешь правило /формулу для преобразования которое сплитит эти поля и все. По традиции по ссылки не ходил, сужу по тому что написано здесь. И это описание мне очень напоминает функционал Enterprise Service Bus где тоже есть поддержка шаблона ETL.
| |
|
3.3, uZver (ok), 11:50, 18/05/2009 [^] [^^] [^^^] [ответить]
| +/– |
> И это описание мне очень напоминает функционал Enterprise Service Bus где тоже есть поддержка шаблона ETL.
че то байда. ESB это постоянно работающий процесс преобразующий данные на лету (on-line) и идет ESB прокидывает данные до их сохранения в БД.
А ETL это процесс выгрузки-загрузки работающий с большим объемом данных, часто в ночное время (off-line). Работает по данным уже сохраненным в БД.
Они ортогональны по принципу работы, но взаимозаменяемы. ESB позволяет получить результат сразу в отличии от ETL.
| |
3.5, Andrej Svininykh (ok), 15:28, 18/05/2009 [^] [^^] [^^^] [ответить]
| +/– |
Да ETL в некотором роде один из элементов построения ESB. В случае PDI: Kettle это один из элементов системы The Pentaho BI Project. Однако реализованные в программе возможности позволяют использовать её в построении и других систем где необходимо загрузка и преобразование данных.
| |
|
2.4, Andrej Svininykh (ok), 15:16, 18/05/2009 [^] [^^] [^^^] [ответить]
| +/– |
Например для выгрузки и обработки данных из множества различных (с разной структурой) Excel файлов, для дальнейшей загрузки в СУБД.
PDI:Kettle рассчитана на работу по обмену данными между различными хранилищами информации. Основная область применения организация обмена между различными системами автоматизации в случаях когда переход к единой системе невозможен.
Пример. Есть Поставщик у которого есть "Система Учёта А", Покупателю он предоставляет накладные в электронном виде. У Покупателя есть "Система Учёта Б" в неё требуется загрузить информацию из накладных. PDI:Kettle необходим для того что-бы для каждого поставщика имеющего различные формы электронных накладных составить схемы обработки. PDI:Kettle можно настроить для работы по расписанию или запускать через скрипт, информация может быть доступна по e-mail, ftp, http и т.д.
| |
|
1.6, Mr.Close (?), 16:49, 18/05/2009 [ответить]
| +/– |
Коллега, если Вы не в курсе "нафига эта штука вообще нужна", то Вам она скорее всего и не нужна. ))) А тем, кто постоянно работает с обменом данными в "промышленных масштабах" объяснять не нужно. В качестве примера - обычный банк, работающий с физлицами... Фактически любая перегрузка данных из одной БД в другую - это ETL-процесс, хотя специальных средств в нем и не используется. )))
Не стоит сравнивать ETL и ESB. Это сильно разные механизмы по устройству и назначению и часто дополняют друг друга. Выбор механизма в каждом конкретном случае сильно зависит от бизнес-задачи и имеющихся ресурсов. Оперативность ESB сильно перекрывается ее ресурсоемкостью. Если все обмены данных проводить по ESB, то вполне реально ее убить вконец. ETL гораздо экономнее к ресурсам, если считать относительно объемов передаваемых данных. Обычно оперативные (транзакционные) обмены между OLTP-системами сочетают с ETL-обменами для отчетно-аналитических систем. А баланс между этими двумя технологиями - задача для хорошего архитектора. ESB и ETL скорее взаимодополняющие, хотя и взаимозаменяемыми могут быть.
Очень хорошая новость - появление opensource ETL-средств, т.к. промышленные брендовые и до кризиса были игрушкой недешевой, а ошибками и ограничениями тоже радуют частенько. А здесь появнляется возможность добавить или исправить в нужных местах функционал. Если будет в моих силах, обязательно посодействую проекту.
| |
|
2.8, Andrej Svininykh (ok), 22:09, 18/05/2009 [^] [^^] [^^^] [ответить]
| +/– |
Кстати интересна возможность использования ETL систем в рамках стандарта Electronic Data Interchange (EDI). А конкретно PDI:Kettle интересно приспособить для обработки/организации электронного документооборота по средствам электронных документов EDIFACT или XML/EDIFACT.
| |
|
1.7, Andrej Svininykh (ok), 21:54, 18/05/2009 [ответить]
| +/– |
Сам работаю с данной системой примерно три месяца, для меня 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, это не финансовый (внедрение, обучение всё равно денег стоить будет), а экономия человеко-часов (не секрет зачастую в компаниях есть люди задача которых переброска цифр из одной таблицы в другую).
Вопрос в другом нужен-ли для такой системы перевод на русский язык. Плюс конечно будет в популяризации данного пакета, но проблема в сложности перевода. И существуют-ли вообще такие системы на русском языке?
| |
|
2.9, upyx (ok), 04:55, 19/05/2009 [^] [^^] [^^^] [ответить]
| +/– |
>Вопрос в другом нужен-ли для такой системы перевод на русский язык. Плюс
>конечно будет в популяризации данного пакета, но проблема в сложности перевода.
Ну дык "на данный момент нет сложившейся русской терминологии в области ETL. Для начала работы по локализации PDI требуется создание определённого круга единомышленников, который и будет создавать (согласовывать) эту терминологию"
Конечному пользователю все равно учить термины. Т.ч. на русском нужна документация: описание принципов работы, пояснения создания схем, примеры и т.п. Перевод интерфейса IMHO бесполезен.
| |
|
3.10, Andrej Svininykh (ok), 07:26, 19/05/2009 [^] [^^] [^^^] [ответить]
| +/– |
>Конечному пользователю все равно учить термины. Т.ч. на русском нужна документация: описание
>принципов работы, пояснения создания схем, примеры и т.п. Перевод интерфейса IMHO
>бесполезен.
Да, документация для PDI: Kettle очень неплоха, одно описание каждого из шагов в модуле Spoon чего стоит (http://wiki.pentaho.com/display/EAI/Pentaho+Data+Integration+v3.2.+Steps). Здесь не только о всём рассказано, но и всё на примерах показано, конечно перевести её задача на порядок большая, чем перевод интерфейса. Но на русском языке документ описывающий работу PDI: Kettle я пока знаю только один (http://www.javaportal.ru/articles/Pentaho_Data_Integration.html).
| |
|
|
|