Citando os DataFrames Spark,Conjuntos de dados e manual SQL:

Algumas otimizações do Hive ainda não estão incluídas no Spark. Alguns desses (como índices) são menos importantes devido ao modelo computacional em memória do Spark SQL. Outros estão com slots para versões futuras do Spark SQL.

Sendo novo no Spark, estou um pouco confuso com isso por dois motivos:

O Spark SQL foi projetado para processar Big Data e, pelo menos no meu caso de uso, o tamanho dos dados excede em muito o tamanho da memória disponível. Supondo que isso não seja incomum, o que significa "modelo computacional em memória do Spark SQL"? O Spark SQL é recomendado apenas para casos em que os dados cabem na memória?

Mesmo assumindo que os dados se encaixam na memória, uma varredura completa em um conjunto de dados muito grande pode levar muito tempo. Eu liesse argumento contra a indexação no banco de dados na memória, mas eu não estava convencido. O exemplo discute uma varredura de uma tabela de 10.000.000 de registros, mas isso não é realmente um grande volume de dados. A varredura de uma tabela com bilhões de registros pode fazer com que consultas simples do tipo "SELECT x WHERE y = z" demorem uma eternidade em vez de retornar imediatamente.

Entendo que os índices têm desvantagens, como INSERT / UPDATE mais lento, requisitos de espaço etc. Mas, no meu caso de uso, primeiro processo e carrego um grande lote de dados no Spark SQL e depois os exploro como um todo, sem mais modificações. O Spark SQL é útil para o processamento distribuído inicial e o carregamento dos dados, mas a falta de indexação torna a exploração interativa mais lenta e mais complicada do que eu esperava.

Pergunto-me, então, por que a equipe do Spark SQL considera os índices sem importância a ponto de estar fora de seu roteiro. Existe um padrão de uso diferente que possa fornecer os benefícios da indexação sem recorrer à implementação de algo equivalente independentemente?