[Перевод] Как 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.
Такое хранилище объектов выступает в качестве конечной точки для потребителей:
Для обработки получаемых миллиардов блоков и их обновлений используется 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.
