AGGREGATE DATA STREAMS IN RELATIONAL DATABASE SYSTEMS

Abstract

Methods, systems, and computer readable media can provide for aggregating high-rate, large-volume input data streams into low-volume output data streams in real-time. Aggregating high-rate, large-volume data streams into low-volume output data streams can be facilitated by analyzing lossless aggregation relationships among helper views within one or more continuous query tasks and executing conventional queries to derive high-level, low-volume output data streams from low-level, high-volume input data streams.

Description

CROSS REFERENCE TO RELATED APPLICATION

This application is a non-provisional application claiming the benefit of U.S. Provisional Application Ser. No. 61/681,959, entitled “Aggregate Data Streams in Relational Database Systems,” which was filed on Aug. 10, 2012, and is incorporated herein by reference in its entirety.

TECHNICAL FIELD

This disclosure relates to aggregating low-level, high-rate data streams into high-level, low-volume data streams continuously in real time.

BACKGROUND

Enterprise applications can carry out a variety of functions, such as data and/or information management, and can be used by a plurality of users, typically through a computer network. Generally, enterprise applications are faced with the task of processing high-volume input data and presenting results to users in real-time. Various enterprise applications can receive continuous query tasks from users, and users typically expect such continuous query task results to be obtained and presented in real-time.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a block diagram illustrating an example system operable to aggregate low-level, high-rate input data streams into high-level, low volume output data streams.

FIG. 2 is a flowchart illustrating an example process operable to construct one or more view family hierarchies from continuous query tasks.

FIG. 3 is a block diagram illustrating an example view family hierarchy comprising views having one or more lossless aggregation relationships with other views in the hierarchy.

FIG. 4 is a flowchart illustrating an example process operable to continuously aggregate one or more input data streams.

Like reference numbers and designations in the various drawings indicate like elements.

DETAILED DESCRIPTION

Enterprise application developers face a challenge in quickly processing ever growing amounts of high-volume input data and presenting the data in real-time to meet complex operational requirements. Research has been conducted on data streams and continuous queries associated with high-volume input data. However, data stream processing in enterprise applications still presents a challenge, particularly data stream processing by a single relational database system. For example, application developers face the challenge of efficiently displaying multiple sets of aggregated data streams (e.g., data streams aggregated from one or more input data streams) on a dashboard simultaneously, while maintaining each set of aggregated data streams in its own sliding window. In some implementations of this disclosure, a continuous data stream aggregation engine based on the concept of view groups in a relational database system can be operable to more efficiently accept incoming data streams and send outgoing summary data streams to a plurality of application components. Furthermore, lossless aggregation relationships (e.g., relationships between a plurality of views which allow the views to be aggregated without losing information stored in the views or accuracy in the aggregation) among views in a view group can be applied in the optimization of a continuous aggregation algorithm. For example, a count of the number of operations taking place over a one hour period has a lossless aggregation relationship with the counts of the number of operations taking place over each of the sixty, one minute periods within the one hour period, because the hour count can be calculated directly from the minute counts accurately and without losing any information.

In some implementations, large amounts of input data can be organized and summary data associated with the input data can be presented in a live enterprise dashboard. A typical dashboard can contain multiple sets of application data or widgets, which in turn, can display aggregated data in near real-time. In some implementations of this disclosure, the presentation of multiple sets of aggregated data in real-time can be facilitated by efficiently and accurately deriving output data from high-rate, large-volume input data.

Traditional relational database language constructs (e.g., materialized views) and aggregate functions are generally insufficient to present summary data associated with high-rate, large-volume input data in real-time. In some implementations of this disclosure, an add-on component with stream aggregation features coupled with a conventional database management system (DBMS) can facilitate the aggregation of high-rate, large-volume input data streams into low-volume output data streams continuously and efficiently inside the boundary of the DBMS. In various implementations of this disclosure, the simplicity of a single-system design can be achieved and continuous query requirements can be met by separating an aggregation engine from a DBMS, thereby eliminating a requirement for extensions to structured query language (SQL) constructs or of adding special Data Stream Management System (DSMS).

