Graph lecture

An Overview of Graph Data Management and Analysis
M. Tamer ¨Ozsu
University of Waterloo
David R. Cheriton School of Computer Science
© M. Tamer ¨Ozsu Croucher ASI (2015/12/16-18) 1 / 96

Graph Data are Very Common
Internet

Social
networks

Trade volumes
and
connections

Biological
networks

As of September 2011
Music
Brainz
(zitgist)
P20
Turismo
de
Zaragoza
yovisto
Yahoo!
Geo
Planet
YAGO
World
Fact-
book
El
Viajero
Tourism
WordNet
(W3C)
WordNet
(VUA)
VIVO UF
VIVO
Indiana
VIVO
Cornell
VIAF
URI
Burner
Sussex
Reading
Lists
Plymouth
Reading
Lists
UniRef
UniProt
UMBEL
UK Post-
codes
legislation
data.gov.uk
Uberblic
UB
Mann-
heim
TWC LOGD
Twarql
transport
data.gov.
uk
Traffic
Scotland
theses.
fr
Thesau-
rus W
totl.net
Tele-
graphis
TCM
Gene
DIT
Taxon
Concept
Open
Library
(Talis)
tags2con
delicious
t4gm
info
Swedish
Open
Cultural
Heritage
Surge
Radio
Sudoc
STW
RAMEAU
SH
statistics
data.gov.
uk
St.
Andrews
Resource
Lists
ECS
South-
ampton
EPrints
SSW
Thesaur
us
Smart
Link
Slideshare
2RDF
semantic
web.org
Semantic
Tweet
Semantic
XBRL
SW
Dog
Food
Source Code
Ecosystem
Linked Data
US SEC
(rdfabout)
Sears
Scotland
Geo-
graphy
Scotland
Pupils &
Exams
Scholaro-
meter
WordNet
(RKB
Explorer)
Wiki
UN/
LOCODE
Ulm
ECS
(RKB
Explorer)
Roma
RISKS
RESEX
RAE2001
Pisa
OS
OAI
NSF
New-
castle
LAAS
KISTI
JISC
IRIT
IEEE
IBM
Eurécom
ERA
ePrints dotAC
DEPLOY
DBLP
(RKB
Explorer)
Crime
Reports
UK
Course-
ware
CORDIS
(RKB
Explorer)
CiteSeer
Budapest
ACM
riese
Revyu
research
data.gov.
ukRen.
Energy
Genera-
tors
reference
data.gov.
uk
Recht-
spraak.
nl
RDF
ohloh
Last.FM
(rdfize)
RDF
Book
Mashup
Rådata
nå!
PSH
Product
Types
Ontology
Product
DB
PBAC
Poké-
pédia
patents
data.go
v.uk
Ox
Points
Ord-
nance
Survey
Openly
Local
Open
Library
Open
Cyc
Open
Corpo-
rates
Open
Calais
OpenEI
Open
Election
Data
Project
Open
Data
Thesau-
rus
Ontos
News
Portal
OGOLOD
Janus
AMP
Ocean
Drilling
Codices
New
York
Times
NVD
ntnusc
NTU
Resource
Lists
Norwe-
gian
MeSH
NDL
subjects
ndlna
my
Experi-
ment
Italian
Museums
medu-
cator
MARC
Codes
List
Man-
chester
Reading
Lists
Lotico
Weather
Stations
London
Gazette
LOIUS
Linked
Open
Colors
lobid
Resources
lobid
Organi-
sations
LEM
Linked
MDB
LinkedL
CCN
Linked
GeoData
LinkedCT
Linked
User
Feedback
LOV
Linked
Open
Numbers
LODE
Eurostat
(Ontology
Central)
Linked
EDGAR
(Ontology
Central)
Linked
Crunch-
base
lingvoj
Lichfield
Spen-
ding
LIBRIS
Lexvo
LCSH
DBLP
(L3S)
Linked
Sensor Data
(Kno.e.sis)
Klapp-
stuhl-
club
Good-
win
Family
National
Radio-
activity
JP
Jamendo
(DBtune)
Italian
public
schools
ISTAT
Immi-
gration
iServe
IdRef
Sudoc
NSZL
Catalog
Hellenic
PD
Hellenic
FBD
Piedmont
Accomo-
dations
GovTrack
GovWILD
Google
Art
wrapper
gnoss
GESIS
GeoWord
Net
Geo
Species
Geo
Names
Geo
Linked
Data
GEMET
GTAA
STITCH
SIDER
Project
Guten-
berg
Medi
Care
Euro-
stat
(FUB)
EURES
Drug
Bank
Disea-
some
DBLP
(FU
Berlin)
Daily
Med
CORDIS
(FUB)
Freebase
flickr
wrappr
Fishes
of Texas
Finnish
Munici-
palities
ChEMBL
FanHubz
Event
Media
EUTC
Produc-
tions
Eurostat
Europeana
EUNIS
EU
Insti-
tutions
ESD
stan-
dards
EARTh
Enipedia
Popula-
tion (En-
AKTing)
NHS
(En-
AKTing) Mortality
(En-
AKTing)
Energy
(En-
AKTing)
Crime
(En-
AKTing)
CO2
Emission
(En-
AKTing)
EEA
SISVU
educatio
n.data.g
ov.uk
ECS
South-
ampton
ECCO-
TCP
GND
Didactal
ia
DDC Deutsche
Bio-
graphie
data
dcs
Music
Brainz
(DBTune)
Magna-
tune
John
Peel
(DBTune)
Classical
(DB
Tune)
Audio
Scrobbler
(DBTune)
Last.FM
artists
(DBTune)
DB
Tropes
Portu-
guese
DBpedia
dbpedia
lite
Greek
DBpedia
DBpedia
data-
open-
ac-uk
SMC
Journals
Pokedex
Airports
NASA
(Data
Incu-
bator)
Music
Brainz
(Data
Incubator)
Moseley
Folk
Metoffice
Weather
Forecasts
Discogs
(Data
Incubator)
Climbing
data.gov.uk
intervals
Data
Gov.ie
data
bnf.fr
Cornetto
reegle
Chronic-
ling
America
Chem2
Bio2RDF
Calames
business
data.gov.
uk
Bricklink
Brazilian
Poli-
ticians
BNB
UniSTS
UniPath
way
UniParc
Taxono
my
UniProt
(Bio2RDF)
SGD
Reactome
PubMed
Pub
Chem
PRO-
SITE
ProDom
Pfam
PDB
OMIM
MGI
KEGG
Reaction
KEGG
Pathway
KEGG
Glycan
KEGG
Enzyme
KEGG
Drug
KEGG
Com-
pound
InterPro
Homolo
Gene
HGNC
Gene
Ontology
GeneID
Affy-
metrix
bible
ontology
BibBase
FTS
BBC
Wildlife
Finder
BBC
Program
mes BBC
Music
Alpine
Ski
Austria
LOCAH
Amster-
dam
Museum
AGROV
OC
AEMET
US Census
(rdfabout)
Media
Geographic
Publications
Government
Cross-domain
Life sciences
User-generated content
Linked data
Linking Open Data cloud diagram, by Richard Cyganiak and Anja Jentzsch.
http://lod-cloud.net/

Outline
1 Introduction – Graph Types
2 Property Graph Processing
Classiﬁcation
Online querying
Oﬄine analytics
3 RDF Graph Querying
Data Warehousing
Distributed SPARQL Execution
Linked Object Data Querying

Outline
Classiﬁcation
Online querying
Oﬄine analytics
Data Warehousing

Graph Types
Property graph
film 2014
(initial release date, “1980-05-23”)
(label, “The Shining”)
books 0743424425
(rating, 4.7)
offers 0743424425amazonOffer
geo 2635167
(name, “United Kingdom”)
(population, 62348447) actor 29704
(actor name, “Jack Nicholson”)
film 3418
(label, “The Passenger”)
film 1267
(label, “The Last Tycoon”)
director 8476
(director name, “Stanley Kubrick”)
film 2685
(label, “A Clockwork Orange”)
film 424
(label, “Spartacus”)
actor 30013
(relatedBook)
(hasOffer)
(based near)
(actor)
(director) (actor)
(actor) (actor)
(director) (director)

