Блог

Мы создали и обучили модель с использованием библиотек H2O. Сконфигурировал H2O в контейнере OpenShift и развернул обученную модель для получения вывода в реальном времени. Это хорошо работало, когда у нас был один контейнер. Мы должны масштабироваться, чтобы справиться с увеличением объема транзакций. Возникла проблема с состоянием H2OFrame. Пожалуйста, посмотрите мой пример кода.

Шаг 1: преобразует словарь JSON в фрейм Pandas.
Шаг-2: преобразует фрейм Pandas в фрейм H2O.
Шаг 3: Запустите модель с фреймом H2O в качестве входных данных.

Здесь шаг 2 возвращает дескриптор данных, хранящихся в контейнере. «H2OFrame похож на фрейм данных pandas или R data.frame. Одним из важных различий является то, что данные обычно не хранятся в памяти, вместо этого они находятся на (возможно, удаленном) Кластер H2O, и, следовательно, H2OFrame представляет собой простой дескриптор этих данных «. Таким образом, запрос шага 3 должен отправляться в тот же контейнер. В противном случае он не может найти кадр H2O и выдает ошибку.

Шаг 1: преобразование словаря JSON в фрейм данных с использованием фрейма данных Pandas

  ToBeScored = pd.DataFrame([jsonDictionary])
  

Шаг 2: преобразовать фрейм данных panda в фрейм H2o

  ToBeScored_hex = h2o.H2OFrame(ToBeScored)
  

Шаг 3: запустите модель

  outPredections = rf_model.predict(ToBeScored_hex)
  

Если H2OFrame может быть возвращен как объект в памяти на шаге-2, тогда можно избежать состояния. Есть ли какой-нибудь способ?
Или, может ли кластеризация H2O быть настроена для хранения H2OFrame таким образом, чтобы он мог быть доступен из любого контейнера OpenShift в кластере?

Полезные ссылки
Функция прогнозирования H2O принимает данные только в формате H2OFrame. Функция прогнозирования — http://docs.h2o.ai/h2o/latest-stable/h2o-py/docs/model_categories.html#h2o.model.model_base .ModelBase.predict
Тип данных фрейма H2O — http://docs.h2o.ai/h2o/latest-stable/h2o-py/docs/frame.html

Обновлено 19.6.2019 продолжение вопроса к разъяснению @ErinLeDell
Мы обновились до H2O 3.24 и использовали модель MOJO. Удален шаг 2 и заменен на шаг 3 этим вызовом функции.

 import h2o as h 
result = h.mojo_predict_csv(input_csv_path="PredictionDataRow.csv",mojo_zip_path="rf_model.zip",
genmodel_jar_path="h2o-genmodel.jar", java_options='-Xmx512m -XX:ReservedCodeCacheSize=256m', verbose=True) 
  

Внутренне он выполнил приведенную ниже команду, которая инициализировала новую JVM и запускала локальный сервер H2O для каждого вызова. Локальный сервер H2O инициализируется для поиска пути к java.

 java = H2OLocalServer._find_java()   // Find java path then creates below command line

C:Program Files (x86)Common FilesOracleJavajavapathjava.exe -Xmx512m -XX:ReservedCodeCacheSize=256m -cp h2o-genmodel.jar hex.genmodel.tools.PredictCsv --mojo C:UsersadminDocumentsCodepythonrf_model.zip --input PredictionDataRow.csv --output C:UsersadminDocumentsCodepythonprediction.csv --decimal 
  

Вопрос-1: Есть ли какой-либо способ использовать существующую JVM и не всегда создавать новую для каждой транзакции?
Вопрос-2: Есть ли способ передать путь java, чтобы избежать инициализации локального сервера H2O? Требуется ли H2OLocalServer для чего-либо, кроме поиска пути Java? Если этого нельзя избежать, возможно ли один раз инициализировать локальный сервер и направлять новые запросы на существующий локальный сервер H2O вместо запуска нового локального сервера H2O?

Альтернативой является использование модели H2O MOJO (вместо двоичной модели, которая должна существовать в памяти кластера H2O для прогнозирования). Модели MOJO могут располагаться на диске и не требуют работающего кластера H2O. Затем вы можете пропустить шаг 2 и использовать функцию h2o.mojo_predict_pandas() на шаге 3.