Francisco Candeias

Hoje em dia, a maior parte das empresas têm necessidades relacionadas com dados. A forma como esses dados são tratados e geridos têm muitos processos que, a certo ponto, podem sobrecarregar a capacidade de trabalho. Às vezes, enquanto trabalham com dados, os seus colaboradores, especialmente developers, vêem-se a desenvolver os mesmos processos ou pipelines de dados para diferentes projetos. É, por isso, que a necessidade de uma estrutura como uma framework é tão importante.

Com ela, é possível ter processos padrão de forma a que possa controlar e monitorizar melhor todos os pipelines de dados. Esta abordagem ajuda a estabelecer as melhores práticas e evita tornar data lakes em data swamps, enquanto mantém lógicas de negócio independentes e específicas para cada pipeline,  o que quer dizer que poderá lidar com cada data set de forma única e retirar o máximo partido.

Existem alguns passos para uma framework trabalhar bem. Descubra quais:

A ingestão de dados é uma etapa crucial em qualquer pipeline de processamento de dados e deve ser replicada várias vezes para reunir todos os dados necessários. Ao usar uma framework bem projetada para garantir que os dados sejam extraídos com eficiência de várias fontes e carregados no armazenamento de dados de destino, pode garantir que sabe sempre quantas linhas foram importadas, onde os dados foram colocados e garantir que tem um processo conciso e robusto com um único ponto de mudança para lidar com mudanças futuras.

Normalmente, a framework de ingestão de dados extrai dados de diferentes fontes, como bancos de dados do SQL Server, ficheiros .csv, etc. que podem ser carregados no armazenamento em nuvem, como Azure Data Lake Storage (ADLS) Gen 2, por exemplo. Esta etapa é onde as conexões de fontes de dados são feitas e onde os dados são preparados para serem ingeridos num armazenamento. Além disso, é nesta etapa que é configurada a lógica de carregamento, seja full load ou incremental. Basicamente, significa que pode processar todos os dados sempre que houver uma execução ou processar apenas novos dados.

Manter os dados brutos no armazenamento significa que, para a próxima etapa, que é o processamento, todos os dados estarão disponíveis, mesmo que não sejam usados imediatamente, o que significa que mais tarde poderá aproveitar os campos não utilizados e obter um controlo de dados abrangente.

Transformar dados em tabelas estruturadas é uma etapa crítica no processo analítico. Depois de o processo de ingestão de dados ter corrido, a próxima etapa é processar e transformar os dados numa estrutura que possa ser usada para fins analíticos para obter uma análise de dados eficaz.

Esses pipelines de dados funcionam para limpar e manter a qualidade dos dados, realizar cálculos, especialmente aqueles que mais precisa que, normalmente são KPIs, e, ao fazer isso, dar alertas se algo correr mal durante a execução do processo. Embora a maioria das transformações sejam específicas para o modelo de negócios que está a ser processado, há tarefas lógicas que serão recorrentes, como monitorizar a qualidade e a execução dos dados ou, até mesmo, excluir dados para reprocessamento.

Essas tarefas recorrentes podem ser padronizadas, permitindo que os engenheiros de dados encaixem facilmente qualquer lógica de negócio específica no processo.

Vamos usar o exemplo do Azure Synapse. Após a ingestão de dados, eles são acedidos usando tabelas externas que lêem a diretoria ADLS Gen2, onde os ficheiros para uma tabela específica são armazenados. Para processar e transformar dados, dois tipos de pipelines de processamento podem ser desenvolvidos:

• um para criar dimensões;
• outro para criar tabelas de factos.

Ambos os processos utilizam a ferramenta Data Flow do Synapse, que é uma ferramenta de transformação de dados baseada na cloud, que permite aos utilizadores criar e gerir operações de transformação de dados em larga escala.

Quando o fluxo de dados é concluído, o resultado é uma tabela SQL que é gravada no Synapse Dedicated Pool. Essas tabelas podem ser usadas para soluções de analytics, como dashboards de Power BI, que inclui uma ligação para o Synapse Dedicated Pool que permite aos utilizadores importar tabelas ou fazer consultas diretas.

