Halodoc constrói framework de data profiling nativo no Airflow para escalar governança de dados
Aprofundamento CEVIU
Aprofundamento
A Halodoc, healthtech indonésia com 7 milhões de pacientes mensais e infraestrutura em mais de 50 serviços AWS, não construiu só mais um wrapper SQL para profiling: criou um operador Airflow nativo que transforma metadados em política executável. Ele roda em pods isolados no EKS, não como sandbox genérico, mas com orquestração de recursos por tabela (CPU, memória, tempo de vida), baseada em heurísticas de cardinalidade e frequência de atualização. Cada execução gera um run_id que garante idempotência *e* rastreabilidade de proveniência, essencial para auditorias de dados usados em modelos clínicos ou relatórios regulatórios da BPJS (sistema público de saúde indonésio). O framework não para no Redshift ou Athena: ele extrai padrões de joins entre tabelas de origem (como transações de farmácia vs. registros de teleconsulta) e alimenta um catálogo interno com lineage explícito, algo que o toolkit da dltHub, lançado dias antes, ainda trata como verificação pós-execução, não como parte do fluxo de ingestão.
O uso do Airflow 3.x é estratégico: a Halodoc aproveitou o novo suporte a event-driven scheduling para disparar profiling apenas quando há mudança de esquema detectada via AWS Glue Schema Registry, evitando ciclos desnecessários. Isso contrasta com a abordagem da Grab, que usa Flink para ingestão em tempo real, mas delega qualidade de dados para etapas posteriores. Aqui, profiling é acoplado ao ciclo de vida do dado desde o primeiro byte no S3, não como checkpoint, mas como gate.
Por que isso importa
Em 2026, dados 'prontos para agentes' de IA exigem mais do que schema válido: exigem confiança na origem, na transformação e no contexto de uso. A solução da Halodoc converte governança de dados de tarefa manual, com dashboards estáticos e alertas genéricos, em mecanismo ativo de segurança operacional. Quando um time de análise descobre que uma coluna de 'data de entrega' tem 42% de valores nulos em tabelas de logística, o sistema já aponta automaticamente quais pipelines dependem dela, quais modelos de previsão estão expostos ao risco e qual versão do esquema foi usada na última carga. Isso reduz o tempo médio de investigação de incidentes de qualidade de dados de horas para minutos, um diferencial crítico em saúde, onde decisões baseadas em dados impactam diretamente tempo de resposta clínica.
Linha do tempo
Grab lança plataforma de ingestão unificada com Apache Flink, focando em velocidade de integração
CEVIU analisa uso de PostgreSQL como camada central para workflows de marketing orientados por IA
Halodoc anuncia framework de data profiling nativo no Airflow, integrando governança ao ciclo de vida do dado
Perguntas frequentes
Por que usar Airflow em vez de ferramentas especializadas como Great Expectations ou Soda?
A Halodoc priorizou integração profunda com sua stack existente (EKS, Redshift, S3) e controle granular de execução. Ferramentas especializadas exigiriam novos agentes, camadas de abstração e sincronização de metadados. Com um operador Airflow nativo, o profiling herda toda a observabilidade, retry policy e lineage do orquestrador, e pode ser versionado junto com os DAGs, não como configuração externa.
Como o isolamento por pod no Kubernetes evita conflitos entre tabelas grandes e pequenas?
Cada tabela recebe um pod com limites de CPU/memória calculados dinamicamente com base em seu tamanho histórico e complexidade de profiling (ex: contagem de valores únicos em colunas de texto exige mais memória do que estatísticas básicas). Isso impede que uma tabela de 2 TB sobrecarregue recursos compartilhados e degrade o profiling de centenas de outras menores, algo que soluções centralizadas em um único cluster de Spark ou Polars Distributed ainda enfrentam.
O que torna esse framework 'nativo no Airflow', e não só 'executado pelo Airflow'?
Ele usa operadores personalizados com lógica de execução embutida, não chamadas shell ou PythonOperator genéricas. Os metadados de cada profiling (valores nulos, distribuição, correlação entre colunas) são registrados diretamente no metastore do Airflow como XComs estruturados, permitindo que outros DAGs consumam esses resultados como entrada, sem APIs intermediárias ou arquivos no S3. É governança como código, não como job ad-hoc.
Links relacionados
Fontes
- blogs.halodoc.iofonte original
- Categoria
- CEVIU Dados
- Publicado
- 01 de junho de 2026
- Editoria
- CEVIU Dados
