Fonte: Freepik e Flaticon Ao pesquisar um pouco sobre esta arquitetura, vamos encontrar alguns artigos falando sobre ela e no site da Databricks temos uma definição simples e bem clara: “Uma arquitetura medalhão é um padrão de design de dados usado para organizar logicamente os dados em um lakehouse, com o objetivo de melhorar incremental e progressiva a estrutura e a qualidade dos dados à medida que fluem através de cada camada da arquitetura (das tabelas de camada Bronze ⇒ Silver ⇒ Gold).” Ok, mas o que seria um Lakehouse? O conceito Lakehouse nasceu há pouco tempo, sendo um tipo de “unificação” dos conceitos e práticas adotadas no Data Warehouse + Data Lake e normalmente são bastante confundidos. Vamos então ver um breve resumo da diferença entre essas arquiteturas: Databricks Lakehouse Data Warehouse: É um repositório de dados analíticos, gerado a partir de dados transacionais (normalmente dados estruturados). Nele utilizamos processos de ETL (extração, transformação e carregamento de dados) e são muito utilizados para business intelligence (BI). Com sua utilização podemos ter alguns problemas como volumetria de dados, estresse do banco de dados, cargas demoradas, não conseguir trabalhar com muitas variações de dados, performance, etc... Data Lake: Após o “boom” do avanço da internet e suas tecnologias, surgiu então a necessidade de analisar essas novas variedades de dados e conseguir acompanhar a sua volumetria. Surge então um novo conceito de repositório de dados desenhado para armazenar e processar grandes quantidades de dados estruturados e não estruturados (vídeos, imagens, documentos, comentários de usuários em blogs e sites de rede social, etc...). Tem como fonte da verdade os dados a partir do seu formato bruto. Nele utilizamos processo de ELT e são muito utilizados por cientistas de dados e analistas de BI. Com sua utilização podemos ter alguns problemas como consistência de dados, pois não há controle ACID; onde por exemplo, se tivermos algum job em execução e o mesmo apresentar um problema no meio de sua execução, os dados ficam inconsistentes pois não há controle de Rollback. Não existe controle de versionamento ou auditoria por logs; operações de delete, atualização e merge não são fáceis e existe muito uso de ETL do data lake para um DW. Entendendo os problemas com as duas arquiteturas anteriores, surge então o Data Lakehouse, que seria a ideia de trazer o Data Warehouse para dentro do Data Lake, porém adicionando uma governança unificada e facilidade na movimentação dos dados. Utilizando por exemplo as features do Delta Lake (que é um projeto de código aberto), que fornece transações ACID para o Apache Spark, manipulação de metadados, processamento de dados em streaming e batch em data lakes como o ADLS, S3, GCS, HDFS... Unindo assim, o melhor das duas arquiteturas anteriores em um único repositório, porém com maior poder de processamento, escalabilidade, e confiabilidade em relação aos dados. Abaixo, uma ótima comparação entre Data Warehouse, Data Lake e Data Lakehouse que está disponibilizada aqui no site da Databricks: Uma vez que entendemos então a definição de um lakehouse, quais seriam os benefícios de trabalhar com este tipo de arquitetura e qual seria a melhor forma de implantá-lo na sua organização? Neste momento surgem “N” pensamentos sobre o que seria “a verdade” em termos de padronização e boas práticas, mas veremos ao longo do artigo que muito do que precisará ser feito vai depender de negócio para negócio. Logo, não teríamos então algo como 100% fonte da verdade, pois em um projeto de Big Data sempre vamos ter que lidar com muitos conceitos e que, independentemente das ferramentas utilizadas, nada irá vir pronto, você sempre irá analisar o cenário e aplicar tecnologias, ferramentas e conceitos conforme necessidade e viabilidade para seu projeto. "The Medallion Architecture" Databricks Medallion Architecture Quando estamos trabalhando em um projeto de Big Data, irão aparecer situações em que não iremos ter definições exatas, sendo preciso um pouco mais de paciência e reflexão. Uma dessas questões é como organizar os dados no Data Lake, pois se as informações não estiverem organizadas da maneira correta, elas podem se tornar inúteis (transformando-se em um data swamp) ou até mesmo prejudicar a análise dos dados no dia a dia. Por isso, é importante pensar bem na estrutura do Data Lake para garantir que as informações estejam disponíveis e acessíveis quando precisarmos delas. A “Arquitetura Medalhão” visa realizar essa organização dentro do repositório, distribuindo os dados em várias camadas/níveis diferentes e que ao mesmo tempo possam atender necessidades diferentes do negócio, mantendo o ambiente seguro, organizado e de fácil compreensão. Iremos falar um pouco sobre as camadas Bronze, Silver e Gold, mas primeiramente, vamos falar sobre uma camada importante que antecede as demais. ⏩ Transient (landing) É uma camada provisória, responsável pela primeira ingestão dos dados no data lake. É um local onde diferentes variações de dados e arquivos (RDBMS, XMl, CSV, JSON...), de diversos sistemas e fontes de origem (ERP, WMS, E-commerce, Redes Sociais, IoT, etc...) serão armazenados antes de movê-los para a camada Bronze(raw). Ela é extremamente útil para uma primeira organização dos dados em relação as fontes, onde ao realizar a ingestão desses dados para um data lake, já podemos aplicar uma transformação para um formato de arquivo de maior desempenho, como por exemplo o Parquet para trabalhar no ADLS. Aqui, literalmente os dados são mantidos de forma provisória e após a transformação com sucesso dos dados para a Bronze, podem ser excluídos desta primeira camada. 🥉 Bronze (raw) É a camada onde serão armazenados os dados, em seu formato bruto (As-Is), derivados da camada Transient e que após uma primeira carga, pode ser aplicado uma carga incremental dos dados utilizando o formato Delta Table. Neste nível, normalmente quem têm acesso são os engenheiros de dados, mas a depender do objetivo do negócio, pode-se também ser aplicado análises por cientistas de dados que precisam realizar análises nos dados ainda em seu formato bruto para gerar alguns determinados insights mais específicos sem nenhum tratamento prévio. 🥈 Silver (trusted/acurated) A ideia desta camada é transformar os dados brutos descentralizados, em entidades centralizadas, aplicando mais “desnormalização” nos dados. Logo, é aplicado diversas transformações, uniões, enriquecimento dos dados, aplicação de SCD, padronização e Data Quality, melhorando por exemplo nomenclatura dos campos (ex: inglês para português, retirada de abreviações – nm_cli = nome_cliente) conforme regras definidas pelo equipe envolvida na modelagem desta camada. Nesta camada, saímos de uma visão de sistema para uma visão de negócio, realizando agrupamento de várias tabelas para transformar em uma entidade de negócio. Digamos que temos uma tabela chamada “Produtos” e “Produtos_Categorias, Produtos_Classes, Produtos_Fornecedores), aqui unificaríamos estas tabelas para formar uma entidade “Produto” que receberá vários atributos, tratando-os de uma forma que os dados fiquem mais contextualizados e qualificados. Poderá acontecer também de unificar uma mesma tabela do mesmo assunto, de diferentes sistemas. Ex: unificação de tabela do ERP chamada “Produtos” e E-commerce com tabela “Produtos”, formando uma única fonte de dados, podendo incluir um campo de “origem” para saber de que fonte de dados se trata o mesmo. 🥇 Gold (refined) Finalmente, na camada Gold, é onde os dados deverão ser transformados e preparados para consumo pela área de negócio, ou seja, aqui poderemos aplicar mais uma camada de regras extras, separar determinados dados num escopo por área da organização, realizar a criação de tabelas com modelagem Star Schema (Fato e Dimensão), com agregações, cálculos, indicadores, com o enriquecimento de dados necessário e preparados para atingir um objetivo específico. Esta é uma camada às vezes “polêmica”, pois existem pessoas e negócios que tratam de formas diferentes, como por exemplo, uns modelam baseado no Star Schema, outros podem gerar OBT’s (One Big Tables) pois em alguns casos irão obter melhor performance na ferramenta de visualização, outros podem transformar os dados da Bronze para a Gold, etc... Cada caso será “um caso” e muitas vezes podem acabar fugindo dos padrões para atender às necessidades do negócio. Porém, é preciso ter atenção durante a criação da estratégia e definição desta arquitetura, criar documentações, aplicar uma boa governança de dados, para que de fato, o seu Lakehouse mesmo com todas essas definições técnicas e preocupações, não acabe se tornando um data swamp (se não for bem acompanhado e gerenciado). Afinal de contas, não basta simplesmente planejar e criar, também é imprescindível monitorar e melhorar os processos (lembra do PDCA?). Os dados hoje em dia não são apenas “o novo petróleo”, eles são tudo de mais valioso que uma empresa tem, se ela souber identificá-los, gerenciá-los e usar a seu favor, se tornará uma organização de grande referência no mercado perante aos seus concorrentes, utilizando-os com inteligência para reduzir seus custos e aumentar então o seu ROI. Espero que tenham gostado! 😊 Referências: What is a Medallion Architecture? (databricks.com) Data Lake Zones: O que é? Para que serve? Quantas são? Quanto Custa? (linkedin.com) 3 camadas para sucesso do meu Data Lake (linkedin.com) Fundamentos do Delta Lake (linkedin.com) Evolution to the Data Lakehouse - The Databricks Blog Festival da Tecnologia - YouTube 3 camadas para sucesso do meu Data Lake (linkedin.com) Medallion architecture: best practices for managing Bronze, Silver and Gold | by Piethein Strengholt | Medium

