## 1 Introduction  
The semantic web allows computers to understand and manipulate the meaning of documents [1, 2, 3]. The semantic web has emerged to process various resources and data management by computers automatically. As studies on semantic web services were conducted actively, a Resource Description Frame (RDF) that can manage resources over the web was studied [4, 5, 6]. RDF is a standard metadata model that expresses resource information in the semantic web. The RDF identifies a relationship between expressed values and processes data intelligently. RDF forms a graph through a triple structure, which is expressed with the subject (S), predicate (P), and object (O) [7, 8, 9, 10]. As the volume of the RDF graph increases over the semantic web, some studies on SPARQL Protocol and RDF Query Language (SPARQL), which is a language that can query and process RDF data, were conducted [11, 12, 13, 14]. SPARQL is an RDF query language, which consists of PREFIX, SELECT, and WHERE clauses [15, 16, 17]. PREFIX means an RDF graph set used in a query. SELECT means variable expressing query results. WHERE means conditions to process the query. There are other clauses: ORDER BY clause to designate an order of query results, LIMIT clause that designates how many records are displayed in the query result, and OFFSET clause that designates from which lines the query result starts. As web-based services increase in scale, it becomes impossible to store the entire RDF graph data, which is used in services in a repository based on a single node. Moreover, performance degradation occurs when a large scale of RDF graph is queried and processed [18, 19, 20, 21, 22, 23, 24]. Thus, not only a scheme of how to store RDF graph in the distributed manner but also a query processing scheme of the stored RDF graph are required [25, 26, 27, 28, 29]. The existing query processing schemes that divide a SPARQL query into subqueries and process the divided subqueries were proposed for SPARQL query processing [30, 31, 32, 33, 34, 35, 36, 37, 38]. As a result, communication amount is increased, and the cost of query processing becomes higher since many joins occur or a large amount of data are generated when fetching results from the divided data in various environments in which data are divided [39; 40]. In the existing schemes, query processing is conducted by searching many nodes and finding data accordingly during SPARQL query requests over the peer-to-peer (P2P) environment. The data transmission and join cost occurs in order to generate result data from the distributed result data during query processing through searching data via many nodes [41]. Another scheme in the past considered the join and communication costs during query processing. However, it assumed an environment where data were replicated in a few nodes. The data communication and join cost can be reduced if data are replicated and stored rather than distributed and stored. However, the existing schemes cannot be utilized in a data distributed environment if all RDF graphs cannot be stored in a single node [42]. More recently, a scheme that reduces the disk I/O cost during data parsing and join cost during query processing in the Spark environment, which was a distributed in-memory platform, was proposed [43; 44; 45]. However, it does not consider the communication cost during query processing in a distributed environment, resulting in a large amount of cost generated during query processing of a large scale of RDF graph [43]. In this paper, we propose a distributed SPARQL query processing scheme considering Spark environments to reduce join and communication costs that occurred during query processing, which are problems in existing schemes. The proposed scheme reduces disk I/O cost through query processing in the Spark environment, which is a distributed in-memory environment. In addition, it reduces join and communication costs during query processing through the query execution paths considering data communication costs and various costs that occur during query processing.