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. O Delta Lake 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 artigo original do Delta Lake ( Delta Lake: armazenamento de tabelas ACID de alto desempenho sobre armazenamentos de objetos em nuvem ) descreve como ele foi criado para armazenamento de objetos em nuvem. Quando a Vertica testou o uso do Delta Lake para tabelas externas, eles confiaram no MinIO. Os clientes do HPE Ezmeral Runtime Enterprise executam o Delta Lake no MinIO . 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.

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 Delta Lake: armazenamento de tabelas ACID de alto desempenho sobre armazenamentos de objetos na nuvem , “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 oferece o seguinte:

• Garantias do ACID: 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.
• Tratamento escalonável de dados e metadados: 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.
• Histórico de auditoria e viagem no tempo: 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.
• Aplicação de esquema e evolução do esquema: 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.
• Suporte para exclusões, atualizações e mesclagens: 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.
• Unificação de streaming e lote: 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.
• Cache: 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.

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 lista grande e crescente 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.

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 Configuração de armazenamento — documentação do Delta Lake . É 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.

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 delta . No Scala, por exemplo:

 // Create a Delta table on MinIO: spark.range(5).write.format("delta").save("s3a://<your-minio-bucket>/<path-to-delta-table>") // Read a Delta table on S3: spark.read.format("delta").load("s3a://<your-mnio-bucket>/<path-to-delta-table>").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 benchmark recente 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.

É provável que os buckets do Delta Lake contenham muitos arquivos Parquet e JSON, o que se alinha muito bem com todas as otimizações de arquivos pequenos 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.

A maioria das empresas exige funcionalidade multinuvem para o Delta Lake. O MinIO inclui replicação ativo-ativo 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.

Transações ACID com Delta Lake

Adicionar transações ACID (Atomicidade, Consistência, Isolamento e Durabilidade) 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.

Central para Delta Lake é o DeltaLog , 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.

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 _delta_log . À medida que o usuário modifica a tabela, cada confirmação é gravada como um arquivo JSON no subdiretório _delta_log em ordem crescente, ou seja, 000000.json , 000001.json , 000002.json e assim por diante.

Digamos que adicionamos novos registros à nossa tabela a partir dos arquivos de dados 1.parquet e 2.parquet . Essa transação é adicionada ao DeltaLog e salva como o arquivo 000000.json . Posteriormente, removemos esses arquivos e adicionamos um novo arquivo 3.parquet . Essas ações são registradas como um novo arquivo, 000001.json .

Depois que 1.parquet e 2.parquet 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 VACUUM seja executado. O controle de versão do MinIO fornece outra camada de garantia contra exclusão acidental.

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:

• O Erasure Coding 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.
• Bit Rot Protection captura e cura objetos corrompidos em tempo real para remover essa ameaça silenciosa à durabilidade dos dados
• A imutabilidade de balde e objeto 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.
• O controle de versão 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 Data Lifecycle Management 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 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 criptografa 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 provedores de identidade 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.

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

1. Baixe e instale o Apache Spark.
2. Baixe e instale o MinIO. Registre o endereço IP, a porta TCP, a chave de acesso e a chave secreta.
3. Baixe e instale o MinIO Client.
4. 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 .
5. Hadoop - hadoop-aws-2.6.5.jar - Delta Lake precisa da classe org.apache.hadoop.fs.s3a.S3AFileSystem do pacote hadoop-aws , que implementa a API FileSystem 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.
6. 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=<your-MinIO-access-key> \ --conf spark.hadoop.fs.s3a.secret.key=<your-MinIO-secret-key> --conf "spark.hadoop.fs.s3a.endpoint=<your-MinIO-IP:port> \ --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://<your-MinIO-IP:port> <your-MinIO-access-key> <your-MinIO-secret-key> 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 http://<your-MinIO-IP:9001> com sua chave de acesso e chave secreta. Você verá a tabela Delta Lake no balde:

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, baixe o MinIO e veja por si mesmo ou crie uma instância de mercado em qualquer nuvem pública. você tem perguntas? Pergunte no Slack ou via [email protected].