M2 Informatique – DAC – ASWS...

M2 Informatique DAC – ASWS 2018/2019 – – Bernd Amann

M2 Informatique – DAC – ASWS 2018/2019Apprentissage Symbolique et Web Sémantique

Bernd Amann

SU

22 octobre 2018

293 / 357

M2 Informatique DAC – ASWS 2018/2019 – – Bernd Amann

Systèmes RDF

1 Services de données RDF

2 Triple stores « SQL »

3 Systèmes RDF « noSQL »

4 Systèmes RDF fédérés

294 / 357

M2 Informatique DAC – ASWS 2018/2019 – Services de données RDF – Bernd Amann

Outline





295 / 357


Services de données RDFServices d’un système de données RDF

stockage et interrogation de graphes RDFimportation / exportation : fichiers RDF↔ graphes RDF« endpoint » SPARQL : interrogation à distance (service web/REST)service d’inférence RDFS et/ou OWL;interfaces de mises-à-jour (SPARQL Update)

Défis liés à la performance

taille des graphes ∼ nombre de triplets RDFoptimisation des requêtes (surtout le traitement des jointures)complexité des schéma RDFS et/ou ontologies OWL

inférence (matérialisation) avant l’interrogation→ taille des donnéesinférence (dynamique) pendant l’interrogation→ optimisation de requêtes

296 / 357


Classification des systèmes RDFSystèmes RDF « non-natifs » : réutilisation

réutilisation de technologies existantes (relationnel, noSQL) :réutilisation au niveau logique : représentation de graphes dans des tables ettraduction de requêtes SPARQL en requêtes SQLréutilisation au niveau physique : structures d’index (arbres-B), opérateursphysiques (sélection, jointures, ...)

exemples : RDF-3X, Jena, Virtuoso, Graph DB, HBase/MapReduce,SPARK/Sparql SQL

Systèmes RDF « natifs » : spécialisation

systèmes spécialisés pour le traitement de données RDFreprésentation physique spécialisée (nouvelle)opérateurs conçus pour le traitement de graphes RDF

exemples : Sesame/rdf4j, WaterFowl, gStore

La séparation entre systèmes « natifs » et « non-natifs » n’est pas tou-jours évidente.

297 / 357


Critères de comparaison de systèmes

Comment comparer les systèmes?

coûts de stockage du graphe (occupation disque/mémoire)coûts d’importation / pré-traitement de données (indexation,compression)coûts d’évaluation des requêtes (jointures !)mode de persistance : disque versus mémoire, distribution et réplicationcomplexité de déploiement : architecture, configuration du systèmeparallélisation des traitements

298 / 357

M2 Informatique DAC – ASWS 2018/2019 – Triple stores « SQL » – Bernd Amann

Outline





299 / 357

M2 Informatique DAC – ASWS 2018/2019 – Triple stores « SQL » – Bernd Amann

SPARQL et SQLObjectif

Utiliser un moteur SQL pour évaluer des requêtes SPARQL :optimiseur : traduire requêtes SPARQL en SQL→ optimisation et évaluationSQLopérateurs physiques et index : traduire requêtes SPARQL en plan d’exécution→ optimisation SPARQL et évaluation SQL

→ définir un schéma de stockage relationnel pour des données RDF

Schéma de stockage relationnel pour RDF

schémas de stockage génériques :schémas relationnels fixes et indépendants du schéma RDFS (classes et propriétés)

schémas de stockage partitionnés :schémas relationnels dépendant du schéma RDFS (classes et propriétés)partitionnement structurelle du graphe en plusieurs tables

schémas de stockages étendus :modèle relationnel étendu (relationnel-objet, SQL3)structures et opérateurs (fonctions) spécifiques pour l’interrogation de graphes RDF

300 / 357

M2 Informatique DAC – ASWS 2018/2019 – Triple stores « SQL » – Schémas de stockage génériques Bernd Amann

2 - Triple stores « SQL »

Schémas de stockage génériquesSchémas de stockage partitionnéesSchémas de stockage étendus

301 / 357


Solution 1 : Table de triplets

Schéma de stockage générique

une seule table principale : Triples(subject, property, object)tables « support » (dictionnaire) et indexVirtuoso, Jena, Sesame, 3store, Kaon, RStar

Avantages

importation / exportation simple et rapide (triplet = nuplet)traitement uniforme des données RDF et schémas RDFSreprésentation « naturelle » de propriétés multivaluées et optionnelles

Inconvénients

beaucoup d’auto-jointures sur une grande table

302 / 357


Motifs simples = jointures SQLRequête optional1

PREFIX : < h t t p : / / example . org / ns#>SELECT ? t i t l e ?pr i ceFROM <bib l iosem . t t l >

WHERE { ?x : t i t l e ? t i t l e .?x : p r i ce ?pr i ce . }

Expression algébrique de optional1

