Patent Description:
ETL (Extract, Transform, Load) processing may typically include extracting data from one or more data sources, sometimes transforming the data in some manner, such as to make the data compatible for an intended use, and loading the data to a target location, such as a data warehouse or other repository. ETL processes are commonly used to gather, consolidate or otherwise integrate data from multiple different data sources, repositories, or the like. Examples of data sources and repositories may include databases, data warehouses, big data storage clusters, and so forth. However, performing an ETL process with multiple different data cluster sources and targets can be challenging. For instance, if an ETL process utilizes multiple different data clusters, each of which may employ a different version of data cluster software or the like, the ETL process might not be able to be executed to completion from within the same application instance, such as due to conflicts between the different versions. For instance, in such situations,. it may be necessary to divide the execution of the ETL process among the various different data cluster versions, limit the scope of the ETL sources/targets to only those sources/targets that are known to be compatible, or impose other undesirable limitations.

Herein, as an example, in <CIT>, a node processing system is disclosed in which different nodes present in the system are configured to actively amend their included runtime libraries and/or process capabilities so as to adapt to the formal requirements needed for respective data transfers. Particularly, the above-mentioned system stipulates to store all available runtime libraries and particular process capabilities in a centralized storage area and send the respective elements to a corresponding system node whenever the latter are required for a given job request.

Furthermore, in <CIT>, a data processing apparatus for providing an object-orientated execution environment, such as a virtual machine operable for first and second version of the same class, is disclosed. Specifically, said data processing apparatus is configured so that different versions of a class can share data or information between them.

Specific embodiments are defined in the dependent claims.

Some implementations include a computing device able to communicate with a plurality of data clusters. For example, a first data cluster may be configured with a first version of data cluster software including a first library version, and a second data cluster may be configured with a second version of data cluster software including a second library version that is different from the first. The computing device may execute a single instance of an application to send, based at least on information in the first library version, to the first data cluster, a request for first data, and may receive the first data from the first cluster. Further, the computing device may send, based at least on information in the second library version, second data that is based on the first data to the second data cluster to store the second data with the second data cluster.

Some implementations herein are directed to techniques and arrangements for enabling a single instance of an ETL execution application to execute multiple ETL operations successively and/or concurrently with a plurality of different data cluster implementations executing different software versions for extracting, transforming and loading data. Examples herein provide a solution that includes the ability to execute an ETL process from start to end with a plurality of non-homogeneous data clusters within a single ETL execution application. For instance, the single ETL execution application may be able to execute the ETL process including a plurality of ETL operations with a plurality of different data cluster implementations, respectively, such as data clusters that are configured using different software versions (e.g., provided by different entities) and having corresponding different software libraries.

As one example, each ETL operation (e.g., discrete step) in an ETL process may be performed by interacting with or otherwise accessing a data cluster implementation that is different from data cluster implementations accessed in the other ETL operations. Accordingly, the ETL execution application may perform the multiple ETL operations of the ETL process without having to split or distribute the execution of the ETL process, thereby substantially improving the efficiency and ease of implementing the ETL process.

In some examples, the data cluster implementations accessed during execution of the ETL processes herein may store, manage, or otherwise maintain big data that may include data that comes from business functions, such as through a company's practices and procedures, human data generated from communications, and so forth. Other examples of big data may include database data, demographic data, machine-generated data, such as may be produced by the world's infrastructure systems, various types of sensors of weather, time, location, and so forth. Numerous other types of data will be apparent to those of skill in the art, and implementations herein are not limited to any particular type of data. According to some estimates, <NUM> percent of all big data may be unstructured data that may require some processing, normalizing, or other transformation to be able to provide useful business insights. Furthermore, the volume and variety of big data has been increasing dramatically as has the number of sources of this data.

In some examples herein, the data clusters may be big data clusters, which are a type of computational cluster that is able to store and, in some cases, analyze huge amounts of unstructured data in a distributed computing environment. One of the most well-known types of big data clusters is the HADOOP data cluster. Accordingly, in some cases, at least some of the different data cluster implementations herein may include HADOOP big data clusters employing various different configurations of HADOOP data storage, and which may further include HADOOP libraries and HADOOP distributed file systems (HDFSs).

In some cases, the data clusters herein may be configured with HADOOP open source distributed processing software on a group of configured computers as at least a portion of the respective data cluster. For instance, one or more computing devices in the data cluster may provide management functions for the other computing devices in the data cluster. The other computing devices in the data cluster may act as storage and processing nodes. HADOOP data clusters may be referred to as "shared nothing" systems because the computing devices in the data cluster may typically store data and process data independently of each other.

The data clusters herein may be implemented with any of a plurality of different versions of software and libraries provided by various different distribution entities. For example, a number of different distribution entities may provide data cluster platforms with their own implementations of the HADOOP framework, such as CLOUDERA Distribution for Hadoop, HORTONWORKS Data Platform and MAPR Distribution, and which may be opensource software in some cases. Each of the various distribution entities may utilize their own HADOOP libraries, which may each be a different library version from the library versions employed by the other distribution entities. Accordingly, data cluster requests generated from a first version of a HADOOP library used by a first distribution entity may not be compatible for use with a second version of a HADOOP data cluster implemented with software from a second distribution entity. Furthermore, in some cases, even different release versions from the same distribution entity may not be entirely compatible with each other.

Some examples herein are able to employ a plurality of different HADOOP library versions during the execution of an ETL process from within a single instance of an ETL execution application by implementing versioned class loaders that able to host particular ones of the plurality of different HADOOP library versions alongside the ETL execution application's main class loader. In addition, some examples include a service layer that can be used by the single instance of the ETL execution application to send information and request actions from the multiple different versions of the HADOOP libraries hosted by the multiple the class loader versions. In some examples, the ETL execution application may be implemented in JAVA programming language, and the main class loader and the versioned class loaders may be JAVA class loaders, although implementations herein are not limited to any particular programming language.

