# SPARQL2 Flink: Evaluation of SPARQL Queries on Apache Flink
## 7 Conclusions and Future Work  
We have presented an approach for transforming SPARQL queries into Apache Flink programs for querying massive static RDF data. The main contributions of this paper are the formal definitions of the Apache Flink's subset transformations, the definition of the semantic correspondence between Apache Flink's subset transformations and the SPARQL Algebra operators, and the implementation of our approach as a library. For the sake of simplicity, we limit to SELECT queries with SPARQL Algebra operators such as Basic Graph Pattern, AND (Join), OPTIONAL (LeftJoin), PROJECT, DISTINCT, ORDER BY, UNION, LIMIT, and specific FILTER expressions of the form (_variable operator variable_), (_variable operator constant_), and (_constant operator variable_). The operator within FILTER expression are logical connectives (\(\&\&,\|\)), inequality symbols (\(<,\leq,\geq,>,\cdot\)), and equality symbol (=). Our approach does not support queries containing clauses or operators FROM, FROM NAMED, CONSTRUCT, DESCRIBE, ASK, INSERT, DELETE, LOAD, CLEAR, CREATE/DROP GRAPH, MINUS, or EXCEPT. This work is the first step towards building up a Hybrid (batch and streaming) SPARQL query system on a Big Data scalable ecosystem. In this respect, the preliminary scalability tests with SPARQL2 Flink show promising results in the processing of SPARQL queries over static RDF data. We can see that in all cases (i.e., Figures 2 and 3), the _query execution time_ decreases as the number of nodes in the cluster increases. However, improvements are still needed to optimize the processing of queries. It is important to note that our proposed approach and its implementation did not apply any optimization techniques. The generated Flink program process raw triples datasets. The static RDF dataset used in our approach is serialized in a traditional plain format called N-Triples, which is the simplest form of the textual representation of RDF data but is also the most difficult to use because it does not allow URI abbreviation. The triples are given in subject, predicate, and object order as three complete URIs separated by spaces and encompassed by angle brackets (\(<\) and \(>\)). Each statement is given on a single line ended by a period (.). This approach results in a painful task requiring a great effort in terms of time and computational resources. Performance and scalability arise as significant issues in this scenario, and their resolution is closely related to the efficient storage and retrieval of the semantic data. Loading the raw triples to RAM significantly affects the dataset loading time (dlt), as can be seen in Table 4, more specifically, in the column labeled dlt. This value increases as the size of the dataset increases as well. For example, for the dataset with 69,494,080 triples, the loading time value is 938 s, using 4 nodes of the local cluster, when processing the Q1 query. This is because the SPARQL2 Flink library does not yet implement optimization techniques. In future works, we will focus on two aspects: optimization techniques and RDF stream processing. We will study how to adapt some optimization techniques inherent in the processing of SPARQL queries like HDT compression [55; 56; 57] and multi-way join operators [58; 59]. For RDF stream processing, we will extend the PACT Data Model to describe a formal interpretation of the data stream notion, the different window types, and the windowing operation necessary to establish an encoding to translate CQELS-QL [60] queries to DataStream PACT transformations. In practice, the DataStream API of the Apache Flink comes with predefined window assigners for the most common use cases,