- In den vergangenen drei Jahren sind die Daten bei Notion durch das Wachstum von Nutzern und Inhalten um das Zehnfache gestiegen und haben sich alle 6 bis 12 Monate verdoppelt.
- Um dieses rasante Wachstum zu bewältigen und zugleich die Datenanforderungen wichtiger Produkt- und Analyse-Use-Cases, einschließlich der jüngsten Notion-AI-Funktionen, zu erfüllen, hat Notion seinen Data Lake aufgebaut und skaliert.
Datenmodell und Wachstum bei Notion
- Alles, was man in Notion sieht, wird als Entität vom Typ "Block" modelliert und mit einer konsistenten Struktur, einem konsistenten Schema und zugehörigen Metadaten in einer Postgres-Datenbank gespeichert.
- Diese Blockdaten haben sich alle 6 bis 12 Monate verdoppelt: Anfang 2021 gab es mehr als 20 Milliarden Block-Zeilen, heute sind es über 200 Milliarden Blöcke.
Die Data-Warehouse-Architektur von Notion im Jahr 2021
- Die dedizierte Dateninfrastruktur begann mit einer einfachen ELT-Pipeline, die mithilfe von Fivetran Daten aus dem Postgres-WAL in Snowflake einspeiste.
- Es wurden 480 Connectoren eingerichtet, die stündlich für 480 Shards liefen und in 480 rohe Snowflake-Tabellen schrieben; diese Tabellen wurden anschließend zu einer großen Tabelle für Analyse-, Reporting- und Machine-Learning-Use-Cases zusammengeführt.
Herausforderungen bei der Skalierung
- Mit dem Wachstum der Postgres-Daten traten mehrere Probleme auf.
- Betriebsfähigkeit: Der Aufwand für Überwachung und Verwaltung von 480 Fivetran-Connectoren wurde sehr hoch.
- Geschwindigkeit, Datenaktualität und Kosten: Aufgrund von Notions einzigartig updatezentrierter Workload wurde die Einspeisung nach Snowflake langsamer und teurer.
- Unterstützung von Use-Cases: Die Logik für Datentransformationen wurde komplexer und schwergewichtiger und überstieg die Möglichkeiten der standardmäßigen SQL-Schnittstelle eines klassischen Data Warehouse.
Aufbau und Skalierung von Notions internem Data Lake
- Ziele des internen Data Lake
- Aufbau eines Datenspeichers, der rohe und verarbeitete Daten in großem Maßstab speichern kann.
- Schnelle, skalierbare, betreibbare und kosteneffiziente Datenerfassung und Berechnung für alle Workloads, insbesondere für Notions updatezentrierte Blockdaten.
- Unterstützung von Use-Cases für AI, Suche und andere Produkte, die denormalisierte Daten benötigen.
- Es war nicht beabsichtigt, Snowflake und Fivetran vollständig zu ersetzen oder Online-Use-Cases mit strengen Latenzanforderungen zu unterstützen.
High-Level-Design des Data Lake
- Mit dem Debezium-CDC-Connector werden inkrementell aktualisierte Daten aus Postgres in Kafka eingespeist; anschließend werden diese Updates mit Apache Hudi aus Kafka nach S3 geschrieben.
- Auf Basis dieser Rohdaten werden Transformation, Denormalisierung und Anreicherung durchgeführt; danach werden die verarbeiteten Daten erneut in S3 oder in nachgelagerten Systemen gespeichert, um Anforderungen aus Analyse und Reporting sowie von AI, Suche und anderen Produkten zu erfüllen.
Designentscheidungen
- Wahl von Datenspeicher und Lake: S3 wurde als Datenspeicher und Lake gewählt, um alle rohen und verarbeiteten Daten zu speichern; das Data Warehouse und andere produktnahe Datenspeicher sind nachgelagert.
- Wahl der Processing Engine: Das Open-Source-Framework Spark wurde als zentrale Engine für die Datenverarbeitung ausgewählt.
- Bevorzugung inkrementeller Erfassung gegenüber Snapshot-Dumps: Im Normalbetrieb werden geänderte Postgres-Daten inkrementell erfasst und fortlaufend nach S3 übertragen; in seltenen Fällen wird einmalig ein vollständiger Postgres-Snapshot erzeugt, um Tabellen in S3 zu bootstrappen.
- Vereinfachung der inkrementellen Erfassung: Mit dem Kafka-Debezium-CDC-Connector werden inkrementell geänderte Postgres-Daten in Kafka veröffentlicht, und Hudi erfasst die inkrementellen Daten aus Kafka nach S3.
- Erfassung der Rohdaten vor der Verarbeitung: Um eine Single Source of Truth zu schaffen und das Debugging über die gesamte Datenpipeline hinweg zu vereinfachen, werden rohe Postgres-Daten ohne On-the-fly-Verarbeitung in S3 erfasst.
Skalierung und Betrieb des Data Lake
- Einrichtung von CDC-Connectoren und Kafka: Pro Postgres-Host wurde ein Debezium-CDC-Connector eingerichtet und in einem AWS-EKS-Cluster bereitgestellt.
- Hudi-Setup: Apache Hudi Deltastreamer wird verwendet, um Kafka-Nachrichten zu verarbeiten und den Zustand von Postgres-Tabellen in S3 zu replizieren.
- Spark-Setup für die Datenverarbeitung: Für die meisten Datenverarbeitungsaufgaben wird PySpark eingesetzt; bei komplexeren Aufgaben wie Baum-Traversierung und Denormalisierung wird die starke Performance von Spark genutzt.
- Bootstrap-Setup: Der Debezium Connector wird so konfiguriert, dass Postgres-Änderungen nach Kafka erfasst werden; anschließend wird mit einem von AWS RDS bereitgestellten Export nach S3 der aktuelle Snapshot der Postgres-Tabellen in S3 gespeichert, danach liest ein Spark-Job diese Daten aus S3 und schreibt sie im Hudi-Tabellenformat.
Ergebnisse
- Die Entwicklung der Data-Lake-Infrastruktur begann im Frühjahr 2022 und wurde im Herbst desselben Jahres abgeschlossen.
- Im Jahr 2022 ergaben sich Nettoeinsparungen von über 1 Million US-Dollar; 2023 und 2024 fielen die Einsparungen proportional noch höher aus.
- Die End-to-End-Erfassungszeit von Postgres nach S3 und Snowflake wurde von mehr als einem Tag auf wenige Minuten bei kleinen Tabellen und auf höchstens einige Stunden bei großen Tabellen reduziert.
- Der Data Lake ermöglichte die erfolgreiche Einführung der Notion-AI-Funktionen in den Jahren 2023 und 2024.
2 Kommentare
Könnten Sie mir bitte mitteilen, welche Dokumente oder Referenzen sich auf den obigen Inhalt beziehen?
Ich habe Unsinn geschrieben, hahaha.
Ich habe es gefunden~~~