The examples herein enable an ETL execution application to execute an ETL process that includes a plurality of ETL operations performed with a plurality of different data clusters, each of which may be using a different HADOOP library version without having to restart the ETL execution application for using the ETL execution application with different versions of libraries and data clusters. Further, the system may be capable of executing an entire ETL process from within a single instance of an ETL execution application while utilizing multiple HADOOP data clusters configured using various different versions of data cluster platform software from various different distribution entities, including various different library versions. The single instance of the ETL execution application may invoke multiple HADOOP version library modules, each of which may correspond to respective ones of multiple different HADOOP library versions, for enabling access to the multiple data cluster implementations.

In addition, the ETL execution application may extract and/or store data on any of the multiple data cluster implementations during any discrete ETL operation of the ETL process. For example, the instance of the ETL execution application may execute an ETL process that includes multiple ETL operations performed on multiple data clusters, serially and/or concurrently. For example, the ETL execution application may extract data from a first data cluster implementation as a first ETL operation, extract data from a second data cluster implementation as a second ETL operation, and may store data on a third data cluster implementation as a third ETL operation, and each of the first data cluster implementation, the second data cluster implementation, and the third data cluster implementation may require use of a different respective library for interacting with the respective data cluster implementation.

In some examples herein , a service layer implemented at a service computing device that executes the ETL execution application may enable various different versions of the libraries to be utilized side-by-side, either serially or in parallel. In some examples, the ETL execution application may employ a main class loader that communicates ETL operations to the service layer. The service layer may invoke a separate HADOOP version library module for each separate data cluster version and associated HADOOP library version. Further, each version of a library module may have an associated version of a class loader corresponding to one of the library versions. The service layer receives the ETL operation request and routes the ETL operation request to the correct class loader version for the data cluster that is the target of the ETL operation request. The version of the class loader may use the corresponding version library and a corresponding application programming interface (API) for the target data cluster to send the ETL operations request to the target data cluster, and in some cases, may return a result from the target data clusters. The ETL execution application may be able to extract data from any or all of the data cluster implementations when executing a single ETL process by passing a respective ETL operation to the service layer and thereby to a corresponding one of the HADOOP version library modules and class loader version for the HADOOP library version required by the target data cluster to which the ETL operation relates.

When an ETL operation requires interacting with one of the data clusters, which, in turn, requires a specific version of the library corresponding to that data cluster implementation, the ETL execution application may pass the big data request to the service layer for utilizing a corresponding one of the available versions of the library modules. For instance, the versions of the library modules enable separate library versions to coexist on the computing device executing the ETL process without interfering with each other. In particular, different library versions may be incompatible an any number of ways, such as by having different security or authentication requirements, different command structures, different functions associated with classes or other library objects having the same name, and so forth.

Each library module version may have its own class loader version which allows each library module version execute the particular class loader version to handle one respective library version. The class loader version may process a data request using the respective library version and return the results to the main class loader through a service layer program and local API. For example, a class loader version may isolate and locate classes or other library objects within a particular version of a library at runtime. Accordingly, each class loader version may be configured to host a particular library version for locating and utilizing particular library objects from the particular library version during execution of a requested ETL operation with the corresponding data cluster for performing an ETL operation with a target data cluster.

According to the invention, a system includes two data clusters, each of which is implemented using a different HADOOP library version, such as from different distribution entities, or the like. Further, suppose that a user wants to execute an ETL process to extract data from the first data cluster and store the results in the second data cluster. In this scenario the ETL execution application uses the service layer to pass a data request to the class loader version hosting the HADOOP library version corresponding to the first data cluster which, in turn, sends the data request to the first cluster based on information obtained from the HADOOP library version. The request causes the first data cluster to send the requested data to the class loader version, which provides the requested data to the ETL execution application via the service layer. The ETL execution application does transform the received data based on one or more operations specified in the ETL process. The ETL execution application does then send, through the service layer, the transformed data to a second version class loader of a second version library module hosting a second HADOOP library version corresponding to the second cluster. The second version class loader uses information in the second HADOOP library version to send the transformed data to the second cluster.

In an example, suppose that the ETL process requests data from a plurality of different data cluster versions, each implemented using a different HADOOP library version. Accordingly, similar to the example above, the ETL execution application may execute one or more ETL operations of the ETL process for extracting data from the plurality of different data cluster versions. For example, the ETL execution application may send requests to the service layer for each different data cluster version from which data is to be extracted. The service layer may direct the requests to the respective versions of the class loaders hosting the respective HADOOP library versions corresponding to the respective data clusters from which data is to be extracted.

Thus, the data requests are sent to the respective data clusters by the respective versions of the class loaders using information in the respective library versions, and the requested data may be received by the corresponding library module version and class loader version.

As another example, suppose that an ETL process is configured to relocate data directly from a first data cluster to a second data cluster, each implemented using a different HADOOP library version, and without storing a large amount of data at a third location temporarily. This scenario may occur when data is desired to be extracted from a first data cluster, such as for the purpose of migrating the data to a new system or backing the data up to a different location, but the data clusters are implemented with different HADOOP library versions. In the implementations herein, a single instance of an ETL execution application may execute an ETL process to invoke the corresponding version library modules and class loader versions for the respective libraries, as described, above to essentially stream the data from the first data cluster, through the computing device executing the ETL execution application, and to the second data cluster, reducing the likelihood of data corruption that might be introduced, e.g., because of intermediate data conversion/storage. For instance, without this capability, system analysts and administrators might need to store a large amount of the data at a temporary third location and/or in an intermediate format and then re-ingest the data to store the data to the destination data cluster.

For discussion purposes, some example implementations are described in the environment of one or more service computing devices in communication with a plurality of different data clusters having HADOOP implementations from different distribution entities for storing data. However, implementations herein are not limited to the particular examples provided, and may be extended to other types of computing system architectures, other types of data storage environments, other data storage cluster types, other distribution entities, other types of data, and so forth, as will be apparent to those of skill in the art in light of the disclosure herein.

