Graphyti: A Semi-External Memory Graph Library for FlashGraph

TL;DR

Graphyti is a new semi-external memory graph library that enables efficient processing of large graphs on a single machine by minimizing I/O and memory use, achieving near in-memory performance.

Contribution

It introduces principles for SEM application development and provides an extensible Python library built on FlashGraph for high-performance graph analytics.

Findings

Achieves 80% of in-memory performance in SEM.

Outperforms distributed engines like PowerGraph and Galois.

Built on FlashGraph, available via pip.

Abstract

Graph datasets exceed the in-memory capacity of most standalone machines. Traditionally, graph frameworks have overcome memory limitations through scale-out, distributing computing. Emerging frameworks avoid the network bottleneck of distributed data with Semi-External Memory (SEM) that uses a single multicore node and operates on graphs larger than memory. In SEM, $\mathcal{O}(m)$ data resides on disk and $\mathcal{O}(n)$ data in memory, for a graph with $n$ vertices and $m$ edges. For developers, this adds complexity because they must explicitly encode I/O within applications. We present principles that are critical for application developers to adopt in order to achieve state-of-the-art performance, while minimizing I/O and memory for algorithms in SEM. We present them in Graphyti, an extensible parallel SEM graph library built on FlashGraph and available in Python via pip. In SEM, Graphyti achieves 80% of the performance of in-memory execution and retains the performance of FlashGraph, which outperforms distributed engines, such as PowerGraph and Galois.

Equations

$$R(u)=c\sum _{v\in B_u}\frac{R(v)}{N_v},$$

$$Q=\frac{1}{2m}\sum _{ij}(A_{ij}-\frac{k_i{k}_j}{2m})\delta (c_i,c_j),$$

Full text

††publicationid: pubid:

©2019 IEEE. Personal use of this material is permitted. Permission from IEEE must be obtained for all other uses, in any current or future media, including reprinting/republishing this material for advertising or promotional purposes, creating new collective works, for resale or redistribution to servers or lists, or reuse of any copyrighted component of this work in other works.

1 Introduction

Graphs datasets exceed the in-memory capacity of modern computers. With the advent of multi-core NUMA machines and fast solid state storage, such as NVMe SSDs, developers embraced semi-external memory (SEM) for graph analytics [23, 12, 9, 1, 21] to scale algorithms to problems that exceed memory capacity. Despite their promise, SEM graph engines have experienced relatively low adoption rates, owing to (i) the challenges of programming SEM algorithms, and (ii) limited algorithms in SEM graph libraries.

We address fundamental questions regarding efficient and scalable design of semi-external memory applications within a vertex-centric graph framework. Vertex-centric programs encode algorithms as actions on the vertexes of a graph and achieve parallelism by processing many vertices concurrently. Vertices are activated in a bulk synchronous processing (BSP) step that completes when all vertices are inactive and the framework reaches a global synchronization barrier. We identify core principles through optimizations within Graphyti and demonstrate improved runtime performance. Graphyti provides a high-level language interface to a broad range of popular graph algorithms.

Semi-external memory graph frameworks are an attractive alternative to distributed frameworks, because they avoid the performance penalty from moving data across networks. SEM frameworks [23, 12, 9] deliver large-scale graph processing on limited hardware; they typically exceed the performance of systems with an order of magnitude more processing [5, 13]. As such, understanding how to achieve highly parallel, I/O-minimal applications is critical to SEM adoption. This work describes several popular algorithms in SEM and uses these algorithms as examples of patterns for development of other large-scale graph applications.

The challenge with developing SEM vertex-centric applications is that programmers must explicitly request edge data from disk and maintain $\mathcal{O}(n)$ in-memory state. SEM adds a layer of complexity as developers must now also encode I/O and memory usage. We highlight principles that ease this process for a wide variety of algorithms.

We present principles and techniques that lower the barrier of entry for the vertex-centric SEM applications. We illustrate principles through example applications implemented in an open-source, extensible library—Graphyti. Based on these optimizations, we realize a semi-external memory tool that realizes 80% of the performance of totally in-memory computation, reducing memory consumption by a factor of 20 to 100 of the total graph size.

2 Related Works

Popular graph libraries [4, 6] are flexible, but lack multithreaded support and, thus, scalability. Application development is simple because graph algorithms are invoked as functions against data. Performance optimizations revolve around data structure design. Developers may assume all vertices are in-memory and need not consider I/O.

