自动模块化的工作流抽象：提升工作流代码的可复用性

《Future Generation Computer Systems》：Workflow abstractions for automatic modularity: Improving workflow code reusability

　　**摘要**
数据分析工作流在数据密集型科学中起着核心作用，但其日益增加的结构复杂性使得理解和重用变得困难。大型工作流图通常由数百个步骤和数千个数据依赖关系组成，这可能会让用户感到不知所措，并阻碍代码探索。子工作流提供了一种自然的机制来降低这种复杂性，通过提供粗粒度的、层次化的视图来呈现工作流结构，并提供专门用于重用的功能组件。利用GitHub上的分支数量作为重用的指标，对从GitHub中提取的3009个Nextflow工作流进行的实证研究表明，使用子工作流的工作流平均被分叉的数量是不使用子工作流的工作流的2.5倍，这突显了模块化与重用之间的强烈关联。然而，只有21.8%的工作流定义了子工作流，这反映了设计有意义的模块结构的难度。为了解决这一难题，我们提出了一个用于自动构建抽象的框架，即编码（可能是嵌套的）子工作流的工作流图结构对象。基于对用户定义的子工作流的大规模分析，我们推断出了常见的模块化策略，并形式化了三种类型的自动抽象。我们引入了AbstractionBuilder算法，该算法可以直接从工作流依赖图中构建这些抽象。来自工作流开发者的反馈以及对实际工作流的实证评估表明，这种抽象框架可以创建有意义的子工作流，从而降低工作流图的结构复杂性。这些发现表明，抽象框架支持工作流的理解和重用。

**引言**
在数据密集型科学中，数据科学家正在定义越来越复杂的数据分析工作流[1],[2]。基于工作流的方法已在许多科学领域得到广泛应用，包括生命科学[3]、天文学或生物多样性等[4]。工作流可以广泛定义为一种计算过程，它协调多个分析步骤及其数据依赖关系。工作流的日益普及催生了各种系统的开发[5],[6]，从交互式环境（例如Jupyter[7]或RStudio1）到专用的工作流管理系统（如Galaxy[8]、Snakemake[9]和Nextflow[10]）。现在广泛鼓励共享数据分析工作流[11]，在某些情况下，编辑政策甚至要求这样做[2]，以促进科学透明度。共享的承诺是通过允许其他科学家重新执行数据分析来实现可重复性，并促进代码在相关上下文中的重用和适应，从而推动工作流之间的组件重用并支持累积的科学进步[3],[12]。然而，无论是先前的[13]还是最近的研究[14]都显示，工作流的重用仍然有限。实际上，我们观察到被重用工作流的一个关键特点是定义了子工作流[5],[11],[15]，即可以单独隔离和处理的模块化组件。这种模块化与重用之间的联系在软件开发中已被充分证实：Alomar等人[16]在1828个开源Java项目中研究表明，提高重用的重构直接与代码结构的模块化变化有关。由于Nextflow在生物信息学中是一个被广泛采用的工作流系统，我们用它作为我们研究的代表案例。使用GitHub上的分支数量作为重用的指标，在从GitHub提取的3009个Nextflow工作流中，定义了子工作流的工作流平均被分叉的数量是不定义子工作流的工作流的2.5倍（3.0 vs 1.2）。nf-core社区[17],[18]进一步说明了这一点：由于它维护了一个要求使用子工作流的标准，其组件在该生态系统中被最广泛地重用[14]。模块化的工作流有助于更好地理解和提高清晰度，这是重用的基本前提。因此，指导工作流开发者在引入子工作流时需要一个专门的方法和工具，以满足以下要求，这些要求是在ShareFAIR项目中与十多位工作流开发者合作确定的[4]：
(1) 创建连贯的组件。模块化的子工作流有助于识别和提取工作流中的连贯组件，即将具有共同意义的步骤分组，使它们在不同上下文中更易于重用[11]。实际上，在我们的工作流样本中，只有21.8%的工作流使用了子工作流。这表明设计连贯的组件可能是一项具有挑战性的任务。这一观察得到了我们作为工作流开发者的经验支持，以及在ShareFAIR项目和其他领域与专家的讨论[17],[18],[22]。确定什么是连贯组件并不总是直截了当的，因为它可能受到多种有时相互竞争的设计策略的指导。例如，子工作流通常是为了将具有相同功能的步骤分组在一起而创建的，因此它们在同一上下文中执行，形成一个功能上连贯的组件；或者它们可以通过解耦并行分析路径来提供灵活性，允许它们独立管理或修改，以及其他策略。
(2) 降低工作流表示的复杂性。对于数据分析工作流，用户通常希望在深入了解实现细节（如输入-输出关系和软件依赖关系[12]之前，先把握主要分析步骤。然而，可视化整个工作流图往往是不切实际的：数据分析工作流可能由数百个分析步骤组成，导致非常复杂的图表示，具有数千个顶点和边。这样的表示很快就变得难以处理，并可能妨碍而不是帮助用户理解（见图1(a)）。因此，通过降低其图表示的复杂性来促进对工作流的理解非常重要。实际上，这意味着首先以高层次的、粗粒度的表示来展示分析步骤，然后在理解了整体结构后再揭示更详细的细节。图1展示了flexlmm工作流的细粒度（图1(a)）和粗粒度（图1(b)表示，说明了粗粒度表示的优势[19]。因此，构建这种粗粒度表示至关重要，而模块化的子工作流为此提供了一个自然的机制。通过将这些子工作流孤立出来并将每个子工作流表示为一个单独的顶点（即有效地折叠它们），可以减少整个工作流的结构，形成工作流的简化视图。这提高了图的抽象层次，同时显著降低了其表观复杂性。
(3) 以不同的粒度级别发现工作流。有趣的是，我们样本中60.5%的子工作流嵌套在其他子工作流中。由于子工作流本身也可能包含嵌套的子工作流，将不同的子工作流折叠成单个顶点可以产生同一工作流在不同粒度级别上的多种可能视图，允许用户通过逐渐放大和缩小在粗粒度和细粒度表示之间进行探索。因此可以考虑一系列粒度级别。最粗糙的级别，或“表面视图”，是当每个子工作流被折叠成一个单独的顶点时获得的，而最细的级别对应于原始的工作流图本身（见图1(a)）。
(4) 有效地创建层次结构。一种能够自动建议连贯层次结构的工具在开发工作流的过程中有两个不同的用例中非常有价值。首先，在工作流构建期间，这样的工具可以实时协助开发者快速建议如何将步骤分组为组件，或者可能如何修改现有的组件。其次，在工作流重用期间，这样的工具可以通过快速提出简化的结构来支持对外部现有工作流的检查，从而有助于理解工作流并识别值得重用的组件。在这两种情况下，工具都会建议新的组件或现有组件的替代方案，允许用户根据需要快速重构工作流。关键的是，这种方法需要设计一个能够近乎实时生成建议的工具。
这些要求引发了两个问题：开发者目前在设计子工作流时遵循哪些策略？我们如何支持子工作流层次结构（通过嵌套的子工作流）的自动设计？

