Spark SQL

Spark SQL — это модуль для обработки структурированных и полуструктурированных данных в рамках вычислительной платформы Apache Spark, предоставляющий интерфейс для работы с данными через язык запросов SQL и программные API на языках Java, Scala, Python и R. Модуль позволяет выполнять запросы, аналогичные SQL, над распределёнными наборами данных, поддерживая интеграцию с различными источниками данных (Hive, Avro, Parquet, JSON, JDBC) и обеспечивая высокую производительность за счёт использования оптимизатора Catalyst и механизма выполнения Tungsten.

История

Spark SQL был официально представлен в составе Apache Spark 1.0 (выпуск 2014 года) как замена более раннему модулю Shark, который базировался на Apache Hive и имел ограничения по производительности и совместимости. Основная цель создания Spark SQL — предоставить единый механизм для работы как с реляционными данными (SQL), так и с алгоритмическими вычислениями (например, MapReduce-подобными операциями) в рамках одного процесса. Разработка велась под руководством лаборатории AMPLab Калифорнийского университета в Беркли и позднее — компанией Databricks.

В версии Spark 2.0 (2016 год) Spark SQL стал центральным компонентом всей платформы: API DataFrame и Dataset, построенные поверх Spark SQL, вытеснили устаревшие RDD (Resilient Distributed Datasets) для большинства задач, требующих структурированных данных. В последующих версиях (Spark 3.x) модуль получил поддержку ANSI SQL, улучшенную обработку потоковых данных через Structured Streaming и интеграцию с хранилищами данных в облаке.

Классификация и компоненты

Spark SQL можно условно разделить на три основные логические части:

• SparkSession — точка входа для всех операций Spark, начиная с версии 2.0. Заменила отдельные объекты SQLContext, HiveContext и SparkContext.
• API: DataFrames, Datasets, SQL-запросы и UDF (определяемые пользователем функции), которые компилируются в единый оптимизированный план выполнения.
• Оптимизатор Catalyst — модуль, отвечающий за трансформацию логического плана запроса в физический план с применением правил оптимизации на основе деревьев выражений.
• Механизм выполнения Tungsten — низкоуровневая реализация обработки, использующая кодогенерацию и off-heap память для минимизации накладных расходов JVM.
• Data Sources API — стандартный интерфейс для чтения/записи данных из различных форматов (Parquet, ORC, Avro, JSON, CSV, JDBC, Delta Lake, Apache Iceberg, Apache Hudi).

Устройство и архитектура

Spark SQL обрабатывает запросы в несколько стадий:

1. SQL-парсинг — текст SQL-запроса разбирается в абстрактное синтаксическое дерево (AST), которое представляет логический план запроса.
2. Анализ — AST проверяется на семантическую корректность: разрешаются имена таблиц и столбцов, проверяются типы данных, присоединяются метаданные из каталога (Hive Metastore или встроенного SparkSessionCatalog).
3. Логическая оптимизация — Catalyst применяет фиксированный набор правил: перестановка предикатов (predicate pushdown), проталкивание проекций (project pruning), упрощение выражений, удаление подзапросов (subquery unnesting) и другие. Результат — оптимизированный логический план.
4. Физическое планирование — из оптимизированного логического плана выбирается конкретный набор физических операторов (например, выбор метода соединения — SortMergeJoin, BroadcastHashJoin, ShuffledHashJoin), учитывающий статистики данных и окружение (размер данных, наличие бродкаста).
5. Генерация кода — Tungsten преобразуёт физический план в эффективный скомпилированный Java-байт-код, минимизируя вызовы виртуальных функций и упаковку объектов. Это позволяет выполнять до нескольких миллиардов строк в секунду на одном ядре (в синтетических тестах).
6. Выполнение — сгенерированный код выполняется на узлах кластера Spark с минимальным использованием Java-объектов (вся обработка ведётся в off-heap памяти или в массивах примитивных типов).

Применение

Spark SQL используется в трёх основных сценариях:

• Аналитические ETL и отчёты — массовое преобразование, фильтрация, агрегация и запись данных в целевые хранилища (например, загрузка логов из Kafka в Parquet, построение витрин данных).
• Интерактивные запросы — ad-hoc анализ через JDBC/ODBC (например, через Apache Thrift Server или Databricks SQL) для BI-инструментов (Tableau, Power BI, Yandex DataLens). В этом режиме Spark SQL выступает как распределённый SQL-движок.
• Structured Streaming — обработка потоковых данных (из Kafka, Kinesis, файловых лент) с SQL-синтаксисом и оконными функциями, при этом данные рассматриваются как бесконечная таблица. Результаты могут записываться в те же форматы, что и в пакетном режиме.

Примеры

• Розничная аналитика: ежедневный расчёт общей выручки по магазинам и категориям товаров из 500 ГБ данных в Parquet с последующей записью результатов в PostgreSQL через JDBC.
• Логирование и мониторинг: чтение JSON-логов из S3, фильтрация по ошибкам, агрегация по IP-адресам за последний час с использованием группировки по окну.
• Машинное обучение: предварительная подготовка признаков (feature engineering) — объединение таблиц пользователей и транзакций, вычисление скользящих средних и кодирование категориальных переменных — перед обучением модели в MLlib.

Преимущества и недостатки

Spark SQL обеспечивает:

• Производительность — до 50–100 раз быстрее (в синтетических тестах), чем Hive на MapReduce для сложных запросов, благодаря поколению кода Tungsten и in-memory-обработке.
• Универсальность — единый API для пакетной и потоковой обработки, а также для машинного обучения (MLlib) и графовых вычислений (GraphX) в рамках одного кластера.
• Интеграция — поддержка десятков источников данных стандартными коннекторами, а также возможность реализовать собственный DataSource через интерфейсы Spark.

Недостатки:

• Требовательность к памяти — для оптимальной работы данные должны помещаться в оперативную память кластера (хотя возможен spilling на диск). Неэффективное управление памятью может вызвать переполнение кучи или «серый лист» задач.
• Отсутствие полной поддержки сложных SQL-конструкций — хотя в Spark 3.x добавлены многие элементы ANSI SQL (включая UNNEST, LATERAL VIEW, коррелированные подзапросы), часть синтаксиса (например, recursive CTE) ограничена.
• Не подходит для OLTP — Spark SQL ориентирован на пакетную или массовую обработку, не предназначен для единичных транзакционных запросов с латентностью менее 1 мс.

Критика

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

Интересные факты

• Spark SQL изначально разрабатывался как часть более широкой экосистемы Spark, но позднее получил собственную популярность, и на его базе были созданы отдельные продукты, такие как Databricks SQL и Apache Kyuubi — распределённые SQL-серверы на основе Spark.
• Оптимизатор Catalyst изначально вдохновлён идеей «золотого стандарта» из компиляторостроения: использование деревьев выражений и системы правил на основе Scala-паттернов.
• Механизм Tungsten был назван по одноимённой компании, которая производит высокотемпературные лампы, — в знак того, что Spark «светит» гораздо ярче (производительнее) на одном и том же «электричестве» (железе).

Источники

• Apache Spark 3.5.3 Documentation — «Spark SQL Guide»
• Armbrust, M., et al. Spark SQL: Relational Data Processing in Spark (SIGMOD 2015)
• Xin, R., et al. Tungsten: A Highly Efficient Execution Engine for Apache Spark (VLDB 2015)
• Databricks Engineering Blog: «Adaptive Query Execution and Dynamic Partition Pruning in Apache Spark» (2021)