Миграция на рабочие места ETL через инструменты ETL
Я хочу разработать логику синтаксического анализа, чтобы задания (графики в AI, отображения в Inofrmatica или Jobs в DS) можно было извлекать в формате xml и переносить в инструменты ETL без повторной перестройки задания / графиков / отображений снова в другой целевой инструмент ETL. Может ли кто-нибудь предоставить какие-либо выводы?
5 ответов
Существует коммерческий продукт под названием AnalytixDS, который утверждает, что поддерживает эту функцию.
Я не использовал его (они наши конкуренты), но у меня нет оснований сомневаться в претензии.
Ну, у меня нет опыта, но.
- Informatica имеет возможность создать полную резервную копию репозитория (это двоичный файл в своем собственном формате).
- Informatica имеет возможность экспортировать все объекты в формате XML; используя свою собственную модель / определение XML; так что его может быть полезно проанализировать и попытаться "подражать" процессу ETL; воссоздать его для других ETL. Этот процесс может пропустить множество конфигураций, созданных с помощью файлов соединений и параметров (это лучший способ повторно использовать или использовать Informatica в нескольких средах).
Реальная сделка. Отзывы о рабочих процессах и задачах; включая сопоставления, чтобы получить используемые запросы и объекты и попытаться сделать это один за другим. Я предполагаю, что действительно трудно экспортировать и импортировать; скажем, от Informatica к ODI или подобному DataStage "как есть"; поэтому у каждого ETL есть свои исходные определения, логика преобразования и методы загрузки... даже соглашения об именах и способ доступа к данным могут быть непростыми.
Так. Удачи!
- Juan
Давайте поговорим о том, как ETL Tools хранит эту информацию.
Informatica и DataStage являются инструментами "Engine", что означает, что они имеют определенную серверную среду, в которой все метаданные хранятся в нескольких вариантах в базах данных (db2, sql server, oracle) плюс файлы, и прямые вмешательства в него не разрешены для коммерческих нужд. (скажем, вы хотите построить решение на основе этого). В то же время, если вы являетесь клиентом и у вас есть ЛЮБЫЕ проблемы с вашей средой, поставщик решений заметит, что вы делаете прямые вмешательства в метаданные, и вы потеряете свою поддержку.
ODI (старый Sunopsis) хранит всю информацию в репозитории базы данных, которая может быть Oracle, SQL Server, DB2, MySQL, Postgres, и ее "можно" легче обновлять, так как нет файлов. С другой стороны, ODI контролирует все объекты с идентификаторами репозитория, а это означает, что будет очень сложно управлять идентификаторами объектов при прямой вставке метаданных. Даже когда вы пытаетесь использовать экспорт / импорт и SmartExport/ SmartImport из ODI в ODI сами по себе, иногда мы сталкиваемся с некоторыми проблемами, представьте себе, что это нужно делать извне.
Интеграция данных Talend хранит всю свою метаду, используя Файлы (Open Studio) и Файлы + База данных (Enterprise Edition).
Принимая это во внимание, ваше решение должно было бы: уметь читать все типы баз данных, поддерживаемых каждым инструментом ETL, и способность переводить каждую модель метаданных из каждого инструмента, также учитывая, что разные версии ETL одного и того же инструмента имеют изменения метаданных.
Есть и другие вещи, которые следует учитывать.
1) Сторонние инструменты: Практически во всех проектах ETL используется множество сторонних драйверов, плагинов, JAR-файлов, EXE-файлов, сценариев оболочки и PowerShell, внешних программ, функций, хранящихся в базах данных. Все эти объекты необходимо учитывать при выполнении миграции ETL.
2) Специфичные для проекта методы и правила. Существует множество проектов, в которых инструменты BI хранятся в соответствии с ИТ-управлением. Это означает очень жесткие процедуры для развертывания объектов ETL. Даже если вы быстро переведете все задания ETL, такой сценарий обязательно придется пересмотреть. Также ваше решение должно соответствовать всем корпоративным правилам.
3) Особенности проекта по архитектуре данных между различными инструментами. Проект ETL при использовании DataStage - это совершенно другая вселенная, чем проект, использующий ODI. Эти инструменты имеют философские различия практически во всем. DataStage стремится сделать все за пределами базы данных, а ODI стремится сделать все внутри базы данных. То же самое происходит между ODI и Talend, Informatica и ODI и т. Д.
Вывод заключается в том, что это невозможно сделать без необходимости делать то, чего вы пытаетесь избежать: много и много работы.
Выбирайте свой инструмент ETL с умом и лучше всего: определите хорошие процедуры и хорошие стратегии, которые помогут избежать больших трудностей при переходе на инструмент ETL.
ура
В большинстве хранилищ данных, над которыми я работал, нам удалось найти список общих процессов, которые вы выполняете большую часть времени, и сгенерировать сценарии, которые могут принимать параметры и запускать их.
Например, вы можете создать шаг извлечения, который принимает в качестве параметров исходную базу данных, таблицу и столбцы и записывает их в определенное место. Если вы решите перейти на другой инструмент ETL, вы можете просто сгенерировать эту программу извлечения в другом инструменте ETL вместо того, чтобы создавать все с нуля.
С большой работой это может быть возможно... но когда одна из этих систем меняет формат своих извлеченных файлов обратно на чертежную доску. Жонглирование слишком большим количеством тарелок на мой вкус