HK40026042A - Storage correlation engine - Google Patents

Description

Storage association engine

RELATED APPLICATIONS

This application claims priority and any benefit from U.S. non-provisional patent application No.15/787,773 filed on 2017, 10, 19, which is hereby incorporated by reference in its entirety.

Technical Field

The present invention relates generally to methods and systems for ensuring that data flowing from multiple sources to multiple repositories, or directly to data consumers, represents the most recent and accurate instance of the data.

Background

Enterprises and other such organizations generate and receive large amounts of data. The data may represent data generated during the daily operation of the enterprise, data relating to the environment in which the enterprise operates, enterprise performance data, customer data, employee data, and data relating to the enterprise assets. The data may be relatively static in nature or may vary continuously. Continuously changing data may immediately create problems associated with determining whether a particular instance of data is accurate or up-to-date. Even relatively static data can present problems due to multiple copies of the data. In addition to the problems associated with the recency of a particular data set, the fact that an organization has multiple distributed data sources may also lead to situations where the relevant data is scattered across multiple storage locations. For example, a tangible asset may have a business record stored in one location and a financial record stored in another location. Thus, unless there is a way to correlate organizational data across multiple (and typically multiple) data platforms, it is likely that incomplete or non-recent data will be used in the decision process. For example, an application may extract data from a data source or storage location in order to generate various performance and status reports. These reports may be presented to management personnel to allow these personnel to make decisions on behalf of the enterprise. In the event that the extracted data conflicts with or is less recent than similar data from other sources, the reports generated, and thus the decisions made dependent on those reports, may not be as optimal as would be the case if the extracted data were correlated between data sources. Furthermore, data from scattered storage locations may be inadvertently missed in the information provided to the decision maker. For at least the reasons described above, the large amounts of data that enterprises often retain become difficult or impossible to manage using manual processes, and thus an automatic association process is needed. Accordingly, there is a need for an automated method and system for associating data held in various repositories throughout an organization.

Disclosure of Invention

The general inventive concept includes methods and systems for associating data stored throughout an organization in multiple data stores.

In an exemplary embodiment, a method of associating data between storage locations and data sources includes providing data to an association engine. The correlation engine extracts data from each of these storage locations and data sources and analyzes each piece of data to determine whether the received data is most recent relative to other copies of the data stored throughout the organization.

In some exemplary embodiments, the extraction of data is performed using a collection script.

In some exemplary embodiments, the correlation engine extracts data from a storage location and compares the extracted data to other copies of the data extracted from the same storage location.

In some exemplary embodiments of the invention, the correlation engine extracts data from the storage location and compares the extracted data to other copies of the data created earlier than the extracted data.

In an exemplary embodiment, a system for associating data between various storage locations and data sources. The system includes a plurality of data sources, a plurality of storage locations, and a correlation engine. The correlation engine receives data from each of these storage locations and data sources and analyzes each piece of data to determine whether the received data is most recent relative to other copies of the data stored throughout the organization. In this manner, it may be ensured that the data is properly associated, corresponds, or otherwise related to the data throughout the organization.

