Proyecto LinkedIn

La Comunidad Ninja sigue evolucionando y, con ello, nacen nuevos proyectos colaborativos que nos permiten aprender juntos mientras trabajamos en iniciativas reales.

Este proyecto se inspira en la web datanerd.tech y busca responder preguntas clave para quienes buscan oportunidades laborales en el sector de datos.

Sesión 1

En esta primera sesión, no solo sentamos las bases del Proyecto LinkedIn, sino que definimos cómo abordaremos el aprendizaje de forma práctica y colaborativa.

🎯 Objetivo del Proyecto

A lo largo de este proyecto, nos enfrentaremos a desafíos reales en ingeniería de datos, análisis y visualización, explorando herramientas clave del ecosistema de datos.

Nuestro objetivo es construir una herramienta que permita visualizar datos de interés para cualquier ninja de los datos como:

• Las habilidades más demandadas en distintas posiciones.
• Comparaciones salariales en el sector de datos.
• Tendencias en la contratación de perfiles técnicos en diferentes países.

🛠️ ¿Qué vamos a aprender?

Este proyecto nos dará la oportunidad de aprender haciendo, tocando cada etapa clave de un flujo de trabajo de datos:

1️⃣ Extracción de Datos

• Uso de APIs para obtener datos estructurados de LinkedIn.
• Evaluación de alternativas de scrapping y consideraciones éticas.

2️⃣ Transformación y Modelado de Datos

• Procesamiento y limpieza de datos con dbt y/o Apache Spark.
• Creación de estructuras de datos eficientes para análisis.

3️⃣ Almacenamiento en un Data Warehouse

• Configuración y gestión de BigQuery y/o Snowflake.
• Aprender a manejar grandes volúmenes de datos en la nube.

4️⃣ Análisis y Visualización

• Creación de dashboards con Streamlit, Looker y/o Power BI.
• Interpretación de datos para obtener insights relevantes.

🤝 ¿Cómo vamos a colaborar?

El aprendizaje es colaborativo y flexible.

Cada miembro podrá contribuir en las áreas que más le interesen, ya sea ingeniería de datos, modelado, almacenamiento o análisis.

Además:

• Organizaremos sesiones para resolver dudas y compartir avances.
• Usaremos un espacio común en Discord para debatir estrategias y compartir recursos.

Si te interesa aprender más sobre Ingeniería de Datos, Análisis o Tecnologías Cloud, esta es tu oportunidad de hacerlo con un proyecto práctico y en comunidad.

📺 Puedes ver la sesión de presentación del proyecto a continuación:

Sesión 2

En esta segunda sesión del proyecto, Raúl nos guía en la etapa de planificación de proyectos de datos extremo a extremo.

📅 Planificación del proyecto

Para evitar una sobrecarga de tareas y garantizar avances tangibles, nos enfocaremos en la construcción de un MVP (Producto Mínimo Viable).

Un aspecto clave es definir claramente qué queremos mostrar antes de recopilar los datos.

La estrategia será partir de preguntas concretas para evitar almacenar información innecesaria y optimizar el proceso de transformación y análisis.

Además de definir la infraestructura y el enfoque de trabajo, consolidamos la importancia de establecer una base sólida antes de comenzar con la recopilación de datos.

Con estos fundamentos, el siguiente paso será comenzar a extraer datos de LinkedIn y evaluar su calidad para garantizar que las visualizaciones finales cumplan con los objetivos planteados.

Si quieres conocer más sobre cómo estamos construyendo este proyecto, no te pierdas la grabación de la sesión.

Sesión 3

En esta tercera sesión de una hora del Proyecto LinkedIn, nos adentramos en la extracción de datos desde APIs y damos el primer paso técnico para construir nuestra base de conocimiento sobre el mercado laboral en el sector de datos.

🧠 Conceptos básicos sobre APIs

Empezamos con una introducción a las APIs, entendiendo qué son y cómo funcionan, con analogías sencillas que ayudan a aterrizar conceptos como los endpoints, los métodos HTTP, los parámetros o las claves API.

A partir de ahí, exploramos dos marketplaces que ofrecen acceso a datos de LinkedIn:

• RapidAPI
• Scrapping Dog

Analizamos qué ofrece cada uno, qué campos devuelven, cómo están documentados y, muy importante, cuánto cuestan.

Este punto es clave para decidir cuál usaremos en el proyecto, ya que cada una tiene sus ventajas y limitaciones tanto técnicas como económicas.

🐍 Demo práctica con Python

Después vino la parte práctica.

