Reduzindo custos para cargas de trabalho do Apache Spark com alto embaralhamento com armazenamento sem servidor para Amazon EMR Serverless

No re:Invent 2025, anunciamos armazenamento sem servidor para Amazon EMR Sem servidoreliminando a necessidade de provisionar armazenamento em disco native para cargas de trabalho do Apache Spark. O armazenamento sem servidor do Amazon EMR Serverless reduz os custos de processamento de dados em até 20% ao mesmo tempo que ajuda a evitar falhas de trabalho devido a restrições de capacidade do disco.

Nesta postagem, exploramos as melhorias de custo que observamos ao comparar trabalhos do Apache Spark com armazenamento sem servidor no EMR Serverless. Analisamos mais detalhadamente como o armazenamento sem servidor ajuda a reduzir custos para cargas de trabalho do Spark com alto embaralhamento e descrevemos orientações práticas sobre como identificar os tipos de consultas que podem se beneficiar mais com a ativação do armazenamento sem servidor em seus trabalhos do EMR Serverless Spark.

Resultados de benchmark para EMR 7.12 com armazenamento sem servidor em relação a discos padrão

Conduzimos o benchmarking de desempenho e economia de custos usando o Conjunto de dados TPC-DS em escala de 3 TB, executando mais de 100 consultas que incluíam uma combinação de operações de alto e baixo embaralhamento. A configuração de teste utilizou Alocação Dinâmica de Recursos (DRA) sem capacidade pré-inicializada. O sistema foi configurado com 20 GB de espaço em disco, e as configurações do Spark incluíram 4 núcleos e 14 GB de memória para driver e executor, com alocação dinâmica começando em 3 executores iniciais (spark.dynamicAllocation.initialExecutors = 3). Uma análise comparativa foi realizada entre configurações de armazenamento em disco native e armazenamento sem servidor. O objetivo period avaliar as implicações dos custos totais e médios entre essas abordagens de armazenamento.

A tabela e o gráfico a seguir comparam a redução de custos observada no ambiente de teste descrito acima. Baseado em preços us-east-1observamos uma economia de custos de mais de 26% ao usar armazenamento sem servidor.

% Economia relativa (por consulta) de armazenamento sem servidor em comparação com o embaralhamento de disco padrão

Nestes testes, observamos que o armazenamento sem servidor no EMR Serverless reduz o custo de aproximadamente 80% das consultas TPC-DS. Para as consultas onde traz benefícios, proporciona uma economia média de custos de aproximadamente 47%, com economia de até 85%. As consultas que regridem normalmente têm baixa intensidade de embaralhamento, mantêm alto paralelismo durante a execução ou são concluídas com rapidez suficiente para que as oportunidades de redução de escala do executor sejam mínimas. A figura a seguir mostra a diferença percentual de custo para cada uma das consultas TPC-DS quando o armazenamento sem servidor foi habilitado, em comparação com a configuração de linha de base sem armazenamento sem servidor. Valores positivos indicam economia de custos (quanto maior, melhor), enquanto valores negativos indicam regressões de custos.

Porcentagem de economia de custos por consulta TPC-DS com armazenamento sem servidor habilitado

Comparação de tempo de execução

Há uma economia de custos significativa devido ao aumento da elasticidade resultante da rescisão antecipada dos executores. No entanto, o tempo de conclusão do trabalho pode aumentar porque os dados aleatórios são armazenados em armazenamento sem servidor, em vez de localmente nos executores. A latência adicional de leitura e gravação para dados aleatórios contribui para um tempo de execução mais longo. A tabela e o gráfico a seguir mostram a comparação do tempo de execução que observamos em nosso ambiente de teste.

Armazenar o embaralhamento externamente e desacoplar da computação permitiu flexibilidade para o EMR Serverless desligar recursos não utilizados dinamicamente à medida que as informações de estado eram descarregadas da computação. No entanto, essas economias de custos só podem ser obtidas quando o DRA está ativado. Se o DRA estiver desativado, o Spark manterá vivos os recursos não utilizados, aumentando o custo whole.

Padrões de consulta que se beneficiam do armazenamento sem servidor

A economia de custos com o armazenamento sem servidor depende muito de como a demanda do executor muda ao longo dos estágios de um trabalho. Nesta seção, examinamos padrões de execução comuns e explicamos quais formatos de consulta têm maior probabilidade de se beneficiar do armazenamento sem servidor do EMR Serverless e quais padrões de consulta podem não se beneficiar da externalização aleatória.

