Data Engineering

Uma Plataforma Moderna de Dados: A tecnologia por trás dos produtos Whitebook e iClinic

Uma arquitetura em constante evolução que prioriza flexibilidade, escalabilidade e segurança para os produtos digitais da Afya, baseada nos padrões mais modernos do mercado

A Afya é o maior hub de educação em saúde e healthtechs do Brasil, proporcionando soluções inovadoras que combinam conhecimento acadêmico e tecnologia de ponta. Entre seus principais produtos digitais estão o Whitebook, uma ferramenta que fornece informações precisas e direcionadas à equipe médica para auxiliar no suporte às decisões clínicas, e o iClinic/Shosp, que são sistemas de gestão médica que otimizam o atendimento e a administração de clínicas.

Para suportar esses produtos e os times que estão à frente deles, precisamos de uma plataforma descentralizada, que possibilite maior autonomia e flexibilidade para os times trabalharem, que gere confiabilidade e segurança, que são questões básicas quando falamos de plataforma de dados e, por fim, que seja escalável e otimizada a fim de não precisarmos crescer o nosso time de dados de forma linear ao crescimento de demandas e necessidades em relação à plataforma.

Na Afya, operamos atualmente com quatro Data Lakes: Graduação & Educação Continuada, Whitebook, iClinic, e MDM & CDP & B2B, todos hospedados majoritariamente na AWS. Embora 90% da nossa Plataforma de Dados esteja na AWS, também utilizamos a Azure para alguns casos de uso específicos, principalmente relacionados à Graduação e ao B2B. Atualmente, estamos trabalhando na unificação dos Data Lakes Whitebook e iClinic, que ainda operam de forma separada devido às suas origens em estruturas empresariais distintas quando foram adquiridos. Nosso primeiro passo nesse processo de unificação foi a equalização de processos e ferramentas, sobre o qual entraremos em mais detalhes futuramente.

Arquitetura

Antes de entrarmos em detalhes sobre nossa arquitetura atual, gostaria de destacar que já iniciamos um trabalho de revisão visando 2025. Nosso objetivo é não apenas simplificar, mas também modernizar ainda mais nossa infraestrutura, incorporando tecnologias que consideramos alinhadas com a direção que estamos tomando. Atualmente estamos estudando como tecnologias de outros fornecedores e novas estruturas de armazenamento, como Apache Iceberg, podem ou não agregar ainda mais valores à nossa plataforma.

Agora, vamos explorar as diferentes camadas que compõem nossa arquitetura de dados: ingestão, transformação, visualização, machine learning e data ops. Cada uma dessas camadas desempenha um papel crucial em nosso ecossistema de dados. Nos próximos tópicos, detalharemos o funcionamento de cada camada e os motivos por trás da escolha de cada ferramenta.

Ingestão

A camada de ingestão de dados é a primeira etapa crucial em nossa plataforma, encarregada de coletar e importar dados de diversas fontes para o nosso Data Warehouse, especificamente no AWS Redshift. Essa fase garante que os dados sejam capturados de maneira eficiente, seja por meio de APIs, Change Data Capture (CDC) com bancos de dados replicas, ou utilizando conectores prontos de ferramentas SAS. A seguir, apresentamos as ferramentas que utilizamos, juntamente com seus respectivos casos de uso:

• Stitch: Uma ferramenta de ingestão de dados que oferece integração rápida e eficiente, utilizando conectores baseados no projeto Singer. Configurar esses conectores para que os dados comecem a ser transferidos para o AWS Redshift é muito simples. No entanto, há algumas limitações: não podemos criar conectores específicos para nossas necessidades, e, devido a essa falta de autonomia, dependemos do suporte técnico para resolver quaisquer problemas de ingestão que possam surgir.
• AWS Lambda: Como um serviço de computação serverless, AWS Lambda simplifica o desenvolvimento de processos de ingestão ao eliminar a necessidade de configurar servidores. Além disso, você paga apenas pelo tempo de execução. No entanto, uma desvantagem é que a orquestração só poderia ser feita por meio do AWS Step Functions ou pelo uso do AWS Lambda Operator no Airflow. Outro desafio é o versionamento de código. Para resolver isso, integramos nosso repositório de código para que, sempre que houver um merge para produção, uma imagem de container será gerada no AWS ECR e usamos essa imagem nas Lambdas. Atualmente estamos migrando nossas lambdas para o Airflow.
• Airflow: Além de ser uma ferramenta para orquestração de pipelines, utilizamos os operadores do Airflow (Python e Python Virtualenv) para desenvolver ingestões mais personalizadas. Atualmente, o Airflow é executado dentro do EKS, permitindo um uso mais eficiente dos recursos disponíveis. Essa configuração nos possibilita manter ambientes de desenvolvimento e produção com a mesma arquitetura, bem isolados, diferenciando-se apenas pelo dimensionamento dos recursos alocados.
• AWS DMS (Data Migration Service): Usado especificamente para a replicação de bancos de dados dos produtos digitais, que são predominantemente Postgres ou MySql. A replicação pode ser executada tanto no modelo Full Load, comumente usado para tabelas de pequenos (até 1 MM linhas) ou médio (20 MM linhas) porte que passam por frequentes atualizações de dados, quanto no Change Data Capture (CDC), empregado basicamente para tabelas de grande porte ou quando análises Near Real Time são necessárias. Um dos principais desafios dessa ferramenta é a gestão de alertas, pois o tratamento desses alertas no AWS Cloudwatch para acioná-los no Slack provou ser uma tarefa bem complexa. Além disso, a replicação pode parar mesmo quando não há geração de mensagens de erro, o que nos levou a criar um campo nas tabelas replicadas para monitorar a data e a hora da última atualização.
• Snowplow: Para capturar o comportamento do usuário em nossas aplicações e portais, utilizamos dados de rastreamento coletados pelo Snowplow. Usamos o Snowplow como um serviço PaaS, o que significa que toda a infraestrutura está na nossa conta AWS. Os custos estão relacionados ao suporte e monitoramento do pipeline, que utiliza serviços como EMR, Kinesis e Kibana. Para mais detalhes sobre o Snowplow, uma ferramenta extremamente relevante para nós, confira o artigo específico que escrevi sobre ela.

Transformação

A camada de transformação de dados é uma etapa crucial para converter dados brutos em informações valiosas. Nesse estágio, realizamos desde a higienização e limpeza dos dados até a construção de tabelas que serão usadas em relatórios pelos times de negócio e variáveis enriquecidas pelo time de Ciência de Dados. Esta camada é composta principalmente por duas ferramentas:

• DBT: Implementada desde 2023 em toda a Afya, essa ferramenta é a principal solução para a transformação de dados. Sua adoção se deve ao sucesso na iClinic, onde já era utilizada antes da aquisição pela Afya, proporcionando maior autonomia aos analistas de dados e permitindo diversas automações e testes, além de incorporar boas práticas do desenvolvimento de software. Um desafio significativo durante sua implementação foi treinar os times de análise, que não são extremamente técnicos, nas boas práticas de construção e versionamento de código. Criamos processos de validação de Merge Requests para aplicar um modelo de aprendizado prático (learning by doing). Recomendo ler os artigos que publicamos no Medium de Dados da Afya, bem como os artigos da engenheira Alice Thomaz, que trabalhou conosco e compartilhou muitos conhecimentos com a comunidade. Um dos principais projetos que estamos desenvolvento atualmente, está relacionado a migração do DBT Cloud para o DBT Core no EKS.
• AWS Redshift: Esta ferramenta de Data Warehouse é onde centralizamos os dados analíticos da Afya. Atualmente, temos quatro clusters do tipo RA3, sendo que o Whitebook e a iClinic possuem clusters exclusivos, onde os recursos de computação e armazenamento são desacoplados. Essa decisão foi tomada devido a uma funcionalidade que é muito importante para nós: o datashare. A principal limitação do uso do AWS Redshift está relacionada à falta de inovação e simplificação em comparação com grandes concorrentes, como Databricks e Snowflake, especialmente quando utilizado em conjunto com o DBT.

