Переход от 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.
Комментарии (8)
sved
23.09.2024 17:12Сам писал небольшой сервис по выгрузки данных из Kafka в S3 в parquet формате. Поэтому не понимаю зачем вам Spark для такой простой задачи. У вас какие-то сложные преобразования в процессе происходят?
avovana7 Автор
23.09.2024 17:12Насколько я понял, они считают что для такого большого объёма часто меняющихся данных нужны представленные инструменты. Нет данных по их анализу рынка решений. Просто итог, что выбрали такое решение. Возможно Spark нужен для каких-то доп. преобразований на лету.
Насколько parquet оказался простым для понимания, интеграции, использования? Выявились ли какие-то подводные камни в процессе эксплуатации созданного сервиса?
vvbob
То больше не будете, потому что некоторые люди не совсем люди для Notion
edward_freedom
ты точно винишь в этом ноту?
vvbob
Точно
edward_freedom
что, взяли и просто так ограничили доступ?
vvbob
А что, нет?
Atreides07
del