Aposentar o ETL Legado – Migrar Informatica, ODI e Teradata para SSIS/Azure

Posicionamento

Tecnologias de ETL legado como Informatica PowerCenter, Oracle Data Integrator e Teradata foram as ferramentas de trabalho de movimentacao de dados em grandes empresas por decadas. Elas funcionaram de forma confiavel, mas foram construidas sobre infraestruturas que mudaram fundamentalmente desde entao: servidores AIX substituidos por clusters Windows e Linux; bancos de dados Oracle migrados para SQL Server ou Azure; modelos de licenciamento criados numa era em que alternativas baseadas em nuvem ainda nao existiam. O resultado sao sistemas que ainda funcionam tecnicamente, mas se tornaram um fardo organizacional e economico crescente.

Cresci com essas tecnologias. Em um grupo de logistica, operei Informatica PowerCenter 8.6.1 e 9.1.0 em producao: mappings, maplets, workflows, worklets, Workflow Manager e Workflow Monitor, logica de reinicio para execucoes interrompidas, substituicoes SQL em transformacoes Source Qualifier e Lookup, arquivos de parametros para operacao multi-tenant, e a camada de agendamento AIX/KSH/Perl que chamava workflows a cada noite. Conheco os pontos fortes desta arquitetura – e conheco seus limites e custos.

Encontrei o Oracle Data Integrator em um ambiente de seguros, onde interfaces ODI carregavam dados de origem Oracle em tabelas de destino. A filosofia ELT do ODI – executar transformacoes diretamente no banco de dados em vez de em um servidor ETL dedicado – e conceitualmente elegante, mas a camada proprietaria de Knowledge Modules e a dependencia da Oracle tornam dificil operar o ODI economicamente fora de um stack Oracle.

Encontrei scripts BTEQ do Teradata e jobs FastLoad tanto no grupo de logistica quanto em um projeto do setor de saude e assistencia social. Em resumo: BTEQ e uma ferramenta poderosa mas arcaica; FastLoad carrega arquivos flat em tabelas Teradata com velocidade impressionante, mas requer um profundo entendimento do modelo de paralelismo proprio do Teradata.

Contexto de Mercado: Por que a Aposentadoria do ETL Legado e Urgente

Para muitas organizacoes, a questao de aposentar o Informatica PowerCenter ou o Oracle Data Integrator ja nao e mais uma opcao estrategica, mas uma necessidade economica. As licencas do Informatica PowerCenter chegam ha anos a valores anuais de cinco ou seis digitos em euros – e nao diminuiram desde entao. Alem disso vem contratos de manutencao, escalacoes de suporte caras e a necessidade de manter pessoal especializado que saiba operar essas ferramentas.

O Oracle Data Integrator esta vinculado ao stack Oracle. Quem quiser executar ODI sem um banco de dados Oracle enfrenta um problema conceitual: o ODI e arquiteturalmente projetado como uma ferramenta ELT para Oracle. Em organizacoes que buscam reduzir sua presenca Oracle como parte de uma migracao para SQL Server ou Azure, o ODI se torna o motivo para manter a ultima licenca Oracle restante – o que torna as operacoes gerais mais caras, nao mais baratas.

Teradata e a plataforma de dados mais cara do mercado. Para organizacoes que agora executam apenas uma parte de seus dados no Teradata e ja transferiram o restante para SQL Server ou Azure, o bloco restante do Teradata e muitas vezes o maior item de custo unico em toda a infraestrutura de dados. A questao nao e se, mas quando e como aposentar esse bloco.

Consolidacao Tecnologica como Estrategia

Alem dos custos puros de licenca, a consolidacao tecnologica e um objetivo por si so. Organizacoes que executam Informatica, ODI, SSIS, ADF e Teradata simultaneamente tem um problema operacional: precisam de especialistas para cada uma dessas tecnologias, nao podem compartilhar ferramentas e scripts entre equipes, e precisam depurar falhas em quatro paradigmas diferentes. Consolidar em uma unica plataforma – tipicamente SSIS para on-premises e ADF para a nuvem – reduz nao apenas os custos de licenca, mas tambem a complexidade operacional e o esforco de integracao para novos funcionarios.

• Informatica PowerCenter: Eliminar custos anuais de licenca e manutencao
• Oracle Data Integrator: Quebrar dependencia Oracle, unificar o stack
• Teradata: Substituir a plataforma mais cara por SQL Server ou Azure
• Consolidar em SSIS/ADF: Plataforma unica, pool de talentos mais amplo
• Reducao de riscos: Eliminar riscos de fim de vida de versoes antigas
• Introducao de praticas modernas de DevOps: CI/CD, Git, automacao de implantacao

O panorama ETL legado de uma grande empresa tipica: Teradata, Informatica PowerCenter e ODI em infraestrutura AIX – com SSIS/Azure como destino economicamente eficiente. A reducao de custos de licenca e o principal driver de migracao.