Consultas de padrão de triângulo invertido

Para entender por que a externalização dos dados aleatórios pode permitir uma economia de custos tão significativa, considere uma consulta simplificada. A consulta a seguir calcula o whole anual de vendas do conjunto de dados TPC-DS juntando-se ao store_sales e date_dim tabelas, somando os valores de vendas por ano e ordenando os resultados.

SELECT d_year, SUM(ss_net_paid) AS total_sales
FROM store_sales
JOIN date_dim ON store_sales.ss_sold_date_sk = date_dim.d_date_sk
GROUP BY d_year
ORDER BY d_year;

Esta consulta demonstra que a alta demanda de executores durante a fase de mapa e a baixa demanda de executores na fase de redução é uma consulta de agregação com uma entrada de alta cardinalidade e um agrupamento de baixa cardinalidade.

• Estágio 1 (alta demanda de executores)

As etapas de junção e leitura examinam todo o store_sales e date_dim tabelas. Isso geralmente envolve bilhões de linhas em conjuntos de dados TPC-DS de grande escala, então o Spark tentará paralelizar a varredura em muitos executores para maximizar a taxa de transferência de leitura e a eficiência computacional.

• Estágio 2 (Baixa Demanda do Executor)

A agregação está ativada d_yearque normalmente tem poucos valores exclusivos, como apenas alguns anos nos dados. Isso significa que após o estágio de embaralhamento, a fase de redução combina os agregados parciais em um número de chaves igual ao número de anos (geralmente <10). Apenas algumas tarefas do Spark são necessárias para concluir a agregação ultimate, de modo que a maioria dos executores fica ociosa.

Com as informações de embaralhamento armazenadas no disco native, os recursos de computação associados a esses executores ociosos ainda estariam em execução para manter os dados de embaralhamento disponíveis. Com os dados aleatórios descarregados dos nós que executam os executores, com o DRA habilitado, os nós com executores ociosos são liberados imediatamente.

Como os estágios iniciais processam entradas de alta cardinalidade e os estágios posteriores recolhem os dados em um pequeno número de chaves, essas consultas formam um padrão de execução de “triângulo invertido”: paralelismo amplo na parte superior e paralelismo estreito na parte inferior, conforme mostrado na imagem a seguir:

Consultas de padrão de ampulheta

Dependendo da complexidade do trabalho, pode haver vários estágios com demanda variável de acordo com o número de executores necessários para o estágio. Esses trabalhos podem se beneficiar de uma maior elasticidade obtida ao descarregar dados aleatórios para armazenamento externo sem servidor. Um desses padrões é o padrão da ampulheta. A figura a seguir mostra um padrão de carga de trabalho em que a demanda do executor se expande, contrai durante os estágios de embaralhamento intenso e se expande novamente. O armazenamento sem servidor do EMR Serverless separa os dados da computação, permitindo uma redução mais eficiente durante estágios estreitos e ajudando a melhorar a otimização de custos para cargas de trabalho elásticas.

Padrão de ampulheta na execução do estágio Spark

Para identificar consultas desta categoria, considere o exemplo a seguir: A consulta passa por três estágios:

• Estágio 1: A junção inicial e filtro entre store_sales e merchandise produz um conjunto de dados intermediário amplo e de alta cardinalidade, exigindo alto paralelismo (muitos executores).
• Etapa 2: Agregação de grupos por um pequeno conjunto de categorias como “Casa” ou “Eletrônicos”, resultando em uma queda drástica nas partições de produção. Portanto, esse estágio é executado de forma eficiente com apenas alguns executores, pois há poucos dados para paralelizar.
• Estágio 3: O pequeno resultado é unido (geralmente uma junção de transmissão) de volta a uma grande tabela de fatos com dimensão de knowledge, produzindo novamente um resultado grande que é bem paralelizado, fazendo com que o Spark aumente o uso do executor para esse estágio.

WITH stage1_large_scan AS (
-- Stage 1: Scan and vast be a part of generates numerous parallelism and wishes many executors
SELECT ss_item_sk, ss_sold_date_sk, ss_net_paid, i_category
FROM store_sales
JOIN merchandise ON store_sales.ss_item_sk = merchandise.i_item_sk
WHERE merchandise.i_category IN ('House', 'Electronics')
),
stage2_small_agg AS (
-- Stage 2: Mixture on low-cardinality column (by class), decreasing to few teams, so few executors wanted
SELECT i_category, SUM(ss_net_paid) AS total_cat_sales
FROM stage1_large_scan
GROUP BY i_category
),
stage3_broadcast_filter AS (
-- Stage 3: Be part of again to high-cardinality desk, pushing parallelism up once more
SELECT s.*, d.d_year
FROM store_sales s
JOIN date_dim d ON s.ss_sold_date_sk = d.d_date_sk
)