( p r e f i x ( ( : < h t t p : / / example . org / ns# > ) )( p r o j e c t ( ? t i t l e ?pr i ce )

( bgp( t r i p l e ?x : t i t l e ? t i t l e )( t r i p l e ?x : p r i c e ?pr i ce )

) ) )

SQL

s e l e c t t1 . ob jec t as t i t l e ,t2 . ob jec t as p r i ce

from T r i p l e s t1 , T r i p l e s t2where t1 . p roper ty = ’ : t i t l e ’

and t2 . p roper ty = ’ : p r i c e ’and t1 . sub jec t = t2 . sub jec t ;

ou

s e l e c t t1 . ob jec t as t i t l e ,t2 . ob jec t as p r i ce

from T r i p l e s t1 j o i n T r i p l e s t2on ( t1 . sub jec t = t2 . sub jec t )

where t1 . p roper ty = ’ : t i t l e ’and t2 . p roper ty = ’ : p r i c e ’ ;

303 / 357


OPTIONAL = left outer join SQLRequête optional1a

PREFIX : < h t t p : / / example . org / ns#>SELECT ? t i t l e ?pr i ceFROM <bib l iosem . t t l >

WHERE { ?x : t i t l e ? t i t l e .OPTIONAL { ?x : p r i ce ?pr i ce . } }

Expression algébrique de optional1a

( p r e f i x ( ( : < h t t p : / / example . org / ns# > ) )( p r o j e c t ( ? t i t l e ?pr i ce )

( l e f t j o i n( t r i p l e ?x : t i t l e ? t i t l e )( t r i p l e ?x : p r i c e ?pr i ce )

) ) )

q1 : requête motif ?x :title ?titleq2 : requête motif ?x :price ?price

SQL

s e l e c t t . t i t l e , t . p r i cefrom ( s e l e c t t1 . x , t1 . t i t l e , t2 . p r i ce as p r i ce

from ( q1 ) t1 l e f t ou ter j o i n ( q2 ) t2 on ( t1 . x = t2 . x ) ) t

ou

s e l e c t t . t i t l e , t . p r i cefrom ( s e l e c t t1 . x , t1 . t i t l e , t2 . p r i ce as p r i ce

from ( s e l e c t sub jec t as x , ob jec t as t i t l efrom T r i p l e where proper ty= ’ : t i t l e ’ ) t1

l e f t ou ter j o i n( s e l e c t sub jec t as x , ob jec t as p r i ce

from T r i p l e where proper ty= ’ : p r i ce ’ ) t2on ( t1 . x = t2 . x ) ) t

304 / 357


OPTIONAL imbriquéRequête optional5

PREFIX : < h t t p : / / example . org / ns#>SELECT ? t i t l e ? e d i t o r ?address

FROM <bib l iosem . t t l >WHERE { ?x : t i t l e ? t i t l e .

OPTIONAL { ?x : e d i t o r ? e d i t o rOPTIONAL { ? e d i t o r : address ?address } } }

q1 : requête motif ?x :title ?titleq2 : requête motif ?x :editor ?editorq3 : requête motif ?editor :address ?address

q1 ./ q2 ./ q3

SQL

s e l e c t t . t i t l e t . e d i t o r t . addressfrom ( s e l e c t t1 . x , t1 . t i t l e , t2 . e d i t o r

from q1 t1 l e f t ou ter j o i n( s e l e c t t2 . x , t2 . ed i t o r , t3 . addressfrom q2 t2 l e f t ou ter j o i n q3 t3

on ( t3 . e d i t o r = t2 . e d i t o r ) ) taon ( t1 . x = t2 . x ) ) t

305 / 357

M2 Informatique DAC – ASWS 2018/2019 – Triple stores « SQL » – Schémas de stockage partitionnées Bernd Amann



306 / 357


Solution 2 : Tables partitionnéesSchéma de stockage partitionné

une table par type de propriété : Propertyi (Subject, Object)exemple : SW-Store [Abadi et.al. 07].

Avantages

import/export simple et rapide (triplet=nuplet)représentation « naturelle » de propriétés multivalués et optionnellesréutilisation de la technologie column tables (Vertica / Monet DB)jointures efficaces : tables trié par le sujet et merge-join

Inconvénients

beaucoup de jointuresnombre de tables importantes (beaucoup de « petites » tables)

307 / 357


Schéma spécifique : Tables partitionnéesRequête simple1

PREFIX : < h t t p : / / example . org / ns#>SELECT ? t i t l e ?pr i ce ? e d i t o rFROM <bib l iosem . t t l >

WHERE { ?x : t i t l e ? t i t l e .?x : e d i t o r ? e d i t o r .?x : p r i c e ?pr i ce . }

SQL

s e l e c t t1 . t i t l e , t2 . ed i t o r , t3 . e d i t o rfrom t i t l e t1 , e d i t o r t2 , p r i ce t3

where t1 . sub jec t = t2 . sub jec tand t2 . sub jec t = t3 . sub jec t

308 / 357


Solution 3 : Tables de propriétés

Schéma de stockage partitionné

regroupement (clustering) de sujets partageant des propriétésplusieurs tables : Proptablei (Subject, Property1, ..., Propertyn)

Avantages

fragmentation des données en plusieurs tablesregroupement de propriétés qui sont souvent interrogées ensembles→moins d’autojointures

Inconvénients

les propriétés partagées entre tables génèrent des unionsles propriétés multivalués ou optionnelles génèrent des valeurs NULL(ou des tables séparées)

309 / 357


Tables de propriétés : Deux variantes

Cluster de propriétés

Propclusteri (Sujet, Property1, Property2, ..., Propertyn)le type RDF (classe) de la ressource est une propriété parmi d’autres.chaque propriété apparaît dans une seule table.

Classes de propriétés

Propclassei (Sujet, Property1, Property2, ..., Propertyn)classe RDFS = table relationnelleune propriété peut apparaître dans plusieurs tables.

310 / 357


Tables de propriétés : moins de jointuresRequête simple1

PREFIX : < h t t p : / / example . org / ns#>SELECT ? t i t l e ?pr i ce ? e d i t o rFROM <bib l iosem . t t l >

WHERE { ?x : t i t l e ? t i t l e .?x : e d i t o r ? e d i t o r .?x : p r i ce ?pr i ce . }

Expression algébrique de simple1

( p r e f i x ( ( : < h t t p : / / example . org / ns# > ) )( p r o j e c t ( ? t i t l e ?pr i ce ? e d i t o r )

( bgp( t r i p l e ?x : t i t l e ? t i t l e )( t r i p l e ?x : e d i t o r ? e d i t o r )( t r i p l e ?x : p r i ce ?pr i ce )

) ) )

Schéma générique

s e l e c t t1 . ob jec t as t i t l e ,t3 . ob jec t as pr ice ,t2 . ob jec t as e d i t o r

from T r i p l e s t1 , T r i p l e s t2 ,T r i p l e s t3

where t1 . p roper ty = ’ : t i t l e ’and t2 . p roper ty = ’ : e d i t o r ’and t3 . p roper ty = ’ : p r i c e ’and t1 . sub jec t = t2 . sub jec t ;and t1 . sub jec t = t3 . sub jec t ;

Table de propriétés

s e l e c t t1 . t i t l e , t2 . p r ice , t1 . e d i t o rfrom t i t l e _ e d i t o r t1 , p r i ce t2

where t1 . sub jec t = t2 . sub jec t ;

311 / 357


Tables de propriétés : plus d’unionsRequête simple2

PREFIX : < h t t p : / / example . org / ns#>SELECT ?x ?pr i ceFROM <bib l iosem . t t l >

WHERE { ?x : p r i ce ?pr i ce . }

Schéma générique

s e l e c t t1 . sub jec t , t1 . ob jec t as pr ice ,from T r i p l e s t1

where t1 . p roper ty = ’ : p r i c e ’

Schéma spécifique

s e l e c t t1 . sub jec t , t1 . p r i c efrom l i v r e _ p r i x t1

unions e l e c t t1 . sub jec t , t1 . p r i c e

from a r t i c l e _ p r i x t1

312 / 357

M2 Informatique DAC – ASWS 2018/2019 – Triple stores « SQL » – Schémas de stockage étendus Bernd Amann



313 / 357


Exemple : Oracle RDF

application du “Spatial Network Data Model” (Spatial NDM)graphe RDF = réseau logiquedeux packages :

SDO_RDF : manipulation de graphes RDF (modèles)SDO_RDF_INFERENCE : inférence et règles

314 / 357


Schéma RDF étendu dans Oracle 10gDeux types abstraits

Interface SQL :SDO_RDF_TRIPLE (affichage)SDO_RDF_TRIPLE_S (stockage)

Plusieurs tables annexes

RDF_LINK$(LINK_ID, P_VALUE_ID, START_NODE_ID, END_NODE_ID,LINK_TYPE, ACTIVE, CONTEXT, REIF_LINK, MODEL_ID)RDF_MODEL$(MODEL_ID, MODEL_NAME)RDF_NAMESPACE$(NAMESPACE_ID, NAMESPACE_NAME)RDF_VALUE$(VALUE_ID,VALUE_NAME, VALUE_TYPE, LITERAL_TYPE) :

les URIs et valeurs sont stockées dans une table séparéeVALUE_TYPE : URI, blank node, literal (plain, typed)

RDF_NODE$(NODE_ID, ACTIVE)RDF_BLANK_NODE$(NODE_ID, NODE_VALUE, ORIG_NAME, MODEL_ID)

(invisibles pour le développeur)

315 / 357


Utilisation du package SDO_RDF

Fonctionnalités principales

Génération d’un graphe RDF :création d’une table T avec un attribut de type SDO_RDF_TRIPLE_Spour stocker interroger des triplets RDF.création d’un modèle (graphe) RDF G : CREATE_RDF_MODEL :génération des tables annexes.

insertion / suppression de triplets RDF dans la table T : INSERT /DELETEinterrogation motifs SPARQL : requête SQL sur des tables générées parSDO_RDF_MATCH sur G

Autres fonctionnalités

gestion d’espaces de noms, collections, noeuds blancs, réification

316 / 357


Exemple : Création Graphe Vide

Création d’une table pour stocker les triplets

CREATE TABLE fam i l y_ rd f_da ta (i d NUMBER,t r i p l e SDO_RDF_TRIPLE_S ) ;

Création des tables annexes

SDO_RDF.CREATE_RDF_MODEL( model_name ,table_name , column_name ) ;

Exemple

EXECUTE SDO_RDF.CREATE_RDF_MODEL( ’ f a m i l y ’ ,’ f am i l y_ rd f_da ta ’ , ’ t r i p l e ’ ) ;

317 / 357


Le type SDO_RDF_TRIPLE_S

SDO_RDF_TRIPLE_S

Type abstrait pour triplets RDF.

Méthodes SDO_RDF_TRIPLE_S

SDO_RDF_TRIPLE_S(model, subject, property, object)constructeur

SDO_RDF_TRIPLE_S.GET_TRIPLE()SDO_RDF_TRIPLE_S.GET_SUBJECT()SDO_RDF_TRIPLE_S.GET_PROPERTY()SDO_RDF_TRIPLE_S.GET_OBJECT()

318 / 357


Exemple : Insertion triplets

INSERT INTO fam i l y_ rd f_da ta VALUES (1 ,SDO_RDF_TRIPLE_S( ’ f a m i l y ’ ,

’ h t t p : / / www. example . org / f a m i l y / John ’ ,’ h t t p : / / www. example . org / f a m i l y / f a the rO f ’ ,’ h t t p : / / www. example . org / f a m i l y / Suzie ’ ) ) ;


’ h t t p : / / www. example . org / f a m i l y / Male ’ ,’ r d f s : subClassOf ’ ,’ h t t p : / / www. example . org / f a m i l y / Person ’ ) ) ;


’ h t t p : / / www. example . org / f a m i l y / s i b l i n g O f ’ ,’ r d f : type ’ ,’ r d f : Proper ty ’ ) ) ;

