image

Acesse bootcamps ilimitados e +650 cursos pra sempre

60
%OFF
Article image
Regilene Silva
Regilene Silva16/09/2024 17:17
Compartilhe

Overview APIs Estruturadas do Spark

    No Spark, podemos escrever consultas usando SQL, DataFrames ou Datasets. Cada um desses formatos tem suas próprias vantagens e sintaxes, mas eles têm um objetivo comum: manipular e consultar dados de maneira eficiente. Além disso, as APIs são uma abstração fundamental para escrever a maior parte dos fluxos de dados.

    Isso significa que com Spark podemos registrar qualquer DataFrame como uma tabela ou view (uma tabela temporária) e consultar usando SQL. Não há diferença de desempenho entre escrever consultas SQL ou escrever código em DataFrame.

    Outra consideração interessante é que “para o Spark (em Python ou R), não existe Dataset: tudo é um DataFrame e, portanto, sempre contamos com formato otimizado” (ZAHARIA, 2018, pg.57).

    image

    Isso é possível graças ao CATALYST OPTIMIZER, podemos usar SQL, DataFrames ou Datasets que o Catalyst Optimizer pode "traduzir" e otimizar qualquer um desses formatos em um plano de execução eficiente. Isso permite que o desenvolvedor escolha o formato que melhor se adapta ao seu use case, sem se preocupar com as nuances da execução física.

    image

    Catalyst Optimizer é um componente fundamental do Apache Spark, ele é responsável por melhorar o desempenho das consultas SQL e operações de DataFrame por meio de várias técnicas de otimização. 

    OVERVIEW ESTRUTURA DE EXECUÇÃO DA API

    image

    1.Logic plan / uresolved logical plan: Quando escrevemos um código usando qualquer uma dessas APIs (SQL, DataFrame ou Dataset), o código é inicialmente transformado em um plano lógico abstrato. Esse plano lógico representa as operações que você deseja realizar, mas não especifica como essas operações serão executadas fisicamente no cluster, razão pela qual é chamado de “unresolved logic plan”.

    2. Catalog and Analysis: O Spark usa o catálogo, um repositório de todas as informações sobre tabelas e DataFrames, para resolver colunas e tabelas no analisador. O analisador pode rejeitar o “unresolve logic plan”  se o nome da tabela ou coluna necessária não existir no catálogo. Se o analisador conseguir resolvê-lo, o resultado é passado para o Catalyst Optimizer.

    3.Catalyst Optimizer: O Catalyst Optimizer então entra em ação para transformar esse “resolved logic plan” em um” optimized logical plan”, um plano físico otimizado. O otimizador aplica uma série de regras e transformações para melhorar o desempenho da consulta, como reordenar operações, eliminar redundâncias e escolher as melhores estratégias de execução. 

    4.Phisical plan: Após a otimização, o Catalyst gera um plano físico detalhado que especifica exatamente como as operações serão executadas no cluster. Isso inclui decisões sobre como ler os dados, quais algoritmos de processamento usar e como distribuir o trabalho entre os nós do cluster.

    5. Execução e Resultados: Finalmente, o plano físico é executado e o resultado é retornado ao usuário. Ao selecionar um “physical plan” o Spark executa todo esse código sobre RDDs, a interface de programação de baixo nível do Spark. O Spark realiza otimizações adicionais em tempo de execução e, finalmente, retorna o resultado ao usuário. 

    Espero que esse estudo ajude a compreender um pouco mais sobre o ecossistema do Spark.

    Bons estudos e boa semana!

    Referências:

    Todas as imagens e conceitos foram retirados do livro Spark Definitive Guide, Matei Zaharia, 2018, Oreilly.

    Compartilhe
    Comentários (1)
    CARLOS
    CARLOS - 16/09/2024 22:16

    Parabéns pelo artigo.