Distributed frameworks, such as Turi [13] and Mahout [17], scale by processing graphs on multiple nodes across a network. Datasets must fit in the aggregate memory of a cluster. Such frameworks encode parallelism through vertex-centric or edge-centric computing abstractions. Google’s Pregel [15] introduced vertex-centric programming, which has become the prominent abstraction for graph parallelism [13, 16, 8]. Network traffic bottlenecks distributed graph frameworks. Therefore, most optimizations focus on reducing network I/O and do not focus on reducing memory consumption. Distributed frameworks use process-level concurrency and do not take advantage of shared-memory at computing nodes.

Out-of-core graph frameworks [24, 11, 19] minimize memory and maximize scalability by streaming datasets from disk. This comes at a steep performance cost, because each iteration rereads the entire dataset. In contrast, SEM holds $\mathcal{O}(n)$ data in-memory and performs selective I/O to only the edge data that are needed.

Other out-of-core frameworks rely on heavy graph format preprocessing and use custom hardware co-processors [14] or GPUs [7] to improve performance. Libraries in this space must minimize I/O between device and host. The architecture, memory hierarchy and processor density of co-processors differ vastly from that of CPUs. This leads to programming patterns that are distinct from those that accelerate SEM applications on CPUs.

SEM realizes high-performance on a modest amount of commodity hardware and have become the focus of much recent effort [23, 12, 9, 1, 21, 20]. The SEM model offers a rich optimization landscape that includes I/O reduction, caching optimization, I/O prefetching and overlap of computation with asynchronous I/O. The key difference in programming for SEM is that vertexes must explicitly issue I/O requests for edge data. Once requests are fulfilled and data are in memory, activated vertices are processed. Although Graphyti is built on FlashGraph, application optimizations are generic to the SEM model and, thus, could be implemented in other SEM frameworks.

3 Architecture

Graphyti provides python bindings and a C++ library that runs on the FlashGraph engine. FlashGraph builds upon the SAFS userspace file system [22] that performs asynchronous parallel I/O from external memory devices. SAFS is distributed and installed transparently with FlashGraph. Figure 1 shows the C++ FlashGraph programming interface and architecture.

4 Principles

We present six algorithms that demonstrate the principles that are critical to realize state-of-the-art performance for SEM vertex-centric applications. The patterns in these algorithms serve as a blueprint for the developers of other SEM algorithms. Each subsection (4.1 – 4.6) describes an algorithm followed by the vertex-centric, SEM optimizations.

We conduct validation experiments on either the directed or undirected version of the Twitter [10] graph dataset which contains $42$ Million vertices and $1.5$ Billion edges of size $14$ GB. All experiments require no more than $4$ GB of memory of which $2$ GB is used for FlashGraph’s configurable page cache.

4.1 PageRank

PageRank [18] is an iterative algorithm that identifies vertices of high importance in a directed graph. It assigns a higher rank to vertices referenced by other high ranking vertices as follows:

[TABLE]

in which $R(x)$ is the PageRank of vertex $x$, $B_{x}$ is the set of all inward pointing neighbors of vertex $x$, $c$ is a normalization factor, and $N_{x}$ is the number of outward pointing neighbors of vertex $x$. Traditionally, developers adopt the following algorithm for vertex-centric interfaces:

gather in-edge neighbor PageRank values. 2. 2.

compute a vertex’s updated PageRank. 3. 3.

if the updated PageRank value surpasses a predefined threshold, multicast to out-bound neighbors informing them to activate.

We refer to this as the PR-pull algorithm and it is utilized by both Google’s Pregel [15] and Apple’s Turi [13]. In the pull model vertices extract information from their neighbors.

When developing the application for SEM we must prioritize I/O minimization. We instead adopt a push (PR-push) model as follows:

compute a vertex’s PageRank. 2. 2.

if a vertex’s current PageRank exceeds a predefined threshold, multicast its PageRank to its out-bound neighbors.

PR-push demonstrates the principle:

Limit superfluous reads: The key insight is that PR-pull activates vertices and requests data for neighbors whose PageRank has already converged. PR-push instead computes a delta then sends messages only activating the minimal subset of vertices necessary. Vertex activation, processing and the superfluous I/O degrade the performance of PR-pull. Even though PR-push and PR-pull share the same upper bound of messaging complexity ($\mathcal{O}(m^{2})$), PR-push sends fewer messages, reducing I/O and improving performance. Figure 2 demonstrates a reduction of I/O by a factor of $1.8$, and improvement in runtime of $2.2$. Furthermore, PR-push reduces I/O read requests by a factor of nearly $5$. Finally, a reduction in messages leads to reduced burden on FlashGraph to load balance message queues for worker threads.

4.2 Coreness Decomposition

