O que é a API Spark DataFrame?

O Apache Spark é um mecanismo de processamento distribuído projetado para processar dados estruturados, semiestruturados e não estruturados em escala. Para interagir com o mecanismo e definir operações de dados distribuídos, os desenvolvedores usam a API Spark.

No centro do desenvolvimento moderno do Spark está a API Spark DataFrame. Um DataFrame organiza e processa dados distribuídos em colunas nomeadas, de forma semelhante a uma tabela em um banco de dados relacional ou uma planilha. Ele oferece uma interface estruturada e declarativa para analisar conjuntos de dados enormes, otimizando automaticamente a execução física nos bastidores.

Arquitetura e execução da API Spark

Para entender como a API Spark executa seu código em uma rede distribuída, é importante conhecer os componentes básicos da arquitetura do ambiente de execução:

Driver: o coordenador central do aplicativo Spark. Ele lê seu código, traduz operações declarativas em planos de execução lógicos e programa tarefas nos nós de trabalho.
Gerenciador de cluster: o alocador de recursos (como o Kubernetes ou gerenciadores de recursos independentes) que provisiona recursos de CPU, memória e rede em todo o cluster.
Executores: as instâncias de worker em execução nos nós do cluster. Eles recebem instruções de tarefas do driver, executam operações de processamento de dados localmente na memória e retornam resultados ou os gravam no armazenamento.
DAGs, estágios e tarefas: o Spark não executa transformações de dados linha por linha. Em vez disso, o driver compila o código do DataFrame em um gráfico acíclico dirigido (DAG) de operadores físicos. O driver agrupa esses operadores em fases de execução amplas chamadas de estágios, que são divididos por limites de redistribuição de dados, e divide esses estágios em tarefas individuais distribuídas aos executores para execução paralela.

Qual é a diferença entre RDDs e DataFrames do Spark?

Ao projetar pipelines de dados distribuídos, os desenvolvedores escolhem entre duas interfaces de programação principais:

Spark RDD (conjunto de dados distribuídos resiliente): a API original de baixo nível do Spark. Representa uma coleção imutável e tolerante a falhas de objetos JVM distribuídos em um cluster. Como os RDDs contêm objetos Java arbitrários, o mecanismo de execução não pode inspecionar a estrutura interna deles. Isso força os desenvolvedores a escrever e ajustar manualmente a lógica de transformação de baixo nível, o que geralmente resulta em um overhead significativo de coleta de lixo e uma serialização lenta.
DataFrame do Spark: o padrão moderno para processamento de dados estruturados. Os DataFrames organizam os dados em linhas e colunas definidas por um esquema rígido. Como o mecanismo de execução conhece os tipos de dados e a estrutura do conjunto de dados, ele consegue otimizar automaticamente o código antes de executá-lo.

Por que escolher DataFrames em vez de RDDs?

Para quase todos os casos de uso de engenharia e ciência de dados, a API DataFrame é a escolha preferida. Os RDDs são reservados para cenários em que você precisa manipular dados brutos e não estruturados (como arquivos binários ou streams de mídia) usando objetos Java personalizados. Os DataFrames exigem menos código, são executados automaticamente com mais rapidez e usam o gerenciamento de memória binária fora do heap para evitar gargalos de coleta de lixo da JVM.

Como as equipes de dados usam a API Spark

A API Spark DataFrame simplifica as tarefas computacionais exigentes de processamento, limpeza e preparação de grandes volumes de dados.

Engenheiros de dados: os engenheiros usam a API DataFrame para criar pipelines de dados resilientes e tolerantes a falhas. Eles extraem dados brutos, aplicam esquemas, executam transformações estruturadas e gravam tabelas conformadas em data lakes ou data warehouses em nuvem. Com a sintaxe declarativa, eles conseguem processar terabytes de dados diariamente, minimizando a complexidade do código e o overhead de manutenção.
Cientistas de dados: os cientistas de dados usam a API DataFrame para analisar e preparar conjuntos de dados enormes que excedem os limites de memória de uma única máquina. Ao distribuir partições de dados entre nós de trabalho, eles podem executar análise detalhada de dados, limpar valores nulos e criar atributos em escala, acelerando o tempo de geração de insights.

