Governança de dados: Engenharia e Qualidade de dados

Qualidade de dados como estratégia organizacional - Introdução

Apresentando o curso e o contexto

Olá! Bem-vinde ao curso de qualidade e engenharia de dados.

Neste curso, adotaremos um enfoque diferente sobre a qualidade dos dados. Nós trabalhamos em um banco chamado Banco Pantanal, que está investindo fortemente em transformação digital. Dentro dessa transformação, a principal estratégia relacionada a dados é utilizá-los para tomar melhores decisões.

Implementando o Data LakeHouse e planejando a qualidade de dados

Para isso, vamos construir — ou a equipe de dados foi orientada a construir — um Data LakeHouse (arquitetura unificada de dados).

Durante os testes das capacidades do nosso Data LakeHouse (arquitetura unificada de dados) para entregar dados com qualidade, identificamos alguns problemas.

A partir disso, precisamos entender como, dentro do sistema e das limitações que temos, podemos criar diversas iniciativas para garantir a qualidade dos dados de ponta a ponta: definir responsabilidades, estabelecer como vamos assegurar a qualidade desde a saída na fonte até a chegada ao Data LakeHouse (arquitetura unificada de dados) e determinar a melhor forma de fazer isso. É exatamente isso que vamos fazer neste curso.

Qualidade de dados como estratégia organizacional - Estratégia-decisoes orientadas por dados

Apresentando o curso e os objetivos

Vamos iniciar o nosso curso sobre qualidade e engenharia de dados. Trataremos das influências e responsabilidades das áreas envolvidas com a qualidade de dados: a própria área de Qualidade de Dados, quando existente, a área de Governança de Dados e a Engenharia.

Para começar, precisamos entender onde vamos trabalhar, qual é a empresa que vamos apoiar e como vamos tratar a questão da qualidade de dados dessa empresa. Vamos ao nosso caso de negócio.

Contextualizando o banco e a transformação digital

Trabalharemos em um banco predominantemente físico e regionalizado que definiu fortalecer a plataforma digital como estratégia de expansão no Brasil. Como veremos adiante, trata-se de um banco bastante regional do Centro-Oeste, que reconheceu a dificuldade de competir diretamente com os grandes bancos brasileiros. Entretanto, ao adotar uma opção digital, pode conquistar mercados com custo menor. Para isso, será necessário passar por uma transformação digital, e é justamente esse o foco do nosso trabalho aqui.

Sobre o Banco Sertanejo, já se passaram dois anos desde o início dessa transformação digital, quando foi definida a migração para o ambiente digital. O banco opera mais de 60 sistemas legados e transacionais, a maioria deles on-premises (no local), com servidores que hospedam bancos de dados responsáveis por processar, por exemplo, o pagamento de salários de clientes e transferências via PIX, entre outros. Está em curso também a transformação desses sistemas legados on-premises (no local) para alguns sistemas em nuvem. Este é o contexto geral de como a empresa opera.

Enfatizando a estratégia orientada por dados

O ponto mais importante para nós é que o Banco Sertanejo definiu o uso de dados como parte fundamental da sua estratégia. Em busca de maior eficiência estratégica e visando habilitar iniciativas de IA, o investimento em transformação digital foi direcionado de forma significativa para a área de dados. A ideia é que nós possamos usar os dados já existentes na instituição para tomar melhores decisões, isto é, decisões orientadas por dados.

Há, portanto, uma concentração de esforços e investimentos, envolvendo diversas áreas, para garantir que isso aconteça.

Detalhando a estratégia e o data lakehouse

Para que isso seja, de fato, implementado, adotamos uma estratégia dividida em quatro pontos.

Vamos iniciar pelo canto superior direito. Nesse canto, temos o Data Lakehouse (arquitetura unificada de lago e armazém de dados), que é uma infraestrutura unificada de armazenamento de dados que também pode ser utilizada para análises. Todos os dados da organização que vinham do sistema on-premises (no local) devem ser concentrados em uma única plataforma de dados, o Data Lakehouse. Essa plataforma realizará tanto o armazenamento dos dados quanto a facilitação das análises.