<FIG> illustrates an example architecture of a system <NUM> able to perform ETL operations with a plurality of non-homogenous versions of data clusters according to some examples. The system <NUM> includes one or more service computing device(s) <NUM> that are able to communicate with, or otherwise coupled to, a plurality of data clusters <NUM>, each data cluster <NUM> including a plurality of computing devices <NUM> coupled to the one or more service computing device(s) <NUM> through one or more networks <NUM>. Further, the service computing device(s) <NUM> are able to communicate over the network(s) <NUM> with one or more client computing devices <NUM>.

In this example, three data clusters <NUM> are illustrated comprising a first data cluster <NUM>(<NUM>), a second data cluster <NUM>(<NUM>), and a third data cluster <NUM>(<NUM>), although more or fewer data clusters may be included in other examples. Accordingly, implementations herein are not limited to any particular number of the data clusters <NUM>. Further, the plurality of data cluster computing devices <NUM> may be arranged as first version data cluster computing device(s) <NUM>(<NUM>) at the first data cluster <NUM>(<NUM>), second version data cluster computing device(s) <NUM>(<NUM>) at the second data cluster <NUM>(<NUM>), third version data cluster computing device(s) <NUM>(<NUM>) at the third data cluster <NUM>(<NUM>), and so forth.

In some examples, each different data cluster <NUM>(<NUM>)-<NUM>(<NUM>) may have a different software version installed on its respective computing devices <NUM>(<NUM>)-<NUM>(<NUM>). For example, the respective computing devices <NUM>(<NUM>)-<NUM>(<NUM>) of the respective different clusters <NUM>(<NUM>)-<NUM>(<NUM>) may be configured using a different version of a distribution entity data cluster platform of the HADOOP framework, such as CLOUDERA Distribution for HADOOP, HORTONWORKS Data Platform, MAPR Distribution, and so forth. Thus, as one example, the first version data cluster computing devices <NUM>(<NUM>) of the first data cluster <NUM>(<NUM>) are configured with a first version of a data cluster platform, such as from a first distribution entity; the second version data cluster computing devices <NUM>(<NUM>) of the second data cluster <NUM>(<NUM>) may be configured with a second version of a data cluster platform, such as from a second distribution entity that is different from the first distribution entity; and the third version data cluster computing devices <NUM>(<NUM>) of the third data cluster <NUM>(<NUM>) may be configured with a third version of a data cluster platform from a third distribution entity that is different from the first and second distribution entities. In some examples, some or all of the implementations of the data cluster computing device(s) <NUM>(<NUM>)-<NUM>(<NUM>) may be configured as big data clusters, such as HADOOP big data clusters, that are able to store and analyze huge amounts of unstructured data in a distributed computing environment.

The one or more networks <NUM> may include any suitable network, including a wide area network, such as the Internet; a local area network (LAN), such as an intranet; a wireless network, such as a cellular network, a local wireless network, such as Wi-Fi, and/or short-range wireless communications, such as BLUETOOTH®; a wired network including Fibre Channel, fiber optics, Ethernet, or any other such network, a direct wired connection, or any combination thereof. Accordingly, the one or more networks <NUM> may include both wired and/or wireless communication technologies. Components used for such communications can depend at least in part upon the type of network, the environment selected, or both. Protocols for communicating over such networks are well known and will not be discussed herein in detail. Accordingly, the service computing device(s) <NUM>, the data cluster computing devices <NUM>, and the client device(s) <NUM> are able to communicate over the one or more networks <NUM> using wired or wireless connections, and combinations thereof.

In some examples, the service computing device(s) <NUM> may include one or more servers that may be embodied in any number of ways. For instance, the programs, other functional components, and at least a portion of data storage of the service computing device(s) <NUM> may be implemented on at least one server, a cluster of servers, a server farm, a data center, a cloud-hosted computing service, and so forth, although other computer architectures may additionally or alternatively be used. Additional configuration details of the service computing device(s) <NUM> are discussed below with respect to <FIG>.

Each client device <NUM> may be any suitable type of computing device, such as a desktop, laptop, tablet computing device, mobile device, smart phone, wearable device, terminal, and/or any other type of computing device able to send data over a network. A user <NUM> may be associated with a respective client device <NUM>, such as through a respective user account, user login credentials, or the like. Furthermore, the client device(s) <NUM> may be able to communicate with the service computing device(s) <NUM> through the one or more networks <NUM>, through separate networks, direct connection, or through any other suitable type of communication connection.

Further, each client device <NUM> may include a respective instance of a client application <NUM> that may execute on the client device <NUM>, such as for communicating with a management program <NUM> or other programs or applications executable on the service computing device(s) <NUM>, as discussed below. In some cases, the client application <NUM> may include a browser or may operate through a browser, while in other cases, the client application <NUM> may include any other type of application having communication functionality enabling communication with the management program <NUM> over the one or more networks <NUM>. As one example, the user <NUM> may employ the client application <NUM> to communicate with the management program <NUM>, such as for sending one or more ETL instructions <NUM> to the management program <NUM> to configure and/or schedule one or more ETL processes <NUM> for execution by an execution instance of an ETL execution application <NUM> on the service computing device(s) <NUM>.

The service computing device(s) <NUM> may execute the management program <NUM> and the ETL execution application <NUM> for executing the one or more ETL processes <NUM> that may be configured by the user <NUM>. Each ETL process <NUM> may include one or more ETL operations that are performed during execution of the ETL process <NUM>, such as for extracting data from a specified data cluster <NUM>, transforming data, or loading data to a specified data cluster <NUM>.

The service computing device(s) <NUM> may further include a main class loader <NUM> that may be included in or may otherwise be executed by the ETL execution application <NUM> for loading an ETL process <NUM>, as discussed additionally below. As one example, the main class loader <NUM> and other class loaders described herein may be JAVA class loaders, although implementations herein are not limited to any particular computer programming language unless explicitly specified.