319 / 357


Évaluation de Motifs de GraphesFonction SDO_RDF_MATCH

SDO_RDF_MATCH(query VARCHAR2,models SDO_RDF_MODELS, ru lebases SDO_RDF_RULEBASES,a l i ases SDO_RDF_ALIASES,f i l t e r VARCHAR2

) RETURN ANYDATASET;

Exemple

SELECT mFROM TABLE(SDO_RDF_MATCH(

’ (?m r d f : type : Male ) ’ ,SDO_RDF_Models ( ’ f a m i l y ’ ) , n u l l ,SDO_RDF_Aliases ( SDO_RDF_Alias ( ’ ’ , ’ h t t p : / / www. example . org / f a m i l y / ’ ) ) ,

n u l l ) ) ;

Réponse

M−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−h t t p : / /www. example . org / f a m i l y / Jackh t t p : / /www. example . org / f a m i l y /Tom

320 / 357


Utilisation du package SDO_RDF_INFERENCESDO_RDF_INFERENCE

Package pour la définition et l’exécution de règles RDF.

Application

création de bases de règles : CREATE_RULEBASEinsertion / suppression de règles : INSERT / DELETEapplication de règles (matérialisation) : CREATE_RULES_INDEX

forward chaining : génération de l’ensemble de triplets qu’on peut déduire à partir desrègles

