This paper discusses one of the most significant challenges of large-scale RDF data processing over Apache Spark, the relational schema optimization. The choice of RDF partitioning techniques and storage formats using SparkSQL significantly impacts query performance. The impact of the relational schemas and the underlying data storage formats is indisputable; they significantly afect the query performance. Nevertheless, the trade-ofs in different configurations have not been a subject of intensive study in the literature. This paper presents an in-depth investigation for practitioners to understand such trade-ofs and their best practices. It also reports on the pitfalls behind the implementation SPARQL optimizations over SparkSQL. Our experiments provide insights into these schemas' relative strengths by comparing three diferent partitioning techniques and four other storage formats. Our results draw a better understanding of the current State-Of-The-Art (S.O.T.A) and pave the way for a wide range of best practices and systematically tuning the performance of distributed systems to handle vast RDF data.
Currently, we are witnessing an enormous amount of widely
available RDF datasets [
BD platforms excel in the analytical processing of relational
data. The literature includes several attempts that leverage such
capabilities to analyze RDF data [
In this paper, we try to fill this research gap by
experimentally evaluating SPARQL on top of SparkSQL. In particular, our
analysis focuses on existing RDF relational schemas and their
state-of-the-art improvements. To this end, we present a
systematic and comparative evaluation of the query performance
considering (i) ℎ RDF partitioning techniques (most
suitable for relational nature of data in Spark-SQL), i.e., Horizontal,
Subject-based, and Predicate-based partitioning and (ii)
different well-established storage formats, i.e., ORC, CSV, Parquet,
and Avro [
The contribution of this paper is threefold. (i) First, it uses SparkSQL to validate the performance of RDF schema advancements (i.e. ExtVP and WPT ) compared to their baseline opponents (i.e PT, and VP). (ii) Second, it empirically analyzes the efect of partitioning techniques on the ExtVP and WPT schema runtime performance. (iii) Third, it tests the efects of multiple distributed storage row and columnar-oriented file formats on HDFS. Finally, it outlines the best practices and recommendations that help in achieving the best RDF query performance. Overall, the paper findings guide the realization of next-generation large-scale RDF solutions over Apache Spark by optimizing the relational schemas.
The remainder of the paper is organized as follows: section 2 presents an overview of the required background information and key concepts necessary to understand our study. Section 3 discusses the experimental methodology. Section 4 presents the benchmarking scenario and the experimental setup. Section 5 presents the paper results, while we provide a comprehensive discussion in section 6. Section 7 presents the related work, positioning this paper in the context of other survey on RDF processing using BD frameworks. Finally, section 8 concludes the paper and presents future works. 2
In this section, we present the information that is necessary to understand the content of this paper. We assume that the reader is familiar with the RDF data model and the SPARQL query language. 2.1
Apache Spark is currently the de-facto BD engine [
SparkSQL is a relational package built on top of Apache Spark
[
The most intuitive approach to follow for representing RDF into a relational structure is the Single Statement Table Schema (ST), which requires storing RDF datasets in a single triples table of three columns that represent components of the RDF triple, i.e., Subject, Predicate, and Object. This solution is the simplest, and it is commonly adopted by several existing open-source RDF triplestores, e.g., Apache Jena, RDF4J, and Virtuoso. However, it inevitably increases the number of required self-joins for long chains SPARQL query evaluation when they run on top of relational SQL systems.
age schema proposed to mitigate the performance issues of the ST
schema. It aims to speed up the queries over RDF triple stores [
Extended Vertical Partitioning schema (ExtVP) is a
querydriven optimization that aims at minimizing the input size of
the data during query evaluation [
proposed to cluster multiple RDF properties as n-ary table columns
for the same subject to group entities that are similar in structure.
The biggest advantage of property tables compared to a single
triples table schema (ST) is that they can reduce the number of
subject-subject self-joins that result from star-shaped patterns in a
SPARQL query. Whereas, one of the limitations of the PT schema
is that it works quite well with the highly structured RDF data.
However, its performance degrades for the poorly structured
ones [
RDF dataset into a single unified table [
For RDF data processing, many partitioning techniques exist [
RDF dataset evenly (as much as possible) on the number of machines in the cluster. In particular, we use this technique to partition the relational RDF tables of the diferent schemas horizontally into even chunks(i.e partitions) over the cluster machines.
of triples into partitions according to the hash value computed for the RDF subjects. As a result, all the triples that have the same subject are assumed to reside on the same partition. In our scenario, we applied spark partitioning using the subject as the partitioning key with our diferent relational schema tables (i.e DataFrames).
it distributes triples to the various partitions based on the hash value computed for the predicate. Similarly, all the triples that have the same predicate are assumed to reside on the same partition. We also applied the Spark partitioning using the predicate as the partitioning key with our diferent relational schemas Dataframes.
Baseline partitioning (BP): In our experiments, we also used
the baseline partitioning technique that basically depends on the
native default partitioning of HDFS of the tables files over the
cluster nodes. This is the technique used in the state-of-the-art
works of the schema advancements [
In this section, we discuss the experimental methodology that
we used for the reproducibility of the state-of-the-art findings [
First, we assess if we can reproduce the state-of-the-art
results of those schema optimizations over the baseline relational
schemas performance. Thus, we performed our experiments in
a setup as similar as possible to what the original authors have
done [
Second, we introduce disturbing factors to our experiments, such as the diferent partitioning techniques, and diferent file formats alongside diferent SPARQL query shapes.
Regarding the data partitioning, we introduce the Horizontal Partitioning technique and Subject-based partitioning for the WPT and PT schema experiments.On the other hand, Horizontal, Subject and Predicate-based partitioning techniques were used for the VP and ExtVP schema experiments. We expect that these partitioning techniques will negatively impact the performance of SparkSQL when evaluating SPARQL queries due tothe distribution of the relational table across nodes. This will force more shufling in the presence of joins. In particular, Horizontal partitioning should have a worse impact than Subject-based partitioning on PT and WPT schemas, and Predicated-based on (Ext)VP ones. It worth mentioning that the HP technique does not take the query shape into account and possibly place these rows in diferent nodes.
Regarding the storage of file formats besides the baseline
Parquet, we consider an additional columnar one, i.e., ORC, and two
row-oriented ones, i.e., CSV and Avro. We expect columnar
formats to perform better for the queries with a subset of column
projections, since they allow an eficient scan of tables by reading
only a portion of columns [
Finally, aiming to draft our observations, primary findings, and propose best practices, we discuss and analyze our results. Additionally, we highlight the trade-ofs of combining all these dimensions in the discussion section.
Moreover, we aim to observe these optimizations’ impact on the large SPARQL query performance on the SparkSQL engine. Mostly, we want to verify and answer the following questions: (1) How far do RDF partitioning techniques and storage formats impact the query performance? (2) How can we systematically analyze diferent relational schemas? How can these schemas efectively improved to achieve the highest performance? (3) What are the best practices that guide the large RDF community eforts in adopting performance-oriented solutions?
This section outlines the paper experiment setup and the used
benchmark with its queries. The experimental setups (presented
in Figure 1) summarizes the configuration combinations (
Relational schema, Partitioning, Storage). The triangle with X
represents that we have performed our experiments for 4 diferent
relational schemas, partitioning each schema across 4 various
relational techniques, i.e one baseline HDFS, and other 3
RDFspecific techniques. Last but not least, those schemas are stored
across 4 diferent storage formats. In detail:
Benchmark &Dataset: In our evaluation, we used the SP2Bench
(SPARQL Performance Benchmark) [
Data Storage: We generated a synthetic RDF dataset with 100 triples size in Notation3 format. This scale size is enough for checking the validity of the literature findings regarding the RDF relational schemas optimizations, and maintaining the reproducibility of them in a more complex solution space. VP 8KB-1.9GB -Total: 8.3GB 8KB-272MB -Total: 1.7GB 8KB-249MB -Total: 1.5GB 8KB-264MB -Total: 1.6GB Wide Property
Tables Property
Tables Ext. Vertical
Tables Vertical
Tables Relational Schemata
ExtVP - OS (4.9GB) - SS (39GB) - SO (806MB) -Total:∼45GB - OS (359MB) - SS (8.8GB) - SO (331MB) -Total:∼9.5GB - OS (243MB) - SS (7.8GB) - SO (301MB) -Total:∼8.4GB - OS (319MB) - SS (8.4GB) - SO (318MB) -Total:∼9GB
Baseline
HDFS Horizontal
Based Subject Based Predicate
Based Partitioning Technique
The generated n3 RDF dataset is converted into CSV relational schemas using Jena TDB 1, a disk-based access repository for storing RDF datasets. We further used the Jena ARQ 2 for querying these TDB datasets and generating the output schemas tables in the CSV file format. Finally, these raw textual CSV documents are loaded to the HDFS. Moreover, we have used the Spark framework to write the relational schemas data tables from the CSV format into the other HDFS file formats (Avro, Parquet, and ORC). Table 1 shows the size of the generated native RDF dataset (i.e 11GB), as well as store sizes of each relational schema in the mentioned diferent file formats on top of HDFS. It is clearly shown, how the diferent relational schemas afect the input data sizes.
In action, the PT schema has the smallest table sizes in total, followed by the VP schema, then the WPT table schema. Whereas, the largest storage overheads come with the ExtVP schema. We can also notice how the storage formats afect the sizes of the schemas significantly. In particular, columnar-oriented formats have the minimum table sizes across all the schemas. Indeed, ORC is shown to have the minimum table sizes, followed by Parquet. While, the Avro row-oriented formats have quite larger schema sizes, and CSV has the largest table sizes.
Queries: SP2Bench queries have diferent complexities and a
high diversity of features [
Environment Setup: Our experiments were executed on a baremetal cluster of 4 machines with CentOS-Linux V7 OS, running on 32 cores per node processor, and 128 GB of memory per node, alongside with a high speed 2 TB SSD drive for each node. We used Spark V2.4 to fully support SparkSQL capabilities. In particular, our Spark cluster consists of one master node and 3 worker machines, while Yarn is used as the resource manager, which in total uses 330 GB and 84 virtual processing cores.
RDF Data Partitioning: We used Spark partitioners for partitioning the registered relational schemas tables/Spark DataFrames. This is required to persist those DataFrames on top of the HDFS default file blocks partitioning level. We use the resulting Data Frames as the input for the query engine. In our experiments, we have the baseline HDFS partitioning (grey partitioning box cf. 1). While other RDF partitioning techniques also have been tested, namely HP, SBP, and PBP approaches. These techniques depend on partitioning the tables’ data horizontally across machines (i.e HP), or on the Spark key partitioning of the RDF subject or predicate (i.e SBP, PBP respectively).
Spark.time function by passing the spark.sql(...) query execution function as a parameter to measure the query latency. We run the experiments for all queries 5 times (excluding the first cold start run time, to avoid the warm-up bias, and computed an average of the other 4 run times). 5
In this section, we discuss our experiment results. Also, we compare the optimized relational schemas (i.e., WPT, and ExtVP) against their baseline schemas, i.e., PT, and VP, respectively, according to our methodology (cf. Section 3).
PT WPT 2 0 9 0 2 0 8 3 WPT vs. PT
2/9
2/9
2/9
7
3
CSV
2/9
3/9
2/9
6
3
ORC
8/9
6/9
6/9
9
10
Table 3 shows the SP2Bench queries’ number of joins when
translated into SQL concerning the PT and WPT schemas. Except for
8 (that requires many self-joins of the WPT table), the number
of joins always decreases, adopting the WPT schema. Moreover,
we expect that the WPT schema query performance (i.e., in terms
of latency) will outperform other relational schemas [
Meanwhile, Table 4 shows the overall benchmark results of the WPT performance over PT schema across all file formats (horizontally in the table), and across the diferent partitioning techniques (vertically). Values in this table specify the number of queries in which the WPT schema performs better than the baseline PT schema. The green color indicates that WPT performing the best, while the yellow color indicates that its performance is above 50% over PT, and the red means that performance is less than 50%.
Our experiment results confirm that the WPT schema
performs better than the baseline PT schema in all the queries (i.e., 9
queries out of 9 queries in the benchmark) with Parquet file
format, alongside using the baseline HDFS partitioning technique.
Indeed, these results confirm the findings in [
To investigate how the performance diference between the WPT and PT schemas changes, we introduce two new dimensions, i.e., various file formats and diferent partitioning techniques. In this regard, Table 5 shows the efect of data partitioning ( left of the table) and storage formats (right of the table) considering the other new factors across all the experiments. To this extent, we have calculated the percentages as follows, for the partitioning factor’s impact, we pivoted on each partitioning technique and counted the percentage of how much the WPT schema performance in SparkSQL is better than the PT schema one across all the queries while considering all the changes of the storage file formats (moving across them). We calculated the partitioning effect similarly but pivoting on the storage file format and moving across the partitioning techniques in all of queries.
Table 5 also demonstrates that in such a complex space of diferent relational schema, data partitioning, and storage file formats, the schema-based query optimization is not straightforward. As we can see, WPT outperforms PT schema only for 58% in the queries using only the baseline default HDFS partitioning technique regarding the storage formats, and only 78% for the 3http://dbis.informatik.uni-freiburg.de/index.php?project=SP2B/queries.php 4https://datasystemsgrouput.github.io/SPARKSQLRDFBenchmarking/ avro csv orc avro csv orc csv orc
Parquet Parquet file format. The determination of this result shows the trade-of of considering alternative storage file formats and partitioning techniques alongside the experiments’ query evaluation.
Regarding the storage, we can see that ORC, another columnar ifle format gives closer performance to our baseline columnar Parquet file format with 74%. However, the baseline Parquet is yet better, as Parquet is unlike ORC, can eficiently handle the WPT table’s sparsity. Whereas, we can see that row-oriented formats have a significant negative efect on the performance of WPT. WPT schema performance is better than PT with only 22% and 25% in all Avro and CSV queries, respectively. In action, SP2Bench queries only have one query (i.e., 2) with more than 2 column projections. This justifies why column-oriented formats give better results for the WPT than the row-based ones. In general, we can state that file formats afected the generalization of the state-of-the-art results for the WPT schema.
At last, we enroll in three specific queries, namely, 2, 4, and 8 , which well exemplify our findings. We selected these queries as good representatives of our findings. There is a tremendous performance enhancement in WPT over PT in 2 and 4. The reason behind this refers to the number of SparkSQL joins of WPT is significantly less than the joins in PT schema (cf. Table 3). Particularly, in 2 number of joins in PT (SQL-version) is 9 compared to no-joins in WPT schema. While in 4 with PT schema, we have 8 SQL joins in comparison to 3 self-joins of the WPT table. Interestingly, we have more joins in WPT than the baseline PT schema in 8, i.e., 10 self-joins, and 8 joins, respectively. Figure 2 (a), (b) and Figure 3 depict the performance of SparkSQL for 2, 4, and 8 respectively under a various combination of file formats and partitioning techniques. In particular, these figures combine the ratios of WPT being better than PT in those mentioned queries. Ratios less than 1 indicate better performance of WPT over PT in that query and across the diferent configuration settings.
Not surprisingly, we can notice that 8 is the only query that witnesses worse performance for the WPT compared to the PT schema. Figure 3 shows that most of the ratios of ’WPT over PT’ is greater than 1 in the baseline-partitioned data experiments (i.e. only partitioned with HDFS), and other file formats instead of Parquet. Notably, all the results (i.e., total query runtimes) and query histograms can be found on our mentioned GitHub repository.
According to [
VP ExtVP Input tables data Size Red.
Q1 2 2 58% Q2 9 9 77% Q3 1 1 59% Q4 7 7 96% Q5 5 5 60% Q6 9 9 31% Q8 9 & 1 Union 9 & 1 Union 5% Q9 2 & 1 Union 2 & 1 Union 0% Q10 1 Union 1 Union 0%
Q11 0 0 0%
Table 6: Number of joins and percentage of input tables
sizes [Red]uctions after optimization ExtVP VS. VP.
1.4
VP 1.2
rvoe 1
PV 0.8
txE 0.6
foo 0.4
i
taR 0.2
0
1.4
VP 1.2
rveo 1
PV 0.8
txE 0.6
foo 0.4
i
taR 0.2
0
avro
csv
orc
avro
csv
orc
In more details, ExtVP optimizes specific queries according
to the correlations between triple patterns in those queries [
The same approach that has been adopted in WPT to PT schemas performance comparison is also used for evaluating the performance of ExtVP against the VP.
First, we check if our experiments’ results confirm the stateof-the-art regarding the ExtVP schema optimization over the baseline VP schema performance.
Table 7 (on the right) shows the total number of queries in
which the ExtVP performance is better than VP schema
performance across all the benchmark queries. For our baseline HDFS
partitioning technique, and with the Parquet file format, we can
see that some queries do not benefit from the optimizations of
the ExtVP. Indeed, 3 out of 10 queries fail to utilize the optimized
ExtVP technique. The reason behind such behavior is that those
queries have unbounded predicates that can not be optimized
by the ExtVP schema [
Second, similarly to what we have done for the WPT schema optimization, we now investigate how generalizable the stateof-the-art results are when we introduce diferent file formats partitioning techniques over the data for both the ExtVP and VP schemas.
Similarly, Table 8 shows how far the data partitioning (left of the table) and data formats (right of the table) impact the results of ExtVP in comparison to VP schema performance. Notably, this table’s percentage values are also calculated similarly to how we have calculated the WPT against the PT. We pivoted on the analysis dimension of choice, i.e., file format or partitioning technique , and we calculated how many times SparkSQL performs better using ExtVP than using the baseline VP approach.
Regarding the partitioning techniques’ efect on ExtVP, our expectations are confirmed. In particular, we can observe that the partitioning techniques degraded the performance of ExtVP significantly. Only, 35%, and 30% of the experiments adopting Horizontal, and Subject-based partitioning respectively show a performance improvement in using ExtVP over VP. Adopting
Baseline_Part 6/10 6/10 5/10 7/10 Horizontal_Part 3/10 3/10 3/10 3/10 Predicate_Part 2/10 3/10 6/10 6/10 Subject_Part 2/10 3/10 3/10 3/10 Table 7: Comparison of ExtVP schema with the VP schema in diferent storage formats, and in diferent partitioning techniques.
Baseline_Part Horizontal Predicate-bsed Subject-based 67.5% 35% 55% 30%
Parquet ORC AVRO CSV 55% 45% 42.5% 42.5% Predicate-based partitioning slightly reduces this negative efect (i.e., 55% of the queries show that performance improvement).
From Table 8, we can also see that the ExtVP schema is only outperforming the VP schema, with 67% of the queries using the baseline HDFS partitioning scenario. Thus, we can see the trade-of of considering various storage file formats. We can see also that the baseline Parquet file format is the one that has less impact on the overall performance for ExtVP. Indeed, in 55% of the cases where Parquet is used, ExtVP outperforms the VP performance. Additionally, the ORC columnar file format provides high performance of ExtVP over VP schema with an overall 45%. However, there is a clear diference from the Parquet ifle format with 10%.
On the other hand, the row-oriented formats degrade the performance of ExtVP. For only 42.5% of the experiments that adopt either Avro or CSV, ExtVP performance beats the performance of the VP schema. Such behavior is related to the number of column projections in the SP2Bench queries, which are the minimum in this benchmark scenario. Thus, columnar file formats can fit such query workloads better than the row-oriented ones.
Last but not least, herein the most notable query examples are introduced, confirming our previous findings but with more innumerable details. First, 4 is revealed to be the query with the most benefit with the ExtVP optimization. The reason behind this is that 4 includes a high number of joins (i.e., 7 joins), and has the maximum number of input tables’ rows reductions while using the ExtVP schema optimization with 96% of reduced processed rows (cf. Table 6). This query is directly followed by 2 with 77%. Although 2 has a higher number of table joins WPTH
PTH Q1 Q2 Q3 Q4 Q5 Q6 Q8 Q10 Q11 Q1 Q2 Q3 Q4 Q5 Q6 Q8 Q10 Q11 Q1 Q2 Q3 Q4 Q5 Q6 Q8 Q10 Q11 (a) CSV - Horizontal Partitioning (b) CSV - Subject-based Partitioning (c) Avro - Horizontal Partitioning WPT
PT WPT
PT WPT
PT Q1 Q2 Q3 Q4 Q5 Q6 Q8 Q10 Q11 Q1 Q2 Q3 Q4 Q5 Q6 Q8 Q10 Q11 Q1 Q2 Q3 Q4 Q5 Q6 Q8 Q10 Q11 (d) Avro - Subject-based Partitioning (e) ORC - Horizontal Partitioning (f) ORC - Subject-based Partitioning WPT
PT WPT
PT
Q1 Q2 Q3 Q4 Q5 Q6 Q8 Q10 Q11
Q1 Q2 Q3 Q4 Q5 Q6 Q8 Q10 Q11
(g) Parquet - Horizontal Partitioning
(h) Parquet - Subject-based Partitioning
than 4, the reductions in input table sizes in 4 are more
significant. On the other side, 9, 10, and 11 do not benefit from
the ExtVP optimization, i.e., ExtVP does not provide any input
table size reductions. In particular, 9 and 10 have unbounded
predicate variables in the original SPARQL queries. ExtVP cannot
directly handle this type of queries[
In the next section, we discuss in further details the experiment ifndings against the current S.O.T.A regarding the superiority of ExtVP and PT.
The paper helps to characterize and classify the RDF schemas and their optimizations within the SparkSQL realm. It helps data architects and practitioners interested in large scale RDF better understanding the relational RDF schema’s potential using diferent partitioning techniques and storage formats. This understanding will lead to a better selection of the most suitable and performance-optimized solution that adequately suits their case. Doing so will also accommodate better design and development of new SPARQL systems, leading to reliable RDF services with high Spark performance. Taking our experiment findings into consideration, herein, we discuss our results and give some insights on processing RDF best practices at a large scale.
Next, we place the literature assumptions on the relational schema optimizations’ superiority against our experimental findings. We follow this by recommendations to the large RDF practitioners.
According to [
The state-of-the-art findings of the WPT schema are fully reproduced with the default HDFS partitioning and with using the baseline Parquet file format. That is, the performance of Spark using WPT schema for representing RDF dataset is always outperforming the baseline PT schema.
Nevertheless, our results show when we deviate from the
original setup [
ExtVP
ExtVP
VP (j) CSV-Horizontal Partitioning (k) CSV-Subject-based Partitioning (l) CSV-Predicate-based Partitioning optimizations. Only 78% of the queries results conform with the fact that WPT is better than the PT schema (Table 5).
Figure 5 aims to analyze the schemas performance when the solution adopts diferent partitioning techniques and file formats. Figures 5 (a-h) show clearly the efect of partitioning techniques on the reproducibility of the WPT optimizations across all the different file formats. For instance, notably the horizontal partitioning (Figures 5 (a,c,e,g)) afected the performance of WPT, making its performance in SparkSQL worse than the baseline PT schema in most of the queries (i.e., 1,3,5,6,8,11). Similarly, we can observe the negative efect of the subject-based technique on WPT schema (Figures 5 (b,d,f,h)) in the same queries.
The impact of file formats aside Parquet is even worse. Even using the baseline (HDFS) partitioning technique afects the reproducibility of the WPT schema optimizations. Overall, only 58% of the query results conforming with the fact that WPT is outperforming PT schema (Table 5). The experiments show that columnar file formats, e.g., ORC, and Parquet, are the best for representing such wide tables (WPT and PT). Columnar file formats are the best for sparse queries (i.e., queries with few column projections or columns to access) out of the wide tables. They perform better than the row-oriented file formats, e.g., CSV and Avro, which would be only better with queries that require full rows reading.
Figure 5 shows the performance degradation considering different file formats. For instance, moving from Parquet and ORC in Figures 5 (e-h) to other row-oriented file formats such as Avro and CSV in Figures 5 (a-d), we can notice the performance degradation of the queries with the WPT schema optimizations.
According to [
Based on our experiments, the findings of the ExtVP schema are not fully reproduced, even considering the default HDFS partitioning and the baseline Parquet file format. Some queries do not benefit from the ExtVP optimizations ( 9, 10, 11), notable input size reductions occurred in those queries), cf. Table 6. Beyond those queries, we can confirm that the state-of-the-art results (ExtVP performs better than VP in most cases). However, our results show that the schema-based query optimization is not straightforward in such a complex solution space.
Regarding the partitioning techniques, using an alternative to the baselines technique (HDFS) afects the reproducibility of the ExtVP optimizations even if the storage format is Parquet. Only 55% of the queries results show that ExtVP is superior to the VP schema (cf. Table 8). Moreover, Figure 6 shows the efect of other RDF partitioning techniques on the reproducibility findings of the ExtVP optimization. For instance, deviating from the baseline partitioning technique to other RDF-based techniques with the same baseline Parquet, i.e., Figures 6(a-c) degrades the results of ExtVP and makes it perform worse than the baseline VP schema in several queries (1, 4, 5, 6, 8) with the Horizontal and Subject-based partitioning. The predicate-based partitioning in Figure 6(c) has a better performance with this schema, which has performance close to VP’s in the previously-mentioned queries.
Similarly, using storage formats diferent from Parquet afects the ExtVP optimizations’ reproducibility, even with the baseline (HDFS) partitioning technique. Indeed, we have only 67.5% of the queries results of ExtVP outperforming VP (cf. Table 8). Similarly, Figure 6 shows the efect of other file formats other than the baseline Parquet, i.e Figures 6 (d-l) for ORC, Avro, and CSV respectively. We can notice the queries’ performance degradation with the ExtVP schema optimizations moving vertically to these other formats.
Finally, from our experiments, we observe that columnar file formats are better than the Row-oriented ones. However, the performance diference is not significant with such similar schemas. The table structure is the same table of two columns Predicate (Subject-Object) in both vertical schemas. Moreover, both schemas have not wide tables in comparison to the WPT and PT schemas. That is, these schemas will not benefit a lot from the columnar file formats. The performance gain of columnar over the row-oriented file formats is because SP 2Bench queries have a
Where ✓is good practice, X is bad practice, and ˜ has the same performance compared to VP.
* ExtVP had a very competitive performance few numbers of column projections. Thus, it would work better with columnar rather than row-based file formats. 6.3
Overall, Tables 9 and 10 provides an abstracted map of good and bad storage format and partitioning techniques.
The results in Figure 5 and Table 9, show that partitioning the WPT table has, in the majority, a negative efect on the WPT optimization, making it perform even worse than its baseline approach, i.e, the PT schema. The efect of the storage formats is more significant in the WPT optimization (cf. Tables 5, 9). Therefore, this WPT schema’s storage format selection decision should be dealt with as a first-class citizen in such experiments.
The horizontal and subject-based partitioning techniques are not recommended with ExtVP optimization. However, Predicatebased still gives better results than those two other RDF partitioning techniques (cf. Tables 8 and 10). Also, columnar file formats are still recommended with the ExtVP schema optimization. However, it was noticed that the efect of the partitioning is more significant to this optimization (cf. Figure 6, Tables 8, and 10). Thus, the partitioning selection decision of this ExtVP schema should be highly considered in these experiments.
Also, our analysis yields the following recommendations (1) With WPT, it is recommended to use the columnar storage formats rather than row-oriented ones (cf. Table 9). (2) With the WPT schema, Parquet is yet the best columnar ifle format to select, it eficiently handles its sparsity. (3) With WPT, it is recommended to use the native HDFS partitioning, rather than selecting an RDF-oriented partitioning technique. (4) With ExtVP, the baseline HDFS partitioning is more recommended than specific RDF ones. However, larger datasets would require partitioning anyway. (5) With ExtVP, the columnar file formats is a recommended optimization. 7
In this section, we present the related work. In particular, we focus
on comparative studies that investigate the use of BD frameworks
for distributed RDF processing. To the best of our knowledge,
the literature includes several studies that compare partitioning
techniques, relational schemas, and storage formats [
Abdelaziz et al. [
Arrascue et al. [
Cossu et al. [
On another side, Pham et al. results in [
Finally, Akhter et al. [
The reproducibility of well-known relational RDF processing optimizations is critical to foster best practices that guide the practitioners’ eforts. In this paper, we presented a comprehensive empirical evaluation using three RDF partitioning techniques and four storage formats over the distributed SparkSQL engine to cope with this limitation. Our analysis demonstrates decisively variant trade-ofs using diferent relational schemas, data partitioning, and storage file formats against these state-of-the-art optimizations. Our experiments show significant degradation in Spark performance when partitioning by subject in the WPT and partitioning horizontally due to the vast, sparse, and large partitions of its schema table. On the same note, the storage format also afects the WPT performance, where ORC and Parquet are the most suitable representation of such configuration. Our results on ExtVP illustrate that schema-based query optimization is not straightforward using diferent configurations.
Future work includes extending this study by analyzing the impact of data scalability on SparQL performance. We intend to utilize other RDF benchmarks such as WatDiv with diferent types of query shapes and complexities. Our plans include investigating this area further to design a benchmark that combines query workloads with precise partitioning and storage instructions.