-
Notifications
You must be signed in to change notification settings - Fork 385
Spark Debugger
Summary: The Spark debugger provides replay debugging for Spark programs. It's currently in development, but you can try it out in the event-log branch.
From a user's point of view, debugging a general distributed program can be tedious and confusing. Many distributed programs are nondeterministic; their outcome depends on the interleaving between computation and message passing across multiple machines. Also, the fact that a program is running on a cluster of hundreds or thousands of machines means that it's hard to understand the program state and pinpoint the location of problems.
In order to tame nondeterminism, a distributed debugger has to log a lot of information, imposing a serious performance penalty on the application being debugged.
But the Spark programming model lets us provide replay debugging for almost zero overhead. Spark programs are a series of RDDs and deterministic transformations, so when debugging a Spark program, we don't have to debug it all at once -- instead, we can debug each transformation individually. Broadly, the debugger lets us do the following two things:
- Recompute and inspect intermediate RDDs after the program has finished.
- Re-run a particular task in a single-threaded debugger to find exactly what went wrong.
At least in theory, debugging a Spark program is now as easy as debugging a single-threaded one.
As your Spark program runs, the slaves report key events back to the master -- for example, RDD creations, RDD contents, and uncaught exceptions. (A full list of event types is in EventLogging.scala.) The master logs those events, and you can load the event log into the debugger after your program is done running.
A note on nondeterminism: For fault recovery, Spark requires RDD transformations (for example, the function passed to RDD.map
) to be deterministic. The Spark debugger also relies on this property, and it can also warn you if your transformation is nondeterministic. This works by checksumming the contents of each RDD and comparing the checksums from the original execution to the checksums after recomputing the RDD in the debugger.
To turn on event logging for your program, set $SPARK_JAVA_OPTS
in conf/spark-env.sh
as follows:
export SPARK_JAVA_OPTS='-Dspark.logging.eventLog=path/to/event-log'
where path/to/event-log
is where you want the event log to go relative to $SPARK_HOME
.
Warning: There's currently no way to disable the collection of performance data, which includes average element processing time and total serialization time. As a result, enabling the event log will probably slow your program down by 50% or so. Once the Spark debugger is released, it'll be possible to disable performance monitoring. Once that happens, overhead will be almost zero.