...
Tool/Object | Metric Group | Metric Name | Description | Usage and Comments | |||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
CleaningJob | CleaningJobStatus | Deleted documents | The total count of DB_GONE (HTTP 404) and/or DB_DUPLICATE documents ultimately deleted from the indexer(s). | This metric is useful for determining whether filtering or duplicate detection needs to happen further upstream prior to indexing. Ideally DB_GONE and DB_DUPLICATE documents would not make it into production indices in the first place. | |||||||||||||||||||||
CrawlDbFilter | CrawlDB filter | Gone records removed | The total count of DB_GONE (HTTP 404) records deleted from the CrawlDB during an update. | See
| |||||||||||||||||||||
CrawlDB filter | Orphan records removed | The total count of orphaned pages e.g. a page which have no more other pages linking to it, deleted from the CrawlDB during an update. | See
| ||||||||||||||||||||||
CrawlDB filter | URLs filtered | The total count of filtered pages e.g. pages which didn't pass one or more URLFIlter implementation(s), deleted from the CrawlDB during an update. | This metric is generally useful for determining the overall effectiveness of URLFilter plugins over time. POSSIBLE IMPROVEMENT: This metric could be improved if an association could be made between the URL was filtered and the URLFilter which filtered it. This would facilitate aggregating URLFiltering results by URLFilter. | ||||||||||||||||||||||
CrawlDbReducer | CrawlDB status | CrawlDatum.getStatusName(CrawlDatum().getStatus()) | With each URL able to have only one state at any given point in time, this metric facilitates aggregated counts of the different types of CrawlDatum states for a given CrawlDB. | The state of any given URL will change as the URL transitions through a crawl cycle. Available URL states are defined in the CrawlDatum e.g., STATUS_DB_UNFETCHED, STATUS_DB_FETCHED, STATUS_FETCH_SUCCESS, etc. Practically, CrawlDatum status' are defined using byte signatures but accessed programmatically using static final constants. This metric can be used to identify the presence of undesired URL CrawlDatum status' for given URL's e.g., STATUS_DB_GONE. Such an event could then trigger a cleaning/pruning operation. | |||||||||||||||||||||
DeduplicationJob | DeduplicationJobStatus | Documents marked as duplicate | The total number of duplicate documents in the CrawlDB. | The process of identifying (near) duplicate documents is of vital importance within the context of a search engine. The precision of any given information retrieval system can be negatively impacted if (near) duplicates are not identified and handled correctly. This does not always mean removing them, for example maybe (near) duplicates are important for versioning purposes. In most cases however it is preferred to identify and remove (near) duplicate records. The Deduplication algorithm in Nutch groups fetched URLs with the same digest and marks all of them as duplicate except the one with the highest score (based on the score in the crawldb, which is not necessarily the same as the score indexed). If two (or more) documents have the same score, then the document with the latest timestamp is kept. If the documents have the same timestamp then the one with the shortest URL is kept. A duplicate record will have a CrawlDatum status of CrawlDatum.STATUS_DB_DUPLICATE. | |||||||||||||||||||||
DomainStatistics | N/A | MyCounter.EMPTY_RESULT | The total count of empty (probably problematic) URL records for a given host, domain, suffix or top-level domain. | It is possible that the DomainStatistics tool may identify an empty record for a given URL. This may happen regardless of whether the tool is invoked to retrieve host, domain, suffix or top-level domain statistics. When this discovery event occurs, it it is likely that some investigation would take place to understand why. For example, the CrawlDbReader could be invoked with the -url command line argument to further debug/detail what CrawlDatum data exists. | |||||||||||||||||||||
N/A | MyCounter.FETCHED | The total count of fetched URL records for a given host, domain, suffix or top-level domain. | This metric is particularly useful for quickly drilling down through large datasets to determine, for example, how much 'coverage' has been achieved for a given host, domain, suffix or top-level domain. This figure can be compared to a website administrators total. | ||||||||||||||||||||||
N/A | MyCounter.NOT_FETCHED | The total count of unfetched URL records for a given host, domain, suffix or top-level domain. | This metric is particularly useful for quickly drilling down through large datasets to determine, for example, how much 'coverage' still has to be achieved for a given host, domain, suffix or top-level domain. When combined with the fetched figure and compared to a website administrators total it can provide useful insight. | ||||||||||||||||||||||
Fetcher | FetcherStatus | bytes_downloaded | The total bytes of fetched data acquired across the Fetcher Mapper task(s). | Over time, this can be used to benchmark how much data movement is occurring over the Nutch crawl network. POSSIBLE IMPROVEMENT: This metric could be improved if a correlation could be made between the volume of data and the source it came from whether that be a given host, domain, suffix or top-level domain. | |||||||||||||||||||||
FetcherStatus | hitByThrougputThreshold | A total count of the URLs dropped across all fetch queues due to throughput dropping below the threshold too many times. | This aspect of the Nutch Fetcher configuration is designed to prevent slow fetch queues from stalling the overall fetcher throughput. However it usually has the impact of increasing the latency/timeliness of URLs actually being fetched if they are essentially dropped because of low throughput. This means that they are shelved until a future fetch operation. The specific configuration settings is
A more thorough understanding of Fetcher configuration relating to (slow) throughput requires an understanding of the following configuration settings as well
POSSIBLE IMPROVEMENT: It would be advantageous to understand which URLs from which hosts in the queue(s) were resulting in slow throughput. This would facilitate investigation into why this was happening. | ||||||||||||||||||||||
FetcherStatus | hitByTimeLimit | A total count of the URLs dropped across all fetch queues due to the fetcher execution time limit being exceeded. | This metric is valuable for quantifying the number of URLs which have been effectively timebombed e.g. shelved for future fetching due to overall fetcher runtime exceeding a predefined timeout. Although by default the Fetcher never times out e.g. the configuration is set to -1,if a timeout is preferred then the following configuration property can be edited.
POSSIBLE IMPROVEMENT: It could be useful to record the fact that a URL was staged due to it being hit by the timeout limit. This could possibly be stored in the CrawlDatum metadata. Also see
| ||||||||||||||||||||||
FetcherThread | FetcherStatus | AboveExceptionThresholdInQueue | The total count of URLs purged across all fetch queues as a result of the maximum number of protocol-level exceptions (e.g. timeouts) per queue being exceeded. | This metric is useful for quantifying the number of URLs shelved for future fetching due to anomalies occurring during fetcher execution exceeding a predefined ceiling. Although by default the Fetcher never enforces this behaviour e.g. the configuration is set to -1, if this is changed then this total count will become a useful metric to track. Further information on the configuration parameter can be seen below
POSSIBLE IMPROVEMENT: It could be useful to record the fact that a URL was staged due to it being hit by the exception limit. Additionally, it could be useful to write metadata to all URLs which contributed towards the limit being met. This could possibly be stored in the CrawlDatum metadata. | |||||||||||||||||||||
FetcherStatus | FetchItem.notCreated.redirect | A total count of URLs across all fetch queues for which following redirect(s) resulted in no result. | Essentially, each FetcherThread attempts to understand and eliminate all redirect options e.g. duplicate redirect URL, before giving up on a redirect URL entirely. In the case of a redirect URL for which no logical fetch outcome can be produced e.g. that the FetchItem is null, redirecting is simply deactivated as it is impossible to continue. | ||||||||||||||||||||||
FetcherStatus | outlinks_detected | A total count of detected outlinks for all fetch items (URLs) across all fetch queues. | This metric can be used to estimate the number in URLs to be fetched in the next fetch phase. If for example, resources were being allocated within the client at configuration/compile time (rather than dynamically at runtime) this could be used to inform resource reservations, utilization and data partitioning logic. | ||||||||||||||||||||||
FetcherStatus | outlinks_following | From outlinks_detected (see directly above), this is a total count of URLs which will be followed. | This metric value may be the same as outlinks_detected or it may be less. This ultimately depends on a few things i.e.,
| ||||||||||||||||||||||
FetcherStatus | ProtocolStatus.getName() | Total counts of all the different fetched finished status' for all URLs. | For a comprehensive collection of the various fetched finish status' to expect, check out the private static final HashMap<Integer, String> codeToName defined within ProtocolStatus. This metric is useful for understanding, from across your CrawlDb, the status of certain URLs. Via different tools, you can begin to investigate further. | ||||||||||||||||||||||
FetcherStatus | redirect_count_exceeded | Total count of all URLs which have exceeded the maximum configured number of redirects. | See the following configuration property in nutch-default.xml
This metric is useful for understanding how many URLs are possibly skipped due to a large number of redirects. Also see the following property
| ||||||||||||||||||||||
FetcherStatus | redirect_deduplicated | Total count of duplicate (and hence not fetched) redirected URLs. | No fetching takes place for this class of redirect URLs as they are duplicates of other redirect URLs already fetched. | ||||||||||||||||||||||
FetcherStatus | robots_denied | Total count of all URLs not fetched due to being denied by robots.txt rules. | By default Nutch is configured to respect and comply with robots.txt rules for any given site. It is useful to know how many URLs may not be fetched from a given site due to robots.txt compliance. | ||||||||||||||||||||||
FetcherStatus | robots_denied_maxcrawldelay | Total count of URLs which are skipped due to the robots.txt crawl delay being above a configured maximum. | The following configuration property must be consulted for a detailed explanation behind this metric.
Essentially, a delay of 5 seconds is used for fetching requests to the same host unless a crawl delay is specified within the robots.txt. Also see
| ||||||||||||||||||||||
ParserStatus | ParseStatus.majorCodes[p.getData().getStatus().getMajorCode()] | Total count of major codes (see right) from parsing URLs. | ParseStatus defines three major categories for the result of an URL parse operation. i.e., notparsed, success and failed. This metric is useful for debugging how many parse operations failed for a given crawl cycle. Subsequent parse attempts can then be made or the URL record can be handled appropriately. | ||||||||||||||||||||||
Generator | Generator | EXPR_REJECTED | Total count of URLs rejected by Jexl expression(s) during the generate phase. | This metric is useful for determining the impact that that Jexl expressions (provided via the Generator CLI) have on filtering URLs. The expressions are evaluated during the Generator Map phase. All of the configuration which drives this metric is read or set from Java code and not explicitly defined in nutch-default.xml. | |||||||||||||||||||||
Generator | HOSTS_AFFECTED_PER_HOST_OVERFLOW | Total count of host(s) or domain(s) affected by the number of URLs exceeding a configured fetchlist size threshold. | This configuration property is essentially turned off by default e.g. there is no defined maximum number of URLs per fetchlist. However, if a maximum is defined, then it is useful to know, how many hosts or domains included in fetchlists have more URLs than allowed. In these cases additional URLs won't be included in the fetchlist but bumped on to future crawling cycles. The configuration property below will directly drive this metric.
| ||||||||||||||||||||||
Generator | INTERVAL_REJECTED | Total count of records rejected due to retry or fetch interval being above a configured thershold. | This configuration property is essentially turned off by default e.g. there is no minimum defined retry interval. This metric is useful for understanding the impact that changing that has on URL filtering. The configuration property below drives this metric.
| ||||||||||||||||||||||
Generator | MALFORMED_URL | Total count of malformed URLs filtered. | In the Generator, malformed URLs are either discovered by
| ||||||||||||||||||||||
Generator | SCHEDULE_REJECTED | Total count of URLs not suitable for selection (in a given crawl cycle due to the fetch time being higher than the current time. | The metric description covers the default fetch schedule case but this can change depending on the actual implementation. Of specific interest is FetchSchedule#shouldFetch(...) which explains further. This metric can be useful for comparing implementations of FetchSchedule. | ||||||||||||||||||||||
Generator | SCORE_TOO_LOW | Total count of filtered URL entries with a score lower than a configured threshold. | The configuration parameter which drives this metric is
The default value for this configuration property means that all entries should be selected. The metric can be useful to determine if a configured minimum value is too high and filters too many URLs from being included in fetchlists. | ||||||||||||||||||||||
Generator | STATUS_REJECTED | Total count of URLs filtered by a CrawlDatum status filter. | The following configuration property is used to straight filter URLs depending on their CrawlDatum status
As an indication of the status keys which can be used, see CrawlDatum.statNames. This metric is useful to simply see how effective the status filters are. | ||||||||||||||||||||||
Generator | URLS_SKIPPED_PER_HOST_OVERFLOW | Total count of URLs skipped by the number of URLs exceeding a configured fetchlist size threshold. | This configuration property is essentially turned off by default e.g. there is no defined maximum number of URLs per fetchlist. However, if a maximum is defined, then it is useful to know, how many URLs are skipped. In these cases additional URLs won't be included in the fetchlist but bumped on to future crawling cycles. The configuration property below will directly drive this metric.
| ||||||||||||||||||||||
IndexerMapReduce | IndexerStatus | deleted (duplicates) | Total count of duplicate records deleted from the indexing backend. | This configuration property is deactivated by default however it can be activated by providing the -deleteGone flag to the IndexerJob CLI. The duplication algorithm is documented well in the DeduplicationJob Javadoc. POSSIBLE IMPROVEMENT: See the commentary on whether a distinction should be made between HTTP 404/gone, temp/perm redirects and duplicates. This may ultimately result in these functions being broken out into individual flags and/or configuration properties in nutch-default.xml at which stage this documentation will be updated. | |||||||||||||||||||||
IndexerStatus | deleted (IndexingFilter) | Total count of deleted records as a result of being skipped/filtered by indexing filters. | This configuration property is deactivated by default but it can be activated either by providing the -params indexer.delete.skipped.by.indexingfilter=true flag to the IndexerJob CLI or editing it in nutch-default.xml as shown below
Additional information on the original implementation can be found at https://issues.apache.org/jira/browse/NUTCH-1449 | ||||||||||||||||||||||
IndexerStatus | deleted (gone) | Total count of HTTP 404/gone records deleted from the indexing backend. | If a Nutch deployment uses the crawl script then this configuration property is activated by default otherwise it is deactivated. However it can be activated by providing the -deleteGone flag to the IndexerJob CLI (as is done in the crawl script). POSSIBLE IMPROVEMENT: See the commentary on whether a distinction should be made between HTTP 404/gone, temp/perm redirects and duplicates. This may ultimately result in these functions being broken out into individual flags and/or configuration properties in nutch-default.xml at which stage this documentation will be updated. | ||||||||||||||||||||||
IndexerStatus | deleted (redirects) | Total count of temporary and permanently redirected records deleted from the indexing backend. | This configuration property is deactivated by default however it can be activated by providing the -deleteGone flag to the IndexerJob CLI. POSSIBLE IMPROVEMENT: See the commentary on whether a distinction should be made between HTTP 404/gone, temp/perm redirects and duplicates. This may ultimately result in these functions being broken out into individual flags and/or configuration properties in nutch-default.xml at which stage this documentation will be updated. | ||||||||||||||||||||||
IndexerStatus | deleted (robots=noindex) | Total count of deleted records which contain meta robots="noindex" | This configuration property is deactivated by default but it can be activated either by providing the -params indexer.delete.robots.noindex=true flag to the IndexerJob CLI or editing it in nutch-default.xml as shown below
See Google's Block Search indexing with noindex documentation for more information. Additional information on the original implementation can be found at https://issues.apache.org/jira/browse/NUTCH-1434 | ||||||||||||||||||||||
IndexerStatus | errors (IndexingFilter) | Total count of errors which occurred during execution of the indexing filtering and normalization chain. | Both filtering and normalization are deactivated by default in IndexingJob but can be activated by providing the -filter and -normalize flags respectively to the IndexerJob CLI. This metric is useful for determining, for example, the impacts that changes to an indexing filtering/normalization chain are having on URLs ultimately being indexed. A higher count means that something is wrong. POSSIBLE IMPROVEMENT: It could be useful to record the fact that URL filtering and/or normalization processes resulted in an error for a given record. This could possibly be stored in the relevant datum/metadata container. POSSIBLE IMPROVEMENT: Additionally, although URL filtering and normalization happens in both Map and Reduce phases of a job, this metric is only implemented in the Reduce phase. We need to determine if we want to extend this metric to also cover the Map phase of IndexingJob. POSSIBLE IMPROVEMENT: Finally, we need to determine whether this is a general metric we wish to capture for any job where filtering and normalization takes place. | ||||||||||||||||||||||
IndexerStatus | errors (ScoringFilter) | Total count of errors which occurred during execution of the scoring filtering chain. | This metric is useful for determining, for example, the impacts that changes to an indexing scoring chain are having on URLs ultimately being indexed. A higher count means that something is wrong. Scoring is always executed during the indexing reduce phase. Scoring implementations are initially configured in the plugin.includes configuration property of nutch-default.xml however their order of execution is based on the following configuration property
Some scoing plugins have specific settings in nutch-default.xml which should be consulted prior and during execution and use in production deployments. POSSIBLE IMPROVEMENT: Finally, we need to determine whether this is a general metric we wish to capture for any job where scoring takes place. | ||||||||||||||||||||||
IndexerStatus | indexed (add/update) | Total count of records successfully indexed or updated by the indexing backend. | This metric is literally the last thing which is counted within the IndexingJob reduce phase. When combined with other metrics it can be used to provide an overall understanding of indexing results. | ||||||||||||||||||||||
IndexerStatus | skipped (IndexingFilter) | Total count of records skipped/filtered by indexing filters. | Note the similarity to deleted (IndexingFilter) above however in this case the documents are not deleted from the indexing backend. | ||||||||||||||||||||||
IndexerStatus | skipped (not modified) | Total count of records skipped with a db_notmodified status i.e., that the page was successfully fetched and found not modified. | This configuration property is deactivated by default but it can be activated either by providing the -params indexer.skip.notmodified=true flag to the IndexerJob CLI or editing it in nutch-default.xml as shown below
| ||||||||||||||||||||||
Injector | injector | urls_filtered | Total count of new seed URLs filtered by the Injector. | URL normalization and then filtering operations are executed within the Injector Map task(s). They are both turned off by default in nutch-default.xml however if these values are not interpreted the Injector turns normalization and filtering operations on by default. This metric is useful to determine the impact that normalization and filtering have on the injection of seeds contained within seed lists. For more information on configuration see
| |||||||||||||||||||||
injector | urls_injected | Total count of seed URLs injected by the Injector. | A useful metric for simply counting by how many URLs the CrawlDb has grown by the end of an Injector invocation. | ||||||||||||||||||||||
injector | urls_merged | Total count of seed URLs merged with an existing CrawlDatum record. | This metric is useful for seeing how many existing URL records were affected by a given seed list within the Injector reduce task(s). Several configuration settings are used to determine what those affects are...
You should also consult the Injector.InjectorReducer#reduce documentation as it adequately describes the Injector merging algorithm. | ||||||||||||||||||||||
injector | urls_purged_404 | Total count of deleted/purged URLs due to an existing CrawlDatum.STATUS_DB_GONE | If turned on, 404 purging occurs during the Injector Map task(s). It relies on the following configuration property
The metric is useful for understanding how many seed URLs are already known to be essentially dead links. POSSIBLE IMPROVEMENT: The property description above needs to be updated to accommodate usage of this property in Injector. | ||||||||||||||||||||||
injector | urls_purged_filter | Total count of existing CrawlDatum records filtered by one or more filters and/or normalizers during the Injector execution. | Not to be confused with similar metric urls_filtered above. This configuration setting can only be activated in the Injector Map phase by passing the -filterNormalizeAll flag on the command-line. | ||||||||||||||||||||||
ParseSegment | ParserStatus | ParseStatus.majorCodes[parseStatus.getMajorCode()] | Total individual record counts of major parse status i.e., notparsed, successand failed. | This metric is really useful for determining total counts of generic parse status' particularly as it provides insight into parsing failures. For a given media type within a given dataset or crawl cycle we can better understand what kind of input data results in parse failures and then begin to work to debug why and provide fixes. This metric is generated during the Map phase of the ParseSegment tool. POSSIBLE IMPROVEMENT: Create a composite key which includes both the major parse status and minor parse status. An example could be failed:FAILED_TRUNCATED or similar. Minor parse status' are documented in ParseStatus.java#L50-L84. | |||||||||||||||||||||
QueueFeeder | FetcherStatus | filtered | Total count of URLs which were filtered or failed to normalize within Fetcher queue feeding thread(s). | The QueueFeeder feeds queues with input items, and re-fills them as items are consumed by FetcherThread-s. This metric is useful for quantifying how many records were filtered or normalized during that process particularly if changes are made to the URL filter(s) or normalizer(s) chain. By default filtering and normalization are deactivated during Fetcher execution however they can be activated by editing the following configuration properties.
| |||||||||||||||||||||
(also QueueFeeder) | FetcherStatus | AboveExceptionThresholdInQueue | |||||||||||||||||||||||
ResolverThread | UpdateHostDb | checked_hosts | |||||||||||||||||||||||
UpdateHostDb | existing_known_host | ||||||||||||||||||||||||
UpdateHostDb | existing_unknown_host | ||||||||||||||||||||||||
UpdateHostDb | new_known_host | ||||||||||||||||||||||||
UpdateHostDb | new_unknown_host | ||||||||||||||||||||||||
UpdateHostDb | purged_unknown_host | ||||||||||||||||||||||||
UpdateHostDb | rediscovered_host | ||||||||||||||||||||||||
UpdateHostDb | Long.toString(datum.numFailures()) + "_times_failed" | ||||||||||||||||||||||||
SitemapProcessor | Sitemap | existing_sitemap_entries | |||||||||||||||||||||||
Sitemap | failed_fetches | ||||||||||||||||||||||||
Sitemap | filtered_records | ||||||||||||||||||||||||
Sitemap | filtered_sitemaps_from_hostname | ||||||||||||||||||||||||
Sitemap | new_sitemap_entries | ||||||||||||||||||||||||
Sitemap | sitemaps_from_hostname | ||||||||||||||||||||||||
Sitemap | sitemap_seeds | ||||||||||||||||||||||||
UpdateHostDbMapper | UpdateHostDb | filtered_records | Total count of records filtered within an update to the HostDb. | Useful for determining the impact that filtering and normalization plugins and associated rules have on the resulting HostDb. See the following configuration properties
This value can also be overridden on the command line with the -filter and -normalize flags. | |||||||||||||||||||||
UpdateHostDbReducer | UpdateHostDb | total_hosts | Total count of all hosts processed in one HostDb update. | Useful when considered alongside other metrics to determine the overall impact that configuration, such as filtering or skipping, has on processing of hosts contained within the HostDb. | |||||||||||||||||||||
(also UpdateHostDbReducer) | UpdateHostDb | skipped_not_eligible | Total count of records skipped within an update to the HostDb. | Records are skipped if the -checkNew flag is used whilst invoking the tool AND it is a new Host (meaning that the HostDatum is empty). Also see the following configuration property
| |||||||||||||||||||||
WebGraph | WebGraph.outlinks | added links | Total count of links which will ultimately be used in WebGraph scoring. | Useful metric to indicate how many links are essentially used within the scoring process. | |||||||||||||||||||||
(also WebGraph) | WebGraph.outlinks | removed links | Total count of GONE pages not used in Webgraph scoring. | Useful metric to indicate presence of gone/404 records which are not used within the scoring process. | |||||||||||||||||||||
WARCExporter | WARCExporter | exception | Total count of IOException and/or IllegalStateException's caught during tool execution. | These Exception's can occur in the WARCExporter Reduce task(s) and if they do it is convenient to count them. They can arise when attempting to write records with a WARCWritable value. | |||||||||||||||||||||
WARCExporter | invalid URI | Total count of invalid entries with an invalid WARC-Target-URI | These Exception's can occur in the WARCExporter Reduce task(s) and if they do it is convenient to count them. This metric is essentially indicating that an Exception was raised and caught as a result of an invalid WARC-Target-URIi for some given record. | ||||||||||||||||||||||
WARCExporter | missing content | Total count of records with missing (null) content. | These Exception's can occur in the WARCExporter Reduce task(s) and if they do it is convenient to count them. POSSIBLE IMPROVEMENT: Providing traceability to the individual record would enable debugging of why content is null. | ||||||||||||||||||||||
WARCExporter | missing metadata | Total count of records with missing (null) CrawlDatum metadata. | These Exception's can occur in the WARCExporter Reduce task(s) and if they do it is convenient to count them. POSSIBLE IMPROVEMENT: Providing traceability to the individual record would enable debugging of why CrawlDatum metadata is null. | ||||||||||||||||||||||
WARCExporter | omitted empty response | Total count of records not written because they have empty responses. | This setting can be turned on via the command line with the -onlySuccessfulResponsesi flag. If it is turned on it means that records with the CrawlDatum status' not STATUS_FETCH_SUCCESS or STATUS_FETCH_NOTMODIFIED will not be written as they are irregular responses. | ||||||||||||||||||||||
WARCExporter | records generated | Total count of WARC records successfully exported written. | A useful metric when combined with other counts as it provides a more comprehensive understanding of data quality i.e., missing and or incomplete data. |
...