Использование SparkR JVM для вызова методов из файла Scala jar

Я хотел иметь возможность упаковать DataFrames в jar файл Scala и получить к ним доступ в R. Конечной целью является создание способа доступа к определенным и часто используемым таблицам базы данных в Python, R и Scala без написания другой библиотеки для каждого.

Чтобы сделать это, я создал файл jar в Scala с функциями, которые используют библиотеку SparkSQL для запроса базы данных и получения требуемых DataFrames. Я хотел иметь возможность называть эти функции в R без создания другой JVM, поскольку Spark уже работает на JVM в R. Однако использование JVM Spark не отображается в SparkR API. Чтобы сделать его доступным и сделать Java-методы вызываемыми, я изменил "backend.R", "generics.R", "DataFrame.R" и "NAMESPACE" в пакете SparkR и перестроил пакет:

В "backend.R" я сделал формальные методы "callJMethod" и "createJObject":

  setMethod("callJMethod", signature(objId="jobj", methodName="character"), function(objId, methodName, ...) {
  stopifnot(class(objId) == "jobj")
  if (!isValidJobj(objId)) {
    stop("Invalid jobj ", objId$id,
         ". If SparkR was restarted, Spark operations need to be re-executed.")
  }
  invokeJava(isStatic = FALSE, objId$id, methodName, ...)
})


  setMethod("newJObject", signature(className="character"), function(className, ...) {
  invokeJava(isStatic = TRUE, className, methodName = "<init>", ...)
})

Я модифицировал "generics.R", чтобы также содержать эти функции:

#' @rdname callJMethod
#' @export
setGeneric("callJMethod", function(objId, methodName, ...) { standardGeneric("callJMethod")})

#' @rdname newJobject
#' @export
setGeneric("newJObject", function(className, ...) {standardGeneric("newJObject")})

Затем я добавил экспорт этих функций в файл NAMESPACE:

export("cacheTable",
   "clearCache",
   "createDataFrame",
   "createExternalTable",
   "dropTempTable",
   "jsonFile",
   "loadDF",
   "parquetFile",
   "read.df",
   "sql",
   "table",
   "tableNames",
   "tables",
   "uncacheTable",
   "callJMethod",
   "newJObject")

Это позволило мне вызвать функции Scala, которые я написал, не запустив новую JVM.

В методах Scala я написал возвращаемые DataFrames, которые при возврате являются "jobj" s в R, но SparkR DataFrame - это среда + jobj. Чтобы превратить эти данные DataFrames в SparkR DataFrames, я использовал функцию dataFrame() в "DataFrame.R", которую я также сделал доступной, следуя приведенным выше шагам.

Затем я смог получить доступ к DataFrame, который я "построил" в Scala из R, и использовать все функции SparkR на этом DataFrame. Мне было интересно, есть ли лучший способ сделать такую кросс-язычную библиотеку, или если есть какая-то причина, что Spark JVM не должен быть общедоступным?

Ответ 1

по какой-либо причине Spark JVM не должен быть общедоступным?

Возможно, более одного. Разработчики Spark прилагают серьезные усилия для обеспечения стабильного публичного API. Низкие детали реализации, включая способ взаимодействия гостевых языков с JVM, просто не являются частью контракта. Он может быть полностью переписан в любой момент без какого-либо негативного воздействия на пользователей. Если вы решите использовать его, и есть обратные несовместимые изменения, вы сами по себе.

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

лучший способ сделать такую кросс-язычную библиотеку

Трудно сказать, не зная больше о вашем случае использования. Я вижу по крайней мере три варианта:

Для начала R предоставляет только слабые механизмы контроля доступа. Если какая-либо часть API является внутренней, вы всегда можете использовать функцию ::: для ее доступа. Как говорят умные люди:

Как правило, ошибка дизайна использует ::: в вашем коде, поскольку соответствующий объект, вероятно, был внутренним для хорошая причина.

но одна вещь наверняка намного лучше, чем изменение источника искры. В качестве бонуса он четко отмечает части вашего кода, которые являются особенно хрупкими, потенциально нестабильными.

Если вы хотите создать DataFrames, проще всего использовать raw SQL. Он чистый, портативный, не требует компиляции, упаковки и просто работает. Предполагая, что строка запроса, как указано ниже, хранится в переменной с именем q
```
CREATE TEMPORARY TABLE foo
USING org.apache.spark.sql.jdbc
OPTIONS (
    url "jdbc:postgresql://localhost/test",
    dbtable "public.foo",
    driver "org.postgresql.Driver"
)
```
его можно использовать в R:
```
sql(sqlContext, q)
fooDF <- sql(sqlContext, "SELECT * FROM foo")
```
Python:
```
sqlContext.sql(q)
fooDF = sqlContext.sql("SELECT * FROM foo")
```
Scala:
```
sqlContext.sql(q)
val fooDF = sqlContext.sql("SELECT * FROM foo")
```
или непосредственно в Spark SQL.
Наконец, вы можете использовать Spark Data Sources API для последовательного и поддерживаемого межплатформенного доступа.

Из этих трех я предпочел бы сырой SQL, а затем API Data Sources для сложных случаев и оставить внутренности в качестве последнего средства.

Изменить (2016-08-04):

Если вам интересен доступ к JVM на низком уровне, существует относительно новый пакет rstudio/sparkapi, который предоставляет внутренний протокол SparkR RPC. Трудно предсказать, как он будет развиваться, поэтому используйте его на свой страх и риск.