Graph Types
RDF graph
mdb:film/2014
“1980-05-23”
movie:initial release date
“The Shining”
refs:label
bm:books/0743424425
4.7
rev:rating
bm:offers/0743424425amazonOffer
geo:2635167
“United Kingdom”
gn:name
62348447
gn:population
mdb:actor/29704
“Jack Nicholson”
movie:actor name
mdb:film/3418
“The Passenger”
refs:label
mdb:film/1267
“The Last Tycoon”
refs:label
mdb:director/8476
“Stanley Kubrick”
movie:director name
mdb:film/2685
“A Clockwork Orange”
refs:label
mdb:film/424
“Spartacus”
refs:label
mdb:actor/30013
movie:relatedBook
scam:hasOffer
foaf:based near
movie:actor
movie:director
movie:actor
movie:actor movie:actor
movie:director movie:director

Graph Types
Property graph
film 2014
books 0743424425
(rating, 4.7)
geo 2635167
film 3418
film 1267
director 8476
film 2685
film 424
actor 30013
(relatedBook)
(hasOffer)
(based near)
(actor)
(director) (actor)
(actor) (actor)
Workload: Online queries and
analytic workloads
Query execution: Varies
RDF graph
mdb:film/2014
“1980-05-23”
“The Shining”
refs:label
bm:books/0743424425
4.7
rev:rating
geo:2635167
gn:name
62348447
gn:population
mdb:actor/29704
movie:actor name
mdb:film/3418
“The Passenger”
refs:label
mdb:film/1267
refs:label
mdb:director/8476
movie:director name
mdb:film/2685
refs:label
mdb:film/424
“Spartacus”
refs:label
mdb:actor/30013
movie:relatedBook
scam:hasOffer
foaf:based near
movie:actor
movie:director
movie:actor
Workload: SPARQL queries
Query execution: subgraph
matching by homomorphism

Outline
Classiﬁcation
Online querying
Oﬄine analytics
Data Warehousing

Classification [Ammar and Özsu, 2015]
Graph Dynamism
Static
Graphs
Dynamic
Graphs
Streaming
Graphs
Evolving
Graphs
Algorithm Types
Offline Online
Streaming Incremental
Dynamic
Batch
Dynamic
Workload Types
Online
Queries
Analytics
Workloads

Graph Dynamism
Static
Graphs
Dynamic
Graphs
Streaming
Graphs
Evolving
Graphs
Algorithm Types
Oﬄine Online
Dynamic
Batch
Dynamic
Workload Types
Online
Queries
Analytics
Workloads
Focus here is on the
dynamism of the
graphs in whether or
not they change and
how they change.

Graph Dynamism
Static
Graphs
Dynamic
Graphs
Streaming
Graphs
Evolving
Graphs
Algorithm Types
Oﬄine Online
Dynamic
Batch
Dynamic
Workload Types
Online
Queries
Analytics
Workloads
dynamism of the
not they change and
how they change.
how algorithms behave
as their input changes.

Graph Dynamism
Static
Graphs
Dynamic
Graphs
Streaming
Graphs
Evolving
Graphs
Algorithm Types
Oﬄine Online
Dynamic
Batch
Dynamic
Workload Types
Online
Queries
Analytics
Workloads
dynamism of the
not they change and
how they change.
how algorithms behave
as their input changes.
The types of workloads
that the approaches are
designed to handle.

Graph Dynamism
Static
Graphs
Dynamic
Graphs
Streaming
Graphs
Evolving
Graphs
Algorithm Types
Oﬄine Online
Dynamic
Batch
Dynamic
Workload Types
Online
Queries
Analytics
Workloads
Graphs do not
change or we
are not inter-
ested in their
changes – only
a snapshot is
considered.

Graph Dynamism
Static
Graphs
Dynamic
Graphs
Streaming
Graphs
Evolving
Graphs
Algorithm Types
Oﬄine Online
Dynamic
Batch
Dynamic
Workload Types
Online
Queries
Analytics
Workloads
Graphs do not
change or we
are not inter-
ested in their
changes – only
a snapshot is
considered.
Graphs change
and we are
interested in
their changes.

Graph Dynamism
Static
Graphs
Dynamic
Graphs
Streaming
Graphs
Evolving
Graphs
Algorithm Types
Oﬄine Online
Dynamic
Batch
Dynamic
Workload Types
Online
Queries
Analytics
Workloads
Graphs do not
change or we
are not inter-
ested in their
changes – only
a snapshot is
considered.
Graphs change
and we are
interested in
their changes.
Dynamic
graphs with
high veloc-
ity changes –
not possible to
see the entire
graph at once.

Graph Dynamism
Static
Graphs
Dynamic
Graphs
Streaming
Graphs
Evolving
Graphs
Algorithm Types
Oﬄine Online
Dynamic
Batch
Dynamic
Workload Types
Online
Queries
Analytics
Workloads
Graphs do not
change or we
are not inter-
ested in their
changes – only
a snapshot is
considered.
Graphs change
and we are
interested in
their changes.
Dynamic
graphs with
high veloc-
ity changes –
not possible to
see the entire
graph at once.
Dynamic
graphs with un-
known changes
– requires re-
discovery of
the graph (e.g.,
LOD).

Graph Dynamism
Static
Graphs
Dynamic
Graphs
Streaming
Graphs
Evolving
Graphs
Algorithm Types
Oﬄine Online
Dynamic
Batch
Dynamic
Workload Types
Online
Queries
Analytics
Workloads
Computation accesses a
portion of the graph
and the results are
computed for a subset
of vertices; e.g., point-
to-point shortest path,
subgraph matching,
reachability, SPARQL.

Graph Dynamism
Static
Graphs
Dynamic
Graphs
Streaming
Graphs
Evolving
Graphs
Algorithm Types
Oﬄine Online
Dynamic
Batch
Dynamic
Workload Types
Online
Queries
Analytics
Workloads
Computation accesses a
portion of the graph
and the results are
computed for a subset
of vertices; e.g., point-
to-point shortest path,
subgraph matching,
reachability, SPARQL.
Computation accesses
the entire graph and
may require multiple
iterations; e.g., PageR-
ank, clustering, graph
colouring, all pairs
shortest path.

Graph Dynamism
Static
Graphs
Dynamic
Graphs
Streaming
Graphs
Evolving
Graphs
Algorithm Types
Oﬄine Online
Dynamic
Batch
Dynamic
Workload Types
Online
Queries
Analytics
Workloads
Sees the en-
tire input in
advance.

Graph Dynamism
Static
Graphs
Dynamic
Graphs
Streaming
Graphs
Evolving
Graphs
Algorithm Types
Oﬄine Online
Dynamic
Batch
Dynamic
Workload Types
Online
Queries
Analytics
Workloads
Sees the en-
tire input in
advance.
Sees the input
piece-meal as it
executes.

Graph Dynamism
Static
Graphs
Dynamic
Graphs
Streaming
Graphs
Evolving
Graphs
Algorithm Types
Oﬄine Online
Dynamic
Batch
Dynamic
Workload Types
Online
Queries
Analytics
Workloads
Sees the en-
tire input in
advance.
Sees the input
piece-meal as it
executes.
One-pass on-
line algorithm
with limited
memory.

Graph Dynamism
Static
Graphs
Dynamic
Graphs
Streaming
Graphs
Evolving
Graphs
Algorithm Types
Oﬄine Online
Dynamic
Batch
Dynamic
Workload Types
Online
Queries
Analytics
Workloads
Sees the en-
tire input in
advance.
Sees the input
piece-meal as it
executes.
One-pass on-
line algorithm
with limited
memory.
Online algo-
rithm with
some info
about forth-
coming input.

Graph Dynamism
Static
Graphs
Dynamic
Graphs
Streaming
Graphs
Evolving
Graphs
Algorithm Types
Oﬄine Online
Dynamic
Batch
Dynamic
Workload Types
Online
Queries
Analytics
Workloads
Sees the en-
tire input in
advance.
Sees the input
piece-meal as it
executes.
One-pass on-
line algorithm
with limited
memory.
Online algo-
rithm with
some info
about forth-
coming input.
Sees the en-
tire input
in advance,
which may
change; an-
swers computed
as change oc-
curs.

Graph Dynamism
Static
Graphs
Dynamic
Graphs
Streaming
Graphs
Evolving
Graphs
Algorithm Types
Oﬄine Online
Dynamic
Batch
Dynamic
Workload Types
Online
Queries
Analytics
Workloads
Sees the en-
tire input in
advance.
Sees the input
piece-meal as it
executes.
One-pass on-
line algorithm
with limited
memory.
Online algo-
rithm with
some info
about forth-
coming input.
Sees the en-
tire input
in advance,
which may
change; an-
swers computed
as change oc-
curs.
Similar to dy-
namic, but
computation
happens in
batches of

Example Design Points
Graph Dynamism
Static
Graphs
Dynamic
Graphs
Streaming
Graphs
Evolving
Graphs
Algorithm Types
Oﬄine Online
Dynamic
Batch
Dynamic
Workload Types
Online
Queries
Analytics
Workloads
Compute the query result/perform analytic computation over the graph
as it exists.

