Parallel model creation in cloud platform

A system, method, and computer-readable medium to receive at least one data table relating to a data set; receive a plurality of dimensions; combine, by a first parallelization process, the plurality of dimensions into a plurality of different clusters, each cluster being a grouping of different dimensions; transmit each of the plurality of different clusters to a cloud platform; divide, by a second parallelization process, the at least one data table into a plurality of different chunks of data; and transmit each of the plurality of different chunks of data to the cloud platform, in parallel to and independent of the transmission of the plurality of different clusters the cloud platform, the cloud platform to generate a data model based on a combination of the transmitted plurality of different clusters and the transmitted plurality of different chunks of data.

BACKGROUND

Enterprise software systems receive, generate, and store data related to many aspects of an enterprise. The size of data files related to an enterprise may be relatively large—several gigabytes in size. In some contexts, some applications and services may be delivered over the internet or other large network (e.g., a WAN or MAN) in a cloud computing architecture (e.g., a Platform as a Service, PaaS). In a scenario where large sized files might need to be transmitted between entities, systems, and platforms, the transfer of the large files may be time consuming and possibly error-prone given the large size of the files being transmitted.

More efficient systems and methods are desired to manage network traffic in a cloud platform environment.

DETAILED DESCRIPTION

The following description is provided to enable any person in the art to make and use the described embodiments. Various modifications, however, will remain readily apparent to those in the art.

In some example contexts, use-cases, and embodiments, one or more terms will be used in the present disclosure. As a matter of introduction and to ease the understanding of the present disclosure, a number of terms will be introduced, where the full meaning of the following terms will be further understood in context of the disclosure herein, on the whole.

FIG. 1is an illustrative block diagram of an architecture or system100, in one example. Examples of some embodiments of the present disclosure are not limited to the particular architecture100shown inFIG. 1. System100includes one or more client devices105running one or more applications110. Applications110may, in some embodiments, include a suite of different software applications having, at least to some extent, related functionality, similar user interfaces, and some ability to exchange data with each other. Applications110may include different software applications that support the operations and process of an organization. In some embodiments, one of the applications110may include functionality or a tool to define and create a data model (i.e., model) based on a data set. As used herein, a model is a representation of business data to define relationships, calculations, and data of an organization or business segment. In some embodiments, applications110may be configured to facilitate, support, and execute a program to generate a data model in a cloud computing platform (e.g., HANA Cloud Platform (HCP) by SAP SE, the assignee hereof).

The cloud platform120may include a controller135such as, but not limited to, a PaaS controller. Controller135may control storage associated with one or more servers125. Server125may be associated with storage device130such as, but not limited to, a storage area network. In some embodiments, cloud platform120may include more than one instance of a server such as application server125and more than one data storage device130. Storage device130may comprise any query-responsive data source or sources that are or become known, including but not limited to a structured-query language (SQL) relational database management system. Data stored in the storage device130may be stored as part of a relational database, a multi-dimensional database, an eXtendable Markup Language (XML) document, or any other data storage system storing structured and/or unstructured data. The data may be distributed among several relational databases, multi-dimensional databases, and/or other data sources. In some embodiments, storage device130may be implemented as an “in-memory” database (e.g., HANA), in which volatile (e.g., non-disk-based) storage (e.g., Random Access Memory) is used both for cache memory and for storing the full database during operation, and persistent storage (e.g., one or more fixed disks) is used for offline persistency and maintenance of database snapshots. Embodiments are not limited to any number or types of data sources.

Application server125may comprise a computing device that processes requests using a computer processor. For example, each application server125may support server-side scripting using Active Server Pages (ASP), Personal Home Page (PHP), or other scripting languages.

The devices at105may execute a browser that is used by a user to interface with service115.

System100further includes a backend system that can generate, automatically, in response to a request or call from cloud platform120, executable code or instructions to perform a process to create and/or support the creation of a model. In some aspects herein, a user may provide an indication or request for one or more models, as implemented in an application110and/or cloud platform120via network115, which may operate in cooperation with the processing of a backend system120to generate a program or response to effectuate the creation of the model that may be used in rendering a reporting a visualization.

In one example, a client105executes an application110to generate one or more data models via a user interface (UI) to a user on a display of client105. The user may manipulate UI elements within the UI to indicate and specify, either explicitly or implicitly, data aspects to include in a model to be generated, where the cloud platform120, in cooperation with server database130and possibly backend system140, to generate, for example, a model that might be used in an analysis and reporting regarding an enterprise's operational data.

