- Durante los últimos 3 años, los datos de Notion crecieron 10 veces debido al aumento de usuarios y contenido, y se duplicaron cada 6 a 12 meses
- Recientemente, Notion construyó y escaló su data lake para gestionar este crecimiento acelerado mientras cubría los requisitos de datos de casos de uso clave de producto y analítica, incluidas las funciones de Notion AI
El modelo de datos y el crecimiento de Notion
- Todo lo que se ve en Notion se modela como una entidad de "bloque" y se almacena en una base de datos Postgres con una estructura, esquema y metadatos relacionados consistentes
- Estos datos de bloques se duplicaron cada 6 a 12 meses: a inicios de 2021 había más de 20 mil millones de filas de bloques, y hoy hay más de 200 mil millones de bloques
La arquitectura del data warehouse de Notion en 2021
- Comenzaron su infraestructura de datos dedicada con un pipeline ELT simple que usaba Fivetran para ingerir datos desde el WAL de Postgres hacia Snowflake
- Configuraron 480 conectores, ejecutándose cada hora para 480 shards, para escribir en 480 tablas crudas de Snowflake, y luego fusionaban esas tablas en una sola tabla grande para casos de uso de analítica, reportes y machine learning
Desafíos al escalar
- A medida que crecían los datos en Postgres, enfrentaron varios problemas
- Operabilidad: el overhead de monitorear y administrar 480 conectores de Fivetran se volvió muy alto
- Velocidad, frescura de datos y costo: debido a la carga de trabajo única de Notion, centrada en actualizaciones, la ingesta hacia Snowflake se volvió más lenta y más costosa
- Soporte de casos de uso: la lógica de transformación de datos se volvió más compleja y pesada, superando las capacidades de la interfaz SQL estándar que ofrece un data warehouse tradicional
Construir y escalar el data lake interno de Notion
- Objetivos del data lake interno
- Establecer un almacén de datos capaz de guardar datos crudos y procesados a gran escala
- Permitir ingesta y cómputo rápidos, escalables, operables y rentables para todas las cargas de trabajo, especialmente para los datos de bloques de Notion centrados en actualizaciones
- Dar soporte a casos de uso para AI, búsqueda y otros productos que requieren datos desnormalizados
- No buscaban reemplazar por completo Snowflake y Fivetran ni soportar casos de uso en línea con requisitos estrictos de latencia
Diseño de alto nivel del data lake
- Usaron conectores CDC de Debezium para ingerir datos actualizados incrementalmente desde Postgres hacia Kafka, y luego Apache Hudi para escribir esas actualizaciones desde Kafka hacia S3
- Con estos datos crudos, realizaban transformaciones, desnormalización y enriquecimiento, y luego volvían a guardar los datos procesados en S3 o en sistemas downstream para satisfacer requisitos de analítica y reportes, así como necesidades de AI, búsqueda y otros productos
Decisiones de diseño
- Elegir el almacenamiento de datos y el lake: usar S3 como almacén de datos y lake para guardar todos los datos crudos y procesados, dejando el data warehouse y otros almacenes de datos orientados a producto aguas abajo
- Elegir el motor de procesamiento: seleccionar Spark, un framework open source, como motor principal de procesamiento de datos
- Preferir ingesta incremental sobre dumps por snapshot: durante la operación normal, ingerir incrementalmente los datos modificados de Postgres y aplicarlos continuamente en S3; en casos poco frecuentes, generar una sola vez un snapshot completo de Postgres para bootstrapear tablas en S3
- Simplificar la ingesta incremental: usar conectores CDC de Kafka Debezium para publicar en Kafka los datos incrementales modificados de Postgres, y Hudi para ingerir esos datos incrementales desde Kafka hacia S3
- Ingerir datos crudos antes del procesamiento: recolectar en S3 los datos crudos de Postgres sin procesamiento on-the-fly para establecer una única fuente de verdad y simplificar el debugging en todo el pipeline de datos
Escalado y operación del data lake
- Configuración de conectores CDC y Kafka: configuraron un conector CDC de Debezium por cada host de Postgres y lo desplegaron en un clúster de AWS EKS
- Configuración de Hudi: usaron Apache Hudi Deltastreamer para consumir mensajes de Kafka y replicar en S3 el estado de las tablas de Postgres
- Configuración del procesamiento de datos con Spark: aprovecharon PySpark para la mayoría de los trabajos de procesamiento de datos, y para tareas más complejas como recorrido de árboles y desnormalización aprovecharon el sólido rendimiento de Spark
- Configuración de bootstrap: configuraron el conector Debezium para recolectar cambios de Postgres hacia Kafka, usaron la tarea de exportación a S3 provista por AWS RDS para guardar en S3 el snapshot más reciente de las tablas de Postgres, y luego crearon un trabajo de Spark para leer esos datos desde S3 y escribirlos en formato de tabla Hudi
Resultados
- Comenzaron a desarrollar la infraestructura del data lake en la primavera de 2022 y la completaron en el otoño de ese mismo año
- Obtuvieron ahorros netos de más de 1 millón de dólares en 2022, y en 2023 y 2024 los ahorros fueron proporcionalmente mayores
- El tiempo de ingesta end-to-end desde Postgres hacia S3 y Snowflake se redujo de más de un día a unos minutos para tablas pequeñas, y a unas pocas horas como máximo para tablas grandes
- El data lake permitió lanzar con éxito las funciones de Notion AI en 2023 y 2024
2 comentarios
¿Podrían indicarme si hay documentación o materiales de referencia relacionados con lo anterior que hayan consultado?
Lo escribí mal jajaja
Lo encontré~~~