link discovery tutorial part i: efficiency

Link Discovery TutorialPart I: Efficiency

Axel-Cyrille Ngonga Ngomo(1), Irini Fundulaki(2), Mohamed Sherif(1)

(1) Institute for Applied Informatics, Germany(2) FORTH, Greece

October 18th, 2016Kobe, Japan

Ngonga Ngomo et al. (InfAI & FORTH) LD Tutorial: Efficiency October 17, 2016 1 / 106

Table of Contents

1 Introduction

2 LIMES

3 MultiBlock

4 Reduction-Ratio-Optimal Link Discovery

5 Link Discovery for Temporal Data

6 GNOME

7 GPUs and Hadoop

8 Summary and Conclusion

Table of Contents

1 Introduction

2 LIMES

3 MultiBlock

6 GNOME

7 GPUs and Hadoop

IntroductionLink Discovery

Definition (Declarative Link Discovery)Given sets S and T of resources and relation RFind M = (s, t) ∈ S × T : R(s, t)Here, find M ′ = (s, t) ∈ S × T : δ(s, t) ≥ τ

ProblemNaïve complexity ∈ O(S × T ), i.e., O(n2)Example: ≈ 70 days for cities in DBpedia and LinkedGeoData

Solutions1 Reduce the number of comparisons C(A) ≥ |M ′| [NA11; IJB11; Ngo12;

Ngo13]2 Use planning [Ngo14]3 Reduce the complexity of linking to < n2 [GSN16]4 Use features of hardware environment [Ngo+13; NH16]

Table of Contents

1 Introduction

2 LIMES

3 MultiBlock

6 GNOME

7 GPUs and Hadoop

LIMESIntuition

Some δ are distances (in the mathematical sense) [NA11]Examples

Levenshtein distanceMinkowski distance

IntuitionDistances abide by triangle inequalityδ(x , z) + δ(z , y) ≤ δ(x , y) ≤ δ(x , z) + δ(z , y)Use exemplars for pessimistic approximationReduce number of computations

LIMESIntuition

Some δ are distances (in the mathematical sense) [NA11]Examples

Levenshtein distanceMinkowski distance

IntuitionDistances abide by triangle inequalityδ(x , z) + δ(z , y) ≤ δ(x , y) ≤ δ(x , z) + δ(z , y)Use exemplars for pessimistic approximationReduce number of computations

LIMESApproach

1 Start with random e1 ∈ T

2 en+1 = argmaxx∈T

n∑i=1

δ(x , ei )

3 Assign each t to e(t) with e(t) = argminei

δ(t, ei )

4 Approximate δ(s, t) by using δ(s, t) ≥ δ(s, e(t))− δ(e(t), t)

LIMESApproach

2 en+1 = argmaxx∈T

n∑i=1

δ(x , ei )

LIMESApproach

3 Assign each t to e(t) with e(t) = argminei

δ(t, ei )

LIMESApproach

4 Approximate δ(s, t) by using δ(s, t) ≥ δ(s, e(t))− δ(e(t), t)

LIMESEvaluation

Measure = LevenshteinThreshold = 0.9, KB base size = 103

x-axis is number of exemplars, y-axis is number of comparisons

0 50 100 150 200 250 300

Brute force

LIMESEvaluation

Measure = LevenshteinThreshold = 0.9, KB base size = 104

x-axis is number of exemplars, y-axis is number of comparisonsOptimal number of examplars ≈

√|T |

0 50 100 150 200 250 300

Brute force

LIMESConclusion

Time-efficent approachReduces number of comparisons through approximationNo guarantee pertaining to reduction ratio

Table of Contents

1 Introduction

2 LIMES

3 MultiBlock

6 GNOME

7 GPUs and Hadoop

MultiBlockIntuition

IdeaCreate multidimensional index of dataPartition the space so that σ(x , y) < θ ⇒ index(x) 6= index(y)Decrease number of computations by only comparing pairs (x , y) withindex(x) = index(y)

MultiBlockIntuition

IdeaCreate multidimensional index of dataPartition the space so that σ(x , y) < θ ⇒ index(x) 6= index(y)Decrease number of computations by only comparing pairs (x , y) withindex(x) = index(y)

MultiBlockApproach

Similarity functions are aggregations of atomic measures sim, e.g.,σ = MIN(levenshtein, jaccard)Each atomic measure must define a blocking functionblock : (S ∪ T )× [0, 1]→ P(Nn)Each aggregation must define a similarity, a block and a thresholdaggregation

MultiBlockExample

sim = levenshtein(s,t)max(|s|,|t|) (normalized levenshtein)

block : Σq → NMaps each q-gram to exactly one block (e.g., Goedelisation)Only c = max(|s|, |t|)(1− θ) · q + 1 q-grams to be indexed per string

