EAD-Governança de Dados-Unidade 03

Prévia do material em texto

Governança de Dados
Lauro de Freitas
Unidade 03
Arquitetura de Dados
Modelo de uma Arquitetura
Arquitetura de Dados Moderna
Fonte: https://sonra.io/data-warehouse/reference-enterprise-data-architecture-the-ultimate-
guide-to-architecting-data-warehouse-date-lakehouse-and-data-management-platforms/
Arquitetura de Dados Moderna
Fonte: https://adatis.co.uk/the-common-data-model-in-azure-data-lake-storage-azure-data-
services-data-factory-data-flow//
Arquitetura de Dados Moderna – 6 Layers
Fonte: https://www.montecarlodata.com/blog-what-is-a-data-platform-and-how-to-build-one/
Arquitetura de Dados Moderna
Fonte: https://www.montecarlodata.com/blog-what-is-a-data-platform-and-how-to-build-one/
Banco de Dados Relacional
Modelo Relacional
Fonte: Próprio autor
Modelo Dimensional
Fonte: Próprio autor
Normalização
• Normalização é uma ferramenta usada no projeto lógico que serve para reestruturar tabelas e atributos, reduzindo assim 
redundâncias e permitindo o correto crescimento do banco de dados. 
• O processo de normalização conta com 6 formas:
• 1° Forma Normal.
• 2° Forma Normal.
• 3° Forma Normal.
• FNBC (Forma normal de Boyce e Codd):
• 4° Forma Normal.
• 5° Forma Normal.
• A partir da 3° Forma Normal diz-se que o banco de dados já se encontra normalizado. A FNBC, a 4FN e a 5FN são usadas para 
refinar ainda mais o banco. 
Normalização
• Problemas de Inserção:
• Só é possível inserir um cliente se o mesmo adquirir um produto. Só é possível inserir um produto se algum cliente adquiri-lo.
• Problemas de alteração:
• Para atualizar o telefone do cliente ou o preço do produto, todos os outros registros deverão ser atualizados, ou seja, dado 
redundante. 
• Problemas de exclusão:
• Se os produtos adquiridos por algum cliente forem excluídos, os dados cadastrais referente a esse cliente se perderão.
Fonte: Próprio autor
Normalização
 1ª Forma Normal (1FN): toda relação deve ter uma chave 
primária e deve-se garantir que todo atributo seja atômico. 
Atributos compostos devem ser separados. 
Normalização
 2ª Forma Normal (2FN): toda relação deve estar na 1FN e deve eliminar dependências 
funcionais parciais, ou seja, todo atributo não chave deve ser totalmente dependente da 
chave primária. 
Normalização
 3ª Forma Normal (3FN): toda relação deve estar na 2FN e 
devem-se eliminar dependências funcionais transitivas, ou 
seja, todo atributo não chave deve ser mutuamente 
independente. 
Modelo Conceitual
Fonte: https://www.visual-paradigm.com/support/documents/vpuserguide/3563/3564/85378_conceptual,l.html
https://www.visual-paradigm.com/support/documents/vpuserguide/3563/3564/85378_conceptual,l.html
Modelo Lógico
Fonte: https://www.visual-paradigm.com/support/documents/vpuserguide/3563/3564/85378_conceptual,l.html
https://www.visual-paradigm.com/support/documents/vpuserguide/3563/3564/85378_conceptual,l.html
Modelo Físico
Fonte: https://www.visual-paradigm.com/support/documents/vpuserguide/3563/3564/85378_conceptual,l.html
https://www.visual-paradigm.com/support/documents/vpuserguide/3563/3564/85378_conceptual,l.html
Banco de Dados Relacional
• Os dados são estruturados de acordo com o modelo relacional.
• SQL Server, Oracle, PostgreSQL, MySQL, DB2 e outros.
• Elementos básicos
• Relações (tabelas) e registros (tuplas)
• Características fundamentais
 Restrições de integridade
 PK-primary key, FK-foreign key, UK-unique key, CK-check key, NN-not null
 Normalização (formas normais)
 Linguagem SQL (Structured Query Language)