Montamos un entorno con Docker que incluye Jupyter y una base de datos PostgreSQL, y desarrollamos un script en Python que:

1. Hace peticiones a la API para obtener ofertas de empleo por palabra clave.
2. Recupera los detalles de cada oferta a partir de su ID.
3. Convierte los resultados en un DataFrame con pandas.
4. Inserta los datos estructurados en una base de datos PostgreSQL.

Esta sesión marca el inicio del trabajo con datos reales, sentando las bases técnicas para las siguientes etapas del proyecto.

Puedes ver la sesión completa a continuación:

Sesión 4

En esta cuarta sesión, hemos dado un paso fundamental en el diseño de nuestra herramienta: el modelado conceptual de datos.

💡 ¿Por qué es importante el modelado de datos?

Aquí donde conectamos el mundo técnico con las necesidades reales de quienes usarán nuestros dashboards.

El modelado de datos no es solo cosa de ingeniería: también es análisis, estrategia y sentido común.

📊 Modelado conceptual

Nos centramos en identificar qué métricas queremos representar (por ejemplo, número de ofertas por tipo de contrato, ubicación o tecnología requerida) y qué dimensiones vamos a necesitar para analizarlas.

Durante la sesión reflexionamos sobre lo que podemos obtener fácilmente desde la API de LinkedIn y lo que requerirá más trabajo, especialmente en el tratamiento de texto libre (como las habilidades en la descripción de las ofertas).

También discutimos las principales estrategias de modelado de datos, con sus ventajas y limitaciones.

• El modelo en estrella (Kimball), muy usado por su simplicidad y eficiencia para el análisis;
• El modelo en copo de nieve, más normalizado;
• La estructura en tabla única (OBT, One Big Table), ideal para proyectos más exploratorios;
• El modelo Data Vault, pensado para entornos más complejos con múltiples fuentes y trazabilidad total.

🧭 El modelado conceptual nos da dirección: antes de picar código, pensar qué queremos construir.

Así evitamos desarrollar soluciones que no resuelven problemas reales.

¿Quieres ver cómo lo hicimos en directo y qué decisiones tomamos como equipo? Puedes ver la grabación completa aquí:

Sesión 5

En esta sesión extra del Proyecto LinkedIn, nos adentramos en el uso de modelos de lenguaje para enriquecer nuestra base de datos con información extraída de la descripción del puesto de trabajo.

🤖 Extracción de información con LLMs

El objetivo de esta sesión de 50 minutos de duración es utilizar un modelo de lenguaje para analizar las descripciones de las ofertas de empleo y extraer de manera automática atributos como habilidades técnicas, herramientas, soft skills o incluso el idioma en el que está escrita la oferta.

Este paso nos permite transformar texto no estructurado en datos listos para ser analizados, ampliando así el valor de nuestro dataset original.

🔧 ¿Qué hacemos en esta sesión?

• Explico el acceso al repositorio privado de la comunidad en GitHub y recordamos las buenas prácticas de colaboración (creación de ramas, pull requests...).
• Clonamos el repositorio, levantamos los contenedores con Docker y nos conectamos a la base de datos PostgreSQL.
• Repasamos y corregimos los problemas de carga de datos detectados en sesiones anteriores.
• Creamos una nueva tabla para almacenar la información extraída por el modelo de lenguaje.
• Diseñamos un esquema de respuesta estructurada en JSON para guiar al LLM en la extracción de skills, herramientas y soft skills.
• Implementamos el flujo completo: recuperación de descripciones, llamada al modelo, parsing de resultados y almacenamiento en base de datos.

Esta sesión marca el inicio del trabajo con modelos de lenguaje en el Proyecto LinkedIn, abriendo la puerta a nuevas formas de enriquecer nuestros análisis con información más profunda y precisa.

¿Quieres ver todo el proceso en detalle? Puedes acceder a la grabación completa aquí:

Sesión 6

El objetivo de esta sesión de 1 hora es sumergirnos en el mundo de la arquitectura de datos y establecer una estructura sólida para nuestro proyecto de análisis de ofertas de empleo.

Exploraremos cómo organizar y transformar los datos que hemos recopilado, utilizando como guía principal la arquitectura Medallion con sus capas Bronce, Plata y Oro.

Este enfoque nos permitirá evolucionar desde datos crudos y sin procesar hasta información refinada, lista para análisis y visualizaciones, sentando una base robusta para las futuras etapas del proyecto.

🏗️ ¿En qué consiste la arquitectura de datos?

