Abordagem Híbrida de Parsing Estruturado e (LLMs) para a Conversão de Pipelines de ETL Legados (DataStage) para PySpark Serverless na AWS

A modernização de sistemas legados de Extração, Transformação e Carga (ETL) representa um dos maiores gargalos na migração para arquiteturas de Modern Data Stack. Este artigo apresenta uma abordagem de engenharia para a conversão automatizada de fluxos do IBM InfoSphere DataStage para Apache Spark (PySpark), utilizando uma arquitetura assíncrona, orientada a eventos e serverless na AWS. Demonstramos que a transpilação puramente baseada em Engenharia de Prompts com Modelos de Linguagem de Grande Porte (LLMs) é insuficiente devido à impedância semântica entre os paradigmas. A solução proposta mitiga essa limitação através do acoplamento de um Parser sintático determinístico a um pipeline de inferência contextualizada via Amazon Bedrock, resultando em uma autonomia de conversão de ~73% e redução significativa de esforço de engenharia reversa.

1. Introdução e Formulação do Problema

A migração de ferramentas de ETL baseadas em interface gráfica e servidores dedicados (como o IBM DataStage) para frameworks de computação distribuída em nuvem (como o Apache Spark) é motivada pela necessidade de escalabilidade linear, redução de custos operacionais (TCO) e eliminação de vendor lock-in.

No entanto, a automação desse processo enfrenta o desafio da desconexão de paradigmas:

• DataStage (Modelo Orientado a Fluxo/Componentes): Opera através de stages proprietários (e.g., Transformer, Join, Aggregator) interconectados por links de dados, onde regras de negócio muitas vezes residem ocultas em metadados implícitos, variáveis de ambiente do projeto ou blocos de código SQL dialetal embarcado.
• Apache Spark (Modelo Funcional/Declarativo Distribuído): Baseia-se em avaliações preguiçosas (lazy evaluation) sobre Grafos Acíclicos Direcionados (DAGs) de DataFrames, exigindo otimização de partições, gerenciamento de memória distribuída e código explicitamente tipado.

A tentativa de submeter o código-fonte de exportação do DataStage (arquivos XML baseados no formato ISX) diretamente a LLMs comerciais falha sistematicamente. Os motivos incluem a extrapolação da janela de contexto por ruído de formatação do XML, a alucinação de APIs inexistentes do Spark e a incapacidade do modelo estatístico de inferir o grafo de dependência lógica sem uma representação intermediária estruturada.

2. Arquitetura da Solução (Esteira de Transpilação Assíncrona)

Para garantir escalabilidade horizontal e resiliência no processamento de centenas de artefatos complexos, desenvolveu-se uma arquitetura baseada nos princípios de microsserviços serverless e desacoplamento por mensageria na AWS.

2.1 Componentes de Infraestrutura

1. API Gateway & AWS Lambda (Ingress): Ponto de entrada RESTful que recebe o payload XML do DataStage, realiza a validação de esquema inicial e gera um identificador único de execução (UUID).
2. Amazon SQS (Camada de Desacoplamento): Fila de mensagens que gerencia o amortecimento de carga (load leveling), garantindo tolerância a falhas e controle de concorrência frente aos limites de taxa (Rate Limiting) das APIs de inferência.
3. Worker Lambda (Motor de Execução): Consumidor assíncrono responsável por executar a lógica core de parsing, enriquecimento de contexto, chamada ao LLM e pós-processamento.
4. Amazon DynamoDB (Persistência de Estado): Banco de dados NoSQL utilizado como máquina de estados e datastore de observabilidade, registrando metadados, métricas de conversão e logs de erro.
5. Amazon Bedrock (Camada de Inteligência Artificial Generativa): Acesso gerenciado a modelos de fundação de última geração via APIs unificadas, operando sob políticas estritas de governança de dados e privacidade.

3. O Motor de Transpilação Híbrido: Parsing e Engenharia de Contexto

O diferencial técnico do projeto reside no abandono da abordagem naive (“apenas prompt”) em favor de um pipeline de compilação assistida por IA, estruturado em duas macroetapas:

Fluxo Técnico de Conversão Híbrida de DataStage para PySpark

3.1 O Parser Especializado (Análise Sintática e Extração de Metadados)