**理解科学家如何开发工作流**
几十年来，人们一直在讨论科学家如何开发工作流，无论是总体上[23],[24]还是在生物信息学社区内部[25],[26]。使用最近的工作流系统（如Nextflow或Snakemake）开发工作流的方式在[27]中进行了研究，并在[28]中进一步讨论。然而，所有这些研究主要集中在旨在优化工作流执行的开发策略上。据我们所知，没有专门的研究更广泛地表征工作流开发者遵循的设计策略，特别是考虑到重用。
关于第二个研究问题，之前的工作流研究探讨了降低工作流图的复杂性。ZOOM*UserViews[29],[30]通过将工作流图划分为复合模块来降低复杂性，但依赖于用户输入。Alper等人[31]通过基于规则的重写迭代地降低图复杂性，以简化与生成的数据集相关的来源信息，但并不旨在生成可重用的组件。重构方法[32]则针对效率低下的工作流进行重写。最重要的是，所有这些特定于工作流的方法都产生单层解决方案；它们都没有解决支持子工作流层次结构设计的问题。
更广泛地说，类似的降低图复杂性的目标也在工作流领域之外通过图稀疏化[33]、图凝结[34]、统计图摘要[35]和图粗化[36],[37],[38]等方式得到追求。虽然这些技术在概念上与我们的问题相关，但它们是为不同的应用场景开发的，包括图数据库聚合（OLAP）、机器学习[34]和实际应用（如电网分析[39]）。图粗化与我们的目标最为相关，因为它将图划分为顶点组[36],[37],[38]。然而，[36]依赖于图中已有的属性注释，而[37]是基于固定参数k进行划分的。同样重要的是，这两种方法都没有生成层次结构。虽然[38]生成了层次结构，但它是通过递归应用k-way图划分来平衡结果组件中的顶点数量来实现的，而不是依赖于反映开发者设计选择的准则。据我们所知，无论是特定于工作流的方法还是更通用的图简化技术，都没有能够自动生成连贯子工作流的层次结构。
为了解决这些挑战，我们提出了一个自动构建工作流抽象的框架，这些抽象结构对象编码了工作流图中的嵌套子工作流层次结构（第2节）。重要的是，该框架是通用的：它操作于抽象的工作流依赖图，不假设任何特定的工作流管理系统。我们在Nextflow工作流上对该框架进行了实例化和实证验证，鉴于其在生物信息学中的普遍性以及大型、精心策划的语料库（特别是通过nf-core）的可用性。
然后，我们介绍了对用户定义的子工作流的研究结果，以表征实际中的模块化策略。基于这些观察，我们推断出了三种不同类型的自动抽象，每种抽象反映了不同的设计策略（第3节）。为了自动构建这些抽象，我们提出了AbstractionBuilder算法，该算法直接从工作流图中构建它们（第4节）。然后通过分析实际工作流的语料库以及与外部工作流开发者的系列访谈，从实证和主观两个方面对这些抽象进行了评估（第5节）。最后，我们讨论了该框架（第6节），并概述了未来的发展方向（第7节）。

