Блог

Я много работал с Pentaho PDI, поэтому некоторые очевидные вещи бросаются в глаза.

С этого момента я буду называть менеджеров подключений «CMS».

Очевидно, Project CMs> Package CMs для расширения / повторного использования. Кажется, действительно редкий случай, когда вам нужен CM уровня пакета.

Но мне интересно узнать другую лучшую практику. Должен ли каждый проект CM сам по себе состоять из переменных? (или параметров, я думаю).

Давайте поговорим в конкретных терминах. Существуют определенные источники базы данных. Давайте назовем два из них используемыми Finance2000 и ETL_Log_db. У них есть определенные строки подключения (пароль, источник и т.д.).

Теперь, если у вас есть 50 пакетов, извлекаемых из Finance2000, а также с использованием ETL_Log_db … что ж … что произойдет, если базы данных изменятся? (хост, имя, пользователь, пароль?)

Допустим, теперь это Finance3000.

Ну, я думаю, вы можете зайти в Finance2000 и изменить источник, спецификации и даже само название — тогда все должно работать, верно?

Или вам следует просто создать базу данных уровня проекта с именем «FinanceX» или что-то еще и сделать ее состоящей из параметров, чтобы строка connectoin была чем-то вроде @Source @ credentials @ whatever?

Или это просто избыточно?

Я вижу одно из преимуществ метода параметров в том, что вы можете изменять «базу данных ведения журнала» на лету даже внутри самого пакета во время выполнения, вместо того, чтобы передавать параметры просто во время выполнения. Я думаю. Я не знаю. У меня пока нет большого опыта работы с SSIS.

SSIS, начиная с версии 2012, имеет базу данных каталога SSIS. Вы можете создать все свои 50 пакетов в одном проекте, и все эти пакеты используют одни и те же менеджеры подключений проекта.
Затем вы развертываете этот проект в каталоге SSIS; Проект автоматически предоставляет параметры диспетчера соединений с префиксом CM. Параметры CM являются частями определения диспетчера соединений.

В каталоге SSIS вы можете создавать так называемые Среды. В среде вы определяете переменные с именем и типом данных и сохраняете их значение.
Затем — самая интересная часть — вы можете связать Среду и загруженный проект. Это позволяет вам привязать параметр проекта к переменной окружения.

При выполнении пакета — вы должны указать, какую среду использовать при указании Строк подключения. Да, у вас может быть несколько сред в Каталоге, и вы можете выбрать их при запуске пакета.
Круто, не правда ли?
Более того, пароли хранятся в зашифрованном виде, поэтому никто не может их скопировать. Значения этих переменных среды могут быть настроены инженерами службы поддержки, которые ничего не знают о пакетах SSIS.
Более подробную информацию о каталоге SSIS и средах можно найти в MS Docs.

Я поделюсь своим опытом.

Недавно у меня был аналогичный опыт на работе, изменились названия наших 2 основных баз данных, и у меня не было проблем или простоев в расписаниях.

Используемая нами модель не самая лучшая, но по этой и по другим причинам с ней довольно удобно работать. Мы используем BAT-файлы для передачи именованных параметров в задание «Master», и в основном, в зависимости от двух параметров, задание выполняется на альтернативной базе данных / хосте.

Используемая нами модель заключается в том, что в каждом KTR / KJB мы используем переменные $ {host} и ${dbname}, эти параметры передаются с каждым файлом BAT. Итак, когда нам пришлось изменить имена хостов и баз данных, это была простая замена всего текстового соответствия в NotePad , и готово, исправлено более 2.000 BAT-файлов и никаких простоев.

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

Вы также можете использовать файл kettle.properties для подключения к журналу.