SnappyData - snappy-job - impossible d'exécuter le fichier jar

Question

J'essaie de lancer le fichier jar à partir de snappydata cli.

Je veux juste créer une session sparkSession et SnappyData au début.

package io.test 

import org.apache.spark.sql.{SnappySession, SparkSession} 

object snappyTest { 

    def main(args: Array[String]) { 
    val spark: SparkSession = SparkSession 
    .builder 
    .appName("SparkApp") 
    .master("local") 
    .getOrCreate 

val snappy = new SnappySession(spark.sparkContext) 
} 
} 

à partir du fichier SBT:

name := "SnappyPoc" 

version := "0.1" 

scalaVersion := "2.11.8" 

libraryDependencies += "io.snappydata" % "snappydata-cluster_2.11" % "1.0.0" 

Quand je suis le code debug dans IDE, il fonctionne très bien, mais quand je crée un fichier jar et essayer de l'exécuter directement sur Snappy je reçois un message:

"message": "Ask timed out on [Actor[akka://SnappyLeadJobServer/user/context-supervisor/snappyContext1508488669865777900#1900831413]] after [10000 ms]", 
"errorClass": "akka.pattern.AskTimeoutException", 

J'ai Spark Standalone 2.1.1, SnappyData 1.0.0. J'ai ajouté des dépendances à l'instance Spark.

Pourriez-vous m'aider? Merci à l'avance.

Answer 1

Je pense qu'il manquait des méthodes isValidJob et runSnappyJob. Quand j'ai ajouté ceux au code cela fonctionne, mais connaissez quelqu'un ce qui est releation entre le corps de metod runSnappyJob et la méthode principale

Devrait être la même dans les deux?

Answer 2

La différence entre le mode "intégré" et le mode "connecteur intelligent" doit d'abord être expliquée.

Normalement, lorsque vous exécutez un travail à l'aide de la commande spark-submit, il génère un ensemble de nouvelles machines virtuelles JVM exécutées par configuration pour exécuter le code. Cependant, dans le mode embarqué de SnappyData, les nœuds hébergeant les données hébergent eux-mêmes des Spark Executors de longue durée. Ceci est fait pour minimiser le mouvement des données (c'est-à-dire déplacer l'exécution plutôt que les données). Pour ce mode, vous pouvez soumettre un travail (en utilisant snappy-job.sh) qui exécutera le code sur ces exécuteurs préexistants. Les routes alternatives incluent le JDBC/ODBC pour l'exécution intégrée. Cela signifie également que vous ne pouvez pas (encore) utiliser spark-submit pour exécuter des travaux intégrés car cela générera ses propres JVM. Le mode «connecteur intelligent» est le mode habituel de fonctionnement des autres connecteurs Spark, mais comme tous ceux-ci ont l'inconvénient de devoir extraire les données requises dans les JVM des exécuteurs et seront donc plus lents que le mode embarqué. Pour la configuration, vous devez spécifier la propriété "snappydata.connection" pour pointer vers le serveur d'épargne qui s'exécute sur le localisateur du cluster SnappyData. Il est utile dans de nombreux cas où les utilisateurs souhaitent étendre la capacité d'exécution du cluster (par exemple, si l'exécution intégrée du cluster est saturée tout le temps sur l'UC) ou pour les distributions/déploiements Spark existants. Inutile de dire que spark-submit peut fonctionner en mode connecteur très bien. Ce qui est "intelligent" à propos de ce mode est: a) si les nœuds physiques hébergeant les données et exécutant des exécuteurs sont communs, alors les partitions seront routées vers ces exécuteurs autant que possible pour minimiser l'utilisation du réseau, b) utilisera les plans SnappyData optimisés pour analyser les tables, l'agrégation de hachage, la jointure de hachage. Pour cette question spécifique, la réponse est: runSnappyJob recevra l'objet SnappySession comme argument qui devrait être utilisé plutôt que de le créer. Le reste du corps qui utilise SnappySession sera exactement le même. De même, pour travailler avec SparkContext de base, il pourrait être plus facile d'implémenter SparkJob et le code sera similaire sauf que SparkContext sera fourni comme argument de fonction qui devrait être utilisé. La raison en est comme expliqué ci-dessus: le mode intégré a déjà un SparkContext en cours d'exécution qui doit être utilisé pour les tâches.