Bases de règles par défaut (Oracle 11gR2)

RDFS : RDF/RDFS entailmentRDFS++ : RDFS et owl :InverseFunctionalProperty, owl :sameAsOWLSIF : RDFS++ et owl :FunctionalProperty, owl :SymmetricProperty,owl :TransitiveProperty, owl :inverseOf, owl :equivalentClass,owl :equivalentProperty, owl :hasValue, owl :someValuesFrom,owl :allValuesFromOWLPrime : OWLSIF + owl :disjointWith, owl :complementOfOWL2RL http://www.w3.org/TR/owl-profiles/#OWL_2_RL

321 / 357

http://www.w3.org/TR/owl-profiles/#OWL_2_RL


Exemple : Interrogation avec Inférence

Règles utilisateurs

EXECUTE SDO_RDF_INFERENCE.CREATE_RULEBASE( ’ f am i l y_ rb ’ ) ;INSERT INTO MDSYS.RDFR_FAMILY_RB VALUES(

’ g randparent_ru le ’ ,’ (? x : parentOf ?y ) (? y : parentOf ?z ) ’ ,NULL, ’ (? x : grandParentOf ?z ) ’ ,SDO_RDF_Aliases ( SDO_RDF_Alias ( ’ ’ ,

’ h t t p : / / www. example . org / f a m i l y / ’ ) ) ) ;

Requêtes avec Inférence

SELECT m FROM TABLE(SDO_RDF_MATCH( ’ (?m r d f : type : Male ) ’ ,SDO_RDF_Models ( ’ f a m i l y ’ ) ,SDO_RDF_Rulebases ( ’RDFS ’ ) ,SDO_RDF_Aliases ( SDO_RDF_Alias ( ’ ’ ,

’ h t t p : / / www. example . org / f a m i l y / ’ ) ) , n u l l ) ) ;

322 / 357

M2 Informatique DAC – ASWS 2018/2019 – Systèmes RDF « noSQL » – Bernd Amann

Outline





323 / 357

M2 Informatique DAC – ASWS 2018/2019 – Systèmes RDF « noSQL » – RDF et noSQL Bernd Amann

3 - Systèmes RDF « noSQL »

RDF et noSQLSystèmes RDF/noSQLRDF/SPARQL en MapReduce

324 / 357

M2 Informatique DAC – ASWS 2018/2019 – Systèmes RDF « noSQL » – RDF et noSQL Bernd Amann