Informatica PowerCenter: Expertise Profundo da Pratica de Projetos

O Informatica PowerCenter e um framework ETL completo que vai muito alem de uma ferramenta de integracao de dados. Ele inclui um Repository Service, Integration Service, Reporting Service e o cliente Designer com quatro editores: Source Analyzer, Target Designer, Mapping Designer e Transformation Developer. Trabalhar com o PowerCenter exige um profundo entendimento desta arquitetura para construir solucoes que rodem de forma confiavel, com bom desempenho e reiniciando de forma limpa apos falhas.

Mappings e Transformacoes

Um mapping do Informatica descreve o fluxo de dados de tabelas ou arquivos fonte atraves de transformacoes ate tabelas de destino. Os componentes principais incluem o Source Qualifier (carrega dados fonte e permite substituicoes SQL), Expression Transformation (calcula expressoes por linha), Aggregator Transformation (soma, conta, agrupa), Lookup Transformation (recupera dados de referencia de banco de dados ou cache), Update Strategy (decide insert/update/delete por linha), Router Transformation (distribui linhas para diferentes saidas) e Joiner Transformation (une dois pipelines fonte). O desafio nao e conhecer essas transformacoes, mas usa-las corretamente: um Aggregator com trabalho excessivo coloca no mapping desacelera todo o fluxo de dados; um Lookup Transformation sem cache persistente emite uma consulta ao banco de dados para cada linha.

Workflows, Worklets e Logica de Reinicio

Enquanto mappings descrevem a logica de transformacao de dados, workflows controlam a ordem de execucao: quando cada sessao roda? Quais dependencias existem? O que acontece em caso de falha? Worklets sao fragmentos de workflow reutilizaveis – um conceito analogo a stored procedures para logica de processo. A logica de reinicio e um dos aspectos operacionais criticos: o PowerCenter pode retomar sessoes interrompidas em determinados pontos de recuperacao, desde que as sessoes estejam configuradas para recuperacao. No grupo de logistica, mantive execucoes noturnas onde a configuracao de reinicio era critica – recarregar toda uma sessao com milhoes de linhas nao era uma resposta de erro aceitavel.

O interpretador de linha de comando pmcmd e os arquivos de parametros sao tambem ferramentas operacionais essenciais. O pmcmd permite iniciar, parar e monitorar workflows a partir da linha de comando – permitindo integracao com agendadores externos como Autosys ou scripts simples Perl/KSH. Arquivos de parametros tornam os mappings capazes de operar em modo multi-tenant: em vez de tabelas de origem ou strings de conexao hard-coded, os arquivos de parametros contem valores substituiveis passados em cada invocacao.

# Arquivo de parametros para workflow do Informatica PowerCenter
# Define conexao e parametros de tempo de execucao para o cliente A
# Passado para o workflow na inicializacao via pmcmd

[WF:WF_PEDIDO_CARREGAR]
# Conexao fonte para o cliente atual
$$FONTE_DB_CONEXAO=TERADATA_PROD_CLIENTE_A
# Conexao destino - SQL Server DWH
$$DESTINO_DB_CONEXAO=SQLSERVER_DWH_PROD
# Intervalo de datas para carga delta (formato AAAA-MM-DD)
$$DELTA_DE=2024-01-01
$$DELTA_ATE=2024-01-31
# ID do lote para auditoria
$$LOTE_ID=20240131_A

[SESS:S_PEDIDO_CARREGAR]
# Substituicao SQL no Source Qualifier - carrega apenas o cliente atual
$$SQ_SQL_SUBSTITUICAO=SELECT PEDIDO_NR, PEDIDO_DT, CLIENTE_ID, VALOR, CLIENTE FROM TD_PEDIDO WHERE CLIENTE = 'A' AND PEDIDO_DT BETWEEN TO_DATE('$$DELTA_DE','AAAA-MM-DD') AND TO_DATE('$$DELTA_ATE','AAAA-MM-DD')

# --- Chamada pmcmd do agendador Perl ---
# Inicia o workflow com o arquivo de parametros acima
# pmcmd startworkflow -sv IntegrationService -d Domain -u admin -p <senha> -f Pasta -paramfile ./params/cliente_a.par WF_PEDIDO_CARREGAR

Arquivos de parametros permitem usar o mesmo mapping para diferentes clientes, intervalos de datas ou ambientes (teste/producao) sem modificar o codigo do mapping. O pmcmd integra o PowerCenter com agendadores externos.

Oracle Data Integrator: Conceitos ELT e Estrategia de Migracao

O Oracle Data Integrator difere conceitualmente de ferramentas ETL como Informatica ou SSIS: o ODI segue a abordagem ELT (Extrair, Carregar, Transformar), onde as transformacoes nao ocorrem em um servidor ETL dedicado, mas diretamente dentro do banco de dados de destino. Os dados fonte sao primeiro carregados em areas de staging do banco de dados de destino; la o ODI gera scripts SQL (execucoes de Knowledge Module) que realizam a transformacao. Para cenarios Oracle-para-Oracle isso e elegante; para cenarios de migracao heterogeneos, torna-se um problema.

