DataLakes y DataWarehouses: cómo se utilizan en SEO

Publicado: 2021-02-16

Si bien los conceptos de DataWarehouses y DataLakes se convirtieron en parte del lenguaje cotidiano de los analistas de datos y los científicos de datos hace mucho tiempo, solo hemos oído hablar de ellos en otras industrias durante los últimos años.
Por ejemplo, los analistas web y los expertos en SEO están comenzando a analizar seriamente estos conceptos, debido a la naturaleza de sus trabajos y la fuerte conexión que existe entre lo que hacen y la manipulación de datos. Muchos artículos recientes hablan del interés de implementar un SEO DataLake o un SEO DataWarehouse, tratando los dos términos como intercambiables y sin diferenciarlos.

En este artículo, lo guiaremos para determinar las diferencias entre DataLakes y DataWarehouses para comprender sus propósitos y sus casos de uso en SEO y análisis web.

DataWarehouse: almacén estructurado de datos

El primer uso del término "DataWarehouse" se remonta a 1988 en un artículo de Paul Murphy y Barry Delvin, An architecture for a business and information systems . Este artículo nos da una primera definición del concepto como un entorno de base de datos relacional de fácil acceso, que reúne todos los datos de negocio útiles para la toma de decisiones estratégicas.

¿Qué contiene un DataWarehouse?

El DataWarehouse se utiliza para reunir en un solo lugar los datos de negocio útiles para la toma de decisiones estratégicas de la empresa. Estamos hablando de datos comerciales que pueden abarcar desde datos de clientes, hasta información de inventario, conversiones en un sitio web comercial o visitas orgánicas (desde un motor de búsqueda como Google, por ejemplo).

Se acepta comúnmente que los datos enviados a un almacén de datos son datos estructurados y preprocesados ​​que se utilizan para descargar bases de datos operativas, lo que en última instancia permite que estas bases de datos operativas se soliciten lo menos posible con fines de consulta.
El objetivo principal de un DataWarehouse y de quienes lo administran es compilar datos de varias fuentes heterogéneas (tanto internas como externas) para estandarizarlos de modo que las diversas fuentes puedan comunicarse entre sí. El objetivo final es utilizar estos datos para realizar análisis, informes, apoyo a la toma de decisiones, etc.

¿Quiénes son los usuarios diarios de un DataWarehouse?

Debido a la naturaleza del DataWarehouse y al formato y tipo de datos que contiene, es un campo de juego ideal para los analistas de datos y web.
Los analistas de datos trabajan junto con el administrador de DataWarehouse (o el equipo de administración). Definen las necesidades del negocio y los casos de uso. Identifican las fuentes de datos y las acciones necesarias para procesar los datos aguas arriba. Estos datos serán utilizados por los analistas de datos al final de la cadena.

¿Cómo se comunican los usuarios con un DataWarehouse?

Una vez que las fuentes de datos han sido identificadas y los datos procesados, ingeridos y vinculados en el DataWarehouse, el analista de datos puede usar estos datos en análisis y para crear nuevas combinaciones de datos. Este proceso se puede utilizar para mantener paneles de informes, paneles de alerta, etc.

El lenguaje de programación más utilizado para realizar consultas en un almacén de datos es SQL (o lenguajes similares a SQL). SQL permite a los analistas de datos manipular y procesar datos para satisfacer las necesidades comerciales: seguimiento, toma de decisiones estratégicas, etc.

¿A qué casos de uso y tipos de proyectos sirven los almacenes de datos?

Es imposible elaborar una lista exhaustiva de casos de uso que impliquen el uso de un DataWarehouse. Sin embargo, aquí hay algunos ejemplos de proyectos en los que es probable que trabaje un analista de datos:

Mejora de un DataWarehouse:
Este tipo de proyecto se encuentra a menudo cuando se configura un almacén de datos, pero también cuando se identifica una nueva necesidad o caso de uso comercial.
Aquí se trata de agregar nuevos datos a un DWH (nuevamente, estos pueden ser datos internos o externos).
En este caso solemos hablar de un proceso ETL (Extracción-Transformación-Carga):

  • Extracción:
    Un primer paso que consiste en identificar y recopilar datos de las distintas fuentes necesarias para las operaciones posteriores.
  • Transformación:
    Este segundo paso es muy importante, porque sin ajuste, sin estandarización, generalmente es imposible utilizar nuevos datos y hacer que se comuniquen con los que ya existen en el DWH.
    Es por tanto una fase de necesaria estandarización que en ocasiones se puede complicar por la rigidez que impone el DWH en cuanto a formato y esquema de tablas.
  • Cargando:
    Fase de ingesta de los datos procesados ​​(y por tanto estructurados) en el DWH.

