Skip to content

References

Jump to bottom
Ivan edited this page Aug 25, 2023 · 6 revisions

Subclassing from the Base Check

The base Check class (data_checks.base.check) define methods used to initialize, customize, and execute a check and its rules. It also has methods to store data related to the check and its execution as well as interact with its suite (if any). It is not recommended to directly subclass the Check class unless you have a specific use case that requires it. Instead, use the DataCheck class (data_checks.data_check) which is a simplified and beginner friendly subclass of the Check class.

If you truly want to modify the base Check class, you can do so by subclassing it and overriding its methods. However be ‼️ extremely careful ‼️ when doing so as it may break the functionality of the library. If you do so, make sure to test your check thoroughly.

⚠️WARNING
Documentation for the base Check class is limited and still a work in progress. For now, you can refer to the source code and its corresponding docstrings for more information.

Subclassing from the Base Suite

The base Suite class (data_checks.base.check) define methods used to initialize, customize, and execute a suite and its checks. It also has methods to store data related to the suite and its execution as well as interact with its checks. It is not recommended to directly subclass the Suite class unless you have a specific use case that requires it. Instead, use the DataSuite class (data_checks.data_suite) which is a simplified and beginner friendly subclass of the Suite class.

If you truly want to modify the base Suite class, you can do so by subclassing it and overriding its methods. However be ‼️ extremely careful ‼️ when doing so as it may break the functionality of the library. If you do so, make sure to test your suite thoroughly.

⚠️WARNING
Documentation for the base Suite class is limited and still a work in progress. For now, you can refer to the source code and its corresponding docstrings for more information.

Database

Suites, checks, rules, and rule executions are stored in a database. The database is specified in the CHECKS_DATABASE_URL variable in your settings file. Any database that is supported by SQLAlchemy can be used. This library generates the following tables in the database:

Suite Table

Stores data related to suites.

id (INT) name (VARCHAR) code (TEXT) config (TEXT) created_at (TIMESTAMPTZ)
001 Suite1 def ... {"schedule": "* */2 * * *"} 2023-08-22 00:00:00.359828-00
002 Suite2 def ... {"schedule": "* * * * *"} 2023-08-22 01:00:00.359828-00
003 Suite3 def ... {"schedule": "* */3 * * *"} 2023-08-22 02:00:00.359828-00
004 Suite4 def ... {"schedule": "* * * * *"} 2023-08-22 03:00:00.359828-00
  • id: Unique identifier for the suite.
  • name: Name of the suite.
  • code: Code of the suite.
  • config: Configuration (in JSON) of the suite.
  • created_at: Timestamp of when the suite was created.

Check Table

Stores data related to checks.

id (INT) name (VARCHAR) code (TEXT) excluded_rules (VARCHAR) config (TEXT) created_at (TIMESTAMPTZ)
001 Check1 def ... ["rule1", "rule2", "rule3"] {..., "rules_config": {...}} 2023-08-22 00:00:00.359828-00
002 Check2 def ... ["rule1", "rule2", "rule3"] {..., "rules_config": {...}} 2023-08-22 01:00:00.359828-00
003 Check3 def ... ["rule1", "rule2", "rule3"] {} 2023-08-22 02:00:00.359828-00
004 Check4 def ... ["rule1", "rule2", "rule3"] {..., "rules_config": {...}} 2023-08-22 03:00:00.359828-00
  • id: Unique identifier for the check.
  • name: Name of the check.
  • code: Code of the check.
  • excluded_rules: List of rules to exclude from the check.
  • config: Configuration (in JSON) of the check.
  • created_at: Timestamp of when the check was created.

Rule Table

Stores data related to rules.

id (INT) check_id (INT) suite_id (INT) name (VARCHAR) hash (TEXT) severity (NUMERIC) code (TEXT) config (TEXT) created_at (TIMESTAMPTZ)
001 001 NULL Rule1 RULE_HASH1 1 def ... {"silenced_until": ...} 2023-08-22 00:00:00.359828-00
002 002 002 Rule2 RULE_HASH2 2 def ... {"silenced_until": ...} 2023-08-22 01:00:00.359828-00
003 003 NULL Rule3 RULE_HASH3 3 def ... {} 2023-08-22 02:00:00.359828-00
004 004 004 Rule4 RULE_HASH4 4 def ... {} 2023-08-22 03:00:00.359828-00
  • id: Unique identifier for the rule.
  • check_id: ID of the check the rule belongs to.
  • suite_id: ID of the suite the rule belongs to.
  • name: Name of the rule.
  • hash: Hash of the rule. In the following format:
suite:SUITE_NAME::check:CHECK_NAME::group:{name: GROUP_NAME, value: GROUP_VALUE}::rule:RULE_NAME::params:{args: [ARG1, ARG2, ...], kwargs: {key1: value1, key2: value2, ...}}
  • severity: Severity of the rule.
  • code: Code of the rule.
  • config: Configuration (in JSON) of the rule.
  • created_at: Timestamp of when the rule was created.

Rule Execution Table

Stores data related to rule executions.

id (INT) rule_id (INT) status (VARCHAR) params (TEXT) logs (TEXT) traceback (TEXT) exception (TEXT) created_at (TIMESTAMPTZ) finished_at (TIMESTAMPTZ)
001 001 success {"args": [], "kwargs": {}} hellow world ... NULL NULL 2023-08-22 00:00:00.359828-00 2023-08-22 00:00:00.359828-00
002 002 failed {"args": [], "kwargs": {}} NULL lorem ipsum dolor sit ... lorem ipsum dolor sit ... 2023-08-22 01:00:00.359828-00 2023-08-22 01:00:00.359828-00
003 003 success {"args": [], "kwargs": {}} hellow world ... NULL NULL 2023-08-22 02:00:00.359828-00 2023-08-22 02:00:00.359828-00
004 004 failed {"args": [], "kwargs": {}} NULL lorem ipsum dolor sit ... lorem ipsum dolor sit ... 2023-08-22 03:00:00.359828-00 2023-08-22 03:00:00.359828-00
  • id: Unique identifier for the rule execution.
  • rule_id: ID of the rule the rule execution belongs to.
  • status: Status of the rule execution.
  • params: Params of the rule execution.
  • logs: Logs of the rule execution.
  • traceback: Traceback of the rule execution.
  • exception: Exception of the rule execution.
  • created_at: Timestamp of when the rule execution was created.
  • finished_at: Timestamp of when the rule execution finished.

Architecture

This library defines 3 core concepts: suites, checks, and rules. Suites are a collection of checks and/or rules. Checks are groups of organized rules that can be selectively executed. Rule are the atomic unit of this data check library and are functions that check incoming data. In the current version, rules need to be defined within checks. This will be changed in a later version of the library. Rules are the fundamental building block of data checks — every other component in this library is built on top of rules and adds additional functionality around these rules. Furthermore note that a Dataset simplifies how data moves between checks and when defined in a suite can be accessed by its corresponding checks and their rules.

Hierarchy

Suites are top level components that group checks. A dataset can be attached to a suite so that the same dataset can be accessed by the underlying checks and rules. Checks are second level components that contain rules. Rules are the lowest level components that actually check data. The following diagram shows the hierarchy of these components:

Data Checks Overview

Execution Flow

The execution flow of a suite of data checks proceeds as follows:

Execution Order

Documentation

Clone this wiki locally