Conceitos ODI: Interfaces, Knowledge Modules, Datastores

O conceito central do ODI e a interface: uma interface descreve de onde vem os dados (datastore fonte), como sao transformados (expressoes de mapeamento e joins) e para onde vao (datastore destino). Knowledge Modules (KMs) sao templates de codigo reutilizaveis que geram scripts SQL ou PL/SQL concretos a partir da definicao da interface: o Loading Knowledge Module (LKM) carrega dados na area de staging; o Integration Knowledge Module (IKM) executa a transformacao de destino. Para o especialista em migracao isso significa: nao e a interface que precisa ser migrada, mas o SQL gerado que resulta da interface e dos KMs – essa e a logica de transformacao real.

Em um projeto de seguros, encontrei interfaces ODI cujo SQL gerado pelo IKM era altamente especifico do Oracle: instrucoes MERGE com hints NOAPPEND, chamadas a procedimentos PL/SQL dentro da execucao do KM, consultas de hierarquia CONNECT BY e formatacao de datas especifica do Oracle. O destino era uma migracao para SSIS no SQL Server. O desafio nao era entender o conceito ODI, mas traduzir o Oracle PL/SQL em T-SQL equivalente e garantir que a saida fosse identica ao sistema antigo.

-- Logica original: interface ODI com saida Oracle PL/SQL IKM
-- (representacao simplificada do SQL gerado pelo IKM)
-- Fonte: area de staging Oracle (AP$_CONTRATO)
MERGE INTO DWH_CONTRATO TGT
USING (
    -- Transformacao fonte no staging Oracle
    SELECT
        C.CONTRATO_NR,
        C.VERSAO_NR,
        TO_DATE(C.DATA_INICIO, 'YYYYMMDD')  AS DATA_INICIO_DT,
        NVL(C.PREMIO, 0)                    AS PREMIO_EUR,
        DECODE(C.STATUS, '1','ATIVO','0','CANCELADO','DESCONHECIDO') AS STATUS_TXT
    FROM AP$_CONTRATO C
    WHERE C.LOTE_ID = :LOTE_ID
) SRC
ON (TGT.CONTRATO_NR = SRC.CONTRATO_NR)
WHEN MATCHED THEN
    UPDATE SET TGT.PREMIO_EUR  = SRC.PREMIO_EUR,
               TGT.STATUS_TXT  = SRC.STATUS_TXT,
               TGT.DT_ALTERACAO = SYSDATE
WHEN NOT MATCHED THEN
    INSERT (CONTRATO_NR, VERSAO_NR, DATA_INICIO_DT, PREMIO_EUR, STATUS_TXT, DT_CRIACAO)
    VALUES (SRC.CONTRATO_NR, SRC.VERSAO_NR, SRC.DATA_INICIO_DT,
            SRC.PREMIO_EUR, SRC.STATUS_TXT, SYSDATE);

-- Equivalente SSIS/T-SQL apos a migracao:
-- O SSIS Data Flow carrega do staging; o Execute SQL Task executa o MERGE T-SQL.
-- SSIS OLE DB Source carrega do staging SQL Server (populado antes via ADF ou Linked Server)
-- T-SQL MERGE no SQL Server DWH:
MERGE INTO dbo.DWH_Contrato AS TGT
USING (
    -- Consulta de staging no SQL Server
    SELECT
        CONTRATO_NR,
        VERSAO_NR,
        -- Oracle TO_DATE -> T-SQL CONVERT com estilo 112 (YYYYMMDD)
        CONVERT(DATE, DATA_INICIO, 112)           AS DATA_INICIO_DT,
        ISNULL(PREMIO, 0)                         AS PREMIO_EUR,
        -- Oracle DECODE -> T-SQL CASE
        CASE STATUS WHEN '1' THEN 'ATIVO'
                    WHEN '0' THEN 'CANCELADO'
                    ELSE 'DESCONHECIDO' END        AS STATUS_TXT
    FROM dbo.Stg_Contrato
    WHERE LOTE_ID = @LOTE_ID
) AS SRC
ON TGT.CONTRATO_NR = SRC.CONTRATO_NR
WHEN MATCHED THEN
    UPDATE SET TGT.PREMIO_EUR   = SRC.PREMIO_EUR,
               TGT.STATUS_TXT   = SRC.STATUS_TXT,
               TGT.DT_ALTERACAO = GETDATE()
WHEN NOT MATCHED THEN
    INSERT (CONTRATO_NR, VERSAO_NR, DATA_INICIO_DT, PREMIO_EUR, STATUS_TXT, DT_CRIACAO)
    VALUES (SRC.CONTRATO_NR, SRC.VERSAO_NR, SRC.DATA_INICIO_DT,
            SRC.PREMIO_EUR, SRC.STATUS_TXT, GETDATE());

