Dalla piattaforma di dati alla piattaforma di apprendimento automatico

Dalla piattaforma di dati alla piattaforma di apprendimento automatico un nuovo approccio tecnologico

Come evolvono le piattaforme di dati/ML e supportano le pratiche MLOps complesse

I dati/ML sono stati l’argomento più popolare nel nostro panorama tecnologico. Voglio condividere la mia comprensione delle piattaforme di dati/ML e come queste piattaforme evolvano da semplici a complesse. Infine, faccio del mio meglio per coprire MLOps, un principio per la gestione dei progetti di ML.

Riguardo a chi sono, ecco il mio LinkedIn.

Inizio del viaggio: Servizio Online + OLTP + OLAP

All’inizio, le infrastrutture dati potrebbero essere piuttosto semplici. Le query analitiche potrebbero essere inviate alla replica di lettura di un database OLTP online o potrebbe essere configurato un database OLAP che funge da magazzino dati.

Ecco come potrebbe apparire l’infrastruttura:

• Apprendimento rinforzato regolarizzato per entropia spiegato
• Top 9 Strumenti di Gestione dei Dati da Utilizzare nel 2023
• Questo articolo sull’intelligenza artificiale presenta CLIN un agente di apprendimento continuo del linguaggio che eccelle sia nell’adeguamento delle attività che nella generalizzazione a compiti e ambienti non visti in un’impostazione di assenza totale

Non c’è nulla di sbagliato in questi sistemi finché soddisfano i requisiti aziendali. Tutti i sistemi che soddisfano le nostre esigenze aziendali sono buoni sistemi. Se sono semplici, è ancora meglio.

In questa fase, ci sono più modi per effettuare l’analisi dei dati:

1. Semplicemente inviare query al nodo replica del database OLTP (non raccomandato).
2. Abilitare il CDC (Change Data Capture) del database OLTP e inserire i dati in un database OLAP. Per l’opzione di servizio di ingestione per i log CDC, puoi scegliere in base al database OLAP selezionato. Ad esempio, Flink data streaming con i connettori CDC è un modo per gestirlo. Molti servizi aziendali offrono la propria soluzione suggerita, ad esempio Snowpipe per Snowflake. È anche consigliato caricare i dati dal nodo replica per preservare la larghezza di banda CPU/IO del nodo principale per il traffico online.

In questa fase, i carichi di lavoro di ML potrebbero essere eseguiti nel tuo ambiente locale. Puoi configurare un notebook Jupyter in locale e caricare dati strutturati dal database OLAP, quindi allenare il tuo modello di ML in locale.

Le sfide potenziali di questa architettura includono, ma non si limitano a:

• È difficile gestire dati non strutturati o semi-strutturati con un database OLAP.
• OLAP potrebbe avere una regressione delle prestazioni quando si tratta di elaborazione di dati massivi. (più di TB di dati richiesti per un singolo compito ETL)
• Mancanza di supporto per diversi motori di calcolo, ad esempio Spark o Presto. La maggior parte dei motori di calcolo supporta la connessione a OLAP tramite il punto di accesso JDBC, ma l’elaborazione parallela sarà fortemente limitata dal collo di bottiglia dell’IO del punto di accesso JDBC stesso.
• Il costo di memorizzare grandi quantità di dati in un database OLAP è elevato.

Potresti già sapere la direzione per risolvere questi problemi. Crea un data lake! Introdurre un data lake non significa necessariamente dover eliminare completamente il database OLAP. È ancora comune vedere aziende che utilizzano due sistemi che coesistono per utilizzi diversi.

Data lake: Separazione di storage e calcolo + Schema on Write

Un data lake ti consente di persistere dati non strutturati e semi-strutturati e di eseguire lo schema-on-write. Ti consente di ridurre i costi memorizzando grandi volumi di dati con una soluzione di storage specializzata e creando cluster di calcolo in base alla tua domanda. Ti consente inoltre di gestire i dataset di TB/PB senza sforzo scalando i cluster di calcolo.

Ecco come potrebbe apparire la tua infrastruttura:

Si tratta di un grafico semplificato. L’implementazione effettiva di un data lake può essere molto più complicata.

Molti provider di cloud hanno soluzioni di archiviazione piuttosto consolidate per Data lake, ad esempio AWS S3 e Azure ADLS. Ci sono comunque molte attività da svolgere oltre a queste soluzioni di archiviazione. Ad esempio, dovrebbe essere presente un metastore Hive per gestire i metadati delle tabelle e un Datahub per fornire visibilità dei dati. Ci sono anche argomenti complessi come il controllo dei permessi dettagliati nel data lake e l’analisi di lineage dei dati (ad esempio spline).

Per massimizzare il valore e l’efficienza del tuo data lake, dovremmo scegliere con cura il formato del file e le dimensioni medie del file per ogni livello del tuo data lake.

I consigli generali sono:

• Evitare file piccoli: I file piccoli sono una delle principali cause di elevati costi di archiviazione e cattive prestazioni nel data lake.
• Bilanciare la latenza, il rapporto di compressione e le prestazioni: Una tabella nel data lake con bassa latenza e formato di file come Hudi potrebbe non offrirti il miglior rapporto di compressione, mentre file ORC di grandi dimensioni con alto rapporto di compressione potrebbero causarti problemi di prestazioni. Potresti voler scegliere il formato del file con saggezza in base al pattern di utilizzo della tabella, ai requisiti di latenza e alle dimensioni della tabella.

Ci sono alcuni provider SaaS/PaaS piuttosto consolidati come Databricks che offrono una soluzione decente per il data lake (o ora LakeHouse). Puoi anche esplorare ByteHouse per avere un’esperienza unificata di analisi di big data.

Nel campo dell’apprendimento automatico (ML), il team potrebbe iniziare ad esplorare framework per l’ML consolidati come TensorFlow e PyTorch in un ambiente remoto. Inoltre, i modelli di ML addestrati potrebbero essere distribuiti in un ambiente di produzione per l’infrenza di modelli online. Sia TensorFlow che PyTorch sono forniti con soluzioni di servizio, come TensorFlow Serving e PyTorch Serving.

Tuttavia, il nostro percorso non si fermerà qui. Potremmo avere le seguenti sfide ora:

• Mancanza di gestione delle metriche in tempo reale e delle caratteristiche che sono cruciali per il servizio di modelli di ML online.
• Mancanza di monitoraggio delle prestazioni del modello.

Alziamo ulteriormente il nostro livello di gioco.

Infrastruttura dati/ML in tempo reale: Data River + Data Streaming + Feature Store + Metric Server

Solitamente, la costruzione di un’infrastruttura dati in tempo reale è un impegno congiunto di più dipartimenti delle aziende. La logica iniziale di costruire un Data River di solito non riguarda i sistemi di dati/ML, ma consente alle microservizi di scalare ulteriormente rimuovendo le chiamate sincronizzate. Invece, i microservizi guadagneranno efficienza comunicando con un message broker come Kafka (a scapito di un livello di consistenza inferiore).

L’architettura complessiva potrebbe apparire così.

Con i dati disponibili in Data River (ad esempio, Kafka), possiamo costruire una pipeline di data streaming per elaborare i dati in tempo reale. Questi dati possono essere utilizzati direttamente nel feature store online o sincronizzati in un metric server come Pinot. Il metric server può elaborare/aggregare ulteriormente questi punti metrici per ottenere metriche sulle prestazioni del modello più utili e metriche aziendali. Puoi anche adottare un database di streaming come RisingWave, che può unire/aggregare dati di streaming con sintassi SQL.

Per la costruzione dello streaming dati stesso, Flink è piuttosto popolare. Puoi anche utilizzare Flink con CDC connector per estrarre dati dal database OLTP e inviarli a message broker e data lake.

Dovrebbe esserci un negozio online con una base di dati chiave-valore come ScyllaDB o AWS Dynamo DB. Il negozio online può aiutarti ad arricchire la richiesta inviata al servizio di Model Serving con un vettore di caratteristiche associato a un determinato ID di riferimento (ID utente, UUID del prodotto). Può separare notevolmente la dipendenza tra il team del servizio di backend che costruisce i microservizi e il team degli ingegneri di machine learning che costruisce i modelli di machine learning. Permette agli ingegneri di machine learning di implementare nuove funzionalità di machine learning con nuovi modelli di machine learning in modo indipendente (la firma dell’API di servizio del modello esposta ai microservizi rimarrà la stessa quando si aggiorna il vettore di caratteristiche).

Nel libro, Designing Machine Learning System, ha parlato di Model Stacking (Jen Wadkin’s VoAGI post su model stacking). È piuttosto comune che le persone utilizzino il model stacking anche nel model serving. È necessario un orchestratore quando si desidera impilare modelli eterogenei insieme, ad esempio impilare modelli pytorch e tensorflow. Puoi rendere ancora più complicato il tuo orchestratore avendo uno peso dinamico basato sulle prestazioni del modello durante l’instradamento delle richieste verso modelli diversi.

Ora abbiamo un sistema complicato. Sembra piuttosto interessante, ma porta nuove sfide:

• Il debito del sistema aumenterà considerevolmente se viene lasciato in fase di gestione.
• Un’alta carico cognitivo per gli ingegneri di machine learning.

Probabilmente è il momento in cui devi pensare a come MLOps può aiutarti.

MLOps: Astrazione, Osservabilità e Scalabilità

MLOps non è mai una soluzione specifica. È più una serie di principi per la gestione del sistema di machine learning. Diversamente da un tipico progetto software. I sistemi di machine learning sono fortemente influenzati dal cambiamento dei dati e la gestione delle dipendenze dei dati non è un compito facile. Il paper Hidden Technical Debt in Machine Learning Systems ha descritto queste sfide in dettaglio. Pertanto, una piattaforma di machine learning guidata da MLOps deve essere in grado di:

• Monitorare i cambiamenti dei dati e la qualità dei dati.
• Gestire le caratteristiche di machine learning in ambienti offline e online.
• Creare un pipeline di machine learning riproducibile che soddisfi la simmetria sperimentale-operativa.
• Configurazione concisa della pipeline di machine learning che possa astrarre i dettagli dell’infrastruttura.

Questo articolo, MLOps: Continuous delivery and automation pipelines in machine learning, ha evidenziato l’importanza della simmetria sperimentale-operativa. Ha anche descritto il livello di automazione di MLOps dal livello 0, al livello 1 infine al livello 2. Mi piace molto il grafico di questo documento e lo userò solo per spiegare come appare MLOps di livello 1.

Per implementare una pratica di MLOps di tale portata nella tua organizzazione, devi fornire una configurazione concisa della pipeline di machine learning che possa astrarre i dettagli dell’implementazione dell’infrastruttura per gli ingegneri di machine learning. In questo modo, gli ingegneri di piattaforma ottengono anche flessibilità per aggiornare la piattaforma di machine learning senza causare troppo disturbo agli utenti della piattaforma. Puoi considerare l’uso di file di configurazione come yaml per descrivere le pipeline di machine learning e fare affidamento sui tuoi controller di pipeline di machine learning per tradurli in carichi di lavoro effettivi.

Quindi organizziamo i dati in tempo reale/infrastruttura di ML con il seguente grafico per evidenziare come MLOps modella le nostre piattaforme.

Per darti un’idea migliore di come potrebbero apparire le pipeline di ML, ecco alcuni esempi di astrazione per ogni fase della pipeline di ML. Il seguente grafico ti aiuterà solo a comprendere meglio quale potrebbe essere la configurazione. Non rappresenta alcuna implementazione effettiva. Non copre tutti gli aspetti richiesti.

Kubernetes è una soluzione popolare per orchestrare il carico di lavoro di ML (o forse tutto il carico di lavoro al giorno d’oggi). Puoi usare CRD per fornire interfacce concise tra gli utenti e le piattaforme. Nell’articolo My thinking of Kubebuilder, ho condiviso alcuni dei miei pensieri quando costruisco CRD con kubebuilder.

Ovviamente, non ho coperto molti importanti sotto-argomenti che includono, ma non sono limitati a:

• ottimizzazione degli iperparametri
• architettura di addestramento distribuito

Cosa viene dopo

Puoi vedere che MLOps dà solo un nome appropriato a una missione conosciuta. È ancora lontano dall’essere un lavoro finito. Quello che ho condiviso è una strategia opinabile per implementare una piattaforma ML Ops. Anche con questo, la qualità nella creazione di prodotti di ML è ancora alta e l’effort nella raccolta, elaborazione, estrazione di dati è ancora considerevole.

Oltre a queste sfide rimanenti, voglio anche condividere le tendenze nel panorama di ML che ho osservato. Certamente non è una lista completa dato quanto velocemente evolva questo settore.

• “Senza servizio”: abbiamo messo troppo in secondo piano il valore di ML perché la base di una piattaforma di ML di solito è una piattaforma di dati. È come obbligare gli utenti a comprare computer per partecipare ai social media quando siamo già nell’era dei dispositivi mobili. I servizi dati senza server e i cluster di calcolo stanno affrontando questa sfida. Molti fornitori di servizi esplorano la propria soluzione senza server per abbassare la soglia di adozione, ad esempio Databricks, Snowflake, Bytehouse. Le aziende possono iniziare a costruire i loro prodotti di ML dopo aver creando archivi dati, o laghi di dati, o magazzini di dati.
• Ingegneria delle caratteristiche basata su AI: Beh, l’AI può fare tutto adesso, no?
• Tendenze MaaS: Spunteranno modelli-as-a-service più potenti. Le aziende possono sfruttare direttamente il potere di ML senza neanche dover costruire il proprio servizio di ML per ottenere un grande impulso al loro business.

Come tutti abbiamo notato, lo spazio di ML evolve così velocemente. In questo stesso momento, mentre scrivo, questo articolo potrebbe già essere superato. Già molte idee sono state proposte e tradotte in realtà. Per favore, fammi sapere cosa ne pensi di ML Ops, o su cosa dovrei focalizzarmi per approfondire la mia conoscenza. Continuiamo il passo insieme!