Cómo Airbnb Migró su Grafo de Identidad de 7 Mil Millones de Nodos a una Plataforma Interna de Knowledge Graph

Por qué un Knowledge Graph es Clave para Trust & Safety

Toda plataforma grande se enfrenta a un desafío fundamental: entender cómo usuarios, dispositivos y cuentas están conectados. Para Airbnb, estas conexiones son críticas para detectar fraudes, prevenir robos de cuenta y aplicar políticas de confianza.

El grafo de identidad de Airbnb es la columna vertebral de este esfuerzo. Modela usuarios y sus relaciones como vértices y aristas en una base de datos de grafos, permitiendo consultas como:

• “¿Esta nueva cuenta está vinculada a alguna cuenta previamente baneada?”
• “¿Este ID de dispositivo aparece en múltiples reservas sospechosas?”

A medida que la plataforma creció, el grafo explotó en complejidad — 7 mil millones de nodos, 11 mil millones de aristas, creciendo 5 millones de aristas por día. La arquitectura original no podía seguir el ritmo. Este case study recorre la evolución, la migración a una infraestructura interna de knowledge graph y las optimizaciones clave que lo hicieron posible.

Las Tres Iteraciones del Grafo de Identidad

Fase 1: Relacional + KV Store

Inicialmente, Airbnb almacenaba datos de usuarios en una base relacional y las listas de aristas como blobs JSON en un key-value store. A medida que la densidad del grafo aumentó, los joins se volvieron prohibitivamente caros y el enfoque JSON hizo que las consultas de recorrido fueran lentas y frágiles.

Puntos de dolor: Alto costo, baja escalabilidad, sin recorrido nativo de grafos.

Fase 2: SaaS de Grafos de Terceros

En 2021, Airbnb adoptó una base de datos de grafos gestionada (PaaS). Esto mejoró la escalabilidad horizontal e introdujo un lenguaje de consulta real (Gremlin). Sin embargo, surgieron nuevos desafíos:

• Latencia de cola larga: Nodos con alto factor de expansión causaban picos impredecibles en P99.
• Inestabilidad operativa: Se requerían reinicios manuales periódicos para mantener el rendimiento.
• Control limitado: Indexación fina y ajuste de consultas eran difíciles o imposibles.
• Vendor lock-in: Migrar a otra solución sería costoso.

Fase 3: Infraestructura Interna de Knowledge Graph

En 2024, Airbnb construyó una plataforma de grafos basada en JanusGraph (base de datos de grafos distribuida open source) con DynamoDB como backend de almacenamiento y OpenSearch para indexación. El grafo de identidad fue el primer tenant en migrar.

¿Por qué JanusGraph + DynamoDB?

• Separación de almacenamiento permitió usar la escalabilidad probada de DynamoDB mientras se controlaba la lógica del grafo.
• El lenguaje Gremlin se preservó, facilitando la migración.
• Código abierto significaba visibilidad total y capacidad de hacer parches.

// Ejemplo de consulta Gremlin usada en el grafo de identidad
// Encuentra todas las cuentas vinculadas a un usuario en hasta 3 saltos
g.V().has('user_id', 'usuario_objetivo')
  .repeat(__.bothE('cuenta_vinculada').otherV().simplePath())
  .times(3)
  .path()
  .limit(100)

Optimizaciones Clave para Rendimiento

Para cumplir con los requisitos de latencia de Airbnb, el equipo hizo varios cambios profundos en el motor JanusGraph:

1. Transacciones optimizadas: Reemplazó el bloqueo predeterminado de JanusGraph por escrituras condicionales y APIs de transacción de DynamoDB, reduciendo overhead y manteniendo integridad.
2. Ejecución paralela de consultas: La interfaz getMultiSlices se mejoró para obtener datos en paralelo, reduciendo la latencia en consultas con alto fan-out (ej: un usuario con miles de cuentas vinculadas).
3. Reescritura de consultas en el cliente:
   • Eliminación de steps Path donde era posible, reemplazándolos por verificaciones acíclicas condicionales para evitar consultas lentas no batch.
   • Optimización de steps side-effect para minimizar cómputo en operaciones de agregación.
4. Observabilidad: Integración del tracing distribuido de Airbnb en el fork interno, cerrando la brecha de observabilidad del open source.

// Ejemplo simplificado de optimización de consulta en el cliente
// Antes: usando path() step (puede ser lento)
// Después: usando dedup() y where() para garantizar resultados acíclicos
g.V().has('user_id', 'objetivo')
  .repeat(__.bothE('vinculado').otherV().dedup())
  .times(3)
  .where(without('visitados'))
  .dedup()

Estrategia de Migración: Lado a Lado con Tráfico Sombra

Airbnb no volteó un interruptor. La migración usó un enfoque cuidadoso de tráfico sombra:

1. La solución antigua (vendor) y la nueva solución interna corrieron en paralelo.
2. Ambos motores soportaban Gremlin, así que consultas idénticas pudieron ser comparadas lado a lado.
3. Después de que el benchmark confirmara que la solución interna cumplía con los requisitos de latencia y throughput, el tráfico de producción se fue moviendo gradualmente.

Resultados: ¿Qué Ganó Airbnb?

Limitaciones y Precauciones

• JanusGraph no es una bala de plata. Requiere experiencia operativa significativa para ajustarlo, especialmente para workloads con alto fan-out.
• La separación de almacenamiento añade complejidad. Gestionar JanusGraph y DynamoDB significa más partes móviles que una solución all-in-one.
• La optimización de consultas Gremlin sigue siendo manual. La reescritura descrita arriba requirió un entendimiento profundo tanto de los datos como del motor de consultas.
• No todos los casos de uso se benefician igual. Consultas con pocos saltos (1–2) pueden no ver mejoras dramáticas; las mayores ganancias están en recorridos multi-salto.

Conclusión: Construir vs. Comprar — Un Punto de Datos para tu Arquitectura

El viaje de Airbnb es un case study poderoso para cualquier equipo que esté considerando una infraestructura de knowledge graph. La decisión de construir una plataforma interna valió la pena en:

• Rendimiento: 10x más throughput de escritura y latencia P99 significativamente menor.
• Control: Capacidad total de ajustar, parchar y evolucionar el motor de grafos.
• Estabilidad: Sin más reinicios manuales, resolución de incidentes más rápida.

Sin embargo, este enfoque no es para todos. Si tu workload de grafos es pequeño (< 1B aristas) o tu equipo no tiene experiencia en bases de datos de grafos, un PaaS gestionado puede seguir siendo la opción correcta. Pero si estás escalando a miles de millones de nodos y necesitas consultas de recorrido por debajo de 100ms, el camino interno vale la pena considerarlo.

Próximos pasos para tu aprendizaje:

• Controlando el Determinismo de Punto Flotante en CUDA: Un Análisis Profundo de la Nueva API de CUB — otro análisis profundo de infraestructura crítica de rendimiento.
• Construyendo el Gráfico de Pastel Perfecto en CSS: Un Enfoque Semántico y Accesible — un dominio completamente diferente, pero muestra el mismo principio de elegir la herramienta correcta para el trabajo.

Fuente: Este análisis está basado en el post de Ingeniería de Airbnb sobre Escalando el grafo de identidad de Airbnb con una infraestructura unificada de knowledge graph.