O desafio central da migracao ODI para SSIS/T-SQL: funcoes especificas Oracle (NVL, DECODE, TO_DATE, SYSDATE) devem ser traduzidas para equivalentes T-SQL (ISNULL, CASE, CONVERT, GETDATE). A logica e identica; a sintaxe difere.

Teradata: BTEQ, FastLoad e o Dialeto SQL

O Teradata e uma plataforma de dados construida para consultas SQL massivamente paralelas em volumes de dados muito grandes. Seu modelo de paralelismo – distribuicao automatica de linhas entre nos via Primary Index, execucao paralela de consultas atraves de AMPs (Access Module Processors) – e impressionantemente poderoso, mas requer um entendimento dos conceitos especificos do Teradata: Primary Index, particicionamento, gerenciamento de spool space e criacao de scripts BTEQ.

BTEQ: Scripting em Lote no Teradata

BTEQ (Basic Teradata Query) e a ferramenta primaria de scripting em lote para o Teradata. Ela permite executar sequencias SQL, tratar codigos de erro, exportar e importar dados, e controlar o fluxo de scripts condicionalmente. O BTEQ roda em Unix/AIX, Windows e no proprio console Teradata, e era em muitas grandes empresas o mecanismo primario para processamento em lote noturno antes da introducao de ferramentas ETL dedicadas.

No grupo de logistica, mantive scripts BTEQ que carregavam, transformavam e gravavam dados de programas de bonus e de controle de qualidade em tabelas de relatorios a cada noite. Esses scripts tinham crescido organicamente e nao seguiam nenhuma convencao unificada de tratamento de erros – tipico para ambientes BTEQ. A migracao primeiro exigiu um inventario completo desses scripts, uma analise de dependencias e a traducao em jobs SQL Agent no SQL Server.

.LOGON tdpid/tdusuario,tdsenha;

-- Verifica se uma sessao anterior ainda esta em execucao (tabela de bloqueio)
-- .IF errorcode <> 0 THEN .QUIT 12;

SELECT 'Execucao BTEQ iniciada: ' || CAST(CURRENT_TIMESTAMP AS CHAR(26));

-- Passo 1: Limpar tabela destino (delete de particao em vez de TRUNCATE)
DELETE FROM DWH_PEDIDO_STG
WHERE LOTE_DT = CAST('${LOTE_DT}' AS DATE FORMAT 'YYYY-MM-DD');
.IF ERRORCODE <> 0 THEN .GOTO ERRO_HANDLER;

-- Passo 2: Carregar dados da tabela fonte
INSERT INTO DWH_PEDIDO_STG
  (PEDIDO_NR, PEDIDO_DT, CLIENTE_ID, VALOR_EUR, LOTE_DT)
SELECT
    P.PEDIDO_NR,
    P.PEDIDO_DT,
    P.CLIENTE_ID,
    -- Formato decimal Teradata: evitar ponto como separador de milhares
    CAST(P.VALOR AS DECIMAL(15,2)) AS VALOR_EUR,
    CAST('${LOTE_DT}' AS DATE FORMAT 'YYYY-MM-DD') AS LOTE_DT
FROM PROD_PEDIDO P
WHERE P.PEDIDO_DT = CAST('${LOTE_DT}' AS DATE FORMAT 'YYYY-MM-DD')
  AND P.STATUS_CD NOT IN ('X','S');
.IF ERRORCODE <> 0 THEN .GOTO ERRO_HANDLER;

SELECT CAST(COUNT(*) AS VARCHAR(10)) || ' linhas carregadas.' FROM DWH_PEDIDO_STG
WHERE LOTE_DT = CAST('${LOTE_DT}' AS DATE FORMAT 'YYYY-MM-DD');

.GOTO FIM_SCRIPT;
.LABEL ERRO_HANDLER;
  SELECT 'Erro em LOTE_DT=${LOTE_DT}, ERRORCODE: ' || CAST(.ERRORCODE AS VARCHAR(5));
  .QUIT 99;
.LABEL FIM_SCRIPT;
  .LOGOFF;
  .QUIT 0;

Padrao tipico BTEQ: logon, DELETE seguro antes do INSERT, rotulos de salto condicionais (.IF ERRORCODE / .GOTO / .LABEL), LOGOFF explicito. O padrao de substituicao de variaveis (${LOTE_DT}) e definido pelo wrapper Perl ou KSH que chama o script.

Teradata FastLoad para Carregamento de Arquivos Flat

Enquanto o BTEQ e usado para transformacao SQL e controle, o FastLoad e a ferramenta Teradata para carregamento paralelo de alto desempenho de arquivos flat. O FastLoad ignora completamente o log de transacoes e carrega dados diretamente em tabelas vazias – tornando-o ordens de magnitude mais rapido que carregamentos baseados em INSERT, mas tambem menos flexivel: o tratamento de erros em nivel de linha requer tabelas de erros (tabelas ET). No projeto do setor de saude e assistencia social, mantive jobs FastLoad que carregavam diariamente arquivos flat de faturamento com milhoes de linhas em tabelas de staging Teradata. Migrar esses jobs para SSIS Bulk Insert Task ou BCP foi uma das partes mais simples de toda a aposentadoria do legado – o salto conceitual e pequeno; a sintaxe difere.