Coreness decomposition extracts a maximal subgraph in which each vertex has at least degree $k_{max}$. The algorithm proceeds by iteratively deleting vertices beginning with those with degree [math] until $k_{max}$. Deleted vertices notify neighboring vertices to reduce their degree until only vertices with a coreness of $\geq k_{max}$ remain. The optimizations we employ to improve the performance of coreness highlight the following core principles:

Minimize messaging: Graphyti’s coreness adopts a hybrid messaging discipline inspired by guided schedulers. In early iterations, almost all vertices modify their degree and inform neighbors of edge and node deletions. During this phase, multicast messages are most efficient. As the graph becomes sparser, multicast messages incur higher overhead because many neighboring vertices with lower coreness values have already been deleted. At this point, point-to-point messages greatly reduces messaging overhead, improving runtime as shown in Figure 3. Graphyti’s coreness maintains a distribution over all remaining vertices to determine when each one should should switch to point-to-point messaging. We empirically determine that once a vertex has $10\%$ of its original degree, point-to-point messaging improves the time necessary to process a single vertex by an order of magnitude.

Algorithmically prune computation: At the completion of a coreness iteration, $k_{i}$, in which $k_{i}<k_{max}$, as stated, the algorithm would proceed to $k_{i+1}$, $k_{i+2}$ and so forth. Graphyti prunes unnecessary $k_{i}$ values by observing the next possible core value is at least $k_{\min(deg(\alpha))}\forall\alpha\in A$, in which $deg$ the degree of a vertex, $\alpha\subset V$ and $V$ is the set of all vertices in the graph. This optimization alone improves performance by an order of magnitude (Figure 3).

4.3 Graph Diameter

Graph diameter for connected graphs is the maximum of the all pairs shortest paths in a graph. Exact graph diameter has complexity $\mathcal{O}(n^{3})$ and is computationally challenging for any framework. Graphyti computes an estimated diameter using a series of breadth-first searches from pseudo-peripheral vertices: ones as close to the extremities of the graph as possible. Optimizing diameter estimation highlights the following guiding principle:

Decouple algorithm development from framework constructs: Diameter estimation provides the opportunity to design a more efficient vertex-centric application. A simple algorithm repeats the following until all reachable vertices are visited:

select a peripheral source vertex. 2. 2.

perform BFS from the selected vertex. 3. 3.

update neighboring vertex distances to one greater than their nearest neighbor in parallel.

This uni-source BFS can be performed multiple times with different source vertices to find larger diameters. Although parallel, this algorithm limits the potential amount of work each vertex performs in a single BFS iteration, limiting CPU cache data reuse, and increasing the relative overhead of synchronization barriers at each BSP step. Uni-source BFS does not reuse edge data that are brought into memory, resulting in increased data stalls as the application becomes heavily I/O bound.

Graphyti rethinks the computation to minimize the overhead of each BSP step by performing concurrent parallel breadth-first searches (Figure 4). This multi-source BFS leads to higher rates of vertex activations within a BSP step and consequently lower global barrier overhead compared with uni-source BFS. Additionally, this reduces cache thrashing, because requested data that are now in-memory have greater opportunity for reuse. In multi-source BFS, each vertex holds a bitmap indicating which BFS path(s) it is on. Figure 5(b) demonstrates the performance improvements and I/O reduction induced by these optimizations.

4.4 Betweenness Centrality (BC)

Betweenness centrality measures the importance of a vertex in a network by computing the number of shortest paths in which a vertex participates. The most efficient algorithm to compute betweenness centrality [3] is an iterative algorithm with computation complexity $O(nm+n^{2}\log n)$, for weighted graphs.

Betweenness centrality has three phases per iteration, (i) breadth-first search (BFS) from a source vertex (ii) backward propagation (BP), and (iii) an accumulation phase (ACC). We derive the following principles:

Develop asynchronous applications: Graphyti adopts a multi-source betweenness centrality strategy, similar to that of the graph diameter. The existence of 3 phases, provides the opportunity for further optimization. Eliminating phase synchrony for the multiple sources improves parallel efficiency. Vertex activation messages now contain metadata for both the current path(s) and the current phase(s).

Graphyti’s betweenness application separates algorithmic design from the innate BSP paradigm within all vertex-centric frameworks. Asynchronous design improves runtime by over $10\%$ when compared with just multi-source and $40\%$ when compared to uni-source at $32$ sources (Figure 6). Multi-source asynchronous betweenness centrality reduces the amount of data brought from disk by a factor of $4$ when $32$ concurrent searches are performed.

