Ensembl Hive Schema Documentation

This document describes the tables that make up the Hive schema. Tables are grouped into categories, and the purpose of each table is explained.
You can toggle the display of individual columns using [Show/Hide columns] buttons.

Hive schema diagram links the tables together.

List of the tables:

Pipeline structure

Resources

Job-related

execution tables

Logging and monitoring

Pipeline structure

This table keeps several important hive-specific pipeline-wide key-value pairs such as hive_sql_schema_version, hive_use_triggers and hive_pipeline_name.

pipeline_wide_parameters
show Show columns [Back to top]

This table contains a simple hash between pipeline_wide_parameter names and their values. The same data used to live in 'meta' table until both the schema and the API were finally separated from Ensembl Core.

Each Analysis is a node of the pipeline diagram. It acts both as a "class" to which Jobs belong (and inherit from it certain properties) and as a "container" for them (Jobs of an Analysis can be blocking all Jobs of another Analysis).

Parallel table to analysis_base which provides high level statistics on the state of an analysis and it's jobs. Used to provide a fast overview, and to provide final approval of 'DONE' which is used by the blocking rules to determine when to unblock other analyses. Also provides

Each entry of this table defines a starting point for dataflow (via from_analysis_id and branch_code) to which point a group of dataflow_target entries can be linked. This grouping is used in two ways: (1) dataflow_target entries that link into the same dataflow_rule share the same from_analysis, branch_code and funnel_dataflow_rule (2) to define the conditions for DEFAULT or ELSE case (via excluding all conditions explicitly listed in the group)

This table links specific conditions with the target object (Analysis/Table/Accu) and optional input_id_template.

analysis_ctrl_rule
show Show columns [Back to top]

These rules define a higher level of control. These rules are used to turn whole anlysis nodes on/off (READY/BLOCKED). If any of the condition_analyses are not 'DONE' the ctrled_analysis is set to BLOCKED. When all conditions become 'DONE' then ctrled_analysis is set to READY The workers switch the analysis.status to 'WORKING' and 'DONE'. But any moment if a condition goes false, the analysis is reset to BLOCKED.

Resources

Maps between resource_class numeric IDs and unique names.

resource_description
show Show columns [Back to top]

Maps (ResourceClass, MeadowType) pair to Meadow-specific resource lines.

Job-related

The job is the heart of this system. It is the kiosk or blackboard where workers find things to do and then post work for other works to do. These jobs are created prior to work being done, are claimed by workers, are updated as the work is done, with a final update on completion.

For testing/debugging purposes both STDOUT and STDERR streams of each Job can be redirected into a separate log file. This table holds filesystem paths to one or both of those files. There is max one entry per job_id and retry.

Accumulator for funneled dataflow.

A generic blob-storage hash. Currently the only legitimate use of this table is "overflow" of job.input_ids: when they grow longer than 254 characters the real data is stored in analysis_data instead, and the input_id contains the corresponding analysis_data_id.

execution tables

Entries of this table correspond to Worker objects of the API. Workers are created by inserting into this table so that there is only one instance of a Worker object in the database. As Workers live and do work, they update this table, and when they die they update again.

Entries of this table correspond to Role objects of the API. When a Worker specializes, it acquires a Role, which is a temporary link between the Worker and a resource-compatible Analysis.

Logging and monitoring

worker_resource_usage
show Show columns [Back to top]

A table with post-mortem resource usage statistics of a Worker. This table is not automatically populated: you first need to run load_resource_usage.pl. Note that some meadows (like LOCAL) do not support post-mortem inspection of resource usage

When a Job or a job-less Worker (job_id=NULL) throws a "die" message for any reason, the message is recorded in this table. It may or may not indicate that the job was unsuccessful via is_error flag. Also $self->warning("...") messages are recorded with is_error=0.

analysis_stats_monitor
show Show columns [Back to top]

A regular timestamped snapshot of the analysis_stats table.