The service computing device(s) <NUM> may further include a service layer <NUM> that may include an executable service layer program <NUM> that may communicate with the ETL execution application <NUM> and receive communications from via a local API <NUM>. The service layer may further include other APIs used to communicate with the respective data clusters <NUM>. For instance, each data cluster <NUM> may have one or more different APIs that are used for communication with the respective version of the data cluster computing devices <NUM> at that data cluster <NUM>. Accordingly, in this example, the service layer <NUM> may include a first data cluster API <NUM>, a second data cluster API <NUM>, and a third data cluster API <NUM> that may be used for communication with the respective data clusters <NUM>(<NUM>), <NUM>(<NUM>) and <NUM>(<NUM>), respectively.

In addition, the service computing device(s) <NUM> may include respective library module versions for respective libraries of respective ones of the data clusters <NUM>. In this example, the library module versions are illustrated as part of the service layer <NUM> for convenience of illustration, but this is not required. Accordingly, the service layer <NUM> may include a first version library module <NUM>, that may be used for interacting with a library of the first data cluster <NUM>(<NUM>), a second version library module <NUM> that may be used for interacting with a library of the second data cluster <NUM>(<NUM>), and a third version library module <NUM> that may be used for interacting with a library of the third data cluster <NUM>(<NUM>). In addition, each version of the library module may have an associated version of a class loader that may be included in or otherwise invoked by the respective version of the library module. Thus, the service computing device(s) <NUM> includes a first version class loader <NUM> associated with the first version library module <NUM>, a second version class loader <NUM> associated with the second version library module <NUM>, and a third version class loader <NUM> associated with the third version library module <NUM>.

In some examples, the service layer program <NUM> may receive an ETL request from the main class loader <NUM> and may route the ETL request to the correct version library module, e.g., based on determining the target data cluster <NUM>. The version library module may invoke its version class loader to access the library version for the targeted data cluster <NUM> and to send the ETL request to the targeted data cluster <NUM>.

The data cluster computing devices <NUM> may include, for each data cluster <NUM>, a respective data cluster manager program that is executable on at least one data cluster computing device <NUM> at each data cluster <NUM>. Further, the data cluster computing devices <NUM> of each data cluster <NUM> may include a respective library that is utilized by the service computing device(s) <NUM> for interacting with that respective data cluster. The respective version of the data cluster manager program and version of the library may correspond to the version of the data cluster platform installed at the respective data cluster <NUM>. Accordingly, the respective data cluster manager programs and libraries at the respective data clusters <NUM> may differ substantially from each other in some cases.

In this example, a first version data cluster manager program <NUM> and first version library <NUM> are installed at the first version data cluster computing devices <NUM>(<NUM>) of the first data cluster <NUM>(<NUM>); a second version data cluster manager program <NUM> and second version library <NUM> are installed at the second version data cluster computing devices <NUM>(<NUM>) of the second data cluster <NUM>(<NUM>); and a third version data cluster manager program <NUM> and third version library <NUM> are installed at the third version data cluster computing devices <NUM>(<NUM>) of the third data cluster <NUM>(<NUM>).

In some cases, the versions of the libraries <NUM>, <NUM>, and <NUM> of the respective data clusters <NUM>(<NUM>), <NUM>(<NUM>), and <NUM>(<NUM>) may be downloaded from the respective data clusters <NUM>(<NUM>), <NUM>(<NUM>), and <NUM>(<NUM>), and stored at the service computing device(s) <NUM>, or may be otherwise accessed before or during execution of an ETL process <NUM>. As one example, copies of the libraries <NUM>, <NUM>, and <NUM> may be maintained at the service computing device(s) <NUM> in association with the respective version class loaders <NUM>, <NUM> and <NUM>, respectively. In some cases, the versions of the libraries <NUM>, <NUM>, and <NUM> may include, or may be configured to be used with, the data cluster APIs <NUM>, <NUM>, and <NUM>, respectively. In addition, the libraries <NUM>, <NUM>, and <NUM> may include various other types of library objects, such as pre-compiled executable code and subroutines, collections of functions, classes, values and/or type specifications that may be used for interacting with the data clusters <NUM>(<NUM>), <NUM>(<NUM>) and <NUM>(<NUM>), respectively, and the respective associated data.

In addition, one, some, or all of the data clusters <NUM> may receive data from various data sources and may store the received data at the respective data cluster <NUM>. In this example, the first data cluster <NUM>(<NUM>) may receive data <NUM> from data sources <NUM>(<NUM>)-<NUM>(z); the second data cluster <NUM>(<NUM>) may receive data <NUM> from data sources <NUM>(<NUM>)-<NUM>(y); and the third data cluster <NUM>(<NUM>) may receive data <NUM> from data sources <NUM>(<NUM>)-<NUM>(x). Furthermore, as discussed below, in some cases the data <NUM>, <NUM>, <NUM> stored at the respective data clusters <NUM>(<NUM>), <NUM>(<NUM>), <NUM>(<NUM>) may be received from the service computing device(s) <NUM> and/or other ones of the data clusters <NUM>, such as through ETL processing, rather than, or in addition to, being received from the data sources <NUM>, <NUM>, <NUM>.

As one example, suppose that the user <NUM> has sent the ETL instruction <NUM> to instruct the management program <NUM> to execute the ETL execution application <NUM> to perform an ETL process <NUM> to extract data from the first data cluster <NUM>(<NUM>) and store the results in the third data cluster <NUM>(<NUM>). In this example, the ETL execution application <NUM> may use the service layer <NUM> including the service layer program <NUM> and local API <NUM> to pass an ETL data request <NUM> to the first version class loader <NUM>, which may host the first version library <NUM> corresponding to the first data cluster <NUM>(<NUM>). The first version class loader <NUM> may employ the first data cluster API <NUM> and the first version library <NUM> to send the ETL data request <NUM> in proper format to the first version data cluster computing devices <NUM>(<NUM>) at the first cluster <NUM>(<NUM>). The ETL data request <NUM> may cause at least one of the first version data cluster computing devices <NUM>(<NUM>) at the first cluster <NUM>(<NUM>) to send the requested data <NUM> to the service computing device(s) <NUM>, such as to the first version class loader <NUM>, which may forward the requested data to the ETL execution application <NUM>, such as via the service layer program <NUM> and the local API <NUM>.