In an exemplary embodiment of the invention, data is extracted from a data source by a data collection script for retrieving the data. In addition to the data itself, additional information about switches, ports, areas, configurations, etc. may be determined or otherwise obtained. This additional information is not normally extracted from the data source from which the data was extracted. However, this additional information related to the infrastructure data can be used to determine relationships between various data sources to enable data association across the distributed computing architecture. Checking the validity of the retrieved data, comprising: checking to determine if there is a reported extraction error; checking the data size against previously extracted data sizes to determine if the data set includes a desired number of elements (e.g., matches); and parsing the extracted data to compare various parsed elements with similarly parsed elements from a previous extraction. In an exemplary embodiment, if the extracted data is found to be invalid, the previously stored data is retained, while the retrieved data is discarded as invalid data. Conversely, if the extracted data is found to be valid, then a data transformation operation is performed on the data to prepare it for association with other data sources and eventual use. For example, in some exemplary embodiments, the data is parsed and reformatted so that it becomes agnostic as to its original storage format. In other exemplary embodiments, the data may be subject to various translation functions. In other exemplary embodiments, the data may be parsed into a different arrangement, for example, into a column format. For example, after parsing and validation, data from multiple sources is correlated and inserted into a standardized data model such that data retrieved from different vendors is stored in a consistent and vendor-independent manner. The data may be extracted through an Application Program Interface (API). In addition to the API, the normalized data is inserted into the data lake for use across various groups of different platforms throughout the organization. Providing data to the data lake allows users outside of the secure storage to obtain performance data. Example performance data may include, but is not limited to, IOPS, response time or latency, throughput, or MBPS (read and write). In some exemplary embodiments, the extracted data found to be valid is reformatted to be compatible in format with each of the first storage location, the second storage location, and the third storage location.

After data extraction, data size checking, data validity checking, and data transformation are completed, the resulting data is provided to an associated database for processing and storage. The relational database also includes a table into which data from the previous day is moved. In some exemplary embodiments, data from the previous days is stored for a rolling time period (e.g., six months) to provide a source of historical information.

Once the data is stored in the association database, the data is available to various points of use. In some exemplary embodiments, these points of use may include data lakes, various programs (e.g., efficiency programs), data migration and refresh functions, and operational groups (e.g., billing and capacity management). In some exemplary embodiments, the shared data is made accessible by providing one or more Application Program Interfaces (APIs) to facilitate access to the data stored in the association database. In some example embodiments, shared data is made accessible by providing a microservice architecture interface.

In some exemplary embodiments, data from the correlation database is provided to a private store (e.g., a data lake) for use by the entire organization without requiring the consumer of the information to retrieve the data directly from the correlation engine. In other exemplary embodiments, the data may be provided directly to various applications for use. These methods of accessing the associated data ensure that data consumers can continue to access information in the manner they are accustomed to, while receiving the benefits of the data processed by the data association engine.

In other exemplary embodiments, the method steps and functions described herein may be performed using a system comprising a processor and a memory, the memory further comprising instructions that when executed by the processor result in the performance of the method steps and functions described above.

The foregoing and other aspects and advantages of the general inventive concept will become more apparent from the following description and accompanying drawings, which illustrate, by way of example, the principles of the general inventive concept.

Drawings

These and other features of the general inventive concept will be better understood by reference to the following description and drawings, wherein:

FIG. 1 is a diagram illustrating various data sources and repositories in communication with a storage association engine, which communicates with various data consumers, in accordance with an illustrative embodiment;

FIG. 2 is a diagram of a correlation engine in accordance with an illustrative embodiment;

3A-3C are diagrams illustrating data flow from various data sources to an association engine, according to an exemplary embodiment;

FIG. 4 is a diagram of infrastructure data in accordance with an example embodiment;

FIG. 5 is a flowchart of steps for verifying data in accordance with an exemplary embodiment; and

FIG. 6 is a diagram illustrating data flow from a storage association engine to various data usage points in accordance with an illustrative embodiment.

Detailed Description

An organization (enterprise, charity, hospital, school, etc.) typically has a large amount of data that must be maintained by the organization. The data may be data received from a source external to the organization or may be data generated by the operation of the organization itself. For example, the external information may be obtained from a government agency, a customer, or a commercial data provider. The internal data may be data generated due to normal business operations, or may be data derived from analyzing business operation data, external data, or a combination of both. Because both internal and external data may be continuously changing and distributed throughout the organization for storage and use, it is likely that some data instances will be inconsistent with other instances throughout the organization. Related data segments may also be distributed throughout the organization. Both of these situations may be more common in large decentralized enterprises (e.g., banks). Depending on the size of the differences between the various data instances and the nature of the data, these differences may result in severe confusion and poor business decisions.