FIG. 1 is a block diagram illustrating an example system 100 operable to aggregate low-level, high-rate input data streams into high-level, low volume output data streams. In some implementations, the system 100 can include a registry 110, an aggregation engine 120, and a relational database management system (RDBMS) 130.

In some implementations, a registry 110 can store a list of continuous query tasks generated from application requirements. For example, the registry can receive a list of continuous query tasks from an application, or other source, and can store the list of continuous query tasks inside the registry. In various implementations, the registry can send a query task to an aggregation engine 120. In some implementations, the list of query tasks stored in the registry can change continuously.

For example, new tasks received from an application can be entered into the registry and tasks that are no longer needed can be removed from the registry.

In some implementations, an aggregation engine 120 can parse a query task into conventional queries and helper views associated with the conventional queries. For example, an aggregation engine can receive a query task from a registry 110 and can parse the query task into a series of SQL queries and a set of helper views which can function as temporary tables. In various implementations, the helper views can be used by an RDBMS 130 as input and/ or output tables for the series of SQL queries. For example, the aggregation engine can define an input helper view and an output helper view to be used during the execution of each of the SQL queries.

In some implementations, the aggregation engine 120 can organize the helper views into one or more helper view families. For example, the aggregation engine can identify a first helper view in a list of helper views and can place the first helper view into a first helper view family. The aggregation engine can then identify a next helper view in the list of helper views and can determine whether the next helper view has a lossless aggregation relationship with at least one of the helper views in the first helper view family. Where the next helper view does have a lossless aggregation relationship with at least one of the helper views in the first helper view family, the next helper view can be placed in the first helper view family. Where the next helper view does not have a lossless aggregation relationship with any one of the helper views in the first helper view family, the next helper view can be placed in a next helper view family. In some implementations, the aggregation engine can continue this process of placing helper views into helper view families by identifying the remaining helper views in the list of helper views and placing them into helper view families.

In some implementations, after helper views have been organized into one or more helper view families, the aggregation engine 120 can merge helper view families that share a common helper view. For example, the aggregation engine can compare each of the helper views in a first helper view family to each of the helper views in a next helper view family, and if the first helper view family and the next helper view family share at least one helper view in common with each other, the helper views in the next helper view family can be merged into the first helper view family.

In some implementations, the aggregation engine 120 can generate a family hierarchy based on the relationships between helper views in a helper view family. For example, input data can be stored in an operation table, and the operation table can be placed at the bottom of the family hierarchy. One or more helper views that can be populated directly from the operation table can be placed directly above the operation table in the family hierarchy. In various implementations, lossless relationships among helper views can be analyzed and where a higher level view can be derived from a lower level view without the loss of information or accuracy, the higher level view can be placed directly above the lower level view in the family hierarchy. For example, one or more helper views that can be populated directly from another helper view in the family hierarchy can be placed directly above the other helper view in the family hierarchy (e.g., an hourly count view can be populated directly from a plurality of minute count views, thus the hourly count view can be placed directly above the minute count view in the family hierarchy 300 of FIG. 3).

In various implementations, a helper view can be populated from a plurality of other helper views in a family hierarchy. For example, a minute average view can be derived from the combination of a minute count view and a minute sum view, thus the minute average view can be placed directly above both the minute count view and minute sum view in the family hierarchy 300 of FIG. 3.

In some implementations, the RDBMS 130 can be used as a repository store. For example, data stream repositories and continuous query tasks can be mapped onto the RDBMS. In this example, the RDBMS can receive instructions for creating helper views from an aggregation engine 120, and can store helper views and SQL queries associated with the helper views. In some implementations, processing capabilities of the RDBMS can be used to aggregate input data streams on a relation-to-relation basis. For example, input data streams can be stored in continuous, append-only relations upon which database queries can be processed.

In some implementations, the RDBMS can accept input data streams from one or more sources and send output data streams to one or more targets. For example, input data streams can be stored in an append-only source table and output data streams can be stored in an append-only destination table. As input data streams are received and output data streams are generated, the contents of the source table and the contents of the destination table can be continuously appended. The source table can be treated as a starting helper view and the destination table can be treated as an ending helper view. In various implementations, the RDBMS can store historical summary data, in temporary relations, for participating in other queries.