In addition, the ETL execution application <NUM> may send, via the local API <NUM>, an ETL request to the service layer program <NUM> for sending the data <NUM> received from the first data cluster <NUM>(<NUM>) to the third data cluster <NUM>(<NUM>). For example, the service layer program <NUM> may route the request to the third version library module <NUM>, which may invoke the third version class loader <NUM>, which may host the third version library <NUM>. The third version class loader may use information from the third version library <NUM> and the third data cluster API <NUM> to send the ETL data <NUM> to the third data cluster <NUM>(<NUM>). One or more of the third version data cluster computing devices <NUM>(<NUM>) may receive and store the received ETL data <NUM>.

<FIG> is a block diagram illustrating an example of an ETL execution application instance <NUM> executing an ETL process <NUM> according to some implementations. In this example, similar to the example discussed above with respect to <FIG>, suppose that the user <NUM> has sent the ETL instruction <NUM> to instruct the management program <NUM> to execute the ETL execution application <NUM>. The ETL execution application <NUM> may execute as a single ETL execution application instance <NUM> illustrated in <FIG> to perform a specified ETL process <NUM>. Further, in this example, suppose that the ETL process <NUM> includes three ETL operations, namely, a first ETL operation <NUM> to extract data from the first data cluster <NUM>(<NUM>), a second ETL operation <NUM> to transform the extracted data in a specified manner, and a third ETL operation <NUM> to store the transformed data at the third data cluster <NUM>(<NUM>).

When the ETL execution application instance <NUM> begins execution, it may call the main class loader <NUM> to execute the first operation <NUM> of the ETL process <NUM> to send an ETL data request to the service layer program <NUM>, such as via the local API <NUM>. In addition, based on determining that the first data cluster <NUM>(<NUM>) is the target of the request, the service layer program <NUM> may invoke execution of the first version library module <NUM>, which may in turn call the first version class loader <NUM>, which is able to access and use the library objects in the first version library <NUM> corresponding to the first data cluster <NUM>(<NUM>). As one example, the first version library <NUM> may be a HADOOP library corresponding to a version of a HADOOP data cluster platform implemented on the first cluster <NUM>(<NUM>).

The first version class loader <NUM> may employ the first data cluster API <NUM> and information from the first version library <NUM> to send the ETL data request <NUM> in proper form to the first version data cluster computing devices <NUM>(<NUM>) at the first cluster <NUM>(<NUM>). The ETL data request <NUM> may cause at least one of the first version data cluster computing devices <NUM>(<NUM>) at the first cluster <NUM>(<NUM>) to send the requested data <NUM> to the ETL execution application instance <NUM> at the service computing device(s) <NUM>, such as via the first data cluster API <NUM> to the first version class loader <NUM>, which may send the requested data to the ETL execution application instance <NUM> via the service layer program <NUM>.

According to the invention, the main class loader <NUM> executes the second ETL operation <NUM>, such as to transform the requested data in some manner, e.g., to normalize the data, to correlate the data with other data, to filter the data, or any of numerous other data operations, as will be apparent to those of skill in the art having the benefit of the disclosure herein. Furthermore, the main class loader <NUM> may execute the third ETL operation <NUM> for sending the transformed data as ETL data <NUM> to the third data cluster <NUM>(<NUM>). For example, the main class loader <NUM> may send an ETL request to the service layer program <NUM> via the local API <NUM>. Based at least in part on determining that the target of the ETL request is the third data cluster <NUM>(<NUM>), the service layer program <NUM> may invoke execution of the third version library module <NUM>, which may call the third version class loader <NUM>. The third version class loader <NUM> may employ the third data cluster API <NUM> and information from the third version library <NUM>, which may be hosted by the third version class loader <NUM>, to send the ETL data <NUM> to the third data cluster <NUM>(<NUM>). One or more of the third version data cluster computing devices <NUM>(<NUM>) may receive and store the ETL data <NUM>.

<FIG> is a block diagram illustrating an example of execution of an ETL process according to some implementations. For example, as discussed above, an ETL execution application instance <NUM> may call the main class loader <NUM> to execute an ETL process <NUM> that includes a first ETL operation <NUM>, a second ETL operation <NUM>, a third ETL operation <NUM>, and a fourth ETL operation <NUM>. Furthermore, in this example, suppose that the data <NUM> maintained by the first data cluster <NUM>(<NUM>) includes data maintained in a data structure <NUM> that includes a plurality of rows <NUM>, <NUM>, <NUM>,. , such as rows in a table, a database, or any other suitable type of data structure <NUM>. Additionally, suppose that the first ETL operation <NUM> is configured to obtain the data from the data structure <NUM> on a row-by-row basis, e.g., as a row of data <NUM>, one row at a time, and pass the received row of data to the second ETL operation <NUM>.

Further, in this example, the second ETL operation <NUM> may be configured to receive the row of data <NUM> from the first ETL operation <NUM> and obtain second data <NUM> from the second data cluster <NUM>(<NUM>) that is to be combined with or otherwise correlated with the row of data <NUM> obtained by the first ETL operation <NUM>. In addition, the third ETL operation <NUM> may be configured to receive the row of data <NUM> and the second data <NUM>, and may, for example, normalized or otherwise transformed the data <NUM> and/or <NUM> make such that the second data <NUM> is compatible with the data in the row of data <NUM> received from the first data cluster <NUM>(<NUM>), and vice versa.