The general inventive concept includes a data association engine that extracts data from various storage locations and data sources throughout an organization and associates the data between the various sources. The resulting correlated data may be stored in a stored correlation database that is part of the correlation engine. Alternatively, the stored association database may be located outside of the association engine. In some cases, the storage association database is not used at all.

FIG. 1 illustrates a system 100 for associating data according to an example embodiment. The system 100 includes a correlation engine 104, a data source 102, and a data consumer 112. The data 150 received by the correlation engine 104 may be in a format that is not usable by the data consumer in the format in which it is received. By way of example, such formats may include, but are not limited to, LUN #, area name, and World Wide Number (WWN). These formats require mapping to the host and then to the service line and application names. The correlation engine 104 serves as a source for merging the stored supplier tool data with data enriched by the data enrichment functions available to the organization. For example, the host receives storage data from three data storage frames (data storage frames). An example host has two Host Bus Adapters (HBAs) connected to two switches from odd data fabrics (fabric) and even data fabrics. Thus, the host is partitioned, mapped and masked to three storage frames. Furthermore, each frame has its own performance value. The received stored data 150 needs to be tied to the service line (LoB) application level. To understand the storage and host capabilities allocated to the host in this example, the data from all three frames must be merged.

In some exemplary embodiments, an abstraction layer formed by the association engine 104 is configured between storing data provided by the vendor tool and the use of such data by the organization. In an exemplary embodiment, each data source 102 may be from a different vendor platform. The abstraction layer is used to convert the data 150 collected from the various sources 102 into a standardized, vendor-independent format. This standardized, vendor-independent data format serves to simplify subsequent operations performed on the data. The result is that the data consumer 112 does not have to worry about the source of the data or the data format.

In many organizations, engineering resources utilize data usage information to identify infrastructure requirements. The data usage information is generated from a hardware or software data instrumentation system, typically controlled by engineering resources. In certain exemplary embodiments, these instrumentation systems are positioned such that they receive data from the correlation engine 104. In addition to these data instrumentation systems, the data storage provider may also provide reporting tools that enable users to obtain usage and other data related to the stored data. However, in organizations that utilize multiple storage providers, a user wishing to obtain reporting information may have to consult multiple different tools and data sources and then attempt to merge the results. In some exemplary embodiments, the system 100 includes an automated data feed 114 that provides data 120 from the correlation engine database 116 to the data consumer 112. Because these automated data feeds 114 provide the associated data 120 directly to the data consumers 112, they provide an evergreen data source that avoids problems caused by outdated or replaced data.

In some exemplary embodiments, the data 118 extracted from these multiple storage providers 102 becomes available through an Application Program Interface (API) or microservice function. These data interfaces and the consolidation of data sources 102 make it possible to efficiently manage the distribution of information stored in large quantities throughout an organization.

In addition to the API and microservice functions, in some exemplary embodiments, the associated data 120 is sent directly to the data lake 110 maintained by the organization. This direct provision of data serves to keep the available data in data lake 110 as recent and accurate as possible while reducing the amount of intervention of administrative resources required to manage the process. In some exemplary embodiments, one or more user interfaces are provided that allow a user to directly input data, thereby eliminating the need for certain data repositories. Such a user interface may allow a user to enter enrichment data.

Because data 118 is routed through the correlation engine 104, information related to data clustering, distribution, virtual machines, and other constructs may be used by the correlation engine. Thus, in some exemplary embodiments, in addition to associating various data and distributing the associated data, the system 100 may be configured to compute data storage consumption and fully automate the billing process of the storage service.

