It works on execution graphs that model runtime events and their correlations in distributed systems. In G2, a diagnosis process involves a series of queries, expressed in a high-level declarative language that supports both relational and graph-based operators. Each query is compiled into a distributed execution. G2’s execution engine supports both parallel relational dataprocessing and iterative graph traversal.
Execution graphs in G2 tend to have long paths and are in structure distinctly different from other largescale graphs, such as social or web graphs. Tailoredfor execution graphs and graph traversal operations onthose graphs, G2’s graph engine distinguishes itself byembracing batched asynchronous iterations that allowsfor better parallelism without barriers, and by enabling partition-level states and aggregation.
We have applied G2 to diagnosis of distributed systems such as Berkeley DB, SCOPE/Dryad, and G2 itself to validate its effectiveness. When co-deployed on a 60-machine cluster, G2’s execution engine can handle execution graphs with millions of vertices and edges; for instance, using a query in G2, we traverse, ﬁlter, and summarize a 130 million-vertex graph into a 12 thousand vertex graph within 268 seconds on 60 machines. The use of an asynchronous model and a partition-level interface delivered a 66% reduction in response time when applied to queries in our diagnosis tasks.
Todd Hoff on High Scalability had some thoughts on this tool saying that the main downside would be issues arising from viewing applications as execution graphs when those programs have been written with low level code. But there certainly is an upside: "There are many advantages to this approach, fault diagnosis and performance monitoring are just one of the wins."