Realización de análisis estadísticos:
Este es un uso muy frecuente de DWH. El objetivo puede ser probar X o Y a través de los datos, producir estadísticas basadas en los datos históricos disponibles o establecer vínculos causales para explicar un hallazgo, etc.
Informes y alertas:
Este es, una vez más, un caso de uso muy frecuente. De hecho, como los datos en un DWH están altamente estructurados y formateados (comparten un esquema fijo y predefinido), todo es adecuado para enviar datos a paneles de informes o alertas.

Esta es una solicitud recurrente de la alta dirección, que necesita poder monitorear los equipos operativos y la salud de los resultados, ventas, etc. de la manera más simple y rápida posible.

Si resumimos todo esto, tenemos más o menos 2 tipos de proyectos: proyectos de adquisición e integración de datos (que también se pueden comparar con una forma de almacenamiento e historización de datos) y proyectos de análisis y evaluación de datos (a través de monitoreo/tablero y alertas). ).

El concepto de un DWH ha estado presente en el lenguaje cotidiano de quienes trabajan con datos durante mucho tiempo. Hace tiempo que se confirmó cómo funciona y sus numerosos casos de uso, y los DWH se pueden encontrar en muchas empresas de diversa madurez en lo que respecta a cuestiones de gestión de datos.

Este es menos el caso del concepto de DataLakes, que es mucho más joven y mucho menos generalizado.

Datos de seguimiento³

Amplíe su análisis con conexiones perfectas a conjuntos de datos adicionales. Analice su estrategia de SEO en función de los datos sobre vínculos de retroceso, tráfico de SEO, clasificaciones y conjuntos de datos personalizados de su CRM, solución de monitoreo o cualquier otra fuente.
Aprende más

DataLake: lago de megadatos (BigData)

El origen de este concepto se atribuye a James Dixon, CTO de Penthao, quien lo define como una solución para almacenar y explotar grandes volúmenes de datos, sin preprocesamiento y sin necesariamente un caso de uso específico… A diferencia de los DWH, que están muy orientados hacia la activación inmediata.
El DL trata de llenar el vacío, que es cada vez más importante con la aparición de BigData, de qué hacer con toda esta masa de datos que somos capaces de recopilar hoy y cómo aprovecharla.

¿Qué contiene un DataLake?

Comenzaré citando a James Dixon, quien utiliza una comparación muy evocadora, que sirve tanto como explicación del nombre “lago” de su concepto como para diferenciarlo del DWH:

“Si piensa en un datamart como un almacén de agua embotellada, limpia, empaquetada y estructurada para un consumo fácil, el lago de datos es una gran masa de agua en un estado más natural. El contenido del lago de datos fluye desde una fuente para llenar el lago, y varios usuarios del lago pueden venir a examinar, sumergirse o tomar muestras”.

Esta cita ilustra perfectamente la diferencia entre el tipo de datos contenidos en un DWH, que está estructurado y organizado en tablas con patrones fijos y precisos, y el tipo de datos contenidos en un DataLake, que es crudo, sin procesamiento previo, disponible para tomar muestras según sea necesario, ya sea exploratorio o no.

Cuando un DWH está restringido para acomodar datos estructurados, DataLake está diseñado para almacenar todo tipo de datos sin procesar (estructurados o no). Un debate entre Tamara Dull (Amazon Web Service) y Anne Buff (Microsoft SAS) nos da una visión un poco más concreta del contenido de un DataLake:

“Un lago de datos es un depósito de almacenamiento que contiene una gran cantidad de datos sin procesar en su formato nativo, incluidos datos estructurados, semiestructurados y no estructurados. La estructura de datos y los requisitos no se definen hasta que se necesitan los datos”.

¿Quiénes son los usuarios diarios de DataLakes?

Mientras que un analista de datos se adaptaba perfectamente para trabajar con los datos estructurados contenidos en un DHW, los datos sin procesar son, en cambio, la especialidad de los científicos de datos, que a menudo están mejor equipados para manipular este tipo de datos.
Este cambio en el perfil de datos y el usuario principal también da como resultado diferentes lenguajes de programación y casos de uso.

¿Qué casos de uso y tipos de proyectos sirven DataLakes?