As described above, the correlation engine 104 is in communication with a plurality of data sources 102. These data sources 102 may be specific data stores 106. The data source 102 may be operational data 108. Data source 102 can be a data lake 110. Such data sources 102 are both static and dynamic in nature. For example, static data store 106 includes data items that, if changed, are infrequently changed, such as asset records and various historical records. The dynamic data source 106 includes data items that eventually change, if not frequently. Examples include, but are not limited to, business performance data, client or customer data, accounts receivable, accounts payable, and other types of data that are not static in nature. There may be data redundancy between these various sources. In addition to this redundancy, the actual data values stored at various locations may differ from one location to another. Because of these differences, the individual or organization that utilizes the data (i.e., the data consumer 112) may not know which data source reflects the most up-to-date information. To address potential problems caused by inconsistent or outdated data, the data 118 extracted from a particular data store 106 is provided to the storage association engine 104. The storage association engine 104 processes the received data 118 to associate it between the various specific data stores 106.1-106.6. As indicated at 112, the storage association engine 104 makes the associated data 120 available to various data consumers (which may be internal or external to the organization).

FIG. 2 illustrates a correlation engine 200 according to an exemplary embodiment. The correlation engine 200 includes a processor 202 in electronic communication with a memory 204. The memory includes software instructions that configure the processor to perform the steps described herein. Additionally, the memory may include all of the data, none of the data, or a portion of the data. Other exemplary embodiments may include multiple processors and memory locations. In some exemplary embodiments, the system 200 also includes an interface 206 that communicates with various specific data stores 106 and various consumers 112.

Fig. 3A-3C illustrate data flows 120 from various data sources 106.1-106.6 to the correlation engine 104 according to an example embodiment. The data source 102 includes a plurality of specific data stores 106.1-106.6, each having a corresponding manner 302 for extracting data from the data stores 106.1-106.6. In some exemplary embodiments, these approaches include data collection scripts and parsed reporting methods. In some exemplary embodiments, when data 118 is extracted from multiple data sources 102, additional information 304 is obtained about the extracted data 118. As shown in FIG. 4, with data construct storage, such additional information 304 may include a list of switches (switches) 402 for each construct 404. In addition, configuration data 406 is collected for each switch 402. Such configuration data 406 includes, for example: construct login (flogi) data 408; construct channel name server (FCNS) data 410; interface data 412; and region set data 414. Other examples of additional information may include performance indicators for certain storage locations 305.

Once the initial data extraction 500 (including obtaining additional information as needed) is complete, a validity check 306 is performed. In this exemplary embodiment, the validity check includes three separate checks. Fig. 5 shows the steps of performing a validity check according to an exemplary embodiment. The first validity check 502 assumes that the data obtained from the element manager is accurate, and that the reference system is also accurate. As a result of these assumptions, failures reported during data collection will result in indications of collection errors. The reported collection error thus results in the entire data set for that data collection (run) instance being discarded 504. For example, if a switch in a data fabric reports an error during data collection, the entire run of the fabric will be considered invalid. If such an error is detected, the data correlation engine may treat the most recent successful data run as the most accurate data. The detected error will be recorded and an alarm generated.

The second validity check 506 involves data parsing. In data parsing, different types of data sets collected from a data construct are parsed and then correlated to detect errors. For example, as shown in Table 1, flogi data is collected from the first interface. The data includes a port name. In a second validity check 506, the data is parsed and compared to the FCNS data as shown in table 2. As shown, the port name in the flogi data from interface fc3/1 matches the port name found in the FCNS data. Data matching the port name is found in the FCNS data, confirming that the host bus adapter is online and active. Other parsing checks may be performed to validate the data by comparing the parsed data from the first source to ensure that it matches the parsed data available from the second source. If the comparison results in a mismatch, then at least one of the retrieved data values is inconsistent, thus causing the second quality check 506 to fail. If such an error is detected, the entire build data is discarded 504 and an alert is generated.

TABLE 1

TABLE 2

