O Delta Lake é um formato de armazenamento de dados de código aberto que combina arquivos de dados do Apache Parquet com um registro de metadados robusto. O formato Delta Lake traz funções chave de gerenciamento de dados, como transações ACID e controle de versões de dados, para data lakes, tornando-o a base para muitos data lakehouses.
Desenvolvido pela primeira vez pela Databricks em 2016, o Delta Lake é um formato de tabela aberta, uma framework de código aberto para dados tabulares que cria uma camada de metadados sobre os formatos de arquivo existentes. O Delta Lake usa especificamente tabelas Parquet para armazenamento de dados. Outros formatos de tabelas abertas incluem o Apache Iceberg e o Apache Hudi.
A camada de metadados permite que o Delta Lake e outras tabelas abertas otimizem as consultas de pesquisa e sejam compatíveis com operações de dados avançadas com as quais muitos formatos de tabelas padrão não são. As organizações frequentemente usam o Delta Lake para tornar seus data lakes mais confiáveis e intuitivos.
A criação do Delta Lake foi uma etapa crítica no desenvolvimento da arquitetura de data lakehouse, que combina o armazenamento de um data lake com o desempenho de um data warehouse.
O Delta Lake e o data lake são frequentemente discutidos juntos, mas é importante saber que essas tecnologias são distintas uma da outra.
Um data lake é um ambiente de armazenamento de dados de baixo custo projetado para lidar com conjuntos de dados maciços de qualquer tipo e formato de dados. A maioria dos data lakes usa plataformas de cloud object storage, como o Amazon Simple Storage Service (S3), o Microsoft Azure Blob Storage ou o IBM Cloud Object Storage.
O Delta Lake é um formato de armazenamento de dados tabulares que uma organização pode usar em um data lake ou outro armazenamento de dados.
O Delta Lake não é um tipo de data lake, nem uma alternativa a um data lake. Em vez disso, pode-se pensar em um data lake como o "onde", e o Delta Lake como o "como":
O formato Delta Lake pode ajudar a tornar os data lakes mais gerenciáveis e eficientes.
Os data lakes têm muitos benefícios, mas normalmente não possuem controles de qualidade de dados integrados, e a consulta direta dos data lakes pode ser difícil. Muitas vezes, as organizações precisam pegar dados de um lake, limpá-los e carregá-los em data warehouses e data marts separados antes que possam ser usados.
Ao introduzir uma camada de metadados, o Delta Lake oferece às organizações uma maneira de impor esquemas, rastrear e reverter alterações e proporcionar compatibilidade com transações ACID.
Os usuários podem executar consultas em linguagem de consulta estruturada (SQL), cargas de trabalho de análise de dados e outras atividades diretamente em um data lake, simplificando a business intelligence (BI), inteligência de dados (DI), inteligência artificial (IA) e aprendizado de máquina (ML).
O Delta Lake tem dois componentes principais: os arquivos de dados, que contêm dados, e o log de transações, que abriga metadados sobre esses arquivos de dados.
O log de transações registra informações sobre os arquivos de dados (como nomes de colunas e valores mínimos e máximos) e alterações feitas nos arquivos (o que foi alterado, quando, como e por quem).
O log é o que diferencia o Delta Lake de um arquivo Parquet padrão. O log de transações atua essencialmente como uma camada de gerenciamento e um conjunto de instruções para todas as atividades no data lake, habilitando funcionalidades como transações ACID, viagem no tempo e evolução de esquema.
Os arquivos Parquet comuns são imutáveis, o que significa que não podem ser alterados após serem criados; eles só podem ser reescritos. O log de transações do Delta Lake torna os arquivos Parquet funcionalmente, se não literalmente, mutáveis, ao separar ações físicas (ações realizadas diretamente nos dados) de ações lógicas (ações realizadas nos metadados).
Por exemplo, um usuário não pode remover uma única coluna de uma tabela Parquet sem reescrever todo o arquivo. No Delta Lake, o usuário pode remover efetivamente essa coluna ao alterar os metadados da tabela para marcá-la como excluída. A coluna permanece no arquivo, mas todas as consultas, atualizações e gravações subsequentes veem os metadados e tratam a coluna como inexistente.
“ACID” significa “atomicidade, consistência, isolamento e durabilidade”—propriedades-chave de uma transação de dados confiável.
Data lakes padrão não são compatíveis com transações ACID. Sem garantias ACID, os data lakes são suscetíveis a transações com falha, gravações parciais e outros problemas que podem corromper os dados.
O log de transações do Delta Lake pode registrar informações de transações de acordo com os princípios do ACID, tornando os data lakes mais confiáveis para fluxos de dados de streaming, business intelligence, análise de dados e outros casos de uso.
Os administradores podem definir requisitos de esquema no log de transações, e esses requisitos se aplicam a todos os dados após a ingestão. Os dados que não atendem aos requisitos de esquema são rejeitados.
Os administradores também podem usar o log de transações para alterar o esquema de um arquivo existente, como adicionar novas colunas ou alterar os tipos de colunas. Esse processo é chamado de "evolução do esquema".
Embora não seja um índice tradicional, o log de transações pode ajudar as consultas a recuperar dados de forma mais rápida e eficiente.
Por exemplo, digamos que um usuário esteja pesquisando um determinado valor em uma coluna. Usando metadados no log de transações, a consulta do usuário pode ignorar qualquer arquivo em que o valor de destino não possa existir. Se o valor mínimo for maior ou o valor máximo for menor do que o valor de destino, a consulta poderá ignorar o arquivo.
O log de transações também armazena caminhos de arquivos. Em vez de verificar todo o data lake, as consultas podem usar esses caminhos de arquivos para ir diretamente aos arquivos relevantes.
O Delta Lake pode usar técnicas como a ordenação Z para armazenar dados semelhantes mais próximos no disco, o que facilita ignorar arquivos irrelevantes e encontrar os relevantes.
Os arquivos Parquet normais são imutáveis, mas os usuários podem manipular tabelas Delta por meio da camada de metadados. O Delta Lake é compatível com todos os tipos de operações de dados, incluindo a adição ou exclusão de colunas, a atualização de entradas e a mesclagem de arquivos.
Como o log de transações registra tudo o que acontece nas tabelas Delta, ele mantém efetivamente os históricos das versões para cada tabela. Os usuários podem consultar versões anteriores e até viagens no tempo, ou seja, reverter alterações para restaurar versões anteriores das tabelas.
O Delta Lake tem um ecossistema robusto de conectores. O formato pode ser usado com vários mecanismos de computação, como Apache Spark, Apache Hive, Apache Flink ou Trino. O Delta Lake também possui interfaces de programação de aplicativos (APIs) para Python, Java, Scala e outras linguagens, permitindo que os desenvolvedores gerenciem e consultem as tabelas Delta programaticamente.
Embora o Delta Lake não imponha controles de segurança nativamente, ele pode se integrar a ferramentas de segurança de dados e governança de dados. Essas ferramentas podem, então, usar metadados do log de transações para auditar atividades, rastrear alterações e impor políticas de controle de acesso baseado em função (RBAC).
O Delta Lake pode aceitar dados de streaming e em lote, e os dados podem ser enviados de tabelas Delta para serviços conectados como um streaming ou em lotes.
O Delta Lake 4.0, o próximo lançamento principal programado para o Delta Lake, planeja adicionar mais funcionalidades, tais como:
O Apache Iceberg é um formato de código aberto de alto desempenho para tabelas analíticas maciças. Assim como o Delta Lake, o Iceberg cria uma camada de metadados sobre os formatos de tabela existentes para compatibilidade com transações ACID e outras operações em um data lake.
O Iceberg pode armazenar dados em arquivos Parquet, ORC ou Avro, enquanto o Delta Lake usa exclusivamente o Parquet. O Iceberg também usa uma camada de metadados de três níveis em vez de um único log de transações, como o Delta Lake.
O Iceberg integra-se nativamente a muitos mecanismos de consulta diferentes e é uma escolha comum para análise de dados baseada em SQL em um data lake.
Assim como o Delta Lake e o Iceberg, o Hudi mantém uma camada de metadados sobre uma camada de dados. O Hudi pode usar os formatos de arquivo Parquet, HFile e ORC, e sua camada de metadados assume a forma de uma "linha do tempo", que registra tudo o que acontece na camada de dados.
O Hudi foi projetado para processamento de dados incremental, no qual pequenos lotes de dados são processados com frequência. Esse foco no processamento incremental torna o Hudi uma escolha comum para análise em tempo real e captura de dados de alteração (CDC).
O desenvolvimento do formato Delta Lake ajudou a pavimentar o caminho para a criação de data lakehouses.
Durante muito tempo, as organizações gerenciaram principalmente seus dados em data warehouses. Embora úteis para análise de dados e BI, os warehouses exigem esquemas rigorosos. Eles não funcionam bem com dados não estruturados ou semiestruturados, o que se tornou mais predominante e mais importante à medida que as organizações aumentam seus investimentos em IA e ML.
A ascensão dos data lakes no início da década de 2010 proporcionou às organizações uma maneira de agregar todos os tipos de dados de todos os tipos de fontes de dados em um único local.
No entanto, data lakes têm seus próprios problemas. Eles frequentemente carecem de controle de qualidade. Eles não são compatíveis com transações ACID, e não é fácil consultá-los diretamente.
Para tornar os dados utilizáveis, as organizações geralmente precisavam criar pipelines de dados de extrair, transformar e carregar (ETL) separados para migrar os dados de um lake para um warehouse.
O Delta Lake surgiu em 2016, adicionando transações ACID, imposição de esquemas e viagens no tempo aos data lakes, tornando-os mais confiáveis para consultas e análise de dados diretas.
Lançado em código aberto em 2019, o Delta Lake desempenhou um papel fundamental na formação da arquitetura dos data lakehouses, que combina a flexibilidade dos data lakes com o desempenho dos data warehouses.
Muitas organizações criam data lakehouses construindo uma camada de armazenamento Delta Lake sobre um data lake existente e integrando-a a um mecanismo de processamento de dados, como o Spark ou Hive.
Os data lakehouses ajudam com a compatibilidade com a integração de dados e a otimização da arquitetura de dados, ao eliminar a necessidade de manter data lakes e warehouses separados, o que pode levar à formação de silo de dados.
Por sua vez, essas arquiteturas simplificadas ajudam a garantir que os cientistas de dados, engenheiros de dados e outros usuários possam acessar os dados de que precisam quando precisam. Cargas de trabalho de IA e ML são casos de uso comuns para data lakehouses alimentados pelo Delta Lake.
Os data lakes, por si só, já são úteis para essas cargas de trabalho porque podem armazenar grandes quantidades de dados estruturados, não estruturados e semiestruturados.
Ao adicionar funcionalidades como transações ACID e aplicação de esquemas, o Delta Lake ajuda a garantir a qualidade e a confiabilidade de dados de treinamento de maneiras que os data lakes não conseguem.
Saiba como uma abordagem de data lakehouse aberta pode oferecer dados confiáveis e execução mais rápida para as análises de dados e projetos de IA.
IBM reconhecida como líder pelo 19.º ano consecutivo no Gartner Magic Quadrant™ 2024 para Ferramentas de Integração de Dados.
Explore o guia do líder de dados para criar uma organização baseada em dados e gerar vantagem comercial.
Descubra por que a inteligência e a integração de dados impulsionadas por IA são críticas para estimular a preparação de dados estruturados e não estruturados e acelerar os resultados da IA.
Simplifique o acesso aos dados e automatize a governança dos dados. Conheça o poder da integração de uma estratégia de data lakehouse à sua arquitetura de dados, incluindo a otimização dos custos das suas cargas de trabalho e a escala de IA, com todos os seus dados, em qualquer lugar.
Saiba como a IBM Research é regularmente integrada em novas funcionalidades do IBM Cloud Pak® for Data.
Tenha acesso a insights exclusivos sobre o cenário em evolução das soluções avançadas de BI, destacando as principais descobertas, suposições e recomendações para líderes de dados e de análises.
Coloque seus dados para trabalhar, onde quer que estejam, com o data lakehouse aberto e híbrido para IA e análise de dados.
Resolva os desafios de dados atuais com uma arquitetura lakehouse. Conecte-se a dados em minutos, obtenha insights confiáveis com rapidez e reduza os custos de seu data warehouse.
Libere o valor dos dados empresariais com a IBM® Consulting, construindo uma organização orientada por insights, que proporciona vantagem comercial.