Содержание этой статьи

1. Апач Спарк 2. История развития Spark SQL 3. Основной принцип выполнения Spark SQL 4. Катализатор Две основные оптимизации

портал：Hive Подробный анализ основного процесса выполнения SQL

1. Апач Спарк

Apache Sparkиспользуется длякрупномасштабная обработка данныхединая аналитическая система,на основеВычисления в памяти,Улучшена производительность обработки данных в режиме реального времени в среде больших данных.,При этом гарантированоВысокая отказоустойчивостьиВысокая масштабируемость,Разрешить пользователям развертывать Spark на большом количестве оборудования.,образуют кластеры.

Исходный код Spark вырос с 400 000 строк в версии 1.x до более чем 1 миллиона строк сейчас, и более 1400 экспертов внесли свой код. Весь исходный код платформы Spark — это огромный проект.

2. История развития Spark SQL

Мы знаем, что Hive реализует SQL на Hadoop, что упрощает задачи MapReduce и обеспечивает крупномасштабную обработку данных путем простого написания SQL. Однако у Hive также есть фатальные недостатки. Поскольку базовый уровень использует MapReduce для вычислений, задержка запроса высока.

1. Рождение Шарка

такSparkсуществоватьболее ранняя версия（1.0До）запущенShark,Что это?,Акула и Улей на самом деле тесно связаны.,Многие вещи в нижней части Shark по-прежнему зависят от Hive.,Однако три модуля управления памятью, физического планирования и выполнения были изменены.,Базовая модель вычислений на основе памяти использует Spark.,Это повышает производительность в несколько-сотни раз по сравнению с Hive.

Проблемы возникают:

1. потому что Shark Построение планов выполнения во многом зависит от Hive,хочу добавить новыйоптимизацияочень сложно；
2. Hive — это параллелизм на уровне процессов, а Spark — это параллелизм на уровне потоков, поэтому многие потокобезопасные коды в Hive неприменимы к Spark;
3. Из-за вышеперечисленных проблем Shark поддерживает ветку Hive и не может быть объединена с основной веткой, что делает ее неустойчивой;
4. На саммите Spark 1 июля 2014 года Databricks объявила, что прекращает разработку Shark и сосредоточивается на Spark SQL.

2. Рождение SparkSQL-DataFrame

Чтобы решить проблему:

1. Spark SQL План выполнения и оптимизация переданы в оптимизацию Catalyst；
2. Простой парсер SQL встроен, поэтому вам не нужно использовать HQL;
3. Он также представляет API-интерфейсы DSL, такие как DataFrame, которые не зависят ни от каких компонентов Hive.

новый вопрос：

В ранней версии SparkSQL все еще существует множество проблем, например, она может поддерживать только использование SQL, плохо совместима с императивными форматами, а вход недостаточно унифицирован.

3. Рождение набора данных SparkSQL.

В эпоху 1.6 в SparkSQL добавлен новый API под названием Dataset, который объединяет и объединяет доступ к SQL и использование императивных API. Это эпохальный прогресс.

В Dataset вы можете легко использовать SQL-запросы и фильтровать данные, а затем использовать императивный API для исследовательского анализа.

3. Основной принцип выполнения Spark SQL

Базовая архитектура Spark SQL примерно следующая:

можно увидеть,Оператор SQL, который мы написали,Прошел мимоОптимизатор (Катализатор),Конвертировать в РДД,Оставьте его для выполнения кластеру.

Между SQL и RDD существует Catalyst, который является ядром Spark SQL. Это платформа оптимизации запросов для выполнения операторов Spark SQL, основанная на структуре функционального программирования Scala.

Если мы хотим понять процесс выполнения Spark SQL, очень важно понять рабочий процесс Catalyst.

Оператор SQL генерирует программу, которая может быть распознана механизмом выполнения.,Просто не могу жить безПарсер, Оптимизатор, Выполнение Эти три процесса。иCatalystоптимизацияустройствосуществоватьосуществлятьСоздание планаиоптимизациярабочее время,Он неотделим от пяти своих внутренних компонентов.,Как показано ниже:

1. Модуль парсера：ВоляSparkSqlСтрока анализируется в абстрактное синтаксическое дерево/AST。
2. Модуль анализатора：Этот модуль пройдет весьAST,И выполните привязку типа данных и привязку функции на каждом узле AST.,Затем поля в таблице данных анализируются в соответствии с Каталогом метаданных.
3. Модуль оптимизатора：Этот модульCatalystосновной,Существует две основные стратегии: RBO и CBO.,вRBO основан на правилах, CBO основан на затратах.。
4. Модуль SparkPlanner：оптимизация Логика, лежащая в основеосуществлятьпланOptimizedLogicalPlanЭто все еще логично,и не может быть понят системой Spark,Нужен в это время ВоляOptimizedLogicalPlanпреобразован вфизический план 。
5. Модуль CostModel：Основано главным образом на статистике прошлых результатов,Выберите лучший план физического исполнения. Оптимизацией этого процесса является CBO (оптимизация на основе затрат).

Чтобы лучше понять весь процесс, ниже объясняется простой пример.

Шаг 1. Фаза синтаксического анализа: неанализируемый логический план

Проще говоря, Parser делит строку SQL на токены один за другим, а затем анализирует их в синтаксическое дерево в соответствии с определенными семантическими правилами. Модуль парсера В настоящее время используются сторонние библиотеки.ANTLRруководитьосуществленный,включая тех, с кем мы знакомыHive、Presto、SparkSQLи т. д., все это вызваноANTLRосуществленный。

В этом процессе будет оцениваться, соответствуют ли операторы SQL спецификациям, например, правильно ли написаны такие ключевые слова, как select fromwhere. Конечно, имя таблицы и поля таблицы на этом этапе проверяться не будут.

