Desmistificando o Databricks: Capítulo 1

Compreendendo o Lakehouse e Navegando na Arquitetura de Dados do Databricks

Published in

Data Hackers

14 min readAug 13, 2023

👋 Se você é um novo leitor, meu nome é Italo Barros. Gosto de escrever sobre Dados, Inteligência Artificial e Programação. Você pode se inscrever na minha newsletter aqui.

Este post faz parte de uma série que vai te ajudar na jornada de se tornar um Databricks Champion! Neste primeiro capítulo da série, vamos desmistificar o poder do Lakehouse, explorando sua abordagem unificada de dados que combina o melhor dos Data Lakes e Data Warehouses. Também revisaremos a Arquitetura do Data Lakehouse da Databricks e seu Framework de Analytics.

Introdução

A evolução no mundo do armazenamento de dados percorreu um longo caminho em auxiliar as empresas a obterem insights valiosos para tomadas de decisão e inteligência de negócios (BI). Uma década atrás, as plataformas de análise de dados da primeira geração centralizavam dados de bancos de dados operacionais em “Data Warehouses”, mas enfrentavam desafios com custos crescentes, tratamento de dados não estruturados e suporte à Ciência de Dados, Aprendizado de Máquina e Streaming.

Para enfrentar esses problemas, as plataformas de segunda geração adotaram os chamados “Data Lakes”, caracterizados como sistemas de armazenamento de baixo custo e baseados em uma “file API” que mantém os dados em formatos abertos como Apache Parquet e ORC. Essa abordagem também teve início com o crescente movimento do Apache Hadoop, pois permitia a agilidade de armazenar qualquer tipo de dado a baixo custo. Com o tempo, os data lakes baseado em nuvem foram se aperfeiçoando, melhorarando ainda mais a durabilidade e a eficiência do processamento e redução de custos, sendo sua arquitetura composta pela união em duas camadas de Data Lakes e Data Warehouses.

No entanto, essa abordagem de duas camadas introduziu complexidades e atrasos no processamento de dados. À medida que os casos de uso empresariais se expandiam para incluir análises avançadas como aprendizado de máquina, surgiu a necessidade de soluções de dados mais sofisticadas. Esta arquitetura de dados comumente enfrenta quatro problemas:

Confiabilidade: Manter consistência entre o Data Lake e o Data Warehouse é desafiador e custoso, exigindo engenharia contínua para processos de ETL. Isso traz riscos de falhas e redução na qualidade dos dados devido a diferenças entre os sistemas.
Dados Obsoletos: Os dados do Warehouse tendem a ficar defasados em relação ao Data Lake, levando horas ou dias para serem carregados, o que causa atrasos na consulta de dados operacionais recentes.
Suporte Limitado para Análises Avançadas: Os Warehouses têm dificuldade em lidar com consultas preditivas complexas usando os principais sistemas de Aprendizado de Máquina, exigindo a exportação de dados para arquivos, o que adiciona complexidade e obsolescência. Alternativamente, o uso de formatos abertos no Data Lake sacrifica recursos de gerenciamento dos Warehouses.
Custo Total: ETL contínuo e duplicação de dados resultam em despesas mais altas. Os formatos proprietários dos Data Warehouses comerciais aumentam os custos de migração e bloqueiam os dados, limitando a flexibilidade para trocar de sistema.

Para resolver esse problema, foi criado um novo sistema chamado Lakehouse, responsável por transformar Data Lakes em sistemas de alta performance que podem oferecer tanto o desempenho e os recursos de gerenciamento dos Data Warehouses quanto uma Leitura/Escrita direta rápida, permitindo assim análises de dados mais avançadas.

O “Lakehouse”

Um “Lakehouse” é um sistema de gerenciamento de dados que combina as vantagens dos Data Lakes e dos Data Warehouses. Ele é baseado em armazenamento facilmente acessível e de baixo custo, oferecendo recursos como transações “ACID ( atomicity, consistency, isolation, and durability)”, versionamento de dados, indexação e otimização de consultas.

