Diseño del sistema: Importaciones de CSV muy grandes cada mes

7

Tenemos una aplicación web que se basará en CSV grandes de proveedores externos cada mes. Cuando digo en voz alta, estamos mirando alrededor de 6 GB, por lo que unos pocos millones de filas. Probablemente, 2-5 CSVs. Esta aplicación web también permitirá a los usuarios ingresar, corregir y marcar / eliminar datos. El número de columnas y la limpieza de los datos no están garantizados desde la perspectiva del proveedor. Además, los datos pueden superponerse (no podemos mostrar datos superpuestos en nuestra aplicación web).

He estado pensando en varias formas de abordar esto:

  1. Cargue estos CSV en una tabla por CSV que coincida con los encabezados de columna y luego creamos "vistas" de lo que necesitamos.

Esta solución parece ser la más fácil de implementar y mantener, ya que solo podemos importar el CSV cada mes a las tablas de CSV y las cosas simplemente funcionan. Parece el menos eficiente y tendría la mayoría de los problemas con la integridad de los datos. Además, las vistas serían hella complejas.

  1. Cargue estos CSV en nuestro propio esquema cada mes y cree nuestra aplicación web a partir de nuestro propio esquema.

Esta solución parece más difícil de implementar y mantener porque cuando la importación se realiza todos los meses, tendrá que ejecutar su importación y esto podría romper sus datos existentes. Sería lo mejor que su aplicación web sea su propio esquema y simplemente puede "asignarlo". Además, los CSV contendrán datos que invalidan los datos antiguos, por lo que será difícil actualizarlos. Si fuera por esta ruta, ¿haría la importación en Java / C # o SQL? Parece que Java / C # tendría sentido para que podamos procesar nuestras reglas de negocios pero es más lento ...

  1. Cargue CSV en una tabla por CSV y simplemente ejecute consultas SQL para que la aplicación web cree modelos que coincidan con lo que necesita la aplicación.

Esta solución se encuentra con el mismo problema que la solución de vista, excepto que ahora sus consultas SQL son muy complejas y tiene el dolor de cabeza de mantenerlas. Si el proveedor externo cambia el esquema, se podrían interrumpir las consultas de SQL, aunque podría cambiar el CSV antes de importar para que coincida con su importador.

Entonces tenemos estas preguntas:

  1. Si un usuario actualiza una fila en la que se llenó el CSV, digamos que vamos con el número 2, que es a lo que me estoy inclinando, ¿cómo preservamos esa actualización cuando ingresan los CSV?

    1. ¿Cómo podemos revertir una importación CSV? ¿Qué pasaría si pensáramos que la importación de CSV fue buena durante 1 mes y ahora tenemos una tonelada de datos generados por el usuario a ese CSV?

Parece que no hay una solución trivial y de cualquier manera tengo que "tomarla". ¿Me estoy perdiendo algo? ¿Alguien puede encontrar o pensar en una solución trivial?

    
pregunta user2370642 04.03.2018 - 22:19

3 respuestas

7

"CSV" no es la palabra correcta para lo que te entregan. Es el formato en el que se lo entregan, y con garantías muy débiles. La mayoría de las personas se refieren a un archivo CSV de 6 GB con datos no confiables y faltantes simplemente como "los datos", y creo que eso es más preciso aquí. Tiene un proveedor que pone a su disposición algunos datos y usted es responsable de proporcionarlos a sus clientes de alguna manera.

  

Cargue estos CSV en nuestro propio esquema cada mes y cree nuestra aplicación web a partir de nuestro propio esquema.

Esto se ve mejor. Está aplicando la lógica empresarial a los datos suministrados para mantener su integridad y rendimiento. Su proveedor le ofrece garantías muy débiles y usted ofrece a sus clientes garantías sólidas. El formato que te dan es una cadena larga. En cualquier entrevista técnica, si piden construir un acceso persistente a una cadena larga, la respuesta es preprocesarlo, que es lo que esta propuesta tuya.

Debes asumir que tus usuarios pedirán más funciones sobre cómo interactuar con los datos. Tal vez quieran un botón de deshacer o un registro de auditoría, los cuales requieren que tengas tus propios datos (metadatos).

Contraste esto con un caso en el que ponen los datos a tu disposición en un formato limpio o funcional, p. ej. una base de datos Entonces, tomaría la misma decisión de ser propietario de los datos o utilizar su formato, solo que ahora su formato tiene garantías mucho más sólidas.

  

Entonces tenemos estas preguntas:

Esas son preguntas buenas y difíciles, y como dije, parece que su compañía está en el negocio de resolverlas para sus usuarios, y sí, estos casos de uso sin duda fomentan el uso de su propio esquema.

Fuera de mi cabeza, esto parece un problema de control de versión, así que investigue algo como "control de versión de datos grandes". Un hit de Google: enlace

    
respondido por el djechlin 04.03.2018 - 22:22
3

Esto depende en gran medida de los requisitos, lo que "ingresar, corregir y marcar / eliminar datos" significa exactamente, y sus requisitos adicionales para el preprocesamiento y el posprocesamiento. ¿Se realiza la edición por fila? ¿Cada fila en su totalidad, o hay bloques en esa fila que no necesitan ser procesados? ¿Completamente manual, o también hay algunos pasos de limpieza / preprocesamiento automáticos? ¿Cómo se detecta la "superposición"? Debe haber algún criterio para detectar la identidad de una fila.

Tampoco mencionó lo que viene después en su flujo de datos. Supongo que corregir los datos no es un fin en sí mismo, por lo que también hay que considerar qué sucede después de que se realizó la edición: ¿es necesario volver a escribir los datos en archivos CSV, utilizando el formato original? ¿Será almacenado / archivado en alguna parte? ¿O se procesarán los datos de una manera completamente diferente?

Entonces, una vez que haya cumplido estos requisitos generales, debe crear un modelo de datos / esquema que admita exactamente los pasos de edición y procesamiento que necesita, no menos, ni más . Esto puede ser hasta cierto punto su enfoque # 2, pero

  • ya que mencionó que mezclar los datos de diferentes meses como un problema, integrarlos no es un requisito, así que mantenga los datos separados por mes. Tenga una tabla maestra Datapool con una clave principal "fecha" o "mes", tal vez el nombre del archivo CSV como un atributo único, y cree las otras tablas como tablas de detalles de la tabla maestra

  • modele solo la parte de los datos que sus usuarios y procesos realmente necesitan mostrar y editar; Los datos restantes se pueden guardar, por ejemplo, en una columna de cadena. No invierta tiempo en modelar detalles cuando aún no sabe (si todavía) si alguna vez los necesitará.

  • asegúrese de que puede admitir todos los pasos posteriores. Conocer esos requisitos debería ayudarlo a decidir qué datos deben conservarse y cuáles pueden ignorarse.

Al crear el modelo de datos, tenga en cuenta que los datos probablemente no sean de la calidad que le gustaría tener. Por ejemplo, puede que no sea posible tener todas las restricciones "únicas" para cada atributo que debería ser único después de la edición.

    
respondido por el Doc Brown 05.03.2018 - 14:06
1

Una solución que adoptamos fue crear mapeos. La herramienta tomaría las primeras n filas de datos omitiendo cualquier cosa que pareciera repetitivo para que la persona que maneja la importación pueda ver una muestra de los datos y los encabezados de las filas para controlar la asignación.

El esquema "CSV" fue controlado por la fila del encabezado si está disponible y el número de columnas. Teníamos una manera de asignar los datos del esquema CSV al esquema de la aplicación. Encontramos un par de cosas que necesitábamos un manejo especial para:

  • Valores predeterminados para las columnas requeridas (tuvimos casos en los que los datos se conocían, pero no se proporcionaron porque eran los mismos para todos los registros)
  • Reconocimiento de formato de fecha personalizado (nota: cuando sus muestras de fecha incluyen 1/2/2018 y 1/3/2018, puede ser difícil detectar cuál es el mes y cuál es el día)

Hay más, estoy seguro, pero me han quitado un par de años de trabajar en ese proyecto.

Esta asignación se almacenó en la base de datos para que podamos buscarla en base a la firma del encabezado para futuros volcados de datos. Ayudó mucho con el manejo del formato de los datos.

El procesamiento consistió en leer datos y escribir en la base de datos en fragmentos. Eso significaba leer en 100 filas aproximadamente, prepararlas en una colección para que pudiéramos eliminar el ruido un poco más fácilmente y luego escribirlas en esa parte. Acelera la importación de datos al escribir en la base de datos sin necesidad de tener todo en la memoria a la vez.

Todos los errores se escribieron en un CSV guardado en el registro de la base de datos que hacía referencia al archivo para que pudiéramos descubrir qué era lo que estaba mal en nuestra asignación (es decir, se invirtieron el mes y el día, o se llenó una columna obligatoria). El CSV tenía el número de línea, el error específico, los datos que causaron el problema y la columna de destino esperada.

El problema más difícil para usted es detectar datos duplicados. Mientras tenga consultas / búsquedas eficientes para el almacén de datos de su aplicación, tiene un par de opciones:

  • Escriba la entrada en bruto en un área preparada, luego post-proceso como un paso separado
  • Consulte la base de datos a medida que avanza.

La compensación es que, en términos de preparar los datos en un esquema conocido, la primera opción va a ingerir los datos mucho más rápidamente. Permitiéndole clasificar la asignación antes de que esté realmente lista para el consumo. La segunda opción tendrá sus datos listos en una sola pasada, pero puede demorar hasta 10 veces el tiempo de procesamiento.

    
respondido por el Berin Loritsch 05.03.2018 - 15:19

Lea otras preguntas en las etiquetas