As shown in fig. 3A-3C, after the data manipulation process 310 is performed, a third validity check 312 is performed. In this third validity check 312, the number of records (data size) of the currently retrieved data is compared to a predetermined expected data size. The expected data size is determined by examining the historical data size values and allows for minor differences. If the data size is found to be valid, the data is assimilated 314 into the storage correlation engine database and then the previous day's data is moved to a "previous day" table where it will be kept for a period of time (e.g., up to six months) in some exemplary embodiments to provide a history. If the result of the validity check is that invalid data is determined, the previous data is retained 308 and the invalid data is discarded 504. In this case, an alarm is generated to prompt investigation of the cause of the invalid data. In this way, incomplete or erroneous fetches will not result in corruption of the stored data. This prevents corrupt or invalid data from entering the database maintained by the storage association engine 104. Once the data is found to be valid, a data manipulation process 310 is performed to convert the particular data into a vendor-independent format. These data manipulation processes 310 may vary depending on the type of data received from a particular data store 106.1-106.6.

FIG. 6 illustrates a data flow 120 from the storage association engine 104 to various consumption or storage points in accordance with an exemplary embodiment. For example, there may be multiple data consumers 602, including but not limited to data lake 604, various organizational programs 606, data migration and refresh team 608, and billing group 610. In the example shown, data is retrieved from the association database 612 and provided to the store association engine API 614. This API 614 may then be accessed by multiple consumers (e.g., devices and systems) to allow the consumer 602 to directly extract the associated data. Thus, the correlation engine can be configured such that its operation is transparent to the data consumer.

While the present invention and related inventive concepts have been illustrated by a description of various embodiments thereof, and while these embodiments have been described in considerable detail, it is not the intention of the applicants to restrict or in any way limit the scope of the appended claims to such detail. Other advantages and modifications will be apparent to persons skilled in the art. Moreover, in some cases, elements described in one embodiment may be readily adapted for use with other embodiments. The invention in its broader aspects is therefore not limited to the specific details, representative apparatus, and illustrative examples shown and described. Accordingly, departures may be made from such details without departing from the spirit or scope of the general inventive concept.

Claims (20)

1. A method for associating data stored at a plurality of storage locations, the method comprising:

extracting first data representing an information item from a first storage location;

extracting second data representing the information item from a second storage location; and

evaluating validity of the second data using the first data and the second data, including confirming whether a data size of the second data is the same as a data size of the first data,

wherein, upon determining that the second data is invalid:

retaining the first data; and

discarding the second data; and

wherein, upon determining that the second data is valid:

converting the second data into third data having a standardized data format; and

storing said third data as new data, an

Wherein confirming that the data size of the second data is the same as the data size of the first data comprises:

receiving a count of reference objects in the second data;

calculating a desired number of reference objects by determining a number of reference objects in the first data; and

comparing the received count to the calculated number and determining a difference between the received count and the calculated number.

2. The method of claim 1, wherein evaluating the validity of the second data using the first data and the second data comprises:

confirming that there are no reported errors in the process of extracting the second data from the second storage location.

3. The method of claim 1, wherein using the first data and the second data to evaluate the validity of the second data further comprises:

parsing the first data to obtain first parsed data corresponding to one or more parsed categories;

parsing the second data to obtain second parsed data corresponding to the one or more parsed categories; and

comparing the first parsed data and the second parsed data.

4. The method of claim 1, further comprising:

providing an interface allowing direct access to said third data.

5. The method of claim 1, further comprising, if the second data is determined to be valid: recording the second data as historical data.

6. The method of claim 1, further comprising: receiving information related to the first storage location, wherein the information comprises:

port identification data;

partitioning data; and

storage location configuration data, and

wherein information relating to the first storage location is stored outside of the first storage location.

7. The method of claim 1, further comprising: receiving information related to the first storage location, wherein the information comprises:

constructing login data;

constructing channel name server data;

interface data; and

the data is collected.

8. The method of claim 1, further comprising: storing the third data in a third storage location.

9. The method of claim 8, wherein storing the third data in the third storage location further comprises:

moving a previously stored data value representing the information item from the third storage location to a storage table of a previous day; and

storing the third data to a data storage location of the third storage locations.

10. A system for associating data from a plurality of data sources, the system comprising:

a processor;

a hardware data interface;

a correlation engine database;

a memory;

