Fundamentos da Engenharia de Dados

Uma pessoa que deseja ingressar na carreira de engenharia de dados certamente irá se deparar com inúmeras fontes de conteúdo que podem deixar o caminho um pouco confuso por alguns motivos como:

• Pesquisas sobre o assunto endereçam muito a materiais sobre ferramentas como Spark, Airflow, Python, SQL, etc.;
• As áreas e carreiras relacionadas a dados vem crescendo muito por conta do big data e as definições muitas vezes não ficam muito claras (mistura-se muita coisa de engenharia, análise, ciência de dados, machine learning, etc.);
• As pessoas que atuam na área podem viver contextos diferentes, pois as empresas podem ter visões diferentes sobre as funções de um engenheiro de dados;

Então, um ponto focal unânime sobre como ingressar bem nessa carreira é conhecer e ficar bom nos assuntos fundamentais, aqueles que trazem a base para qualquer segmento dentro da carreira de engenharia de dados.

Nesse texto, gostaria de compartilhar um pouco de minhas anotações sobre os fundamentos da engenharia de dados, de forma que possa ajudar quem esteja começando, a entender alguns assuntos, conceitos e terminologias ou apenas ajude a formar um índice sobre os assuntos fundamentais.

Espero que tenham uma ótima leitura!

Um pouco sobre OLTP

Esse conceito é importante porque representa uma forma antiga muito conhecida dentro da área de TI de gerenciamento de dados que ficou consolidada durante muitos anos, é utilizada nos dias atuais e serve como fonte de dados para diversas tarefas que um engenheiro de dados realiza.

OLTP é o conceito que define o uso de banco de dados relacional para realização de processamento de leitura, escrita e atualização de dados em grande escala de forma transacional (garantia de que um processamento sendo realizado por um usuário X não interfira em outro processamento realizado por usuário Y), online e atômico (garante que um conjunto de transações interligadas sejam concluídas com sucesso ou nenhuma delas é efetivada).

É difícil imaginar um sistema computacional comercial que não utilize um OLTP, pois, a grande maioria tem em sua arquitetura um banco de dados relacional para gerenciar o processamento de suas informações.

Um OLTP engloba algumas características que são importantes para um sistema como:

• Ter um banco de dados relacional unificado organizado em tabelas que possuem atributos e podem se relacionar entre si;
• Definir algumas regras de negócio nas tabelas, afim de ter um controle e organização das informações no banco de dados;
• Disponibilizar características essenciais de processamento (leitura, escrita e atualização) de forma segura e organizada;
• Possuí integração com diversos ecossistemas já consolidados no universo da TI, diversas ferramentas já maduras para o trabalho, além de muita literatura e conteúdo;

Entendendo que o OLTP possuí muitos dados relacionados ao negócio de uma empresa e que hoje a utilização de dados está cada vez mais rápida e volumosa, aparecem algumas desvantagens nesse sistema porque OLTP não foi desenhado para atender uma frenética carga de operações ao mesmo tempo e nem é otimizado para realizar análises.

E nos dias atuais existe a necessidade de que os dados estejam otimizados para análises e estejam preparados para serem consumidos e utilizados de diversas formas estratégicas, onde, muitas operações de leitura são realizadas e muitas pessoas interessadas em alavancar os negócios, criar oportunidades e entender as informações obtidas através dos dados querem trabalhar.

E então surge a necessidade de uma outra estratégia que engloba leitura constante e análise de dados para qual o OLTP não está preparado.

Nesse cenário, existe um importante tipo de profissional que lida com a resolução dessa necessidade, já sabe que profissional é esse ?

Uma pequena lupa no conceito de ACID

Todos os bancos relacionais são projetados para implementar o conceito denominado ACID (Atomicidade, Consistência, Isolamento e Durabilidade).

