Patent Application
20190258648
The present disclosure relates to data governance. More specifically, the present disclosure relates to generating asset level classifications using machine learning.
Data governance relates to the overall management of the availability, usability, integrity, and security of data used in an enterprise. Data governance includes rules or policies used to restrict access to data classified as belonging to a particular asset level classification. For example, a database column storing social security numbers may be tagged with an asset level classification of “confidential,” while a rule may restrict access to data tagged with the confidential asset level classification to a specified user or group of users. Asset level classifications may be specified manually by a user, or programmatically generated by a system based on a classification rule (or policy). However, as new assets are added, existing rules may need to change in light of the new assets. Similarly, new rules may need to be defined in light of the new assets. With asset types numbering in the millions or more, it is not possible for users to decide what new rules should be defined, or what existing rules need to be modified. Similarly, the users cannot determine whether existing asset classifications should be modified for a given asset, or whether to tag assets with new classifications.
According to one embodiment of the present disclosure, a method comprises receiving a plurality of assets from a data catalog and a respective plurality of classifications applied to each asset in the data catalog, extracting, for a plurality of features, feature data from the plurality of assets and the plurality of asset classifications, generating a feature vector based on the extracted feature data, and generating, by a machine learning (ML) algorithm and based on the feature vector, a first classification rule specifying a condition for applying a first classification of the plurality of classifications to a first asset of the plurality of assets.
Embodiments disclosed herein leverage machine learning (ML) to generate new asset level classification rules and/or generate changes to existing asset level classification rules. Generally, embodiments disclosed herein provide different attributes, or features, to a ML algorithm which generates a feature vector. The ML algorithm then uses the feature vector to generate one or more asset level classification rules. Doing so allows existing and new assets to be programmatically tagged with the most current and appropriate asset level classifications.
The rules engine 106 is configured to generate new classification rules 111 for storage in the classification rules 105 using machine learning. The new rules 111 are also representative of modifications to existing rules in the classification rules 105. As shown, the rules engine 106 includes a data store of features 107, one or more machine learning algorithms 108, one or more feature vectors 109, and one or more machine learning models 110. The features 107 are representative of features (or attributes) of the assets 1021-N and/or the classifications 1031-N. Stated differently, a feature is an individual measurable property or characteristic of the data catalog 101, including the assets 1021-N and/or the classifications 1031-N. Example features 107 include, without limitation, a classification 103N assigned to an asset 102N, data types (e.g., integers, binary data, files, etc.) of assets 1021-N, tags that have been applied to the assets 1021-N(e.g., salary, accounting, etc.), and sources of the assets 1021-N. In at least one embodiment, a user defines the features 107 for use by the ML algorithms 108. Generally, a machine learning algorithm is a form of artificial intelligence which allows software to become more accurate in predicting outcomes without being explicitly programmed to do so. Examples of ML algorithms 108 include, without limitation, decision tree classifiers, support vector machines, artificial neural networks, and the like. The use of any particular ML algorithm 108 as a reference example herein should not be considered limiting of the disclosure, as the disclosure is equally applicable to any type of machine learning algorithm configured to programmatically generate classification rules 105.
Generally, a given ML algorithm 108 receives the features 107, the assets 1021-N, and the classifications 1031-N as input, and generates a feature vector 109 that identifies patterns or other trends in the received data. For example, if the features 107 specified 100 features, the feature vector 109 would include data describing each of the 100 features relative to the assets 1021-N and/or the classifications 1031-N. For example, the feature vector 109 may indicate that out of 1,000 example assets 1021-N tagged with a “personally identifiable information” classification 103N, 700 of the 1,000 assets 1021-N had data types of “person name” and “zip code”. In some embodiments, the feature vectors 109 may be generated by techniques other than via the ML algorithms 108. In such embodiments, the feature vectors 109 may be defined based on an analysis of the data in the assets 1021-N and/or the classifications 1031-N. The ML algorithms 108 may then use the feature vector 109 to generate one or more ML models 110 that specify new rules 111. For example, a new rule 111 generated by the ML algorithms 108 and/or the ML models 110 may specify: “if an asset contains a column of type ‘employee ID’ and a column of type ‘salary’ and the columns ‘employeeID’ and ‘salary’ are of type ‘integer’, tag the asset with a classification of ‘confidential’”. The preceding rule is an example of a format the new rules 111 may take. However, the new rules may be formatted according to any predefined format, and the ML algorithms 108 and/or ML models 110 may be configured to generate the new rules 111 according to any format.
The rules engine 106 may then store the newly generated rules 111 in the classification rules 105. However, in some embodiments, the rules engine 106 processes the new rules 111 differently based on whether a user has provided an asset level classification 103N for a given asset 1021-N in the data catalog, and whether the classification component 104 programmatically generated a classification 103N for a given asset 1021-N based on the a rule in the classification rules 105 that was programmatically generated by the rules engine 106. If the user has previously provided asset level classifications 103N, the rules engine 106 searches for a matching (or substantially similar) rule in the classification rules 105 (e.g., based on matching of terms in each rule, a score computed for the rule, etc.). If a match exists, the rules engine 106 compares the identified rule(s) to the new rule 111. If the rules are the same, the rules engine 106 discards the rule. If the identified rules are similar, the rules engine 106 may output the new rule 111 to a user (e.g., a data steward) as a suggestion to modify the existing rule in the classification rules 105. If there is no matching rule, the rules engine 106 may optionally present the new rule 111 to the user for approval prior to storing the new rule 111 in the classification rules 105.
If the classification component 104 has previously generated a classification 1031-N based on a classification rule 105 generated by the rules engine 106, the rules engine 106 compares the new rule 111 to the classification rule 105 previously generated by the rules engine 106. If the new rule 111 is the same as the classification rule 105 previously generated by the rules engine 106, the rules engine 106 ignores and discards the new rule 111. If the comparison indicates a difference between the new rule 111 and the existing classification rule 105 previously generated by the rules engine 106, the rules engine 106 may output the new rule 111 as a suggested modification to the existing classification rule 105. The user may then approve the new rule 111, which replaces the existing classification rule 105. The user may also decline to approve the new rule 111, leaving the existing classification rule 105 unmodified. In some embodiments, the rules engine 106 applies heuristics to the new rule 111 before suggesting the new rule 111 as a modification to the existing classification rule 105. For example, if the difference between the new rule 111 and the existing classification rule 105 relates only to the use of data types (or other basic information such as confidence levels or scores), the rules engine 106 may determine that the difference is insignificant, and refrain from suggesting the new rule 111 to the user. More generally, the rules engine 106 may determine whether differences between rules are significant or insignificant based on the type of rule, the data types associated with the rule, and the like.
At block 230, the rules engine 106 leverages the selected ML algorithm 108 to extract feature data from the existing assets 1021-N and/or the classifications 1031-N in the catalog 101 to generate the feature vector 109 and generate one or more ML models 110 specifying one or more new classification rules, which may then be stored in the classification rules 105. Generally, at block 230, the ML algorithm 108 is provided the data describing assets 1021-N and the classifications 1031-N from the catalog 101, which extracts feature values corresponding to the features defined at 210. As previously indicated, however, in some embodiments, the feature vector 109 is generated without using the ML algorithm 108, e.g. via analysis and extraction of data describing the assets 1021-N and/or the classifications 1031-N in the catalog 101. For example, if the features 107 include a feature of “asset type”, the feature vector 109 would reflect each different type of asset in the assets 1021-N, as well as a value reflecting how many assets 1021-N are of each corresponding asset type. Based on the generated feature vector 109, the selected ML algorithm 108 may then generate a ML model 110 specifying one or more new classification rules.
At block 240, the rules engine 106 processes the new classification rules generated at block 230 if an asset 1021-N in the catalog 101 has been tagged with a classification 1031-N by a user. Generally, the rules engine 106 identifies existing rules in the classification rules 105 that are similar to (or match) the new rules generated at block 230, discarding those that are duplicates, suggesting modifications to existing rules to a user, and storing new rules in the classification rules 105. At block 250, the rules engine 106 processes the new classification rules generated at block 230 if an asset 1021-N has been tagged by the classification component 104 with a classification 1031-N based on a classification rule 105 generated by the rules engine 106 (or some other programmatically generated classification rule 105). Generally, at block 250, the rules engine 106 searches for existing rules in the classification rules 105 that match the rules generated at block 230. If an exact match exists, the rules engine 106 discards the new rule. If a similar rule exists in the classification rules 105, the rules engine 106 outputs the new and existing rule to the user, suggesting that the user accept the new rule as a modification to the existing rule. If the rule is a new rule, the rules engine 106 adds the new rule to the classification rules 105. In some embodiments, a given asset 102N may meet the criteria defined at blocks 240 and 250. Therefore, in such cases, the methods 400 and 500 are executed for the newly generated rules.
At block 260, the classification component 104 tags new assets 1021-N added to the catalog 101 with one or more classifications 1031-N based on the rules generated at block 230 and/or updates existing classifications 1031-N based on the rules generated at block 230. Doing so improves the accuracy of classifications 1031-N programmatically applied to assets 1021-N based on the classification rules 105. Furthermore, the steps of the method 200 may be periodically repeated to further improve accuracy of the ML models 110 and rules generated the ML algorithms 108, such that the ML algorithms 108 are trained on the previously generated ML models 110 and rules.
At block 320, the data format the assets 1021-N is optionally defined as a feature. Doing so allows the rules engine 106 and/or ML algorithms 108 to identify relationships between data formats and classifications 103N for the purpose of generating classification rules. For example, if an asset 102N includes many columns of data that are of a “binary” data format, these binary data columns may be of little use. Therefore, such an asset 102N may be tagged with a classification 103N of “non-productive data”, indicating a low level of importance of the data. As such, the rules engine 106 and/or ML algorithms 108 may generate a rule specifying to tag assets 1021-N having columns of binary data with the classification of “non-productive data”.
At block 330, the classifications 1031-N of a given asset is optionally defined as a feature 107. Often, existing classifications are related to other classifications. For example, if an asset 102N is tagged with a “finance” classification 103N, it may be likely to have other classifications 1031-N that are related to the finance domain, such as “tax data” or “annual report”. By defining related classifications as a feature 107, such relationships may be extracted by the rules engine 106 and/or ML algorithms 108 from the catalog 101, facilitating the generation of classification rules 105 based on the same. At block 340, the project (or data catalog 101) in which an asset 102N belongs to is optionally defined as a feature 107. Generally, data assets 1021-N that are in the same project (or data catalog 101) are often related to each other. Therefore, if a project (or the data catalog 101) contains many assets 1021-N that are classified with a classification 103N of “confidential”, it is likely that a new asset 102N added to the catalog 101 should likewise be tagged with a classification 103N of “confidential”. During machine learning, the ML algorithms 108 and/or rules engine 106 may determine the degree to which these relationships matter, and generate classification rules 105 accordingly.
At block 350, the data quality score of an asset 1021-N (or a component thereof) is optionally defined as a feature 107. Generally, the data quality score is a computed value which reflects the degree to which data values for a given column of an asset 1021-N satisfy one or more criteria. For example, a first criterion may specify that a phone number must be formatted according to the format “xxx-yyy-zzzz”, and the data quality score reflects a percentage of values stored in the column having the required format. The rules engine 106 may classify assets 1021-N having low quality scores with a classification 103N of “review” to trigger review by a user. At block 360, the tags applied to an asset are optionally defined as a feature 107. Generally, a tag is a metadata attribute which describes an asset 1021-N. For example, a tag may identify an asset 102N as a “salary database”, “patent disclosure database”, and the like. By analyzing the tags of an asset 102N, the rules engine 106 and/or the ML algorithms 108 may generate classification rules 105 reflecting the relationships between the tags and the classifications 1031-N of the asset 102N. For example, such a classification rule 105 may specify to apply a classification 103N to the “salary database” and the “patent disclosure database”.
At block 370, the name and/or textual description of an asset 102N is optionally defined as a feature 107. The name may also include bigrams and trigrams formed using the name of the asset 102N. The description may also include bigrams and trigrams that are formed using the description of the asset 102N. Often, the name and/or textual description of an asset 1021-N has a role in the classifications 1031-N applied to the asset 1021-N. For example, the description of an asset 1021-N includes the words “social security number”, it is likely that a classification 103N of “confidential” should be applied to the asset 1021-N. As such, the rules engine 106 and/or ML algorithms 108 may identify such names and/or descriptions, and generate classification rules 105 accordingly. At block 380, the source of an asset 1021-N is optionally defined as a feature 107. For example, an asset 1021-N may have features similar to the features in a group of assets 1021-N to which it belongs. As such, the rules engine 106 and/or the ML algorithms 108 may generate classification rules 105 reflecting the classifications 1031-N of other assets in a group of assets 1021-N.
At block 560, upon determining a matching or substantially similar rule does not exist in the classification rules 105, the rules engine 106 stores the current rule in the classification rules 105. The rules engine 106 may optionally present the current rule to the user for approval before storing the rule. At block 570, the rules engine 106 stores the current rule responsive to receiving user input approving the current rule. At block 580, the rules engine 106 determines whether more rules remain. If more rules remain, the rules engine 106 returns to block 520. Otherwise, the method 500 ends.
The server 101 generally includes a processor 704 which obtains instructions and data via a bus 720 from a memory 706 and/or a storage 708. The server 101 may also include one or more network interface devices 718, input devices 722, and output devices 724 connected to the bus 720. The server 101 is generally under the control of an operating system (not shown). Examples of operating systems include the UNIX operating system, versions of the Microsoft Windows operating system, and distributions of the Linux operating system. (UNIX is a registered trademark of The Open Group in the United States and other countries. Microsoft and Windows are trademarks of Microsoft Corporation in the United States, other countries, or both. Linux is a registered trademark of Linus Torvalds in the United States, other countries, or both.) More generally, any operating system supporting the functions disclosed herein may be used. The processor 704 is a programmable logic device that performs instruction, logic, and mathematical processing, and may be representative of one or more CPUs. The network interface device 718 may be any type of network communications device allowing the server 101 to communicate with other computers via the network 730.
The storage 708 is representative of hard-disk drives, solid state drives, flash memory devices, optical media and the like. Generally, the storage 708 stores application programs and data for use by the server 101. In addition, the memory 706 and the storage 708 may be considered to include memory physically located elsewhere; for example, on another computer coupled to the server 101 via the bus 720.
The input device 722 may be any device for providing input to the server 101. For example, a keyboard and/or a mouse may be used. The input device 722 represents a wide variety of input devices, including keyboards, mice, controllers, and so on. Furthermore, the input device 722 may include a set of buttons, switches or other physical device mechanisms for controlling the server 101. The output device 724 may include output devices such as monitors, touch screen displays, and so on.
As shown, the memory 706 contains the classification component 104, rules engine 106, and ML algorithms 108, each described in greater detail above. As shown, the storage 708 contains the data catalog 101, the classification rules 105, and the ML models 110, each described in greater detail above. Generally, the system 700 is configured to implement all functionality, methods, and techniques described herein with reference to
Advantageously, embodiments disclosed herein leverage machine learning to generate classification rules for applying classifications to assets in a data catalog. By programmatically generating accurate classification rules, the classifications may be programmatically applied to the assets with greater accuracy.
The descriptions of the various embodiments of the present disclosure have been presented for purposes of illustration, but are not intended to be exhaustive or limited to the embodiments disclosed. Many modifications and variations will be apparent to those of ordinary skill in the art without departing from the scope and spirit of the described embodiments. The terminology used herein was chosen to best explain the principles of the embodiments, the practical application or technical improvement over technologies found in the marketplace, or to enable others of ordinary skill in the art to understand the embodiments disclosed herein.
In the foregoing, reference is made to embodiments presented in this disclosure. However, the scope of the present disclosure is not limited to specific described embodiments. Instead, any combination of the recited features and elements, whether related to different embodiments or not, is contemplated to implement and practice contemplated embodiments. Furthermore, although embodiments disclosed herein may achieve advantages over other possible solutions or over the prior art, whether or not a particular advantage is achieved by a given embodiment is not limiting of the scope of the present disclosure. Thus, the recited aspects, features, embodiments and advantages are merely illustrative and are not considered elements or limitations of the appended claims except where explicitly recited in a claim(s). Likewise, reference to “the invention” shall not be construed as a generalization of any inventive subject matter disclosed herein and shall not be considered to be an element or limitation of the appended claims except where explicitly recited in a claim(s).
Aspects of the present disclosure may take the form of an entirely hardware embodiment, an entirely software embodiment (including firmware, resident software, microcode, etc.) or an embodiment combining software and hardware aspects that may all generally be referred to herein as a “circuit,” “module” or “system.”
The present disclosure may be a system, a method, and/or a computer program product. The computer program product may include a computer readable storage medium (or media) having computer readable program instructions thereon for causing a processor to carry out aspects of the present disclosure.
The computer readable storage medium can be a tangible device that can retain and store instructions for use by an instruction execution device. The computer readable storage medium may be, for example, but is not limited to, an electronic storage device, a magnetic storage device, an optical storage device, an electromagnetic storage device, a semiconductor storage device, or any suitable combination of the foregoing. A non-exhaustive list of more specific examples of the computer readable storage medium includes the following: a portable computer diskette, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or Flash memory), a static random access memory (SRAM), a portable compact disc read-only memory (CD-ROM), a digital versatile disk (DVD), a memory stick, a floppy disk, a mechanically encoded device such as punch-cards or raised structures in a groove having instructions recorded thereon, and any suitable combination of the foregoing. A computer readable storage medium, as used herein, is not to be construed as being transitory signals per se, such as radio waves or other freely propagating electromagnetic waves, electromagnetic waves propagating through a waveguide or other transmission media (e.g., light pulses passing through a fiber-optic cable), or electrical signals transmitted through a wire.
Computer readable program instructions described herein can be downloaded to respective computing/processing devices from a computer readable storage medium or to an external computer or external storage device via a network, for example, the Internet, a local area network, a wide area network and/or a wireless network. The network may comprise copper transmission cables, optical transmission fibers, wireless transmission, routers, firewalls, switches, gateway computers and/or edge servers. A network adapter card or network interface in each computing/processing device receives computer readable program instructions from the network and forwards the computer readable program instructions for storage in a computer readable storage medium within the respective computing/processing device.
Computer readable program instructions for carrying out operations of the present disclosure may be assembler instructions, instruction-set-architecture (ISA) instructions, machine instructions, machine dependent instructions, microcode, firmware instructions, state-setting data, or either source code or object code written in any combination of one or more programming languages, including an object oriented programming language such as Smalltalk, C++ or the like, and conventional procedural programming languages, such as the “C” programming language or similar programming languages. The computer readable program instructions may execute entirely on the user's computer, partly on the user's computer, as a stand-alone software package, partly on the user's computer and partly on a remote computer or entirely on the remote computer or server. In the latter scenario, the remote computer may be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or the connection may be made to an external computer (for example, through the Internet using an Internet Service Provider). In some embodiments, electronic circuitry including, for example, programmable logic circuitry, field-programmable gate arrays (FPGA), or programmable logic arrays (PLA) may execute the computer readable program instructions by utilizing state information of the computer readable program instructions to personalize the electronic circuitry, in order to perform aspects of the present disclosure.
Aspects of the present disclosure are described herein with reference to flowchart illustrations and/or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the disclosure. It will be understood that each block of the flowchart illustrations and/or block diagrams, and combinations of blocks in the flowchart illustrations and/or block diagrams, can be implemented by computer readable program instructions.
These computer readable program instructions may be provided to a processor of a general purpose computer, special purpose computer, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions/acts specified in the flowchart and/or block diagram block or blocks. These computer readable program instructions may also be stored in a computer readable storage medium that can direct a computer, a programmable data processing apparatus, and/or other devices to function in a particular manner, such that the computer readable storage medium having instructions stored therein comprises an article of manufacture including instructions which implement aspects of the function/act specified in the flowchart and/or block diagram block or blocks.
The computer readable program instructions may also be loaded onto a computer, other programmable data processing apparatus, or other device to cause a series of operational steps to be performed on the computer, other programmable apparatus or other device to produce a computer implemented process, such that the instructions which execute on the computer, other programmable apparatus, or other device implement the functions/acts specified in the flowchart and/or block diagram block or blocks.
The flowchart and block diagrams in the Figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of the present disclosure. In this regard, each block in the flowchart or block diagrams may represent a module, segment, or portion of instructions, which comprises one or more executable instructions for implementing the specified logical function(s). In some alternative implementations, the functions noted in the block may occur out of the order noted in the figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved. It will also be noted that each block of the block diagrams and/or flowchart illustration, and combinations of blocks in the block diagrams and/or flowchart illustration, can be implemented by special purpose hardware-based systems that perform the specified functions or acts or carry out combinations of special purpose hardware and computer instructions.
Embodiments of the disclosure may be provided to end users through a cloud computing infrastructure. Cloud computing generally refers to the provision of scalable computing resources as a service over a network. More formally, cloud computing may be defined as a computing capability that provides an abstraction between the computing resource and its underlying technical architecture (e.g., servers, storage, networks), enabling convenient, on-demand network access to a shared pool of configurable computing resources that can be rapidly provisioned and released with minimal management effort or service provider interaction. Thus, cloud computing allows a user to access virtual computing resources (e.g., storage, data, applications, and even complete virtualized computing systems) in “the cloud,” without regard for the underlying physical systems (or locations of those systems) used to provide the computing resources.
Typically, cloud computing resources are provided to a user on a pay-per-use basis, where users are charged only for the computing resources actually used (e.g. an amount of storage space consumed by a user or a number of virtualized systems instantiated by the user). A user can access any of the resources that reside in the cloud at any time, and from anywhere across the Internet. In context of the present disclosure, a user may access applications or related data available in the cloud. For example, the rules engine 106 could execute on a computing system in the cloud and generate classification rules 105. In such a case, the rules engine 106 could store the generated classification rules 105 at a storage location in the cloud. Doing so allows a user to access this information from any computing system attached to a network connected to the cloud (e.g., the Internet).
While the foregoing is directed to embodiments of the present disclosure, other and further embodiments of the disclosure may be devised without departing from the basic scope thereof, and the scope thereof is determined by the claims that follow.
This application is a continuation of co-pending U.S. patent application Ser. No. 15/820,117, filed Nov. 21, 2017. The aforementioned related patent application is herein incorporated by reference in its entirety.
| Number | Date | Country | |
|---|---|---|---|
| Parent | 15820117 | Nov 2017 | US |
| Child | 16398460 | US |
