Комментарии 4
этот факт делал нецелесообразным "обертывания" существующих функций в Catalyst Expression
Ну погодите, каталист же вряд ли многое понимает о нашем/вашем Java коде. И уж тем более о коде функций, которые взяты из существующих классов. Да и какие физические оптимизации ему даст это знание? Ну т.е. какие свойства выражений каталист позволяют применять к ним те оптимизации, которые нельзя применять к UDF, и что это за оптимизации?
Я думаю, тут разница в генерации кода. Предположу, что если код на Java, то Catalyst генерит Java байт-код из нашего inline-кода. Если же используем объекты Scala, то байт-код объектов Scala генериться компилятором Scala, а не самим Catalyst'ом (то есть Catalyst переисползует байт-код, полученный от копилятора Scala), что может помешать Catalyst'у провести часть оптимизаций.
Например, при манипуляции с колонками нам надо их найти, извлечь значния из различных "мест" памяти и только потом применить преобразования. Catalyst же при генерирации Java-кода для выражений, вроде как объединяет его с кодом для доступа к столбцам из представления InternalRow и компилирует все это в единый байт-код JVM. В том числе и поэтому, думаю, такой код более производительный.
Ну то есть, эти оптимизации - они на уровне кода функции, скажем так? Т.е. это не оптимизация нашего плана, в виде скажем проталкивания предикатов (потому что предикат в форме Catalyst Expression все равно не сильно-то протолкнешь). Хотя в теории, если оптимизатор знает структуру выражения, то он его может попытаться пропихнуть и в JDBC источник, и в паркет (с ограничениями, разумеется).
[Туториал] Пишем собственные Spark Native Functions (Часть 2)