Partilhar via

Otimização do armazenamento de dados para o Apache Spark

  • Artigo

Este artigo aborda estratégias para otimizar o armazenamento de dados para uma execução eficiente de tarefas do Apache Spark no Azure HDInsight.

Descrição Geral

O Spark suporta vários formatos, como csv, json, xml, parquet, orc e avro. O Spark pode ser expandido para suportar muitos mais formatos com origens de dados externas. Para obter mais informações, veja Pacotes do Apache Spark.

O melhor formato para desempenho é parquet com compressão snappy, que é a predefinição no Spark 2.x. Parquet armazena dados em formato columnar e está altamente otimizado no Spark.

Escolher abstração de dados

As versões anteriores do Spark utilizam RDDs para abstrair dados, o Spark 1.3 e 1.6 introduziram DataFrames e Conjuntos de Dados, respetivamente. Considere os seguintes méritos relativos:

  • DataFrames
    • Melhor escolha na maioria das situações.
    • Fornece otimização de consultas através do Catalyst.
    • Geração de código em fase inteira.
    • Acesso direto à memória.
    • Sobrecarga de recolha de lixo baixa (GC).
    • Não tão amigável para programadores como Os Conjuntos de Dados, uma vez que não existem verificações de tempo de compilação ou programação de objetos de domínio.
  • Conjuntos de Dados
    • Bom em pipelines ETL complexos em que o impacto no desempenho é aceitável.
    • Não é bom em agregações em que o impacto no desempenho pode ser considerável.
    • Fornece otimização de consultas através do Catalyst.
    • Compatível com o programador ao fornecer a programação de objetos de domínio e verificações de tempo de compilação.
    • Adiciona uma sobrecarga de serialização/desserialização.
    • Sobrecarga de GC elevada.
    • Interrompe a geração de código em toda a fase.
  • RDDs
    • Não precisa de utilizar RDDs, a menos que precise de criar um novo RDD personalizado.
    • Sem otimização de consultas através do Catalyst.
    • Nenhuma geração de código de fase inteira.
    • Sobrecarga de GC elevada.
    • Tem de utilizar APIs legadas do Spark 1.x.

Selecionar armazenamento predefinido

Quando cria um novo cluster do Spark, pode selecionar Armazenamento de Blobs do Azure ou Azure Data Lake Storage como o armazenamento predefinido do cluster. Ambas as opções dão-lhe o benefício do armazenamento de longo prazo para clusters transitórios. Assim, os seus dados não são eliminados automaticamente quando elimina o cluster. Pode recriar um cluster transitório e continuar a aceder aos seus dados.

Store Type Sistema de Ficheiros Velocidade Transitório Casos de Utilização
Armazenamento de Blobs do Azure wasb://url/ Standard Yes Cluster transitório
Armazenamento de Blobs do Azure (seguro) wasbs://url/ Standard Yes Cluster transitório
Azure Data Lake Storage Gen2 abfs://url/ Mais rápido Yes Cluster transitório
Azure Data Lake Storage Gen 1 adl://url/ Mais rápido Yes Cluster transitório
Local HDFS hdfs://url/ Mais rápido No Cluster interativo 24 horas por dia, 7 dias por semana

Para obter uma descrição completa das opções de armazenamento, veja Comparar opções de armazenamento para utilização com clusters do Azure HDInsight.

Utilizar a cache

O Spark fornece os seus próprios mecanismos nativos de colocação em cache, que podem ser utilizados através de diferentes métodos, como .persist(), .cache()e CACHE TABLE. Esta colocação em cache nativa é eficaz com pequenos conjuntos de dados e em pipelines ETL onde precisa de colocar em cache resultados intermédios. No entanto, atualmente, a colocação em cache nativa do Spark não funciona bem com a criação de partições, uma vez que uma tabela em cache não mantém os dados de criação de partições. Uma técnica de colocação em cache mais genérica e fiável é a colocação em cache da camada de armazenamento.

  • Colocação em cache do Spark Nativo (não recomendado)

    • Bom para pequenos conjuntos de dados.
    • Não funciona com a criação de partições, o que pode mudar em futuras versões do Spark.

  • Colocação em cache ao nível do armazenamento (recomendado)

    • Pode ser implementado no HDInsight com a funcionalidade Cache de E/S .
    • Utiliza a colocação em cache na memória e SSD.

  • HDFS local (recomendado)

    • hdfs://mycluster caminho.
    • Utiliza a colocação em cache SSD.
    • Os dados em cache serão perdidos quando eliminar o cluster, exigindo uma reconstrução da cache.

Otimizar a serialização de dados

As tarefas do Spark são distribuídas, pelo que a serialização de dados adequada é importante para o melhor desempenho. Existem duas opções de serialização para o Spark:

  • A serialização java é a predefinição.
  • Kryo a serialização é um formato mais recente e pode resultar numa serialização mais rápida e compacta do que Java. Kryo requer que registe as classes no seu programa e ainda não suporta todos os tipos Serializáveis.

Utilizar os registos

O registo é semelhante à criação de partições de dados. Mas cada registo pode conter um conjunto de valores de coluna em vez de apenas um. Este método funciona bem para a criação de partições em números grandes (em milhões ou mais) de valores, como identificadores de produtos. Um registo é determinado ao hashar a chave de registo da linha. As tabelas em registo oferecem otimizações exclusivas porque armazenam metadados sobre como foram registados e ordenados.

Algumas funcionalidades avançadas de registo são:

  • Otimização de consultas com base no registo de metadados.
  • Agregações otimizadas.
  • Associações otimizadas.

Pode utilizar a criação de partições e o registo ao mesmo tempo.

Passos seguintes