Как Notion обрабатывает 200 миллиардов объектов данных

Переход от PosgreSQL-only решения к собственному DataLake для отделения read нагрузки под нужды аналитики и AI.

Вступление

Если вы использовали Notion, то знаете, что он позволяет вам делать практически всё — создавать заметки, планировать, составлять списки чтения и управлять проектами.

Notion является гибким инструментом. Вы можете настраивать пространство до тех пор, пока не почувствуете, что достигли желаемого.

Всё в Notion представляет собой блок — текст, изображения, списки, строки базы данных и даже страницы.

Эти динамические единицы могут быть преобразованы в блоки других типов или свободно перемещаться внутри Notion.

Блоки — это LEGO от Notion.

Postgres ruled them all.

Изначально Notion хранила все блоки в базе данных Postgres. В 2021 году их было более 20 миллиардов. Сейчас количество блоков выросло до 200 миллиардов.

До 2021 года всё помещалось в один инстанц Postgres.

Сейчас база данных разбита на 480 логических сегментов, которые распределены по 96 инстанцам Postgres, так что каждый отвечает за 5 сегментов.

Postgres обрабатывал всё — от онлайн-трафика пользователей до офлайн-аналитики и машинного обучения.

Осознавая большие запросы для аналитики и AI было решено создать под них собственную инфраструктуру.

Fivetrans и Snowflake

Сначала в 2021 году был создан простой ETL, который использовал Fivetran для передачи данных из Postgres в Snowflake. Использовались 480 коннекторов для записи 480 сегментов в необработанные таблицы Snowflake ежечасно.

Затем Notion объединяла эти таблицы в одну большую для анализа и машинного обучения.

Но у этого подхода возникли некоторые проблемы, когда объем данных Postgres вырос:

Управление 480 коннекторами Fivetran оказалось кошмаром:

• Пользователи Notion обновляют блоки чаще, чем добавляют новые. Этот паттерн интенсивного обновления замедляет и увеличивает стоимость обработки данных Snowflake.

• Потребление данных становится все более сложным и тяжелым (рабочие нагрузки искусственного интеллекта)

Notion приступила к созданию собственного хранилища данных.

Озеро данных

Были поставлены следующие требования для системы:

• Масштабируемое хранилище данных для хранения как необработанных, так и обработанных данных.

• Быстрый и экономичный прием данных и вычисления для любой рабочей нагрузки. Особенно с часто обновляемыми данными.

В 2022 году была внедрена собственная архитектура DataLake, суть которой в передачи данных из Postgres в Kafka с помощью Debezium, с последующей передачей в Apache Hudi и S3.

Такое хранилище объектов выступает в качестве конечной точки для потребителей:

• аналитических систем

• системм отчетности

• AI систем

Для обработки получаемых миллиардов блоков и их обновлений используется Spark.

Благодаря созданию такой подсистемы получилось значительно сократить текущие расходы.

Ниже представлен основной пайплайн выгрузки данных:

1 коннектор Debeizum CDC на 1 инстанц Postgres.

• Коннекторы деплоятся и управляются в Kubernetes на AWS (EKS)

• Коннектор может обрабатывать изменения строк Postgres со скоростью десятки МБ/с.

• Один топик Kafka на 1 Postgres таблицу.

• Все коннекторы потребляют данные из 480 сегментов и записывают в соответствующий топик для данной таблицы.

• Apache Hudi Deltastreamer используется для получения сообщений из Kafka и записи данных в S3.

• Большинство заданий по обработке данных были написаны в PySpark.

• Для более сложных заданий используется Scala Spark. Notion также использует многопоточность и параллельную обработку для ускорения обработки 480 сегментов.

Выигрыш

• Выгрузка данных из Snowflake в S3 сэкономила Notion более миллиона долларов в 2022 году, с еще более значительной экономией в 2023 и 2024 годах.

• Общее время по приёму и обработки данных с Postgres значительно сократилось: с более чем суток до нескольких минут для небольших таблиц и пары часов для больших.

• Новая инфраструктура данных открывает дополнительные возможности по использованию аналитики. Она помогла успешно внедрить новый функционал искусственного интеллекта в 2023 и 2024 годах.

Вместо завершения

Больше распределенных отказоустойчивых систем, паттернов, архитектурных кат, System Design интервью в telegram сообществе system_design_world.