Volver a la lista

Snakemake: Inferir el orden del pipeline solo con los nombres de archivo

Si alguna vez has experimentado que un script de shell se detiene inesperadamente mientras se ejecuta en secuencia, aquí se aborda el principio del grafo acíclico dirigido (DAG) de Snakemake, que infiere el orden de ejecución únicamente a partir de patrones de nombres de archivo, así como la optimización de reejecuciones.

Intermedio
|
20min
|
Verificado (2026-07-29)
Snakemakeworkflow managerpipeline reproducibility
Progreso0/120 (0%)

F26 Siguiente problema: El entorno es fijo, pero ¿quién gestiona el orden?

En F26 nos liberamos del infierno de dependencias con Pixi·uv. Sin embargo, los trabajos de bioinformática no terminan con una sola herramienta. Es necesario encadenar varias herramientas en un orden específico: alineación de FASTQ (S03) → eliminación de duplicados (S05) → llamada de variantes (S07) → filtrado (S09). Todos hemos tenido la experiencia, al menos una vez, de ejecutar manualmente un script de shell paso a paso y tener que reiniciar todo desde el principio porque el servidor se detuvo en el tercer paso. Snakemake (2012~) resuelve este problema con la idea de "no especificar el orden directamente, sino inferirlo mediante patrones de nombres de archivo".

Principio — Definir el flujo de trabajo por resultados, no por comandos

La vulnerabilidad fundamental de los scripts procedimentales

Al escribir un flujo de trabajo con un script de shell, debemos especificar manualmente el orden en que se ejecutan cada uno de los pasos. Si hay un fallo intermedio, hay que verificar manualmente hasta dónde se llegó y volver a editar el script para omitir los pasos que ya se completaron con éxito.

script de shell=el orden lo gestiona una persona    los costes de reinicio y reproducibilidad recaen sobre la persona\text{script de shell} = \text{el orden lo gestiona una persona} \implies \text{los costes de reinicio y reproducibilidad recaen sobre la persona}

La regla de Snakemake: unidades de trabajo definidas por entradas y salidas

Snakemake define cada unidad de trabajo no como una secuencia de comandos, sino mediante la relación entre los archivos de entrada y los archivos de salida.

python
# Ejemplo de Snakefile
rule align:
input:
r1="reads/{sample}_R1.fastq.gz",
r2="reads/{sample}_R2.fastq.gz",
ref="ref/genome.fa"
output:
"aligned/{sample}.bam"
shell:
"bwa mem {input.ref} {input.r1} {input.r2} | samtools sort -o {output}"
rule mark_duplicates:
input:
"aligned/{sample}.bam"
output:
"dedup/{sample}.bam"
shell:
"gatk MarkDuplicates -I {input} -O {output} -M {output}.metrics.txt"

Aquí, {sample} actúa como una comodín (wildcard), lo que permite llenar automáticamente el nombre de la muestra específica a partir del patrón del nombre de archivo, sin necesidad de codificarlo manualmente. Dado que la entrada de la regla mark_duplicates coincide en nombre con la salida de la regla align, Snakemake es capaz de inferir automáticamente las dependencias entre ambas reglas sin necesidad de una conexión explícita.

Construcción del DAG (grafo acíclico dirigido) y ordenamiento topológico

Snakemake construye un grafo acíclico dirigido (Directed Acyclic Graph, DAG) para determinar qué reglas se necesitan y en qué orden, retrocediendo desde el archivo objetivo final.

Archivo objetivo ftarget    conjunto de reglas necesarias{r1,r2,}    determinacioˊn del orden de ejecucioˊn mediante ordenamiento topoloˊgico (topological sort)\text{Archivo objetivo } f_{\text{target}} \implies \text{conjunto de reglas necesarias} \{r_1, r_2, \ldots\} \implies \text{determinación del orden de ejecución mediante ordenamiento topológico (topological sort)}

Una vez construido el DAG, las reglas que no dependen entre sí (por ejemplo, el alineamiento de muestras diferentes) pueden ejecutarse en paralelo.

Ejemplo de cálculo manual: reducir el alcance de la reejecución

Supongamos que se ejecuta un pipeline de tres pasos (alineamiento → deduplicación → llamada de variantes) para 10 muestras. El número total de tareas es