Шаг 2. Этап анализатора: анализируемый логический план

Логический план после анализа в основном имеет скелет.,В настоящее время для выражения этих морфем необходима базовая метаданная.,Наиболее важная информация метаданных в основном состоит из двух частей.：Схема таблицыиОсновная информация о функциях,Схема таблицы в основном включает в себя базовое определение таблицы (имя столбца, тип данных), формат данных таблицы (Json, Text), физическое расположение таблицы и т. д.,Базовые функции в основном относятся к информации о классе.

Анализатор снова обойдет все синтаксическое дерево.,Привязывайте типы данных и функции к каждому узлу дерева.,напримерpeopleЛексема будет проанализирована в соответствии с информацией таблицы метаданных, чтобы включитьage、idа такжеnameтаблица из трех столбцов,people.ageбудет разобрано на тип данныхintпеременная,sumанализируется в определенную агрегатную функцию。

Этот процесс определит, действительно ли имя таблицы и имя поля оператора SQL существуют в базе данных метаданных.

Шаг 3. Модуль оптимизатора: оптимизированный логический план

Модуль оптимизации Optimizer — это ядро ​​всего Catalyst.,Как упоминалось выше, оптимизация делится на два типа: оптимизация на основе правил (RBO) и оптимизация на основе затрат (CBO). Стратегия оптимизации на основе правил фактически представляет собой обход синтаксического дерева.,Узлы сопоставления шаблонов, удовлетворяющие определенным правилам.,существовать Выполните соответствующие эквивалентные преобразования。Вот три общих правила:：Предикат Pushdown 、Постоянное складывание 、Обрезка колонн 。

• Предикат Pushdown

Левая часть изображения выше — это проанализированное синтаксическое дерево.,Сначала создаются две таблицы в синтаксическом дереве.join,послесуществоватьиспользоватьage>10руководитьfilter。joinОператор очень трудоемкий оператор,Сколько времени это займет, обычно зависит от размера двух таблиц, участвующих в объединении.,Если можно уменьшить размер двух таблиц, участвующих в объединении,Это может значительно сократить время, необходимое для оператора соединения.

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

• Постоянное складывание

постоянное накоплението естьнапримервычислитьx+(100+80)->x+180,Хотя это небольшое изменение,Но значение огромно. Если оптимизация не выполнена,Каждый результат требуетосуществлятьодин раз100+80издействовать,а затем добавить его к результату。оптимизациянет необходимости делать это сноваосуществлять100+80действовать。

• Обрезка колонн

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

Шаг 4. Модуль SparkPlanner: преобразование в план физического выполнения.

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

На этом этапе необходимо преобразовать логический план выполнения в план физического выполнения.,То есть превратить логически осуществимый план выполнения в план, который Spark действительно может выполнить. Например, оператор соединения,Spark разработал различные стратегии алгоритмов для этого оператора на основе разных сценариев.,иметьBroadcastHashJoin、ShuffleHashJoinа такжеSortMergejoinждать,План физического выполнения на самом деле состоит в том, чтобы выбрать наименее трудоемкую реализацию алгоритма среди этих конкретных реализаций.,Как выбрать,Давайте кратко поговорим об этом:

• Фактически SparkPlanner преобразует логический план после оптимизации.,генерируетсяНесколько исполняемых физических планов Физический план；
• затемCBO (Оптимизация на основе затрат)оптимизация Стратегия будет основана наCost ModelПосчитайте каждыйPhysical Спланируйте стоимость и выберите тот, у которого наименьшая стоимость. Physical План как окончательный физический Plan。

Вышеупомянутые 2, 3 и 4 шага вместе представляют собой оптимизатор Catalyst!

Шаг 5. Выполните физический план

Наконец, на основе оптимального плана физического выполнения генерируется байт-код Java, SQL преобразуется в DAG, а операции выполняются в форме RDD.

Резюме: Общая блок-схема выполнения

4. Катализатор Две основные оптимизации

Вот две важные оптимизации оптимизатора Catalyst:

1. RBO: оптимизация на основе правил

Точки оптимизации включают в себя: перемещение предикатов, сокращение столбцов, постоянное накопление и т. д.

• Случай с предикатом：

select 
* 
from 
table1 a 
join 
table2 b 
on a.id=b.id 
where a.age>20 and b.cid=1

Приведенный выше оператор будет автоматически оптимизирован следующим образом:

select 
*
from
(select * from table1 where age>20) a
join
(select * from table2 where cid=1) b
on a.id=b.id 

То есть данные фильтруются заранее на этапе подзапроса, а объем перемешиваемых данных при более позднем объединении значительно уменьшается.

• Случай обрезки столбца：

select
a.name, a.age, b.cid
from
(select * from table1 where age>20) a
join
(select * from table2 where cid=1) b
on a.id=b.id

Приведенный выше оператор будет автоматически оптимизирован следующим образом:

select 
a.name, a.age, b.cid
from
(select name, age, id from table1 where age>20) a
join
(select id, cid from table2 where cid=1) b
on a.id=b.id

То есть заранее запросить необходимые столбцы и исключить другие ненужные столбцы.

• постоянное накопление：

select 1+1 as id from table1

Приведенный выше оператор будет автоматически оптимизирован следующим образом:

select 2 as id from table1

то есть会提前Воля1+1Рассчитано как2,Затем назначьте его каждой строке столбца идентификатора.,Не нужно каждый раз рассчитывать1+1。

2. CBO: оптимизация затрат

Именно в SparkPlanner оптимизированный логический план генерирует несколько исполняемых физических планов. Planпосле,множественная физикаосуществлятьпланна основеCost Model选取最优изосуществлять耗时最少из那个План по физике。

--END-