Почему Spark SQL считает поддержку индексов неважной?

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

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

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

Spark SQL предназначен для обработки больших данных и, по крайней мере, для моего использования в случае, если размер данных намного превышает размер доступной памяти. Предполагая, что это не редкость, что подразумевается под "Spark SQLs" in-memory "? Искры Spark SQL рекомендуется только для случаи, когда данные вписываются в память?
Даже если данные вписываются в память, полное сканирование на очень большом набор данных может занять много времени. Я прочитал этот аргумент против индексирование в базе данных в памяти, но я не был убежден. Пример там обсуждается сканирование таблицы в 10 000 000 записей, но это не действительно большие данные. Сканирование таблицы с миллиардами записей может вызвать простые запросы типа "SELECT x WHERE y = z" принимают навсегда вместо этого немедленного возвращения.

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

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

Ответ 1

Индексирование входных данных

Основная причина, по которой индексирование внешних источников данных не входит в сферу Spark, заключается в том, что Spark не является системой управления данными, а движком обработки пакетных данных. Поскольку он не владеет данными, которые он использует, он не может надежно контролировать изменения и, как следствие, не может поддерживать индексы.
Если источник данных поддерживает индексирование, он может быть косвенно использован Spark через механизмы, такие как предикат pushdown.

Индексирование распределенных структур данных:

Стандартные методы индексирования требуют постоянного и четко определенного распределения данных, но данные в Spark обычно являются эфемерными, а его точное распределение недетерминировано.
компоновка данных высокого уровня, обеспечиваемая надлежащим разделением в сочетании с хранилищем и сжатием столбцов, может обеспечить очень эффективный распределенный доступ без накладных расходов на создание, хранение и поддержание индексов. Это общий шаблон, используемый различными столбчатыми системами в памяти.

Ответ 2

В общем, полезность индексов в лучшем случае сомнительна. Вместо этого важнее разделение данных. Это очень разные вещи, и только потому, что ваша база данных по выбору поддерживает индексы, это не значит, что они имеют смысл, учитывая то, что пытается сделать Spark. И это не имеет ничего общего с "в памяти".

Итак, что такое индекс?

В те дни, когда постоянное хранилище было сумасшедшим (вместо, по сути, свободным), системы реляционной базы данных были связаны с минимизацией использования постоянного хранилища. Реляционная модель, по необходимости, разбила запись на несколько частей - нормализовала данные - и сохранила их в разных местах. Чтобы прочитать запись клиента, возможно, вы прочитали таблицу customer, таблицу customerType, извлеките пару записей из таблицы address и т.д. Если у вас есть решение, требующее, чтобы вы прочитали всю таблицу найти то, что вы хотите, это очень дорого, потому что вам нужно сканировать так много таблиц.

Но это не единственный способ сделать что-то. Если вам не нужны столбцы фиксированной ширины, вы можете хранить весь набор данных в одном месте. Вместо того, чтобы выполнять полноэкранное сканирование в связке таблиц, вам нужно сделать это только в одной таблице. И это не так плохо, как вы думаете, особенно если вы можете разбить свои данные.

Спустя 40 лет законы физики изменились. Скоростные скорости чтения/записи на жестком диске и линейные скорости чтения/записи резко расходятся. Вы можете в основном сделать 350 движений головы за секунду на диск. (Немного больше или меньше, но это хорошее среднее число.) С другой стороны, один диск может читать около 100 МБ в секунду. Что это значит?

Сделайте математику и подумайте об этом - это означает , если вы читаете менее 300 Кбайт на движение головки диска, вы дросселируете пропускную способность своего диска.

Seriouusly. Подумайте об этом секунду.

Цель индекса - позволить вам переместить головку вашего диска в нужное место на нужном диске и просто прочитать эту запись - скажем, только запись address, объединенная как часть вашей записи customer. И я говорю, что это бесполезно.

Если бы я составлял индекс, основанный на современной физике, мне нужно было бы получить только 100 КБ целевой части данных (если бы мои данные были выложены большими кусками), но мы говорим о теории здесь все равно). Основываясь на приведенных выше цифрах, больше точности, чем это просто отходы.

Теперь вернитесь к своему стандартизованному дизайну стола. Скажем, что запись customer действительно разделена на 6 строк, хранящихся в 5 таблицах. 6 всего движения головки диска (я предполагаю, что индекс кэшируется в памяти, поэтому нет движения диска). Это означает, что я могу читать 1,8 МБ линейных/де-нормированных записей клиентов и быть таким же эффективным.

А как насчет истории клиентов? Предположим, я хотел не просто посмотреть, как выглядит клиент сегодня - представьте себе, что я хочу полную историю или подмножество истории? Умножьте все выше на 10 или 20, и вы получите изображение.

Что лучше, чем индекс, будет разделение данных - убедитесь, что все записи клиентов попадают в один раздел. Таким образом, с движением одного диска, я могу прочитать всю историю клиента. Движение одной головки диска.

Скажите еще раз, почему вы хотите индексы.

Индексы против ___?

Не поймите меня неправильно - есть ценность в "предварительном приготовлении" ваших поисков. Но законы физики предлагают лучший способ сделать это, чем традиционные индексы. Вместо того, чтобы хранить запись клиента только в одном месте и создавая указатель на нее - индекс - почему бы не сохранить запись в нескольких местах?

Помните, что дисковое пространство по существу бесплатное. Вместо того, чтобы пытаться свести к минимуму объем используемого хранилища - устаревший артефакт реляционной модели - просто используйте свой диск в качестве кеша поиска.

Если вы считаете, что кто-то хочет видеть клиентов, перечисленных как по географии, так и по продажам, сделайте несколько копий ваших записей клиентов таким образом, чтобы оптимизировать эти запросы. Как я уже сказал, используйте диск, подобный вашему в кеше памяти. Вместо того, чтобы создавать свой кеш в памяти, объединяя разрозненные фрагменты постоянных данных, создайте свои постоянные данные, чтобы отразить ваш кеш в памяти, поэтому все, что вам нужно сделать, это прочитать его. На самом деле даже не пытайтесь хранить его в памяти - просто прочитайте его прямо с диска каждый раз, когда вам это нужно.

Если вы думаете, что это звучит сумасшедшим, подумайте об этом - если вы будете кэшировать его в памяти, вы, вероятно, будете кэшировать его дважды. Вероятно, ваш контроллер OS/drive использует основную память в качестве кеша. Не беспокойтесь о кешировании данных, потому что кто-то еще уже!

Но я отвлекаюсь...

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