• Atomicidade: Garantia de que toda operação dentro de uma transação seja efetivada por completo, se algum processo ali dentro da transação falhar, nada é efetivado, em resumo é tudo ou nada, por exemplo, em um sistema de vendas, se toda vez que uma venda é efetivada, preciso inserir os dados da venda e dar baixa no estoque, se alguma dessas operações que fazem parte da mesma transação falhar, nenhuma operação deve funcionar.
• Consistência: Garantia de que uma transação seja realizada de acordo com o estado em que os dados se encontram no banco, por exemplo, uma operação de baixa no estoque que retirará 1 produto do estoque de 50, tem que ser garantida e o estoque deve diminuir para 49.
• Isolamento: Garantia de que 2 usuários do banco de dados não realizem transações (que possam interferir na atomicidade e consistência) ao mesmo tempo que geralmente são inserção e atualização, é criado um bloqueio para isolar uma transação e só libera o banco para novas transações assim que a outra terminar.
• Durabilidade: Garantia de que toda operação realizada no banco de dados que foi efetivada seja permanente, ou seja, o banco de dados é um local de armazenamento, é preciso garantia de que os dados estarão lá.

O conceito de ACID rege a implementação dos bancos de dados relacionais, a garantia desses 4 tópicos é o que norteia toda a estrutura de um sistema OLTP.

Em decorrência desses tópicos, existe também um conceito interessante dos bancos de dados relacionais que é o multi-versionamento.

Quando um usuário solicita uma operação de leitura, ou seja, realiza uma consulta no banco de dados, ele espera que o retorno sejam os dados mais atualizados possíveis, e se ele faz uma consulta no momento em que está ocorrendo uma transação de inserção, deve-se esperar toda a transação ocorrer para retornar a consulta ?

Nesse caso existe o conceito de multi-versionamento, onde criasse uma réplica do estado mais atual do banco antes do inicio da transação de inserção e a consulta recebe o retorno com maior performance sem esperar o término da transação que estava ocorrendo ao mesmo tempo da consulta.

Exemplos de banco de dados relacionais: MySQL, PostgreSQL, SQL Server, OracleDB, etc.

Uma solução para deficiência do OLTP: OLAP

Vimos que o OLTP é um sistema desenhado para lidar bem com e garantir o conceito de ACID e que ele não foi desenhado para prática de análise de dados.

Nos dias atuais, análise de dados é um tema extremamente quente e poderoso, pois, é através das análises que podemos trazer utilidade para os dados que são chamados hoje de "o novo petróleo".

Como os sistemas OLTP possuem diversas tabelas que se relacionam entre si e é um modelo que persiste os registros em forma de linhas (cada linha é um registro e possuí diversas colunas), na medida em que as consulta de análises vão ficando mais complexas buscando colunas especificas de registros que possuem N relacionamentos, a performance vai ficando mais baixa, as consulta são lentas e fica cada vez mais difícil de trazer os insights necessários.

Então surgiu o conceito de OLAP, que são sistemas desenhados para o trabalho analítico.

OLTP = Operacional, ACID.
OLAP = Analítico, colunar.

Os sistemas OLAP possuem a estrutura de armazenamento colunar

E como OLAP não é operacional, de onde vem os dados já que as interações de registros ficam em sistemas OLTP ?

Os dados vem justamente do OLTP (podem vir de outros lugares também) através de um sistema de pipeline que faz diversas consultas no OLTP e abastece o sistema OLAP de acordo com a necessidade dos analistas de dados.

Esse trabalho de trazer os dados para o OLAP é uma das responsabilidades do Engenheiro de Dados.

Conhecendo o conceito de ETL

Vimos que existe um processo que conecta os sistemas OLTP com os sistemas OLAP.

Esse processo é chamado de ETL, significa extrair, transformar e carregar (extract, transform, load).

O engenheiro de dados projeta esse processo de forma que faça as consultas necessárias para extrair os dados do OLTP e então existe um trabalho de transformar os dados para deixar de acordo com as necessidades das áreas de análises e então carregar os dados para os sistemas OLAP.

Esse processo é realizado de tempos em tempos (ex: 6h em 6h), para não sobrecarregar os sistemas OLTP.

A ideia é utilizar alguma ferramenta que possibilite realizar um trabalho agendado de tempos em tempos e outras ferramentas que auxiliam nos trabalhos de extração, transformação e carregamento.

