Ingeniería de datos y backend
La ingeniería de datos y backend es el trabajo que vuelve confiable todo lo que se construye encima de tus datos: meterlos de forma fiable, guardarlos para que se puedan consultar rápido, y asegurar que la misma pregunta devuelva la misma respuesta en todos los lugares donde se hace. Suele ser la parte menos visible de un proyecto de automatización y la razón más común de que uno fracase.
Los síntomas
Este trabajo se reconoce por lo que la gente reclama. Un reporte tarda horas en correr. Dos tableros no coinciden y nadie sabe decir cuál tiene la razón. Un proceso se rompió hace tres semanas y la primera señal fue un número que se veía un poco bajo. Alguien mantiene una hoja de cálculo porque no confía en el sistema.
Ninguno de esos llega presentado como un problema de datos. Llegan como “el sistema está lento” o “los números están mal”, y el arreglo está aguas arriba de donde cae el reclamo.
Medir primero, rehacer después
El trabajo de rendimiento sin una línea base es adivinar con presupuesto. El tiempo de ejecución y el perfil de consultas se registran antes de cambiar nada, para que la mejora se pueda mostrar en vez de afirmar.
Durante un proyecto empresarial previo, antes de que Datasmarts existiera, rehacer la capa de consulta de un proceso de datos crítico llevó su tiempo de ejecución de 2 horas a 9 minutos, dejando la capa de base de datos en su lugar. El trabajo estuvo en encontrar qué parte de la capa era la responsable de verdad, que es donde se va la mayor parte del tiempo en un proyecto de este tipo.
La confiabilidad es una característica del proceso
Un proceso de ingesta que entrega menos datos en silencio es peor que uno que se detiene. En un proceso de expedientes que cubría 44 fuentes, la corrida registró cero fallas de sondeo. Eso importa porque una fuente que falta no se anuncia aguas abajo. Aparece como un total un poco más bajo de lo debido, y nadie revisa un total que se ve plausible.
Por eso los procesos reciben monitoreo sobre el proceso, no solo sobre el resultado: qué se esperaba, qué llegó, y una alerta cuando esos dos no coinciden.
Esto es el cimiento, no el proyecto
Nadie quiere comprar ingeniería de datos. Vale la pena hacerla cuando está bloqueando algo que sí quieres, y la secuencia honesta es averiguar eso durante el diagnóstico y no a mitad de camino construyendo encima.
El problema
La automatización que quieres se apoya en datos lentos, dispersos entre sistemas, o que no coinciden consigo mismos de un reporte al siguiente.
El resultado
Una capa de datos lo bastante rápida y consistente como para confiar en los sistemas construidos encima sin una revisión manual.
Lo que recibes
- Procesos de ingesta que jalan de tus fuentes con una frecuencia fija y fallan de forma visible cuando una fuente cambia
- Una capa de consulta afinada contra los patrones de acceso que de verdad tienes, no los que supuso el esquema
- Trabajo de esquema y modelo de datos, para que la misma pregunta devuelva la misma respuesta en todos los sistemas
- Servicios de backend y APIs sobre los que el resto de tus herramientas puede construir
- Monitoreo del proceso mismo, para que un hueco silencioso en los datos se vea antes de que alguien lo reporte
- Documentación de dónde sale cada número, que es lo que vuelve defendible un reporte
Cómo trabajamos
Rastrear los números
Medir antes de cambiar
Rehacer la capa que de verdad está lenta
Volver visible la falla
Trabajo relacionado
2 horas
de ejecución de un proceso de datos crítico antes del trabajo
De 2 horas a 9 minutos: rehacer un proceso de datos empresarial
un cliente empresarial de varios miles de millones de dólares
unos $77M
de gasto en publicidad política de TV rastreado y atribuido
De expedientes de la FCC a unos $77M de gasto publicitario rastreado
una consultora política estadounidense
Preguntas sobre este servicio
Nuestros reportes están lentos. ¿Es un problema de base de datos o de infraestructura?
Con más frecuencia de la capa de consulta que del hardware, y vale la pena medirlo antes de comprar nada. Durante un proyecto empresarial previo, antes de que Datasmarts existiera, rehacer la capa de consulta de un proceso de datos crítico bajó su tiempo de ejecución de 2 horas a 9 minutos, dejando la capa de base de datos en su lugar. Escalar hacia arriba habría costado dinero y escondido el problema real.
¿Por qué dos de nuestros sistemas reportan números distintos para lo mismo?
Casi siempre es un problema de definición y no de datos. Dos sistemas cuentan poblaciones ligeramente distintas, o cortan el periodo en fronteras distintas, y ambos son correctos por dentro. Rastrear cada número hasta su fuente y escribir las definiciones es el arreglo, y normalmente tiene que pasar antes de que valga la pena construir automatización sobre esos datos.
¿Pueden trabajar con el stack que ya tenemos?
Sí, y esa es la opción por defecto. Reemplazar un almacén de datos que funciona es caro y rara vez es la razón por la que las cosas están lentas. Trabajamos con las bases de datos, bodegas y servicios que ya corres, y recomendamos un cambio solo cuando hay una razón concreta de costo o de confiabilidad que podamos señalar.
¿Necesitamos esto antes de poder hacer algo con IA?
A veces, y vale la pena averiguarlo temprano. Un sistema de recuperación construido sobre datos que se contradicen va a producir respuestas seguras y equivocadas, y la falla va a parecer un problema de IA. Si un diagnóstico encuentra que la capa de datos es el bloqueo, arreglarla es el primer proyecto y no un prerrequisito que nadie presupuestó.
¿No sabes cuál de estos necesitas?
Ese es el punto de partida habitual, y para eso sirve el diagnóstico. Cuéntanos cuál proceso te está costando más tiempo y te decimos si vale la pena automatizarlo.