Os Lakehouses funcionam bem em ambientes em nuvem com armazenamento e computação separados, permitindo que várias aplicações de computação acessem os mesmos dados. No entanto, eles podem sacrificar alguns aspectos da independência de dados em comparação com os sistemas tradicionais de gerenciamento de bancos de dados relacionais. Os Lakehouses também podem ser implementados em sistemas de armazenamento locais. O principal objetivo do Lakehouse é abordar os seguintes problemas-chave:

Gerenciamento de Dados Confiável: Um Lakehouse deve armazenar dados brutos e suportar processos de ETL/ELT para curadoria de dados. Sistemas recentes como o Delta Lake e o Apache Iceberg oferecem visualizações transacionais e recursos de gerenciamento, reduzindo etapas de ETL. Analistas podem consultar tabelas de dados brutos de maneira semelhante às plataformas de análise de primeira geração.
Performance no SQL: Os Lakehouses precisam fornecer excelente desempenho de SQL em conjuntos de dados Parquet/ORC. Técnicas como manter dados auxiliares e otimizar a disposição dos dados alcançam desempenho competitivo. O Databricks Delta Engine demonstra desempenho superior em relação aos principais data warehouses em nuvem no TPC-DS.
Suporte para Aprendizado de Máquina e Ciência de Dados: Sistemas de Aprendizado de Máquina podem acessar eficientemente um Lakehouse devido a leituras diretas aos arquivos do Data Lake. O acesso à APIs declarativas que utilizam DataFrames também otimizam a leitura de dados em cargas de trabalho de ML, beneficiando-se das otimizações do Lakehouse.

Gestão de Dados

A primeira ideia chave para a implementação de um Lakehouse é armazenar os dados em um object store (repositório de objetos de baixo custo como o Amazon S3) usando um formato de arquivo padrão (por exemplo, Apache Parquet) com uma camada de metadados transacionais por cima. Essa camada de metadados possibilita recursos de gerenciamento, como transações ACID e versionamento, mantendo os dados no object store.

Embora as camadas de metadados aumentem o nível de abstração sobre o armazenamento de Data Lake, sistemas de armazenamento existentes como o S3 ou HDFS, fornecem apenas interfaces de object store ou um sistema de arquivos de baixo nível, faltando atomicidade para certas operações.

Para lidar com isso, as organizações desenvolveram camadas de gerenciamento de dados mais ricas sobre o armazenamento de Data Lake. Exemplos incluem o Apache Hive ACID, Delta Lake, Apache Iceberg e Apache Hudi. Esses sistemas oferecem escalabilidade aprimorada e recursos de gerenciamento, como transações, clonagem de dados sem cópia e “time travel” para versões anteriores de tabelas. Eles podem ter desempenho igual ou até melhor do que Data Lakes brutos de Parquet/ORC em termos de performance. Sistemas como o Delta Lake e o Apache Iceberg adicionaram com sucesso esses recursos aos Data Lakes.

No entanto, apesar de todas estas vantagens, para alcançar uma boa performance de SQL, são necessárias técnicas adicionais utilizadas em Data Warehouses, como armazenamento SSD, estatísticas, índices e otimizações na disposição dos dados.

SQL Performático

Para o SQL mais performático, a Databricks propôs otimizações de desempenho independentes do formato dados disponíveis nos Lakehouses, abrangendo também formatos de dados existentes e futuros. Essas otimizações são implementadas no “Databricks Delta Engine” e demonstram um desempenho competitivo com Data Warehouses baseados em nuvem, mas também deixando espaço para melhorias adicionais. As três principais otimizações são:

Cache: O uso de uma camada de metadados transacionais permite ao sistema Lakehouse armazenar em cache arquivos do object store em dispositivos de armazenamento mais rápidos, como SSDs e RAM. O cache pode estar em um formato “transcoded”, combinando otimizações usadas em Data Warehouses tradicionais. Por exemplo, o cache da Databricks descomprime parcialmente os dados Parquet para consultas mais eficientes.
Dados Auxiliares: Enquanto o formato de armazenamento da tabela base deve ser exposto para Leitura/Escrita direta, o Lakehouse pode manter outros dados em arquivos auxiliares para otimizar consultas. O Delta Lake e o Delta Engine mantêm estatísticas de mínimo-máximo de colunas nos arquivos Parquet, possibilitando otimizações de “data skipping” para dados clusterizados.
Disposição dos Dados: A disposição dos dados impacta significativamente o desempenho de acesso. Mesmo em um formato de armazenamento fixo como o Parquet, o sistema Lakehouse pode otimizar as decisões de layout. Técnicas como ordenação de registros, agrupamento de registros usando dimensões ou “space-filling curves” e escolha de estratégias de compressão diferentes para vários grupos de registros podem melhorar o desempenho.

Essas três otimizações funcionam bem juntas para cargas de trabalho analíticas típicas. A maioria das consultas se concentra em um subconjunto de dados“quentes” (dados que precisam de acesso imediato ou são frequentemente acessados), em que o Lakehouse pode armazenar em cache usando estruturas de dados otimizadas semelhantes às de data warehouses tradicionais.

Para dados “frios”(dados raramente acessadosos ), o desempenho depende em grande parte da quantidade de dados lidos por consulta. Nesse caso, a combinação de otimizações na disposição dos dados e estruturas de dados auxiliares permite ao sistema Lakehouse minimizar as operações de Escrita/Leitura, assemelhando-se ao comportamento de Data Warehouses proprietários, apesar de usar um formato de arquivo aberto.

Suporte ao Aprendizado de Máquina e Ciência de Dados

O desafio ao projetar camadas de acesso a dados para análises avançadas reside nas bibliotecas que geralmente usam código imperativo e exigem acesso a grandes volumes de dados. Para resolver isso, era necessário maximizar a flexibilidade para o código, ao mesmo tempo em que se beneficiava das oportunidades de otimização de um Lakehouse. Uma das abordagens tomadas para resolver esse problema foi fornecer uma versão declarativa das APIs baseadas em DataFrames, mapeando as computações em planos de consulta do Spark SQL. Isso permitiu que as bibliotecas se beneficiassem das otimizações do Delta Lake e do Databricks Delta Engine.

O planejador de queries do Spark otimiza a computação de um DataFrame ao empurrar seleções e projeções diretamente para cada leitura da fonte de dados. Ao aproveitar o cache, o data skipping e as otimizações de layout da fonte de dados do Delta Lake, as leituras do Delta Lake via DataFrame podem ser aceleradas, beneficiando cargas de trabalho de aprendizado de máquina (ML) e ciência de dados. Dessa forma, os Lakehouses podem acelerar as cargas de trabalho de análises avançadas e oferecer melhor gerenciamento de dados por meio das APIs declarativas. Bibliotecas de ML como TensorFlow e Spark MLlib podem assim ler formatos de arquivo como o Parquet, facilitando a integração com um Lakehouse.

O Data Lakehouse desta forma fornece acesso direto e aberto a dados armazenados em formatos padrão do Data Lake, assim como baixa latência de consulta com alta confiabilidade tanto para BI quanto para análises avançadas.

Data Warehouse vs Data Lakehouse vs Data Lake

As soluções de dados como Data Warehouses, Data Lakes, e Data Lakehouses desempenham e desempenharam papéis cruciais ao capacitar empresas com insights valiosos, facilitando a tomada de decisões orientada por dados. Cada um desses sistemas possui pontos fortes e capacidades únicas, tornando-os adequados para diferentes casos de uso e cenários de dados. Segue abaixo um breve comparativo entre eles e como o Data Lakehouse se destacam entre os demais:

Databricks Data Analytics Framework

O framework da Databricks é um ecossistema integrado que simplifica a jornada completa do dado, participando da captura, processamento, e análise de dados (avançada ou não). Ele oferece um espaço de trabalho unificado que permite aos profissionais de dados colaborar de forma eficaz seja na parte de engenharia e operacionalização dos pipelines, quanto no desenvolvimento de modelos e/ou reports/dashboards.

O framework foi construído usando o conceito do Data Lakehouse, combinando transações ACID, a governança de dados de Data Warehouses corporativos e a flexibilidade/eficiência de custos dos Data Lakes para permitir a manipulação dos dados para Inteligência de Negócios (BI) e Aprendizado de Máquina (ML). Vamos explorar como cada profissional de dados pode se beneficiar desse framework:

Data Engineers: A framework permite simplificar tarefas de ETL e preparação de dados por meio de suporte a IDEs, APIs RESTs e integração com o MLflow. Com o Koalas e a Dataframe API, os engenheiros de dados podem manipular e limpar eficientemente grandes conjuntos de dados. Além disso, as ferramentas como o Databricks Workflows and Jobs, permitem agendar e automatizar pipelines de dados, melhorando eficiência e escalabilidade sem a necessidade de uma tool externa como Airflow ou Prefect.
ML Engineers: O framework fornece um ambiente de execução de ML, permitindo que engenheiros de machine learning treinem e implantem modelos de aprendizado de máquina em escala. Aproveitando as capacidades do Databricks Auto ML, eles podem automatizar a seleção e ajuste de modelos, reduzindo o tempo até a produção. As Delta Live Tables também possibilitam atualizações de modelos em tempo real, garantindo previsões atualizadas.
Data Scientists: O framework oferece um conjunto amplo de ferramentas para exploração e análise de dados. Eles podem construir modelos complexos usando o MLlib e LLMs proprietários ou open-source para tarefas de processamento de linguagem natural. A integração com o MLflow permite um rastreamento e colaboração de modelos sem interrupções.
Business Analysts: O framework capacita os analistas de negócios com editores de SQL, integração com ferramentas de BI (PowerBI, Tableau, etc.), e a possibilidade de criar visualizações com Databricks SQL Dashboards. A plataforma promove a tomada de decisões orientada por dados, fornecendo insights em tempo real sobre métricas de negócios.

Ao combinar ferramentas de ETL, Capacidades de Ingestão de Dados, Análises de Dados Avançadas, Ferramentas de BI e recursos de Governança de Dados, a Databricks oferece uma plataforma holística que atende às diversas necessidades do atual stack de dados moderno. Abaixo você encontra um breve resumo dos componentes disponíveis neste framework:

Desmistificando a Arquitetura do Databricks

A arquitetura do Data Lakehouse do Databricks tem como objetivo abordar as limitações e desafios enfrentados pelos Data Warehouses tradicionais e Data Lakes, proporcionando uma abordagem mais escalável, performática e econômica para o processamento e análise de dados. Sua arquitetura de divide em dois tipos: o Classic Data Plane e o Severless Data Plane.

Para o Classic Data Plane (a arquitetura inicial da plataforma, que envolve Clusters Apache Spark e SQL Data Warehouses), a Databricks opera a partir de um Control Plane (Layer de Controle) e um Data Plane (Layer de Dados). Embora as arquiteturas possam variar dependendo de configurações e cloud utilizada, o diagrama a seguir representa a estrutura e o fluxo mais comuns entre estes dois planos:

Classic Control Plane

O Layer de Controle inclui os serviços de back-end que a Databricks gerencia em sua própria conta na nuvem, a maioria dos dados não reside aqui, mas os notebooks, job schedulers, cluster management e configurações do workspace são armazenados aqui e criptografados no resto.
O cluster management, scheduling e notebooks estão disponíveis neste plano e interagem com o Layer de Dados para efetuar o processamento. No entanto, é importante observar que, mesmo que não processe os dados, ele pode ler os metadados das tabelas como resultados, nomes de colunas, etc. Resultados parciais dos notebooks interativos são armazenados aqui para apresentação na interface do usuário, no entanto, isso pode ser alterado mediante solicitação do cliente, de modo que todos os resultados sejam armazenados no armazenamento do cliente.

Classic Data Plane

O Layer de Dados é onde os dados são processados, ele reside na Cloud Account do cliente e utiliza o Apache Spark como motor de processamento, permitindo o processamento de dados distribuído de alto desempenho.
O Driver e Workers do Spark estão disponíveis aqui. Este layer permite aos usuários ingerir dados de várias fontes, incluindo armazenamento em nuvem (por exemplo, AWS S3, Azure Data Lake Storage), bancos de dados, plataformas de streaming e outros sistemas externos.
Este layer utiliza o Delta Lake como camada de armazenamento, que fornece recursos avançados como transações ACID, aplicação de esquema, viagem no tempo e otimizações para processamento de dados.
Este layer permite a autenticação usando Single Sign-On (SSO), sendo capaz de integrar-se a Provedores de Identidade como SAML 2.0 e Azure AD.
Novos clusters são criados dentro da rede virtual de cada espaço de trabalho na conta do cliente.
Possui isolamento natural, pois é executado na própria Cloud Account de cada cliente.