In some implementations, the RDBMS 130 can execute SQL queries associated with helper views in a family hierarchy and populate the helper views in the family hierarchy. Moreover, in some implementations, the RDBMS can populate a higher view by deriving data from a lower view in a hierarchy, thereby, keeping the data involved in a calculation to a minimum. Generally, a higher level view can have coarser granularity than a lower level view, thus the data stored by a higher level view is typically smaller than the data stored by a lower level view, and the smaller amount of data can correlate to achieving faster query results.

In some implementations, the RDBMS can identify a helper view in the family hierarchy and can identify an SQL query associated with the identified helper view. For example, the RDBMS can identify an SQL query from a series of SQL queries parsed from a query task by the aggregation engine 120. In various implementations, the RDBMS 130 can populate each helper view in a family hierarchy by executing the SQL query associated with each of the helper views. For example, an SQL query associated with a helper view can instruct the RDBMS to retrieve data from one or more input tables associated with the helper view and populate one or more output tables (e.g., the series of SQL queries can instruct the RDBMS to read from input helper views and write to output helper views until the destination table is populated).

In various implementations, a timer can trigger the aggregation process. For example, the aggregation of an hourly count view can proceed when the minute count views within the hour associated with the hourly count view have been populated.

FIG. 2 is a flowchart illustrating an example process 200 operable to construct one or more view family hierarchies from continuous query tasks. The process 200 can start at stage 210 when an aggregation engine receives one or more query tasks.

After a query task is received, the process 200 can proceed to stage 220. At stage 220, query tasks can be parsed into a series of SQL queries and a list of helper views. Query tasks can be parsed into a series of SQL queries and a list of helper views, for example, by an engine associated with a RDBMS (e.g., aggregation engine 120 of FIG. 1). For example, an aggregation engine 120 can separate a query task into SQL queries and helper views and can store the SQL queries and helper views separately. In some implementations, received query tasks can be stored in a list in a registry 110 of FIG. 1.

After query tasks are parsed into a series of SQL queries and a list of helper views, the process 200 can proceed to stage 230. At stage 230, input and output views can be defined for each SQL query. Input and output views for each SQL query can be defined, for example, by an engine associated with a RDBMS (e.g., aggregation engine 120). In some implementations, one or more input views associated with an SQL query can be defined based on the input data used to populate a view. For example, the minute average view of the family hierarchy 300 of FIG. 3 can be derived from a combination of the minute count view and the minute sum view, thus the minute count view and the minute sum view can be defined as input views for the SQL query associated with the minute average view.

In various implementations, the one or more output views associated with an SQL query can be the one or more views that are populated through execution of the SQL query. For example, the SQL query associated with the hourly count view of the family hierarchy 300 of FIG. 3 can populate the hourly count view. Thus the hourly count view can be defined as the output view for the SQL query associated with the hourly count view.

After input and output views are defined for each SQL query, the process 200 can proceed to stage 240. At stage 240, a set of view families can be constructed. A set of view families can be constructed, for example, by an engine associated with a RDBMS (e.g., aggregation engine 120). For example, each helper view parsed from one or more query tasks can be stored in a view family. In various implementations, a plurality of helper views parsed from one or more query tasks can be stored in a view family in such a manner that each of the helper views within the view family has a lossless aggregation relationship with at least one other helper view in the view family. In some implementations, a view family can consist of a single helper view.

After a set of view families is constructed, the process 200 can proceed to stage 250. At stage 250, view families within a set of view families can be merged together. View families within a set of view families can be merged, for example, by an engine associated with a RDBMS (e.g., aggregation engine 120). In some implementations, an aggregation engine 120 can merge view families that share a common helper view. For example, the aggregation engine 120 can compare each of the helper views in a first view family to each of the helper views in a next view family, and if the first view family and the next view family share at least one helper view in common with each other, the helper views in the next view family can be merged into the first view family.