Banco de Dados NoSQL
Banco de Dados Relacional
Fonte: https://www.guru99.com/nosql-tutorial.html
NoSQL
• NoSQL é um termo genérico que define 
bancos de dados não-relacionais.
• A tecnologia NoSQL foi iniciada por 
companhias líderes da Internet como 
Google, Facebook, Amazon e LinkedIn, 
para superar as limitações de banco de 
dados relacional para aplicações web 
modernas.
Fonte: https://openclassrooms.com/en/courses/5671741-design-the-logical-model-of-your-relational-database/6255746-compare-relational-and-
nosql-databases
NoSQL
• Não quer dizer que seus modelos não 
possuem relacionamentos e sim que 
não são orientados a tabelas. 
• Not Only SQL (não apenas SQL).
• Bancos de dados NoSQL são cada vez 
mais usados em Big Data e 
aplicações web de tempo real.
Fonte: https://www.filecloud.com/blog/2014/08/leading-nosql-databases-to-consider/
NoSQL - Características
• Escalabilidade horizontal.
• Ausência de esquema ou esquema flexível.
• Suporte a replicação.
• API simples.
• Nem sempre prima pela consistência.
Ausência de Esquema
• Ausência de esquema (Schema-free) ou esquema flexível é uma outra característica em bancos de 
dados NoSQL.
• Basicamente é a ausência parcial ou total de esquema que define a estrutura de dados. 
• É justamente essa ausência de esquema que facilita uma alta escalabilidade e alta disponibilidade, 
mas em contrapartida não há a garantia de integridade dos dados, fato este que não ocorre no 
Modelo Relacional.
Ausência de Esquema
Fonte: https://docs.treasuredata.com/display/public/PD/Schema+Management
Alguns Bancos NoSQL
• Aerospike: Banco de dados NoSQL que oferece uma vantagem de velocidade de memória, 
atraindo empresas de anúncios de alta escala e aquelas que precisam de tempos de 
resposta em milissegundo. Aerospike está apostando em novas categorias, incluindo jogos, 
e-commerce e segurança, onde a baixa latência é tudo.
• Apache Cassandra: Os pontos fortes são a modelagem de dados NoSQL e escalabilidade 
linear flexível em hardware por conta do uso de cluster.
• Amazon DynamoDB: foi desenvolvido pela Amazon para incrementar o seu e-commerce, 
possibilitando ter seus serviços altamente escaláveis. Inspirou o Cassandra, Riak, e outros 
projetos NoSQL.
Alguns Bancos NoSQL
• MongoDB: É o banco de dados mais popular NoSQL, com mais de sete milhões de downloads e 
centenas de milhares de implantações. Sua popularidade se deve à facilidade de 
desenvolvimento e manejo flexível dos dados. Muito utilizado em aplicações de redes sociais 
web e móvel.
• HBase: É o banco de dados que roda em cima do HDFS (Hadoop Distributed File System – 
sistema de arquivos distribuído), por isso dá aos usuários a capacidade única de trabalhar 
diretamente com os dados armazenados no Hadoop. As características incluem grande 
escalabilidade.
• Redis: É o banco de dados NoSQL do tipo chave-valor mais conhecido. No mercado podemos 
encontrar diversas outras soluções que também são mecanismos de armazenamento baseado 
em chave-valor.
Banco de Dados NewSQL
NewSQL
• Pode ser definido como uma classe de SGBDs relacionais modernos que buscam fornecer o 
mesmo desempenho escalonável do NoSQL para cargas de trabalho OLTP e, simultaneamente, 
garantir a conformidade ACID para transações como no RDBMS.
• Basicamente esses sistemas desejam alcançar a escalabilidade do NoSQL sem ter que descartar o 
modelo relacional com SQL e suporte a transações do DBMS legado.
Fonte: https://www.xenonstack.com/blog/sql-vs-nosql-vs-newsql
SQL, NoSQL ou NewSQL
Fonte: https://ganganichamika.medium.com/sql-vs-nosql-vs-newsql-c0d7cfe98f62
SQL, NoSQL ou NewSQL
Fonte: https://blog.devart.com/sql-vs-nosql.html
Alguns Bancos NewSQL
• MemSQL: Como o próprio nome sugere, é operado em memória, e é um sistema de banco de 
dados de alta escala por sua combinação de desempenho e compatibilidade com o SQL 
transacional e ACID na memória, adicionando uma interface relacional em uma camada de 
dados in-memory.
• VoltDB: Projetado por vários pesquisadores de sistema de banco de dados bem conhecidos, 
esse banco oferece a velocidade e a alta escalabilidade dos bancos de dados NoSQL, mas 
com garantias ACID, e sua latência em milissegundo e integração com Hadoop.
• SQLFire: Servidor de banco de dados NewSQL da VMware, desenvolvido para escalar em 
plataformas nas nuvens e tomar as vantagens de infraestrutura virtualizadas.
• MariaDB: foi desenvolvido pelo criador do MySQLe é totalmente compatível com o MySQL. 
Também pode interagir com os bancos de dados NoSQL, como Cassandra e LevelDB.
Modelos de Banco de Dados NoSQL
Modelos de NoSQL
Fonte: https://www.guru99.com/nosql-tutorial.html
Modelos de NoSQL
Fonte: https://www.guru99.com/nosql-tutorial.html
Modelos de NoSQL
• Temos quatro categorias do NoSQL:
• Chave-valor (key-Value)
• Orientado a Grafos
• Orientado a Coluna (Column Family)
• Orientado a Documentos
Fonte: https://www.guru99.com/nosql-tutorial.html
Chave-Valor (Key-Value)
• Modelo mais simples.
• Permite a visualização do banco como 
uma grande tabela.
• Todo o banco é composto por um conjunto 
de chaves que estão associadas a um 
único valor.
Fonte: https://neo4j.com/blog/why-nosql-databases/
Orientado a Grafos
• Este modelo possui três componentes básicos: 
• Nós (vértices dos grafos).
• Os relacionamentos (arestas).
• As propriedades (conhecidos também como 
atributos).
• É visto como um multigrafo rotulado e direcionado, 
onde cada par de nós pode ser conectado por mais de 
uma aresta. 
• A utilização deste modelo é muito útil quando é 
necessário fazer consultas demasiadamente 
complexas. 
• O modelo orientado a grafos possui uma alta 
performance, permitindo um bom desempenho nas 
aplicações. 
Fonte: https://neo4j.com/blog/why-nosql-databases/
Orientado a Grafos
• Imagine uma aplicação que mantêm informações relativas à viagem. Uma consulta pertinente seria: 
“Quais cidades foram visitadas anteriormente por pessoas que foram para Nova Iorque?”
• Temos diversas pessoas: João, Ricardo, Carolina, Maria, Fernando e Fábio que representam nós do 
grafo e estão conectadas a cidades que visitaram ou residiram. 
Orientado a Colunas
• Este tipo de banco de dados foi criado para 
armazenar e processar uma grande quantidade de 
dados distribuídos em diversas máquinas. 
• Aqui existem as chaves, mas neste caso, elas 
apontam para atributos ou colunas múltiplas.
• Os dados são indexados por uma tripla (coluna, linha 
e timestamp), a coluna e linha são identificadas 
por chaves e o timestamp permite diferenciar 
múltiplas versões de um mesmo dado. 
• Como o próprio nome sugere, as colunas são 
organizadas por famílias de colunas. Demonstra 
maior complexidade que o de chave-valor.
Fonte: https://neo4j.com/blog/why-nosql-databases/
Orientado a Colunas
• Podemos modelar o conceito de amigos, onde o primeiro 
nome e sobrenome são colunas pertencentes à família 
de colunas denominada “nome”. Da mesma forma, as 
colunas endereço, cidade pertencem à família local. 
• É interessante observar que na linha 001 a pessoa tem 
diversos endereços. Como a busca neste tipo de banco de 
dados é atômica, mesmo que o interesse seja buscar o 
primeiro nome da linha 001, todas as colunas serão 
retornadas quando esta mesma linha for consultada.
Orientado a Documentos
• Armazenam chave/valor.
• O valor é um documento estruturado e indexado, com 
metadados.
• Valor (Documento), pode ser consultado.
• JSON: JavaScript Object Notation.
• Feito para troca de dados.
• Mais compacto e legível que XML.
Fonte: https://neo4j.com/blog/why-nosql-databases/
JSON
• É um acrônimo de JavaScript 
Object Notation, e tem um 
formato compacto, de padrão 
aberto independente, de troca de 
dados simples e rápida entre 
sistemas, especificado por 
Douglas Crockford em 2000, que 
utiliza texto legível a humanos, no 
formato atributo-valor.
Fonte: Próprio autor
MongoDB
 Open source.
 Multiplataforma.
 Escalável.
 Orientado a documentos: JSON.
 Permite documentos aninhados.
 Indexados: pode-se buscar o conteúdo dos documentos.
 Não tem schema fixo.
 Não tem integridade referencial.
