Graft: a Debugging Tool for Apache Giraph
Total Page：16
File Type：pdf, Size：1020Kb
Graft: A Debugging Tool For Apache Giraph Semih Salihoglu, Jaeho Shin, Vikesh Khanna, Ba Quan Truong, Jennifer Widom Stanford University {semih, jaeho.shin, vikesh, bqtruong, widom}@cs.stanford.edu ABSTRACT optional master.compute() function is executed by the Master We address the problem of debugging programs written for Pregel- task between supersteps. like systems. After interviewing Giraph and GPS users, we devel- We have tackled the challenge of debugging programs written oped Graft. Graft supports the debugging cycle that users typically for Pregel-like systems. Despite being a core component of pro- go through: (1) Users describe programmatically the set of vertices grammers’ development cycles, very little work has been done on they are interested in inspecting. During execution, Graft captures debugging in these systems. We interviewed several Giraph and the context information of these vertices across supersteps. (2) Us- GPS programmers (hereafter referred to as “users”) and studied vertex.compute() ing Graft’s GUI, users visualize how the values and messages of the how they currently debug their functions. captured vertices change from superstep to superstep,narrowing in We found that the following three steps were common across users: suspicious vertices and supersteps. (3) Users replay the exact lines (1) Users add print statements to their code to capture information of the vertex.compute() function that executed for the sus- about a select set of potentially “buggy” vertices, e.g., vertices that picious vertices and supersteps, by copying code that Graft gener- are assigned incorrect values, send incorrect messages, or throw ates into their development environments’ line-by-line debuggers. exceptions. The captured set of vertices is typically quite small, Graft also has features to construct end-to-end tests for Giraph pro- sometimes containing as little as a single vertex with its neighbors, grams. Graft is open-source and fully integrated into Apache Gi- because it is slow to log, and difficult to inspect the information raph’s main code base. of a large number of vertices. (2) Then, users inspect the captured vertex information and mentally “replay” their graph algorithms 1. INTRODUCTION superstep by superstep, until they narrow in on the most suspicious The Pregel distributed graph-processing engine [18] and its open vertices and supersteps. (3) Finally, they return to their code and source versions, such as Apache Giraph [7], Apache Hama [11], try to identify the part of vertex.compute() that must have and GPS [24], are being adopted by a growing number of applica- executed on the suspicious vertices and supersteps, hoping to find tions for processing large-scale graphs. For example, Facebook is the bug. using Apache Giraph in production for its Graph Search applica- Based on our observations, we designed and developed Graft, a tion [22] and its recommendation algorithms, and PayPal is using new replay-style debugger that is tailored specifically for the needs Giraph for fraud detection and user credit risk [27]. Like MapRe- of Giraph users. Existing replay debuggers, e.g. [2, 6], capture and duce [3] and Hadoop [10] for record-oriented data, Pregel-like sys- replay all low-level system calls made by a distributed application, tems offer transparent scalability, automatic fault-tolerance, and a such as memory reads and writes to the network drivers, which are simple programming interface based around implementing a small usually not relevant for diagnosing bugs inside vertex.compu- set of functions. te() functions. They also do not provide any replay functionality The computational framework introduced by Pregel is based on specific to Pregel’s vertex-centric graph computations. Graft’s ap- the Bulk Synchronous Parallel (BSP) computation model [28]. At proach is motivated by the three manual steps we observed in users’ the beginning of the computation, the vertices of the graph are dis- current debugging cycles, which we call capture, visualize, and re- tributed across Worker tasks running on different compute nodes. produce, respectively: Computation is broken down into iterations called supersteps, and • Capture: Users describe programmatically which vertices they all workers synchronize at the end of each superstep. Algorithms are interested in capturing (details in Section 3.1). Graft cap- are implemented in a vertex-centric fashion inside a vertex.com- tures the entire context information for these vertices, across all pute() function, which gets called on each vertex exactly once supersteps or a user-defined selection of supersteps. It is ex- in every superstep. Inside vertex.compute(), vertices receive pected that the selected set of vertices will be relatively small, messages from the previous superstep, update their local values, and the rich API encourages applying selective criteria. and send messages to other vertices. In Giraph [7] and GPS [24], an • Visualize: Graft includes a graph-specific and superstep-based visual interface for users to replay the algorithm’s effects on the vertices whose contexts have been captured. Users can see how the values and messages of these vertices change from super- step to superstep, narrowing in on suspicious values, messages, or exceptions. • Reproduce: The last step involves code inspection, for which we rely on the user’s integrated development environment (IDE), . such as Eclipse [4] or IntelliJ [12]. The context that Graft cap- Apache Giraph Cluster 1 public class RWDebugConfig { … 2 public int numRandomVerticesToCapture() { return 5; } Machine1 Machine2 Machinen 3 public boolean captureNeighborsOfVertices () { return true ; } … 4 public boolean messageValueConstraint(Message msg, ID srcID, Instrumented 5 ID dstID, int superstep ) { return msg.value ≥ 0; }} HDFS trace files of captured ver<ces & master Program reproduce visualize capture Figure 2: A DebugConfig file. Context Gra GUI GRAFT Reproducer Graph Visualizer Instrumenter are broadcast to the vertices and also decide to terminate the - Generate JUnit test - Play supersteps computation. When algorithms are comprised of a sequence of code reproducing - See vertex contexts Debug Config vertex/master contexts - Browse msg/vertex • Vertex IDs different vertex-centric computations, the master.compute() constraints, excep<ons • Message/vertex function is typically used to coordinate phases. Make Unit/End-to-End Test value constraints - From actual run or scratch Original Giraph Program: compute() methods 3. THE GRAFT DEBUGGING TOOL Programmer Using Gra Figure 1 gives an overview of Graft’s architecture. In the fol- • Submits original Giraph program and DebugConfig to Gra lowing subsections we explain the architecture and components in • Visualizes captured ver<ces through Gra GUI • Copies Junit test reproducing vertex context to local IDE for terms of the capture, visualize, and reproduce functionalities they step-by-step debugging on local machine implement. Figure 1: Graft architecture. 3.1 Capture: The DebugConfig File and Graft tures is sufficient to generate code that can reproduce exactly Instrumenter those lines of vertex.compute() that executed for a spe- Users extend and implement a DebugConfig class to spec- cific vertex and superstep. The user copies this code into the ify the vertices they are interested in capturing. Users can instruct IDE and uses its line-by-line debugger. The code that Graft Graft to capture all vertices in five categories: (1) vertices specified generates is a unit test file, which the user may wish to turn into by their IDs, and optionally their neighbors; (2) a random set of a a real unit test case for his vertex.compute() function. given number of vertices, and optionally their neighbors; (3) ver- Graft similarly helps users debug their master.compute() func- tices that violate a specified constraint on vertex values; (4) vertices tions. that send a message value that violates a specified constraint; and In our demo, we will show how Graft is used effectively under (5) vertices that raise exceptions. Alternatively, a user may spec- several different debugging scenarios (see Section 4), with low run- ify that all active vertices should be captured. Users can also limit time overhead and small log files. Graft is fully implemented and in which supersteps Graft captures vertices; by default Graft cap- integrated into Giraph’s official code base [7]. tures vertices in each superstep. For example, the DebugConfig shown in Figure 2 instructs Graft to capture 5 random vertices 2. BACKGROUND: GIRAPH API and their neighbors, and all vertices that send negative-valued mes- The Giraph API consists of the four classes that were described sages, across all supersteps. in the original API of Pregel, and an optional Master class, which The Graft Instrumenter takes as input the user’s DebugConfig was introduced by GPS [24]. For the purposes of describing Graft, file and vertex.compute() function. It uses Javassist [15] to the important components are: wrap the vertex.compute() around a new instrumented one, • vertex.compute(): Users subclass the Vertex class and which is the final program that is submitted to Giraph. When Gi- code the vertex-centric logic of the computation by implement- raph calls compute() on the instrumented code of a vertex v, the ing the vertex.compute() function. Inside vertex.- code calls the user’s original vertex.compute() function, in- compute(), a vertex has access to five pieces of data: (1) the tercepting messages and value updates so it can check constraints. vertex ID; (2) its outgoing edges; (3) its incoming messages; After the user’s vertex.compute() function returns, the in- (4) a set of aggregators (see below); and (5) default global strumented function checks whether v should be captured: (1) if v data consisting of the current superstep number and the total is in one of the five possible categories of DebugConfig (above); number of vertices and edges in the graph. Each vertex also has or (2) if the user instructed Graft to capture all active vertices. To an active/inactive flag; a vertex declares itself inactive by call- capture v, the instrumented code logs the context of v, along with ing the voteToHalt() function in the API.