wherein the processor is in electronic communication with the hardware data interface, the correlation engine database, and the memory;

the memory includes software instructions that, when executed by the processor, cause the processor to:

extracting first data representing an item of information from a first storage location using the hardware data interface;

extracting second data representing the item of information from a second storage location using the hardware data interface;

receiving information related to the second data using the hardware data interface, the information comprising:

the number of file records;

data source port data;

a value representing a count of reference objects in the second data;

evaluating validity of the second data using the first data, including confirming whether a data size of the second data is the same as a data size of the first data;

wherein, upon determining that the second data is invalid:

retaining the first data; and

discarding the second data; and

wherein, upon determining that the second data is valid:

converting the second data into third data having a standardized data format; and

storing the third data as new data using the hardware data interface, an

Wherein confirming that the data size of the second data is the same as the data size of the first data comprises:

receiving a count of reference objects in the second data;

calculating a desired number of reference objects by determining a number of reference objects in the first data; and

comparing the received count to the calculated number and determining a difference between the received count and the calculated number.

11. The system of claim 10, wherein evaluating the validity of the second data using the first data and the second data comprises:

confirming that there are no reported errors in the process of extracting the second data from the second storage location.

12. The system of claim 10, wherein evaluating the validity of the second data using the first data and the second data further comprises:

parsing the first data to obtain first parsed data corresponding to one or more parsed categories;

parsing the second data to obtain second parsed data corresponding to the one or more parsed categories; and

comparing the first parsed data and the second parsed data.

13. The system of claim 10, wherein the third data is stored in a third storage location.

14. The system of claim 13, wherein the third data is stored in the third storage location by:

moving a previously stored data value representing the information item from the third storage location to a storage table of a previous day; and

storing the third data to a data storage location of the third storage locations.

15. The system of claim 10, further comprising software instructions that, when executed by the processor, cause the processor to:

providing an interface allowing direct access to said third data.

16. The system of claim 10, wherein,

the software instructions include instructions that, when executed by the processor, cause the processor to receive information related to the first storage location, the information including:

port identification data;

partitioning data; and

storage location configuration data, and

wherein information relating to the first storage location is stored outside of the first storage location.

17. The system of claim 10, wherein the software instructions comprise instructions that, when executed by the processor, cause the processor to receive information related to the first storage location, the information comprising:

constructing login data;

constructing channel name server data;

interface data; and

the data is collected.

18. A non-transitory computer readable medium configured to store instructions for associating data stored in a plurality of storage locations, wherein the instructions, when executed, cause a processor to:

extracting first data representing an information item from a first storage location;

extracting second data representing the information item from a second storage location; and

evaluating validity of the second data using the first data and the second data, including confirming whether a data size of the second data is the same as a data size of the first data,

wherein, when it is determined that the second data is invalid, the instructions, when executed, cause the processor to further perform:

retaining the first data; and

discarding the second data; and

wherein when the second data is determined to be valid, the instructions, when executed, cause the processor to further perform:

converting the second data into third data having a standardized data format; and

storing the third data as new data in a third storage location; and

providing an interface allowing direct access to said third data, an

Wherein confirming that the data size of the second data is the same as the data size of the first data comprises:

receiving a count of reference objects in the second data;

calculating a desired number of reference objects by determining a number of reference objects in the first data; and

comparing the received count to the calculated number and determining a difference between the received count and the calculated number.

19. The non-transitory computer-readable medium of claim 18, wherein storing the third data in the third storage location further comprises:

moving a previously stored data value representing the information item from the third storage location to a storage table of a previous day; and

storing the third data to a data storage location of the third storage locations.

20. The non-transitory computer-readable medium of claim 18, wherein evaluating the validity of the second data using the first data and the second data further comprises:

parsing the first data to obtain first parsed data corresponding to one or more parsed categories;

parsing the second data to obtain second parsed data corresponding to the one or more parsed categories; and

comparing the first parsed data and the second parsed data.