After view families are merged together, the process 200 can proceed to stage 260. At stage 260, a family hierarchy can be constructed for each view family within a set of view families. In some implementations, a family hierarchy can be built according to the relationships among the helper views within a view family. In various implementations, lossless relationships among helper views can be analyzed and where a higher level view can be derived from a lower level view without the loss of information or accuracy, the higher level view can be placed directly above the lower level view in the family hierarchy. For example, one or more helper views that can be populated directly from another helper view in the family hierarchy can be placed directly above the other helper view in the family hierarchy (e.g., an hourly count view can be populated directly from a plurality of minute count views, thus the hourly count view can be placed directly above the minute count view in the family hierarchy 300 of

FIG. 3). After a family hierarchy is constructed for each view family, the process 200 can end at stage 270.

FIG. 3 is a block diagram illustrating an example view family hierarchy 300 of a view family comprising views having one or more lossless aggregation relationships with other views in the view family. Where a first view within a view family has a lossless aggregation relationship with another view in the view family, the first view can be located higher than the other view in the view family hierarchy. For example, each row of an hourly count view can be derived from a minute count view without a loss in information or accuracy, thus the hourly count view has a lossless aggregation relationship with the minute count view. Therefore, the hourly count view can be located higher than the minute count view in the view family hierarchy 300.

Generally, a view family hierarchy can consist of a set of overlapping trees where multiple ancestors can co-exist. For example, an hourly average view can be aggregated from an hourly count view and an hourly sum view, and a minute average view can be aggregated from a minute count view and a minute sum view. The view family hierarchy 300 can facilitate the derivation of a minute average view and an hourly average view from input data (e.g., data stored in minute count view and minute sum view). In the view family hierarchy 300, both the hourly average view and the minute average view share two common nodes, the minute count view and the minute sum view. Where the minute count view and minute sum view are shared by the hourly average view and the minute average view, the minute count view and the minute sum view can be used to populate both the minute average view and the hourly count and hourly sum views, thus the operation table does not have to be accessed in order to populate the hourly count and hourly sum views.

FIG. 4 is a flowchart illustrating an example process 400 operable to continuously aggregate one or more input data streams. The process 400 can start at stage 410 when a family hierarchy associated with a view family is identified for traversal. For example, an aggregation engine 120 of FIG. 1 can identify one of a plurality of family hierarchies stored in the aggregation engine for traversal.

After a family hierarchy is identified for traversal, the process 400 can proceed to stage 420. At stage 420, a first view in the family hierarchy can be identified. A first view in the family hierarchy can be identified, for example, by an engine associated with a RDBMS (e.g., aggregation engine 120). In some implementations, the aggregation engine 120 can identify the lowest-level view in the family hierarchy. For example, the lowest-level view in a family hierarchy can be the first view on the left of the lowest level of views in the family hierarchy (e.g., minute count view of FIG. 3).

After a first view is identified, the process 400 can proceed to stage 430. At stage 430, a determination can be made whether the identified view is a source view. The determination whether the identified view is a source view can be made, for example, by an engine associated with a RDBMS (e.g., aggregation engine 120). For example, a source view can be a view storing data from an input data stream (e.g., operation table of FIG. 3). In some implementations, if the identified view is not a source view, the process 400 can proceed to stage 440.

At stage 440, an SQL query associated with the identified view can be identified. The SQL query associated with the identified view can be identified, for example, by an aggregation engine (e.g., aggregation engine 120). For example, the SQL query associated with the identified view can be identified from the list of SQL queries parsed from a query task and stored by the aggregation engine 120 at stage 220 of FIG. 2. In some implementations, the SQL query can provide instructions for an RDBMS 130 to populate a view associated with the SQL query. For example, the SQL query associated with the hourly count view of FIG. 3 can instruct the RDBMS 130 to aggregate the minute count view of FIG. 3 for one hour.

In various implementations, the SQL query can define input and output helper views to be used in the execution of the SQL query. For example, the SQL query associated with the minute average view of FIG. 3 can instruct the RDBMS 130 to populate the output helper view, the minute average view, from two input helper views, the minute count view and the minute sum view.