Next, the fourth ETL operation <NUM> may be configured to specify that the data <NUM> from the third ETL operation <NUM>, including the row of data <NUM> and the second data <NUM>, which may have been transformed at <NUM>, is sent to the third data cluster <NUM>(<NUM>) for inclusion together in a data structure <NUM>, which may include a plurality of rows <NUM>, <NUM>, <NUM>,. , and which may include at least one column <NUM> for inclusion of the data from the second data cluster <NUM>(<NUM>). Thus, the data structure <NUM> may be populated row-by-row by receipt of each row of data <NUM> and second data <NUM>.

The techniques discussed above with respect to <FIG> and <FIG> may be utilized for executing the ETL process <NUM> of <FIG> using the single application instance <NUM> to perform all of the ETL operations <NUM>-<NUM>. For example, as discussed above, the main class loader <NUM> may send the ETL operations <NUM>, <NUM>, and <NUM> to the service layer program <NUM>, which in turn may invoke execution of respective versions of the library module <NUM>, <NUM> and <NUM> for sending appropriate ETL communications to the first data cluster <NUM>(<NUM>), the second data cluster <NUM>(<NUM>), and the third dated cluster <NUM>(<NUM>), respectively.

<FIG> is a block diagram illustrating an example of execution of an ETL process according to some implementations. For example, an ETL execution application instance <NUM> may call the main class loader <NUM> to execute an ETL process <NUM> that includes a first ETL operation <NUM>, a second ETL operation <NUM>, a third ETL operation <NUM>, and a fourth ETL operation <NUM>. Furthermore, in this example, similar to the example of <FIG> discussed above, suppose that the data <NUM> maintained by the first data cluster <NUM>(<NUM>) includes data maintained in the data structure <NUM> that includes the plurality of rows <NUM>, <NUM>, <NUM>,. , such as rows in a table, a database, or any other suitable type of data structure <NUM>. The example of <FIG> includes a fourth data cluster <NUM>(<NUM>) including one or more fourth version data cluster computing devices <NUM>(<NUM>), having a fourth version data cluster manager program <NUM>, a fourth version library <NUM>, and data <NUM>.

In some cases, the ETL operations to be performed by the ETL execution application instance <NUM> when performing the entire ETL process <NUM> may be determined on a row-by-row basis as each data row is processed. For instance, within the same ETL process <NUM>, two different rows of data might travel different paths (i.e., be subject to different ETL operations) within the ETL process <NUM> and, by doing so, cause the ETL process <NUM> to access different data clusters for the different respective rows of data.

In this example, suppose that the first ETL operation <NUM>, similar to operation <NUM> discussed above with respect to <FIG>, is configured to read the data from the data structure <NUM> on a row-by-row basis, e.g., one row at a time, and pass the received row of data to the second ETL operation <NUM>. Accordingly, the main class loader <NUM> may execute the first ETL operation <NUM> to receive the first row of data <NUM>. Further, in this example, the second ETL operation <NUM> may be configured to check the data <NUM> stored at the second data cluster <NUM> to determine if there is data for correlation with the row of data currently being processed. If so, the second ETL operation <NUM> may be configured to pass the row of data and the correlated second data obtained from the second data cluster to the third ETL operation <NUM>. On the other hand, if there is not data at the second data cluster <NUM>(<NUM>) for correlation with the row of data currently being processed, the second ETL operation <NUM> may be configured to skip the third ETL operation <NUM> and instead pass the data from the row currently being processed to the fourth ETL operation <NUM>.

In this example, the first row of data <NUM> is being processed and suppose that there is no second data at the second data cluster <NUM>(<NUM>) for correlation with the first row of data <NUM>. Accordingly, the first row of data <NUM> may be passed to the fourth ETL operation <NUM> and the third ETL operation <NUM> is not performed. At the fourth ETL operation <NUM>, the first row of data <NUM> is sent to the fourth data cluster <NUM>(<NUM>) for storage by the fourth data cluster <NUM>(<NUM>).

The techniques discussed above with respect to <FIG> and <FIG> may be utilized for executing the ETL process <NUM> of <FIG> using the single application instance <NUM> to perform the ETL operations <NUM>-<NUM>, which performance is dependent in part on the data content being processed. As discussed above, the main class loader <NUM> may send the ETL operations <NUM>, <NUM>, <NUM> and <NUM>, when performed, to the service layer program <NUM>, which in turn may invoke execution of respective versions of the library modules <NUM>, <NUM>, <NUM> and a library module configured for the fourth version library <NUM> (not shown in <FIG>) for sending appropriate ETL communications to the first data cluster <NUM>(<NUM>), the second data cluster <NUM>(<NUM>), the third dated cluster <NUM>(<NUM>), and the fourth data cluster <NUM>(<NUM>), respectively. Additionally, this example allows for the use of multiple data cluster versions during the execution of a single multi-step ETL process <NUM> by a single ETL execution application instance <NUM>, eliminating the need for splitting ETL execution or implementing complex distributed computing systems.

<FIG> is a block diagram illustrating an example of execution of an ETL process according to some implementations. <FIG> illustrates a continuation of the example of <FIG> discussed above for execution of the ETL execution application instance <NUM>. In the example of <FIG>, the second row of data <NUM> is obtained from the data structure <NUM> at the first data cluster <NUM>(<NUM>) by execution of the first ETL operation <NUM>. During execution of the second ETL operation <NUM>, second data <NUM> is correlated with the second row of data <NUM> and is received from the second data cluster <NUM>(<NUM>). Since the second ETL operation <NUM> identified second data <NUM> to correlate with the second row of data <NUM>, the data is passed from the second ETL operation <NUM> to the third ETL operation <NUM>, rather than to the fourth ETL operation <NUM>.