MongoDB - Definições
Fonte: http://netcoders.com.br/mongodb-aplicacoes-dotnet/
Arquitetura Banco de Dados NoSQL
Arquitetura Mongodb
• Arquitetura usando Sharding e ReplicaSet.
Fonte: https://www.linkedin.com/pulse/replication-vs-sharding-mongodb-zelalem-a-
enyew/?trk=articles_directory
Teorema CAP
• De acordo com o teorema CAP, um sistema 
distribuído de bancos de dados somente pode 
operar com dois desses comportamentos ao 
mesmo tempo, mas jamais com os três 
simultaneamente.
Fonte: https://www.yugabyte.com/blog/tag/cap-theorem/
Consistência Eventual
• É um conceito interessante derivado do 
teorema CAP.
• O sistema prioriza as escritas de dados 
(armazenamento), sendo o sincronismo 
entre os nós do servidor realizado em 
um momento posterior – o que causa 
um pequeno intervalo de tempo no qual 
o sistema como um todo é 
inconsistente. 
• Para isso, são implementadas as 
propriedades Disponibilidade e 
Tolerância a Partição.
Fonte: https://www.nexsoftsys.com/articles/CAP-theorem-database-
dbms.html
Consistência Eventual
• Exemplos de sistemas de bancos de dados que implementam a 
consistência eventual são o MongoDB, Cassandra e RavenDB 
(bancos NoSQL), entre outros. 
• Em Bancos Relacionais, é muito comum implementar as 
propriedades Consistência e Disponibilidade. Como exemplos, 
citamos os SGBDRs Oracle, MySQL, PostgreSQL, SQL Server e 
outros.
• Ao criar um banco de dados distribuído é importante ter em 
mente o teorema CAP. 
• Você terá de decidir se o banco será consistente ou disponível, 
pois bancos de dados distribuídos são sempre tolerantes a 
partição.
Escalabilidade Horizontal
• À medida em que o volume de dados 
cresce, aumenta-se a necessidade de 
escalabilidade e melhoria do 
desempenho. 
• Podemos escalar verticalmente 
(adicionar CPU, memória, disco) ou 
podemos escalar horizontalmente 
(adicionar mais nós).
Fonte: https://blog.router-switch.com/2021/03/what-is-the-difference-between-scale-up-and-scale-out/
Sharding
• O sharding, ou escalabilidade 
horizontal divide o conjunto de dados 
e os distribui por vários servidores ou 
shards. 
• Cada shard é um banco de dados 
independente e, coletivamente, os 
shards formam um único banco de 
dados lógico.
Fonte: https://www.mongodb.com/docs/v2.6/core/sharding-introduction/
Sharding
• Coleções fragmentadas (Sharding) e 
não fragmentadas (Non-Sharding).
• Um banco de dados pode ter uma 
mistura de coleções fragmentadas e 
não fragmentadas. 
• As coleções fragmentadas são 
particionadas e distribuídas entre os 
fragmentos no cluster. 
• As coleções não fragmentadas são 
armazenadas em um fragmento 
primário. Cada banco de dados tem 
seu próprio shard primário. Fonte: https://www.mongodb.com/docs/manual/sharding/
Sharding
Fonte: https://www.mongodb.com/docs/manual/sharding/
Replica Set
• Um conjunto de réplicas no MongoDB é um grupo de 
instâncias mongod que mantém o mesmo conjunto de 
dados. Ele contém vários nós de suporte de dados e, 
opcionalmente, um nó de árbitro.
• O nó primário recebe todas as operações de gravação 
e registra todas as alterações em seus conjuntos de 
dados em seu log de operação, ou seja, oplog.
• Os secundários replicam o oplog do primário e 
aplicam as operações a seus conjuntos de dados de 
forma assíncrona.
• Tendo os conjuntos de dados secundários refletem o 
conjunto de dados do primário, o conjunto de réplicas 
pode continuar a funcionar apesar da falha de um ou 
mais membros.
• Se a primária não estiver disponível, uma secundária 
elegível fará uma eleição para se eleger a nova 
primária. Fonte: https://www.mongodb.com/docs/manual/replication/
Replica Set
Fonte: https://www.mongodb.com/docs/manual/replication/
Sistema de Arquivos Distribuídos
Sistemas de Arquivos
• Foram originalmente desenvolvidos como um recurso do S.O 
que fornece uma interface de programação conveniente para 
armazenamento em disco.
• São responsáveis pela organização, armazenamento, 
recuperação, atribuição de nomes, compartilhamento e 
proteção de arquivos.
• Projetados para armazenar e gerenciar um grande número 
de arquivos, com recursos para criação atribuição de nomes e 
exclusão de arquivos.
Sistemas de Arquivos
• Diretório é um arquivo de tipo especial;
• Fornece um mapeamento dos nomes textuais paraidentificadores internos;
• Podem incluir nomes de outros diretórios.
Fonte: https://homepages.dcc.ufmg.br/~fsantos/ECO036/seminarios/sistemas_arquivos_distribuidos.pdf
Sistemas de Arquivos Distribuídos (DFS ou SAD)
• Um sistema de arquivos distribuídos permite aos programas 
armazenarem e acessarem arquivos remotos exatamente 
como se fossem locais, possibilitando que os usuários acessem 
arquivos a partir de qualquer computador em uma rede.” 
(COULOURIS, et. al, p. 284).
• Objetivo: permitir que os programas armazenem e acessem 
arquivos remotos exatamente como se fossem locais.
• Permitem que vários processos compartilhem dados por 
longos períodos, de modo seguro e confiável.
• O desempenho e segurança no acesso aos arquivos 
armazenados em um servidor devem ser compatíveis aos 
arquivos armazenados em discos locais.
Requisitos de um Sistemas de Arquivos Distribuídos
• Transparência.
• Atualização concorrente de arquivos.
• Replicação de arquivos.
• Heterogeneidade.
• Tolerância a falha.
• Consistência.
• Segurança.
• Eficiência.
Fonte: https://homepages.dcc.ufmg.br/~fsantos/ECO036/seminarios/sistemas_arquivos_distribuidos.pdf
Arquitetura do SAD
• Modelo abstrato de arquitetura que serve para o Network File 
System (NFS) e Andrew File Systen (AFS).
• Divisão de responsabilidades entre três módulos.
• Cliente.
• Serviço de arquivos planos.
• Serviço de diretórios.
• Design aberto
• Diferentes módulos cliente podem ser utilizados para 
implementar diferentes interfaces.
• Simulação de operações de arquivos de diferentes S.O.
• Otimização de performance para diferentes configurações de 
hardware de clientes e servidores.
Fonte: https://pt.wikipedia.org/wiki/Network_File_System
Sistemas de Arquivos Distribuídos (DFS ou SAD)
• Sistemas de arquivo distribuídos devem ser vistos pelos clientes como 
um sistema de arquivo local.
• A transparência é muito importante para seu bom funcionamento.
• É necessário um bom controle de concorrência no acesso.
• Cache é importante.
Apache Hadoop
• Hadoop é uma plataforma de software de código aberto para o armazenamento e 
processamento distribuído de grandes conjuntos de dados, utilizando clusters de 
computadores com hardware commodity.
• Os serviços do Hadoop fornecem armazenamento , processamento, acesso, governança, 
segurança e operações de Dados.
Fonte: https://hadoop.apache.org/
HDFS
• O HDFS (Hadoop Distributed File System) é um 
sistema de arquivos distribuído, projetado para 
armazenar arquivos muito grandes, com padrão de 
acesso aos dados streaming , utilizando clusters de 
servidores facilmente encontrados no mercado e de 
baixo ou médio custo. 
• Não deve ser utilizado para aplicações que precisem 
de acesso rápido a um determinado registro e sim 
para aplicações nas quais é necessário ler uma 
quantidade muito grande de dados. 
• Outra questão que deve ser observada é que não 
deve ser utilizado para ler muitos arquivos 
pequenos, tendo em vista o overhead de memória 
envolvido. Fonte: https://hadoop.apache.org/docs/r1.2.1/hdfs_design.html
Recursos do HDFS
• O HDFS tem 2 tipos de Nós : Master (ou Namenode) e 
Worker (ou Datanode). 
• O Master armazena informações da distribuição de arquivos e 
metadados. 
• Já o Worker armazena os dados propriamente ditos. Logo o 
Master precisa sempre estar disponível. Para garantir a 
disponibilidade podemos ter um backup ( similar ao Cold 
Failover ) ou termos um Master Secundário em um outro 
servidor. Nesta segunda opção, em caso de falha do primário, o 
secundário pode assumir o controle muito rapidamente.
• Tal como um sistema Unix, é possível utilizar o HDFS via linha de 
comando. 
HDFS
Fonte: http://hadoopguide.blogspot.com/2013/05/hadoop-hdfs-data-flow-io-classes.html
Data Lake
• Centralizar dados da organização num único local;
• Persiste dados estruturados, semi-estruturados e não-estruturados;
• Alta performance em escrita (ingestão) e em acesso (consumo);
• Baixo custo de armazenamento, se comparado a um Data Warehouse;
• Suporta regras de segurança e proteção de dados;
• Desacopla o armazenamento do processamento (ELT).
Características de um Data Lake
• Coleta e armazenamento de qualquer tipo de dado a baixo custo;
• Proteção de todos os dados armazenados no repositório central;
• Pesquisa e localização de dados relevantes no repositório central;
• Consulta aos dados, definindo a estrutura deles no momento do uso (esquema na 
leitura).
Recursos de um Data Lake
• Dados estruturados: banco de dados relacionais, Excel.
• Dados semiestruturados: arquivos HTML, XML, por exemplo
• Dados não-estruturados: arquivos de texto, imagens, vídeos e dados de redes sociais.
Amazenamento em um Data Lake
• Determinadas situações podem necessitar estruturações 
diferentes, o padrão é a divisão do Data Lake em 4 zonas:
• Transient Zone;
• Raw Data Zone;
• Trusted Zone;
• Refined Zone.
Estágios para Armazenamento em um Data Lake
Fonte: https://dzone.com/articles/data-lake-governance-best-practices
A primeira zona é uma zona transitória, na qual os dados serão ingeridos pelo 
Data Lake. 
Aqui já pode-se iniciar o processo de governança com catalogação das origens 
e tipos de dados que estão entrando, e identificação do início das linhagens.
Depois que os dados ingeridos forem alocados na Raw Data Zone, os arquivos 
aqui são excluídos, tornando essa uma zona de arquivos temporários.
Transient Zone
Uma dos principais diferencias de Data Lakes para Warehouses, já que nessa zona 
pode-se armazenar com agilidade todos os dados de fontes relevantes, 
independente de quanto será consumido de imediato.
Como estes dados são brutos, ainda não receberam os tratamentos necessários 
para serem consumidos em análises tradicionais, mas agregam muito valor por 
fornecerem aos cientistas de dados uma fonte crua, a partir da qual podem criar 
suas próprias modelagens para machine learning e AI.
Raw Data Zone
Os Dados alocados nesta zona já foram tratados, sofreram as transformações 
necessárias para serem consumidos e já possuem garantias de Data Quality, 
podendo ser considerados exatos e confiáveis
Trusted Zone
Na Refined Zone é possível encontrar dados tratados e enriquecidos, estando 
prontos para serem consumidos por aplicações externas.
Justamente por esse uso, essa camada costuma ser construída com infraestrutura 
de bancos de dados relacionais.
Refined Zone
Data Mesh
Arquitetura Data Mesh
Fonte: https://www.datanami.com/2022/01/21/data-meshes-set-to-spread-in-
2022/
No Data Mesh, o novo não está na criação de tecnologias e/ou ferramentas, mas sim na combinação 
de conceitos e práticas consolidadas, criando uma nova abordagem para trabalhar com dados:
• Data: pensar nos dados como parte essencial da estratégia executiva e tecnológica.
• Product thinking: pensar nos dados como produtos, não como projeto ou serviço, oferecendo uma ótima 
experiência para os usuários. 
• Distributed domain driven design architecture: pensar nos dados como parte dos domínios de negócio, 
distribuindo efetivamente a autonomia e responsabilidade. Podemos observar esta nova arquitetura 
ganhando espaço junto com Domain-driven design (DDD), microservices e service mesh;
• Self-service platform design: reduzir a carga cognitiva dos usuários com padrões, protocolos, 
tecnologias e ferramentas agnósticas de domínio, disponíveis em uma plataforma de autosserviço. 
Arquitetura Data Mesh
Princípios do Data Mesh: 
1. Domain Ownership
2. Data as Product
3. Self-service Data Plataform
4. Federated Computacional Governace
Arquitetura Data Mesh
Arquitetura de dados descentralizada orientada ao domínio
O primeiro e mais importante princípio do Data Mesh é mover a propriedade dos dados de um único time 
centralizado para muitos times distribuídos nos domínios de negócio. 
A arquitetura deve ser modelada para organizar os dados analíticos por domínios. 
Em um exemplo de e-commerce, poderíamos ter domínios de ‘clientes’ e ‘pedidos’. O domíniode ‘clientes’ poderia 
fornecer, por exemplo, endpoints de APIs para: 
1) obter todos os clientes (um por linha) baseado em filtros; 
2) disponibilizar estatísticas sobre os clientes (como número de clientes ativos, inadimplentes etc.).
Arquitetura Data Mesh
Dados disponibilizados como produto
O objetivo do Data Mesh é tratar os dados como um produto, onde cada fonte de dados tem seu próprio 
proprietário, que faz parte de uma equipe multifuncional de engenheiros de dados. 
Cada fonte de dados tem uma equipe focada em uma oferta autônoma, construindo uma arquitetura 
distribuída orientada ao domínio.
Arquitetura Data Mesh
Plataforma de dados self-service
Ter uma infraestrutura de dados self-service, como uma plataforma, para habilitar a autonomia do domínio. A 
ideia principal é evitar a duplicação de esforços, permitindo que cada equipe de produto de dados construa 
seus produtos rapidamente.
Arquitetura Data Mesh
Governança Federada
Cada dono de um produto de dados tem autonomia e poder de decisão local de domínio, enquanto cria e adere a 
um conjunto de regras globais — regras aplicadas a todos os produtos de dados e suas interfaces — para 
garantir um ecossistema saudável e interoperável. 
O grupo tem uma tarefa difícil: manter um equilíbrio entre centralização e descentralização. O desafio então é 
criar um modelo de governança federada, que equilibre descentralização e centralização.
Arquitetura Data Mesh
• www.datameshlearning.com
• Dheghani, Z. How to move beyond a monolithic data lake to a distributed datamesh-. Disponível em: 
https://martinfowler.com/articles/data-monolith-to-mesh.html
• Dheghani, Z. Data Mesh-Principles and logical architecture. Disponível em: 
https://martinfowler.com/articles/data-mesh-principles.html.
Fontes de Pesquisa para Data Mesh
http://www.datameshlearning.com/
https://martinfowler.com/articles/data-monolith-to-mesh.html
https://martinfowler.com/articles/data-mesh-principles.html
Data Layers
Fonte: https://www.analyticsvidhya.com/blog/2022/01/layers-of-
the-data-platform-architecture/
Data Layers – Arquitetura de Dados
Esta é a primeira camada da arquitetura da plataforma de dados. 
A camada de coleta de dados, como o nome sugere, é responsável por conectar-se aos sistemas de origem e trazer dados para a plataforma de dados 
de maneira periódica. 
Fonte: https://www.analyticsvidhya.com/blog/2022/01/layers-of-
the-data-platform-architecture/
Ingestão / Coleta de Dados
Fonte: https://www.analyticsvidhya.com/blog/2022/01/layers-of-the-data-platform-
architecture/
Batch / Stream
Essa camada é responsável por disponibilizar dados para 
processamento, ela precisa ser confiável, escalável, de alto 
desempenho e econômica. IBM DB2, IBM DB2, Microsoft SQL Server, 
MySQL, Oracle Database e PostgreSQL são alguns dos bancos de dados 
relacionais populares. Mas hoje em dia, os bancos de dados relacionais 
baseados em nuvem ganharam popularidade nos últimos anos, alguns 
bancos de dados relacionais baseados em nuvem são IBM DB2, Google 
Cloud SQL e SQL Azure. Nos sistemas de banco de dados NoSQL ou não 
relacional na nuvem, temos IBM Cloudant, Redis, MongoDB, Cassandra 
e Neo4J. 
Fonte: https://www.analyticsvidhya.com/blog/2022/01/layers-of-the-data-platform-
architecture/
Data Storage / Integration
As ferramentas para integração incluem o Cloud Pak for Data da IBM, o Cloud Pak for 
Integration da IBM e o Open Studio. Uma vez que os dados tenham sido ingeridos, 
armazenados e integrados, eles precisam ser processados. Então, com isso, avançamos para a 
Camada de Processamento de Dados
Fonte: https://www.analyticsvidhya.com/blog/2022/01/layers-of-the-data-platform-
architecture/
Data Storage / Integration
Essa camada é responsável por uma tarefa de processamento. O 
processamento inclui validações de dados, transformações e aplicação 
de lógica de negócios aos dados. A camada de processamento deve ser 
capaz de executar algumas tarefas que incluem:
- Leia dados nos modos de lote ou streaming do armazenamento e 
aplique transformações.
- Suporte a ferramentas de consulta populares e linguagens de 
programação.
- Dimensione para atender às demandas de processamento de um 
conjunto de dados crescente.
- Fornecer uma maneira para analistas e cientistas de dados 
trabalharem com dados na plataforma de dados.
Fonte: https://www.analyticsvidhya.com/blog/2022/01/layers-of-the-data-platform-
architecture/
Data Processing
Existem inúmeras ferramentas disponíveis no mercado para realizar 
essas operações nos dados, incluindo planilhas, OpenRefine, Google 
DataPrep, Watson Studio Refinery e Trifacta Wrangler. Python e R 
também oferecem várias bibliotecas e pacotes que são explicitamente 
criados para o processamento de dados. É muito importante saber que 
o armazenamento e o processamento nem sempre são realizados em 
camadas separadas. 
Por exemplo, em bancos de dados relacionais, o armazenamento e o 
processamento ocorrem na mesma camada, enquanto nos sistemas de 
Big Data, os dados são armazenados primeiro no sistema Hadoop File 
Distributed e, em seguida, processados no mecanismo de 
processamento de dados, como o Spark. Fonte: https://www.analyticsvidhya.com/blog/2022/01/layers-of-the-data-platform-
architecture/
Data Processing
Essa camada é responsável por fornecer os dados do processo aos 
usuários finais, incluindo analistas de inteligência de negócios e partes 
interessadas nos negócios que consomem esses dados com a ajuda de 
painéis e relatórios interativos. Além disso, cientistas de dados e 
analistas de dados se enquadram nessa categoria de usuário final que 
processe posteriormente esses dados para o caso de uso específico. 
Essa camada precisa oferecer suporte a ferramentas de consulta, como 
ferramentas SQL e ferramentas No-SQL e linguagens de programação 
como Python, R e Java e, além disso, essas camadas precisam oferecer 
suporte a APIs que podem ser usadas para executar relatórios sobre 
dados para online e offline em processamento.
Fonte: https://www.analyticsvidhya.com/blog/2022/01/layers-of-the-data-platform-
architecture/
Analysis / User Interface
Esta camada é responsável por implementar e manter um fluxo 
contínuo de dados através deste pipeline de dados. É a camada que 
tem a capacidade de extrair, transformar e carregar ferramentas. Há 
uma série de soluções de pipeline de dados disponíveis, sendo as mais 
populares entre elas o Apache Airflow e o DataFlow.
Fonte: https://www.analyticsvidhya.com/blog/2022/01/layers-of-the-data-platform-
architecture/
Data Pipeline
Data Ops
• Abreviação de operações de dados, DataOps é uma prática que aplica as melhores formas de trabalho da 
engenharia ágil e DevOps no campo de gerenciamento de dados. 
• É uma colaboração entre equipes de DevOps, engenheiros de dados, cientistas de dados e equipes de 
análise para acelerar a coleta e implementação de insights de negócios orientados a dados.
• O DataOps é centrado em automatizar e orquestrar pipelines de dados. Os esforços manuais sozinhos 
não conseguem acompanhar a quantidade de dados gerados. Automação e orquestração permitem uma 
rápida e eficiente movimentação dos dados entre vários sistemas, com uma performance adequada.
DataOps
• Como o nome sugere, DevOps é uma abordagem combinada de Desenvolvimento de Software (Dev) 
e Operações de TI (Ops). 
• DevOps é uma união de tecnologia, pessoas e processos para entregar valor contínuo aos clientes. O 
DevOps não é uma tecnologia, estrutura ou conjunto de padrões específicos e sim uma “Cultura” e 
promove uma melhor comunicação e colaboração entre as equipes.
• DevOps é o descendente direto do desenvolvimento ágil de software, nascido da necessidade de 
acompanhar o aumento da velocidade de desenvolvimento de software e métodos ágeis de 
rendimento.
O que é DevOps
• O fluxo de trabalho do DevOps consiste em fases:
– Planejando a próxima iteração do desenvolvimento do produto– Construindo o código
– Testar e implantar no ambiente de produção
– Entrega de atualizações de produtos
– Monitorando e registrando o desempenho do software
– Coletando o feedback do cliente
Fluxo DevOps com Ferramentas
Fonte: https://medium.com/clarusway/popular-devops-tools-review-ee0cffea14e
• Um ciclo de vida de DevOps padrão consiste em 7 fases:
1. Desenvolvimento contínuo;
2. Integração contínua;
3. Testes Contínuos;
4. Monitoramento Contínuo;
5. Feedback contínuo;
6. Implantação Contínua;
7. Operações contínuas.
• Essas 7 fases do ciclo de vida do DevOps são contínuas, iterativas e permitem melhorias em 
todo o processo de desenvolvimento de software.
Princípios Básicos do DevOps
• O DevOps apresenta dois conceitos fundamentais: Integração Contínua (CI) e 
Implantação Contínua (CD). 
• O CI cria, integra e testa continuamente novos códigos em um ambiente de 
desenvolvimento. A construção e o teste são automatizados para que possam 
ocorrer de forma rápida e repetida. Isso permite que os problemas sejam 
identificados e resolvidos rapidamente. 
• CD é uma abordagem automatizada para implantar ou entregar software. Depois 
que um aplicativo passa em todos os testes de qualificação, o DevOps o implanta 
em produção. Juntos, CI e CD resolvem a principal restrição que dificulta o 
desenvolvimento ágil.
DevOps
Fonte: https://unionitdigital.com.br/tecnologias/devops/
• DataOps é uma prática que usa os conceitos:
– Ágil;
– DevOps;
– Controle estatístico do processo (do Lean) para acelerar e industrializar a entrega e a 
execução de projetos centrados em dados.
DataOps
• Para colaboração do DataOps funcionar, existem três pilares principais:
– Automação: A automatização de processos de dados permite tempos de resposta mais rápidos 
e menos erros.
– Qualidade: Melhorar a qualidade dos dados por meio de uma melhor governança e processos 
padronizados leva a uma melhor tomada de decisão.
– Colaboração: A colaboração eficaz em equipe leva a uma cultura mais orientada a dados e a 
uma melhor tomada de decisão.
Pilares do DataOps
• Assim como o DevOps, o DataOps promove o uso de soluções de tecnologia avançada para 
automatizar o gerenciamento de dados e os processos operacionais, ao mesmo tempo em que 
incorpora controles de governança apropriados. 
• Para ter sucesso, desde os componentes fundamentais dos processadores de dados até a 
infraestrutura de dados devem ser automatizados o máximo possível. 
• Além disso, os requisitos fundamentais do pipeline de dados (ingestão, integração, qualidade, teste, 
implantação e monitoramento dos dados) devem ser intrinsecamente conectados por 
orquestração.
DataOps - Automação
Fonte: Altexsoft
DataOps - Processo
Fonte: Microsoft / Azure
DataOps - Pipeline
Fonte: https://medium.com/data-ops/dataops-is-not-just-devops-for-data-6e03083157b7
DevOps x DataOps
Fonte: https://medium.com/data-ops/dataops-is-not-just-devops-for-data-6e03083157b7
DataOps
• DataOps baseia-se no modelo de desenvolvimento DevOps. 
• O fluxo do processo DevOps inclui uma série de etapas comuns aos projetos de desenvolvimento de 
software:
– Desenvolver — criar/modificar um aplicativo;
– Construir — montar componentes do aplicativo;
– Teste — verifique o aplicativo em um ambiente de teste;
– Deploy — código de transição para produção;
– Executar — executa o aplicativo.
DevOps x DataOps
DataOps – Ferramentas de DataOps
Fontes: https://www.devopsschool.com/blog/top-20-dataops-tools-and-its-ranking/
• A plataforma Data Kitchen DataOps automatiza e coordena todas as pessoas, ferramentas e ambientes 
em toda a sua organização de análise de dados.
• Tudo, desde orquestração, teste e monitoramento até desenvolvimento e implantação.
• Se você já tem as ferramentas que precisa, o Data Kichen orquestra automaticamente seus pipelines de 
múltiplas ferramentas e ambientes de ponta a ponta – desde o acesso a dados até a entrega de valor.
Data Kitchen
	Número do slide 1
	Número do slide 2
	Número do slide 3
	Número do slide 4
	Número do slide 5
	Número do slide 6
	Número do slide 7
	Número do slide 8
	Número do slide 9
	Número do slide 10
	Número do slide 11
	Número do slide 12
	Número do slide 13
	Número do slide 14
	Número do slide 15
	Número do slide 16
	Número do slide 17
	Número do slide 18
	Número do slide 19
	Número do slide 20
	Número do slide 21
	Número do slide 22
	Número do slide 23
	Número do slide 24
	Número do slide 25
	Número do slide 26
	Número do slide 27
	Número do slide 28
	Número do slide 29
	Número do slide 30
	Número do slide 31
	Número do slide 32
	Número do slide 33
	Número do slide 34
	Número do slide 35
	Número do slide 36
	Número do slide 37
	Número do slide 38
	Número do slide 39
	Número do slide 40
	Número do slide 41
	Número do slide 42
	Número do slide 43
	Número do slide 44
	Número do slide 45
	Número do slide 46
	Número do slide 47
	Número do slide 48
	Número do slide 49
	Número do slide 50
	Número do slide 51
	Número do slide 52
	Número do slide 53
	Número do slide 54
	Número do slide 55
	Número do slide 56
	Número do slide 57
	Número do slide 58
	Número do slide 59
	Número do slide 60
	Número do slide 61
	Número do slide 62
	Número do slide 63
	Número do slide 64
	Número do slide 65
	Número do slide 66
	Número do slide 67
	Número do slide 68
	Número do slide 69
	Número do slide 70
	Número do slide 71
	Número do slide 72
	Número do slide 73
	Número do slide 74
	Número do slide 75
	Número do slide 76
	Número do slide 77
	Número do slide 78
	Número do slide 79
	Número do slide 80
	Número do slide 81
	Número do slide 82
	Número do slide 83
	Número do slide 84
	Número do slide 85
	Número do slide 86
	Número do slide 87
	Número do slide 88
	Número do slide 89
	Número do slide 90
	Número do slide 91
	Número do slide 92
	Número do slide 93
	Número do slide 94
	Número do slide 95
	Número do slide 96
	Número do slide 97
	Número do slide 98
	Número do slide 99
	Número do slide 100
	Número do slide 101
	Número do slide 102
	Número do slide 103
	Número do slide 104
	Número do slide 105
	Número do slide 106
	Número do slide 107
	Número do slide 108
	Número do slide 109
	Número do slide 110
	Número do slide 111
	Número do slide 112
	Número do slide 113