SELECT s3.d_year, s2.i_category, s2.total_cat_sales
FROM stage2_small_agg s2
JOIN stage3_broadcast_filter s3 ON s2.i_category = s3.i_category
ORDER BY s3.d_year, s2.i_category;

Esse padrão é comum para cenários de relatórios e análises dimensionais e é eficaz para demonstrar como o Spark ajusta dinamicamente o uso de recursos entre estágios de trabalho com base nas necessidades de cardinalidade e paralelismo. Essas consultas também podem se beneficiar da elasticidade possibilitada pelo armazenamento externo sem servidor.

Consultas de padrão retangular

Nem todas as consultas se beneficiam da externalização do embaralhamento. Considere uma consulta em que a cardinalidade é alta, o que significa que ambos os estágios operam em um grande número de partições e chaves. Normalmente, as consultas agrupadas por colunas de alta cardinalidade (como merchandise ou cliente) fazem com que a maioria dos estágios exija quantidades semelhantes de paralelismo. A figura a seguir ilustra uma carga de trabalho do Spark em que o paralelismo permanece consistentemente alto entre os estágios. Neste padrão, tanto a Fase 1 como a Fase 2 operam num grande número de partições e chaves, resultando numa procura sustentada do executor durante todo o ciclo de vida do trabalho.

Padrão de execução de alta cardinalidade com paralelismo sustentado

A consulta a seguir é a mesma que usamos anteriormente no padrão de triângulo invertido, com uma alteração. Substituímos a tabela dim_date (baixa cardinalidade) por merchandise (alta cardinalidade).

SELECT i_item_id, SUM(ss_net_paid) AS total_sales
FROM store_sales
JOIN merchandise ON store_sales.ss_item_sk = merchandise.i_item_sk
GROUP BY i_item_id
ORDER BY i_item_id
LIMIT 100;

• Estágio 1: Lê as linhas de store_sales e se junta com merchandiseespalhando dados por muitas partições — semelhante ao primeiro estágio da consulta authentic.
• Etapa 2: A agregação é feita por i_item_idque normalmente possui milhares a milhões de valores distintos em conjuntos de dados reais. Isso mantém o paralelismo alto; muitas tarefas lidam com teclas não sobrepostas e as saídas aleatórias permanecem grandes.

Não há queda significativa na cardinalidade: como nenhum dos estágios é reduzido a um conjunto de pequenos grupos, a maioria dos executores permanece ocupada durante as fases principais do trabalho, com pouco tempo ocioso mesmo após o embaralhamento. Esse tipo de consulta resulta em um perfil de utilização do executor mais uniforme porque cada estágio processa um quantity de trabalho semelhante, minimizando assim a variação na utilização de recursos. Essas consultas de padrão retangular não terão o benefício de custo da elasticidade obtida ao descarregar dados aleatórios. No entanto, ainda pode haver outros benefícios, como a redução de falhas de trabalho e gargalos de desempenho devido a restrições de disco, liberdade de planejamento e dimensionamento de capacidade e provisionamento de armazenamento para operações de dados intermediárias.

Conclusão

O armazenamento sem servidor para Amazon EMR Serverless pode proporcionar economias substanciais de custos para cargas de trabalho com padrões de recursos dinâmicos, como visto na economia média de custos de 26% que observamos em nosso ambiente de testes. Ao externalizar os dados aleatórios, você pode obter elasticidade para liberar executores ociosos imediatamente, demonstrado pelas economias que chegam a 85% em nosso ambiente de testes, em consultas que seguem padrões de triângulo invertido e ampulheta quando a Alocação Dinâmica de Recursos está habilitada. Embora as consultas de padrão retangular possam não apresentar reduções drásticas de custos, elas ainda podem se beneficiar de maior confiabilidade e remoção da sobrecarga de planejamento de capacidade.

Para começar: Analise seus padrões de execução de trabalho, habilite a alocação dinâmica de recursos e teste o armazenamento sem servidor em cargas de trabalho com alto quantity de trabalho. Procurando reduzir os custos sem servidor do Amazon EMR para cargas de trabalho do Spark? Discover o armazenamento sem servidor para EMR Serverless hoje.

Sobre os autores