Perl, KSH e AIX: O Mundo de Agendamento da Era Mainframe

Para muitos ambientes ETL do inicio dos anos 2000, o AIX (IBM Advanced Interactive eXecutive, a versao Unix da IBM) era a base primaria de servidores. O Informatica PowerCenter, o Teradata BTEQ e toda a infraestrutura de agendamento rodavam em servidores AIX. Os scripts eram feitos em Perl ou na Korn Shell (KSH); o agendamento diario usava jobs cron ou agendadores comerciais como o Autosys.

Essa camada – o wrapper Perl ou KSH que chamava scripts BTEQ, verificava codigos de retorno, escrevia arquivos de log e enviava emails de alerta em caso de falha – e frequentemente o componente mais negligenciado durante migracoes. No entanto, ela e essencial: define a ordem de execucao, a passagem de parametros, o comportamento em caso de erro e o registro de auditoria. Durante a migracao, essa camada deve ser completamente inventariada e traduzida em jobs SQL Agent ou pipelines Azure Data Factory.

#!/usr/bin/ksh
# Wrapper KSH para jobs em lote Informatica PowerCenter e BTEQ em AIX
# Uso: carga_noturna.ksh AAAA-MM-DD
# Retorna 0 em sucesso, 99 em erro (para integracao Autosys)

LOTE_DT=${1:-$(date +%Y-%m-%d)}
LOGDIR=/opt/etl/logs
LOGFILE="${LOGDIR}/noturno_${LOTE_DT}.log"
BTEQ_DIR=/opt/etl/bteq
PMCMD=/opt/informatica/server/bin/pmcmd

# Funcao auxiliar: registrar erro e abortar
sair_com_erro() {
    echo "[ERRO] $(date '+%Y-%m-%d %H:%M:%S') $1" >> "$LOGFILE"
    exit 99
}

echo "[INFO] $(date '+%Y-%m-%d %H:%M:%S') Execucao noturna iniciada para LOTE_DT=${LOTE_DT}" >> "$LOGFILE"

# Passo 1: Executar script BTEQ (carregar staging Teradata)
# Substituir LOTE_DT no template BTEQ
sed "s/\${LOTE_DT}/${LOTE_DT}/g" "${BTEQ_DIR}/carga_pedido.bteq" > /tmp/carga_pedido_exec.bteq
bteq < /tmp/carga_pedido_exec.bteq >> "$LOGFILE" 2>&1
RC=$?
if [ $RC -ne 0 ]; then
    sair_com_erro "BTEQ carga_pedido.bteq falhou, RC=${RC}"
fi
echo "[OK] $(date '+%Y-%m-%d %H:%M:%S') BTEQ concluido com sucesso." >> "$LOGFILE"

# Passo 2: Iniciar workflow Informatica PowerCenter
# pmcmd retorna 0 em sucesso
$PMCMD startworkflow \
    -sv IntegrationService_PROD \
    -d Domain_PROD \
    -u etl_usuario \
    -p $(cat /opt/etl/secrets/.ipc_senha) \
    -f ETL_PEDIDO \
    -paramfile "${BTEQ_DIR}/params/cliente_a_${LOTE_DT}.par" \
    WF_PEDIDO_CARREGAR >> "$LOGFILE" 2>&1
RC=$?
if [ $RC -ne 0 ]; then
    sair_com_erro "Workflow Informatica WF_PEDIDO_CARREGAR falhou, RC=${RC}"
fi
echo "[OK] $(date '+%Y-%m-%d %H:%M:%S') Workflow Informatica concluido." >> "$LOGFILE"
echo "[INFO] $(date '+%Y-%m-%d %H:%M:%S') Execucao noturna concluida com sucesso." >> "$LOGFILE"
exit 0

Wrapper tipico AIX/KSH: passagem de parametros, substituicao de template BTEQ via sed, verificacao de codigo de retorno, integracao pmcmd para Informatica PowerCenter. Essa camada deve ser completamente inventariada durante a migracao.

Migrando a Camada de Agendamento para SQL Agent / ADF

O wrapper KSH/Perl no AIX nao tem equivalente direto como script de SO no SQL Server ou Azure. A equivalencia e criada por jobs SQL Agent com multiplos passos (passo T-SQL, passo de pacote SSIS, passo PowerShell) ou por pipelines ADF com atividades condicionais e tratamento de erros. O ponto chave e preservar a semantica: a ordem de execucao, a passagem de parametros, o tratamento de erros e o alerta devem ser funcionalmente equivalentes mesmo que a tecnologia seja diferente.

Metodologia de Migracao: Da Analise ao Go-Live