Graph Dynamism
Static
Graphs
Dynamic
Graphs
Streaming
Graphs
Evolving
Graphs
Algorithm Types
Oﬄine Online
Dynamic
Batch
Dynamic
Workload Types
Online
Queries
Analytics
Workloads
Compute the query result/perform analytic computation over the graph
as it is revealed.

Graph Dynamism
Static
Graphs
Dynamic
Graphs
Streaming
Graphs
Evolving
Graphs
Algorithm Types
Oﬄine Online
Dynamic
Batch
Dynamic
Workload Types
Online
Queries
Analytics
Workloads
Compute the query result/perform analytic computation on each snap-
shot from scratch.

Graph Dynamism
Static
Graphs
Dynamic
Graphs
Streaming
Graphs
Evolving
Graphs
Algorithm Types
Oﬄine Online
Dynamic
Batch
Dynamic
Workload Types
Online
Queries
Analytics
Workloads
Continuously compute the query result/perform analytic computation as
the input changes.

Graph Dynamism
Static
Graphs
Dynamic
Graphs
Streaming
Graphs
Evolving
Graphs
Algorithm Types
Oﬄine Online
Dynamic
Batch
Dynamic
Workload Types
Online
Queries
Analytics
Workloads
Compute the query result/perform analytic computation after a batch of
input changes.

Example Design Points – Not all alternatives make sense
Graph Dynamism
Static
Graphs
Dynamic
Graphs
Streaming
Graphs
Evolving
Graphs
Algorithm Types
Oﬄine Online
Dynamic
Batch
Dynamic
Workload Types
Online
Queries
Analytics
Workloads
Dynamic (or batch-dynamic) algorithms do not make sense for static
graphs.

Graph Processing Systems
System Memory/
Disk
Architecture
Computing
paradigm
Supported
Workloads
Hadoop Disk Parallel/Distributed MapReduce Analytical
Haloop Disk Parallel/Distributed MapReduce Analytical
Pegasus Disk Parallel/Distributed MapReduce Analytical
GraphX Disk Parallel/Distributed
MapReduce
(Spark)
Analytical
Pregel/Giraph Memory Parallel/Distributed Vertex-Centric Analytical
GraphLab Memory Parallel/Distributed Vertex-Centric Analytical
GraphChi Disk Single machine Vertex-Centric Analytical
Stream Disk Single machine Edge-Centric Analytical
Trinity Memory Parallel/Distributed
Flexible using K-V
store on DSM
Online &
Analytical
Titan Disk Parallel/Distributed
K-V store
(Cassandra)
Online
Neo4J Disk Single machine
Procedural/
Linked-list
Online

Graph Workloads
Online graph querying
Reachability
Single source shortest-path
Subgraph matching
SPARQL queries
Oﬄine graph analytics
PageRank
Clustering
Strongly connected
components
Diameter ﬁnding
Graph colouring
All pairs shortest path
Graph pattern mining
Machine learning algorithms
(Belief propagation, Gaussian
non-negative matrix
factorization)

Outline
Classiﬁcation
Online querying
Oﬄine analytics
Data Warehousing

Reachability Queries
film 2014
books 0743424425
(rating, 4.7)
geo 2635167
film 3418
film 1267
director 8476
film 2685
film 424
actor 30013
(relatedBook)
(hasOffer)
(based near)
(actor)
(director) (actor)
(actor) (actor)

film 2014
books 0743424425
(rating, 4.7)
geo 2635167
film 3418
film 1267
director 8476
film 2685
film 424
actor 30013
(relatedBook)
(hasOffer)
(based near)
(actor)
(director) (actor)
(actor) (actor)
Can you reach film 1267 from film 2014?

film 2014
books 0743424425
(rating, 4.7)
geo 2635167
film 3418
film 1267
director 8476
film 2685
film 424
actor 30013
(relatedBook)
(hasOffer)
(based near)
(actor)
(director) (actor)
(actor) (actor)
Is there a book whose rating is > 4.0 associated with a film that was
directed by Stanley Kubrick?

Think of Facebook graph and ﬁnding friends of friends.

Subgraph Matching
?m ?d
movie:director
?name
rdfs:label
?b
movie:relatedBook
movie:director name
?r
rev:rating
FILTER(?r > 4.0)
mdb:film/2014
“1980-05-23”
“The Shining”
refs:label
bm:books/0743424425
4.7
rev:rating
geo:2635167
gn:name
62348447
gn:population
mdb:actor/29704
movie:actor name
mdb:film/3418
“The Passenger”
refs:label
mdb:film/1267
refs:label
mdb:director/8476
movie:director name
mdb:film/2685
refs:label
mdb:film/424
“Spartacus”
refs:label
mdb:actor/30013
movie:relatedBook
scam:hasOffer
foaf:based near
movie:actor
movie:director
movie:actor
Su
bgraphMatching

Outline
Classiﬁcation
Online querying
Oﬄine analytics
Data Warehousing

PageRank Computation
A web page is important if it is pointed to by other important
pages.
P1 P2
P3
P5P6
P4
r(Pi ) =
Pj ∈BPi
r(Pj )
|FPj
|
r(P2) =
r(P1)
2
+
r(P3)
3
rk+1(Pi ) =
Pj ∈BPi
rk(Pj )
|FPj
|
BPi
: in-neighbours of Pi
FPi
: out-neighbours of Pi

PageRank Computation
A web page is important if it is pointed to by other important
pages.
P1 P2
P3
P5P6
P4
rk+1(Pi ) =
Pj ∈BPi
rk(Pj )
|FPj
|
Iteration 0 Iteration 1 Iteration 2
Rank at
Iter. 2
r0(P1) = 1/6 r1(P1) = 1/18 r2(P1) = 1/36 5
r0(P2) = 1/6 r1(P2) = 5/36 r2(P2) = 1/18 4
r0(P3) = 1/6 r1(P3) = 1/12 r2(P3) = 1/36 5
r0(P4) = 1/6 r1(P4) = 1/4 r2(P4) = 17/72 1
r0(P5) = 1/6 r1(P5) = 5/36 r2(P5) = 11/72 3
r0(P6) = 1/6 r1(P6) = 1/6 r2(P6) = 14/72 2
Iterative processing.

Some Alternative Computational Models for Oﬄine
Analytics
Vertex-centric (Scatter-Gather)
Specify (a) computation at each vertex, and (b) communication with
neighbour vertices
Synchronous – Pregel [Malewicz et al., 2010], Giraph
Asynchronous – GraphLab [Low et al., 2012]

Analytics
neighbour vertices
Block-centric
Similar to vertex-centric but on blocks for communication
Connected subgraph of the graph
Blogel [Yan et al., 2014]

Analytics
neighbour vertices
Block-centric
MapReduce
Need to save in HDFS intermediate results of each iteration – both
good and bad
Hadoop, Haloop [Bu et al., 2012]

Analytics
neighbour vertices
Block-centric
MapReduce
Need to save in HDFS intermediate results of each iteration – both
good and bad
Hadoop, Haloop [Bu et al., 2012]
Modiﬁed MapReduce
Based on Spark [Zaharia et al., 2010; Zaharia, 2016]
Keep intermediate states in memory
Provide fault-tolerance by keeping lineage
GraphX [Gonzalez et al., 2014]

Vertex-Centric Computation
“Think like a vertex”
vertex_scatter(vertex v)
Push local computation to
neighbours on the out-bound
edges
vertex_gather(vertex v)
Gather local computation from
neighbours on the in-bound edges
Continue until all vertices are
inactive
?

Vertex-Centric Computation
“Think like a vertex”
vertex_scatter(vertex v)
Push local computation to
neighbours on the out-bound
edges
vertex_gather(vertex v)
Gather local computation from
neighbours on the in-bound edges
Continue until all vertices are
inactive
Vertex state machine
?
Active Inactive
Vote halt
Message received

Synchronous Vertex-Centric Computation
Computation

Superstep 1 Superstep 2 Superstep 3

Machine 1
Machine 2
Machine 3
Communication
Barrier
Each machine performs
vertex-centric computation
on its graph partition

Machine 1
Machine 2
Machine 3
Machine 1
Machine 2
Machine 3
Communication
Barrier
Communication
Barrier

Machine 1
Machine 2
Machine 3
Machine 1
Machine 2
Machine 3
Machine 1
Machine 2
Machine 3
Communication
Barrier
Communication
Barrier

Asynchronous Vertex-Centric Computation
No communication barriers.
Uses the most recent vertex values.
Machine 1
Machine 2
Machine 3
Machine 1
Machine 2
Machine 3

Asynchronous Vertex-Centric Computation
No communication barriers.
Uses the most recent vertex values.
Implemented via distributed locking
Machine 1
Machine 2
Machine 3
Machine 1
Machine 2
Machine 3
v0
v1 v2
v3 v4

Summary of an Experiment [Han et al., 2014]
A large study comparing Giraph, GraphLab, GPS, Mizan.
1 Giraph scales better across graphs;
GraphLab scales better across more machines.

64 machines TW UK
Giraph (byte array) 5.8GB 7.0GB
GraphLab (sync) 4.5GB 14GB
TW 16 machines 128 machines
Giraph (byte array) 8.5GB 5.8GB
GraphLab (sync) 11GB 3.3GB

2 Distributed locking for asynchronous execution is not scalable –
Performance degrades as more machines are used due to lock
contention, termination scheme, lack of message batching

3 Graph storage should be memory and mutation eﬃcient.

No Mutations
Time Memory
Byte array
Hash map
With Mutations (DMST)
Time Memory
Byte array
Hash map

4 Message processing optimizations are very important.

4 Message processing optimizations are very important.
5 Workloads have diﬀerent resource demands
Algorithm CPU Memory Network
PageRank Medium Medium High
SSSP Low Low Low
WCC Low Medium Medium
DMST High High Medium

Block-Centric Computation
Blogel [Yan et al., 2014]: “Think like a block”; also “think like a
graph” [Tian et al., 2013]
Vertex-centric assumes all vertices communicate over the network;
this is not eﬃcient
Read-world graphs have skewed vertex degree distribution
Common in power-law graphs
Problem: imbalanced communication workloads
Real-world graphs have large diameters
Common in road networks, web graphs, terrain meshes
Problem: one superstep per hop ⇒ too many supersteps
Real-world graphs have high average vertex degree
Common in social networks, mobile communication networks
Problem: heavy average communication workloads

Blogel Principles
Exploit the partitioning of the graph
Message exchanges only among blocks
Block: a connected subgraph of the graph
Within a block, run a serial in-memory algorithm; no need to follow a
BSP model

Beneﬁts of Block-Centric Computation
High-degree vertices inside a block send no messages
Fewer number of supersteps
Fewer number of blocks than vertices

Example: Weakly Connected Component
Algorithm exchanges vertex id’s
with neighbours
id(vi ) ← min{vi , vj , . . . , vk}
where vj , . . . , vk are neighbours
of vi
Vertex-centric requires every
vertex sends to its neighbours
until every vertex is reached
Block-centric needs two
iterations:
1 All vertices in partition A
exchange ids; X and Y send
ids to neighbours in partition
B
2 All vertices in partition B
exchange ids
A B
0
X
Y

Block Construction
The partitioning algorithm needs to maximize number of vertices that
have all their edges in the same partition
Hash partitioning is not suitable because many vertices will probably
have at least one cut-edge
URL partitioner
For web graphs: based on domain names of web page nodes
2D partitioner
For spatial networks: based on coordinates of node
Graph Voronoi diagram partitioner
For general graphs

MapReduce Basics [Li et al., 2014]
For data analysis of very large data sets
Highly dynamic, irregular, schemaless, etc.
SQL too heavy
“Embarrassingly parallel problems”
New, simple parallel programming model
Data structured as (key, value) pairs
E.g. (doc-id, content), (word, count), etc.
Functional programming style with two functions to be given:
Map(k1,v1) → list(k2,v2)
Reduce(k2, list (v2)) → list(v3)
Implemented on a distributed ﬁle system (e.g., Google File System)
on very large clusters

MapReduce Processing
...
Inputdataset
Map
Map
Map
Map
(k1, v)
(k2, v)
(k2, v)
(k2, v)
(k1, v)
(k1, v)
(k2, v)
Group by k
Group by k
(k1, (v, v, v))
(k1, (v, v, v, v)) Reduce
Reduce
Outputdataset

MapReduce Architecture
Scheduler
Master
Input Module
Map Module
Combine Module
Partition Module
Map Process
Worker
Input Module
Map Module
Combine Module
Partition Module
Map Process
Worker
Input Module
Map Module
Combine Module
Partition Module
Map Process
Worker
Group Module
Reduce Module
Output Module
Reduce Process
Worker
Group Module
Reduce Module
Output Module
Reduce Process
Worker

Execution Flow with Architecture [Dean and Ghemawat, 2008]
MapReduce: Simplified Data Processing on Large Clusters
split 0
split 1
split 2
split 3
split 4
(1) fork
(3) read
(4) local write
(1) fork
(1) fork
(6) write
worker
worker
worker
Master
User
Program
output
file 0
output
file 1
worker
worker
(2)
assign
map
(2)
assign
reduce
(5) remote
(5) read
Input
files
Map
phasr
Intermediate files
(on local disks)
Reduce
phase
Output
files

Hadoop
Most popular MapReduce implementation – developed by Yahoo!
Two components
Processing engine
HDFS: Hadoop Distributed Storage System – others possible
Can be deployed on the same machine or on diﬀerent machines
Processes
Job tracker: hosted on the master node and implements the schedule
Task tracker: hosted on the worker nodes and accepts tasks from job tracker
and executes them
HDFS
Name node: stores how data are partitioned, monitors the status of data
nodes, and data dictionary
Data node: Stores and manages data chunks assigned to it
Task Tracker Job Tracker Task Tracker
Data Node Name Node Data Node
Worker 1 Name Node Worker n
MapReduce
HDFS

HaLoop [Bu et al., 2012]
Overcome MapReduce shortcomings for iterative jobs
Having to save data in HDFS in between each iteration
Checking the fixpoint requires a new job at each iteration
Scheduler change: assign to the same machine the map reduce
tasks that occur in different iterations but access the same data
Cache invariant data
Cache reduce output to easily check for fixpoint

Spark System
MapReduce does not perform well in iterative computations
Workﬂow model is acyclic
Have to write to HDFS after each iteration and have to read from
HDFS at the beginning of next iteration

Spark System
Spark objectives
Better support for iterative programs
Provide a complete ecosystem
Similar abstraction (to MapReduce) for programming
Maintain MapReduce fault-tolerance and scalability

Spark System
Spark objectives
Better support for iterative programs
Provide a complete ecosystem
Similar abstraction (to MapReduce) for programming
Maintain MapReduce fault-tolerance and scalability
Fundamental concepts
RDD: Reliable Distributed Datasets
Caching of working set
Maintaining lineage for fault-tolerance

Spark Ecosystem [Michiardi, 2015]
Native
Spark
Apps
Spark
SQL
Spark
Streaming
MLlib
(machine
learning)
GraphX
(graph
processing)
Apache Spark

Spark Programming Model [Zaharia et al., 2010, 2012]
HDFS
Create RDD
· · ·
RDD
Cache? Cache
Yes
Transform
RDD?
No
Process
No
Transform
Yes
HDFS

HDFS
Create RDD
· · ·
RDD
Cache? Cache
Yes
Transform
RDD?
No
Process
No
Transform
Yes
HDFS
Each transform generates a
new RDD that may also be
cached or processed

HDFS
Create RDD
· · ·
RDD
Cache? Cache
Yes
Transform
RDD?
No
Process
No
Transform
Yes
HDFS
cached or processed
Created from HDFS or parallelized arrays;
Partitioned across worker machines;
May be made persistent lazily;

HDFS
Create RDD
· · ·
RDD
Cache? Cache
Yes
Transform
RDD?
No
Process
No
Transform
Yes
HDFS
cached or processed
Created from HDFS or parallelized arrays;
Partitioned across worker machines;
May be made persistent lazily;
Processing done on one of the RDDs;
Done in parallel across workers;
First processing on a RDD is from disk;
Subsequent processing of the same RDD from cache

Example – Log Mining [Zaharia et al., 2010, 2012]
Load log messages from a file system, create a new file by filtering the
error messages, read this file into memory, then interactively search for
various patterns
Driver
WorkerWorkerWorker
Block 1 Block 2 Block 3

