Home Ciencia y Tecnología 5 errores comerciales principales al trabajar con Large Information: Lecciones de una...

5 errores comerciales principales al trabajar con Large Information: Lecciones de una empresa que administra 16 TB de datos

42
0

Más de una cuarta parte de los profesionales de datos y análisis en todo el mundo estiman que los datos de baja calidad le cuestan a las empresas más de $ 5 millones anuales, con un 7% que la cifra en $ 25 millones o más. El uso de datos de baja calidad es solo uno de los muchos errores comunes que, con el tiempo, pueden conducir a serias pérdidas financieras.

He estado trabajando con el sistema de análisis de producción en Waites durante más de 10 años. Durante este tiempo, hemos recopilado más de 16 terabytes de datos y recibimos más de 10 mil millones de puntos de datos nuevos diariamente de equipos industriales. Según mi experiencia trabajando con Large Information, identificé cinco errores principales que las empresas a menudo cometen cuando comienzan a trabajar con datos.

Período de retención de datos indefinido

La duración de los datos de tiempo se almacenan antes de eliminarse se determina por el momento de vivir (TTL). Típicamente, TTL para datos activos varía de 1 a 2 años, mientras que los datos archivados se conservan durante unos 5 años.

Cada compañía puede establecer su propio TTL en función de las necesidades comerciales, pero no establecerlo puede conducir a problemas. Si el TTL para datos activos es mucho más largo de lo realmente necesario, el sistema comienza a disminuir. Incluso al consultar solo los últimos seis meses, la base de datos puede tener que escanear volúmenes excesivos de información, especialmente si los datos no se han archivado. Además, el almacenamiento de datos obsoletos durante demasiado tiempo conduce a costos innecesarios de infraestructura.

Los formatos de archivo como Apache Avro o ProtoBuf permiten que los datos se almacenen de manera más compacta. Combinados con algoritmos de compresión, ayudan a reducir los costos de almacenamiento. Sin embargo, leer tales archivos requiere más recursos informáticos y tiempo de procesamiento. Es por eso que es importante lograr un equilibrio entre la velocidad de acceso, los costos de infraestructura y el volumen de almacenamiento.

Mala calidad de datos y falta de estandarización

En 2022, Unity Software program, la compañía detrás de un motor de videojuegos ampliamente utilizado, lanzó su propio sistema de publicidad. Este movimiento se produjo después de que los cambios en la política de la IDFA de Apple hicieron que los modelos de anuncios tradicionales fueran menos efectivos. El sistema de Unity se basaba en sus propios datos de interacción del usuario en lugar de los de Apple, y aunque la thought parecía prometedora, se basó en datos de baja calidad. Como resultado, la orientación fue inexacta y el rendimiento de AD disminuyó. Los clientes comenzaron a cambiar a competidores, lo que llevó a una pérdida de capitalización de mercado de $ 5 mil millones.

A menudo, las empresas solo se dan cuenta de los problemas de calidad de los datos una vez que ya han causado daños financieros significativos.

Los problemas con los tipos de datos, las marcas de tiempo, los duplicados o la falta de estandarización pueden distorsionar el análisis y llevar a los modelos de IA para obtener conclusiones incorrectas. Para evitar esto, es esencial establecer un estándar unificado para almacenar y procesar datos durante la fase de diseño, documentarlo claramente y garantizar la alineación en todos los equipos. Las verificaciones de calidad de datos regulares también son cruciales: esto incluye eliminar duplicados, estandarizar formatos y monitorear la integridad de los datos.

La trampa de autoscalaje durante las cargas máximas

Cada empresa experimenta períodos de mayor demanda: vacaciones, promociones estacionales o lanzamientos de nuevos productos. Trabajamos con empresas manufactureras, y durante tales períodos pico, observamos un aumento de 5–10x en el volumen de datos y el número de solicitudes. La infraestructura debe estar preparada para manejar este nivel de carga.