The third ETL operation <NUM> is executed to send the data <NUM> from the second ETL operation to the third data cluster <NUM>(<NUM>) for inclusion in the data structure <NUM> at the third data cluster <NUM>(<NUM>). Accordingly, the ETL process <NUM> may be executed continually with the third data cluster <NUM>(<NUM>) or the fourth data cluster <NUM>(<NUM>) receiving data from the ETL process <NUM>, depending on whether a row of data being processed is able to be correlated with data from the second data cluster <NUM>.

<FIG> is a block diagram illustrating an example of execution of an ETL process according to some implementations. For example, as discussed above, an ETL execution application instance <NUM> may call the main class loader <NUM> to execute an ETL process <NUM> that includes a first ETL operation <NUM>, a second ETL operation <NUM>, a third ETL operation <NUM>, and a fourth ETL operation <NUM>. The example of <FIG> illustrates that implementations herein are able to receive data concurrently from multiple data clusters by execution of a single ETL operation and further that data processing may be offloaded by an ETL operation to one of the data clusters and the result later retrieved by another ETL operation.

The first ETL operation <NUM> is configured to concurrently receive first data <NUM> from the first data cluster <NUM>(<NUM>) and second data <NUM> from the second data cluster <NUM>(<NUM>) by execution of the single first ETL operation <NUM>. For instance, due to the configuration of the implementations disclosed herein, including the plurality of independently executable library modules, any number of data clusters <NUM> may be accessed concurrently by a single ETL operation for sending or receiving data from the respective data clusters <NUM>.

The second ETL operation <NUM> may be executed to receive the first data <NUM> and the second data <NUM> from the first ETL operation <NUM>, and to send the first and second data <NUM> to the third data cluster <NUM>(<NUM>). In addition, in this example, suppose that the third data cluster <NUM>(<NUM>) also receives third data <NUM> from the data source <NUM>(<NUM>). Furthermore, suppose that the second ETL operation <NUM> instructs the third data cluster <NUM>(<NUM>) to process the first data, the second data, and the third data at the third data cluster <NUM>(<NUM>). The processing performed by the third data cluster <NUM>(<NUM>) may be any type of data processing from simple to extremely complex data processing.

The third ETL operation <NUM> may be executed to obtain the output data <NUM> that is the result of the data processing performed by the third data cluster <NUM>(<NUM>). Furthermore, the fourth ETL operation <NUM> may be executed to receive the output data <NUM> from the third ETL operation <NUM> and to send the output data <NUM> to the fourth data cluster <NUM>(<NUM>).

<FIG> is a flow diagram illustrating an example process <NUM> for performing ETL processing with non-homogeneous data clusters according to some implementations. The process is illustrated as a collection of blocks in a logical flow diagram, which represents a sequence of operations, some or all of which may be implemented in hardware, software or a combination thereof. In the context of software, the blocks may represent computer-executable instructions stored on one or more computer-readable media that, when executed by one or more processors, program the processors to perform the recited operations. Generally, computer-executable instructions include routines, programs, objects, components, data structures and the like that perform particular functions or implement particular data types. For discussion purposes, the process is described with reference to the environments, frameworks, and systems described in the examples herein, although the process may be implemented in a wide variety of other environments, frameworks, and systems. In the example of <FIG>, the process <NUM> may be executed at least in part by the one or more service computing device(s) <NUM> executing the ELT executing application <NUM>, or the like.

At <NUM>, the computing device may receive, from a client device, at least one instruction to cause execution of an ETL process by a single instance of an ETL execution application.

At <NUM>, the computing device may initiate execution of the single instance of the ETL execution application.

At <NUM>, the computing device may invoke execution of a main class loader to execute the ETL process.

At <NUM>, the computing device may send, e.g., by execution of the main class loader, to a service layer program, a request for data from a data cluster of a plurality of non-homogeneous data clusters configured with different versions of data cluster software including different library versions.

At <NUM>, the computing device may invoke, e.g., by execution of the service layer program, based on determining a first data cluster that is a target of the request, execution of a first version library module that invokes the execution of a first version class loader corresponding to a first library version used by the first data cluster.

At <NUM>, the computing device may send, e.g., by execution of the first version class loader, based at least in part on information in the first library version, the request to a first data cluster computing device associated with the first data cluster.

At <NUM>, the computing device may receive first data from the first data cluster computing device.

At <NUM>, the computing device may send, e.g., by execution of the main class loader, to the service layer program, a request to send data to a second data cluster of the plurality of non-homogeneous data clusters.

At <NUM>, the computing device may invoke, e.g., by execution of the service layer program, based on determining the second data cluster is the target of the request, execution of a second version library module that invokes the execution of a second version class loader corresponding to a second library version used by the second data cluster.

At <NUM>, the computing device may send, e.g., by execution of the second version class loader, based at least in part on information in the second library version, second data that is based at least in part on the first data to a second data cluster computing device associated with the second data cluster to store the second data with the second data cluster. For example, the first data may have been transformed at least in part to make up at least a portion of the second data.

The example processes described herein are only examples of processes provided for discussion purposes. Numerous other variations will be apparent to those of skill in the art in light of the disclosure herein. Further, while the disclosure herein sets forth several examples of suitable frameworks, architectures and environments for executing the processes, the implementations herein are not limited to the particular examples shown and discussed. Furthermore, this disclosure provides various example implementations, as described and as illustrated in the drawings.

<FIG> illustrates select example components of the service computing device(s) <NUM> that may be used to implement at least some of the functionality of the systems described herein. The service computing device(s) <NUM> may include one or more servers or other types of computing devices that may be embodied in any number of ways. For instance, in the case of a server, the programs, other functional components, and data may be implemented on a single server, multiple servers, a cluster of servers, a server farm or data center, a cloud-hosted computing service, and so forth, although other computer architectures may additionally or alternatively be used. Multiple service computing device(s) <NUM> may be located together or separately, and organized, for example, as virtual servers, server banks, and/or server farms. The described functionality may be provided by the servers of a single entity or enterprise, or may be provided by the servers and/or services of multiple different entities or enterprises.

