Как обрабатывать добавленные столбцы входных данных без необходимости поддерживать несколько версий пакетов служб SSIS?

Question

Я пишу, чтобы получить идеи для решения предстоящей проблемы.

Продукт, который предоставляет данные для нашего процесса ETL, в настоящее время имеет несколько версий. Все наши клиенты используют какую-то версию продукта, но не все используют одну и ту же версию, и они не будут обновлены одновременно.

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

Проблема, которую мы хотим решить, заключается в том, как обрабатывать данные для клиентов, которые используют более старую версию продукта. Если мы не учтем новые столбцы в наших пакетах служб SSIS, данные в этих столбцах для клиентов, использующих более старую версию продукта, не будут обрабатываться.

Чего мы хотим избежать, так это поддерживать отдельную версию пакетов служб SSIS для каждой версии продукта. Кто-нибудь успешно реализовал решение для этой ситуации?

Answer 1

Ну, мне пришлось сделать что-то похожее, когда я получил разные файлы в разных форматах от разных поставщиков, и все они должны были пойти в одно и то же место. Я создал контейнер For Each Loop, который запускается через файлы, и первый шаг цикла определяет путь, по которому он идет. Затем я написал отдельный поток данных для каждого пути.

Вы можете сделать это с таблицей, в которой перечислены ожидаемые столбцы для каждой версии, а затем отправит ее по пути для версии, которой она соответствует.

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

Или вы можете написать новый пакет для каждой версии (включая версию в имени), чтобы избежать наличия 20 разных путей в одном пакете служб SSIS. Затем создайте для каждого цикла в вызывающем пакете служб SSIS, а затем отправьте файл правильной версии. Или просто настройте разные задания для каждого клиента, зная, в какой версии ppackage они находятся. Затем вы можете просто изменить пакет ssis на их рабочие вызовы при обновлении до новой версии.

Answer 2

Похоже, что вы пытаетесь избежать необходимости поддерживать метаданные для всех возможных версий. Решение @ HLGEM хорошо, но все же требует от вас ведения метаданных для всех возможных комбинаций версий.

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

1. Условные разбиения: наиболее очевидное решение, которое хорошо работает, когда имеется несколько вариаций, и простой способ обнаружить разницу на основе нескольких свойств строки. Это плохо масштабируется для управления сложными изменениями, потому что выражения становятся слишком сложными для написания и обслуживания.

2. Преобразования скрипта: если вы читаете в каждой строке как одну строку, то вы можете использовать задачи скрипта, чтобы определить, нужно ли выписывать дополнительные столбцы. Это хорошо работает, когда есть много, много, много разных комбинаций комбинаций полей и правила определения того, какой путь использовать, очень сложны.

3. Метаданные, управляемые таблицами: для одного углового случая, когда я импортировал файлы XML, я создал контрольную таблицу с номерами версий. Я в основном загрузил XML в тип данных XML в таблице, а затем обработал XML в хранимой процедуре. Затем пакет прошел итерацию по каждому номеру версии и динамически сгенерировал SQL, необходимый ему из таблицы, чтобы извлечь правильные узлы из XML, а затем пометил исходную строку как обработанную. Это было хорошим решением для моего процесса, но основная проблема с этим подходом заключалась в том, чтобы знать, когда добавлять новые строки в контрольную таблицу. Я в основном должен был дать группе разработчиков флажок на их формах SDLC, который требовал, чтобы они подписали меня, что я получил новые изменения схемы для основных изменений версии.

Я не уверен, поможет ли вам что-нибудь из этого, но я надеюсь, что вы сможете извлечь из этого что-то полезное. Удачи.