Debido a su naturaleza no estructurada y al considerable volumen de datos que puede contener un DataLake, los casos de uso pueden ser muy diferentes a los encontrados anteriormente en el framework DWH, por ejemplo:

  • La implementación de algoritmos de aprendizaje automático para crear valor agregado para BigData:
    A menudo hablamos aquí de análisis predictivo, basado en algoritmos de aprendizaje automático que explotan todo tipo de datos.
    Para poner un ejemplo más concreto, imaginemos que una empresa del sector financiero (banca y seguros) quiere determinar la probabilidad de que una transacción financiera X sea fraudulenta. Esto puede recurrir a científicos de datos, capaces de crear algoritmos de aprendizaje automático que entrenarán sobre la cantidad astronómica de datos contenidos en el DataLake (cantidad, fecha, frecuencia, perfil habitual de transacciones realizadas por el titular de la cuenta, etc.). El objetivo es realizar un estudio predictivo que servirá para identificar transacciones potencialmente fraudulentas y así permitir a la empresa reducir su tiempo de reacción para detectarlas y en definitiva evitar grandes pérdidas para ellos y sus clientes.
    Este es un ejemplo simple que se usa regularmente para ilustrar el interés y el valor agregado del aprendizaje automático, pero hay muchos otros, como puede imaginar.
  • DataLakes como fuente de datos para un DataWarehouse:
    Muy simple, un DataLake puede actuar como una zona de tránsito entre sus diversas fuentes de datos internas y externas y su DWH. El principio mismo de un DataLake es centralizar todo tipo de datos, estructurados o no estructurados, para realizar estudios predictivos vía ML, o para su extracción como muestras para análisis. Por lo tanto, el DWH parece muy adecuado para esta segunda categoría de proyecto y se beneficia de un DataLake como fuente potencial (siempre que los datos de DataLake se importen de forma estructurada a través del preprocesamiento, si es necesario).
  • De DataLake a software BI (Business Intelligence):
    Podemos ver esto como un uso similar al que vimos con DataWarehouses, aunque existen ciertas especificidades al usar un DataLake para este propósito. Un DataLake te permitirá hacer visualizaciones un poco más exóticas (por la variedad de datos que contiene), a través de herramientas como Tableau, Qlikview, Google Data Studio, Microstrategy, etc.

¿Cómo se comunican los usuarios con un DataLake?

Dados los casos de uso y los usuarios (Data Scientists), muy a menudo encontraremos lenguajes de programación como Python, Java, R, Scala, etc…
En su mayor parte, estos lenguajes han estado presentes en el campo de la ciencia de datos durante mucho tiempo.

Un DataLake es, por tanto, una herramienta para gestionar BigData. Se basa en el almacenamiento masivo de datos sin procesar para fines de análisis y visualización avanzados, lo que permite mejorar los datos que antes no se habían utilizado mucho.

A modo de resumen, a continuación se muestra una tabla de los elementos diferenciadores establecidos desde el inicio de este artículo:

Almacén de datos lago de datos
tipo de datos Datos estructurados, preprocesados, organizados en tablas con esquemas definidos Datos sin procesar, almacenados de forma estructurada o no estructurada
Usuarios Analistas de datos, analistas web Científicos de datos
(a veces analistas de datos)
Volumen de datos Pequeño grande
(Dependiendo de la necesidad y caso de uso)
Potencialmente muy grande
(Grandes datos)
Lenguaje de programación utilizado SQL o similar a SQL Python, R, Java, Scala, entre otros
tipo de proyecto Proyectos analíticos y estadísticos, informes, alertas, proyectos de tipo ELT (exportar, transformar, cargar), algunos análisis predictivos y basados ​​en datos Análisis predictivo, aprendizaje automático, zona de tránsito entre fuentes de datos y DWH, visualización avanzada: BI, análisis basado en datos

Análisis predictivo, aprendizaje automático, zona de tránsito entre fuentes de datos y DWH, visualización avanzada: BI, análisis basado en datos

Son estas diferencias las que hacen que estos dos conceptos sean herramientas complementarias. En muchos casos, dependiendo de la madurez del gobierno corporativo y la gestión de datos de una empresa, pueden depender de una combinación de estas dos herramientas.
Un DWH se usa principalmente para informes y análisis tradicionales, mientras que un DataLake sirve como fuente de datos antes de alcanzar su máximo potencial a medida que la empresa se acerca a la madurez en los sujetos de datos.

En mi opinión, los DataLakes son más una respuesta a los nuevos problemas de datos del siglo XXI, especialmente con la aparición de BigData y la creciente capacidad de las empresas para recopilar datos, que un reemplazo de los DWH, como algunos podrían pensar.
Ambos tienen sus ventajas, desventajas, fortalezas y debilidades. La mejor manera de aprovechar al máximo ambos sigue siendo usarlos juntos para poder hacer frente a cualquier eventualidad y abordar una variedad más amplia de necesidades.

