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

Extension of simple_rule design except that goal(to) is now in extended URL format e.g. mysql://ensadmin:@ecs2:3361/compara_hive_test?analysis.logic_name='blast_NCBI34' (full network address of an analysis). The only requirement is that there are rows in the job, analysis, dataflow_rule, and worker tables so that the following join works on the same database WHERE analysis.analysis_id = dataflow_rule.from_analysis_id AND analysis.analysis_id = job.analysis_id AND analysis.analysis_id = worker.analysis_id These are the rules used to create entries in the job table where the input_id (control data) is passed from one analysis to the next to define work. The analysis table will be extended so that it can specify different read and write databases, with the default being the database the analysis is on

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.

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.