Uma migracao ETL legado nao e um projeto big-bang. Quem tenta migrar todos os workflows Informatica, interfaces ODI e scripts BTEQ simultaneamente e fazer a transicao em uma unica data arrisca erros nao detectados e incidentes em producao. Minha abordagem e iterativa e faseada: primeiro entender, depois traduzir, depois comparar, depois aposentar.

A metodologia de migracao em cinco fases. A Fase 4 (comparacao de saida) e a fase central de garantia de qualidade: a logica ETL nova e antiga rodam em paralelo com dados de entrada identicos; as saidas sao comparadas automaticamente.

Fase 1: Inventario e Analise de Dependencias

Antes de escrever uma unica linha de novo codigo, capturo o estado atual completo: todos os mappings e workflows Informatica (exportacao do repositorio), todas as interfaces ODI (exportacao de topologia/contexto), todos os scripts BTEQ (varredura do sistema de arquivos), todos os wrappers Perl/KSH e suas relacoes de chamada. A partir desse inventario e construido um grafo de dependencias: quais workflows dependem uns dos outros? Quais tabelas sao usadas como staging intermediario por multiplos pipelines? Esse grafo determina a sequencia de migracao.

Fase 2: Analise de Equivalencia

Cada objeto a ser migrado recebe um mapeamento de equivalencia: mapping Informatica para pacote SSIS (data flow), interface ODI para data flow SSIS ou procedimento T-SQL, script BTEQ para job SQL Agent. Para cada passo de transformacao a contrapartida na plataforma destino e definida explicitamente. Atencao especial vai para casos extremos: funcoes SQL especificas Oracle, tipos e formatos DATE especificos Teradata, funcoes internas Informatica sem equivalente SSIS direto.

Fase 3: Construcao na Plataforma Destino

Com o mapeamento de equivalencia como base, pacotes SSIS, procedimentos T-SQL e jobs SQL Agent sao construidos. Cada novo objeto e versionado no Git, segue o padrao de nomenclatura definido e inclui logging, tratamento de erros e parametrizacao. A construcao acontece iterativamente – nao todos os pipelines de uma vez, mas na ordem ditada pelo grafo de dependencias.

Fase 4: Comparacao de Saida com Entradas Identicas

A Fase 4 e a fase critica de qualidade. O sistema antigo e o novo sistema rodam em paralelo com os mesmos dados de entrada. As tabelas de saida sao comparadas automaticamente – primeiro pela contagem de linhas, depois por hashes de colunas agregadas, depois por diferencas de linhas individuais. Apenas quando a comparacao de saida passa para todos os pipelines a migracao esta liberada para o go-live.

Fase 5: Go-Live e Cancelamento de Licenca

O go-live nao e a hora zero, mas a conclusao de um processo validado. O sistema legado permanece ativo por um periodo de encerramento definido (tipicamente duas a quatro semanas) para permitir rollback caso problemas inesperados surjam. Apenas apos estabilidade confirmada a licenca legada e cancelada – esse e o momento em que as economias de custos se tornam concretas.

• Inventario completo antes de escrever a primeira linha de codigo
• Grafo de dependencias como base para a sequencia de migracao
• Mapeamento de equivalencia explicito para cada passo
• Versionamento Git de todos os novos objetos desde o primeiro dia
• Operacao paralela e comparacao de saida como porta de qualidade
• Opcao de rollback definida ate o cancelamento da licenca legada

Equivalencia Tecnologica: Legado para SSIS e Azure

Cada componente de ETL legado tem um equivalente na plataforma moderna. O diagrama abaixo mostra as correspondencias primarias – tanto para SSIS on-premises quanto para Azure Data Factory como destino na nuvem. O mapeamento nem sempre e um-para-um, mas e sempre completo: para cada conceito legado ha um sucessor claro.

Matriz completa de equivalencia tecnologica: cada componente legado do Informatica PowerCenter, ODI e Teradata tem uma contrapartida definida em SSIS ou Azure Data Factory. Esta matriz e a base de cada plano de migracao.

Equivalencias Informatica em Detalhe

O Informatica Source Qualifier corresponde ao SSIS OLE DB Source com uma consulta SQL. Substituicoes SQL no Source Qualifier se tornam consultas parametrizadas no editor SSIS OLE DB Source. O Informatica Aggregator corresponde ao SSIS Aggregate Transformation ou – para logica mais complexa – a um GROUP BY T-SQL em um procedimento de staging. O Informatica Lookup Transformation corresponde ao SSIS Lookup Transformation com a opcao de cache (comparavel ao cache conectado do Informatica). O Informatica Router corresponde ao SSIS Conditional Split.

Equivalencias ODI em Detalhe

Uma interface ODI com LKM Oracle para Oracle corresponde a um data flow SSIS com OLE DB Source e OLE DB Destination. A parte IKM (logica INSERT/UPDATE) corresponde a um SSIS Execute SQL Task com uma instrucao MERGE ou a um padrao upsert no data flow SSIS usando SSIS Lookup + Conditional Split + OLE DB Command. Procedimentos ODI (blocos PL/SQL livremente editaveis) correspondem a passos de job SQL Agent com chamadas T-SQL.

