¿Qué es el big data?

La definición más citada en el ámbito técnico es la del NIST, el instituto de normalización de Estados Unidos. En su marco de interoperabilidad de 2019, describe el big data como conjuntos de datos extensos, caracterizados sobre todo por su volumen, su variedad, su velocidad o su variabilidad, que requieren una arquitectura escalable para almacenarlos, manipularlos y analizarlos de forma eficiente.

La parte importante de esa definición es la segunda. Big data es más que «muchos datos»: el tamaño, el ritmo con que llegan o la mezcla de formatos obligan a cambiar de herramienta. Una hoja de cálculo o una base de datos en un solo servidor dejan de bastar, y el trabajo se reparte entre muchas máquinas.

Las cuatro características se entienden mejor con ejemplos. Volumen: los registros de un servidor web grande, con millones de líneas al día. Velocidad: los clics de una tienda online que hay que procesar mientras se producen. Variedad: datos en tablas junto a textos, imágenes o registros de máquinas. Variabilidad: datos cuyo significado o ritmo cambia con el tiempo, como el tráfico de una web antes y después de una actualización de Google.

El principio técnico es repartir. En lugar de un servidor cada vez más potente, el NIST describe el paradigma del big data como la distribución de los sistemas de datos entre recursos independientes acoplados en horizontal: muchas máquinas normales que guardan y procesan cada una una parte. Si los datos crecen, se añaden máquinas.

Sobre esa base hay dos formas típicas de trabajar. En el procesamiento por lotes, los datos se acumulan y se analizan cada cierto tiempo, por ejemplo una vez al día. En el procesamiento en flujo, se analizan a medida que llegan, lo que permite reaccionar en segundos. Los almacenes de datos en la nube, como BigQuery, permiten consultar tablas enormes con SQL sin gestionar las máquinas que hay detrás.

Para quien hace marketing o SEO, el contacto con el big data suele ser indirecto: los datos de Search Console, de Google Analytics o de los registros del servidor llegan ya resumidos por una herramienta. Y cada resumen deja algo fuera.

Search Console es el ejemplo más claro. Google explica que sus datos de rendimiento tienen dos límites. Uno es la privacidad: las consultas que no han hecho más de unas pocas docenas de usuarios en dos o tres meses se anonimizan y no aparecen en las tablas, aunque sí cuentan en los totales del gráfico. El otro es el número de filas: según Google en 2022, la interfaz exporta como máximo 1.000, y la API, según su documentación actual, 50.000 filas por día y por tipo de búsqueda. Desde febrero de 2023, la exportación masiva a BigQuery entrega todos los datos sin ese límite de filas. Tampoco allí se ve el texto de las consultas anonimizadas: sus filas llevan is_anonymized_query = true y el campo query vacío.

Google lo ilustra en su blog con un ejemplo de cálculo: las consultas desglosadas suman 450 clics, pero el total del gráfico marca 550, porque incluye también los clics de las consultas anonimizadas. Quien suma las filas de la tabla o de la API no llega nunca al total.

Para la búsqueda con IA, la escala es todavía mayor. Los modelos de lenguaje se entrenan con colecciones de texto que solo se pueden manejar con técnicas de big data, y los buscadores con IA se apoyan en índices que abarcan buena parte de la web. Lo que una web publica pasa a formar parte de esos datos, con la misma lógica de volumen, velocidad y variedad.

• Formula la pregunta antes de reunir datos: el volumen sin una pregunta concreta solo produce más almacenamiento.
• Conoce los límites de cada fuente: muestreo, anonimización, límites de filas y retrasos en los datos definitivos.
• En sitios grandes, usa la exportación masiva de Search Console a BigQuery en lugar de la API si necesitas todas las filas.
• Guarda por separado los totales y los desgloses, y no compares una suma de filas con un total sin saber qué falta.
• Anota de qué fecha y en qué estado están los datos, por ejemplo si son provisionales o definitivos.
• Trata los datos personales conforme al RGPD desde el diseño, no como un añadido posterior.

• Sumar las filas de Search Console por consulta y esperar que cuadren con los clics totales.
• Confundir volumen con conocimiento: más datos no responden por sí solos a una pregunta mal planteada.
• Mezclar datos provisionales y definitivos en la misma serie temporal.
• Montar una infraestructura de big data para un volumen que cabe en una hoja de cálculo.
• Guardar datos personales «por si acaso», sin finalidad ni base legal.