Armazenamento em Cache de Fragmentos Resultantes do Spark

As versões 6.6.0 e superiores do Amazon EMR incluem o recurso opcional Armazenamento em Cache de Fragmentos Resultantes, que automaticamente armazena em cache os fragmentos resultantes. Esses fragmentos resultantes são partes dos resultados de subárvores de consultas que são armazenadas em um bucket do Amazon S3 de sua escolha. Os fragmentos resultantes da consulta armazenados são reutilizados em execuções de consultas subsequentes, resultando em consultas mais rápidas.

O Armazenamento em Cache de Fragmentos Resultantes analisa as consultas do Spark SQL e armazena em cache os fragmentos resultantes elegíveis no local especificado do S3. Em execuções subsequentes da consulta, os fragmentos resultantes utilizáveis da consulta são automaticamente detectados e obtidos no S3. O Armazenamento em Cache de Fragmentos Resultantes difere do Armazenamento em Cache de Conjuntos Resultantes, em que as consultas subsequentes precisam corresponder exatamente à consulta original para retornar os resultados do cache. Quando usado para consultas repetidamente direcionadas a um subconjunto estático dos dados, o Armazenamento em Cache de Fragmentos Resultantes acelera significativamente a performance.

Considere a consulta a seguir, que conta pedidos até o ano de 2022:

select
    l_returnflag,
    l_linestatus,
    count(*) as count_order
from
    lineitem
where
    l_shipdate <= current_date
    and year(l_shipdate) == '2022'
group by
    l_returnflag,
    l_linestatus

Com o passar do tempo, essa consulta precisa ser executada todos os dias para informar o total de vendas do ano. Sem o Armazenamento em Cache de Fragmentos Resultantes, os resultados de todos os dias do ano precisam ser recalculados todos os dias. A consulta ficará mais lenta com o tempo e será mais lenta no final do ano, quando todos os 365 dias de resultados precisarão ser recalculados.

Ao ativar o Armazenamento em Cache de Fragmentos Resultantes, você usa os resultados de todos os dias anteriores do ano com base no cache. A cada dia, o atributo deve recalcular apenas um dia de resultados. Depois que o atributo computa o fragmento resultante, o atributo armazena o fragmento em cache. Como resultado, os tempos de consultas habilitadas para cache são curtos e permanecem constantes para cada consulta subsequente.

Habilitar o Armazenamento em Cache de Fragmentos Resultantes do Spark

Para habilitar o Armazenamento em Cache de Fragmentos Resultantes do Spark, execute as seguintes etapas:

1. Crie um bucket de cache no Amazon S3 e autorize o acesso de leitura/gravação para o EMRFS. Para ter mais informações, consulte Autorizar acesso aos dados do EMRFS no Amazon S3.

2. Defina a configuração do Spark no Amazon EMR para habilitar o recurso.

   spark.subResultCache.enabled = true
   spark.subResultCache.fs.root.path = s3://DOC-EXAMPLE-BUCKET/cache_dir/

3. Habilite o gerenciamento do ciclo de vida do S3 para que o bucket limpe automaticamente os arquivos de cache.

4. Opcionalmente, configure as maxBufferSize propriedades reductionRationThreshold e para ajustar ainda mais o recurso.

   spark.sql.subResultCache.reductionRatioThreshold
   spark.sql.subResultCache.maxBufferSize

Considerações ao usar o Armazenamento em Cache de Fragmentos Resultantes

A economia de custos obtida quando você usa resultados já armazenados em cache no Amazon S3 em vez de recalculá-los aumenta com o número de vezes que os mesmos resultados armazenados em cache podem ser usados. Consultas com verificações de grandes tabelas seguidas por filtros ou agregações de hash que reduzem o tamanho do resultado em um fator de pelo menos 8 (ou seja, uma proporção de pelo menos 8:1 em tamanho de entrada:resultados) serão as que mais se beneficiarão desse atributo. Quanto maior a taxa de redução entre a entrada e os resultados, maior a relação custo-benefício. Consultas com taxas de redução menores, mas que contêm etapas computacionais caras entre a verificação da tabela e o filtro ou as agregações, também serão beneficiadas, desde que o custo de produzir os resultados seja maior do que o custo de buscá-los no Amazon S3. Por padrão, o Armazenamento em Cache de Fragmentos Resultantes só entra em vigor quando detecta que uma taxa de redução será de pelo menos 8:1.