In the illustrated example, the service computing device(s) <NUM> includes, or may have associated therewith, one or more processors <NUM>, one or more computer-readable media <NUM>, and one or more communication interfaces <NUM>. Each processor <NUM> may be a single processing unit or a number of processing units, and may include single or multiple computing units, or multiple processing cores. The processor(s) <NUM> can be implemented as one or more central processing units, microprocessors, microcomputers, microcontrollers, digital signal processors, state machines, logic circuitries, and/or any devices that manipulate signals based on operational instructions. As one example, the processor(s) <NUM> may include one or more hardware processors and/or logic circuits of any suitable type specifically programmed or configured to execute the algorithms and processes described herein. The processor(s) <NUM> may be configured to fetch and execute computer-readable instructions stored in the computer-readable media <NUM>, which may program the processor(s) <NUM> to perform the functions described herein.

The computer-readable media <NUM> may include volatile and nonvolatile memory and/or removable and non-removable media implemented in any type of technology for storage of information, such as computer-readable instructions, data structures, program modules, or other data. For example, the computer-readable media <NUM> may include, but is not limited to, RAM, ROM, EEPROM, flash memory or other memory technology, optical storage, solid state storage, magnetic tape, magnetic disk storage, RAID storage systems, storage arrays, network attached storage, storage area networks, cloud storage, or any other medium that can be used to store the desired information and that can be accessed by a computing device. Depending on the configuration of the service computing device(s) <NUM>, the computer-readable media <NUM> may be a tangible non-transitory medium to the extent that, when mentioned, non-transitory computer-readable media exclude media such as energy, carrier signals, electromagnetic waves, and/or signals per se. In some cases, the computer-readable media <NUM> may be at the same location as the service computing device <NUM>, while in other examples, the computer-readable media <NUM> may be partially remote from the service computing device <NUM>.

The computer-readable media <NUM> may be used to store any number of functional components that are executable by the processor(s) <NUM>. In many implementations, these functional components comprise instructions or programs that are executable by the processor(s) <NUM> and that, when executed, specifically program the processor(s) <NUM> to perform the actions attributed herein to the service computing device(s) <NUM>. Functional components stored in the computer-readable media <NUM> may include the management program <NUM>, the ETL execution application, the main class loader <NUM>, the service layer program <NUM>, the first, second and third version library modules <NUM>, <NUM>, and <NUM>, respectively, and the first, second and third version class loaders <NUM>, <NUM>, and <NUM>, respectively, each of which may include one or more computer programs, applications, executable code, or portions thereof. Further, while these programs are illustrated together in this example, during use, some or all of these programs may be executed on separate service computing device(s) <NUM>.

In addition, the computer-readable media <NUM> may store data, data structures, and other information used for performing the functions and services described herein. For example, the computer-readable media <NUM> may store the ETL process(es) <NUM>, the local API <NUM>, the first data cluster API <NUM>, the second data cluster API <NUM>, and the third data cluster API <NUM>. In addition, in some examples, the computer readable media <NUM> may store copies of each of the data cluster version libraries <NUM>, such as the first version library <NUM>, the second version library <NUM>, and the third version library <NUM>. Further, while these data and data structures are illustrated together in this example, during use, some or all of these data and/or data structures may be stored on separate service computing device(s) <NUM>. The service computing device <NUM> may also include or maintain other functional components and data, which may include programs, drivers, etc., and the data used or generated by the functional components. Further, the service computing device <NUM> may include many other logical, programmatic, and physical components, of which those described above are merely examples that are related to the discussion herein.

The one or more communication interfaces <NUM> may include one or more software and hardware components for enabling communication with various other devices, such as over the one or more network(s) <NUM>. For example, the communication interface(s) <NUM> may enable communication through one or more of a LAN, the Internet, cable networks, cellular networks, wireless networks (e.g., Wi-Fi) and wired networks (e.g., Fibre Channel, fiber optic, Ethernet), direct connections, as well as close-range communications such as BLUETOOTH®, and the like, as additionally enumerated elsewhere herein.

In some examples herein, the data cluster computing devices <NUM> may have similar hardware configurations to those discussed above for the service computing device(s) <NUM>, but with different functional components and data, such as indicated in <FIG>. Further, the data cluster computing devices <NUM> may include many other logical, programmatic, and physical components, of which those described above are merely examples that are related to the discussion herein.

Claim 1:
A system comprising:
a first computing device configured to communicate over a network (<NUM>) with a plurality of data cluster computing devices (<NUM>) associated with a plurality of data clusters (<NUM>), wherein a first data cluster (<NUM>(<NUM>)) of the plurality of data clusters (<NUM>) is configured with a first version of data cluster software including a first library version (<NUM>), and wherein a second data cluster (<NUM>(<NUM>)) of the plurality of data clusters (<NUM>) is configured with a second version of data cluster software including a second library version (<NUM>) that is different from the first library version (<NUM>), the first computing device executing a single instance of an ETL, Extract, Transform, Load, execution application conducted on the first computing device to perform operations characterized by:
(<NUM>) sending, based at least in part on information in the first library version (<NUM>), to a first data cluster computing device (<NUM>(<NUM>)) associated with the first data cluster (<NUM>(<NUM>)), a request for first data (<NUM>);
(<NUM>) receiving the first data (<NUM>) from the first data cluster computing device (<NUM>(<NUM>));
transforming the first data (<NUM>) based on one or more operations such as normalizing the data, correlating the data with other data or filter the data to form a second data (<NUM>);
and
(<NUM>) sending, based at least in part on information in the second library version (<NUM>), the second data (<NUM>) that is based at least in part on the first data (<NUM>) to a second data cluster computing device (<NUM>(<NUM>)) associated with the second data cluster (<NUM>(<NUM>)) to store the second data (<NUM>) with the second data cluster (<NUM>(<NUM>)).