Spark 4.2, выпущенный 14 июля 2026 года, добавил в SQL векторные функции и новый механизм nearest-by join для top-K поиска ближайших соседей. Для команд, которые собирают RAG, поиск по embeddings и AI-сервисы поверх уже существующего data lake, это выглядит как попытка превратить Spark из ETL-комбайна в площадку, где можно не только готовить данные, но и обслуживать часть AI-нагрузки.
Об этом сообщает The New Stack, и сам повод действительно не проходной. В релизе Apache Spark 4.2 разработчики закрыли более 1700 Jira-задач при участии свыше 250 контрибьюторов. Но для AI-стека важнее не объем списка изменений, а конкретика: в движке появились функции вроде vector_cosine_similarity, vector_l2_distance, vector_inner_product, а также API nearestByJoin для поиска ближайших записей между двумя наборами данных.
Именно отсюда и растет громкий тезис про «пенсию для vector database». Если embeddings уже лежат в таблицах Spark, а инженерам нужно быстро считать similarity, ранжировать кандидатов и собирать top-K результаты, часть задач действительно можно не выносить в отдельный специализированный контур. Для крупных компаний это не только про красоту архитектуры. Это про деньги, операционную сложность и вечный вопрос, зачем держать еще один сервис, еще один индекс и еще одну команду поддержки, если значимая часть пайплайна и так живет в Spark.
Но здесь есть важная оговорка, без которой заголовок легко превращается в маркетинговую сказку. По документации Spark 4.2, текущая реализация nearestByJoin пока считает полный декартов продукт левой и правой сторон, а память ограничивает только числом возвращаемых результатов на строку. Иными словами, движок уже умеет формально делать nearest-neighbor join, но не обещает магического ускорения на огромных корпусах в стиле зрелых vector DB. Более того, в документации прямо сказано, что индексные approximate-стратегии только планируются для будущих релизов, а пока большую правую таблицу лучше предварительно фильтровать.
Для практиков это даже интереснее, чем сам хайповый заголовок. Spark 4.2 не убивает рынок векторных баз одним махом, зато меняет границу, где отдельная vector DB вообще нужна. Если у вас внутренний поиск по документам, семантический матчинг каталога, дедупликация похожих сущностей или ранжирование кандидатов внутри уже существующего lakehouse-контура, новая функциональность может закрыть задачу «достаточно хорошо». А вот там, где нужны миллисекундные ответы, агрессивная approximate nearest neighbor-индексация, самостоятельный online-serving слой и зрелая operational-модель под read-heavy запросы, специализированные движки пока выглядят безопаснее.
Контекст здесь тоже важен. Spark давно был центром корпоративной обработки данных, но AI-бум заставил инфраструктурные платформы расширять амбиции. Раньше Spark в типичном пайплайне отвечал за ingestion, подготовку фичей и batch-обработку, а дальше эстафету принимали отдельные хранилища, feature store, vector database и online-сервисы. Теперь границы снова сдвигаются: если embeddings можно считать, хранить, агрегировать и хотя бы частично искать в одном движке, архитекторам проще защищать консолидацию стека перед бизнесом. Не потому, что «одна система лучше всех», а потому что каждая лишняя система очень быстро превращается в лишний бюджет, отдельный SLA и новую точку отказа.
На этом фоне остальная часть релиза тоже выглядит не случайным набором фич, а заявкой на роль платформы для AI workloads. В Spark 4.2 по умолчанию включили Arrow-optimized Python UDFs и Arrow-based IPC для PySpark, добавили поддержку CDC через SQL-конструкцию CHANGES и DataFrame/PySpark API, расширили возможности Data Source V2, а также улучшили Spark Connect. Для Python-команд это особенно показательно: Spark продолжает снижать трение между JVM-миром и реальной инженерной жизнью, где большинство AI-пайплайнов собирается не на Scala, а на Python.
Для русскоязычной аудитории здесь вывод довольно приземленный. Если ваша команда уже использует Spark, Delta/Iceberg-подобный слой и строит retrieval-пайплайны вокруг корпоративных данных, Spark 4.2 стоит смотреть не как «очередной мажорный релиз», а как повод пересчитать архитектуру. Возможно, часть сценариев семантического поиска можно вернуть обратно в основной контур данных и убрать лишний сервис. Возможно, наоборот, тесты покажут, что без специализированного ANN-индекса задержка и стоимость запросов остаются слишком высокими. В обоих случаях выигрыш в том, что теперь спор можно вести не на уровне презентаций вендоров, а на уровне конкретного кода и конкретных нагрузок.
Главный вопрос после релиза звучит так: останется ли Spark 4.2 удобным местом для подготовки embeddings, или действительно дорастет до полноценного слоя AI-serving без обязательной прослойки из внешних векторных систем. Если в следующих версиях проект добавит зрелые индексные approximate-стратегии, этот спор станет заметно интереснее. Подробнее о поводе пишет .