Ahora que hemos definido claramente los conceptos, finalmente nos centraremos en el uso de DataWarehouses y DataLakes para marketing y más específicamente para SEO (aunque en muchos casos, lo que es cierto para el primero lo será para el segundo, y viceversa). viceversa).

DataWarehouse y DataLake SEO

Hablaremos aquí de un DataWarehouse o un DataLake (o ambos) donde al menos una parte de los datos presentes se pueden utilizar para casos de uso de SEO.

¿Por qué asociar DataLakes y DataWarehouses con Marketing y SEO?

El SEO (y, en general, el marketing) ya ha dado un giro muy marcado hacia los datos en los últimos años. Cada vez más tareas requieren el uso de varias fuentes de datos:

  • Datos analíticos (Google Analytics, AT internet, etc.)
  • Datos de rendimiento (Google Search Console, Analytics)
  • Datos de registro, una "fuente" de datos muy grande para algunos sitios, que requiere una alta frecuencia de actualización y una gran capacidad de almacenamiento.
  • Datos de enlace en red (Majestic, Ahrefs, Babbar)
  • Datos de posicionamiento (SEMRush, Monitorank, etc.)
  • Datos de rastreo (OnCrawl, etc.)
  • A veces también datos comerciales/industriales

A esta lista también debemos agregar el uso de API de herramientas como Search Console, Majestic, Google Analytics, por ejemplo, lo que naturalmente nos empuja hacia el tipo de soluciones descritas anteriormente en este artículo.
Es esta fuerte conexión entre el SEO y los datos lo que impulsa a más y más analistas web y expertos en SEO a aprender nuevas formas de organizar su flujo de datos.

Sin embargo, los impulsores de esta transición no solo se relacionan con el potencial y la interconexión de SEO y datos. Muchos casos de uso diario resuenan con los tipos de proyectos enumerados anteriormente para DWH y DL.

Los casos de uso de un SEO DataWarehouse o un SEO DataLake.