Para que o Data Lakehouse seja implementado, de fato, foi criada uma diretoria de dados, que estabelecerá a liderança e a governança para todas as iniciativas de dados. De outro lado, temos os objetivos que gostaríamos de alcançar: análises avançadas, insights (percepções) profundos, realização de previsões com algoritmos de Data Science (ciência de dados), utilização de implementações de IA e garantia de decisões orientadas por dados para melhorar a tomada de decisão em todos os níveis da organização — operacional, tático e, principalmente, estratégico.

Definindo o escopo, as equipes e próximos passos

Quanto ao nosso escopo de atuação, trabalharemos dentro dessa diretoria de dados, que foi dividida em cinco grandes áreas, isto é, cinco equipes:

• Equipe de governança de dados, responsável por estabelecer políticas para garantir qualidade, segurança e privacidade.
• Equipe de engenharia de dados, que coleta e integra dados de diversas fontes para o Data Lakehouse.
• Equipe de qualidade de dados, que assegura que os dados sejam seguros, precisos e confiáveis.
• Equipe de engenharia de Analytics (análises), responsável por criar visualizações com dados, utilizando Power BI ou qualquer outra ferramenta de Business Intelligence (inteligência de negócios).
• Equipe de plataforma de dados, uma equipe enxuta que trabalha muito próxima da engenharia.

Esse é o espaço onde trabalhamos dentro da empresa. Especificamente, vamos atuar ora como e com as pessoas de governança de dados, como e com as pessoas de engenharia e como e com as pessoas de qualidade de dados.

Tudo isso é uma introdução para compreendermos melhor onde vamos trabalhar dentro dessa organização. Na próxima aula, vamos fazer um deep dive (imersão aprofundada) no que é um Data Lakehouse e falar também sobre a arquitetura dessa solução.

Qualidade de dados como estratégia organizacional - Entendendo a arquitetura do Data LakeHouse

Contextualizando a empresa e a estratégia de dados

Na última aula, discutimos em qual empresa vamos trabalhar e descobrimos que é o Banco Pantanal, um banco regional focado no Centro-Oeste brasileiro, que optou por uma plataforma digital mais ampla como estratégia de expansão para outras regiões do Brasil. Para isso, foi realizada uma transformação digital abrangente, e um dos focos dessa transformação é garantir que possamos tomar melhores decisões, neste caso, decisões baseadas em dados. Para atingir esse objetivo, foi criada uma diretoria de dados e, para viabilizá-lo, nós estamos implementando um Data Lakehouse (arquitetura de lago de dados e armazém de dados).

Como o Data Lakehouse (arquitetura de lago de dados e armazém de dados) é um conceito específico, hoje vamos entender detalhadamente o que ele é, como isso afeta a arquitetura e como vamos trabalhar com os dados dentro da organização. Basicamente, um Data Lakehouse (arquitetura de lago de dados e armazém de dados) é uma das principais arquiteturas atuais para armazenamento de dados em um ambiente analítico.

Diferenciando os ambientes transacional e analítico

Vale conceituar brevemente o que é o ambiente analítico. Nas empresas, normalmente temos dois ambientes: o ambiente transacional, onde de fato ocorrem as transações, e o ambiente analítico, que copia os dados de forma separada, fornecendo mais liberdade e segurança para trabalharmos com esses dados.

Vamos a um exemplo. No nosso banco, todos os dados de PIX dos clientes precisam estar armazenados em bases muito precisas e confiáveis. Se déssemos acesso direto a essas bases e alguém realizasse muitas consultas, ou consultas muito complexas, poderíamos sobrecarregar a memória desse banco de dados e provocar lentidão na operação do PIX — algo que definitivamente não queremos. Uma das formas que as organizações utilizam hoje para não sobrecarregar o sistema transacional é criar uma cópia dele orientada à parte de analytics (análise de dados), isto é, ao uso analítico e organizacional dos dados.