Systèmes not-only SQLDonnées RDF

données volumineuses, complexes et faiblement structuréesrequêtes complexes (motifs de graphes)cohérence faible (données web, schéma = description)

Systèmes « SQL »

structuration forte : schéma = contraintesalgèbre physique complexe→ distribution et parallélisation difficilegestion de cohérence coûteuse (ACID)

Systèmes « noSQL »

favoriser la scalabilité et la disponibilitéstructuration faible : schéma = description et validation des donnéescohérence à terme (eventual consistency) au lieu de cohérence forte (lecture/écriture)

Les systèmes noSQL sont bien adaptés pour le stockage et l’interrogation detrès grands graphes RDF.

325 / 357

M2 Informatique DAC – ASWS 2018/2019 – Systèmes RDF « noSQL » – Systèmes RDF/noSQL Bernd Amann



326 / 357


Column StoresSystèmes no-SQL

Bigtable/Google, Hbase/Apache, Cassandra/Apache, SimpleDB

Modèle

tables avec familles de colonnes / couples (clé,valeur) imbriquéskeyspace→ column family (table)→ row key (ligne)→ column key (attribut)→valeurindexation par « hachage cohérent » sur un anneau

Avantages et Inconvénients

+ favorise la cohérence et la tolérance aux pannes- complexité de la mise-en-oeuvre

Column Stores RDF

20 (Hexastore + HBase), CumulusRDF [21] (Cassandra), Stratusstore [22](SimpleDB)

327 / 357


Document Stores

Systèmes

Lotus notes, mongodb/10gen, couchDB/Apache, Terrastore, JSON stores

Modèle

collection de documents indépendants et identifiés par des clésdocument = instance JSON : imbrication, liste, ...


+ contrôle sur la fragmentation de données en documents indépendants- distribution à la charge du développeur (sharding)

Document Stores RDF

rdf-couchdb, MongoDB-RDF

328 / 357


Graph DB

Systèmes

Neo4j, InfiniteGraph, Trinity (Microsoft), FlockDB

Modèle

graphes dirigés et étiquetés


+ implémentation « directe » du modèle graphe RDF : jointure parnavigation, expressions de chemins

- parallélisation compliquée : partitionnement de graphes

Graph Stores RDF

Neo4J (support natif de SPARQL), gStore, AMBER

329 / 357

M2 Informatique DAC – ASWS 2018/2019 – Systèmes RDF « noSQL » – RDF/SPARQL en MapReduce Bernd Amann



330 / 357


Performance et passage à l’échelleScalabilité

Implémenter des systèmes RDF qui sont capables d’adapter « enproportion » leurs besoins en ressources aux demandes (requêtes) et auxvolumes de données RDF à gérer.

Scalabilité⇔ distribution et parallélisation

Partitionnement et distribution des données :schémas de stockage partitionnés (hash, graph)indexation distribuée

Évaluation parallèle de requêtes (jointures)

Problème d’optimisation

Deux problèmes équivalents :Minimiser l’échange de données (shuffling) entre les noeudsMaximiser la localité des données par rapport aux traitements

331 / 357


Data Parellelism and Map-ReduceData parallelism

Separate task on a big dataset into a set of synchronizes parallel tasks on smaller subsets.

Map-Reduce Program

Three consecutive steps executed by m mappers Mi and r reducers Rj :initialization : data set D is distributed to m mappers Mimap : each mapper Mi partitions and sorts its local data set (tuples) Di according to akey-value k to generate partitions Pi(k).shuffle : all partitions Pi(k) with the same key-value k are sent to the same reducer Rj .reduce : each reducer Rj aggregates for some given k the partitions Pi(k) of all mappers.

Each node can play the role of one or several mappers and/or one or several reducers.

Example

All mappers use the same partitioning scheme andsend all tuples t in partition v where v mod 3 = 0to reducer R1, v mod 3 = 1 to reducer R2 andv mod 3 = 2 to reducer R3.

D

M1 M2 M3 M4

R1 R2 R3

332 / 357


Map-Reduce Joins and Graph PatternsMap-Reduce and RDF

RDF data set can be partitioned and distributed over a given set of computation nodesGraph pattern ∼ many joins

Observations

Map-Reduce step naturally implements a « join » on the hash values.Joins with Map-Reduce is a well-known problem;Two main join processing strategies : partitioned join and broadcast (replicated) join

Example

All mappers partition their tupes on joinattribtute a and send all tuples in partitiont .a = v where t .a mod 3 = 0 to reducerR1, t .a mod 3 = 1 to reducer R2 andt .a mod 3 = 2 to reducer R3.

D

M1 M2 M3 M4

R1 R2 R3

333 / 357


Partitioned Triple joinJoin t 1?x t ′

initialization (executed once) : data set D is distributed to the mappers Mi .map : each mapper Mi partitions the triples matching patterns t and t ′ according to thebindings k of variable ?x to generate partitions Pi(t , k) and Pi(t ′, k).shuffle : all partitions Pi(t , k) and Pi(t ′, k) with the same key-value k are sent to the samereducer Rj .reduce : reducer Rj joins the partitions Pi(t , k) and Pi(t ′, k) received from all mappers Mifor a given join value k of .

