DTS в SSIS: переезжаем вместе с клиентом с SQL Server 2000 на 2005

Когда в июле мы перевели первого клиента с SQL Server 2000 на 2005, всё прошло в целом нормально - движок встал, 1С заработала, производительность подросла. Но один вопрос тогда тихо отложили на потом: ночные загрузки данных. Там крутилось несколько пакетов DTS, и они продолжали работать через режим совместимости - SQL Server 2005 умеет запускать старые DTS-пакеты, пока установлен соответствующий компонент. Формально работает. Но это не переезд, это костыль.

В ноябре клиент попросил добавить несколько новых потоков загрузки, и стало очевидно: дорабатывать DTS в 2006 году - значит тащить с собой наследие, которое всё равно придётся переписывать. Решили сделать миграцию сразу, пока пакетов ещё не слишком много.

Что было в наследстве

У клиента набралось восемь DTS-пакетов. Назначение типичное для торговой компании: выгрузка из учётной системы в аналитическую витрину, трансформация справочников, агрегации в несколько промежуточных таблиц и финальная загрузка в таблицы фактов. Запуски - ночью по расписанию через SQL Server Agent.

Пакеты делились на две группы довольно чётко:

• Простые - переливка из источника в приёмник с минимальной логикой: переименование полей, простые преобразования типов, иногда lookup по справочнику. Таких было пять.
• Сложные - там внутри была логика на ActiveX Script: кастомные трансформации, условные ветвления, обработка ошибок с записью в лог-таблицу, один пакет дёргал COM-объект для генерации отчёта. Три штуки.

Мастер конвертации: честный разбор

В SQL Server 2005 есть Migration Wizard для DTS-пакетов. Запускаешь, указываешь исходный пакет - он пытается собрать аналог в SSIS. Для простых пакетов это работает. Из пяти простых мастер нормально сконвертировал четыре - открыли в Business Intelligence Development Studio, проверили маппинг полей, прогнали тестово. Один пакет мастер тоже сконвертировал, но с ошибкой в маппинге типов: в источнике был varchar(50), в приёмнике - nvarchar, и мастер не учёл collation. Поправили руками за десять минут.

Три сложных пакета мастер честно сконвертировал в заготовки, но ActiveX Script внутри превратился в Script Task с предупреждением: «код перенесён как есть, требует ревизии». И это корректное поведение - VBScript из DTS в SSIS работает иначе, доступ к переменным пакета другой, объектная модель поменялась. Запустить «как есть» не получилось ни у одного из трёх.

Переписываем вручную

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

SSIS устроен принципиально иначе, чем DTS. В DTS «шаг» - это просто задача, связи между задачами определяют порядок выполнения. В SSIS есть два уровня: Control Flow (управление потоком выполнения) и Data Flow (трансформация данных). Данные идут через компоненты внутри Data Flow Task, а логика запуска, ветвления и обработки ошибок - в Control Flow. Это разделение сначала кажется избыточным, но быстро становится понятно зачем: Data Flow умеет работать с данными параллельно, буферизовать строки, и никакого VBScript в критическом пути нет - есть нормально типизированные компоненты.

Логику, которая в DTS жила в ActiveX Script, переписали на Conditional Split, Derived Column и Script Component там, где без кода не обойтись. Обработку ошибок переделали через Error Output - стандартный механизм SSIS, который перенаправляет плохие строки в отдельный поток, а не падает весь пакет. Запись в лог-таблицу заменили на встроенный Event Handling в SSIS.

COM-объект для генерации отчёта убрали совсем - оказалось, что отчёт давно никто не смотрел, и клиент не возражал.

Что получилось по итогу

Все восемь пакетов работают в SSIS. Ночные загрузки прошли три цикла без инцидентов. Из наблюдений по существу:

Читаемость. DTS-пакеты открывались в Designer 2000, и разобраться в чужом пакете было то ещё удовольствие: связи между шагами, ActiveX-скрипты, всё в одной плоскости. SSIS с разделением на Control Flow и Data Flow читается значительно проще - видно, что происходит с данными, отдельно от того, в каком порядке запускаются задачи.

Обработка ошибок. В DTS типичная стратегия - «упал шаг, весь пакет упал». В SSIS можно настроить поведение на уровне каждого компонента: перенаправить ошибочные строки, продолжить выполнение, залогировать. Для загрузки данных из нескольких источников это принципиально.

Режим совместимости закрыт. Компонент DTS Runtime можно снести - мы это сделали после финального теста. Меньше зависимостей, меньше вопросов при следующем обновлении.

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

Если ваша аналитическая загрузка живёт в DTS и сервер уже переехал на SQL Server 2005 - это хороший момент разобраться с витринами данных и ETL по-нормальному, а не откладывать до следующей миграции.