index(s, θ) = block(qgrams(s[0...c])String mapped to several blocksComparison only within blocks

Comparison of drugs in DBpedia and Drugbank

Setting Comparisons Runtime LinksFull comparison 22,242,292 430s 1,403Blocking (100 blocks) 906,314 44s 1,349Blocking (1,000 blocks) 322,573 14s 1,287MultiBlock 122,630 6s 1,403

MultiBlockExample

sim = levenshtein(s,t)max(|s|,|t|) (normalized levenshtein)

block : Σq → NMaps each q-gram to exactly one block (e.g., Goedelisation)Only c = max(|s|, |t|)(1− θ) · q + 1 q-grams to be indexed per string

index(s, θ) = block(qgrams(s[0...c])String mapped to several blocksComparison only within blocks

Comparison of drugs in DBpedia and Drugbank

Setting Comparisons Runtime LinksFull comparison 22,242,292 430s 1,403Blocking (100 blocks) 906,314 44s 1,349Blocking (1,000 blocks) 322,573 14s 1,287MultiBlock 122,630 6s 1,403

Table of Contents

1 Introduction

2 LIMES

3 MultiBlock

6 GNOME

7 GPUs and Hadoop

Link Discovery

Intuition: Reduce the number of comparisons C(A) ≥ |M ′|Maximize reduction ratio:

RR(A) = 1− C(A)|S||T |

QuestionCan we devise lossless approaches with guaranteed RR?Advantages

Space managementRuntime predictionResource scheduling

Link Discovery

RR(A) = 1− C(A)|S||T |

Link Discovery

RR(A) = 1− C(A)|S||T |

RR Guarantee

Best achievable reduction ratio: RRmax = 1− |M′||S||T |

Approach H(α) fulfills RR guarantee criterion, iff:

∀r < RRmax,∃α : RR(H(α)) ≥ r

Here, we use relative reduction ratio (RRR):

RRR(A) = RRmaxRR(A)

RR Guarantee

RRR(A) = RRmaxRR(A)

RR Guarantee

RRR(A) = RRmaxRR(A)

Formal GoalDevise H(α) : ∀r > 1,∃α : RRR(H(α)) ≤ r

Restrictions

Minkowski Distance

δ(s, t) = p

√√√√ n∑i=1|si − ti |p, p ≥ 2

Space Tiling

HYPPOδ(s, t) ≤ θ describes a hypersphereApproximate hypersphere by using a hypercube

Easy to computeNo loss of recall (blocking)

Space Tiling

Set width of single hypercube to ∆ = θ/α

Tile Ω = S ∪ T into the adjacent cubes CCoordinates: (c1, . . . , cn) ∈ Nn

Contains points ω ∈ Ω : ∀i ∈ 1 . . . n, ci ∆ ≤ ωi < (ci + 1)∆

Space Tiling

Set width of single hypercube to ∆ = θ/αTile Ω = S ∪ T into the adjacent cubes C

Coordinates: (c1, . . . , cn) ∈ Nn

Space Tiling

Set width of single hypercube to ∆ = θ/αTile Ω = S ∪ T into the adjacent cubes C

Coordinates: (c1, . . . , cn) ∈ Nn

HYPPOIdea

Combine (2α + 1)n hypercubes around C(ω) to approximate hypersphere

RRR(HYPPO(α)) = (2α+1)n

αnS(n)

limα→∞

RRR(HYPPO(α)) = 2n

HYPPOReduction Ratio

RRR(HYPPO) for p = 2, n = 2, 3, 4 and 2 ≤ α ≤ 50

limα→∞

RRR(HYPPO(α)) = 4π ≈ 1.27 (n = 2)

limα→∞

RRR(HYPPO(α)) = 6π ≈ 1.91 (n = 3)

limα→∞

RRR(HYPPO(α)) = 32π2 ≈ 3.24 (n = 4)

HYPPOReduction Ratio

RRR(HYPPO) for p = 2, n = 2, 3, 4 and 2 ≤ α ≤ 50

limα→∞

RRR(HYPPO(α)) = 4π ≈ 1.27 (n = 2)

limα→∞

RRR(HYPPO(α)) = 6π ≈ 1.91 (n = 3)

limα→∞

RRR(HYPPO(α)) = 32π2 ≈ 3.24 (n = 4)

index(C , ω) =

0 if ∃i : |ci − c(ω)i | ≤ 1, 1 ≤ i ≤ n,n∑

i=1(|ci − c(ω)i | − 1)p else,

Compare C(ω) with C iff index(C , ω) ≤ αp

α = 4, p = 2

ClaimsNo loss of recalllimα→∞

RRR(HR3(α)) = 1

Lemma 1

Lemmaindex(C , s) = x ⇒ ∀t ∈ C δp(s, t) > x∆p

p = 2, n = 2, index(C , s) = 5

Lemma 1

p = 2, n = 2, index(C , s) = 5

Lemma 1

Proof.

index(C , s) = x ⇒n∑

i=1(|ci − ci (s)| − 1)p = x

Out of definition of cube index follows |si − ti | > (|ci − ci (s)| − 1)∆

Thus,n∑

i=1|si − ti |p >

n∑i=1

(|ci − ci (s)| − 1)p∆p

Therewith, δp(s, t) > x∆p

Lemma 2

∀s ∈ S : index(C , s) > αp implies that all t ∈ C are non-matches

Proof.Follows directly from Lemma 1:index(C , s) > αp ⇒ ∀t ∈ C , δp(s, t) > ∆pαp = θp

Claims

No loss of recallXlimα→∞

RRR(HR3(α)) = 1

Lemma 3

Lemma∀α > 1 RRR(HR3(2α)) < RRR(HR3(α))

p = 2, α = 4

Proof (idea)

∀α > 1 RRR(HR3(2α)) < RRR(HR3(α))

p = 2, α = 8

p = 2, α = 25

p = 2, α = 50

Theorem

limα→∞

RRR(HR3(α)) = 1

Proof.α→∞⇒ ∆→ 0Thus, C(s) = s,C = t

Index function :n∑

i=1∆p(|ci (s)− ci | − 1)p ≤ ∆pαp

∆→ 0⇒n∑

i=1|si − ti |p ≤ θp

Claims

No loss of recallXlimα→∞

RRR(HR3(α)) = 1X

Evaluation

Compare HR3 with LIMES 0.5’s HYPPO and SILK 2.5.1Experimental Setup:

Deduplicating DBpedia places by minimum elevation, elevation and maximumelevation (θ = 49m, 99m).Geonames and LinkedGeoData by longitude and latitude (θ = 1, 9)

Windows 7 Enterprise machine 64-bit computer with a 2.8GHz i7 processorwith 8GB RAM.

Evaluation (Comparisons)

Experiment 2: Deduplicating DBpedia places, θ = 99m0.64× 106 less comparisons

Experiments (Comparisons)

Experiment 4: Linking Geonames and LinkedGedData, θ = 94.3× 106 less comparisons

Experiments (RRR)

Experiment 3,4: Geonames and LGD, θ = 1, 9

Experiments (Runtime)

Experiment 3,4: Geonames and LGD, θ = 1, 9

2 4 8 16 32

Granularity

HYPPO (Exp 3)HR3 (Exp 3)HYPPO (Exp. 4)HR3 (Exp. 4)

Experiments (Runtime)

Experiment 1, 2: DBpedia, θ = 49, 99mExperiment 3, 4: Geonames and LGD, θ = 1, 9

Exp. 1 Exp. 2 Exp. 3 Exp. 4100

HR3HYPPOSILK

Conclusion

Main result: new category of algorithms for link discoveryOutperforms the state of the art (runtime, comparisons)Future Work

Combine HR3 with multi-indexing approachDevise resource management approachDevelop other algorithms (esp. for strings) with the same/similar theoreticalguarantees

Table of Contents

1 Introduction

2 LIMES

3 MultiBlock

6 GNOME

7 GPUs and Hadoop

AEGLEWhy?

:E1 rdfs:label "Engine failure"@en:E1 rdf:type :Error:E1 :beginDate :"2015-04-22T11:39:35":E1 :endDate :"2015-04-22T11:39:37"

:E2 rdfs:label "Car accident"@en:E2 rdf:type :Accident:E2 :beginDate :"2015-06-28T11:45:22":E2 :endDate :"2015-06-28T11:45:24"

Need to create links between events, e.g., :startsEvent

Need to deal with volume and velocity

AEGLEEvent Definition

Definition (Event)Events can be modeled as time intervals: v = (b(v), e(v))

b(v) is the beginning time (:beginDate)e(v) is the end time (:endDate)b(v) < e(v)

AEGLEAllen’s Interval Algebra

Relation Notation Inverse Illustration

X before Y bf (X ,Y ) bfi(X ,Y )

X meets Y m(X ,Y ) mi(X ,Y )

X finishes Y f (X ,Y ) fi(X ,Y )

X starts Y st(X ,Y ) sti(X ,Y )

X during Y d(X ,Y ) di(X ,Y )

X equal Y eq(X ,Y ) eq(X ,Y )

X overlaps with Y ov(X ,Y ) ovi(X ,Y )

AEGLESolution

Aegle: Allen’s intErval alGebra for LinkdiscovEry

Efficient computation of temporalrelations between eventsAllen’s Interval Algebra: distinct,exhaustive, and qualitative relationsbetween time intervalsIntuition

Expressing 13 Allen relationsusing 8 atomic relationsTime is ordered: Find matchingentities using two sorted lists

AEGLEExpress st(s, t) using atomic relations

tb(s) = b(t)

tb(s) < e(t)

tb(s) = b(t)

tb(s) < e(t)

te(s) > b(t)

tb(s) = b(t)

tb(s) < e(t)

te(s) > b(t)

te(s) < e(t)

AEGLEAtomic relations

Compute 8 atomic Boolean relations between begin and end pointsBeginBegin (BB) for b(s), b(t):

BB1(s, t) ⇔ (b(s) < b(t))BB0(s, t) ⇔ (b(s) = b(t))BB−1(s, t) ⇔ (b(s) > b(t)) ⇔ ¬(BB1(s, t) ∨ BB0(s, t))

BeginEnd(BE) for b(s), e(t)EndBegin(EB) for e(s), b(t)EndEnd(EE) for e(s), e(t)

AEGLECombination of relations

tst(s, t)⇔ BB0(s, t) ∧ BE 1(s, t) ∧ EB−1(s, t) ∧ EE 1(s, t) ⇔ BB0(s, t) ∧ EE 1(s, t)

ssti(s, t)⇔ BB0(s, t) ∧ BE 1(s, t) ∧ EB−1(s, t) ∧ EE−1(s, t) ⇔

BB0(s, t) ∧ EE−1(s, t) = BB0(s, t) ∧¬(EE 0(s, t)∨ EE 1(s, t))

AEGLEAlgorithm for st, sti

Source

Targett1

For st:Compute BB0:

s1 s2 t1 t2

(s1, t1), (s2, t1)

Compute EE 1:(s1, t1), (s2, t1), (s1, t2)

Intersection between BB0 and EE 1:(s1, t1), (s2, t1)

Source

Targett1

For st:

Compute BB0:

s1 s2 t1 t2

(s1, t1), (s2, t1)

Source

Targett1

For st:Compute BB0:

s1 s2 t1 t2

(s1, t1), (s2, t1)

Source

Targett1

For st:Compute BB0:

s1 s2 t1 t2

(s1, t1), (s2, t1)

Compute EE 1:

s1 s2 t1 t2

(s1, t1), (s2, t1), (s1, t2)

Source

Targett1

For st:Compute BB0:

s1 s2 t1 t2

(s1, t1), (s2, t1)

Compute EE 1:

s1 s2 t1 t2

(s1, t1), (s2, t1), (s1, t2)

Source

Targett1

For st:Compute BB0:

s1 s2 t1 t2

(s1, t1), (s2, t1)

Compute EE 1:

s1 s2 t1 t2

(s1, t1), (s2, t1), (s1, t2)

Source

Targett1

For sti :

Retrieve BB0 and EE 1:Compute EE 0:

s1 s2 t1 t2

(s2, t2)

Union between EE 0 and EE 1:(s1, t1), (s2, t1), (s2, t1), (s2, t2)

Difference between BB0 and EE 0, EE 1:(s1, t2), (s2, t2)

Source

Targett1

For sti :Retrieve BB0 and EE 1:

Compute EE 0:

s1 s2 t1 t2

(s2, t2)

Source

Targett1

For sti :Retrieve BB0 and EE 1:Compute EE 0:

s1 s2 t1 t2

(s2, t2)

Source

Targett1

s1 s2 t1 t2

(s2, t2)

Source

Targett1

s1 s2 t1 t2

(s2, t2)

AEGLEExperimental Set-Up

Datasets: S = TLog Type Dataset name Size Unique b(s) Unique e(s)

Machinery3KMachines 3,154 960 96030KMachines 28,869 960 960300KMachines 288,690 960 960

Query3KQueries 3,888 3,636 3,63830KQueries 30,635 3,070 3,070300KQueries 303,991 184 184

State-of-the-art:Silk extended to deal with spatio-temporal dataBaseline for eq using brute-force

Evaluation measures:atomic runtime of each of the atomic relationsrelation runtime required to compute each Allen’s relationtotal runtime required to compute all 13 relations

AEGLEResults

Q1: Does the reduction of Allen relations to 8 atomic relations influence theoverall runtime of the approach?

AEGLEResults

Q1: Does the reduction of Allen relations to 8 atomic relations influence theoverall runtime of the approach?

AEGLEResults

Q2: How does Aegle perform when compared with the state of the art interms of time efficiency?

Log Type Dataset Name Total RuntimeAegle Aegle * Silk

Machine3KMachines 11.26 5.51 294.0030KMachines 1,016.21 437.79 29,846.00

300KMachines 189,442.16 78,416.61 NA

Query3KQueries 26.94 17.91 541.00

30KQueries 988.78 463.27 33,502.00300KQueries 211,996.88 86,884.98 NA

AEGLEResults

Machine QueryRelation Approach 3KMachines 30KMachines 300KMachines 3KQueries 30KQueries 300KQueries

m Aegle 0.02 0.19 3.42 0.02 0.21 3.89Silk 23.00 2,219.00 NA 41.00 2,466.00 NA

eqAegle 0.05 0.79 49.84 0.05 0.45 348.51

Silk 23.00 2,250.00 NA 41.00 2,473.00 NAbaseline 2.05 171.10 23,436.30 3.15 196.09 31,452.54

ovi Aegle 3.16 222.27 38,226.32 11.97 257.59 42,121.68Silk 22.00 2,189.00 NA 42.00 2,503.00 NA

ConclusionAegle = efficient temporal linking

Reduction of 13 Allen Interval relations to 8 atomic relationsEfficiency: simple sorting with complexity O(n log n)Scalable LD

Table of Contents

1 Introduction

2 LIMES

3 MultiBlock

6 GNOME

7 GPUs and Hadoop

GnomeProblem

What if ...Data does not fit memory C , i.e.,|S|+ |T | > |C |

1 Common problem2 Growing size and number of

datasets≈ 150× 109 triples≈ 10× 103 datasetsLargest dataset with> 20× 109triples

3 Mostly in-memory solutions

GnomeIdea

InsightMost approaches rely on divide-and-merge paradigmExample: HR3

σ(s, t) ≥ θ ⇔ δ(s, t) ≤ ∆

GnomeIdea

InsightMost approaches rely on divide-and-merge paradigmExample: HR3

σ(s, t) ≥ θ ⇔ δ(s, t) ≤ ∆

GnomeFormal Model

1 Define S = S1, . . . ,Sn with Si ⊆ S ∧⋃iSi = S

2 Define T = T1, . . . ,Sm with Tj ⊆ T ∧⋃jTj = T

3 Find mapping function µ : S → 2T withelements of Si only compared with elements of sets in µ(Si )union of results over all Si ∈ S is exactly M′.

GnomeFormal Model

GNOMETask Graph

DefinitionA task Eij stands for comparing Si with Tj ∈ µ(Si )

Task Graph G = (V ,E ,wv ,we), withV = S ∪ Twv (v) = |V |we(eij ) = |Si ||Tj |

GNOMETask Graph

DefinitionA task Eij stands for comparing Si with Tj ∈ µ(Si )Task Graph G = (V ,E ,wv ,we), with

V = S ∪ Twv (v) = |V |we(eij ) = |Si ||Tj |

GNOMETask Graph

GNOMEProblem Reformulation

Locality maximizationTwo-step approach:

1 Clustering: Find groups of nodes that fit in memory and2 Scheduling: Compute sequence of groups that minimizes hard drive access

GNOMEStep1: Clustering

Naïve ApproachCluster by Si

Example: |C | = 7

Greedy ApproachStart by largest taskAdd connected largest tasks until none fits in C

Example: |C | = 7

GNOMEStep2: Scheduling

InsightsOutput of clustering: Sequence G1, . . . ,GN of clustersIntuition: Consecutive clusters should share dataGoal: Maximize overlap of generated sequence

Overlap o(Gi ,Gj) =∑

v∈V (Gi )∩V (Gj )|v |

o(G4, G1) = 4

Overlap o(G1, . . . ,GN) =N−1∑i=1

o(Gi ,Gi+1)

o(G4, G1, G2, G1) = 9

v∈V (Gi )∩V (Gj )|v |

o(G4, G1) = 4

Overlap o(G1, . . . ,GN) =N−1∑i=1

o(Gi ,Gi+1)

o(G4, G1, G2, G1) = 9

v∈V (Gi )∩V (Gj )|v |

o(G4, G1) = 4

Overlap o(G1, . . . ,GN) =N−1∑i=1

o(Gi ,Gi+1)

o(G4, G1, G2, G1) = 9

Best-EffortSelect random pair of clustersIf permutation improves overlap, then permuteRelies on local knowledge for scalability

Trick:

∆(Gi ,Gj) = (o(Gi−1,Gj) + o(Gj ,Gi+1) + o(Gj−1,Gi ) + o(Gi ,Gj+1))−(o(Gi−1,Gi ) + o(Gi ,Gi+1) + o(Gj−1,Gj) + o(Gj ,Gj+1))

G3 G1 G2 G40 3 2

G4 G1 G2 G34 3 2

Best-EffortSelect random pair of clustersIf permutation improves overlap, then permuteRelies on local knowledge for scalability

Trick:

∆(Gi ,Gj) = (o(Gi−1,Gj) + o(Gj ,Gi+1) + o(Gj−1,Gi ) + o(Gi ,Gj+1))−(o(Gi−1,Gi ) + o(Gi ,Gi+1) + o(Gj−1,Gj) + o(Gj ,Gj+1))

G3 G1 G2 G40 3 2

G4 G1 G2 G34 3 2

GreedyStart with random clusterChoose next cluster with largest overlapGlobal knowledge needed

G3 G1 G2 G40 3 2

G3 G2 G1 G42 3 4

GreedyStart with random clusterChoose next cluster with largest overlapGlobal knowledge needed

G3 G1 G2 G40 3 2

G3 G2 G1 G42 3 4

GNOMEExperimental Setup

Datasets1 DBP: 1 million labels from DBpedia

version 04-20152 LGD: 0.8 million places from

LinkedGeoDataHardware

1 Intel Xeon E5-2650 v3 processors(2.30GHz)

2 Ubuntu 14.04.3 LTS3 10GB RAM

Measures1 Total runtime2 Hit ratio

GNOMEEvaluation of Clustering

Only show results of LGDResults on DBP lead to similar insights

Runtimes Hit Ratio|C | Naive Greedy Naive Greedy100 568.0 646.3 0.57 0.77200 518.3 594.0 0.66 0.80400 532.0 593.3 0.67 0.80

1,000 5,974.0 118,454.7 0.51 0.642,000 6,168.0 115,450.0 0.51 0.634,000 7,118.3 121,901.7 0.50 0.63

Conclusion1 Naïve approach is more efficient2 Greedy approach is more effective3 Select naïve approach for clustering

GNOMEEvaluation of Clustering

Runtimes Hit Ratio|C | Naive Greedy Naive Greedy100 568.0 646.3 0.57 0.77200 518.3 594.0 0.66 0.80400 532.0 593.3 0.67 0.80

1,000 5,974.0 118,454.7 0.51 0.642,000 6,168.0 115,450.0 0.51 0.634,000 7,118.3 121,901.7 0.50 0.63

Conclusion1 Naïve approach is more efficient2 Greedy approach is more effective3 Select naïve approach for clustering

GNOMEEvaluation of Scheduling

Runtimes (ms) Hit ratio|C | Best-Effort Greedy Best-Effort Greedy100 571.3 1,599.3 0.56 0.68200 565.7 1,448.3 0.66 0.85400 581.0 1,379.3 0.67 0.88

1,000 5,666.0 814,271.7 0.51 0.862,000 6,268.0 810,855.0 0.51 0.864,000 6,675.7 814,041.7 0.50 0.86

Conclusion1 Best-effort approach more time-efficient2 Greedy more effective3 Best-effort approach is to be used for scheduling

GNOMEEvaluation of Scheduling

Runtimes (ms) Hit ratio|C | Best-Effort Greedy Best-Effort Greedy100 571.3 1,599.3 0.56 0.68200 565.7 1,448.3 0.66 0.85400 581.0 1,379.3 0.67 0.88

1,000 5,666.0 814,271.7 0.51 0.862,000 6,268.0 810,855.0 0.51 0.864,000 6,675.7 814,041.7 0.50 0.86

Conclusion1 Best-effort approach more time-efficient2 Greedy more effective3 Best-effort approach is to be used for scheduling

GNOMEComparison with Caching Approaches

Runtimes (ms)|C | Gnome FIFO F2 LFU LRU SLRU

1,000 5,974.0 37,161.0 42,090.3 45,906.7 54,194.3 56,904.32,000 6,168.0 31,977.0 39,071.3 39,872.0 45,473.0 46,795.04,000 7,118.3 21,337.0 40,860.0 28,028.3 26,816.7 27,200.0

Hit ratio1,000 0.51 0.17 0.16 0.19 0.17 0.172,000 0.51 0.29 0.30 0.32 0.30 0.304,000 0.51 0.54 0.55 0.59 0.55 0.56

Conclusion1 Gnome is more time-efficient2 Leads to higher hit rates in most cases

GNOMEComparison with Caching Approaches

Runtimes (ms)|C | Gnome FIFO F2 LFU LRU SLRU

1,000 5,974.0 37,161.0 42,090.3 45,906.7 54,194.3 56,904.32,000 6,168.0 31,977.0 39,071.3 39,872.0 45,473.0 46,795.04,000 7,118.3 21,337.0 40,860.0 28,028.3 26,816.7 27,200.0

Hit ratio1,000 0.51 0.17 0.16 0.19 0.17 0.172,000 0.51 0.29 0.30 0.32 0.30 0.304,000 0.51 0.54 0.55 0.59 0.55 0.56

Conclusion1 Gnome is more time-efficient2 Leads to higher hit rates in most cases

GNOMEScalability

100k 200k 400k 800kLGD 362,141.3 1,452,922.0 5,934,038.7 20,001,965.7DBP 434,630.7 1,790,350.7 6,677,923.0 12,653,403.3

ConclusionSub-quadratic growth of runtimeRuntime grows linearly with number of mappingsFor LGD, 360 – 370 mappings/s

Table of Contents

1 Introduction

2 LIMES

3 MultiBlock

6 GNOME

7 GPUs and Hadoop

Reach for the Cloud?Dealing with Time Complexity

1 Devise better algorithms

BlockingAlgorithms for given metrics

PPJoin+, EDJoinHR3

2 Use parallel hardware

Threads poolsMapReduceMassively Parallel Hardware

Reach for the Cloud?Dealing with Time Complexity

1 Devise better algorithms

BlockingAlgorithms for given metrics

PPJoin+, EDJoinHR3

2 Use parallel hardware

Threads poolsMapReduceMassively Parallel Hardware

Reach for the Cloud?Parallel Implementations

Different architecturesMemory (shared, hybrid, distributed)Execution paths (different, same)Location (remote, local)

QuestionWhen should which use which hardware?

Reach for the Cloud?Parallel Implementations

Different architecturesMemory (shared, hybrid, distributed)Execution paths (different, same)Location (remote, local)

QuestionWhen should which use which hardware?

Reach for the Cloud?Premises and Goals

PremisesGiven an algorithm that runs on all threearchitectures ...

Note to self: Implement onePicked HR3

Reduction-ratio-optimal

Reach for the Cloud?Goals

Compare runtimes on all three parallelarchitecturesFind break-even points

PremisesGiven an algorithm that runs on all threearchitectures ...Note to self: Implement one

Picked HR3

PremisesGiven an algorithm that runs on all threearchitectures ...Note to self: Implement one

Picked HR3

Reach for the Cloud?HR3

1 Assume spaces with Minkowski metric and p ≥ 2

δ(s, t) = p

√√√√ n∑i=1|si − ti |p

2 Create grid of width ∆ = θ/α

3 Link discovery condition describes a hypersphere

4 Approximate hypersphere with hypercube

5 Use index to discard portions of hypercube

Reach for the Cloud?HR3 in GPUs

Large number of simple compute coresSame instruction, multiple dataBottleneck: PCI Express Bus

1 Run discretization on CPU2 Run indexing on GPU3 Run comparisons on CPU

Local memory

Global/constant memory

Local memory Local memory Local memory

Work item

Work group

Global/constant cache

Reach for the Cloud?HR3 on the Cloud

Naive Approach

1 Rely on Map Reduce paradigm2 Run discretization and assignment to cubes in map step3 Run distance computation in reduce step

Naive Approach1 Rely on Map Reduce paradigm2 Run discretization and assignment to cubes in map step3 Run distance computation in reduce step

Load Balancing1 Run two jobs2 Job1: Compute cube population matrix3 Job2: Distribute balanced linking tasks across mappers and reducers

Reach for the Cloud?Evaluation Hardware

1 CPU (Java)32-core server running Linux 10.0.4AMD Opteron 6128 clocket at 2.0GHz

2 GPU (C++)AMD Radeon 7870 with 20 compute units, 64parallel threadsHost program ran on Intel Core i7 3770 CPU with8GB RAM and Linux 12.10Ran the Java code on the same machine for scaling

3 Cloud (Java)10 c1.medium nodes (2 cores, 1.7GB) for smallexperiments30 c1.large nodes (8 cores, 7GB) for largeexperiments

Reach for the Cloud?Experimental Setup

Run deduplication taskEvaluate behavior on different number of dimensionsImportant: Scale results

Different hardware (2-7 times faster C++ workstation)Programming language

Evaluate scalability (DS4)

Reach for the Cloud?Results – DS1

DBpedia, 3 dimensions, 26KGPU scales better

DBpedia, 2 dimensions, 475KGPUs scale better across different θBreak-even point ≈ 108 results

LinkedGeoData, 2 dimensions, 500KSimilar picture

Reach for the Cloud?Results – Scalability

LinkedGeoData, 2 dimensions, 6MCloud (with load balancing) better for ≈ 1010+ results

Reach for the Cloud?Summary

Question: When should we use which hardware for link discovery?Results

Implemented HR3 on different hardwareProvided the first implementation of link discovery on GPUsDevised a load balancing approach for linking on the cloudDiscovered 108 and 1010 results as break-even points

Reach for the Cloud?Summary

Question: When should we use which hardware for link discovery?Insights

Load balancing important for using the cloudGPUs: Need faster buses that PCIe (e.g., Firewire speed)Accurate use of local resources sufficient for most of the currentapplications

Table of Contents

1 Introduction

2 LIMES

3 MultiBlock

6 GNOME

7 GPUs and Hadoop

Summary and Conclusion

Four approaches to scalability1 Improve reduction ratio (LIMES,

MultiBlock, HYPPO, HR3, . . . )2 Reduce runtime complexity

(AEGLE)3 Better use of hardware (GNOME)4 Improve execution of

specifications

Challenges include1 Increase number of

reduction-ratio-optimalapproaches (HR3, ORCHID)

2 Adaptive resource scheduling3 Self-regulating approaches4 Distribution in modern in-memory

architecture (SPARK)5 . . .

Summary and Conclusion

Four approaches to scalability1 Improve reduction ratio (LIMES,

MultiBlock, HYPPO, HR3, . . . )2 Reduce runtime complexity

(AEGLE)3 Better use of hardware (GNOME)4 Improve execution of

specificationsChallenges include

1 Increase number ofreduction-ratio-optimalapproaches (HR3, ORCHID)

2 Adaptive resource scheduling3 Self-regulating approaches4 Distribution in modern in-memory

architecture (SPARK)5 . . .

Acknowledgment

This work was supported by grants from the EU H2020 Framework Programmeprovided for the project HOBBIT (GA no. 688227).

References I

Kleanthi Georgala, Mohamed Ahmed Sherif, andAxel-Cyrille Ngonga Ngomo. “An Efficient Approach for theGeneration of Allen Relations”. In: ECAI 2016 - 22nd EuropeanConference on Artificial Intelligence, 29 August-2 September 2016,The Hague, The Netherlands - Including Prestigious Applications ofArtificial Intelligence (PAIS 2016). Ed. by Gal A. Kaminka et al.Vol. 285. Frontiers in Artificial Intelligence and Applications. IOSPress, 2016, pp. 948–956. isbn: 978-1-61499-671-2. doi:10.3233/978-1-61499-672-9-948. url:http://dx.doi.org/10.3233/978-1-61499-672-9-948.

Robert Isele, Anja Jentzsch, and Christian Bizer. “EfficientMultidimensional Blocking for Link Discovery without losing Recall”.In: Proceedings of the 14th International Workshop on the Web andDatabases 2011, WebDB 2011, Athens, Greece, June 12, 2011. Ed. byAmélie Marian and Vasilis Vassalos. 2011. url:http://webdb2011.rutgers.edu/papers/Paper%2039/silk.pdf.

References II

Axel-Cyrille Ngonga Ngomo and Sören Auer. “LIMES - ATime-Efficient Approach for Large-Scale Link Discovery on the Webof Data”. In: IJCAI 2011, Proceedings of the 22nd International JointConference on Artificial Intelligence, Barcelona, Catalonia, Spain, July16-22, 2011. Ed. by Toby Walsh. IJCAI/AAAI, 2011, pp. 2312–2317.isbn: 978-1-57735-516-8. doi:10.5591/978-1-57735-516-8/IJCAI11-385. url: http://dx.doi.org/10.5591/978-1-57735-516-8/IJCAI11-385.

Axel-Cyrille Ngonga Ngomo et al. “When to Reach for the Cloud:Using Parallel Hardware for Link Discovery”. In: The Semantic Web:Semantics and Big Data, 10th International Conference, ESWC 2013,Montpellier, France, May 26-30, 2013. Proceedings. Ed. byPhilipp Cimiano et al. Vol. 7882. Lecture Notes in Computer Science.Springer, 2013, pp. 275–289. isbn: 978-3-642-38287-1. doi:10.1007/978-3-642-38288-8_19. url:http://dx.doi.org/10.1007/978-3-642-38288-8_19.

References III

Axel-Cyrille Ngonga Ngomo. “Link Discovery with GuaranteedReduction Ratio in Affine Spaces with Minkowski Measures”. In: TheSemantic Web - ISWC 2012 - 11th International Semantic WebConference, Boston, MA, USA, November 11-15, 2012, Proceedings,Part I. Ed. by Philippe Cudré-Mauroux et al. Vol. 7649. Lecture Notesin Computer Science. Springer, 2012, pp. 378–393. isbn:978-3-642-35175-4. doi: 10.1007/978-3-642-35176-1_24. url:http://dx.doi.org/10.1007/978-3-642-35176-1_24.

Axel-Cyrille Ngonga Ngomo. “ORCHID - Reduction-Ratio-OptimalComputation of Geo-spatial Distances for Link Discovery”. In: TheSemantic Web - ISWC 2013 - 12th International Semantic WebConference, Sydney, NSW, Australia, October 21-25, 2013,Proceedings, Part I. Ed. by Harith Alani et al. Vol. 8218. LectureNotes in Computer Science. Springer, 2013, pp. 395–410. isbn:978-3-642-41334-6. doi: 10.1007/978-3-642-41335-3_25. url:http://dx.doi.org/10.1007/978-3-642-41335-3_25.

References IV

Axel-Cyrille Ngonga Ngomo. “HELIOS - Execution Optimization forLink Discovery”. In: The Semantic Web - ISWC 2014 - 13thInternational Semantic Web Conference, Riva del Garda, Italy,October 19-23, 2014. Proceedings, Part I. Ed. by Peter Mika et al.Vol. 8796. Lecture Notes in Computer Science. Springer, 2014,pp. 17–32. isbn: 978-3-319-11963-2. doi:10.1007/978-3-319-11964-9_2. url:http://dx.doi.org/10.1007/978-3-319-11964-9_2.

Axel-Cyrille Ngonga Ngomo and Mofeed M. Hassan. “The LazyTraveling Salesman - Memory Management for Large-Scale LinkDiscovery”. In: The Semantic Web. Latest Advances and NewDomains - 13th International Conference, ESWC 2016, Heraklion,Crete, Greece, May 29 - June 2, 2016, Proceedings. Ed. byHarald Sack et al. Vol. 9678. Lecture Notes in Computer Science.Springer, 2016, pp. 423–438. isbn: 978-3-319-34128-6. doi:10.1007/978-3-319-34129-3_26. url:http://dx.doi.org/10.1007/978-3-319-34129-3_26.

link discovery tutorial part i: efficiency

Science

advanced tiered link building tutorial presentation

northumbria research link - ucl discovery

ontology mapping and link discovery

when recommendation goes wrong - anomalous link discovery in

tutorial owl and drug discovery icbo 2013

link discovery tutorial part v: hands-on

a tutorial on false discovery control

link discovery tutorial part iii: benchmarking for instance...

colibri - unsupervised link discovery through knoeledge base...

data mining tutorial - lmu munich · data mining tutorial...

sagu discovery tutorial

link earning-tutorial-backlink-building-guide

padlet visual discovery map tutorial

link - discovery communications

stmicroelectronics: and keil mdk 5 toolkitwe will use a...

iot discovery tutorial

tutorial psim smartctrl link cristina

eclipse and the parallel tools...

link discovery tutorial introduction

link layer discovery protocol (lldp)