Example : t=(?x :p :r1), t’=(?a :q ?x)

all results for triple patterns (?x :p :r1 and (?a :q ?x) contaning the same binding for ?xare sent to the same reducer R which computes the join.data transfer cost : O(b + b′) where b and b′ is the size of all bindings for both patterns tand t ′.the result is partitioned on ?x

Data locality depends on initialization step

For example, if all triples with the same subject s are distributed to the same mapper nodeM(s) and each mapper node M(s) is also the reducer M(s) = R(s) of the triples with subjectS ⇒ star queries are executed locally (without any data exchange)

334 / 357


Broadcast joinJoin t 1?x t ′

initialization (executed once) : data set D is distributed to the mappers Mi .map : each mapper Mi partitions the triples matching patterns t according to thebindings k of variable ?x to generate partitions Pi(t , k) and Pi(t ′, k).shuffle : each mapper Mi broadcasts the partition corresponding to the smallerdata set, say Pi(t , k), to all computation nodes (reducers).reduce : each reducer Rj joins all received partitions Pi(t , k) bindings with itslocal partition Pj(t ′, k).

Example : t=(?x :p :r1), t’=(?a :q ?x)

for a given node (mapper) N, all bindings produced by N for triple pattern t(small) are sent to all nodes (reducers) which compute the join.data transfer cost : O(b ∗ n) where b is the size of bindings for t and n is thenumber of computation nodes.the result preserves the initial (target) partitioning.

335 / 357


Example : RDF-3X + Hadoop [9]

Data distribution

partition RDF graph : METIS graph partitionereach Hadoop node stores one or several partitions in a local RDF-3Xinstance(partial) replication to reduce inter-machine communication (N-hopguarantee)

Parallel query processing

Query is parallelizable without communication?yes : result = union of locally evaluated sub-queriesno :

1 decompose query pattern into subqueries (minimal edge partionining ofquery graph)

2 evaluate subqueries3 integrate subquery results globally

336 / 357


RDF-3X + Hadoop : Node Cut PartitioningGraphe RDF

:r1 :r2 :r3 :r4 :r13

:r6 :r7 :r8 :r5

:r9 :r10 :r11 :r12

:p:q :r

:s

:t

:r:q

:p

:t

:s

:t

:r

:s

trois partitions :

p1 p2 p3

les noeuds repliqués sonten rouge (1-hopreplication).

Motifs SPARQL

M1 :

?b

?a

?c

:r

:s

M2 :

?b

?a ?c ?d

?e

:r:t :t

:s

M1 : évaluation localementdans les trois partitions etunion des mappingsobtenusM2 : décomposition ensous-motifs qui sontévalués localement ; leursréponses sont jointsglobalement.

337 / 357

M2 Informatique DAC – ASWS 2018/2019 – Systèmes RDF fédérés – Bernd Amann

Outline





338 / 357

M2 Informatique DAC – ASWS 2018/2019 – Systèmes RDF fédérés – LOD et SPARQL endpoints Bernd Amann

4 - Systèmes RDF fédérés

LOD et SPARQL endpointsExemple : SPLENDID

339 / 357


LOD

Linked Open Data Cloud

http://lod-cloud.net/

graphe de 1 224 datasets RDFreliés par 16 113 liens (Juin 2018)chaque dataset RDF évolueindépendamment et est lié àd’autres dataset RDFrafraîchir les donnéesrégulièrement est coûteux→architectures fédérées

"Linking Open Data cloud diagram 2017, by Andrejs Abele, John P. McCrae, PaulBuitelaar, Anja Jentzsch and Richard Cyganiak. http ://lod-cloud.net/"

340 / 357

http://lod-cloud.net/


SPARQL EndpointsSPARQL endpoint

Service Web (REST) qui exécute des requêtes SPARQL sur un datasetRDF :

HTTP GET avec requête SPARQL comme paramètrerésultat en XML, JSON, Turtle, textAPIs : PHP (ARC, RAP), Java (ARQ-Jena, Sesame), Python(PySPARQL, SPARQL wrapper)

Exemples

https://www.wikidata.org/wiki/Wikidata:SPARQL_query_service

http://data.gov/

http://www4.wiwiss.fu-berlin.de/dblp/

http://dbpedia.org/

Liste : https://www.w3.org/wiki/SparqlEndpoints341 / 357



http://data.gov/

http://www4.wiwiss.fu-berlin.de/dblp/

http://dbpedia.org/

https://www.w3.org/wiki/SparqlEndpoints


Interroger plusieurs SPARQL endpoints

1 programmes avec des requêtes paramétrées : bouclesrequêtes/sous-requêtes+ données à jour- inefficace : composition de requêtes ad-hoc par un programme

2 SPARQL endpoint universel qui réunit plusieurs RDF datasets(http://lod.openlinksw.com/sparql)+ efficace : données locales, optimisation SPARQL- données obsolètes

3 systèmes RDF « fédérés » qui optimisent et propagent les requêtes+ données à jour+ optimisation de requêtes distribuées- mise-en-place complexe

342 / 357

http://lod.openlinksw.com/sparql


Architectures d’intégration de données RDF

1 entrepôts de données RDF :chargement de datasets dans un serveur centralisé ;données, indexation et interrogation localesOpenLink Virtuoso, AllegroGraph, Jena TDB, Stardog

2 systèmes fédérés :fédération de serveurs RDF (endpoints SPARQL)données distribuées, index centralisé, interrogation distribuéeFedX, SPLENDID, Anapsid, Avalanche

3 protocole « link-traversal » :exploration dynamique du graphe pendant l’interrogationdonnées distribuées, pas d’index, interrogation distribuée

4 réseaux pair-à-pairréseau P2P structuré (overlay network, DHT)données, indexation et interrogation distribuésRDFPeers, Atlas

343 / 357


Distribution de données RDF

Distribution de données RDF

RDF permet de différents « schémas de distribution » :toutes les propriétés et valeurs (objets) d’une entité (sujet) sont localesavec des liens owl:sameAs vers des entités distants ;toutes les propriétés d’une entité sont locales avec des valeurs (objets)locales et distants ;les propriétés et valeurs d’une entité (sujet) sont distribuées librement ;

Défis

Chaque type de distribution nécessite des solutions spécifiques pourdécouvrir/identifier les sources (SPARQL endpoint) pertinentes pourune requêteréécrire, optimiser et évaluer les requêtes

344 / 357


Systèmes RDF fédérés : cataloguesCatalogue de sources

statique : catalogue de sources (portail http://thedatahub.org)dynamique : moteur de recherche RDF (Sindice)

Catalogue de données

Description du contenu des sources :les classes et propriétés couvertes avec des statistiques (schema index)les chemins de propriétés couverts (structure index)des informations sur les instances (par ex., histogramme de valeurs)

Informations difficiles et coûteuses à obtenir et à maintenir :publication par les serveurscollecte dynamique (requêtes SPARQL) par les clients (cache)

Problème : manque de standard de publication.

345 / 357

http://thedatahub.org

M2 Informatique DAC – ASWS 2018/2019 – Systèmes RDF fédérés – Exemple : SPLENDID Bernd Amann

4 - Systèmes RDF fédérés

LOD et SPARQL endpointsExemple : SPLENDID

346 / 357


Évaluation de requêtes

catalogue de sources/données : statique ; format VOIDsélection des sources : schema index, requêtes ASKoptimisation de requêtes (modèle de coût)exécution de requêtes : bind join, hash join

347 / 357


Sélection de sources

IP : propriétés→ sourcesIt : types (classes)→ sourcesrésultat : motif de triplet→ sources

348 / 357


Évaluation de motifs de graphes I

Algorithme général

Entrée : un motif de graph P = {t1, ..., tn} où chaque motif de triplet ti estlié à un ensemble de sources D(ti) ⊆ D :

Étapes :1 décomposition : générer des partitionnements Π de P × D en couples

(Pi ,Dj ) où Pi est un sous-graphe connexe (pas de produits cartésiens) etévaluée par la source Dj .

2 pour chaque couple (pi ,Dj ) dans la décomposition Π : évaluer pi sur Dj etjoindre localement avec le résultat intermédiaire

3 résultat : union des résultats partiels obtenus dans les deux étapesprécédentes

349 / 357


Optimisation de requêtes fédérées

Optimisation de requêtes

trouver des décompositions efficaces (qui calculent le résultat correct)chaque décomposition représente un plan de jointure avec des sourcesdistantes

Problèmes liés à la distribution

coût d’évaluation dominé par le coût de communicationréduire le nombre de sous-requêtes évaluées à distanceréduire la taille des résultats intermédiaires

modèle d’estimationprécision de méta-données/statistiques limitéejointures : estimation des coûts et des tailles des résultats difficiles(variables dépendantes)

350 / 357


Optimisation : Stratégies de décompositionDécomposition complète

évaluer chaque motif ti sur toutes ses sources D(ti)inefficace : beaucoup de requêtes et de résultats redondants

Décomposition par groupes exclusifs

hypothèse : certains motifs sont couvertes par une seule sourceregrouper les motifs de triplets qui sont couvertes par une seule source

Regroupement par ressources (sujets)

hypothèse : pour chaque ressource (sujet) il existe une source qui couvre toutes ses propriétésregrouper les motifs partageant le même sujet (star queries) et choisir les sources partagées partous ces motifsrésultats potentiellement incomplets (hypothèse trop forte)

Regroupement owl:sameAs

hypothèse : les sources sont connectées uniquement par des liens owl:sameAsregrouper les motifs de triplets (?y owl:sameAs ?z) avec tous les autres motifs contenant lavariable ?y et choisir les sources partagées par tous les motifsrésultats potentiellement incomplets (hypothèse trop forte)

351 / 357


Optimisation : Jointures distribuées

Objectif

Réduire la taille des données échangées entre le site local et le sitedistant.

Opérateurs de Jointure distribués

semi-join : envoyer uniquement les valeurs de jointure au site distantbloom-join : envoyer un filtre Bloom qui encode les valeurs de jointureau site distantbind-join : nested-loop avec passage de liaisons de variables

352 / 357

M2 Informatique DAC – ASWS 2018/2019 – Bibliographie – Bernd Amann

Bibliographie I1 D. Abadi, A. Marcus, S. Madden and K. Hollenbach. SW-Store : a

vertically partitioned DBMS for Semantic Web data management.VLDBJ 18(2), 2009.

2 Marcelo Arenas, Jorge Pérez, Querying semantic web data withSPARQL, Proceedings of the thirtieth ACM SIGMOD-SIGACT-SIGARTsymposium on Principles of database systems, June 13-15, 2011,Athens, Greece

3 Bornea, Mihaela A., Julian Dolby, Anastasios Kementsietsidis, KavithaSrinivas, Patrick Dantressangle, Octavian Udrea, and BishwaranjanBhattacharjee. Building an Efficient RDF Store over a RelationalDatabase. In Proceedings of the 2013 International Conference onManagement of Data - SIGMOD ’13, 121. New York, New York, USA :ACM Press, 2013.

4 Aluc, Günes, Tamer M. Ozsu, Khuzaima Daudjee, and Olaf Hartig.Executing Queries over Schemaless RDF Databases. Proceedings -International Conference on Data Engineering 2015-May (2015) :807-818.

353 / 357


Bibliographie II

5 Chebotko, Artem, Shiyong Lu, and Farshad Fotouhi. SemanticsPreserving SPARQL-to-SQL Translation. Data & KnowledgeEngineering 68, no. 10 (October 2009) : 973-1000.

6 Goasdoué, François, Zoi Kaoudi, Ioana Manolescu, Jorge-ArnulfoQuiané-Ruiz, and Stamatis Zampetakis. CliqueSquare : Flat Plans forMassively Parallel RDF Queries. In 2015 IEEE 31st InternationalConference on Data Engineering, 771-782. IEEE, 2015.

7 C. Guttierez, C. Hurtado, A. Mendelzon, Foundations of Semantic WebDatabases, PODS 2004

8 Harth, Andreas, Katja Hose, and Ralf Schenkel. Database Techniquesfor Linked Data Management. In Proceedings of the 2012 ACMSIGMOD International Conference on Management of Data, 597-600.ACM, 2012.

9 Huang et al : Scalable SPARQL Querying of Large RDF Graphs. VLDB2011

354 / 357


Bibliographie III

10 Kaoudi, Zoi, and Ioana Manolescu. RDF in the Clouds : A Survey. TheVLDB Journal 24, no. 1 (2015) : 67-91.

11 Andrés Letelier, Jorge Pérez, Reinhard Pichler, Sebastian Skritek, Staticanalysis and optimization of semantic web queries, ACM Transactionson Database Systems (TODS), v.38 n.4, p.1-45, 2013.

12 H. Naacke, O. Curé, B. Amann, SPARQL query processing with ApacheSpark, arXiv preprint arXiv :1604.08903

13 T. Neumann and G. Weikum. RDF-3X : a RISC-style engine for RDF.VLDBJ 19(1), 2010.

14 Özsu, M. Tamer. A Survey of RDF Data Management Systems.Frontiers of Computer Science, 2016, 1-15.

15 Reinhard Pichler, Sebastian Skritek, Containment and equivalence ofwell-designed SPARQL, Proceedings of the 33rd ACMSIGMOD-SIGACT-SIGART symposium on Principles of databasesystems, June 22-27, 2014, Snowbird, Utah, USA.

355 / 357


Bibliographie IV

16 Schätzle, Alexander, Martin Przyjaciel-Zablocki, Simon Skilevic, andGeorg Lausen. S2RDF : RDF Querying with SPARQL on Spark. arXivPreprint arXiv :1512.07021, 2015. http ://arxiv.org/abs/1512.07021.

17 Schmidt, Michael, Michael Meier, and Georg Lausen. Foundations ofSPARQL Query Optimization. In Proceedings of the 13th InternationalConference on Database Theory - ICDT ’10, 4. New York, New York,USA : ACM Press, 2010.

18 Petros Tsialiamanis, Lefteris Sidirourgos, Irini Fundulaki, VassilisChristophides, Peter Boncz, Heuristics-based query optimisation forSPARQL, Proceedings of the 15th International Conference onExtending Database Technology, March 27-30, 2012, Berlin, Germany

19 Lei Zou, M. Tamer Özsu, Lei Chen, Xuchuan Shen, Ruizhe Huang,Dongyan Zhao, gStore : A Graph-based SPARQL Query Engine, VLDBJournal, 23(4) : 565-590, 2014.

20 Sun et al. Scalable RDF Store Based on HBase and MapReduce.ICACTE 2010

356 / 357


Bibliographie V

21 G. Ladwig et al. CumulusRDF : Linked Data Management on NestedKey-Value Stores. SSWS 2011

22 R. Stein et al : RDF On Cloud Number Nine. NeFoRS 2010

23 Kaoudi, Zoi, and Ioana Manolescu. Cloud-Based RDF DataManagement. In Proceedings of the 2014 ACM SIGMOD InternationalConference on Management of Data, 725-729. ACM, 2014.

24 Görlitz, O. (2015). Distributed Query Processing for Federated RDFData Management.

357 / 357

M2 Informatique – DAC – ASWS...

Documents

Transcript of M2 Informatique – DAC – ASWS...