KR20200010659A - Stream reasoning system - Google Patents

Abstract

Embodiments of the present invention provide a stream reasoning system including an input unit and an inference unit and may be realized as a middleware. In addition, the embodiments provide a real-time distributed messaging system, a real-time distributed processing system or a stream reasoning system using a data pipeline. Thus, embodiments of the present invention can intelligently process a large amount of stream information in real time.

Description

Stream listening system {STREAM REASONING SYSTEM}

Embodiments of the present invention relate to streamlisting systems, and more particularly, to streamlisting systems and methods for intelligent processing of large-scale stream big data.

Smart City is a futuristic city in which information and communication technologies are melted in the city to provide smart services to city residents anytime, anywhere, anytime, and on any device in order to improve the quality of life of the citizens. (Non-Patent Document 1)

Gartner predicts that 1.6 billion connected things will be used in the smart city in 2016. That's up 39 percent from 2015. (Non-Patent Document 2)

The Internet of Thing (IoT) technology connects the physical things in the real world and the virtual things in the cyber environment with each other through the Internet, and the objects, data and people in these physical and virtual spaces. It is the future Internet infrastructure technology that can provide various services through this linkage. (Non-Patent Document 3)

In order to implement smart services in smart cities, it is necessary to analyze the huge amount of big data transmitted from the smart devices of the IoT, and to provide intelligent services to urban citizens through accurate judgment-aware. . In this case, in order to recognize the situation by processing the constantly occurring big data in real time, a stream reasoning technique is necessary.

Stream leasing is a recent development that “is a logical way of dealing in real time with large, big data streams mixed with a large number of heterogeneous and bad data, with the aim of supporting decision systems used by very large numbers of concurrent users. Logical reasoning ”. (Non-Patent Document 4)

Looking at the prior art associated with stream leasing as follows.

Non-Patent Document 5 proposes a parallel processing methodology utilizing a computer cluster and a Yahoo S4 framework to provide a high overall throughput of streamlisting. We also present a set of low-level predicates on the stream and use these predicates to present the encoding of RDFS listening and the C-SPARQL query response.

Non-Patent Document 6 proposes a large scale real-time semantic processing framework and a flexible distributed stream engine for IoT applications. The proposed engine supports all kinds of IoT applications based on the distributed computing platform SPARK, and is an example of a home environment monitoring application. Experiments have shown that it can be extended for large sensor streams with different types of IoT applications.

However, the prior art has a difficult time to perform stream leasing in real time using a rapidly changing, huge amount of stream big data.

  [1] YW Lee, “Smart-city”, European Union Parliament Seminar, May 2013, [Online], Retrieved June 2016 from http://www.europarl.europa.eu/document/activities/cont/20130 5 / 20130514ATT66084 /20130514ATT66084EN.pdf.  [2] R. Meulen, V. Woods, Gartner, “Gartner Says Smart Cities Will Use 1.6 Billion Connected Things in 2016”, Gartner Newsroom, 2015, [Online], Retrieved June 2016 from http://www.gartner.com / newsroom / id / 3175418.  [3] Karen Rose, Scott Eldridge, Lyman Chapin, “The Internet of Things: An Overview”, Report of Internet Society, 2015.  [4] E. D. Valle, S. Ceri, F. v. Harmelen, D. Fensel, “It's a Streaming World! Reasoning upon Rapidly Changing Information ”, IEEE Intelligent Systems, Vol. 24, pp. 83- 89, 2009  [5] J. Hoeksema, S. Kotoulas, “High-performance Distributed Stream Reasoning using S4”, Proc. The First International Workshop on Ordering and Reasoning (OrdRing 2011), pp. 1-12, 2011  [6] X. Chen, H. Chen, N. Zhang, J. Huang, W. Zhang, “Large-Scale Real-Time Semantic Processing Framework for Internet of Things”, International Journal of Distributed Sensor Networks, Vol. 11, No. 10, pp. 1-11, 2015

In order to solve the above problems, embodiments of the present invention include a stream listening system comprising an input unit for receiving stream information and an inference unit for inferring context in real time based on the stream information to generate inference information. The purpose is to provide.

One embodiment of the present invention for achieving the above object is an input unit for receiving stream information; And an inference unit configured to generate inference information by inferring a context in real time based on the stream information.

As described above, the embodiments of the present invention have high scalability since the stream listening system can be processed in real time and can be implemented as middleware.

In addition, embodiments of the present invention can use a real-time distributed messaging system and a real-time distributed processing system can accurately process a large amount of stream information in real time.

In addition, embodiments of the present invention can be composed of a plurality of pipelines according to the type of data can be processed quickly stream information.

In addition, the embodiments of the present invention have a storage space for storing inference information every specific time, so that it can cope with the continuous query quickly.

Not limited to the above-mentioned effects, other effects that are not mentioned can be clearly understood by those skilled in the art from the following description.

1 is a block diagram illustrating an example of a stream listening system according to an embodiment.
2 is a block diagram illustrating an example of a stream listening system according to an embodiment.
3 is a block diagram illustrating an example of a stream listening system according to an embodiment.
4 is a diagram illustrating an example of an OWL domain ontology for a smart city according to an embodiment.
5 is a flowchart illustrating an example of a stream listening method according to an embodiment.
6A to 6E are exemplary diagrams illustrating an example of experiments by implementing a stream listening system.

Description of the present invention is only for embodiments for structural or functional description, the scope of the present invention should not be construed as limited by the embodiments described in the text. That is, since the present embodiments can be variously modified and can have various forms, the scope of the present invention should be understood to include equivalents that can realize the technical idea. In addition, the objects or effects presented in the present invention does not mean that a specific embodiment should include all or only such effects, the scope of the present invention should not be understood as being limited thereby.

BRIEF DESCRIPTION OF THE DRAWINGS The accompanying drawings are provided to assist in understanding the present invention, and provide embodiments with a detailed description. However, the technical features of the present invention are not limited to the specific drawings, and the features disclosed in the drawings may be combined with each other to constitute new embodiments.

A stream listening system disclosed in the following embodiments will be described in more detail with reference to the accompanying drawings.

1 is a block diagram illustrating an example of a stream listening system according to an embodiment.

Referring to FIG. 1, the stream listening system 100 according to an exemplary embodiment may receive stream information from a sensor 200 and receive query information from a user terminal or an external system 300 to receive a user terminal or an external system. The query result may be sent to 300.

The sensor 200 may detect gas, carbon dioxide, temperature, a user's location, and the like, and transmit stream information corresponding to the value detected through the communication network to the stream listening system 100.

Here, the communication network may mean a wide concept network including a wired or wireless communication network. The same applies to the following.

The user terminal or the external system 300 may transmit query information about context information or context information such as whether a current fire has occurred in the stream listening system 100 or whether toxic gas is leaked through a communication network, and the query information. The query result for may be received from the stream listening system 100.

Here, the user terminal 300 may be any one of a notebook, a mobile phone, a smart phone (2G / 3G / 4G / LET, smart phone), a portable media player (PMP), a personal digital assistant (PDA), and a tablet PC (Tablet PC). It can be one.

The stream listening system 100 may include an input unit 110, an inference unit 120, and a management unit 130.

The input unit 110 may receive the stream information from the sensor 200 and transmit the stream information to the inference unit 120 in real time. Here, since the stream information has a large capacity and needs real time processing, the input unit 110 requires scalability and low transmission delay time according to the amount of stream information.

Therefore, the input unit 110 is preferably implemented as a real-time distributed messaging system. Here, a messaging system is a standard that allows semantically accurate messages to be sent between computer systems, consisting of service providers, service consumers, and / or brokers, thus simplifying the communication structure. Specifically, in a messaging system, a service provider may send a message to a broker to store a message in a broker's queue and a service consumer may retrieve a message stored in the broker's queue.

In addition, here, a real-time distributed messaging system is a distributed messaging system for sending messages in real time, a simple communication method for fast message transmission in real time, and distribute the message to multiple servers so that the broker does not miss a large amount of messages received It can mean a messaging system that can be enabled.

The input unit 110 may use Kafka, which is a kind of real-time distributed messaging system, to receive a large data stream in real time. Kafka can send stream information in real time to a messaging system specialized in processing large messages. And because it works as a cluster for scale-out and high availability, it is easy to handle large data generated from smart cities. In addition, it satisfies the large-scale real-time transmission and low transmission latency required for stream listening, and it is also suitable for the transmission of stream information between IoT devices and SOUL using its own light protocol compared to the existing messaging protocol AMQP protocol or JMS API.

The inference unit 120 may include a conversion unit 122 and an analysis unit 126, which will be described later, and generate inference information by inferring context in real time based on stream information received from the input unit 110. In this case, since the stream information has a large capacity and needs real time processing, the inference unit 120 requires high scalability, high throughput, and low processing delay time according to the amount of stream information.

Therefore, the inference unit 120 is preferably implemented as a real-time distributed processing system. Here, a real-time system may mean a system capable of processing a task within a limited time, and a real-time distributed processing system communicates and transmits messages between different networked computers to process a large amount of information within a limited time. It can mean a system that can coordinate and perform work.

In addition, the real-time distributed processing system should be able to provide the ability to configure a plurality of data pipelines according to the type of data in order to process a large amount of information quickly. Here, the data pipeline may refer to a set of data processing elements sequentially connected such that data output by one data processing element is input data of a next data processing element.

The inference unit 120 may use Apache Storm, which is a kind of real-time distributed processing system, to process a large data stream in real time. Apache Storm includes input logic and processing logic to process input streams using topology. There are two kinds of components, spouts and vaults. Spouts create a data stream from an external source into the topology, the vault performs all the processing of the topology, and the stream is Create a data stream to process. You can also place multiple vaults by separating processing operations in vaults to get the desired data stream. These storm structures and processes are very efficient for the real-time processing and inference mechanisms of stream listening.

The management unit 130 receives the inference information generated by the inference unit 120, receives query information about the inference information from the user terminal or the external system 300, and infers the information corresponding to the query result from the user terminal or the external system. Transmit to 300.

In addition, the management unit 130 may process the query information registered in the user terminal or the external system 300 continuously in the stream listening system to return the inference information that is the result of the stream listening. When the user terminal or the external system 300 registers the continuous query information, the management unit 130 should be able to continuously return the result of the query, which is called a continuous query.

2 is a block diagram illustrating an example of a stream listening system according to an embodiment.

2, the stream listening system 100 according to an exemplary embodiment may include an input unit 110, a conversion unit 122, an analysis unit 126, a management unit 130, a database 140, and a service broker 150. It may be configured to include).

In addition, the stream listening system 100 may be configured as middleware of the smart city system 400.

Here, the smart city system 400 is a three-tier architecture for intelligently managing a large number of infrastructures, including IoT devices in the smart city, and providing various smart applications of the smart city to the citizens. It is composed of city middleware tier and smart city infrastructure tier, among which smart city middleware tier can intelligently process various data coming through smart city infrastructure and provide smart city service through smart city portal tier.

In this context, middleware refers to software that functions as an intermediary for connecting data to each other, or software that connects a service to many processes on multiple computers connected through a network. .

The common device interface layer may play a role of receiving data from sensors in the infrastructure area and delivering the data to the smart computing layer, supporting various types of sensors and communication protocols, and providing a common interface for heterogeneous USNs.

The smart computing layer may be configured to include a transformation unit 122, an analysis unit 126, a management unit 130, and a database 140 as an important layer of stream listening. The smart city middleware may change and infer from the raw data to the RDF / OWL format in order to perform stream listening. It can store inferred information and support continuous queries for contexts.

The converter 122 receives the raw data (sensor data, stream information) from the common device interface layer, performs filtering according to the filter policy, and analyzes the raw data onto the context ontology so that the stream filtering can be performed by the analyzing unit 126. Changes can be made to ontology information such as RDF / OWL following the model.

Here, an ontology is a conceptual, computer-workable model that expresses the consensus of what people see, hear, feel and think about the world, in a conceptual and computer-friendly form, expressing the types of concepts and constraints on their use. Means the technology defined.

The analyzer 126 may generate inference information by inferring a context in real time according to a predefined rule. And to improve the performance of streamlisting, cloud computing technology at the ubiquitous core computing layer can support distributed processing. Cloud computing technology can be implemented based on OpenNebula and Haizea.

The storage 140 may store a context ontology model, a context instance, a rule, and an inferred context (inference information).

The management unit 130 may serve as an interface with the ubiquitous core computing layer, interpret a query from the service broker 150 of the ubiquitous core computing layer, and perform a query.

The context ontology model and rules file can be preloaded into memory when the system is initialized, and the context instance can be loaded into memory at runtime.

As such, the stream listening system 100 may be implemented in middleware and thus may operate in heterogeneous systems.

3 is a block diagram illustrating an example of a stream listening system according to an embodiment.

Referring to FIG. 3, the stream listening system 100 according to an embodiment includes an input unit 110, a conversion unit 122, an analysis unit 126, a management unit 130, a database 140, and a service broker 150. ) And the stream listening system 100 may be configured as middleware as in FIG. 2.

The input 110 on the common device interface layer may include a Kafka broker 112.

The Kafka broker 112 may perform a buffer function for storing the stream information received from the sensor 200 and transmit the stream information to the converter 122 of the smart computing layer.

As such, since the input unit 110 transmits a message using a real-time distributed messaging system such as Kafka, a large amount of stream information can be effectively transmitted without delay and loss.

In addition, the Kafka broker 112 may be divided into a plurality of data pipelines according to the received stream information and transmit the stream information to the converter 122 through the configured data pipeline.

As such, the Kafka broker 112 may transmit data through a plurality of data pipelines, thereby rapidly processing a large amount of stream information in real time.

The converter 122 may be composed of a Kafka spout 123 and a converter Bolt 124.

Kafka spout 123 is an implementation that implements Kafka Consumer (service consumer described above) in Apache Storm, it can accept the stream information transmitted from the input unit (110).

The Kafka spout 123 may be configured of a plurality of data pipelines according to the received stream information, and may transmit the stream information to the transformer Bolt 124 through the configured data pipeline.

The converter Bolt 124 may convert the received stream information into an OWL ontology instance by using an OWL ontology model.

In this regard, FIG. 4 is a diagram illustrating an example of an OWL domain ontology for a smart city according to an embodiment.

In addition, the converter Bolt 124 may be divided into a plurality of data pipelines according to the type of stream information, and may transmit the stream information to the analyzer 126 through the configured data pipeline.

As described above, the converter Bolt 124 may transmit data through a plurality of data pipelines, thereby rapidly processing a large amount of stream information in real time.

The analyzer 126 may generate inference information by performing inference using an OWL ontology instance and a user-defined rule, and may include an analyzer Bolt 127.

The analysis unit Bolt 127 may perform OWL inference using the Apache Jena Framework, and the OWL Reasoner may use Pellet. The custom rule used here can be configured to accept changes from the user during run-time.

The management unit 130 may transmit the inference result performed by the analyzing unit 126 to the database 140 and perform an interface function with the service broker 150 of the ubiquitous core computing layer, which is an upper layer.

Persistentaggregate 132 of each node may deliver inference information to State 134. In addition, the Persistentaggregate 132 collects inference information for a specific time and delivers it to the State 134 at one time, or adds or merges inference information for a specific time to the State 134, and among the inference information received for a specific time. Only recent inference information may be transferred to the state 134.

State 134 may be a memory store for storing state in order to process a continuous query transmitted in a Distributed Remote Procedure Call (DRPC). In order to perform a continuous query on the result of successive inference in stream listening, the state for each moment must be stored. You can use the windowing technique to maintain the state to query the state for each moment in the stream. Here, the window technique may mean maintaining information for a specific unit time until the next unit time elapses.

As such, the manager 130 may process the continuous query quickly by providing the state 134 separately from the database 140.

Meanwhile, Storm's DRPC technique can be used to implement continuous queries in Apache Storm.

The DRPC server 136 is a server that enables RPC (Remote Procedure Call) to perform Storm's topology used by Storm. The DRPC server 136 receives a command from the service broker 150 and receives a processed result from the Aggregate 139. It may return to the broker 150.

The DRPC spout 137 may transfer the query information received from the DRPC server 136 to the State query 138. In addition, the DRPC spout 137 may be divided into a plurality of data pipelines according to the type of query information, and transmit the query information to the state query 138 through the configured data pipeline.

As such, the DRPC spout 137 may transmit data through a plurality of data pipelines, thereby rapidly processing a large amount of query information in real time.

The state query 138 may inquire the state 134 described above about the current state value on the window by using the received query information, receive the result information (inference information) for the query, and transmit the result information to the aggregate 139. .

Aggregate 139 may deliver the received result to the DRPC server 136. In addition, the Aggregate 139 may merge or add several result values for the continuous query to the DRPC server 136 or deliver only the latest result value to the DRPC server 136.

The database 140 is a repository for persistent storage of state values that have been loaded into the memory of the state, and an inferred ontology instance for each moment may be loaded.

The service broker 150 belongs to the ubiquitous core computing layer and may serve as an interface with the smart computing layer. The smart city application may request a continuous query from the service broker 150 to obtain necessary situation information, and receive the result.

5 is a flowchart illustrating an example of a stream listening method according to an embodiment.

Referring to FIG. 5, the stream listening method 500 according to an embodiment may include an input step S510, a conversion step S520, an analysis step S530, and a management step S540.

In the input step (S510), the stream listening system 100 may receive the stream information from the sensor 200.

In the conversion step (S520), the stream listening system 100 receives the stream information, performs filtering according to the filter policy, and stores the raw data in accordance with the context ontology model to enable stream listening in the context analyzer. It can be changed into ontology information such as

In analysis step S530, the stream listening system 100 may generate inference information by inferring a context in real time according to a predefined rule. And to improve the performance of streamlisting, cloud computing technology at the ubiquitous core computing layer can support distributed processing. Cloud computing technology can be implemented based on OpenNebula and Haizea.

In the management step (S540), the stream listening system 100 receives the inference information and receives the query information about the inference information from the user terminal or the external system 300 and the inference information corresponding to the query result in the user terminal or external Transmit to system 300.

6A to 6E are exemplary diagrams illustrating an example of experiments by implementing a stream listening system.

6A and 6B, 16 clusters were used in the experiment for performing stream listening in a distributed environment, and the cluster node specification (FIG. 6A) and the cluster environment (FIG. 6B) were used. Can be.

The stream data generator was implemented and used to generate a large amount of stream information generated in a smart city. In this experiment, 1,000,000 sensor data were generated and the processing time and throughput per second were measured while changing the transmission speed of the data generated by the stream data generator.

Because stream leasing is a real-time processing system, it is difficult to evaluate in the same way as a typical batch data processing experiment. In order to evaluate the stream listening system, the number of stream data was fixed and the sensor data transmission amount per second according to the sensor data transmission time was measured. The total processing time and the total throughput per second were measured based on the measured sensor data transfers per second. Each experimental result was measured 10 times, and only the averaged results except the minimum and maximum values were used as data.

6c to 6e show the results of experiments while increasing the number of nodes from 4 nodes to 12 nodes. From one node to three nodes, performance measurement was not possible due to insufficient memory.

FIG. 6C is a diagram illustrating a transmission amount of sensor stream data per second when all 1,000,000 pieces of sensor stream information are transmitted as streams. Since a fixed number of data is sent over time, the transmission per second is inversely decreasing.

FIG. 6D is a diagram showing the total processing time according to the transmission amount of sensor stream data per second used as the Y-axis of FIG. 6C. When using 4 nodes and 6 nodes, the result is quite unstable. In 8 nodes and 10 nodes, the processing time was the smallest in the case of about 10,000 transmissions per second. Since then, the processing time is small but increases gradually. Using 12 nodes, processing time was reduced even when the transmission amount per second exceeded 11,000. As a result, it can be inferred that the maximum processing power of the present experimental system can process about 10,000 streams of data per second for 10 nodes, and the time will decrease if more nodes are added.

FIG. 6E is a diagram illustrating total throughput per second according to transmission amount of sensor stream data per second. When four nodes are used, 5,000 data can be processed per second. When six nodes are used, 6,000 data can be processed per second. When 8 nodes and 10 nodes are used, the throughput increases proportionally per second as the throughput increases, and the total throughput per second is the highest when the throughput of the sensor stream data per second is 10,000. After that, we can see that the throughput per second is getting lower. If 12 nodes are used, it can be seen to increase after 10,000. As a result, as in the conclusion of FIG. 6D, when using 10 nodes in the present experimental system, the maximum processing capacity can process about 10,000 streams of data per second. It can also be inferred that throughput increases per second as nodes increase.

As described above, although described with reference to the preferred embodiments of the present application, those skilled in the art various modifications of the present application without departing from the spirit and scope of the present invention described in the claims below And can be changed.

100: stream listening system
110: input unit 120: inference unit
122: converter 126: analyzer
130: management unit 140: database
150: service broker
200: sensor 300: user terminal or external system

Claims (9)

An input unit for receiving stream information; And
And an inference unit configured to generate inference information by inferring a context in real time based on the stream information.
The method of claim 1,
The inference unit,
A conversion unit for converting the stream information into ontology information;
And an analysis unit for generating inference information by inferring a context in real time based on the ontology information and a rule defined by a user.
The method of claim 2,
The rule is a stream listening system, characterized in that dynamically changeable.
The method of claim 2,
The transformation unit and the analysis unit stream stream system, characterized in that composed of a plurality of data pipelines according to the type of data.
The method of claim 1,
The stream listening system,
And a management unit for receiving a query for inference information and transmitting the generated inference information.
The method of claim 5,
The management unit stream stream system, characterized in that it comprises a storage space for storing inference information for a particular period.
The method of claim 1,
And the input unit uses a real-time distributed messaging system.
The method of claim 1,
The reasoning unit stream stream system, characterized in that using a real-time distributed processing system.
The method of claim 1,
The stream listening system is a stream listening system, characterized in that corresponding to the middleware.

Images