ETL

ETL significa extrair, transformar e carregar, e descreve o processo de extrair dados de sistemas de origem, convertê-los em uma estrutura consistente e carregá-los em um destino, como um data warehouse. É a infraestrutura por trás da análise de dados, e sua confiabilidade determina se os relatórios gerados a partir dela são confiáveis.

Cada etapa apresenta dificuldades distintas. A extração exige a obtenção de dados de sistemas que não foram projetados para consultas externas, lidando com limites de taxa de API, detecção incremental de alterações e fontes que não oferecem uma maneira confiável de identificar o que mudou. A transformação deve conciliar formatos inconsistentes, identificadores diferentes, definições conflitantes e valores ausentes. O carregamento deve lidar com o volume de dados, manter o histórico e tratar registros que chegam com atraso ou fora de ordem.

A variante ELT inverte as duas últimas etapas, carregando os dados brutos no destino e transformando-os lá. Isso se tornou comum porque as plataformas de data warehouse modernas têm capacidade de processamento suficiente para tornar a transformação in-place eficiente, e porque a retenção dos dados brutos permite que as transformações sejam revisadas e reaplicadas sem a necessidade de reextração das fontes. Isso também significa que os erros na lógica de transformação são recuperáveis, em vez de permanentes.

O processamento incremental é a necessidade prática que complica a maioria das implementações. Reprocessar todos os dados históricos a cada execução é simples, mas torna-se inviável à medida que o volume aumenta. Portanto, os pipelines devem identificar o que mudou desde a última execução. Fontes sem registros de alteração confiáveis, registros atualizados retroativamente e exclusões sem deixar rastros tornam essa tarefa mais difícil do que parece, e uma lógica incremental incorreta produz dados incompletos silenciosamente.

O tratamento de falhas determina se um pipeline está pronto para produção. Pipelines falham rotineiramente porque os sistemas de origem alteram seus esquemas, as credenciais expiram, os serviços upstream ficam indisponíveis ou dados inesperados chegam. As propriedades importantes são que as falhas sejam detectadas imediatamente, que execuções parciais não deixem o destino em um estado inconsistente, que novas execuções produzam o mesmo resultado em vez de duplicar registros e que alguém seja notificado em vez de a falha ser descoberta apenas quando um relatório parecer incorreto.

A validação da qualidade dos dados deve ser feita durante o processo de validação, e não depois. Verificar se a contagem de linhas corresponde ao esperado, confirmar se os campos principais estão preenchidos, verificar se os valores estão dentro de intervalos plausíveis e testar a consistência referencial detectam a corrupção de dados no ponto de entrada. Sem esses testes, dados incorretos se propagam para relatórios e decisões, e geralmente são descobertos semanas depois, quando alguém percebe um valor inconclusivo.

O agendamento e o gerenciamento de dependências determinam se a saída é coerente. Os pipelines raramente são executados isoladamente, e uma tarefa subsequente que começa antes que sua fonte anterior tenha terminado produz resultados parciais que parecem completos. Existem ferramentas de orquestração para expressar essas dependências explicitamente, e pipelines encadeados por suposições de tempo, em vez de por dependências declaradas, falham intermitentemente de maneiras difíceis de reproduzir.

A documentação e a linhagem são importantes porque os fluxos de trabalho sobrevivem às pessoas que os constroem. Saber a origem de cada campo, quais transformações foram aplicadas e quais regras de negócio estão codificadas é essencial para responder a perguntas sobre por que um número tem a aparência que tem e para avaliar o impacto da alteração de um sistema de origem. Fluxos de trabalho sem documentação se tornam sistemas que ninguém se atreve a modificar, e é assim que as organizações acabam com fluxos de trabalho paralelos produzindo números conflitantes.

Como a confiabilidade, e não a sofisticação, determina o valor entregue, a disciplina de engenharia aplicada aos dutos deve ser a mesma aplicada ao software de produção. Na prática, os dutos são construídos e operados por desenvolvimento de produtos ou de Departamento de Informática, a lógica de transformação que codifica as definições de negócios é especificada com análise de dadosE as regras de validação devem ser acordadas antes da construção do primeiro pipeline, em vez de serem adicionadas após o primeiro incidente.