- Au cours des 3 dernières années, les données de Notion ont été multipliées par 10 en raison de la hausse du nombre d’utilisateurs et des contenus, et elles ont doublé tous les 6 à 12 mois
- Notion a construit et fait évoluer son data lake pour gérer cette croissance rapide tout en répondant récemment aux besoins en données de cas d’usage majeurs côté produit et analytique, notamment les fonctionnalités Notion AI
Modèle de données et croissance chez Notion
- Tout ce qui est visible dans Notion est modélisé comme une entité « bloc » et stocké dans une base de données Postgres avec une structure, un schéma et des métadonnées associées cohérents
- Ces données de blocs ont doublé tous les 6 à 12 mois : elles comptaient plus de 20 milliards de lignes de blocs au début de 2021, contre plus de 200 milliards aujourd’hui
Architecture de l’entrepôt de données de Notion en 2021
- L’infrastructure de données dédiée a commencé avec un pipeline ELT simple utilisant Fivetran pour ingérer les données du WAL de Postgres vers Snowflake
- 480 connecteurs exécutés toutes les heures ont été configurés pour 480 shards afin d’écrire dans 480 tables Snowflake brutes, puis ces tables ont été fusionnées en une seule grande table pour les cas d’usage d’analyse, de reporting et de machine learning
Défis liés au passage à l’échelle
- Plusieurs problèmes sont apparus avec l’augmentation du volume de données Postgres
- Exploitabilité : la surcharge liée à la supervision et à la gestion de 480 connecteurs Fivetran est devenue très élevée
- Vitesse, fraîcheur des données et coût : en raison de la charge de travail propre à Notion, centrée sur les mises à jour, l’ingestion des données vers Snowflake est devenue plus lente et plus coûteuse
- Prise en charge des cas d’usage : la logique de transformation des données est devenue plus complexe et plus lourde, dépassant les capacités de l’interface SQL standard fournie par un data warehouse classique
Construire et faire évoluer le data lake interne de Notion
- Objectifs du data lake interne
- Établir un stockage de données capable de conserver à grande échelle les données brutes et les données traitées
- Permettre une ingestion et un calcul rapides, évolutifs, exploitables et économes en coûts pour toutes les charges de travail, en particulier pour les données de blocs de Notion centrées sur les mises à jour
- Prendre en charge les cas d’usage pour l’IA, la recherche et d’autres produits nécessitant des données dénormalisées
- L’objectif n’était pas de remplacer totalement Snowflake et Fivetran, ni de prendre en charge des cas d’usage en ligne exigeant une latence stricte
Design de haut niveau du data lake
- Les données mises à jour de façon incrémentale sont ingérées de Postgres vers Kafka à l’aide de connecteurs CDC Debezium, puis écrites de Kafka vers S3 avec Apache Hudi
- À partir de ces données brutes, des transformations, dénormalisations et enrichissements sont effectués, puis les données traitées sont à nouveau stockées dans S3 ou dans des systèmes en aval afin de répondre aux besoins d’analyse et de reporting ainsi qu’aux besoins produits liés à l’IA, à la recherche et à d’autres usages
Choix de conception
- Choix du stockage de données et du lake : utilisation de S3 comme stockage et data lake pour conserver toutes les données brutes et traitées, avec le data warehouse et d’autres stockages de données orientés produit placés en aval
- Choix du moteur de traitement : sélection de Spark, framework open source, comme moteur principal de traitement des données
- Préférence pour l’ingestion incrémentale plutôt que les dumps snapshot : en fonctionnement normal, les données Postgres modifiées sont ingérées de manière incrémentale et appliquées en continu à S3 ; dans de rares cas, un snapshot complet de Postgres est généré une seule fois pour initialiser les tables dans S3
- Simplification de l’ingestion incrémentale : utilisation de connecteurs CDC Kafka Debezium pour publier dans Kafka les changements incrémentaux des données Postgres, puis de Hudi pour ingérer ces données incrémentales de Kafka vers S3
- Ingestion des données brutes avant traitement : les données Postgres brutes sont ingérées dans S3 sans traitement à la volée afin d’établir une source unique de vérité et de simplifier le débogage de l’ensemble du pipeline de données
Extension et exploitation du data lake
- Configuration des connecteurs CDC et de Kafka : un connecteur CDC Debezium a été configuré par hôte Postgres et déployé sur un cluster AWS EKS
- Configuration de Hudi : Apache Hudi Deltastreamer est utilisé pour consommer les messages Kafka et répliquer dans S3 l’état des tables Postgres
- Configuration du traitement de données avec Spark : PySpark est utilisé pour la majorité des traitements, et pour les tâches plus complexes comme la traversée d’arbres et la dénormalisation, les excellentes performances de Spark sont mises à profit
- Configuration du bootstrap : le connecteur Debezium est configuré pour ingérer les changements Postgres vers Kafka, l’export vers S3 fourni par AWS RDS est utilisé pour stocker dans S3 le snapshot le plus récent des tables Postgres, puis un job Spark lit ces données depuis S3 et les écrit au format de table Hudi
Résultats
- Le développement de l’infrastructure de data lake a commencé au printemps 2022 et s’est achevé à l’automne de la même année
- Les économies nettes ont dépassé 1 million de dollars en 2022, avec des gains proportionnellement plus élevés en 2023 et 2024
- Le temps d’ingestion de bout en bout de Postgres vers S3 et Snowflake est passé de plus d’une journée à quelques minutes pour les petites tables et à quelques heures au maximum pour les grandes tables
- Le data lake a permis de lancer avec succès les fonctionnalités Notion AI en 2023 et 2024
2 commentaires
Pourriez-vous me faire savoir s’il existe des documents ou des références en lien avec le contenu ci-dessus ?
Je me suis trompé en écrivant, haha
Je l’ai trouvé~~~