Antes de acionar a camada generativa, o XML legado é submetido a um motor de análise sintática híbrido escrito em Python (utilizando bibliotecas de alta performance como lxml combinadas com motores de expressões regulares otimizados). Esta camada executa as seguintes subtarefas:

• Deconstrução de Sub-elementos: Extração cirúrgica de propriedades contidas nas tags <Collection>, <Record> e <Property> do formato ISX.
• Isolamento de Dialeto SQL: Identificação e extração de queries embutidas em estágios de conectividade (e.g., DB2 Connector, Oracle Enterprise), isolando heranças lógicas complexas.
• Mapeamento de Linhagem (Lineage): Reconstrução do fluxo de dados unindo InputPins e OutputPins dos stages, gerando uma representação em formato de Grafo Intermediário.

3.2 O Core de Conversão e Injeção de Contexto (Context-Driven Prompt Engineering)

Com o grafo lógico e os metadados extraídos, o sistema constrói dinamicamente o payload de entrada para o Amazon Bedrock. Em vez de enviar o XML bruto, o prompt é estruturado seguindo rigorosos padrões de engenharia de software:

{
  "contexto_arquitetural": "Alvo: Apache Spark 3.x, Execução sobre AWS Glue / EMR Serverless.",
  "metadados_job": {
    "parametros": ["DATA_CARGA", "DIRETORIO_S3"],
    "estrategia_leitura": "Incremental via coluna de controle",
    "querys":"SLEXT * FFROM..."
  },
  "grafo_logico": "STAGE_FONTE_01 (Leitura Oracle) -> STAGE_TRANSFORM_02 (Regra de Negócio) -> STAGE_ALVO_03 (Escrita Parquet Delta)",
  "regras_especificas": "Converter funções proprietárias como StringToDate para funções nativas do pyspark.sql.functions."
}

Esta técnica minimiza drasticamente a entropia do modelo, forçando-o a focar estritamente na tradução semântica das transformações e na geração de código PySpark idiomático (aplicando boas práticas como evitar o uso de loops for, preferir operações vetorizadas sobre DataFrames e estruturar partições eficientes).

4. Arquitetura do Motor de Transpilação

O diferencial técnico da solução reside no pipeline de compilação assistida por IA, estruturado em camadas de parsing estruturado, injeção contextual e validação de gaps.

4.1 Análise do Parsing Core e Enriquecimento de Contexto (Context-Driven Engineering)

Antes de acionar a camada generativa, o XML legado é submetido a um motor de análise sintática híbrido. A análise do código-fonte da solução revela o uso de heurísticas avançadas para garantir que o LLM opere com o máximo de informações estruturadas.

Consideremos o seguinte extrato relevante do motor de parse core:

"""Extrato Relevante do Core de conversao DataStage XML -> codigo PySpark."""

def build_table_mode_context(datastage_info: Dict[str, Any]) -> str:
    """Aplica heuristicas para identificar o modo de escrita e PK da tabela no Spark."""
    if not isinstance(datastage_info, dict):
        return "No table identified."

    sql_query = datastage_info.get("sql_queries", {}).get("main_query", "")
    # Utiliza um segundo parser especializado para extrair tabelas da query SQL embarcada
    sql_tables = [normalize_table_name(t) for t in extract_table_references(sql_query)]
    if not sql_tables:
        return "No table identified."

    # Carrega configuracoes externas de Spark para mapear estrategias de escrita
    table_configs = load_spark_table_configs()
    lines: List[str] = []

    for table in sql_tables:
        # Heuristica de Mapeamento: Determina se a escrita e FULL ou INCREMENTAL 
        # baseada no metadado da tabela alvo no Spark Catalog.
        cfg = table_configs.get(table)
        if not cfg:
            lines.append(f"- {table}: write_mode=unknown, pk_column=N/A")
            continue
        lines.append(
            f"- {table}: write_mode={cfg.get('write_mode', 'full')}, "
            # Normalizacao da PKColumn extraida da configuracao
            f"pk_column={normalize_partition_id(cfg.get('partition_id', '')) or 'N/A'}"
        )
    return "\n".join(lines) if lines else "No table identified."

Este trecho demonstra como a engenharia ao redor da IA resolve ambiguidades:

1. Parsing de SQL Embarcado: O motor não confia apenas no XML do DataStage; ele extrai a query SQL principal e utiliza um parser especializado para identificar tabelas e colunas.
2. Mapeamento de Estratégias de Dados (Write Mode): A solução aplica heurísticas para decidir se o script Spark gerado deve ler dados de forma integral (FULL) ou incremental (read_and_persist_incremental), cruzando as tabelas identificadas com configurações externas do Spark Catalog.
3. Identificação de PK: A PKColumn é normalizada, garantindo que operações distribuídas como deduplicação (dropDuplicates) ou junções (join) sejam geradas corretamente.

5. Validação Resiliente via Multi-Agente: O Padrão “Agente no Loop”

A fase mais crítica para a confiabilidade da transpilação ocorre após a inferência inicial do LLM. Para garantir a produção de código PySpark idiomático, compilável e logicamente equivalente ao legado, desenvolvemos um pipeline de validação multi-agente, implementando um padrão de “Agente no Loop”.

Fluxo de Validação Multi-Agente

5.1 Agente 1: Geração de Transpilação

Este agente recebe o prompt enriquecido com o contexto estruturado (parsing de SQL, regras de escrita, identificação de PKs) e gera uma versão preliminar do código PySpark, aderente às boas práticas e à arquitetura de conectores internos.

5.2 Agente 2: Validação de Gaps e Equivalência Semântica

Todo script gerado pelo Agente 1 é submetido a um segundo agente especializado em validação técnica. Este agente opera sob a seguinte metodologia:

1. Comparação contra Script-Modelo: O Agente 2 tem acesso a padrões-modelo (skeletons) de arquitetura PySpark otimizados para o ambiente da CNP (Glue/EMR Serverless). Ele não verifica apenas a sintaxe, mas a aderência ao padrão arquitetural (e.g., manipulação correta de SparkSession, gerenciamento de memória em shuffle, estruturas de try-except-finally).
2. Verificação de Gaps Lógicos e Semânticos: O Agente 2 realiza uma análise estática assistida para identificar possíveis falhas:

• Gaps de Compilação: Alucinação de APIs ou dependências inexistentes.
• Gaps Semânticos: Mapeamento incorreto de transformações (e.g., converter FilterStage do DataStage para uma query SQL Spark incorreta).
• Gaps de Metadados: Verificação se todas as PKColumns e Write Modes definidos no parsing core foram aplicados corretamente no script final.

3. Relatório de Gap e Regeneração: Caso falhas sejam identificadas, o Agente 2 gera um relatório técnico detalhado dos gaps. Este relatório pode ser utilizado como feedback para uma nova rodada de inferência do Agente 1 (autocorreção) ou entregue ao engenheiro para revisão manual focada.

6. Resultados Experimentais e Análise de Impacto

A solução foi homologada sob um portfólio real de jobs de ETL de alta complexidade. Os resultados quantitativos e qualitativos demonstram a viabilidade da abordagem:

6. 1 Métricas de Eficiência

Métricas de Eficiência avaliados

6.2 Artefatos Gerados por Execução

A esteira não entrega apenas um arquivo de script isolado, mas sim um pacote de governança técnica para a equipe de Engenharia de Dados:

1. Script PySpark (.py): Código limpo, modularizado, documentado e aderente à PEP 8.
2. Relatório Técnico de Linhagem: Documentação em Markdown detalhando a lógica mapeada do job legado.
3. Mapeamento de Metadados: Estrutura JSON com de/para de esquemas, tabelas de origem e destino, facilitando o provisionamento de catálogos de dados (e.g., AWS Glue Data Catalog).

7. Conclusão e Trabalhos Futuros

A experiência documentada neste artigo comprova que a automação resiliente de migrações de sistemas de dados legados de larga escala não encontra sua resposta em soluções generalistas de Inteligência Artificial Generativa. O sucesso do projeto reside na arquitetura de acoplamento fraco, onde o determinismo do parsing estruturado clássico fornece os trilhos normativos (contexto rico), e uma esteira de validação multi-agente garante o controle de qualidade estatística, comparando a inferência contra padrões-modelo de engenharia rigorosos. O ganho real não está no “uso de IA”, mas na estruturação determinística do problema ao redor dela. Esse paradigma ditara o sucesso ou fracasso de muitos projetos envolvendo IA atualmente.