Traduci i dati tra strutture di dati con corrispondenza incoerente

What patterns can I follow to represent the mostly-correlated but imperfectly-aligned data structures, such that the translation describes all the mapping complexity and all we need do then is connect the systems at each end?

Questa domanda riassuntiva suggerisce che potrebbe esserci qualche tipo di schema o procedura da seguire che sarà semplice, completa e ovviamente corretta. Sfortunatamente, non c'è.

Considera le "molte incongruenze" che hai menzionato o le "correlazioni che abbiamo scoperto ." Non conosci l'intera serie di mappature appropriate. Per esperienza probabilmente ne conosci molte - ma non tutte, e non c'è garanzia che una nuova non emergerà domani. O che una trasformazione che ritenevi solida e affidabile si rivelerebbe errata in alcune circostanze da scoprire. Rudi risvegli sono un fatto inevitabile della vita sulla frontiera ETL .

Quindi, come andare avanti?

• suggerimento di Bogdan sull'uso di un insieme di routine strutturate from_X_to_Y e probabilmente una libreria di pipeline di trasformazione è buona. Con o senza una libreria di oggetti mapper per aiutarti, dovrai inevitabilmente farlo se le strutture non corrispondono in molti punti e devi scrivere molti convertitori personalizzati per le differenze. Questi aiutano a strutturare il lavoro del tuo trasformatore.

• Strumentazione : essere in grado di trovare cosa è andato storto, dove e per quali ragioni è inestimabile. Metti le tue trasformazioni in asserzioni. Se ritieni che certe condizioni siano valide, chiedi al codice di confermare tali ipotesi. Le asserzioni diventano tripwap per identificare i problemi che non conoscevi, e farlo prima che causi problemi più grandi.

• Un carrello-arresto : un meccanismo di prima classe per studiare e rielaborazione dei casi di errore che emergono. Quando la trasformazione fallisce, disporre del codice e degli strumenti pronti per la stampa e descrivere i casi di errore in modo chiaro e facilmente leggibile. Aspettatevi errori e rendeteli più facili da studiare (uno per uno, non solo come pochi record tra milioni nel mezzo di una discarica completa dei dati). I piloti dicono "piano di schiantarsi". Non perché vogliono andare in crash, ma perché se le cose vanno male, vogliono pensare a strategie di mitigazione molto prima che scoppino le emergenze. Questo principio si applica qui.

• Gestisci per eccezione. Nei progetti ETL "dirty data" - più o meno tutti su scala - è super-utile avere un'abilità "messa da parte". Se elabori un milione di record e trovi 13 casi di errore, è molto meglio so essere in grado di inviare i 999.987 successi, mettendo da parte alcuni bambini problematici per lo studio e la bonifica "fuori banda". Se devi correggere i 13 errori prima che i eventuali record vengano inviati correttamente, ora hai un enorme collo di bottiglia potenziale. Quanto ci vorrà per capire quei casi brutti? Un'ora? Un giorno? Una settimana? Avendo affrontato tutti questi scenari di ritardo, ti dirò che non essere in grado di inviare il lavoro che conosci è buono a causa di alcuni anomali è terribile , specialmente quando tieni personalmente responsabile della processi. Anche dover setacciare i record 1M per trovare la dozzina di errori di un fornaio è terribile. Quindi fai un favore a te stesso ed esegui un processo che presuppone l'insorgere di errori, che mette tranquillamente quelli in disparte e continua con le presentazioni principali. I set-set non sono sempre fattibili nei sistemi di produzione che si aspettano invii atomici, ma se possibile, li usano. In ogni caso, prendi gli errori nell'attrezzatura di studio, individuali, aggiorna il codice e itera la procedura di invio.

• Notifiche in corso e processo in corso. Non menzioni la tua situazione operativa, ma dopo che le trasformazioni sono state "fatte" e in servizio, possono ancora verificarsi errori ed omissioni. Speriamo che le tue affermazioni possano aiutarti a trovarli, ma alcuni potrebbero passare alla presentazione dei dati di produzione. In ogni caso, è possibile impostare notifiche automatiche di problemi a voi o allo staff di sviluppo. Questo può essere semplice come e-mail o testi automatici. Ma hai bisogno di un modo per coinvolgere in modo efficiente coloro che riescono a indagare e "risolvere" i casi problematici in modo appropriato. Automatizzare questo può ridurre enormemente la frustrazione, sia per te che per le persone che altrimenti si lamenteranno "Sì. Devo dire agli sviluppatori che il loro codice è fallito. AGAIN ." Convertendolo in un processo in cui sono consapevoli che la trasformazione non è euristica perfetta e dove lo sviluppo sembra essere sempre al di sopra degli aggiornamenti necessari - non è un componente di per sé della tecnologia, ma sarà rendere il processo complessivo più fluido.

In Java esiste un progetto chiamato Dozer che gestisce tali casi. Hai un file XML in cui dichiari ciò che nella sorgente corrisponde a ciò che nella destinazione e Dozer fa il lavoro. Gestisce le conversioni tra i tipi di dati, se i tipi hanno gli stessi campi non è necessario specificare nulla li abbina semplicemente per nome, se hai bisogno di una conversione personalizzata puoi farlo anche tu, ecc.

Potrebbe esserci qualcosa di simile in Python. Una rapida ricerca su Google mi ha trovato questo: link . Potrebbero essercene altri. Potrebbero supportare ciò di cui hai bisogno o farti parte del percorso.

Ma il mio consiglio sarebbe di creare una classe utils con funzioni al suo interno del modulo:

def from_<TypeX>_to_<TypeY>(x):
    y = TypeY()
    # ... read x and do the mapping here to y
    return y

per mappare tra le strutture di dati. Con o senza una libreria di oggetti mapper per aiutarti, dovrai inevitabilmente farlo se le strutture non corrispondono in molti punti e devi scrivere molti convertitori personalizzati per le differenze.