Add spark 4+ and scala 2.13 support

[CMBCKSRL]

Что предлагается

Добавить поддержку Apache Spark 4.x (Scala 2.13) в дополнение к текущему
Spark 3.5.x (Scala 2.12). Сейчас и сборка, и рантайм-реестр жёстко привязаны
к 3.5/2.12 (ClickhouseDialectRegistry бросает UnsupportedOperationException
на любой версии, кроме 3.5), поэтому на Spark 4 расширение не запускается.

Зачем

• Spark 4.x уже выпущен и постепенно становится дефолтом; пользователи на
  Spark 4 / Scala 2.13 сейчас не могут использовать диалект вообще.
• В build.gradle уже стоят TODO мейнтейнеров про кросс-билд для Scala 2.13
  и для разных версий Spark — то есть потребность осознавалась.
• Сама логика диалекта оказалась совместимой со Spark 4 практически без
  изменений, так что цена поддержки невысока.

Как это будет работать

Кросс-билд через Gradle-property (по аналогии с уже существующим
-Pclickhouse.jdbc.version):

• -PsparkProfile=spark3 → Scala 2.12 / Spark 3.5.1 / Java 8–11, артефакт _2.12
• -PsparkProfile=spark4 → Scala 2.13 / Spark 4.1.2 / Java 17, артефакт _2.13
• по умолчанию spark3 (текущее поведение публикации не меняется)

Версионно-специфичные исходники: диалект для каждой мажорной версии
Spark лежит в своём source-каталоге (scala-spark3 / scala-spark4),
реестр выбирает реализацию по spark.version в рантайме через рефлексию.

Ключевые моменты, которые стоит обсудить:

1. В Spark 4 у JdbcDialect появился метод isObjectNotFoundException,
   через который JdbcUtils.tableExists отличает «таблицы нет» от реальной
   ошибки. ClickHouse JDBC-драйвер не выставляет SQLState, поэтому без
   переопределения этого метода все операции записи падают на probe-запросе
   SELECT 1 FROM t WHERE 1=0 (ошибка UNKNOWN_TABLE). Предлагается
   переопределить его, распознавая код ошибки ClickHouse 60 / UNKNOWN_TABLE
   по тексту сообщения — это рабочее, но не самое строгое решение, и здесь
   хотелось бы услышать ваше мнение.
2. Spark 4 требует Java 17 и стандартный набор --add-opens (иначе падает
   обработка Date/DateTime). Предлагается добавлять их в test-таск на Java 9+.
3. На Spark 4 поведение чтения массивов меняется: с драйвером ClickHouse 0.7.x
   несколько типов (Array(Int16/Int32/Int64/Float32/Float64)), ранее
   считавшихся неподдерживаемыми, теперь читаются успешно; остальные кидают
   новый класс ошибки COLUMN_ARRAY_ELEMENT_TYPE_MISMATCH. Ожидания в тестах
   станут версионно-специфичными.
4. Scalafix на профиле spark4 придётся отключить: semanticdb-scalac пока не
   опубликован для версии Scala 2.13, которую подтягивает Spark 4. На spark3
   Scalafix продолжит работать. (Готов обсудить альтернативы — например,
   пин конкретной версии Scala/semanticdb.)

CI: матрицы тестов и релиза расширяются на оба профиля с соответствующей
версией Java.

Статус

Черновая реализация уже готова и проверена локально (все тесты зелёные на
обоих профилях и обоих версиях драйвера 0.7.2 / 0.9.8 против ClickHouse 25.9).
Готов оформить PR после обсуждения подхода — особенно по пунктам 1 и 4 выше.

[dolfinus]

Добрый день.

Спасибо за предложение. Мы будем рады, если получится реализовать поддержку свежих версий Spark в данном диалекте.

Несколько моментов, которые хотелось бы проговорить.

Сборка под разные версии Spark

Да, мы бы хотели, чтобы в .jar артефакте диалекта по возможности не было зашитой версии Spark. Для этого мы как раз и реализовывали runtime проверку на версию Spark, соответствующая реализация подгружается из модуля io.github.mtsongithub.doetl.sparkdialectextensions.clickhouse.sparkXY. Вместо введения нового деления на scala-spark3, scala-spark4 лучше придерживаться данного подхода, по возможности.

В качестве reference стоит использовать репозиторий OpenLineage - есть отдельные gradle подпроекты с реализациями под разные версии Spark, но при этом финальный .jar артефакт лишь один. Не уверен, что этот подход получится применить и здесь - в OpenLineage используется чисто Java, в диалекте же могут быть нюансы, связанные с компиляцией под разные версии Scala.

Мы не против того, чтобы артефакт со Scala 2.12 был под Spark 3, а Scala 2.13 под Spark 4. Но по возможности стоит сделать так, чтобы артефакт не зависел от минорной версии Spark - без отдельных .jar под Spark 4.0, 4.1, 4.2 и т.п.

Ожидания в тестах станут версионно-специфичными.

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

ClickHouse JDBC-драйвер не выставляет SQLState

Судя по коду, для JDBC v2 класс ExceptionUtils, в котором определен код ошибки для невалидного SQL запроса - кажется он должен подойти под этот кейс. И для JDBC v1 был аналогичный класс SqlExceptionUtils. Это не то, что нужно?

На текст ошибки полагаться не стоит - он зависит от локали на Clickhouse сервере.

[dolfinus]

@CMBCKSRL Возможна ли реализация с учетом озвученных предложений?

[CMBCKSRL]

@dolfinus думаю, что да. В ближайшее время постараюсь добраться до этой задачки