El uso de autoscalado en la nube puede parecer una solución obvia, pero si no establece los límites superiores, el sistema puede agregar automáticamente servidores mucho más allá de lo que realmente se necesita. Fui testigo de un caso en el que el número de servidores saltó de los requeridos de 8 a 80 durante la noche. La compañía terminó con una factura por varios cientos de miles de dólares. Si bien los clientes estaban contentos con el rendimiento, el negocio no fue, porque los mismos resultados podrían haberse logrado sin el costo excesivo.

Para evitar esto, las empresas deben no solo configurar los límites de escala sino también monitorear de cerca lo que está sucediendo en tiempo actual. Herramientas como Datadog o AWS CloudWatch pueden ayudar al alertar a los equipos cuando se exceden los umbrales.

A veces, los picos estacionales no se pueden gestionar no escalando la infraestructura, sino mediante la optimización, como cambiar los formatos de datos, reestructurar bases de datos o distribuir la carga en múltiples servidores. Si bien esto puede requerir un esfuerzo adicional de los arquitectos y desarrolladores, a la larga, demuestra ser una solución mucho más rentable.

Costos excesivos causados por datos excedentes

A menudo, las empresas recopilan no solo las métricas necesarias para la toma de decisiones, sino también la información técnica del usuario que no se analiza. Según la investigación de Snowflake, solo el 6% de las empresas han logrado una alta eficiencia de datos y están obteniendo beneficios comerciales reales de él. Y solo el 38% de las empresas usan datos como base para la toma de decisiones.

Las empresas más pequeñas que almacenan hasta un millón de registros pueden no notar problemas de los datos excedentes por un tiempo. Pero cuando se trata de miles de millones o billones de registros, los costos comienzan a sumar: gastos en aumentos de infraestructura, se necesitan más desarrolladores, la integración del sistema se vuelve más compleja y el rendimiento basic disminuye.

Por ejemplo, en análisis industrial, los sensores IIOT transmiten no solo los parámetros de estado del equipo actualizados regularmente, como los niveles de vibración o la temperatura, sino también los detalles técnicos que rara vez cambian, como la versión o el tipo de informe del firmware del sensor. El almacenamiento de estos detalles técnicos en cada registro puede aumentar el volumen de datos de 10 a 20 veces. Es por eso que solo guardamos información técnica cuando cambia. Este enfoque ahorra espacio de almacenamiento, cut back los costos y acelera el procesamiento.

Cuando se trabaja con datos, es importante desde el principio para definir claramente qué información es esencial para el análisis y la toma de decisiones, y qué se puede omitir o almacenarse temporalmente.

Elegir la base de datos incorrecta

Uno de los errores más subestimados es usar una única base de datos como una solución única para todos. Lo que funciona bien para un caso puede ser ineficiente en otro.

Para explicar en el contexto del análisis de producción: las bases de datos NoSQL como MongoDB funcionan bien cuando necesita mostrar todos los datos relacionados con un equipo específico en una sola página: parámetros, registros, notas, informes de ML, and so on. Pero el uso de una base de datos NoSQL para construir listas que requieran información breve en muchos objetos diferentes pueden causar problemas. NoSQL no admite consultas o relaciones eficientes específicas de campo entre los datos de la forma en que las bases de datos relacionales. Como resultado, el sistema puede tener que cargar documentos completos donde solo se necesiten piezas, reduciendo el rendimiento y la desaceleración del procesamiento de consultas.

Antes de diseñar su arquitectura, asegúrese de que la base de datos elegida se ajuste a su tipo de datos y necesidades comerciales. InfluxDB, TimescaledB u OpenSDB son adecuados para datos de sequence de tiempo; MongoDB, Cassandra o DynamodB funcionan para datos flexibles o semiestructurados; y MySQL, PostgreSQL, Oracle o MS SQL son los mejores para datos estructurados. Evite confiar en una sola base de datos.

La gestión efectiva de datos no comienza con la recopilación de datos, sino que se pregunta: ¿qué necesita grabar para tomar decisiones, qué datos son necesarios y cómo lo almacenará y procesará?

fuente