Série Data Pipelines at Scale

Como transformar milhares de registros públicos em informação analisável sem perder contexto? Neste estudo, trabalhei com ocorrências da polícia do Reino Unido e organizei um fluxo de ingestão, limpeza e processamento distribuído para descobrir padrões frequentes nos dados.

O projeto analisou registros de julho de 2015 a junho de 2018 referentes a Swindon, no condado de Wiltshire. A fonte foi o portal de dados abertos da polícia do Reino Unido.

Fonte e estrutura dos dados

Os arquivos continham informações como identificador, mês da ocorrência, força policial responsável, longitude, latitude, localização, tipo de crime e última ação registrada.

Para um pipeline recorrente, eu registraria para cada arquivo:

• período de referência e data de ingestão;
• origem e checksum do objeto recebido;
• esquema esperado e versão do esquema;
• contagem de linhas aceitas, rejeitadas e deduplicadas.

Esse controle evita reprocessamentos silenciosos e permite rastrear exatamente qual fonte produziu cada resultado.

Limpeza com regra de negócio

Durante o data wrangling, identifiquei valores ausentes na coluna de última ação. Os registros de comportamento antissocial foram excluídos da etapa de associação porque a ausência não permitia concluir se o caso estava ou não resolvido.

Essa decisão precisa ser documentada: excluir registros melhora a consistência do conjunto usado pelo algoritmo, mas também altera sua cobertura. Em produção, eu manteria os registros na camada bruta, marcaria o motivo da rejeição na camada tratada e publicaria uma métrica sobre a perda de dados.

Após a filtragem, a base usada no processamento ficou com 8 colunas e 124.185 registros.

Por que FP-Growth

Regras de associação procuram combinações de atributos que aparecem juntas com frequência. Duas métricas orientam o processo:

• suporte: proporção de registros em que a combinação aparece;
• confiança: frequência com que o consequente aparece quando o antecedente está presente.

O Apriori gera e testa conjuntos candidatos em várias passagens pela base. O FP-Growth reduz esse custo ao representar os padrões frequentes em uma estrutura compacta, a FP-Tree. Essa característica o torna interessante quando o volume e o número de combinações aumentam.

Processamento distribuído

Utilizei R, SparkR e o algoritmo FP-Growth, com confiança mínima de 0,70 e suporte mínimo de 0,01. O Spark distribui o processamento, enquanto o FP-Growth evita enumerar todas as combinações possíveis.

Um fluxo produtivo para esse processamento poderia ser organizado assim:

Arquivos mensais -> validação de esquema -> camada bruta
                 -> padronização e qualidade -> camada tratada
                 -> FP-Growth no Spark -> regras publicadas

Os parâmetros de suporte e confiança devem ser versionados junto ao resultado. Sem isso, duas execuções sobre os mesmos dados podem gerar conjuntos de regras diferentes sem que a causa fique evidente.

Da transformação ao produto analítico

O resultado do processamento pode ser publicado em dois modelos complementares:

Modelo	Granularidade	Uso principal
fct_ocorrencia_criminal	uma ocorrência registrada	análises por período, local e categoria
mart_regras_associacao	uma regra por período e conjunto de parâmetros	comparação de suporte, confiança e estabilidade

Dimensões de tempo, localização e categoria permitem reaproveitar as mesmas definições em diferentes análises. No mart_regras_associacao, eu manteria também min_support, min_confidence, versão do algoritmo e data de processamento. Assim, a regra deixa de ser apenas uma saída de notebook e passa a ser um produto analítico comparável ao longo do tempo.

Observabilidade e evolução

Para tornar o pipeline confiável, eu acompanharia:

• atraso entre o mês da ocorrência e sua disponibilidade;
• percentual de coordenadas e categorias nulas;
• duplicidade do identificador da ocorrência;
• volume por mês e por tipo de crime;
• quantidade de regras geradas e variação em relação à execução anterior.

Também particionaria os dados por ano e mês, preservaria o arquivo original e tornaria o processamento idempotente. Dessa forma, reexecutar um período corrigido substituiria apenas a partição correspondente, sem duplicar o histórico.

Aprendizados

O algoritmo é apenas uma parte da solução. A confiabilidade das regras depende da origem, do tratamento dos nulos, da rastreabilidade dos filtros e da capacidade de repetir o processamento. Esse é o ponto em que mineração de dados e Engenharia de Dados se encontram.