Para o Serverless Data Plane (Databricks SQL Serverless), os recursos de computação da Databricks são executados em uma camada de computação dentro da sua conta Databricks. As principais diferenças estão na forma como os dados são processados. Uma comparação completa entre o Classic Data Plane e o Severless Data Plane pode ser encontrada aqui.

Serverless Control Plane

A arquitetura é semelhante ao Classic Control Plane, no entanto, a comunicação entre o Layer de Controle e de Dados é feita através de uma conexão privada.
Para o “Model Serving”, a comunicação utiliza criptografia mTLS com a conexão iniciada a partir do layer de controle, possuindo assim acesso limitado aos endereços IP deste layer.

Serverless Data Plane

Em vez de residir na Cloud Account do Cliente, ele residirá na Conta de Cliente dentro do Databricks. Para proteger os dados do cliente dentro do layer de dados, a computação serverless é executada dentro de um limite de rede para o respectivo Databricks Workspace.
Os Dados Físicos ainda residem na Cloud Account do Cliente.
A Databricks cria um Layer de Dados na mesma região do Classic Data Layer baseado na região do Databricks Workspace do cliente.
Os Worker Nodes do Spark são privados, o que significa que eles não têm endereços IP públicos.

Arquitetura “Medallion” (Multi-Hop)

A Arquitetura Medallion é um framework moderno de processamento e análise de dados projetado para enfrentar as limitações dos sistemas tradicionais de Data Warehouse, especialmente em relação ao uso de tabelas de staging/raw. Ele aproveita tecnologias avançadas para fornecer uma solução mais eficiente e escalável para gerenciamento, integração e análise de dados. A Databricks recomenda a utilização desta arquitetura multi-layer por permitir a criação de uma única fonte de dados, além de facilitar tarefas de BI e ML.

Os principais componentes dessa arquitetura são:

Processamento de Dados em Tempo Real: Ao contrário dos sistemas tradicionais de Data Warehouse, que frequentemente dependem do processamento em batch, a Arquitetura Medallion suporta o processamento de dados em tempo real (streaming).
Pipelines de Dados Simplificados: O Medallion elimina a necessidade de processos ETL (Extração, Transformação, Carregamento) complexos, reduzindo a sobrecarga e a complexidade na preparação de dados.
Escalabilidade e Desempenho: Com a engine de processamento de dados distribuídos do Spark, essa arquitetura oferece escalabilidade e desempenho aprimorados. Ela pode lidar com grandes volumes de dados e processar consultas analíticas complexas rapidamente, garantindo operações suaves mesmo em cenários de alta demanda.
Evolução de Esquema e Flexibilidade: A arquitetura abraça o schema evolution, permitindo mudanças nos esquemas das tabelas sem interromper os pipelines existentes. Essa flexibilidade acomoda as mudanças nas necessidades de negócios e promove agilidade no gerenciamento de dados.
Self-Service: A arquitetura capacita os usuários com ferramentas de análise e self-service. Isso reduz a dependência de equipes de TI e permite que os usuários de negócios explorem e visualizem dados de forma independente, promovendo uma cultura orientada por dados.

Conclusão

E assim chegamos ao final desta empolgante exploração do sistema Lakehouse e da inovadora Arquitetura de Dados do Databricks. Nesta jornada, mergulhamos fundo nas águas do Lakehouse, desvendando como essa abordagem inovadora funde com maestria o poder dos Data Lakes e a eficiência dos Data Warehouses, oferecendo uma solução holística para os desafios da análise de dados moderna.

À medida que fechamos este capítulo, estamos conscientes de que nossa desmistificação está longe de terminar. Fique ligado para o nosso próximo Capítulo, onde iremos desbravar o mundo do Delta Lake!