Eng Dados PDF

Sumário ARQUITETURA LAMBDA............................................................................................................. 2 LAMBDA NO AZURE – CAMADA BATCH................................................................................... 3 ARQUITETURA KAPPA................................

Sumário ARQUITETURA LAMBDA............................................................................................................. 2 LAMBDA NO AZURE – CAMADA BATCH................................................................................... 3 ARQUITETURA KAPPA................................................................................................................ 4 PALESTRA ARTHUR LUZ............................................................................................................ 4 DISSECANDO A ARQUITETURA LAMBDA............................................................................. 4 DISSECANDO A ARQUITETURA KAPPA................................................................................ 5 DATA LAKE................................................................................................................................... 5 DATA LAKE OU DATA SWAMP............................................................................................... 6 DATA LAKEHOUSE - CONCEITOS............................................................................................. 7 DATA LAKEHOUSE – PARADIGMA DA DÉCADA.................................................................. 7 PRIMEIRAS IMPRESSÕES UTILIZANDO O DELTA LAKE NA PRÁTICA.............................. 8 FUNDAMENTOS DO DELTA LAKE........................................................................................ 11 DATA LAKEHOUSE EXPLICADO EM 2 MINUTOS............................................................... 12 BIG DATA COM DATA LAKE HOUSE.................................................................................... 13 LINKS ÚTEIS............................................................................................................................... 18 DELTA......................................................................................................................................... 18 APLICAÇÃO E EVOLUÇÃO DO ESQUEMA DELTA LAKE COM MERGE SCHEMA E OVERWRITE SCHEMA........................................................................................................... 18 APLICAÇÃO DO ESQUEMA DELTA LAKE............................................................................ 18 APPENDING OVERWRITING WITH DIFFERENT SCHEMA TO DELTA LAKE VS PARQUET................................................................................................................................................. 23 DATA SKIPPING..................................................................................................................... 29 10 Configurações úteis para tabelas delta.................................................................................. 30 INSIGHTS.................................................................................................................................... 30 Bibliografia................................................................................................................................... 32 ARQUITETURA LAMBDA Ao trabalhar com conjuntos de dados muito grandes, pode levar muito tempo para executar a classificação de consultas de que os clientes precisam. Essas consultas não podem ser executadas em tempo real e geralmente exigem algoritmos como MapReduce, que operam em paralelo em todo o conjunto de dados. Os resultados são então armazenados separadamente dos dados brutos e usados para consulta. Uma desvantagem dessa abordagem é que ela introduz latência — se o processamento levar algumas horas, uma consulta poderá retornar resultados de várias horas atrás. O ideal é que você obtenha alguns resultados em tempo real (talvez com alguma perda de precisão) e combine esses resultados com os resultados da análise de lote. A arquitetura lambda, primeiramente proposta por Nathan Marz, resolve esse problema criando dois caminhos para o fluxo de dados. Todos os dados recebidos pelo sistema passam por esses dois caminhos: Uma camada de lote (caminho frio) armazena todos os dados de entrada em sua forma bruta e executa o processamento em lotes nos dados. O resultado desse processamento é armazenado como uma exibição de lote. Uma camada de velocidade (caminho quente) analisa os dados em tempo real. Essa camada foi projetada para baixa latência, em detrimento da precisão. A camada de lote alimenta uma camada de serviço que indexa a exibição de lote para uma consulta eficiente. A camada de velocidade atualiza a camada de serviço com atualizações incrementais de acordo com os dados mais recentes. Os dados que fluem para o caminho quente são restritos por requisitos de latência impostos pela camada de velocidade, de modo que ela possa ser processada o mais rapidamente possível. Geralmente, isso exige uma desvantagem de algum nível de precisão em favor dos dados que estão prontos o mais rapidamente possível. Por exemplo, considere um cenário de IoT em que um grande número de sensores de temperatura envia dados telemétricos. A camada de velocidade pode ser usada para processar uma janela de tempo deslizante dos dados de entrada. Os dados que fluem para o caminho frio, por outro lado, não estão sujeitos aos mesmos requisitos de baixa latência. Isso permite uma computação de alta precisão em conjuntos de dados grandes, o que pode ser muito demorado. 2 Em última análise, os caminhos quente e frio convergem no aplicativo cliente de análise. Se o cliente precisar exibir dados em tempo hábil, mas potencialmente menos precisos em tempo real, ele adquirirá seu resultado do caminho quente. Caso contrário, ele selecionará resultados do caminho frio para exibir dados em menos tempo hábil, mas mais precisos. Em outras palavras, o caminho quente contém dados para uma janela relativamente pequena de tempo, após o qual os resultados podem ser atualizados com os dados mais precisos do caminho frio. Os dados brutos armazenados na camada de lote são imutáveis. Os dados de entrada sempre são acrescentados aos dados existentes e os dados anteriores nunca são substituídos. As alterações no valor de um dado específico são armazenadas como um novo registro de evento com carimbo de data/hora. Isso permite o recálculo em qualquer ponto no tempo no histórico dos dados coletados. A capacidade de recalcular a exibição de lote dos dados brutos originais é importante, pois permite que novas exibições sejam criadas conforme o sistema evolui. (MICROSOFT, Arquiteturas de Big Data, 2018) LAMBDA NO AZURE – CAMADA BATCH 3 ARQUITETURA KAPPA Uma desvantagem da arquitetura de lambda é sua complexidade. A lógica de processamento aparece em dois lugares diferentes — os caminhos frio e quente — usando estruturas diferentes. Isso leva a uma lógica de cálculo duplicada e a complexidade de gerenciar a arquitetura para os dois caminhos. A arquitetura de kappa foi proposta por Jay Kreps como uma alternativa à arquitetura de lambda. Ela tem as mesmas metas básicas da arquitetura de lambda, mas com uma diferença importante: todos os dados fluem por um único caminho, usando um sistema de processamento de fluxo. Há algumas semelhanças na camada de lote da arquitetura de lambda, em que os dados do evento são imutáveis e todos eles são coletados, em vez de um subconjunto. Os dados são ingeridos como um fluxo de eventos em um log unificado distribuído e tolerante a falhas. Esses eventos são ordenados e o estado atual de um evento é alterado somente por um novo evento que está sendo acrescentado. Semelhante à camada de velocidade da arquitetura de uma lambda, todo o processamento de eventos é feito no fluxo de entrada e persistido como uma exibição em tempo real. Se você precisar recalcular todo o conjunto de dados (equivalente ao que a camada de lote faz no lambda), basta reproduzir o fluxo, normalmente usando o paralelismo para concluir o cálculo em tempo hábil. (MICROSOFT, Arquiteturas de Big Data, 2018) PALESTRA ARTHUR LUZ DISSECANDO A ARQUITETURA LAMBDA. Ao invés de ter uma transformação do DATA SOURCE > DATA STORAGE eu simplesmente carrego (LOAD) esses dados para o meu DATA STORAGE. Ou seja, o meu DATA STORAGE aqui é o meu DATA LAKE. Eu tenho minhas origens e as cargas do meus dados cru (RAW DATA) sendo feitas para dentro do meu DATA LAKE. 4 A minha transformação seria o meu BATCH PROCESSING. Dentro desse cenário eu teria o meu ELT. Logo após, fazemos a inserção dos dados na minha camada analítica (ANALITICAL DATA STORE), essa camada analítica pode ser também o meu DATA STORAGE. Eu posso transformar e armazenar o meu arquivo transformado no meu DATA STORAGE, ou podemos ter uma outra camada, por exemplo, um DW. Na camada de ANALYTICS AND REPORTS usamos esse dado para criar os relatórios e painéis. Importante: Podemos passar diretamente para a camada de REPORT através do PROCESSING, seja ela, BATCH ou STREAM, assim como a figura mostra. Essa arquitetura na parte superior não é muito diferente da arquitetura de BI tradicional, o que muda é que agora temos uma camada de STREAM, dados em tempo real sendo carregados e processados. Os meus dados que antes, eram consumidos a cada 1 hora, 1 dia ou 1 semana, agora eu preciso consumir ele a cada 2 ou 3 segundos. Voltando a figura, temos nossas origens, obviamente que são origens de STREAM, essas minhas origens serão carregadas pela minha camada de REAL-TIME INGESTION, eu posso salvar esse dado também dentro do meu DATA STORAGE, é um dado que ele entra STREAM, mas tenho a necessidade de guardar ele historicamente para poder consumi-lo na camada posterior, então eu salvo ele na minha camada de DATA STORAGE. Posso processar esse dado na minha camada de PROCESSING e consumir esse dado na minha camada ANALYTICS REPORTS. E tenho minhas ferramentas de orquestração, AZURE DATA FACTORY poderia ser usado para isso, por exemplo. (LUZ, 2019) DISSECANDO A ARQUITETURA KAPPA DATA LAKE O criador do conceito foi James Dixon em 2010. Lembrando que o conceito de Data Lake é uma coisa, os produtos de Data Lake é outra. Data Lake é um repositório de dado cru (Raw Data). Com o Data Lake temos a democratização dos dados. O Data Lake é um local heterogêneo que armazena diferentes tipos de dados como: Dados estruturados, semiestruturados e não estruturados. Produtos de Data Lake: Azure Blob Storage e Azure Data Lake Storage Gen2 AWS S3 e AWS Lake Formation Google Cloud Storage Hadoop HDFS O Data Lake foi desenhado para ser um local de armazenamento, não foi feito para acesso instantâneo. Ele garante muito bem que o dado vai ser escrito, vai ser replicado e garante que em casos de desastres ou falhas o seu dado esteja em várias regiões diferentes. Ele garante disponibilidade, isso é diferente afirmar que vou conseguir processar terabytes com eficiência dentro do Data Lake. Lembre-se que ele foi feito com várias máquinas commodities com performance diferentes. Ele não consegue entregar um SLA extremamente eficiente. Diferenças Data Mart: Dados de um departamento Data Warehouse: Um conjunto de Data Mart 5  Data Lake: Raw Data (Source of Truth) Dificuldades Data Swamp: Alta desorganização dos dados Governança de dados Data Quality: Veracidade dos dados Data Security: Proteção dos dados Não Suporta ACID Com o Data Lake você ganha com a democratização do dado, mas você perde com a organização dele. Definição - O que significa Commodity Computing? A computação de commodities refere-se ao uso de recursos de hardware de baixo custo por uma empresa para obter mais poder de computação. Em vez de comprar supercomputadores elaborados, as empresas que usam a computação de commodities reúnem o poder de processamento de vários computadores mais convencionais e de baixo custo, como estações de trabalho que a empresa já possui. Isso pode ajudar uma empresa a adquirir mais poder de processamento a um custo consideravelmente mais baixo. DATA LAKE OU DATA SWAMP Hoje temos uma grande facilidade em juntar e armazenar dados. Cada ano surgem maiores e melhores métodos de armazenamento, tanto físicos quanto em cloud. Quando equiparamos com os custos de processamento, os custos de armazenamento são significantemente menores. Inclusive, ganhamos uma quantidade generosa de espaço sem custo algum em algumas plataformas para guardar arquivos. Com toda essa facilidade em baixar e guardar arquivos, é natural começarmos um processo de acumulação, afinal, eles podem ser úteis algum dia, não é mesmo? Então vamos criando pastas aqui, pastas ali e tudo certo. Em um data lake, a facilidade então é ainda maior, já que a capacidade de armazenamento é tanta que a princípio pensamos que jamais vamos conseguir acumular tantos arquivos a ponto de saturá-lo. É nesse acumula aqui, acumula dali, captura de lá, captura de cá que nosso data lake dos sonhos pode virar um data swamp, lotado de arquivos sem sentido e sem nenhuma estrutura para achar o arquivo que queremos. Quando trabalhamos com esse nível de fluxo de informações, é primordial criar uma governança e catalogar nossos dados. As características de um bom data lake costumam ser: categorização e conhecimento dos metadados; governança de dados; processamento automatizado de dados; dados úteis; e uma rotina de limpeza. Durante um projeto específico, lembramos quais são os arquivos certos, mas depois de meses sem mexer neles, fica complicado lembrar o nome do arquivo e onde ele deve ou deveria estar. É por esse caminho que os metadados nos auxiliam. Eles são tags para facilitar a busca dos arquivos que queremos. Governança de dados é outro tema muito importante. Quem pode acessar? Quais permissões essa pessoa ou aplicativo tem? A pessoa que tem permissão tem conhecimento de como estruturar e organizar o data lake? Se não, temos um procedimento e restrições, pois cada usuário tende a organizar e colocar os arquivos da forma que entendem corretos, o que acaba gerando uma falta de padrão e organização nos nossos dados. Processos de automação nos auxiliam (e muito!) em manusear nosso data lake. Podemos já processar os dados para um formato propício para uso ao invés de deixá-lo em seu formato original e sem utilidade. Ou mesmo separar nosso data lake em partes originais e processadas caso precisemos manter os arquivos em seu formato original. Com as automações, podemos 6 fazer isso de forma rápida, sistemática e prática, não desperdiçando recursos humanos para fazer todo esse trâmite e limpeza. Claro, sempre precisamos rever aquilo que guardamos. Assim como de tempos em tempos precisamos revisitar nosso guarda-roupa e fazer aquela faxina, nosso data lake deve ser tratado da mesma maneira. Certos dados podem parecer importantes e vitais de serem guardados em determinado tempo, mas depois de meses ou anos, percebemos que não são tão úteis. Ou então a defasagem é tanta que já não servem a nenhum propósito. Por isso, devemos sempre limpar nosso data lake, liberando espaço e mantendo ele organizado para novos dados. (BERTHOLD, Data lake ou data swamp? Cuidados no armazenamento de dados 2021) DATA LAKEHOUSE - CONCEITOS DATA LAKEHOUSE – PARADIGMA DA DÉCADA O que é Data LakeHouse? Data LakeHouse é o novo termo no paradigma de arquitetura de plataforma de dados. LakeHouse é como a combinação de Data Lake e Data Warehouse (obviamente, a partir do termo que você deve ter entendido). No Data LakeHouse, você terá poder de processamento além dos Data Lakes, como S3, HDFS, Azure Blob, etc Em outras palavras, você não precisa carregar os dados em nenhum dos data warehouses para processar e fazer a análise ou o requisito de Business Intelligence. Você pode consultar diretamente os dados subjacentes em seus data lakes feitos de armazenamentos de 7 objetos ou Hadoop. Este método diminui a sobrecarga operacional no Data Pipelining e manutenção. Vantagem do Data LakeHouse Algumas das vantagens de ter Data LakeHouse são: Eliminação de trabalhos ETL simples: Na técnica de Data warehousing, os dados devem ser carregados no Data Warehouse para consulta ou para realizar a análise. Por exemplo, carregar os dados de seu Data Lake existente para o Data Warehouse, limpando e transformando-os no esquema de destino usando algumas das ferramentas ETL / ELT. Mas, usando a ferramenta Data LakeHouse, o processo ETL será eliminado conectando o mecanismo de consulta diretamente ao seu Data Lake. Redundância de dados reduzida Data LakeHouse remove redundância de dados. Por exemplo, você tem dados em várias ferramentas e plataformas, como dados limpos no data warehouse para processamento, alguns metadados na ferramenta de business intelligence, dados temporários em ferramentas ETL, etc. Esses dados devem ser mantidos e monitorados continuamente para evitar quaisquer problemas de sanidade de dados. Portanto, se você estiver usando uma única ferramenta para processar seus dados brutos, poderá superar esse problema de redundância de dados. Facilidade de governança de dados Data LakeHouse pode eliminar a sobrecarga operacional de gerenciamento de governança de dados em várias ferramentas. Se você estiver lidando com dados confidenciais, deve ter cuidado ao transferir dados de uma ferramenta para outra, para que cada ferramenta possa manter os controles de acesso e criptografia adequados. Mas se você usar uma única ferramenta Data LakeHouse, o gerenciamento de governança de dados pode ser feito de um ponto. Conecte-se diretamente a ferramentas de BI Ferramentas de habilitação do Data LakeHouse, como Apache Drill, oferecem suporte à conexão direta com algumas das ferramentas populares de BI, como (Tableau, PowerBI, etc.). Isso eventualmente reduz o tempo gasto dos dados brutos para a visualização em tempos exponenciais. Redução de custos No paradigma do Data Lake e do armazenamento, os dados devem ser armazenados em vários locais (Data Lake e Data Warehouse) e o custo do armazenamento também é alto. Comparativamente, o Data LakeHouse pode armazenar os dados em armazenamento barato, como armazenamento de objetos, como S3, Blob, etc. (Medium) PRIMEIRAS IMPRESSÕES UTILIZANDO O DELTA LAKE NA PRÁTICA Há algum tempo iniciei em um projeto onde a necessidade do cliente apontava para uma característica específica levando em conta a economia de tempo em relação ao desenvolvimento e também em relação aos custos visto que iniciamos tudo do zero em uma Cloud Provider. Não é sempre que temos esta oportunidade de encontrar projetos de tecnologia onde podemos dar o start inicial e onde até mesmo a arquitetura utilizada é proposta por você e seu time. 8 Foi nesse momento que me lembrei que já havia lido algo sobre o Delta Lake e que algumas características desta tecnologia poderiam ser úteis para atender algumas necessidades e também aproveitar e colocar uma pitada de inovação. O Delta Lake, como definido pela Databricks é uma camada de armazenamento open-source que traz os poder das transações ACID para o Apache Spark e workloads de big data. No final deste post vou deixar o link oficial para mais informações sobre o Delta Lake. O Delta Lake não substitui o Data Lake mas sim adiciona uma camada lógica sobre o data lake onde tudo pode ser controlado de uma forma escalável, flexível e com uma maior qualidade. Não vou entrar em muitos detalhes técnicos de programação em Spark com o Delta Lake mas sim mostrar algumas excelentes características e também alguns problemas encontrados no decorrer desses meses compartilhando com vocês minha experiência. Em primeiro lugar a criação de uma tabela delta é muito simples, tendo sua origem de dados, com arquivos CSV, JSON ou algum outro formato ou fonte podemos carregá-los para um dataframe no Spark e então persistí-los como delta, e é aqui que tudo se transforma. Ao criar uma tabela delta, na verdade ele não apenas cria o arquivos parquets que representam os seus dados ou tabela mas cria também um controle de log de transações que possibilita explorar todas as features oferecidas pelo delta que vamos comentar um pouco sobre cada uma mais para frente neste post. No delta podemos trabalhar com o conceito de camadas onde temos as tabelas bronze, silver e gold. As tabelas Bronze representam o seu dado no formato bruto (raw data), nas tabelas Silver podemos fazer a limpeza, deletes, transformações e enriquecimento dos dados. As tabelas Gold são as tabelas agregadas, sumarizadas e que atendem ao negócio como um todo. Essa organização nas três camadas não é obrigatória mas apenas uma organização lógica utilizada quando trabalhamos com delta lake. Uma das features interessantes sobre o delta é o Schema Evolution. Este possibilita que sejam adicionadas novas colunas na estrutura original de forma dinâmica sem que para isso você precise alterar tabelas, código ou ajustar o pipeline em sua ferramenta de ETL. Resumindo, se hoje sua tabela possui 600 colunas amanhã ela poderá ter as mesmas colunas mais N colunas novas de forma transparente. 9 O delta conta também com uma feature chamada Time Travel onde a cada operação de Update, Insert, Delete, Merge, Upsert etc. é criada uma versão daquele momento que pode ser resgatada sempre que houver necessidade. Imagine o seu time de cientistas de dados precisando fazer a execução de um modelo baseado em uma data no passado. Usando o delta você não precisaria criar uma estratégia de carga para atender apenas a esta necessidade, os dados podem ser resgatados de uma tabela delta baseado em suas versões ou em uma data com um simples código em Spark ou SQL. Vamos a mais um exemplo onde o Time Travel se mostra útil. Suponhamos que você cadastrou um cliente em janeiro cujo seu status era bronze e no decorrer desse tempo ele se tornou um cliente gold baseando-se em alguma regra de negócio como aumento de compras, intervalo entre compras, valor da compra etc. Então passados alguns meses você poderia consultar sua tabela e ver esse cliente com seu último status, como já estamos acostumados, porém poderia responder algumas perguntas como por exemplo, quando ele se tornou Silver ? ou com quantas compras ele se tornou Gold ? e quando foi isso? Bem, o delta te responde tudo isso em apenas uma tabela utilizando o Time Travel. O delta oferece a possibilidade de utilizar Merge, Upserts e Deletes baseados em uma coluna considerada como chave e também aceita chaves compostas. Sim. Agora podemos trabalhar com estas operações em nossos dados persistidos em parquet. Estas operações podem se tornar muito úteis em tempos de GDPR. Para alguém que fez um opt-out por exemplo, bastaria fazer um UPDATE na tabela necessária com o ID deste cliente economizando muito o tempo de reprocessamento para alterar isso em tabelas tradicionais usando parquet. A tabela delta uma vez criada pode servir como objeto para operações batch ou streaming sem a necessidade de ajustes ou pipelines adicionais. Podemos também garantir a integridade dos dados pois o delta conta com o Schema Enforcement, onde suas colunas podem ser tipadas e garantir que colunas necessárias estejam lá. Como o delta ainda podemos utilizar algumas técnicas tradicionais como compressão, utilizando snappy, por exemplo. Temos condição de trabalhar com partiçoes e buckets sem nenhum problema. Pensando em prós temos algumas vantagens como menor tempo de desenvolvimento e manutenção. Menor custo em processamento e também a possibilidade de trazer o poder de transações para estruturas de big data utilizando Spark. Utilizar APIs Spark para o delta com Python, Java, Scala onde aumenta a flexibilidade no desenvolvimento. Mas espere. Nem tudo são flores. Utilizar o delta também exige um pouco mais de esforço quando se trata de dominar alguns pontos que em alguns casos ainda não encontrei solução nem mesmo na documentação oficial. 10 O delta gera muitos arquivos parquets pequenos. O que pode ser um problema no processamento de grande volume de dados. Neste caso existem algumas configurações que podemos definir para este controle mas nem sempre funcionam como o esperado. Desta forma, enquanto por um lado temos um ganho no custo com processamento o mesmo não é verdade para armazenamento. Não é totalmente compatível com o Polybase da Microsoft. Pelo menos não até esta data na qual escrevo. Ler arquivos delta com tabelas criadas como External apontando para o Location dos arquivos parquets no Azure Synapse, por exemplo, geram duplicidade na leitura. A experiência com o delta lake pode não ser para pessoas que não estão dispostas a gastar um tempo de suas vidas pesquisando e tentando entender como resolver alguns desses problemas até que tudo esteja cem por cento implementado. A Databricks evolui a cada dia nesta tecnologia e acredito até que novas features serão lançadas em breve. No geral você acaba tendo mais pontos positivos se comparados aos negativos e sem contar que podemos continuar usando nosso querido Spark. Conforme comentado no início deste post segue o link oficial do Delta Lake e espero que tenha ajudado em uma melhor direção no momento de escolher uma tecnologia para seu pipeline de dados. (DOUGLAS, Primeiras impressões utilizando o Delta Lake na prática, 2020) FUNDAMENTOS DO DELTA LAKE Delta Lake pode ser considerado um padrão de arquitetura de dados que traz uma camada de estrutura e governança de dados para o Data Lake, garantindo a confiabilidade e melhorando a performance do processamento dos workloads. Consiste basicamente em organizar dados em diferentes camadas/áreas, desde a ingestão do dado em seu estado puro até a disponibilidade dos dados em tabelas limpas e agregadas para as necessidades do negócio. A camada Bronze contém os dados crus, da forma como é ingerido de diversas fontes (JSON, RDBMS, IoT...), os dados aqui são mantidos por anos e salvos como são, sem nenhuma transformação. A camada Silver oferece uma camada mais refinada dos dados, aqui os dados já são diretamente consultados e pronto para projetos de big data e AI. Os dados são unidos de várias tabelas bronze para enriquecer e atualizar registros baseado em atividades recentes. Os dados já estão limpos, normalizados e disponíveis como a única fonte da verdade do negócio. A camada Gold oferece agregações a nível de necessidade de negócios para usos particulares, os dados são preparados para um objetivo específico. O Delta Lake pode ser visto composto por 4 elementos: Delta Files, que são arquivos Parquet salvos no repositório de objetos. O Parquet é o estado da arte em termos de formato de arquivo para manter dados tabulares, é mais rápido e considerado mais poderoso que métodos tradicionais para dados tabulares por conta do uso de colunas ao invés de linhas, permitindo pular sobre dados irrelevantes rapidamente, as consultas são executadas em menos tempo. Além disso, oferece versionamento, metadados e salva logs de transações para manter as mudanças rastreáveis. Delta Tables, que são coleções de dados mantidos para uso pelo Delta Lake, consiste em Delta Files, Metastore (um tipo de catálogo para rastrear metadados dos dados) e o Delta Log para transações, que são salvos como Delta files. 11 Delta Optimization Engine é um motor de consulta que permite alta performance e oferece uma forma eficiente para processar dados no Data Lake, acelerando as operações e suportando uma variedade de workload vindo desde ETL de grande escala até consultas interativas ad-hoc. Delta lake Storage Layer é onde o dado é armazenado de fato para então ser acessado via Databricks. A ideia chave é que a empresa mantenha todos os dados em arquivos salvos no armazenamento de objetos. Isso é um ponto benéfico devido ao baixo custo de armazenamento utilizado para repositório. O Delta lake oferece ACID para as transações, Gerenciamento de Esquemas para tabelas, lida bem com a necessidade de escalar Metadados, unifica processamento batch e stream e versiona através de log de transações, permitindo auditar as alterações realizadas e inclui metadados e estatísticas sobre arquivos em tabelas. E vem para resolver muitos problemas enfrentados em outras arquiteturas, como: Dificuldade para alterar/atualizar dados Dificuldade para rollback quando o job falha no meio do caminho e já alterou/criou vários arquivos Dificuldade para conseguir processar dados em tempo real Problemas e custo alto para manter versões dos dados Dificuldade para manipular grande quantidade de metadados Problemas frequentes de "Too many files" Dificuldade para conseguir uma boa performance Problemas com qualidade dos dados afetando resultados das análises Se tratando de arquitetura de projeto de dados, o Delta Lake se mostra uma excelente opção para lidar com as necessidades e problemas do mundo real das organizações. Espero que você tenha gostado desse conteúdo! (EBRAIN, Fundamentos do delta lake, 2021) DATA LAKEHOUSE EXPLICADO EM 2 MINUTOS O data warehouse foi construído principalmente para lidar com dados de estrutura e volume relativamente alto. Ao longo do tempo, muitos aplicativos começaram a gerar dados semiestruturados e não estruturados que levaram ao nascimento do data lake, que pode lidar com variedades, volume e velocidade de dados e também é econômico em termos de armazenamento, mas não foi capaz de suportar bi/relatórios existentes. Isso leva à adição de outra camada física chamada data warehouse em data lakes, geralmente sem bancos de dados SQL, o que leva a um esforço e custo extras na construção do pipeline de dados e na duplicação de dados entre o data lake e o data warehouse. Aí vem data lakehouse para resgate Data lakehouse é uma camada virtual construída sobre data lake (não precisa ter uma camada de armazenamento separada de data warehouse) e pode suportar bi/relatórios, é armazenado em opções de armazenamento econômicas como Hadoop/Object Storage usando formatos de arquivo de código aberto ( Delta Lake , Apache Iceberg , Apache Hudi ) e processados diretamente por mecanismos de execução como Presto, Dremio etc. 12 Ele não precisa ter uma camada de armazenamento separada do data warehouse. Além disso, oferece alguns benefícios adicionais mencionados abaixo. Eu adoraria ouvir seus pensamentos na seção de comentários abaixo. Mais para vir sobre este tema! (GAURAV, Data lakehouse explicado em 2 minutos, 2021) BIG DATA COM DATA LAKE HOUSE Após quase 10 anos de evolução do Data Lake, considerar (2010 a 2020), algumas questões críticas para sua evolução são necessárias: 1. Primeiro, o armazenamento em nuvem baseado em object store; 2. Segundo, a necessidade de resolver transações ACID; 3. Terceiro, Arquitetura Batch + Streaming. As soluções em nuvem definiram um novo padrão de armazenamento, com mais flexibilidade e escala distribuída, conhecido como object store (ou armazenamento de objetos), exemplo Amazon S3 o mais famoso usado atualmente. Tornando-se muito atraente para grandes volumes de dados como os Data Lakes. Ao mesmo tempo que o armazenamento de objetos estava substituindo os casos de uso do sistema de arquivos, o Hadoop estava surgindo para a análise de dados. No início, o Hadoop foi visto por alguns como um retrocesso. Ele alcançou uma escalabilidade e economia de custos, mas limitou o que tornava os sistemas RDBMS tão poderosos e fáceis de trabalhar. Embora não exija flexibilidade adicional de esquemas, latências de consulta e desempenho geral diminuíram. Mas o ecossistema Hadoop continuou a se expandir e atender às necessidades dos usuários. O Spark elevou o desempenho para um novo nível e o Hive forneceu padrões de consultas SQL. Este é o futuro para o storage Data Lake… armazenamento de objetos! 13 O armazenamento de objetos pode gerenciar dados em formatos nativos para big data e ferramentas analíticas. Os processos Hadoop e Spark podem acessar diretamente o armazenamento de objeto por meio dos conectores. Porém ainda assim, sua implementação como armazenamentos de chave-valor torna difícil realizar transações ACID com baixa latência. Os data lakes não suportam transações ACID, não impõem a qualidade dos dados e sua falta de consistência/isolamento torna quase impossível unir escritas e leituras rodando processos batch e stream. Uma das questões críticas para empresas que já usam o Data Lake em grande escala é resolver os desafios ACID, para transações nas etapas de ETL e preparação dos dados principalmente. E se pensarmos conceitualmente em uma solução convergente: Data Lakehouse — Data Lake + Data Ware house obs: apesar de usarmos uma abordagem proposta pela Databricks, o objetivo principal é entendermos os desafios da evolução para o Data Lake. Outras implementações de arquiteturas (Cloudera, AWS, Google, IBM, propõem arquiteturas evolutivas como esta usando especificações diferentes). Vantagens de um Lakehouse A capacidade de derivar inteligência de dados não estruturados (texto, imagens, vídeo, áudio) torna o manuseio desses tipos de dados crítico para as empresas. Tradicionalmente, porém, os data warehouses não eram otimizados para esses tipos de dados não estruturados, tornando necessário o gerenciamento simultâneo de vários sistemas, um data lake, vários data warehouses e outros sistemas especializados. Manter vários sistemas pode ser caro e até atrasar sua capacidade de acessar insights de dados oportunos. Um único data lakehouse tem várias vantagens em relação a um sistema de várias soluções, incluindo: Menos tempo e esforço administrando Esquema simplificado e governança de dados Reduzida movimentação e redundância de dados Acesso direto aos dados para ferramentas de análise Armazenamento de dados econômico Um data lakehouse serve como uma plataforma única para data warehousing e data lake. Snowflake uma plataforma de Lakehouse Nativa A Snowflake é um dos melhores exemplos para abordarmos a plataforma de Lakehouse, inclusive existe uma possibilidade da primeira abordagem de Lakehouse ter sido criado para falar sobre a proposta da Snowflake… mesmo sendo depois usado amplamente na Databricks. 14 Uma plataforma de dados não é um conjunto distinto de ferramentas ou serviços. Em vez disso, deve ser uma plataforma integrada que execute muitas funções e cargas de trabalho, incluindo: Acesso rápido aos dados Analytics Exploração de dados Engenharia de Dados para ingestão e transformação de dados Ciência de Dados para a criação de IA e modelos de Machine Learning Desenvolvimento e operação de aplicações de dados Data sharing rápido e seguro de dados entre usuários autorizados Uma plataforma flexível como o Snowflake permite que você use ferramentas tradicionais de business intelligence e tecnologias mais novas e avançadas dedicadas à inteligência artificial, aprendizado de máquina, ciência de dados e outras atividades analíticas de dados voltadas para o futuro. Ele combina data warehouses, data marts de assuntos específicos e data lakes em uma única fonte de verdade que alimenta vários tipos de Workload. Avançando um pouco mais com a visão agora da Databricks Para isso vamos entender como o Delta Lake, um camada de armazenamento ACID sobre o armazenamento de objetos em nuvem desenvolvido na Databricks. Os principais sistemas de “big data” de código aberto, incluindo Apache Spark, Hive e Presto, suportam leitura e gravação usando armazenamento de objetos baseados em formatos de arquivo como Apache Parquet e ORC. Serviços em nuvem, incluindo AWS Athena, Google BigQuery e o Redshift também podem consultar diretamente esses sistemas e formatos de arquivo abertos. Os data lakehouses também garantem que as equipes tenham os dados mais completos e atualizados disponíveis para projetos de ciência de dados, aprendizado de máquina e análise de negócios. 15 O Delta Lake fornece transações ACID, tratamento de metadados escalonáveis e unifica o processamento de dados batch e streaming. O Delta Lake é executado sobre o Data Lake existente e é totalmente compatível com as APIs do Apache Spark. Delta Lake é construído principalmente sobre três pilares que abordam os desafios de confiabilidade, desempenho e engenharia: Dados limpos e de qualidade; Visualizações consistentes em cargas de trabalho de dados batch e stream; Otimizado e fácil de adotar. Especificamente, o Delta Lake oferece: Transações ACID no Spark: níveis de isolamento serializáveis asseguram que os leitores nunca vejam dados inconsistentes. Manipulação de metadados escaláveis: aproveita a capacidade de processamento distribuído do Spark para lidar com todos os metadados para tabelas de escala de petabytes com bilhões de arquivos com facilidade. Unificação de stream e batch: uma tabela no Delta Lake pode ser atualizada via streaming. A ingestão de dados streaming, permitem as consultas interativas imediatamente. Flexibilidade de esquema: manipula automaticamente as variações de esquema para evitar a inserção de registros inválidos durante a ingestão. Dados históricos: o controle de versão de dados permite reversões, trilhas de auditoria de histórico completo e experimentos de aprendizado de máquina reproduzíveis. Upserts e Delete: dá suporte a operações de upsert, atualização e exclusão para habilitar casos de uso complexos, como Change-Data-Capture, operações SCD (slowly- Changing-Dimension), streaming Upserts e assim por diante. As otimizações do mecanismo Delta possibilitam as operações do Delta Lake serem realizadas com alto desempenho, dando suporte a uma variedade de cargas de trabalho que variam de processamento de ETL em larga escala até consultas interativas e ad hoc. Qual formato o Delta Lake usa para armazenar os dados ? Delta Lake usa arquivos Parquet com versão para armazenar seus dados em nuvem. Além das versões, Delta Lake também armazena um log de transações para manter o controle de todos os commits feitos na tabela ou diretório de armazenamento de blob para fornecer transações ACID. 16 Delta Lake tem três estágios de enriquecimento de dados: Bronze: contêm os dados brutos ingeridos de várias fontes, como arquivos json, dados de sistemas RDBMS, dados IoT etc. Silver: fornecem uma visão mais refinada dos dados Bronze. Gold: fornece agregados de nível de negócios geralmente usados para relatórios e painéis. Considere os dados se movendo por diferentes tabelas denominadas Bronze, Silver e Gold. Os dados dos jobs de Streaming e Batch são primeiro capturados na tabela Bronze em seus formatos brutos, depois nas tabelas Silver são limpos e o processamento é feito para torná-los "consultáveis". As tabelas Gold contêm métricas de negócios chaves, agregadas, que são consultadas com frequência. 17 Na imagem acima podemos perceber uma simplificação dos pipelines, sendo este um dos maiores desafios atualmente da engenharia de dados. A questão principal não é o Delta Lake como solução, e sim o que ele se propõe a resolver, trazendo uma abordagem de manter toda a evolução dos últimos anos com uma arquitetura evolutiva, e integrado as principais APIs dos provedores em nuvem. (ANDERSON, Big Data com Data Lakehouse, 2020) LINKS ÚTEIS https://medium.com/nanolearning/um-contraponto-para-o-data-lake-46eba4f31043 https://ichi.pro/pt/o-que-ha-dentro-do-delta-lake-58914778121023 DELTA APLICAÇÃO E EVOLUÇÃO DO ESQUEMA DELTA LAKE COM MERGE SCHEMA E OVERWRITE SCHEMA Merge Schema não é o melhor quando os esquemas são completamente diferentes. É melhor para alterações de esquema incrementais. Definir overwriteSchema como TRUE apagará o esquema antigo e permitirá que você crie uma tabela completamente nova. Os Delta oferecem recursos poderosos de evolução de esquema que não estão disponíveis nos Parquet. Os delta também impõem esquemas e tornam menos provável que uma gravação incorreta atrapalhe todo o seu lago. Delta oferece alguns ótimos recursos que simplesmente não estão disponíveis em lagos de parquet simples. (MRPOWERS, Delta Lake schema enforcement and evolution with mergeSchema and overwriteSchema, 2019) APLICAÇÃO DO ESQUEMA DELTA LAKE Esta postagem ensina sobre a imposição de esquema do Delta Lake e demonstra como ele o protege de adicionar arquivos com esquemas incompatíveis à sua tabela Delta. As tabelas Parquet não oferecem suporte à imposição de esquema integrada, portanto, aceitam dados com qualquer esquema, o que não é necessariamente desejável. A gravação acidental de arquivos Parquet em seu data lake pode ser surpreendentemente difícil de desfazer. Data lakes (por exemplo, tabelas Parquet) são schema-on-read, o que significa que os mecanismos de execução precisam determinar o esquema ao executar consultas. Os data warehouses são schema-on-write, o que significa que eles verificam o esquema quando os dados são gravados. O Delta Lake oferece a flexibilidade dos data lakes e também é schema-on-write, oferecendo a segurança e as garantias dos data warehouses. A imposição de esquema do Delta Lake é um grande benefício de esquema na gravação fornecido aos usuários. Vamos começar observando como as tabelas Parquet sem uma entrada de metastore do Hive associada não impedem que você anexe dados com um esquema diferente, o que é potencialmente perigoso. Visitaremos as tabelas Parquet armazenadas no metastore do Hive mais tarde. Tabelas parquet não têm aplicação de esquema Esta seção demonstra como as tabelas Parquet não têm nenhuma imposição de esquema integrada, portanto, você pode anexar dados por engano com um esquema diferente a uma tabela Parquet. 18 Comece criando um DataFrame com colunas first_name e grave idade o em uma tabela Parquet. Agora vamos anexar um DataFrame com um esquema diferente à tabela Parquet. Crie um DataFrame com colunas first_name e favorite_color, um esquema diferente de antes e anexe-o à tabela Parquet existente. O PySpark permite anexar um DataFrame com um esquema diferente à sua tabela Parquet. Diferentes esquemas em uma única tabela Parquet entrarão em conflito e os leitores terão que resolver esse conflito no futuro. É melhor para o mecanismo de consulta lançar um erro se você gravar dados com um esquema incompatível por padrão. O PySpark, infelizmente, não pode executar essa verificação de pré-gravação ao trabalhar com tabelas Parquet porque encontrar o esquema da tabela Parquet subjacente envolveria a verificação de todos os arquivos individualmente, o que seria lento para uma tabela Parquet grande. Leia na tabela Parquet para um DataFrame e inspecione o conteúdo. Este não é um grande resultado. O PySpark encontrou dois esquemas diferentes ao ler os arquivos Parquet e está mostrando apenas um deles. Você precisa definir manualmente mergeSchemaa para true ao ler os dados para ver todos os dados. Novamente, isso não é culpa do PySpark. O PySpark está fornecendo o melhor comportamento padrão possível devido às limitações de esquema na leitura das tabelas Parquet. 19 Vejamos como o Delta Lake oferece suporte à imposição de esquema e fornece um melhor comportamento padrão pronto para uso. A aplicação do esquema do Delta Lake é integrada A mensagem de erro fornece uma explicação descritiva de por que a operação falhou e duas maneiras diferentes de habilitar a gravação de dados com esquemas incompatíveis. O comportamento padrão de imposição do esquema Delta Lake é desejável. Você não deseja permitir que dados com um esquema incomparável sejam adicionados a uma tabela Delta por padrão. Você só deseja permitir incompatibilidades de esquema quando o usuário declara explicitamente que é isso que deseja. Delta Lake escreve com mergeSchema definido como verdadeiro 20 Observe que ao ler a tabela Delta, você não precisa configurar como fez mergeSchemaa ao true ler a tabela Parquet. Ao ler uma tabela Parquet com arquivos de esquemas diferentes, você precisa definir manualmente mergeSchema como true. O comportamento padrão do Delta Lake é muito melhor. Os leitores da tabela Parquet precisam, de alguma forma, saber que precisam definir quando leem mergeSchemaa true tabela Parquet que contém arquivos com esquemas diferentes, o que é uma demanda irracional. Os profissionais de dados podem estar lendo dezenas ou centenas de tabelas Parquet. Não se pode esperar que eles acompanhem quando precisam definir mergeSchemae true quando não é necessário. Delta Lake habilita o autoMerge para mesclar esquemas por padrão Você também pode definir uma propriedade do Spark que será habilitada autoMerge por padrão. Depois que essa propriedade for definida, você não precisará defini-la manualmente mergeSchemaa ao true gravar dados com um esquema diferente em uma tabela Delta. Veja como habilitar autoMerge: Podemos ver que os dados foram anexados e não precisamos definir mergeSchemaa ao true executar a gravação na tabela Delta. Mas cuidado! Veja de perto a propriedade que habilita autoMerge e repare que ela é específica para Delta Lake: spark.databricks.delta.schema.autoMerge.enabled Essa propriedade de configuração não afeta as leituras do Parquet. Você ainda precisa definir manualmente mergeSchemaa para true ao ler uma tabela Parquet, como antes, mesmo depois de definir essa propriedade. Este exemplo demonstrou dois conceitos importantes. Vamos discuti-los separadamente. 21 A imposição de esquema é um recurso do Delta Lake que impede que você anexe dados com um esquema diferente a uma tabela, a menos que especifique explicitamente que a tabela deve permitir que dados com esquemas diferentes sejam gravados. As tabelas Parquet não oferecem suporte à imposição de esquema. Os usuários do Parquet precisam implementar manualmente a lógica de negócios de imposição de esquema como uma verificação pré-gravação se quiserem garantir que os dados com um esquema diferente não sejam gravados. A evolução do esquema refere-se à capacidade de uma tabela se adaptar a diferentes esquemas ao longo do tempo, geralmente permitindo a inclusão de colunas adicionais. Nosso exemplo demonstrou a evolução do esquema, mas é um tópico importante, então vamos abordá-lo com mais detalhes em uma postagem de blog separada. Aplicação de esquema do Delta Lake versus restrições A imposição de esquema refere-se a verificações em nível de esquema quando os dados são anexados a uma tabela existente. Refere-se à presença de certas colunas e tipos de dados. Delta Lake também oferece suporte a restrições , que são verificações de nível de valor quando os dados são anexados. Você pode adicionar uma restrição que o impedirá de adicionar null valores a uma determinada coluna, por exemplo. A imposição de esquema e as restrições estão relacionadas porque ambas verificam a qualidade de seus dados antes de gravá-los, mas são conceitos separados. Frequentemente, você desejará aplicar imposição de esquema e restrições. Casos extremos de imposição de esquema Esta postagem aborda a situação de imposição de esquema mais comum, mas há alguns casos extremos que não são discutidos. Consulte esta postagem de blog para obter mais informações sobre casos extremos de imposição de esquema. Por que gravações incorretas podem ser difíceis de corrigir em tabelas Parquet Gravações incorretas são surpreendentemente difíceis de desfazer em tabelas Parquet. Suponha que você execute uma operação de gravação com um esquema incompatível em uma tabela Parquet particionada armazenada na nuvem. A operação de gravação gera 500 arquivos em diferentes partições. Não é fácil identificar os 500 arquivos que foram gravados na tabela Parquet. Na verdade, você nem saberá quantos arquivos foram gravados quando estiver tentando depurar isso. Depois de identificar os 500 arquivos a serem excluídos, você precisa garantir que seu script para excluir os dados ruins não exclua acidentalmente os dados bons também! A remoção manual de dados é perigosa. Um único caractere glob extraviado pode fazer com que você apague acidentalmente todos os seus dados. A exclusão manual de dados também pode interromper a automação do pipeline ETL downstream. É uma operação perigosa que pode criar uma mudança de quebras de ETL. O Delta Lake fornece dados com versão e transações ACID, portanto, você não precisa executar nenhum hotfix da tabela Parquet. Você pode facilmente reverter uma tabela Delta para uma versão anterior se cometer um erro. Aplicação de esquema para tabelas Parquet armazenadas no metastore do Hive Até agora, discutimos apenas arquivos Parquet sem entradas de metastore do Hive associadas. As tabelas Parquet armazenadas no Hive Metastore têm um comportamento padrão de imposição de esquema completamente diferente. Vamos criar uma tabela Parquet no Hive Metastore e observar os padrões de aplicação do esquema. 22 As tabelas Parquet armazenadas no Hive Metastore têm imposição de esquema incorporada apenas se você estiver acessando usando o nome da tabela. Se você esquecer de usar o nome da tabela e usar o caminho diretamente, poderá ignorar a aplicação do esquema e bagunçar sua tabela. É impossível ignorar a imposição do esquema Delta Lake. Além disso, você não pode definir uma propriedade de configuração ou usar mergeSchemaa uma evolução de esquema segura para tabelas Parquet. MergeSchemaa é ignorado ao gravar em uma tabela Parquet: Conclusão O Delta Lake foi desenvolvido com imposição de esquema pronta para uso, o que é uma ótima maneira de proteger a qualidade de sua tabela de dados. As tabelas Parquet sem informações do metastore do Hive não têm imposição de esquema integrada, não permitem bons padrões de esquema de mesclagem e são difíceis de corrigir se uma operação de gravação der errado. As tabelas Parquet armazenadas no metastore do Hive permitem a imposição de esquema, mas são rígidas e não tão flexíveis quanto a imposição de esquema oferecida pelo Delta Lake. A imposição de esquema é uma das muitas vantagens que o Delta Lake oferece em comparação com as tabelas Parquet. Você pode facilmente converter de Parquet para Delta Lake e aproveitar esses recursos para suas cargas de trabalho. (MATHEUS, Delta Lake Schema Enforcement, 2022) APPENDING OVERWRITING WITH DIFFERENT SCHEMA TO DELTA LAKE VS PARQUET 23 Delta Lake tem características únicas e uma delas é o Schema Enforcement. A tentativa de adicionar dados a um arquivo Delta com esquema diferente (diferentes nomes de coluna, diferentes tipos de dados etc.) mostrar o esquema de dados atual e o esquema dos dados que você está tentando anexar. Cabe a você corrigir o esquema antes de anexar os dados ou, se desejar que as novas colunas sejam adicionadas ao esquema existente, você pode optar por fazer a Evolução do Esquema aprovando o novo esquema. Você pode encontrar um exemplo disso em um dos meus posts anteriores clicando AQUI https://medium.com/swlh/do-delta-and-parquet-files-refresh-automatically-when-appending- new-data-to-them-ffa0e05d3c3e Usarei o mesmo conjunto de dados que usei aqui , que é um pequeno conjunto de dados json que consiste em 100.000 registros disponíveis em “/databricks-datasets/structured- streaming/events/”. O conjunto de dados tinha duas colunas “ ação ” e “ data ”. Adicionei uma coluna extra “ id ” ao conjunto de dados, que é um número exclusivo que começa em 1 e é incrementado em um. Como o conjunto de dados contém 100.000 registros, a coluna possui números de 1 a 100.000 24 Escrevi os dados como um arquivo delta e, em seguida, li os dados delta em um quadro de dados events_delta. O número de registros no quadro de dados events_delta mostra 100.000 registros e o esquema mostra que existem 3 colunas. Eliminei o a coluna id do quadro de dados events_delta conforme mostrado abaixo. Começarei anexando os dados que possuem 2 colunas (ação, data) ao arquivo Delta que possui um esquema de 3 colunas (ação, data, id). Esta ação causará um problema? Delta negará a transação? e não é considerado uma incompatibilidade de esquema?!!. Olhando abaixo, você descobrirá que tudo correu bem e nenhuma exceção foi levantada. 25 O processo de acréscimo funcionou bem e conseguimos adicionar 100.000 registros extras, portanto, agora o arquivo Delta tem 200.000 registros. Então, na verdade, essa transação de acréscimo era totalmente aceitável e não havia nenhuma incompatibilidade de esquema. Vamos ver por que isso não é considerado incompatibilidade de esquema. Mostrarei o esquema da tabela Delta e você precisa observar uma propriedade importante da coluna id abaixo que é (nullable = true). Isso significa que, quando descartamos a coluna id e tentamos anexar os dados apenas com (ação, data), Delta considerou que ainda estamos adicionando valores para a coluna id, exceto que considera todos os valores como nulos desde que a coluna id foi descartada. Portanto, ele considerou adicionar 100.000 nulos na coluna id e não considerou isso uma incompatibilidade de esquema. Vamos verificar agora quantos valores de id dos 200.000 valores são nulos. Devemos esperar que o resultado seja 100.000. Portanto, o que discuti acima foi uma tentativa de anexar à tabela Delta depois de descartar uma das colunas. Vamos ver o que acontecerá se eu repetir as mesmas etapas enquanto altero o modo para sobrescrever em vez de anexar. 26 Na verdade, você verá abaixo que o esquema Delta não mudou e o número de colunas permaneceu como está. O arquivo é substituído pelos 100.000 registros do quadro de dados events_delta e nulos foram adicionados na coluna id. Se você quiser que o esquema mude de 3 colunas para apenas 2 colunas (ação e data), você deve adicionar uma opção para isso, que é option(“overwriteSchema”, “true”). Portanto, para mostrar a você, primeiro excluí o arquivo delta existente, conforme mostrado abaixo. Em seguida, repeti todas as etapas acima desde o início até a parte de descartar a coluna id. Depois disso fiz o seguinte. Como você pode ver acima, depois de adicionar a opção (“overwriteSchema”, “true”) para sobrescrever o schema , o schema agora tem apenas 2 colunas, action e date ( id não existe mais). Considere agora que temos um arquivo Parquet que já possui os mesmos 100.000 registros do arquivo json mencionado acima, com um esquema que possui as mesmas 3 colunas (ação, data, id). Eu carreguei os dados em um data frame events_parquet. 27 Vamos agora ver a reação do Parquet ao anexar os dados depois de descartar o id da coluna. Depois de anexar os novos registros, os dados substituíram os dados que estavam no arquivo Parquet. Portanto, perdemos 100.000 registros que existiam no arquivo antes e agora temos apenas no arquivo os 100.000 registros anexados de 2 colunas em vez de 3 colunas que existiam antes. Mudar o modo para overwrite , fará a mesma coisa que append fez, exceto que precisaríamos atualizar para ver os resultados, lendo os dados novamente, que são 100.000 registros das 2 colunas (ação, data) que substituíram o antigo schema e excluiu os dados existentes. 28 Espero que tenham achado o post interessante e que eu tenha conseguido demonstrar o assunto de uma forma boa e clara. (AMANY, Appending/Overwriting with Different Schema to Delta Lake Vs Parquet, 2020) DATA SKIPPING Quando fazemos uma consulta, por exemplo, essa abaixo, o lakehouse traz um Layer de estatística antes de consultar. O delta não retorna todos os arquivos para ser filtrado somente no Spark. Você não ler 10 terabytes, coloca os 10 terabytes na memória para depois consultar no Spark, não. Antes de entrar no lake, você dá uma olhada nas estatísticas e consulta somente os arquivos que você quer. Essa é a grande sacada do lakehouse, você tem que ir no data lake, mas você vai menos. https://www.youtube.com/watch?v=eqNRzwjihRg&t=1807s 1:13:30 29 10 Configurações úteis para tabelas delta ✅ delta.appendOnly: esta propriedade de configuração no Delta Lake que permite apenas acréscimos à tabela Delta, não permitindo atualizações e exclusões. ✅ delta.autoOptimize.autoCompact e delta.autoOptimize.optimizeWrite permitem a otimização automática de gravações e compactação de pequenos arquivos para melhorar o desempenho da consulta. ✅ delta.checkpoint.writeStatsAsJson controla se as estatísticas da tabela são escritas no formato JSON durante o checkpointing, o que pode ser útil para depuração e monitoramento. ✅ delta.columnMapping.mode especifica o modo de mapeamento de coluna ao executar operações de evolução de esquema. ✅ delta.deletedFileRetentionDuration especifica a duração pela qual os arquivos excluídos devem ser retidos na tabela para reversões e recuperação. ✅ delta.logRetentionDuration determina em determina por quanto tempo o log de transações Delta Lake deve ser mantido, também usado para fins de recuperação e reversão. ✅ delta.randomizeFilePrefixes adiciona um prefixo aleatório aos nomes de arquivo ao gravar dados na tabela, o que pode ajudar a evitar colisões de nomenclatura e melhorar o desempenho de gravação. ✅ delta.tuneFileSizesForRewrites melhora o desempenho de grandes atualizações ou mesclagens otimizando o tamanho dos arquivos Delta. ✅ delta.dataSkippingNumIndexedCols controla o número de colunas a serem indexadas ao usar o pulo de dados, o que pode melhorar o desempenho da consulta. INSIGHTS Fala do vídeo: Dw vs. Data Lake vs. MDW vs. Data Lakehouse para Pipeline de Dados O dado no DW estava enviesado, e como tiramos o viés desse dados? Indo para o Data Lake. 30 Não ache que você vai para tecnologias novas com arquiteturas velhas. Não tente resolver problemas novos com soluções antigas ou com formatos e mentes antigas. O MDW a ideia é você ter armazenamento e processamento desacoplado. Segundo ponto são as características que você tem por dentro dele: compressão colunar, você paga pelo que usa etc. Quando você vem para o MDW a ideia é você escrever e integrar em datasets. O que é um dataset? É um conjunto de dados para uma visualização específica. São tabelões que compõem uma visão específica que você deseja dar para aquele departamento, distrito etc. Tudo isso é trabalhado na lógica de processamento, eu não lido mais com chave primária, no Big Query, por exemplo eu não tenho chave primária. São coisas atuais com modelagens atuais. Falando sobre Delta Lake: Eu continuo tenho meu data lake, mas no topo eu coloco uma tecnologia para poder aprimorar e trazer algumas features que eu não tenho no data lake. Conseguimos fazer na Delta, por exemplo, transações ACID, coisas que eu não conseguia fazer com o data lake cru. No delta temos algumas features texto extraído do livro delta: ACID GUARANTEES O Delta Lake garante que todas as alterações de dados gravadas no armazenamento sejam confirmadas para durabilidade e tornada visível para os leitores atomicamente. Em outras palavras, não mais parcial ou arquivos corrompidos! Discutiremos mais sobre as garantias de ACID como parte do log de transação mais adiante neste capítulo SCALABLE DATA AND METADATA HANDLING Como o Delta Lake é construído em data lakes, todas as leituras e gravações usando Spark ou outro os mecanismos de processamento distribuído são inerentemente escaláveis à escala de petabytes. No entanto, ao contrário da maioria dos outros formatos de armazenamento e mecanismos de consulta, o Delta Lake aproveita o Spark para dimensionar todo o processamento de metadados, lidando com metadados de bilhões de arquivos para tabelas em escala de petabytes. Discutiremos mais sobre o log de transações mais adiante neste capítulo. AUDIT HISTORY AND TIME TRAVEL O log de transações do Delta Lake registra detalhes sobre todas as alterações feitas nos dados fornecendo uma trilha de auditoria completa das mudanças. Esses instantâneos de dados permitem que os desenvolvedores para acessar e reverter para versões anteriores de dados para auditorias, reversões ou para reproduzir experimentos. Iremos aprofundar este tópico no Capítulo 3: Viagem no Tempo com Delta. SCHEMA ENFORCEMENT AND SCHEMA EVOLUTION O Delta Lake impede automaticamente a inserção de dados com um esquema incorreto, ou seja, não corresponde ao esquema da tabela. E quando necessário, permite que o esquema da tabela ser desenvolvido explicitamente e com segurança para acomodar dados em constante mudança. Vamos mergulhe mais fundo neste tópico no Capítulo 4 com foco na aplicação de esquema e evolução. SUPPORT FOR DELETES UPDATES, AND MERGE A maioria das estruturas de processamento distribuído não suporta modificação de dados atômicos operações em data lakes. Delta Lake suporta mesclagem, atualização e exclusão, operações para permitir casos de uso complexos, incluindo, entre outros, captura de alteração de dados (CDC), operações de dimensão de alteração lenta (SCD) e streaming upersets. Iremos nos aprofundar neste tópico no Capítulo 5: Modificações de dados em Delta STREAMING AND BATCH UNIFICATION 31 Uma tabela Delta Lake tem a capacidade de funcionar em lote e como uma fonte de streaming e afundar. A capacidade de trabalhar em uma ampla variedade de latências, desde ingestão de dados de streaming para preenchimento de histórico em lote para consultas interativas, tudo funciona sai da caixa. Iremos nos aprofundar neste tópico no Capítulo 6: Aplicação de streaming transações com Delta. O Delta Lake é uma camada Delta (camada ACID) em cima do seu data Lake. O mercado foi em direção ao MDW e a Databricks foi muito mais em direção do Data lakehouse. Com o data lake eu tenho a unificação do dado, com o lakehouse eu tenho minha unificação de processo, agora eu consigo fazer transações petabytes com garantias ACID. O lakehouse é simplesmente o formato de um dado: Delta, Iceberg, Hud. Claro que a tecnologia de processamento tem que está apta para esses formatos. O meu custo continua sendo o data lake. O outro “custo” que não é custo, é simplesmente que a minha tecnologia de processamento seja compatível com o formato que eu desejo usar, por exemplo, formato Delta. Fala do vídeo: Data Warehouse vs. Data Lakehouse - Casos de Uso e Comparações com Orlando Marley Caindo em problemas de soluções de tecnologia: Quando começamos a criar soluções que na verdade estão resolvendo problemas que você mesmo criou, e não que o seu cliente tem. Não é o técnico que manda no projeto, e sim o business. Eu preciso entender primeiramente o que você faz para depois te propor uma solução. Quando criamos uma solução estamos querendo eliminar uma complexidade na ponta, e não transferir a complexidade para a ponta. Fala: Lakehouse: Delta Lake 2.0.0 e Apache Spark 3.2 para Pipelines de Dados Inteligentes | Live #77 O lakehouse é a combinação do melhor do data lake com o melhor do data warehouse. No data lake é commodit e um ambiente muito semiestruturado e não estruturado. O data warehouse traz transações ACID, garantia do dado, informações estruturadas dentro de tabela. Falas gerais: Qual problema você quer resolver? Em que momento a sua empresa está e qual o grau de maturidade da sua empresa? Você não deveria usar uma tecnologia só porque o conceito é mais moderno. No DW tem a barreira de escalabilidade da consulta. No Data Lake tem a barreira do dado que está dentro do lake. O Lakehouse é o caminho para unir o melhor dos dois mundos. No processo da camada RAW para Bronze tente sempre utilizar o APPEND-ONLY Bibliografia ARQUITETURA de Big data. Docs Microsoft, 12 de Fev. de 2018. Disponível em: https://docs.microsoft.com/pt-br/azure/architecture/data-guide/big-data/ Acesso em: 04 de mar. de 2021. LUZ, Arthur. A INDUSTRIA 4.0, nuvem e Big Data. DBA Brasil, 26 Fev. de 2019. 32 Disponível em: https://www.youtube.com/watch?v=srylO_Rs95Y&t=4914s Acesso em: 06 de mar. de 2021. LEITE, Douglas. Primeiras impressões utilizando o Delta Lake na prática, 6 de Out. de 2020. Disponível em: https://www.linkedin.com/pulse/primeiras-impress%C3%B5es-utilizando-o-delta- lake-na-pr%C3%A1tica-douglas-leite/?trk=read_related_article-card_title Acesso em: 26 de mar. de 2022. CARVALHO, Ebrain. Fundametnos do delta lake. 20 de Nov. de 2021 Disponível em:https://www.linkedin.com/pulse/fundamentos-do-delta-lake-ebraim- carvalho/?originalSubdomain=pt Acesso em: 26 de mar. De 2022 AGGARWAI, Gaurav, Data lakehouse explicado em 2 minutos, 5 de Mar. De 2021 Disponível em: https://medium.com/@gaurav2485/data-lakehouse-explained-in-2-minutes- 9305b63877a8 Acesso em: 27 de mar. De 2022 BERTHOLD, Guilherme Data lake ou data swamp? Cuidados no armazenamento de dados, 24 de Mar. de 2021. Disponível em: https://blog.zetadados.com.br/data-lake-ou-data-swamp-cuidados-no- armazenamento-de-dados/ Acesso em: 09 de jun. De 2022 PAULUCCI, Anderson, Big Data com Data Lakehouse, 31, Ago. 2020. Disponível em: https://anderson-paulucci.medium.com/big-data-com-data-lakehouse- cbd7b4300a81 Acesso em: 19 de Jul. 2022 MRPOWERS, Delta Lake Schema enforcement and evolution with mergeSchema and overwriteSchema, 25, Out. 2019. Disponível em: https://mungingdata.com/delta-lake/schema- enforcement-evolution-mergeschema-overwriteschema/ Acessado em: 11 de Fev. 2023 POWERS, Mattew, Delta Lake Schema Enforcement, 16, Nov, 2022. Disponível em: https://delta.io/blog/2022-11-16-delta-lake-schema-enforcement/ Acessado em: 11 de Fev. 2023 ABDELHALIM, Amany, Appending/Overwriting with Different Schema to Delta Lake Vs Parquet, 24, Out, 2020. Disponível em: https://medium.com/@amany.m.abdelhalim/appending- overwriting-with-different-schema-to-delta-lake-vs-parquet-6b39c4a5d5dc Acessado em: 11 de Mar. 2023 33