Tulip: modernizzazione della piattaforma dati di Meta

Le migrazioni sono difficili. Inoltre, diventano molto più difficili a Meta a causa di:

Prima di entrare nei dettagli della storia della migrazione, vorremmo fare un passo indietro e provare a spiegare la motivazione e la logica di questa migrazione.

Nel corso del tempo, la piattaforma dati si è trasformata in varie forme man mano che le esigenze dell'azienda crescevano. Quella che all’inizio era una piattaforma dati modesta è diventata una piattaforma su scala exabyte. Alcuni sistemi che servivano su scala più piccola iniziarono a mostrare segni di insufficienza per le crescenti richieste che venivano loro poste. In particolare, ci siamo imbattuti in alcuni problemi concreti di affidabilità ed efficienza legati alla (de)serializzazione dei dati, che ci hanno portato a ripensare il modo in cui registriamo i dati e a rivisitare le idee dei principi primi per affrontare questi problemi urgenti.

Logger è il cuore della piattaforma dati. Il sistema viene utilizzato per registrare dati analitici e operativi su pipeline di elaborazione Scuba, Hive e streaming tramite Scribe. Ogni team del prodotto e della piattaforma dati interagisce con la registrazione. Il formato dei dati per la registrazione era Hive Text Delimited o JSON, per motivi legacy. Le limitazioni di questi formati sono descritte nel nostro precedente articolo su Tulip.

Per risolvere queste limitazioni, è stato sviluppato il formato di serializzazione Tulip per sostituire i formati di serializzazione legacy specifici della destinazione.

I grafici seguenti rappresentano graficamente il percorso di migrazione per la conversione del formato di serializzazione in Tulip per mostrare i progressi nelle varie fasi e tappe fondamentali.

Possiamo vedere che mentre il numero di schemi di registrazione è rimasto più o meno lo stesso (o ha registrato una crescita organica), i byte registrati hanno registrato una diminuzione significativa a causa del cambiamento nel formato di serializzazione. I dettagli relativi al risparmio di byte specifici del formato sono tabulati nella sezione seguente.

Nota: i numeri nel grafico 2 sono estrapolati (al traffico complessivo) in base ai risparmi effettivi osservati per i cinque schemi di registrazione più grandi (in volume).

Vorremmo presentare il nostro viaggio migratorio come due fasi distinte con le rispettive prospettive.

Progettare il sistema tenendo presente la migrazione aiuta a rendere la migrazione molto più semplice. Le seguenti soluzioni ingegneristiche sono state sviluppate per garantire che il team fosse dotato degli strumenti necessari e del supporto infrastrutturale per cambiare il formato wire in modo sicuro ed eseguire il debug dei problemi che potrebbero sorgere durante la fase di migrazione in modo scalabile.

Le soluzioni rientravano grosso modo nei seguenti secchi:

Sfida: come si può facilitare la migrazione e ridurre i rischi evitando di richiedere ai produttori e ai consumatori di dati di cambiare atomicamente i formati di serializzazione?

Soluzione: durante l'inversione di un singolo schema di registrazione per utilizzare il nuovo protocollo di serializzazione Tulip per scrivere i payload, era necessario supportare i payload in modalità mista su un singolo flusso di scriba poiché sarebbe stato impossibile commutare "atomicamente" tutti i produttori di dati per utilizzare il nuovo formato . Ciò ha inoltre consentito al team di limitare la velocità di implementazione della serializzazione del nuovo formato.

Il formato del cavo in modalità mista era importante per supportare il concetto degli shadow logger, che venivano ampiamente utilizzati per i test di accettazione end-to-end prima di un'implementazione su larga scala.

La sfida principale per il formato wire in modalità mista era non riuscire a modificare la serializzazione esistente dei payload in formato Hive Text o JSON. Per aggirare questa limitazione, ogni payload serializzato Tulip ha il prefisso con la sequenza di 2 byte 0x80 0x00, che è una sequenza utf-8 non valida.

La sfida: in alcuni sistemi, il formato di serializzazione Hive Text (o JSON) si è insinuato nel codice dell'applicazione che ha finito per fare affidamento su questo formato per il consumo di payload. Questo è il risultato del fatto che i consumatori superano l’astrazione del formato di serializzazione.

Soluzione: due soluzioni hanno affrontato questa sfida.

Lettore (controparte del logger per la deserializzazione dei dati)

Reader è una libreria che converte un payload serializzato in un oggetto strutturato. Il lettore (come il logger) è disponibile in due versioni, (a) codice generato e (b) generico. Un oggetto lettore consuma dati in uno qualsiasi dei tre formati (Tulip, Hive Text o JSON) e produce un oggetto strutturato. Ciò ha consentito al team di passare dai consumatori ai lettori prima dell'inizio della migrazione. Il codice dell'applicazione doveva essere aggiornato per consumare questo oggetto strutturato invece di una riga serializzata grezza. Ciò ha allontanato il formato wire dai consumatori dei dati.