FIG. 2is an illustrative architecture or system200to create a model. In particular, system200includes a serializer215that combines raw data (e.g., tables from a database) from a data source205with a user defined model from, for example, a cloud based modeler210. Data source205may include one or more data servers or instances thereof. Serializer215operates to combine the raw data including, for example, facts/measures of a data set comprising a fact table220and the model225from modeler210. In the example ofFIG. 2, a single request is transmitted from serializer215to a cloud platform230to generate a model235using the computing resources of the cloud platform. The single request transmitted to cloud platform230includes all of the information to generate business model235, including fact table220and model225. The size of the data file included in the single request may be several gigabytes in size. The large size of the file may cause undesirably long processing and transmission times. Additionally, the processing of a single large file including all of the information to generate the model may be susceptible to errors and/or long recovery times in the event of a failure in the processing and transmission of the single request.

FIG. 3is an illustrative depiction of an architecture or system300, in accordance with some embodiments herein. System300includes a modeler305that provides a user defined model310. The user defined model may include a plurality of dimensions that can be used in the analysis and reporting of data from data source315. In some instances, the user defined model310may be an OLAP (Online Analytical Processing) model. In some instances, user defined model310may include thousands of dimensions. As illustrated inFIG. 3, data source315includes, as an example, three servers320,325, and330. These servers may provide measures of a data set (e.g., a relational database).

As shown, the source315of the measures and the modeler305supplying the user defined model are external to a cloud platform380. As such, these data components need to be transmitted or otherwise forwarded to cloud platform380so that the cloud platform can generate a business model (e.g., models385,390) based thereon.

In some embodiments, system300provides a mechanism to transmit the requisite data to generate a model to a cloud platform in multiple messages. The multiple messages will contain, in aggregate, all of the requisite data to generate the desired model. However, each message in the example ofFIG. 3will contain less data than other methods and systems (e.g.,FIG. 2, system200) where a single request to the cloud platform included all of the data to generate a model.

In some embodiments, system300processes the two primary data types or components separately and independently of each other using a distinct parallelization process for each type of data. Moreover, the processing of the two types of data is accomplished simultaneously.

Referring toFIG. 3, the user defined model310is forwarded to a first parallelizer340. Vertical parallelizer340operates to combine the dimensions of the user defined model310into a plurality of different groupings or clusters. A cluster of dimensions herein refers to a grouping of one or more dimensions. As shown in the example ofFIG. 3, parallelizer340has grouped the dimensions received thereby into 3 clusters, including dimension cluster1(350), dimension cluster2(355), and dimension cluster N (360). As further illustrated inFIG. 3, each of the clusters350,355, and360contain different dimensions.

In some regards, each dimension can be treated independent of other dimensions and can be shipped to the cloud platform/processor380concurrently (i.e., parallel) with other dimensions. The different dimensions may be concurrently transmitted, for at least some period of time (i.e., not limited to parallel transmissions). In some embodiments, vertical parallelizer340can dynamically determine the number of clusters to be used to ship or transmit a user defined model and how the dimensions are to be distributed amongst the clusters. In some instances, dimensions may not all be the same size. Since the dimensions of the user defined model can be numerous and can vary in size relative to each other, it might not be efficient to simply transmit each dimension concurrently.

As an example, there are 10 dimensions in a user defined model, where dimensions 1-5 are each 1 MB in size and dimensions 6-10 are each 5 MB in size. In this simplified example, dimensions 1-5 may be grouped into a first cluster (e.g., 5 MB sized cluster) while dimensions 6-10 are each in a cluster of their own. In this example, all of the clusters are 5 MB in size. In some embodiments, the size of the dimension clusters can vary.

In some aspects, the creation of a modeling artifact (i.e., dimensions, models) might take a finite amount of time. The time may vary depending on the platform performing the task(s). For example, a repository process of an in-memory database might handle the creation of modeling artifacts where such a process might be single-threaded. Each dimension might need to be activated or made live, which takes some amount of time (e.g., about 1.5 seconds each). Given the many dimensions foreseen in practical examples, the parallelization processing of dimensions might benefit efficiencies.

In some aspects, processing times in system300may be increased by including more than 1 dimension in a message sent to cloud platform380, as well as sending more than 1 message at time. However, care should be taken not to over-burden system200. In some embodiments, vertical parallelizer340may seek to optimize the size of the messages of dimensions (i.e., dimension clusters) shipped to some optimum level. In some aspects, vertical parallelizer340may seek to optimize a risk of failure by maintaining a number of dimensions shipped in parallel at any given time below a certain threshold (i.e., how many requests to the cloud platform), since the more processes run in parallel at any given time increases a risk of failure.

