Die beste Möglichkeit zum Anpassen von JARs in Spark Worker Classpath

Question

Ich arbeite an einer ETL-Pipeline in Spark und ich finde, dass das Drücken einer Freigabe Zeit/Bandbreite intensiv ist. Mein Release Script (Pseudo-Code):

sbt assembly 
openstack object create spark target/scala-2.11/etl-$VERSION-super.jar 
spark-submit \ 
    --class comapplications.WindowsETLElastic \ 
    --master spark://spark-submit.cloud \ 
    --deploy-mode cluster \ 
    --verbose \ 
    --conf "spark.executor.memory=16g" \ 
    "$JAR_URL" 

das funktioniert, kann aber mehr als 4 Minuten in Anspruch nehmen zu montieren und eine Minute zu drücken. Mein build.sbt:

name := "secmon_etl" 

version := "1.2" 

scalaVersion := "2.11.8" 

exportJars := true 

assemblyJarName in assembly := s"${name.value}-${version.value}-super.jar" 

libraryDependencies ++= Seq (
    "org.apache.spark" %% "spark-core" % "2.1.0" % "provided", 
    "org.apache.spark" %% "spark-streaming" % "2.1.0" % "provided", 
    "org.apache.spark" %% "spark-streaming-kafka-0-10" % "2.1.0", 
    "io.spray" %% "spray-json" % "1.3.3", 
// "commons-net" % "commons-net" % "3.5", 
// "org.apache.httpcomponents" % "httpclient" % "4.5.2", 
    "org.elasticsearch" % "elasticsearch-spark-20_2.11" % "5.3.1" 
) 

assemblyMergeStrategy in assembly <<= (assemblyMergeStrategy in assembly) { 
    (old) => { 
    case PathList("META-INF", xs @ _*) => MergeStrategy.discard 
    case x => MergeStrategy.first 
    } 
} 

Die Frage erscheint die schiere Größe der Elasticsearch-Funken 20_2.11 zu sein. Es fügt meinem Uberjar ungefähr 90MB hinzu. Ich würde mich freuen, es in eine provided Abhängigkeit vom Spark-Host zu verwandeln, was es unnötig macht zu packen. Die Frage ist, was ist der beste Weg, das zu tun? Sollte ich nur manuell über JARS kopieren oder gibt es eine idiotensichere Möglichkeit, eine Abhängigkeit anzugeben und ein Werkzeug zu haben, das alle transitiven Abhängigkeiten auflöst?

Answer 1

Ich habe meine Funkenjobs jetzt laufen und viel schneller. Ich lief

sbt assemblyPackageDependency 

die eine riesige Glas erzeugt (110 MB!), Leicht in der Funken platziert Arbeitsverzeichnis ‚Gläser‘ Ordner, so dass jetzt meine Dockerfile für einen Funken Cluster sieht wie folgt aus:

FROM openjdk:8-jre 

ENV SPARK_VERSION 2.1.0 
ENV HADOOP_VERSION hadoop2.7 
ENV SPARK_MASTER_OPTS="-Djava.net.preferIPv4Stack=true" 

RUN apt-get update && apt-get install -y python 

RUN curl -sSLO http://mirrors.ocf.berkeley.edu/apache/spark/spark-$SPARK_VERSION/spark-$SPARK_VERSION-bin-$HADOOP_VERSION.tgz && tar xzfC /spark-$SPARK_VERSION-bin-$HADOOP_VERSION.tgz /usr/share && rm /spark-$SPARK_VERSION-bin-$HADOOP_VERSION.tgz 

# master or worker's webui port, 
EXPOSE 8080 
# master's rest api port 
EXPOSE 7077 

ADD deps.jar /usr/share/spark-$SPARK_VERSION-bin-$HADOOP_VERSION/jars/ 

WORKDIR /usr/share/spark-$SPARK_VERSION-bin-$HADOOP_VERSION 

nach, dass die Konfiguration der Bereitstellung änderte ich meine build.sbt so die kafka-streaming/elasticsearch-spark Gläser und Abhängigkeiten als provided gekennzeichnet sind:

name := "secmon_etl" 

version := "1.2" 

scalaVersion := "2.11.8" 

exportJars := true 

assemblyJarName in assembly := s"${name.value}-${version.value}-super.jar" 

libraryDependencies ++= Seq (
    "org.apache.spark" %% "spark-core" % "2.1.0" % "provided", 
    "org.apache.spark" %% "spark-streaming" % "2.1.0" % "provided", 

    "org.apache.spark" %% "spark-streaming-kafka-0-10" % "2.1.0" % "provided", 
    "io.spray" %% "spray-json" % "1.3.3" % "provided", 
    "org.elasticsearch" % "elasticsearch-spark-20_2.11" % "5.3.1" % "provided" 
) 

assemblyMergeStrategy in assembly <<= (assemblyMergeStrategy in assembly) { 
    (old) => { 
    case PathList("META-INF", xs @ _*) => MergeStrategy.discard 
    case x => MergeStrategy.first 
    } 
} 

meine entfaltet Jetzt in 20 Sekunden durchlaufen!