various patterns
lines = spark.textFile(hdfs://...)
CreateRDD
Driver
WorkerWorkerWorker

various patterns
errors = lines.filter( .startsWith(ERROR))
Transform RDD
Driver
WorkerWorkerWorker

various patterns
messages = errors.map( .split(‘t ’)(2))
Another transform
Driver
WorkerWorkerWorker

various patterns
cachedMsgs = messages.cache()
Cache results
Driver
WorkerWorkerWorker

various patterns
cachedMsgs.filter( .contains(foo)).count
Action
Driver
WorkerWorkerWorker

various patterns
Driver
WorkerWorkerWorker
Tasks

various patterns
Driver
WorkerWorkerWorker
TasksResults

various patterns
Driver
WorkerWorkerWorker
TasksResults
Cache Cache Cache

various patterns
cachedMsgs.filter( .contains(bar)).count
Another Action
accesses cache
Driver
WorkerWorkerWorker
TasksResults
Cache Cache Cache

RDD and Processing
HDFS
lines
Error, msg1
Warn, msg2
Error, msg1
Info, msg8
Warn, msg2
Info, msg8
Error, msg3
Info, msg5
Info, msg5
Error, msg4
Warn, msg9
Error, msg1
errors
Error, msg1
Error, msg1
Error, msg3 Error, msg4
Error, msg1
messages
messages = errors.map .split(‘t ’)(2)
msg1
msg1
msg3 msg4
msg1
Thesearenotyetgenerated

RDD and Processing
lines
errors
messages
msg1
msg1
msg3 msg4
msg1
lines
messages.filter( .contains(foo)).count
errors
messages
msg1
msg1
msg3 msg4
msg1
NowtheRDDsarematerialized;
Commandnotyetexecuted
Driver
messages.filter( .contains(foo)).count

GraphX [Gonzalez et al., 2014]
Built on top of Spark
Objective is to combine data analytics with graph processing
Unify computation on tables and graphs
Carefully convert graph to tabular representation
Native GraphX API or can accommodate vertex-centric computation
Native
Spark
Apps
Spark
SQL
Spark
Streaming
MLlib
(machine
learning)
GraphX
(graph
processing)
Apache Spark
Vertex-
centric API
AppApp
App App

GraphX: Representation of Graphs as Tables
A
B
C
D
E
F
G
H
I
J

Partition 1
Partition 2
A
B
C
D
E
F
G
H
I
J
Edge-disjoint
partitioning

Partition 1
Partition 2
Machine1Machine2
Vertex Table
(RDD)
v-prop:vertex prop.
A
B
C
D
E
F
G
H
I
J
Edge-disjoint
partitioning
A v-prop
B v-prop
...
I v-prop
D v-prop
E v-prop
F v-prop
J v-prop

Partition 1
Partition 2
Machine1Machine2
Vertex Table
(RDD)
v-prop:vertex prop.
Edge Table
(RDD)
e-prop:edge prop.
A
B
C
D
E
F
G
H
I
J
Edge-disjoint
partitioning
A v-prop
B v-prop
...
I v-prop
D v-prop
E v-prop
F v-prop
J v-prop
A e-prop B
A e-prop C
...
F e-prop G
A e-prop D
A e-prop E
...
E e-prop F

Partition 1
Partition 2
Machine1Machine2
Vertex Table
(RDD)
v-prop:vertex prop.
Edge Table
(RDD)
e-prop:edge prop.
A
B
C
D
E
F
G
H
I
J
Edge-disjoint
partitioning
A v-prop
B v-prop
...
I v-prop
D v-prop
E v-prop
F v-prop
J v-prop
A e-prop B
A e-prop C
...
F e-prop G
A e-prop D
A e-prop E
...
E e-prop F
Joining vertices
and edges
Move vertices to edges

Partition 1
Partition 2
Machine1Machine2
Vertex Table
(RDD)
v-prop:vertex prop.
Edge Table
(RDD)
e-prop:edge prop.
Routing
Table
(RDD)
A
B
C
D
E
F
G
H
I
J
Edge-disjoint
partitioning
A v-prop
B v-prop
...
I v-prop
D v-prop
E v-prop
F v-prop
J v-prop
A e-prop B
A e-prop C
...
F e-prop G
A e-prop D
A e-prop E
...
E e-prop F
A 1 2
B 1
...
I 1
F 1 2
D 2
E 2
J 2

GraphX: Computation Model
Machine1Machine2
Vertex Table Edge Table
A v-prop
B v-prop
...
I v-prop
D v-prop
E v-prop
F v-prop
J v-prop
A e-prop B
A e-prop C
...
F e-prop G
A e-prop D
A e-prop E
...
E e-prop F

Machine1Machine2
A v-prop
B v-prop
...
I v-prop
D v-prop
E v-prop
F v-prop
J v-prop
A e-prop B
A e-prop C
...
F e-prop G
A e-prop D
A e-prop E
...
E e-prop F
First Phase: Join
Vertex table Edge table
Triples View
A v-prop e-prop B v-prop
A v-prop e-prop C v-prop
C v-prop e-prop G v-prop
...
E v-prop e-prop G v-prop
J v-prop e-prop G v-prop

Machine1Machine2
A v-prop
B v-prop
...
I v-prop
D v-prop
E v-prop
F v-prop
J v-prop
A e-prop B
A e-prop C
...
F e-prop G
A e-prop D
A e-prop E
...
E e-prop F
Triples View
A v-prop e-prop B v-prop
A v-prop e-prop C v-prop
C v-prop e-prop G v-prop
...
E v-prop e-prop G v-prop
J v-prop e-prop G v-prop
Second Phase: Compute neighbourhood
Group-by aggregate

GraphX: Operators
Table transform operators – inherited from Spark
map(func) Return a new RDD formed by passing each element
of the source through a function func
ﬁlter(func) Return a new RDD formed by selecting those
elements of the source on which func returns true
ﬂatMap(func) Similar to map, but each input item can be mapped
to 0 or more output items
mapPartitions(func) Similar to map, but runs separately on each partition
(block) of the RDD, so func must be of type Iterator
sample(repl, fraction,
seed)
Sample a fraction fraction of the data, with or
without replacement (set repl accordingly), using a
given random number generator seed
union(otherDataset)
intersection()
Return a new RDD containing the union/intersection
of the elements in the source RDD and the argument
groupByKey() Operates on a RDD of (K, V) pairs, returns a RDD
of (K, IterableV) pairs
reduceByKey(func, . . .) Operates on a RDD of (K, V) pairs, returns a RDD
of (K, V) pairs where the values for each key are
aggregated using the given reduce function func

GraphX: Operators
Table transform operators – inherited from Spark
Graph operators
Graph(vertex coll,
edge coll)
Logically binds together a pair of vertex and edge
property collections into a property graph; veriﬁes
that each vertex occurs only once and edges connect
existing vertices
triplets(vertex coll,
vertex coll, edge coll)
Returns the triplets view of the graph
mrTriplets(map,reduce) MapReduce triplets - encodes the two-stage process
of join to create triplets and group by

Outline
Classiﬁcation
Online querying
Oﬄine analytics
Data Warehousing

RDF Introduction
Everything is an uniquely named
resource
http://data.linkedmdb.org/resource/actor/JN29704

RDF Introduction
resource
Preﬁxes can be used to shorten the
names
xmlns:y=http://data.linkedmdb.org/resource/actor/
y:JN29704

RDF Introduction
resource
names
Properties of resources can be deﬁned
y:JN29704
y:JN29704:hasName “Jack Nicholson”
y:JN29704:BornOnDate “1937-04-22”

RDF Introduction
resource
names
Relationships with other resources can
be deﬁned
y:JN29704
y:JN29704:BornOnDate “1937-04-22”
y:TS2014:title “The Shining”
y:TS2014:releaseDate “1980-05-23”
y:TS2014
JN29704:movieActor

RDF Introduction
resource
names
Relationships with other resources can
be deﬁned
Resource descriptions can be
contributed by diﬀerent people/groups
and can be located anywhere in the web
Integrated web “database”
y:JN29704
y:JN29704:BornOnDate “1937-04-22”
y:TS2014:title “The Shining”
y:TS2014:releaseDate “1980-05-23”
y:TS2014
JN29704:movieActor

RDF Data Model
Triple: Subject, Predicate (Property), Object
(s, p, o)
Subject: the entity that is described (URI
or blank node)
Predicate: a feature of the entity (URI)
Object: value of the feature (URI, blank
node or literal)
(s, p, o) ∈ (U ∪ B) × U × (U ∪ B ∪ L)
Set of RDF triples is called an RDF graph
U
Subject Object
U B U B L
U: set of URIs
B: set of blank nodes
L: set of literals
Predicate
Subject Predicate Object
http://...imdb.../ﬁlm/2014 rdfs:label “The Shining”
http://...imdb.../ﬁlm/2014 movie:releaseDate “1980-05-23”
http://...imdb.../29704 movie:actor name “Jack Nicholson”
. . . . . . . . .

RDF Example Instance
Prefixes: mdb=http://data.linkedmdb.org/resource/; geo=http://sws.geonames.org/
bm=http://wifo5-03.informatik.uni-mannheim.de/bookmashup/
lexvo=http://lexvo.org/id/;wp=http://en.wikipedia.org/wiki/
Subject Predicate Object
mdb: film/2014 rdfs:label “The Shining”
mdb:film/2014 movie:initial release date “1980-05-23”’
mdb:film/2014 movie:director mdb:director/8476
mdb:film/2014 movie:actor mdb:actor/29704
mdb:film/2014 movie:actor mdb: actor/30013
mdb:film/2014 movie:music contributor mdb: music contributor/4110
mdb:film/2014 foaf:based near geo:2635167
mdb:film/2014 movie:relatedBook bm:0743424425
mdb:film/2014 movie:language lexvo:iso639-3/eng
mdb:director/8476 movie:director name “Stanley Kubrick”
mdb:film/2685 rdfs:label “A Clockwork Orange”
mdb:film/424 rdfs:label “Spartacus”
mdb:actor/29704 movie:actor name “Jack Nicholson”
mdb:film/1267 rdfs:label “The Last Tycoon”
mdb:film/3418 rdfs:label “The Passenger”
geo:2635167 gn:name “United Kingdom”
geo:2635167 gn:population 62348447
geo:2635167 gn:wikipediaArticle wp:United Kingdom
bm:books/0743424425 dc:creator bm:persons/Stephen+King
bm:books/0743424425 rev:rating 4.7
bm:books/0743424425 scom:hasOffer bm:offers/0743424425amazonOffer
lexvo:iso639-3/eng rdfs:label “English”
lexvo:iso639-3/eng lvont:usedIn lexvo:iso3166/CA
lexvo:iso639-3/eng lvont:usesScript lexvo:script/Latn
URI Literal
URI

RDF Graph
mdb:film/2014
“1980-05-23”
“The Shining”
refs:label
bm:books/0743424425
4.7
rev:rating
geo:2635167
gn:name
62348447
gn:population
mdb:actor/29704
movie:actor name
mdb:film/3418
“The Passenger”
refs:label
mdb:film/1267
refs:label
mdb:director/8476
movie:director name
mdb:film/2685
refs:label
mdb:film/424
“Spartacus”
refs:label
mdb:actor/30013
movie:relatedBook
scam:hasOffer
foaf:based near
movie:actor
movie:director
movie:actor

RDF Query Model – SPARQL
Query Model - SPARQL Protocol and RDF Query Language
Given U (set of URIs), L (set of literals), and V (set of variables), a
SPARQL expression is deﬁned recursively:
an atomic triple pattern, which is an element of
(U ∪ V ) × (U ∪ V ) × (U ∪ V ∪ L)
?x rdfs:label “The Shining”
P FILTER R, where P is a graph pattern expression and R is a built-in
SPARQL condition (i.e., analogous to a SQL predicate)
?x rev:rating ?p FILTER(?p 3.0)
P1 AND/OPT/UNION P2, where P1 and P2 are graph pattern
expressions
Example:
SELECT ?name
WHERE {
?m r d f s : l a b e l ?name . ?m movie : d i r e c t o r ?d .
?d movie : director name ” Stanley Kubrick ” .
?m movie : relatedBook ?b . ?b rev : r a t i n g ? r .
FILTER(? r 4.0)
}

SPARQL Queries
SELECT ?name
WHERE {
FILTER(? r 4.0)
}
?m ?d
movie:director
?name
rdfs:label
?b
movie:relatedBook
movie:director name
?r
rev:rating
FILTER(?r 4.0)

Outline
Classiﬁcation
Online querying
Oﬄine analytics
Data Warehousing

Na¨ıve Triple Store Design
SELECT ?name
WHERE {
FILTER(? r 4.0)
}
Subject Property Object
mdb:ﬁlm/2014 rdfs:label “The Shining”
mdb:ﬁlm/2014 movie:initial release date “1980-05-23”

SELECT ?name
WHERE {
FILTER(? r 4.0)
}
SELECT T1 . o b j e c t
FROM T as T1 , T as T2 , T as T3 ,
T as T4 , T as T5
WHERE T1 . p=” r d f s : l a b e l ”
AND T2 . p=” movie : relatedBook ”
AND T3 . p=” movie : d i r e c t o r ”
AND T4 . p=” rev : r a t i n g ”
AND T5 . p=” movie : d i r e c t o r n a m e ”
AND T1 . s=T2 . s
AND T1 . s=T3 . s
AND T2 . o=T4 . s
AND T3 . o=T5 . s
AND T4 . o 4.0
AND T5 . o=” S t a n l e y Kubrick ”

SELECT ?name
WHERE {
FILTER(? r 4.0)
}
SELECT T1 . o b j e c t
FROM T as T1 , T as T2 , T as T3 ,
T as T4 , T as T5
WHERE T1 . p=” r d f s : l a b e l ”
AND T2 . p=” movie : relatedBook ”
AND T3 . p=” movie : d i r e c t o r ”
AND T4 . p=” rev : r a t i n g ”
AND T5 . p=” movie : d i r e c t o r n a m e ”
AND T1 . s=T2 . s
AND T1 . s=T3 . s
AND T2 . o=T4 . s
AND T3 . o=T5 . s
AND T4 . o 4.0
AND T5 . o=” S t a n l e y Kubrick ”
Easy to implement
but
too many self-joins!

Exhaustive Indexing
RDF-3X [Neumann and Weikum, 2008, 2009], Hexastore [Weiss
et al., 2008]
Strings are mapped to ids using a mapping table
Original triple table
mdb: film/2014 rdfs:label “The Shining”
Encoded triple table
0 1 2
0 3 4
5 6 7
8 9 5
Mapping table
ID Value
0 mdb: film/2014
1 rdfs:label
2 “The Shining”
3 movie:initial release date
4 “1980-05-23”
5 mdb:director/8476
6 movie:director name
7 “Stanley Kubrick”
8 mdb:film/2685
9 movie:director

Exhaustive Indexing
et al., 2008]
Triples are indexed in a clustered B+ tree in lexicographic order
0 1 2
0 3 4
5 6 7
8 9 5
...
...
...
B+ tree
Easy querying
through mapping
table

