Kann nicht Jetty der GzipHandler Klasse finden, wenn JUnit gegen SnappyData

Question

läuft

SnappyData v.0-5

Mein Ziel ist es, ein snappydata Treiberprogramm zum Anschluss von bis zu SnappyData in einem Remote-Server ausgeführt werden. Ich habe einen Junit dafür geschrieben. Allerdings, wenn ich es laufen lasse, erhalte ich einen Fehler mit dem SparkContext instanziiert wird:

**java.lang.NoClassDefFoundError: org/eclipse/jetty/server/handler/GzipHandler** 
    at org.apache.spark.ui.JettyUtils$$anonfun$4.apply(JettyUtils.scala:235) 
    at org.apache.spark.ui.JettyUtils$$anonfun$4.apply(JettyUtils.scala:234) 
    at scala.collection.TraversableLike$$anonfun$map$1.apply(TraversableLike.scala:244) 
    at scala.collection.TraversableLike$$anonfun$map$1.apply(TraversableLike.scala:244) 
    at scala.collection.mutable.ResizableArray$class.foreach(ResizableArray.scala:59) 
    at scala.collection.mutable.ArrayBuffer.foreach(ArrayBuffer.scala:47) 
    at scala.collection.TraversableLike$class.map(TraversableLike.scala:244) 
    at scala.collection.AbstractTraversable.map(Traversable.scala:105) 
    at org.apache.spark.ui.JettyUtils$.startJettyServer(JettyUtils.scala:234) 
    at org.apache.spark.ui.WebUI.bind(WebUI.scala:136) 
    at org.apache.spark.SparkContext$$anonfun$13.apply(SparkContext.scala:499) 
    at org.apache.spark.SparkContext$$anonfun$13.apply(SparkContext.scala:499) 
    at scala.Option.foreach(Option.scala:236) 
    at org.apache.spark.SparkContext.<init>(SparkContext.scala:499) 

Meine pom.xml Abhängigkeiten sind:

<dependency> 
     <groupId>io.snappydata</groupId> 
     <artifactId>snappy-core_2.10</artifactId> 
     <version>0.5</version> 
    </dependency> 
    <dependency> 
     <groupId>io.snappydata</groupId> 
     <artifactId>snappy-cluster_2.10</artifactId> 
     <version>0.5</version> 
<dependency> 


@Test 
public void testInsertDataFromCsv() throws Exception { 

    SparkConf conf = new SparkConf(); 
    conf.setMaster("spark://snappy-lead-host:8090"); 
    conf.setAppName("MySparkApp"); 

    SparkContext sc = new SparkContext(conf); 
    SnappyContext snappyContext = new SnappyContext(sc); 

    String fileResource = "data.csv"; 

    DataFrame dataFrame = snappyContext.read() 
      .format("com.databricks.spark.csv").option("header", "true") 
      .option("inferSchema", "true").load(fileResource); 

    JavaRDD<Row> row = dataFrame.javaRDD(); 
    System.out.println(row.toDebugString()); 

    dataFrame.write().insertInto("example_table_col"); 

} 

Answer 1

Ein Hauptmerkmal von SnappyData Cluster ist lang andauernde Funkenzieher (die dieselben wie die Datenspeicher-JVMs selbst sind). Die Absicht des Programms scheint es zu sein, sich mit dem bestehenden Cluster zu verbinden, aber stattdessen wird versucht, eine neue Menge von Executor-JVMs zur Verarbeitung zu starten, so wie Spark normalerweise funktioniert. Der SnappyData-Lead unterstützt diesen Modus nicht, da er vorhandene Datenknoten zur Ausführung wiederverwendet.

Diese Einschränkung in Spark ist aufgrund der Tatsache, dass es nur einen Treiber im Cluster geben kann, der bereits in SnappyData Lead-Knoten ausgeführt wird, und somit keine neuen Treiber erstellt werden können (wir beabsichtigen, diese Einschränkung in einem zu entfernen) zukünftige Veröffentlichung). Eine URL wie "spark://...", die auf den Lead-Knoten verweist, funktioniert nicht. Das Ausführen von Spark-Jobs erfordert eine dieser möglichen Bereitstellungsstrategien (abgesehen von direkter SQL-Übermittlung mit JDBC/ODBC-Clients).