Una cosa es modelar los datos —es decir, representar qué entidades existen, cómo se relacionan y qué atributos tienen— y otra muy distinta es pensar en cómo gestionamos esos datos de principio a fin: desde que los recibimos hasta que los usamos en un dashboard o en una toma de decisiones.

Eso es lo que hace la arquitectura de datos: definir el recorrido completo que sigue la información.

Nos ayuda a responder preguntas como:

• ¿Dónde se almacenan los datos cuando llegan?
• ¿Cómo se transforman a lo largo del tiempo?
• ¿Cómo nos aseguramos de que son fiables, consistentes y trazables?

Para entenderlo, repasamos la evolución de los sistemas de almacenamiento:

• Bases de datos transaccionales: las clásicas bases donde se registran operaciones del día a día (ventas, usuarios, etc.). Óptimas para registrar, pero no para analizar.
• Data Warehouses: réplicas optimizadas para el análisis. Copiaban los datos transaccionales, los limpiaban, y los preparaban para reportes. Muy útiles, pero limitados a datos tabulares estructurados.
• Data Lakes: almacenamiento masivo y flexible. Puedes guardar desde CSVs hasta vídeos. Pero cuidado: sin orden, puede convertirse en un “Data Swamp” donde hay mucha información pero nada localizable.
• Data Lakehouse: el híbrido moderno. Combina la escalabilidad del Data Lake con la estructura y consultas del Data Warehouse. Gracias a tecnologías como Delta Lake o Apache Iceberg, permite hacer SQL sobre archivos distribuidos. Lo mejor de los dos mundos.

A partir de ahí, Databricks propuso un patrón llamado arquitectura Medallion, que organiza los datos por niveles de calidad y transformación y del que hablamos largo y tendido durante la sesión.

🔧 ¿Qué hacemos en esta sesión?

• Repasamos los conceptos fundamentales del modelado de datos ampliando lo que ya vimos en la Sesión 5, incluyendo los niveles conceptual, lógico y físico, y discuto estrategias clásicas como el modelo en Estrella, Inmon y Data Vault.
• El tema central de la sesión es la arquitectura de datos, y os explicaré la evolución desde los Data Warehouses tradicionales y Data Lakes hasta los modernos Data Lakehouses y las diferencias entre ellos.
• Durante la sesión hablaremos en detalle la arquitectura Medallion, explicando el propósito de las capas Bronce (datos crudos), Plata (datos limpios y enriquecidos) y Oro (datos agregados listos para el consumo).
• Después, veremos cómo aplicar este patrón a nuestro proyecto, identificando los datos clave a conservar de la API y definiendo las métricas iniciales que queremos obtener.

Con esta sesión terminamos de definir cómo gestionaremos nuestros datos de manera eficiente y escalable, asegurando la calidad y la trazabilidad necesarias para generar análisis fiables y de impacto.

¿Quieres ver cómo empezamos a construir nuestras capas de datos y aplicamos la teoría a la práctica?

Puedes acceder a la grabación completa aquí:

Sesión 7

El objetivo de esta sesión de una hora es profesionalizar nuestro proyecto de análisis de ofertas de empleo, aprendiendo cómo refactorizar un proyecto de datos para dejar atrás los notebooks y la fase de experimentación y construir una base sólida, segura y modular.

Aplicamos buenas prácticas de ingeniería de datos y preparamos el terreno para su automatización con Airflow.

Durante la sesión exploramos:

• Cómo convertir el código experimental de un notebook en funciones reutilizables y orquestables,
• Qué estructura de carpetas es recomendable para proyectos de analytics engineering,
• Cómo manejar nuestras variables sensibles (como claves API y credenciales de base de datos) de forma segura.

📂 ¿Cómo debe estructurarse un proyecto de datos moderno?

¿Tienes tu código en notebooks y quieres llevarlo a producción? ¿No sabes cómo estructurar un proyecto de datos de forma profesional?

Es normal.

Cuando empezamos un proyecto en Jupyter, todo suele estar en un único archivo.

Pero en cuanto queremos escalar, colaborar o automatizar, necesitamos separar responsabilidades y pensar como ingenieros de datos:

• ¿Cómo dividimos el código en funciones reutilizables?
• ¿Dónde ponemos la lógica de extracción, carga y enriquecimiento?
• ¿Cómo preparamos el proyecto para que Airflow pueda ejecutar tareas automáticamente?
• ¿Qué carpetas necesitamos para notebooks, configuraciones, SQL, y scripts Python?

En esta sesión trabajamos todo eso.