Equivalencias Teradata em Detalhe

Logica BTEQ (sequencias INSERT/SELECT de multiplos passos com tratamento de erros) se torna jobs SQL Agent com passos T-SQL. Substituicao de variaveis BTEQ via sed/Perl se torna parametros de job SQL Agent ou parametros de pacote SSIS. Teradata FastLoad se torna SSIS Bulk Insert Task, BCP ou data flow SSIS com OLE DB Destination no modo de carga rapida. Macros Teradata (blocos SQL reutilizaveis e parametrizados) correspondem a stored procedures T-SQL no SQL Server.

• Informatica Mapping -> Pacote SSIS (Control Flow + Data Flow)
• Informatica Workflow/Worklet -> Job SQL Agent com passos de job
• Informatica Session Log -> SSIS Logging (Event Handler + Logging Provider)
• ODI Interface (LKM+IKM) -> SSIS Data Flow + Execute SQL Task (MERGE)
• ODI Knowledge Module -> SSIS Custom Component ou Script Task
• Script BTEQ -> Job SQL Agent (passo T-SQL) + pacote SSIS
• Teradata FastLoad -> SSIS Bulk Insert Task ou BCP
• Agendador Perl/KSH -> Job SQL Agent com dependencias ou Pipeline ADF

Garantia de Qualidade: Comparacao de Saida com Entradas Identicas

A comparacao de saida e a peca central da certificacao de migracao. O principio e simples: ambos os sistemas – legado e plataforma destino – sao executados com dados de entrada identicos. Volumes de saida, valores agregados e linhas individuais sao comparados. Se as saidas coincidem, a migracao esta correta. Se divergem, a comparacao mostra exatamente onde a divergencia ocorre.

Na pratica ha desafios: sistemas legados no Teradata ou Informatica podem tratar ordens de classificacao e valores NULL de forma diferente do SQL Server. Scripts BTEQ podem depender de comportamento padrao nao documentado do Teradata que o SQL Server trata diferentemente. Essas desviacoes nao sao erros de migracao, mas diferencas de semantica de plataforma que devem ser explicitamente documentadas e alinhadas com a area de negocio.

Comparacao Automatizada com T-SQL

Uso procedimentos de comparacao T-SQL que rodam tanto contra o resultado legado quanto contra o resultado da migracao. Primeiro uma comparacao de contagem de linhas, depois hashes agregados (CHECKSUM_AGG sobre colunas agregadas), depois diferencas de linhas individuais via FULL OUTER JOIN com verificacoes NOT EXISTS. Cada execucao de comparacao e registrada em uma tabela de auditoria para que exista um rastro completo de evidencias.

Um aspecto particular e o tratamento de numeros de ponto flutuante e valores arredondados: Oracle, Teradata e SQL Server arredondam diferentemente em casos limites. Defino limiares de tolerancia para campos numericos e registro desviacoes abaixo do limiar separadamente. Apenas desviacoes acima do limiar contam como erros de migracao.

Reducao de Custos de Licenca como Objetivo Central do Projeto

As licencas de ETL legado sao caras – e os custos sobem enquanto o uso diminui. As licencas do Informatica PowerCenter sao cobradas por nucleo ou por servidor e incluem taxas anuais de manutencao que rapidamente atingem valores de seis digitos em ambientes maiores. As licencas de banco de dados Oracle, muitas vezes mantidas apenas por causa do ODI, custam de forma similar. O Teradata e o componente mais caro: um appliance Teradata incluindo software e manutencao excede o custo de um ambiente SQL Server comparavel muitas vezes.

O retorno sobre investimento de uma migracao pode ser calculado concretamente: economia anual de licenca legada menos custo de migracao resulta no periodo de break-even. Para um ambiente tipico de Informatica PowerCenter com tres a cinco servidores, o break-even geralmente e inferior a um ano, pois as economias anuais superam o custo de migracao. Para ambientes Teradata em volumes de dados medios, o break-even tambem e frequentemente inferior a dois anos.

O que o SSIS Custa no Pacote SQL Server: Nada

O SSIS esta incluido no SQL Server Enterprise ou Standard Edition – sem licenca separada, sem renovacao anual, sem sobrecarga por nucleo. Quem ja executa SQL Server e aposenta Informatica ou ODI nao paga custos adicionais de licenca para o destino da migracao. Esse e um dos argumentos economicos mais fortes para o SSIS como destino de migracao: a plataforma destino ja esta paga.

Azure Data Factory: Modelo de Custo Variavel em vez de Licenca Fixa

O Azure Data Factory segue um modelo de consumo: os custos acumulam para atividades de pipeline executadas, volume de movimentacao de dados e horas de integration runtime. Para ambientes com execucoes de lote diarias e volumes de dados moderados, esses custos sao tipicamente bem abaixo dos custos fixos de um ambiente Informatica ou Teradata comparavel – e escalam para baixo quando cargas sao removidas.