O Azure Synapse Analytics é uma plataforma fornecida pela Microsoft, onde oferece um ambiente unificado para ingestão, preparação, orquestração, gerenciamento, monitoramento e análise de dados, permitindo com que as empresas processem grandes quantidades de dados e obtenham insights valiosos. Logo, com a crescente quantidade de dados que estão sendo processados na nuvem, a segurança dos dados torna-se então não só um alerta, mas uma grande preocupação para as empresas que utilizam recursos na nuvem no sentido de “como gerenciar” da forma mais adequada e segura possível. Neste artigo, vamos explorar sobre 3 principais medidas de segurança que a plataforma oferece para proteger os dados dos clientes contra ameaças externas e internas, garantir a integridade, confidencialidade e disponibilidade de seus dados. Vamos então conhecer alguns dos recursos de segurança importantes da plataforma: · Autenticação e Autorização: Fonte: Freepik Primeiro vamos entender o que significa cada um: Autenticação é a verificação das credenciais do usuário para conceder acesso a um sistema, podendo ser única, de dois fatores ou multifator. Já a autorização é a verificação de permissões para acessar áreas ou executar ações em uma aplicação com base em critérios e condições estabelecidos. A autorização pode conceder ou negar permissões, também podemos ouvir ser chamados de controle de acesso ou controle de privilégio. A autenticação e autorização no Synapse Analytics é baseada em vários recursos de segurança do Azure, onde consegue fornecer de maneira segura e escalável controle dos acessos aos recursos dos serviços. Para isto, utilizam-se o Azure AD (Azure Active Directory) e o Azure RBAC (Role-Based Access Control), onde os mesmos funcionam desta forma: Autenticação: O AAD é usado para autenticação no Synapse Analytics. Isso significa que as identidades dos usuários e recursos são gerenciadas pelo AAD. Os usuários do Synapse Analytics são autenticados usando suas credenciais do AAD. Isso pode incluir senhas, autenticação multifator ou autenticação baseada em certificado. O Synapse Analytics também suporta logon único (SSO) para usuários que já fizeram logon em outros serviços do Azure usando o mesmo Azure AD/credencial, melhorando a experiência do usuário. Autorização: O Azure RBAC (Role-Based Access Control) é usado para autorização no Synapse Analytics. Isso significa que as permissões de acesso aos recursos são gerenciadas usando funções predefinidas do RBAC. O Synapse Analytics oferece várias funções predefinidas do RBAC, como proprietário(owner), colaborador (contributor) e leitor (reader), que fornecem diferentes níveis de acesso aos recursos do serviço. Os proprietários de recursos podem conceder permissões a usuários e grupos do AAD atribuindo funções predefinidas ou criando funções personalizadas com permissões granulares específicas (https://learn.microsoft.com/pt-br/azure/role-based-access-control/custom-roles). O Synapse Analytics também suporta a criação de grupos de acesso, que permitem que os proprietários de recursos concedam permissões a vários usuários ou grupos ao mesmo tempo. · Criptografia: Fonte: Freepik O Azure Synapse Analytics usa criptografia em repouso e em trânsito para proteger seus dados. A criptografia em repouso é fornecida por meio do recurso de criptografia de disco do Azure Storage, que garante que seus dados sejam criptografados enquanto estão armazenados no disco (em repouso). As tentativas de obter acesso físico ao hardware em que os dados são armazenados e em seguida comprometer os dados contidos, é o que chamamos de ataque contra dados em repouso. No ASA, utilizamos o Transparent Data Encryption (TDE) com chaves gerenciadas pelo serviço, que é uma solução de criptografia em repouso onde protege os dados armazenados no banco de dados. Como a chave de criptografia é gerenciada pelo serviço, significa que os dados são protegidos mesmo que o servidor seja comprometido. O TDE pode ser habilitado ou desabilitado para cada pool de SQL dedicado no espaço de trabalho. A criptografia em trânsito é a proteção dos dados enquanto eles são transmitidos entre diferentes partes do serviço. É como se fosse uma senha que deixa os dados protegidos enquanto viajam pela internet. O serviço usa um protocolo chamado SSL/TLS que criptografa os dados para que só quem tiver a senha (destinatário certo) possa acessá-los. Isso é muito importante para manter informações sensíveis seguras e garantir que ninguém roube ou intercepte os dados no caminho. O Azure Key Vault é a alternativa de armazenamento de chave recomendada e apresenta uma gestão padronizada em todos os serviços. As chaves são mantidas e administradas em um "cofre de chaves" e a possibilidade de acesso ao cofre de chaves pode ser concedida a usuários ou serviços. Fonte: Microsoft · Defender for SQL O Azure Defender for SQL é um recurso do Azure Defender que pode ser ativado no Synapse Analytics e agir como um “escudo” para proteger bancos de dados SQL. Ao ser ativado, o Azure Defender for SQL já começa a monitorar as atividades do banco de dados, identificando e alertando sobre possíveis ameaças, alguma atividade maliciosa, tentativas de acesso não autorizado e/ou algum outro tipo de vulnerabilidade. Ele gera relatórios e insights detalhados sobre as ameaças detectadas e as ações que foram tomadas para resolver. O Azure Defender for SQL usa machine learning para analisar os padrões de acesso e identificar atividades suspeitas e através disto, recomendar medidas corretivas para ajudar a analisar o risco. Com a utilização do Azure Defender for SQL, adicionamos uma camada a mais de segurança para os bancos de dados no Synapse Analytics contra as ameaças cibernéticas e o mesmo pode ser testado gratuitamente por 30 dias e depois decidir se deseja ou não continuar utilizando. Em resumo, o Azure Synapse Analytics é uma plataforma altamente segura que oferece uma ampla gama de recursos de segurança para proteger seus dados. Ao adotar essas medidas de segurança, você tem uma grande garantia de que seus dados permaneçam seguros e protegidos em todas as etapas do ciclo de vida dos dados. Por fim, é importante lembrar que a segurança é uma responsabilidade compartilhada. Embora o Azure Synapse Analytics forneça medidas avançadas de segurança, é importante que seja implementado as boas práticas recomendadas de segurança de dados, como por exemplo o uso de senhas fortes, configuração de políticas de segurança de rede e o monitoramento regular de atividades suspeitas. Links de referências: https://learn.microsoft.com/pt-br/azure/synapse-analytics/security/synapse-workspace-synapse-rbac-roles https://learn.microsoft.com/pt-br/azure/role-based-access-control/overview https://learn.microsoft.com/pt-br/azure/role-based-access-control/custom-roles https://learn.microsoft.com/pt-br/azure/synapse-analytics/security/workspaces-encryption Protect your SQL Server on-premises, in Azure, and in multicloud - Microsoft Security Blog Autenticação x autorização – qual é a diferença? (freecodecamp.org)