Exhaustive Indexing
et al., 2008]
Triples are indexed in a clustered B+ tree in lexicographic order
Create indexes for permutations of the three columns: SPO, SOP,
PSO, POS, OPS, OSP
0 1 2
0 3 4
5 6 7
8 9 5
...
...
...
B+ tree
Easy querying
through mapping
table

Exhaustive Indexing–Query Execution
Each triple pattern can be answered by a range query
Joins between triple patterns computed using merge join
Join order is easy due to extensive indexing
0 1 2
0 3 4
5 6 7
8 9 5
...
...
...
ID Value
0 mdb: ﬁlm/2014
1 rdfs:label
2 “The Shining”
4 “1980-05-23”
5 mdb:director/8476
8 mdb:ﬁlm/2685
9 movie:director

0 1 2
0 3 4
5 6 7
8 9 5
...
...
...
ID Value
0 mdb: ﬁlm/2014
1 rdfs:label
2 “The Shining”
4 “1980-05-23”
5 mdb:director/8476
8 mdb:ﬁlm/2685
9 movie:director
Advantages
Eliminates some of the joins – they become range queries
Merge join is easy and fast

0 1 2
0 3 4
5 6 7
8 9 5
...
...
...
ID Value
0 mdb: ﬁlm/2014
1 rdfs:label
2 “The Shining”
4 “1980-05-23”
5 mdb:director/8476
8 mdb:ﬁlm/2685
9 movie:director
Advantages
Eliminates some of the joins – they become range queries
Merge join is easy and fast
Disadvantages
Space usage

Property Tables
Grouping by entities; Jena [Wilkinson, 2006], DB2-RDF [Bornea
et al., 2013]
Clustered property table: group together the properties that tend to
occur in the same (or similar) subjects
Property-class table: cluster the subjects with the same type of
property into one property table
. . . . . . . . .
Subject refs:label movie:director
mob:ﬁlm/2014 “The Shining” mob:director/8476
mob:ﬁlm/2685 “The Clockwork Orange” mob:director/8476
Subject movie:actor name
mdb:actor “Jack Nicholson”

Property Tables
et al., 2013]
. . . . . . . . .
Advantages
Fewer joins
If the data is structured, we have a relational system – similar to
normalized relations

Property Tables
et al., 2013]
. . . . . . . . .
Advantages
Fewer joins
If the data is structured, we have a relational system – similar to
normalized relations
Disadvantages
Potentially a lot of NULLs
Clustering is not trivial
Multi-valued properties are complicated

