Come usare i quaderni esplorativi [Best Practices]

Come utilizzare i quaderni esplorativi Le migliori pratiche

I notebook Jupyter sono stati uno degli strumenti più controversi nella comunità della scienza dei dati. Ci sono alcuni critici schietti, così come appassionati fan. Tuttavia, molti scienziati dei dati concorderanno sul fatto che possono essere veramente preziosi – se usati correttamente. Ed è su questo che ci concentreremo in questo articolo, il secondo della mia serie su Software Patterns per Data Science e ML Engineering. Ti mostrerò le migliori pratiche per utilizzare i Jupyter Notebooks per l’analisi esplorativa dei dati.

Ma prima, dobbiamo capire perché i notebook sono stati introdotti nella comunità scientifica. Quando la scienza dei dati era sexy, i notebook non esistevano ancora. Prima di loro, avevamo IPython, che era integrato negli IDE come Spyder che cercavano di imitare il funzionamento di RStudio o Matlab. Questi strumenti hanno ottenuto una diffusione significativa tra i ricercatori.

Nel 2014, il progetto Jupyter è nato da IPython. Il suo utilizzo è cresciuto rapidamente, trainato principalmente dai ricercatori che sono passati a lavorare nell’industria. Tuttavia, gli approcci per l’utilizzo dei notebook che funzionano bene per i progetti scientifici non necessariamente si traducono bene nelle analisi condotte per le unità aziendali e produttive delle imprese. Non è raro che gli scienziati dei dati assunti appena usciti dall’università stentino a soddisfare le nuove aspettative che incontrano riguardo alla struttura e presentazione delle loro analisi.

In questo articolo, parleremo dei notebook Jupyter specificamente da un punto di vista aziendale e produttivo. Come ho già detto, i notebook Jupyter sono un argomento polarizzante, quindi andiamo subito alla mia opinione.

I notebook Jupyter dovrebbero essere utilizzati solo per compiti esplorativi o analisi ad hoc.

Un notebook non dovrebbe essere altro che un rapporto. Il codice che contiene non dovrebbe essere importante affatto. Sono solo i risultati che genera che contano. Idealmente, dovremmo essere in grado di nascondere il codice nel notebook perché è solo un mezzo per rispondere alle domande.

Ad esempio: Quali sono le caratteristiche statistiche di queste tabelle? Quali sono le proprietà di questo dataset di addestramento? Qual è l’impatto di mettere questo modello in produzione? Come possiamo garantire che questo modello superi il precedente? Come ha funzionato questo AB test?

I notebook Jupyter sono utili in diversi settori e per diversi scopi
I notebook Jupyter sono utili in diversi settori e per diversi scopi | Fonte: Autore

Notebook Jupyter: linee guida per una narrazione efficace

Scrivere i notebook Jupyter è fondamentalmente un modo per raccontare una storia o rispondere a una domanda su un problema che hai investigato. Ma questo non significa che devi mostrare il lavoro esplicito che hai svolto per arrivare alla tua conclusione.

I notebook devono essere rifiniti.

Sono creati principalmente affinché lo scrittore possa comprendere una questione, ma anche affinché i loro colleghi possano acquisire quella conoscenza senza doversi addentrare nel problema in modo approfondito.

Scopo

La natura non lineare e ad albero dell’esplorazione dei dati nei notebook, che di solito contengono sezioni di esplorazione irrilevanti che non hanno portato a nessuna risposta, non è il modo in cui il notebook dovrebbe apparire alla fine. Il notebook dovrebbe contenere il contenuto minimo che risponde meglio alle domande in gioco. Dovresti sempre commentare e fornire ragionamenti su ciascuna delle ipotesi e conclusioni. I riassunti esecutivi sono sempre consigliati poiché sono perfetti per le parti interessate con un interesse vago sull’argomento o poco tempo a disposizione. Sono anche un ottimo modo per preparare i revisori delle tue righe guida complete.

Pubblico

Il pubblico dei notebook di solito è piuttosto tecnico o orientato al business. Pertanto, ci si aspetta che si utilizzi un linguaggio avanzato. Tuttavia, i riassunti esecutivi o le conclusioni dovrebbero sempre essere scritti in linguaggio semplice e fare riferimento alle sezioni con spiegazioni ulteriori e più approfondite. Se ti trovi a faticare nel creare un notebook per un pubblico non tecnico, potresti voler considerare la creazione di una presentazione invece. Lì puoi utilizzare infografiche, visualizzazioni personalizzate e metodi più ampi per spiegare le tue idee.

I diversi attori di un data scientist hanno tutte esigenze diverse
I diversi attori di un data scientist hanno tutte esigenze diverse | Fonte: Autore

Contesto

Fornisci sempre il contesto del problema. I dati da soli non sono sufficienti per una storia coerente. Dobbiamo inquadrare tutta l’analisi all’interno del settore in cui stiamo lavorando in modo che il pubblico si senta a suo agio nella lettura. Utilizza i collegamenti alla base di conoscenza esistente dell’azienda per supportare le tue affermazioni e raccogli tutti i riferimenti in una sezione dedicata del notebook.

Come strutturare il contenuto di un notebook Jupyter

In questa sezione, spiegherò il layout del notebook che utilizzo di solito. Potrebbe sembrare molto lavoro, ma consiglio di creare un modello di notebook con le seguenti sezioni, lasciando dei segnaposto per le specificità del tuo compito. Un modello personalizzato di questo tipo ti permetterà di risparmiare molto tempo ed assicurare coerenza tra i notebook.

  1. Titolo: Idealmente, il nome dell’attività JIRA associata (o qualsiasi altro software di gestione delle attività) collegata all’attività. Ciò consente a te e al tuo pubblico di connettere in modo univoco la risposta (il notebook) alla domanda (l’attività JIRA).
  2. Descrizione: Cosa vuoi raggiungere in quest’attività? Deve essere molto breve.
  3. Indice: Le voci dovrebbero essere collegamenti alle sezioni del notebook, permettendo al lettore di saltare alla parte di suo interesse. (Jupyter crea ancoraggi HTML per ogni titolo derivati dal titolo originale attraverso headline.lower().replace(” “, “-“), quindi puoi collegarli con semplici link Markdown come [titolo sezione](#titolo-sezione). Puoi anche posizionare tu stesso degli ancoraggi aggiungendo <a id=’tuo-ancora’></a> alle celle Markdown.)
  4. Riferimenti: Collegamenti a documentazione interna o esterna con informazioni di sfondo o informazioni specifiche utilizzate nell’analisi presentata nel notebook.
  5. TL;DR o Sommario esecutivo: Spiega, in modo molto conciso, i risultati di tutta l’esplorazione e metti in evidenza le conclusioni chiave (o le domande) a cui sei arrivato.
  6. Introduzione & contesto: Metti l’attività nel contesto, aggiungi informazioni sulla precedenti aziendali chiave relative alla questione e spiega l’attività più in dettaglio.
  7. Importazioni: Importazioni di librerie e impostazioni. Configura le impostazioni per le librerie di terze parti, come matplotlib o seaborn. Aggiungi variabili d’ambiente, come le date, per fissare la finestra di esplorazione.
  8. Dati da esplorare: Descrivi le tabelle o i set di dati che stai esplorando/analizzando e fai riferimento alle loro fonti o collega le loro voci nel catalogo dei dati. Idealmente, rivela come ogni set di dati o tabella viene creato e con quale frequenza viene aggiornato. Puoi collegare questa sezione a qualsiasi altra documentazione.
  9. Celle di analisi
  10. Conclusione: Spiegazione dettagliata dei risultati chiave ottenuti nella sezione di analisi, con collegamenti a parti specifiche dei notebook in cui i lettori possono trovare ulteriori spiegazioni.

Ricorda sempre di utilizzare sempre la formattazione Markdown per gli header e per evidenziare dichiarazioni e citazioni importanti. Puoi controllare le diverse opzioni di sintassi Markdown nella documentazione di Markdown Cells — Jupyter Notebook 6.5.2.

Esempio di modello per un notebook esplorativo
Esempio di modello per un notebook esplorativo | Fonte: Autore

Come organizzare il codice in un notebook Jupyter

Per le attività esplorative, il codice per produrre query SQL, manipolazione dei dati con pandas o creazione di grafici non è importante per i lettori.

Tuttavia, è importante per i revisori, quindi dovremmo comunque mantenere una qualità e una leggibilità elevate.

I miei consigli per lavorare con il codice nei notebook sono i seguenti:

Sposta le funzioni ausiliarie in moduli Python normali

In generale, è meglio importare le funzioni definite nei moduli Python anziché definirle nel notebook. Per prima cosa, le differenze di Git all’interno dei file .py sono molto più facili da leggere rispetto alle differenze nei notebook. Il lettore non dovrebbe nemmeno conoscere ciò che una funzione sta facendo sotto il cofano per seguire il notebook.

Ad esempio, di solito hai funzioni per leggere i tuoi dati, eseguire query SQL e preprocessare, trasformare o arricchire il tuo dataset. Tutte dovrebbero essere spostate in file .py e poi importate nel notebook in modo che i lettori vedano solo la chiamata alla funzione. Se un revisore desidera maggiori dettagli, può sempre guardare direttamente il modulo Python.

Trovo che questo sia particolarmente utile per le funzioni di plotting, ad esempio. È tipico che io possa riutilizzare la stessa funzione per creare un barplot più volte nel mio notebook. Avrò bisogno di apportare piccole modifiche, come utilizzare un diverso set di dati o un diverso titolo, ma il layout e lo stile del grafico saranno gli stessi. Invece di copiare e incollare lo stesso frammento di codice, creo semplicemente un modulo utils/plots.py e creo funzioni che possono essere importate e adattate fornendo argomenti.

Ecco un esempio molto semplice:

import matplotlib.pyplot as plt
import numpy as np
 
def create_barplot(data, x_labels, title='', xlabel='', ylabel='', bar_color='b', bar_width=0.8, style='seaborn', figsize=(8, 6)):
    """Crea un barplot personalizzabile utilizzando Matplotlib.
 
    Parametri:
    - data: Lista o array di dati da tracciare.
    - x_labels: Lista di etichette per l'asse x.
    - title: Titolo del grafico.
    - xlabel: Etichetta per l'asse x.
    - ylabel: Etichetta per l'asse y.
    - bar_color: Colore delle barre (predefinito è blu).
    - bar_width: Larghezza delle barre (predefinito è 0.8).
    - style: Stile Matplotlib da applicare (ad esempio, 'seaborn', 'ggplot', 'default').
    - figsize: Tupla che specifica la dimensione della figura (larghezza, altezza).
 
    Restituisce:
    - Nessuno
    """
    # Imposta lo stile di Matplotlib
    plt.style.use(style)
 
    # Crea una figura e un asse
    fig, ax = plt.subplots(figsize=figsize)
 
    # Genera le posizioni x per le barre
    x = np.arange(len(data))
 
    # Crea il barplot
    ax.bar(x, data, color=bar_color, width=bar_width)
 
    # Imposta le etichette dell'asse x
    ax.set_xticks(x)
    ax.set_xticklabels(x_labels)
 
    # Imposta le etichette e il titolo
    ax.set_xlabel(xlabel)
    ax.set_ylabel(ylabel)
    ax.set_title(title)
 
    # Mostra il plot
    plt.show()
 
# Esempio di utilizzo all'interno di una cella del notebook:
create_barplot(
    data,
    x_labels,
    title=”Grafico a Barre Personalizzabile”,
    xlabel=”Categorie”,
    ylabel=”Valori”,
    bar_color=”skyblue”,
    bar_width=0.6,
    style=”seaborn”,
    figsize=(10,6)
)

Quando crei questi moduli Python, ricorda che il codice fa ancora parte di un’analisi esplorativa. Quindi, a meno che tu non lo stia usando in un’altra parte del progetto, non deve essere perfetto. Deve solo essere abbastanza leggibile e comprensibile per i revisori.

Posizionare le funzioni per il tracciamento, il caricamento dei dati, la preparazione dei dati e le implementazioni delle metriche di valutazione nei moduli Python normali mantiene un notebook Jupyter focalizzato sull'analisi esplorativa
Spostare le funzioni per il tracciamento, il caricamento dei dati, la preparazione dei dati e le implementazioni delle metriche di valutazione nei moduli Python normali mantiene un notebook Jupyter focalizzato sull’analisi esplorativa | Fonte: Autore

Utilizzo di SQL direttamente nelle celle di Jupyter

Ci sono alcuni casi in cui i dati non sono in memoria (ad esempio, in un DataFrame pandas) ma nel data warehouse dell’azienda (ad esempio, Redshift). In quei casi, la maggior parte dell’esplorazione e della manipolazione dei dati viene fatta tramite SQL.

Ci sono diversi modi per utilizzare SQL nei notebook Jupyter. JupySQL ti consente di scrivere codice SQL direttamente nelle celle del notebook e mostra il risultato della query come se fosse un DataFrame di pandas. Puoi anche memorizzare gli script SQL in file di accompagnamento o all’interno dei moduli Python ausiliari di cui abbiamo discusso nella sezione precedente.

Scegliere tra uno o l’altro dipende principalmente dal tuo obiettivo:

Se stai eseguendo una esplorazione dei dati su diverse tabelle da un data warehouse e vuoi mostrare ai tuoi colleghi la qualità e la validità dei dati, mostrare le query SQL all’interno del notebook è di solito la migliore opzione. I tuoi revisori apprezzeranno di poter vedere direttamente come hai interrogato queste tabelle, che tipo di join hai dovuto fare per arrivare a determinate viste, quali filtri hai dovuto applicare, ecc.

Tuttavia, se stai solo generando un set di dati per convalidare un modello di apprendimento automatico e il focus principale del notebook è mostrare diverse metriche e output di spiegabilità, allora consiglierei di nascondere il processo di estrazione del set di dati il più possibile e conservare le query in uno script SQL separato o in un modulo Python.

Vedremo ora un esempio di come utilizzare entrambe le opzioni.

Lettura ed esecuzione da script .sql

Possiamo utilizzare file .sql che vengono aperti ed eseguiti dal notebook attraverso una libreria di connettore per database.

Supponiamo di avere la seguente query in un file select_purchases.sql:

SELECT * FROM public.ecommerce_purchases WHERE product_id = 123

Quindi, potremmo definire una funzione per eseguire gli script SQL:

import psycopg2
 
def execute_sql_script(filename, connection_params):
    """
    Esegui uno script SQL da un file utilizzando psycopg2.
 
    Parametri:
    - filename: Il nome del file script SQL da eseguire.
    - connection_params: Un dizionario contenente i parametri di connessione PostgreSQL,
                        come 'host', 'port', 'database', 'user' e 'password'.
 
    Restituisce:
    - None
    """
    # Estrarre i parametri di connessione
    host = connection_params.get('host', 'localhost')
    port = connection_params.get('port', '5432')
    database = connection_params.get('database', '')
    user = connection_params.get('user', '')
    password = connection_params.get('password', '')
 
    # Stabilire una connessione al database
    try:
        conn = psycopg2.connect(
            host=host,
            port=port,
            database=database,
            user=user,
            password=password
        )
        cursor = conn.cursor()
 
        # Leggere ed eseguire lo script SQL
        with open(filename, 'r') as sql_file:
            sql_script = sql_file.read()
            cursor.execute(sql_script)
        
        # Ottenere il risultato in un DataFrame di Pandas
        result = cursor.fetchall()
        column_names = [desc[0] for desc in cursor.description]
        df = pd.DataFrame(result, columns=column_names)

        # Eseguire il commit delle modifiche e chiudere la connessione
        conn.commit()
        conn.close()
        return df

    except Exception as e:
        print(f"Errore: {e}")
        if 'conn' in locals():
            conn.rollback()
            conn.close()

Nota che abbiamo fornito valori predefiniti per i parametri di connessione al database in modo da non doverli specificare ogni volta. Tuttavia, ricorda di non memorizzare mai segreti o altre informazioni sensibili all’interno dei tuoi script Python! (Più avanti nella serie, discuteremo delle diverse soluzioni a questo problema.)

Ora possiamo utilizzare il seguente comando one-liner all’interno del nostro notebook per eseguire lo script:

df = execute_sql_script('select_purchases.sql', connection_params)

Utilizzo di JupySQL

Tradizionalmente, ipython-sql è stato lo strumento preferito per interrogare SQL dai notebook Jupyter. Ma è stato ritirato dal suo creatore originale nell’aprile 2023, che raccomanda di passare a JupySQL, che è un fork attivamente mantenuto. In futuro, tutti i miglioramenti e le nuove funzionalità saranno aggiunte solo a JupySQL.

Per installare la libreria per l’uso con Redshift, dobbiamo fare:

pip install jupysql sqlalchemy-redshift redshift-connector 'sqlalchemy<2'

(Puoi anche usarlo insieme ad altri database come snowflake o duckdb,)

Nel tuo notebook Jupyter puoi ora utilizzare il comando magico %load_ext sql per abilitare SQL e utilizzare il seguente snippet per creare un motore sqlalchemy per Redshift:

from os import environ
from sqlalchemy import create_engine
from sqlalchemy.engine import URL

user = environ["REDSHIFT_USERNAME"]
password = environ["REDSHIFT_PASSWORD"]
host = environ["REDSHIFT_HOST"]

url = URL.create(
    drivername="redshift+redshift_connector",
    username=user,
    password=password,
    host=host,
    port=5439,
    database="dev",
)

engine = create_engine(url)

Successivamente, basta passare il motore al comando magico:

%sql engine --alias redshift-sqlalchemy

E sei pronto!

Adesso è semplice come utilizzare il comando magico e scrivere la query che desideri eseguire e otterrai i risultati nel output della cella:

%sql
SELECT * FROM public.ecommerce_purchases WHERE product_id = 123

Assicurati di eseguire le celle in ordine

Ti consiglio di eseguire sempre tutte le celle di codice prima di caricare il notebook nel tuo repository. I notebook Jupyter salvano lo stato di output di ogni cella quando viene eseguita. Ciò significa che il codice che hai scritto o modificato potrebbe non corrispondere all’output mostrato della cella.

Eseguire un notebook dall’inizio alla fine è anche un buon test per verificare se il tuo notebook dipende da qualsiasi input dell’utente per essere eseguito correttamente. Idealmente, tutto dovrebbe funzionare senza la tua intervento. Se non è così, la tua analisi probabilmente non può essere riprodotta da altri – o nemmeno da te in futuro.

Un modo per verificare se un notebook è stato eseguito correttamente è utilizzare il hook pre-commit di nbcheckorder. Controlla se i numeri di output delle celle sono sequenziali. Se non lo sono, indica che le celle del notebook non sono state eseguite una dopo l’altra e impedisce il commit Git.

Configurazione di esempio .pre-commit-config.yaml:

- repo: local
   rev: v0.2.0
   hooks:
     - id: nbcheckorder

Se non stai ancora usando pre-commit, ti consiglio vivamente di adottare questo piccolo strumento. Ti consiglio di iniziare a conoscerlo attraverso questa introduzione a pre-commit di Elliot Jordan. Successivamente, puoi consultare la sua documentazione dettagliata per comprendere tutte le sue funzionalità.

Svuota l’output delle celle

Meglio ancora del consiglio precedente, svuota tutti gli output delle celle nel notebook. Un vantaggio ottenuto è che è possibile ignorare lo stato e gli output delle celle, ma d’altra parte, obbliga i revisori a eseguire il codice in locale se vogliono vedere i risultati. Ci sono diversi modi per farlo automaticamente.

Puoi utilizzare il pacchetto nbstripout insieme a pre-commit come spiegato da Florian Rathgeber, autore dello strumento, su GitHub:

- repo: local
  rev: 0.6.1
  hooks:
    - id: nbstripout

Puoi anche utilizzare nbconvert –ClearOutputpPreprocessor in un hook personalizzato di pre-commit come spiegato da Yury Zhauniarovich:

  - repo: local
    hooks:
      - id: jupyter-nb-clear-output
        name: jupyter-nb-clear-output
        files: \.ipynb$
        stages: [ commit ]
        language: python
        entry: jupyter nbconvert --ClearOutputPreprocessor.enabled=True --inplace
        additional_dependencies: [ 'nbconvert' ]

Produc e condividi report con Jupyter notebook

Ecco, qui viene una domanda non ben risolta nel settore. Qual è il modo migliore per condividere i tuoi notebook con il tuo team e gli stakeholder esterni?

In termini di condivisione delle analisi da quaderni Jupyter, il campo si divide tra tre tipi diversi di team che favoriscono modi diversi di lavorare.

I team di traduzione

Questi team credono che le persone delle unità aziendali o dei prodotti non si sentiranno a proprio agio nel leggere i quaderni Jupyter. Pertanto, adattano le loro analisi e relazioni al pubblico previsto.

I team di traduzione prendono le loro conclusioni dai quaderni e le aggiungono al sistema di conoscenza della loro azienda (ad esempio Confluence, Google Slides, ecc.). Come effetto collaterale negativo, perdono parte della tracciabilità dei quaderni, perché ora è più difficile rivedere la cronologia delle versioni del rapporto. Ma, sosterranno, sono in grado di comunicare i loro risultati e analisi in modo più efficace agli stakeholder pertinenti.

Se si desidera fare ciò, consiglio di mantenere un collegamento tra il documento esportato e il quaderno Jupyter in modo che siano sempre sincronizzati. In questa configurazione, è possibile mantenere quaderni con meno testo e conclusioni, focalizzati maggiormente sui fatti o le evidenze dei dati grezzi. Si utilizzerà il sistema di documentazione per approfondire il riassunto esecutivo e i commenti su ciascuna delle conclusioni. In questo modo, è possibile separare i due deliverable: il codice esplorativo e le conclusioni ottenute.

I team interni completi

Questi team utilizzano quaderni Jupyter locali e li condividono con altre unità aziendali costruendo soluzioni personalizzate per il sistema di conoscenza e l’infrastruttura della loro azienda. Credono che i responsabili aziendali e dei prodotti debbano essere in grado di comprendere i quaderni del data scientist e ritengono importante mantenere una tracciabilità completa delle conclusioni risalente al dato grezzo.

Tuttavia, è improbabile che il team finanziario si colleghi a GitHub o Bitbucket per leggere il tuo quaderno.

Ho visto diverse soluzioni implementate in questo ambito. Ad esempio, è possibile utilizzare strumenti come nbconvert per generare PDF da quaderni Jupyter o esportarli come pagine HTML, in modo che possano essere facilmente condivisi con chiunque, anche al di fuori dei team tecnici.

È possibile persino spostare questi quaderni su S3 e consentire loro di essere ospitati come un sito web statico con la visualizzazione renderizzata. Si potrebbe utilizzare un flusso di lavoro CI/CD per creare e caricare una visualizzazione HTML del quaderno su S3 una volta che il codice viene unito a un determinato branch.

Proponenti di strumenti di terze parti

Questi team utilizzano strumenti che consentono non solo lo sviluppo di quaderni, ma anche la condivisione con altre persone nell’organizzazione. Ciò comporta tipicamente problematiche complesse come garantire un accesso semplice e sicuro a magazzini dati interni, data lake e database.

Alcuni degli strumenti più ampiamente adottati in questo campo sono Deepnote, Amazon SageMaker, Google Vertex AI e Azure Machine Learning. Sono tutte piattaforme complete per l’esecuzione di quaderni che consentono di creare ambienti virtuali su macchine remote per eseguire il codice. Forniscono plottaggio interattivo, esplorazione dati e sperimentazioni, semplificando l’intero ciclo di vita della scienza dei dati. Ad esempio, Sagemaker consente di visualizzare tutte le informazioni sull’esperimento che hai tracciato con Sagemaker Experiments e Deepnote offre anche una visualizzazione punto e clic con i loro Blocchi di Grafico.

Inoltre, Deepnote e SageMaker consentono di condividere il quaderno con i tuoi colleghi per visualizzarlo o persino per abilitare la collaborazione in tempo reale utilizzando lo stesso ambiente di esecuzione.

Esistono anche alternative open-source come JupyterHub, ma lo sforzo di configurazione e manutenzione necessario per farlo funzionare non ne vale la pena. Avviare un JupyterHub in sede può essere una soluzione subottimale e ha senso solo in pochissimi casi (ad esempio: tipi di carico di lavoro molto specializzati che richiedono hardware specifico). Utilizzando i servizi cloud, è possibile sfruttare economie di scala che garantiscono architetture a prova di errore molto migliori rispetto ad altre aziende che operano in settori diversi. Tuttavia, bisogna assumere i costi iniziali di configurazione, delegare la sua manutenzione a un team di operazioni della piattaforma per tenerlo in funzione per i Data Scientist e garantire sicurezza e privacy dei dati. Pertanto, fidarsi dei servizi gestiti eviterà fastidiose preoccupazioni sull’infrastruttura che è meglio non avere.

I miei consigli generali per esplorare questi prodotti: se la tua azienda sta già utilizzando un provider cloud come AWS, Google Cloud Platform o Azure, potrebbe essere una buona idea adottare la loro soluzione di notebook, in quanto l’accesso all’infrastruttura della tua azienda sarà probabilmente più facile e sembrerà meno rischioso.

Abbracciare pratiche efficaci dei notebook Jupyter

In questo articolo, abbiamo discusso delle best practice e dei consigli per ottimizzare l’utilità dei notebook Jupyter.

Il messaggio più importante:

Avvicinati sempre alla creazione di un notebook tenendo presente il pubblico di destinazione e l’obiettivo finale. In questo modo, saprai quanto focalizzarti sulle diverse dimensioni del notebook (codice, analisi, sintesi esecutiva, ecc).

Tutto sommato, incoraggio gli scienziati dei dati a utilizzare i notebook Jupyter, ma esclusivamente per rispondere a domande esplorative e per scopi di reporting.

Artefatti di produzione come modelli, set di dati o iperparametri non dovrebbero risalire ai notebook. Dovrebbero avere la loro origine in sistemi di produzione riproducibili e rieseguibili. Ad esempio, SageMaker Pipelines o Airflow DAGs che sono ben mantenuti e ampiamente testati.

Queste ultime considerazioni sulla tracciabilità, riproducibilità e genealogia saranno il punto di partenza per il prossimo articolo della mia serie su Software Patterns in Data Science and ML Engineering, che si concentrerà su come aumentare le tue competenze ETL. Spesso ignorato dagli scienziati dei dati, ritengo che padroneggiare l’ETL sia fondamentale e cruciale per garantire il successo di qualsiasi progetto di machine learning.