Diferenças entre Engenharia de dados e Ciência de Dados

Apesar de fazer parte de um mesmo contexto (Dados e Big Data), entendo que são duas funções diferentes e complementares.

O Engenheiro de Dados trabalha para construir uma base sólida de recursos para que o Cientista de Dados possa atuar.

Sendo o engenheiro responsável por trabalhos de coleta, armazenamento, exploração e transformação de dados e o cientista encarregado de análises, identificação/rotulagem, treinamento de modelos, utilizar inteligência artificial para lidar com dados, etc.

Data Warehouse

Data Warehouse é o conceito que representa o nosso armazém de dados que é um conjunto grande de dados destinado à análises.

O Data Warehouse é um representante do sistema OLAP.

Estando na ponta de saída dos processos de ETL, o data warehouse recebe os dados que foram extraídos dos sistemas OLTP, transformados, modelados em estratégias específicas (ex: star schema ou snowflake schema) para otimizar as características de análises.

Como Data Warehouse é um conceito, é possível definir banco de dados tradicionais como um, aplicando-se características que representem um OLAP, porém, existem muitas tecnologias especificas e otimizadas para isso como Amazon Redshift, Snowflake, Oracle ADW, Google Big Query, etc.

Data Lake

Com o grande volume e variedade de dados sendo gerados o tempo todo, as organizações estão lidando com dados originados de seus próprios sistemas e/ou sistemas externos.

Existe alguns tipos de dados como:

• Dados estruturados: Dados que tem um modelo definido e consistente, são dados que vem de sistemas de banco de dados relacional;
• Dados semiestruturados: Possuem uma estrutura livre, como XML ou JSON;
• Dados não-estruturados: São arquivos, imagens, áudios, que são dados que não possuem uma estrutura definida, não tem colunas, registros, etc.;

*Quando as organizações lidam com inúmeros fontes e tipos de dados, surge a necessidade de manter um estoque destinado apenas a armazenamento em que não seja necessário preocupação com algum tipo de processamento no primeiro momento.

Dessa forma, na medida em que for necessário, os analistas, engenheiros, cientistas vão poder recuperar esses dados e dar um devido processamento.

Surge a ideia de utilizar um disco de armazenamento que recebe arquivos (dumps de banco de dados, imagens, json, csv, txt, xml, etc.) e vão acumulando esses dados como um estoque.

Esse disco, onde estão armazenados arquivos que representam diversos dados vindos de diversas fontes recebe o nome de data lake.

Exemplos famosos de sistemas utilizados para data lake (amazon s3, google cloud storage, blob storage).

Governança de Dados

Uma organização que mantêm estruturas de big data certamente precisará de uma forma de manter o suporte necessário para que os donos dos dados (quem produz o dado) consiga utilizar os dados de acordo com a proposta do negócio.

A infraestrutura de TI é responsável por todo o sistema de frameworks e suporte para que os usuários e aplicações possam gerar e utilizar os dados, porém, a infra estrutura de TI não é dona dos dados.

Algumas diretrizes de governança de dados comumente aplicadas: catalogação de dados, definir e manter a qualidade dos dados, implementar politicas de privacidade e segurança, etc.

Computação Distribuída

A computação distribuída é um conceito relevante porque atualmente com o grande volume e variedade de dados transitando fica dificil lidar com o processamento desses dados em servidores com escala vertical porque todo o trabalho fica concentrado em uma única máquina.

A ideia de dividir para conquistar é muito interessante para esse contexto, distribuindo o volume em diversos servidores é possível trabalhar com o processamento de dados paralelamente.

A maioria dos serviços modernos (em cloud principalmente) utiliza os conceitos de computação distribuída.

Existem alguns conceitos que as tecnologias de computação distribuída conseguem implementar como processamento paralelo que favorece o processamento de um grande volume de dados, redundância de armazenamento para garantir consistência e/ou alta disponibilidade.

Referências

A maior parte desse texto foi baseado nos estudos do treinamento de Fundamentos da Engenharia de Dados disponível na comunidade The Plumbers

E um pouco do livro Fundamentals of Data Engineer