Por que isso é tão importante? Primeiro, bases de dados transacionais não estão otimizadas para leituras; elas são otimizadas para operações de escrita, para registrar novas transações. Já os sistemas orientados ao ambiente analítico são mais eficientes em leituras e em disponibilizar dados para consumo. Além disso, ao isolar os ambientes, garantimos que nenhuma pessoa interessada apenas em análise consiga alterar qualquer dado em produção — o que seria especialmente crítico no caso de um banco. Essa é uma estratégia adotada por muitas empresas e que facilita, ou instrumentaliza, a criação de um ambiente informacional robusto.

Apresentando a arquitetura e os benefícios do Data Lakehouse

O Data Lakehouse (arquitetura de lago de dados e armazém de dados) contará com uma camada de armazenamento de dados que, especificamente neste caso, utilizará uma arquitetura de medalhão: três camadas com distintos níveis de tratamento de dados. Isso nos permitirá realizar análises avançadas, utilizar machine learning (aprendizado de máquina) e outras ferramentas de data science (ciência de dados), como processamento de linguagem natural, além de outras formas de trabalhar com esses dados que serão importantes para a tomada de decisões no futuro.

Além disso, o Data Lakehouse (arquitetura de lago de dados e armazém de dados) facilitará a acessibilidade aos dados, já que eles estarão segregados do ambiente transacional, o que torna mais simples garantir o acesso. Lembrando que, especialmente em bancos, vimos que este banco operava com mais de 60 sistemas distintos; suponhamos que seis deles sejam voltados para vendas. Se quisermos autorizar uma pessoa do nosso time de análise de dados a visualizar essas informações, precisaríamos conceder acesso em seis sistemas diferentes. A gestão desse permissionamento se torna bastante complexa e passa a ser centralizada quando migramos para o Data Lakehouse (arquitetura de lago de dados e armazém de dados).

Essa arquitetura também é desenhada para crescer conforme as necessidades da empresa, pois conseguimos centralizar mais as ações e incorporar outros times, se necessário, para continuar evoluindo o trabalho.

Detalhando a arquitetura de medalhão e os processos ELT/ETL

Em resumo do que abordamos até aqui, isso é um Data Lakehouse (arquitetura de lago de dados e armazém de dados). Para sermos mais específicos, nós vamos detalhar a arquitetura de medalhão, um dos enfoques mais comuns ao trabalharmos com Data Lakehouses (arquiteturas de lago de dados e armazéns de dados) modernas. Qual é a ideia, então? Aqui nós vamos retomar os conceitos de ELT e ETL. ELT significa Extract, Load, Transform (Extrair, Carregar e Transformar) e ETL significa Extract, Transform, Load (Extrair, Transformar e Carregar).

Definimos o seguinte procedimento: vamos tomar a camada de dados brutos, que normalmente provêm de sistemas que são sistemas legacy (legado), e trazê-los para o Data Lakehouse (Data Lakehouse) na camada Bronze, exatamente como estão no sistema de origem. Supondo que exista um sistema de vendas, por exemplo, de seguros, vamos trazer os dados exatamente como estão. Assim, realizamos a carga dos dados para a camada Bronze, o que significa que a camada Bronze é fiel aos dados do sistema transacional; os dados são espelhados de forma um-para-um.

Em seguida, teremos a camada Silver, dedicada à harmonização desses dados e à garantia de um nível de qualidade. Isso significa que, por exemplo, se houver uma definição muito clara do que é cliente, sabemos que todo cliente deve ter um identificador único. Podemos garantir que esse identificador único esteja correto na camada Silver, considerando que a camada Bronze apenas copia os dados da fonte. Outra ação possível é criar níveis de qualidade de dados nessa camada Silver, tema que abordaremos com mais profundidade nas próximas aulas.

Por fim, temos a camada Gold, a camada de uso e disponibilidade dos dados. Os dados da camada Silver estarão lá, prontos para que outras partes da organização os consumam. No entanto, se, em determinados casos, o time de marketing (marketing) estiver interessado nos dados, ir diretamente à camada Silver pode não fazer tanto sentido. Como diferentes áreas — por exemplo, marketing (marketing) e compliance (conformidade) — terão visões distintas sobre os dados de vendas, a ideia é que nós, quando necessário para realizar uma análise específica, levemos os dados para a camada Gold, aplicando as modificações que o negócio exigir. A partir da camada Gold, colocaremos esses dados à disposição. Nesse momento, os dados estão prontos para consumo. É assim que funciona a arquitetura de medalhão.