Binary Tables
Grouping by properties: For each property, build a two-column table,
containing both subject and object, ordered by subjects [Abadi et al.,
2007, 2009]
Also called vertical partitioned tables
n two column tables (n is the number of unique properties in the data)
. . . . . . . . .
Subject Object
mdb:film/2014 mdb:director/8476
movie:director
Subject Object
mob:film/2014 “The Shining”
mob:film/2685 “The Clockwork Orange”
refs:label
Subject Object
mdb:actor/29704 “Jack Nicholson”
movie:actor name

Binary Tables
2007, 2009]
. . . . . . . . .
Subject Object
movie:director
Subject Object
refs:label
Subject Object
movie:actor name
Advantages
Supports multi-valued properties
No NULLs
No clustering
Read only needed attributes (i.e. less I/O)
Good performance for subject-subject joins

Binary Tables
2007, 2009]
. . . . . . . . .
Subject Object
movie:director
Subject Object
refs:label
Subject Object
movie:actor name
Advantages
Supports multi-valued properties
No NULLs
No clustering
Read only needed attributes (i.e. less I/O)
Good performance for subject-subject joins
Disadvantages
Not useful for subject-object joins
Expensive inserts

Graph-based Approach
Answering SPARQL query ≡ subgraph matching using homomorphism
gStore [Zou et al., 2011, 2014], chameleon-db [Alu¸c et al., 2013]
?m ?d
movie:director
?name
rdfs:label
?b
movie:relatedBook
movie:director name
?r
rev:rating
FILTER(?r 4.0)
mdb:film/2014
“1980-05-23”
“The Shining”
refs:label
bm:books/0743424425
4.7
rev:rating
geo:2635167
gn:name
62348447
gn:population
mdb:actor/29704
movie:actor name
mdb:film/3418
“The Passenger”
refs:label
mdb:film/1267
refs:label
mdb:director/8476
movie:director name
mdb:film/2685
refs:label
mdb:film/424
“Spartacus”
refs:label
mdb:actor/30013
movie:relatedBook
scam:hasOffer
foaf:based near
movie:actor
movie:director
movie:actor
Subgraph
M
atching

?m ?d
movie:director
?name
rdfs:label
?b
movie:relatedBook
movie:director name
?r
rev:rating
FILTER(?r 4.0)
mdb:film/2014
“1980-05-23”
“The Shining”
refs:label
bm:books/0743424425
4.7
rev:rating
geo:2635167
gn:name
62348447
gn:population
mdb:actor/29704
movie:actor name
mdb:film/3418
“The Passenger”
refs:label
mdb:film/1267
refs:label
mdb:director/8476
movie:director name
mdb:film/2685
refs:label
mdb:film/424
“Spartacus”
refs:label
mdb:actor/30013
movie:relatedBook
scam:hasOffer
foaf:based near
movie:actor
movie:director
movie:actor
Subgraph
M
atching
Advantages
Maintains the graph structure
Full set of queries can be handled

?m ?d
movie:director
?name
rdfs:label
?b
movie:relatedBook
movie:director name
?r
rev:rating
FILTER(?r 4.0)
mdb:film/2014
“1980-05-23”
“The Shining”
refs:label
bm:books/0743424425
4.7
rev:rating
geo:2635167
gn:name
62348447
gn:population
mdb:actor/29704
movie:actor name
mdb:film/3418
“The Passenger”
refs:label
mdb:film/1267
refs:label
mdb:director/8476
movie:director name
mdb:film/2685
refs:label
mdb:film/424
“Spartacus”
refs:label
mdb:actor/30013
movie:relatedBook
scam:hasOffer
foaf:based near
movie:actor
movie:director
movie:actor
Subgraph
M
atching
Advantages
Maintains the graph structure
Full set of queries can be handled
Disadvantages
Graph pattern matching is expensive

Two Systems
gStoreSystem Architecture
Offline Online
Storage
Input Input
RDF Parser
RDF Graph
Builder
Encoding
Module
VS*-tree
builder
RDF data
RDF Triples
RDF Graph
Signature Graph
Key-Value
Store
VS*-tree
Store
SPARQL
Parser
SPARQL Query
Encoding
Module
VS*-tree
Query Graph
Filter
Module
Join
Module
Signature Graph
Node Candidate
Results
Fig. 4. System Architecture
itstrings, denoted as vS ig(u). We encode query Q with the
ame encoding method. Consequently, the match between Q
nd G can be veriﬁed by simply checking the match between
orresponding encoded bitstrings.
chameleon-db
Structural Index
...
Vertex Index
Spill Index
ClusterIndexStorageSystem
StorageAdvisor
Query
Engine Plan Generation Evaluation

gStore
General Approach:
Work directly on the RDF graph and the SPARQL query graph
Use a signature-based encoding of each entity and class vertex to
speed up matching
Filter-and-evaluate
Use a false positive algorithm to prune nodes and obtain a set of
candidates; then do more detailed evaluation on those
Use an index (VS∗-tree) over the data signature graph (has light
maintenance load) for eﬃcient pruning

1. Encode Q and G to Get Signature Graphs
Query signature graph Q∗
0100 0000 1000 0000
00010
0000 0100
10000
Data signature graph G∗
0010 1000
0100 0001
00001
1000 0001
00010
0000 0100
10000
0000 1000
10000
0000 0010
10000
0000 1001
00100
0001 0001
01000
0100 1000
01000
1001 1000
01000
0001 0100
01000

2. Filter-and-Evaluate
Query signature graph Q∗
0100 0000 1000 0000
00010
0000 0100
10000
Data signature graph G∗
0010 1000
0100 0001
00001
1000 0001
00010
0000 0100
10000
0000 1000
10000
0000 0010
10000
0000 1001
00100
0001 0001
01000
0100 1000
01000
1001 1000
01000
0001 0100
01000
Find matches of Q∗ over
signature graph G∗
Verify each match in
RDF graph G

How to Generate Candidate List
Two step process:
1 For each node of Q∗
get lists of nodes in G∗
that include that node.
2 Do a multi-way join to get the candidate list

Two step process:
Alternatives:

Two step process:
Alternatives:
Sequential scan of G∗
Both steps are ineﬃcient

Two step process:
Alternatives:
Use S-trees
Height-balanced tree over signatures
Run an inclusion query for each node of Q∗
and get lists of nodes in
G∗
• Given query signature q and a set of data signatures S, ﬁnd all
data signatures si ∈ S where qsi = q
Does not support second step – expensive

Two step process:
Alternatives:
Use S-trees
Height-balanced tree over signatures
Run an inclusion query for each node of Q∗
and get lists of nodes in
G∗
• Given query signature q and a set of data signatures S, ﬁnd all
data signatures si ∈ S where qsi = q
Does not support second step – expensive
VS-tree (and VS∗
-tree)
Multi-resolution summary graph based on S-tree
Supports both steps eﬃciently
Grouping by vertices

S-tree Solution
1111 1111
0110 1111 1101 1101
0000 1110 0110 1001 1100 1001 1001 1101
0000 1000
0000 0100 0000 0010
0010 1000
0100 0001
1000 0001
0000 1001
0100 1000
1001 1000
0001 0100
0001 0001
005
004 006
001
002
003
007
011
008
009
010
d1
1
d2
1 d2
2
d3
1 d3
2 d3
3 d3
4
G3
G2
G1
1000 00000100 0000
00010
0000 0100
10000

S-tree Solution
1111 1111
0110 1111 1101 1101
0000 1110 0110 1001 1100 1001 1001 1101
0000 1000
0000 0100 0000 0010
0010 1000
0100 0001
1000 0001
0000 1001
0100 1000
1001 1000
0001 0100
0001 0001
005
004 006
001
002
003
007
011
008
009
010
d1
1
d2
1 d2
2
d3
1 d3
2 d3
3 d3
4
G3
G2
G1
1000 00000100 0000
00010
0000 0100
10000 002
011

S-tree Solution
1111 1111
0110 1111 1101 1101
0000 1110 0110 1001 1100 1001 1001 1101
0000 1000
0000 0100 0000 0010
0010 1000
0100 0001
1000 0001
0000 1001
0100 1000
1001 1000
0001 0100
0001 0001
005
004 006
001
002
003
007
011
008
009
010
d1
1
d2
1 d2
2
d3
1 d3
2 d3
3 d3
4
G3
G2
G1
1000 00000100 0000
00010
0000 0100
10000 002
011
003
008