After an SQL query associated with the identified view is identified, the process 400 can proceed to stage 450. At stage 450, the identified SQL query can be executed. The identified SQL query can be executed, for example, by RDBMS logic (e.g., RDBMS 130). In some implementations, the RDBMS 130 can aggregate lower views in a family hierarchy to populate an identified view. For example, in executing the SQL query associated with the hourly count view of FIG. 3, an RDBMS 130 can populate the hourly count view by aggregating a plurality of minute count views (e.g., aggregating the minute count views within the one hour period associated with the hourly count view). After the identified SQL query is executed, the process 400 can proceed to stage 460.

Returning to stage 430, if the identified view is a source view, the process 400 can proceed to stage 460. At stage 460, a determination can be made whether there is a next view in the family hierarchy (e.g., a view located above or to the right of the currently identified view in the family hierarchy). If there is a next view in the family hierarchy, the next view can be identified and the process 400 can proceed to stage 430.

If there is not a next view in the family hierarchy, the process 400 can end at stage 470.

Claims

1. A computer-implemented method, comprising:

parsing a query task into a plurality of structured query language queries and a plurality of views associated with the plurality of structured query language queries;

defining a plurality of views comprising input views and output views for the plurality of structured query language queries;

merging the plurality of views into one or more view families;

generating a family hierarchy associated with one or more of the plurality of views within one or more of the view families; and

aggregating one or more of the plurality of views into one or more aggregate output data streams.

2. The computer-implemented method of claim 1, wherein the one or more view families comprise at least two views that have a lossless relationship with each other.

3. The computer-implemented method of claim 1, wherein the one or more aggregate output data streams comprise low-volume data streams.

4. The computer-implemented method of claim 1, wherein the query task comprises a continuous query task.

5. The computer-implemented method of claim 1, wherein the aggregation of the one or more of the plurality of views into the one or more aggregate output data streams occurs in real-time.

6. The computer-implemented method of claim 1, further comprising:

presenting the one or more aggregate output data streams in one or more rolling application windows.

7. A system, comprising:

a registry operable to store query tasks;

an engine operable to parse a query task into one or more structured query language queries and one or more views associated with the one or more structured query language queries; and

a relational database management system operable to aggregate one or more input data streams into one or more output data streams.

8. The system of claim 7, wherein the engine is further operable to merge the one or more views into one or more view families.

9. The system of claim 8, wherein the one or more view families comprise at least two views that have a lossless relationship with each other.

10. The system of claim 7, wherein the one or more input data streams comprise high-volume data streams and the one or more output data streams comprise low-volume data streams.

11. The system of claim 7, wherein the query task comprises a continuous query task.

12. The system of claim 7, wherein the query task comprises a query task received from an application and generated from requirements associated with the application.

13. The system of claim 7, wherein the relational database management system is further operable to aggregate the one or more input data streams into the one or more output data streams in real-time.

14. The system of claim 7, wherein the relational database management system is further operable to present the one or more output data streams to an application, or other destination, in one or more rolling application windows.

15. One or more computer readable media operable to execute on a processor, the computer readable being operable to cause the processor to perform the operations comprising:

parsing a query task into a plurality of structured query language queries and a plurality of views associated with the plurality of structured query language queries;

defining one or more input views and an output view for each of the plurality of structured query language queries;

merging the plurality of views into one or more view families;

generating a family hierarchy associated with the one or more views within one or more view families; and

aggregating one or more input data streams into one or more output data streams.

16. The one or more computer-readable media of claim 15, wherein the one or more view families comprise at least two views that have a lossless relationship with each other.

17. The one or more computer-readable media of claim 15, wherein the one or more input data streams comprise high-volume data streams and the one or more output data streams comprise low-volume data streams.

18. The one or more computer-readable media of claim 15, wherein the query task comprises a continuous query task.

19. The one or more computer-readable media of claim 15, wherein the aggregation of the one or more input data streams into the one or more output data streams occurs in real-time.

20. The one or more computer-readable media of claim 15, wherein the computer readable is further operable to cause the processor to:

present the one or more output data streams in one or more rolling application windows.