In the era of the ever growing semantic data flood, the challenge of processing declarative queries (or reasoning) over rich and massive RDF data streams remains of major importance. The trade-off between language expressiveness and system scalability (E&S) has been identified as a main issue in RDF stream reasoning. In the first place, stream processing must be efficient enough to ingest data at the throughput and latency imposed by the incoming data streams. Besides, the query language has to be expressive enough to support temporal logic and reasoning that may require recursion. In order to cope with the first aspect, distributed systems supporting fault tolerance, automatic task distribution and recovery are generally involved. Considering the second aspect, Datalog and ASP programs seem to fit efficiently since they represent a good balance between expressive power, safety, performance and usability. Note that considering such an expressiveness permits to address ontology languages such as OWL2RL. This work is not limited to demonstrate that the E&S trade-off is reachable but we would also like to emphasize that such a solution can be implemented with open-source, state-of-the-art big data technologies, hence being a prototype for production-ready systems.
Thus the BigSR system addresses important problems that are being met frequently in modern applications. For instance projects like Waves111https://www.waves-rsp.org/ (French FUI), SEAS222https://www.the-smart-energy.com (European ITEA2), Optique333http://optique-project.eu/ (European FP7) and many others require to process data streams with rich semantics in close to real time. At the same time, industrial systems based on Datalog , , datomic444www.datomic.com are emerging. It hence makes sense to mix these two features in a single framework to fulfill an emerging kind of systems.
Available stream reasoning systems [17, 22, 9] chose a centralized design to benefit from existing ASP solver such as Clingo . The system scalability is apparently limited by single machine/process. Actually, high expressive queries often involve recursion or complex temporal logical operators, which are considered as the main performance bottlenecks for stream reasoning. Additionally, The optimization tailored for static query evaluation e.g., data indexing, data preprocessing neither meet the real-time nor the defined temporal logical requirements. And distributed environment often retains shared-nothing context. The memory of different data partitions are isolated, some advanced optimization for Datalog program materialization  can be hardly applied.
Although it may have many obstacles to apply distributed computing technique on stream reasoning, relevant in-depth research is still missing. In this paper we first introduce our technical demonstrator, namely BigSR. BigSR possesses two broad classes of streaming models: Bulk Synchronous Processing (BSP) and Record-at-A-Time(RAT) to cover a wide variety of use cases. We implement BigSR on Apache Spark Streaming  and Apache Flink  to support our evaluations.
Our key contributions are as follows: (1) we build a connection between recent theoretical works on RDF stream reasoning to the state of the art Big Data technologies. We also first try to combine stream reasoning (with complex temporal logics and recursion) with distributed computing. (2) We implement a reusable prototype to support a positive fragment of LARS framework on two distributed systems, namely Apache Spark and Apache Flink. (3) We identify the pros and cons of BSP and RAT on E&S for different scenarios, respectively. (4) We conduct a series of experiments from variety datasets, and through our experiments we prove that both E&S can be achieved with distributed solution.
2 Background Knowledge
We begin by giving the basic notions of LARS. Next, we describe the general methodologies to parallelize the evaluation of Datalog programs and their relations to LARS. Finally, we introduce two representative distributed streaming systems, i.e., Spark Streaming and Flink with their own streaming models BSP and RAT, respectively. We assume the readers are familiar with the basic notions of Datalog, e.g., , intensional and extensional databases (resp. IDB and EDB), stratification, recursion .
2.1 LARS Framework
LARS  is a rule-based logical framework defined as an extension of Answer Set Programming (ASP) which we are using as a theoretical foundation. Systems like Ticker and Laser are also based on LARS. For the sake of briefness, we only list some basic definitions and the LARS formal syntax that we use in our system.
Assume an atom set , where is a set of intensional atoms and a set of extensional atoms disjoint from . In this paper, a term starting with a capital letter refers to a variable, otherwise it is constant.
Definition 1 (Stream).
A stream is a pair , where is a timeline interval in , and is an evaluation function such that for .
A stream is a substream of , if , and for all ,.
Definition 2 (Window function).
A window function takes a stream as input and returns a substream , where . where , , . selects the most recent atoms in the time points.
Definition 3 (Time-based Window).
Consider a stream , and a pair . A time-based window returns the substream of contains all the elements of the last time units, and slides with step size .
LARS distinguishes two types of streams - and . represents the currently considered window , and is called fixed input stream. To meet the real-time feature, we consider that as the type of input stream. I.e., we do not assume that the system is capable to load the stream , from to directly.
Definition 4 (Window operators).
Let be a window function. The window operator signifies that the evaluation should occur on the delivered stream by window function .
We consider the set of extended atoms by the grammar: , where and is a time point. The formula means holds in the current window , if holds at some time point in . The window operator signifies that the evaluation should occur on the delivered stream by window function .
Definition 5 (Rule and program).
An expression of the form is called a LARS rule. where is an atom and are extended atoms. A (positive plain) LARS program is a set of LARS rules.
The semantics of LARS programs is given by the notion of answer stream. For a positive LARS program, its answer stream is unique.
2.2 Parallel Datalog evaluation
Before illustrating the distributed stream reasoning in BigSR, we summarize the three Parallelism Levels (PL) mentioned in  for parallel instantiation of Datalog programs.
(PL1) Components level. Consider a stratified Datalog program and its dependency graph . can be split into subprograms where each subprogram is associated to a strongly connected component (SCC) of . In accordance with the topological order of , we can identify the subprograms that can be executed in parallel.
(PL2) Rules level. When recursion occurs in , is evaluated through bottom-up semi-naive algorithm  be evaluated concurrently.
(PL3) Single Rule level. Consider a program where contains a limited number of rules. As a result, is neither benefiting from PL1 nor PL2. In this situation, the idea is to divide a single rule instantiation into a number of subtasks. All the subtasks are able to run independently.
Computing the answer stream of a positive LARS program can be regarded as evaluating a Datalog programs at each time point. PL1, PL2 and PL3 are thus enabled to be applied in LARS program.
2.3 Streaming Models: BSP and RAT
Streaming Models. In general, two broad classes of execution models exist in distributed stream processing frameworks: BSP and RAT. The representative streaming systems with BSP model like Spark Streaming, Google Dataflow  buffer and process data by batch. BSP organizes the communication between processes and synchronizes the data processing across records by setting barriers at the end of each batch. On the contrary, RAT systems like Flink  and Storm  handle data processing record by record, where operators are regarded as long running tasks, which rely on mutable local states. The computation is done through the data flowing from one operator to another. We choose Spark and Flink as the underlying systems of BigSR, which correspond to BSP and RAT, respectively. Both systems ensure fault tolerance, automatic work distribution and load balancing.
Spark is a MapReduce-like distributed computing framework. The computation is based on Spark’s native data structure, namely, Resilient Distributed Dataset (RDD). An RDD is distributed into multiple partitions across different machines and thus enables operations to be performed in parallel. Spark Streaming is one of the main extension of the Spark engine. Spark Streaming processes data streams by cutting input data into batches which are represented as DStream (sequence of RDDs). The online streaming job is treated as a sequence of bounded batch jobs. To simplify, we denote Spark Streaming as Spark in the rest of this paper.
Flink is another distributed stream processing engine. Different from Spark Streaming, Flink relies on continuous processing model where the data operations are processed over unbounded dataset. Flink continuously processes and produces incoming data stream.
Before we present the implementation details of BigSR, we use an example to demonstrate a fundamental difference between BSP and RAT. Considering a program , Figure 1 roughly gives a runtime example of on Spark (Figure 1(a)) and Flink (Figure 1(b)). Spark processes the data stream synchronously, the next query execution will be launched after the previous one is finished. Conversely, Flink serializes, caches, and pushes forward each record to the next operator eagerly right after the current computation is done. Such behavior minimizes the data processing delay, and operators are able to perform asynchronously. In Figure 1, although Spark uses 3 nodes to compute the second part of every query with higher parallelism than Flink, it still needs some time for synchronization between two jobs. Thus, within 9 time units, Flink is able to finish 5 continuous queries while Spark is only able to process 3 queries during this same period of time. This clearly showcases a better use of computing resources in favor of Flink.
Even LARS dose not include any notion of state, to build the connection between LARS and Spark/Flink’s execution model, we define stateful and stateless operator as following: A stateless operator over a stream transforms a stream into another stream. In contrast, a statefull operator is a function which takes a pair of a stream and a state, and returns another pair of stream and state. In other words, the data processing in stateless operator only looks up current record. The evaluation of stateful operator requires system to hold an internal state, e.g., use local memory or external database for window operator, etc.
3 Distributed RDF Stream Reasoning
In this section, we start with a description of the BigSR system architecture. Then, using a query example, we discuss the approaches used to handle distributed RDF stream reasoning based on the BSP and RAT models. Finally, some implementation details on Spark and Flink are provided.
3.1 Architecture of BigSR
Figure 2 gives a high-level view of the BigSR architecture. It consists of three principal modules: (i) Data-feed is built on top of Apache Kafka (a distributed message queue) and ensures high throughput and fault-tolerant data stream injection/management; (ii) Sink persists query outputs into a storage component such as Amazon S3, HDFS or even Kafka; (iii) Computing core first registers and compiles a given LARS program into BigSR’s logical execution plan. Then, the system binds the obtained logical plan to the physical operators of Spark (Streaming) or Flink for real-time distributed RDF stream reasoning.
BigSR comes with a LARS/stream reasoning DSL language. Listing 1 showcases a query example from the SRBench dataset. The query grammar follows a general datalog program writing style. For instance on line 2 of Listing 1, atom_tp2 denotes an atom of extensional predicate with variable and constant . Rule r is constructed with a head atom atom_res, two body atoms atom_1, atom_2 and a time-based window timeWindow. timeWindow accepts two parameters l and u to define a sliding window over the conjunction of atom_tp1 and atom_tp2. Finally, we construct program p, where p can be expressed by the following LARS rule:
3.2 Data Structure & Program plans generation
In order to capture the previously-stated parallelism paradigms of Section 2.2 with BSP and RAT streaming models, we detail the query evaluation on Spark and Flink. BigSR adopts set semantics to handle all stateful operators, i.e., each IDB inferred by stateful datalog formulas will be deduplicated.
Data Structure. Both Spark and Flink keep their own data structures to support BSP and RAT, respectively: (1) Spark abstracts a sequence of RDD as DStream to enable near real-time data processing, the system buffers incoming data streams periodically as a micro-batch RDD. Each RDD encapsulates the data in a certain time interval, i.e., corresponding to wall-clock times. Intuitively, a micro-batch RDD refers to the minimum allowable data operation granularity. In addition, the timestamp assigned by the system does not bring any impact to query’s semantic. (2) Flink takes DataStream as a basic data structure. DataStream represents a parallel data flow running on multiple partitions where all data transformations are processed at a record-level. Such fine-grained data transformation makes event-timestamp-based operation feasible. In BigSR, we use the so-called ingestion time to handle the time-based window. Practically, each record gets stream source’s current time as a timestamp. Moreover, internally, Flink handles ingestion and event time in the same manner. Instead of using event timestamp, we choose ingestion time for data stream processing in Flink for the purpose of simplifying our experiment.
Program plans generation. Figure 3 compares the logical plan of example query in Listing 1. Both Spark and Flink can naturally embed the three parallelism strategies from Section 2.2 into their own native physical plan. Due to reliable cluster resource allocation, continuous Spark jobs are launched synchronously, i.e., a link connects two consecutive query executions (Figure 3, (a)). Input data from stream sources are collected through a window of duration which consists of micro-batches of duration . The buffered data are processed by the entire DAG of operators. On the other hand, the execution bound only exists on stateful operators, e.g., join and window, in Flink (Figure 3 (b)). Except for the conjunction of and which run synchronously, data reception and selections , run asynchronously.
3.3 Distributed Stream Reasoning on Spark
In order to clarify distributed stream reasoning in Spark, we introduce the following program () where we assume that , , and hold the same window operator in their bodies. Predicate is an EDB predicate while and are two IDB predicates.
corresponds to a series of BSP Spark jobs which execute in a Spark Streaming context. One restriction is that is only allowed to possess a single global window ().
For a non-recursive program, the logical plan is first mapped into a single Spark job’s DAG logical plan. Next, Spark compiles the logical plan to its physical plan and is then evaluated. We mainly discuss the recursive program evaluation on Spark here. Considering the previously defined program , Figure 4 (a) gives a running example by using the semi-naive evaluation of . We now present how this evaluation is parallelized in Spark:
PL1.: The system starts the evaluation by initializing and using input EDB . and forms an SCC , for any other SCC , where does not depend on , the evaluations of and can be computed in parallel.
PL2. In each iteration step of the semi-naive evaluation, the set of operations (e.g., selection, join, union) which compute each IDB predicate are chained together as a Spark job, i.e., , two Spark jobs for the evaluation of and are involved. The iterations are completed until a fix-point is reached. The system outputs and for further calculation.
PL3. Inside a single Spark Job, each operator performs a transformation of RDD. As an RDD is a distributed data collection, multiple tasks may execute concurrently across different data partitions.
Limitation & Envisioned Optimization. The implementation of recursion support in BigSR is straightforward. Some discussions about  and our envisioned optimization for recursive query handling are worth mentioning. Of the four proposed solutions in , two of them play key roles: (i) extends immutable RDD to mutable SetRDD; (ii) add recursive stage support in Spark job scheduler. Both (i) and (ii) sacrifice fault-tolerance to gain system performance. For a streaming service runs in , such fault-tolerance trade-off has high potential impact on system’s robustness and reliability.
In addition to the optimizations of , we propose two other envisioned solutions: (a) Integration with distributed index. For stratified LARS program, iterations and join operations become the performance bottleneck, Since iteration potentially involves intensive job scheduling and network shuffling in a distributed environment. Instead of scanning each partition entirely in RDD, the work555https://github.com/amplab/spark-indexedrdd integrates adaptive radix tree  to have efficient data access and update. Our preliminary experiments shows that indexed RDD gains 2.5 - 3 times performance for each iteration. However, the index needs to be reconstructed after each iteration, which comes with a non-negligible overhead. This approach thus is in the experimental and envisaged stage. (b) Parallel job scheduling. Spark schedules submitted jobs in a centralized way by master node. Frequent job submissions in iteration causes unavoidable latency. Rather than merging multiple jobs together into a single job , distributed job scheduler  provides millisecond latency for job scheduling without sacrificing any fault-tolerance.
3.4 Distributed Stream Reasoning on Flink
For a non-recursive program, BigSR compiles a LARS program into Flink’s streaming topology (i.e., DAG). Then, is evaluated through data flowing between operators in the DAG. In the case of recursive program (), Figure 4(b) gives a high-level vision of Flink’s workflow:
PL1. Similar to Spark, any other SCC which is independent from can be computed in parallel.
PL2. Different from Spark, which splits the recursion into a series of independent jobs. Flink achieves recursion with streaming feedback. In iteration , the system needs to feed back and (downstream for computing and , respectively) as the input for iteration . And the processes on and occur in parallel in a single iteration step.
PL3. Similar to Spark, the DataStream flows through each operator across in parallel, each operator consists of multiple tasks (over some partitions) which can be performed concurrently (w.r.t. PL3).
Limitation & Envisioned Optimization. There are two main limitations we found by using the RAT model:
(1) We require that the conjunction of two atoms , should share the same window operator, e.g., , a formula currently imposes that (). To our experience, this limitation shows up when input stream is type and the underlying process relies multi-cores/distributed environment. The main difficulties come from synchronization of clocks, task progress, and window trigger mechanism. However, a single-core/centralized system with input stream does not suffer from such a synchronization problem. Since all the computations are done sequentially, the program evaluation performs in a quasi-static way without considering the fast updating of . To the best of our knowledge, CQELSCloud, which is the only implementation with distributed setting, has a similar semantic. Nevertheless, to avoid above mentioned problems, CQELSCloud forbids event timestamp and “sliding” mechanisms in their window operators. The record is emitted eagerly right when the computation is done.
(2) We do not support recursive queries in Flink yet. Within the LARS framework, the implementation of recursion with RAT could be quite challenging. The example given earlier skips window operator. Once the body atoms of and are restricted by temporal logical operator (e.g., window operator), the synchronization problem mentioned in (1) will reappear. A naive solution is that the system merges and pushes the input stream by batch into a single operator for the evaluation of recursion, which behaves like a BSP model. However, this approach is against the original intention of using RAT model. The system becomes difficult to scale up since it does not provide any benefice from the asynchronous executions of the operators.
|BSP (Spark)||Low, coarse-grained||Implementation easy|
|RAT (Flink)||High, fine-grained||Implementation difficult|
Table 1 briefly compares BSP and RAT for implementing a stream reasoning framework like LARS. With BSP on Spark, the manipulation of temporal logical operators is rather coarse-grained with low expressiveness. The query should be evaluated in batches by a global window. Furthermore, the semantic of data timestamps does not influence the semantic of the query. The combination of window operators is not flexible. However, the query evaluation of the BSP model in a window is practically similar to a static data processing. Therefore, BSP greatly simplifies the implementation of recursion. On the other side, RAT model handles data processing record by record. The evaluation of operators can be performed asynchronously. RAT enables to manipulate the timestamp and window operators in a fine-grained fashion. Different types of time (e.g., event time, ingestion time, system processing time) can be integrated on RAT. The combination of multiple window operators can be chained together and ran independently. For recursive query evaluation, RAT suffers from synchronization of processes over multiple streams and multiple windows. This makes the implementation of recursion within the LARS framework a challenging problem.
The code base (written using the Scala programming language), data sources and test queries are available on GitHub666https://github.com/renxiangnan/bigsr. We conduct our experiments on a Amazon EMR cluster with a Yarn resource manager. The EMR cluster consists of a total of 9 nodes of type m4.xlarge. One node is setup for the Kafka broker and message producer, one node for Apache Zookeeper, seven nodes for Spark/Flink application (one master node and six worker nodes). Each node has 4 CPU virtual cores of 2.4 GHz Intel Xeon E5-2676 v3 processors, 16 GB RAM and 750 MB/s bandwidth. We use Spark 2.2.1, Flink 1.4.0 (broadcast join is disabled), Scala 2.11.7 and Java 8 as evaluation baselines.
4.1 Benchmark Design
Dataset & Queries. Our evaluation is based on synthetic and real-world datasets which involve 4 different datasets and 15 queries (Table 2). The 4 datasets correspond to Waves, SRBench , CityBench  and LUBM . All the data captured by the Waves, SRBench, and CityBench datasets come from real-world IoT sensors. The Waves dataset describes measures of a potable water network, e.g., values of flow, pressure and chlorine levels, etc. SRBench, one of the first RSP benchmark, contains USA weather observations ranging from 2001 to 2009. CityBench simulates a smart city context for RSP applications and concerns sensor measures on vehicle traffic, parking lot utilization and user location use cases. All the aforementioned datasets come from RSP contexts. It is hard to design a recursive query, because the generated RDF data streams are usually directly converted from flat data (CSV) with few references between entities. Therefore, we use LUBM for recursive query evaluations. Query to include stateful operators for windowing and recursion, where to only contain stateless operators (e.g., selection, filter, projection). We evaluate to to highlight the engine performance with BSP and RAT model for low-latency use cases, such as reactive applications.
To guarantee query semantics consistency between BSP and RAT, the result sets of a given query should be the same on the two distributed models. Input data streams are generated by Kafka message producer, and injected into BigSR in parallel. The average stream rate is around 250,000 to 300,000 triples/second.
Performance metrics. Considering Benchmarking Streaming Computation Engines at Yahoo!, the well-know benchmark for distributed streaming systems777https://yahooeng.tumblr.com/post/135321837876/benchmarking-streaming-computation-engines-at, we take system throughput and query latency as the principal performance criteria. In particular, we categorize the evaluations into two groups:
Group 1: to (queries with stateful operators). We denote throughput as the number of triples processed per second by the engine (i.e., triples/second). Latency corresponds to the duration taken by BigSR between the arrival of an input and the generation of its output.
Group 2: to (queries with only stateless operators). We focus on the minimum latency that the engine is able to attain. On Spark, we first reduce the micro-batch size as much as possible, then we record the query latency for completing the process of current micro-batch. On Flink, the latency of a record
indicates the time difference between the momententers the system and the moment outputs from the system.
Performance tuning is one of the most important step for the deployment of Spark and Flink applications. Based on our previous experience in , we list three important factors which bring significant impact on engine performance, i.e., parallelism level, memory management, and data serialization. Unfortunately, there is no fixed rule to configure these parameters in an optimal way. The tuning has to be done empirically. Besides, recursion on Spark may generate long RDD lineage in the driver memory which can lead to stack overflow. We thus periodically trigger the local checkpoint of RDD to truncate the RDD lineage.
4.2 Evaluation Results & Discussion
In this section, we present and discuss the evaluation result over the queries presented in Section 4.1. We do not compare BigSR to the state of the art RSP/(Streaming) ASP systems. This is due to our previous work  which has already shown a much higher performance gain (1 to 2 orders of magnitude) than available RSPs (C-SPARQL and CQELS). Compared to , the Spark implementation in BigSR is approximately 30% less performant. We partially attribute this to the distinct operation which satisfies the set semantic. Thus we still consider that the distributed design of BigSR takes a substantial performance advantage on existing centralized RSP engines.
Throughput. Figure 5 reports the engine throughput for to . Both implementation with BSP (Spark) and RAT (Flink) achieves million-level throughput. We observe that the throughput of Flink is 1.x - 3.x times superior to Spark. This difference is more substantial when the query has more intensive joins/conjunctions. This can be explained by the job scheduling on Spark which leads join operations to be performed on different compute nodes, thus causing network shuffles. Moreover Spark’s job scheduling is difficult to control in a fine-grained manner. On the contrary, Flink is able to avoid shuffles with an appropriate system configuration, i.e., the join operation can be managed by a task manager and performed locally on a single compute node.
For recursive queries to , Spark achieves the throughput up to 2.3M triples/second. Although we design three recursive queries for Lubm, the length of transitivity in Lubm is small which limits the number of iterations in semi-naive evaluation. Additionally, the intermediate results generated in to are low-sized, which reduces the performance penalty implied by shuffle operators.
Latency. We summarize the query latency of Group 1 ( to ) in Figure 6. Spark and Flink hold second/sub-second delay in general. Flink has a lower latency than Spark, only exceeds one second on Flink. The obtained latency on Spark and Flink are already acceptable for most streaming applications.
Here, we highlight the experiment over queries in group 2 (Table 3). Intuitively, to have been designed to stress BSP and RAT on latency. In fact, the micro-batch interval size of Spark is set to 500 ms. Even though the average latency on Spark is around 100 ms, but 500 ms is approximately the minimum “safe” batch size we can configure on Spark. The reason is that the garbage collection (GC) triggers periodically in a long running Spark Streaming application (on driver and workers), GC pause occurs from time to time. The query latency thus can grow up to 400 ms. We conclude that Spark satisfies the near-real time use case with sub-second delay requirement.
On Flink, we calculate the record latency by subtracting the output timestamp from input system assigned timestamp. The minimum observable time unit is millisecond (limited by Flink), and the vast majority obtained latency is 0 ms. Apparently, sub-millisecond delay meets most real-time, latency-sensitive use cases.
5 Related Work
In this section, we consider related work in the context of RSP, stream reasoning and Datalog engines. We emphasize that none of the existing systems tackle both scalability and ASP/Datalog reasoning.
RSP. Several RSP systems have been implemented over the last few years. The most popular ones correspond to centralized engines, e.g., C-SPARQL , CQELS , ETALIS  and SPARQL . Systems like CQELS-cloud and Strider  tackle the scalability issue but distributing stream processing. Available RSP systems are equipped with their own syntax, which generally take the form of continuous versions of the standard SPARQL grammar. This limits the expressiveness on temporal logical operators, e.g., the combination or even nesting of window operators. Moreover, the support of recursion is also missing.
RDF Stream Reasoner. Both StreamRule  and its recent parallelized version StreamRule  use a RSP engine for data stream pre-filtering and Clingo as the ASP solver. The expressiveness of BSP implementation in BigSR can fully cover StreamRule and StreamRule, since the implementation in these two reasoners stay on positive stratified Datalog program. Evaluation of StreamRule/StreamRule showcases that the average throughput is around thousand-triples/second with second-level delay. Comparatively, our BSP implementation has almost three orders of magnitude gains. Laser  and Ticker  are both stream processing systems based on the LARS framework but do not concentrate on scalability. Ticker concentrates incremental model maintenance and sacrifices performance by relying on an external ASP engine (Clingo). Laser also proposes an incremental model based on time interval annotations which can prevent unnecessary re-computations. Although Laser claims to represent a trade-off between expressiveness and data throughput, it cannot scale the way BigSR enables to. This is mainly due to Laser’s inability to distribute stream processing.
Other Datalog Solvers. Logiblox  is a single-machine commercial transactional and analytical system. Its query language, namely LogiQL, is a unified and declarative query language based on Datalog equiped with incremental maintenance. RDFox  is a centralized, main-memory RDF store with support for parallel Datalog reasoning and incremental materialization maintenance. None of these systems consider stream processing.
Myria  and BigDatalog  are both distributed datalog engines that perform on shared-nothing architectures. The former is implemented on its parallel processing framework and interacts with PostgreSQL databases for write and read operations. Much of the effort in the datalog engine of Myria has been concentrated on distributing rule processing in a fault-tolerant manner. BigDatalog implements a parallel semi-Naïve datalog evaluation on top of Spark. Neither Myria nor BigDatalog support stream processing.
This paper bridges the gap between theoretical work in progress on RDF stream reasoning and modern cutting-edge Big Data technologies. We emphasize that a trade-off between expressiveness of reasoning and scalability is possible in RDF stream reasoning. In fact our BigSR system is able to reach the millions triples per second processing mark on complex queries and second and subsecond latency in general. In order to tackle scalability, BigSR considers the standard BSP and RAT approaches through implementations with state of the art open source frameworks, respectively Apache Spark and Apache Flink. Both these systems offer rich APIs (e.g
., obviously for stream processing but also for machine learning, graph analytics), fault-tolerance, load balancing and automatic work distribution. In terms of reasoning, we address logic programming through the ASP-based LARS framework.
Our experimentation presents some interesting results on the current state of these systems. With its large programmer community, Spark is easier than Flink to get into and implement applications. Nevertheless, it may be difficult to configure, tune this parallel computing framework. The support for recursive rules was not a difficult problem. The overall performance of Flink on both data throughput and latency is superior to Spark and is quite impressive without requiring a lot of tuning. Nonetheless, the design and implementation of an evaluation approach for recursive programs is not straightforward. This is in fact in our future work list together with a more efficient incremental model maintenance.
-  Serge Abiteboul, Richard Hull, and Victor Vianu. Foundations of Databases. Addison-Wesley, 1995.
-  Tyler Akidau, Robert Bradshaw, Craig Chambers, Slava Chernyak, Rafael J. Fernández-Moctezuma, Reuven Lax, Sam McVeety, Daniel Mills, Frances Perry, Eric Schmidt, and Sam Whittle. The dataflow model: A practical approach to balancing correctness, latency, and cost in massive-scale, unbounded, out-of-order data processing. PVLDB, 2015.
-  Muhammad Intizar Ali, Feng Gao, and Alessandra Mileo. Citybench: A configurable benchmark to evaluate rsp engines using smart city datasets. In ISWC, 2015.
-  Darko Anicic, Sebastian Rudolph, Paul Fodor, and Nenad Stojanovic. Stream reasoning and complex event processing in etalis. Semant. web, 2012.
-  Molham Aref, Balder ten Cate, Todd J. Green, Benny Kimelfeld, Dan Olteanu, Emir Pasalic, Todd L. Veldhuizen, and Geoffrey Washburn. Design and implementation of the logicblox system. In SIGMOD, 2015.
-  Davide Francesco Barbieri and al. C-SPARQL: SPARQL for continuous querying. In WWW, 2009.
-  Hamid R. Bazoobandi, Harald Beck, and Jacopo Urbani. Expressive stream reasoning with laser. In ISWC, 2017.
-  Harald Beck, Minh Dao-Tran, Thomas Eiter, and Michael Fink. LARS: A logic-based framework for analyzing reasoning over streams. In AAAI, 2015.
-  Harald Beck, Thomas Eiter, and Christian Folie. Ticker: A system for incremental asp-based stream reasoning. TPLP, 2017.
-  Jean-Paul Calbimonte, Óscar Corcho, and Alasdair J. G. Gray. Enabling ontology-based access to streaming data sources. In ISWC, 2010.
-  Paris Carbone, Asterios Katsifodimos, Stephan Ewen, Volker Markl, Seif Haridi, and Kostas Tzoumas. Apache flink™: Stream and batch processing in a single engine. IEEE Data Eng. Bull., 2015.
-  Brian Chin, Daniel von Dincklage, Vuk Ercegovac, Peter Hawkins, Mark S. Miller, Franz Och, Chris Olston, and Fernando Pereira. Yedalog: Exploring knowledge at scale. In SNAPL, 2015.
-  Martin Gebser, Roland Kaminski, Benjamin Kaufmann, and Torsten Schaub. Clingo = ASP + control: Preliminary report. CoRR, 2014.
-  Yuanbo Guo, Zhengxiang Pan, and Jeff Heflin. LUBM: A benchmark for OWL knowledge base systems. J. Web Sem., 2005.
-  Danh Le-Phuoc, Minh Dao-Tran, Josiane Xavier Parreira, and Manfred Hauswirth. A native and adaptive approach for unified processing of linked streams and linked data. In ISWC, 2011.
-  Viktor Leis, Alfons Kemper, and Thomas Neumann. The adaptive radix tree: Artful indexing for main-memory databases. ICDE ’13, 2013.
-  Alessandra Mileo, Ahmed Abdelrahman, Sean Policarpio, and Manfred Hauswirth. Streamrule: A nonmonotonic stream reasoning system for the semantic web. In RR, 2013.
-  Boris Motik, Yavor Nenov, Robert Piro, Ian Horrocks, and Dan Olteanu. Parallel materialisation of datalog programs in centralised, main-memory RDF systems. In AAAI, 2014.
-  Boris Motik, Yavor Nenov, Robert Piro, Ian Horrocks, and Dan Olteanu. Parallel materialisation of datalog programs in centralised, main-memory RDF systems. In AAAI, 2014.
-  Kay Ousterhout, Patrick Wendell, Matei Zaharia, and Ion Stoica. Sparrow: Distributed, low latency scheduling. SOSP, 2013.
-  Simona Perri, Francesco Ricca, and Marco Sirianni. Parallel instantiation of ASP programs: techniques and experiments. TPLP, 2013.
-  Thu-Le Pham, Alessandra Mileo, and Muhammad Intizar Ali. Towards scalable non-monotonic stream reasoning via input dependency analysis. In 33rd ICDE 2017, 2017.
-  Danh Le Phuoc and al. Elastic and scalable processing of linked stream data in the cloud. In ISWC, 2013.
-  Xiangnan Ren and Olivier Curé. Strider: A hybrid adaptive distributed RDF stream processing engine. In ISWC, 2017.
-  Alexander Shkapsky, Mohan Yang, Matteo Interlandi, Hsuan Chiu, Tyson Condie, and Carlo Zaniolo. Big data analytics with datalog queries on spark. SIGMOD, 2016.
-  Ankit Toshniwal, Siddarth Taneja, Amit Shukla, Karthik Ramasamy, Jignesh M. Patel, Sanjeev Kulkarni, Jason Jackson, Krishna Gade, Maosong Fu, Jake Donham, Nikunj Bhagat, Sailesh Mittal, and Dmitriy Ryaboy. Storm@twitter. SIGMOD, 2014.
-  Leslie G. Valiant. A bridging model for parallel computation. Commun. ACM, 33(8):103–111, August 1990.
-  Jingjing Wang, Magdalena Balazinska, and Daniel Halperin. Asynchronous and fault-tolerant recursive datalog evaluation in shared-nothing engines. PVLDB, 2015.
-  Matei Zaharia, Mosharaf Chowdhury, Tathagata Das, Ankur Dave, Justin Ma, Murphy McCauley, Michael J. Franklin, Scott Shenker, and Ion Stoica. Resilient distributed datasets: A fault-tolerant abstraction for in-memory cluster computing. In NSDI, 2012.
-  Matei Zaharia, Tathagata Das, Haoyuan Li, Timothy Hunter, Scott Shenker, and Ion Stoica. Discretized streams: Fault-tolerant streaming computation at scale. In SOSP, 2013.
-  Matei Zaharia, Tathagata Das, Haoyuan Li, Timothy Hunter, Scott Shenker, and Ion Stoica. Discretized streams: Fault-tolerant streaming computation at scale. In Proceedings of the Twenty-Fourth ACM Symposium on Operating Systems Principles, SOSP ’13, pages 423–438, New York, NY, USA, 2013. ACM.
-  Ying Zhang, Pham Minh Duc, Oscar Corcho, and Jean-Paul Calbimonte. Srbench: A streaming rdf/sparql benchmark. In ISWC, 2012.