Los cinco retos del Big Data
Teradata sigue desvelando los secretos y retos del Big Data en la actualidad. Más allá de describir este fenómeno hay que definir algo muy importante: a qué retos se enfrenta el Big Data.
Las organizaciones con las que Teradata trabaja no solo van más allá del análisis de transacciones y eventos, sino que también analizan las interacciones y dominan los cinco retos clave del Big Data:
1. El reto de los datos multi-estructurados: Los datos de transacciones y eventos que se han ido almacenando, integrando y analizando en los Data Warehouses tradicionales y en aplicaciones de Business Intelligence durante las tres últimas décadas están en gran parte orientados a dejar constancia de lo ocurrido y se definen en términos de esquema explícito. No siempre se puede decir lo mismo de las nuevas fuentes de Big Data. Social data and machine log data se caracterizan por su volatilidad: el modelo de información que usamos para entenderlos puede ser implícito en lugar de explícito, puede ser orientado a documento, pudiendo (o no) incluir algún nivel de organización jerárquica, puede cambiar continuamente o puede que queramos aplicar diferentes interpretaciones a los datos en tiempo real (esquema de lectura) en función de cada uso y aplicación.
Martin Willcox, Director de Producto y Soluciones de Marketing International en Teradata Corporation, comenta: “A las nuevas generaciones de analistas de sistemas de negocio nos enseñaron que los procesos de negocio están cambiando continuamente, pero que los datos y sus relaciones no, así que lo importante es moldear los datos. El Big Data acaba con estas enseñanzas y hace que el enfoque tradicional para integrar datos no sea productivo ya que requiere que se aplique un esquema rígido e inflexible a los datos a medida que pasan a formar parte de un entorno de análisis”.
2. El desafío de las analíticas interactivas: Las interacciones, tanto entre personas y cosas, personas y personas como cosas y cosas, describen redes o gráficos. Muchos análisis de interacciones se caracterizan por operaciones en las que el orden de registro es importante. Sin embargo, la cronología, la trayectoria y el gráfico dan problemas debido a las tecnologías ANSI-standar SQL, ya que están basados en el modelo relacional y en la teoría de conjuntos, en las que el orden de registro no tiene importancia. Son variadas las ampliaciones que se han propuesto a lo largo de los años para que el estándar ANSI SQL haga frente a estas limitaciones, entre ellas las funciones User Defined Functions (UDF) y Order Analytical OLAP, pero solo son una solución parcial, ya que no siempre se podrá saber cuándo una función refleja el esquema preciso de los datos que se necesitan procesar.
“El problema de estas consultas es que a menudo son difíciles de expresar en el estándar ANSI SQL y puede ser demasiado costoso a nivel de computación hacerlas funcionar en plataformas optimizadas para el procesamiento basado en conjuntos, incluso si tenemos éxito al hacerlo”, asegura Martin Willcox, de Teradata.
3. El reto de los datos con ruido: Algunos grupos de Big Data son grandes y con ruido y se vuelven aún más grandes rápidamente, se accede a ellos con poca frecuencia para ayudar al procesamiento asociado con objetivos de nivel de servicio relajados y sin valor probado. Las empresas tienen que capturar volúmenes de datos cada vez más grandes en los que la señal útil está acompaña por un volumen aún mayor de datos que suponen ruido para la mayor parte de las compañías, que buscan modelos rentables de almacenamiento y procesamiento de datos. Sin embargo, estos datos podrían ser una gran oportunidad para un pequeño y selecto grupo de Data Scientists.
4. El reto de “puede haber una aguja en un pajar pero si se necesitan doce meses y 500.000 € para averiguarlo no hay tiempo ni dinero para investigarlo”: Muchas organizaciones comprenden que los nuevos grupos de Big Data son valiosos pero no saben dónde buscarlos. Los enfoques tradicionales hacia Data Integration: modelar los sistemas de origen, desarrollar un nuevo e integrado modelo de datos, aplicar los modelos de origen al de destino, desarrollar procesos ETL que capturen y transformen de forma precisa los datos del sistema de origen al modelo de destino, etc, suelen dar problemas con la captura de datos multi-estructurados y tienen aún más dificultades en estos escenarios debido al tiempo y coste que hay entre el Data Scientist y el acceso a los nuevos datos.
Se ha estimado que los costes de adquisición, normalización e integración de datos representan hasta el 70% del coste total de implementar una base de datos analítica y aún así es más barato que las alternativas.
“Cuando no queramos preguntar o responder de manera fiable sino explorar nuevos conjuntos de datos para comprender si nos permitirán plantear nuevas preguntas que merezcan la pena contestar, quizá necesitemos un nuevo enfoque para adquirir datos que nos proporcionen una calidad de datos suficientemente buena”, afirma Martin Willcox, Director de Teradata Corporation. “En estos contextos de “exploración y descubrimiento” experimentamos continuamente con los datos para identificar nuevas hipótesis que merezca la pena probar y para identificar nuevas fuentes de datos. Dado que muchos de estos experimentos fallarán, la productividad y el ciclo de tiempo son fundamentales para alcanzar el éxito”, concluye.
5. El reto de ir más allá y el valor de la entrega: Numerosos proveedores y analistas siguen afirmando que “el objetivo de un proyecto de Big Data es aumentar los conocimientos empresariales”, sin embargo esto no es del todo cierto. ya que el objetivo debe ser usar esa visión para cambiar el negocio y así impulsar el retorno de la inversión (ROI).
“Como dijo uno de mis antiguos jefes: “procesos arcaicos de negocio + tecnología novedosa y cara = procesos de negocio caros y viejos”. Utilizar los conocimientos obtenidos a partir de experimentos analíticos a menudo requerirá que creemos los datos y analíticas necesarias, de manera que podamos compartir de forma fiable y precisa nuevas KPIs, medidas y alertas con toda nuestra empresa”, comenta Martin al respecto. “Aunque es cierto que los Data Scientist son cada vez más importantes para cualquier negocio, ellos no hacen que funcione, sino los encargados, empleados, responsables de atención al cliente o supervisores de logística. Asimismo, todos los datos que no puedan ser procesables y compartidos más allá del Laboratiorio de Datos no permitirán hacer un trabajo mejor que el anterior”, concluye.
Estos cinco retos clave y sus consecuencias son los que están impulsando la evolución a largo alcance de Enterprise Analytical Architecture desde que Devlin, Inmon, Kimball,etc., presentaron el Enterprise Data Warehouse.