• Informatica PowerCenter: Eliminar custos de licenca e manutencao
• ODI: Aposentar licenca Oracle DB mantida apenas para ODI
• Teradata: Substituir a plataforma mais cara por SQL Server ou Azure
• SSIS: Ja incluido no SQL Server – sem licenca adicional necessaria
• Azure Data Factory: Baseado em consumo em vez de licenca fixa
• Calculo de ROI: Break-even frequentemente inferior a um ano

Azure como Plataforma Destino: SSIS vs. ADF

Em cada migracao surge a questao: SSIS on-premises ou Azure Data Factory? A resposta depende da infraestrutura existente, das localizacoes das fontes de dados e da direcao estrategica da organizacao em relacao a nuvem.

Quando o SSIS e a Escolha Certa

O SSIS e a escolha certa quando os sistemas de origem e destino estao on-premises e o trafego de rede nao justifica o desvio pelo Azure. SQL Server com SSIS roda na infraestrutura existente, pode ser colocado em producao imediatamente e nao requer custos de migracao para a nuvem. O SSIS tambem e preferivel quando existem fluxos de dados complexos com muitos passos de transformacao que sao mais complicados de implementar no ADF – o SSIS oferece uma biblioteca de transformacoes mais rica aqui.

Quando o Azure Data Factory e Melhor

O ADF e a escolha certa quando a organizacao ja usa servicos de nuvem Azure: Azure SQL Database, Azure Synapse, Blob Storage, Data Lake Storage. O ADF se integra perfeitamente a esses servicos e evita o desvio por um servidor SSIS on-premises. O ADF tambem fornece recursos cloud-native como escala elastica, monitoramento integrado atraves do Azure Monitor e parametrizacao nativa via Azure Key Vault – aspectos que o SSIS on-premises nao oferece nessa forma.

SSIS no Azure via Integration Runtime

Um caminho intermediario e o lift-and-shift SSIS para Azure via Azure-SSIS Integration Runtime no ADF: pacotes SSIS existentes rodam no Azure sem serem reescritos. Essa e uma opcao atraente para organizacoes que desejam transferir seus pacotes SSIS para o Azure sem duplicar o esforco de desenvolvimento. A longo prazo, migrar para atividades nativas ADF e recomendado porque o Azure-SSIS Integration Runtime e relativamente caro.

• SSIS on-premises: Para pipelines puramente on-premises, disponibilidade imediata
• SSIS no Azure IR: Lift-and-shift de pacotes SSIS para a nuvem
• Azure Data Factory: Para cenarios cloud-native com servicos Azure
• Hibrido: SSIS e ADF podem coexistir e se complementar
• Azure Synapse Analytics: Grandes volumes de dados, cargas de trabalho de data warehouse
• Longo prazo: Preferir ADF nativo para novos desenvolvimentos na nuvem

Servicos Tipicos em Resumo

O escopo dos meus servicos ETL legado vai do inventario inicial ao go-live produtivo da solucao de migracao. Dependendo da fase do projeto e dos requisitos, assumo areas individuais ou o caminho de migracao completo.

• Inventario: Exportacao de repositorio Informatica, topologia ODI, varredura de arquivos BTEQ, mapeamento Perl/KSH
• Analise de dependencias e priorizacao da sequencia de migracao
• Mapeamento de equivalencia: componentes legados para construcoes SSIS/ADF
• Desenvolvimento SSIS: fluxos de dados, fluxos de controle, tratamento de erros, logging, implantacao
• Desenvolvimento T-SQL: procedimentos MERGE, logica de staging, jobs SQL Agent
• Azure Data Factory: pipelines, datasets, linked services, triggers, Key Vault
• Comparacao de saida: procedimentos de comparacao T-SQL, relatorio de diferencas, documentacao de aprovacao
• Suporte ao go-live: operacao paralela, monitoramento, coordenacao de cancelamento de licenca
• Documentacao: especificacao tecnica, manual de operacoes, transferencia para equipe interna

O trabalho de migracao pode ser executado como um projeto completo (da analise ao go-live) ou como suporte direcionado para fases individuais. Para organizacoes que ja iniciaram uma migracao e encontraram problemas, posso entrar precisamente onde o suporte e necessario – seja na analise de equivalencia, no desenvolvimento SSIS ou na automacao de comparacao de saida.

O trabalho remoto e bem adequado para migracoes ETL legado, desde que o acesso aos sistemas relevantes (repositorio Informatica, topologia ODI, Teradata, SQL Server, Azure) esteja assegurado. Para as fases iniciais de inventario e suporte ao go-live, a presenca no local e frequentemente valiosa porque o overhead de comunicacao em fases criticas e alto.

Projetos de Referencia Anonimizados

Perguntas Frequentes sobre Migracao ETL Legado