Validity constraints for data analysis workflows

Autor/innen

  • F. Schintke
  • K. Belhajjame
  • N. De Mecquenem
  • D. Frantz
  • V.E. Guarino
  • M. Hilbrich
  • F. Lehmann
  • P. Missier
  • R. Sattler
  • J.A. Sparka
  • D.T. Speckhard
  • H. Stolte
  • A.D. Vu
  • U. Leser

Journal

  • Future Generation Computer Systems

Quellenangabe

  • Futur Gener Comp Syst 157: 82-97

Zusammenfassung

  • Porting a scientific data analysis workflow (DAW) to a cluster infrastructure, a new software stack, or even only a new dataset with some notably different properties is often challenging. Despite the structured definition of the steps (tasks) and their interdependencies during a complex data analysis in the DAW specification, relevant assumptions may remain unspecified and implicit. Such hidden assumptions often lead to crashing tasks without a reasonable error message, poor performance in general, non-terminating executions, or silent wrong results of the DAW, to name only a few possible consequences. Searching for the causes of such errors and drawbacks in a distributed compute cluster managed by a complex infrastructure stack, where DAWs for large datasets typically are executed, can be tedious and time-consuming. We propose validity constraints (VCs) as a new concept for DAW languages to alleviate this situation. A VC is a constraint specifying logical conditions that must be fulfilled at certain times for DAW executions to be valid. When defined together with a DAW, VCs help to improve the portability, adaptability, and reusability of DAWs by making implicit assumptions explicit. Once specified, VCs can be controlled automatically by the DAW infrastructure, and violations can lead to meaningful error messages and graceful behavior (e.g., termination or invocation of repair mechanisms). We provide a broad list of possible VCs, classify them along multiple dimensions, and compare them to similar concepts one can find in related fields. We also provide a proof-of-concept implementation for the workflow system Nextflow.


DOI

doi:10.1016/j.future.2024.03.037