Bibliotecas principais criadas na API DataFrame

A API Spark DataFrame serve como a base programática para as bibliotecas de processamento avançado do Spark:

Spark SQL: esse módulo permite executar consultas ANSI SQL diretamente em conjuntos de dados do Spark. É possível consultar DataFrames como visualizações temporárias, combinando perfeitamente o código declarativo em Python ou Scala com consultas SQL padrão.
Structured Streaming: esse mecanismo processa fluxos contínuos de dados em tempo real. Ele usa os mesmos comandos da API DataFrame que o processamento em lote estático, lidando automaticamente com microlotes, tolerância a falhas e gerenciamento de estado.
MLlib: a biblioteca de machine learning distribuída do Spark usa DataFrames para gerenciar e preparar conjuntos de dados de treinamento, fornecendo algoritmos integrados e escalonáveis para classificação, regressão, clustering e filtragem colaborativa.

Benefícios da API Spark DataFrame

Otimização declarativa

Os DataFrames usam um otimizador de consultas integrado chamado Catalyst Optimizer. Quando você escreve o código do DataFrame, o otimizador reescreve automaticamente o plano de execução física aplicando o pushdown de filtro, a poda de projeção e a reordenação de mesclagem para que seja executado o mais rápido possível sem ajuste manual.

Flexibilidade de linguagem

Não importa se sua equipe escreve código em Python (PySpark), Scala, Java ou R. A API DataFrame garante um desempenho idêntico. O plano de execução subjacente é compilado e otimizado na mesma camada de execução independente da JVM.

Gerenciamento de memória eficiente

Os DataFrames usam o mecanismo de execução Tungsten para armazenar dados em um formato binário fora do heap altamente compactado. Isso elimina o overhead de criação de objetos da JVM e evita que as pausas da coleta de lixo congelem as linhas de execução do executor.

Como usar a API Spark DataFrame no Google Cloud

Tradicionalmente, executar o Spark de código aberto requer configuração manual de clusters, gerenciamento de versões de software e peering de rede complexo. Para simplificar isso, o Google Cloud oferece o Serviço Gerenciado para Apache Spark, transformando a execução distribuída em uma plataforma de dados totalmente gerenciada e pronta para empresas.

As equipes de dados executam cargas de trabalho do DataFrame do Spark no Google Cloud usando os seguintes recursos:

Implantação de clusters sem servidor e gerenciados: no Google Cloud, você escolhe o modelo de execução que se adapta às suas necessidades operacionais. É possível executar o código do DataFrame no modo sem servidor para enviar jobs em lote diretamente, pagando apenas pelos segundos exatos de tempo de execução, conforme o escalonamento automático dos recursos, ou implantar clusters gerenciados persistentes e altamente personalizáveis para cargas de trabalho contínuas.
Conectividade otimizada do BigQuery: o conector Spark-BigQuery ignora as transições orientadas por linhas da JVM ao consumir dados do BigQuery diretamente no formato nativo do Apache Arrow. Os cientistas de dados também podem usar uma interface de notebook integrada para executar o código do DataFrame do PySpark e as consultas SQL no mesmo conjunto de dados governado sem trocar de ambiente.
Execução vetorizada nativa em C++: ao executar cargas de trabalho do Spark no Google Cloud, é possível ativar o Lightning Engine para seus lotes sem servidor ou clusters gerenciados. Esse mecanismo de execução nativa de consultas em C++ compila planos de consulta físicos diretamente em instruções nativas usando o Velox e o Gluten. Ao ignorar o modelo de iterador Volcano da JVM e os gargalos de coleta de lixo, ele acelera suas cargas de trabalho do DataFrame e Spark SQL em até 4,9 vezes sem alterações no código.