maestru ajunge la eliberare stabilă | R-bloggeri

Durate mai rapide de construire și de rulare a programului

S-a depus mult efort pentru îmbunătățirea performanței funcțiilor de bază build_schedule şi run_schedule. Construirea este mai ales mai eficientă, de aproximativ 2x-4x mai rapidă pentru proiectele cu un număr decent de conducte. De exemplu, cel mai greu proiect maestru al nostru, care are peste 50 de conducte, a înregistrat un timp mediu de construcție de 2 secunde coborât la 0,5 secunde. Acest lucru face mai fezabil rularea maestrului la frecvențe strânse ale orchestratorului.

Programele sunt mai portabile

O problemă cu vechiul mod în care maestro a construit programele a fost că memorarea în cache și reutilizarea unui obiect de program (spre deosebire de reconstruirea lui de fiecare dată) a dus în cele din urmă la expirarea programului.². Începând cu maestro 1.1.0, programele pot fi stocate în cache și reutilizate în siguranță, evitând nevoia de a rula build_schedule la fiecare cursă de orchestrator. Este la fel de simplu ca alergatul saveRDS pe un program predefinit și apoi folosind readRDS pentru a-l încărca în ciclul de producție.

Funcție nouă get_run_sequence

Este adesea util să cunoașteți orele viitoare pentru care conductele dvs. sunt programate să ruleze. În acest scop, am adăugat get_run_sequence funcţie care returnează un data.frame de timpi de execuţie programaţi. Acest lucru poate fi util pentru planificare și monitorizare:

#' ./pipelines
#' @maestroFrequency hourly
hourly <- function() {
  
}

#' @maestroFrequency daily
#' @maestroStartTime 02:00:00
daily <- function() {
  
}

#' @maestroFrequency 3 hours
#' @maestroStartTime 01:00:00
every_3_hours <- function() {
  
}

library(maestro)

schedule <- build_schedule(quiet = TRUE)

get_run_sequence(schedule) |>
  head(n = 10)

# A tibble: 10 × 3
   pipe_name     scheduled_time      is_primary
                               
 1 hourly        2026-04-20 00:00:00 TRUE      
 2 hourly        2026-04-20 01:00:00 TRUE      
 3 every_3_hours 2026-04-20 01:00:00 TRUE      
 4 hourly        2026-04-20 02:00:00 TRUE      
 5 daily         2026-04-20 02:00:00 TRUE      
 6 hourly        2026-04-20 03:00:00 TRUE      
 7 hourly        2026-04-20 04:00:00 TRUE      
 8 every_3_hours 2026-04-20 04:00:00 TRUE      
 9 hourly        2026-04-20 05:00:00 TRUE      
10 hourly        2026-04-20 06:00:00 TRUE      

Timpi de ancorare mai intuitivi pentru conductele săptămânale/lunare

Înainte de 1.1.0, conductele care rulau cu o frecvență mai mică decât cea zilnică aveau nevoie de o ancoră de dată specifică ca oră de începere. Acestea s-au simțit arbitrare și au făcut dificil să știi care era intenționat să fie punctul de ancorare real.

#' Old pre 1.1.0 method for scheduling a weekly pipeline on a Monday
#' @maestroFrequency weekly
#' @maestroStartTime 2026-04-13 04:00:00
weekly_pipeline <- function() {
  
}

#' New, 1.1.0 intuitive way
#' @maestroFrequency weekly
#' @maestroStartTime Mon 04:00:00
weekly_pipeline <- function() {
  
}

#' @maestroFrequency monthly
#' @maestroStartTime 2 04:00:00
monthly_pipeline <- function() {
  
}

O mai bună observabilitate a conductelor DAG care se clasifică – revizuire get_status().

În nomenclatura DAG, fan-in-ul are loc atunci când mai multe conducte diferite sunt introduse într-o singură conductă. Un bun exemplu ar fi o conductă generică „send_logs_to_storage” care este reutilizată de fiecare conductă dintr-un proiect ca maestroOutputs. Înainte de lansarea stabilă, această operațiune a funcționat în maestro, dar rezultatul get_status ar raporta doar ultima invocare chiar dacă a fost apelată de mai multe ori.

Din acest motiv, am modificat rezultatul lui get_status() pentru a include un rând pentru fiecare invocare unică de conductă într-o singură rulare a orchestratorului. Aceeași logică trebuia aplicată get_artifacts(). De asemenea, am dat fiecărei invocații un unic run_id pentru a urmări mai bine execuția distinctă a unei conducte și execuția introdusă în ce conductă din aval.

Aruncă o privire la următorul exemplu trivial de fan-in în care atât p1, cât și p2 au introdus în p3:

#' ./pipelines
#' @maestroFrequency hourly
#' @maestroOutputs p3
p1 <- function() {
  1
}

#' @maestroFrequency hourly
#' @maestroOutputs p3
p2 <- function() {
  2
}

#' @maestro
p3 <- function(.input) {
  .input * 2
}

schedule <- build_schedule(quiet = TRUE)

output <- run_schedule(
  schedule,
  orch_frequency = "1 hour",
  n_show_next = 0
)

── (2026-04-20 14:01:36)
Running pipelines ▶ 

── (2026-04-20 14:01:37)
Pipeline execution completed ■ | 0.089 sec elapsed 

✔ 4 successes | ! 0 warnings | ✖ 0 errors | ◼ 4 total

────────────────────────────────────────────────────────────────────────────────

get_status(schedule)(, c("pipe_name", "run_id", "input_run_id", "lineage"))

# A tibble: 4 × 4
  pipe_name run_id input_run_id lineage
                   
1 p1        KbGACI          p1     
2 p2        mbmNzx          p2     
3 p3        loyy2f KbGACI       p1->p3 
4 p3        Zs1Avj mbmNzx       p2->p3 

get_artifacts(schedule)

$p1
(1) 1

$p2
(1) 2

$p3
$p3$loyy2f
(1) 2

$p3$Zs1Avj
(1) 4

Funcții depreciate

Această versiune marchează deprecierea a două funcții interactive mai puțin utilizate.

suggest_orch_frequency este depreciat, fără o perioadă de timp specifică pentru eliminare. Această funcție a fost un ajutor pe jumătate pentru a oferi cea mai bună ipoteză la o frecvență ideală a orchestratorului, având în vedere toate conductele din proiect. Motivul pentru care merge este că este periculos dacă este folosit automat și perpetuează un tipar prost de alegere a frecvențelor de conducte, oricum naiba-ți dorești, mai degrabă decât de a încuraja un pic de gândire atentă la cel mai bun mod de a orchestra conductele.

show_network este, de asemenea, depreciat și va fi eliminat într-o versiune viitoare 1.2.0. Acesta a fost un înveliș subțire în jurul pachetului DiagrammR pentru a afișa rețeaua de grafice implicată de un DAG. Problema mea a fost că necesita o dependență de DiagrammR pentru o capacitate de vizualizare banală. În plus, în majoritatea proiectelor, vizualizarea pe care a produs-o a fost destul de greu de privit datorită naturii maestrului fiind în principal pentru mai multe conducte independente.

Învelire

Ca întotdeauna, orchestrare fericită!