Regarding the data table portion (i.e., raw data)315of the data comprising the basis for the model to be generated by cloud platform380, this data may be also processed in parallel. In particular, data315may be obtained from one or more data sources outside of the cloud platform and, in some instances, may comprise several gigabytes of data. In some embodiments herein, the data (e.g.,320,325, and330) may be divided into a plurality of chunks. As used herein, a “chunk” of data with respect to the table data315refers to smaller pieces or sub-sets of the whole set of data315. In the example ofFIG. 3, data315is processed by horizontal parallelizer345to divide the data into multiple chunks, including data chunk1(365), data chunk2(370), and data chunk3(375). In some embodiments, horizontal parallelizer345can transmit the chunks of data processed thereby concurrently (at least in part) and independent of each other.

Multiple requests including the plurality of dimension clusters output by vertical parallelizer340and the plurality of data chunks output by horizontal parallelizer345are sent, forwarded, or otherwise transmitted to cloud platform380in multiple, parallel (concurrent) requests so that a model may be generated by the cloud platform. As shown inFIG. 3, cloud platform380may include a facility to store the models385and390generated therein. These and other models may be saved for a future use, such as, for example, a reporting visualization of an organization's operational data.

In some aspects, vertical parallelizer340and horizontal parallelizer345each (independent of the other) provides support and facilitates fault isolation in the event of a failure in a request for a model generation by cloud platform380. For example, instead of a single request including the entirety of the data required for the model generation failing and having to resend and reprocess the entire single request in other systems and methods, some embodiments herein limit the extent of harm due to a failure to an isolated point of failure that can be retransmitted and reprocessed. Thus, in the event of a request failure an entity might only have to resend and reprocess a limited portion of the dimensions and/or fact table associated with the failed request.

The architecture and system300provides mechanism(s) including parallelization at both the user define model data and the data tables, as well independent parallelization within dimensions and data chunks. In this manner, architecture and system300can provide improved efficiencies and increases in throughput of data.

FIG. 4is an illustrative depiction of a model generated in some embodiments herein. In some regards, model400may be a detailed view representation of the model385generated by the system ofFIG. 3. As shown inFIG. 4, the model includes a plurality of dimensions405that may be used in analyzing (i.e., categorizing, presenting, etc.) measures of the fact table425. In the current example, the plurality of dimensions includes dimensions410,415, and420, whereas the fact table includes data chunks430,435, and440.

FIG. 5is a flow diagram of an example process500in some embodiments. Process500includes receiving at least one data table relating to a data set from at least one source at operation505. The data table (or other data structure) can include raw data or actual data relating to systems, operations, and processes. Operation510includes receiving a plurality of dimensions that may be used in an analysis of the data received at operation505. Together, the data received at operation505and operation510may comprise (at least) the data needed to generate a desired model by a cloud platform.

Operation515is part of a parallelization process performed by a first parallelizer (e.g., a vertical parallelizer). Operation515includes grouping the received dimensions into different clusters of dimensions. In some aspects, the size and number of the clusters may be optimized in accord with one or more techniques.

At operation520, each of the plurality of the different clusters is transmitted to a cloud platform. The different clusters may be transmitted in parallel, independent of each other.

Operation525is part of a parallelization process performed by a second parallelizer (e.g., a horizontal parallelizer). The labeling of one parallelizer herein as the “first” and the other as the “second” is provided solely as a means to distinguish the two from each other. No other significance is intended by such labeling herein. Moreover, the second parallelization process performed at operation525includes dividing the at least one data table into a plurality of different chunks of data. This dividing of the table data of a data set into different chunks might be optimized by chunking the data according to a size limit.

The parallelization aspects of operation515includes operation520and the parallelization aspects of operation525includes operation530, such that the transmission of the plurality of the different chunks of data to the cloud program may be performed in parallel and independent of the transmission of the plurality of different dimension clusters, as stated in operation530of process500.

In some embodiments, the processes (e.g.,FIG. 5) and systems (e.g.,FIGS. 1 and 3) disclosed herein may be optimized to execute in an optimal manner, given a number of considerations and/or parameters. In some aspects, the relevant parameters may be dynamically tuned so that a system in accordance with the present disclosure operates in an optimal manner.

The parallel model creation architecture disclosed herein includes two important underlying factors. As illustrated in the example ofFIG. 3, there are two parameters that may be tuned in an effort to achieve optimal performance of the model creation, in some embodiments. Those two parameters include the number of dimensions (n1) and the number of data chunks (n2) to be processed. As such, there is a need to determine how many clusters (n1) should be used for the dimensions and how many data chunks (n2) should be used for the table data. This problem is referred to as a model creation problem herein and the two parameters of n1 and n2 will be determined in light of come constraints.