10×3=30 tareas10 \times 3 = 30\text{ tareas}

Si, después de haber completado el alineamiento de todas las muestras y los pasos posteriores de las otras 9 muestras, solo la salida dedup de la octava muestra desaparece debido a un error en el disco, Snakemake compara el estado de los archivos con el DAG. Esto permite saltarse las 28 tareas ya completadas y reejecutar únicamente la etapa faltante de esa muestra y sus tareas downstream.

Nuˊmero de tareas a reejecutar=1(dedup)+1(call)=2 tareas30 tareas\text{Número de tareas a reejecutar} = 1(\text{dedup}) + 1(\text{call}) = 2\text{ tareas} \ll 30\text{ tareas}

En comparación con volver a ejecutar todo desde el principio, esto implica reejecutar solo 15 veces menos tareas. Este es el beneficio más práctico que ofrece Snakemake frente a los scripts de shell procedimentales.

Práctica: ejecutar un mini pipeline de 3 pasos con Snakemake

bash
# SageMaker Studio Lab permite registrarse sin tarjeta de crédito. Snakemake se instala con pip/conda.
pip install snakemake
# Ejecute especificando el archivo objetivo desde el directorio que contiene el Snakefile.
# Es seguro verificar primero solo el plan de ejecución (DAG) con -n (dry-run).
snakemake -n --cores 4 dedup/sample01.bam
# Visualizar DAG como imagen (requiere graphviz)
snakemake --dag dedup/sample01.bam | dot -Tpng > dag.png
# Ejecución real. Especifique la cantidad de tareas en paralelo con --cores.
snakemake --cores 4 dedup/sample01.bam dedup/sample02.bam

La costumbre de verificar primero el DAG y el orden de ejecución con la opción -n(dry-run) ayuda a evitar perder tiempo aplicando accidentalmente reglas incorrectas a conjuntos de datos grandes.

Mapeo de CS

  • DAG y ordenamiento topológico: La planificación de la ejecución de Snakemake es un ejemplo de aplicación práctica en pipelines del ordenamiento topológico de grafos acíclicos dirigidos, tal como se enseña en cursos de estructuras de datos y algoritmos.
  • Genealogía del sistema de compilación make: Definir tareas mediante relaciones de archivos de entrada/salida y determinar si deben reejecutarse basándose en marcas de tiempo es la idea central de make utilizada en la compilación de C/C++, trasladada al dominio de la bioinformática.
  • Programación declarativa vs imperativa: El enfoque de Snakemake, que describe "qué se necesita" (relaciones de entrada/salida) en lugar de "cómo hacerlo" (secuencia de scripts shell), es coherente con la filosofía de diseño de herramientas declarativas como SQL o Terraform.

Errores comunes

  • Ignorar la ambigüedad en los patrones de comodines: Si el patrón del nombre de archivo puede coincidir con múltiples reglas simultáneamente, Snakemake no podrá determinar qué regla utilizar y generará un error. Es necesario diseñar los patrones de salida de cada regla para que no se superpongan.
  • Confundir la actualización de marcas de tiempo como desencadenante de reejecución: Si solo cambia la marca de tiempo (por ejemplo, al copiar un archivo) pero el contenido del archivo no varía, Snakemake podría interpretar que es necesaria una reejecución. En tales casos, es más seguro usar la opción --touch para actualizar únicamente la marca de tiempo.

Para profundizar

El texto ha sido reconstruido directamente por el equipo de investigación de BPD. Para un estudio más avanzado, consulte los artículos originales y la documentación oficial.

  • Artículo original de Snakemake: Köster & Rahmann (2012), Snakemake — a scalable bioinformatics workflow engine, Bioinformatics 28(19).
  • Documentación oficial de Snakemake: Tutoriales y referencia de sintaxis para wildcards y reglas.
  • Formación de EMBL-EBI — Curso de Snakemake: Material práctico oficial.

En el siguiente capítulo (F28), examinaremos Nextflow DSL2, que comparte una filosofía similar a Snakemake pero trata el flujo de datos como un objeto de primera clase.

💬 Preguntas y comentarios

0 comentarios

Puedes publicar sin iniciar sesión. Los comentarios de invitados no pueden editarse ni eliminarse después.

0/2000

Cargando...