**第1节：工作流抽象的通用框架**
在本节中，我们首先介绍了从工作流代码中提取的构成我们抽象框架基础的元素，然后形式化了工作流抽象的概念。

**设计抽象策略**
在前一节中，工作流抽象是通过使用从工作流代码中提取的用户定义的子工作流来注释工作流图来构建的。然而，这些注释的定义方式会显著影响结果抽象的结构和解释。在本节中，我们首先研究了用户定义的子工作流在实践中的构建方式。然后，我们定义了自动构建注释的替代策略，从而...

**构建工作流抽象**
在本节中，我们描述了AbstractionBuilder算法，该算法以工作流图W=(V,A)及其相关注释Φ=(Λ,prop)作为输入，并生成一个层次结构Γ={γ1,…,γh}，这是一个最小的工作流抽象。给定W、Φ(C)、Φ(D)或Φ(Π)，AbstractionBuilder分别生成最小条件抽象、支配抽象或并行抽象。

**实验和结果**
前一节介绍了工作流图抽象的概念，包括一个手动定义的抽象，并提供了三种自动抽象（条件抽象、支配抽象和并行抽象），涵盖了大量常见的设计策略。在本节中，在介绍了实验设置之后，我们描述了评估我们方法性能的结果，该方法旨在满足引言中强调的要求，即：（1）创建具有连贯性的模块；（2）创建抽象方法。该抽象框架已经通过实证和主观评估，发现它能够创建可用于重用的连贯性组件，降低工作流程图的复杂性，并通过特定的层次结构探索不同级别的粒度，同时这些组件可以高效地通过AbstractionBuilder算法生成。所有三种抽象方法在实证评估中都显示出了实用性。这与不同用户可能有不同的观点和需求这一事实是一致的。

在本文中，我们研究了开发人员在设计子工作流时采用的策略，基于共享条件、常见的数据流依赖关系和平行路径推断出了三种方法。我们开发了一个工作流抽象框架，该框架可以自动生成层次化的子工作流图，并根据这些设计策略定义了三种抽象类型：条件抽象、支配抽象和平行抽象。我们引入了AbstractionBuilder算法，该算法能够从特定数据中生成这些抽象。

**作者贡献声明：**
George Marchment：编写——原始草案，软件设计，方法论，形式化分析，数据管理，概念化。
Sarah Cohen-Boulakia：编写——审阅与编辑，监督，项目管理，资金获取，概念化。
Alain Denise：编写——审阅与编辑，监督，方法论，概念化。
Frédéric Lemoine：编写——审阅与编辑，监督，方法论，概念化。

**资助：**
部分由法国国家研究机构（ANR-22-PESN-0007）在France 2030计划下提供。

**利益冲突声明：**
作者声明他们没有已知的财务利益冲突或个人关系可能会影响本文所述的工作。

**致谢：**
我们要感谢ShareFAIR的成员和Leo Planche进行了富有成效的讨论，感谢六位匿名工作流开发者对抽象方法提供的反馈，以及审稿人提出的建设性意见。

**作者信息：**
George Marchment | Sarah Cohen-Boulakia | Alain Denise | Frédéric Lemoine
巴黎萨克雷大学，法国国家科学研究中心（CNRS），数字科学跨学科实验室，91405，奥赛