Descrevendo o plano de execução e as responsabilidades dos times

Agora que já sabemos por onde vamos navegar, qual é a arquitetura que utilizaremos nesta empresa e qual é o background (contexto) da organização de maneira mais geral, recebemos uma missão como parte da diretoria de dados. Temos aproximadamente dois meses para comprovar que é possível tomar melhores decisões baseadas em dados e, para isso, precisávamos executar algumas ações. Estamos chegando ao final desse prazo.

O primeiro passo foi coletar os dados de vendas desses sistemas legacy (legado) — ao todo 60 sistemas. Precisamos criar integrações para todos eles, a fim de trazer esses dados para dentro do Data Lakehouse (arquitetura de lago de dados e armazém de dados) na camada Bronze.

Com os dados na camada Bronze, o segundo passo é a criação dos pipelines (fluxos de processamento), isto é, as conexões entre as camadas que vão transformar um pouco ou segregar esses dados conforme nossas necessidades. A criação dos pipelines (fluxos de processamento) foi o passo dois.

Na sequência, temos a implementação desses pipelines (fluxos de processamento). Por quê? Nesta empresa especificamente, a criação dos pipelines (fluxos de processamento) é responsabilidade do time de engenharia de dados, enquanto a implementação é responsabilidade do time de plataforma. Podemos, então, discutir o que é a plataforma de dados: trata-se da gestão de todos esses pipelines (fluxos de processamento) em conjunto e da definição das regras para a criação de um bom pipeline (fluxo de processamento) dentro da organização. O time responsável pela plataforma é quem entende esse ecossistema, nos provê toda a infraestrutura necessária para garantir que a arquitetura exista e, além disso, uma vez que os pipelines (fluxos de processamento) estejam em funcionamento, garante que um não interfira no outro, que tudo esteja em execução, que haja memória suficiente para todos os pipelines (fluxos de processamento) serem executados, que haja espaço de armazenamento para que os dados fiquem devidamente guardados e assim por diante.

Construindo o dashboard e identificando problemas de qualidade de dados

Agora que o time de plataforma já realizou a implementação dos pipelines (fluxos de processamento), vamos solicitar ao time de Analytics que crie um dashboard (painel). É exatamente nessa etapa que nos encontramos nesta semana. O time de Analytics está finalizando a criação do dashboard (painel) e, em alguns dias, faremos a apresentação para a diretoria.

Para isso, reunimos as lideranças, profissionais mais experientes de todas as áreas, como nós, e analisamos o processo como um todo. Observamos alguns problemas de qualidade nesses dados. Chegamos a convidar algumas pessoas do time de vendas para entender se esse dashboard (painel) realmente fazia sentido, já que elas conhecem as vendas da nossa organização, e começaram a apontar alguns pontos que não estavam corretos. Constatamos, portanto, problemas de qualidade de dados.

Esses problemas de qualidade acabaram tornando o dashboard (painel) pouco funcional para o que a diretoria precisava. Decidimos, então, pausar um pouco e, antes de apresentar os dados nesse estado, buscar entender como podemos garantir a qualidade desses dados. Falaremos mais sobre essa trajetória no próximo vídeo.

Sobre o curso Governança de dados: Engenharia e Qualidade de dados

O curso Governança de dados: Engenharia e Qualidade de dados possui 162 minutos de vídeos, em um total de 53 atividades. Gostou? Conheça nossos outros cursos de Governança de Dados em Data Science, ou leia nossos artigos de Data Science.

Matricule-se e comece a estudar com a gente hoje! Conheça outros tópicos abordados durante o curso:

• Qualidade de dados como estratégia organizacional
• Dissecando os problemas de qualidade de dados
• Acompanhando a qualidade no fluxo de dados
• Monitorando a qualidade de dados em todo o fluxo de dados
• Definindo atores, responsabilidades e prioridade