Utilize functional constructs: Vertex-centric frameworks provide abstractions over threads that are accessible to developers. Each partition thread in FlashGraph is a mechanism to represent contention-free structures. As such, associative operations such as functional reductions (e.g., max, min, sum etc.) are naturally supported without resource contention. The BFS phase, computes a global per-source-vertex max. The ACC phase, computes a global per-source-vertex add. Both phases utilize this optimization.

4.5 Triangle Counting

Triangle counting is a topological structure discovery algorithm that finds pairs of vertices that share a common neighbor. When performed in SEM, the complexity is $\mathcal{O}(n^{3})$. The fundamental task finds the intersection of the adjacency lists of neighboring vertices to discover triangles. Each vertex requests its neighbor’s adjacency lists and computes when the list is available in the page cache. We discount alternative implementations in which the state of a vertex can exceed the size of its own edge list and that of one other neighbor because they would violate the SEM limited memory usage guarantee.

Optimize in-memory operations: Once data has been brought into memory it is essential to not only reuse cached data, but perform in-memory optimizations. The following accelerates the intersection search operation:

• •

Store adjacency lists in sorted order. This allows the implementation to choose between binary search and sequential scans when appropriate.

• •

Store the adjacency list of a vertex with degree higher than a certain threshold in a hash table to improve lookup performance.

• •

Perform a restarted binary search in the event an element is not found. A restarted binary search looks for the next item using the end point of the previous search.

• •

Order the adjacency list enumeration appropriately. This choice will lead to either forward or reverse traversal of edge lists being more efficient. In our case, reverse iteration leads to an improvement of $1.7X$ in search. This is because the discovery of triangles is performed by higher degree vertices leading to fewer requests for edge lists of lower degree vertices.

Figure 7 displays the improvement from each of the in-memory optimizations. After all optimizations are applied, Graphyti’s triangle counting performs two orders of magnitude faster on average.

4.6 Louvain Modularity

Louvain modularity [2] is an agglomerative community detection algorithm that maximizes the density of edges within communities and minimizes those outside. Modularity for any pair of communities $i$ and $j$ is computed as:

[TABLE]

in which $m$ is the sum of all graph edge weights, $A_{ij}$ is the edge weight between $v_{i}$ and $v_{j}$, $k_{i}$ and $k_{j}$ are the weighted sum of edges between $v_{i}$ and $v_{j}$, $\delta$ is a function that differentiates one community from the next.

We start with the most popular two phase, greedy approximation algorithm [2]. Exact solutions are computationally infeasible for large networks. A vertex changes community to another that contains the maximum positive modularity among neighboring communities.

This algorithm poses challenges for SEM frameworks because it modifies the graph structure. Modification is extremely expensive, because edge data need to be rewritten on disk. We adopt the following principle:

Avoid graph structure modification: Modifying the graph is prohibitively expensive. In fact, for SEM applications, modification can easily surpass the algorithmic runtime, because disk write throughput is orders of magnitude slower than memory throughput. We demonstrate this in Figure 8(b). Accordingly, we circumvent modification through (i) lazy deletion and (ii) vertex nomination of a community representative. We maintain a partitioned bitmap with lookups for deleted vertices in addition to an index for vertex-to-community lookups. This ensures all messages are appropriately routed to the correct vertex without involving the graph engine or requiring messages to be forwarded.

Figure 8(b) shows the “best-case scenario” for an SEM implementation that physically modifies the graph. We maintain a RAMDisk in fast DDR$4$ to hold the new physical state of the graph. Graphyti’s louvain performs twice as fast as this best case (Figure 8(a)). We trade-off graph structure modification with metadata updates and messaging. Naturally, as the algorithm progresses to deeper levels, more vertices merge, resulting in fewer clusters. This reduces the cost of traditional graph modification, while conversely increasing the overhead of messaging and metadata maintenance for Graphyti’s louvain. Accordingly, Graphyti’s louvain design capitalizes most during early levels to attain its performance gains.

5 Software

Graphyti is an open source library available through Python’s pip package manager under the name graphyti. To extend the library, developers can visit

https://github.com/flashxio/graphyti. Furthermore, we provide Docker integration for developers to reduce the barrier to entry.

6 Conclusions

We present key principles that are critical to state-of-the-art performance for vertex-centric, semi-external-memory graph algorithms. Example applications within Graphyti illustrate the positive performance effects of adopting these principles. Finally, we improve the accessibility of SEM graph applications for users by providing a high-level Python interface to Graphyti.

Acknowledgments

This work is supported by DARPA GRAPHS N66001-14-1-4028, DARPA SIMPLEX N66001-15-C-4041, and by NSF ACI-1649880.