Цель плана выполнения
План выполнения - это набор операций, выполняемых для преобразования операторов языка запросов (SQL, Spark SQL, операции с фреймами данных и т. д.) в набор оптимизированных логических и физических операций.
Если говорить кратко, то это набор операций, которые превращаются в DAG и отправляются на Spark Executors.
DAG означает «направленный ациклический граф». DAG - это ациклический граф, создаваемый DAGScheduler в Spark. Как граф, он состоит из вершин и ребер, которые будут представлять RDD и операции (трансформации и действия), выполняемые над ними.
В Spark оптимизатор носит имя «Catalyst» и может быть представлен схемой ниже. Он будет создавать различные типы планов:
Catalyst последовательно выполняет следующие операции:
- Analysis (Анализ)
- Logical Optimization (Логическая оптимизация)
- Physical Planning (Физическое планирование)
- Cost Model Analysis (Анализ с помощью модели затрат)
- Code Generation(Генерация кода)
В результате будут созданы планы:
- Unresolved logical plan
- Resolved logical plan
- Optimized logical plan
- Physical plans
Цель всех этих операций и планов - автоматически создать наиболее эффективный способ обработки вашего запроса.
Генерация планов
Функция для просмотра плана называется explain(). Мы можем манипулировать датафреймом как с помощью DataFrame API так и Spark SQL. В обоих случаях нам доступен вызов функции explain().
До версии Apache Spark 3.0 существовало только два режима форматирования вывода explain:
- explain(extended=False), который отображал только физический план
- explain(extended=True), который отображал все планы (логический и физический)
Начиная с Apache Spark 3.0, есть новый параметр «mode», который определяет ожидаемый формат плана:
- explain(mode=«simple»), который будет отображать физический план
- explain(mode=«extended»), который будет отображать физический и логический планы (как и опция «extended»)
- explain(mode=«codegen»), который будет отображать java-код, планируемый к выполнению
- explain(mode=«cost»), который отобразит оптимизированный логический план и связанную с ним статистику (если она существует)
- explain(mode=«formatted»), который отобразит форматированый вывод с деталями каждого узла
Различия в планах
1. Parsed Logical Plan: Разбор логического плана - это начальный этап обработки, на котором Spark разбирает SQL-запрос или трансформаций DataFrame и преобразует его в представление абстрактного синтаксического дерева (AST). На этом этапе выполняется лексический анализ (токенизация) и синтаксический анализ (синтаксический разбор), чтобы убедиться, что синтаксис запроса корректен и соответствует правилам грамматики Spark SQL. Разобранный логический план отражает структуру запроса или преобразования в древовидной форме, но не включает никаких проверок оптимизации или валидации. На этом этапе Spark только проверяет синтаксис и структуру запроса.
2. Analyzed Logical Plan: Проанализированный логический план - это этап, на котором Spark выполняет семантический анализ и разрешает ссылки на объекты базы данных (таблицы, столбцы, функции) в запросе или преобразовании. На этом этапе распознаются имена таблиц и столбцов, проверяется их существование и доступность, а также применяется проверка типов для обеспечения совместимости. Проанализированный логический план представляет собой полностью разрешенную и проверенную структуру запроса или трансформаций, включая все ссылки на объекты и выражения.
3. Optimized logical Plan: Оптимизированный логический план - это этап, на котором Spark применяет логические оптимизации для повышения производительности запросов и использования ресурсов. На этом этапе к анализируемому логическому плану применяются правила и преобразования для генерации более эффективного плана. Оптимизатор Catalyst примененяет широкий спектр методов оптимизации, таких как predicate pushdown, projection pruning, join reordering, constant folding, and subquery optimization.. Оптимизированный логический план представляет собой окончательную, оптимизированную версию логического плана выполнения запроса перед его трансляцией в физический план выполнения.
4. Physical Plan: На основе оптимизированного логического плана создается план, описывающий его физическое выполнение на кластере. Но прежде чем выбрать физический план, Catalyst Optimizer сгенерирует множество физических планов, основанных на различных стратегиях. Каждый физический план будет оценен по времени выполнения и прогнозу потребления ресурсов, и только один план будет выбран для выполнения.
AQE (Adaptive Query Execution)
AQE - это новая функция в Spark 3.0, которая позволяет изменять план во время выполнения.
Она собирает статистику во время выполнения, и если Spark обнаруживает лучший план, он меняет его прямо во время выполнения. Если мы наложим это на обновление схему Catalyst, получится что-то вроде этого:
