top of page

Δημιουργώντας ένα Climate Hazard Pipeline: Η Υποδομή πίσω από την Επιστήμη

  • πριν από 12 ώρες
  • διαβάστηκε 3 λεπτά


Creating a Climate Hazard Pipeline

Το να πεις «μοντελοποιούμε τον κλιματικό κίνδυνο» ακούγεται απλό. Στην πράξη, όμως, αυτό σημαίνει κάτι πολύ συγκεκριμένο: τεράστια αρχεία από πολλαπλά περιφερειακά κλιματικά μοντέλα, διαφορετικά σενάρια εκπομπών, πολλές μεταβλητές, ensembles που πρέπει να επεξεργαστούν παράλληλα, να συγκεντρωθούν και τελικά να παραχθούν ως γεωχωρικά δεδομένα. Όλο το έργο που υλοποίησε η ομάδα μας τον χρόνο που πέρασε προκύπτει απευθείας από τα πραγματικά δεδομένα και όχι από θεωρητικές τεχνικές σχεδιασμού.


Τι κάνει πραγματικά το pipeline

Για κάθε κλιματικό κίνδυνο, τρέχουμε ομάδες συνόλων (Ensembles) μοντέλων σε διαφορετικά σενάρια εκπομπών και χρονικούς ορίζοντες. Κάθε μοντέλο τρέχει ως ξεχωριστή παράλληλη εργασία: παίρνει τα ακατέργαστα κλιματικά δεδομένα, υπολογίζει τα απαραίτητα features, γράφει ενδιάμεσα αποτελέσματα στο cloud και μετά περιμένει να ολοκληρωθούν και τα υπόλοιπα μοντέλα του συνόλου.

Όταν τελειώσουν όλα, ξεκινά το δεύτερο στάδιο: διαβάζουμε όλα τα αποτελέσματα, υπολογίζουμε στατιστικά, ταξινομούμε τα αποτελέσματα σε επίπεδα σοβαρότητας και γράφουμε τα γεωχωρικά αποτελέσματα στη βάση δεδομένων μοντελοποίησης.Και όλα αυτά για πολλαπλά σενάρια, πολλαπλά έτη και δύο τύπους αποτελεσμάτων (πιθανότητα και σοβαρότητα). Ο όγκος δεδομένων μεγαλώνει πολύ γρήγορα.


DAGs: το pipeline ως γράφημα

Ως εργαλείο ενορχήστρωσης  (Orchestration) χρησιμοποιούμε Apache Airflow. Η βασική έννοια εκεί είναι το DAG (Directed Acyclic Graph). Με απλά λόγια: ένα σύνολο εργασιών με καθορισμένες εξαρτήσεις που ορίζει ποια εργασία πρέπει να τελειώσει πριν ξεκινήσει η επόμενη. Το γράφημα αυτό είναι ουσιαστικά το ίδιο το pipeline.

Έχουμε ένα DAG για κάθε hazard. Όλα ακολουθούν την ίδια λογική:

  • Fan-out: δημιουργείται ένα task για κάθε κλιματικό μοντέο και τρέχουν όλα παράλληλα.

  • Synchronization: περιμένουμε να τελειώσουν όλα.

  • Εισαγωγή των αποτελεσμάτων στη βάση.

Είναι μια επαναλαμβανόμενη, τυποποιημένη δομή και αυτό είναι σκόπιμο.


Το πρόβλημα υποδομής

Το δύσκολο κομμάτι δεν ήταν μόνο τα δεδομένα ή τα μοντέλα. Ήταν η υποδομή. Ήδη είχαμε παραγωγικές υπηρεσίες στο ίδιο Kubernetes cluster: authentication, risk, content, modeling όλα με background workers.

Οι διεργασίες climate processing είναι bursty: για κάποιες ώρες θέλουν πολύ compute και μετά τίποτα. Αν αυτά τρέχουν στα ίδια nodes με τα API services, θα δημιουργήσουν latency και αστάθεια.

Η λύση ήταν να προσθέσουμε δύο ξεχωριστά node pools:

  • Ένα για τα βασικά components του Airflow.

  • Ένα για τα pods που τρέχουν τα climate computations.

Το δεύτερο κάνει autoscale μέχρι και στο μηδέν όταν δεν τρέχει pipeline. Αυτό μειώνει κόστος και δεν κρατά άσκοπα resources. Με Kubernetes taints και tolerations εξασφαλίσαμε πλήρη απομόνωση και τα production services δεν μοιράζονται πόρους με τα climate jobs.


Identity και secrets

Το pipeline έχει δύο διαφορετικούς τρόπους πρόσβασης:

  • Έναν operator που διαβάζει secrets από το key vault.

  • Task pods που διαβάζουν/γράφουν σε blob storage.

Δώσαμε ξεχωριστή managed identity σε κάθε περίπτωση, με πρόσβαση μόνο στον απολύτως απαραίτητο πόρο. Υπήρχε και μια παλιά ταυτότητα που είχε μαζέψει δικαιοδοσίες με τα χρόνια και αυτό το project ήταν η αφορμή να τη διαγράψουμε.

Αλλάξαμε επίσης και τον τρόπο που περνάνε τα secrets στο cluster. Πριν, τα secrets συνδέονταν με το lifecycle των pods, πράγμα που μας είχε αναγκάσει να έχουμε ένα pod που απλά έμενε πάντα ανοιχτό για να «κρατάει» τα secrets ενεργά.Τώρα χρησιμοποιούμε έναν operator που συγχρονίζεται συνεχώς με το vault. Ενημερώνεις ένα certificate στο vault → ο operator το φέρνει → ο ingress controller βλέπει το νέο secret. Χωρίς manual βήματα.


Πού βρισκόμαστε τώρα

Η υποδομή είναι πλέον live. Το Airflow τρέχει, τα node pools υπάρχουν, τα secrets έχουν τακτοποιηθεί. Αυτό που έχουμε τώρα είναι μια σταθερή βάση πάνω στην οποία μπορούμε να προσθέτουμε και να συντηρούμε climate hazard models.

Κάθε hazard πλέον ακολουθεί την ίδια δομή:

  • Standardized interface για την επιστημονική λογική.

  • Ένα DAG για orchestration.

  • Ένα CI/CD pipeline που κάνει validate, build και promote αλλαγές από dev σε production μέσω version control.


Οι εποχές των ad-hoc ενημερώσεων μοντέλων και του χειροκίνητου συντονισμού έχουν τελειώσει. Ο κλιματικός κίνδυνος είναι ένα μακροπρόθεσμο παιχνίδι και το pipeline που χτίσαμε είναι σχεδιασμένο για να αντέξει στον χρόνο.


Η ομάδα E-ON Engineering αναπτύσσει την πλατφόρμα πίσω από το RiskClima — εργαλείο για κλιματικό κίνδυνο, μοντελοποίηση και δεδομένα για οργανισμούς που σχεδιάζουν για τα επόμενα τριάντα χρόνια.

 

Σχόλια


bottom of page