Combinando Delta Lake com MinIO para Data Lakes Multi-Cloud

Delta Lake é uma estrutura de armazenamento de software livre usada para construir data lakes sobre o armazenamento de objetos em uma arquitetura Lakehouse. oferece suporte a transações ACID, manipulação de metadados escalonáveis e streaming unificado e processamento de dados em lote. O Delta Lake é comumente usado para fornecer confiabilidade, consistência e escalabilidade aos aplicativos Apache Spark. O Delta Lake é executado na parte superior do armazenamento de data lake existente, como MinIO, e é compatível com as APIs do Apache Spark. O Delta Lake O artigo original do Delta Lake ( ) descreve como ele foi criado para armazenamento de objetos em nuvem. Quando para tabelas externas, eles confiaram no MinIO. Os clientes do HPE Ezmeral Runtime Enterprise . O MinIO oferece suporte aos requisitos de durabilidade do Delta Lake porque o MinIO segue modelos rígidos de consistência de leitura após gravação e lista após gravação para todas as operações de i/o nos modos distribuído e autônomo e é amplamente reconhecido por executar cargas de trabalho do Delta Lake. Delta Lake: armazenamento de tabelas ACID de alto desempenho sobre armazenamentos de objetos em nuvem a Vertica testou o uso do Delta Lake executam o Delta Lake no MinIO Muitas organizações dependem de armazenamentos de objetos nativos da nuvem, como MinIO e AWS S3, para abrigar grandes conjuntos de dados estruturados, semiestruturados e não estruturados. Cada tabela é armazenada como um conjunto de objetos que são Parquet ou ORC e organizados em partições. Consultas em arquivos grandes são basicamente verificações executadas rapidamente. Sem o Delta Lake, as cargas de trabalho Spark mais complexas, especialmente aquelas que modificam, adicionam ou removem dados, enfrentam desafios de desempenho e correção sob cargas pesadas de vários usuários/vários aplicativos. As atualizações de vários objetos não são atômicas e as consultas não são isoladas, o que significa que, se uma exclusão for realizada em uma consulta, outras consultas simultâneas obterão resultados parciais à medida que a consulta original atualiza cada objeto. Reverter gravações é complicado e uma falha no meio de uma atualização pode resultar em uma tabela corrompida. O verdadeiro matador de desempenho são os metadados – para tabelas massivas com milhões de objetos que são arquivos Parquet contendo bilhões ou trilhões de registros, as operações de metadados podem interromper os aplicativos criados em um data lake. O Delta Lake foi projetado para combinar a confiabilidade transacional dos bancos de dados com a escalabilidade horizontal dos data lakes. O Delta Lake foi criado para oferecer suporte a cargas de trabalho no estilo OLAP com uma camada de armazenamento de tabela ACID sobre armazenamentos de objetos nativos da nuvem, como MinIO. Conforme descrito no artigo , “a ideia central do Delta Lake é simples: mantemos informações sobre quais objetos fazem parte de uma tabela Delta de maneira ACID, usando um método de gravação log de frente que é armazenado no armazenamento de objeto de nuvem.” Os objetos são codificados em Parquet e podem ser lidos por um mecanismo que entende Parquet. Múltiplos objetos podem ser atualizados de uma só vez “de maneira serializada enquanto ainda atingem alto desempenho paralelo de leitura e gravação”. O log contém metadados, como estatísticas min/max para cada arquivo, “permitindo pesquisas de metadados mais rápidas em ordem de magnitude” do que pesquisar arquivos diretamente no armazenamento de objeto. Delta Lake: armazenamento de tabelas ACID de alto desempenho sobre armazenamentos de objetos na nuvem Delta Lake oferece o seguinte: o Delta Lake garante que todas as alterações nos dados sejam gravadas no armazenamento e confirmadas para durabilidade, ao mesmo tempo em que estão disponíveis para usuários e aplicativos atomicamente. Não há mais arquivos parciais ou corrompidos no seu data lake. Garantias do ACID: todas as leituras e gravações usando o Spark (ou outro mecanismo de processamento distribuído) podem ser dimensionadas para petabytes. 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 e pode lidar com metadados de bilhões de arquivos para tabelas em escala de petabytes com eficiência. Tratamento escalonável de dados e metadados: o log de transações do Delta Lake registra detalhes sobre todas as modificações feitas nos dados, incluindo uma trilha de auditoria completa das alterações. Os instantâneos de dados permitem que os desenvolvedores acessem e revertam para versões anteriores de dados para auditorias, reversões ou por qualquer outro motivo. Histórico de auditoria e viagem no tempo: o Delta Lake impede automaticamente a inserção de dados que não correspondem ao esquema de tabela existente. No entanto, o esquema da tabela pode ser desenvolvido explicitamente e com segurança para acomodar alterações na estrutura e no formato dos dados. Aplicação de esquema e evolução do esquema: a maioria das estruturas de processamento distribuído não oferece suporte a operações de modificação de dados atômicos em data lakes. Por outro lado, o Delta Lake oferece suporte a operações de mesclagem, atualização e exclusão para casos de uso complexos, como captura de dados alterados, operações de dimensão de alteração lenta e upserts de streaming. Suporte para exclusões, atualizações e mesclagens: uma tabela Delta Lake tem a capacidade de funcionar em modo de lote e como fonte e coletor de streaming. O Delta Lake funciona em uma ampla variedade de latências, incluindo ingestão de dados de streaming e preenchimento de histórico em lote para fornecer consultas interativas em tempo real. Os trabalhos de streaming gravam pequenos objetos na tabela em baixa latência, combinando-os posteriormente transacionalmente em objetos maiores para melhor desempenho. Unificação de streaming e lote: Confiar no armazenamento de objetos significa que os objetos em uma tabela Delta e seu log são imutáveis e podem ser armazenados em cache localmente com segurança - onde quer que esteja na multicloud localmente. Cache: A arquitetura Lakehouse, Delta Lake em particular, traz novas funcionalidades importantes para data lakes construídos no armazenamento de objetos. O Delta Lake funciona com uma de aplicativos e mecanismos de computação, como Spark, Starburst, Trino, Flink e Hive, e também inclui APIs para Scala, Java, Rust, Ruby e Python. Construído para a nuvem, o MinIO nativo do Kubernetes permite aplicativos de data lake de alto desempenho, resilientes e seguros em qualquer lugar - na borda, no data center e na nuvem pública/privada. lista grande e crescente Arquivos do Lago Delta Uma tabela Delta é uma coleção de arquivos que são armazenados juntos em um diretório (para um sistema de arquivos) ou bucket (para MinIO e outro armazenamento de objeto). Para ler e gravar no armazenamento de objetos, o Delta Lake usa o esquema do caminho para identificar dinamicamente o sistema de armazenamento e usar a implementação LogStore correspondente para fornecer garantias ACID. Para MinIO, você usará S3A, consulte . É fundamental que o sistema de armazenamento subjacente usado para Delta Lake seja capaz de leituras/gravações atômicas simultâneas, assim como o MinIO. Configuração de armazenamento — documentação do Delta Lake Criar tabelas Delta é, na verdade, gravar arquivos em um diretório ou bloco. As tabelas delta são criadas (abertas) escrevendo (lendo) um Spark DataFrame e especificando o formato e o caminho . No Scala, por exemplo: delta // Create a Delta table on MinIO: spark.range(5).write.format("delta").save("s3a:// / ") // Read a Delta table on S3: spark.read.format("delta").load("s3a:// / ").show() O Delta Lake depende de um depósito por tabela, e os depósitos geralmente são modelados de acordo com os caminhos do sistema de arquivos. Uma tabela Delta Lake é um depósito que contém dados, metadados e um log de transações. A tabela é armazenada no formato Parquet. As tabelas podem ser particionadas em vários arquivos. O MinIO oferece suporte ao S3 LIST para listar objetos com eficiência usando caminhos no estilo do sistema de arquivos. MinIO também oferece suporte a solicitações de intervalo de bytes para ler com mais eficiência um subconjunto de um grande arquivo Parquet. O MinIO é um excelente lar para as mesas Delta Lake devido ao desempenho líder do setor. A combinação de escalabilidade e alto desempenho do MinIO coloca todas as cargas de trabalho, por mais exigentes que sejam, ao seu alcance. O MinIO é capaz de um desempenho tremendo - um alcançou 325 GiB/s (349 GB/s) em GETs e 165 GiB/s (177 GB/s) em PUTs com apenas 32 nós de SSDs NVMe prontos para uso. O MinIO oferece mais do que o desempenho necessário para alimentar as cargas de trabalho mais exigentes no Delta Lake. benchmark recente É provável que os buckets do Delta Lake contenham muitos arquivos Parquet e JSON, o que se alinha muito bem com todas as que incorporamos ao MinIO para uso como um data lake. Objetos pequenos são salvos em linha com metadados, reduzindo o IOPS necessário para ler e gravar arquivos pequenos, como transações do Delta Lake. otimizações de arquivos pequenos A maioria das empresas exige funcionalidade multinuvem para o Delta Lake. O MinIO inclui para sincronizar dados entre locais - no local, na nuvem pública/privada e na borda. A replicação ativo-ativo permite que as empresas arquitetem resiliência multigeográfica e failover hot-hot rápido. Cada balde, ou tabela Delta Lake, pode ser configurado para replicação separadamente para maior segurança e disponibilidade. replicação ativo-ativo Transações ACID com Delta Lake Adicionar a data lakes é um grande negócio porque agora as organizações têm maior controle e, portanto, maior confiança na massa de dados armazenados no data lake. Anteriormente, as empresas que dependiam do Spark para trabalhar com data lakes não tinham APIs atômicas e transações ACID, mas agora o Delta Lake torna isso possível. Os dados podem ser atualizados após serem capturados e gravados e, com suporte para ACID, os dados não serão perdidos se o aplicativo falhar durante a operação. O Delta Lake faz isso agindo como um intermediário entre o Spark e o MinIO para ler e gravar dados. transações ACID (Atomicidade, Consistência, Isolamento e Durabilidade) Central para Delta Lake é o , um registro ordenado de transações realizadas por usuários e aplicativos. Cada operação (como UPDATE ou INSERT) executada em uma tabela Delta Lake por um usuário é um commit atômico composto de várias ações ou trabalhos. Quando cada ação for concluída com sucesso, a confirmação será registrada como uma entrada no DeltaLog. Se algum trabalho falhar, a confirmação não será registrada no DeltaLog. Sem atomicidade, os dados podem ser corrompidos em caso de falha de hardware ou software que resulte na gravação parcial dos dados. DeltaLog Delta Lake divide as operações em uma ou mais das seguintes ações: Adicionar arquivo - adiciona um arquivo Remover arquivo - remove um arquivo Atualizar metadados - registra alterações no nome, esquema ou particionamento da tabela Definir transação - registra que um trabalho de streaming tem dados confirmados Commit info - informações sobre o commit, incluindo a operação, usuário e hora Alterar protocolo - atualiza o DeltaLog para o protocolo de software mais recente Não é tão complicado quanto parece. Por exemplo, se um usuário adicionar uma nova coluna a uma tabela e adicionar dados a ela, o Delta Lake divide isso em suas ações de componente - atualizar metadados para adicionar a coluna e adicionar arquivo para cada novo arquivo adicionado - e adicioná-los ao DeltaLog quando eles forem concluídos. O Delta Lake depende do controle de simultaneidade otimista para permitir que vários leitores e gravadores de uma determinada tabela trabalhem na tabela ao mesmo tempo. O controle de simultaneidade otimista assume que as alterações em uma tabela feitas por diferentes usuários podem ser concluídas sem conflito. À medida que o volume de dados aumenta, aumenta também a probabilidade de os usuários trabalharem em tabelas diferentes. O Delta Lake serializa os commits e segue uma regra de exclusão mútua caso dois ou mais commits ocorram ao mesmo tempo. Ao fazer isso, o Delta Lake atinge o isolamento necessário para o ACID e a tabela terá a mesma aparência após várias gravações simultâneas, como seria se essas gravações tivessem ocorrido em série e separadamente umas das outras. Quando um usuário executa uma nova consulta em uma tabela aberta que foi modificada desde a última vez que foi lida, o Spark consulta o DeltaLog para determinar se novas transações foram postadas na tabela e atualiza a tabela do usuário com essas novas alterações. Isso garante que a versão de uma tabela do usuário seja sincronizada com a tabela mestre em Delta Lake para a operação mais recente e que os usuários não possam fazer atualizações conflitantes em uma tabela. DeltaLog, controle de simultaneidade otimista e aplicação de esquema (combinado com a capacidade de evoluir o esquema) garantem atomicidade e consistência. Explorando o DeltaLog Quando um usuário cria uma tabela Delta Lake, o log de transações dessa tabela é criado automaticamente no subdiretório . À medida que o usuário modifica a tabela, cada confirmação é gravada como um arquivo JSON no subdiretório em ordem crescente, ou seja, , , e assim por diante. _delta_log _delta_log 000000.json 000001.json 000002.json Digamos que adicionamos novos registros à nossa tabela a partir dos arquivos de dados e . Essa transação é adicionada ao DeltaLog e salva como o arquivo . Posteriormente, removemos esses arquivos e adicionamos um novo arquivo . Essas ações são registradas como um novo arquivo, . 1.parquet 2.parquet 000000.json 3.parquet 000001.json Depois que e foram adicionados, eles foram removidos. O log de transações contém ambas as operações, mesmo que elas neguem uma à outra. O Delta Lake retém todas as confirmações atômicas para habilitar o histórico completo de auditoria e os recursos de viagem no tempo que mostram aos usuários como uma tabela parecia em um ponto específico no tempo. Além disso, os arquivos não são removidos rapidamente do armazenamento até que um trabalho seja executado. do MinIO fornece outra camada de garantia contra exclusão acidental. 1.parquet 2.parquet VACUUM O controle de versão Durabilidade com Delta Lake e MinIO O Delta Lake alcança durabilidade armazenando tabelas e logs de transações em mídia persistente. Os arquivos nunca são substituídos e devem ser removidos ativamente. Todas as alterações de dados gravadas no armazenamento estão disponíveis para os usuários automaticamente à medida que ocorrem. Arquivos parciais e corrompidos se tornam coisa do passado. Delta Lake não mantém tabelas e logs na RAM por muito tempo e os grava diretamente no MinIO. Contanto que os dados de confirmação tenham sido registrados no DeltaLog e os arquivos JSON tenham sido gravados no bucket, os dados são duráveis no caso de falha do sistema ou do trabalho. MinIO garante durabilidade depois que uma tabela e seus componentes são escritos por meio de vários mecanismos: divide os arquivos de dados em blocos de dados e paridade e os codifica para que os dados primários sejam recuperáveis, mesmo que parte dos dados codificados não esteja disponível. Os sistemas de armazenamento distribuído horizontalmente escalonáveis contam com codificação de eliminação para fornecer proteção de dados, salvando dados codificados em várias unidades e nós. Se uma unidade ou nó falhar ou os dados forem corrompidos, os dados originais podem ser reconstruídos a partir dos blocos salvos em outras unidades e nós. O Erasure Coding captura e cura objetos corrompidos em tempo real para remover essa ameaça silenciosa à durabilidade dos dados Bit Rot Protection protege os dados salvos no MinIO contra exclusão ou modificação usando uma combinação de bloqueio de objeto, retenção e outros mecanismos de governança. Os objetos gravados no MinIO nunca são substituídos. A imutabilidade de balde e objeto protege ainda mais os objetos. MinIO mantém um registro de cada versão de cada objeto, mesmo se ele for excluído, permitindo que você volte no tempo (muito parecido com a viagem no tempo de Delta Lake). O controle de versão é um componente-chave do que permite aos administradores mover baldes entre camadas, por exemplo, usar NVMe para cargas de trabalho intensivas em desempenho e definir uma data de expiração nas versões para que sejam removidas do sistema para melhorar a eficiência do armazenamento. O controle de versão de balde e objeto Data Lifecycle Management O MinIO protege as tabelas do Delta Lake usando criptografia e regula o acesso a elas usando uma combinação de IAM e controles de acesso baseados em políticas. O MinIO dados em trânsito com TLS e dados em unidades com criptografia granular em nível de objeto usando algoritmos de criptografia modernos e padrão do setor, como AES-256-GCM, ChaCha20-Poly1305 e AES-CBC. O MinIO integra-se com externos, como ActiveDirectory/LDAP, Okta e Keycloak para IAM. Os usuários e grupos estão sujeitos ao PBAC compatível com IAM da AWS enquanto tentam acessar as tabelas do Delta Lake. criptografa provedores de identidade Tutorial Delta Lake e MinIO Esta seção explica como iniciar rapidamente a leitura e gravação de tabelas Delta no MinIO usando o modo de cluster único. Pré-requisitos o Apache Spark. Baixe e instale o MinIO. Registre o endereço IP, a porta TCP, a chave de acesso e a chave secreta. Baixe e instale o MinIO Client. Baixe e instale Os seguintes arquivos jar são necessários. Você pode copiar os jars em qualquer local necessário na máquina Spark, por exemplo . /home/spark Hadoop - - Delta Lake precisa da classe do pacote , que implementa a API do Hadoop para S3. Certifique-se de que a versão deste pacote corresponda à versão do Hadoop com a qual o Spark foi criado. hadoop-aws-2.6.5.jar org.apache.hadoop.fs.s3a.S3AFileSystem hadoop-aws FileSystem AWS - aws-java-sdk-1.7.4.jar Configurar Apache Spark com Delta Lake Inicie o shell Spark (Scala ou Python) com Delta Lake e execute trechos de código interativamente. Em Escala: bin/spark-shell --packages io.delta:delta-core_2.12:1.2.1 --conf "spark.sql.extensions=io.delta.sql.DeltaSparkSessionExtension" --conf "spark.sql.catalog.spark_catalog=org.apache.spark.sql.delta.catalog.DeltaCatalog" Configurar Delta Lake e AWS S3 no Apache Spark Execute o seguinte comando para iniciar um shell Spark com Delta Lake e suporte S3 para MinIO: bin/spark-shell \ --packages io.delta:delta-core_2.12:1.2.1,org.apache.hadoop:hadoop-aws:3.3.1 \ --conf spark.hadoop.fs.s3a.access.key= \ --conf spark.hadoop.fs.s3a.secret.key= --conf "spark.hadoop.fs.s3a.endpoint= \ --conf "spark.databricks.delta.retentionDurationCheck.enabled=false" \ --conf "spark.sql.extensions=io.delta.sql.DeltaSparkSessionExtension" \ --conf "spark.sql.catalog.spark_catalog=org.apache.spark.sql.delta.catalog.DeltaCatalog" Criar um balde no MinIO Use o MinIO Client para criar um bucket para Delta Lake: mc alias set minio http:// mc mb minio\delta-lake Crie uma tabela de teste do Delta Lake no MinIO Experimente e crie uma tabela Delta Lake simples usando Scala: // Create a Delta table on MinIO: spark.range(500).write.format("delta").save("s3a://delta-lake/demo1") Você verá algo indicando que o Spark escreveu a tabela com sucesso. Abra um navegador para fazer login no MinIO em com sua chave de acesso e chave secreta. Você verá a tabela Delta Lake no balde: http:// MinIO e Delta Lake para transações ACID de alto desempenho em Data Lakes A combinação de MinIO e Delta Lake permite que as empresas tenham um data lake multinuvem que serve como uma única fonte consolidada de verdade. A capacidade de consultar e atualizar as tabelas do Delta Lake oferece às empresas informações valiosas sobre seus negócios e clientes. Vários grupos acessam as tabelas do Delta Lake para suas próprias análises ou iniciativas de aprendizado de máquina, sabendo que seu trabalho é seguro e os dados oportunos. Para ir mais fundo, e veja por si mesmo ou crie uma instância de mercado em qualquer nuvem pública. você tem perguntas? Pergunte no ou via hello@min.io. baixe o MinIO Slack Publicado também . aqui