anchor.diff:  |gremlin.hadoop.graphOutputFormat |The format that the output file(s) should be represented in.
   |gremlin.hadoop.jarsInDistributedCache |Whether to upload the Hadoop-Gremlin jars to a distributed cache (necessary if jars are not on the machines' classpaths).
   |=========================================================
  +
  +
   
   Along with the properties above, the numerous link:http://hadoop.apache.org/docs/stable/hadoop-project-dist/hadoop-common/core-default.xml[Hadoop specific properties] can be added as needed to tune and parameterize the executed Hadoop-Gremlin job on the respective Hadoop cluster.
   
  
positive.code: The `SparkGraphComputer` algorithm leverages Spark's caching abilities to reduce the amount of data shuffled across the wire on each iteration of the <<vertexprogram,`VertexProgram`>>. When the graph is loaded as a Spark RDD (Resilient Distributed Dataset) it is immediately cached as `graphRDD`. The `graphRDD` is a distributed adjacency list which encodes the vertex, its properties, and all its incident edges. On the first iteration, each vertex (in parallel) is passed through `VertexProgram.execute()`. This yields an output of the vertex's mutated state (i.e. updated compute keys -- `propertyX`) and its outgoing messages. This `viewOutgoingRDD` is then reduced to `viewIncomingRDD` where the outgoing messages are sent to their respective vertices. If a `MessageCombiner` exists for the vertex program, then messages are aggregated locally and globally to ultimately yield one incoming message for the vertex. This reduce sequence is the "message pass." If the vertex program does not terminate on this iteration, then the `viewIncomingRDD` is joined with the cached `graphRDD` and the process continues. When there are no more iterations, there is a final join and the resultant RDD is stripped of its edges and messages. This `mapReduceRDD` is cached and is processed by each <<mapreduce,`MapReduce`>> job in the <<graphcomputer,`GraphComputer`>> computation.
  
  image::spark-algorithm.png[width=775]
  
  IMPORTANT: If the vendor/user wishes to bypass using Hadoop `InputFormats` for pulling data from the underlying graph system, it is possible to leverage Spark's RDD constructs directly. There is a `gremlin.hadoop.graphInputRDD` configuration that references a `Class<? extends InputRDD>`. An `InputRDD` provides a read method that takes a `SparkContext` and returns a graphRDD. Likewise, to bypass `OutputFormat`, use `gremlin.hadoop.graphOutputRDD` and the respective `OutputRDD` with its write-based method.
  
  
negative.code: gremlin.hadoop.graphOutputFormat=org.apache.tinkerpop.gremlin.hadoop.structure.io.gryo.GryoOutputFormat
  gremlin.hadoop.jarsInDistributedCache=true
  ####################################
  # Spark Configuration              #
  ####################################
  spark.master=local[4]
  spark.executor.memory=1g
  spark.serializer=org.apache.tinkerpop.gremlin.spark.structure.io.gryo.GryoSerializer
  ####################################
  # SparkGraphComputer Configuration #
  ####################################
  gremlin.hadoop.graphInputRDD=org.apache.tinkerpop.gremlin.spark.process.computer.io.InputRDDFormat
  gremlin.hadoop.graphOutputRDD=org.apache.tinkerpop.gremlin.spark.process.computer.io.OutputRDDFormat
  gremlin.spark.persistContext=true
  #####################################
  # GiraphGraphComputer Configuration #
  #####################################
  