Primero comenzaré con los puntos débiles que comúnmente encuentran los expertos en SEO antes de explicar cómo el uso de un DataLake o un DataWarehouse es una respuesta a considerar al abordarlos.
Entre los principales puntos de dolor, destacan los siguientes:

  • La multiplicación de archivos de Excel (el papel de hojas sueltas de nuestra década) y el copiado y pegado asociado:
    Para muchos SEO, esta sigue siendo la norma, pero seamos honestos, consume mucho tiempo, es restrictivo y muy propicio para el error humano. Para esto, un DataWarehouse es una solución perfecta. Los DataWarehouses no solo permiten recopilar todos los KPI necesarios para realizar tal o cual auditoría/análisis de las distintas fuentes de datos disponibles, sino que también permiten automatizar el procesamiento necesario para lograr el resultado esperado.
    A medida que se construye un almacén de datos, se identifican más y más casos de uso y se resuelven más y más problemas, lo que genera ahorros de tiempo cada vez más significativos.
  • Límites de capacidad (como recordatorio, Excel solo puede abrir un archivo completo si no supera las 1 048 576 líneas. Esto parece mucho, pero en realidad no es tanto en los volúmenes actuales): En realidad, no hay ningún caso de uso particular aquí, porque en En general, tanto los DataLakes como los DataWarehouses no sufren este tipo de límite. Ambos ofrecen los medios para solicitar grandes volúmenes de datos para cualquier tipo de necesidad. Para este caso concreto, es importante tener en cuenta que, en función de la necesidad, uno u otro te permitirá liberarte de los límites de aforo y, en definitiva, afrontar estas situaciones con mayor facilidad.
  • Responder a una necesidad de historización de datos
    Spoiler: uno de los casos de uso puede ser, por ejemplo, guardar un historial de los datos de Google Search Console en un DataWarehouse de SEO, en lugar de copiar y paginar sus datos en Hojas de cálculo de Google cada semana para mantener un panel de control de Data Studio. En mi opinión, tenemos aquí uno de los casos de uso más comunes entre los expertos en SEO, ya sea en agencias o in-house: la historización de datos. De hecho, muchos analistas de SEO analizan los datos históricos y sacan conclusiones de ellos.
    El ejemplo que te puede haber venido directamente a la cabeza es el caso de Google Search Console. Solo proporciona acceso a 16 meses de historial hoy (incluso a través de API). Y si sigue siendo posible una acumulación manual a través de exportaciones para pegarlas en Hojas de cálculo de Google cada semana (u otros métodos oscuros), es una pérdida de tiempo considerable además de dolorosa y aburrida.
    Eso es algo bueno porque es un problema relativamente simple de abordar con un DataWarehouse. Todo lo que tiene que hacer es configurar una conexión automática a la API de Google Search Console, definir las diversas combinaciones posibles de preprocesamiento y datos necesarias para obtener datos con valor agregado real y, finalmente, automatizar las llamadas a la API.
  • El deseo de llevar los análisis más allá, de fusionar o "analizar de forma cruzada" datos de rastreo, datos de audiencia, registros, etc. de una manera industrializada.
    Porque una pequeña ventaja competitiva nunca está de más. Las descripciones que hemos dado de un DataWarehouse y un DataLake hablan aquí por sí solas. Uno de los principales objetivos de ambas herramientas es abrir nuevas posibilidades de análisis, a través de la recopilación de datos y el análisis cruzado y/o el aprendizaje automático.
    Por citar sólo un ejemplo muy representativo; el uso de algoritmos de aprendizaje automático como Random Forest o XG-Boost para hacer predicciones de clasificación en Google.
    Muy simple, la idea es entrenar un algoritmo en una gran cantidad de SERP (páginas de resultados) de Google y todas las métricas de SEO recolectables para estas SERP para determinar, en función de esas mismas métricas, el potencial de clasificación de una URL determinada (y por lo tanto, aún más particularmente, para determinar las métricas más importantes para clasificar en un sector/tema en particular).
    → Encontrará la metodología completa en el artículo de Vincent Terrasi, Director de Producto de Oncrawl, “Predecir con éxito las clasificaciones de Google en la vanguardia de la ciencia de datos” , 2018.
  • El deseo de automatizar la generación de informes tanto como sea posible, para centrarse en tareas de alto valor agregado. Nuevamente, esto cae literalmente dentro de los casos de uso clásicos de un DataWarehouse. Ofrece la posibilidad de automatizar toda la recuperación y el procesamiento de las distintas fuentes de datos, y aborda perfectamente este punto débil. Una vez configurada, una tabla se alimentará automáticamente al DWH y se puede usar como una conexión con el software de BI para tableros, ya sea para monitoreo, alertas, etc. Por supuesto, la automatización no se detiene solo en los proyectos de informes. Tanto un DWH como un DL se pueden usar para muchas optimizaciones de SEO automatizadas. Por ejemplo, actualizaciones dinámicas de bloques de enlaces internos sobre rango, presupuesto de rastreo, audiencia de SEO, etc. (todos los datos contenidos en el DWH).
  • El deseo de acabar de una vez por todas con los problemas de seguridad (sabemos quién hizo qué y dónde encontrarlos) y evitar perder tiempo en mantenimiento. Terminamos aquí en un aspecto más orientado a procesos que a un caso de uso, estrictamente hablando.
    Tanto DataLakes como DataWarehouses implican la implementación de procesos particulares que se pueden presentar de la siguiente forma simplificada:

    • El punto de partida es una observación que se descompone en una declaración de necesidades (equipo comercial / SEO – Analista de datos).
    • Luego, esto se transforma en una especificación más técnica que le permitirá al equipo que administra la herramienta comprender qué se debe hacer y cómo se debe hacer.
    • Este mismo equipo de administración realiza la solicitud.
    • El equipo comercial y los analistas de datos producen un caso de uso de procedimiento para el trabajo realizado.
    • Hay un proceso continuo en el que los dos extremos de la cadena (equipo comercial y equipo de administración de DataWarehouse o DataLake) se aseguran de que nada cambie en términos de entrada y salida.
      Este es particularmente el caso de un DWH, que rechazará cualquier dato que no sea parte de la estructura (el esquema predefinido).

Nuevamente, esta es una lista no exhaustiva de puntos débiles y posibles casos de uso para DataWarehouse – DataLake SEO. Los límites se encuentran más en la falta de imaginación de quienes los utilizan que en las propias herramientas.

Elegir un DataWarehouse o DataLake para sus usos de SEO

Para concluir, contrariamente a lo que puede escuchar o leer a menudo, DataWarehouses y DataLakes son estructuras separadas para el almacenamiento y la recopilación de datos, y no son incompatibles. No hay necesidad de elegir uno sobre el otro, todo lo contrario. Ambos tienen diferentes casos de uso e incluso hay algunas adherencias.

El caso de SEO es un ejemplo revelador y refuerza la necesidad de DataWarehouses y DataLakes en general. Los datos son omnipresentes en SEO: tenemos que manipular grandes cantidades de datos de diferentes fuentes. Así que no sorprende que hablemos de DataWarehouses y DataLakes en este contexto. Podemos imaginar muchos casos de uso de DataWarehouses o DataLakes en SEO, ya sea con fines de automatización, para realizar análisis “aumentados” a través de datos, o simplemente para resolver problemas recurrentes (puntos débiles).