Molti clienti hanno già pipeline di dati che funzionano bene. La sfida è trovare un modo per eseguirle dove i dati devono rimanere, o abbastanza vicini alla loro fonte affinché l'applicazione possa rispondere rapidamente. Alcuni casi d'uso hanno requisiti di residenza dei dati che limitano i dati grezzi a non uscire dal confine di sicurezza del cliente. Altri beneficiano dell'elaborazione locale per ridurre i ritardi di trasferimento dei dati.
L'architettura proposta porta pipeline ETL esistenti e workflow MLOps su infrastruttura Oracle presso il sito del cliente. Oracle Autonomous AI Database (ADB) supporta la pianificazione e l'accesso ai risultati pubblicati. La pipeline stessa viene eseguita nell'ambiente di esecuzione locale. In questo design, gli input grezzi e l'elaborazione intermedia rimangono locali, mentre una politica di pubblicazione definita dal cliente governa ciò che viene inviato ai servizi cloud.
Contesto
Una pipeline operativa tipica inizia leggendo, pulendo e aggregando i dati di origine. Le fasi successive possono preparare le caratteristiche, addestrare i modelli, generare previsioni e rilevare anomalie. I team operativi utilizzano questi output attraverso dashboard e applicazioni per comprendere cosa sta accadendo e decidere dove agire.
Queste fasi utilizzano l'infrastruttura in modi diversi. L'ETL può essere molto pesante su CPU, memoria e larghezza di banda di archiviazione. L'elaborazione del modello può utilizzare una GPU, mentre la combinazione di previsioni e l'applicazione di regole di rilevamento riporta il lavoro alla CPU. Abbinare le risorse a queste fasi ci dà la possibilità di migliorare il modo in cui viene eseguita la pipeline.
Dove viene eseguita la pipeline è altrettanto importante. Se i dati grezzi non possono lasciare il confine del cliente, l'elaborazione deve avvenire lì. Se l'applicazione necessita di una risposta rapida, posizionare l'ETL vicino alla generazione dei dati può ridurre il ritardo di trasferimento degli input grezzi a un ambiente remoto. Questo può aiutare le applicazioni che supportano operazioni mission-critical e decisioni in tempo reale.
Entrambi i motivi possono rendere utile l'elaborazione locale. L'ottimizzazione aiuta quindi la pipeline a funzionare in modo più efficiente in quell'ambiente. La risposta complessiva dell'applicazione include anche come arrivano i dati, quando inizia l'elaborazione e come viene utilizzato il risultato.
Oracle Roving Edge Infrastructure e Oracle Compute Cloud@Customer offrono modi per portare i servizi di calcolo e archiviazione Oracle presso il sito del cliente. Quale opzione si adatta dipenderà dal carico di lavoro, dalla capacità, dalla configurazione supportata e dal modo in cui si prevede di operare. Sono opzioni di distribuzione in questa architettura. Le osservazioni riportate di seguito non stabiliscono le prestazioni per una specifica generazione di RED o configurazione di Compute Cloud@Customer.
Architettura tecnica
La figura 1 mostra le due parti del design. Nel data center del cliente, l'archiviazione locale contiene input grezzi, dataset intermedi e artefatti del modello, e un motore di esecuzione esegue la pipeline. In una regione di Oracle Cloud Infrastructure (OCI), tabelle di soluzione in ADB contengono metadati della pipeline consentiti e cronologia delle esecuzioni. Selezionati output passano attraverso un passaggio di pubblicazione a OCI Object Storage per l'accesso di ADB.
La figura 1 mostra tre idee chiave:
- Esecuzione locale: archiviazione, ETL, MLOps e il motore di esecuzione condividono l'ambiente del cliente. Il design colloca l'elaborazione dei dati grezzi all'interno di quell'ambiente e vicino alla sua fonte.
- Automazione supportata dal database: i componenti della soluzione utilizzano Oracle APEX e ADB per gestire definizioni, programmi e cronologia delle esecuzioni. Un servizio locale personalizzato riceve richieste e segnala progresso e completamento.
- Pubblicazione controllata: un componente separato della soluzione seleziona gli output per l'accesso cloud. La politica del cliente si applica ai dati derivati e agli artefatti del modello oltre che agli input grezzi, ai log e ai metadati di esecuzione.
Il confine mostrato è una proprietà del design di distribuzione, piuttosto che una garanzia automatica di un prodotto. Prima di abilitare un percorso cloud, è necessario rivedere il contenuto delle definizioni della pipeline, dei payload delle richieste, della cronologia delle esecuzioni, dei file di log, dei file di output e degli artefatti del modello. Ogni elemento necessita di una decisione esplicita se può uscire dall'ambiente del cliente. I dati derivati sono soggetti alla stessa revisione.
Il passaggio di pubblicazione scrive solo gli output selezionati dalla politica su OCI Object Storage. ADB può caricare dataset supportati o interrogare file supportati tramite tabelle esterne, fornendo ai consumatori uno strato di accesso SQL comune. Se i risultati derivati devono rimanere anche in sede, questo percorso di pubblicazione cloud non è adatto per quei risultati e necessita di un'alternativa localmente consentita.
Dashboard e applicazioni di business intelligence (BI) possono utilizzare i risultati pubblicati. Le query assistite da AI sono un'integrazione a valle possibile, piuttosto che una funzione testata descritta qui. Qualsiasi integrazione del genere necessita della propria revisione del servizio del modello e del flusso di dati, inclusi prompt, contesto di query e risultati inviati a un endpoint di modello esterno. Il diagramma non implica che l'inferenza del modello venga eseguita localmente o esclusivamente all'interno di ADB.
Per un'applicazione che necessita di una risposta rapida, dobbiamo anche guardare oltre il passaggio di elaborazione locale. Pianificazione, pubblicazione e accesso al database possono aggiungere tempo ovunque l'applicazione li utilizzi. Testare quel percorso completo ci aiuta a vedere se il design è abbastanza veloce per il caso d'uso.
Automatizzare la pipeline con ADB
Una volta che la pipeline viene eseguita localmente, il passo successivo è collegarla alla pianificazione e al tracciamento delle esecuzioni. Oracle Scheduler fornisce il meccanismo di lavoro del database. La soluzione fornisce le definizioni della pipeline, la cronologia delle esecuzioni dell'applicazione, l'API di esecuzione locale, il rilevamento di riavvio e la logica di pubblicazione. Questi componenti formano un'integrazione personalizzata intorno ad ADB; non sono un servizio di orchestrazione delle pipeline integrato in ADB.
Un'esecuzione segue il flusso mostrato nella figura 1:
- Un utente definisce una pipeline nell'applicazione della soluzione e la avvia manualmente o tramite un lavoro di Oracle Scheduler.
- Il codice della soluzione invia una richiesta consentita che identifica la pipeline e la finestra di elaborazione al servizio di esecuzione locale.
- Il motore locale esegue ETL o MLOps contro l'archiviazione locale e restituisce lo stato. Il servizio utilizza un'identità di richiesta per rilevare i riavvi e evitare lavori duplicati.
- Il componente di pubblicazione seleziona gli output consentiti e li scrive su OCI Object Storage. ADB fornisce quindi l'accesso tramite il metodo di caricamento o tabella esterna scelto.
Oracle documenta DBMSSCHEDULER.CREATEJOB per la creazione di lavori del database. Un lavoro può invocare una procedura PL/SQL di proprietà della soluzione che invia una richiesta di esecuzione e registra il suo esito. Questo descrive un modello di implementazione supportato; non implica che Scheduler esegua direttamente la pipeline locale.
La connettività è un prerequisito. Per un servizio di esecuzione privato on-premises, il target necessita di una connessione sicura e affidabile con ADB. Questo può essere raggiunto tramite una VPN o un circuito dedicato, a seconda delle esigenze di sicurezza e delle politiche del cliente.