HINWEIS: Für den Embedded-Modus sind snappy-cluster und snappy-core Abhängigkeiten erforderlich, während für andere zwei Modi nur snappy-core als Abhängigkeit hinzugefügt werden sollte.

Ausführung im eingebetteten Modus: Wie bei den JDBC/ODBC-Clients erfolgt die Ausführung in den Datenknoten selbst. Dazu müssen die Jobs über den Job-Server gesendet werden, der auf dem aktiven Lead-Knoten läuft. Das Programm muss SnappySQLJob/JavaSnappySQLJob implementieren und es über die REST API (entweder das mitgelieferte snappy-job.sh Skript oder etwas wie this für in sich abgeschlossene Tests) einreichen. Details hier: http://snappydatainc.github.io/snappydata/jobs/

public Object runJavaJob(SnappyContext snappyContext, Config config) { 
    String fileResource = "data.csv"; 

    DataFrame dataFrame = snappyContext.read() 
      .format("com.databricks.spark.csv").option("header", "true") 
      .option("inferSchema", "true").load(fileResource); 

    dataFrame.write().insertInto("example_table_col"); 

    // for debugging 
    JavaRDD<Row> row = dataFrame.javaRDD(); 
    return row.toDebugString(); 
    // return Boolean.TRUE; 
} 

public JSparkJobValidation isValidJob(SnappyContext snappyContext, 
             Config config) { 
    return new JSparkJobValid(); 
} 

Local Split-Modus: In diesem Modus wird der Ausführungs-Cluster ein Funken local Master ist und somit aus dem snappydata Cluster trennen. Dies führt nicht zu einer guten Leistung, da für die meisten Abfragen viele Daten von den Datenknoten abgerufen werden müssen. Es sollte jedoch am einfachsten für Funktionstests mit kleinen Datenmengen verwendet werden. Verwenden Master als local und setzte snappydata.store.locators Eigenschaft auf die Locator-zu-Punkt (siehe http://snappydatainc.github.io/snappydata/connectingToCluster/ und die Verbindung vor)

@Test 
public void testInsertDataFromCsv() throws Exception { 

    SparkConf conf = new SparkConf(); 
    conf.setMaster("local[*]"); 
    conf.setAppName("MySparkApp"); 
    // below property can also be fetched with 
    // io.snappydata.Property.Locators().apply() 
    conf.set("snappydata.store.locators", "snappy-locator-host:10334"); 

    SparkContext sc = new SparkContext(conf); 
    SnappyContext snappyContext = new SnappyContext(sc); 

    String fileResource = "data.csv"; 

    DataFrame dataFrame = snappyContext.read() 
      .format("com.databricks.spark.csv").option("header", "true") 
      .option("inferSchema", "true").load(fileResource); 

    JavaRDD<Row> row = dataFrame.javaRDD(); 
    System.out.println(row.toDebugString()); 

    dataFrame.write().insertInto("example_table_col"); 
} 

Split-Modus-Ausführungs: schließlich der Ausführungs-Cluster ein normaler Funken/Garn/Mesos Cluster, werden kann, sprechen Sie mit dem snappydata-Cluster als normalen Datenspeicher. So funktionieren Funkenverbindungen für andere Produkte (wie Cassandra-Verbinder, bei denen Cassandra vom Spark-Cluster getrennt ist). Sie kann auf den gleichen Knoten wie der snappydata-Cluster ausgeführt werden, um die beste Leistung zu erzielen, und snappydata wird sich bemühen, sicherzustellen, dass die Ausführung so weitergeleitet wird, dass Daten nur von lokalen Tabellendaten abgerufen oder eingefügt werden. Starten Sie einen separaten Spark-Cluster mit start-all.sh entweder aus der snappydata-Distribution selbst oder Apache Spark 1.6.x (oder einem Yarn/Mesos-Cluster wie in Apache Spark docs). Der Code entspricht dem lokalen Split-Modus, wobei der Master auf den Spark/Yarn/Mesos-Master und nicht auf den Snappydata-Lead zeigt. Weitere Informationen finden Sie unter Verknüpfungen im lokalen Teilungsmodus.