Progettazione del sistema: Importazioni CSV molto grandi ogni mese

"CSV" non è la parola giusta per ciò che ti consegna. È il formato che ti consegna e con garanzie molto deboli. La maggior parte delle persone fa riferimento a un file CSV da 6 GB con dati inaffidabili e mancanti semplicemente come "i dati" e ritengo che sia più accurato qui. Hai un fornitore che ti mette a disposizione alcuni dati e sei responsabile di servirlo in qualche modo ai tuoi clienti.

Load these CSVs into our own schema each month and build our webapp off of our own schema.

Questo sembra il migliore Stai applicando la logica aziendale ai dati forniti per mantenerne l'integrità e le prestazioni. Il tuo fornitore ti offre garanzie molto deboli e offri ai tuoi clienti forti garanzie. Il formato che ti danno è una lunga stringa. In qualsiasi intervista tecnologica, se chiedono di creare un accesso persistente a una stringa lunga, la risposta è di pre-elaborarla, che è ciò che questa tua proposta è.

Dovresti dare per scontato che i tuoi utenti chiederanno ulteriori funzionalità su come interfacciare i dati. Forse vogliono un pulsante di annullamento o un registro di controllo, che richiedono entrambi di avere i propri dati (meta) proprietari.

Confrontalo con un caso in cui mettono a disposizione i dati in un formato pulito o funzionale, ad es. un database. Quindi dovresti prendere la stessa decisione sul possesso dei dati o utilizzare il loro formato, solo ora il loro formato ha garanzie molto più forti.

Then we have these questions:

Queste sono domande buone e difficili, e come ho detto sembra che la tua azienda stia nel business di risolverli per i tuoi utenti, e sì, questi casi d'uso sicuramente incoraggiano l'uso del tuo schema.

In cima alla mia testa, questo sembra un problema di controllo della versione, quindi ricerca qualcosa come "versione controllo di grandi quantità di dati". Un hit di Google: link

Questo dipende in larga misura dai requisiti, ciò che "inserisci, correggi e contrassegna / cancella i dati" significa esattamente, e i tuoi ulteriori requisiti per la preelaborazione e la postelaborazione. La modifica è eseguita su una base per riga? Ogni riga per intero o ci sono blocchi in quella riga che non devono essere elaborati? Completamente manuale o ci sono anche alcuni passaggi di pulizia / pre-elaborazione automatici? Come viene rilevata la "sovrapposizione"? Ci deve essere qualche criterio per rilevare l'identità di una riga.

Inoltre, non hai specificato cosa verrà dopo nel tuo flusso di dati. Immagino che correggere i dati non sia fine a se stesso, quindi c'è anche da considerare cosa succede dopo che il montaggio è stato fatto: c'è un obbligo di riscrivere i dati nuovamente nei file CSV, usando il formato originale? Sarà archiviato / archiviato da qualche parte? O i dati saranno elaborati in un modo completamente diverso?

Quindi, una volta soddisfatti questi requisiti generali, dovresti creare un modello / schema dati che supporti esattamente i passaggi di modifica ed elaborazione necessari, non meno, non più . Questo potrebbe essere in qualche modo il tuo approccio # 2, ma

• dato che hai accennato a confondere i dati di diversi mesi come un problema, integrarli non è un requisito, quindi tieni i dati separati al mese. Avere una tabella master Datapool con una chiave primaria "date" o "month", forse il nome del file CSV come attributo univoco e creare le altre tabelle come tabelle di dettaglio della tabella master

• modella solo la parte dei dati che gli utenti e i processi devono realmente visualizzare e modificare; i dati rimanenti possono essere mantenuti, ad esempio, in una colonna di stringhe. Non investire tempo nella modellazione dei dettagli quando non sai (ancora) se ne avrai mai bisogno.

• assicurati di poter supportare tutti i passaggi successivi. Conoscere questi requisiti dovrebbe aiutarti a decidere quali dati devono essere conservati e quali possono essere ignorati.

Durante la creazione del modello di dati, tieni presente che i dati probabilmente non sono della qualità che ti piace averlo. Ad esempio, potrebbe non essere possibile avere tutti i vincoli "univoci" sul posto per ogni attributo che dovrebbe essere unico dopo la modifica.

Una soluzione che abbiamo adottato è stata la creazione di mapping. Lo strumento catturerebbe le prime n righe di dati saltando tutto ciò che sembrava hotplan in modo che la persona che gestiva l'importazione sarebbe in grado di vedere un campionamento dei dati e le intestazioni delle righe per controllare la mappatura. / p>

Lo schema "CSV" era guidato dalla riga di intestazione se disponibile e dal numero di colonne. Abbiamo avuto modo di mappare i dati dallo schema CSV allo schema dell'applicazione. Abbiamo incontrato un paio di cose di cui avevamo bisogno per una gestione speciale:

• Valori predefiniti per le colonne richieste (abbiamo avuto casi in cui i dati erano noti, ma non forniti poiché era lo stesso per tutti i record)
• Riconoscimento del formato della data personalizzato (nota: quando i campioni della data includono 1/2/2018 e 1/3/2018 può essere difficile individuare quale sia il mese e qual è il giorno)

Ce ne sono ancora di più, ma mi mancano due anni per lavorare su quel progetto.

Questa mappatura è stata archiviata nel database in modo da poterla consultare in base alla firma dell'intestazione per i futuri dump di dati. Ha aiutato molto con la gestione della formattazione dei dati.

L'elaborazione consisteva nella lettura dei dati e nella scrittura nel database in blocchi. Ciò significava leggere 100 righe circa, prepararle in una raccolta in modo da eliminare il rumore un po 'più facilmente e quindi scriverle in quel blocco. Accelera l'importazione dei dati durante la scrittura nel database senza bisogno di avere tutto in memoria in una volta.

Tutti gli errori sono stati scritti in un CSV contenuto nel record del database che ha fatto riferimento al file in modo da poter capire cosa c'era di sbagliato nella nostra mappatura (cioè il mese e il giorno sono stati invertiti, o la colonna richiesta è stata riempita scarsamente). Il CSV aveva il numero di riga, l'errore specifico, i dati che hanno causato il problema e la colonna di destinazione prevista.

Il problema più difficile per te è il rilevamento di dati duplicati. Se hai query efficienti o cerchi l'archivio dati della tua applicazione, hai un paio di opzioni:

• Scrivi l'input non elaborato in un'area preparata, quindi post-elaborazione come passaggio separato
• Esegui una query sul database mentre prosegui.

Il compromesso è che in termini di preparazione dei dati in uno schema conosciuto, la prima opzione è quella di ingerire i dati molto più rapidamente. Consentendo di triage la mappatura prima che sia effettivamente pronta per il consumo. La seconda opzione avrà i tuoi dati pronti in un unico passaggio, ma può richiedere fino a 10 volte il tempo di elaborazione.