Table of Contents
Fetching ...

Exploring the Landscape of Distributed Graph Sketching

David Tench, Evan T. West, Kenny Zhang, Michael Bender, Daniel DeLayo, Martin Farach-Colton, Gilvir Gill, Tyler Seip, Victor Zhang

TL;DR

This paper presents Landscape, a distributed graph-stream processing system that uses linear sketching to distribute the CPU work of computing graph properties to distributed workers with no need for worker-to-worker communication, and overcomes the CPU and network bottlenecks that limit other systems.

Abstract

Recent work has initiated the study of dense graph processing using graph sketching methods, which drastically reduce space costs by lossily compressing information about the input graph. In this paper, we explore the strange and surprising performance landscape of sketching algorithms. We highlight both their surprising advantages for processing dense graphs that were previously prohibitively expensive to study, as well as the current limitations of the technique. Most notably, we show how sketching can avoid bottlenecks that limit conventional graph processing methods. Single-machine streaming graph processing systems are typically bottlenecked by CPU performance, and distributed graph processing systems are typically bottlenecked by network latency. We present Landscape, a distributed graph-stream processing system that uses linear sketching to distribute the CPU work of computing graph properties to distributed workers with no need for worker-to-worker communication. As a result, it overcomes the CPU and network bottlenecks that limit other systems. In fact, for the connected components problem, Landscape achieves a stream ingestion rate one-fourth that of maximum sustained RAM bandwidth, and is four times faster than random access RAM bandwidth. Additionally, we prove that for any sequence of graph updates and queries Landscape consumes at most a constant factor more network bandwidth than is required to receive the input stream. We show that this system can ingest up to 332 million stream updates per second on a graph with $2^{17}$ vertices. We show that it scales well with more distributed compute power: given a cluster of 40 distributed worker machines, it can ingest updates 35 times as fast as with 1 distributed worker machine. Landscape uses heuristics to reduce its query latency by up to four orders of magnitude over the prior state of the art.

Exploring the Landscape of Distributed Graph Sketching

TL;DR

This paper presents Landscape, a distributed graph-stream processing system that uses linear sketching to distribute the CPU work of computing graph properties to distributed workers with no need for worker-to-worker communication, and overcomes the CPU and network bottlenecks that limit other systems.

Abstract

Recent work has initiated the study of dense graph processing using graph sketching methods, which drastically reduce space costs by lossily compressing information about the input graph. In this paper, we explore the strange and surprising performance landscape of sketching algorithms. We highlight both their surprising advantages for processing dense graphs that were previously prohibitively expensive to study, as well as the current limitations of the technique. Most notably, we show how sketching can avoid bottlenecks that limit conventional graph processing methods. Single-machine streaming graph processing systems are typically bottlenecked by CPU performance, and distributed graph processing systems are typically bottlenecked by network latency. We present Landscape, a distributed graph-stream processing system that uses linear sketching to distribute the CPU work of computing graph properties to distributed workers with no need for worker-to-worker communication. As a result, it overcomes the CPU and network bottlenecks that limit other systems. In fact, for the connected components problem, Landscape achieves a stream ingestion rate one-fourth that of maximum sustained RAM bandwidth, and is four times faster than random access RAM bandwidth. Additionally, we prove that for any sequence of graph updates and queries Landscape consumes at most a constant factor more network bandwidth than is required to receive the input stream. We show that this system can ingest up to 332 million stream updates per second on a graph with vertices. We show that it scales well with more distributed compute power: given a cluster of 40 distributed worker machines, it can ingest updates 35 times as fast as with 1 distributed worker machine. Landscape uses heuristics to reduce its query latency by up to four orders of magnitude over the prior state of the art.

Paper Structure

This paper contains 75 sections, 9 theorems, 3 equations, 18 figures, 6 tables.

Key Result

Theorem 4.1

(Adapted from l0sketch, Theorem 1): Given a 2-wise independent hash family $\mathcal{F}$ and an input vector $x \in \mathbb{Z}^n$, there is an $\ell_0$-sampler using $O(\log^2(n)\log(1/\delta))$ space that succeeds with probability at least $1 - \delta$.

Figures (18)

  • Figure 1: Graphs studied in academic works exhibit a selection effect. Any point to the left of the dark line indicates a dataset which can be represented as an adjacency list in 16GB of RAM.
  • Figure 2: Data flow diagram for Landscape's ingestion algorithm. Connectivity information from the input stream is compressed into the graph sketch and added to GreedyCC.
  • Figure 3: Landscape ingestion rate scales to one-fourth of sequential RAM bandwidth.
  • Figure 4: CameoSketch and pipeline hypertree are vital for good ingestion performance. Without CameoSketch, Landscape's ingestion rate scales slowly as the number of threads increases. Without pipeline hypertree, the system bottlenecks at slightly over 100 million updates/sec.
  • Figure 5: GreedyCC dramatically decreases query latency.
  • ...and 13 more figures

Theorems & Definitions (10)

  • Claim 1: Dense graph processing
  • Theorem 4.1
  • Theorem 4.2
  • Theorem 4.3
  • Theorem 5.1: Distributed cost.
  • Theorem 5.2: k-connectivity.
  • Lemma H .1
  • Lemma H .2
  • Lemma H .3
  • Lemma H .4