Зображення створене автором.

Оригінал можна знайти за посиланням https://vutr.substack.com.

Вступ

Якщо ви користувалися Notion, ви знаєте, що він дозволяє вам робити майже все - робити нотатки, планувати, складати списки для читання та управляти проектами.

Notion не є жорстким; він дозволяє налаштовувати речі до тих пір, поки ви не почуваєте себе комфортно.

У Notion все є блоками - текст, зображення, списки, рядки в базі даних і навіть сторінки.

Скріншот та декорації від автора 😉

Ці динамічні одиниці можна перетворювати на інші типи блоків або вільно переміщати всередині Notion.

Блоки - це ЛЕГОшки Notion.

Postgres правив усім.

Postgres правив усім!! Зображення створене автором.

Спочатку Notion зберігав усі блоки в базі даних Postgres.

У 2021 році в них було понад 20 мільярдів блоків.

Зараз блоки зросли до понад двохсот мільярдів сутностей.

До 2021 року вони помістили всі блоки в один екземпляр Postgres.

Тепер вони розділили базу даних на 480 логічних шарів і розподілили їх на 96 екземплярів Postgres, кожний відповідальний за 5 шарів.

У Notion бази даних Postgres обробляють все, від онлайн трафіку користувачів до офлайн аналітики та машинного навчання.

Розпізнавши вибухові потреби в аналітичних випадках використання, особливо їхні нещодавні функції Notion AI, вони вирішили побудувати окрему інфраструктуру для офлайн робочого навантаження.

Fivetrans та Snowflake

У 2021 році вони розпочали свою подорож з простим ETL, який використовував Fivetran, щоб завантажувати дані з Postgres до Snowflake, використовуючи 480 конекторів для запису 480 шарів в сирих таблицях Snowflake щогодини.

![зображення](https://miro.medium.com/v2/resize:fit:1400/0*4tTyeNmyLzdAwjlj.

markdown

Їхня перша концепція складу даних. Зображення створено автором.

Потім Notion би об'єднувала ці таблиці в одну велику таблицю для аналітики та обробки даних з використанням машинного навчання.

Проте, цей підхід мав деякі проблеми, коли дані в Postgres зростали:

Зображення створено автором.

Керування 480 підключеннями Fivetran є кошмаром.

• Користувачі Notion частіше оновлюють блоки, ніж додають нові. Цей інтенсивний паттерн оновлення уповільнює та збільшує вартість інгесту даних в Snowflake.
• Споживання даних стає складнішим та важчим (навантаження штучного інтелекту)

Notion вирушила на побудову власного озера даних.

Озеро

Вони хочуть побудувати рішення, яке надає наступне:

• Масштабований сховище даних для зберігання як сировинних, так і оброблених даних.
• Швидкий та ефективний процес інгесту даних та обчислень для будь-якого завдання. Особливо з їхніми важкими на оновлення блоками даних.

У 2022 році вони внедрили архітектуру власного озера даних, що інкрементально інгестувала дані з Postgres в Kafka за допомогою Debezium, а потім використовувала Apache Hudi для запису з Kafka в S3.

Зображення створено автором.

Об’єктне сховище буде виступати як кінцева точка для споживчих систем, обслуговуючи потреби аналітики, звітності та навантажень штучного інтелекту.

Вони використовували Spark як основний рушій обробки даних для роботи з мільярдами блоків поверх озера.

Відвести інгест даних та обчислювальне навантаження від Snowflake допомагає значно скоротити витрати.

Зміни з Postgres захоплюються конектором Kafka Debezium та потім записуються в S3 через Apache Hudi.

Notion обрав такий формат таблиць, оскільки він добре працює з їхнім інтенсивним на оновлення блоками робочим навантаженням та має вбудовану інтеграцію з повідомленнями CDC від Debezium.

Ось короткий опис того, як вони працюють з рішеннями:

Зображення створено автором.

_

Один з'єднувач Debeizum CDC на одного хоста Postgres.

• Компанія Notion розгорнула ці з'єднувачі на керованому Kubernetes на AWS (EKS).
• З'єднувач може обробляти десятки МБ/с змін рядків в Postgres.
• Один тема Kafka на кожну таблицю Postgres.
• Всі з'єднувачі будуть споживати дані з усіх 480 шардів і писати у ту саму тему для цієї таблиці.
• Вони використовують Apache Hudi Deltastreamer, Spark-засноване завдання вивантаження, для споживання повідомлень Kafka та запису даних у S3.
• Більшість завдань обробки даних написані на PySpark.
• Для складніших завдань Notion використовує Scala Spark. Крім того, вони використовують багатопотоковість та паралельну обробку для прискорення обробки 480 шардів.

Вигода

• Вивантаження даних з Snowflake до S3 зекономило Notion понад мільйон доларів у 2022 році, з ще більшими економіями у 2023 та 2024 роках.
• Загальний час вивантаження з Postgres до S3 та Snowflake значно скоротився, від більше ніж доби до кількох хвилин для невеликих таблиць та кількох годин для великих.
• Нова інфраструктура обробки даних відкриває більш розвинені можливості аналітики та продукту, дозволяючи успішно запустити функції штучного інтелекту Notion у 2023 та 2024 роках.

Заключення

Дякую за увагу до кінця. Як глибше досліджую, як великі технологічні компанії будують та керують своєю інфраструктурою для аналізу даних, я з нетерпінням чекаю можливості поділитися корисними уроками з мого шляху. До зустрічі в майбутніх статтях!

Тепер час засвоїти деякі цікаві посилання, які я знайшов на минулому тижні 😉

References

[1] XZ Tie, Натан Луї, Томас Чоу, Дарін Ім, Абхішек Моді, Венді Джіао, Побудова та масштабування дата-озера Notion (2024)

Перекладено з: How does Notion handle 200 billion data entities?