🔧 ¿Qué hacemos paso a paso?

• Implementamos una estructura modular con carpetas para extracción, carga, enriquecimiento y SQL.
• Refactorizamos funciones clave del notebook para que puedan ejecutarse desde Airflow.
• Configuramos variables de entorno para proteger nuestras claves API y credenciales.
• Creamos archivos requirements.txt, .env y definimos buenas prácticas de versionado en Git

💡 Si estás buscando cómo pasar de un notebook experimental a un pipeline profesional en un entorno colaborativo, esta sesión es tu hoja de ruta.

Sesión 8

El objetivo de esta sesión de una hora es aprender a crear un DAG en Airflow paso a paso y automatizar nuestro pipeline de análisis de ofertas de empleo.

Una vez hemos refactorizado el código del proyecto y ya tenemos las funciones de extracción, carga y transformación listas, ahora es el momento de orquestarlas en un flujo controlado, programado y escalable.

Durante la sesión configuramos el entorno, explicamos cómo funciona Airflow por dentro, y construimos nuestro primer DAG.

📌 ¿Qué es un DAG y cómo funciona Airflow?

Airflow es una herramienta que nos permite automatizar tareas que hacemos de forma repetitiva, como descargar datos, procesarlos o generar reportes.

Lo hace mediante algo llamado DAG: un conjunto de tareas conectadas entre sí que se ejecutan en un orden determinado.

Cada tarea puede ser un script de Python, un comando en la terminal o incluso algo que no hace nada pero sirve para marcar un paso (como los checkpoints).

Además, Airflow nos permite decidir cuándo ejecutar esas tareas (cada día, cada semana, o cuando queramos), guardar un historial de ejecuciones, ver errores y asegurarnos de que todo funciona correctamente.

🔧 ¿Qué hacemos en esta sesión?

• Vemos las partes que componen Airflow y cómo funciona.
• Configuramos Airflow con Docker y lo integramos con nuestro proyecto
• Exploramos el interfaz de Airflow para lanzar el DAG manualmente, monitorizarlo y solucionar errores
• Definimos el esqueleto de nuestro DAG para automatizar las tareas de scraping, guardado y análisis de datos

💡 Al final de la sesión tendrás claro cómo crear un DAG en Airflow paso a paso, desde un archivo .py hasta su ejecución automatizada dentro de un contenedor Docker.

¿Quieres pasar de ejecutar scripts manualmente a tener un flujo automatizado y monitorizado?

Entonces esta sesión es para ti 🤩

Sesión 9

En esta novena sesión del Proyecto LinkedIn, seguimos trabajando con Airflow utilizando el CLI de Astro.

Si en la sesión anterior sentamos las bases sobre qué teníamos que hacer para automatizar nuestro pipeline de análisis de ofertas de empleo, en esta sesión nos ponemos manos a la obra y vemos todo el código de nuestras DAGs.

⚙️ Cómo crear y depurar DAGs de Airflow en un proyecto real

En esta sesión vemos como hemos construido el código de las piezas por separado (extracción, enriquecimiento y transformación) y vemos cómo hacerlas fucnionar como un único sistema.

La orquestación con Airflow no solo consiste en programar tareas, sino en gestionar las dependencias entre ellas, monitorizar su ejecución y, lo más importante, saber cómo diagnosticar y solucionar los problemas cuando ocurren.

Veremos cómo los tres DAGs que hemos diseñado en Airflow trabajan juntos para transformar los datos crudos de la API en un modelo dimensional listo para el análisis, enfrentándonos a los desafíos y errores que surgen en un entorno real.

🔧 ¿Qué hacemos en esta sesión?

• Repasamos cómo pasamos del notebook inicial a un entorno orquestado con Astronomer.
• Creamos DAGs que automatizan la carga diaria de ofertas desde la API.
• Enriquecemos los datos con GPT-4.1 y los transformamos en estructuras que podamos analizar.
• Revisamos cómo Airflow ejecuta cada tarea, cómo depurar errores y cómo leer los logs.
• Exploramos la arquitectura de datos completa, desde la capa bronce hasta la gold.

Una sesión especialmente práctica para entender cómo automatizar todo el flujo de datos y construir una plataforma escalable y mantenible.

Sesión 10

Después de varias sesiones construyendo una arquitectura sólida, automatizando flujos de datos con Airflow y enriqueciendo nuestra base de datos con modelos de lenguaje, en esta décima sesión damos el salto al frontend de nuestro proyecto:

¡la visualización de datos!