Exemplo simples de processamento de uma tabela de factos, utilizando um data flow

O Azure DevOps é um conjunto de tecnologias que oferece uma solução completa para desenvolvimento agile e DevOps. Este conjunto contém inúmeras tecnologias que podem auxiliar os developers na gestão de todo o processo de desenvolvimento, incluindo controlo de versões, integração contínua e entrega contínua. Independentemente da abordagem de desenvolvimento, aproveitar vários ambientes é uma prática recomendada reconhecida pelo setor. Isto garante que qualquer informação criada é minuciosamente avaliada, tanto tecnicamente quanto pelos business users, antes de ser tornada pública ou aplicada num contexto de produção.

Normalmente esses ambientes são Desenvolvimento, Testes ou Garantia de Qualidade (QA) e Produção. No ambiente de desenvolvimento, os engenheiros de dados desenvolvem e constroem pipelines. Quando esses pipelines estão num estado funcional e estável, eles são promovidos para o ambiente de QA, onde os oututs podem ser testados pelos utilizadores finais e/ou developers. Se nenhum desenvolvimento adicional for necessário, os pipelines podem ser enviados para Produção.

Embora os pipelines de dados sejam desenvolvidos de forma diferente do código, isso não significa que deve deixar DevOps de fora. Num workspace do Azure Synapse Analytics, a ferramenta de Integração Contínua/Entrega Contínua (CI/CD) move todas as entidades de um ambiente (desenvolvimento, QA, produção) para outro ambiente. Esses modelos serão usados para enviar os seus recursos para os ambientes de QA e Produção.

Esta abordagem oferece várias vantagens:

• Em primeiro lugar, minimiza o impacto das alterações de outras equipas/developers;
• Em segundo lugar, o tempo de inatividade e o risco são minimizados se o desenvolvimento e os testes forem feitos dentro de ambientes dedicados.
• Por fim, a segurança e as permissões podem ser restritas a cada ambiente para reduzir o risco de erro humano, perda de dados e proteger dados confidenciais.

A monitorização é outra parte crucial da framework do Synapse e, para auxiliar essa área, existe a ferramenta Azure Monitor. Usando o Kusto Query Language (KQL), é possível consultar logs quase em tempo real e configurar alertas por e-mail que o administrador do espaço de trabalho Synapse receberá sempre que uma execução de pipeline falhar.

A framework também é capaz de armazenar os logs do Azure Monitor num contentor ADLS Gen2 para manter os dados históricos e consumi-los no Power BI e criar um relatório sobre esses logs. Os logs incluem estatísticas de execução e mensagens. As fases de ingestão e processamento da framework reúnem estatísticas funcionais de execução e guardam-nas também nos logs.

O Power BI é, então, usado para fazer análises ad hoc para entender, por exemplo, que pipelines podem demorar mais, se houve algum desvio nas linhas processadas ou outras estatísticas funcionais, qual deles falha com mais frequência, entender quando o dedicated pool está a atingir o limite de uso ou até criar combinações onde o número de linhas processadas é dividido pelo tempo para entender se o processo demorou mais que o normal.
Implementar o Azure Monitor, ajuda a minimizar riscos, melhorar a qualidade dos processos e garantir que os pipelines funcionam como o esperado.

Ter uma framework para os seus pipelines de dados é realmente uma vantagem, pois fornece padronização e escalabilidade. Ter uma framework que executa todos os seus pipelines de dados torna todo o processo mais simples e eficiente porque os seus developers não precisam de perder tempo a definir propriedades para cada pipeline individualmente todas as vezes que mudam o seu ambiente de trabalho, por exemplo, de desenvolvimento para QA. Ter um lugar onde tudo corre dá mais controlo sobre a qualidade do processo, e dá mais poder para monitorizar tudo corretamente. Assim, quando surge um problema, os seus developers são alertados pela framework e podem verificar os logs necessários para entender o que aconteceu e resolver erros mais rapidamente.

Além disso, imagine ter de escalar todos os seus pipelines de dados um a um. Com a framework, poderá escalar todos de uma só vez, apenas alterando as propriedades da framework, em vez de alterar cada pipeline individualmente.