In order to optimize the model creation problem herein, a determination will be made regarding the size of the data chunks to be used. While the data chunks might vary in size, applicant(s) herein have realized that using the same size for all of the data chunks provides significant gains with a minimum of costs (e.g., processing time, computing resources, etc.). In keeping the size of the data chunks the same, the importance of the number of chunks is important. It is noted that the size of the individual chunks might be determined in some embodiments.

The number of dimension clusters (n1) and the number of data chunks (n2) can be determined by solving a multiple objective optimization problem as follows below.

It is noted that the total time to create a model might be expressed, in a simplified expression, as a combination of the time to successfully create a model (Tc); the time, given a failure, to recover the model after the failure (Tf); and the probability of a failure in creating the model. Together, these factors can combine to determine the total time need to create a model in a cloud platform herein.
In one regard,Ttotal=Tc+Tr*Pf(1)

This formula is a simplified expression that treats the time to fail and the time to successfully create a model equally. However, this is not typically the case in reality. Accordingly, the relevant factors may be weighted in order to reflect the realities of an implementation. In some instances, the different contributors in equation (1) may be weighted to tune or focus the relationship on the failures or successful model creations. Such tuning may most likely depend on runtime environment that will impact the weighting parameters (e.g., a, b).

Accordingly, the optimization formulation may be represented by:
Ttotal=a*Tc(n1,n2)+b*Pf(n1,n2)*Tr(n1,n2)  (2)

where the objective is to minimize the total time to create the model (Ttotal), within some constraints. In some embodiments, equation (2) is subject to:
a>0,b>0,n1>0,n2>0,c>0;
Pf(n1,n2)<failure_tolerance_level; and
Tc(n1,n2)<c*(size_of_model+size_of_fact_table).

In some scenarios, we want to minimize the weighted sum of the successful model creation time Tc and the failure recovery time Pf*Tr. Here, a and b are predefined weights and Tc, Pf, and Tr are all functions of n1 and n2. When there are no failures, the successful model creation time (Tc) should have a linear upper bound determined by the size of the model creation problem. Hereinabove, c is a predefined parameter that represents the slope of the upper bound curve.

The failure probability constraint above should be below some threshold. That is, the probability of failure should not be too large, otherwise the system will not be useful. The threshold is the failure_tolerance_level listed above. Accordingly, Pf(n1, n2)<failure_tolerance_level is a constraint in this example.

As an example, an application service provider may guarantee a customer 99% service time in a contract for a service. It is further important to maintain data consistency as well since it is not desired to lose data or have data that is inaccurate. As such, the failure probability should be minimized.

It is noted that while it may be a goal to minimize the time to create a model, failures are not welcomed at the expense of speed. As such, an objective may be to minimize both time and failures.

Accordingly, the second constraint of to minimize successful model creation time (Tc) for a given model size is also considered. Taken together, these two constraints may be used to guarantee successful creation of a model in a given time for a particular size of model. That is, the model is created in less than some time.

Regarding equation (2), the optimization formula is a summation of two parts. There may be a desire or drive to minimize both components, in an effort to limit the overall result.

In some embodiments, the particular optimization formula that may be used in conjunction with the systems disclosed herein may vary from the specifically disclosed examples herein.

Apparatus600includes processor605operatively coupled to communication device620, data storage device630, one or more input devices610, one or more output devices620and memory625. Communication device615may facilitate communication with external devices, such as a reporting client, or a data storage device. Input device(s)610may comprise, for example, a keyboard, a keypad, a mouse or other pointing device, a microphone, knob or a switch, an infra-red (IR) port, a docking station, and/or a touch screen. Input device(s)610may be used, for example, to enter information into apparatus600. Output device(s)620may comprise, for example, a display (e.g., a display screen) a speaker, and/or a printer.

Data storage device630may comprise any appropriate persistent storage device, including combinations of magnetic storage devices (e.g., magnetic tape, hard disk drives and flash memory), optical storage devices, Read Only Memory (ROM) devices, etc., while memory625may comprise Random Access Memory (RAM), Storage Class Memory (SCM) or any other fast-access memory.

Services635and application640may comprise program code executed by processor605to cause apparatus600to perform any one or more of the processes described herein (e.g.,FIGS. 3 and 5). Embodiments are not limited to execution of these processes by a single apparatus.

Data645(either cached or a full database) may be stored in volatile memory such as memory625. Data storage device630may also store data and other program code and instructions for providing additional functionality and/or which are necessary for operation of apparatus600, such as device drivers, operating system files, etc.