Загрузка / создание фрейма на внешнем бэкэнде H2O зависает из python / pyspark - PullRequest
Новая
       56

Загрузка / создание фрейма на внешнем бэкэнде H2O зависает из python / pyspark

0 голосов
/ 16 марта 2019

У меня проблема с тем, что команда h2o.H2OFrame([1,2,3]) создает фрейм в h2o на внутреннем бэкэнде , но не на внешнем бэкэнде .Вместо этого соединение не прерывается (создается кадр, но процесс зависает).

Может показаться, что сообщение на /3/ParseSetup не возвращается (где urllib3, похоже, застряло).Более конкретно, из журналов h2o для соединения с внешним бэкэндом, примером этого является (где я сократил дату и IP): 

* 10.*.*.15:56565 8120 #7003-141 INFO: Reading byte InputStream into Frame:
* 10.*.*.15:56565 8120 #7003-141 INFO: frameKey: upload_8a440dcf457c1e5deacf76a7ac1a4955
* 10.*.*.15:56565 8120 #7003-141 DEBUG: write-lock upload_8a440dcf457c1e5deacf76a7ac1a4955 by job null
* 10.*.*.15:56565 8120 #7003-141 INFO: totalChunks: 1
* 10.*.*.15:56565 8120 #7003-141 INFO: totalBytes:  21
* 10.*.*.15:56565 8120 #7003-141 DEBUG: unlock upload_8a440dcf457c1e5deacf76a7ac1a4955 by job null
* 10.*.*.15:56565 8120 #7003-141 INFO: Success.
* 10.*.*.15:56565 8120 #7003-135 INFO: POST /3/ParseSetup, parms: {source_frames=["upload_8a440dcf457c1e5deacf76a7ac1a4955"], check_header=1, separator=44}

Для сравнения, внутренний бэкэнд завершает этот вызови файлы журнала содержат: 

** 10.*.*.15:54444 2421 #0581-148 INFO: totalBytes:  21
** 10.*.*.15:54444 2421 #0581-148 INFO: Success.
** 10.*.*.15:54444 2421 #0581-149 INFO: POST /3/ParseSetup, parms: {source_frames=["upload_b985730020211f576ef75143ce0e43f2"], check_header=1, separator=44}
** 10.*.*.15:54444 2421 #0581-150 INFO: POST /3/Parse, parms: {number_columns=1, source_frames=["upload_b985730020211f576ef75143ce0e43f2"], column_types=["Numeric"], single_quotes=False, parse_type=CSV, destination_frame=Key_Frame__upload_b985730020211f576ef75143ce0e43f2.hex, column_names=["C1"], delete_on_done=True, check_header=1, separator=44, blocking=False, chunk_size=4194304}
...

Существует различие в блокировке by job null, которая возникает, но она снята, поэтому я подозреваю, что это не критическая проблема.Я безуспешно свернул эту конечную точку на обоих серверах и проверяю исходный код, чтобы выяснить, почему.

Я могу просмотреть загруженный фрейм, работающий h2o.ls(), несмотря на процесс зависания, и я могучтобы извлечь кадр, используя h2o.get_frame(frame_id="myframe_id") на внешнем бэкэнде.

Я попробовал / подтвердил следующие вещи:

  • Подтвердил, что версия с газированной водой верна относительноверсия spark (т.е. h2o_pysparkling_2.3 - для Spark 2.3.x, как указано в docs.h2o.ai --- в моем случае газированная вода 2.3.12 - Spark 2.3.0.cloudera2);
  • Загрузил газированную воду, стабильную в кластер и запустил ./get-extended-h2o.sh cdh5.14, что дало мне h2odriver-sw2.3.0-cdh5.14-extended.jar банку;
  • Различные перестановки параметров для карты сокращают работу.Интересно, что наш кластер довольно занят, и настройка базового порта была необходима для стабильности.Кроме того, наши подсети охватывают переключатели, которые перепутались с мульти-кастом.В конечном итоге следующий аргумент вызвал бэкэнд без сбоев: 
    hadoop jar h2odriver-sw2.3.0-cdh5.14-extended.jar -Dmapreduce.job.queuename=root.users.myuser -jobname extback -baseport 56565 -nodes 10 -mapperXmx 10g -network 10.*.*.0/24
  • Подтвердил, что могу запросить бэкэнд, так как h2o.ls() работает;
  • Вместо этого загрузил фрейм данных искрыпростого списка (та же проблема): 
    sdf = session.createDataFrame([
    ('a', 1, 1.0), ('b', 2, 2.0)],
    schema=StructType([StructField("string", StringType()),
                       StructField("int", IntegerType()),
                       StructField("float", FloatType())])) 
    hc.as_h2o_frame(sdf)

С точки зрения YARN я предпринял попытки представления в режиме клиента и кластера в простом тестовом приложении: 

spark2-submit --master yarn --deploy-mode cluster --queue root.users.myuser --conf 'spark.ext.h2o.client.port.base=65656' extreboot.py

и без --master yarn и --deploy-mode cluster для режима клиента по умолчанию.

Наконец, код extreboot.py: 

    from pyspark.conf import SparkConf
    from pyspark.sql import SparkSession
    from pysparkling import *
    import h2o

    conf = SparkConf().setAll([
    ('spark.ext.h2o.client.verbose', True),
    ('spark.ext.h2o.client.log.level', 'DEBUG'),
    ('spark.ext.h2o.node.log.level', 'DEBUG'),
    ('spark.ext.h2o.client.port.base', '56565'),
    ('spark.driver.memory','8g'),
    ('spark.ext.h2o.backend.cluster.mode', 'external')])

    session = SparkSession.builder.config(conf=conf).getOrCreate() 

    ip_addr='10.10.10.10'  
    port=56565

    conf = H2OConf(session).set_external_cluster_mode().use_manual_cluster_start().set_h2o_cluster(ip_addr, port).set_cloud_name("extback")
    hc = H2OContext.getOrCreate(session, conf)

    print(h2o.ls())
    h2o.H2OFrame([1,2,3])
    print('DONE')

Кто-нибудь знает, почему он может зависать (в сравнениик внутреннему бэкэнду), что я делаю не так, или какие шаги я могу предпринять, чтобы лучше отладить это?Спасибо!

1 Ответ

1 голос
/ 18 марта 2019

Я бы порекомендовал обновить версию Sparkling Water до последней версии (в настоящее время 2.3.26 и доступно здесь ), поскольку вы используете 2.3.12 и с тех пор было несколько исправлений для проблем с зависаниями. Надеюсь, быстрое обновление исправит вашу проблему.

...