No AWS Redshift temos as seguintes categorias para schemas de dados:

• Raw: São schemas idênticos às fontes originais de dados, onde as ingestões são armazenadas.
• Staging: Contém tabelas com corte temporal para apoiar cargas incrementais, otimizando a performance das nossas tarefas.
• Sources: Nomenclatura que utilizamos para a camada bronze; são modelagens específicas do DBT onde catalogamos e padronizamos os dados da camada raw.
• Curated: Camada prata, onde realizamos a higienização e estruturação dos dados, responsabilidade da engenharia de dados, ou começamos a trazer alguns contextos de negócio, responsabilidade de análise de dados.
• Marts: Modelagens analíticas, a camada ouro, onde transformamos dados em informações que geram valor perceptível para os times de negócio.

Visualização

A camada de visualização de dados é essencial para transformar informações valiosas em insights acionáveis. Nesta etapa, os dados processados e transformados são apresentados de maneira clara e acessível para os times de negócio e outras partes interessadas. Utilizamos principalmente duas ferramentas para essa camada:

• Metabase: Uma plataforma de código aberto que permite criar visualizações e dashboards de forma intuitiva. Seu uso está mais relacionado ao período em que os produtos ainda eram startups, com maior adesão pelo iClinic. Para o Whitebook, o uso do Metabase esteve mais ligado a uma iniciativa anterior de Self Service BI. Atualmente, essa ferramenta opera dentro da nossa estrutura de EKS.
• Power BI: Nossa principal ferramenta de visualização de dados, especialmente útil para análises complexas e apresentações de alto nível. Suporta uma ampla gama de visualizações avançadas e recursos de compartilhamento. Utilizamos a versão Premium e disponibilizamos os principais dashboards para os times de negócio por meio de um Portal de Dados.

Machine Learning 🚧

A camada de machine learning é fundamental para transformar dados em insights preditivos e automatizar decisões baseadas em dados. Até o início deste ano, tínhamos estruturas muito diferentes de uso do SageMaker em cada data lake, o que dificultava a padronização e a eficiência dos processos. No entanto, com o crescente uso, e casos de uso, de LLMs (Modelos de Linguagem de Grande Escala), estamos experimentando MVPs (Mínimos Produtos Viáveis) de plataformas para otimizar nossas operações de machine learning.

Atualmente, estamos testando duas abordagens principais:

• SageMaker: Estamos utilizando o SageMaker Studio, as LLMs do Bedrock e modelos prontos do JumpStart. Além disso, implementamos uma aplicação MLflow no EKS para garantir a rastreabilidade dos experimentos que estamos conduzindo.
• Databricks: Em paralelo, estamos utilizando um ambiente Databricks na Azure para avaliar sua eficácia em comparação com o SageMaker. Nesta avaliação, estamos validando todo o ciclo de vida da ciência de dados, desde a engenharia de features até a implantação dos modelos. Neste caso não foi necessário subir uma aplicação do MLFlow, pois já é algo built-in desta plataforma.

Futuramente devo escrever um artigo contanto melhor sobre esta trajetória! 😁

DataOps

A camada de DataOps é essencial para operacionalizar e escalar nossa plataforma de dados, garantindo eficiência, segurança e alinhamento com as práticas de FinOps. Essa estrutura nos permite gerenciar, monitorar e automatizar processos de dados de ponta a ponta, desde a ingestão até a entrega, mantendo um alto padrão de governança e controle de custos. Atualmente, estamos trabalhando na simplificação dessa camada, pois, como mencionado anteriormente, acabamos com sobreposição de ferramentas provenientes das startups que adquirimos. As ferramentas que utilizamos são:

• Gitlab: Utilizamos não apenas como repositório de código, mas também para automações de pipelines através do GitLab CI. Seu uso é específico para os times que atendem ao produto Whitebook. Implementamos uma integração com o Jira, permitindo acompanhar todo o ciclo de desenvolvimento dentro dos cards e garantir a rastreabilidade completa dos commits realizados. Hoje utilizamos a versão Self Managed.
• Github: Possui o mesmo escopo do GitLab mencionado acima, mas ainda não implementamos integração com o Jira. Sua principal vantagem é o uso do GitHub Actions, que oferece uma ampla gama de integrações nativas com o DBT, facilitando a automação de nossos pipelines de dados. Dado seu robusto ecossistema e funcionalidades avançadas, estamos considerando o GitHub como nossa ferramenta principal de versionamento de código a médio prazo.
• Kibana: Integrado à infraestrutura PaaS fornecida pelo Snowplow, sendo utilizado prioritariamente para o acompanhamento de eventos capturados pelos Snowplow em tempo real. Seu uso é essencial para a validação por parte dos times de engenharia e análise de dados, bem como pelo time de engenharia de software e QA.
• Grafana: Principal ferramenta de observabilidade do time de engenharia de dados. Possuímos painéis para monitorar a qualidade dos dados como a proporção de bad datas gerado para o Snowplow, que podem indicar problemas em features implementadas nos produtos ou portais. Também temos visões detalhadas sobre o uso e consumo de recursos da plataforma. Em caso de anomalias, um canal de alerta no Slack notifica imediatamente nossa equipe para uma rápida intervenção.
• EKS (Elastic Kubernetes Service): Introduzido em nossa plataforma de dados no final de 2023, permitindo a utilização do Kubernetes. Anteriormente, os contêineres eram gerenciados dentro de EC2 (Elastic Compute Cloud), no entanto, com essa nova arquitetura conseguimos um uso mais eficiente dos recursos, maior escalabilidade e melhor gerenciamento das cargas de trabalho. Todas as aplicações são implantadas via Helm, uma ferramenta de gerenciamento de pacotes para Kubernetes, que facilita a instalação e atualização de aplicações.
• ArgoCD: Com a implementação do Kubernetes utilizando o EKS, foi necessário termos uma ferramenta robusta para o gerenciamento de pods e a automação das implementações. Seu papel é garantir que nossas aplicações estejam sempre em conformidade com as configurações definidas nos repositórios de código. Ele oferece uma monitoração contínua do estado atual das aplicações, sincronizando automaticamente com o estado desejado.
• Terraform: Para garantir um controle rigoroso sobre as alterações em nossa arquitetura, utilizamos o Terraform como ferramenta de infraestrutura como código, principalmente por ser agnóstica em relação à nuvem que estamos utilizando. Essa ferramenta assegura que todas as modificações na nossa infraestrutura sejam documentadas e rastreáveis, com exceção da parte de redes, que optamos por não gerenciar via Terraform. Outra exceção são os componentes da infraestrutura PaaS do Snowplow, que também são gerenciados via Terraform, mas por eles.
• Slack: Nossa principal ferramenta de comunicação, apesar do uso corporativo do Microsoft Teams na Afya. Além dos canais tradicionais de comunicação entre os times de dados, utilizamos automações com Webhooks no Slack para receber alertas proativos sobre qualquer instabilidade em nossa plataforma.

Com uma plataforma de dados moderna e robusta, a Afya continua a inovar e melhorar seus produtos digitais, Whitebook e iClinic. Através da adoção de tecnologias avançadas e práticas recomendadas, como EKS, SageMaker, DBT e Terraform, estamos construindo uma infraestrutura escalável, segura e eficiente. Além disso, estamos constantemente revisando a nossa plataforma.

Agradeço a sua atenção e espero que este artigo tenha contribuído para o seu conhecimento sobre o tema, principalmente na busca de benchmarks de como grandes empresas cuidam da sua plataforma de dados. Caso tenham alguma sugestão, crítica ou elogio, peço que entrem em contato comigo pelo LinkedIn.

Agora se você deseja fazer parte do maior ecossistema médico do país, com as mais avançadas tecnologias de dados e em um ambiente propício à inovação, vem pra Afya!