Big Data de verdad o “tipo Big Data”

Rodrigo Sandoval
R:Solver Blog
Published in
4 min readOct 21, 2020

Partamos por una pregunta básica: ¿cuántos datos se consideran “Big Data”?

Pero en realidad, ¿importa hacer esa distinción?

Dentro de la literatura, se habla de Big Data con más formalidad cuando se involucran datos en tal volumen, que su manejo presenta desafíos. Típicamente datos no-estructurados, como comentarios en lenguaje natural, y/o video.

Datos que generan valor de negocio (por ej, en visualizar tendencias y predicciones), son los que realmente importan, más allá de si se trata de Big Data o no. (Foto por Carlos Muza en Unsplash)

Se habla de las Vs de Big Data: Volumen, Variedad, Veracidad, y Velocidad (de acceso), además de Valor de negocio.

Por ello, para realmente declarar un proyecto como Big Data, se podría considerar que algunas de esas Vs están involucradas.

Pero, aún así, en realidad no importa demasiado esa distinción formal, mientras la empresa tenga el objetivo de crear valor de negocio desde los datos.

Pero hay ciertas consideraciones relevantes de mantener en cuenta, que pueden ayudar en este tipo de iniciativas y proyectos.

¿Más datos o más detalles de los datos?

Si se busca realizar análisis sobre clientes, mientras más clientes, mejor. Pero, especialmente al comenzar el proyecto, cuando aún se están capturando datos de los clientes, vale la pena extender la cantidad de atributos. Por ej, en el contexto retail, el comportamiento de compra tiende a enfocarse en 3 indicadores: RFM — Recencia, Frecuencia, Monto (promedio de compra).

Entonces, ¿será interesante capturar otros atributos, como antigüedad del cliente, ubicación geográfica (domicilio o locales que frecuenta)?

Seguro hay otros atributos, que podrían generar información de valor, por lo que se vuelve fundamental considerarlos lo antes posible, de modo que el proceso de captura de datos tenga consideraciones de diseño para facilitar estos datos.

Entonces → Más datos y más atributos de los datos.

¿Datos estructurados y/o no-estructurados?

Para poder distinguirlos, se podría decir que los estructurados son los que se pueden tabular fácilmente en una planilla, mientras que lo no-estructurados, precisamente, no tienen una estructura. Es el caso típico de comentarios de los clientes en sus comunicaciones con la empresa/marca. Por ej, por e-mails o posts en redes sociales. En esos comentarios, de texto natural, puede haber mucha información valiosa que extraer.

Veamos un ejemplo.

Un cliente compró un nuevo smartphone en la tienda online. Esa transacción queda registrada como de su historia e impulsa la predicción de que el cliente (y aquellos calificados como “similares”) podrá volver a comprar un producto así, e incluso, estará propenso a comprar accesorios relacionados.

Pero el sistema de ventas e-commerce no rescata que el cliente, un par de semanas después, se quejó del producto en medios sociales. Cualquier predicción que no incluye esa queja, estará evidentemente equivocada. Más aún, si la tienda fuese capaz de capturar esos comentarios y reconocer el descontento del cliente en su mensaje indirecto, podría contactarlo directamente y ofrecerle algún incentivo para re-encantarlo y, en el futuro, siga siendo cliente.

Un cliente descontento difícilmente entregará información estructurada, sino que se expresará por otros medios. Foto por Icons8 Team en Unsplash

¿Tecnología Big Data?

Se ven muchos departamentos TI, que al ser comandados a implementar un proyecto Big Data, comienzan por la adopción de tecnología. Por ej, alguna de las plataformas de BD distribuida. Si bien, hay significativas ventajas en aprovechar este tipo de tecnologías, no hay que despreciar los repositorios RDBMS, con SQL, que igualmente son capaces de responder más que adecuadamente en la mayoría de los proyectos e iniciativas que aún no saltan al espectro “Big” en datos. Todo depende del contexto, pero lo importante es no frenar una iniciativa de data analytics sólo por no tener un NoSQL.

¿Machine Learning Supervisado, no-Supervisado?

Evocando al “Síndrome del Martillo” (“todo parece un clavo”), vemos recurrentemente a equipos empecinados en implementar algún modelo de clasificación supervisada o no-supervisada para resolver un problema, que posiblemente se resuelva mejor de otra forma. En la práctica, los modelos de predicción y descripción que, colectivamente, se denominan Machine Learning, sirven para resolver cierto tipo de preguntas, como ¿qué clase de ____ es un ítem? ¿Cómo agrupar los ítems en relación a su semejanza?

Sin embargo, preguntas de valor de negocio como ¿cuál es la combinación ideal de recursos para minimizar el costo? se resuelven con heurísticas de optimización.

Entonces, lo importante en este tipo de proyectos es entender bien cuál es la pregunta que se requiere resolver, y según eso, determinar cuál técnica es la que enfrentará de mejor manera el caso, así como los datos (tipos, variedad, completitud, volumen), que serán necesarios para lograr resultados adecuados.

Como corolario, vale la pena reiterar que es irrelevante la calificación correcta o incorrecta de un proyecto “Big Data”, mientras que exista una situación de negocio real y sea factible, por medio de datos (pocos, muchos, variados, o simples) implementar una solución que responda esa pregunta generando valor de negocio, siempre mirando hacia el horizonte, para el cual se irán capturando y recolectando más datos, más variados, más valiosos, más veraces.

--

--

Rodrigo Sandoval
R:Solver Blog

Published photographer, author and computer scientist, based in Santiago, Chile