Quando suas consultas reutilizam repetidamente os resultados armazenados em cache, os benefícios desse atributo são maiores. Consultas em janelas contínuas e incrementais são bons exemplos. Por exemplo, uma consulta de janela contínua de 30 dias que já foi executada por 29 dias precisaria extrair apenas 1/30 dos dados de destino de sua fonte de entrada original e usaria fragmentos de resultados armazenados em cache nos 29 dias anteriores. Uma consulta de janela incremental se beneficiaria ainda mais, já que o início da janela permanece fixo: em cada invocação da consulta, uma porcentagem menor do processamento exigirá a leitura da fonte de entrada.

Veja a seguir considerações adicionais sobre o uso do Armazenamento em Cache de Fragmentos Resultantes:

• As consultas que não têm como alvo os mesmos dados com os mesmos fragmentos de consulta terão uma baixa taxa de acertos de cache e, portanto, não se beneficiarão desse atributo.

• Consultas com taxas de redução baixas que não contêm etapas de computação caras resultarão em resultados armazenados em cache que são aproximadamente tão caros de ler quanto de processar inicialmente.

• A primeira consulta sempre demonstrará uma pequena regressão devido ao custo de gravação no cache.

• O atributo Armazenamento em Cache de Fragmentos Resultantes funciona exclusivamente com arquivos Parquet. Arquivos em outros formatos não são compatíveis.

• Os buffers do atributo Armazenamento em Cache de Fragmentos Resultantes só tentarão armazenar em cache verificações com tamanhos de divisão de arquivos de 128 MB ou mais. Com a configuração padrão do Spark, o Armazenamento em Cache de Fragmentos Resultantes será desabilitado se o tamanho da verificação (tamanho total de todos os arquivos que estão sendo verificados) dividido pelo número de núcleos do executor for menor que 128 MB. Quando qualquer uma das configurações do Spark listadas abaixo for definida, o tamanho da divisão de arquivos será:

  min(maxPartitionBytes, max(openCostInBytes, scan size / minPartitionNum))

  • spark.sql. leafNodeDefaultParalelismo (o valor padrão é spark.default.parallelism)

  • spark.sql.files. minPartitionNum (o valor padrão é spark.sql. leafNodeDefaultParalelismo)

  • spark.sql.files. openCostInBytes

  • spark.sql.files. maxPartitionBytes

• O atributo Armazenamento em Cache de Fragmentos Resultantes realiza o armazenamento em cache na granularidade da partição de Resilient Distributed Dataset (RDD - conjunto de dados resilientes e distribuídos). A taxa de redução descrita anteriormente, cujo padrão é 8:1, é avaliada por partição de RDD. Workloads com taxas de redução por RDD maiores e menores que 8:1 podem ter benefícios menores de performance do que workloads com taxas de redução por RDD consistentemente menores que 8:1.

• O atributo Armazenamento em Cache de Fragmentos Resultantes usa um buffer de gravação de 16 MB por padrão para cada partição RDD armazenada em cache. Se mais de 16 MB forem armazenados em cache por partição RDD, o custo de determinar que uma gravação não é possível pode resultar em uma regressão de desempenho.

• Embora, por padrão, o Armazenamento em Cache de Fragmentos Resultantes não tente armazenar em cache os resultados da partição de RDD com uma taxa de redução menor que 8:1 e limite seu buffer de gravação em 16 MB, esses dois valores podem ser ajustados por meio das seguintes configurações:

  spark.sql.subResultCache.reductionRatioThreshold (default: 8.0)
  spark.sql.subResultCache.maxBufferSize (default: 16MB, max: 64MB)

• Vários clusters usando a mesma versão do Amazon EMR podem compartilhar o mesmo local de cache. Para garantir a exatidão dos resultados, o Armazenamento em Cache de Fragmentos Resultantes não usará resultados de cache gravados por diferentes versões do Amazon EMR.

• O cache de fragmentos de resultados será desativado automaticamente para casos de uso do Spark Streaming ou quando RecordServer o Apache Ranger for usado. AWS Lake Formation

• A leitura/gravação do Armazenamento em Cache de Fragmentos Resultantes usa buckets do EMRFS e do Amazon S3. As criptografias CSE/SSE S3/SSE KMS são compatíveis.