Цитируя Spark DataFrames,Наборы данных и руководство по SQL:

Несколько оптимизаций Hive еще не включены в Spark. Некоторые из них (например, индексы) менее важны из-за вычислительной модели Spark SQL в памяти. Другие предназначены для будущих выпусков Spark SQL.

Будучи новичком в Spark, я немного озадачен этим по двум причинам:

Spark SQL предназначен для обработки больших данных, и по крайней мере в моем случае размер данных намного превышает размер доступной памяти. Если предположить, что это не редкость, что подразумевается под «вычислительной моделью Spark SQL в памяти»? Spark SQL рекомендуется только в тех случаях, когда данные помещаются в память?

Даже если предположить, что данные помещаются в память, полное сканирование очень большого набора данных может занять много времени. Я читаюэтот аргумент против индексации в базе данных в памяти, но я не был убежден. В приведенном здесь примере рассматривается сканирование таблицы с 10 000 000 записей, но это не очень большие данные. Сканирование таблицы с миллиардами записей может привести к тому, что простые запросы типа «SELECT x WHERE y = z» будут длиться вечно, а не возвращаться немедленно.

Я понимаю, что у индексов есть недостатки, такие как медленная INSERT / UPDATE, требования к пространству и т. Д. Но в моем случае использования я сначала обрабатываю и загружаю большой пакет данных в Spark SQL, а затем исследую эти данные в целом без дальнейших изменений. Spark SQL полезен для первоначальной распределенной обработки и загрузки данных, но отсутствие индексации делает интерактивное исследование медленнее и громоздче, чем я ожидал.

Тогда мне интересно, почему команда Spark SQL считает индексы неважными до такой степени, что они не соответствуют их плану. Есть ли другая модель использования, которая может обеспечить преимущества индексации, не прибегая к реализации чего-то эквивалентного независимо?