S-tree Solution
1111 1111
0110 1111 1101 1101
0000 1110 0110 1001 1100 1001 1001 1101
0000 1000
0000 0100 0000 0010
0010 1000
0100 0001
1000 0001
0000 1001
0100 1000
1001 1000
0001 0100
0001 0001
005
004 006
001
002
003
007
011
008
009
010
d1
1
d2
1 d2
2
d3
1 d3
2 d3
3 d3
4
G3
G2
G1
1000 00000100 0000
00010
0000 0100
10000 002
011
003
008
004
009

S-tree Solution
1111 1111
0110 1111 1101 1101
0000 1110 0110 1001 1100 1001 1001 1101
0000 1000
0000 0100 0000 0010
0010 1000
0100 0001
1000 0001
0000 1001
0100 1000
1001 1000
0001 0100
0001 0001
005
004 006
001
002
003
007
011
008
009
010
d1
1
d2
1 d2
2
d3
1 d3
2 d3
3 d3
4
G3
G2
G1
1000 00000100 0000
00010
0000 0100
10000 002
011
003
008
004
009
Possibly large join space!

VS-tree
1111 1111
0110 1111 1101 1101
0000 1110 0110 1001 1100 1001 1001 1101
0000 1000
0000 0100 0000 0010
0010 1000
0100 0001
1000 0001
0000 1001
0100 1000
1001 1000
0001 0100
0001 0001
005
004 006
001
002
003
007
011
008
009
010
d1
1
d2
1 d2
2
d3
1 d3
2 d3
3 d3
4
G3
G2
G1
11101
10010
10001 01100
10000 00001 01100
00010
10000
01000
01000
10000
10000
10000
10000
00010
00100
01000
01000
01000
01000
Super edge

Pruning with VS-Tree
1111 1111
0110 1111 1101 1101
0000 1110 0110 1001 1100 1001 1001 1101
0000 1000
0000 0100 0000 0010
0010 1000
0100 0001
1000 0001
0000 1001
0100 1000
1001 1000
0001 0100
0001 0001
005
004 006
001
002
003
007
011
008
009
010
d1
1
d2
1 d2
2
d3
1 d3
2 d3
3 d3
4
G3
G2
G1
11101
10010
10001 01100
10000 00001 01100
00010
10000
01000
01000
10000
10000
10000
10000
00010
00100
01000
01000
01000
01000
1000 00000100 0000
00010
0000 0100
10000

1111 1111
0110 1111 1101 1101
0000 1110 0110 1001 1100 1001 1001 1101
0000 1000
0000 0100 0000 0010
0010 1000
0100 0001
1000 0001
0000 1001
0100 1000
1001 1000
0001 0100
0001 0001
005
004 006
001
002
003
007
011
008
009
010
d1
1
d2
1 d2
2
d3
1 d3
2 d3
3 d3
4
G3
G2
G1
11101
10010
10001 01100
10000 00001 01100
00010
10000
01000
01000
10000
10000
10000
10000
00010
00100
01000
01000
01000
01000
1000 00000100 0000
00010
0000 0100
10000
d3
2
d3
3
d3
3
d3
4
d3
1
d3
4
G3
00010 10000
01000

1111 1111
0110 1111 1101 1101
0000 1110 0110 1001 1100 1001 1001 1101
0000 1000
0000 0100 0000 0010
0010 1000
0100 0001
1000 0001
0000 1001
0100 1000
1001 1000
0001 0100
0001 0001
005
004 006
001
002
003
007
011
008
009
010
d1
1
d2
1 d2
2
d3
1 d3
2 d3
3 d3
4
G3
G2
G1
11101
10010
10001 01100
10000 00001 01100
00010
10000
01000
01000
10000
10000
10000
10000
00010
00100
01000
01000
01000
01000
1000 00000100 0000
00010
0000 0100
10000
d3
2
d3
3
d3
3
d3
4
d3
1
d3
4
G3
00010 10000
01000
003
008
002
011
004
009

1111 1111
0110 1111 1101 1101
0000 1110 0110 1001 1100 1001 1001 1101
0000 1000
0000 0100 0000 0010
0010 1000
0100 0001
1000 0001
0000 1001
0100 1000
1001 1000
0001 0100
0001 0001
005
004 006
001
002
003
007
011
008
009
010
d1
1
d2
1 d2
2
d3
1 d3
2 d3
3 d3
4
G3
G2
G1
11101
10010
10001 01100
10000 00001 01100
00010
10000
01000
01000
10000
10000
10000
10000
00010
00100
01000
01000
01000
01000
1000 00000100 0000
00010
0000 0100
10000
d3
2
d3
3
d3
3
d3
4
d3
1
d3
4
G3
00010 10000
01000
003
008
002
011
004
009
Reduced join space!

Adaptivity to Workload
Applications that rely on RDF data are increasingly popular and are
more varied [Verborgh et al., 2014]
Data that are being handled are far more heterogeneous [Duan et al.,
2011]
SPARQL queries are becoming more diverse [Arias et al., 2011] and
dynamic [Kirchberg et al., 2011]
An experiment [Alu¸c et al., 2014a]
No single system is a sole winner across all queries
No single system is the sole loser across all queries, either
There can be 2–5 orders of magnitude diﬀerence in the performance
(i.e., query execution time) between the best and the worst system for
a given query
The winner in one query may timeout in another
Performance diﬀerence widens as dataset size increases

2011]
a given query
Can existing systems cope with these trends – workload diversity
dynamism
No! [Alu¸c et al., 2014b]
Fragmented data
Suboptimal pruning by indexes
Unnecessarily large sets of intermediate result tuples

2011]
a given query
Our proposal: Idea behind chameleon-db
When designing and implementing an RDF data management system,
assume nothing about the workload upfront
Organize data dynamically and purely based on the workload

Group-by-Query Approach
v1
v21
A
v21
v20
B
v1
v98
A
v98
v30
C
v1
v250
A
v250
v40
D
v0
v32
A
v0
v52 C
v0
v80
C
v0
v66C
v0
v47
B
v6
v7
A
v6
v8
B
v6
v9
C
C1 C2 C3 C4 C5
Characteristics:
Records are not necessarily of ﬁxed length
Records are not grouped into tables
Records do not necessarily share the same set of RDF predicates
Each record represents a very tiny part of the RDF graph

v1
v21
A
v21
v20
B
v1
v98
A
v98
v30
C
v1
v250
A
v250
v40
D
v0
v32
A
v0
v52 C
v0
v80
C
v0
v66C
v0
v47
B
v6
v7
A
v6
v8
B
v6
v9
C
C1 C2 C3 C4 C5
?x ?y
A
?y ?z
?b
Figure: Query 1

v1
v21
A
v21
v20
B
v1
v98
A
v98
v30
C
v1
v250
A
v250
v40
D
v0
v32
A
v0
v52 C
v0
v80
C
v0
v66C
v0
v47
B
v6
v7
A
v6
v8
B
v6
v9
C
C1 C2 C3 C4 C5
?a
?z
C
?a
?x
A
?a
?y
B
Figure: Query 2

v1
v21
A
v21
v20
B
v1
v98
A
v98
v30
C
v1
v250
A
v250
v40
D
v0
v32
A
v0
v52 C
v0
v80
C
v0
v66C
v0
v47
B
v6
v7
A
v6
v8
B
v6
v9
C
C1 C2 C3 C4 C5
?a
?z
C
?a
?x
A
?a
?y
B
Figure: Query 2
Advantages
Data are physically clustered for the workload
Better pruning by the indexes
Fewer intermediate result tuples

Challenges
Physical Data Layout: As the workloads change, the way data are
grouped together may no longer be suitable
Hierarchical Clustering Algorithm [Alu¸c et al., 2015]
Tunable-LSH [Alu¸c et al., 2015]
Indexing: Indexing upfront is not a choice
Query Evaluation: Can we execute queries eﬃciently even when the
physical layout is constantly changing? [Alu¸c et al., 2015]

chameleon-db
Prototype system [Alu¸c et al., 2013]
35,000 lines of code in C++ under Linux (plus code for SPARQL 1.0
parser)
Structural Index
...
Vertex Index
Spill Index
ClusterIndexStorageSystem
StorageAdvisor
Query
Engine Plan Generation Evaluation

Outline
Classiﬁcation
Online querying
Oﬄine analytics
Data Warehousing

Remember the Environment
Distributed environment
Some of the data sites can
process SPARQL queries –
SPARQL endpoints
Not all data sites can process
queries

SPARQL endpoints
queries
Alternatives

SPARQL endpoints
queries
Alternatives
Data re-distribution + query
decomposition

Graph lecture

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

En vedette

En vedette (12)

Plus de M. Tamer Özsu

Plus de M. Tamer Özsu (6)

Dernier

Dernier (20)

Graph lecture