📊 Cómo conectar Streamlit con un Data Warehouse

En esta sesión integramos Streamlit como nuevo servicio dentro de nuestro entorno de contenedores.

El objetivo: desarrollar un dashboard interactivo que nos permita visualizar los resultados del pipeline completo, desde la ingesta hasta la capa de análisis.

Aprendemos paso a paso:

• Cómo conectar Streamlit con nuestro Data Warehouse en PostgreSQL.
• Cómo consultar nuestro datamart para alimentar las visualizaciones.
• Cómo generar gráficos dinámicos con matplotlib directamente en Streamlit.

Además, diseñamos una primera visualización que muestra, para cada palabra clave de búsqueda (como data scientist o data engineer), cuáles son las habilidades técnicas más demandadas según los datos extraídos de las ofertas de empleo.

Esta sesión nos permite empezar a ver el potencial de nuestros datos 🚀

Sesión 11

En esta sesión del Proyecto LinkedIn de una hora de duración, nos centramos en las mejoras técnicas implementadas y los últimos ajustes necesarios antes de pasar el proyecto a producción en la nube.

🚀 Mejoras en la robustez del pipeline

Durante esta sesión revisamos todas las optimizaciones implementadas para hacer el proyecto más estable, eficiente y listo para producción:

Control avanzado de errores en las APIs

Hemos implementado un sistema completo de manejo de errores para las llamadas a Scraping Dog y OpenAI:

• Reintentos automáticos: Si una llamada a la API falla, el sistema reintenta automáticamente antes de marcar la tarea como fallida.
• Backoff exponencial: Cuando la API rechaza una conexión por sobrecarga, esperamos un tiempo que aumenta progresivamente en cada reintento, evitando saturar el servicio.
• Captura de excepciones: Bloques try-catch específicos para errores comunes de servidor y problemas de conexión, registrando información detallada en los logs.
• Gestión de timeouts: Control de tiempos de espera para evitar que las DAGs queden colgadas indefinidamente.

Optimización de llamadas concurrentes

Aprovechamos al máximo los límites de la API de Scraping Dog:

• Peticiones simultáneas: Pasamos de llamadas secuenciales a 5 peticiones concurrentes, el máximo permitido por la API, reduciendo drásticamente el tiempo de extracción.
• Código asíncrono: Implementación de funciones async/await en Python para gestionar las llamadas paralelas de forma eficiente.
• Control de rate limiting: Espaciado inteligente entre peticiones para no exceder los límites de la API y evitar rechazos.

Sistema de caché y prevención de duplicados

Para optimizar el uso de créditos de la API, implementamos:

• Caché en Google Cloud Storage: Guardamos un registro de todos los job IDs ya procesados que se compara antes de cada extracción.
• Filtrado previo: Identificamos ofertas nuevas comparando con el historial antes de hacer la segunda llamada a la API para obtener detalles.
• Ahorro de costes: El sistema reporta cuántas llamadas a la API se han ahorrado en cada ejecución gracias a este filtrado.

Almacenamiento resiliente en la nube

Implementamos una arquitectura de almacenamiento que previene pérdida de datos:

• Guardado incremental: Los datos se almacenan en Google Cloud Storage inmediatamente después de extraerse, antes de cualquier procesamiento.
• Particionado por fecha: Estructura de carpetas organizada por fechas que facilita la recuperación y auditoría de datos históricos.
• Formato Parquet: Almacenamiento eficiente que reduce el espacio ocupado comparado con CSV o JSON.
• Separación de errores: Las ofertas que fallan en el procesamiento se guardan en una carpeta específica para reintentos posteriores.

⚙️ Estado de las DAGs de Airflow

Las tres DAGs con las que terminamos la sesión:

• Job Ingestion to GCS: Extrae ofertas diariamente, identifica duplicados y almacena en Google Cloud Storage.
• Load from GCS to Postgres: Se dispara automáticamente al detectar nuevos datos y los carga a la tabla staging.
  • ⚠️ Problema identificado: la conexión a PostgreSQL no se carga automáticamente desde airflow_settings.yml y requiere configuración manual tras cada reinicio.
• Enriquecimiento: Procesa descripciones con GPT-4.1 Mini.
• Transformación: Crea el modelo de datos del proyecto

🛡️ Archivos sensibles y configuración local

Para mantener la seguridad del proyecto, evitar exponer información crítica y acostumbrarnos a seguir buenas prácticas, algunos archivos no están incluidos en el repositorio.

A continuación encontrarás el contenido de esos archivos que debes usar: