Exportar resultados a un data warehouse

Una integración puede funcionar bien y aun así alimentar un tablero equivocado. Entre la respuesta de la API y el gráfico que mira un responsable de flota hay una copia: filas cargadas en un almacén analítico, con esquema, frecuencia y criterios propios. Deja de estar cubierta por el contrato de la API apenas se escribe.

Exportar no es mover bytes. Es decidir qué se conserva, cada cuánto, bajo qué clave y qué pasa cuando la fuente corrige algo que ya viajó. Sin esas decisiones, el destino acumula duplicados, versiones viejas conviviendo con las nuevas y silencios que una consulta agregada interpreta como ceros.

Qué se copia: los resultados y la corrida que los produjo

Un modelo mínimo necesita dos tablas. La primera guarda hechos: una fila por acta observada, con jurisdicción, identificador, fechas, estado y monto informado. La segunda guarda corridas: qué dominios se consultaron, contra qué fuentes, cuáles respondieron y cuáles fallaron.

La segunda suele omitirse y es la que sostiene toda lectura posterior. Si una jurisdicción no contestó, en la tabla de hechos no hay filas, y nada distingue “no había infracciones” de “no hubo respuesta”. La misma cautela que pide una respuesta parcial vale todavía más acá: el tablero se consulta meses después, cuando nadie recuerda cómo respondió cada portal.

Qué conviene no copiar

Un almacén analítico es otro tratamiento de datos personales, no un área neutral. La Ley 25.326 abarca el almacenamiento y la comunicación, y exige datos pertinentes y no excesivos respecto de la finalidad. Conviene cargar los campos que el tablero usa y no el payload completo por comodidad: titular, documento y domicilio rara vez hacen falta para contar infracciones por jurisdicción.

La ventana incremental corre por el reloj de observación

La marca de agua que decide qué traer en cada corrida debe apoyarse en el momento en que la plataforma observó o procesó el registro, no en la fecha del hecho. Una infracción de marzo puede publicarse en agosto: filtrada por fecha del hecho, esa fila no se carga nunca. Los tres relojes de una integración están descritos aparte; acá importa cuál gobierna el incremental.

Esas marcas se guardan como instantes con desplazamiento explícito respecto de UTC, en el formato que define RFC 3339. Una cadena sin offset obliga a suponer una zona horaria al comparar, y esa comparación decide si una fila entra o queda afuera.

Conviene además solapar la ventana: releer un tramo ya cargado cubre publicaciones tardías y relojes desalineados. El solape sólo es seguro si la escritura es idempotente; si no, duplica filas.

Idempotencia: clave natural, versión y retiro lógico

La clave del destino no puede ser el orden de llegada ni un autoincremental. Se arma con el código estable de la jurisdicción y el identificador del acta, tratados como texto. Sobre esa clave la carga hace un upsert, no un insert.

Una corrección no es una fila nueva ni un pisado silencioso: llega como una versión posterior del mismo hecho y las vistas leen la vigente. Retirar tampoco es borrar: si la fuente deja de informar un acta, la fila se marca con la fecha en que dejó de aparecer. Es el eslabón final de propagar una rectificación, el que suele quedar sin hacer.

La prueba es simple: volver a ejecutar la misma ventana tiene que dejar el mismo estado, no el doble de filas.

Tipos que el cargador no debería inferir

RFC 8259 advierte que la interoperabilidad de los números en JSON depende de la implementación que los lea. Un identificador largo que viaja como número puede perder dígitos en un cargador que lo interpreta como punto flotante. Los identificadores se almacenan como texto; los montos, en un tipo decimal.

Cuando el intercambio pasa por archivos, RFC 4180 fija lo básico: comillas, comas y saltos de línea dentro de un campo, y una fila de encabezado que hay que declarar, no adivinar. La inferencia automática de tipos es la fuente habitual de identificadores que pierden ceros a la izquierda.

Tres estados merecen columnas distintas en el destino, no un nulo común: dato ausente, dato informado como vacío y valor cero. Colapsarlos hace que un promedio de montos mienta sin que ninguna consulta falle.

Qué verificar antes del primer tablero

Antes del primer gráfico, comprobá sobre datos de prueba que:

• una corrida repetida sobre la misma ventana deja el mismo recuento;
• una corrección posterior aparece como versión vigente y la anterior sigue consultable;
• una fuente caída figura en la tabla de corridas y no como ausencia de infracciones;
• un identificador largo llega completo desde el origen hasta la columna final.

Queda una decisión que no es técnica: cuánto tiempo se conservan estas filas y qué pasa ante un pedido de supresión. La respuesta debe alcanzar a los extractos y tableros derivados, no sólo a la tabla principal.

Una buena exportación no es la que carga más rápido. Es la que permite explicar, meses después, qué decía cada fuente el día en que se la consultó.

Metodología

Alcance

Diseño de la carga de resultados de infracciones en un almacén analítico: qué tablas hacen falta, qué ventana usa el incremental y qué clave gobierna la escritura. No cubre la elección de motor, la modelización dimensional completa ni la herramienta de visualización.

Unidad de análisis

Una corrida de exportación y cada fila de acta que esa corrida escribe, actualiza o marca como retirada en el destino.

Cobertura

Criterios derivados de los estándares de fecha, JSON y CSV citados, y de obligaciones generales de tratamiento de datos personales de la Ley 25.326 al 29 de agosto de 2026.

Limitaciones

• Cada motor analítico resuelve distinto el upsert, el particionado y los tipos decimales; las cláusulas concretas cambian entre productos.
• No es asesoramiento legal. La política de retención y de supresión la define el responsable de datos de cada empresa.
• El solapamiento de la ventana, la frecuencia y el volumen deben calibrarse contra la cuota real de la integración.

Fuentes

• RFC 3339 — Date and Time on the Internet — RFC Editor (consultada el 2026-08-29)
• RFC 8259 — The JavaScript Object Notation Data Interchange Format — RFC Editor (consultada el 2026-08-29)
• RFC 4180: Common Format and MIME Type for CSV Files — RFC Editor (consultada el 2026-08-29)
• Ley 25.326 de Protección de los Datos Personales — Argentina.gob.ar (consultada el 2026-08-29)

Preguntas frecuentes

¿Puedo contar las infracciones de la flota sumando las filas cargadas?

Sólo si el registro de la corrida confirma que todas las fuentes previstas respondieron en esa ventana. Si alguna falló, la suma describe lo que se pudo observar, no lo que existe. Conviene que el tablero muestre siempre esa condición junto al número.

¿Qué fecha debe gobernar la ventana incremental de la carga?

La del momento en que la plataforma observó o procesó el registro, no la del hecho informado. Una infracción antigua puede publicarse mucho después: si la ventana filtra por fecha del hecho, esa fila no entra nunca.

¿Conviene borrar las filas que la fuente dejó de informar?

No como parte de la carga. Un borrado ahí destruye la evidencia de que ese dato existió y de cuándo se lo vio; la práctica más segura es el retiro lógico: marcar la fila con la fecha en que dejó de aparecer y que las vistas del tablero la excluyan. Es una decisión distinta de la política de retención, que sí puede obligar a borrar cuando el dato deja de ser necesario.

¿El warehouse necesita los mismos cuidados de privacidad que la API?

Sí, y a veces más, porque conserva copias durante años y suele tener más lectores. Almacenar y comunicar son tratamiento de datos personales, así que la minimización, la retención y la respuesta a un pedido de supresión también aplican a estas tablas y a los extractos que salen de ellas.

Notas relacionadas