Data-команды должны стать командами контекста

Context engineering = управление данными + инженерия данных + наука о данных.

Помните, как ваша компания подключила BI-инструмент напрямую к продакшен-базе данных? Цифры постоянно были неверными. Никто не доверял дашбордам — поэтому мы построили data-стэки, чтобы это исправить.

AI-агенты сегодня — это эквивалент BI-инструментов, подключённых к продакшен-БД. Теперь у каждой компании есть внутренние AI-агенты, подключённые к сырым источникам контекста: дискам, Notion, почте. Это вроде бы работает, но полностью доверять ответам нельзя.

Context engineering — это создание источников истины для всех знаний компании надёжным и эффективным способом. И именно этим data-команды занимались с данными на протяжении многих лет.

Context engineering требует ключевых навыков, которыми обладают data-команды:

• Context Engineering = управление данными + инженерия данных + наука о данных
• Context engineering требует управления для определения источников истины контекста
• Context engineering требует инженерии для их загрузки и консолидации
• Context engineering требует науки для измерения и повышения надёжности AI

Что такое context engineering?

Context engineering направлен на создание оптимального контекста для AI-агентов.

Что такое оптимальный контекст для агента?

• Доля ответов: процент вопросов, на которые агент действительно может ответить
• Точность: процент ответов, которые являются корректными
• Стоимость: расходы на LLM, которые несёт агент
• Скорость: насколько быстро агент отвечает

Какие компромиссы нужно оптимизировать?

Слишком мало контекста → неправильные ответы или их отсутствие.
Агент знает недостаточно. Он галлюцинирует, упускает нюансы или полностью сдаётся.

Слишком много контекста → дорого и запутанно.

Входные токены могут очень быстро увеличить счёт за LLM (1 миллион токенов в Claude Opus 4.5 стоит $5). Вызов с большим объёмом контекста легко может отправлять 50–100 тыс. токенов на один запрос, что будет стоить ~50 центов. И помимо стоимости, нерелевантный контекст размывает сигнал — модель путается в шуме.

Как можно спроектировать контекст?

Выбирайте, какие источники включать, а какие исключать.

Определяйте, какой контент является источником истины по конкретной теме (правильное определение, самый свежий источник). Иногда вы можете обнаружить, что сами изначально не были в этом уверены.

Создавайте новый контекст там, где его ещё нет.

Форматируйте контекст так, чтобы модель могла эффективно его парсить: делайте его более модульным, хорошо структурированным.

Коротко говоря, context engineering следует тем же принципам, что и data engineering: измерять, итерировать, оптимизировать. Отслеживайте производительность вашего агента. Определяйте причины сбоев. Добавляйте недостающий контекст. Тестируйте улучшения. Повторяйте.

Управление контекстом: источник истины контекста — это новый источник истины данных

Нам нужно управление контекстом так же, как раньше нам было нужно управление данными.

Нам было нужно управление данными, потому что без него «выручка» означала три разных вещи в зависимости от того, кого вы спрашивали. Команда маркетинга считала валовые бронирования. Финансы считали чистый ARR. Продуктовая команда считала активные подписки. Нет метрического слоя, нет канонического определения — поэтому каждый дашборд рассказывал свою историю.

Сегодня нам нужно управление контекстом, потому что знания компании имеют ту же самую проблему. Спросите «какова наша политика возвратов?» — и ответ будет зависеть от того, какой документ агент найдёт первым: устаревший Notion, последний ответ в Zendesk или сообщение от юридического отдела в Slack за прошлый квартал. А иногда никто на самом деле и не задумывался, каким должен быть правильный ответ.

Многие специалисты по данным помнят тревожные времена, когда приходили в компанию, где BI был подключён напрямую к продакшен-базе данных. Все данные были на месте, но ни одна цифра не совпадала с другой, всё работало медленно и болезненно. Сегодня мы делаем ровно то же самое, подключая AI ко всем знаниям нашей компании.

Мы все знаем, что знания компании полны неточностей, устаревших элементов и противоречий. Поэтому подключать агента напрямую к этому хаосу — не самая лучшая идея.

Нам нужен контекстный слой: единый, управляемый, версионируемый источник истины для знаний компании. Чёткий ответ на каждый вопрос, с которым может столкнуться агент. И нам нужна инфраструктура, чтобы его строить и поддерживать.

Context engineering: контекстный стек — это data-стек

• Чтобы создать источники истины данных, мы построили data-стек.
• Чтобы создать источники истины контекста, нам нужен контекстный стек.

Ситуация сегодня такая же, как с данными 10 лет назад: у нас есть источники, у нас есть инструменты потребления. Но у нас нет промежуточного слоя — контекстного ETL-слоя.

Нам нужны:

• Инструменты ingestion для автоматического подтягивания источников контекста
• Инструменты трансформации для выбора источника истины контекста
• Контекстный слой как источник истины знаний компании
• Оркестрация для поддержания актуальности контекста

Мониторинг AI для измерения и отслеживания производительности нашего контекста в AI-агентах

Некоторые data-команды уже начали собирать части этого самостоятельно. Я видел, как команды пишут скрипты для выгрузки метаданных схем и статистики профилирования из хранилища, синхронизируют документацию из data-каталога или отбирают проверенные запросы из BI-инструмента в markdown-файлы. Это работает — но это множество скриптов и постоянная поддержка.

С мониторингом всё ещё сложнее. Большинство инструментов для аналитических агентов пока не поддерживают фреймворки оценки, поэтому нет простого способа построить unit-тесты, которые проверяют, что ваш контекст по-прежнему выдаёт правильные ответы после изменений.

Когда у нас есть управление и стек, нам нужно использовать техники data science, чтобы итерироваться и улучшать контекст.

Context sciences: тонкая настройка контекста как параметров ML-модели

В ML вы определяете метрику успеха (accuracy и т.д.) и имеете train/test-набор размеченных данных. Затем вы настраиваете параметры, признаки, обучающие выборки. После каждого изменения измеряете производительность, пока не найдёте оптимум.

В context engineering должен быть тот же цикл. Вы определяете метрики успеха (надёжность, стоимость и т.д.). Ваши параметры — это источники истины контекста, форматирование контекста, инструменты. Вы можете создать набор unit-тестов из промптов и ожидаемых ответов. Вы меняете контекст, заново прогоняете тестовые промпты, измеряете влияние, оставляете то, что работает.

Дополнительная сложность — как измерять метрики → стоимость и скорость измерить легко, но для оценки надёжности агента нужны более специализированные инструменты: проверять использованные файлы? точное совпадение? LLM как судья?

Чтобы это реализовать, нужно построить собственный evaluation framework. Определить KPI, которые вы будете отслеживать — что такое успех агента, как его измерять, какие ещё параметры важны (стоимость, скорость и т.д.). Затем создать набор unit-тестов и тонко настраивать контекст, измеряя производительность на разных наборах контекста.

Как начать переход уже сейчас

Как вы видите, контекстный стек пока ещё не сформирован. Нам всё ещё не хватает инструментов для открытого курирования и улучшения контекста.

Я думаю, что первым шагом для data-команд может быть демонстрация того, что они владеют context engineering в своей области: можете ли вы действительно заставить контекст для вашего аналитического агента работать?

Как я показывал в своих предыдущих статьях с бенчмарками аналитических агентов, готовые решения «из коробки» не работают и являются чёрными ящиками контекста. Если data-команды инвестируют в context engineering для собственных аналитических агентов, я уверен, они смогут показать, что это работает лучше, чем решения «из коробки».

Два подхода уже сейчас позволяют войти в context engineering:

• AI-агенты, работающие с файловой системой (Cursor, Claude Code, Cowork, Codex)
• Эти инструменты читают контекст напрямую из файлов, которыми вы управляете. Вы точно видите, что знает агент, можете изменить это, отредактировав файл, и сразу измерить эффект.
• Кроме того, можно построить evaluation framework поверх этого, поскольку всё доступно через код.

Собственные (in-house) агенты

Если вы построили собственного агента, вы контролируете весь конвейер контекста: какие элементы контекста добавлять и как оценивать агента. Создайте набор unit-тестов из промптов и начните прогонять их в разных сценариях контекста.

Ссылки на дополнительные статьи / материалы

• GitHub: 12-Factor Agents — Principles for building reliable LLM applications
• Context Engineering: A Guide With Examples
• GitHub: OpenWork
• GitHub: Data Formulator: AI-powered Data Visualization

Сайты со Skills для ai-agents

• skills.sh
• skillhub.club
• skillsmp.com
• GitHub: Awesome Agent Skills

Обучающие материалы по ai, llm

• GitHub: Microsoft AI Agents for Beginners — A Course
• GitHub: AI Agents From Scratch
• GitHub: Codes/Notebooks for AI Projects
• RAG Zero to Hero Guide
• Advanced RAG Techniques: Elevating Your Retrieval-Augmented Generation Systems
• RAG From Scratch
• GitHub: Skills, MCP servers, Custom Agents, Agents.md for SDKs to ground Coding Agents
• Model Context Protocol (MCP) Curriculum for Beginners
• 63 Must-Know LLMs Interview Questions in 2026

Data Engineering AI

• GitHub Astronomer: AI agent tooling for data engineering workflows — Includes an MCP server for Airflow, a CLI tool (af) for interacting with Airflow from your terminal, and skills that extend AI coding agents with specialized capabilities for working with Airflow and data warehouses.

Сообщение Context engineering = data governance + data engineering + data science появились сначала на DataTalks.RU. Data Engineering / DWH / Data Pipeline.

YouTube

• Ну НАСТОЯЩИЙ Senior! 10 лет опыта и экспертиза абсолютно во ВСЁМ? / Техсобес Senior Python Developer
• ТОП 70 ВОПРОСОВ НА СОБЕСЕДОВАНИИ SENIOR PYTHON DEVELOPER
• #33 Собеседование Python 2025 в BIG TECH компанию | Разбор вопросов
• Python разработчик | Собеседование с задачей из Яндекса. Максим Никулин
• «Техническое собеседование python-разработчика уровня мидл»

Рекомендации по подготовке к интервью в разных компаниях

• ТБанк: Как проходит интервью по Python
• Подготовка к алгоритмической секции (Яндекс):
  • https://leetcode.com/explore/featured/card/top-interview-questions-easy/127/strings/885/
  • https://leetcode.com/problems/kth-smallest-element-in-a-bst/
  • https://leetcode.com/problems/group-anagrams/
  • https://leetcode.com/problems/decode-ways/
  • https://leetcode.com/problems/word-break/
  • https://leetcode.com/problems/integer-to-roman/
  • Строки, массивы
  • Хеш-таблицы, словари
  • Обход двоичного дерева
  • Реализация различных примитивов: счётчиков, кешей и т. д.

Подборки задач (Leetcode и другие)

• Blind 75 LeetCode Questions
• neetcode.io
• Best Free Coding Interview Prep Resources in 2026 (Complete List)
• Coding Interview Prep (awesome interview)
• Моя подборка задач Easy уровня на Leetcode:
  • 1. Arrays Easy
  • 2. String Easy
  • 3. Sorting Easy
  • 4. Counting Easy
• Решение задач по алгоритмам «Подготовка к собеседованиям (задачи)»

Сообщение Подготовка к собеседованию Python появились сначала на DataTalks.RU. Data Engineering / DWH / Data Pipeline.

Test / Test Case (тест / тест-кейс) — Одиночная проверка поведения кода: функция, имя которой начинается с test_. Pytest автоматически обнаруживает и запускает такие тесты.

Assertion (ассерция / утверждение) — Проверка, выраженная через стандартный Python-оператор assert. Pytest делает assert-интроспекцию — показывает подробный разбор выражения при ошибке, что упрощает диагностику.

Assertion Introspection (интроспекция ассерций) — Особенность Pytest: при провале assert показываются подробности выражения (значения левой/правой части, вложенные выражения и т.д.).

Fixture (фикстура) — Функция, отмеченная декоратором @pytest.fixture, которая подготавливает окружение (данные, подключения и т. д.) для тестов и/или выполняет очистку после. Тесты “запрашивают” фикстуру через аргументы функций.

Scope (область действия) фикстуры может быть:

• function — на каждый тест,
• class — на класс,
• module — на модуль,
• package — на пакет,
• session — на весь прогон.

Marker (маркер) — Метаданные, которыми помечаются тесты для отнесения их к категориям/группам (например, @pytest.mark.slow, @pytest.mark.integration), а также изменения их поведения. Маркеры упрощают выборку тестов при запуске с помощью опции -m.

Mock — объект-заглушка, который заменяет реальный объект в тестах и позволяет проверять, как он использовался. Monkeypatch — фикстура pytest для временного изменения атрибутов, словарей или environment variables. Используется для изоляции тестируемого кода от его зависимостей (например, подмена запроса к API возвратом готовых данных).

Parametrization (параметризация) — Механизм запуска одного теста с разными наборами аргументов, обычно через декоратор @pytest.mark.parametrize. Это позволяет покрывать больше сценариев без копирования кода.

Skip / Skipif (пропуск теста) — Маркер или вызов (pytest.mark.skip, pytest.mark.skipif) для пропуска теста в определённых условиях (например, на неподходящей платформе).

XFail / Expected Failure (ожидаемо падающий тест) — Маркер pytest.mark.xfail для тестов, которые ожидаемо должны упасть (например, из-за известной ошибки). Их падение не считается ошибкой прогонки.

Plugins (плагины) — Расширения, которые добавляют Pytest-функциональность (например, отчеты, параллельный запуск, интеграции). Pytest имеет богатую экосистему плагинов.
Популярные плагины:

• pytest-cov: интеграция с coverage.py для анализа покрытия кода
• pytest-xdist: для параллельного запуска тестов
• pytest-django: для тестирования Django-приложений
• pytest-asyncio: для тестирования asyncio-кода

Conftest.py — Специальный файл Python, который используется для хранения общих фикстур, плагинов и хуков для всего проекта. Фикстуры и плагины, объявленные в conftest.py, автоматически обнаруживаются и становятся доступными во всех тестах того же package и его подпакетах. Это центральное место для общей конфигурации.

Hook (хук) — Функция, которая вызывается в определенные моменты выполнения тестов (например, во время сбора или запуска тестов) и позволяет кастомизировать поведение pytest. Используется для написания плагинов или изменения стандартного поведения pytest (например, добавление своих действий перед запуском всех тестов).

Test Suite (набор тестов) — Группа тестов (обычно множество функций/файлов), которые выполняются вместе.

Test Collection (сбор тестов) — Процесс, когда Pytest сканирует каталоги и файлы, находит тесты и готовит их к выполнению.

Test Report (отчет о тестах) — Итоговый вывод после выполнения тестов, включающий количество прошедших, проваленных, пропущенных и xfail-тестов.

Тестовый проект PyTest на GitHub

https://github.com/ivanshamaev/pytest-tutorial

Курсы pytest и материалы

YouTube

• Pytest Курс
• Pytest. Необходимый минимум

Сообщение Pytest Tutorial: тесты, fixture, mark, parametrize появились сначала на DataTalks.RU. Data Engineering / DWH / Data Pipeline.

Лучшие практики по работе с Apache Airflow 3

Создание нового Dag — это процесс из трёх шагов:

• написание Python-кода для создания объекта Dag,
• проверка того, что код соответствует вашим ожиданиям,
• настройка зависимостей окружения для запуска вашего Dag

В этом руководстве представлены лучшие практики для этих трёх шагов.

Написание Dag

Создание нового Dag в Airflow довольно простое. Однако существует множество вещей, о которых необходимо позаботиться, чтобы запуск Dag или его сбой не приводили к неожиданным результатам.

Создание пользовательского Operator/Hook

Пожалуйста, следуйте нашему руководству по пользовательским (custom) Operator’ам.

Создание задачи

Вы должны рассматривать задачи в Airflow как эквивалент транзакций в базе данных. Это означает, что ваши задачи никогда не должны производить неполные результаты. Например, нельзя оставлять неполные данные в HDFS или S3 по завершении задачи.

Airflow может повторно запускать задачу в случае её сбоя. Следовательно, задачи должны выдавать одинаковый результат при каждом повторном запуске. Некоторые способы избежать получения различного результата:

• Не используйте INSERT при повторном запуске задачи — оператор INSERT может привести к появлению дублирующихся строк в базе данных. Замените его на UPSERT.
• Читайте и записывайте данные в конкретный партицию. Никогда не читайте самые последние доступные данные в задаче. Кто-то может обновить входные данные между повторными запусками, что приведёт к разным результатам. Лучший подход — читать входные данные из конкретного партициона. В качестве партициона можно использовать data_interval_start. Этот же метод партиционирования следует применять и при записи данных в S3/HDFS.
• Функция Python datetime now() возвращает текущий объект datetime. Эту функцию никогда не следует использовать внутри задачи, особенно для выполнения критических вычислений, так как это приводит к разным результатам при каждом запуске. Допустимо использовать её, например, для генерации временного лога.

Совет

Следует определять повторяющиеся параметры, такие как connection_id или пути S3, в default_args, а не объявлять их для каждой задачи. default_args помогают избежать ошибок, таких как опечатки. Кроме того, большинство типов соединений имеют уникальные имена параметров в задачах, поэтому вы можете объявить соединение только один раз в default_args (например, gcp_conn_id), и оно будет автоматически использоваться всеми операторами, которые работают с данным типом соединения.

Удаление задачи

Будьте осторожны при удалении задачи из Dag. После удаления вы не сможете увидеть эту задачу в Graph View, Grid View и других представлениях, что усложнит проверку логов данной задачи через Webserver. Если такое поведение нежелательно, пожалуйста, создайте новый Dag.

Коммуникация

Airflow выполняет задачи Dag на разных серверах в случае использования Kubernetes Executor или Celery Executor. Поэтому не следует хранить какие-либо файлы или конфигурации в локальной файловой системе, так как следующая задача с большой вероятностью будет выполняться на другом сервере без доступа к ним — например, задача, которая загружает файл с данными, который затем обрабатывается следующей задачей. В случае использования Local Executor хранение файлов на диске также может усложнить повторные запуски, например если вашей задаче требуется конфигурационный файл, который удаляется другой задачей в Dag.

По возможности используйте XCom для передачи небольших сообщений между задачами, а для передачи больших объёмов данных используйте удалённое хранилище, такое как S3 или HDFS. Например, если у вас есть задача, которая сохраняет обработанные данные в S3, эта задача может положить путь к выходным данным в S3 в XCom, а downstream-задачи смогут получить этот путь из XCom и использовать его для чтения данных.

Задачи также не должны хранить внутри себя какие-либо параметры аутентификации, такие как пароли или токены. По возможности используйте Connections для безопасного хранения данных в backend’е Airflow и получайте их с помощью уникального connection id.

Код верхнего уровня Python

Следует избегать написания кода верхнего уровня, который не требуется для создания Operator’ов и построения связей Dag между ними. Это связано с архитектурным решением планировщика Airflow и влиянием скорости парсинга кода верхнего уровня на производительность и масштабируемость Airflow.

Планировщик Airflow выполняет код вне методов execute операторов с минимальным интервалом min_file_process_interval секунд. Это делается для того, чтобы обеспечить динамическое планирование Dag’ов — когда расписание и зависимости могут со временем изменяться и влиять на следующий запуск Dag. Планировщик Airflow постоянно старается убедиться, что то, что описано в Dag’ах, корректно отражено в запланированных задачах.

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

Одним из важных факторов, влияющих на время загрузки Dag, который часто упускают из виду Python-разработчики, является то, что импорты на верхнем уровне могут занимать неожиданно много времени и создавать значительные накладные расходы. Этого легко избежать, переместив такие импорты в локальные импорты внутри Python-callable, например.

Рассмотрим два примера ниже. В первом примере Dag будет парситься на дополнительные 1000 секунд дольше, чем функционально эквивалентный Dag во втором примере, где expensive_api_call выполняется в контексте своей задачи.

Неизбежание кода верхнего уровня Dag:

import pendulum

from airflow.sdk import DAG
from airflow.sdk import task


def expensive_api_call():
    print("Hello from Airflow!")
    sleep(1000)


my_expensive_response = expensive_api_call()

with DAG(
    dag_id="example_python_operator",
    schedule=None,
    start_date=pendulum.datetime(2021, 1, 1, tz="UTC"),
    catchup=False,
    tags=["example"],
) as dag:

    @task()
    def print_expensive_api_call():
        print(my_expensive_response)

Избегание кода верхнего уровня Dag:

import pendulum

from airflow.sdk import DAG
from airflow.sdk import task


def expensive_api_call():
    sleep(1000)
    return "Hello from Airflow!"


with DAG(
    dag_id="example_python_operator",
    schedule=None,
    start_date=pendulum.datetime(2021, 1, 1, tz="UTC"),
    catchup=False,
    tags=["example"],
) as dag:

    @task()
    def print_expensive_api_call():
        my_expensive_response = expensive_api_call()
        print(my_expensive_response)

В первом примере expensive_api_call выполняется каждый раз при парсинге файла Dag, что приводит к неоптимальной производительности при обработке Dag-файла. Во втором примере expensive_api_call вызывается только во время выполнения задачи и, таким образом, Dag может быть распарсен без потери производительности. Чтобы проверить это самостоятельно, реализуйте первый Dag и посмотрите, как строка «Hello from Airflow!» выводится в логах планировщика.

Обратите внимание, что операторы import также считаются кодом верхнего уровня. Поэтому, если у вас есть import, который выполняется долго, или импортируемый модуль сам выполняет код на верхнем уровне, это также может негативно сказаться на производительности планировщика. Следующий пример показывает, как работать с дорогостоящими импортами.

# It's ok to import modules that are not expensive to load at top-level of a Dag file
import random
import pendulum

# Expensive imports should be avoided as top level imports, because Dag files are parsed frequently, resulting in top-level code being executed.
#
# import pandas
# import torch
# import tensorflow
#

...


@task()
def do_stuff_with_pandas_and_torch():
    import pandas
    import torch

    # do some operations using pandas and torch


@task()
def do_stuff_with_tensorflow():
    import tensorflow

    # do some operations using tensorflow

Как проверить, является ли мой код «кодом верхнего уровня»

Чтобы понять, является ли ваш код «кодом верхнего уровня» или нет, необходимо разбираться во многих тонкостях того, как работает парсинг Python. В общем случае, когда Python парсит файл, он выполняет весь код, который видит, за исключением (как правило) внутреннего кода методов, который он не выполняет.

Существует ряд неочевидных специальных случаев — например, к коду верхнего уровня также относится любой код, используемый для определения значений по умолчанию у методов.

Однако есть простой способ проверить, является ли ваш код «кодом верхнего уровня» или нет. Достаточно распарсить ваш код и посмотреть, выполняется ли данный фрагмент кода.

Представьте следующий код:

from airflow.sdk import DAG
from airflow.providers.standard.operators.python import PythonOperator
import pendulum


def get_task_id():
    return "print_array_task"  # <- is that code going to be executed?


def get_array():
    return [1, 2, 3]  # <- is that code going to be executed?


with DAG(
    dag_id="example_python_operator",
    schedule=None,
    start_date=pendulum.datetime(2021, 1, 1, tz="UTC"),
    catchup=False,
    tags=["example"],
) as dag:
    operator = PythonOperator(
        task_id=get_task_id(),
        python_callable=get_array,
        dag=dag,
    )

Чтобы это проверить, вы можете добавить несколько операторов print в код, который хотите проверить, а затем выполнить команду python <my_dag_file>.py.

from airflow.sdk import DAG
from airflow.providers.standard.operators.python import PythonOperator
import pendulum


def get_task_id():
    print("Executing 1")
    return "print_array_task"  # <- is that code going to be executed? YES


def get_array():
    print("Executing 2")
    return [1, 2, 3]  # <- is that code going to be executed? NO


with DAG(
    dag_id="example_python_operator",
    schedule=None,
    start_date=pendulum.datetime(2021, 1, 1, tz="UTC"),
    catchup=False,
    tags=["example"],
) as dag:
    operator = PythonOperator(
        task_id=get_task_id(),
        python_callable=get_array,
        dag=dag,
    )

При выполнении этого кода вы увидите:

[Breeze:3.10.19] root@cf85ab34571e:/opt/airflow# python /files/test_python.py
Executing 1

Это означает, что get_array не выполняется как код верхнего уровня, а get_task_id — выполняется.

Качество кода и линтинг

Поддержание высокого качества кода имеет ключевое значение для надёжности и сопровождаемости ваших workflow в Airflow. Использование инструментов линтинга помогает выявлять потенциальные проблемы и обеспечивать соблюдение стандартов кодирования. Одним из таких инструментов является ruff — быстрый линтер для Python, который теперь включает специальные правила для Airflow.

ruff помогает выявлять устаревшие возможности и паттерны, которые могут повлиять на миграцию на Airflow 3.0. Например, он включает правила с префиксом AIR, предназначенные для обнаружения потенциальных проблем.

Полный список этих правил описан в разделе Airflow (AIR).

Установка и использование ruff

ruff — это очень быстрый линтер и автоформаттер для Python, написанный на Rust (в десятки раз быстрее flake8, isort, pylint).

Установка: установите ruff с помощью pip:

pip install "ruff>=0.14.10"

Запуск ruff: выполните ruff для проверки ваших Dag’ов на наличие потенциальных проблем:

ruff check dags/ --select AIR3

Эта команда проанализирует ваши Dag’и, расположенные в директории dags/, и сообщит о проблемах, связанных с указанными правилами.

Пример

Рассмотрим legacy Dag, определённый следующим образом:

from airflow import dag
from airflow.datasets import Dataset
from airflow.sensors.filesystem import FileSensor


@dag()
def legacy_dag():
    FileSensor(task_id="wait_for_file", filepath="/tmp/test_file")

Запуск ruff приведёт к следующему выводу:

dags/legacy_dag.py:7:2: AIR301 Dag should have an explicit schedule argument
dags/legacy_dag.py:12:6: AIR302 schedule_interval is removed in Airflow 3.0
dags/legacy_dag.py:17:15: AIR302 airflow.datasets.Dataset is removed in Airflow 3.0
dags/legacy_dag.py:19:5: AIR303 airflow.sensors.filesystem.FileSensor is moved into ``standard`` provider in Airflow 3.0

Интегрируя ruff в ваш процесс разработки, вы можете заблаговременно устранять устаревшие элементы и поддерживать высокое качество кода, что облегчает переход между версиями Airflow.

Динамическая генерация Dag

Иногда написание Dag’ов вручную нецелесообразно. Возможно, у вас есть большое количество Dag’ов, которые делают одно и то же, отличаясь лишь параметрами. Или вам нужен набор Dag’ов для загрузки таблиц, но вы не хотите вручную обновлять Dag’и каждый раз при изменении этих таблиц. В этих и других случаях может быть полезно динамически генерировать Dag’и.

Избегание избыточной обработки в коде верхнего уровня, описанное в предыдущей главе, особенно важно в случае динамической конфигурации Dag’ов, которая, по сути, может быть реализована одним из следующих способов:

• через переменные окружения (не путать с Airflow Variables)
• через внешне предоставляемый, сгенерированный Python-код, содержащий метаданные в папке Dag’ов
• через внешний, сгенерированный файл конфигурационных метаданных в папке Dag’ов

Некоторые случаи динамической генерации Dag’ов описаны в разделе Dynamic Dag Generation.

Переменные Airflow

Использование переменных Airflow приводит к сетевым вызовам и обращениям к базе данных, поэтому их применение в коде Python верхнего уровня для DAG-ов следует по возможности избегать, как упоминалось в предыдущей главе Python-код верхнего уровня. Если переменные Airflow всё же необходимо использовать в коде DAG верхнего уровня, их влияние на парсинг DAG можно снизить, включив экспериментальный кэш, настроенный с разумным значением ttl.

Вы можете свободно использовать переменные Airflow внутри методов execute() операторов, а также передавать переменные Airflow в существующие операторы через Jinja-шаблоны, что откладывает чтение значения до момента выполнения задачи. Синтаксис шаблона для этого следующий:

{{ var.value.<variable_name> }}

или, если требуется десериализовать JSON-объект из переменной:

{{ var.json.<variable_name> }}

В коде верхнего уровня переменные, использующие Jinja-шаблоны, не выполняют запрос до момента запуска задачи, тогда как Variable.get() выполняет запрос каждый раз, когда файл DAG парсится планировщиком, если кэширование не включено. Использование Variable.get() без включённого кэширования приводит к неоптимальной производительности при обработке файлов DAG.

В некоторых случаях это может привести к тому, что файл DAG не успеет полностью распарситься и произойдёт тайм-аут.

Плохой пример:

from airflow.sdk import Variable

foo_var = Variable.get("foo")  # AVOID THAT
bash_use_variable_bad_1 = BashOperator(
    task_id="bash_use_variable_bad_1", bash_command="echo variable foo=${foo_env}", env={"foo_env": foo_var}
)

bash_use_variable_bad_2 = BashOperator(
    task_id="bash_use_variable_bad_2",
    bash_command=f"echo variable foo=${Variable.get('foo')}",  # AVOID THAT
)

bash_use_variable_bad_3 = BashOperator(
    task_id="bash_use_variable_bad_3",
    bash_command="echo variable foo=${foo_env}",
    env={"foo_env": Variable.get("foo")},  # AVOID THAT
)

Хороший пример:

bash_use_variable_good = BashOperator(
    task_id="bash_use_variable_good",
    bash_command="echo variable foo=${foo_env}",
    env={"foo_env": "{{ var.value.get('foo') }}"},
)

@task
def my_task():
    var = Variable.get("foo")  # This is ok since my_task is called only during task run, not during Dag scan.
    print(var)

В целях безопасности рекомендуется использовать Secrets Backend для любых переменных, содержащих чувствительные данные.

Расписания (Timetables)

Избегайте использования переменных/подключений Airflow или обращения к базе данных Airflow на верхнем уровне кода расписаний. Доступ к базе данных должен быть отложен до момента выполнения DAG. Это означает, что не следует получать переменные/подключения в качестве аргументов при инициализации класса расписания, а также использовать Variable/Connection на верхнем уровне вашего пользовательского модуля расписания.

Плохой пример:

from airflow.sdk import Variable
from airflow.timetables.interval import CronDataIntervalTimetable


class CustomTimetable(CronDataIntervalTimetable):
    def __init__(self, *args, something=Variable.get("something"), **kwargs):
        self._something = something
        super().__init__(*args, **kwargs)

Хороший пример:

from airflow.sdk import Variable
from airflow.timetables.interval import CronDataIntervalTimetable


class CustomTimetable(CronDataIntervalTimetable):
    def __init__(self, *args, something="something", **kwargs):
        self._something = Variable.get(something)
        super().__init__(*args, **kwargs)

Запуск DAG-ов после изменений

Избегайте запуска DAG-ов сразу после их изменения или изменения любых сопутствующих файлов в папке DAG-ов.

Необходимо дать системе достаточно времени для обработки изменённых файлов. Этот процесс включает несколько этапов. Сначала файлы должны быть доставлены планировщику — обычно через распределённую файловую систему или Git-Sync, затем планировщик должен распарсить Python-файлы и сохранить их в базе данных. В зависимости от вашей конфигурации, скорости распределённой файловой системы, количества файлов, количества DAG-ов, числа изменений в файлах, размеров файлов, количества планировщиков, скорости CPU, этот процесс может занимать от нескольких секунд до нескольких минут, а в крайних случаях — многие минуты. Вам следует дождаться появления DAG-а в UI, прежде чем пытаться его запустить.

Если вы наблюдаете большие задержки между обновлением DAG-а и моментом, когда он становится доступен для запуска, вы можете обратить внимание на следующие параметры конфигурации и настроить их в соответствии с вашими потребностями (подробности по каждому параметру см. по ссылкам):

• scheduler_idle_sleep_time — Управляет временем ожидания планировщика между циклами, но если в цикле ничего не нужно делать, то есть если что-то запланировано, то следующая итерация цикла начнется немедленно.
• min_file_process_interval — Количество секунд, по истечении которых происходит разбор DAG-файла. Разбор DAG-файла происходит каждые несколько секунд. Обновления DAG-файлов отражаются после этого интервала. Низкое значение этого параметра приведет к увеличению загрузки ЦП.
• refresh_interval — Как часто (в секундах) следует обновлять или искать новые файлы в пакете DAG.
• parsing_processes — Процессор DAG может запускать несколько процессов параллельно для анализа DAG. Это определяет, сколько процессов будет запущено.
• file_parsing_sort_mode — Один из вариантов modified_time, random_seeded_by_host и alphabetical. Процессор DAG перечислит и отсортирует файлы DAG, чтобы определить порядок их анализа.
  • modified_time — Сортировка файлов по времени изменения. Это полезно в больших масштабах для предварительной обработки недавно измененных DAG-графов.
  • random_seeded_by_host — Произвольная сортировка файлов несколькими процессорами DAG, но в одном и том же порядке на одном и том же хосте, что позволяет каждому процессору обрабатывать файлы в разном порядке.
  • alphabetical — Сортировка по имени файла

Пример паттерна watcher с правилами триггеров

Паттерн watcher — это способ организации DAG-а с задачей, которая «наблюдает» за состояниями других задач. Его основное назначение — пометить запуск DAG-а как failed, если любая другая задача завершилась с ошибкой. Необходимость в этом возникла в системных тестах Airflow, которые представляют собой DAG-и с разными задачами (аналогично тесту, состоящему из шагов).

Обычно, когда любая задача завершается с ошибкой, все остальные задачи не выполняются, и весь запуск DAG-а также получает статус failed. Однако при использовании правил триггеров можно нарушить стандартный поток выполнения задач, и весь DAG может получить статус, отличный от ожидаемого. Например, можно иметь задачу очистки ресурсов (teardown task) с правилом триггера TriggerRule.ALL_DONE, которая будет выполняться независимо от состояния других задач (например, для освобождения ресурсов). В такой ситуации DAG всегда выполнит эту задачу, и запуск DAG-а получит статус именно этой задачи, в результате чего можно потерять информацию о задачах, завершившихся с ошибкой. Если требуется гарантировать, что DAG с задачей очистки завершится с ошибкой при падении любой задачи, необходимо использовать паттерн watcher.

Задача watcher — это задача, которая всегда завершается с ошибкой при выполнении, но она должна запускаться только в том случае, если любая другая задача завершилась с ошибкой. Для неё необходимо установить правило триггера TriggerRule.ONE_FAILED, а также сделать её downstream-задачей для всех остальных задач в DAG-е. Благодаря этому, если все остальные задачи завершатся успешно, watcher будет пропущена, а если произойдёт ошибка, задача watcher выполнится и завершится с ошибкой, что приведёт к статусу failed у всего запуска DAG-а.

Примечание

Следует учитывать, что правила триггеров опираются только на непосредственные upstream-задачи (родительские). Например, TriggerRule.ONE_FAILED будет игнорировать любые задачи со статусом failed (или upstream_failed), которые не являются прямыми родителями параметризуемой задачи.

Проще понять концепцию на примере. Предположим, у нас есть следующий DAG:

from datetime import datetime

from airflow.sdk import DAG
from airflow.sdk import task
from airflow.exceptions import AirflowException
from airflow.providers.standard.operators.bash import BashOperator
from airflow.utils.trigger_rule import TriggerRule


@task(trigger_rule=TriggerRule.ONE_FAILED, retries=0)
def watcher():
    raise AirflowException("Failing task because one or more upstream tasks failed.")


with DAG(
    dag_id="watcher_example",
    schedule="@once",
    start_date=datetime(2021, 1, 1),
    catchup=False,
) as dag:
    failing_task = BashOperator(task_id="failing_task", bash_command="exit 1", retries=0)
    passing_task = BashOperator(task_id="passing_task", bash_command="echo passing_task")
    teardown = BashOperator(
        task_id="teardown",
        bash_command="echo teardown",
        trigger_rule=TriggerRule.ALL_DONE,
    )

    failing_task >> passing_task >> teardown
    list(dag.tasks) >> watcher()

Визуальное представление этого DAG-а после выполнения выглядит следующим образом:

В нём есть несколько задач, выполняющих разные роли:

• failing_task — всегда завершается с ошибкой;
• passing_task — всегда завершается успешно (если выполняется);
• teardown — всегда запускается (независимо от состояний других задач) и должна всегда завершаться успешно;
• watcher — является downstream-задачей для всех остальных задач, то есть запускается, когда любая задача завершается с ошибкой, и тем самым переводит весь запуск DAG-а в состояние failed, так как является листовой задачей.

Важно отметить, что без задачи watcher весь запуск DAG-а получит состояние success, поскольку единственная задача, завершающаяся с ошибкой, не является листовой, а задача teardown завершится успешно. Если мы хотим, чтобы watcher отслеживала состояние всех задач, необходимо сделать её зависимой от каждой из них по отдельности. Благодаря этому мы можем перевести запуск DAG-а в состояние failed, если любая из задач завершится с ошибкой. Обратите внимание, что для задачи watcher установлено правило триггера «one_failed».

С другой стороны, без задачи teardown задача watcher не понадобилась бы, поскольку failing_task передала бы свой статус failed downstream-задаче passing_task, и весь запуск DAG-а также получил бы статус failed.

Использование исключения AirflowClusterPolicySkipDag в кластерных политиках для пропуска определённых DAG-ов

Добавлено в версии 2.7.

DAG-и Airflow обычно разворачиваются и обновляются из конкретной ветки Git-репозитория с помощью git-sync. Однако, когда по операционным причинам требуется запускать несколько кластеров Airflow, поддержка нескольких Git-веток становится крайне неудобной. Особенно это усложняется, когда необходимо периодически синхронизировать две отдельные ветки (например, prod и beta) с использованием корректной стратегии ветвления.

• cherry-pick слишком трудоёмок для сопровождения Git-репозитория;
• hard-reset не является рекомендуемым подходом в GitOps.

Вместо этого можно рассмотреть вариант подключения нескольких кластеров Airflow к одной и той же ветке Git (например, main) и управления ими с помощью разных переменных окружения и различных конфигураций подключений с одинаковым connection_id. При необходимости также можно выбрасывать исключение AirflowClusterPolicySkipDag в кластерной политике, чтобы загружать определённые DAG-и в DagBag только в конкретном развертывании Airflow.

def dag_policy(dag: DAG):
    """Пропуск DAG-а с тегом `only_for_beta`."""

    if "only_for_beta" in dag.tags:
        raise AirflowClusterPolicySkipDag(
            f"Dag {dag.dag_id} is not loaded on the production cluster, due to `only_for_beta` tag."
        )

Приведённый выше пример показывает фрагмент кода dag_policy, который пропускает DAG в зависимости от тегов, указанных у него.

Снижение сложности DAG-ов

Хотя Airflow хорошо справляется с обработкой большого количества DAG-ов с множеством задач и зависимостей между ними, при наличии большого числа сложных DAG-ов их сложность может негативно сказаться на производительности планирования. Одним из способов поддерживать высокую производительность и эффективное использование экземпляра Airflow является стремление к упрощению и оптимизации DAG-ов везде, где это возможно. Следует помнить, что процесс парсинга и создания DAG-а — это всего лишь выполнение Python-кода, и именно от вас зависит, насколько производительным он будет. Не существует «волшебных рецептов» для того, чтобы сделать DAG «менее сложным» — поскольку это Python-код, именно автор DAG-а контролирует сложность своего кода.

Не существует метрик «сложности DAG-а», и в частности нет метрик, которые могли бы однозначно сказать, является ли DAG «достаточно простым». Однако, как и в случае с любым Python-кодом, можно определить, что код DAG-а стал «проще» или «быстрее», если он оптимизирован. Если вы хотите оптимизировать свои DAG-и, можно предпринять следующие действия:

• Сделайте загрузку DAG-а быстрее:
  Это единственная рекомендация по улучшению, которая может быть реализована разными способами, но именно она оказывает наибольшее влияние на производительность планировщика. Если у вас есть возможность ускорить загрузку DAG-а — делайте это, если ваша цель — повышение производительности. Обратитесь к разделу Python-код верхнего уровня для получения советов, а также к Dag Loader Test, чтобы оценить время загрузки DAG-а.
• Генерируйте более простую структуру DAG-а:
  Каждая зависимость между задачами добавляет дополнительную нагрузку на планирование и выполнение. DAG с простой линейной структурой A → B → C будет испытывать меньшие задержки при планировании задач, чем DAG с глубоко вложенной древовидной структурой, например с экспоненциально растущим числом зависимых задач. Если вы можете сделать свои DAG-и более линейными — так, чтобы в каждый момент времени было как можно меньше потенциальных задач-кандидатов на запуск, — это, как правило, улучшит общую производительность планирования.
• Уменьшите количество DAG-ов в одном файле:
  Хотя Airflow 2 оптимизирован для сценария, при котором в одном файле описано несколько DAG-ов, в системе есть компоненты, из-за которых такой подход иногда менее производителен или приводит к большим задержкам по сравнению с разбиением DAG-ов по нескольким файлам. Уже сам факт того, что один файл может быть обработан только одним FileProcessor, делает этот подход менее масштабируемым. Если у вас много DAG-ов, генерируемых из одного файла, рассмотрите возможность их разделения, особенно если вы замечаете, что изменения в файлах DAG-ов долго отражаются в UI Airflow.
• Пишите эффективный Python-код:
  Необходимо соблюдать баланс между меньшим количеством DAG-ов в файле (как указано выше) и общим объёмом кода. Файлы Python, описывающие DAG-и, должны следовать лучшим практикам программирования и не должны рассматриваться как конфигурационные файлы. Если ваши DAG-и используют схожий код, не следует копировать его снова и снова в большое количество почти идентичных исходных файлов, так как это приведёт к ненужным повторным импортам одних и тех же ресурсов. Вместо этого следует стремиться к минимизации повторяющегося кода во всех DAG-ах, чтобы приложение работало эффективно и было проще в отладке.
  См. раздел Dynamic Dag Generation о том, как создавать несколько DAG-ов с похожей логикой.

Тестирование DAG-а

Пользователям Airflow следует относиться к DAG-ам как к коду промышленного уровня, и у DAG-ов должны быть различные связанные тесты, чтобы гарантировать получение ожидаемых результатов. Для DAG-а можно написать широкий спектр тестов. Рассмотрим некоторые из них.

Тест загрузки DAG-а (Dag Loader Test)

Этот тест должен гарантировать, что ваш DAG не содержит кода, который вызывает ошибку во время загрузки. Для запуска этого теста пользователю не требуется писать дополнительный код.

python your-dag-file.py

Выполнение приведённой выше команды без ошибок гарантирует, что в DAG-е нет неустановленных зависимостей, синтаксических ошибок и т. д. Убедитесь, что вы загружаете DAG в окружении, соответствующем окружению планировщика — с теми же зависимостями, переменными окружения и общим кодом, на который ссылается DAG.

Это также отличный способ проверить, загружается ли DAG быстрее после оптимизации, если вы хотите попробовать оптимизировать время загрузки DAG-а. Просто запустите DAG и измерьте время его выполнения, но, опять же, необходимо убедиться, что DAG выполняется с теми же зависимостями, переменными окружения и общим кодом.

Существует множество способов измерить время выполнения, один из них в Linux — использование встроенной команды time. Обязательно запускайте её несколько раз подряд, чтобы учесть эффекты кэширования. Сравнивайте результаты до и после оптимизации (в одинаковых условиях — на той же машине, в том же окружении и т. д.), чтобы оценить влияние оптимизации.

time python airflow/example_dags/example_python_operator.py

Результат:

real    0m0.699s
user    0m0.590s
sys     0m0.108s

Важной метрикой является «real time», которая показывает, сколько времени заняла обработка DAG-а. Обратите внимание, что при таком способе загрузки файла каждый раз запускается новый интерпретатор, поэтому присутствует начальное время инициализации, которого нет при парсинге DAG-а самим Airflow. Оценить время инициализации можно, выполнив:

time python -c ''

Результат:

real    0m0.073s
user    0m0.037s
sys     0m0.039s

В данном случае начальное время запуска интерпретатора составляет примерно ~0,07 с, что составляет около 10% времени, необходимого для парсинга example_python_operator.py выше, поэтому фактическое время парсинга для примера DAG-а составляет примерно ~0,62 с.

Подробности о том, как тестировать отдельные операторы, см. в разделе Testing a Dag.

Юнит-тесты

Юнит-тесты гарантируют отсутствие некорректного кода в вашем DAG-е. Вы можете писать юнит-тесты как для отдельных задач, так и для самого DAG-а.

Юнит-тест загрузки DAG-а:

import pytest

from airflow.models import DagBag

@pytest.fixture()
def dagbag():
    return DagBag()

def test_dag_loaded(dagbag):
    dag = dagbag.get_dag(dag_id="hello_world")
    assert dagbag.import_errors == {}
    assert dag is not None
    assert len(dag.tasks) == 1

Юнит-тест структуры DAG-а:

Это пример теста, предназначенного для проверки структуры DAG-а, сгенерированного кодом, путём сравнения с объектом типа dict.

def assert_dag_dict_equal(source, dag):
    assert dag.task_dict.keys() == source.keys()
    for task_id, downstream_list in source.items():
        assert dag.has_task(task_id)
        task = dag.get_task(task_id)
        assert task.downstream_task_ids == set(downstream_list)

def test_dag():
    assert_dag_dict_equal(
        {
            "DummyInstruction_0": ["DummyInstruction_1"],
            "DummyInstruction_1": ["DummyInstruction_2"],
            "DummyInstruction_2": ["DummyInstruction_3"],
            "DummyInstruction_3": [],
        },
        dag,
    )

Юнит-тест для пользовательского оператора:

import pendulum

from airflow.sdk import DAG, TaskInstanceState

def test_my_custom_operator_execute_no_trigger(dag):
    TEST_TASK_ID = "my_custom_operator_task"
    with DAG(
        dag_id="my_custom_operator_dag",
        schedule="@daily",
        start_date=pendulum.datetime(2021, 9, 13, tz="UTC"),
    ) as dag:
        MyCustomOperator(
            task_id=TEST_TASK_ID,
            prefix="s3://bucket/some/prefix",
        )

    dagrun = dag.test()
    ti = dagrun.get_task_instance(task_id=TEST_TASK_ID)
    assert ti.state == TaskInstanceState.SUCCESS
    # Assert something related to tasks results: ti.xcom_pull()

Самопроверки (Self-Checks)

Вы также можете реализовать проверки непосредственно в DAG-е, чтобы убедиться, что задачи производят ожидаемые результаты. Например, если у вас есть задача, которая выгружает данные в S3, вы можете реализовать проверку в следующей задаче. Такая проверка, к примеру, может удостовериться, что партиция создана в S3, и выполнить простые проверки, чтобы определить корректность данных.

Аналогично, если у вас есть задача, которая запускает микросервис в Kubernetes или Mesos, следует проверить, был ли сервис успешно запущен, используя airflow.providers.http.sensors.http.HttpSensor.

task = PushToS3(...)
check = S3KeySensor(
    task_id="check_parquet_exists",
    bucket_key="s3://bucket/key/foo.parquet",
    poke_interval=0,
    timeout=0,
)
task >> check

Staging-окружение

По возможности поддерживайте staging-окружение для тестирования полного выполнения DAG-а перед деплоем в production. Убедитесь, что ваш DAG параметризован и позволяет изменять переменные, например путь вывода при работе с S3 или базу данных, используемую для чтения конфигурации. Не хардкодьте значения внутри DAG-а и не изменяйте их вручную в зависимости от окружения.

Для параметризации DAG-а вы можете использовать переменные окружения.

import os

dest = os.environ.get("MY_DAG_DEST_PATH", "s3://default-target/path/")

Мокирование переменных и подключений

При написании тестов для кода, использующего переменные или подключения, необходимо убедиться, что они существуют во время выполнения тестов. Очевидное решение — сохранить эти объекты в базе данных, чтобы их можно было прочитать во время выполнения кода. Однако чтение и запись объектов в базу данных сопровождаются дополнительными временными затратами. Чтобы ускорить выполнение тестов, имеет смысл имитировать наличие этих объектов без сохранения их в базе данных. Для этого можно создать переменные окружения, замокировав os.environ с помощью unittest.mock.patch.dict().

Для переменных используйте AIRFLOW_VAR_{KEY}.

with mock.patch.dict("os.environ", AIRFLOW_VAR_KEY="env-value"):
    assert "env-value" == Variable.get("key")

Для подключений используйте AIRFLOW_CONN_{CONN_ID}.

conn = Connection(
    conn_type="gcpssh",
    login="cat",
    host="conn-host",
)
conn_uri = conn.get_uri()
with mock.patch.dict("os.environ", AIRFLOW_CONN_MY_CONN=conn_uri):
    assert "cat" == Connection.get_connection_from_secrets("my_conn").login

Обслуживание metadata DB

Со временем база метаданных будет увеличивать занимаемое дисковое пространство по мере накопления запусков DAG-ов и задач, а также логов событий.

Для очистки старых данных можно использовать Airflow CLI с командой airflow db clean.

Подробности см. в разделе использования db clean.

Обновления и откаты версий

Резервное копирование базы данных

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

Отключение планировщика

Во время проведения такого обслуживания можно рассмотреть отключение кластера Airflow.

Один из способов — установить параметр [scheduler] > use_job_schedule в значение False и дождаться завершения всех выполняющихся DAG-ов; после этого новые запуски DAG-ов не будут создаваться, если только они не будут запущены извне.

Лучший способ (хотя и более ручной) — использовать команду dags pause. Вам потребуется заранее зафиксировать список DAG-ов, которые не находятся в состоянии паузы, чтобы затем знать, какие из них нужно вернуть в активное состояние после завершения обслуживания. Сначала выполните airflow dags list и сохраните список не приостановленных DAG-ов. Затем используйте этот же список для выполнения dags pause для каждого DAG-а перед обслуживанием и dags unpause после его завершения. Преимущество такого подхода в том, что после обновления можно попробовать снять с паузы только один или два DAG-а (например, специальные тестовые DAG-и), чтобы убедиться, что всё работает корректно, прежде чем включать все DAG-и обратно.

Добавление DAG-ов для интеграционного тестирования

Полезно добавить несколько DAG-ов для «интеграционного тестирования», которые используют все основные сервисы вашей экосистемы (например, S3, Snowflake, Vault), но с тестовыми ресурсами или «dev»-аккаунтами. Эти тестовые DAG-и можно запускать первыми после обновления, поскольку в случае их сбоя это не приведёт к негативным последствиям, и вы сможете откатиться к резервной копии. Если же они выполняются успешно, это подтвердит, что кластер способен выполнять задачи с использованием необходимых библиотек и сервисов.

Например, если вы используете внешний secrets backend, убедитесь, что у вас есть задача, которая извлекает подключение. Если вы используете KubernetesPodOperator, добавьте задачу, выполняющую sleep 30; echo "hello". Если требуется запись в S3 — реализуйте это в тестовой задаче. А если нужен доступ к базе данных, добавьте задачу, выполняющую select 1 на сервере.

Очистка данных перед обновлением (Prune data)

Некоторые миграции базы данных могут занимать значительное время. Если база метаданных имеет очень большой размер, перед выполнением обновления стоит рассмотреть возможность очистки части старых данных с помощью команды db clean. Используйте с осторожностью.

Работа с конфликтующими и сложными Python-зависимостями

Airflow имеет множество Python-зависимостей, и иногда зависимости Airflow конфликтуют с зависимостями, которые ожидает код ваших задач. Поскольку по умолчанию окружение Airflow представляет собой единый набор Python-зависимостей и одно Python-окружение, нередко возникают ситуации, когда разные задачи требуют различных зависимостей, которые при этом конфликтуют между собой.

Если вы используете предопределённые Operator’ы Airflow для взаимодействия с внешними сервисами, выбор обычно невелик, однако такие операторы, как правило, имеют зависимости, не конфликтующие с базовыми зависимостями Airflow. Airflow использует механизм constraints, что означает наличие «зафиксированного» набора зависимостей, с которым сообщество гарантирует корректную установку Airflow (включая все community-провайдеры) без возникновения конфликтов. При этом вы можете обновлять провайдеры независимо, и их constraints вас не ограничивают, поэтому вероятность конфликтов зависимостей ниже (хотя такие зависимости всё равно необходимо тестировать). Таким образом, при использовании предопределённых операторов вероятность столкнуться с конфликтующими зависимостями минимальна или отсутствует вовсе.

Однако при более «современном» подходе к использованию Airflow — когда вы применяете TaskFlow API и большинство операторов реализуете с помощью собственного Python-кода, либо когда вы пишете собственные Custom Operator’ы — вы можете столкнуться с ситуацией, когда зависимости, требуемые вашим кастомным кодом, конфликтуют с зависимостями Airflow, или даже когда зависимости нескольких ваших Custom Operator’ов конфликтуют между собой.

Существует несколько стратегий, которые можно использовать для смягчения этой проблемы. И хотя работа с конфликтами зависимостей в кастомных операторах может быть сложной, она значительно упрощается при использовании airflow.providers.standard.operators.python.PythonVirtualenvOperator или airflow.providers.standard.operators.python.ExternalPythonOperator — как при прямом использовании классического подхода с Operator’ами, так и при использовании задач, декорированных @task.virtualenv или @task.external_python, если вы применяете TaskFlow.

Начнём со стратегий, которые проще всего реализовать (хотя они имеют определённые ограничения и накладные расходы), и постепенно перейдём к стратегиям, требующим изменений в развертывании Airflow.

Использование PythonVirtualenvOperator

Это самая простая в использовании и одновременно наиболее ограниченная стратегия. PythonVirtualenvOperator позволяет динамически создавать virtualenv, в котором будет выполняться ваш Python-callable. В современном подходе TaskFlow, описанном в разделе Pythonic Dags with the TaskFlow API, это также можно сделать, задекорировав callable декоратором @task.virtualenv (рекомендуемый способ использования оператора). Каждая задача airflow.providers.standard.operators.python.PythonVirtualenvOperator может иметь собственный независимый Python virtualenv (динамически создаваемый при каждом запуске задачи) и задавать детальный набор зависимостей, которые необходимо установить для выполнения этой задачи.

Оператор берёт на себя:

• создание virtualenv на основе вашего окружения,
• сериализацию вашего Python-callable и передачу его на выполнение Python-интерпретатору внутри virtualenv,
• выполнение callable, получение результата и передачу его через XCom, если это указано.

Преимущества оператора:

• Нет необходимости заранее подготавливать virtualenv. Он динамически создаётся перед запуском задачи и удаляется после её завершения, поэтому для использования нескольких виртуальных окружений не требуется ничего особенного (кроме наличия пакета virtualenv в зависимостях Airflow).
• Вы можете запускать задачи с разными наборами зависимостей на одних и тех же воркерах — таким образом, ресурсы памяти переиспользуются (хотя см. ниже про накладные расходы на CPU при создании virtualenv).
• В крупных инсталляциях авторам Dag’ов не нужно просить кого-то создавать virtualenv за них. Как автор Dag’а, вам достаточно иметь установленную зависимость virtualenv, и вы можете задавать и изменять окружения по своему усмотрению.
• Не требуется изменений в требованиях к деплою — независимо от того, используете ли вы локальный virtualenv, Docker или Kubernetes, задачи будут работать без добавления чего-либо в окружение развертывания.
• Автору Dag’ов не нужно изучать контейнеры или Kubernetes. Для такого подхода к написанию Dag’ов достаточно знания Python-зависимостей.

У данного оператора есть определённые ограничения и накладные расходы:

• Ваш Python-callable должен быть сериализуемым. Существует множество Python-объектов, которые не сериализуются стандартной библиотекой pickle. Часть этих ограничений можно обойти с помощью библиотеки dill, однако и она не решает всех проблем сериализации.
• Все зависимости, отсутствующие в окружении Airflow, должны импортироваться локально внутри используемого callable, а код верхнего уровня Dag не должен импортировать или использовать эти библиотеки.
• Virtualenv запускаются в рамках одной и той же операционной системы, поэтому они не могут иметь конфликтующие системные зависимости (устанавливаемые через apt или yum). Независимо могут устанавливаться только Python-зависимости.
• Оператор добавляет накладные расходы на CPU, сеть и общее время выполнения каждой задачи — Airflow вынужден пересоздавать virtualenv с нуля для каждого запуска задачи.
• Воркеры должны иметь доступ к PyPI или приватным репозиториям для установки зависимостей.
• Динамическое создание virtualenv подвержено временным сбоям (например, если репозиторий недоступен или возникают сетевые проблемы при подключении к нему).
• Легко попасть в ситуацию «слишком» динамичного окружения — устанавливаемые зависимости могут обновляться, а их транзитивные зависимости могут получать независимые обновления, в результате чего задача может перестать работать из-за выхода новой версии зависимости или вы можете стать жертвой атаки на цепочку поставок, когда новая версия зависимости оказывается вредоносной.
• Задачи изолированы друг от друга только за счёт выполнения в разных окружениях. Это означает, что выполняющиеся задачи всё ещё могут влиять друг на друга — например, последующие задачи, выполняемые на том же воркере, могут быть затронуты предыдущими задачами, которые создавали или изменяли файлы и т. п.

Подробные примеры использования airflow.providers.standard.operators.python.PythonVirtualenvOperator приведены в соответствующем разделе руководства по TaskFlow API.

Использование ExternalPythonOperator

Добавлено в версии 2.4.

Более сложным в использовании, но при этом значительно менее накладным с точки зрения ресурсов, безопасности и стабильности вариантом является использование airflow.providers.standard.operators.python.ExternalPythonOperator. В современном подходе TaskFlow, описанном в разделе Pythonic Dags with the TaskFlow API, этого также можно добиться, задекорировав ваш callable декоратором @task.external_python (рекомендуемый способ использования оператора). Однако для этого требуется заранее подготовленное, неизменяемое Python-окружение. В отличие от airflow.providers.standard.operators.python.PythonVirtualenvOperator, вы не можете добавлять новые зависимости в такое предсуществующее окружение. Все необходимые зависимости должны быть добавлены заранее и быть доступны на всех воркерах, если Airflow работает в распределённом окружении.

Таким образом, вы избегаете накладных расходов и проблем, связанных с пересозданием virtualenv, однако такие окружения необходимо подготовить и задеплоить вместе с установкой Airflow. Обычно в этот процесс вовлечены специалисты, отвечающие за установку Airflow, и в крупных инсталляциях это, как правило, другие люди, нежели авторы Dag’ов (DevOps/System Admins).

Такие virtualenv могут быть подготовлены разными способами: при использовании LocalExecutor их достаточно установить на машине, где запускается планировщик; при использовании распределённой установки Celery должна существовать пайплайн, который устанавливает эти virtualenv на нескольких машинах; наконец, если вы используете Docker-образы (например, в Kubernetes), создание virtualenv должно быть добавлено в пайплайн сборки вашего кастомного образа.

Преимущества оператора:

• Отсутствие накладных расходов при запуске задачи. Virtualenv уже готов в момент начала выполнения задачи.
• Вы можете запускать задачи с разными наборами зависимостей на одних и тех же воркерах — таким образом, все ресурсы переиспользуются.
• Воркерам не требуется доступ к PyPI или приватным репозиториям. Меньше вероятность временных сбоев, связанных с сетью.
• Зависимости могут быть заранее проверены администраторами и командой безопасности, и никакой новый, неожиданный код не будет динамически добавляться. Это полезно как с точки зрения безопасности, так и стабильности.
• Минимальное влияние на деплой — вам не нужно переходить на Docker-контейнеры или Kubernetes, чтобы эффективно использовать оператор.
• Автору Dag’ов не нужно изучать контейнеры или Kubernetes. Для написания Dag’ов таким способом достаточно знания Python и работы с requirements.

Недостатки:

• Окружения должны быть подготовлены заранее. Обычно это означает, что вы не можете менять их «на лету»: добавление новых зависимостей или изменение существующих требует как минимум повторного деплоя Airflow, а время итераций при разработке новых версий может увеличиться.
• Ваш Python-callable должен быть сериализуемым. Существует множество Python-объектов, которые не сериализуются стандартной библиотекой pickle. Часть этих ограничений можно смягчить с помощью библиотеки dill, однако она также не решает всех проблем сериализации.
• Все зависимости, отсутствующие в окружении Airflow, должны импортироваться локально внутри используемого callable, а код верхнего уровня Dag не должен импортировать или использовать эти библиотеки.
• Virtualenv запускаются в рамках одной и той же операционной системы, поэтому они не могут иметь конфликтующие системные зависимости (устанавливаемые через apt или yum). Независимо могут устанавливаться только Python-зависимости.
• Задачи изолированы друг от друга только за счёт выполнения в разных окружениях. Это означает, что выполняющиеся задачи всё ещё могут влиять друг на друга — например, последующие задачи, выполняемые на том же воркере, могут быть затронуты предыдущими задачами, которые создавали или изменяли файлы и т. п.

PythonVirtualenvOperator и ExternalPythonOperator можно рассматривать как взаимодополняющие инструменты, которые упрощают переход от этапа разработки к продакшену. Как автор Dag’ов, вы обычно будете итерироваться с зависимостями и разрабатывать Dag, используя PythonVirtualenvOperator (декорируя задачи @task.virtualenv), а после завершения итераций и внесения изменений, для продакшена, скорее всего, переключитесь на ExternalPythonOperator (и @task.external_python) после того, как команды DevOps/System Admin развернут новые зависимости в предсуществующих virtualenv в продакшене. Преимущество такого подхода в том, что вы в любой момент можете вернуть декоратор обратно и продолжить «динамическую» разработку с PythonVirtualenvOperator.

Подробные примеры использования airflow.providers.standard.operators.python.ExternalPythonOperator приведены в разделе TaskFlow External Python example.

Использование DockerOperator или KubernetesPodOperator

Ещё одной стратегией является использование airflow.providers.docker.operators.docker.DockerOperator и airflow.providers.cncf.kubernetes.operators.pod.KubernetesPodOperator. Для этого требуется, чтобы Airflow имел доступ к Docker Engine или кластеру Kubernetes.

Аналогично Python-операторам, декораторы TaskFlow удобны в случае, если вы хотите использовать эти операторы для выполнения вашего Python-callable.

Однако этот подход значительно сложнее — вам необходимо понимать, как работают Docker-контейнеры и Kubernetes Pod’ы, если вы хотите его использовать. Зато задачи полностью изолированы друг от друга, и вы даже не ограничены выполнением только Python-кода. Вы можете писать задачи на любом языке программирования. Кроме того, ваши зависимости полностью независимы от зависимостей Airflow (включая системные зависимости), поэтому если вашей задаче требуется принципиально иное окружение, это подходящий вариант.

Добавлено в версии 2.2:
Начиная с версии Airflow 2.2, вы можете использовать декоратор @task.docker для запуска функций с помощью DockerOperator.

Добавлено в версии 2.4:
Начиная с версии Airflow 2.2, вы можете использовать декоратор @task.kubernetes для запуска функций с помощью KubernetesPodOperator.

Преимущества использования этих операторов:

• Вы можете запускать задачи с разными наборами как Python-, так и системных зависимостей, а также задачи, написанные на совершенно другом языке программирования или даже под другую архитектуру процессора (x86 vs. arm).
• Окружение, в котором выполняются задачи, использует оптимизации и неизменяемость контейнеров. Похожие наборы зависимостей эффективно переиспользуют закешированные слои образов, поэтому окружение хорошо оптимизировано для случаев, когда у вас есть несколько похожих, но разных окружений.
• Зависимости могут быть заранее проверены администраторами и командой безопасности, и никакой новый, неожиданный код не будет динамически добавляться. Это полезно как с точки зрения безопасности, так и стабильности.
• Полная изоляция между задачами. Они не могут влиять друг на друга иначе, чем через стандартные механизмы Airflow XCom.

Недостатки:

• Существует накладной расход на запуск задач. Обычно он меньше, чем при динамическом создании virtualenv, но всё равно заметен (особенно для KubernetesPodOperator).
• В случае использования декораторов TaskFlow весь вызываемый метод должен быть сериализован и передан в Docker-контейнер или Kubernetes Pod, при этом существуют системные ограничения на размер метода. Сериализация, передача и последующая десериализация на удалённой стороне также добавляют накладные расходы.
• Присутствуют накладные расходы по ресурсам, связанные с необходимостью нескольких процессов. При использовании этих операторов для выполнения задач требуется как минимум два процесса: один процесс (в Docker-контейнере или Kubernetes Pod), выполняющий задачу, и процесс-наблюдатель в воркере Airflow, который отправляет задание в Docker/Kubernetes и отслеживает его выполнение.
• Контейнерные образы должны быть подготовлены заранее. Обычно это означает, что вы не можете изменять их «на лету». Добавление системных зависимостей, изменение или обновление Python-зависимостей требует пересборки и публикации образа (как правило, в приватном реестре). Время итераций при работе с новыми зависимостями обычно больше и требует от разработчика сборки и использования собственных образов во время разработки. Наличие корректного пайплайна деплоя здесь критически важно для надёжного сопровождения системы.
• Если вы хотите запускать Python-callable через декораторы, он должен быть сериализуемым. Также в этом случае все зависимости, отсутствующие в окружении Airflow, должны импортироваться локально внутри используемого callable, а код верхнего уровня Dag не должен импортировать или использовать эти библиотеки.
• Вам необходимо глубже понимать, как работают Docker-контейнеры или Kubernetes. Абстракции, предоставляемые этими технологиями, являются «протекающими», поэтому для написания Dag’ов с использованием этих операторов нужно разбираться в ресурсах, сетях, контейнерах и других аспектах.

Подробные примеры использования airflow.providers.docker.operators.docker.DockerOperator приведены в разделе TaskFlow Docker example, а airflow.providers.cncf.kubernetes.operators.pod.KubernetesPodOperator — в разделе TaskFlow Kubernetes example.

Использование нескольких Docker-образов и очередей Celery

Существует возможность (хотя она требует глубокого понимания деплоя Airflow) запускать задачи Airflow с использованием нескольких независимых Docker-образов. Это можно реализовать путём назначения разных задач разным очередям (Queues) и настройки Celery-воркеров на использование разных образов для разных очередей. Однако такой подход (по крайней мере на данный момент) требует большого объёма ручной конфигурации деплоя и глубоких знаний того, как работают Airflow, Celery и Kubernetes. Кроме того, он вносит существенные накладные расходы при выполнении задач — снижается возможность переиспользования ресурсов, а также становится значительно сложнее точно настраивать стоимость потребляемых ресурсов без негативного влияния на производительность и стабильность.

Одним из возможных способов сделать этот подход более полезным является реализация AIP-46 (Runtime isolation for Airflow tasks and Dag parsing) и завершение AIP-43 (Dag Processor Separation). До реализации этих инициатив преимуществ у данного подхода крайне мало, и он не рекомендуется к использованию.

Однако после реализации этих AIP откроется возможность более мультиарендного (multi-tenant) подхода, при котором несколько команд смогут иметь полностью изолированные наборы зависимостей, используемые на протяжении всего жизненного цикла Dag — от парсинга до выполнения.

Создание пользовательского оператора (custom Operator)

Airflow позволяет создавать новые операторы в соответствии с требованиями вас или вашей команды. Такая расширяемость — одна из ключевых возможностей, делающих Apache Airflow мощным инструментом.

Вы можете создать любой оператор, унаследовавшись от публичного базового класса SDK — BaseOperator.

В производном классе необходимо переопределить два метода:

• Конструктор (__init__) — определить параметры, необходимые для оператора. Нужно указывать только аргументы, специфичные для вашего оператора. default_args можно задать в файле Dag.
• Execute — код, который будет выполнен при вызове оператора раннером. Метод принимает контекст Airflow в качестве параметра, который можно использовать для чтения конфигурационных значений.

Примечание

При реализации пользовательских операторов не выполняйте ресурсоёмкие операции в методе init. Операторы создаются один раз за цикл планировщика для каждой задачи, которая их использует, и выполнение, например, запросов к базе данных может существенно замедлить планирование и привести к неэффективному использованию ресурсов.

Реализуем пример HelloOperator в новом файле hello_operator.py:

from airflow.sdk import BaseOperator


class HelloOperator(BaseOperator):
    def __init__(self, name: str, **kwargs) -> None:
        super().__init__(**kwargs)
        self.name = name

    def execute(self, context):
        message = f"Hello {self.name}"
        print(message)
        return message

Примечание

Чтобы импорты работали корректно, файл должен находиться в директории, присутствующей в переменной окружения PYTHONPATH. Airflow по умолчанию добавляет директории dags/, plugins/ и config/ из домашнего каталога Airflow в PYTHONPATH. В нашем примере файл размещён в директории custom_operator/.

Теперь вы можете использовать созданный пользовательский оператор следующим образом:

from custom_operator.hello_operator import HelloOperator

with dag:
    hello_task = HelloOperator(task_id="sample-task", name="foo_bar")

Вы также можете продолжать использовать папку plugins для хранения пользовательских операторов. Если файл hello_operator.py находится в директории plugins, оператор можно импортировать следующим образом:

from hello_operator import HelloOperator

Если оператор взаимодействует с внешним сервисом (API, база данных и т. п.), рекомендуется реализовать слой взаимодействия через Hooks. Это позволит повторно использовать реализованную логику в других операторах. Такой подход обеспечивает лучшее разделение ответственности и более эффективное использование интеграции по сравнению с созданием CustomServiceBaseOperator для каждого внешнего сервиса.

Ещё один аспект — временное состояние. Если операция требует хранения состояния в памяти (например, job id, который должен использоваться в методе on_kill для отмены запроса), это состояние должно храниться в операторе, а не в hook. Таким образом, hook сервиса остаётся полностью stateless, а вся логика операции сосредоточена в одном месте — в операторе.

Hooks

Hooks выступают интерфейсом для взаимодействия с внешними общими ресурсами в Dag. Например, нескольким задачам в Dag может потребоваться доступ к базе данных MySQL. Вместо создания отдельного подключения для каждой задачи можно получить подключение через hook и использовать его повторно.

Hook также помогает избежать хранения параметров аутентификации подключения непосредственно в Dag.

Расширим предыдущий пример и получим имя из MySQL:

class HelloDBOperator(BaseOperator):
    def __init__(self, name: str, mysql_conn_id: str, database: str, **kwargs) -> None:
        super().__init__(**kwargs)
        self.name = name
        self.mysql_conn_id = mysql_conn_id
        self.database = database

    def execute(self, context):
        hook = MySqlHook(mysql_conn_id=self.mysql_conn_id, schema=self.database)
        sql = "select name from user"
        result = hook.get_first(sql)
        message = f"Hello {result['name']}"
        print(message)
        return message

Когда оператор выполняет запрос через объект hook, создаётся новое подключение, если оно ещё не существует. Hook получает параметры аутентификации (например, имя пользователя и пароль) из backend Airflow и передаёт их в airflow.hooks.base.BaseHook.get_connection().

Создавать hook следует только в методе execute или в методах, вызываемых из execute. Конструктор вызывается каждый раз при парсинге Dag (а это происходит часто), и создание hook в нём приведёт к множеству ненужных подключений к базе данных. Метод execute вызывается только во время запуска Dag.

Пользовательский интерфейс

Airflow позволяет разработчику управлять отображением оператора в интерфейсе Dag.

• Переопределите ui_color, чтобы изменить цвет фона оператора в UI.
• Переопределите ui_fgcolor, чтобы изменить цвет текста.

Переопределите custom_operator_name, чтобы изменить отображаемое имя (отличное от имени класса).

class HelloOperator(BaseOperator):
    ui_color = "#ff0000"
    ui_fgcolor = "#000000"
    custom_operator_name = "Howdy"
    # ...

Шаблонизация (Templating)

Вы можете использовать шаблоны Jinja для параметризации оператора. Airflow применяет шаблонизацию к полям, указанным в template_fields, во время рендеринга оператора.

class HelloOperator(BaseOperator):
    template_fields: Sequence[str] = ("name",)

    def __init__(self, name: str, world: str, **kwargs) -> None:
        super().__init__(**kwargs)
        self.name = name
        self.world = world

    def execute(self, context):
        message = f"Hello {self.world} it's {self.name}!"
        print(message)
        return message

Использование шаблона:

with dag:
    hello_task = HelloOperator(
        task_id="task_id_1",
        name="{{ task_instance.task_id }}",
        world="Earth",
    )

В этом примере Jinja найдёт параметр name и заменит {{ task_instance.task_id }} на task_id_1.

Параметр также может содержать имя файла, например bash-скрипта или SQL-файла. В этом случае нужно указать расширение файла в template_ext. Если поле из template_fields содержит строку, заканчивающуюся расширением из template_ext, Jinja прочитает содержимое файла и заменит шаблоны на реальные значения.

Обратите внимание: Jinja подставляет значения в атрибуты оператора, а не в аргументы функции.

class HelloOperator(BaseOperator):
    template_fields: Sequence[str] = ("guest_name",)
    template_ext = ".sql"

    def __init__(self, name: str, **kwargs) -> None:
        super().__init__(**kwargs)
        self.guest_name = name

В этом примере template_fields должен быть ['guest_name'], а не ['name'].

Дополнительно вы можете указать template_fields_renderers — словарь, определяющий, в каком формате значение шаблонного поля будет отображаться в веб-интерфейсе. Например:

class MyRequestOperator(BaseOperator):
    template_fields: Sequence[str] = ("request_body",)
    template_fields_renderers = {"request_body": "json"}

    def __init__(self, request_body: str, **kwargs) -> None:
        super().__init__(**kwargs)
        self.request_body = request_body

В ситуации, когда template_field сам по себе является словарём, также можно указать путь к ключу через точку, чтобы извлекать и корректно отображать отдельные элементы. Например:

class MyConfigOperator(BaseOperator):
    template_fields: Sequence[str] = ("configuration",)
    template_fields_renderers = {
        "configuration": "json",
        "configuration.query.sql": "sql",
    }

    def __init__(self, configuration: dict, **kwargs) -> None:
        super().__init__(**kwargs)
        self.configuration = configuration

Использование этого шаблона:

with dag:
    config_task = MyConfigOperator(
        task_id="task_id_1",
        configuration={"query": {"job_id": "123", "sql": "select * from my_table"}},
    )

В результате в UI поле configuration будет отображаться в формате JSON, а значение, находящееся по пути configuration.query.sql, будет подсвечено с использованием SQL-лексера.

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

• bash
• bash_command
• doc
• doc_json
• doc_md
• doc_rst
• doc_yaml
• doc_md
• hql
• html
• jinja
• json
• md
• mysql
• postgresql
• powershell
• py
• python_callable
• rst
• sql
• tsql
• yaml

Если вы укажете несуществующий лексер, значение шаблонного поля будет отображено как красиво отформатированный (pretty-printed) объект.

Ограничения

Чтобы предотвратить неправильное использование, при определении и назначении шаблонизируемых полей в конструкторе оператора (если он определён, иначе — см. ниже) необходимо соблюдать следующие ограничения:

1. Параметры конструктора, соответствующие шаблонным полям, должны называться точно так же, как и сами поля.

Следующий пример некорректен, так как имя параметра конструктора не совпадает с именем шаблонного поля:

class HelloOperator(BaseOperator):
    template_fields = "foo"

    def __init__(self, foo_id) -> None:  # должно быть def __init__(self, foo) -> None
        self.foo = foo_id  # должно быть self.foo = foo

2. Атрибуты экземпляра, соответствующие шаблонным полям, должны быть явно присвоены из соответствующих параметров конструктора — либо напрямую, либо через вызов конструктора родительского класса (где эти поля определены как template_fields) с явной передачей параметров.

Следующий пример некорректен, так как атрибут self.foo вообще не присваивается, несмотря на то, что он объявлен как шаблонное поле:

class HelloOperator(BaseOperator):
    template_fields = ("foo", "bar")

    def __init__(self, foo, bar) -> None:
        self.bar = bar

Следующий пример также некорректен, так как self.foo в MyHelloOperator инициализируется неявно через kwargs, переданные в конструктор родителя:

class HelloOperator(BaseOperator):
    template_fields = "foo"

    def __init__(self, foo) -> None:
        self.foo = foo


class MyHelloOperator(HelloOperator):
    template_fields = ("foo", "bar")

    def __init__(self, bar, **kwargs) -> None:  # должно быть def __init__(self, foo, bar, **kwargs)
        super().__init__(**kwargs)  # должно быть super().__init__(foo=foo, **kwargs)
        self.bar = bar

3. Нельзя применять преобразования к параметру при его присваивании в конструкторе.

Любые действия над значением должны выполняться в методе execute().

Следующий пример некорректен:

class HelloOperator(BaseOperator):
    template_fields = "foo"

    def __init__(self, foo) -> None:
        self.foo = foo.lower()  # должно быть только self.foo = foo

Если оператор наследуется от базового оператора и не определяет собственный конструктор, указанные ограничения не применяются. Однако шаблонные поля должны быть корректно определены в родительском классе с соблюдением этих правил.

Следующий пример корректен:

class HelloOperator(BaseOperator):
    template_fields = "foo"

    def __init__(self, foo) -> None:
        self.foo = foo


class MyHelloOperator(HelloOperator):
    template_fields = "foo"

Эти ограничения проверяются pre-commit hook’ом с именем validate-operators-init.

Добавление шаблонных полей через наследование

Распространённый сценарий создания пользовательского оператора — расширение уже существующих template_fields. Может возникнуть ситуация, когда нужный вам оператор не объявляет определённые параметры как шаблонные, но вы хотите передавать их динамически через Jinja-выражения. Это легко реализуется через простое наследование.

Предположим, у вас есть ранее определённый HelloOperator:

class HelloOperator(BaseOperator):
    template_fields: Sequence[str] = ("name",)

    def __init__(self, name: str, world: str, **kwargs) -> None:
        super().__init__(**kwargs)
        self.name = name
        self.world = world

    def execute(self, context):
        message = f"Hello {self.world} it's {self.name}!"
        print(message)
        return message

Допустим, вы хотите динамически параметризовать аргумент world.

Поскольку template_fields гарантированно является Sequence[str] (списком или кортежем строк), можно легко создать подкласс и расширить список шаблонных полей:

class MyHelloOperator(HelloOperator):
    template_fields: Sequence[str] = (*HelloOperator.template_fields, "world")

Теперь можно использовать MyHelloOperator следующим образом:

with dag:
    hello_task = MyHelloOperator(
        task_id="task_id_1",
        name="{{ task_instance.task_id }}",
        world="{{ var.value.my_world }}",
    )

В этом примере аргумент world будет динамически установлен в значение переменной Airflow с именем my_world через Jinja-выражение.

Определение дополнительной ссылки (Extra Link) для оператора

Для своего оператора вы можете определить дополнительную ссылку (extra link), которая будет перенаправлять пользователей во внешние системы. Например, можно добавить ссылку, ведущую на документацию или руководство по использованию оператора.

Sensors

Airflow предоставляет специальный тип оператора — Sensor, предназначенный для регулярной проверки (polling) некоторого состояния (например, наличия файла) до тех пор, пока не будет выполнено условие успешного завершения.

Вы можете создать собственный сенсор, унаследовавшись от airflow.sensors.base.BaseSensorOperator и реализовав метод poke, который будет опрашивать внешнее состояние и проверять критерий успешности.

Режим reschedule

У сенсоров есть мощная возможность — режим reschedule, который позволяет задаче сенсора быть перепланированной, вместо того чтобы занимать слот воркера между проверками.

Это полезно, если:

• вы можете позволить себе более длинный интервал опроса,
• ожидается длительное ожидание выполнения условия.

Ограничение режима reschedule

Режим reschedule имеет важное ограничение: сенсор не может сохранять внутреннее состояние между перепланированными запусками.

Если ваш сенсор хранит внутреннее состояние, его следует декорировать с помощью airflow.sensors.base.poke_mode_only(). Это даст пользователям понять, что сенсор не подходит для использования в режиме reschedule.

Пример сенсора с внутренним состоянием

Примером сенсора, который хранит внутреннее состояние и не может использоваться в режиме reschedule, является:

airflow.providers.google.cloud.sensors.gcs.GCSUploadSessionCompleteSensor

Этот сенсор:

• опрашивает количество объектов по заданному префиксу (это количество является его внутренним состоянием),
• считается успешно завершённым, если в течение определённого времени количество объектов не меняется.

Сообщение Best Practices — Airflow 3 Документация появились сначала на DataTalks.RU. Data Engineering / DWH / Data Pipeline.

YouTube ролики

• Как работает GIL в Python. Многопоточность. Многопроцессность. IO/CPU-Bound
• Yandex for Developers — 01. Устройство CPython – Егор Овчаренко
• [ZProger] Многопоточность и Многопроцессорность Python. Threading & Multiprocessing Python
• Асинхронность, многопоточность, многопроцессность в python | Библиотека asyncio и асинхронный код
• Threading. Кратко про Python
• Плейлист Асинхронность в Python
• Young&&Yandex ШБР 2023 — Асинхронное программирование (Python) — полный плейлист Python ШБР 2023
• Особенности asyncio.wait_for() в асинхронном Python. Как работает таймаут для корутины
• Плейлист Асинхронность в Python
• Асинхронное программирование на примере Python / asyncio
• Собеседование Python. Разбор вопросов
• Денис Аникин. Вновь ускоряем cpu-bound задачи
• Python: Threads, GIL, asyncio
• Лекция Тимофей Хирьянов — Параллельное программирование на Python
• Yandex Developer (плейлист Школа бэкенд-разработки 2019) — Асинхронное программирование — Лекция 1, Лекция 2, Лекция 3
  • Плейлист Школа бэкенд-разработки 2021
• Плейлист «Конкурентность в Python»
• GIL в Python: зачем он нужен и как с этим жить
• Асинхронный Python-код медленнее обычного кода! Ааа!!1один. Aiohttp VS синхронные фреймворки

YouTube English:

• PlayList: Воспроизвести все import asyncio: Learn Python’s AsyncIO
• CPU Bound vs. I/O Bound | Computer Basics
• threading vs multiprocessing in python
• I/OBound vs CPU Bound Code

Статьи

• CPython простыми словами: всё, что нужно знать начинающему
• Как устроен GIL (Global Interpreter Lock) в Python: влияние на многозадачность и производительность
• Как устроен GIL в Python
• Глобальная блокировка интерпретатора (GIL) и её воздействие на многопоточность в Python
• Всё, что нужно знать о сборщике мусора в Python
• Визуализация управления памятью в Python: что творится внутри?

Введение в Python

Исходный глоссарий

Виртуальное адресное пространство

Виртуальное адресное пространство — это абстракция, предоставляемая ОС, в рамках которой каждый процесс видит собственную непрерывную адресную память, не зная о реальном физическом расположении данных.

Структура виртуального адресного пространства

Высокие адреса
┌─────────────────────────┐
│ Kernel space (отображ.) │  ← недоступен напрямую
├─────────────────────────┤
│ Stack                   │  ← стек потоков
├─────────────────────────┤
│ Heap                    │  ← объекты Python
├─────────────────────────┤
│ Data / BSS              │  ← глобальные переменные
├─────────────────────────┤
│ Code (text segment)     │  ← байткод + C-расширения
└─────────────────────────┘
Низкие адреса

Python не управляет адресным пространством напрямую — он запрашивает память у ОС через malloc, mmap, brk.

Heap & Stack

Стек(stack) и куча(heap) – области в оперативной памяти (ОЗУ, RAM), в которых хранятся данные приложения во время его выполнения. Управление оперативной памятью для приложения Python осуществляется с помощью Python memory manager.

В управлении памятью (Python memory management) существует механизм учёта ссылок (reference counting), который ведет внутренний журнал того, как много ссылок ссылается на объект в куче. Когда на объект не ссылается ни одна ссылка сборщик мусора (Garbage collector) автоматически освобождает память выделенную ранее для этого объекта.

Heap — область памяти процесса, предназначенная для динамического выделения памяти во время выполнения.

В Python:

• все объекты Python живут в heap
• int, list, dict, class, function — всё heap

Stack — область памяти, используемая для хранения локальных переменных, адресов возврата, аргументов функций. Каждый поток имеет собственный стек.

Python stack — это логическая абстракция, а не «настоящий» stack ОС.

Дескрипторы ресурсов (File Descriptors)

File descriptor — это целое число, которое операционная система даёт твоей программе, когда она открывает файл или другое устройство ввода-вывода (например, сокет, pipe). Это как минимальный идентификатор ресурса: Python использует его для низкоуровневых операций с файлами.

• Это не объект Python, это число, под которым ОС видит открытый файл/ресурс.
• С помощью FD можно делать низкоуровневые операции (чтение, запись, дупликация, перемещение позиции и т.п.).
• Отличие от обычного open() в том, что FD используют функции модуля os, а не методы объекта файла.

Каждый FD — ограниченный ресурс. Если ты открыл много файлов или сокетов и не закрыл их, система закончится и новые операции упадут с ошибками вроде Too many open files. Это особенно критично для серверов, которые держат много соединений одновременно.

В Unix-системах всё представляется как файл. Стандартные дескрипторы:

• 0 — stdin
• 1 — stdout
• 2 — stderr

Ты можешь перенаправлять их (например, в скриптах bash или в приложениях), и это тоже работает через FD.

Примеры ресурсов: файлы, сокеты, pipe, eventfd, epoll/kqueue

Глобальные переменные в Python

Глобальные переменные — это имена, привязанные в namespace модуля.

В реальности:

• имя x → указатель
• объект 10 → heap
• namespace модуля → dict в heap

Регистры CPU

Регистры CPU — сверхбыстрая память внутри процессора.

Хранят: указатель инструкции (IP), указатель стека (SP), флаги, временные значения.

Python не управляет регистрами напрямую. Но при context switch ОС сохраняет регистры, при переключении потоков Python → регистры меняются. Это основная стоимость context switch.

User Space

User space — режим выполнения с ограниченными правами.

Python-код выполняется исключительно в user space.

Запрещено:

• прямой доступ к устройствам
• управление памятью
• прерывания

Kernel Space

Kernel space — привилегированный режим выполнения.

Ядро:

• управляет памятью
• планирует процессы
• обрабатывает I/O
• управляет сетевым стеком

Что такое процесс, поток, системный вызов и context switch?

Процесс — это изолированное выполняемое окружение, предоставляемое ОС. Каждый процесс имеет собственное виртуальное адресное пространство, heap, stack, дескрипторы ресурсов (файлы, сокеты).

Поток (Thread) — это единица выполнения внутри процесса. Потоки разделяют одно адресное пространство процесса, каждый поток имеет собственный stack, выполняются псевдопараллельно внутри 1 процесса. Общее у потоков heap, глобальные переменные, объекты Python. Раздельное — stack, регистры CPU.

Системный вызов — это контролируемый переход из user space в kernel space.

Python-код не может напрямую:

• читать диск
• писать в сокет
• создавать процесс
• спать

Что происходит при системном вызове:

• Python вызывает C-функцию
• C-функция делает syscall
• ОС выполняет операцию
• Поток блокируется, пока ОС не закончит

В этот момент:

• GIL может быть освобождён
• другой поток может выполняться

Context switch — это переключение CPU с одной задачи на другую.

Бывает:

• между потоками
• между процессами

Что сохраняется:

• регистры CPU
• указатель стека
• состояние планировщика

Архитектура CPython

CPython — это эталонная реализация языка программирования Python. Это версия Python по умолчанию, наиболее широко используемая и оригинальная реализация, написанная преимущественно на языке C.

Иными словами CPython — это программа, которая принимает ваш код на Python и выполняет его, преобразуя в понятные машине действия.

1. Исходный код (Source code) – mymodule.py преобразуется в байт-код с помощью компилятора (compiler) Python
2. Байт-код (Byte code) сохраняется в определенном формате (.pyc, .pyo, .pyd) – mymodule.pyc
3. Виртуальная машина Python (или PVM) получает байт-код и с помощью интерпретатора преобразует его в бинарный код.
4. Бинарный или машинный код (Binary code)
5. Компьютер читает бинарный код и выполняет программу

Важно понимать разницу между языком Python и интерпретатором CPython. Язык Python — это набор правил и синтаксиса (описанных в документации), а CPython конкретная программа, исполняющая код на этом языке.

Python — язык, а CPython — его основной движок.

Что такое PVM?

Мы знаем, что компьютеры понимают только машинный код, состоящий из нулей и единиц. Поскольку компьютер понимает исключительно машинный код, любой программный код перед выполнением должен быть преобразован в машинный код. Для этого используется компилятор. Обычно компилятор преобразует исходный код программы непосредственно в машинный код.

Компилятор Python выполняет ту же задачу, но несколько иным образом. Он преобразует исходный код программы в другой вид кода, называемый байт-кодом. Каждая инструкция программы на Python преобразуется в набор инструкций байт-кода.

Виртуальная машина Python (Python Virtual Machine, PVM) принимает этот байт-код и преобразует его в машинный код, чтобы компьютер мог выполнить соответствующие инструкции и вывести итоговый результат. Для выполнения этого преобразования PVM оснащена интерпретатором. Интерпретатор преобразует байт-код в машинный код и передаёт этот машинный код процессору компьютера для выполнения. Поскольку именно интерпретатор играет ключевую роль, виртуальную машину Python часто также называют интерпретатором.

Альтернативные реализации

Хотя CPython является стандартной реализацией, существуют и другие реализации Python, созданные для конкретных задач, таких как повышение производительности или интеграция с другими платформами:

• PyPy — использует компиляцию Just-In-Time (JIT), что позволяет во многих случаях выполнять Python-код значительно быстрее, чем в CPython.
• Jython — написан на Java и компилирует Python-код в байткод Java, что позволяет запускать Python на виртуальной машине Java (JVM) и взаимодействовать с библиотеками Java.
• IronPython — реализован для Common Language Infrastructure (CLI), благодаря чему может работать на платформе .NET.
• MicroPython / CircuitPython — оптимизированные реализации, предназначенные для микроконтроллеров и встраиваемых систем.

Производительность

Те, кто имеют опыт работы с компилирующими языками программирования, такими как C и C++, могут заметить несколько отличий в модели выполнения Python.

• Первое, что бросается в глаза, – это отсутствие этапа сборки, или вызова утилиты «make»: программный код может запускаться сразу же, как только будет написан.
• Второе отличие: байт код не является двоичным машинным кодом (например, инструкциями для микропроцессора Intel). Байт код – это внутреннее представление программ на языке Python.

По этой причине программный код на языке Python не может выполняться так же быстро, как программный код на языке C или C++. Обход инструкций выполняет виртуальная машина, а не микропроцессор, и чтобы выполнить байт код, необходима дополнительная интерпретация, инструкции которого требуют на выполнение больше времени, чем машинные инструкции микропроцессора. С другой стороны, в отличие от классических интерпретаторов, здесь присутствует дополнительный этап компиляции – интерпретатору не требуется всякий раз снова и снова анализировать инструкции исходного текста. В результате Python способен обеспечить скорость выполнения где то между традиционными компилирующими и традиционными интерпретирующими языками программирования.

GIL (Global Interpreter Lock)

GIL (Global Interpreter Lock) — интерпретатор Python однопоточный в том смысле, что в каждый момент времени может выполняться только один участок байт-кода, даже если в процессе работает несколько потоков. Глобальная блокировка интерпретатора не позволяет выполнять несколько потоков одновременно.

Python может освободить GIL на время выполнения операций ввода-вывода (I/O Bound), потому что для выполнения ввода-вывода вызывается низкоуровневая функция операционной системы. Эти функции работают за пределами интерпретатора, т. е. никак не могут повредить его внутренние структуры, от чего и призвана защитить GIL.

GIL был введён для упрощения управления памятью в Python, поскольку многие внутренние операции, такие как создание объектов, по умолчанию не являются потокобезопасными. Без GIL нескольким потокам, одновременно обращающимся к общим ресурсам, потребовались бы сложные механизмы блокировок или синхронизации для предотвращения гонок данных и повреждения состояния.

Когда GIL становится узким местом?

• В однопоточных программах GIL не имеет значения, так как поток обладает эксклюзивным доступом к интерпретатору Python.
• В многопоточных I/O-bound программах влияние GIL менее заметно, поскольку потоки освобождают GIL во время ожидания операций ввода-вывода.
• В многопоточных CPU-bound задачах GIL становится серьёзным узким местом. Несколько потоков, конкурируя за GIL, вынуждены по очереди выполнять байткод Python.

Интересный случай, на который стоит обратить внимание, — использование time.sleep. Python фактически рассматривает time.sleep как I/O-операцию. Функция time.sleep не является CPU-bound, поскольку во время сна не происходит активных вычислений или выполнения байткода Python. Вместо этого ответственность за отслеживание прошедшего времени передаётся операционной системе. В течение этого времени поток освобождает GIL, позволяя другим потокам выполняться и использовать интерпретатор.

Когда GIL может освобождать поток?

Ситуация	GIL
time.sleep()	отпущен
I/O	отпущен
lock.acquire() (ожидание)	отпущен
C-расширение без Python API	отпущен
Чистый Python CPU-код
Работа с Python-объектами
Переключение по таймеру	временно

Рассмотрим подробно каждую ситуацию.

1 кейс — блокирующие операции (I/O, sleep, lock wait): Когда поток заходит в операцию, которая может надолго заблокироваться, CPython отпускает GIL.

time.sleep()

I/O:

sock.recv()
sock.send()
open().read()
requests.get()

Ожидание примитивов синхронизации

lock.acquire()      # если lock уже занят
event.wait()
condition.wait()
queue.get()         # если очередь пуста

Кейс 2 — выполнение C-кода, который отпускает GIL: Если поток заходит в C-расширение, где внутри есть:

Py_BEGIN_ALLOW_THREADS
// тяжёлая работа без Python-объектов
Py_END_ALLOW_THREADS

текущий поток временно теряет GIL.

Примеры библиотек:

• numpy
• hashlib
• zlib
• Pillow

C-расширение без Python API: C-код, который во время выполнения не создаёт, не читает и не изменяет Python-объекты (PyObject*).

Пример Python API в C:

PyLong_FromLong(10);      // создаёт Python-объект
PyList_Append(list, x);  // меняет Python-объект
Py_INCREF(obj);          // меняет refcount
PyObject_CallObject(f);  // вызывает Python-функцию
PyErr_SetString(...);    // трогает исключения

CPU-bound vs I/O-bound задачи

I/O-bound

I/O-bound задача — это задача, выполнение которой блокируется ожиданием операций ввода-вывода (I/O), например сетевых запросов, чтения/записи на диск или работы с внешними устройствами, и поэтому большая часть времени тратится не на вычисления, а на ожидание завершения этих операций.

CPU-bound

CPU-bound задача — это задача, выполнение которой ограничено мощностью центрального процессора (CPU), а не ожиданием ввода-вывода. Время её выполнения определяется главным образом количеством вычислительных операций, которые нужно выполнить CPU, а не тем, сколько времени тратится на ожидание данных из внешних источников.

Многозадачность в Python

Concurrency vs Parallelism

• Concurrency — это управление несколькими задачами в одно и то же время, но не обязательно их одновременное выполнение. Задачи могут выполняться по очереди, создавая иллюзию многозадачности.
• Parallelism — это одновременное выполнение нескольких задач, как правило за счёт использования нескольких ядер CPU.

Критерии выбора подхода — Multithreading, Multiprocessing или Asyncio

Multiprocessing (многопроцессность)

• Лучше всего подходит для CPU-bound задач, требующих интенсивных вычислений.
• Используется, когда необходимо обойти GIL — каждый процесс имеет собственный интерпретатор Python, что позволяет достичь настоящего параллелизма.

Multithreading (многопоточность)

• Лучше всего подходит для быстрых I/O-bound задач, так как уменьшается частота переключений контекста, и интерпретатор Python дольше остаётся в одном потоке.
• Не подходит для CPU-bound задач из-за ограничений GIL.

Asyncio (асинхронность)

• Идеально подходит для медленных I/O-bound задач, таких как длительные сетевые запросы или обращения к базе данных, поскольку эффективно обрабатывает ожидание и хорошо масштабируется.
• Не подходит для CPU-bound задач, если вычисления не выносятся в другие процессы.

threading

threading в CPython — это инструмент для I/O-параллелизма.

Начальный пример Threading

Модуль threading предоставляет способ запуска нескольких потоков (меньших единиц процесса) конкурентно внутри одного процесса. Он позволяет создавать и управлять потоками, делая возможным параллельное выполнение задач с разделяемым адресным пространством памяти. Потоки особенно полезны, когда задачи являются I/O-bound, например при работе с файлами или выполнении сетевых запросов, где значительная часть времени тратится на ожидание внешних ресурсов.

Типичный сценарий использования threading — управление пулом рабочих потоков, которые могут конкурентно обрабатывать несколько задач. Ниже приведён базовый пример создания и запуска потоков с использованием Thread:

import threading
import time
import random
from datetime import datetime

def crawl(link):
    print(f"crawl запустился для ссылки {link}. Время вызова: {datetime.now()}")
    time.sleep(random.randint(1, 11))  # Блокирующий I/O (имитация сетевого запроса)
    print(f"crawl завершен для {link}. Время вызова: {datetime.now()}")

links = [
    "https://python.org",
    "https://docs.python.org",
    "https://peps.python.org",
]

# Создаём потоки для каждой ссылки
threads = []
for i, link in enumerate(links):
    # Используем `args` для позиционных аргументов и `kwargs` для именованных
    t = threading.Thread(target=crawl, args=(link,), name=f"Thread-{i+1}")
    threads.append(t)

# Запускаем каждый поток
for t in threads:
    t.start()
    print(f'Поток {t} запущен в {datetime.now()}')

# Ожидаем завершения всех потоков
for t in threads:
    t.join()
    print(f'{t} завершен в {datetime.now()}')

Результат:

crawl запустился для ссылки https://python.org. Время вызова: 2025-12-27 13:38:45.574122
Поток <Thread(Thread-1, started 138519994431168)> запущен в 2025-12-27 13:38:45.574331
crawl запустился для ссылки https://docs.python.org. Время вызова: 2025-12-27 13:38:45.574500
Поток <Thread(Thread-2, started 138519986038464)> запущен в 2025-12-27 13:38:45.574558
crawl запустился для ссылки https://peps.python.org. Время вызова: 2025-12-27 13:38:45.574701
Поток <Thread(Thread-3, started 138519977645760)> запущен в 2025-12-27 13:38:45.574758
crawl завершен для https://python.org. Время вызова: 2025-12-27 13:38:46.574254
<Thread(Thread-1, stopped 138519994431168)> завершен в 2025-12-27 13:38:46.574417
crawl завершен для https://docs.python.org. Время вызова: 2025-12-27 13:38:47.574610
<Thread(Thread-2, stopped 138519986038464)> завершен в 2025-12-27 13:38:47.574773
crawl завершен для https://peps.python.org. Время вызова: 2025-12-27 13:38:47.574813
<Thread(Thread-3, stopped 138519977645760)> завершен в 2025-12-27 13:38:47.574895

Результат второго запуска:

crawl запустился для ссылки https://python.org. Время вызова: 2025-12-27 13:44:50.159111
Поток <Thread(Thread-1, started 126693911033536)> запущен в 2025-12-27 13:44:50.159203
crawl запустился для ссылки https://docs.python.org. Время вызова: 2025-12-27 13:44:50.159412
Поток <Thread(Thread-2, started 126693902640832)> запущен в 2025-12-27 13:44:50.159460
crawl запустился для ссылки https://peps.python.org. Время вызова: 2025-12-27 13:44:50.159612
Поток <Thread(Thread-3, started 126693894248128)> запущен в 2025-12-27 13:44:50.159679
crawl завершен для https://docs.python.org. Время вызова: 2025-12-27 13:44:57.159525
crawl завершен для https://peps.python.org. Время вызова: 2025-12-27 13:44:58.159735
crawl завершен для https://python.org. Время вызова: 2025-12-27 13:44:59.159292
<Thread(Thread-1, stopped 126693911033536)> завершен в 2025-12-27 13:44:59.159502
<Thread(Thread-2, stopped 126693902640832)> завершен в 2025-12-27 13:44:59.159545
<Thread(Thread-3, stopped 126693894248128)> завершен в 2025-12-27 13:44:59.159565

Общая схема start и join в threading:

Деталь реализации CPython

В CPython из-за глобальной блокировки интерпретатора (GIL) только один поток может выполнять Python-код в каждый момент времени (хотя некоторые ориентированные на производительность библиотеки могут обходить это ограничение). Если требуется более эффективно использовать вычислительные ресурсы многоядерных машин, рекомендуется использовать multiprocessing или concurrent.futures.ProcessPoolExecutor. Тем не менее, threading остаётся подходящей моделью, если нужно одновременно выполнять несколько I/O-bound задач.

GIL и вопросы производительности

В отличие от модуля multiprocessing, который использует отдельные процессы для обхода GIL, модуль threading работает внутри одного процесса, а значит все потоки разделяют одно и то же адресное пространство памяти. Однако GIL ограничивает прирост производительности при работе с CPU-bound задачами, поскольку только один поток может выполнять байткод Python одновременно. Несмотря на это, потоки остаются полезным инструментом для достижения конкурентности во многих сценариях.

Начиная с Python 3.13, существуют free-threaded сборки, в которых GIL может быть отключён, что позволяет добиться настоящего параллельного выполнения потоков. Однако по умолчанию эта возможность недоступна (см. PEP 703).

Жизненный цикл потока

Жизненным циклом потоков можно управлять с помощью следующих методов:

• start() — Дает потоку жизнь.
• run() — Этот метод представляет действия, которые должны быть выполнены в
  потоке.
• join([timeout]) — Поток, который вызывает этот метод, приостанавливается, ожидая завершения потока, чей метод вызван. Параметр timeout (число с плавающей точкой) позволяет указать время ожидания (в секундах), по истечении которого приостановленный поток продолжает свою работу независимо от завершения потока, чей метод join был вызван. Вызывать join() некоторого потока можно много раз. Поток не может вызвать метод join() самого себя. Также нельзя ожидать завершения еще не запущенного потока. Слово «join» в переводе с английского означает «присоединить», то есть, метод, вызвавший join(), желает, чтобы поток по завершении присоединился к вызывающему метод потоку.
• getName() — Возвращает имя потока. Для главного потока это «MainThread«.
• setName(name) — Присваивает потоку имя name.
• isAlive() — Возвращает истину, если поток работает (метод run() уже вызван, но еще не завершился).
• isDaemon() — Возвращает истину, если поток имеет признак демона. Программа на Python завершается по завершении всех потоков, не являющихся демонами. Главный поток демоном не является.
• setDaemon(daemonic) — Устанавливает признак daemonic того, что поток является демоном. Начальное значение этого признака заимствуется у потока, запустившего данный. Признак можно изменять только для потоков, которые еще не запущены.

Атрибуты потока:

• t.name — имя потока
• t.ident — Уникальный идентификатор потока (ID) — None, если поток ещё не запущен
• threading.current_thread() — Возвращает объект текущего потока
• t.daemon = True — Демон-потоки убиваются при завершении главного потока. Используются для фоновых задач, логирования, heartbeat-потоков. daemon нужно задавать до start()
• threading.active_count() — Количество активных потоков
• threading.enumerate() — Список всех живых потоков

Реализация потокобезопасной записи результатов с Lock, чтобы избежать race condition

import threading
import time
import random
from datetime import datetime

def crawl(link, results, lock):
    print(f"Поток {threading.current_thread().name} запущен. Время вызова: {datetime.now()}")

    # Имитация сетевого запроса
    delay = random.randint(1, 10)
    time.sleep(delay)

    # Имитация полученного JSON
    response = {
        "url": link,
        "status": 200,
        "data": {
            "title": f"Данные с {link}",
            "value": random.randint(1, 100),
        },
        "fetched_at": datetime.now().isoformat(),
        "thread": threading.current_thread().name,
    }

    # Потокобезопасная запись результата
    with lock:
        results[link] = response

    print(f"Поток {threading.current_thread().name} завершен. Запрос длился {delay} секунд. Время завершения: {datetime.now()}")


links = [
    "https://python.org",
    "https://docs.python.org",
    "https://peps.python.org",
]

# Общее хранилище результатов
results = {}

# Lock для синхронизации доступа к results
lock = threading.Lock()

# Создаём потоки
threads = []
for i, link in enumerate(links):
    t = threading.Thread(
        target=crawl,
        args=(link, results, lock),
        name=f"Thread-{i + 1}",
    )
    threads.append(t)

# Запускаем потоки
for t in threads:
    t.start()

# Ждём завершения
for t in threads:
    t.join()

# Итоговый объединённый результат
print("\nИТОГОВЫЙ РЕЗУЛЬТАТ:")
for url, data in results.items():
    print(f"{url} → {data}")

Что выполняется в коде:

• t.start() — Создаёт реальный системный поток. Вызывает crawl(…) в новом потоке. Нельзя вызывать start() дважды для одного и того же объекта.
• t.join() — Блокирует главный поток и ждёт, пока поток t завершится. Гарантирует, что все данные собраны.
• threading.current_thread().name — Позволяет узнать, какой поток сейчас выполняется. Используется для логирования и отладки

Результат выполнения скрипта:

Поток Thread-1 запущен. Время вызова: 2025-12-27 20:45:11.807784
Поток Thread-2 запущен. Время вызова: 2025-12-27 20:45:11.807957
Поток Thread-3 запущен. Время вызова: 2025-12-27 20:45:11.808193
Поток Thread-3 завершен. Запрос длился 1 секунд. Время завершения: 2025-12-27 20:45:12.808385
Поток Thread-1 завершен. Запрос длился 4 секунд. Время завершения: 2025-12-27 20:45:15.808069
Поток Thread-2 завершен. Запрос длился 10 секунд. Время завершения: 2025-12-27 20:45:21.808165

ИТОГОВЫЙ РЕЗУЛЬТАТ:
https://peps.python.org → {'url': 'https://peps.python.org', 'status': 200, 'data': {'title': 'Данные с https://peps.python.org', 'value': 15}, 'fetched_at': '2025-12-27T20:45:12.808319', 'thread': 'Thread-3'}
https://python.org → {'url': 'https://python.org', 'status': 200, 'data': {'title': 'Данные с https://python.org', 'value': 84}, 'fetched_at': '2025-12-27T20:45:15.808019', 'thread': 'Thread-1'}
https://docs.python.org → {'url': 'https://docs.python.org', 'status': 200, 'data': {'title': 'Данные с https://docs.python.org', 'value': 17}, 'fetched_at': '2025-12-27T20:45:21.808113', 'thread': 'Thread-2'}

Основы threading

Создание потока через конструктор threading.Thread

threading.Thread(
    target=None,
    args=(),
    kwargs={},
    name=None,
    daemon=None
)

Основные параметры:

Запуск и управление потоками t.start()

t.start()

• Запускает поток
• Внутри вызывает run()
• Нельзя вызвать повторно

t.run()

• Содержит код потока
• Не запускает новый поток, если вызвать напрямую
• Обычно не вызывается вручную

join(timeout=None)

• Ждёт завершения потока
• timeout — максимальное время ожидания (в секундах)

t.is_alive()

• Возвращает True, если поток ещё работает

Примитивы синхронизации: Lock, RLock, Semaphore, Event, Condition

Подробнее: Python. Урок 23. Потоки и процессы в Python. Часть 2. Синхронизация потоков

В Python примитивы синхронизации из модуля threading решают одну ключевую задачу: они позволяют нескольким потокам безопасно и предсказуемо взаимодействовать с общим состоянием. Несмотря на наличие GIL, эти примитивы остаются необходимыми, потому что GIL защищает интерпретатор, но не бизнес-логику и не целостность данных.

Диспетчеры контекста предусмотрены для всех объектов модуля threading, таких как Lock, RLock, Condition, Semaphore и BoundedSemaphore, то есть для работы с этими объектами может применяться инструкция with.

Начнём с Lock и RLock, так как они лежат в основе почти всех сценариев синхронизации.

Lock

Lock — это обычный мьютекс, который может быть захвачен только одним потоком в конкретный момент времени. Когда поток вызывает acquire(), он либо сразу получает доступ к критической секции, либо блокируется до тех пор, пока другой поток не освободит lock. После выполнения защищённого участка кода поток обязан вызвать release(). В реальном коде Lock почти всегда используется через контекстный менеджер with, потому что это гарантирует освобождение блокировки даже при исключении. Lock подходит для защиты простых структур данных, таких как словари, списки или счётчики, и для коротких критических секций. Важно понимать, что один и тот же поток не может захватить Lock повторно: попытка сделать это приведёт к deadlock, когда поток будет ждать самого себя.

Проблема (без Lock)

import threading

counter = 0

def increment():
    global counter
    for _ in range(100_000):
        counter += 1

threads = [threading.Thread(target=increment) for _ in range(2)]

for t in threads:
    t.start()
for t in threads:
    t.join()

print(counter)  #  НЕ гарантировано 200000

Решение с Lock

import threading

counter = 0
lock = threading.Lock()

def increment():
    global counter
    for _ in range(100_000):
        with lock:          #  только один поток внутри
            counter += 1

threads = [threading.Thread(target=increment) for _ in range(2)]

for t in threads:
    t.start()
for t in threads:
    t.join()

print(counter)  #  всегда 200000

Что гарантирует Lock

• Только один поток изменяет общее состояние
• Нет гонок данных

RLock

Эта проблема решается с помощью RLock, или reentrant lock. По сути это мьютекс с учётом владельца. Поток, который уже владеет RLock, может захватить его ещё раз, и Python просто увеличит внутренний счётчик захватов. Освобождать такой lock нужно столько же раз, сколько он был захвачен. RLock необходим в более сложных архитектурах, когда функции с защитой lock вызывают друг друга, либо когда публичный метод и внутренний метод используют одну и ту же блокировку. Без RLock такой код почти неизбежно приводит к взаимной блокировке.

Проблема с Lock

lock = threading.Lock()

def outer():
    with lock:
        inner()

def inner():
    with lock:   #  deadlock: поток уже держит lock
        print("inner")

Решение с RLock

import threading

lock = threading.RLock()

def outer():
    with lock:
        print("outer")
        inner()

def inner():
    with lock:
        print("inner")

threading.Thread(target=outer).start()

Что даёт RLock

• Один поток может захватывать блокировку несколько раз
• Важно для рекурсии и вложенных вызовов

Semaphore

Следующий важный примитив — Semaphore. В отличие от Lock, который допускает ровно одного владельца, semaphore разрешает одновременно находиться в критической секции ограниченному числу потоков. При создании семафора задаётся счётчик, который уменьшается при acquire() и увеличивается при release(). Пока счётчик положительный, потоки могут входить без ожидания, а когда он становится равным нулю, все последующие вызовы acquire() блокируются. Семантически семафор описывает не владение ресурсом, а количество доступных слотов. Это делает его удобным для ограничения параллельного доступа к внешним системам, таким как база данных, пул соединений или сторонний API. В отличие от Lock, семафор не привязан к конкретному потоку, поэтому важно строго соблюдать баланс acquire() и release(), иначе система либо «утечёт» в блокировку, либо начнёт пускать больше потоков, чем предполагалось.

Пример: максимум 2 потока одновременно

import threading
import time

semaphore = threading.Semaphore(2)

def worker(name):
    print(f"{name} ждёт доступ")
    with semaphore:
        print(f"{name} вошёл")
        time.sleep(2)
        print(f"{name} вышел")

threads = [
    threading.Thread(target=worker, args=(f"Thread-{i}",))
    for i in range(5)
]

for t in threads:
    t.start()

Что гарантирует Semaphore

• Не более N потоков внутри секции
• Остальные ждут освобождения ресурса

BoundedSemaphore

BoundedSemaphore — это вариант семафора из модуля threading, который предназначен для строгого контроля количества одновременных доступов к ресурсу и дополнительно защищает от логических ошибок в коде.

По своей сути BoundedSemaphore работает так же, как обычный Semaphore: он хранит внутренний счётчик, и поток может войти в критическую секцию, только если счётчик больше нуля. При входе счётчик уменьшается, при выходе увеличивается. Это позволяет ограничить количество потоков, которые одновременно используют общий ресурс.

Ключевое отличие BoundedSemaphore от Semaphore заключается в том, что он не позволяет превысить начальное значение счётчика. Если вызвать release() больше раз, чем было успешных acquire(), BoundedSemaphore выбросит исключение ValueError. Обычный Semaphore такого не делает и молча увеличивает счётчик, что может привести к незаметным ошибкам и нарушению инвариантов программы.

Таким образом, BoundedSemaphore полезен в ситуациях, где важно гарантировать, что количество «освобождений» ресурса строго соответствует количеству его захватов, например при реализации пулов соединений или управлении ограниченными системными ресурсами. Он помогает выявлять ошибки проектирования на раннем этапе, вместо того чтобы позволять программе продолжать работу в некорректном состоянии.

Пример использования BoundedSemaphore для ограничения числа одновременных работников:

import threading
import time

pool = threading.BoundedSemaphore(2)

def worker(name):
    print(f"{name} пытается войти")
    pool.acquire()
    try:
        print(f"{name} работает")
        time.sleep(1)
    finally:
        pool.release()
        print(f"{name} вышел")

threads = [
    threading.Thread(target=worker, args=(f"Thread-{i}",))
    for i in range(4)
]

for t in threads:
    t.start()
for t in threads:
    t.join()

Если в этом примере по ошибке вызвать pool.release() дважды в одном потоке, программа сразу упадёт с ValueError, что явно укажет на ошибку управления ресурсом. Именно это поведение и является главным практическим отличием BoundedSemaphore от обычного Semaphore.

Event

Event решает другую задачу и не предназначен для защиты критических секций. Это потокобезопасный флаг, который может быть установлен или сброшен, и который другие потоки могут проверять или ожидать. Внутренне Event хранит состояние «установлен» или «не установлен». Когда поток вызывает wait(), он блокируется до тех пор, пока другой поток не вызовет set(). Если событие уже установлено, wait() возвращается сразу. В отличие от lock-ов, событие не «потребляется» при ожидании, и все потоки, ожидающие одного и того же события, будут разбужены одновременно. На практике Event чаще всего используется для управления жизненным циклом потоков, например для корректной остановки воркеров или для сигнализации о готовности системы к работе. Это более выразительная и безопасная альтернатива общим флагам и бесконечным циклам с sleep.

Пример: ожидание старта

import threading
import time

event = threading.Event()

def worker():
    print("Рабочий поток ждёт сигнал...")
    event.wait()          #  блокируется
    print("Рабочий поток получил сигнал!")

def starter():
    time.sleep(3)
    print("Сигнал отправлен!")
    event.set()           #  разблокирует всех

threading.Thread(target=worker).start()
threading.Thread(target=starter).start()

Event идеально подходит для

• старт / стоп сигналов
• graceful shutdown — (плавное или корректное завершение работы) — это процесс остановки компьютерной системы (приложения, сервера, контейнера), при котором она успевает выполнить необходимые задачи по очистке и сохранению данных перед полным выключением.
• ожидания готовности ресурса

Condition

Condition является самым сложным и одновременно самым гибким примитивом синхронизации. Он объединяет в себе мьютекс и механизм ожидания уведомлений. Идея Condition заключается в том, что поток может ждать не просто сигнала, а выполнения определённого логического условия, связанного с состоянием программы. Поток захватывает условие, проверяет состояние, и если оно не удовлетворяет требованиям, вызывает wait(). При этом lock временно освобождается, чтобы другие потоки могли изменить состояние. Когда другой поток вызывает notify() или notify_all(), ожидающие потоки пробуждаются и снова проверяют условие. Именно повторная проверка условия является ключевым моментом, так как пробуждение не гарантирует, что состояние действительно изменилось нужным образом. Condition активно используется в классических паттернах producer–consumer, очередях задач и системах, где потоки должны реагировать на изменение общего состояния, а не просто на факт события.

Если смотреть на эти примитивы как на систему, то Lock и RLock отвечают за эксклюзивный доступ, Semaphore ограничивает параллелизм, Event передаёт сигналы между потоками, а Condition позволяет потокам координироваться на основе сложных условий. В продакшене выбор примитива почти всегда диктуется смыслом задачи, а не техническими деталями. Хорошая синхронизация делает код не только корректным, но и читаемым, потому что по выбранному примитиву сразу понятно, как именно потоки должны взаимодействовать друг с другом.

Producer / Consumer с Condition

import threading
import time
import random

condition = threading.Condition()
queue = []
MAX_ITEMS = 5

def producer():
    for i in range(10):
        time.sleep(random.uniform(0.1, 0.5))
        with condition:
            while len(queue) >= MAX_ITEMS:
                condition.wait()   #  ждём, пока потребитель заберёт
            queue.append(i)
            print(f"Producer добавил {i}")
            condition.notify()     #  сигнал потребителю

def consumer():
    for _ in range(10):
        with condition:
            while not queue:
                condition.wait()   #  ждём данные
            item = queue.pop(0)
            print(f"Consumer забрал {item}")
            condition.notify()     #  сигнал производителю
        time.sleep(random.uniform(0.2, 0.6))

threading.Thread(target=producer).start()
threading.Thread(target=consumer).start()

Condition = Lock + Event

• wait() → отпускает lock и ждёт
• notify() → будит ожидающий поток
• Позволяет ждать логических условий, а не просто блокировки

Barrier

threading.Barrier — это примитив синхронизации в Python, который позволяет группе потоков одновременно ожидать друг друга в определенной точке выполнения (контрольной точке) перед тем, как продолжить работу.

todo

Итоговая таблица

concurrent.futures

todo

multiprocessing

Теория
Разница между:
fork / spawn / forkserver

IPC (межпроцессное взаимодействие):
Queue
Pipe
Manager
Стоимость сериализации (pickle)
Copy-on-write (Linux)

Практика
Параллельная обработка данных
Использование multiprocessing.Pool

Бенчмарк:
threading vs multiprocessing
Поймать баг с pickling’ом

Продакшн insight: multiprocessing часто убивает latency, если использовать бездумно.

asyncio

Ключевая тема для highload backend.

Теория
Event loop
Coroutine
Awaitable
Task vs Future
Cooperative multitasking
Почему async ≠ threading

Практика
Переписать синхронный код в async
Одновременные HTTP-запросы (aiohttp)
Ограничение параллелизма (Semaphore)

Ошибки:
blocking call внутри async
забытый await

Критически важно: понимание, почему один blocking вызов убивает весь сервис.

Сообщение Python — Многозадачность, конкурентность и асинхронность появились сначала на DataTalks.RU. Data Engineering / DWH / Data Pipeline.

Каковы основные преимущества использования PySpark по сравнению с традиционным Python для обработки больших данных?

PySpark, Python API для Apache Spark, предлагает несколько преимуществ по сравнению с традиционным Python для обработки больших данных. К ним относятся масштабируемость для работы с массивными наборами данных, высокая производительность за счёт параллельной обработки, отказоустойчивость для обеспечения надёжности данных, а также интеграция с другими инструментами для работы с большими данными внутри экосистемы Apache.

Как создать SparkSession в PySpark? Каковы его основные назначения?

В PySpark SparkSession является точкой входа для использования функциональности Spark и создаётся с помощью API SparkSession.builder. Его основные назначения включают взаимодействие с Spark SQL для обработки структурированных данных, создание DataFrame, конфигурирование свойств Spark, а также управление жизненным циклом SparkContext и SparkSession. Ниже приведён пример того, как может быть создан SparkSession:

from pyspark.sql import SparkSession
     
spark = SparkSession.builder \
         .appName("MySparkApp") \
         .master("local[*]") \
         .getOrCreate()

Опиши различные способы чтения данных в PySpark.

PySpark поддерживает чтение данных из различных источников, таких как CSV, Parquet и JSON, среди прочих. Для этой цели он предоставляет разные методы, включая spark.read.csv(), spark.read.parquet(), spark.read.json(), spark.read.format() и spark.read.load(). Ниже приведён пример того, как данные могут быть прочитаны в PySpark:

df_from_csv = spark.read.csv("my_file.csv", header=True)
df_from_parquet = spark.read.parquet("my_file.parquet")
df_from_json = spark.read.json("my_file.json")

Как обрабатывать пропущенные данные в PySpark?

В PySpark пропущенные данные можно обрабатывать с использованием нескольких методов. Можно удалять строки или столбцы, содержащие пропущенные значения, с помощью метода .dropna(). Также можно заполнять пропущенные данные конкретным значением или использовать методы интерполяции с помощью .fillna(). Кроме того, можно выполнять импутацию пропущенных значений с использованием статистических методов, таких как среднее значение или медиана, применяя Imputer. Ниже приведён пример обработки пропущенных данных в PySpark:

# Как удалить строки
df_from_csv.dropna(how="any")

# Как заполнить пропущенные значения константой
df_from_parquet.fillna(value=2)

# Как выполнить импутацию значений медианой
from pyspark.ml.feature import Imputer
imputer = Imputer(strategy="median", inputCols=["price","rooms"], outputCols=["price_imputed","rooms_imputed"])
model = imputer.fit(df_from_json)
df_imputed = model.transform(df_from_json)

Как можно кэшировать данные в PySpark для повышения производительности?

Одним из преимуществ PySpark является возможность использовать методы .cache() или .persist() для хранения данных в памяти или на заданном уровне хранения. Это улучшает производительность за счёт предотвращения повторных вычислений и снижения необходимости сериализации и десериализации данных. Ниже приведён пример того, как кэшировать данные в PySpark:

# Как кэшировать данные в памяти
df_from_csv.cache()

# Как сохранить данные на локальном диске
df_from_csv.persist(storageLevel=StorageLevel.DISK_ONLY)

При использовании cache() применяется только уровень хранения по умолчанию:

• MEMORY_ONLY для RDD
• MEMORY_AND_DISK для Dataset

При использовании persist() вы можете указать нужный уровень хранения как для RDD, так и для Dataset.

Из официальной документации:

• Вы можете пометить RDD для сохранения с помощью методов persist() или cache().
• Каждый сохранённый RDD может храниться с использованием разного уровня хранения.
• Метод cache() — это сокращённая форма использования уровня хранения по умолчанию, а именно StorageLevel.MEMORY_ONLY (хранение десериализованных объектов в памяти).

Используйте persist(), если вы хотите назначить уровень хранения, отличный от:

• MEMORY_ONLY для RDD
• или MEMORY_AND_DISK для Dataset

Подробнее почитать:

• Spark Difference between Cache and Persist?

Опиши выполнение соединений в PySpark

PySpark позволяет выполнять несколько типов соединений, таких как inner, outer, left и right. Используя метод .join(), можно задать условие соединения через параметр on и тип соединения через параметр how, как показано в примере:

# Как выполнить inner join двух наборов данных
df_from_csv.join(df_from_json, on="id", how="inner")

# Как выполнить outer join наборов данных
df_from_json.join(df_from_parquet, on="product_id", how="outer")

В чём заключаются ключевые различия между RDD, DataFrame и Dataset в PySpark?

Spark Resilient Distributed Dataset (RDD), DataFrame и Dataset являются ключевыми абстракциями в Spark, которые позволяют работать со структурированными данными в распределённой вычислительной среде. Несмотря на то что все они представляют данные, между ними существуют важные различия.

RDD являются низкоуровневыми API, не имеющими схемы и предоставляющими полный контроль над данными; они представляют собой неизменяемые коллекции объектов.

DataFrame являются высокоуровневыми API, построенными поверх RDD и оптимизированными для производительности, но не обладающими типобезопасностью; они организуют структурированные и полуструктурированные данные в именованные столбцы.

Dataset объединяют преимущества RDD и DataFrame, являясь высокоуровневыми API, которые предоставляют типобезопасную абстракцию; они поддерживают Python и Scala, обеспечивают проверку типов во время компиляции и при этом работают быстрее, чем DataFrame.

Объясни концепцию ленивых вычислений в PySpark. Как она влияет на производительность?

PySpark реализует стратегию, называемую ленивыми вычислениями, при которой преобразования, применяемые к распределённым наборам данных, таким как RDD, DataFrame или Dataset, не выполняются немедленно. Вместо этого Spark строит последовательность операций или преобразований, которые должны быть выполнены над данными, называемую ориентированным ациклическим графом, или DAG. Такой подход улучшает производительность и оптимизирует выполнение, поскольку вычисления откладываются до момента, когда вызывается действие и их выполнение становится действительно необходимым.

Какова роль партиционирования в PySpark и каким образом оно может улучшить производительность?

В PySpark партиционирование данных является ключевой возможностью, которая помогает равномерно распределять нагрузку между узлами кластера. Партиционирование означает разделение данных на более мелкие части, называемые партициями, которые обрабатываются независимо и параллельно на разных узлах кластера.

Это повышает производительность за счёт параллельной обработки, уменьшения перемещения данных и более эффективного использования ресурсов. Управлять партиционированием можно с помощью таких методов, как .repartition() и .coalesce().

Объясни концепцию широковещательных переменных в PySpark и приведи пример использования

Широковещательные переменные являются важной возможностью распределённых вычислительных фреймворков Spark.

В PySpark это разделяемые переменные только для чтения, которые кэшируются и распространяются по узлам кластера для того, чтобы избежать операций shuffle. Они могут быть особенно полезны в распределённых приложениях машинного обучения, которым необходимо использовать и загружать предварительно обученную модель. В этом случае модель передаётся как широковещательная переменная, что помогает сократить накладные расходы на передачу данных и повысить производительность.

В чём различия между PySpark и pandas?

PySpark и pandas оба широко используются для обработки данных, однако между ними существуют ключевые различия. PySpark ориентирован на масштабируемость и предназначен для работы с большими данными и распределённой обработки, тогда как pandas подходит для относительно небольших наборов данных, которые помещаются в память.

С точки зрения производительности PySpark выполняет параллельные вычисления на уровне кластера, что делает его значительно быстрее при работе с большими объёмами данных по сравнению с pandas, который работает на одной машине. С точки зрения удобства использования pandas проще для разведочного анализа данных, тогда как PySpark более сложен, но при этом сильно оптимизирован для распределённых вычислений.

Как можно преобразовать DataFrame из pandas в PySpark DataFrame и обратно?

DataFrame pandas можно преобразовать в PySpark DataFrame с помощью метода spark.createDataFrame(), а PySpark DataFrame обратно в pandas DataFrame с помощью метода .toPandas().

import pandas as pd
from pyspark.sql import SparkSession

# Инициализация SparkSession
spark = SparkSession.builder.appName("Example").getOrCreate()

# Создание Pandas DataFrame
pdf = pd.DataFrame({'id': [1, 2, 3], 'value': [10, 20, 30]})

# Преобразование в PySpark DataFrame
df_spark = spark.createDataFrame(pdf)

# Обратное преобразование в Pandas DataFrame
pdf_new = df_spark.toPandas()

Intermediate PySpark Interview Questions

Рассмотрев основы, перейдём к вопросам для собеседования по PySpark среднего уровня, которые глубже затрагивают архитектуру и модель выполнения приложений Spark.

Что такое Spark Driver и каковы его обязанности?

Spark Driver — это основной процесс, который координирует выполнение приложений Spark, распределяя задачи по кластеру. Он взаимодействует с менеджером кластера для выделения ресурсов, планирования задач и мониторинга выполнения Spark-задач (Tasks).

Что такое Spark DAG?

Ориентированный ациклический граф (DAG) в Spark является ключевым понятием, поскольку он представляет логическую модель выполнения Spark. Он называется ориентированным, потому что каждая вершина представляет преобразование, выполняемое в определённом порядке, заданном рёбрами. Он является ациклическим, так как в плане выполнения отсутствуют циклы или петли. Этот план оптимизируется с использованием конвейерных преобразований, объединения задач и проталкивания предикатов.

Какие типы менеджеров кластеров доступны в Spark?

В настоящее время Spark поддерживает несколько менеджеров кластеров для управления ресурсами и планирования заданий.

• К ним относится Standalone — простой менеджер кластера, встроенный в Spark.
• Hadoop YARN — универсальный менеджер в экосистеме Hadoop, используемый для планирования заданий и управления ресурсами.
• Kubernetes применяется для автоматизации, развёртывания, масштабирования и управления контейнеризованными приложениями.
• Apache Mesos — распределённая система, используемая для управления ресурсами на уровне приложений.

Опиши, как реализовать пользовательское преобразование в PySpark

Для реализации пользовательского преобразования в PySpark можно определить Python-функцию, которая работает с PySpark DataFrame, а затем использовать метод .transform() для вызова этого преобразования. Ниже приведён пример реализации пользовательского преобразования в PySpark:

# Определение Python-функции, работающей с PySpark DataFrame
def get_discounted_price(df):
    return df.withColumn("discounted_price", \
                          df.price - (df.price * df.discount) / 100) 

# Вызов преобразования
df_discounted = df_from_csv.transfrom(get_discounted_price)

Объясни концепцию оконных функций в PySpark и приведи пример

Оконные функции в PySpark позволяют применять операции к окну строк, возвращая одно значение для каждой входной строки. С их помощью можно выполнять ранжирование, аналитические операции и агрегатные функции. Ниже приведён пример применения оконной функции в PySpark:

from pyspark.sql.window import Window
from pyspark.sql.functions import row_number

# Определение оконной функции
window = Window.orderBy("discounted_price")

# Применение оконной функции
df = df_from_csv.withColumn("row_number", row_number().over(window))

Как обрабатывать ошибки и исключения в PySpark?

Одним из наиболее полезных способов обработки ошибок и исключений в преобразованиях и действиях PySpark является оборачивание кода в блоки try-except для их перехвата. В RDD можно использовать операцию foreach для итерации по элементам и обработки исключений.

Каково назначение чекпойнтов в PySpark?

В PySpark чекпойнтинг означает сохранение RDD на диск, чтобы к этой промежуточной точке можно было обратиться в будущем вместо повторного вычисления RDD из исходного источника. Чекпойнты обеспечивают возможность восстановления после сбоев, поскольку драйвер может быть перезапущен с использованием ранее вычисленного состояния.

Как PySpark выполняет вывод схемы и как можно задать схему явно?

PySpark автоматически выводит схему при загрузке структурированных данных, однако для лучшего контроля и повышения эффективности можно явно определить схему с помощью StructType и StructField.

from pyspark.sql.types import StructType, StructField, IntegerType, StringType

schema = StructType([
    StructField("id", IntegerType(), True),
    StructField("name", StringType(), True)
])

df = spark.read.csv("data.csv", schema=schema, header=True)

Advanced PySpark Interview Questions

Для тех, кто претендует на более старшие позиции или стремится продемонстрировать более глубокое понимание PySpark, далее рассматриваются продвинутые вопросы для собеседования, которые углубляются в тонкости преобразований и оптимизаций внутри экосистемы PySpark.

Объясни различия между узкими и широкими преобразованиями в PySpark

В PySpark узкие преобразования выполняются тогда, когда каждый входной партиции соответствует не более одной выходной партиции и при этом не требуется выполнение shuffle. К таким преобразованиям относятся, например, map(), filter() и union(). В противоположность этому, широкие преобразования необходимы для операций, при которых каждая входная партиция может вносить вклад в несколько выходных партиций, и при этом требуется перераспределение данных, выполнение соединений или агрегаций. Примерами таких преобразований являются groupBy(), join() и sortBy().

Что такое оптимизатор Catalyst в Spark и как он работает?

В Spark оптимизатор Catalyst является компонентом Spark SQL, основанным на правилах и предназначенным для оптимизации производительности запросов. Его основная задача заключается в преобразовании и улучшении SQL-запросов или операций DataFrame, заданных пользователем, с целью генерации эффективного физического плана выполнения, адаптированного под конкретный запрос и характеристики набора данных.

Опиши, как реализовать пользовательские агрегации в PySpark

Для реализации пользовательских агрегаций в PySpark можно совместно использовать методы groupBy() и agg(). Внутри вызова agg() можно передавать различные функции из модуля pyspark.sql.functions. Кроме того, можно применять пользовательские агрегации Pandas к группам внутри PySpark DataFrame с помощью метода .applyInPandas(). Ниже приведён пример реализации пользовательских агрегаций в PySpark:

# Использование groupBy и agg с функциями
from pyspark.sql import functions as F
df_from_csv.groupBy("house_id").agg(F.mean("price_discounted"))

# Использование applyInPandas
def normalize_price(df):
    disc_price = df["discounted_price"]
    df["normalized_price"] = disc_price.mean() / disc_price.std()

df_from_csv.groupBy("house_id").applyInPandas(normalize_price)

С какими трудностями ты сталкивался при работе с большими наборами данных в PySpark и как ты их преодолевал?

С помощью этого вопроса можно обратиться к собственному опыту и рассказать о конкретном случае, в котором возникали сложности при работе с PySpark и большими наборами данных, которые могут включать следующее:

• Управление памятью и использование ресурсов.
• Перекос данных и неравномерное распределение нагрузки.
• Оптимизация производительности, особенно для широких преобразований и операций shuffle.
• Отладка и устранение неисправностей сложных сбоев заданий.
• Эффективное партиционирование и хранение данных.

Для преодоления этих проблем PySpark предоставляет возможности партиционирования наборов данных, кэширования промежуточных результатов, использования встроенных техник оптимизации, надёжного управления кластером и применения механизмов отказоустойчивости.

Как интегрировать PySpark с другими инструментами и технологиями в экосистеме больших данных?

PySpark обладает тесной интеграцией с различными инструментами для работы с большими данными, включая Hadoop, Hive, Kafka и HBase, а также с облачными хранилищами, такими как AWS S3 и Google Cloud Storage.

Такая интеграция осуществляется с использованием встроенных коннекторов, библиотек и API, предоставляемых PySpark.

Какие лучшие практики существуют для тестирования и отладки приложений PySpark?

К числу рекомендуемых лучших практик для тестирования и отладки приложений PySpark относятся написание модульных тестов с использованием pyspark.sql.test.SQLTestUtils совместно с Python-библиотеками, такими как pytest, отладка приложений и логирование сообщений с помощью библиотеки logging, а также Spark UI, и оптимизация производительности с использованием API Spark org.apache.spark.metrics и инструментов мониторинга производительности.

Как бы ты решал вопросы безопасности и конфиденциальности данных в среде PySpark?

В настоящее время обмен данными стал значительно проще, поэтому защита чувствительной и конфиденциальной информации является важным способом предотвращения утечек данных. Одной из лучших практик является применение шифрования данных во время обработки и хранения. В PySpark этого можно добиться, используя функции aes_encrypt() и aes_decrypt() для столбцов DataFrame. Также для достижения этой цели можно использовать сторонние библиотеки, такие как библиотека cryptography.

Опиши, как использовать PySpark для построения и развёртывания модели машинного обучения

PySpark предоставляет библиотеку MLlib — масштабируемую библиотеку машинного обучения для построения и развёртывания моделей машинного обучения на больших наборах данных. API этой библиотеки может использоваться на различных этапах ML-процесса, таких как предварительная обработка данных, инженерия признаков, обучение модели, оценка качества и развёртывание. Используя кластеры Spark, можно развёртывать модели машинного обучения на базе PySpark в промышленной среде, применяя пакетный или потоковый инференс.

Как можно оптимизировать операции shuffle в PySpark?

Операции shuffle возникают, когда данные перераспределяются между партициями, и они могут быть затратными с точки зрения производительности. Для оптимизации shuffle можно применять следующие подходы:

• Стратегически использовать repartition() для балансировки партиций перед затратными операциями, такими как join.
• Отдавать предпочтение coalesce() вместо repartition() при уменьшении количества партиций, поскольку это минимизирует перемещение данных.
• Выполнять широковещательные соединения небольших таблиц с помощью broadcast() перед соединением с большими таблицами, чтобы избежать операций, интенсивно использующих shuffle.
• Настраивать конфигурации Spark, такие как spark.sql.shuffle.partitions, для оптимизации количества партиций при shuffle-операциях.

Вопросы для собеседования по PySpark для Data Engineer

Если вы проходите собеседование на позицию инженера данных, ожидайте вопросы, которые оценивают вашу способность проектировать, оптимизировать и устранять проблемы в приложениях PySpark в промышленной среде.

Ниже приведены типичные вопросы, с которыми можно столкнуться.

Опиши, как бы ты оптимизировал задание PySpark, которое работает медленно. На какие ключевые факторы ты бы обратил внимание?

Если задание PySpark работает медленно, существует несколько аспектов, которые можно улучшить для оптимизации его производительности:

• Обеспечение корректного размера и количества партиций данных для минимизации перераспределения данных во время преобразований.
• Использование DataFrame вместо RDD, поскольку они уже используют несколько модулей оптимизации для повышения производительности рабочих нагрузок Spark.
• Использование широковещательных соединений и широковещательных переменных при соединении небольшого набора данных с большим набором данных.
• Кэширование и сохранение промежуточных DataFrame, которые используются повторно.
• Настройка количества партиций, ядер исполнителей и числа экземпляров для эффективного использования ресурсов кластера.

Выбор подходящих форматов файлов для уменьшения объёма данных.

Как обеспечить отказоустойчивость в приложениях PySpark?

Для обеспечения отказоустойчивости в приложениях PySpark можно использовать несколько стратегий:

• Использование чекпойнтинга для сохранения данных в определённых точках.
• Репликация данных путём их сохранения на разных машинах.
• Ведение журнала изменений, выполняемых над данными до их применения.
• Выполнение проверок валидации данных для выявления ошибок.
• Выбор корректного уровня сохранения данных.

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

Какие существуют способы развертывания и управления приложениями PySpark?

Мы можем развертывать и управлять приложениями PySpark с помощью следующих инструментов:

• YARN: менеджер ресурсов, который помогает развертывать и управлять приложениями в Hadoop-кластерах.
• Kubernetes: Spark предоставляет поддержку для развертывания приложений в кластерах Kubernetes.
• Databricks: предоставляет полностью управляемую платформу для приложений PySpark, абстрагируя сложность управления кластерами.

Как вы бы мониторили и устраняли проблемы в заданиях PySpark, работающих в production-среде?

PySpark предоставляет следующие инструменты для мониторинга и устранения проблем заданий, работающих в production-среде:

• Spark UI: веб-интерфейс, который помогает отслеживать прогресс выполнения заданий, использование ресурсов и выполнение задач.
• Логирование: мы можем настроить логирование для сбора детальной информации об ошибках и предупреждениях.
• Метрики: мы можем использовать системы мониторинга для сбора и анализа метрик, связанных с состоянием кластера и производительностью заданий.

Объясните разницу между динамическим и статическим распределением ресурсов в Spark и в каких случаях вы бы выбрали каждый из них

В Spark статическое распределение ресурсов означает предварительное и постоянное выделение фиксированных ресурсов, таких как память и количество ядер executors, на всё время выполнения приложения. В отличие от этого, динамическое распределение ресурсов позволяет Spark динамически изменять количество executors в зависимости от нагрузки. Ресурсы могут добавляться или удаляться по мере необходимости, что улучшает использование ресурсов и снижает затраты.

Как вы принимаете решение между использованием DataFrames и RDD в PySpark?

Выбор между DataFrames и RDD зависит от структуры данных и типа операций, которые необходимо выполнять.

Используйте DataFrames, когда:

• требуется обработка структурированных данных со схемой;
• нужна оптимизированная обработка с использованием Catalyst и Tungsten;
• используются SQL-запросы и встроенные трансформации.

Используйте RDD, когда:

• нужны низкоуровневые трансформации и более детальный контроль над вычислениями;
• вы работаете с неструктурированными или полуструктурированными данными;
• требуется большая гибкость в определении трансформаций.

Как бы вы реализовали инкрементальную обработку данных в PySpark?

Инкрементальная обработка необходима для эффективной работы с постоянно растущими наборами данных. Она может быть реализована с помощью:

• Использования Delta Lake: хранение обновлений в формате Delta позволяет эффективно обрабатывать инкрементальные изменения.
• Использования watermarking в structured streaming: помогает отбрасывать устаревшие данные, сохраняя при этом агрегаты с состоянием.
• Партиционирования и фильтрации: загрузка только новых или изменённых данных вместо переработки всего объёма.
• Использования checkpointing: сохранение промежуточных результатов для предотвращения переработки с нуля в случае сбоя.

Сообщение PySpark Interview — Вопросы и ответы появились сначала на DataTalks.RU. Data Engineering / DWH / Data Pipeline.

GitHub:

• The System Design Primer (329k stars) — Learn how to design large-scale systems. Prep for the system design interview. Includes Anki flashcards
• ByteByteGoHq: System Design 101 (79.5k stars) — Explain complex systems using visuals and simple terms. Help you prepare for system design interviews.
• https://github.com/DovAmir/awesome-design-patterns (45.2k stars) — A curated list of software and architecture related design patterns.
• https://github.com/ashishps1/awesome-system-design-resources (28.2k stars) — Learn System Design concepts and prepare for interviews using free resources.
• https://github.com/madd86/awesome-system-design (11.3k stars) — About
  A curated list of awesome System Design (A.K.A. Distributed Systems) resources.
• https://github.com/ashishps1/awesome-low-level-design (20k stars) — Learn Low Level Design (LLD) and prepare for interviews using free resources.
• https://github.com/mehdihadeli/awesome-software-architecture (10.1k stars) — A curated list of awesome articles, videos, and other resources to learn and practice software architecture, patterns, and principles.
• https://github.com/heynickc/awesome-ddd (12k stars) — A curated list of Domain-Driven Design (DDD), Command Query Responsibility Segregation (CQRS), Event Sourcing, and Event Storming resources

Статьи:

• System Design для начинающих: всё, что вам нужно. Часть 1
• System Design для начинающих: всё, что вам нужно. Часть 2
• System Design для начинающих: всё, что вам нужно. Часть 3
• System Design для начинающих: всё, что вам нужно. Часть 4
• System Design для начинающих: всё, что вам нужно. Часть 5
• Статья — Как построить подготовку к System Design Interview (Александр Поломодов)

YouTube:

• Интервью по System Design. Александр Поломодов (Тинькофф)
• System Design Youtube / TeamLead Avito
• Почему все проваливают собеседование по System Design?
• Как пройти System Design Интервью? 4 этапа, 2 важных качества кандидата
• Mock-собеседование по System Design от Team Lead из Яндекса
• Mock-собеседование по System Design от Team Lead из Ozon
• Как подготовиться и пройти System Design Interview. Александр Поломодов
• Дмитрий Волыхин — System Design-интервью для практиков
• Владимир Маслов — System Design. Как построить распределенную систему и пройти собеседование
• Основы системного дизайна за 30 минут
• Григорий Вахмистров, Владимир Иванов: публичное собеседование по System Design
• Владимир Иванов, Антон Сорокин: публичное собеседование по System Design
• Mock-собеседование по System Design | Ex-Team Lead Яндекс
• Публичное собеседование по System design
• System Design с Валерием Бабушкиным | Выпуск 4 | Собеседование
• ЗАПЛАКАЛ на SYSTEM DESIGN в T-БАНК. FRONTEND СОБЕСЕДОВАНИЕ на 380К
• iOS Мок-собеседование по систем дизайну | Проектируем инстаграм с разработчиком из крупного банка
• #29 Интервью Data Scientist в МосБиржу | Секция System Design | Machine Learning
• #FaangTalk 69 — Вокруг и около System Design интервью
• System Design Interview: 60 минут до оффера / Владимир Невзоров
• СОБЕСЕДОВАНИЕ в ЯНДЕКС на frontend-разработчика. Этап 3: System Design
• Пытаюсь пройти System Design интервью / Такое спрашивают в MAANG? / Mock собеседование
• Собес в Яндекс на Java-разработчика \\ System Design интервью
• Интервью по System Design. youtube

YouTube English:

• System Design Interview: A Step-By-Step Guide
• Design Twitter — System Design Interview
• System Design Playlist

YouTube System Design по темам:

• Как кэшировать данные | Теория кэширования — System Design
• Балансировка в System Design. Алгоритмы на примере NGINX
• Replication in System Design
• System Design. Requirements, HTTP, TCP, Interview
• REDIS для Начинающих за 1 Час | Redis с Нуля Уроки
• Лучший Гайд по HTTP для Начинающих за 25 Мин с Нуля
• Вебинар: Stateful vs. Stateless [Хекслет]
• Stateful vs Stateless Дизайн Веб-Приложений
• Что такое REST API? HTTP, Клиент-Сервер, Проектирование, Разработка, Документация, Swagger и OpenApi
• State management от А до Я. Управление состоянием. Server vs client state. Global vs module
• SSL и TLS — в чем разница?
• TCP и UDP | Что это такое и в чем разница?
• Визуализация архитектуры C4 model / Максим Пальчиков
• Денис Цветцих — C4 model на практике
• Архитектурный репозиторий на базе GitLab и C4 Model для большой компании. Кирилл Ветчинкин
• Нотация C4 и чем она полезна для проектирования Корниенко Андрей

YouTube System Design по темам English:

• Every Type Of API You Must Know Explained!

Общий план по решению задач системного дизайна

Основные этапы интервью (фреймворк) из статьи https://apolomodov.medium.com/how-to-prepare-for-and-pass-the-system-design-interview-78b820589e8

1. Получение задания и контекста — интервьюер даёт название системы и краткое описание.
2. Формализация требований — кандидат задаёт вопросы, уточняет функциональные и нефункциональные требования (например, масштабируемость, доступность, согласованность).
3. Определение границ системы и API — фиксация внешних точек входа, интерфейсов и контрактов.
4. Итеративное проектирование архитектуры — проработка основных потоков (happy path) и исключительных сценариев (exceptional flows).
5. Концептуальная схема — сведение компонентов в общую архитектуру.
6. Выбор технологий и оценка размеров системы (sizing) — обсуждение конкретных инструментов и сколько ресурсов потребуется под нагрузку.
7. Дополнительные вопросы и расширения — optional этап, где обсуждаются дополнительные требования и возможные улучшения.

1) Понимание / уточнение задачи

• Что делать:
  • Спокойно прочитайте задачу.
  • Задавайте вопросы интервьюеру о масштабе, ролях пользователей, сценариях и ограничениях.
• Цель:
  • Выяснить функциональные (что нужно системе делать) и нефункциональные требования (производительность, масштабируемость, отказоустойчивость).

2) Определение ключевых характеристик

• Что требуется выбрать:
  • SCALABILITY (масштабируемость)
  • AVAILABILITY (доступность)
  • CONSISTENCY (согласованность)
  • LATENCY (задержка отклика)
• Как спросить:
  • “Сколько запросов в секунду ожидается?”,
  • “Насколько важна точность данных?”,
  • “Нужно ли работать офлайн?”

3) High-Level Design (Верхнеуровневая архитектура)

• Что делать:
  • Нарисовать базовую схему: Clients → Load Balancer → API Gates → Services → Storage.
  • Определить основные компоненты системы.
• Важно:
  • Покажите, как запросы проходят через систему, какие модули есть и как они связаны между собой.

4) Детализация компонентов

• Проработайте:
  • Какие базы данных (SQL/NoSQL) и почему.
  • Где ставить кеши (Redis/Memcached).
  • Как будут работать очереди сообщений (Kafka, RabbitMQ) для асинхронных задач.
  • Как обеспечить отказоустойчивость (репликация, резервирование).
• Почему это важно:
  • Показывает понимание trade-offs (например, скорость чтения vs. согласованность).

5) Обсуждение сценариев нагрузки

• Примеры вопросов:
  • Что будет при пиковых нагрузках?
  • Как система масштабируется?
  • Чем заменить узкое место?
• Покажите:
  • Как добавить шардирование, их репликацию, горизонтальное масштабирование и оптимизации запросов.

6) Trade-offs и ограничения

• Обсудите:
  • Преимущества и недостатки выбранной архитектуры.
  • Почему выбран тип базы, взаимодействие компонентов и протоколы.
• Цель:
  • Демонстрировать рассуждения — интервьюер смотрит не на правильный ответ, а на логику и аргументацию.

7) Заключение и возможные улучшения

• Что делать:
  • Уточнить, что можно улучшить.
  • Обсудить мониторинг, логирование, безопасность, расширяемость.
• Важно:
  • Показать стратегическое понимание системы за рамками минимального решения.

Короткая формула для интервью

Clarify → High-Level → Deep Dive → Bottlenecks → Trade-offs → Wrap-up

Вертикальное vs горизонтальное масштабирование

Вертикальное и горизонтальное масштабирование — это два принципиально разных подхода к увеличению производительности системы, и каждый из них отражает определённую философию роста.

Вертикальное масштабирование представляет собой усиление одной конкретной машины: ей добавляют больше оперативной памяти, увеличивают количество процессорных ядер, улучшают дисковую подсистему. Система по сути остаётся той же, меняется лишь «железо», на котором она работает. Такой подход привлекателен своей простотой: нет распределённых компонент, нет необходимости координировать состояние между несколькими серверами, нет дополнительных слоёв инфраструктуры. Приложению не требуется перестраиваться — оно просто получает больше ресурсов и продолжает функционировать.

Тем не менее в вертикальном масштабировании заложены фундаментальные ограничения. Во-первых, у любой машины есть предел: невозможно бесконечно увеличивать оперативную память или количество процессорных ядер, и чем мощнее становится сервер, тем быстрее растёт цена каждой следующей единицы мощности. Во-вторых, несмотря на своё удобство, вертикальное масштабирование плохо помогает обеспечить высокую доступность. Если такой единственный мощный сервер выходит из строя, система оказывается уязвимой, и её восстановление занимает время.

Горизонтальное масштабирование решает проблему иначе: вместо усиления одного узла в архитектуру добавляются новые машины, и нагрузка распределяется между ними. Такой подход требует совершенно другой организации приложения. Оно должно уметь работать в распределённой среде, где его копии запускаются параллельно, часто в разных зонах доступности или даже регионах. Данные должны быть реплицированы или разделены на части между узлами, а доступ к сервисам — сбалансирован через специальные компоненты.

Горизонтальное масштабирование намного сложнее в реализации: возникают вопросы согласованности данных, появляются риски сетевых задержек, нужен продуманный механизм обнаружения и изоляции неисправных узлов, а также система автоматического масштабирования, которая будет добавлять и удалять ресурсы в соответствии с текущей нагрузкой. Но вместе с этой сложностью приходит то, чего невозможно достичь вертикальным путём: потенциально неограниченная масштабируемость. Система, построенная на горизонтальном увеличении ресурсов, может расти практически без верхней границы, добавляя всё больше узлов в ответ на увеличение нагрузки. Кроме того, высокая доступность становится естественной частью архитектуры — если один сервер выходит из строя, его роль автоматически берут на себя другие.

Stateful vs stateless сервисы

В мире распределённых систем различие между stateful и stateless сервисами оказывает огромное влияние на архитектуру, масштабируемость и отказоустойчивость.

Stateless-сервисы — это наиболее простой и предсказуемый тип сервисов. Они не хранят никакого состояния между запросами, и каждый запрос обрабатывается так, будто он первый. Сервис не полагается на память о предыдущих взаимодействиях и не требует сохранения пользовательских данных локально. Он получает входные данные, выполняет вычисление и возвращает результат — всё. Именно эта независимость от истории делает такие сервисы чрезвычайно удобными для масштабирования: любую копию сервиса можно добавить или удалить безо всяких последствий, а балансировщик запросов свободно распределяет нагрузку между экземплярами. Фактически stateless-архитектура превращает сервисы в вычислительные «ячейки», которые можно размножать, заменять, обновлять и уничтожать без риска потерять данные или нарушить целостность работы системы.

Stateful-сервисы живут совсем по другим законам. Они хранят состояние — пользовательские сессии, данные, транзакции, контекст взаимодействия, внутренние буферы или кэш, необходимый для корректной работы. Это означает, что один и тот же клиентский запрос должен прийти на тот же узел, который держит состояние, либо состояние должно быть доступно всем узлам через внешний механизм — например, через распределённое хранилище. Система становится более связанной и менее гибкой: невозможно просто взять и создать ещё одну копию сервиса без обеспечения согласованности состояния, так же как невозможно безболезненно выключить существующий узел, пока данные не будут корректно перенесены. Stateful-архитектуры требуют репликации, механизмов консенсуса, мониторинга здоровья узлов и сложных алгоритмов распределения нагрузки. Именно состояние делает систему более “живой”, но одновременно и более хрупкой, более чувствительной к сбоям и сетевым задержкам.

На практике граница между этими двумя типами сервисов редко бывает абсолютно чёткой. Даже самые чистые stateless-сервисы почти всегда используют внешние stateful-хранилища — базы данных, кеши, очереди. Многие stateful-узлы пытаются минимизировать объём состояния, вынеся всё возможное наружу, чтобы упростить масштабирование. Современные архитектуры стремятся к тому, чтобы сами сервисы оставались максимально stateless, а состояние хранилось в специализированных, хорошо масштабируемых стореджах, разработанных для управления консистентностью и отказоустойчивостью.

И всё же фундаментальный принцип остаётся неизменным: stateless-сервисы дают гибкость, простоту и практически линейную масштабируемость, в то время как stateful-сервисы дают возможность работать с реальными данными, но требуют гораздо более сложной инфраструктуры и становятся естественной точкой роста сложности всей системы. Понимание различий между ними лежит в основе любого серьёзного проектирования — от API-сервисов до распределённых баз данных — и определяет, каким образом система будет расти, выдерживать нагрузку и восстанавливаться после сбоев.

Где необходим Stateful подход

Во-первых, это базы данных и хранилища. Любая СУБД по своей сути stateful: она хранит данные, индексы, кэши, журналы транзакций и метаданные. Попытка сделать базу stateless лишена смысла, потому что её ценность — именно в сохранении и управлении состоянием. Здесь statefulness компенсируется репликацией, шардингом и механизмами восстановления.

Во-вторых, in-memory системы с состоянием, такие как Redis, Memcached, Kafka, стриминговые движки и очереди сообщений. Они держат состояние либо в памяти, либо в логах, чтобы обеспечить низкую задержку и высокую пропускную способность. Например, Kafka хранит offset’ы, порядок событий и данные топиков; Flink хранит состояние операторов; Redis — кэш и структуры данных. Вынесение этого состояния «куда-то ещё» разрушило бы их основную функцию.

Третья важная категория — долгоживущие соединения и real-time системы. WebSocket-серверы, игровые серверы, чаты, видеостриминг и push-уведомления требуют постоянного контекста соединения. Здесь состояние связано не только с данными, но и с самим фактом открытого канала связи. Каждый клиент «привязан» к конкретному соединению, и это невозможно сделать полностью stateless без потери функциональности или резкого усложнения архитектуры.

Четвёртая область — стриминговая и event-driven обработка данных. В системах вроде Flink или Spark Streaming состояние необходимо для оконных агрегаций, подсчётов, дедупликации и работы с event time. Без хранения промежуточного состояния невозможно корректно обрабатывать потоки событий. Здесь stateful-подход — не компромисс, а обязательное условие корректности.

Пятая категория — сессии и пользовательский контекст, когда объём состояния велик или часто изменяется. Например, сложные бизнес-процессы, оркестрация саг, workflow-движки, системы бронирования или финансовые процессы. Передавать весь контекст в каждом запросе было бы дорого и небезопасно, поэтому состояние хранится централизованно и обновляется постепенно.

Наконец, stateful-подход оправдан в алгоритмически сложных системах, таких как антифрод, рекомендательные системы, графовые движки и системы машинного обучения онлайн-типа. Они опираются на накопленный контекст, историю и взаимосвязи, которые невозможно эффективно пересчитывать «с нуля» на каждый запрос.

Шардинг vs Репликация

В распределённых хранилищах шардинг и репликация выполняют две разные роли, хотя на практике почти всегда работают вместе.

Репликация — это способ обеспечить надёжность и доступность данных, копируя одну и ту же информацию на несколько узлов. Каждая реплика содержит полный набор данных или хотя бы их логически завершённую часть. Если один сервер выходит из строя, другой может мгновенно его заменить, а система продолжает работать без потерь. Репликация служит своего рода страховкой: она защищает от аппаратных отказов, позволяет распределить нагрузку на чтение между репликами и уменьшает вероятность простоев. Но при всей своей полезности репликация не увеличивает фактическую ёмкость хранилища. Сколько бы копий ни было, каждая хранит всё то же самое. Это делает систему более надёжной, но не более масштабируемой по данным.

Шардинг решает совершенно другую задачу. Если объём информации растёт, а одна база данных перестаёт помещаться на один сервер, приходится дробить набор данных на отдельные сегменты — шарды. Каждый шард хранит только свою часть информации, и вместе эти части образуют целостное хранилище. Это увеличивает вместимость системы практически без предела: можно добавлять новые узлы и переносить на них отдельные части данных, обеспечивая горизонтальную масштабируемость. Но вместе с этим приходит сложность маршрутизации: система должна знать, на какой узел отправить запрос; данные становятся распределёнными, и объединить их в рамках одного запроса может быть гораздо сложнее. Шардинг усложняет операции поиска, агрегирования и транзакций — то, что на одном сервере выполнялось просто, в распределённой среде требует дополнительной логики и координации.

Если репликация защищает данные, но не делает систему “больше”, то шардинг делает систему “больше”, но не защищает её сам по себе. В реальной инфраструктуре редко выбирают между ними — чаще строят комбинацию: каждый шард реплицируется на несколько узлов, чтобы обеспечить и масштабируемость, и отказоустойчивость. Таким образом, хранилище растёт по горизонтали, но при этом любой сервер внутри шарда может выйти из строя без потери данных.

Репликация обеспечивает выживаемость и высокую доступность, но не повышает общую вместимость. Шардинг обеспечивает масштабируемость и распределение нагрузки, но требует более сложной архитектуры и не гарантирует защиту от отказов. Вместе они образуют фундамент современных распределённых хранилищ, позволяя одновременно хранить огромные объёмы данных, выдерживать высокие нагрузки и оставаться устойчивыми к сбоям.

Синхронные vs Асинхронные коммуникации

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

Синхронная модель предполагает, что один сервис отправляет запрос другому и ждёт ответа, прежде чем продолжить работу. Она проста и естественна: запрос связан с ответом, логика понятна, а поток выполнения легко проследить от начала до конца. Такой подход даёт ощущение прямого диалога между системами — пока один говорит, другой слушает и отвечает. Но эта же простота становится источником ограничений. Один медленный сервис способен заблокировать цепочку зависящих от него вызовов. Если где-то возникает задержка или временная недоступность, всё дерево запросов начинает сбоить, а нагрузка растёт каскадом. Система с активным использованием синхронных вызовов становится тесно связанной: здоровье каждого узла напрямую влияет на остальных, и архитектура в целом становится менее устойчивой к непредсказуемости реального мира.

Асинхронные коммуникации предлагают совершенно иной способ взаимодействия. Вместо прямого запроса и ожидания ответа сервис только отправляет сообщение — чаще всего в очередь, шину событий или брокер сообщений — и продолжает работу, не дожидаясь реакции. Это создаёт естественную буферизацию между компонентами: отправитель не знает и не обязан знать, кто обработает сообщение, как скоро это произойдёт и какой объём нагрузки сейчас испытывает получатель. Каждый сервис работает в собственном темпе, а система становится более устойчивой к всплескам нагрузки и временной недоступности отдельных элементов. Потеря скорости одним узлом не приводит к немедленному эффекту домино: сообщения аккуратно накапливаются в очереди, а потребители обрабатывают их по мере готовности.

Однако асинхронность не является универсальным лекарством. Она усложняет разработку: связь между действиями теряется, цепочка событий больше не очевидна, а отладка требует инструментов трассировки. Возникают вопросы гарантии доставки, порядка обработки сообщений и идемпотентности — способности сервиса безопасно принимать одно и то же сообщение несколько раз. Кроме того, асинхронная модель неизбежно добавляет задержку между причиной и следствием, что неприемлемо для систем, требующих мгновенного ответа.

Синхронные коммуникации хороши там, где важна непосредственная взаимосвязь и актуальность данных: запрос к платежному шлюзу, получение результата вычисления, верификация пользователя. Асинхронные коммуникации незаменимы в системах, которые должны выдерживать пики нагрузки, сохранять устойчивость при сбоях и развязывать зависимости между компонентами: отправка email, обработка событий, построение аналитических пайплайнов.

Выбор между синхронностью и асинхронностью — это баланс между простотой и устойчивостью, между скоростью отклика и гибкостью, между тесным связующим контуром и свободным, событийным взаимодействием. В зрелых системах они почти всегда сосуществуют: критически важные операции выполняются синхронно, а всё остальное передаётся по асинхронным каналам, создавая архитектуру, которая одновременно понятна разработчику и остаётся надёжной под непостоянными нагрузками реального мира.

HTTP, сети и протоколы

HTTP

HTTP — это фундамент современных интернет-сервисов, и его эволюция показывает, как интернет постепенно менялся, подстраиваясь под рост потребностей.

HTTP/1.1 был простым и понятным, но страдал от ограничений: каждый запрос открывал новый TCP-коннект или пытался переиспользовать существующий, а браузер мог отправлять лишь несколько параллельных запросов к одному домену. Это приводило к классическим «водопадам» загрузки страниц, где каждый ресурс ждал своей очереди.

HTTP/2 решает эту проблему принципиально иначе: один TCP-коннект превращается в многопоточный канал, где десятки запросов и ответов идут параллельно, перемешиваясь между собой. Появляется бинарный формат, сжатие заголовков и серверные push-запросы. Но HTTP/2 всё равно опирается на TCP, а значит страдает от «головной блокировки строки»: потеря одного пакета может заморозить весь поток.

HTTP/3 делает шаг ещё дальше и строится поверх QUIC — протокола на базе UDP, который обеспечивает поточность на уровне приложения. Потеря пакета больше не замораживает весь трафик, только конкретный поток, и система становится заметно быстрее в реальных сетях с непостоянным качеством соединения, например в мобильных сетях.

WebSockets и long polling

Рядом с HTTP стоит другая важная модель взаимодействия: WebSockets и long polling. Обычный HTTP предполагает короткий запрос и короткий ответ, но многие приложения — чат, игры, торговые терминалы — требуют постоянного двустороннего соединения.

Long polling пытается имитировать реальную подписку: клиент делает запрос, сервер держит его открытым и отвечает только тогда, когда есть новое событие. Это работает, но создаёт дополнительную нагрузку.

WebSocket же устанавливает постоянный канал поверх HTTP-upgrade и превращает клиент и сервер в равноправных участников, способных посылать сообщения в любой момент. Такой канал позволяет строить системы реального времени без постоянных открытий и закрытий соединений.

TCP и UDP

На ещё более низком уровне находится различие между TCP и UDP — двумя фундаментальными транспортными протоколами.

TCP создаёт надёжный поток данных: пакеты приходят в правильном порядке, пропавшие переотправляются, а канал гарантирует доставку. Это идеально подходит для веб-страниц, API, финансовых транзакций.

UDP работает иначе: он не пытается контролировать порядок доставки или гарантировать успех. Но именно благодаря этому UDP быстрее — и становится основой для мультимедиа, игр, стриминга и современных протоколов вроде QUIC. В системном дизайне важно понимать эту разницу: когда важнее скорость, а когда — надёжность.

CDN

И наконец — CDN, тихий герой высокопроизводительного интернета. Контент-дистрибуционные сети выносят копии статических ресурсов ближе к пользователям, сокращая путь, который проходит запрос. Это не просто «кэширование на периферии», это целая географически распределённая сеть узлов, способная взять на себя огромную часть нагрузки и сделать систему более устойчивой к всплескам трафика. CDN особенно важна в глобальных сервисах, где пользователи находятся на разных континентах, а даже небольшое уменьшение задержки может сильно улучшить пользовательский опыт.

Данные и хранение

SQL vs NoSQL

Одним из первых выборов, который приходится делать при проектировании системы, становится выбор между SQL и NoSQL.

Реляционные базы данных — это строгая схема, предсказуемые запросы, гарантии транзакционной целостности и мощная декларативная модель языка SQL. Они блестяще подходят для систем, где данные имеют чёткую структуру: финансы, транзакции, инвентаризация, биллинг. Там, где важна консистентность и возможность выполнять сложные запросы, SQL остаётся безальтернативным решением.

NoSQL появился как ответ на другие требования: гибкость схемы, огромные объёмы данных и горизонтальная масштабируемость. Документные базы и key-value системы не навязывают структуру, легко растут по горизонтали и прекрасно работают там, где данные имеют иерархическую природу или где система должна выдерживать колоссальную нагрузку на чтение. Выбор между SQL и NoSQL никогда не сводится к моде — он всегда определяется моделями доступа, структурой процессов и требованиями к согласованности.

Индексы

Работа с данными неизбежно приводит к вопросу индексов — того механизма, который делает операции поиска не просто возможными, но эффективными.

В основе большинства индексов в реляционных базах лежат B-tree структуры, оптимизированные под дисковые операции. Они позволяют находить строки по ключу или по диапазону за логарифмическое время, что делает их универсальным инструментом для большинства запросов.

Hash-индексы работают иначе: они идеальны для точечных lookup-запросов, но не позволяют выполнять операции по диапазонам. Понимание того, как устроен индекс, помогает избежать ошибок — например, почему сортировка по неиндексированному полю превращается в дорогостоящую операцию, или почему сложно оптимизировать запросы, которые фильтруют по нескольким колонкам с разной селективностью.

Транзакционная изоляция

Даже в относительно простых системах важно понимать основы транзакционной изоляции — те уровни, которые определяют, какие аномалии допускаются при одновременных операциях. Read Uncommitted почти не используется, Read Committed обеспечивает базовую защиту от грязных чтений, Repeatable Read предотвращает непредсказуемые изменения данных в пределах одной транзакции, а Serializable создаёт иллюзию последовательного выполнения операций. На практике полный Serializable слишком дорог, и большинство систем выбирают компромисс — изоляцию, которая устраняет самые опасные аномалии, но не мешает масштабированию.

API Gateway vs. Load Balancer

Load Balancer (Балансировщик нагрузки) — это система, отвечающая за распределение входящего трафика между несколькими серверами, скрытыми за одной точкой входа. Его можно представить как регулировщика движения, который направляет автомобили (запросы) по параллельным полосам (серверам), не допуская образования заторов в сети.

Когда балансировщик обнаруживает всплеск API-запросов, он может автоматически перенаправлять их на подходящие серверы приложений, не позволяя одному узлу быть перегруженным пользовательскими запросами.

Цель балансировщика нагрузки — оптимизировать использование ресурсов, снизить задержки и устранить единые точки отказа. Балансировщики могут работать на разных уровнях модели OSI — от уровня 4 (транспортного) до уровня 7 (прикладного).

На уровне 4 балансировщики опираются на базовую сетевую информацию, такую как IP-адреса и порты, и принимают решения о распределении трафика на основе простых правил. Балансировщики уровня 7 работают на уровне приложения, анализируя HTTP-заголовки, cookies и другие данные запросов, чтобы более осмысленно распределять трафик.

В реальных системах широко используются такие инструменты, как Nginx, HAProxy, а также механизмы балансировки нагрузки, предоставляемые публичными облачными провайдерами. Балансировщики особенно важны в средах с высоким трафиком, например на e-commerce-платформах, где они помогают гарантировать, что ни один сервер не будет перегружен запросами, особенно в периоды пиковых нагрузок — во время флеш-распродаж или сезонов активных покупок.

API Gateway — это центральная точка управления, которая контролирует и направляет API-трафик между клиентами и микросервисами, обеспечивая эффективное и безопасное взаимодействие. В отличие от балансировщика нагрузки, который лишь распределяет запросы, API Gateway интеллектуально оркестрирует API-вызовы, маршрутизирует запросы к соответствующим backend-сервисам и позволяет применять единые политики управления API. Вместе API Gateway и продвинутый подход к API-менеджменту позволяют объединить микросервисы за единым интерфейсом.

API Gateway также предоставляет расширенные возможности, такие как ограничение скорости запросов (rate limiting), управление аутентификацией и авторизацией, трансформацию запросов, кеширование, аналитику и многое другое. В микросервисных средах внедрение gateway снижает сложность системы за счёт централизации сквозных задач и упрощения управления. Вместо того чтобы реализовывать эти механизмы в каждом микросервисе по отдельности, gateway выступает в роли единой точки входа, упрощая эксплуатацию и повышая сопровождаемость системы.

В типичном сценарии клиент отправляет запрос в API Gateway. Gateway анализирует запрос, проверяет токены безопасности, при необходимости переписывает или трансформирует данные и затем маршрутизирует запрос в соответствующий микросервис. Когда микросервис возвращает ответ, gateway может преобразовать полезную нагрузку обратно для клиента или применить логику кеширования для повышения производительности. Таким образом, API Gateway — это не просто инструмент для равномерного распределения запросов, а компонент, который контролирует и посредничает во всём взаимодействии между клиентами и backend-сервисами.

Во многих зрелых микросервисных экосистемах API Gateway часто используется совместно с решениями для API-менеджмента, чтобы упростить управление, анализ использования и применение политик.

Когда выбирать Load Balancer:

Если ваша задача — просто распределять трафик между несколькими серверами или контейнерами, обеспечивать отказоустойчивость и равномерное использование ресурсов, то балансировщик — это ваш инструмент. Он отлично подходит для классических приложений с высокой нагрузкой, контейнерных сервисов, где важна горизонтальная масштабируемость, а логика распределения не требует глубокого анализа запросов.

Когда выбирать API Gateway:

Если вы строите микросервисную архитектуру и хотите единый интерфейс для всех API, централизовать безопасность, авторизацию, throttle/rate limiting, логирование, трансформацию запросов или предоставлять разные версии API, то API Gateway — более подходящее решение. Он выступает «консьержем API», скрывая сложность микросервисов от клиентов и обеспечивая единообразное управление трафиком и политиками.

Когда использовать оба вместе:

В больших продуктах часто применяют сочетание API Gateway + Load Balancer. Например, Load Balancer распределяет трафик по нескольким экземплярам API Gateway для отказоустойчивости и масштабирования, а сам Gateway выполняет логические проверки и маршрутизацию к микросервисам. В других архитектурах Gateway сначала обрабатывает запрос, а затем передаёт его на Load Balancer внутри кластера микросервисов.

Rate limiting / throttling

Rate limiting / throttling — это механизм контроля количества запросов, которые клиент или группа клиентов может отправить в систему за определённый промежуток времени. Его цель — защитить сервисы от перегрузки, злоупотреблений и неравномерного использования ресурсов, сохранив стабильность и предсказуемость работы системы.

В основе rate limiting лежит простая идея: любые вычислительные ресурсы конечны, и если не ограничивать входящий поток запросов, один пользователь, бот или ошибка в коде могут исчерпать эти ресурсы и повлиять на всех остальных. Throttling позволяет системе вежливо, но жёстко сказать: «Ты уже отправил достаточно запросов, подожди немного».

С точки зрения поведения системы rate limiting проявляется в том, что при превышении лимита новые запросы либо отклоняются с ошибкой вроде HTTP 429 Too Many Requests, либо обрабатываются с задержкой. Это создаёт предсказуемый потолок нагрузки и позволяет сервису продолжать работу даже в условиях пикового трафика или атаки.

В распределённых системах rate limiting часто применяется на границе системы — в API Gateway, балансировщике нагрузки или edge-инфраструктуре. Это позволяет отсекать избыточный трафик ещё до того, как он достигнет внутренних сервисов и баз данных. Например, публичное API может разрешать 100 запросов в минуту на один API-ключ, чтобы ни один клиент не мог монополизировать систему.

Существует несколько распространённых алгоритмов rate limiting. Fixed window ограничивает количество запросов в жёстких временных окнах, но может допускать всплески на границе окон. Sliding window сглаживает эти эффекты, учитывая реальное распределение запросов во времени. Token bucket и leaky bucket моделируют систему как сосуд, в который поступают «токены» с фиксированной скоростью, позволяя временные пики, но контролируя среднюю нагрузку. Эти модели широко используются в реальных системах, потому что они хорошо балансируют гибкость и контроль.

Важно понимать разницу между rate limiting и throttling. Rate limiting обычно означает жёсткое ограничение — запросы сверх лимита просто отклоняются. Throttling чаще подразумевает мягкое управление скоростью — система может замедлять ответы, ставить запросы в очередь или постепенно снижать пропускную способность. На практике эти термины часто используются вместе, потому что решают одну и ту же задачу — защиту системы от перегрузки.

В реальных продуктах rate limiting применяется повсеместно. Stripe ограничивает частоту запросов к платёжным API, GitHub — к своим публичным endpoint’ам, а облачные провайдеры используют throttling для защиты инфраструктуры от внезапных всплесков нагрузки. Даже внутри микросервисных архитектур rate limiting важен: он предотвращает ситуации, когда один сервис начинает агрессивно дергать другой и провоцирует каскадные отказы.

Kafka и RabbitMQ

Kafka и RabbitMQ решают похожую задачу — передачу сообщений между компонентами системы, — но делают это принципиально по-разному. Понимание этой разницы важно для системного дизайна, потому что выбор между ними влияет на масштабируемость, модель обработки данных и даже на то, как система будет эволюционировать со временем.

RabbitMQ — это классический брокер сообщений. Его модель ближе всего к очереди задач: продюсер отправляет сообщение, брокер гарантирует его доставку, а консьюмер забирает сообщение и подтверждает обработку. После подтверждения сообщение исчезает. RabbitMQ активно управляет сообщениями: он знает, кто их получил, кто подтвердил, кому нужно сделать retry, а кому отправить сообщение в dead-letter очередь. Это делает RabbitMQ отличным выбором для систем, где важна надёжная доставка каждой задачи и сложная логика маршрутизации. Например, фоновые задачи вроде отправки email, обработки платежей, генерации отчётов или работы с внешними API часто реализуются через RabbitMQ. Здесь критично, чтобы каждое сообщение было обработано ровно один раз или, как минимум, не потерялось.

Kafka работает по другой философии. Это не столько очередь, сколько распределённый лог событий. Сообщения в Kafka не удаляются после чтения — они сохраняются в топике в течение заданного времени или до достижения лимита размера. Консьюмеры сами отслеживают, что они прочитали, управляя своим offset. Это позволяет нескольким независимым сервисам читать одни и те же данные, каждый в своём темпе, не мешая друг другу. Kafka отлично подходит для систем, где важен поток событий, высокая пропускная способность и возможность повторного воспроизведения данных. LinkedIn, Uber и Netflix используют Kafka как основу для аналитики, построения фидов, логирования и event-driven архитектур.

С точки зрения производительности Kafka рассчитана на очень большие объёмы данных и высокую скорость записи — сотни тысяч или миллионы сообщений в секунду. Она масштабируется горизонтально за счёт партиций и распределения нагрузки между брокерами. RabbitMQ тоже масштабируется, но его сильная сторона не в throughput, а в гибкости: сложные схемы routing, topic-exchange, приоритеты сообщений, подтверждения и ретраи.

Есть и различие в характере гарантий доставки. RabbitMQ ориентирован на надёжность обработки каждой задачи и богатую семантику доставки. Kafka чаще используется в модели «at-least once» или «exactly once» (при определённой настройке), но с акцентом на потоковую обработку, а не на индивидуальные задания. В Kafka допустима идея, что сообщение может быть обработано повторно, и система должна быть к этому готова.

Если упростить, RabbitMQ — это инструмент для команд и задач, Kafka — инструмент для событий и потоков данных. Если нужно гарантированно выполнить конкретное действие — например, списать деньги или отправить письмо — чаще выбирают RabbitMQ. Если же нужно зафиксировать факт события и позволить многим сервисам независимо на него реагировать — например, «пользователь сделал заказ» или «поездка завершена» — Kafka становится естественным выбором.

В реальных архитектурах эти системы нередко используются вместе. Kafka может служить основным «хребтом» событийной архитектуры, а RabbitMQ — обслуживать операционные задачи и фоновые процессы. Понимание их различий позволяет осознанно выбирать инструмент под конкретную задачу, а не поддаваться моде или привычке.

Когда выбирать Kafka

Kafka подходит, если:

• нужен event-driven подход
• требуется очень высокий throughput
• несколько сервисов должны читать одни и те же события
• нужна возможность переигрывать события
• строится аналитика или стриминг
• данные — это «история событий»

Примеры:

• аналитика пользовательских действий
• feed generation
• логирование
• real-time metrics
• event sourcing

Когда выбирать RabbitMQ

RabbitMQ подходит, если:

• нужна гарантированная обработка каждой задачи
• важна низкая задержка
• требуется сложная маршрутизация
• есть retry, DLQ, приоритеты
• задачи короткие и независимые

Примеры:

• отправка email/SMS
• фоновые job’ы
• обработка заказов
• интеграции с внешними API
• task queues (Celery)

Fan-out и Fan-in

Fan-out и Fan-in — это базовые паттерны распределённых систем, которые описывают, как запросы или события расходятся и сходятся между компонентами системы. Эти понятия часто встречаются в системном дизайне, очередях сообщений, микросервисах и стриминговых архитектурах.

• Fan-out: один источник — много получателей.
• Fan-in: много источников — один агрегатор.

Fan-out

Fan-out — это ситуация, когда одно событие или запрос «размножается» и отправляется сразу нескольким получателям. Источник генерирует одно сообщение, а система доставки гарантирует, что его получат все заинтересованные сервисы. В этом паттерне отправитель не знает и не должен знать, сколько получателей существует и кто они именно.

Fan-out используется, когда один факт в системе должен вызвать несколько независимых реакций. Например, пользователь зарегистрировался. Это одно событие, но на него могут реагировать разные сервисы: один отправляет приветственное письмо, другой создаёт профиль, третий обновляет аналитику, четвёртый инициирует рекомендации. Все эти действия должны происходить параллельно и не блокировать друг друга.

В Kafka fan-out реализуется естественным образом через consumer groups: одно и то же событие читается разными группами консьюмеров, каждая из которых обрабатывает его по-своему. В RabbitMQ fan-out достигается с помощью exchange, который копирует сообщение во множество очередей. В HTTP-мире fan-out встречается, когда API Gateway делает несколько внутренних вызовов, собирая данные из разных сервисов.

Fan-in

Fan-in — это обратный процесс: несколько источников данных сходятся в одну точку обработки. Система получает события или результаты от множества сервисов и агрегирует их, объединяет или синхронизирует.

Fan-in применяется, когда нужно собрать данные из разных частей системы и получить единый результат. Например, при формировании news feed сервис может получать посты от сервиса подписок, рекламы, рекомендаций и трендов, а затем объединять их в одну ленту. В аналитике fan-in используется для агрегации логов, метрик и событий со множества узлов в один поток для обработки или хранения.

В Kafka fan-in выглядит как множество продюсеров, пишущих в один топик. В RabbitMQ — как несколько продюсеров, отправляющих сообщения в одну очередь. В микросервисах fan-in часто реализуется на уровне сервиса-агрегатора или API Gateway, который собирает ответы от нескольких backend-сервисов и возвращает клиенту единый результат.

Caching (Кеширование)

Кеширование — это один из ключевых инструментов системного дизайна, позволяющий снизить задержки, уменьшить нагрузку на базу данных и повысить устойчивость системы под высокой нагрузкой. В основе кеширования лежит идея временного хранения часто запрашиваемых или дорогих в вычислении данных ближе к месту использования. Однако важно не просто «добавить кеш», а выбрать правильный паттерн, потому что каждый из них по-разному влияет на согласованность данных, сложность системы и сценарии отказов.

Самый распространённый и интуитивно понятный подход — Cache Aside. В этом паттерне ответственность за работу с кешем полностью лежит на приложении. Когда приходит запрос, приложение сначала проверяет кеш. Если данные там есть, они сразу возвращаются клиенту. Если данных нет, приложение идёт в базу данных, получает результат и кладёт его в кеш, чтобы последующие запросы были быстрее. При записи или обновлении данных приложение сначала пишет в базу, а затем инвалидирует или обновляет кеш. Этот подход прост, прозрачен и хорошо контролируем, поэтому он используется в большинстве веб-приложений. Его слабое место — риск временной неконсистентности и cache stampede, когда множество запросов одновременно промахиваются мимо кеша.

Read-Through Cache переносит логику загрузки данных в сам кеш. Приложение всегда обращается только к кешу, а при промахе кеш сам идёт в базу данных, загружает данные и возвращает их приложению. Для разработчика это выглядит как доступ к одному источнику данных, что упрощает код. Такой подход часто реализуется в managed-решениях или библиотеках, тесно интегрированных с хранилищем. Однако он усложняет инфраструктуру и снижает прозрачность: приложение меньше контролирует, когда и как происходят обращения к базе.

Write-Through Cache ориентирован на согласованность данных при записи. Когда приложение сохраняет данные, оно сначала пишет их в кеш, а кеш синхронно записывает изменения в базу данных. Благодаря этому чтения всегда получают актуальные данные из кеша, а риск рассинхронизации минимален. Цена за это — более высокая задержка на запись, так как операция считается завершённой только после записи в базу. Такой паттерн подходит для систем, где корректность данных важнее скорости записи.

Write-Behind (или Write-Back) делает шаг в сторону производительности. Запись сначала происходит только в кеш, а в базу данные сохраняются асинхронно, с задержкой или батчами. Это резко ускоряет операции записи и хорошо работает под высокой нагрузкой. Но взамен система становится более сложной и менее надёжной: при падении кеша есть риск потери данных, а база данных временно содержит устаревшее состояние. Этот подход применяют там, где допустима eventual consistency и где кеш можно сделать надёжным, например с журналированием или репликацией.

Materialized Views выходят за рамки классического кеша, но решают похожую задачу — ускорение чтения. Вместо того чтобы каждый раз выполнять сложные JOIN’ы или агрегации, система заранее вычисляет результат запроса и хранит его в виде отдельной таблицы или представления. При чтении данные отдаются мгновенно, но за это приходится платить сложностью обновления: при изменении исходных данных materialized view нужно пересчитывать полностью или инкрементально. Такой подход часто используется в аналитических системах, отчетах и read-heavy сценариях.

Event Sourcing — это более фундаментальный архитектурный паттерн, в котором состояние системы не хранится напрямую, а восстанавливается из последовательности событий. Сами события являются единственным источником истины, а текущее состояние и производные представления могут кешироваться или храниться как materialized views. В этом контексте кеширование становится способом ускорить восстановление состояния и чтение, а не источником данных. Event sourcing даёт отличную масштабируемость и трассируемость изменений, но значительно усложняет систему и требует зрелого подхода к консистентности и миграциям.

В реальных системах эти подходы редко используются поодиночке. Чаще всего Cache Aside применяется для простых CRUD-операций, write-through или write-behind — для горячих данных с высокой нагрузкой на запись, materialized views — для сложных запросов, а event sourcing — для доменных ядер, где важна история изменений.

Кеширующие системы, которые должен знать каждый разработчик

Данные кешируются повсюду — от клиентской стороны до backend-систем. Рассмотрим основные уровни кеширования, которые используются для оптимизации производительности.

Слои кеширования

Клиентские приложения. Браузеры кешируют HTTP-ответы. Серверные ответы содержат директивы кеширования в заголовках. При последующих запросах браузер может отдать данные из кеша, если они всё ещё считаются актуальными.

Сети доставки контента (CDN). CDN кешируют статический контент — изображения, стили, JavaScript-файлы. Контент обслуживается с серверов, расположенных ближе к пользователям, что снижает задержки и ускоряет загрузку страниц.

Балансировщики нагрузки. Некоторые балансировщики способны кешировать часто запрашиваемые данные. Это позволяет отдавать ответы без обращения к backend-серверам, снижая нагрузку и уменьшая время отклика.

Брокеры сообщений. Системы вроде Kafka кешируют сообщения на диске в соответствии с политикой хранения (retention). Потребители затем читают сообщения в удобном для них темпе.

Сервисы. Отдельные сервисы часто используют кеширование для ускорения доступа к данным, сначала проверяя in-memory кеш перед обращением к базе данных. Также может применяться дисковое кеширование для больших объёмов данных.

Распределённые кеши. Системы вроде Redis кешируют пары ключ–значение и используются несколькими сервисами одновременно, обеспечивая более быстрые операции чтения и записи по сравнению с традиционными базами данных.

Полнотекстовые поисковые движки. Платформы вроде Elasticsearch индексируют данные для быстрого текстового поиска. Такой индекс по сути является формой кеша, оптимизированного под быстрый поиск по тексту.

Базы данных. Внутри СУБД существуют специализированные механизмы повышения производительности, многие из которых используют идеи кеширования.

Механизмы кеширования в базах данных

Buffer Pool. Это внутренний кеш базы данных, который хранит копии страниц данных в памяти. Он позволяет быстро читать и записывать данные во временное хранилище в RAM, снижая необходимость обращаться к диску.

Materialized Views. Материализованные представления похожи на кеши тем, что хранят результаты вычислительно дорогих запросов. База данных может быстро вернуть заранее вычисленные результаты вместо того, чтобы пересчитывать их каждый раз.

В совокупности эти уровни кеширования образуют многоуровневую систему оптимизации, где каждый слой уменьшает задержки и нагрузку на следующий, более «глубокий» уровень инфраструктуры.

Примеры систем кеширования

На уровне приложений чаще всего используются специализированные in-memory хранилища, такие как Redis и Memcached. Они работают как отдельные сервисы, хранящие данные в оперативной памяти и предоставляющие доступ к ним по сети с минимальной задержкой. Приложение при чтении сначала обращается к кешу и только при промахе идёт в основное хранилище. Redis, в отличие от Memcached, поддерживает сложные структуры данных, персистентность, репликацию и механизмы отказоустойчивости, поэтому его часто используют не только как кеш, но и как вспомогательное хранилище состояния. Memcached проще и быстрее в эксплуатации, но ограничен моделью ключ-значение и не сохраняет данные при перезапуске.

Следующий важный уровень — CDN (Content Delivery Network), такие как Cloudflare или AWS CloudFront. CDN кеширует статический и полу-статический контент — изображения, стили, скрипты, видео — на edge-серверах, физически близких к пользователю. Когда клиент запрашивает ресурс, запрос не доходит до основного сервера, а обслуживается ближайшей CDN-нодой. Это резко снижает latency и снимает нагрузку с backend’а. Управление таким кешем обычно осуществляется через HTTP-заголовки Cache-Control, Expires и ETag, которые определяют, сколько времени контент считается валидным.

На стороне пользователя работает кеш браузера, который хранит ресурсы локально и повторно использует их без сетевого запроса. Этот уровень кеширования полностью прозрачен для backend’а, но оказывает огромное влияние на производительность и восприятие скорости приложения. Грамотно настроенный браузерный кеш позволяет загружать страницы практически мгновенно, но требует аккуратной стратегии инвалидирования, особенно при деплое новых версий фронтенда.

Часто кеширование реализуется и на уровне самого приложения — в виде локального in-process кеша. Такие кеши живут в памяти процесса и дают минимальную задержку, но плохо масштабируются и не подходят для распределённых систем без дополнительной синхронизации. Их используют для небольших, редко меняющихся данных или как дополнительный слой поверх Redis для самых горячих запросов.

Отдельный класс — кеши на уровне базы данных и операционной системы. Современные СУБД активно кешируют данные в памяти, используя page cache, buffer pool и другие внутренние механизмы. Операционная система также кеширует файловые операции, снижая количество реальных обращений к диску. Эти кеши управляются автоматически и обычно не контролируются напрямую разработчиком, но они существенно влияют на производительность и должны учитываться при проектировании.

Общим механизмом управления всеми уровнями кеширования являются политики времени жизни данных — TTL (time to live), eviction-алгоритмы вроде LRU или LFU и стратегии инвалидирования. TTL ограничивает срок актуальности данных и предотвращает использование слишком устаревших значений. Eviction-алгоритмы определяют, какие данные будут удалены первыми при нехватке памяти. Инвалидация гарантирует, что изменения в основном хранилище рано или поздно отразятся в кеше.

Stream Processing

Коротко:

• Flink — для сложного stateful streaming с сильными гарантиями,
• Spark Streaming — для аналитического стриминга с упором на batch-модель,
• Storm — для экстремально низкой задержки ценой сложности и ручного управления состоянием.

Apache Flink

Apache Flink — это мощный движок для потоковой обработки данных с сильными гарантиями по состоянию (state) и обработке событий. При этом Flink — скорее фреймворк, чем готовое прикладное решение. Это означает, что почти всю доменную логику разработчик реализует сам: агрегации, оконные функции, управление состоянием, очистку устаревших данных и интеграцию пайплайнов с другими системами.

С точки зрения системного дизайна Flink ценен тем, что он ориентирован на true streaming — обработку событий по мере их поступления, а не батчами. Он поддерживает состояние операторов, таймеры, event-time processing и гарантии exactly-once. Для хранения состояния часто используется RocksDB, что позволяет работать с большими объёмами данных и делать инкрементальные чекпоинты. Однако само управление жизненным циклом состояния — например, TTL для пользовательских профилей или удаление данных после периода неактивности — требует явной реализации со стороны разработчика.

Масштабирование Flink — нетривиальная задача. Добавление или удаление узлов обычно требует сохранения состояния (savepoint) и перезапуска джоба. Начиная с версии 1.13 появился Reactive Mode, который позволяет полуавтоматически масштабировать систему за счёт перезапуска с новыми ресурсами, но настоящее zero-downtime масштабирование пока недоступно. Поэтому Flink хорошо подходит для долгоживущих стриминговых задач с чётко определённой логикой и высокой ценностью состояния, но требует зрелой эксплуатации.

Apache Spark Streaming

Apache Spark Streaming, особенно в режиме Structured Streaming, реализует потоковую обработку через концепцию микробатчей. Вместо обработки каждого события отдельно Spark группирует события в небольшие временные партии и обрабатывает их как мини-батчи. Это упрощает модель исполнения и повторно использует батчевую инфраструктуру Spark, но накладывает ограничения на задержку.

С точки зрения system design ключевой компромисс Spark Streaming — это latency vs simplicity. Микробатчи означают, что минимальная задержка измеряется секундами, а не миллисекундами. Для задач, где требуется реакция «здесь и сейчас», такой подход не подходит. Зато Spark отлично справляется с тяжёлыми агрегациями, оконными вычислениями и интеграцией с аналитическим стеком.

Как и Flink, Spark Streaming — это фреймворк, а не готовое решение. Разработчику необходимо самостоятельно описывать окна, счётчики, агрегации и заботиться о том, как результаты стриминга будут использоваться дальше — например, в обучении моделей или аналитике. Spark хорошо подходит для систем, где стриминг — это продолжение batch-аналитики, а не основа real-time взаимодействия с пользователем.

Apache Storm

Apache Storm создавался с прицелом на ультранизкую задержку. Он обрабатывает события по одному, без микробатчей, что делает его одним из самых быстрых инструментов для настоящей real-time обработки. Это сильное преимущество в сценариях, где важны миллисекунды.

Однако из коробки Storm — stateless-система. Он не хранит контекст между событиями, и если требуется агрегация, подсчёты или оконные метрики, разработчику нужно самостоятельно реализовать хранение состояния — например, во внешней базе данных. Это сильно усложняет архитектуру и повышает связность компонентов.

Storm также не предоставляет богатого набора агрегатных операторов. Любые счётчики, окна, метрики и сложные вычисления нужно писать вручную. Слой Trident добавляет поддержку состояния и частично вводит микробатчи, смягчая ограничения, но даже с Trident Storm остаётся более низкоуровневым и менее удобным, чем современные стриминговые движки. В результате Storm чаще рассматривают как специализированный инструмент для узких real-time задач, а не универсальную стриминговую платформу.

Что важно знать про streaming для system design

С точки зрения системного дизайна стриминговые системы — это всегда баланс между задержкой, состоянием и сложностью эксплуатации. True streaming (как во Flink или Storm) даёт минимальную latency и точный контроль над event-time, но усложняет масштабирование и управление состоянием. Микробатчевый подход (Spark Streaming) проще в эксплуатации и интеграции с аналитикой, но не подходит для интерактивных сценариев.

Важно также понимать, что стриминговые движки редко работают в одиночку. Обычно они строятся поверх брокеров событий вроде Kafka, используют внешние хранилища для долговременного состояния и формируют materialized views для быстрого чтения. В интервью ценится не знание API конкретного инструмента, а понимание, когда нужен streaming вообще, почему нельзя обойтись batch-обработкой и какие компромиссы система делает ради низкой задержки или высокой надёжности.

Графовые базы данных (Graph DB)

Графовые базы данных (Graph DB) — это специализированные системы хранения данных, оптимизированные для работы со связями между сущностями. В отличие от реляционных баз, где связи реализуются через JOIN’ы, в графовых БД связи являются первоклассными объектами и хранятся напрямую. Это делает операции обхода связей, поиска путей и анализа графов на порядки эффективнее и концептуально проще.

В основе графовой модели лежат вершины (nodes), рёбра (edges) и свойства (properties). Вершины представляют сущности — пользователей, товары, документы. Рёбра описывают отношения между ними — «друг», «купил», «подписан». Свойства дополняют и вершины, и рёбра атрибутами. Такая модель особенно хорошо подходит для доменов, где ключевую роль играют связи, а не табличные агрегаты: социальные сети, рекомендательные системы, antifraud, knowledge graph, IAM и сетевые топологии.

Рынок графовых баз данных сформировался вокруг нескольких зрелых решений. Neo4j остаётся безусловным лидером и фактическим стандартом де-факто. Он предлагает зрелую экосистему, язык запросов Cypher, богатые инструменты визуализации и оптимизирован для OLTP-нагрузок с большим количеством обходов графа. Neo4j часто выбирают в enterprise-проектах, где важна стабильность, документация и опыт эксплуатации.

Amazon Neptune — облачно-ориентированная графовая база от AWS, ориентированная на managed-подход. Она поддерживает модели property graph и RDF, а также языки Gremlin и SPARQL. Neptune хорошо вписывается в экосистему AWS, обеспечивает автоматическое масштабирование и высокую доступность, но при этом уступает Neo4j в гибкости и выразительности запросов. Это типичный выбор для компаний, которые уже глубоко сидят в AWS и хотят минимизировать операционные издержки.

ArangoDB представляет собой мультимодельную базу данных, сочетающую в себе документную, ключ-значение и графовую модели. Такой подход удобен для систем, где граф — лишь часть общей архитектуры, а не единственный способ доступа к данным. ArangoDB позволяет работать с разными типами данных в рамках одной СУБД, что снижает сложность инфраструктуры, но может быть менее специализированным по сравнению с «чистыми» графовыми решениями.

Dgraph ориентирован на распределённость и масштабирование «из коробки». Он изначально проектировался как distributed graph database и тесно интегрирован с GraphQL. Это делает его привлекательным для cloud-native и API-ориентированных систем, где важны горизонтальное масштабирование и простой доступ к данным через GraphQL-интерфейсы. При этом Dgraph требует более серьёзного понимания внутренних механизмов и пока менее распространён в enterprise-сегменте.

TigerGraph специализируется на глубокой аналитике связей и обработке очень больших графов. Его сильная сторона — сложные многопереходные запросы, графовая аналитика и сценарии, где нужно анализировать большие объёмы взаимосвязанных данных за минимальное время. TigerGraph часто используется в антифроде, телеком-аналитике и финансовых системах, где глубина обхода графа имеет критическое значение.

Помимо зрелых решений, рынок активно развивается за счёт новых подходов. PuppyGraph предлагает интересную концепцию — выполнять графовые запросы поверх уже существующих хранилищ, без необходимости миграции данных в отдельную графовую БД. Это снижает барьер входа и упрощает интеграцию. RelationalAI, в свою очередь, объединяет реляционную модель с логическими и AI-ориентированными подходами, расширяя традиционные базы возможностями вывода и анализа сложных зависимостей.

С точки зрения системного дизайна графовые базы данных выбирают тогда, когда основная ценность системы — в связях, а не в отдельных записях. Они плохо подходят для простого CRUD или тяжёлых агрегатов, но незаменимы для задач поиска связей, рекомендаций, обнаружения аномалий и анализа сложных структур. В реальных архитектурах Graph DB часто используются вместе с реляционными и документными базами, выполняя роль специализированного компонента для работы с отношениями.

Метрики производительности системы

Ваш API работает медленно. Но насколько именно медленно? Нужны числа. Реальные метрики, которые показывают, что именно сломалось и где это нужно чинить.

Вот четыре ключевые метрики, которые должен понимать каждый инженер при анализе производительности системы:

• Queries Per Second (QPS) — количество входящих запросов, которые система обрабатывает за одну секунду. Если сервер получает 1000 запросов за секунду, значит у него 1000 QPS. Звучит просто, пока не становится ясно, что большинство систем не способны долго выдерживать пиковый QPS без начала деградации.
• Transactions Per Second (TPS) — количество завершённых транзакций, которые система обрабатывает за секунду. Транзакция включает полный цикл обработки: запрос отправляется, доходит до базы данных и возвращается с ответом.
  TPS показывает фактически выполненную работу, а не просто принятые запросы. Именно на эту метрику чаще всего ориентируется бизнес.
• Concurrency (параллелизм) — количество одновременно активных запросов, которые система обрабатывает в конкретный момент времени. Например, система может получать 100 запросов в секунду, но если каждый запрос выполняется 5 секунд, то одновременно в работе находится 500 запросов.
  Высокий уровень параллелизма означает, что системе требуется больше ресурсов, эффективный пул соединений и грамотное управление потоками.
• Response Time (RT) — время, прошедшее с момента начала обработки запроса до получения ответа. Измеряется как на стороне клиента, так и на стороне сервера.

Все эти метрики связывает простое соотношение:

QPS = Concurrency ÷ Среднее время ответа

Больше параллелизма или меньшее время ответа означает более высокую пропускную способность системы.

Метрики производительности в highload системах

В highload-системах метрики производительности нужны не «для графиков», а для ответа на конкретные вопросы: где узкое место, что сломается следующим и почему пользователи чувствуют деградацию. Обычно их рассматривают по уровням системы — от клиента до железа — потому что высокая нагрузка почти всегда проявляется каскадно.

Клиентский уровень (Client-Side Performance)

Этот слой отвечает за то, как пользователь ощущает систему, даже если backend формально «жив».

Ключевые метрики здесь — время установления TCP-соединения, время загрузки HTML, CSS, JavaScript и изображений, а также общее HTTP response time и статус ответа. В highload-сценариях проблемы на backend’е быстро проявляются именно здесь: растёт latency, увеличивается число таймаутов, появляются 5xx-ошибки.

Важно понимать, что клиентская деградация может происходить даже при «нормальных» серверных метриках — например, из-за перегруженной сети, плохой работы CDN или большого количества блокирующих ресурсов на фронтенде.

Сетевой уровень (Network Metrics)

Сеть — это кровеносная система highload-архитектуры. На этом уровне смотрят, выдерживает ли инфраструктура объём соединений и трафика.

Основные показатели — количество установленных TCP-соединений, число TCP-сегментов в секунду, количество reset’ов и неудачных попыток соединения. В условиях высокой нагрузки резкий рост TCP resets или connection failures почти всегда указывает на перегрузку балансировщика, exhaustion портов, проблемы с NAT или неправильные таймауты.

Важный сигнал — рост соединений без роста полезного throughput: это признак того, что система тратит ресурсы на сетевую инфраструктуру, но не выполняет реальную работу.

Уровень веб-сервера (Web Server Metrics)

Этот слой отвечает за приём и первичную обработку запросов. Именно здесь highload чаще всего проявляется в виде очередей и отказов.

Критичны метрики очередей запросов, транзакций в секунду, объёма переданных данных, потребления памяти и cache hit ratio. Рост request queue — один из самых опасных симптомов: он означает, что система уже не справляется с входящим потоком.

Cache hit ratio здесь играет ключевую роль: при высокой нагрузке даже небольшое падение процента попаданий в кеш может лавинообразно увеличить нагрузку на backend и базу данных.

Уровень application-сервера

Это сердце бизнес-логики, и в highload-системах именно здесь чаще всего «горит».

Здесь смотрят на время установления соединений, ожидание соединений (connection wait time), использование памяти, количество потоков, активные и приостановленные транзакции, таймауты и rollback’и.

Рост connection wait time означает, что пул соединений исчерпан. Увеличение active transactions без роста TPS — сигнал о том, что запросы «залипают» внутри системы. Таймауты и rollback’и часто указывают на перегрузку downstream-сервисов или базы данных.

Связь метрик между собой

В highload-системах метрики нельзя анализировать изолированно. Например:

• рост response time почти всегда ведёт к росту concurrency;
• рост concurrency увеличивает потребление памяти и количество открытых соединений;
• перегруженные application-серверы создают очереди на веб-сервере;
• очереди увеличивают клиентскую latency и таймауты.

Поэтому инженеры часто используют базовое соотношение:

Throughput = Concurrency ÷ Response Time

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

Что важно на собеседовании

В контексте system design от тебя ждут не перечисления всех метрик, а понимания:

• какие метрики сигнализируют о начале деградации;
• какие из них указывают на CPU-bound, IO-bound или network-bound систему;
• как метрики разных уровней влияют друг на друга.

Обзор паттернов

Архитектурные паттерны

• Микросервисы — Разбиение системы на независимые сервисы, каждый из которых выполняет свою небольшую задачу. Используют Netflix, Uber, Amazon.
• Монолит — Единое приложение, внутри которого всё тесно связано. Простой старт, сложное масштабирование.
• SOA (Service-Oriented Architecture) — Предшественник микросервисов — крупные сервисы с чётко определёнными контрактами.

Чем отличается SOA (Service-Oriented Architecture) от микросервисной архитектуры

SOA (Service-Oriented Architecture) и микросервисная архитектура основаны на одной идее — разбиении системы на сервисы, — но различаются по масштабу, степени связанности и подходу к разработке и эксплуатации.

SOA возникла как enterprise-подход к интеграции крупных корпоративных систем. Сервисы в SOA обычно достаточно крупные, охватывают значимые бизнес-домены и часто разделяют общую инфраструктуру: базы данных, ESB (Enterprise Service Bus), механизмы безопасности и оркестрации. Взаимодействие между сервисами в SOA нередко строится через централизованный слой интеграции, который отвечает за маршрутизацию, трансформацию сообщений и применение политик. Это упрощает управление и стандартизацию, но повышает связанность системы и создаёт единые точки отказа.

Микросервисная архитектура, напротив, делает акцент на максимальную автономность сервисов. Каждый микросервис обычно небольшой, отвечает за один узкий бизнес-контекст и владеет своими данными. Сервисы взаимодействуют напрямую, чаще всего по лёгким протоколам вроде HTTP или через асинхронные события, без тяжёлого централизованного посредника. Это снижает связанность и позволяет независимо разрабатывать, деплоить и масштабировать компоненты системы.

С точки зрения данных различие особенно заметно. В SOA допускается совместное использование баз данных и схем, что упрощает консистентность, но усложняет эволюцию. В микросервисах принцип «database per service» считается базовым, а согласованность достигается через события и eventual consistency.

Отличается и эксплуатационная модель. SOA ориентирована на стабильные, долго живущие сервисы с редкими изменениями и централизованным управлением. Микросервисы проектируются под частые деплои, автоматизацию, CI/CD, контейнеризацию и горизонтальное масштабирование. Это повышает гибкость, но увеличивает операционную сложность.

Паттерны масштабирования и доступности

• Load Balancer — Распределяет нагрузку между узлами. Классическая схема — NGINX + несколько backend-сервисов.
• Horizontal Scaling — Добавляем больше узлов вместо усиления одного.
• Sharding — Разделение данных по ключу или диапазону между несколькими нодами.
• Replication — Создание копий данных для отказоустойчивости и быстрого чтения.
• Federation / Partitioning — Разделение больших сервисов или БД на тематические домены.

Паттерны взаимодействия между сервисами

• Request/Response — Типичный REST/gRPC вызов.
• Event-Driven Architecture — Сервисы общаются через события, как в Uber, LinkedIn.
• Pub/Sub — Публикация событий в брокер (Kafka, Pulsar), подписчики их потребляют.
• CQRS (Command Query Responsibility Segregation) — Разделение операций записи и чтения. Полезно в high-load системах.
• Saga — Управление распределёнными транзакциями при помощи цепочки локальных операций и компенсационных действий.
• Circuit Breaker — Предотвращение каскадных падений: если сервис долго не отвечает, вызовы отключаются.
• Retry / Exponential Backoff — Повторная отправка запросов с увеличивающимся тайм-аутом.
• Bulkhead — Изоляция компонентов, чтобы сбой одного не уронил всю систему.

Паттерны данных и кеширования

• Cache Aside — Приложение сначала проверяет кеш, затем БД. Самый популярный паттерн.
• Read-Through Cache — Кеш сам ходит в БД при промахе.
• Write-Through Cache — Запись идёт сначала в кеш, потом в базу.
• Write-Behind — Запись в БД происходит асинхронно из кеша.
• Materialized Views — Предварительно пересчитанные данные для быстрых запросов.
• Event Sourcing — Состояние системы хранится как поток событий.

Паттерны потоковой обработки

• Stream Processing — Система обрабатывает данные непрерывным потоком. Kafka Streams, Flink.
• Lambda Architecture — Комбинация batch-обработки и stream-обработки.
• Kappa Architecture — Только потоковая обработка, без batch-а.

Паттерны отказоустойчивости

• Leader Election — Выбор ведущего узла (ZooKeeper, Etcd, Consul).
• Failover — Переход на резервную ноду при отказе основной.
• Redundancy — Дублирование критичных узлов или подсистем.

Паттерны API и интеграции

• API Gateway — Единая точка входа в систему (Netflix Zuul, Kong). Добавляет авторизацию, rate limiting, кеш.
• Backend for Frontend (BFF) — Отдельный backend для каждого типа клиента — мобильного, веба и т. п.
• Service Mesh — Автоматизированная сетка сервисных коммуникаций: Envoy, Istio.

Паттерны управления состоянием

• Stateless — Сервисы без состояния легко масштабируются.
• Stateful — Сервисы, хранящие состояние, требуют репликации или sticky-сессий.
• Sticky Sessions — Привязка клиента к конкретному серверу при работе со stateful-компонентами.

Паттерны безопасности

• OAuth2 / JWT — Стандартные механизмы авторизации.
• Zero Trust — Каждый запрос проверяется, даже внутри частной сети.
• Rate Limiting / Throttling — Ограничение запросов, чтобы защитить сервисы. Статья

Глоссарий / Термины

Общие термины подготовки к интервью

• System Design — проектирование крупномасштабных распределённых систем и архитектурных решений для сложных приложений.
• Coding — подготовка к собеседованиям по алгоритмам и программированию, включая техники решения задач.
• Behavioral Interview — оценка мягких навыков и коммуникативных качеств кандидата.
• Tech Interview — общий термин для всех технических собеседований: coding, system design, behavioral.
• FAANG — аббревиатура ведущих технологических компаний (Facebook/Meta, Apple, Amazon, Netflix, Google), стандарт отрасли.
• STAR Method — структурированный метод ответа на поведенческие вопросы (Situation, Task, Action, Result).
• Mock Interviews — практические имитации интервью для отработки формата и получения обратной связи.
• Interview Roadmap — структурированный план подготовки: coding, design, behavioral.
• Interview Bootcamp — интенсивная программа подготовки с практическими заданиями и наставниками.
• Resume Review — услуга оценки и улучшения резюме для технических ролей.
• AI-Assisted Development / Vibe Coding — использование AI-инструментов (например, ChatGPT) для улучшения процесса написания кода.

System Design: фундаментальные концепции

• System Design Fundamentals — базовый набор концепций и архитектурных паттернов для проектирования систем.
• High-Level Design (HLD) — общая архитектурная картина, компоненты и их связи.
• Low-Level Design (LLD) — детальная проработка компонентов, структуры данных, классы и модули.
• Scalability — способность системы обрабатывать рост нагрузки.
• Performance vs Scalability — производительность для одного пользователя против эффективности при росте нагрузки.
• Latency — время отклика системы.
• Throughput — количество обработанных операций за единицу времени.

Масштабирование

• Вертикальное масштабирование — увеличение мощности одного сервера (CPU, RAM).
• Горизонтальное масштабирование — добавление новых узлов для распределения нагрузки.
• Sharding — горизонтальное разделение данных на части для масштабирования.
• Partitioning — логическое деление наборов данных для параллельной обработки.
• Replication — копирование данных на несколько узлов для отказоустойчивости и доступности.
• Replication factor — число копий данных в распределённой системе.

Consistency и модели согласованности

• CAP Theorem — компромисс между Consistency, Availability и Partition tolerance.
• Weak consistency — отсутствие немедленной согласованности после записи.
• Eventual consistency — реплики данных со временем сходятся к одному состоянию.
• Strong consistency — все чтения после записи видят обновлённые данные.
• Idempotency — повторный вызов операции даёт одинаковый результат без побочных эффектов.

Отказоустойчивость и доступность

• Fail-over — переключение на резервный узел при сбое.
• Active-passive — один узел активен, другой в standby.
• Active-active — оба узла обслуживают трафик одновременно.
• Circuit breaker — блокировка вызовов к проблемному сервису для отказоустойчивости.

Сетевые коммуникации

• HTTP — протокол прикладного уровня для веб-сервисов.
• REST — архитектурный стиль API поверх HTTP.
• WebSockets — двунаправленный протокол для постоянного соединения.
• Long polling — клиент держит открытый запрос до появления новых данных.
• TCP — надёжный транспортный протокол.
• UDP — лёгкий транспортный протокол без гарантии доставки.
• TLS/HTTPS — шифрование сетевого трафика.
• Authentication — подтверждение личности пользователя/сервиса.
• Authorization — проверка прав доступа.
• JWT (JSON Web Token) — стандарт аутентификации и передачи утверждений.
• RPC — удалённый вызов процедур.
• gRPC — высокопроизводительный RPC-фреймворк.

DNS и балансировка нагрузки

• DNS — система доменных имён.
• A record — связывает доменное имя с IP-адресом.
• CNAME — каноническое имя, указывающее один домен на другой.
• NS record — указывает авторитетные DNS-серверы домена.
• MX record — указывает почтовый сервер домена.
• Load Balancer — распределение трафика между серверами.
• Layer 4 load balancing — балансировка на транспортном уровне.
• Layer 7 load balancing — балансировка на прикладном уровне.
• Reverse proxy — прокси, принимающий запросы от клиентов и перенаправляющий на внутренние сервисы.
• Forward proxy — прокси между клиентом и внешним интернетом.
• Service mesh — инфраструктурный слой для управления взаимодействием микросервисов.

Базы данных и хранение

• RDBMS — реляционная база данных с ACID-транзакциями.
• ACID — атомарность, согласованность, изоляция, долговечность транзакций.
• Master-slave replication — одна база для записи, несколько реплик для чтения.
• Master-master replication — несколько узлов принимают чтение и запись с синхронизацией.
• Federation — разделение базы на функциональные части.
• Denormalization — копирование данных для ускорения чтения.
• SQL tuning — оптимизация запросов и индексов.
• NoSQL — ключ-значение, документные, колонкоориентированные, графовые базы.
• Key-value store — хранилище пар «ключ-значение».
• Document store — база данных, хранящая документы.
• Wide-column store — колонкоориентированная база данных.
• Graph Database — база для хранения графов сущностей и связей.
• Indexes — структуры для ускорения поиска.
• Transactional isolation — уровень согласованности параллельных транзакций.

Кэширование

• Cache — временное хранение данных для ускорения доступа.
• Client caching — кэш на стороне клиента.
• CDN caching — кэш на edge-серверах CDN.
• Web server caching — кэш в веб-сервере.
• Database caching — кэш в базе данных.
• Application caching — кэш в приложении (Redis, Memcached).
• Cache-aside — приложение управляет кэшем самостоятельно.
• Write-through — запись в кэш и основной store одновременно.
• Write-behind — запись сначала в кэш, потом в основной store.
• Refresh-ahead — обновление записи до истечения TTL.
• Eviction policy — правило удаления устаревших данных из кэша.
• TTL (Time To Live) — время жизни записи в кэше.
• Cache hit — запрос найден в кэше.
• Cache miss — запрос не найден в кэше, обращение к основному источнику.

Асинхронность и очереди

• Message Queue — очередь сообщений для обмена между сервисами.
• Task Queue — очередь фоновых задач.
• Producer — отправитель сообщений.
• Consumer — получатель сообщений.
• Topic / Partition — логические каналы и партиции в Kafka для параллелизма.
• Retention policy — правила хранения сообщений в очереди/топике.
• Back pressure — защита системы от перегрузки.
• Fan-out / Fan-in — распределение сообщений и агрегирование результатов.
• Rate limiting — ограничение частоты запросов/операций.
• Backoff strategy — уменьшение частоты повторных попыток при ошибках.
• Windowing — обработка событий во временные окна.
• Exactly-once semantics — гарантия однократной обработки события.

Полезные практические ресурсы

• Latency numbers every programmer should know — справочный набор латентностей распределённой системы.
• Use back of the envelope calculations — быстрые приближённые оценки для проектирования ресурсов.

Разбор задач по системному дизайну

Материалы

• https://bytebytego.com/courses/system-design-interview/foreword — часть разделов открыты и бесплатны
• https://newsletter.systemdesign.one/archive
• https://www.geeksforgeeks.org/category/system-design/
• https://www.designgurus.io/blog

URL Shortener (аналог bit.ly)

Классика: генерация коротких ссылок, редиректы, TTL, лимиты.

Сервис сокращения URL: архитектурный разбор

Интервью по системному дизайну часто начинается с классических задач, которые позволяют быстро выявить умение кандидата работать с ограничениями, масштабируемостью и отказоустойчивостью. Сервис сокращения ссылок выделяется своей простотой в пользовательском опыте при наличии ряда нетривиальных инженерных нюансов. На первый взгляд требуется лишь принять длинный URL, сгенерировать короткий идентификатор и обеспечить по нему быстрый редирект. На практике подобная система должна выдерживать высокие пики нагрузки, обладать стабильной латентностью и корректно работать с миллиардами объектов.

Основная функциональность и требования

Пользователь отправляет длинную ссылку. Система должна вернуть уникальный короткий идентификатор, пригодный к последующему использованию в любом клиенте. Доступ по этому идентификатору должен приводить к мгновенному редиректу на исходный URL. Часто возникает необходимость использования срока жизни. Например, ссылки маркетинговых кампаний живут ограниченный период, тогда как ссылки пользователя могут храниться бессрочно. Ограничения могут быть наложены и на количество запросов со стороны клиента, что защищает от злоупотреблений и контролирует бюджет инфраструктуры.

При формулировании требований стоит учитывать, что путь чтения обычно имеет порядок на один, а то и на два порядка выше, чем путь записи. Это определяет выбор хранилища и стратегию кеширования. В критичных системах редирект должен укладываться в единицы миллисекунд.

Генерация коротких идентификаторов

Выбор стратегии генерации идентификатора отражает особенности архитектуры. Наиболее простой подход основан на числовой последовательности. Идентификатор преобразуется в кодированную форму с использованием алфавита, создающего компактную строку. Подобный метод гарантирует уникальность без распределённого консенсуса, но требует централизованного механизма увеличения счётчика или применения шардирования на уровне ID-пространства.

Альтернативный подход основан на хешировании длинного URL. Он не требует глобального состояния и может выполняться на любом узле. Однако применение чистого хеша чревато коллизиями. Поэтому обычно выбирают комбинацию хеша и проверки хранилища. Если коллизия обнаружена, система генерирует новый идентификатор, используя добавочные данные или случайность. В системах с огромным объёмом данных вероятность коллизий становится заметным фактором, поэтому практикуют укороченный хеш с дополнительной энтропией.

Отдельной задачей является требование стабильности. Если пользователь передаёт один и тот же URL, некоторые системы возвращают ранее созданный идентификатор. Это снижает объём базы и делает поведение предсказуемым. Но усложняет кэширование и требует наличия быстрого поиска по URL.

Хранилище

В основе сервиса лежит структура вида ключ-значение. Ключом является короткий идентификатор, значением — исходный URL и метаданные. Применение реляционной базы обычно неоправданно. Такие данные масштабируются горизонтально гораздо проще, если использовать распределённые key-value хранилища или базы класса NoSQL.

Зная, что операции чтения преобладают, критичной становится скорость доступа. Поэтому архитектура почти всегда включает слой кеширования. Ближайший к пользователю региональный кеш Redis или аналог снижает задержку и уменьшает нагрузку на основное хранилище. Важно понимать, что кеш должен обновляться при изменении TTL, удалении ссылок или продлении срока жизни. Ошибки в синхронизации иногда приводят к выдаче истёкших ссылок, поэтому метаданные TTL хранятся как в кеше, так и в первичном хранилище.

Обработка редиректов

Редирект должен быть максимально лёгкой операцией. Сервис получает запрос по короткому идентификатору, определяет актуальность записи, проверяет возможные ограничения и отвечает перенаправлением. На этом пути часто используют CDN как дополнительный уровень защиты. CDN способен обслуживать повторяющиеся запросы без обращения к серверу приложения, что резко снижает задержку на глобальном трафике.

Иногда возникает необходимость подсчитывать клики. Для систем аналитики путь чтения избегают утяжелять синхронной записью. Событие передачи можно отправить в асинхронную очередь, которую downstream-сервисы уже обрабатывают независимо.

TTL, истечение и очистка

Срок жизни описывается на уровне метаданных записи. При истечении запись исключается из кеша, но основное удаление из хранилища выполняется периодически, чтобы не создавать пики нагрузки. Подобные задачи часто реализуют через фоновые процессы или распределённые cron-механизмы. Сложность заключается в том, что объём данных может достигать значений, не допускающих прямых итераций. Поэтому используют стратегии сегментации или слабосвязанные структуры хранения.

Ограничения и защита от злоупотреблений

Защита от чрезмерного использования сервиса чаще всего реализуется через rate-limiting. Ограничения могут быть наложены как на создание ссылок, так и на переходы. Для глобальных публичных сервисов применяется многоуровневая архитектура, где лимиты проверяются на уровне CDN, API-шлюза и непосредственно в сервисе.

Масштабирование

При существенных нагрузках система должна быть способна горизонтально масштабироваться без потери идемпотентности операций. Шардинг идентификаторов позволяет распределять данные по множеству узлов. Распределённый кеш, использующий согласованный хеш, помогает избежать горячих ключей, особенно в случаях, когда популярность конкретной ссылки резко возрастает.

Для систем, работающих по модели eventual consistency, задержки в репликации приемлемы, если не влияют на пользовательский опыт. Однако для хранилища переходов критична именно читающая часть, поэтому используют лидера для записи и несколько реплик для чтения или полностью распределённые хранения, работающие без жёстких ограничений на консистентность.

Возможные схемы

Rate Limiter

Token bucket / leaky bucket, распределённый rate limiting.

Этап 1. Постановка задачи и исходный контекст

Интервьюер формулирует задачу: требуется спроектировать распределённую систему rate limiting, способную ограничивать количество запросов, исходящих от клиента, сервиса или пользователя, в единицу времени. Ограничения должны быть гибкими, управляемыми и устойчивыми к злоупотреблениям. Важно обеспечить предсказуемую нагрузку на backend-части систем, а также защиту от несанкционированных попыток обойти лимиты. Задача должна включать модели token bucket или leaky bucket, а также уметь работать в распределённой среде, что исключает выполнение rate limiting полностью локально.

Нефункциональные требования включают высокую доступность, низкую задержку при проверке лимита, масштабируемость до миллионов или миллиардов запросов в час, гарантированную корректность в условиях распределённости, а также предсказуемый и воспроизводимый алгоритм вычисления оставшихся квот.

После постановки вопроса интервьюер завершает вводную часть и передаёт инициативу кандидату.

Этап 2. Формализация требований и уточняющие вопросы

На этапе формализации кандидат уточняет ключевые параметры задачи. Прежде всего уточняется контекст ввода лимитов: должны ли лимиты применяться на уровне отдельного пользователя, IP-адреса, API-ключа или конкретного endpoint. Важно понимать, должны ли лимиты быть одинаковыми для всех или управляться конфигурационно, а также существует ли требование динамически обновлять лимитирующие правила без перезапуска системы.

Параллельно формулируются нефункциональные цели. Высокая доступность для rate limiter является критичной, поскольку ошибки в этом компоненте могут привести к деградации или отказу всего API. Консистентность требует аккуратного подхода: строгая консистентность повышает задержки, а eventual consistency может допускать временные превышения лимита. Выбор зависит от характера сервиса. Пропускная способность должна быть высокой, так как проверка лимита выполняется на каждом запросе. Масштабируемость важна для горизонтального расширения без разделения контекста лимитов или появления горячих ключей. Аудитируемость может стать обязательной в корпоративных системах, где требуется отслеживание нарушений.

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

Этап 3. Границы системы и публичное API

Теперь требуется определить публичный интерфейс. Rate limiter по сути предоставляет одну основную операцию: проверку и обновление лимита пользователем. В рамках неё клиент передаёт идентификатор субъекта лимитирования и параметры правила (если они не заранее зафиксированы). Результат представляет собой разрешение или запрет действия, дополненный информацией о текущем состоянии бакета или очереди.

В зависимости от модели бакета API может возвращать количество оставшихся токенов, расчётный момент восстановления лимита или фактическое время ожидания. Если система поддерживает управление правилами, она может предоставлять интерфейсы для создания, изменения и удаления конфигураций лимитов. Однако в большинстве случаев требуется только быстрый и корректный ответ на запрос проверки лимита.

Таким образом граница системы формируется вокруг простой операции check-and-update, являющейся атомарной по смыслу, пусть и распределённой по технической реализации.

Этап 4. Проектирование: сценарии, потоки данных и компоненты

На этом этапе начинается построение системы, начиная с основной логики. В основе лежит алгоритм token bucket или leaky bucket. Для token bucket система предполагает наличие ёмкости и скорость восполнения токенов. При каждом запросе проверяется, достаточно ли токенов. Если да, один или несколько токенов списываются. Если нет, запрос отклоняется. Для leaky bucket модель другая: запросы попадают в очередь фиксированной длины, и новая обработка разрешается в соответствии с постоянной скоростью «утечки».

В распределённой системе появляется вопрос синхронизации состояния бакета между узлами. Первым компонентом становится хранилище счётчиков. Оно должно обеспечивать атомарные операции инкремента, декремента, условной записи или хранения временных отметок. Система может использовать in-memory хранилище с распределёнными блокировками, например Redis с Lua-скриптами, либо специализированные распределённые базы данных, предоставляющие операции CAS. Логика rate limiting должна быть максимально компактной, чтобы обработка происходила за десятки микросекунд.

Чтобы избежать горячих ключей, система может распределять состояние лимита по нескольким шардам, использовать согласованное хеширование или локальные промежуточные кеши. Второй сценарий заключается в локальном prefill токенов, что уменьшает обращение к центральному хранилищу и снижает задержку, но требует осторожности в части консистентности.

В случае отказов необходимо предусмотреть graceful degradation. Например, при временной недоступности центрального хранилища система может работать в режиме fail-open или fail-closed. Выбор стратегии зависит от характера сервиса: критичные API обычно предпочитают fail-open, чтобы не блокировать клиентов, но строго внутренние системы могут работать в fail-closed для защиты от перегрузки.

Постепенно формируется общий набор компонентов: модуль конфигурации лимитов, распределённое хранилище счётчиков, локальный компонент принятия решения, механизм синхронизации времени, а также метрики и мониторинг для отслеживания состояния. Потоки данных состоят из последовательного получения состояния бакета, вычисления новых параметров и обновления записи. Всё это должно происходить атомарно в пределах одного логического шага.

Этап 5. Концептуальная архитектура

Завершив развитие сценариев, можно представить целостную схему. API получает запрос на проверку лимита и передаёт его в компонент rate limiter. Этот компонент обращается к распределённому хранилищу счётчиков, выполняя атомарную транзакцию: расчёт восстановленных токенов, проверку лимита и обновление состояния. Результат возвращается клиенту. Для высокой производительности система использует локальные кеши, в которых хранит метаданные лимитов и параметры восстановления. Хранилище выполняет роль единственного источника истины, обеспечивая согласованность в распределённой среде. В архитектуре может быть предусмотрен вспомогательный сервис для централизованной конфигурации правил.

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

Этап 6. Выбор технологий и оценка размера системы

На этом этапе проводится обсуждение конкретных инструментов. Если требуется минимальная задержка, применяется Redis Cluster, позволяющий выполнять атомарные операции через Lua. Для более строгой консистентности можно использовать CockroachDB или DynamoDB, обеспечивающие линейно масштабируемые операции обновления. В случае экстремальных нагрузок возможно применение in-memory систем, работающих полностью распределённо, например Aerospike.

Оценка размера зависит от количества субъектов лимитирования и числа запросов. Если система обрабатывает сотни тысяч запросов в секунду, хранилище должно поддерживать низкую задержку при высокой конкурентности. Выбор region-aware конфигурации Redis или использование шардированных распределённых атомарных счётчиков становится важной частью sizing. Для глобальных систем можно организовать региональные rate-limiters, выполняющие часть работы локально, а глобальная консистентность достигается распределённым накоплением токенов.

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

Этап 7. Дополнительные вопросы и расширения

Наконец, можно рассмотреть расширение задачи. Например, реализацию rate limiting на уровне CDN, распределённые токены, синхронизацию лимитов между дата-центрами, защиту от случайных всплесков нагрузки, реализацию soft-limits и mode-switching при деградации. Можно обсудить многоуровневые лимиты, построенные по принципу периметр → API → метод. Ещё одна интересная тема — rate limiting в системах с микросервисной архитектурой, где каждый сервис может выступать одновременно и потребителем, и контролирующим компонентом.

Эти дополнительные рассуждения демонстрируют широту знаний кандидата и умение видеть систему за пределами узкого требования.

Design a Cache System (Redis-based)

Кеширование профилей, стратегий eviction, борьба со штампедом.

Этап 1. Постановка задачи и контекст

Сервис должен кэшировать профильные данные пользователей для обеспечения низкой латентности чтения и снижения нагрузки на хранилище первичных данных. Профиль включает небольшой набор «горячих» полей (имя, аватар, статус, флаги приватности), а также ряд «холодных» или редко меняющихся полей (история, настройки). Основные функциональные требования: быстрые чтения (миллисекунды), согласованность в рамках разумных ограничений, возможность инвалидации при обновлениях профиля, поддержка TTL для устаревших данных и защита от наводнений запросов (stampede). Нефункциональные требования: высокая доступность, горизонтальная масштабируемость, контролируемое использование памяти, мониторинг и способность обслуживать пики нагрузки.

Этап 2. Формализация требований и ключевые архитектурные характеристики

Необходимо уточнить несколько практических допущений, которые влияют на дизайн: допустимо ли eventual consistency между кэшем и базой; частота и критичность обновлений профиля; цель по hit-rate (например ≥95%); ожидаемый QPS чтений и записей; средний размер профиля. Из нефункциональных свойств важно зафиксировать приоритеты: низкая латентность чтения — главный приоритет; консистентность сильнее важна для операций конфиденциальности и удаления, чем для отображения аватара; доступность должна быть высокой, система не должна становиться «узким местом». На основе этого определяем свойства: оптимизация под high throughput (чтения), допустимость eventual consistency для обычных полей, необходимость auditability для операций обновления критичных атрибутов.

Этап 3. Границы системы и публичный API

Граница системы — уровень кеша, видимый для прикладных сервисов. Набор операций минимален: GetProfile(userId, options) возвращает профиль (или его часть) и метаинформацию; UpdateProfile(userId, delta) обновляет профиль и обеспечивает инвалидацию/обновление кеша; InvalidateProfile(userId) принудительно удаляет/обновляет запись в кеше; BulkWarm(keys) — опционально для прогрева. GetProfile должен поддерживать параметры частичного чтения (hot fields vs full profile). Ответ должен содержать маркер источника («cache» или «db») и, при необходимости, TTL/версию. API должен быть лёгким и атомарным с точки зрения прикладного кода: вызов GetProfile не обязан вручную реализовывать логику кеширования.

Этап 4. Проектирование: happy path и exceptional flows, компоненты и потоки данных

Happy path для чтения: приложению вызывают GetProfile(userId). Клиентский SDK (или middleware на уровне сервиса) проверяет локальный near-cache (опционально), затем Redis. При попадании в кеш (hit) профиль возвращается. При промахе (miss) сервис читает профиль из первичной БД, записывает его в Redis (cache-aside) с нужным TTL/метаданными и возвращает результат. Для ускорения и экономии сети подход cache-aside с централизованной логикой чаще всего лучше, чем write-through, поскольку запись происходит реже.

Обновления: при поступлении UpdateProfile система выполняет запись в первичную БД и затем инвалидиует ключ в Redis. Варианты поведения: синхронная инвалидация после успешной транзакции записи, либо write-through (сначала в кеш, затем в БД) при необходимости строгой консистентности. Для частичных обновлений полезно хранить версию/число смен (version number) в значении кеша — это упрощает детекцию устаревших значений и гонок.

Борьба со штампедом (cache stampede): при большом количестве одновременных запросов на недостающий в кеше ключ нужно предотвратить лавину чтений в БД. Практические техники:

• Singleflight / mutex per key: первый запрос ставит «замок» (локальный или в Redis с SETNX), остальные ждут или получают ответ с опцией «fallback»; после загрузки из БД и записи в кеш замок снимается. Для распределённой среды применяют Redis с небольшим TTL на замок и гарантированным восстановлением.
• Request coalescing на уровне edge: агрегировать запросы внутри процесса или на API-шлюзе.
• Probabilistic early recompute: при приближении TTL популярного ключа его предварительно «перепекают» (background refresh) по вероятностному алгоритму, чтобы избежать одновременной просадки.
• Negative caching и Bloom filter: для отсутствующих ключей возвращать отрицательный кеш (короткий TTL) и использовать Bloom filter, чтобы фильтровать запросы к БД для несуществующих пользователей.
• Lazy locking + timeout: выдержать предел ожидания, а при ошибке чтения возвращать ошибку контролируемо.

Hot keys и «горячие» профили: если конкретный профиль получает несоизмеримо много трафика, имеет смысл хранить его в специальной hot-shard или использовать client-side near-cache с TTL и LFU-недельной политикой, либо применить rate limiting на уровне потребителей для этого ключа.

Eviction и стратегии: Redis предлагает политики evictions: LRU, LFU, TTL-based и их комбинации. Для профилей лучше избегать простого allkeys-lru без учета семантики, иначе горячие профили будут вытеснять набор «активных» пользователей. Практические подходы: разделение ключей по namespace (hot vs cold) с разными maxmemory и политиками; хранение самых важных полей отдельно (hot fields) с более длинным TTL; использование LFU для адаптивного удержания часто запрашиваемых профилей. Также можно применять size-aware eviction: учитывать размер значения при принятии решения об удалении (если профили имеют разный размер).

Последовательность для отказов компонента кеша: при недоступности Redis система должна graceful degrade — либо читать напрямую из БД (fail-open), либо использовать локальные копии (near-cache), либо, при критичности защиты БД, temporarily reject с контролируемым backoff (fail-closed). Чаще выбирают fail-open для пользовательского опыта и мониторинг для отслеживания нагрузки на базу.

Этап 5. Концептуальная архитектура и целостный обзор

В центре — прикладной API слой с middleware, реализующим логику кеширования. Redis Cluster выступает в качестве распределённого in-memory хранилища. Рядом располагаются вспомогательные сервисы: сервис конфигурации TTL/политик, фоновые воркеры для прогрева/рефреша, очередь событий для инвалидаций (pub/sub или Kafka), мониторинг/alerting. Поток чтения: application → local near-cache → Redis → DB. Поток записи: application → DB → (инвалидация через pub/sub) → Redis (delete) или обновление значения. Для борьбы со штампедом дополнительный слой — lock service (реализуемый через Redis SETNX + Lua) и Bloom filter для non-existent keys.

Этап 6. Выбор технологий и sizing

Технологический стек: Redis Cluster для шардирования и масштабирования памяти, с replica-репликами на каждом шардe для отказоустойчивости; Redis Sentinel или встроенные механизмы кластера для failover; использование Redis Modules (RedisJSON) если нужно частичное чтение/запись полей профиля без передачи всего объекта; клиентские библиотеки с поддержкой singleflight/near-cache.

Sizing. Исходим из предположений: N активных пользователей, средний профиль P килобайт, ожидаемый hit-rate H, peak read QPS_r и write QPS_w. Память = N * P * (1 / hit_factor) плюс overhead шардов и metadata; добавляем репликацию (factor 2 или 3). Количество узлов = ceil(memory_total / instance_memory). Для QPS учитываем пропускную способность каждого экземпляра Redis (обычно десятки тысяч ops/s на современном железе), но при большом числе небольших операций важна сетевая задержка и CPU (Lua-скрипты и сериализация). Рекомендуется планировать запас 2–3× по операции и памяти, использовать мониторинг (hit ratio, evictions, latency) и авто-scaling/resharding при росте.

Параметры отказоустойчивости: реплики на каждом шарде, RPO/RTO зависят от выбора persistence (AOF vs RDB) — для кеша обычно persistence выключен или минимален; если важно сохранить кеш между рестартами, включают RDB snapshotting с приемлемыми интервалами.

Этап 7. Дополнительные расширения и эксплуатационные темы

Можно рассмотреть следующие улучшения: partial caching с RedisJSON для снижения трафика при обновлениях; adaptive TTL на основе частоты доступа; per-field versioning для минимизации инвалидаций при частичных обновлениях; CDN/edge caching для контента профиля, не требующего приватности; использование managed Redis (AWS ElastiCache, Azure Redis) для снижения операционной нагрузки. Для наблюдаемости — метрики: hit/miss ratio, evictions/sec, memory usage, slowlog; tracing запросов для выявления hot keys. Наконец, политика безопасности: шифрование транспортного уровня, ACL в Redis, ограничение доступа через VPC.

Messenger/Chat (WhatsApp / Telegram Lite)

Сохранение сообщений, онлайн-статусы, доставляемость, fan-out.

Этап 1. Постановка задачи и исходный контекст

Интервьюеру даётся задача: спроектировать сервис обмена сообщениями — лёгкий мессенджер, обеспечивающий отправку и хранение сообщений, онлайн-статусы, доставляемость и масштабируемый фан-аут как для личных чатов, так и для групповых. Система должна поддерживать множество устройств на один аккаунт, обеспечивать быстрый UX (низкая задержка доставки и отображения новых сообщений), сохранять историю и при необходимости доставлять сообщения оффлайн-пользователям через push. Нефункциональные требования включают высокую доступность, устойчивость к пиковому трафику, масштабирование до миллионов активных пользователей, обработку медиа (attachments) и обеспечение порядка сообщений в пределах чата. Дополнительные пожелания — эффективная борьба с дублированием, поддержка синхронизации между устройствами и возможность расширения (например, голосовые сообщения, шифрование).

Интервьюер на этом этапе обычно не даёт дальнейших уточнений; кандидат должен сам формализовать требования и границы.

Этап 2. Формализация требований и ключевые архитектурные характеристики

Кандидат задаёт уточняющие вопросы и формализует поведение системы. Первое — требуемые гарантии доставки: допустима ли at-least-once или требуется exactly-once? В мессенджерах обычно достаточно at-least-once с идемпотентной обработкой на клиенте (удаление дубликатов по message-id) и семантикой «sent → delivered → read». Второе — требования к порядку: строгий порядок обеспечивает удобство в личных чатах; в группах часто достаточно порядка в пределах одного отправителя или условного causality (переменная важность строгого глобального порядка). Третье — моделирование оффлайн-клиентов: сообщения должны сохраняться на сервере до доставки всем активным девайсам или до истечения TTL, а также синхронизироваться при подключении нового устройства. Четвёртое — масштабируемость фан-аута: одновременная доставка в группы с миллионами подписчиков невозможна простым broadcast-режимом; нужно выбирать между eager fan-out (write-time fan-out) и lazy fan-out (read-time fan-out) с гибридными подходами. Пятое — требования к конфиденциальности и безопасности: будет ли требоваться end-to-end шифрование (E2EE) или достаточно транспорта и хранения в зашифрованном виде на сервере. Нефункционально фиксируется высокая доступность, низкая задержка (мс-уровень для онлайн-доставки), масштабируемость и мониторируемость.

На базе этих ответов фиксируются ключевые архитектурные характеристики: больше внимания — latency и availability; консистентность — умеренная (с акцентом на локальный порядок в чатах); throughput — высокий для читателей и средний/низкий для записей; auditability и долговременное хранение — опционально, зависят от политики ретеншна.

Этап 3. Проектирование границ системы и публичного API

Границей считается набор API, которым оперируют клиенты и вспомогательные сервисы. Минимальный публичный контракт включает операции аутентификации/привязки устройства, отправки сообщения, получения сообщений (с пагинацией и синхронизацией), отметки доставленных/прочитанных сообщений, получения и публикации presence, загрузки и получения медиа, управление подписками на групповые события.

Примеры API (HTTP/HTTP+WebSocket/гетерогенный протокол):

POST /v1/send
body: { fromUserId, fromDeviceId, conversationId, clientMessageId, payload, timestamp, attachmentsMeta }

WS: SUBSCRIBE /v1/stream?userId=…
messages stream: server -> client pushes new messages, presence updates, acks

GET /v1/sync?userId&sinceToken
returns: ordered messages, device sync cursors

POST /v1/ack
body: { conversationId, serverMessageId, ackType: delivered|read, deviceId, timestamp }

POST /v1/presence
body: { userId, deviceId, status: online|offline|idle, lastActiveAt }

API должен возвращать достаточную метаинформацию: серверные идентификаторы, пер-сообщение sequence / lamportTimestamp для порядка, курсоры синхронизации и указание устройств, на которые сообщение было доставлено или нет. Публичный контракт отделяет клиентскую видимость от внутренней реализации (например, internal push-gateway, message-broker, storage).

Этап 4. Проектирование системы: happy path и exceptional flows; компоненты и потоки данных

Основной happy path: пользователь A отправляет сообщение в чат с пользователем B или в группу. Клиент формирует клиентский идентификатор clientMessageId и локальную метку времени; сообщение отправляется на ближайший frontend (API / WebSocket gateway). Gateway выполняет базовую валидацию и передаёт сообщение в контроллер доставок (dispatcher). Dispatcher назначает серверный идентификатор messageId и sequence/ordering metadata, записывает сообщение в durable log (например, partitioned Kafka topic или аналогичный commit-log) и публикует событие в очередь доставки. Затем dispatcher инициирует фан-аут: для личного чата это список устройств B; для группы — список участников (который может храниться в sharded group-service). Для каждого целевого девайса формируется delivery task, который отправляется в ряды delivery-workers.

Delivery-worker пытается доставить сообщение: если получено активное соединение WebSocket/MQTT, worker шлёт push и ждёт acknowledgement от клиента. При подтверждении отправки (device-level ack) worker помечает устройство как доставленное и, при необходимости, обновляет статус в message-store. Если устройство оффлайн, worker генерирует push-notification через APNs/FCM (через push-gateway) и сохраняет сообщение как pending в per-device queue для будущей доставки. После доставки на все устройства обновляется статус «delivered» для конкретного получателя или всех получателей. При прочтении клиент шлёт read-ack, который обновляет read-state и генерирует уведомление отправителю.

На этом пути формируются ключевые компоненты: front-end gateways (HTTP + WebSocket), dispatcher (assigns ids, writes to commit-log), durable commit-log (Kafka-like), delivery workers (stateless, масштабируемые), presence service (tracking active connections and device mapping), group service (manages membership), message store (persisting messages for retrieval and history), per-device pending queues, push-gateway, media-store / CDN для attachments, sync service (reconciliation and history pagination), and monitoring & metrics.

Exceptional flows: дублирование сообщений при повторной отправке со стороны клиента (network retry) обрабатывается идемпотентностью по clientMessageId; потеря ordering при кросс-шардовых операциях решается назначением per-conversation sequence (dispatcher даёт монотонный sequence в пределах conversation partition). Отказ durable log или delivery-workers компенсируется репликацией commit-log и повторной обработкой событий; в случае недоступности push-gateway система может временно накапливать pending-notifications и применять backoff. Для скоростных всплесков применима backpressure на gateway и rate limiting на уровне sender.

Порядок сообщений. В личных чатах важно сохранить строгий порядок; это достигается partitioning commit-log по conversationId — все сообщения одного разговора попадают в один партишин, получают последовательный offset и обрабатываются в порядке поступления. В группах с большим количеством участников схему с single partition может стать узким местом; тогда применяют per-conversation партиционирование + sharding группы по conversationId и, при необходимости, логические sequence от каждого отправителя (per-sender ordering) с merge-стратегией на клиента.

Хранение истории. Сообщения сохраняются в message-store — выбор между wide-column store (Cassandra/DynamoDB) или append-only blob storage с индексом зависит от требований по latency и доступности. Для пользовательского опыта последние N сообщений размещают также в in-memory cache (Redis) для ускорения sync и initial load. Медиа-файлы сохраняются в object storage (S3) и раздаются через CDN; в базе хранятся ссылки и метаданные. Политика retention управляется на уровне сервиса: удаление по истечению TTL, возможность удаления пользователем и аудит.

Синхронизация между устройствами реализуется через sync cursors. Клиент периодически вызывает /sync?sinceToken и получает все новые события. При привязке нового устройства проводится full-sync (последние N сообщений плюс paginated history). Sequence и cursor гарантируют, что клиент получит все события в нужном порядке.

Этап 5. Концептуальная схема и целостный обзор

Система представляется в виде многоуровневой архитектуры. На периферии расположены Gateways, принимающие клиентские соединения. Gateway взаимодействует с Presence Service для определения активных устройств получателя и с Group Service для получения списка участников. Dispatcher делает durable write в commit-log, который является единственным источником правды для событий. Delivery-workers читают из commit-log или получают события через pub/sub и выполняют доставку, сохраняя статусы доставки в Message Store. Message Store даёт возможности чтения истории и согласования при повторной доставке. Media-поток обрабатывается отдельно: uploader сохраняет в object storage, возвращает ссылку, которую включают в сообщение. Push gateway интегрирован с внешними сервисами для уведомлений на мобильные устройства. Синхронная инвалидация/ack flow и метрики обеспечивают поддержку SLA. Такая архитектура обеспечивает надёжную, масштабируемую обработку сообщений и даёт четкие точки расширения.

Этап 6. Выбор технологий и sizing

Выбор технологий ориентируется на требования: Kafka-подобный durable log для commit-log; Cassandra или DynamoDB для message-store при требовании write-heavy и линейного масштабирования; PostgreSQL/Spanner — при необходимости транзакционной логики (редко требуется для чатов). Redis применяется для presence, per-device queues и кеширования последних сообщений. WebSocket / MQTT брокеры (NGINX + WebSocket, EMQX, Mosquitto или propietary gateway) используются для удержания постоянных соединений и низкой латентности пуша. Push-gateway интегрируется с APNs/FCM. Object storage (S3) и CDN для медиа.

Sizing делается на основе входных параметров: число активных пользователей (MAU/DAU), среднее число одновременных подключений, средний QPS отправки сообщений, средний размер сообщения и среднее число получателей. Формула для пропускной способности коммита в durable log: required_throughput = messages_per_sec * replication_factor. Для хранения: daily_storage ≈ messages_per_day * avg_message_size. Примерная численная иллюстрация: при 10M DAU, 20% concurrent, средний отправляемых сообщений на пользователя в день 50, avg_size 1KB, получателей в среднем 1.5, потребуется пропускная способность commit-log порядка 10M50/86400 ≈ 5.8k msg/s (при этом с репликацией и overhead ориентируемся на ≈ 20k ops/s). Message-store размер в день: 10M501KB1.5 ≈ 750GB; с репликацией и overhead под 2TB в день; retention 30 дней — порядка 60TB. Эти оценки показывают необходимость shard- и tiered-storage (горячие последние дни в Cassandra / SSD, архивы в object storage). Количество WebSocket gateway’ев рассчитывается исходя из допустимого числа соединений на ноду и пикового трафика; современные инстансы поддерживают десятки тысяч persistent connections.

Выбор по гарантиям: если достаточно at-least-once, Kafka+consumer-groups + idempotent writes на клиенте — простой путь. Для stronger semantics применяют exactly-once processing с эффектацией последовательных обновлений в message-store с помощью transactional writes или conditional writes.

Этап 7. Дополнительные вопросы, расширения и эксплуатационные аспекты

Система допускает множество дополнений. End-to-End шифрование требует изменения контрактов: сервер перестаёт иметь доступ к расшифрованным payload’ам, хранения метаданных и доставки осуществляются по зашифрованным blob’ам; sync и поиск усложняются. Масштабирование больших групп оптимизируется через hybrid fan-out: для небольших групп — eager fan-out (разовая запись в per-recipient queues), для очень больших групп — lazy fan-out (recipient pulls recent offsets), а для мега-групп — use of multicast-like delivery через push-to-topic + client-side filtering. Hot-group и hot-user detection помогают выделять горячие участки нагрузки в отдельные шарды. Для борьбы с spam — комбинация rate limiting на стороне sender, content-moderation pipelines и machine-learning фильтров.

Операционно важны мониторинг и alerting: delivery latency, ack-rates, queue-latency, commit-log lag, offline message queue sizes, push-failure rates и hotspot detection. Тестирование отказов и chaos engineering критичны для гарантирования SLA; регулярные drills для push-gateway’а и durable-log failover обязательны. Политика бэкапов для message-store зависит от требований к RPO/RTO; для быстрого recovery используются snapshot’ы и репликация.

Наконец, UX-аспекты: клиентская логика должна обрабатывать дубли, обеспечивать локальную видимость отправки (optimistic UI), корректно показывать статус доставлено/прочитано с учётом нескольких устройств, уметь синхронизироваться после долгого offline периода и уважать privacy settings пользователя.

News Feed

Fan-in/fan-out, push vs pull, хранение ленты.

Этап 1. Постановка задачи и исходный контекст

Интервьюер формулирует задачу: спроектировать систему формирования и доставки ленты новостей (news feed) уровня соцсети. Система должна принимать события (посты, репоcты, лайки, комментарии), агрегировать их в персональные ленты пользователей и обеспечивать быструю доставку и прокрутку (infinite scroll). Дополнительные требования: персонализация ранжирования, свежесть контента, масштабирование до миллионов активных пользователей, поддержка как текстовых сообщений, так и медиа, гарантия приемлемой латентности для первой страницы и бесшовной подгрузки истории. Нефункциональные требования включают высокую доступность, устойчивость к пиковому трафику, предсказуемое время отклика, возможность A/B тестирования ранжировщиков и экономное использование ресурсов при больших фан-аутах (множество подписчиков у одного автора).

Интервьюер на этом этапе заканчивает ввод, инициатива переходит к кандидату.

Этап 2. Формализация требований и уточняющие вопросы

Кандидат задаёт вопросы, чтобы определить границы и приоритеты. Что важнее для продукта: абсолютная свежесть или релевантность ранжирования? Нужно ли показывать «activities» от друзей в строгом хронологическом порядке или применять персонифицированный рейтинг? Какая допустимая задержка от создания события до его появления в ленте: сотни миллисекунд, секунды или минуты? Какова типичная структура социальной графа: большинство пользователей имеют небольшое число подписок или есть много «звёзд» с миллионами подписчиков? Будут ли активные push-уведомления для новых постов или достаточно pull/refresh по требованию? Нужны ли глобальные агрегаты («тренды», «топ за день»), и какова политика ретеншна для истории?

Формализуя нефункциональные характеристики, фиксируют цели: низкая латентность загрузки первой страницы, высокая пропускная способность для фан-аута, приемлемая eventual consistency между источником и пользовательской лентой, гибкость в обновлении ранжировщика, а также возможность поведения при отказах (graceful degradation). Эти уточнения формируют основу для выбора архитектурных паттернов.

Этап 3. Границы системы и публичное API

Граница системы — сервис формирования и выдачи ленты. Публичное API включает операции: publishEvent(sourceId, event), getFeed(userId, cursor, policy) и éventuellement subscribeToRealtime(userId) для WebSocket/streaming. API возвращает упорядоченный, постраничный набор feed-items с указанием источника, метаданных ранжирования и курсором для следующей страницы. При публикации события вызывающий компонент может передавать минимальные метаданные (тип события, timestamp, «вес»), а более тяжёлые данные (медиа) хранятся отдельно и инлайнятся ссылками.

Важно надёжно отделить публичный контракт от внутренней реализации: клиент не должен знать, была ли запись сформирована при записи (push fan-out) или собрана при чтении (pull). API должен позволять переключаться между стратегиями без изменения клиентского кода.

Этап 4. Проектирование: сценарии, потоки данных и компоненты

Сердце задачи — выбор модели fan-in/fan-out и стратегия push vs pull. При публикации событие поступает в ingest-пайплайн, проходит валидацию и поступает в durable commit-log. Отсюда есть два принципиально разных подхода к формированию персональных лент.

В модели fan-out-on-write (push) система сразу распространяет событие во все персональные ленты подписчиков: для каждого follower создаётся запись в per-user store (materialized feed). Это делает чтение чрезвычайно быстрым — getFeed просто читает precomputed список. Но при высоком числе подписчиков одного источника (celebrity) write-амплификация становится дорогой: публикация одного поста генерирует огромный объём записей. Решение — гибрид: выполнять eager fan-out для авторов с небольшим числом подписчиков, а для «звёзд» переключаться на read-time сборку.

В модели fan-out-on-read (pull) при запросе ленты система собирает события с источников, которых читатель подписан, и ранжирует их на лету. Это экономит записи при публикации, но увеличивает задержку чтения и вычислительную нагрузку на read-path, особенно при большом числе подписок. Практически всегда используют гибрид: материализованные feeds для подавляющего большинства пользователей и lazy fetch для аккаунтов с огромной аудиторией.

Ранжирование делится на два этапа. Offline-пайплайн (batch) формирует базовые сигналы и обученные модели рекомендаций, предвычисляет candidate set для пользователей или для сегментов. Online-компонент (real-time scorer) применяет скоринг с учётом свежих сигналов (взаимодействия в последних минутах, временные boost’ы, демографические фильтры) и ранжирует кандидатов в момент выдачи. Компонент realtime scoring должен быть быстрым и легковесным; тяжёлые ML-модели выполняются в background и результаты кешируются.

Хранение ленты может быть организовано как per-user materialized view (row per user with ordered list), либо как inverted index в key-value сторе, где ключ = userId, value = списочный указатель на feed-items; вместо хранения полного payload’а хранятся ссылки на события в центральном event-store и на медиа в object storage. Такой подход упрощает инвалидации и сжатие; при удалении контента проще пометить событие как удалённое, не удаляя все зеркала.

Для борьбы с дублированием и order-issues применяют per-user cursors и deterministic ids (eventId, sequence per source). Параллелизм и шардинг социал-графа выполняют по userId, а для равномерного распределения нагрузки используют согласованное хеширование и переназначение шардов при росте.

Realtime delivery опирается на subscription layer: фронт для WebSocket/HTTP-streaming получает события push из materialized feed (или через pub/sub) и отправляет их подключённым клиентам. Для push-уведомлений мобильным устройствам используется отдельный push-gateway. Для offline-пользователей события помещаются в per-device queue до момента доставки.

При больших всплесках нагрузки система должна применять backpressure: throttling на publish (rate limiting для источников), batching публикаций, а также адаптивную деградацию ранжировщика (упрощённый ранжировщик при пиковой нагрузке).

Этап 5. Концептуальная архитектура и целостный обзор

Целостная схема включает следующие зоны: ingest-пайплайн (API gateway → validation → commit-log), materialization layer (fan-out workers и per-user feed storage), ranking layer (offline feature computation + online scoring), storage (event-store, per-user feed store, media storage), realtime delivery (subscription gateways, push-gateway), и monitoring/analytics. Commit-log (Kafka или аналог) служит источником правды и даёт возможность повторной переработки событий для переиндексации лент при изменении ранжировщика. Materialization layer читает из commit-log и актуализирует per-user feeds; он же выполняет hybrid-решение: eager fan-out для «малых» авторов, флаг lazy для «горячих» аккаунтов.

Выдача ленты выглядит просто для клиента — чтение materialized view с последующей дополнительной онлайновой переоценкой топ-N кандидатов. Для мультиязых/мультирегионональных развертываний materialized feeds хранятся в региональных кластерах, а commit-log реплицируется либо через geo-replication, либо через региональные пайплайны с согласованным eventual consistency.

Этап 6. Выбор технологий и оценка размера системы

Для commit-log логичным выбором будет Kafka-подобное решение: обеспечивает высокую пропускную способность, retention и возможность переиграть события. Для materialized per-user feeds подходят хранилища, которые эффективно работают с append/prepend и range-reads: wide-column базы (Cassandra, Scylla), key-value сторы с поддержкой списков (Redis Streams для горячих данных, но при большом retention лучше Cassandra). Для медиа — object storage + CDN. Для realtime scoring и низкой латентности используют in-memory сервисы и feature caches (Redis/KeyDB), а для heavy ML — онлайн feature store и fast API для получения признаков (Feast-подобные решения).

Sizing начинается с расчёта: число публикаций в секунду, средний размер события, среднее число фоловеров источника и retention feed-элементов на пользователя. Общий объём записей при eager fan-out приближается к публикациям × average_followers, поэтому для сервисов с большой долей «звёзд» hybrid-подход существенно снижает нагрузку. Хранилище per-user feed должно выдерживать QPS чтений пиковых часов; для первой страницы важно обеспечить латентность мс-уровня, поэтому hot feeds держат в памяти или на SSD. Репликация, резервирование и мониторинг latency, lag в materialization workers и consumer lag в commit-log критичны для sizing.

Важный практический паттерн — стадирование: хранить только N последних элементов в materialized feed (sliding window), старую историю перемещать в холодное хранилище и доставлять при demand-пагинации. Это экономит оперативную память и упрощает инвалидации.

Этап 7. Дополнительные вопросы, расширения и эксплуатационные аспекты

Система дает возможности для множества улучшений. Персонализация может эволюционировать от простых heuristics (recency, popularity, social proximity) к сложным ML-рестраферным моделям с bandit/A-B testing. Обеспечение fairness и diversity — важные требования продукта, которые вводят дополнительные сигналы в ранжировщик. Конфиденциальность и модерация — фильтрация контента и «take down» операции требуют быстрых инвализаций materialized feeds по всему кластеру; здесь commit-log с быстрым набором worker-ов и topic для moderation-events помогает.

Для борьбы с накрутками и спамом добавляют throttling на create-event, signal-based detection и adaptive penalties. Для повышения UX применяют optimistic updates на клиенте и клиентскую агрегацию (например, показывать «X новых постов», не пытаясь сразу подтянуть всё).

Операционная сторона включает мониторинг tail-latency, consumer lag, number of hot keys, memory pressure на feed-store, size of per-user feeds и ratio eager-vs-lazy fan-out. Chaos engineering и регулярные проверки корректности ранжирования при обновлении ML-моделей обязательны. Архитектура должна позволять безболезненно «переиграть» события через commit-log для ретроактуализации ранжирования.

Design a Logging System

Централизованный сбор логов (ELK / ClickHouse), ingestion pipeline.

Этап 1. Постановка задачи и исходный контекст

Интервьюер ставит задачу: проектировать централизованный лог-ингест и хранение для больших систем. Система должна принимать логи и события от тысяч/миллионов источников (приложения, контейнеры, сетевые устройства, облачные сервисы), обеспечивать надёжный сбор, парсинг и обогащение, давать быстрый полнотекстовый поиск и агрегации в реальном времени, поддерживать аналитические запросы по историческим данным, давать возможности для алертинга и интеграции с downstream-pipelines. Требования включают: устойчивая ингерсия при пиковых нагрузках, гарантии доставки (минимум at-least-once), масштабируемое хранение с управлением ретеншном, низкая латентность для «первого поиска» недавно пришедших логов, дешёвое холодное хранение старых данных и обеспечение безопасности/аудита. После объявления контекста интервьюер обычно молчит; кандидат уточняет границы и характеристики.

Этап 2. Формализация требований и уточняющие вопросы

Кандидат задаёт набор уточняющих вопросов, определяющих архитектурный вектор. Нужны ли в логах структурированные поля (JSON) или свободный текст; какие объёмы ожидаются (EPS и средний размер записи); требования по retention для разных типов логов (audit — месяцы/годы, app debug — дни); что важнее — полнотекстовый поиск или аналитические агрегации на больших объёмах; требуется ли realtime-alerting с задержкой <1–5 секунд; какова допустимая стоимость хранения; какова политика соответствия (GDPR, HIPAA). От ответа на эти вопросы зависит выбор движков: Elasticsearch/Opensearch хорош для полнотекстовых поисков и интерактивного анализа, ClickHouse эффективен для высокоскоростных аналитических агрегаций и хранения, object-storage (S3) — для холодного архива и сырого лога. Не менее важно уточнить требования по SLA/латентности для поиска свежих логов, и следует ли поддерживать reprocessing (переиграть ингерс-лог) при изменении парсинга или ранжирования.

Ключевые нефункциональные характеристики фиксируются так: высокая доступность ingestion-пайплайна, устойчивость к всплескам с приёмом значительной доли пиков, масштабируемость хранилища и возможности дешёвой архивации, предсказуемая стоимость и наблюдаемость (метрики lag, drop, processing time).

Этап 3. Границы системы и публичный API

Границы системы — входные точки для продюсеров логов и внешнего потребителя (search/analytics/alerting). Публичный контракт включает ingestion API (HTTP/S endpoint, syslog/UDP/TCP, beats/forwarder, gRPC), схему для batch-пушей и streaming (безопасный endpoint и возможности ретраев). Для downstream-потребителей публичный API включает query API (search by time/span/fields, aggregation queries, scroll/pagination), subscription API для реального времени (websocket/push on match), и управление retention/reindex/ILM. Также нужны API для schema registry (если используем Avro/Protobuf для структурированных логов), а также endpoints для health/metrics и для административных действий (удаление, экспорт).

API должен выражать, что ингерс — асинхронен: ответ на ingestion даёт подтверждение приёма (accepted/queued) и cursor/offset, а не мгновенную индексацию. Это позволяет упаковать ожидания по латентности.

Этап 4. Проектирование: сценарии, потоки данных и компоненты

Сердце системы — ingestion pipeline, построенный вокруг устойчивого commit-log (обычно Kafka или совместимый). На периферии находятся collectors/agents (Beats, Fluentd, Vector, Filebeat, syslog-ng), которые аггрегируют, буферизуют и шипят данные в ingress brokers. Сюда же входят cloud-native shippers (CloudWatch→Kinesis→Kafka), sidecar’ы в контейнерах и сетевые лог-прокси. Этот слой ответственен за backpressure и локальные ретраи — при падении центрального брокера агенты буферизуют локально.

Далее поток идёт в парсеры/normalizers: stream processors (Logstash, Fluent Bit, Kafka Streams, Apache Flink, or a Beam pipeline) выполняют parsing (JSON парсинг, grok), enrichment (geo-IP, service metadata, kubernetes/pod labels), фильтрацию (redaction PII) и категоризацию. Парсинг может быть тяжёлым — поэтому лучше делать его в распределённом стрим-слое, где можно горизонтально масштабироваться и переигрывать события при обновлении схем.

После нормализации данные идут в две основные ветви хранения: fast-search store и analytics store. Fast-search (hot path) — это полнотекстовый индекс (Elasticsearch / OpenSearch), оптимизированный на быстрый поиск по времени и полям. Analytics store (OLAP) — ClickHouse или Parquet/Delta Lake на S3, оптимизированный на массовые агрегации и дешёвое хранение больших объёмов. При этом сырые события и парсинг-оригиналы также отправляются в объектное хранилище (S3) для долговременного архива и возможности переобработки.

Реалтайм-алертинг реализуется на стрим-слое: CEP/streaming engine смотрит за паттернами и пишет alert-events в алерт-систему (AlertManager, PagerDuty) и/или в ES для fast-query. Для исследований и интерактивных дашбордов используется связка Kibana/Grafana, при этом heavy analytics выполняются в ClickHouse (поддерживает быстрые group-by по большим объёмам).

Ключевые инженерные вопросы на этом этапе: partitioning (по source-id, tenant, time), ordering (в пределах partition), idempotency (message-id для дедупа), schema evolution (registry + versioning), задержки (SLA по приёму→доступности в search), гарантия доставки (at-least-once + dedup), и backpressure (agents + brokers + circuit breakers).

Stampede/пики решаются буферизацией на нескольких уровнях: agent-side disk buffer, Kafka topic с retention и многими consumer groups, и масштабирование парсинг/ingest-workers. Если тема — cost, часть данных можно напрямую шорт-листить: критичные логи в ES, менее критичные в ClickHouse или только в S3.

Этап 5. Концептуальная архитектура и целостный обзор

В целостном виде архитектура выглядит как многоступенчатый конвейер: источники → collectors/agents (buffer, backpressure) → ingress broker (Kafka) → stream processors (parse, enrich, filter) → fast index (Elasticsearch) + analytics store (ClickHouse) + cold archive (S3 / HDFS). Над этим слоем находятся realtime alerting services, query/visualization layer (Kibana/Grafana/Custom UI), и админ-панель для управления policies/ILM/schema. Commit-log (Kafka) служит одним источником правды и даёт возможность переиграть события для исправления парсинга, регенерации индексных представлений или репроцессинга аналитики.

Для безопасности и мульти-тенантности вписываются шлюзы аутентификации/authorization, TLS, per-tenant topics/indices и RBAC. Для наблюдаемости system emits metrics: ingest-lag, consumer-lag, parsing-errors, index-rate, disk-usage, query-latency.

Этап 6. Выбор технологий и sizing (с примером расчёта)

Технологические выборы ориентируются на требования. Для collectors используют Beats/Vector/Fluent Bit; для брокера — Apache Kafka или managed Kafka (Confluent, MSK); для stream processing — Flink/Beam/Flink SQL или Kafka Streams; для быстрого поиска — Elasticsearch/OpenSearch; для аналитики — ClickHouse; для cold storage — S3 + Parquet/ORC; для alerting — Prometheus Alertmanager + custom rule engine; для schema registry — Confluent Schema Registry (Avro/Protobuf). Менеджмент и автоматизация — Kubernetes/Helm и оператор для ES/ClickHouse/Kafka, CI для schema changes.

Чтобы показать подход к sizing, приведу пример: предположим 100k событий в секунду, средний размер события 1 KB. Посчитаем поток сырых данных в сутки и оценим индексную нагрузку.

Шаги расчёта (цифры приведены детерминировано):

EPS = 100 000 событий/с.

Средний размер = 1 000 байт.

Байтов в секунду = EPS × размер = 100 000 × 1 000 = 100 000 000 байт/с.

Байтов в сутки = 100 000 000 × 86 400 = 8 640 000 000 000 байт.

Это 8.64 TB в сутки (десятичные ТБ, 1 TB = 10^12 байт).

Для индексирования в Elasticsearch обычно учитывают фактор overhead для inverted-index / replicas / metadata — практическая оценка 2–4× от сырых данных в зависимости от количества полей, анализаторов и репликации. При 3× overhead ежедневный объём индексируемых данных = 8.64 TB × 3 = 25.92 TB/day.

Отсюда выводы по sizing:

Hot storage (ES) растёт очень быстро; для 30-дневного retention потребуется ≈ 25.92 × 30 ≈ 777.6 TB индекса (без учета реплик и свободного запаса) — это повод держать в ES только последние N дней и делать tiered storage: горячие данные в ES (например последние 7 дней), тёплые в ClickHouse/SSD, холодные в S3 (Parquet).

Kafka throughput должен выдерживать ~100 MB/s входа и репликацию; планирование partition-count и disk throughput критично.

ClickHouse подходит для дешёвых агрегаций: компактное хранение Parquet и эффективная компрессия сильно уменьшают объём долгосрочного хранения.

Количество узлов ES зависит от target IOPS, heap sizing правил (для ES — минимизировать heap, больше RAM для filesystem cache) и репликации; расчёт узлов делается на основе 1) ожидаемой индексации/sec, 2) сред. размера сегментов, 3) retention и 4) оперативной памяти для caching.

Эти численные примеры показывают, почему для больших объёмов логов комбинируют движки: ES для fast-search последних данных, ClickHouse для аналитики и S3 для дешёвого архива.

Этап 7. Дополнительные расширения, эксплуатация и безопасность

Наконец, обсуждаем эксплуатационные и расширяющие аспекты. Schema evolution: использовать schema registry, версионировать парсеры и хранить raw-payload для переобработки. Deduplication: предусмотреть message-id и логику дедупа в стрим-слое. TL;DR по отказам: agents с disk buffer + Kafka с репликами + idempotent consumers + возможность переиграть темы. Для защиты приватных данных — redaction pipeline (PII masking) выполняется до записи в индекс; хранение raw-логов в зашифрованном виде и контроль доступа к ним. Monitoring: метрики ingest-latency, parsing-errors, consumer-lag, index-failure-rate, disk/IOPS; логирование самой лог-инфраструктуры отдельно и выделенно. Disaster recovery: snapshot ES/ClickHouse + репликации Kafka topics + объектные snapshot’ы на S3.

Операционные практики включают: ILM/curation для ES (rollover, shrink, delete), автоматический переход индексов между hot/warm/cold tiers, lifecycle для ClickHouse/Parquet архива, регулярные тесты переигрывания событий и проверка возможности reindex, автоматическое масштабирование consumer groups, и security audits. Для multi-tenant deployments — строгое изоляция данных по tenant-id (topics, indices, access control), rate-limiting per-tenant и мониторинг затрат.

Search Autocomplete

Система подсказок с высокой скоростью отклика.

Этап 1. Постановка задачи и контекст

Интервьюер ставит задачу: спроектировать службу автодополнения для поисковой строки, которая возвращает набор подсказок за очень низкое время отклика (целевые SLO — десятки миллисекунд для p95/p99). Система должна обрабатывать сотни тысяч или миллионы запросов в секунду, обеспечивать релевантность подсказок (popularity, personalization, recency), корректно работать при опечатках и частичных вводах, уважать фильтры безопасности (фильтрация матерных/запрещённых выражений) и позволять быструю инвалидацию/обновление подсказок при поступлении нового контента. Дополнительно важно хранение телеметрии (CTR подсказок, последующий поисковый запрос), A/B тестирование ранжировщиков и GDPR-совместимость при персонализации. После постановки интервьюер замолкает; кандидат переходит к формализации.

Этап 2. Формализация требований и уточняющие вопросы

Кандидат формализует функциональные и нефункциональные требования и задаёт уточнения, которые определяют архитектуру. Вопросы касаются допустимой латентности на p50/p95/p99; объёма QPS; допускаемых trade-offs между свежестью и скоростью; уровня персонализации (анонимная подсказка vs per-user); требуемой устойчивости к опечаткам; политики по обновлению словаря и частоте добавления новых фраз; требований к многокультурности и мульти-язычности; и допустимой стоимости (in-memory решение дорогé, но быстро). На основании ответов формируются целевые характеристики: ultra-low latency на read-path, eventual or near-real-time freshness (seconds→minutes), high throughput, per-query ranking с быстрым ранжированием и малой вычислительной нагрузкой.

Ключевое архитектурное решение уже на этом этапе: разделение на быстрый read-path (latency-critical)—использующий пред-вычисленные структуры и кэш, и менее критичный write-path для обновления словаря и сигналов ранжирования. Это диктует выбор data structures и потоков обновления.

Этап 3. Границы системы и публичный API

Граница системы — HTTP/gRPC интерфейс для клиентов (web, mobile, backend), плюс административные API для управления словарём и метриками.

Примеры контрактов:

GET /v1/autocomplete?q=nyc%20wea&userId=123&locale=en-US&max=10
Response:
{
«query»: «nyc wea»,
«suggestions»: [
{«text»:»nyc weather», «type»:»query», «score»: 98.3, «source»:»global_popular»},
{«text»:»nyc waterfront restaurants», «type»:»entity», «score»: 87.1, «source»:»local_index»}
],
«meta»: {«served_from»:»edge_cache»,»latency_ms»:6}
}

POST /v1/suggests/bulk_update
body: {updates: […]} // admin API for adding/removing phrases

POST /v1/telemetry
body: {userId, query, suggestionText, clicked}

Get-операция должна быть синхронной и укладываться в заданный SLO; админ-операции асинхронны — они пускают изменения в ingestion pipeline.

Граница системы также подразумевает ответственность за нормализацию входа (lowercase, unicode normalization, tokenization), за rate limiting и за базовую фильтрацию. Клиент не должен знать, использовался ли trie, FST, или search engine внутри; контракт остаётся стабильным.

Этап 4. Проектирование: happy path и exceptional flows; компоненты и потоки данных

Happy path для запроса простой: пользователь вводит префикс, клиент посылает /autocomplete, система нормализует префикс, проверяет edge/region cache (в память CDN/edge), затем обращается к локальному suggestion service. Suggestion service читает пред-вычисленные структуры (например FST/finite-state transducer, trie-индексы или inmemory priority lists), получает candidate set и применяет lightweight re-scoring (weighting by popularity, personalization signals, recency boosts, business rules). Результат кэшируется на лепестковом уровне (edge CDN, per-node LRU) и возвращается клиенту.

Основные компоненты:

• Frontend gateways (terminate TLS, auth, basic throttling) и edge caches, сокращающие путь для «горячих» префиксов.
• Suggestion service, реализующий latency-critical read-path: in-memory data structures (FST, prefix trie, or compressed tries stored in memory-mapped files), per-shard caches и fast scorer.
• Offline ingestion pipeline: прием обновлений (popularity events, new phrases, deletions) через commit-log (Kafka), батчевые генераторы FST/indices и incremental updaters (near-real-time).
• Realtime updater/nearline buffer: для немедленной видимости новых фраз поддерживается small in-memory overlay (log-structured memtable) или write-through to fast index; периодическая сшивка overlay → main FST.
• Persistance: backing store for phrase metadata (counts, timestamps, signals) — key-value store или OLAP store.
• Telemetry/analytics: сбор CTR, abandonment, latencies; pipeline feeding ML models for ranking.
• Admin services: profanity lists, blacklists, synonym management.

Выбор структуры данных определяет эффективность. Для дешёвых стоимостных reads эффективен FST (Lucene’s FST), который компактно хранит множество строк и позволяет быстро делать prefix lookup и буферизированную итерацию кандидатов. Для случаев, когда требуется выдать не только exact-prefix, но и fuzzy/typo-tolerant suggestions, используют сочетание FST + n-gram индекс, либо implement Levenshtein automata on the FST, либо предгенерируют n-grams/edge-ngrams в индексе (на чтение это будет быстрый lookup).

Ранжирование: важно держать основной скоринг лёгким: score = α·popularity + β·personalization + γ·recency + δ·business_boost. Сигналы popularity/recency можно инкрементировать в streaming pipeline; personalization сигналы запрашиваются из per-user store, но их извлечение должно быть быстрым (кэши, precomputed user preferences). Тяжёлые ML-модели применяют офлайн или в online-re-rank только на top-K кандидатов (K small, например 50→re-rank→return top 10).

Опечатки и fuzzy matching: варианты реализации разных степеней сложности. Простая, быстрая техника — edge-ngrams: хранить для каждой фразы ее префиксные n-грамы (tri/bi-grams) и при вводе искать по ним. Более точные варианты — Levenshtein automata intersected with FST (поддерживается в Lucene) или использование BK-trees для spell correction. Компромисс: либо дать очень быстрые prefix suggestions с limited fuzzy, либо тратить CPU/latency на глубокий fuzzy-lookup; обычно практикуют hybrid: prefix strict matching + lightweight fuzzy fallback.

Обновление данных и freshness: ingestion pipeline собирает имплицитные сигналы (search logs, clicks) → events → commit-log → streaming counter updates (increment popularity in real-time DB) → periodic rebuild of on-disk/mmapped structures (FST) или incremental update via small delta-FSTs merged regularly. Для immediacy поддерживают in-memory delta layer: new phrases go to memtable visible to reads, and background process compacts memtable into main FST every N seconds/minutes. Это даёт near-real-time видимость без перегенерации всей структуры.

Exceptional flows: сетевые задержки, кеш-мисс, перегрузка backends. При недоступности suggestion-service отвечают из edge cache или возвращают пустой набор с контролируемым fallthrough. Для защиты от широких атак и «helloworld»-пиков — rate limiting и per-key hot-key protection: если префикс слишком «горяч», используем precomputed top suggestions и ограничиваем expensive fuzzy attempts.

Этап 5. Концептуальная схема и целостный обзор

В целом система делится на два логических слоя: latency-critical read layer и asynchronous write/ingest layer. Read layer состоит из front gateways, edge caches (CDN / per-region cache), suggestion nodes (sharded, in-memory structures), и per-node caches. Write layer — telemetry collectors, event stream (Kafka), stream processors (real-time counters), offline batch jobs (rebuild FSTs, train ranking models), и admin pipelines (blacklist/synonym updates). Persistance включает columnar/kv store для metadata и object storage для backup of indices.

При таком дизайне путь для типичного запроса минимален: client → edge cache → suggestion node (in-mem FST) → scorer → return. Обновления проходят через stream → counters update → memtable overlay → periodic compaction. Это обеспечивает быстрое чтение и приемлемую свежесть.

Этап 6. Выбор технологий и оценка размера системы (sizing)

Технологии, часто применимые в продакшне: Lucene/Solr/Elasticsearch (completion suggester, FST), OpenSearch, Redis (for ultra-low-latency small-cache), RocksDB/LMDB as backing store, Kafka для ingestion, Flink/Kafka Streams for counters, and CDN/edge caches.

Как подходить к sizing без конкретных цифр: исходят из QPS автодополнения и целевых latency. Если система должна выдерживать 1M QPS, то чтение полностью из памяти критично; каждому suggestion-шарду ставим ограничение по числу подключений и throughput. Для FST, хранимого в памяти, важна оценка memory footprint: FST эффективен компрессией; если общий словарь из M фраз (например 100M фраз), и средний cost per phrase в FST ~ few tens bytes (зависит от overlaps and shared prefixes), общая память может быть порядка десятков гигабайт до сотен гигабайт. Для масштабируемости делим словарь на шард-ключи (hash by normalized prefix range or hash(query) with replica routing). Реплики для availability: обычно 2–3 копии sharded data.

Примерный расчёт метрики latency/throughput: допустим p95 latency target = 20ms сетевое + сервисное; suggestion node должна обслуживать lookup + scoring в пределах 10 ms. Это диктует in-memory structures и ограничение на количество вспомогательных запросов (minimize external calls). Если per-query re-rank использует heavy ML, то нужно выполнять re-rank только на top-K, к тому же re-rank model делает inference в специализированных serving nodes (GPU/CPU) с заранее закешированными фичами.

Ключевые практические правила sizing: поддерживать запас на 2–3× пиков для latencies; использовать региональные deployment для снижения сетевого RTT; хранить hot part of dictionary на RAM, warm part — on fast mmapped files; считать память на replica factor; проектировать auto-scaling для suggestion nodes по CPU/latency.

Этап 7. Дополнительные вопросы и расширения

Система предлагает много дополнительных функций и сложностей: персонализация подсказок под пользователя (history-based boosting, user segments), A/B тестирование ранжировщиков, поддержка многоязычности и локалей (separate indices or locale-aware normalization), context-aware suggestions (query + current page context), voice/ASR spelling corrections, privacy-aware ranking (обход персонализации по запросу) и safe-search filtering.

Операционные аспекты: мониторинг p50/p95/p99 latency, suggestion CTR, abandonment rate, error rate, hot-prefix heatmap; alerting on cache-evictions and high rebuild times; capability to replay logs to rebuild signals; procedures for blacklist/whitelist and rapid take-down; continuous evaluation pipeline for ranking models; chaos testing for partial failures and cold start.

Безопасность и модерация критичны: real-time profanity/PII filtering in ingestion, rate limiting to prevent abuse, and telemetry retention policies to satisfy privacy regulations.

File Storage Service (Dropbox / Google Drive Lite)

Хранение файлов, версионирование, синхронизация, шардинг.

Этап 1. Постановка задачи и контекст

Задача: спроектировать сервис для хранения пользовательских файлов с поддержкой версионирования, синхронизации между устройствами и масштабируемым хранением. Сервис должен позволять пользователям загружать и скачивать файлы разного размера, синхронизировать изменения между несколькими устройствами в реальном времени или в режиме фоновой синхронизации, предоставлять историю версий, позволять совместное использование (sharing) и обеспечивать разумную защиту данных и приватность. Нефункциональные требования включают: высокая доступность и надёжность (данные не теряются), масштабируемость по объёму и по числу операций, эффективное использование сети и диска (делта-обновления), гарантия целостности данных и возможность восстановления предыдущих версий, низкая латентность при доступе к «горячим» файлам, и экономичное долговременное хранение больших объёмов. Интерфейс должен поддерживать как веб/мобильный доступ, так и фоновые «sync» клиенты.

Этап 2. Формализация требований и уточняющие вопросы

Кандидат уточняет поведение и приоритеты. Насколько строгими должны быть гарантии консистентности между устройствами: нужен ли строгий сериализуемый порядок или достаточно eventual consistency с механизмами разрешения конфликтов? Ожидается ли поддержка больших файлов (десятки гигабайт) и потоковой передачи (streaming)? Как часто изменяются файлы: превалируют небольшие изменения в документах или крупные медиа-файлы? Какая политика версионирования: хранить все версии бесконечно или лимитировать по количеству/времени? Нужны ли блокировки на уровне файлов (advisory locks) или optimistic concurrency с merge-стратегиями? Будет ли служба предоставлять совместное редактирование в реальном времени или достаточно синхронизации версий? Ответы на эти вопросы задают направление по выбору архитектуры: если важна низкая вероятность конфликтов и сильная согласованность, потребуется более сложная координация; если важна пропускная способность и масштаб, стоит ориентироваться на eventually consistent store с семантикой «последнее сохранение выигрывает» и поддержкой версионирования для отмен и слияния.

Ключевые нефункциональные требования фиксируются так: устойчивость и долговечность хранения (RPO≈0), горизонтальная масштабируемость по объёму и по числу клиентов, экономичное холодное хранение, оптимизация сетевого трафика при синхронизации (делта-обновления, chunking), и поддержка офлайн-клиентов с последующей репликацией.

Этап 3. Границы системы и публичный API

Границы — сервис хранения и синхронизации, видимый клиентам и администраторам. Публичный API должен покрывать основные сценарии: загрузка (upload), скачивание (download), получение метаданных, создание/удаление/переименование объектов, управление версиями (listVersions, restoreVersion), операции синхронизации (sync cursors, long-poll / push notifications), управление доступом и шаринг (grant/revoke), а также административные операции (lifecycle, retention, audit logs).

Примеры контрактов: PUT /files/{user}/{path}?uploadId=… для chunked multipart upload; GET /files/{user}/{path}?version=… для получения конкретной версии; POST /sync/push {changes, clientCursor, deviceId} возвращает serverCursor и конфликтные файлы; GET /sync/pull?since=cursor возвращает дифф изменений. API должен быть идемпотентен по возможности: клиент при повторной загрузке с тем же uploadId продолжит процесс, при повторном push изменений сервер должен обрабатывать отдельно существующие идентификаторы изменения.

Этап 4. Проектирование: сценарии, потоки данных и компоненты

Проектирование начинается с happy path: пользователь создаёт или изменяет файл на устройстве. Клиент определяет изменения и передаёт дельту в сервис. Для эффективного использования сети и диска применяется разбиение на блоки (chunking) и адресуемое по содержанию хранение чанков (content-addressable storage, CAS). Клиент делит файл на фиксированные или переменные по контенту чанки, вычисляет их хеши, запрашивает у сервера какие чанки уже есть (dedup), загружает отсутствующие чанки, затем отправляет метаданные (manifest) с указанием порядка чанков и метаданных файла. Сервер, получив manifest, создаёт или обновляет объект файла, сохраняет ссылку на набор чанков, создаёт новую версию и обновляет метаданные пользователя.

Синхронизация между устройствами основана на механизме cursors или change-log: клиент периодически запрашивает изменения с момента своей последней синхронизации или получает push-уведомление. При приходе изменений клиент запрашивает нужные версии/чанки и применяет их локально. При одновременных модификациях применяется стратегия разрешения конфликтов: оптимистичная стратегия с версионными метками и автоматическим merge для текстовых файлов (via operational transforms или CRDT для real-time), либо сохранение обеих версий и уведомление пользователя о конфликте. Для многих приложений выбран pragmatic подход: если файл не является документом для real-time совместной работы, сохранять обе версии (conflict copy) и позволять пользователю/клиенту разрешить конфликт.

Компоненты системы складываются из нескольких групп. Persistence layer включает chunk-storage (объектное хранилище: S3 или его эквиваленты) и metadata store (ключ-значение или wide-column DB для маппинга файлов→манифестов, прав доступа, индексов). Chunk-store хранит неизменяемые чанки, оптимизированы по throughput и долговечности. Metadata store хранит и индексирует древовидную структуру каталогов, ACL, версии и cursors. Sync service отвечает за ingestion client-изменений, запись в write-ahead log (commit-log) и генерацию уведомлений для подписанных устройств. Background services выполняют сборку версий, очистку orphanChunks (гc), lifecycle и tiering (перемещение старых версий в холодный архив). Authentication/authorization и audit trail — отдельные сервисы. Кроме того, требуется notification service для push-уведомлений, CDN для отдачи больших файлов и streaming service для медиа.

Exceptional flows: потеря соединения при upload → поддержка resumable uploads (uploadId + chunkId), недоступность chunk-store → agents буферизуют с помощью local cache или retry-queue, конфликт версий → автогенерация conflict-file и уведомление пользователя, попытки злоупотреблений → rate-limiting и quota checks. Издержки масштабирования: горячие файлы (часто запрашиваемые) требуют кешей (edge CDN, Redis), холодные — перенос в дешёвую долговременную память.

Шардирование и балансировка. Metadata store шардируется по userId или по namespace, давая силуэшную изоляцию пользователей. Chunk-store шардируется по хешу чанка; хеш-ориентированное распределение даёт естественный баланс и позволяет эффективно дедуплицировать повторяющиеся данные у разных пользователей. Для масштабируемости каталоги больших аккаунтов (с миллионами объектов) необходимо делать paging и ленивую инициализацию каталогов, а также оптимизировать операции list с помощью precomputed index shards.

Версионирование. Версии реализуются как неизменяемые manifest-объекты, указывающие на список чанков и метаданные. При изменении создаётся новый manifest и ссылка на него сохраняется в metadata store. Политика хранения версий управляется lifecycle: хранить последние N версий или все версии за последние T дней; старые версии могут быть перемещены в холодный архив и/или удалены по политике.

Безопасность и целостность. Все чанки и manifest подписываются хешами; при восстановлении/передаче клиент может проверить целостность. Для защиты приватности применяют шифрование на стороне сервера (server-side encryption) либо end-to-end (client-side encryption) по требованию. Access control реализуется через токены и ACL, а аудит операций логируется в отдельную систему логов.

Этап 5. Концептуальная схема и целостный обзор

В целостном виде система выглядит как набор взаимосвязанных слоёв. На входе находятся клиенты, которые через API/SDK общаются с front-end gateway. Gateway выполняет аутентификацию, базовую валидацию и маршрутизацию в sync-service. Sync-service пишет операции в commit-log и обращается к metadata-store и chunk-API. Chunk-API взаимодействует с объектным хранилищем для записи и чтения чанков и с кешами для ускорения отдачи. Metadata-store хранит файловую структуру и версии; он шардирован по userId для масштабирования. Background workers читают commit-log и выполняют асинхронные задачи: сбор garbage (удаление неиспользуемых чанков), tiering, репликация и генерацию уведомлений. Notification-service доставляет события на устройства и триггерит pull. CDN/edge ноды обеспечивают быструю доставку больших файлов. Monitoring и alerting покрывают все слои: latency upload/download, storage utilization, gc-lag, error-rates. Такая архитектура разделяет долговременное хранение неизменяемых чанков и динамическую метаинформацию, что упрощает дедупликацию, версионирование и масштабирование.

Этап 6. Выбор технологий и оценка размера системы (sizing)

Технологии выбирают с учётом требований: объектное хранилище S3 (или S3-совместимое) как основа chunk-store для долговечности и cheap cold storage; для горячего слоя — SSD-backed storage или специализированные распределённые хранилища (Ceph, MinIO, Google Cloud Storage) с шардированием по хешу. Metadata store — выбор между DynamoDB/Cassandra/Spanner для горизонтальной масштабируемости и низкой латентности; PostgreSQL/MySQL подходят для меньших конфигураций, но масштабирование сложнее. Commit-log — Kafka или управляемые аналоги для гарантий доставки и переигрывания изменений. Для индексов и поиска (по имени, тегам) применим Elasticsearch или dedicated search service. Для edge-каша и распределённого lock-менеджмента используют Redis (для short-lived locks, rate-limits, sessions). Для push-уведомлений — APNs/FCM и internal push gateway.

Sizing: начнём с входных параметров: число пользователей, среднее число файлов на пользователя, средний размер файла, процент активных пользователей, QPS операций. Приведу примерный расчёт: 10M пользователей, среднее файлов на аккаунт 200, средний размер файла 5 MB. Объём данных ≈ 10M * 200 * 5MB = 10M * 1GB = 10 PB. Учитывая репликацию, overhead метаданных и index, итоговый raw storage может быть в районе 20–30 PB. Для такого объёма S3-стратегия с tiered storage необходима: горячие последние изменения держать на SSD/fast object storage, холодные перемещать в Glacier/Archive. По IOPS: если 1% файлов запросы в сутки, это 100k * 200 = 20M file accesses/day ≈ 230 ops/s — требует большого кеширования на edge. Для throughput при параллельных загрузках оцените пиковую QPS и планируйте трансферную пропускную способность и количество воркеров.

Dedup и chunking существенно сокращают объём: при высокой доле повторяющихся данных (например, резервные копии ОС или медиа) дедупликация может снизить объём хранимых данных в разы. Chunk-size trade-off: маленькие чанки дают лучшую дедупликацию и параллелизм, но больше метаданных; большие — меньше метаданных, но хуже дедупликация. Часто выбирают переменные по контенту чанки (content-defined chunking, CDC) с средней величиной 8–64 KB для хорошего компромисса.

Операционные параметры: поддерживать запас по throughput ~2–3× пиков для обеспечения устойчивости при пиковых бёрстах; мониторить gc latency (удаление старых версий) и неизменно иметь процедуры восстановления. RPO/RTO зависят от SLA — для критичных данных делают гео-репликацию и snapshot-ы.

Этап 7. Дополнительные вопросы и расширения

Наконец, варианты расширений и усложнений. Поддержка совместного редактирования в реальном времени требует реализации OT/CRDT и более сложной модели хранения изменений; это значительно меняет архитектуру, так как сервер должен поддерживать fine-grained ops и трансформации. End-to-end шифрование (E2EE) на клиенте существенно усложняет дедупликацию и серверные операции (сервер не видит содержимого, значит не может дедуплицировать или индексировать), но обеспечивает высокую приватность; практическая компромиссная модель — client-side encryption с optional server-side metadata indexing. Multi-tenant enterprise features (audit, compliance, retention policies, legal hold) требуют расширений metadata-store и интеграции с SIEM.

Другие полезные темы для продакшн-решения: версии хранения для efficient snapshotting (дедуплицированные manifests), квоты и billing, экспорты/миграции, интеграция с файловыми протоколами (WebDAV, SMB), CDN-integrated streaming для больших медиа, интеграция с CDN+signed-URLs для безопасного доступа, и тонкая моделирование прав доступа для совместного использования. Операционные практики: end-to-end тестирование restore-процессов, регулярные drill’ы по отказу региона, мониторинг tail-latency, и автоматизация lifecycle (tiering, cleanup) с отчетностью об экономике хранения.

Video Streaming Platform (YouTube Lite)

CDN, encoding pipeline, рекомендации (поверхностно).

Этап 1. Постановка задачи и контекст

Интервьюер объявляет задачу: спроектировать видеоплатформу, которая принимает пользовательские видео, хранит и транскодирует их в форматы, подходящие для воспроизведения в браузере и на мобильных устройствах, раздаёт контент с низкой задержкой глобальной аудитории через CDN, обеспечивает адаптивную потоковую доставку (ABR), ведёт хранение и метаданные, а также поддерживает базовую подсказку рекомендаций. Нефункциональные требования включают возможность масштабирования до миллионов загрузок и просмотров, минимизацию задержки старта воспроизведения (startup latency), эффективное использование сети и диска, экономную долговременную архивацию исходников, надёжность и устойчивость к пиковым нагрузкам (выпуски, вирусный контент). Платформа должна обеспечивать безопасность контента и правообладательский контроль, а также базовую телеметрию (view counts, watch-time, QoS metrics).

Интервьюер завершает ввод, кандидат переходит к уточнению требований и проекту.

Этап 2. Формализация требований и уточняющие вопросы

Кандидат формализует функциональность и определяет важные нефункциональные характеристики. Нужно понять ожидаемые SLO: p95 startup latency (например <2 s), допустимую задержку между загрузкой и доступностью в основном качестве (minutes→tens of minutes), поддерживаемые устройства и сети (mobile 3G/4G/Wi-Fi), требования к DRM или платному доступу, допустимые форматы исходников, объёмы хранения и ретеншн исходников, а также глубину рекомендаций (simple collaborative filtering vs сложная ML-пайплайн). Следует уточнить требования по live-streaming: требуется ли live или только VOD; в данном упрощённом кейсе сосредотачиваемся на VOD, упомянув отличия для live.

Нефункционально фиксируется приоритет: минимальная задержка старта и стабильная entrega для зрителя; масштабируемость отдачи и дешёвое cold-хранение исходников. Консистентность метрик и надёжность данных о просмотрах и QoS важны для биллинга и рекомендаций.

Этап 3. Границы системы и публичное API

Границы — сервисы загрузки/обработки/хранения/доставки видео, а также API для клиентов и админов. Публичный контракт включает загрузку (multipart / resumable upload), запрос метаданных и статусов обработки, запрос манифеста потоков HLS/DASH, получение статических ресурсов (thumbnails, captions), просмотр счётчиков и отправка телеметрии (player events). API для бек-офиса предоставляет операции для модерации, управления encoding profiles, lifecycle policies и получения аналитики.

Ключевая инвариантность API: клиент не зависит от внутренней реализации транскодирования или CDN; он получает m3u8/DASH manifest и готов к ABR-плееру. Для загрузки поддерживается resumable uploads с uploadId — это упрощает обработку нестабильных сетей.

Этап 4. Проектирование: happy path, exceptional flows и основные компоненты

Happy path загрузки: пользователь отправляет исходный файл на Upload Gateway. Gateway аутентифицирует, проверяет квоты и инициирует chunked/streaming загрузку в объектное хранилище (S3-like), возвращая uploadId. После загрузки manifest (metadata) помещается в job-queue для encoding pipeline. Worker подхватывает задачу, извлекает исходник, выполняет транскодирование в набор битрейтов и разрешений, генерирует сегменты и manifest’ы для HLS и/или DASH, создаёт thumbnails и субтитры (если требуется), а затем выгружает результаты в объектное хранилище, обновляет metadata store и помечает video «готово».

Воспроизведение: клиент запрашивает manifest и начинает получать сегменты через CDN. Плеер поддерживает ABR: на основе скорости сети и буфера выбирается подходящий битрейт. Для минимизации startup latency применяется быстрый первоначальный профиль (low-res first) и HTTP/2/3 prefetching. CDN обслуживает горячие части контента; origin хранится в S3 и используется при cache miss.

Ключевые компоненты формируются естественным образом: Upload Gateway (auth, quota), Object Storage (raw + encoded assets), Encoding Pipeline (job queue, workers, transcoders), Manifest/Segment Store (обычно same object storage with structured paths), CDN (edge nodes, cache policies), Metadata Service (video metadata, status, thumbnails, captions, access control), Playback Service (tokenized URLs, signed URLs, DRM gateway), Telemetry Pipeline (player events → ingestion → analytics), Moderation Service (automated checks: copyright/visual detectors + human review), and Recommendation Service (lightweight for YouTube Lite).

Exceptional flows: транскодер падает/ошибается → job возвращается в очередь и выполняется retry с backoff; исходник повреждён → пометить failed и уведомить uploader; spike загрузок → elastic scaling workers; CDN cache miss при первом просмотре → origin-read cost и потенциальное latency bump; нарушение прав → take-down через admin API и invalidation в CDN и storage.

Особенности с учётом live vs VOD: live требует низкой end-to-end latency, incremental chunking, специализированных transcoders (实时分发) и обычно отдельного pipeline; в этом разборе лишь отмечаем, что live меняет требования к pipeline и CDN (chunk-oriented low-latency delivery, WebRTC/LL-HLS).

Этап 5. Концептуальная архитектура и целостный обзор

В центре архитектуры лежит объектное хранилище для исходников и артефактов транскодирования, job-queue (Kafka/SQS) и серия worker-кластов для CPU/GPU-транскодинга. Upload Gateway принимает файлы и публикует задачи; Encoding Workers выполняют транскод, упаковку в сегменты и генерацию manifest’ов; результаты хранится в объектном хранилище по структуре виде/ resolution/bitrate/segmentIndex; Metadata Service хранит ссылки на manifest’ы и служит единой точкой запроса для клиента; CDN кэширует сегменты и manifest’ы, снижая нагрузку на origin; Telemetry собирает player events и feed’ит аналитические и recommendation pipelines.

Cache-invalidation для take-down/DMCA осуществляется через CDN purge API и пометки в Metadata Service. Для доставки защищённого контента используется signed URL + short TTL и, при необходимости, DRM gateway, выдающий лицензию.

Важный деталь: манифесты и сегменты должны быть организованы таким образом, чтобы позволять частичную замену/обновление (например, обновить один bitrate не затрагивая другие). Также хранение исходников и encoded assets разделяются lifecycle политикой: исходник можно держать в hot хранении некоторое время, затем архивировать.

Этап 6. Технологии и sizing

Технологический стек обычно включает: объектное хранилище (S3 или S3-compatible) для стабильного долговременного хранения; очередь заданий (Kafka, SQS) для coordinate encoding jobs; контейнеризированные encoding workers (FFmpeg-основа, hardware accel via NVENC/VideoCore/TPU) управляемые автоскейлингом; CDN (Cloudflare, Fastly, AWS CloudFront или свой CDN) для глобальной доставки; metadata store (NoSQL — DynamoDB/Cassandra или RDBMS для транзакционных требований); telemetry/analytics (Kafka→Flink/Beam→ClickHouse/BigQuery); signer/service for secure URLs; и опционально DRM providers.

Sizing делается через входные метрики: ожидаемая частота загрузок, средний размер исходника, среднее число просмотров в сутки, медианная длительность просмотра, процент пиковых событий. Примерный расчёт: при 1000 загрузок/сутки и среднем исходнике 500 MB объём исходников ≈ 0.5 TB/сутки. Транскодирование требует CPU/GPU ресурса, пропорционального aggregate encode time. Если средний encode на одном worker занимает 30 минут (CPU-bound), и требуется обрабатывать 1000 задач/сутки равномерно, нужен пул из порядка 30 workers одновременно работающих (30 min per job → 48 jobs/day per worker → ~21 workers; запас 2×→~42). Для пикового поведения важен autoscaling. Хранение сегментированных файлов требует учитывать мультибитрейты: если исходник 500 MB, encoded outputs могут суммарно быть 50–150% от исходника в зависимости от профилей и сегментации; нужно оценивать replication и CDN cache hit ratio.

ABR и плеер: выбирать HLS (в широкой поддержке) и/или MPEG-DASH; сегменты маленького размера (2–4 s) уменьшают startup latency и улучшают адаптации, но увеличивают overhead запросов; trade-off выбирается в зависимости от target devices.

Экономические соображения: CDN cost dominates delivery; origin bandwidth и storage — вторичные. TTL и cache-control играют роль: long cache headers для сегментов, если нет DRM или частых инсертных изменений; для платного/личного контента используют signed URLs с коротким TTL.

Этап 7. Расширения и эксплуатационные аспекты (рекомендации поверхностно)

Рекомендации и personalization. Для YouTube Lite достаточно простого рекомендационного слоя: candidate generation via popularity signals (recent views, trending), basic collaborative filtering (user history → nearest neighbours) и content-based boosting (same tags, creator). Pipeline: player events → ingestion → feature store → offline model training → online serving via feature cache + lightweight ranker. Тяжёлые модели выполняются офлайн и результаты кешируются в per-video / per-user buckets.

Мониторинг и SRE. Ключевые метрики: startup latency p50/p95/p99, time-to-first-byte for manifest and first segment, cache hit ratio at CDN, encode queue depth, failed encodes, storage growth, bandwidth cost, QoE metrics (rebuffer rate, average bitrate). Алерты на резкие изменения QoE и падение CDN hit rate. Chaos testing encoding pipeline и CDN purge/responsiveness.

Контент-безопасность и модерация. Автоматическая фильтрация (специализированные детекторы для аудио/видео), human review pipelines, takedown flows с атомарной инвалидацией manifest и purge CDN, и audit trail. Для правообладателей интеграция fingerprinting/ContentID.

Особые случаи. Для live streaming потребуются low-latency ingest (RTMP/WeBRTC), chunking с минимальными сегментами, специализированные packers; для VR/360 и больших разрешений нужны иные encoding профили и CDN-настройки (edge-caching с поддержкой byte-range).

Distributed Task Queue (как Celery / Kafka Consumer System)

Отложенные задачи, ретраи, DLQ.

Этап 1. Постановка задачи и контекст

Интервьюер ставит задачу: спроектировать распределённую систему для обработки асинхронных задач. Система должна принимать задачи от различных сервисов и пользователей, обрабатывать их с возможностью отложенного запуска и повторных попыток при сбоях, гарантировать доставку и порядок выполнения в рамках потребностей приложения, поддерживать DLQ (Dead Letter Queue) для задач, которые не удалось обработать, и обеспечивать наблюдаемость и мониторинг. Нефункциональные требования включают горизонтальную масштабируемость (обработка миллионов задач в сутки), высокую доступность и устойчивость к сбоям отдельных компонентов, возможность приоритизации задач, эффективность хранения и доставки сообщений, а также контроль количества повторных попыток и backoff стратегий. После объявления контекста интервьюер молчит, кандидат переходит к уточнению требований.

Этап 2. Формализация требований и уточняющие вопросы

Кандидат задаёт уточняющие вопросы: какие гарантии доставки нужны — at-most-once, at-least-once или exactly-once; допустим ли reordering задач; требуется ли поддержка отложенных задач на миллисекундном или секундном уровне; сколько разных типов задач и их приоритетов; какова допустимая задержка между постановкой и выполнением задачи; нужен ли persistence задач на диске или допустим in-memory queue; допустим ли потерянный task при полном крахе системы; какая политика для DLQ — фиксированное количество ретраев или динамическая.

Нефункциональные характеристики формулируются так: высокая доступность брокеров/очередей, масштабируемость обработчиков (worker nodes), устойчивость к spike нагрузкам, предсказуемость задержки выполнения задач, auditability (ведём метрики по успехам/ошибкам/retries).

Этап 3. Границы системы и публичный API

Границы системы включают API для продюсеров задач и сервисов-обработчиков:

Producer API: enqueue_task(task_payload, type, priority, schedule_time, max_retries), поддерживает синхронный/асинхронный ответ с task_id.

Consumer API: pull_task(worker_id, batch_size), acknowledge_task(task_id, status), nack_task(task_id, reason).

Admin API: inspect queues, DLQ, retry/failure policy, purge tasks, metrics (queue length, task success/failures).

Основной контракт: producer создаёт задачу, worker забирает, выполняет и подтверждает результат; при сбое задача может быть повторена или отправлена в DLQ.

Этап 4. Проектирование: сценарии, потоки данных и компоненты

Happy path: клиент создаёт задачу → очередь (broker) ставит её в очередь → worker забирает задачу → выполняет → подтверждает успешное выполнение → broker удаляет задачу.

Retry: если обработка завершается ошибкой, задача возвращается в очередь или отправляется в delay queue с backoff.

DLQ: после превышения max_retries задача помещается в DLQ для ручного или автоматического анализа.

Основные компоненты:

Producer/Task Client — формирует задачу и публикует в broker, опционально может подписываться на статус выполнения.

Broker / Message Queue — хранит задачи, управляет delivery semantics, поддерживает persistence (Kafka, RabbitMQ, Redis Streams). Broker шардируется по типу задач или key hashing для балансировки нагрузки.

Worker Nodes — забирают задачи из очереди, выполняют их, используют concurrency/async для высокой throughput. При падении worker задача возвращается в очередь.

Scheduler / Delay Queue — управляет задачами с отложенным запуском, поддерживает таймеры и приоритетные очереди.

DLQ Handler — обрабатывает задачи, которые не удалось выполнить после заданного числа retries.

Exceptional flows: broker недоступен → producer буферизует локально или fallback; worker падает во время выполнения → задача переходит на повторное выполнение; spike нагрузка → auto-scaling worker nodes; блокировка очереди/падение persistence → задачи остаются в commit log.

Архитектурные решения: partitioning (по task type или hash), idempotency (task_id уникальный для повторных delivery), backoff strategy (fixed, exponential, jitter), visibility timeout (чтобы unacknowledged tasks возвращались), monitoring & alerting (queue depth, retry count, failed tasks).

Этап 5. Концептуальная схема и целостный обзор

Целостно система выглядит как три слоя:

Producers: микросервисы, веб-клиенты, cron jobs. Публикуют задачи в broker.

Broker Layer: message queue / streaming system (Kafka/RabbitMQ/Redis Streams). Поддерживает persistence, partitions, priority queues, delay queues.

Workers: масштабируемые группы обработчиков, забирают задачи, выполняют, подтверждают результат. Используется backoff, retry и DLQ.

Дополнительно: scheduler/cron для отложенных задач, monitoring/metrics collector, DLQ analyzer, admin tools для ручного вмешательства.

Этап 6. Выбор технологий и sizing

Технологии:

Broker: Kafka (для high throughput, log-based persistence), RabbitMQ (AMQP, priority queues), Redis Streams (low-latency, simple tasks).

Workers: Celery + Python, or custom Go/Java consumers, с автошардингом и concurrency.

Delay queue / scheduler: Redis sorted sets, Kafka + scheduled jobs, RabbitMQ delayed messages.

DLQ: отдельная очередь или топик в Kafka для failed tasks.

Sizing: предположим 1M задач/сутки, средний task payload 1 KB.

Объём данных в broker ≈ 1 GB/day.

Worker throughput: если average task = 100ms, 1 worker = 10 tasks/sec → для 1M tasks/day (~12 tasks/sec average), достаточно 2–3 workers с запасом. Для spike нагрузки используется autoscaling.

Storage: если broker log retention = 7 дней, Kafka топик ~7 GB для persistence.

Для большого масштаба: sharding по task type или key hashing, replication factor ≥2 для HA, мониторинг lag и unacknowledged tasks, alert на превышение retry threshold.

Этап 7. Расширения и эксплуатация

Расширения:

Prioritization: отдельные priority queues, worker pools для high-priority tasks.

Rate limiting: ограничение на количество задач от одного producer.

Exactly-once semantics: идемпотентные task_id + deduplication на worker side.

Observability: метрики по выполнению задач, retries, DLQ, latency distribution.

Fault tolerance: multi-region brokers, persistent queues, auto-retry.

Backpressure: если очередь растёт → throttling producers или динамическое масштабирование workers.

Эксплуатация: мониторинг lag, queue depth, DLQ growth, failed tasks, autoscaling workers, SLA по latency обработки, алерты на превышение retries.

Design a Web Crawler

Обход страниц, распределение нагрузки, хранение результатов.

Этап 1. Постановка задачи и контекст

Интервьюер формулирует задачу: спроектировать веб-краулер, который обходит страницы Интернета и сохраняет их содержимое для последующей индексации или анализа. Система должна масштабироваться на миллионы и миллиарды страниц, обеспечивать распределённый обход без перегрузки сайтов, поддерживать приоритетное сканирование, следовать правилам robots.txt, обрабатывать динамический контент (JS-rendered pages), и эффективно хранить результаты. Нефункциональные требования включают высокую производительность обхода, fault tolerance, управление очередями URL, дедупликацию, поддержание politeness (ограничение числа запросов к одному домену в единицу времени) и мониторинг. После постановки контекста интервьюер молчит, инициатива переходит к кандидату.

Этап 2. Формализация требований и уточняющие вопросы

Кандидат уточняет: требуется ли full web (весь Интернет) или ограниченный crawl (например, news sites, заданный набор доменов); какая глубина обхода (BFS vs DFS); допустимая задержка между обнаружением страницы и её обработкой; как часто нужно обновлять уже обработанные страницы; формат хранения контента (HTML, текст, метаданные, ссылки, скриншоты); поддержка мультиязычных сайтов; политика обхода ошибок (HTTP 5xx, timeout); SLA по freshness.

Ключевые архитектурные характеристики: high throughput, scalability (горизонтальное добавление crawlers), politeness, data consistency для очередей URL и хранилища контента, fault tolerance и возможность восстановления после падений, мониторинг и auditability.

Этап 3. Границы системы и публичный API

Граница системы — набор сервисов, принимающих URLs, управляемых scheduler, хранение страниц, API для мониторинга и управления.

Публичный API:

enqueue_url(url, priority, metadata) — добавление нового URL в crawl queue.

fetch_next_urls(batch_size, domain_constraints) — worker забирает URLs для обхода с учётом politeness.

store_page(url, content, metadata) — сохранение результата обхода.

admin APIs — stats по crawler’ам, очередь, DLQ для неудачных fetch’ей, управление политиками (robots.txt, crawl delay).

Контракт обеспечивает идемпотентность: URL не должен обрабатываться повторно без нужды; результаты fetch’а должны сохраняться атомарно с метаданными.

Этап 4. Проектирование: сценарии, потоки данных и компоненты

Happy path: Scheduler выбирает URL → распределяет его на available worker → worker делает HTTP request → парсит HTML → извлекает ссылки и контент → сохраняет результат в хранилище → новые ссылки возвращает в scheduler → повторение.

Exceptional flows: HTTP ошибки/timeout → retry с backoff → после max_retries в DLQ; блокировка сайта (robots.txt) → skip; rate-limit на домен → delay queue; падение worker → task возвращается в очередь.

Компоненты:

URL Frontier / Scheduler — центральный компонент, управляющий очередями, politeness, приоритетами и дедупликацией. Может быть распределённым для горизонтальной масштабируемости.

Workers / Fetchers — HTTP-клиенты, забирающие страницы, парсеры, извлекают ссылки и метаданные. Worker pool масштабируется горизонтально.

Content Storage — распределённое хранилище HTML/текст/медиа (S3-like), с возможностью индексации и хранения метаданных (URL, crawl time, HTTP headers).

URL Deduplication / Bloom Filters — предотвращение повторного обхода одинаковых URL; хранится на fast-access storage (Redis, Cassandra).

Delay Queues / Politeness Enforcer — контролирует частоту обращений к одному домену; может реализовываться через per-domain timers.

Retry & DLQ — задачи с ошибками помещаются в DLQ после заданного числа попыток.

Monitoring / Metrics — очередь на обработку, latency fetch, success rate, error rate, politeness violations.

Обработка динамического контента: JS-rendered pages могут обрабатываться через headless браузеры (Puppeteer, Playwright) или lightweight JS engines; trade-off: высокая латентность, но больше coverage.

Этап 5. Концептуальная схема и целостный обзор

Система делится на слои:

Scheduler / URL Frontier — распределённый, хранит очереди и приоритеты, управляет politeness и дедупликацией.

Worker Layer — масштабируемые fetchers, делают HTTP запросы, парсят страницы, извлекают ссылки, сохраняют content + metadata.

Storage Layer — распределённое хранение контента, метаданных, индексация для дальнейшего анализа или поиска.

Delay / Retry / DLQ Layer — управляет отложенными задачами и ошибками.

Monitoring / Analytics — метрики работы системы и качества crawl.

Поток данных: Scheduler → Worker → Storage → Scheduler (для новых ссылок). Для politeness Scheduler использует per-domain queues и timers; для масштабирования Frontier распределяется по шардированию доменов или хешированию URL.

Этап 6. Выбор технологий и sizing

Технологии:

Message Queue / Scheduler: Kafka, RabbitMQ, Redis Streams для распределённого распределения URL.

Workers: контейнеризированные fetchers на Go/Python/Java, headless browsers для JS.

Storage: S3/MinIO для raw content, Cassandra/HBase/Elasticsearch для метаданных и быстрых lookup.

Deduplication: Bloom Filter в Redis/Redis Cluster или Cassandra; scalable filters на уровне shards.

Retry & DLQ: очередь Redis/Kafka для failed fetches.

Sizing:

Допустим, 1B страниц в базе, средний HTML 50 KB → raw storage ~50 TB.

Для throughput 1M pages/day: ~11.5 pages/sec; при среднее fetch 500ms → ~6 workers/worker pool, с запасом 2× → 12 fetchers.

Politeness: max 1 request/sec/domain, Scheduler управляет rate-limit per domain.

Dedup: Bloom filter для 1B URL с false positive 1% → ~1.2 GB RAM; для распределения shard’ы.

Для больших масштабов: Frontier распределён по доменам, Workers горизонтально масштабируемы, Storage tiering (hot/cold), CDN для часто запрашиваемых страниц, batching fetch results для экономии IOPS.

Этап 7. Расширения и эксплуатационные аспекты

Возможные расширения:

Prioritization / Relevance: crawl pages based on importance, PageRank or domain weight.

Incremental crawl / freshness: повторное посещение страниц с заданной частотой.

Politeness policies: динамический crawl-delay per domain, adaptive backoff.

Dynamic content handling: headless browsers, AJAX crawling.

Content parsing: extract metadata, structured data (JSON-LD, microdata), media.

Monitoring / Alerting: latency, error rates, politeness violations, queue backlog.

Fault tolerance: multi-region Frontier, persistence for URL queues, checkpointing for resuming after crash.

Design a Payment System

Идемпотентность, транзакции, безопасность, подписания запросов.

Этап 1. Постановка задачи и контекст

Интервьюер формулирует задачу: спроектировать систему для обработки финансовых транзакций между пользователями и/или сервисами. Система должна позволять инициировать платежи, проверять баланс, проводить трансферы, обеспечивать идемпотентность операций и атомарность списания и зачисления средств, поддерживать безопасность и шифрование запросов, а также логировать операции для аудита. Нефункциональные требования: высокая доступность, консистентность данных, защита от двойного списания (double-spend), масштабируемость по числу пользователей и объёму транзакций, низкая латентность подтверждения платежей и надежная обработка отказов. После постановки контекста интервьюер молчит.

Этап 2. Формализация требований и уточняющие вопросы

Кандидат уточняет:

Тип платежей: P2P, P2M, B2B, кэш-аут?

Обязательная строгая консистентность или eventual consistency допустима в некоторых сценариях?

Нужно ли поддерживать multi-currency и конвертацию?

Какие SLA по latency: мгновенное подтверждение vs batch processing?

Какие требования к идемпотентности: на уровне request-id или transaction-id?

Требования к безопасности: шифрование, подпись, токенизация, PCI DSS совместимость?

Что делать с отказами: retry, compensation transactions?

Нефункционально фиксируются ключевые характеристики: atomicity, consistency, isolation, durability (ACID), idempotency, security, high availability, auditability.

Этап 3. Границы системы и публичный API

Границы системы включают публичный API для клиентов и внутренних сервисов, backend платёжного движка, интеграцию с банками/платёжными шлюзами, внутреннее хранилище транзакций и баланс-сервис.

Пример API:

POST /payments: инициирует платеж с параметрами (sender, receiver, amount, currency, idempotency_key).

GET /payments/{id}: проверка статуса платежа.

POST /accounts/{id}/topup: пополнение баланса.

POST /accounts/{id}/withdraw: вывод средств.

GET /accounts/{id}/balance: получение текущего баланса.

Admin API: просмотр логов, rollback, reconciliation, мониторинг.

Контракт: каждый request с idempotency_key гарантирует, что повторный вызов не создаст двойную транзакцию.

Этап 4. Проектирование: сценарии, потоки данных и компоненты

Happy path: пользователь инициирует платеж → API валидирует request и idempotency_key → проверка баланса → блокировка суммы на счёте отправителя → запись транзакции в транзакционный журнал (commit log) → выполнение списания и зачисления → уведомление клиента → обновление статуса.

Exceptional flows:

Недостаточно средств → отклонение, логирование.

Сбой в процессе списания → retry с idempotency_key.

Сбой при обновлении баланса получателя → compensation transaction.

Дублированный запрос → обработка через idempotency_key.

Основные компоненты:

API Gateway — аутентификация, валидация, rate limiting, подпись/токенизация запросов.

Payment Service / Transaction Engine — core logic: atomic debit/credit, балансировка нагрузки, идемпотентность, retry и compensation.

Account / Ledger Service — хранение актуального баланса и истории транзакций; реализуется как ACID DB или с транзакционной обработкой через Event Sourcing.

Transaction Log / Audit Trail — immutable журнал всех операций, необходим для reconciliation и compliance.

Notification Service — уведомление пользователей о статусе платежей.

External Gateway Integrations — связь с банками, платёжными шлюзами, обработка callback’ов.

Идемпотентность: idempotency_key хранится вместе с записью транзакции; повторный request проверяет наличие ключа, и если транзакция уже выполнена, возвращает текущий результат.

Безопасность: HTTPS/TLS, подпись запросов HMAC или JWT, токенизация чувствительных данных, PCI DSS совместимость для хранения платёжной информации, ограничение доступа через RBAC и audit logging.

Этап 5. Концептуальная схема и целостный обзор

Архитектура:

API Gateway принимает и валидирует запросы, проверяет подписи.

Payment Engine получает запрос, проверяет баланс, резервирует средства и записывает транзакцию в Transaction Log.

Ledger / Account DB применяет изменения атомарно (например, в ACID-базе или через Event Sourcing с атомарными projections).

Notification Service сообщает клиентам результат.

External Payment Gateways подключаются через асинхронные callback’и и подтверждают завершение платежей.

Данные движутся в pipeline: Request → Validation → Ledger/Transaction Engine → Commit → Notification. При сбоях используется retry, DLQ и compensation.

Этап 6. Выбор технологий и sizing

Технологии:

DB: PostgreSQL/MySQL для ACID, либо распределённые NewSQL (CockroachDB, Spanner) для глобального масштаба.

Transaction Log: Kafka для событийной модели, immutable journal для audit & recovery.

Payment Engine / Microservices: Go/Java/Python с поддержкой concurrency и worker pools.

API Gateway: Nginx/Envoy + JWT/HMAC validation.

Caching: Redis для hot balances и rate-limiting.

Security: TLS, HSM для ключей, tokenization service.

Sizing:

Для 1M пользователей, 10k tx/day, средний payload 1 KB → ~10 MB/day журнал транзакций; 30 days retention → 300 MB; легко управляется любой SQL/NoSQL хранилищем.

Throughput: 10k tx/day ≈ 0.1 tx/sec average, пиковый load 50 tx/sec → 3–5 worker nodes с резервом.

Для глобальной системы требуется распределённая ACID DB с sharding по userId или ledgerId, replication factor ≥2.

Этап 7. Расширения и эксплуатационные аспекты

Multi-currency и FX: отдельные ledger per currency, конверсия с актуальными курсами.

Fraud detection: интеграция с ML/Rule engine для аномалий.

Batch processing: payroll, массовые выплаты.

Reconciliation: сверка транзакций с external gateways и internal ledgers.

Monitoring & SLA: latency, failed transactions, retry rate, balance correctness.

High availability: multi-region deployment, leader election for transaction engine.

Compliance: immutable logs, retention policies, audit reports.

E-commerce Checkout System

Корзина, ордеринг, инвентаризация, платежи.

Этап 1. Постановка задачи и контекст

Интервьюер формулирует задачу: спроектировать систему оформления заказов для интернет-магазина. Система должна обеспечивать работу корзины, формирование заказов, проверку наличия товаров на складе (инвентаризация), интеграцию с платёжной системой, поддержку скидок, налогов и доставки, а также уведомления пользователя о статусе заказа. Нефункциональные требования включают высокую доступность, согласованность данных о товарах и остатках, предотвращение overselling, масштабируемость по числу пользователей и заказов, низкую задержку оформления заказа и поддержку отказоустойчивости. После постановки контекста интервьюер замолкает, кандидат переходит к уточнению деталей.

Этап 2. Формализация требований и уточняющие вопросы

Кандидат уточняет:

Нужно ли поддерживать multi-currency и multi-warehouse?

Какова допустимая консистентность между корзиной и складом — строгая или eventual consistency?

Какие сценарии скидок и акций нужно поддерживать: купоны, bundle, loyalty?

Поддержка частичных оплат или отложенных платежей?

Как управлять отменой и возвратами?

SLA по latency checkout: мгновенное подтверждение или batch?

Политика при падении внешней платёжной системы.

Ключевые архитектурные характеристики: atomicity при создании заказа, consistency запасов, high throughput, scalability, fault tolerance, idempotency для повторных запросов, auditability и безопасность платежей.

Этап 3. Границы системы и публичный API

Границы системы охватывают корзину, checkout сервис, управление заказами, интеграцию с платёжными провайдерами и управление запасами.

Публичный API:

Cart API: add_item(userId, productId, quantity), remove_item, get_cart, update_quantity.

Checkout API: create_order(cartId, payment_info, shipping_info), confirm_payment(orderId), cancel_order(orderId).

Inventory API: check_stock(productId, quantity), reserve_stock(orderId), release_stock(orderId).

Order API: get_order_status(orderId), list_orders(userId).

Admin API: manage inventory, apply discounts, audit logs.

Контракт: API должен обеспечивать идемпотентность при повторных вызовах (например, повторный create_order с тем же requestId не создаёт дублированный заказ).

Этап 4. Проектирование: сценарии, потоки данных и компоненты

Happy path: пользователь добавляет товары в корзину → инициирует checkout → система проверяет наличие товаров → резервирует stock → создаёт запись заказа → инициирует платёж → подтверждает платёж → подтверждает заказ и уведомляет пользователя → обновляет stock и accounting.

Exceptional flows:

Недостаточно товара → отказ с сообщением пользователю.

Платёж отклонён → заказ остаётся в pending, stock возвращается.

Сбой в резервировании stock → retry или отказ.

Дублированный запрос create_order → обработка через idempotency_key.

Компоненты:

Cart Service — хранит временные корзины, поддерживает session, кеширование, idempotent операции.

Inventory Service — проверка и резервирование stock, поддержка concurrency и транзакционность, репликация для HA.

Order Service — создание заказа, управление статусами, интеграция с Inventory и Payment Service.

Payment Service — безопасная интеграция с платёжными шлюзами, подтверждение транзакций, retry и idempotency.

Notification Service — уведомления о статусе заказа.

Discount / Pricing Service — вычисляет финальную цену, применяет купоны и акции.

Архитектурные решения:

Atomicity: при создании заказа важна транзакция между Order и Inventory (можно реализовать через distributed transaction / saga / two-phase commit).

Idempotency: create_order с уникальным requestId.

Concurrency: оптимистическая блокировка stock или pessimistic lock при high contention.

Resilience: retry и compensating transactions при сбоях в Payment Service.

Этап 5. Концептуальная схема и целостный обзор

Система делится на слои:

Frontend / API Gateway — принимает запросы от клиентов, аутентифицирует, валидирует и применяет idempotency.

Cart & Order Services — управляют корзинами, заказами, резервированием stock и статусами.

Inventory Service — консистентное хранилище остатков, интеграция с warehouses.

Payment Service — платёжный движок с idempotent API и retry.

Discount / Pricing Service — вычисление финальной суммы, налоги, акции.

Notification & Audit — уведомления, логирование, мониторинг.

Поток данных: Cart → Checkout → Inventory reservation → Order creation → Payment → Notification → Commit stock changes.
Для fault tolerance используются retry, DLQ и compensating transactions.

Этап 6. Выбор технологий и sizing

Технологии:

DB: PostgreSQL/MySQL или распределённые ACID NewSQL (CockroachDB, Spanner) для Order + Inventory.

Caching: Redis/Memcached для Cart и hot-stock.

Message Queue: Kafka/RabbitMQ для интеграции между сервисами и событийной обработки.

Payment Gateway: интеграция с внешними провайдерами.

Notification: push/email/queue.

Sizing:

100k пользователей, средний cart 5 товаров, 10k заказов/день.

Stock updates: 50k ops/day, low-latency queries → Redis hot cache.

Orders: 10k/day → 2–3 Order worker nodes, queue-based processing.

Inventory: масштабируется по productId, репликация для HA.

Trade-offs:

Strong consistency на stock vs high throughput — можно использовать optimistic locking + compensating transactions.

Distributed transaction сложны на scale → Saga pattern предпочтительнее.

Этап 7. Расширения и эксплуатационные аспекты

Multi-warehouse & fulfillment: распределение stock по локациям.

Partial shipments: split order по availability.

Flash sales / spikes: rate-limiting, queueing и priority handling.

Audit & compliance: immutable logs, monitoring.

Discount & loyalty programs: сложные правила применения.

Idempotent checkout: защищает от повторных кликов или network retries.

Monitoring & SLOs: latency checkout, stock reservation failures, payment errors.

Design a Notification System (email + push + SMS)

Ротация каналов, очереди, массовая доставка.

Этап 1. Постановка задачи и контекст

Интервьюер объявляет задачу: спроектировать систему уведомлений, которая поддерживает несколько каналов доставки — email, push, SMS. Система должна обеспечивать массовую рассылку уведомлений, при этом управлять приоритетами и ротацией каналов (fallback: если push недоставлен, отправить SMS), гарантировать высокую доставляемость, обработку отказов и retry, а также мониторинг и аналитическую отчётность. Нефункциональные требования: масштабируемость до миллионов уведомлений в сутки, низкая латентность доставки для критичных уведомлений, устойчивость к пиковым нагрузкам (flash campaigns), идемпотентность отправки, fault tolerance и observability. После постановки контекста интервьюер замолкает.

Этап 2. Формализация требований и уточняющие вопросы

Кандидат уточняет:

Какие типы уведомлений: transactional (OTP, alerts) vs marketing (promotions)?

SLA по latency для каждого канала?

Поддержка персонализации: template engine, placeholders?

Ротация каналов: fallback при failure, or prioritized sending?

Требования к retry: количество попыток, backoff strategy?

Политика rate limiting для SMS / email / push?

Нужно ли отслеживать opens/clicks/delivery status?

Ключевые нефункциональные характеристики: high throughput, scalability, reliability, idempotency, low latency, observability, fault tolerance.

Этап 3. Границы системы и публичное API

Границы системы включают публичные API для внутренних сервисов и админ-панели, обработку очередей уведомлений и взаимодействие с внешними каналами (SMTP, push providers, SMS gateways).

Пример API:

POST /notifications: создать уведомление с параметрами (recipient, channel(s), templateId, priority, metadata).

GET /notifications/{id}/status: получить статус доставки.

Admin API: просмотр очередей, retry, отмена, статистика delivery.

Контракт: один notification_id = одна логическая цель; повторные вызовы с тем же notification_id должны быть идемпотентны.

Этап 4. Проектирование: сценарии, потоки данных и компоненты

Happy path: сервис создаёт уведомление → enqueue в centralized notification queue → dispatcher забирает уведомление → выбирает канал и template → отправляет через provider → обновляет status → логирование и метрики.

Fallback / channel rotation: если push fails (undelivered) → enqueue retry на SMS → при SMS failure → enqueue retry на email (опционально).

Exceptional flows:

Недоступность внешнего провайдера → retry с backoff.

Ограничение rate limit → delay queue.

Повторное получение того же notification_id → skip / return cached status.

Template rendering fail → логирование, alert, skip delivery.

Основные компоненты:

API Gateway / Notification Service — принимает уведомления, валидирует, применяет idempotency, enqueues.

Central Queue / Message Broker — Kafka/RabbitMQ/Redis Streams для распределённой обработки.

Dispatcher / Worker Pool — забирает уведомления, выбирает канал и template, вызывает provider API.

Channel Providers — SMTP/email service, push provider (Firebase/APNs), SMS gateway.

Retry & DLQ — задачи, не доставленные после N попыток, помещаются в DLQ для анализа.

Monitoring / Analytics — delivery rate, latency, errors, opens/clicks.

Ротация каналов и fallback: реализуется в dispatcher с state machine per notification. При failure → next channel → retry → update status.

Этап 5. Концептуальная схема и целостный обзор

Система делится на слои:

Producer/API layer — принимает уведомления, enqueues с idempotency key и priority.

Queue / Broker — хранение и шардирование уведомлений по каналам и приоритетам, поддержка delay queues.

Dispatcher / Worker Layer — канал-агностичные workers, выбирают канал и template, выполняют отправку, обрабатывают retries и fallback.

Provider Layer — интеграция с внешними email/SMS/push провайдерами.

Analytics & Monitoring — метрики по доставке, latency, retry rate, failed notifications.

DLQ / Retry Management — отдельные очереди для failed notification, возможность ручного вмешательства.

Поток данных: Notification request → Queue → Dispatcher → Channel provider → Update status → Analytics. Для масштабирования queue шардируется по recipient hash / channel type.

Этап 6. Выбор технологий и sizing

Технологии:

Queue: Kafka для high throughput, RabbitMQ или Redis Streams для low-latency.

Workers: контейнеризированные dispatchers на Go/Java/Python, горизонтально масштабируемые.

Template engine: Handlebars, Jinja2, или proprietary templating service.

Provider integration: SMTP servers, Firebase Cloud Messaging, APNs, Twilio/Plivo для SMS.

Monitoring: Prometheus/Grafana, ELK stack или ClickHouse для аналитики.

DLQ & Retry: отдельная топика/queue, retry policy с exponential backoff.

Sizing:

1M notifications/day, смешанный канал: 50% push, 30% email, 20% SMS.

Среднее время доставки push ≈ 1s, email ≈ 5s, SMS ≈ 2s.

Throughput requirement ~12 notifications/sec average, peak 500/sec → horizontal scaling of dispatcher pool (20–30 workers per channel type).

Queue retention: 7 days for retry and monitoring.

Analytics storage: aggregated metrics ~10 MB/day, raw logs ~100 MB/day → manageable with Kafka + ClickHouse.

Trade-offs: для критичных notifications (OTP, alerts) priority queue; marketing notifications can be batched for cost efficiency. Retry и DLQ позволяют выдерживать SLA при отказах провайдера.

Этап 7. Расширения и эксплуатационные аспекты

Personalization: dynamic templates, user preferences for channel.

Rate limiting & throttling: per channel, per recipient, global daily cap.

Batching: объединение маркетинговых сообщений для экономии SMS/email cost.

Monitoring & alerting: failed deliveries, latency spikes, retry saturation.

High availability: multi-region queues, autoscaling dispatcher pool.

Audit & compliance: immutable logs, retention policies.

Feedback loop: opens/clicks/events feed into recommendation engine or analytics.

Real-Time Analytics Dashboard

Агрегации, окна, стрики, кластер Kafka/ClickHouse.

Этап 1. Постановка задачи и контекст

Интервьюер ставит задачу: спроектировать систему для отображения реального времени метрик и событий на дашборде. Система должна обрабатывать события с различных источников (например, веб-сайт, мобильные приложения, IoT), агрегировать их по различным измерениям (user, region, product, event type), строить скользящие окна (tumbling, sliding), поддерживать стриминговые и исторические данные, обеспечивать низкую задержку обновления (sub-second – секунды), и масштабироваться на миллионы событий в минуту. Нефункциональные требования: high throughput, low latency, fault tolerance, горизонтальное масштабирование и возможность добавления новых источников без downtime. После постановки контекста интервьюер молчит.

Этап 2. Формализация требований и уточняющие вопросы

Кандидат уточняет:

Какие виды метрик: count, sum, average, unique users, percentiles?

Размер и количество окон: минутные, часовые, sliding?

SLA latency: обновление дашборда в реальном времени (1–2s) или near-real-time (10–30s)?

Историческое хранение: retention событий и агрегатов?

Количество источников событий и ожидаемый EPS (events per second)?

Требования к консистентности: точное vs approximate aggregates (HyperLogLog, sketches)?

Нужно ли поддерживать ad-hoc queries или только predefined dashboards?

Нефункциональные характеристики: high throughput, low latency, scalability, fault tolerance, data retention, query flexibility.

Этап 3. Границы системы и публичное API

Границы включают источники событий, стриминговый слой, слой хранения и API/сервис визуализации.

Публичное API:

POST /events: ingestion событий с payload (event_type, userId, timestamp, metadata).

GET /dashboard/{metric}: возвращает агрегированные данные для фронтенда.

Admin API: управление retention, источниками, схемой событий, мониторинг throughput.

Контракт: события не теряются; каждый event_id идемпотентен; агрегаты должны быть согласованы с окном времени.

Этап 4. Проектирование: сценарии, потоки данных и компоненты

Happy path: источник отправляет событие → Kafka topic (partitioned by key) → Stream Processor (Flink / Spark Streaming / ksqlDB) → вычисление агрегатов по нужным окнам → запись в ClickHouse (OLAP) → фронтенд дашборда делает запрос → визуализация в реальном времени.

Exceptional flows:

Kafka broker недоступен → producer retry + buffering.

Stream processor node падает → state recovery из checkpoint / Kafka offsets.

ClickHouse shard недоступен → fallback на реплику, частичная доставка.

Высокая нагрузка → autoscaling Stream Processor, горизонтальное масштабирование ClickHouse.

Основные компоненты:

Event Producers — приложения, сервисы, IoT-устройства.

Message Broker / Event Bus — Kafka, sharding и partitioning по ключу (userId, event_type).

Stream Processing / Aggregation — Flink, Spark Streaming, ksqlDB, выполняет windowed aggregations, counts, sums, averages, sketches.

State Store — RocksDB или встроенные state backend stream processors для windowed state.

OLAP Storage — ClickHouse, хранит агрегаты и исторические данные для ad-hoc queries.

Dashboard API / Frontend — REST или GraphQL API, обновление в режиме push (WebSocket) или pull.

Monitoring & Alerting — lag monitoring Kafka, stream processing throughput, ClickHouse query performance.

Windowing & aggregation: tumbling (fixed), sliding (overlapping), session windows. Для unique counts используют approximate structures (HyperLogLog, Count-Min Sketch) для уменьшения памяти.

Этап 5. Концептуальная схема и целостный обзор

Система делится на слои:

Producers — источники событий.

Event Bus / Kafka — durable, partitioned, fault-tolerant.

Stream Processor — windowed aggregation, stateful computation, checkpointing for recovery.

OLAP / ClickHouse — хранение агрегатов и исторических данных.

Dashboard API / Frontend — WebSocket/REST API для push обновлений.

Monitoring & Logging — lag metrics, throughput, error rate, alerts.

Поток данных: Event → Kafka → Stream Processor → Aggregates → ClickHouse → Dashboard. При high-throughput partitioning по userId/event_type + replication. Checkpoints обеспечивают recovery на случай сбоя.

Этап 6. Выбор технологий и sizing

Технологии:

Message Broker: Kafka cluster с replication factor ≥2, partitioning по event_type/userId.

Stream Processing: Flink, Spark Streaming, ksqlDB — поддержка stateful windowed aggregation, exactly-once semantics.

State Store: RocksDB или Flink state backend для windowed state.

OLAP Storage: ClickHouse, поддержка merge-tree, materialized views, retention policies.

Frontend / API: Node.js / Go / Python + WebSocket для realtime push.

Monitoring: Prometheus + Grafana, Kafka lag monitoring, Flink metrics.

Sizing:

EPS = 1M events/sec, 100 bytes per event → 100 MB/sec ingestion.

Kafka: 100 partitions, replication factor 3 → устойчивость и throughput.

Stream Processor: ~20 nodes, state backend для окон (~1GB per node).

ClickHouse: 5 shards × 2 replicas, хранение агрегатов + исторических данных (~1TB/month).

Dashboard: caching top metrics, WebSocket push, batch updates для heavy queries.

Trade-offs:

Строгая консистентность vs low-latency — выбирается exactly-once processing при critical metrics, approximate counts для high-cardinality metrics.

Materialized views в ClickHouse ускоряют queries, но увеличивают storage.

Этап 7. Расширения и эксплуатационные аспекты

Ad-hoc queries: поддержка OLAP-запросов поверх ClickHouse.

Multi-tenancy: разные dashboards для разных клиентов.

Alerts & thresholds: real-time anomaly detection на stream level.

Backfill & replay: возможность пересчитать агрегаты при schema change или баге.

High availability: multi-region Kafka + ClickHouse replication.

Monitoring: latency per aggregation, lag monitoring, state store size, dashboard refresh time.

Approximate algorithms: HyperLogLog, Count-Min Sketch для unique counts и heavy hitters.

API Rate Control / Throttling Gateway

API gateway, quotas, metering, JWT.

Этап 1. Постановка задачи и контекст

Интервьюер объявляет задачу: спроектировать API Gateway, который обеспечивает контроль частоты вызовов API, лимиты использования (quotas), метрики использования и аутентификацию с JWT. Система должна защищать backend-сервисы от перегрузки, обеспечивать fair usage для клиентов, поддерживать различные типы лимитов (per user, per API key, per endpoint), и быть масштабируемой на десятки тысяч запросов в секунду. Нефункциональные требования включают низкую задержку обработки запросов, горизонтальное масштабирование, консистентное применение лимитов, высокую доступность и observability. После постановки контекста интервьюер молчит.

Этап 2. Формализация требований и уточняющие вопросы

Кандидат уточняет:

Какие виды лимитов нужны: rate per second/minute/hour, burst limits, quotas per month?

Аутентификация: JWT с payload (userId, plan, scopes) или API keys?

Как обрабатывать превышение лимита: reject (429) или delay (leaky bucket)?

Нужно ли поддерживать глобальные лимиты или только per-user/client?

SLA latency: sub-ms для gateway или допускается ~10ms overhead?

Нужна ли интеграция с billing / plan enforcement?

Ключевые архитектурные характеристики: high throughput, low latency, consistency (в пределах одного bucket), scalability, fault tolerance, observability, idempotency для повторных запросов.

Этап 3. Границы системы и публичный API

Границы включают: API Gateway с rate control, бекенд-сервисы, метрики и админ-интерфейс.

Публичный API:

Incoming client API: проксирование запросов с JWT/ключом, rate limiting и quota enforcement.

Admin API: set/update rate limits, view metrics per user/endpoint, reset quotas.

Metrics API: expose usage stats for monitoring (requests/sec, quota usage, blocked requests).

Контракт: каждый request проверяется на rate limit; превышение лимита → 429 Too Many Requests; лимиты применяются консистентно на shard’ах.

Этап 4. Проектирование: сценарии, потоки данных и компоненты

Happy path: клиент делает request → API Gateway проверяет JWT → извлекает userId/plan → проверяет текущий rate/quotas → request allowed → proxy to backend → update counters → respond клиенту.

Exceptional flows:

JWT invalid → reject 401.

Quota exceeded → reject 429 + Retry-After header.

Gateway node failure → replication/consistent counters via distributed store.

Burst traffic → token bucket allows burst, leaky bucket smooths traffic.

Компоненты:

API Gateway / Proxy Layer — принимает и валидирует запросы, извлекает JWT, enforces rate limits.

Rate Limiter / Throttling Engine — per-user, per-endpoint, per-plan; реализует token bucket / leaky bucket; хранение state в Redis/etcd/Consul.

Distributed Counter Store — хранит текущее состояние лимитов (Redis cluster, DynamoDB, Cassandra).

Quota Manager / Plan Engine — хранит план пользователя и лимиты, применяет политики.

Metrics & Monitoring — количество запросов, blocked requests, usage per API key, latency.

Admin API — управление лимитами, просмотр usage stats.

Token Bucket vs Leaky Bucket:

Token Bucket: позволяет burst traffic до определённого размера, хорошо для планов с burst allowance.

Leaky Bucket: smooths traffic, предотвращает spikes на backend.

Distributed Limiter: shard по userId/API key, consistent hashing для масштабирования; при multi-node необходимо согласованное хранение токенов и atomic increment.

Этап 5. Концептуальная схема и целостный обзор

Система делится на слои:

Client Requests → JWT / API key authentication.

API Gateway → извлекает claims, проверяет лимиты, proxy to backend.

Rate Limiter → token/leaky bucket per user/endpoint/plan.

Counter Store → Redis cluster или DynamoDB, хранение state.

Metrics & Monitoring → Prometheus/Grafana для observability.

Admin Interface → управление лимитами, просмотр usage stats.

Поток данных: Request → Gateway → Rate Limiter → Counter Store → Backend.
Для horizontal scaling shard’ы распределяются по userId/API key, при необходимости используется replicated state для HA.

Этап 6. Выбор технологий и sizing

Технологии:

API Gateway: Envoy, NGINX, Kong, or custom Go/Java gateway.

Rate Limiter Storage: Redis Cluster (fast increment, TTL), optionally DynamoDB/Cassandra for distributed consistency.

Metrics: Prometheus + Grafana, ELK stack for logs.

JWT handling: HMAC or RSA validation, claims extraction in gateway.

Sizing:

Target: 100k requests/sec, average burst 10 req/sec/user.

Redis cluster: 20 shards, replication factor 2, ~100k active buckets per node.

Gateway nodes: 10–20 horizontally scalable instances behind load balancer.

Counters TTL: per-second/minute/hour window → ~5–10 MB per shard for active users.

Trade-offs:

Strong consistency vs low latency → for distributed token buckets можно использовать approximate counters or Lua scripts in Redis.

Burst handling → token bucket preferred; smoothing → leaky bucket.

Этап 7. Расширения и эксплуатационные аспекты

Dynamic plan updates: менять лимиты без downtime.

Global vs local limits: per-region or multi-region rate limiting.

Failover / HA: replicated counter store, gateway autoscaling.

Analytics: usage patterns, abusive clients, billing integration.

Backpressure: reject or queue requests on backend saturation.

Quota reset & rollover: daily/monthly quotas with TTL.

Security: protect rate limiter store from malicious manipulation, audit logs.

Design a Social Graph (friends / followers)

Хранение графов, рекомендации друзей.

Этап 1. Постановка задачи и контекст

Интервьюер объявляет задачу: спроектировать Social Graph для платформы с друзьями и подписчиками. Система должна хранить отношения пользователей (friend / follower), обеспечивать быстрый доступ к спискам друзей, mutual friends, followers/following, поддерживать поиск рекомендаций друзей и подписок, а также обеспечивать масштабируемость на миллионы и миллиарды пользователей. Нефункциональные требования включают высокую доступность, низкую задержку чтения списка друзей, горизонтальное масштабирование, быстрые query на рекомендации (friend-of-friend), и возможность batch или realtime обработки graph analytics. После постановки контекста интервьюер молчит.

Этап 2. Формализация требований и уточняющие вопросы

Кандидат уточняет:

Тип графа: directed (followers) vs undirected (friends)?

SLA на чтение списков друзей/followers: sub-second?

Частота обновления графа: высоконагруженные изменения (friend request, follow/unfollow)?

Поддержка рекомендаций: friend-of-friend, collaborative filtering, graph embeddings?

Ограничения на размер списка друзей/followers для одного пользователя?

Исторические данные: нужна ли версия графа в прошлых состояниях?

Ключевые характеристики: high throughput, low latency, horizontal scalability, consistency vs eventual consistency trade-offs, fault tolerance, query efficiency.

Этап 3. Границы системы и публичный API

Границы системы охватывают storage для графа, query layer для friends/followers, recommendation engine, и админ/metrics сервисы.

Пример API:

POST /users/{id}/follow/{targetId} — подписка на пользователя.

POST /users/{id}/friend/{targetId} — отправка / подтверждение friend request.

GET /users/{id}/friends — список друзей.

GET /users/{id}/followers — список подписчиков.

GET /users/{id}/recommendations — friend suggestions.

Admin API — просмотр статистики, управление rate limits, audit logs.

Контракт: операция friend/follow должна быть идемпотентной; удаление связи или unfollow обновляет graph state корректно.

Этап 4. Проектирование: сценарии, потоки данных и компоненты

Happy path: пользователь A отправляет запрос дружбы / подписки → система обновляет graph storage → обновляет индексы → при необходимости recompute recommendations → уведомление пользователя B.

Exceptional flows:

Конфликт friend request → обработка на уровне application layer.

Массовое добавление / удаление → batch update для efficiency.

Недоступность storage → fallback на read replicas с eventual consistency.

Recommendation engine heavy load → precompute embeddings / materialized views.

Основные компоненты:

Graph Storage — хранение связей; варианты: adjacency list (RDBMS, key-value), graph DB (Neo4j, JanusGraph), or wide-column stores (Cassandra/HBase).

Index Layer — быстрый lookup friends/followers; sharding по userId.

Recommendation Engine — friend-of-friend, collaborative filtering, graph embeddings, caching top-k recommendations.

API Layer — REST/GraphQL API с rate limiting и auth.

Notification Service — события friend request, new follower.

Analytics / Batch Processing — периодическое recompute сложных recommendations.

Storage trade-offs:

RDBMS — ACID, но масштабирование и join-heavy queries проблематично.

Graph DB — fast traversal, query-friendly, но сложнее масштабировать.

Wide-column / key-value — легко shard по userId, fast read of adjacency lists, eventual consistency.

Этап 5. Концептуальная схема и целостный обзор

Система делится на слои:

API Layer — принимает friend/follow actions, возвращает friend/follower lists, recommendations.

Graph Storage — adjacency list per user (key = userId, value = list of friends/followers).

Index / Cache Layer — Redis/Memcached для hot users, top friends, mutuals.

Recommendation Engine — friend-of-friend traversal, embeddings, collaborative filtering, batch precompute.

Notification Service — push/email alerts.

Analytics Layer — batch recompute for trending recommendations.

Поток данных: Action → Graph Storage → Index update → Recommendation Engine → Cache → API response → Notification.

Этап 6. Выбор технологий и sizing

Технологии:

Graph DB: Neo4j, JanusGraph (backend Cassandra/HBase) для traversal-heavy queries.

Wide-column / KV store: Cassandra, DynamoDB для adjacency lists per user.

Cache: Redis/Memcached для hot users, mutual friends, precomputed recommendations.

Batch processing / Analytics: Spark, Flink, Hadoop for graph embeddings, friend-of-friend counts.

API Layer: Go/Java/Python microservices, GraphQL or REST.

Sizing:

100M users, avg 200 friends → 20B edges.

Adjacency lists: 200 friends × 8B users = 1.6B entries, stored in Cassandra (~50–100 GB depending on replication).

Hot cache: top 10 friends per 1M active users → ~10M entries in Redis (~1–2 GB).

Recommendation engine: precompute daily embeddings, serve top-K recommendations from cache.

Trade-offs:

RDBMS: ACID, joins costly at scale.

Graph DB: fast traversal, harder horizontal scaling.

Wide-column + cache: high throughput reads, eventual consistency acceptable for recommendations.

Этап 7. Расширения и эксплуатационные аспекты

Friend suggestions: friend-of-friend, collaborative filtering, content-based, embeddings.

Multi-tier caching: hot users, cold users, precomputed recommendations.

Rate limiting: prevent spam friend requests or follow/unfollow abuse.

Monitoring & observability: edge-case queries, latency, hot shards.

High availability: multi-region replication, read replicas, failover.

Graph analytics: trending users, communities, influence scores.

Eventual consistency vs strong consistency: friend/follow writes consistent per shard, recommendation results can be eventually consistent.

Ride-Sharing System (Uber Lite)

Matching riders/drivers, геолокации, очереди.

Этап 1. Постановка задачи и контекст

Интервьюер объявляет задачу: спроектировать упрощённую версию сервиса ride-sharing. Система должна обеспечивать поиск и сопоставление водителей и пассажиров, учитывать геолокацию, поддерживать очереди запросов на поездку, уведомлять участников, учитывать ETA (Estimated Time of Arrival) и динамическую загрузку водителей. Нефункциональные требования: низкая латентность matching, масштабируемость по количеству водителей и пассажиров, fault tolerance, горизонтальное масштабирование и возможность обработки пиковых нагрузок. После постановки контекста интервьюер молчит.

Этап 2. Формализация требований и уточняющие вопросы

Кандидат уточняет:

Какой географический масштаб: город, регион, страна?

Тип matching: nearest driver vs pooled rides?

SLA по latency matching: sub-second или допустимо несколько секунд?

Требования к persistence: хранение поездок, истории, платежей?

Необходимость ETA для пассажира и водителя?

Политика отказа: водитель отклонил запрос, пассажир отменил поездку?

Поддержка surge pricing или динамических тарифов?

Ключевые характеристики: high throughput, low latency, scalability, fault tolerance, real-time geospatial processing, availability, auditability.

Этап 3. Границы системы и публичный API

Границы системы включают:

API для пассажиров: request ride, cancel ride, track ride, rate driver.

API для водителей: accept/reject ride, update location, complete ride.

Matching engine и geospatial service.

Storage: trips, users, drivers, payments, location history.

Notification service.

Пример API:

POST /rides/request — пассажир создаёт запрос на поездку (pickup, dropoff).

POST /drivers/{id}/location — водитель обновляет текущее местоположение.

GET /rides/{id}/status — статус поездки.

POST /rides/{id}/cancel — отмена поездки.

Контракт: ride request обрабатывается атомарно; если request отменён, все связанные ресурсы (driver slot, ETA) освобождаются.

Этап 4. Проектирование: сценарии, потоки данных и компоненты

Happy path: пассажир делает запрос → геосервис находит ближайших доступных водителей → matching engine выбирает оптимального водителя → уведомление водителя → водитель принимает → поездка подтверждена → мониторинг статуса (ETA, маршрут) → завершение → оплата.

Exceptional flows:

Водитель отклонил → retry с next nearest driver.

Пассажир отменил → free driver slot, notify driver.

Нет доступных водителей → notify passenger, put request in queue.

Гео-сервис недоступен → fallback на last-known location / cached grids.

Основные компоненты:

API Gateway / Request Service — принимает ride requests, validates, idempotency for retries.

Matching Engine — real-time matching of drivers and riders, prioritizes nearest driver, may use weighted scoring (distance, driver rating, ETA).

Geospatial Service — indexes driver locations (grid-based, quadtrees, geohashes), supports nearest-neighbor queries.

Driver & Rider Queues — temporary queues for requests and available drivers.

Trip Management / State Store — tracks ongoing rides, status, ETA, pricing.

Notification Service — push notifications to drivers/pax.

Monitoring & Analytics — rides completed, latency, driver utilization.

Geospatial indexing:

Partition city into grids (e.g., geohash), store active drivers in grid → fast lookup nearest driver.

Optional in-memory caching (Redis / Hazelcast) for hot zones.

Matching algorithm: nearest-driver-first, weighted by ETA, driver rating, dynamic pricing factors.

Этап 5. Концептуальная схема и целостный обзор

Система делится на слои:

Client API / Gateway — принимает ride requests, driver location updates.

Geospatial Service — driver location indexing, nearest-neighbor search.

Matching Engine — selects optimal driver, manages queues, retry on rejection.

Trip / State Management — trip lifecycle, status updates, ETA, pricing.

Notification Service — push notifications for request/accept/cancel.

Monitoring / Analytics — utilization, latency, rides per region, surge events.

Поток данных: Ride request → Matching Engine + Geospatial Service → Driver → ETA & route updates → Trip completion → Payment & rating.

Этап 6. Выбор технологий и sizing

Технологии:

API Gateway: Envoy / Nginx / Kong.

Geospatial Storage / Indexing: Redis (geo-indexes), Elasticsearch geo queries, PostGIS.

Matching Engine: in-memory processing, scalable microservices, possibly with queue (Kafka) for decoupling requests.

Trip Store: PostgreSQL / MySQL / NoSQL (Cassandra) for horizontal scaling.

Notification: Firebase / APNs / WebSocket.

Monitoring: Prometheus + Grafana, ELK stack for logs.

Sizing:

City-scale: 100k active users, 10k drivers.

Average 1 ride/sec → 3600 rides/hour.

Geohash grids: 1km × 1km, average 10–50 drivers per grid → fast lookup in Redis.

Matching Engine: ~10–20 nodes for parallel processing of ride requests.

Notification: low latency push, autoscaling per demand.

Trade-offs:

Strong consistency (exact driver availability) vs low latency → prefer optimistic matching + compensation if double-book occurs.

ETA calculation: real-time vs cached routing → balance latency and accuracy.

Этап 7. Расширения и эксплуатационные аспекты

Pooling / ride-sharing: multiple passengers per ride.

Dynamic pricing / surge: adjust fares based on supply-demand in grid.

Driver rating & scoring: incorporate in matching decisions.

High availability: multi-region deployment for disaster recovery.

Backpressure handling: queue ride requests if system saturated.

Analytics: driver utilization, heatmaps, demand prediction.

Monitoring & alerting: failed matches, stale driver locations, queue backlog.

Ads Targeting System

Сегментация пользователей, high-throughput сервисы.

Этап 1. Постановка задачи и контекст

Интервьюер объявляет задачу: спроектировать Ads Targeting System, которая позволяет рекламодателям таргетировать пользователей на основе их интересов, поведения и демографических данных. Система должна поддерживать высокую пропускную способность при показе рекламных объявлений, обеспечивать низкую латентность при запросе на показ (real-time bidding), масштабироваться на миллионы пользователей и миллиардные event-потоки. Ключевые нефункциональные требования: high throughput, low latency, горизонтальное масштабирование, fault tolerance, сегментация аудитории, гибкая конфигурация кампаний. После постановки контекста интервьюер молчит.

Этап 2. Формализация требований и уточняющие вопросы

Кандидат уточняет:

Тип таргетинга: демографический, поведенческий, look-alike, ретаргетинг?

SLA latency: сколько времени допускается на решение “показать объявление пользователю”?

Event sources: веб, мобильные приложения, CRM данные?

Поддержка real-time bidding (RTB) или batch-показы?

Частота обновления сегментов: real-time, hourly, daily?

Требования к аутентификации и privacy (GDPR/CCPA)?

Метрики эффективности: CTR, conversions, revenue attribution?

Ключевые характеристики: high throughput, low latency, scalability, flexibility, fault tolerance, observability, data privacy compliance.

Этап 3. Границы системы и публичный API

Границы системы включают: ingestion событий, сегментацию пользователей, storage сегментов и аудитории, real-time targeting engine, API для рекламодателей и платформы доставки объявлений.

Пример API:

POST /events — отправка пользовательских событий (page_view, click, purchase).

GET /ads?userId={id} — получение релевантного объявления для конкретного пользователя.

POST /campaigns — создание/обновление кампаний, таргетинг и бюджеты.

Admin API — просмотр сегментов, performance metrics, debug tools.

Контракт: каждый user event обрабатывается и доступен для сегментации в допустимые SLA; запрос на показ объявления должен учитывать актуальные сегменты и кампании.

Этап 4. Проектирование: сценарии, потоки данных и компоненты

Happy path:

Пользователь совершает действие → event отправляется в ingestion pipeline.

Pipeline агрегирует события → обновляет user profile / segments.

Ads Engine при показе запроса → получает userId → извлекает сегменты → выбирает релевантные кампании → ранжирует объявления → возвращает ad payload в клиентское приложение.

Exceptional flows:

Недоступность сегментационного хранилища → fallback на cached segments.

High load на Ads Engine → throttle или batch decisions.

Event ingestion backlog → eventual consistency для segment updates.

Privacy constraints → filter PII, opt-out users.

Компоненты:

Event Ingestion / Stream — Kafka, Pulsar; partitioned by userId, high throughput.

User Profile & Segment Store — scalable key-value store (Cassandra, DynamoDB, Redis), хранение атрибутов, сегментов.

Real-Time Ads Engine — принимает userId, извлекает сегменты, выбирает объявления, ranks by priority/CTR/price.

Campaign Management Service — CRUD для кампаний, таргетинг правил, budgets.

Analytics / Monitoring — CTR, conversions, campaign effectiveness.

Admin / API Layer — управление, мониторинг, debug.

Сегментация и таргетинг:

Сегменты вычисляются в потоковом режиме (real-time) и batch (hourly/daily).

Для high-cardinality сегментов используется bitmap indexing, inverted indices или Bloom filters.

Ads Engine использует precomputed top-K candidates per segment, cached in-memory.

Этап 5. Концептуальная схема и целостный обзор

Система делится на слои:

Event Producers — веб/мобильные события пользователей.

Ingestion Pipeline — Kafka / Pulsar, partitioned by userId.

Stream Processing — Flink/Spark Streaming для real-time segment updates.

Segment / Profile Store — Cassandra/DynamoDB/Redis, хранение актуальных сегментов per user.

Ads Engine — selects relevant ad based on segments and campaign rules; ranks and returns payload.

Campaign Management — CRUD, targeting rules, budgets.

Analytics / Monitoring — event metrics, ad performance dashboards.

Поток данных: Event → Ingestion → Stream Processing → Profile/Segment Store → Ads Engine → Delivery → Analytics.

Этап 6. Выбор технологий и sizing

Технологии:

Event Bus: Kafka / Pulsar, high throughput ingestion (млн+ events/sec).

Stream Processing: Flink / Spark Streaming, stateful real-time computation.

Segment / Profile Store: Cassandra / DynamoDB для scalable key-value storage, Redis for hot segments.

Ads Engine: in-memory processing (Go/Java), low-latency retrieval from KV store.

Analytics: ClickHouse / Druid for ad performance metrics.

Sizing:

EPS = 10M events/sec → partitioned across 100+ Kafka partitions.

User base = 100M, average 20 attributes/segments → 2B segment entries, ~100–200 GB storage.

Ads Engine: top-K candidates cached in Redis (~1–2 GB), hundreds of concurrent requests per node.

Stream processors: ~20 nodes for low-latency segment computation.

Trade-offs:

Strong consistency vs latency → eventual consistency на segment updates допустима для non-critical campaigns.

Real-time vs batch → critical campaigns real-time, long-tail campaigns batch.

Этап 7. Расширения и эксплуатационные аспекты

Look-alike / ML-based targeting — precompute embeddings, user similarity.

Personalization — dynamic ranking of ads per user/session.

Dynamic budgets & pacing — campaign spend per time unit.

Privacy compliance — GDPR/CCPA opt-out, data anonymization.

High availability & multi-region — replication for ingestion pipeline, segment store.

Monitoring & alerts — ingestion lag, ad delivery latency, CTR metrics.

Fallback / cold-start — default generic ads for users without sufficient profile data.

Online Code Execution Service (как LeetCode / Judge0)

Изоляция, sandboxing, распределение задач по воркерам.

Этап 1. Постановка задачи и контекст

Интервьюер объявляет задачу: спроектировать сервис, позволяющий пользователям выполнять код в онлайн-режиме на различных языках программирования. Система должна обеспечивать изоляцию исполняемого кода (sandboxing), поддержку параллельного выполнения задач, обработку различных языков и версий, безопасное управление ресурсами (CPU, memory, disk), а также масштабирование под большое количество одновременных запросов. Нефункциональные требования: безопасность (изоляция и предотвращение злоумышленного кода), low latency, fault tolerance, горизонтальное масштабирование и управление очередями заданий. После постановки контекста интервьюер молчит.

Этап 2. Формализация требований и уточняющие вопросы

Кандидат уточняет:

Какие языки и версии поддерживать: Python, Java, C++, JS, Go и др.?

SLA latency: среднее время выполнения кода и максимальная задержка?

Ограничения ресурсов на задачу: CPU time, memory, disk, network?

Persistent storage: нужен ли для тестов, логов, или execution ephemeral?

Нужно ли поддерживать batch execution или только interactive submissions?

Поддержка long-running или бесконечного цикла кода → timeout enforcement?

Отслеживание execution metrics: runtime, memory usage, exit status, stderr/stdout?

Ключевые характеристики: security, isolation, scalability, high throughput, low latency, fault tolerance, multi-language support, observability.

Этап 3. Границы системы и публичный API

Границы включают: веб/API layer для приема submissions, execution engine с sandboxing, storage для логов и результатов, очередь заданий, мониторинг и администрацию.

Пример API:

POST /submissions — загрузка кода с параметрами (language, version, stdin, constraints).

GET /submissions/{id}/status — текущий статус выполнения (queued, running, finished, error).

GET /submissions/{id}/result — stdout, stderr, exit code, runtime metrics.

Admin API — управление execution nodes, monitoring, scaling.

Контракт: каждый submission имеет уникальный id; повторный запрос по id идемпотентен; system enforces resource limits and timeouts.

Этап 4. Проектирование: сценарии, потоки данных и компоненты

Happy path:

Пользователь отправляет submission → API validates + enqueues in Job Queue.

Worker забирает задачу из очереди → запускает в sandbox (container, VM, Firecracker microVM, chroot).

Код выполняется с лимитами CPU, memory, disk, timeout → stdout/stderr и exit code сохраняются.

Worker сохраняет результат → updates submission status → notify user.

Exceptional flows:

Code hangs → enforce timeout → terminate sandbox → return timeout error.

Code exceeds memory → terminate → return memory exceeded.

Worker node crashes → job requeued → ensure idempotency.

Security violation (network/file access) → sandbox prevents access, log incident.

Компоненты:

API / Submission Service — принимает submissions, validates payload, enqueues jobs.

Job Queue — Kafka/RabbitMQ/Redis Queue, decouples submissions from workers.

Execution Workers / Sandbox Engine — containerized/microVM execution, resource-limited, isolated.

Language Runtime Images — prebuilt docker/microVM images per language/version.

Result Store — persistent storage for stdout, stderr, exit code, runtime metrics.

Monitoring & Metrics — worker health, queue size, execution latency, sandbox violations.

Admin / Scheduler — scale workers, monitor load, manage language images.

Sandboxing approaches:

Containers (Docker) — lightweight, OS-level isolation.

Firecracker microVMs — stronger isolation, lower overhead than full VM.

chroot / seccomp / cgroups — minimal isolation, less secure for untrusted code.

Resource enforcement: cgroups (CPU, memory), timeout, ephemeral filesystem, network disabled.

Этап 5. Концептуальная схема и целостный обзор

Система делится на слои:

Client / API Layer — принимает submissions, applies validation and idempotency.

Job Queue — decouples submission ingestion and worker execution; handles retries.

Execution Worker — picks job → launches sandbox → executes code → collects results.

Language Runtime Images — prebuilt environments for supported languages.

Result Storage — persistent logs, stdout/stderr, metrics.

Monitoring & Admin — metrics collection, autoscaling, health checks.

Поток данных: Submission → Queue → Worker → Sandbox Execution → Result Storage → API response → Monitoring.

Этап 6. Выбор технологий и sizing

Технологии:

Job Queue: Kafka / RabbitMQ / Redis Streams — durable, partitioned, high throughput.

Execution Workers: Go / Java / Python microservices, horizontally scalable.

Sandboxing: Docker, Firecracker microVMs, cgroups/seccomp for resource isolation.

Result Storage: S3 / MinIO (stdout/stderr), PostgreSQL / DynamoDB (submission metadata).

Monitoring: Prometheus + Grafana, alerting for worker failures or slow jobs.

Sizing:

100k submissions/day, avg execution 1–2s.

Queue throughput ~2–3 submissions/sec on average, peak 500/sec → partitioned queue.

Workers: 50–100 nodes with multiple concurrent sandboxes per node.

Resource limits: 500MB RAM, 2 CPU cores per sandbox.

Storage: stdout/stderr avg 10KB per submission → ~1GB/day.

Trade-offs:

Strong isolation (microVM) vs latency / resource overhead.

Prebuilt language images reduce startup latency.

Queue decouples spikes, ensures retry on worker failure.

Этап 7. Расширения и эксплуатационные аспекты

Multi-language support: добавление новых runtimes и версий.

Autoscaling: workers scale horizontally based on queue depth.

Security monitoring: detect malicious submissions, audit logs.

Timeouts and retries: enforce per submission limits, prevent queue starvation.

Caching: for repeated identical submissions (deduplication).

Interactive execution: support stdin streaming for interactive challenges.

Analytics: submission patterns, execution times, popular languages.

Сообщение Системный дизайн. Интервью по System Design появились сначала на DataTalks.RU. Data Engineering / DWH / Data Pipeline.

Что такое Apache Kafka?

Apache Kafka — это распределённая платформа для обработки потоков данных в реальном времени, которая позволяет приложениям публиковать, хранить и обрабатывать данные в режиме потоков событий. Она обеспечивает высокую пропускную способность, масштабируемость и отказоустойчивость, что делает её популярной для создания событийно-ориентированных архитектур, аналитики в реальном времени и управления большими объёмами данных.

Подборка материалов по Kafka

• YouTube: Лучший Гайд по Kafka для Начинающих За 1 Час (Vlad Mishustin) — классный видос по Kafka
• YouTube: 5 Применений Kafka в Реальных Приложениях — дополнительное видео для понимания использования Kafka в приложениях
• YouTube: Kafka и RabbitMQ — БРОКЕРЫ СООБЩЕНИЙ Простым языком на понятном примере
• YouTube: Playlist Apache Kafka — большой курс по Kafka от JavaGuru
• YouTube: Про Kafka (основы)
• YouTube: Kafka со Слёрмом
• YouTube: Kafka в 2025 для дата-инженера: Полный разбор на практике с Python, S3 и ClickHouse
• Kafka Visualization — онлайн симулятор работы Kafka, можно сконфигурировать (ограничено) работу Kafka и посмотреть на «конвейер сообщений» между продюсерами и потребителями данных. Статья на habr «Симулятор брокера Apache Kafka: Kafka Visualization от компании SoftwareMill» про этот симулятор
• Статья на habr «Apache Kafka: обзор»
• Шпаргалка по Kafka.pdf
• YouTube: Типичные ошибки при работе с Apache Kafka — Виктор Корейша (Ozon)
• YouTube: HighLoadChannel «Kafka»
• YouTube: Алексей Кашин — Надежно отправляем события в Apache Kafka. От CDC до паттерна Transactional Outbox
• YouTube: Apache Kafka: погружение на 45 минут. Григорий Кошелев, Контур, ведущий разработчик

Основная логика работы Kafka

Kafka — это распределённая система журналов (distributed commit log). Она состоит из нескольких брокеров (серверов), которые вместе образуют кластер. Кластер хранит топики, которые разделены на партиции (partitions). Каждая партиция — это упорядоченный, неизменяемый лог событий.

Producer (Продюсер) соединяется с кластером и узнаёт, на каком брокере хранится нужный топик и его партиции. Для каждой записи продюсер выбирает партицию (по ключу, по хешу или случайно). Событие сериализуется (обычно Avro, JSON, Protobuf) и отправляется на брокер. Брокер записывает сообщение в конец партиции — фактически в лог-файл на диске. Каждому сообщению присваивается смещение (offset) — уникальный порядковый номер. Kafka не переписывает данные, а только добавляет новые в конец файла — поэтому она очень быстрая.

Consumer (Консюмер) подключается к брокеру через Consumer Group Coordinator. Консюмер читает сообщения по порядку offset-ов и может сохранять своё текущее смещение (commit offset) в Kafka (__consumer_offsets). Таким образом Kafka знает, до какого места консюмер дочитал поток.

Kafka хранит данные на диске — в виде логов, а не в памяти. Каждая партиция — это директория на диске брокера, содержащая:

00000000000000000000.log
00000000000000001000.log
...

Каждый .log файл — это блок записей. Когда достигается лимит по размеру (segment.bytes) или времени (segment.ms), создаётся новый сегмент. Kafka не удаляет сообщения сразу после чтения.

Партиция сохраняется на диске как каталог сегментов. Сегменты — это физические фрагменты одной партиции, а не отдельные логические сущности.

Topic -> Log -> Segment:

Сообщения хранятся до истечения retention policy:

• по времени (retention.ms),
• по размеру (retention.bytes),
• или в режиме compaction — сохраняется только последнее сообщение для каждого ключа.

Глоссарий Apache Kafka

Основные определения Apache Kafka:

• Apache Kafka — Распределённая платформа потоковой передачи событий (event streaming platform), предназначенная для обработки и хранения потоков данных в реальном времени. Используется для построения real-time пайплайнов и стриминговых приложений.
• Event / Message / Record (Событие / Сообщение / Запись) — Представление факта изменения состояния системы — «что-то произошло». Включает ключ, значение, метку времени и необязательные заголовки. События в Kafka неизменяемы (immutable).
• Topic (Топик) — Логическая категория/канал данных, куда продюсеры публикуют события. Топики делятся на partitions (разделы) и могут быть реплицированы.
• Partition (Раздел) — Физическая часть топика, хранящая события в порядке записи. Базовая единица параллелизма Kafka. Каждая партиция — упорядоченная, неизменяемая последовательность событий, которая записывается в лог. События в партиции строго упорядочены и идентифицируются offset-ом.
• Broker (Брокер) — Сервер Kafka, который принимает события от продюсеров (producers), хранит их в партициях и выдаёт консюмерам (consumers). Обычно Kafka-кластер состоит из нескольких брокеров.
• Producer (Продюсер) — Приложение (клиент), которое публикует (отправляет) события в Kafka-топики. Продюсер может определять, в какую партицию топика записать сообщение.
• Consumer (Консюмер) — Приложение (клиент), которое подписывается на один или несколько топиков и обрабатывает поступающие события. Читает сообщения из партиций в порядке их offset-ов.
• Consumer Group (Группа Потребителей) — Набор консюмеров, совместно обрабатывающих события из одного или нескольких топиков. Каждая партиция назначается только одному консюмеру внутри группы → масштабирование без дублирования.
• Offset (Смещение) — Уникальный порядковый номер события в пределах партиции. Определяет позицию консюмера и обеспечивает контроль обработки сообщений.
• Replication (Репликация) — Механизм копирования партиций на несколько брокеров. Обеспечить отказоустойчивость и сохранность данных. Replication factor определяет количество копий каждой партиции.
• Leader (Лидер) — Основная реплика партиции, которая обрабатывает все операции чтения и записи.
• Follower (Фолловер) — Реплика, синхронизирующаяся с лидером путём копирования его журнала событий. При отказе лидера фолловер может быть выбран новым лидером.
• In-Sync Replica (ISR, Синхронная Реплика) — Набор реплик (включая лидера), которые полностью синхронизированы с лидером. Обеспечивает надёжную запись — продюсер может ждать подтверждений от всех ISR.
• ZooKeeper — распределённая система координации, традиционно использовавшаяся Kafka для хранения метаданных, выборов лидера и конфигурации. KRaft (Kafka Raft) — новый встроенный протокол консенсуса, заменяющий ZooKeeper в современных версиях Kafka.
• Kafka Connect — Фреймворк для интеграции Kafka с внешними системами (базы, очереди, хранилища и т. д.). Source Connectors (загрузка данных в Kafka) и Sink Connectors (выгрузка из Kafka).
• Kafka Streams — Клиентская библиотека, которая позволяет прямо из приложений читать данные из топиков, обрабатывать их (фильтровать, агрегировать, объединять) и писать результат обратно в другие топики. Это “потоковая логика поверх Kafka”.

Пример сценария использования Apache Kafka

Здесь разберем небольшой пример, чтобы на нем описать основную логику работы системы.

Допустим, у нас есть крупный интернет-магазин, где ежедневно создаются тысячи заказов. Каждый заказ запускает целую цепочку бизнес-процессов: уведомления клиенту, резервирование товара, доставка, обновление аналитики и многое другое.

Представим, что мы хотим построить эту систему так, чтобы она была масштабируемой, отказоустойчивой и позволяла добавлять новые микросервисы без необходимости переписывать старые. Именно здесь на сцену выходит Apache Kafka — платформа, которая превращает поток событий в единое, надёжное “сердце” всей e-commerce-инфраструктуры.

Шаг 1. Создание заказа

Всё начинается с того, что пользователь оформляет заказ на сайте. На уровне архитектуры это делает сервис, который мы назовём Order Service. Он отвечает за валидацию данных, проверку наличия товаров и создание записи в базе данных. Когда заказ успешно создан, сервис публикует событие OrderCreated в Kafka — в специальный топик под названием orders.

Выглядит это, как простое сообщение в формате JSON, например:

{
  "order_id": 12345,
  "customer_email": "user1@ecom.ru",
  "total": 199.90,
  "items": [
    {"sku": "AB-123", "qty": 2},
    {"sku": "CD-456", "qty": 1}
  ],
  "created_at": "2025-10-22T10:30:00Z"
}

Продюсер (Order Service) обращается к брокеру Kafka и помещает событие в конец журнала (partition) топика orders. С этого момента Kafka становится источником истины: все сервисы, которым нужно знать о новых заказах, будут читать именно этот поток.

Шаг 2. Сервис уведомлений

После того, как событие появляется в Kafka, его получает первый потребитель — Notification Service. Это отдельное приложение, которое подписано на тот же топик orders, но принадлежит своей consumer group (например, notification_group). Kafka гарантирует, что каждый потребитель внутри группы получает уникальный набор партиций — то есть события распределяются равномерно, а не дублируются.

В данном случае сервис уведомлений получает все события, потому что он один в группе.

Получив сообщение OrderCreated, сервис выполняет простое действие: он берёт адрес электронной почты клиента, формирует письмо и отправляет уведомление:

“Ваш заказ №12345 успешно создан! Мы приступаем к обработке.”

Kafka здесь выступает как надёжный посредник.

Если сервис уведомлений временно недоступен — ничего страшного. Kafka продолжает хранить сообщения в топике orders. Когда сервис вернётся в строй, он просто дочитает поток с того места, где остановился — по сохранённому offset-у. Таким образом, ни одно уведомление не потеряется, даже если в системе временно что-то пошло не так.

Шаг 3. Сервис логистики

Параллельно с Notification Service в системе работает другой потребитель — Logistics Service. Он также слушает топик orders, но уже со своей consumer group, например logistics_group. Это значит, что Kafka отдаёт ему тот же поток событий, что и сервису уведомлений, но независимо. Каждый сервис получает свои копии событий — и каждый может реагировать по-своему.

Когда Logistics Service получает сообщение OrderCreated, он делает совсем другие вещи: резервирует товар на складе, создаёт задачу для курьера, обновляет статус заказа в системе доставки. Таким образом, одно событие запускает два (и потенциально десятки) разных бизнес-процессов — и всё это асинхронно и безопасно.

Потоковая интеграция вместо хрупких связей через API

Если бы мы строили такую систему без Kafka, то Order Service должен был бы сам вызывать API уведомлений, API логистики и, возможно, ещё десяток других сервисов. Такой подход создаёт сильную связанность: ошибка одного из сервисов может замедлить или остановить весь процесс. Kafka решает эту проблему, превращая коммуникацию в поток событий, где каждый сервис просто подписывается на интересующие его данные.

Теперь Order Service не знает, кто именно реагирует на событие OrderCreated. Может, только логистика. Может, логистика и уведомления. А может, ещё и аналитика, CRM, биллинг — без разницы.

Он просто публикует факт: “Заказ создан.” И любой другой сервис может использовать эту информацию, не нарушая независимость архитектуры.

Надёжность и гибкость

Kafka гарантирует, что ни одно событие не потеряется:

• Все сообщения хранятся на диске и могут быть реплицированы на несколько брокеров.
• Каждый потребитель знает, до какого сообщения он дочитал (offset).
• Можно “перемотать” поток назад и перечитать историю заказов — например, если в сервисе логистики произошла ошибка и нужно пересоздать статусы.

Благодаря этому, система становится не просто асинхронной, а воспроизводимой: каждый бизнес-процесс можно “переиграть”, восстановить данные или проанализировать прошлые заказы.

Kafka — это не просто брокер сообщений, а фундаментальный слой событийной архитектуры, на котором можно построить всё: от аналитики и уведомлений до машинного обучения и мониторинга.

Партиционирование (Partitioning)

В контексте Apache Kafka партиционирование (partitioning) — это метод разделения топика на более мелкие, независимые сегменты, называемые разделами (partitions). Каждый раздел представляет собой лог, в котором сообщения хранятся в порядке их поступления. Партиционирование позволяет Kafka параллелизировать обработку данных, что даёт возможность нескольким потребителям (consumers) одновременно читать данные из разных разделов.

Данные в разделе хранятся последовательно (append-only log) на диске. Это позволяет эффективно писать и читать сообщения с высокой пропускной способностью.

Стратегия партиционирования Apache Kafka направлена на достижение нескольких целей: высокая доступность, устойчивость к сбоям, балансировка нагрузки и масштабируемость.

Kafka разбивает топики на разделы, и каждый раздел является независимой единицей данных, которую можно реплицировать между несколькими брокерами.

Партиционирование — это основа горизонтального масштабирования Kafka (единица масштабирования). При добавлении новых разделов система может обрабатывать больший объём данных и поддерживать более высокую параллельность потребителей (больше разделов — больше параллелизма потребителей).

Кроме того, сообщения внутри одного раздела всегда сохраняют порядок, что важно для приложений, где требуется строгая последовательность событий (offsets управляются для каждой consumer group, что даёт отказоустойчивое параллельное потребление).

ВАЖНО

Consumer group = логическая группа потребителей, которые совместно читают данные из одного или нескольких топиков, деля между собой партиции. Это значит, что каждая партиция топика обрабатывается только одним потребителем внутри группы. То есть, в одной consumer group обычно находятся все экземпляры одного сервиса, которые выполняют одну и ту же задачу. Kafka отслеживает смещения (offsets) отдельно для каждой группы, чтобы гарантировать, что одно сообщение не будет прочитано двумя потребителями из одной группы.

Тема разбивается на несколько разделов, что позволяет параллелить чтение/запись и распределять нагрузку по брокерам. Каждому разделу присваивается смещение (offset) для каждого сообщения.

Разделы могут быть реплицированы, один из реплик становится лидером (leader), остальные — followers. Это обеспечивает отказоустойчивость и доступность.

Описание схемы (схема демонстрирует базовый принцип устойчивости Kafka: запись — только через лидера, чтение — обычно из лидера, а синхронизация поддерживается через фолловеров):

• Производитель (Producer) всегда записывает сообщения в лидера раздела (partition).
• Фолловеры (Followers) автоматически реплицируют данные с лидера, чтобы поддерживать копии лога в актуальном состоянии.
• Потребители (Consumers) из группы потребителей (Consumer Group) обычно читают данные с лидера, чтобы получать подтверждённые сообщения.

Внизу показан список ISR (In-Sync Replicas) — это набор брокеров, чьи копии данных синхронизированы с лидером (в примере ISR = [101, 102, 103]).

Транзакции и целостность данных

Kafka поддерживает транзакции, что позволяет атомарно записывать сообщения в несколько разделов/тем и одновременно фиксировать смещения потребителя. Это важно для гарантии exactly-once (или ближе к этому) обработки.

При чтении можно выбирать уровень изоляции: «read_uncommitted» — читать все подряд или «read_committed» — читать только закоммиченные сообщения (т.е. получать только завершённые транзакции).

• Transaction Coordinator — модуль в брокере Kafka, который управляет транзакциями и отслеживает их состояние.
• Transaction Log — внутренний топик, куда записывается состояние транзакций (например: “начата”, “готова к коммиту”, “завершена”).
• Когда продюсер начинает новую транзакцию, он регистрирует свой transactional.id у коорд. После этого он начинает отправлять сообщения обычным образом, но в рамках транзакции. Когда приходит время — либо commitTransaction(), либо abortTransaction(). При коммите Kafka пишет “маркер” транзакции в каждую участвующую партицию и фиксирует, что сообщения этой транзакции видимы.
• Потребитель, настроенный в режиме isolation.level=read_committed, будет видеть только те записи, которые относятся к завершённым (committed) транзакциям, и игнорировать те, что от незавершённых или aborted.

2 модели обмена сообщениями (очередь сообщений и модель публикации-подписки)

При наличии только одной группы получателей Kafka функционирует как традиционная система очереди сообщений. Однако, если на тему подписано несколько групп получателей, Kafka ведёт себя как модель публикации/подписки, когда сообщения получают несколько получателей.

1. Очередь сообщений (Message Queue / Point-to-Point) — каждое сообщение обрабатывается ровно одним потребителем:

• Сообщения распределяются по разделам (partitions) темы.
• Внутри группы потребителей (Consumer Group) Kafka гарантирует, что каждый раздел назначен только одному потребителю.
• Таким образом, сообщения из одного раздела не дублируются между потребителями группы.
• Это обеспечивает горизонтальное масштабирование обработки — больше потребителей в группе — больше параллелизма.

Пример:

• Тема orders с 3 разделами.
• Группа потребителей order-service из 3 экземпляров.

Каждый экземпляр обрабатывает свой раздел — каждое сообщение читается только один раз в рамках группы.

2. Публикация-подписка (Publish-Subscribe) — одно сообщение может быть прочитано множеством независимых потребителей:

• Разные группы потребителей могут подписываться на одну и ту же тему.
• Каждая группа обрабатывает поток независимо от других — Kafka хранит смещения (offsets) для каждой группы.
• Это позволяет нескольким приложениям читать один и тот же поток событий параллельно, не мешая друг другу.

Пример: Тема user-activity.

Группы:

• analytics-service (для анализа поведения),
• monitoring-service (для алертов).

Обе группы читают одинаковые события, но Kafka ведёт отдельные смещения для каждой.

Schema Registry (Реестр схем)

Как только приложения начнут активно отправлять сообщения в Kafka и получать сообщения из него, произойдут два события.

• Во-первых, появятся новые потребители существующих топиков. Это будут совершенно новые приложения — возможно, написанные той же командой, которая создала исходный продюсер сообщений, а возможно, и другой командой, — и им потребуется понимать формат сообщений в топике.
• Во-вторых, формат этих сообщений будет меняться по мере развития бизнеса. Объекты заказов получат новое поле статуса, имена пользователей будут разделены на имя и фамилию вместо полного имени и так далее.

Схема наших объектов предметной области — это постоянно меняющаяся цель, и нам необходимо найти способ согласовать схему сообщений в любом топике.

Schema Registry предоставляет централизованный репозиторий для управления и проверки схем данных сообщений топиков, а также для сериализации и десериализации данных по сети. Производители и потребители топиков Kafka могут использовать схемы для обеспечения согласованности и совместимости данных по мере развития схем. Schema Registry — ключевой компонент управления данными, помогающий обеспечивать качество данных, соответствие стандартам, прозрачность происхождения данных, возможности аудита, совместную работу между командами, эффективные протоколы разработки приложений и производительность системы.

Schema Registry работает с:

• Avro (классика Kafka-мира, бинарный, компактный)
• Protobuf (Google Protocol Buffers)
• JSON Schema (читаемый, но больше размер сообщений)

Реестр схем не включен в Kafka, но существует несколько его вариантов с открытым исходным кодом. Например, Реестр Confluent Schema.

Гарантии доставки сообщений в Kafka

Под семантической гарантией понимается соглашение между продюсером, брокером и потребителем — как именно сообщения передаются и обрабатываются.

Kafka поддерживает три типа семантики доставки:

• At most once (не более одного раза) — Сообщения доставляются один раз, но при сбое системы часть сообщений может быть потеряна и не будет переотправлена. Минимальная задержка, но есть риск потерь.
• At least once (как минимум один раз) — Сообщения доставляются один или несколько раз. При сбое система гарантирует, что сообщение не потеряется, но возможны дубликаты. Без потерь, но может потребоваться обработка повторов.
• Exactly once (ровно один раз) — Каждый сообщение доставляется строго один раз. Оно не теряется и не читается повторно, даже если часть системы выходит из строя. Максимальная надёжность, но выше задержка и сложнее настройка.

Эти три подхода отражают компромисс между задержкой и надёжностью. Выбор зависит от требований вашего приложения.

Важно: многие системы заявляют о поддержке exactly-once, но на деле они не учитывают сбои компонентов за пределами самой системы (например, внешнего продюсера или потребителя).

Kafka же реализует эти гарантии на уровне журнала (log): как только сообщение записано и подтверждено, оно считается зафиксированным (committed). После этого оно не потеряется, пока хотя бы один брокер с репликой этого раздела остаётся «живым».

Доставка сообщений от продюсера

• At most once — Для минимальной задержки продюсер может отправлять сообщения асинхронно (“fire and forget”) — то есть не ожидая подтверждения от брокера. Можно также дождаться подтверждения от ведущего брокера (leader broker), чтобы снизить риск потери, но увеличить задержку.
  В обоих случаях сообщения доставляются один раз, а при сбое — могут быть потеряны и не будут переотправлены.
• At least once — В этом режиме, если продюсер не получил подтверждение, что сообщение было зафиксировано, он переотправит его. Это гарантирует доставку как минимум один раз, но при этом одно и то же сообщение может попасть в лог дважды, если первый запрос всё-таки был успешным.
  Режим идемпотентного продюсера (idempotent producer) гарантирует, что повторная отправка не создаст дубликатов, а порядок сообщений в журнале сохранится. Для этого брокер присваивает продюсеру уникальный ID и использует порядковый номер (sequence number) для каждого сообщения, чтобы исключить повторную запись одного и того же события.
• Exactly once — продюсеры могут использовать транзакционную доставку (transactional delivery). В этом режиме продюсер получает подтверждение, что сообщения приняты и реплицированы, при повторной отправке сообщение записывается идемпотентно — существующие данные перезаписываются, а не дублируются. Это добавляет задержку и требует больших ресурсов, но обеспечивает наивысший уровень надёжности.
  Чтобы реализовать транзакционные гарантии “exactly once”, потребители также должны быть соответственно сконфигурированы (например, использовать isolation.level=read_committed).

Получение сообщений потребителем (Consumer Receipt)

Каждое сообщение в разделе (partition) топика имеет последовательный идентификатор — offset.
Все реплики одного раздела содержат одинаковый журнал логов с теми же offset’ами, а потребитель сам управляет своей позицией в этом логе — то есть знает, с какого offset’а продолжать чтение.
Если потребитель выходит из строя, и его работу должен перенять другой потребитель, тот должен знать, с какого offset’а начать читать.

• At most once — «не более одного раза» — Потребитель читает группу сообщений. Сначала сохраняет своё положение (offset). Затем обрабатывает сообщения. Если потребитель завалится после сохранения offset, но до завершения обработки,
  новый потребитель начнёт читать с сохранённого offset’а, и уже прочитанные, но не обработанные сообщения будут потеряны. Это семантика “at most once” — в случае сбоя часть сообщений может не обработаться вообще.
• At least once — «как минимум один раз» — Потребитель сначала обрабатывает сообщения и только потом сохраняет offset. Если сбой произойдёт между обработкой и сохранением offset, новый потребитель, который возьмёт на себя задачу,
  прочитает те же сообщения повторно. Таким образом, некоторые сообщения могут быть обработаны дважды, но ни одно не будет потеряно.
  Чтобы избежать проблем от повторной обработки, можно использовать идемпотентную запись — например, задавать каждой записи первичный ключ (primary key), чтобы повторное получение просто перезаписало старую запись без дубликатов.

• Exactly once — «ровно один раз» — Когда Kafka используется для чтения из одного топика и записи в другой (например, в приложениях Kafka Streams), Kafka реализует exactly-once семантику с помощью транзакций.
  Позиция потребителя (offset) сохраняется в виде сообщения в специальном топике Kafka. Эти данные об offset’ах записываются в одной транзакции вместе с результатами обработки, отправляемыми в выходные топики.
  Если транзакция откатывается (aborted), то и offset возвращается к предыдущему значению. Таким образом, система возвращается в полностью согласованное состояние.Какие сообщения видны потребителям:
  • isolation.level=read_uncommitted — потребитель видит все сообщения, включая из незавершённых транзакций.
  • isolation.level=read_committed — потребитель читает только сообщения из завершённых транзакций (используется по умолчанию в режиме exactly-once).

Как работает механизм подтверждений (ACK) в Kafka?

ack (acknowledgement) в Kafka — это механизм, который позволяет производителю (producer) получать подтверждение от брокера о том, что сообщение было успешно отправлено и обработано. Этот параметр, настраиваемый в конфигурации продюсера, влияет на баланс между надежностью (риском потери данных) и производительностью.

Kafka предлагает три уровня подтверждений, каждый из которых балансирует между надежностью и скоростью. Рассмотрим каждый из них:

acks=0 (Производитель не ждет подтверждения)

• Fire-and-forget: отправил и забыл
• Молниеносная пропускная способность
• Сообщения могут потеряться
• Подходит для метрик или логов, где потеря нескольких данных не критична

acks=1 (Продюсер ждет подтверждения от лидера партиции/leader partition)

• Ожидает подтверждения от лидера
• Хорошая скорость при базовой надежности
• Есть риск потери сообщений, если лидер выйдет из строя
• Подходит для большинства повседневных сценариев использования

acks=-1 или all (Продюсер ждет подтверждения от всех реплик в синхронизации/In-Sync Replicas, ISR)

• Ожидает подтверждений от всех реплик
• Медленнее, но максимально надежно
• Максимальная устойчивость
• Идеально подходит для финансовых транзакций

Сравнительная таблица настроек ACKs

Повторные попытки отправки сообщений (Retry Kafka)

Retry — это механизм повторных попыток отправки или обработки сообщений в Apache Kafka. Он помогает обеспечить надежность, повторно отправляя сообщения в случае временных сбоев, вместо того, чтобы терять их. Существуют два основных подхода: блокирующие (когда обработчик замирает в ожидании) и неблокирующие (когда сообщение перенаправляется в отдельный топик, чтобы освободить основной поток).

Может реализоваться 2 сценария, когда ретраи требуются:

Сбой сети:

Отправка сообщения →  Сбой сети  
↓  
Ожидание 100 мс и попытка снова  
↓  
Успешная повторная попытка  Сообщение доставлено

Сбой в лидере партиции:

Отправка сообщения →  Лидер недоступен  
↓  
Ожидание 100 мс (идёт выбор нового лидера)  
↓  
Повторная отправка  Новый лидер на линии, сообщение доставлено

Ключевые параметры конфигурации retry:

# Количество попыток отправки
retries=3                   # Повторить 3 раза

# Интервал между повторными попытками
retry.backoff.ms=100        # Базовый интервал 100 мс

# Общий тайм-аут доставки сообщения
delivery.timeout.ms=120000  # Ожидание до 2 минут

# Включить идемпотентность, чтобы предотвратить дубликаты сообщений при retry
enable.idempotence=true

Анатомия сообщения Kafka

Сообщение Kafka состоит из следующих элементов:

Структура сообщения Kafka:

• Key (Ключ). Ключ является необязательным элементом в сообщении Kafka и может быть равен null. Ключ может быть строкой, числом или любым объектом, после чего он сериализуется в бинарный формат.
• Value (Значение). Значение представляет содержимое сообщения и также может быть null. Формат значения произвольный и также сериализуется в бинарный формат.
• Compression Type (Тип сжатия). Сообщения Kafka могут быть сжаты. Тип сжатия можно указать как часть сообщения. Доступные варианты: none, gzip, lz4, snappy и zstd.
• Headers (Заголовки). Может быть список необязательных заголовков сообщения Kafka в виде пар ключ-значение. Обычно заголовки добавляют для указания метаданных о сообщении, особенно для трассировки.
• Partition + Offset (Раздел + Смещение). После того как сообщение отправлено в топик Kafka, ему присваиваются номер раздела и идентификатор смещения (offset). Комбинация topic+partition+offset уникально идентифицирует сообщение.
• Timestamp (Временная метка). Временная метка добавляется либо пользователем, либо системой в сообщение.

API Kafka

Apache Kafka предоставляет пять основных API Java для управления кластерами и клиентами.

• Producer API — позволяет приложениям публиковать (записывать) потоки событий в одну или несколько тем Kafka, предоставляя настройки для подтверждений отправки и сжатия сообщений.
• Consumer API — позволяет приложениям подписываться на темы и читать поток событий, управляя положением чтения (offset) и количеством извлекаемых данных за один цикл.
• Admin Client API — предоставляет методы для программного управления кластером Kafka — создания, удаления, описания и изменения ресурсов вроде тем, брокеров и ACL.
• Connect API — служит фреймворком для встраивания источников и приёмников данных: позволяет перемещать потоки событий между Kafka и внешними системами (СУБД, хранилища, приложения).
• Kafka Streams API — библиотека для построения приложений и микросервисов, которые читают данные из тем Kafka, преобразуют их (фильтрация, агрегация, join) и записывают результаты обратно в темы.

GitHub проект «kafka-tutorial» — для понимания основ

Для статьи я создал отдельный тестовый проект «kafka-tutorial» на GitHub для локального развертывания Kafka и Zookeeper с примерами producer и consumer на Python. Предназначен для изучения и отладки взаимодействия с Kafka.

Краткое описание библиотеки kafka-python

Как работает обмен сообщениями между продьюсером и консюмером в библиотеке kafka‑python (клиент для Apache Kafka на Python).

• Продьюсер: настраиваем, сериализуем, буферизируем, отправляем через TCP к брокеру-лидеру.
• Консюмер: подключаемся, подписываемся/назначаем партиции, выполняем Fetch запросы, десериализуем, возвращаем сообщения.
• Всё взаимодействие реализовано через сетевой протокол Kafka (TCP), библиотека сама строит запросы (Metadata, Produce, Fetch и др), парсит ответы.

Отправка сообщения (Producer)

Создаётся объект:

from kafka import KafkaProducer
producer = KafkaProducer(bootstrap_servers='localhost:9092',
                          key_serializer=…,
                          value_serializer=…)

Здесь библиотека соединяется с брокерами Kafka, получает метаданные (какие топики, какие партиции, какие брокеры лидеры) через Metadata API.

Когда вызывается producer.send(topic, key=…, value=…) процесс выглядит следующим образом:

• Сериализуется ключ и/или значение через переданные key_serializer/value_serializer.
• Сообщение помещается в буфер (в память) для соответствующей партиции. Продусер внутренне ведёт накопитель (RecordAccumulator) и фоновый поток I/O (Sender thread) которые группируют (batch) сообщения и отправляют партиями.
• В зависимости от настроек (linger_ms, batch_size) может быть задержка прежде чем буфер будет отправлен, чтобы накопить больше сообщений.
• Когда пакет сообщений отправляется, используется бинарный протокол Kafka (через TCP) — библиотека вручную формирует запрос ProduceRequest, посылает его брокеру-лидеру партиции. (Это скрыто в коде, но логика за этим есть: метаданные → выбор партиции → сетевой запрос)Ответ (ProduceResponse) возвращается, и если acks настроено (например acks='all'), продьюсер может ждать подтверждения (или получить ошибку/ретрай) от брокера.
• Вы можете получить future = producer.send(...) и дальше future.get(timeout=…) чтобы ждать результата.
• Необходимо вызвать producer.flush() перед завершением, чтобы дождаться отправки всех накопленных сообщений (иначе программа может завершиться раньше и сообщения не будут отправлены).

Резюме: Python-код → KafkaProducer.send() → буфер → сетевой запрос к брокеру Kafka → сообщение попадает в соответствующую тему/партицию.

Получение сообщения (Consumer)

Создаётся объект:

from kafka import KafkaConsumer
consumer = KafkaConsumer('some_topic',
                         bootstrap_servers='localhost:9092',
                         group_id='my_group',
                         key_deserializer=…,
                         value_deserializer=…,
                         auto_offset_reset='earliest')

Библиотека подключается к брокерам, получает метаданные, подписывается на топик(и), либо явно назначает партиции (assign) или через subscribe получает назначение в составе группы потребителей.

После подписки (или назначения) потребитель выполняет цикл for msg in consumer: или вызывает consumer.poll() и получает сообщения:

• Он делает FetchRequest к брокерам для каждой назначенной партиции, ожидая данные. Конфигурации вроде fetch_min_bytes, fetch_max_wait_ms влияют на задержку/объём.
• Когда данные приходят, они десериализуются с помощью key_deserializer/value_deserializer.
• В сообщении вы получаете объект ConsumerRecord, у которого есть topic, partition, offset, key, value.
• Если используется группа (group_id задана), то библиотека взаимодействует с координатором группы (GroupCoordinator) для ребалансировки, назначений партиций и фиксации смещений (offsets) либо вручную либо автоматически (если enable_auto_commit=True).

Например:

for msg in consumer:
    print(msg.topic, msg.partition, msg.offset, msg.key, msg.value)

Резюме: Python-код → KafkaConsumer опрос брокеров → получает сообщения из Kafka → возвращает вам десериализованные объекты.

Обработка потоков (Stream processing) с Kafka Streams

Kafka Streams — это клиентская Java-библиотека, которая читает данные из Kafka топиков (источников), выполняет преобразования, агрегации, join’ы, оконные операции, и записывает результаты обратно в Kafka (или во внешние хранилища). И все это происходит в реальном времени.

Приложение на Kafka Streams — это просто обычный сервис (JVM-программа), без отдельного «кластера стримов». Kafka сама масштабирует обработку через партиции и consumer groups.

В Data Engineering Kafka Streams применяют для:

• очистки и обогащения данных «на лету» перед записью в DWH;
• real-time агрегаций (например, “средний чек за последние 10 минут”);
• вычислений метрик и алертов в реальном времени;
• построения CDC пайплайнов (Change Data Capture).

Подборка материалов по Kafka Streams

• Официальная документация на английском (видео) + небольшая документация на английском Core Concepts
• Статья «Введение в Kafka Streams» + GitHub demo-kafka-streams
• Статья Habr: «Потоковая обработка данных с помощью Kafka Streams: архитектура и ключевые концепции»
• YouTube: Kafka Streams (На примере OUTBOX pattern, Kafka Connect, Debezium)
• YouTube: Kafka Streams // Демо-занятие курса «Apache Kafka»
• YouTube: Kafka Streams: лекция 1 2022-10-10
• YouTube: Запись вебинара «Kafka Streams: для чего еще можно использовать Kafka
• YouTube: Создание потоковых приложений с использованием Kafka Streams // «Java Developer. Professional»
• YouTube ENG: PlayList «Kafka Streams Tutorials | Kafka Streams 101 (2023)» — и еще куча других видео на канале @Confluent/playlists
• YouTube ENG: PlayList «Kafka Streams: Zero to Hero»
• YouTube ENG: Build a Reactive Data Streaming App with Python and Apache Kafka | Coding In Motion
• YouTube: python kafka spark streaming
• Статья «Kafka Streams для начинающих. Потоковая обработка данных в мире Java»
• YouTube: Мощь Kafka Streams. Когда использовать? | Александр Кузнецов | Синимекс
• Статья Habr: Apache Kafka и потоковая обработка данных с помощью Spark Streaming

Что такое Kafka Streams: основные абстракции – KStream, KTable, топология

Kafka Streams — это библиотека потоковой обработки данных, встроенная в Apache Kafka. Она позволяет создавать приложения, которые обрабатывают данные в реальном времени непосредственно из Kafka-топиков и записывают результаты обратно в Kafka или во внешние системы. В отличие от фреймворков, требующих отдельного кластера (например, Apache Flink или Spark Streaming), Kafka Streams работает как часть обычного клиентского приложения и масштабируется за счёт механизма партиционирования Kafka.

Основной моделью данных в Kafka Streams является поток событий — непрерывная последовательность записей (пар «ключ–значение»), поступающих из Kafka-топика. Для работы с такими потоками библиотека предоставляет две ключевые абстракции: KStream и KTable.

KStream представляет собой неизменяемый поток событий, где каждая запись рассматривается как отдельное событие. Поток можно фильтровать, преобразовывать, объединять с другими потоками, группировать или агрегировать. Каждая новая запись в топике немедленно обрабатывается, что делает KStream подходящей моделью для событийных данных — например, логов, кликов, заказов или транзакций.

KTable, напротив, представляет собой табличное представление данных, отражающее их текущее состояние (последнее состояние для каждого ключа). Каждое новое сообщение с тем же ключом обновляет существующую запись, а не добавляет новую. Таким образом, KTable можно воспринимать как материализованное состояние, построенное из потока событий. Эта абстракция используется для агрегаций, подсчётов, хранения текущего состояния или выполнения операций объединения (join) между потоками и таблицами.

Связующим элементом между этими абстракциями является топология (Topology) — направленный граф, описывающий последовательность операций обработки данных.

Топология определяет, какие потоки данных читаются, какие преобразования применяются, где сохраняется промежуточное состояние и в какие топики отправляются результаты. Каждая вершина топологии соответствует операции (например, фильтрации, группировке или объединению), а каждое ребро представляет поток данных между этими операциями.

Kafka Streams, таким образом, объединяет концепции потоков и таблиц в единую модель обработки событий, где данные могут рассматриваться как непрерывный поток изменений или как текущее состояние системы. Это делает библиотеку удобным инструментом для построения реактивных, устойчивых и масштабируемых систем обработки данных в реальном времени.

Почему и когда использовать: трансформации, фильтрации, агрегаты, соединения потоков

Kafka Streams стоит рассматривать не просто как инструмент для обработки событий, а как логическое продолжение самой Kafka — средство, которое превращает поток данных в поток знаний.

Главный вопрос, который задаёт себе инженер данных, — зачем использовать Kafka Streams, если уже есть Kafka и, возможно, Spark? Ответ в архитектурной философии: Kafka Streams — это «ближе к данным», чем большинство других систем. Она позволяет обрабатывать события там же, где они рождаются, без тяжёлой инфраструктуры и внешних движков. Приложение на Kafka Streams становится умным клиентом Kafka, который не просто читает и пишет сообщения, а выполняет вычисления над ними в реальном времени, сохраняя при этом согласованность состояния и способность к восстановлению.

Использовать Kafka Streams стоит там, где нужны реактивные сценарии обработки: например, при построении витрин для real-time аналитики, обнаружении аномалий, расчёте метрик на лету, обработке транзакций, обновлении состояния пользователей или формировании рекомендаций. Она особенно эффективна, когда важна низкая задержка, надёжная обработка каждого события и возможность масштабирования через Kafka partitions, а не через сторонние кластеры.

Когда речь идёт о трансформациях, Kafka Streams превращается в конвейер данных. С помощью операций map, flatMap и selectKey можно изменять структуру, тип и ключ событий, формируя новые потоки. Это позволяет реализовывать бизнес-логику прямо в коде, а не на уровне ETL-инструментов. Каждое преобразование становится узлом в топологии, и поток данных, проходя через них, постепенно приобретает форму, нужную системе downstream.

Фильтрация (filter, filterNot) даёт возможность отсекать ненужные события ещё на раннем этапе. Это особенно важно при работе с большими объёмами данных, где стоимость дальнейшей обработки может быть высока. Потоки становятся чище, а вычисления — экономнее.

Агрегации делают Kafka Streams мощным инструментом для анализа событий во времени. С помощью операций groupByKey, aggregate, reduce и count можно собирать статистику в реальном времени, отслеживать тренды или поддерживать счётчики. Агрегации в Kafka Streams связаны с концепцией окон — временных диапазонов, внутри которых события группируются. Это позволяет, например, считать количество кликов за последние пять минут или среднюю сумму заказов за день. Такие операции сохраняют состояние в локальном сторе (RocksDB), что делает приложение самодостаточным и отказоустойчивым.

Одной из самых интересных возможностей Kafka Streams являются соединения (joins) — механизм, позволяющий объединять данные из разных потоков или таблиц. Сценарии могут быть разными: объединение двух KStream для корреляции событий из разных систем, соединение KStream и KTable для добавления справочной информации или join двух KTable для синхронизации состояний. При этом Kafka Streams обеспечивает согласованность и упорядоченность данных, что особенно критично для финансовых и аналитических систем.

Таким образом, Kafka Streams стоит использовать там, где данные должны не просто перемещаться, а жить — обновляться, объединяться, фильтроваться и агрегироваться в реальном времени. Это библиотека, которая позволяет думать о данных как о непрерывном процессе, а не о статичном снимке. И в этом её сила: она превращает поток событий в логическую модель, которую можно выразить кодом, а не инфраструктурой.

Как запустить приложение Streams (конфигурация, запуск, топология)

Когда речь заходит о запуске приложения Kafka Streams, всё начинается с понимания: мы не поднимаем кластер, мы пишем приложение, которое становится частью распределённой системы.

Kafka Streams — это не сервис, а библиотека, встроенная в ваше Java-приложение. В этом и заключается её философия — обработка данных должна быть как можно ближе к месту, где выполняется бизнес-логика.

Первым шагом в создании любого приложения Streams является конфигурация. Она определяет, как приложение будет взаимодействовать с Kafka и управлять своим состоянием. Ключевые параметры задаются через объект Properties: application.id, bootstrap.servers, default.key.serde, default.value.serde и другие. Параметр application.id служит не просто идентификатором, а точкой согласования состояния: Kafka Streams использует его для хранения метаданных, контрольных точек и топологического состояния в специальных служебных топиках. Поэтому выбор application.id должен быть осознанным — он определяет, сможет ли приложение продолжить работу после перезапуска без потери данных.

Следующим этапом идёт построение топологии — логического графа обработки данных. Для этого используется StreamsBuilder, объект, через который определяются источники (stream и table), преобразования (map, filter, join, aggregate) и выходные точки (to). Каждый вызов метода добавляет новый узел в топологию, формируя конвейер обработки. Эта топология в итоге становится «дорожной картой» данных: Kafka Streams компилирует её в набор задач (tasks), каждая из которых отвечает за обработку части данных из определённого раздела Kafka. Таким образом, масштабирование достигается естественным образом — за счёт распределения задач по инстансам приложения.

Когда топология определена, создаётся объект KafkaStreams. Именно он связывает логику обработки с реальной инфраструктурой Kafka. Запуск осуществляется вызовом метода start(), после чего приложение начинает читать сообщения из входных топиков, применять трансформации и записывать результаты в выходные топики. Под капотом Kafka Streams автоматически управляет состоянием: создаёт локальные сторы (например, RocksDB), периодически синхронизирует их с changelog-топиками и обрабатывает сбои с помощью механизма восстановления состояния.

Завершение работы должно быть таким же аккуратным, как и запуск. Метод close() позволяет корректно остановить приложение, завершить обработку текущих сообщений и синхронизировать состояние. В продакшене часто используется shutdown hook, чтобы при получении сигнала завершения (например, SIGTERM) приложение Streams успевало завершить все операции.

Таким образом, запуск Kafka Streams можно описать как соединение трёх слоёв: конфигурация, определяющая контекст выполнения; топология, описывающая бизнес-логику обработки; и исполнение, связывающее код с Kafka и обеспечивающее надёжность, масштабирование и отказоустойчивость.

Приложение Streams — это не просто потребитель и продюсер, а полноценный участник экосистемы Kafka, способный мыслить в терминах потоков, состояний и событий, превращая данные в реальном времени в управляемый и воспроизводимый процесс.

Состояние и state stores, оконная обработка (windowing), exactly-once семантика

Когда приложение Kafka Streams начинает работать с состоянием, оно выходит за рамки простой потоковой обработки и превращается в систему, способную помнить контекст. В этом и заключается фундаментальное отличие Kafka Streams от большинства других библиотек — она не просто реагирует на события, а хранит знание о прошлом, делая возможным агрегаты, join-операции и анализ во времени.

Состояние (state) — это локальные данные, которые приложение поддерживает между событиями. Когда выполняется агрегирование, подсчёт или обновление значения по ключу, Kafka Streams сохраняет промежуточный результат в специальном хранилище, называемом state store. Это может быть встроенная база RocksDB, in-memory store или кастомное решение. Каждый инстанс приложения хранит своё состояние локально, что позволяет ему работать автономно и с минимальной задержкой. Но, несмотря на локальность, надёжность обеспечивается через механизм changelog-топиков: каждое изменение состояния записывается в Kafka, что даёт возможность полностью восстановить state при сбое или перемещении задачи на другой узел.

Kafka Streams делает состояние «живым». Это не просто кеш, а часть потокового вычисления. Приложение может напрямую обращаться к локальному стору, использовать интерактивные запросы и даже предоставлять доступ к состоянию внешним системам. Такая архитектура позволяет строить event-driven микросервисы, которые не только реагируют на поток данных, но и опираются на накопленные знания.

Другим ключевым элементом является оконная обработка (windowing). В потоковом мире данные бесконечны, и чтобы их агрегировать, необходимо ограничить время наблюдения. Kafka Streams вводит окна — логические границы, разделяющие поток событий на временные сегменты. Окна бывают скользящие, фиксированные и сдвигаемые. Например, можно подсчитывать количество покупок за каждые 10 минут или находить среднее значение температуры за последние 5 секунд.

Важный момент — окно не просто отсекает время, оно управляет тем, какие события считаются «совместимыми». Каждое событие имеет временную метку, и Streams использует её для определения, к какому окну оно относится. При этом предусмотрена гибкость: можно задавать допустимые задержки (grace period), чтобы учесть события, пришедшие с опозданием, но всё ещё относящиеся к нужному окну.

Работа с состоянием и окнами невозможна без гарантии корректности обработки. Здесь вступает в силу exactly-once семантика — одна из важнейших возможностей Kafka Streams. Она обеспечивает, что каждое сообщение будет обработано строго один раз, даже в случае сбоев, перезапусков или дублированных сообщений.

Механизм exactly-once основан на транзакциях Kafka и согласованной записи в changelog-топики. Каждая операция, затрагивающая состояние и производящая выходные сообщения, выполняется в рамках атомарной транзакции. Если что-то идёт не так — транзакция откатывается, и состояние возвращается в согласованное состояние. Это гарантирует, что ни одно событие не будет потеряно и не будет обработано дважды.

Именно комбинация state stores, окон и exactly-once семантики превращает Kafka Streams в полноценную платформу для построения детерминированных потоковых приложений. Здесь поток не просто обрабатывается — он управляется, обогащается и осмысляется.

Kafka Streams делает возможным создание систем, где каждое событие не просто проходит сквозь поток, а оставляет след — формируя устойчивую, воспроизводимую и надёжную модель данных во времени.

Что такое ksqlDB?

YouTube: Курс по KsqlDB на английском «ksqlDB and Stream Processing Tutorials | ksqlDB 101»

ksqlDB — это эволюция идей Kafka Streams, превращённая в полноценную потоковую базу данных. Если Kafka Streams — это библиотека для разработчиков, то ksqlDB — это инструмент для инженеров и аналитиков, позволяющий описывать потоковую обработку не в коде, а с помощью знакомого SQL. Она создана, чтобы сделать работу с потоками данных такой же естественной, как запросы к реляционным таблицам.

В своей сути ksqlDB строится поверх Kafka и Kafka Streams. Каждый запрос, который вы пишете в виде SQL-команды, компилируется в топологию Streams, выполняемую под капотом. Это значит, что вся надёжность, отказоустойчивость и масштабируемость Kafka Streams автоматически становятся частью вашего SQL-приложения.

Главная идея ksqlDB — рассматривать потоки и таблицы как первоклассных граждан в SQL-мире. Потоки (STREAM) представляют собой последовательность событий, где каждое сообщение фиксирует факт: клик, транзакцию, лог, метрику. Таблицы (TABLE) отражают текущее состояние, агрегаты или материализованные результаты — именно как KTable в Streams. Взаимодействие между ними естественно: поток можно агрегировать в таблицу, а таблицу можно обновлять событиями из потока.

ksqlDB позволяет делать всё то же, что Kafka Streams, но декларативно: фильтровать данные (WHERE), преобразовывать (SELECT, CAST), агрегировать (GROUP BY, COUNT, SUM), соединять потоки (JOIN) и работать с окнами (WINDOW). При этом каждый запрос становится живым — он не возвращает статичный результат, а формирует непрерывный поток обновлений.

В отличие от традиционных баз данных, где запросы завершаются, в ksqlDB они живут во времени. Создавая поток или таблицу через SQL-запрос, вы фактически запускаете постоянное вычисление, которое обновляется с приходом новых данных в Kafka. Все результаты можно записывать обратно в топики, использовать для downstream-систем или даже делать запросы напрямую через REST API.

Кроме того, ksqlDB включает встроенное хранилище состояния. Это значит, что вы можете не только выполнять потоковые операции, но и сохранять результаты, а затем делать к ним запросы, словно к обычной базе данных. Таким образом, ksqlDB объединяет концепции потоковой обработки и транзакционного состояния в одном инструменте.

С точки зрения архитектуры, ksqlDB — это сервис, который подключается к вашему кластеру Kafka, управляет топологиями Streams и поддерживает API для работы с потоками данных. Вы можете запускать его как единый сервер или в распределённом режиме, масштабируя под нагрузку.

ksqlDB — это шаг вперёд в эволюции Kafka: она делает потоковую обработку доступной не только программистам, но и аналитикам, DevOps-инженерам и архитекторам данных. Это SQL-язык, который разговаривает с событиями, а не с таблицами — язык, в котором время становится таким же измерением данных, как строки и столбцы.

С помощью ksqlDB поток превращается в понятную, управляемую и интерактивную структуру, где события живут, изменяются и взаимодействуют — а данные текут так же естественно, как запросы к ним.

Сообщение Apache Kafka Tutorial 101: Архитектура, Consumer, Producer, Topic появились сначала на DataTalks.RU. Data Engineering / DWH / Data Pipeline.

Построение архитектуры Medallion для данных Bluesky в формате JSON с помощью ClickHouse

Мы так же взволнованы, как и вся остальная дата-сообщество, из-за недавнего всплеска популярности социальной сети BlueSky и её API, который позволяет получать доступ к потоку публикуемого контента.

Этот набор данных содержит поток с высокой пропускной способностью — тысячи JSON-событий в секунду, и мы подумали, что будет интересно сделать эти данные доступными для сообщества, чтобы каждый мог выполнять по ним запросы.

Во время исследования данных мы обнаружили, что во многих событиях присутствуют некорректные или повреждённые временные метки. Набор данных также содержит частые дубликаты. Поэтому мы не можем просто импортировать данные и на этом закончить — потребуется некоторая очистка.

Это идеальная возможность попробовать архитектуру Medallion, о которой мы недавно писали в блоге. В этом посте мы оживим эти концепции на практическом примере.

Мы создадим рабочий процесс, который решает эти задачи, организуя набор данных в три отдельные уровня: бронзовый, серебряный и золотой. Мы будем придерживаться принципов архитектуры Medallion и активно использовать недавно представленный тип данных JSON.

Каждый уровень будет доступен для публичных запросов в нашей демо-среде на sql.clickhouse.com, где читатели смогут самостоятельно изучить и взаимодействовать с результатами. Мы даже подготовили несколько примерных аналитических запросов, чтобы вам было проще начать!

Что такое Bluesky?

Для тех, кто не так активен в социальных сетях, вы могли пропустить недавний взлёт популярности Bluesky, которая в настоящее время набирает почти миллион пользователей в день. Bluesky — это социальная сеть, похожая на X (бывший Twitter), но, в отличие от него, она полностью открыта и децентрализована!

Bluesky, построенная на AT Protocol (ATProto), представляет собой децентрализованную платформу социальных сетей, которая позволяет пользователям самостоятельно размещать свой контент. По умолчанию данные хранятся на Bluesky Personal Data Server (PDS), но пользователи могут выбирать — размещать эти серверы (и свой контент) у себя. Такой подход отражает возврат к принципам раннего Интернета, когда пользователи имели контроль над своим контентом и связями, вместо того чтобы зависеть от централизованных платформ, которые доминируют и владеют пользовательскими данными.

Данные каждого пользователя управляются в лёгкой, открытой программной среде, где одна база данных SQLite используется для хранения. Такая структура обеспечивает взаимодействие между системами (interoperability) и гарантирует, что право собственности на контент остаётся за пользователем, даже если центральная платформа выйдет из строя или изменит свою политику.

И самое главное для нас: как и старый Twitter, Bluesky предоставляет бесплатный способ получать события — например, посты — в реальном времени, что открывает потенциально огромный набор данных для аналитики, по мере того как сеть набирает популярность.

Чтение данных Bluesky

Чтобы загрузить данные из Bluesky, мы используем недавно выпущенный Jetstream API, который упрощает потребление событий Bluesky, предоставляя потоки, закодированные в формате JSON. В отличие от оригинального firehose, который требует обработки бинарных данных CBOR и файлов CAR, Jetstream снижает сложность, делая процесс доступным для разработчиков, работающих с приложениями в реальном времени. Этот API идеально соответствует нашему случаю использования, позволяя фильтровать и обрабатывать тысячи событий в секунду из постов Bluesky, одновременно решая распространённые проблемы, такие как повреждённые данные и высокий уровень дублирования.

В нашей реализации мы подключаемся к публичному экземпляру Jetstream, потребляя непрерывный поток событий в формате JSON для загрузки. Для этого используется простой bash-скрипт, который обрабатывает поток JSON-событий в реальном времени из Jetstream.

Ссылка на полный bash-скрипт.

Вкратце, он выполняет следующее:

• Проверяет GCS bucket на наличие самого последнего файла .csv.gz, извлекает его временную метку (используемую как курсор) и применяет её для возобновления подписки Jetstream с нужной позиции. Это обеспечивает непрерывность данных и минимизирует дублирование.
• Инструмент websocat используется для подключения к Jetstream API, подписки на события и передачи JSON-потока для обработки. Параметр wantedCollections фильтрует нужные события, а cursor обеспечивает пошаговое (инкрементальное) получение данных, например:

websocat -Un --max-messages-rev $MAX_MESSAGES "$WS_URL/subscribe?wantedCollections=app.*&cursor=$cursor" > "$OUTPUT_FILE"

• Входящие данные JSON разбиваются на фрагменты по 500 000 строк, при этом каждый фрагмент представляет собой файл, где последняя временная метка используется в качестве идентификатора файла. Мы используем clickhouse-local для преобразования файла в CSV, затем сжимаем его в .gz и загружаем в GCS bucket с помощью gsutil.
• Скрипт выполняется внутри Docker-контейнера ClickHouse, который запускается каждые 3 минуты с помощью Google Cloud Run Job.

Обратите внимание, что файлы естественным образом упорядочены по своим именам, основанным на временной метке последнего события. Это критически важно для последующего эффективного инкрементального чтения из GCS bucket. Однако скрипт не гарантирует, что будут зафиксированы все события Bluesky.

Выборка (sampling) данных

На момент написания этого поста мы зафиксировали почти 1,5 миллиарда событийных строк, собранных примерно за 21 день. Мы можем использовать функцию gcs в ClickHouse, чтобы выполнить запрос к данным напрямую и определить общее количество необработанных строк.

clickhouse-cloud :) SELECT count()
FROM gcs('https://storage.googleapis.com/pme-internal/bluesky/*.gz', '', '', 'CSVWithNames')

┌────count()─┐
│ 1484500000 │ -- 1.48 billion
└────────────┘

1 row in set. Elapsed: 72.396 sec. Processed 1.48 billion rows, 205.07 GB (20.51 million rows/s., 2.83 GB/s.)
Peak memory usage: 4.85 GiB.

Мы можем взять выборку данных, используя ту же функцию, преобразовав каждую строку в тип JSON и применив формат PrettyJSONEachRow, чтобы получить читаемый результат.

SET allow_experimental_json_type = 1

SELECT data::'JSON' AS event
FROM gcs('https://storage.googleapis.com/pme-internal/bluesky/*.gz', '', '', 'CSVWithNames')
LIMIT 1
FORMAT PrettyJSONEachRow

{
  "account": {
    "active": true,
    "did": "did:plc:kjealuouxn3l6v4byxh2fhff",
    "seq": "706717212",
    "time": "2024-11-27T18:00:02.429Z"
  },
  "did": "did:plc:kjealuouxn3l6v4byxh2fhff",
  "kind": "account",
  "time_us": "1732730402720719"
}

1 row in set. Elapsed: 0.233 sec.

Хотя приведённый выше пример даёт некоторое представление о структуре событий, он не полностью отражает сложность, изменчивость и непоследовательность данных. Столбец kind в значительной степени определяет последующую структуру, при этом API передаёт три типа событий: commit, identity и account.

Краткое описание типов событий:

• commit — событие фиксации (commit) указывает на создание, обновление или удаление записи. Этот тип представляет большинство событий и включает посты, лайки и подписки.
• identity — обновление идентичности учётной записи.
• account — обновление состояния учётной записи.

Мы подробнее исследуем эти данные после их загрузки в бронзовый слой (Bronze layer).

Проблемы с данными Bluesky

Данные Bluesky, как они поступают через JetStream API, имеют ряд проблем, включая следующее:

• Повреждённый JSON (Malformed JSON) — время от времени встречаются некорректно сформированные JSON-события. Хотя они редки, такие записи могут нарушить обработку файла. Мы исключаем их с помощью функции isValidJSON, ограничивая загрузку в бронзовый слой (Bronze layer) только теми строками, для которых функция возвращает значение 1.
• Непоследовательная структура (Inconsistent structure) — хотя временная метка сбора данных (поле time_us) присутствует во всех событиях, путь JSON, содержащий время, когда событие произошло, зависит от типа события. Наш рабочий процесс должен извлекать единую согласованную временную метку, основываясь на этих условиях. Простой анализ показывает, что:
  • commit.record.createdAt можно использовать для событий типа commit;
  • identity.time — для событий identity;
  • account.time — для событий account.
• Будущие или некорректные временные метки (Future or invalid timestamps) — некоторые события имеют временные метки из будущего. Например, при выборке событий на момент написания поста 42 тысячи commit-событий имели будущие значения времени. Ещё 4 миллиона commit-событий имели метки времени, относящиеся к периоду до запуска Bluesky как сервиса.
• Повторяющиеся структуры (Repeated structures) — встречаются случаи, когда JSON содержит глубоко рекурсивные структуры. Это приводит к появлению более 1800 уникальных JSON-путей, большинство из которых, вероятно, не имеют существенной ценности для анализа содержимого.
• Дубликаты (Duplicates) — несмотря на использование курсора для поддержания последовательности данных, JetStream API создаёт дубликаты (где содержимое идентично, за исключением временной метки сбора). Удивительно, но такие дубликаты могут появляться в широком диапазоне времени — в некоторых случаях с разницей до 24 часов. Важно отметить, что большинство дубликатов встречаются в интервале около 20 минут.

Приведённые выше пункты не представляют собой исчерпывающий список проблем с качеством данных — мы продолжаем находить новые сложности! Однако, в целях наглядности и сжатости примера, в нашем демонстрационном Medallion workflow мы сосредоточимся именно на перечисленных проблемах.

Тип данных JSON в ClickHouse

JSON играет ключевую роль в реализации архитектуры Medallion для данных Bluesky, позволяя системе хранить высокодинамичную и полуструктурированную информацию в бронзовом слое (Bronze layer). Новый тип данных JSON в ClickHouse, представленный в версии 24.8, решил ключевые проблемы, с которыми сталкивались предыдущие реализации.

В отличие от традиционных подходов, которые предполагают единственный тип для каждого JSON-пути (что часто приводит к принудительному приведению типов или их преобразованию), JSON-тип в ClickHouse хранит значения каждого уникального пути и типа в отдельных подколонках (sub-columns).

Такой подход обеспечивает эффективное хранение, сводит к минимуму лишние операции ввода-вывода (I/O) и избегает затрат на приведение типов во время выполнения запроса.

Например, когда в таблицу вставляются два JSON-пути с разными типами данных, ClickHouse сохраняет значения каждого типа в отдельных подколонках. Эти подколонки могут быть запрошены независимо, что снижает ненужные операции ввода-вывода.
При этом, если запросить колонку, содержащую несколько типов данных, её значения всё равно возвращаются как единый столбец в ответе.

Кроме того, благодаря использованию смещений (offsets), ClickHouse гарантирует, что подколонки остаются плотными (dense) — то есть не хранят значения по умолчанию для отсутствующих JSON-путей. Такой подход максимизирует степень сжатия и дополнительно снижает нагрузку на I/O.

Также данный тип данных не страдает от проблемы “взрыва подколонок” (sub-column explosion), возникающей при большом количестве уникальных JSON-путей.
Это особенно важно для данных Bluesky, где при отсутствии фильтрации встречается более 1800 уникальных путей.
При этом это не мешает хранению всех этих путей — новые пути просто сохраняются в общей колонке данных, если превышен лимит (при этом статистика ускоряет выполнение запросов).

Такое оптимизированное обращение с JSON обеспечивает эффективное хранение сложных, полуструктурированных наборов данных, таких как данные Bluesky, в бронзовом слое архитектуры.
Для пользователей, заинтересованных в технических деталях реализации этого нового типа колонок, рекомендуется ознакомиться с подробным постом в нашем блоге (ссылка предоставлена в оригинале).

Бронзовый уровень для необработанных данных (Bronze, сырые данные)

Хотя исходное описание бронзового слоя (Bronze layer) не предполагает фильтрацию или преобразование данных, мы относимся к этому менее догматично и считаем, что минимальная фильтрация и недеструктивные преобразования данных могут быть полезны для исследования проблем и возможности воспроизведения данных в будущем.

Для преобразований мы рекомендуем ограничиться теми, которые можно реализовать с помощью материализованных колонок (Materialized columns), как показано ниже в нашей схеме бронзового слоя:

CREATE TABLE bluesky.bluesky_raw
(
  `data` JSON(SKIP `commit.record.reply.root.record`, SKIP `commit.record.value.value`),
  `_file` LowCardinality(String),
  `kind` LowCardinality(String) MATERIALIZED getSubcolumn(data, 'kind'),
  `scrape_ts` DateTime64(6) MATERIALIZED fromUnixTimestamp64Micro(CAST(getSubcolumn(data, 'time_us'), 'UInt64')),
  `bluesky_ts` DateTime64(6) MATERIALIZED multiIf(getSubcolumn(data, 'kind') = 'commit', parseDateTime64BestEffortOrZero(CAST(getSubcolumn(data, 'commit.record.createdAt'), 'String')), getSubcolumn(data, 'kind') = 'identity', parseDateTime64BestEffortOrZero(CAST(getSubcolumn(data, 'identity.time'), 'String')), getSubcolumn(data, 'kind') = 'account', parseDateTime64BestEffortOrZero(CAST(getSubcolumn(data, 'account.time'), 'String')), toDateTime64(0, 6)),
  `dedup_hash` String MATERIALIZED cityHash64(arrayFilter(p -> ((p.1) != 'time_us'), JSONExtractKeysAndValues(CAST(data, 'String'), 'String')))
)
ENGINE = ReplacingMergeTree
PRIMARY KEY (kind, bluesky_ts)
ORDER BY (kind, bluesky_ts, dedup_hash)

Некоторые важные замечания по этой схеме:

• Тип JSON — колонка data использует новый тип данных JSON и содержит всё событие целиком.
  Мы применяем оператор SKIP, чтобы исключить определённые пути JSON, которые, как показал анализ, были ответственны за повторяющиеся структуры, отмеченные ранее.
• Сохранение метаданных — колонка _file содержит ссылку на файл, из которого была загружена строка.
• Материализованные колонки (Materialized columns) — остальные колонки являются материализованными и вычисляются из колонки data во время вставки:
  • scrape_ts — время, когда событие было доставлено; извлекается из поля JSON time_us.
  • kind — тип события, как упоминалось ранее.
  • bluesky_ts — выполняет условную логику, извлекая временную метку события на основе значения kind; это решает проблему непоследовательной структуры и обеспечивает единый формат временных меток для всех событий.
  • dedup_hash — содержит хеш события.
• Для вычисления хеша создаётся массив всех JSON-путей и их значений, за исключением time_us (так как это поле отличается у дубликатов), с помощью функции JSONExtractKeysAndValues.
  Затем функция cityHash64 обрабатывает этот массив, создавая уникальный хеш события.
• ReplacingMergeTree — используется движок ReplacingMergeTree, который позволяет устранять дубликаты записей, имеющих одинаковые значения ключей сортировки (ORDER BY).
  Дедупликация выполняется асинхронно во время фоновых слияний, которые происходят в неопределённое время и не могут быть напрямую контролируемы — то есть дедупликация осуществляется постепенно (eventual deduplication).

В нашей схеме ключ ORDER BY включает kind и bluesky_ts, что:

• обеспечивает эффективное чтение;
• гарантирует высокую степень сжатия, группируя строки с похожими атрибутами.

Мы также добавляем dedup_hash, чтобы уникально идентифицировать строки для дедупликации, но не включаем его в PRIMARY KEY.
Это оптимизация, которая предотвращает загрузку индекса по dedup_hash в память — разумное решение, так как мы не выполняем прямые запросы по хешу.

Наш бронзовый слой выполняет минимальные преобразования данных с помощью материализованных колонок, но при этом обеспечивает возможность дедупликации.
Важно отметить, что использование ReplacingMergeTree здесь не является обязательным и не влияет на будущие слои.

Пользователи могут предпочесть обычный MergeTree, если хотят анализировать дубликаты напрямую.

Наш выбор обусловлен главным образом желанием минимизировать объём хранимых данных.

Загрузка данных из объектного хранилища (s3, object storage)

Как описано выше, наш конвейер загрузки данных (ingestion pipeline) использует инструмент websocat для потоковой передачи данных из JetStream API, сохраняя события в виде файлов .csv.gz в Google Cloud Storage (GCS).

Этот промежуточный шаг предоставляет несколько преимуществ:

• он позволяет воспроизводить данные (data replay),
• сохраняет оригинальную копию необработанных данных (raw data)
• и имитирует подход, который многие пользователи используют для загрузки данных из объектного хранилища.

Чтобы считать эти файлы из GCS в нашу таблицу бронзового слоя bluesky_raw, мы используем движок таблицы S3Queue (S3Queue table engine). Этот движок считывает данные из объектного хранилища, совместимого с S3, автоматически обрабатывает новые файлы по мере их добавления в бакет и вставляет их в указанную таблицу через материализованное представление (materialized view).

Создание этой таблицы требует небольшой DDL-команды:

CREATE TABLE bluesky.bluesky_queue
(
  `data` Nullable(String)
)
ENGINE = S3Queue('https://storage.googleapis.com/pme-internal/bluesky/*.gz', '', '', 'CSVWithNames')
SETTINGS mode = 'ordered', s3queue_buckets = 30, s3queue_processing_threads_num = 10;

Обратите внимание, что мы указываем GCS-бакет, содержащий сжатые (gzipped) файлы,
и определяем каждую строку как тип String с помощью объявления схемы.

Важно, что мы включаем «ordered mode» через настройку mode = 'ordered'. Это заставляет файлы обрабатываться в лексикографическом порядке, обеспечивая последовательную загрузку данных.

Хотя это означает, что файлы, добавленные с более ранним порядком сортировки, игнорируются, такая конфигурация поддерживает эффективную и инкрементальную обработку, и устраняет необходимость выполнять масштабные операции сравнения множеств, если файлы не имеют естественного порядка.

Наше раннее использование временных меток (timestamps) для имен файлов гарантирует, что данные обрабатываются в правильной последовательности, а движок S3Queue быстро распознаёт новые файлы, которые нужно загрузить.

Наша среда sql.clickhouse.com, в которую мы загружаем данные, состоит из трёх узлов, каждый из которых имеет 60 виртуальных процессорных ядер (vCPUs).

Параметр s3queue_processing_threads_num задаёт количество потоков для обработки файлов на каждом сервере.

Кроме того, при использовании ordered mode вводится дополнительная настройка — s3queue_buckets. Как рекомендуется, мы устанавливаем её как произведение количества реплик (3) на количество потоков обработки (10).

Чтобы потреблять строки из этой очереди, необходимо присоединить инкрементальное материализованное представление (Incremental Materialized View). Это представление читает данные из очереди, выполняет SELECT-запрос над строками, а результат отправляется в таблицу бронзового слоя bluesky_raw.

CREATE MATERIALIZED VIEW bluesky.bluesky_mv TO bluesky.bluesky_raw
(
  `data` Nullable(String)
)
AS SELECT
  data,
  _file
FROM bluesky.bluesky_queue
WHERE isValidJSON(data) = 1

Обратите внимание, что мы выполняем базовую фильтрацию уже на этом уровне:
в таблицу бронзового слоя передаются только строки, где isValidJSON(data) = 1, то есть содержащие валидный JSON.

Также мы добавляем метаданные — колонку _file, чтобы иметь запись о том, из какого gzip-файла была загружена каждая строка.

Потоковая передача Bluesky напрямую в ClickHouse (Streaming)

Обратите внимание, что ClickHouse может напрямую выполнять потоковую загрузку данных с использованием JSON-форматов ввода, как недавно продемонстрировал наш технический директор (CTO) Алексей Миловидов.

Это можно реализовать, объединив тип данных JSON и формат ввода JSON.

Например:

websocat -n "wss://jetstream1.us-east.bsky.network/subscribe?wantedCollections=app.*" | pv -l | split -l 1000 --filter='clickhouse-client --host sql-clickhouse.clickhouse.com --secure --password "" --query "INSERT INTO bluesky.bluesky_raw (data) FORMAT JSONAsObject"'

ClickPipes в ClickHouse Cloud

Хотя механизм таблиц S3Queue позволяет нам выполнять потоковую передачу данных из объектного хранилища в ClickHouse, у него есть определённые ограничения. Помимо того, что он поддерживает только S3-совместимые хранилища, он обеспечивает семантику “по крайней мере один раз” (at-least-once).

Пользователи ClickHouse Cloud могут предпочесть использовать ClickPipes — управляемое решение для загрузки данных, которое обеспечивает семантику “ровно один раз” (exactly-once), поддерживает больше источников (например, Kafka) и разделяет ресурсы загрузки и ресурсы кластера.

Эта технология может быть использована для замены S3Queue в описанной выше архитектуре с минимальной настройкой через пошаговый мастер (guided wizard).

Запросы к бронзовому уровню

Хотя мы не рекомендуем предоставлять доступ к вашей таблице уровня Bronze конечным пользователям (downstream consumers), выбранный нами ключ сортировки (ordering key) позволяет эффективно исследовать данные, выявлять дополнительные проблемы с их качеством или, при необходимости, повторно воспроизводить данные через последующие уровни архитектуры.

Мы отмечали, что во время слияния (merge) движок ReplacingMergeTree определяет дубликаты строк, используя значения столбцов, указанных в ORDER BY, как уникальный идентификатор, и сохраняет только последнюю версию записи. Однако это обеспечивает лишь постепенную (eventual) корректность — то есть не гарантирует, что все дубликаты будут удалены, поэтому полагаться на это не стоит.

Чтобы гарантировать корректные результаты, пользователям необходимо дополнять фоновое объединение (background merges) операцией удаления дубликатов во время выполнения запроса, что можно сделать с помощью оператора FINAL.
Однако это создаёт дополнительную нагрузку на ресурсы и негативно влияет на производительность запросов, что является ещё одной причиной, по которой мы не советуем предоставлять доступ к Bronze-таблицам потребителям данных.

В приведённых выше примерах запросов мы опускаем оператор FINAL, принимая небольшой уровень дублирования, поскольку это допустимо для разведочного анализа данных.

Большинство данных представляют собой commit-события (commit events):

SELECT kind, formatReadableQuantity(count()) AS c
FROM bluesky_raw
GROUP BY kind
FORMAT PrettyCompactMonoBlock
┌─kind─────┬─c──────────────┐
│ commit   │ 614.55 million │
│ account  │ 1.72 million   │
│ identity │ 1.70 million   │
└──────────┴────────────────┘

3 rows in set. Elapsed: 0.124 sec. Processed 617.97 million rows, 617.97 MB (5.00 billion rows/s., 5.00 GB/s.)
Peak memory usage: 139.03 MiB.

Внутри этих commit-событий можно исследовать типы событий с помощью синтаксиса пути JSON (JSON path syntax):

SELECT
  data.commit.collection AS collection,
  count() AS c,
  uniq(data.did) AS users
FROM bluesky_raw
WHERE kind = 'commit'
GROUP BY ALL
ORDER BY c DESC
LIMIT 10
FORMAT PrettyCompactMonoBlock

┌─collection───────────────┬─────────c─┬───users─┐
│ app.bsky.feed.like       │ 705468149 │ 7106516 │
│ app.bsky.graph.follow    │ 406406091 │ 8629730 │
│ app.bsky.feed.post       │ 137946245 │ 4323265 │
│ app.bsky.feed.repost     │  90847077 │ 2811398 │
│ app.bsky.graph.block     │  25277808 │ 1523621 │
│ app.bsky.graph.listitem  │   8464006 │  166002 │
│ app.bsky.actor.profile   │   8168943 │ 4083558 │
│ app.bsky.graph.listblock │  643292   │  216695 │
│ app.bsky.feed.threadgate │  559504   │   94202 │
│ app.bsky.feed.postgate   │  275675   │   38790 │
└──────────────────────────┴───────────┴─────────┘

10 rows in set. Elapsed: 19.923 sec. Processed 1.38 billion rows, 122.00 GB (69.50 million rows/s., 6.12 GB/s.)
Peak memory usage: 1003.91 MiB.

Мы видим, что основная часть событий — это “лайки” и “подписки (follows)”, что вполне ожидаемо.

Серебряный уровень для очищенных данных (Silver Layer)

Слой Silver (Серебряный) представляет собой следующий этап в архитектуре Medallion, преобразуя сырые данные из слоя Bronze (Бронзового) в более согласованную и структурированную форму.

Этот слой решает проблемы качества данных: выполняет дополнительную фильтрацию, стандартизирует схемы, производит преобразования и обеспечивает полное удаление дубликатов.
В ClickHouse обычно наблюдается прямая связь между таблицами Bronze и их эквивалентами в Silver.

Мы знаем, что дубликаты событий имеют одинаковые значения bluesky_ts (и других столбцов), различаясь лишь по scrape_ts, причём последнее значение может быть значительно позже.
Однако ранее мы установили, что большинство дубликатов появляются в пределах 20 минут.
Чтобы гарантировать, что в золотой слой (Gold) не попадут дубликаты, мы вводим понятие конечного окна дедупликации (finite duplication window) в слое Silver.

События будут распределяться по этим окнам дедупликации, которые смещены относительно текущего времени на основе значения bluesky_ts.
Эти «окна» периодически сбрасываются (flushed) в слой Gold, с гарантией, что в каждое окно попадёт только одна копия события.

Использование окон дедупликации избавляет нас от необходимости проводить дедупликацию за бесконечный период времени, что существенно снижает нагрузку на систему и делает задачу более управляемой.

Как мы покажем далее, это можно эффективно реализовать в ClickHouse.

Назначение событий в окна дедупликации, которые синхронизируются с реальным временем и периодически сбрасываются, предполагает, что данные доставляются без значительных задержек.

Анализ таблицы Bronze показывает, что:

• 90% событий имеют значение bluesky_ts, отличающееся от времени их поступления (извлечённого из имени файла в GCS) не более чем на 20 минут.
  Это возможно, если:
• Обработка 1 миллиона сообщений за один раз не вызывает значительных задержек;
• Время чтения и обработки через S3Queue также незначительно (это можно проверить через системные таблицы);
• Время, извлечённое из имени файла, близко к реальному времени загрузки, что подтверждается запросами к GCS.

Кроме того, более 94% событий имеют разницу между scrape_ts и bluesky_ts меньше 20 минут (в 90% случаев — даже менее 10 секунд).
Это означает, что значение scrape_ts также не отстаёт от времени поступления данных.

Понимая, что события обычно доставляются в течение 20 минут после их bluesky_ts, мы можем надёжно формировать окна дедупликации в слое Silver.
Для этого мы создаём раздел (partition) в ClickHouse для каждого 20-минутного интервала — таким образом, раздел фактически соответствует одному окну.

События распределяются по разделам в зависимости от того, в какой интервал они попадают, с помощью функции:

toStartOfInterval(bluesky_ts, toIntervalMinute(20))

Итоговая схема таблицы Silver выглядит следующим образом:

• Мы используем ReplacingMergeTree, но выполняем дедупликацию только внутри каждого раздела, то есть слияние происходит только в пределах окна.
• Для управления объёмом данных применяется TTL, который удаляет строки, старше 1440 секунд (24 часа).

Параметр ttl_only_drop_parts = 1 гарантирует, что части удаляются только тогда, когда все строки в них устарели.

CREATE TABLE bluesky.bluesky_dedup
(
  `data` JSON(SKIP `commit.record.reply.root.record`, SKIP `commit.record.value.value`),
  `kind` LowCardinality(String),
  `scrape_ts` DateTime64(6),
  `bluesky_ts` DateTime64(6),
  `dedup_hash` String
)
ENGINE = ReplacingMergeTree
PARTITION BY toStartOfInterval(bluesky_ts, toIntervalMinute(20))
ORDER BY dedup_hash
TTL toStartOfMinute(bluesky_ts) + toIntervalMinute(1440) SETTINGS ttl_only_drop_parts=1

Так как слишком большое количество разделов может привести к проблемам производительности и ошибкам вроде “Too many parts”, мы ограничиваем таблицу Silver только одними сутками данных (всего 72 окна по 20 минут). Старые данные автоматически удаляются с помощью правил TTL, сохраняя эффективность и стабильность системы.

Инкрементные материализованные представления для фильтрации

При применении фильтрации и правил дедупликации к данным уровня Bronze, пользователи часто сохраняют «негативные совпадения» (то есть записи, не прошедшие фильтры) в отдельной таблице — так называемой Dead-Letter таблице — для последующего анализа.

Так как мы планируем периодически отправлять свежие партиции из слоя Silver в слой Gold, нам нежелательно, чтобы события поступали слишком поздно.
По этой причине, а также чтобы продемонстрировать принцип “dead letter queue”, мы будем отправлять все события из слоя Bronze, у которых разница между scrape_ts и bluesky_ts превышает 20 минут, в очередь “dead letter”.

События же, у которых задержка меньше 20 минут, будут вставляться в соответствующую партицию таблицы Silver, показанную ранее.

Для реализации этого подхода мы используем две инкрементные материализованные представления (incremental materialized views).
Каждое из них выполняет SELECT-запрос к строкам, вставленным в таблицу уровня Bronze (bluesky_raw), и отправляет результаты либо:

• в таблицу dead letter queue,
• либо в таблицу Silver (bluesky_dedup).

Основное различие между этими двумя представлениями заключается в их фильтрующих условиях.

Представление для отправки строк в таблицу Silver:

CREATE MATERIALIZED VIEW bluesky.bluesky_dedup_mv TO bluesky.bluesky_dedup
(
	`data` JSON,
	`kind` LowCardinality(String),
	`scrape_ts` DateTime64(6),
	`bluesky_ts` DateTime64(6),
	`dedup_hash` String
)
AS SELECT
	data,
	kind,
	scrape_ts,
	bluesky_ts,
	dedup_hash
FROM bluesky.bluesky_raw
WHERE abs(timeDiff(scrape_ts, bluesky_ts)) < 1200

Схема таблицы Dead-Letter Queue и связанное с ней материализованное представление:

CREATE TABLE bluesky.bluesky_dlq
(
	`data` JSON(SKIP `commit.record.reply.root.record`, SKIP `commit.record.value.value`),
	`kind` LowCardinality(String),
	`scrape_ts` DateTime64(6),
	`bluesky_ts` DateTime64(6),
	`dedup_hash` String
)
ENGINE = MergeTree
ORDER BY (kind, scrape_ts)

CREATE MATERIALIZED VIEW bluesky.bluesky_dlq_mv TO bluesky.bluesky_dlq
(
	`data` JSON,
	`kind` LowCardinality(String),
	`scrape_ts` DateTime64(6),
	`bluesky_ts` DateTime64(6),
	`dedup_hash` String
)
AS SELECT
	data,
	kind,
	scrape_ts,
	bluesky_ts,
	dedup_hash
FROM bluesky.bluesky_raw
WHERE abs(timeDiff(scrape_ts, bluesky_ts)) >= 1200

Обратите внимание, что для очереди “dead letter” используется обычный движок MergeTree,
так как дедупликация здесь не требуется — эти данные предназначены для анализа проблем и диагностики, а не для основной аналитики.

Отправка данных на золотой уровень (Gold Layer)

Описанный выше процесс оставляет разделы (partitions), заполненные на уровне Silver.
Периодически нам необходимо переносить данные из этих разделов в уровень Gold, гарантируя, что все события были полностью дедуплицированы, и при этом делать это достаточно оперативно, чтобы обеспечить наличие свежих данных в слое Gold для аналитики.

Мы реализуем этот периодический перенос (flushing) с помощью Refreshable Materialized View.
Такие представления выполняются периодически по таблицам уровня Silver и позволяют выполнять сложные преобразования, включая денормализацию данных перед их записью в таблицы уровня Gold.

В нашем случае нам нужно просто периодически вставлять данные из последнего раздела, который больше не получает новых данных, в таблицу Gold.
Запрос при этом должен выполняться с использованием оператора FINAL, чтобы гарантировать, что все события дедуплицированы.

Хотя такой запрос обычно более затратен вычислительно, здесь мы можем использовать два преимущества:

• Запрос выполняется периодически — в нашем случае каждые 20 минут, что смещает нагрузку с пользовательских запросов на уровень загрузки данных.
• Мы обрабатываем только один раздел за одно выполнение. Можно ограничить дедупликацию во время выполнения только этим разделом, установив параметр do_not_merge_across_partitions_select_final=1, что дополнительно оптимизирует запрос и снижает нагрузку.

Для этого требуется определить, какой именно раздел нужно перенести в Gold при каждом выполнении.
Эта логика показана на диаграмме выше, а в кратком виде выглядит так:

• Мы определяем последний раздел в таблице Silver bluesky_dedup с помощью служебного поля _partition_id.
  Из этого значения вычитаем 40 минут, получая раздел, который был создан два окна назад (X — 2) — называем его current_partition.
• В целевой таблице уровня Gold bluesky есть столбец _rmt_partition_id,
  заполняемый refreshable materialized view, где хранится, из какого раздела уровня Silver поступило каждое событие.
  Мы используем это поле, чтобы определить последний успешно перенесённый раздел, прибавляем 20 минут,
  получая раздел, который нужно обработать следующим — next_to_process.

Если next_to_process = 1200, это значит, что таблица bluesky пуста
(0 + 1200 секунд = 1200), и ещё не было ни одной передачи данных.
В этом случае мы используем current_partition и вставляем все события, где _partition_id = current_partition.

Если next_to_process > 1200, значит, переносы уже выполнялись.
Если current_partition >= next_to_process, то мы отстаём не менее чем на 40 минут (2 окна),
и используем значение next_to_process, вставляя все события, где _partition_id = next_to_process.
Если же current_partition < next_to_process, выполняется noop (ничего не происходит) — данные не переносятся.

Эта логика устойчива к сбоям, таким как пропуски выполнения каждые 20 минут, повторные запуски или задержки выполнения. В результате формируется Refreshable Materialized View, в SELECT-запросе которого инкапсулирована описанная выше логика.

CREATE MATERIALIZED VIEW bluesky.blue_sky_dedupe_rmv
REFRESH EVERY 20 MINUTE APPEND TO bluesky.bluesky
(
  `data` JSON(SKIP `commit.record.reply.root.record`, SKIP `commit.record.value.value`),
  `kind` LowCardinality(String),
  `bluesky_ts` DateTime64(6),
  `_rmt_partition_id` LowCardinality(String)
)
AS WITH
  (
          --step 1
        SELECT toUnixTimestamp(subtractMinutes(CAST(_partition_id, 'DateTime'), 40))
        FROM bluesky.bluesky_dedup
        GROUP BY _partition_id
        ORDER BY _partition_id DESC
        LIMIT 1
  ) AS current_partition,
  (
          --step 2
        SELECT toUnixTimestamp(addMinutes(CAST(max(partition_id), 'DateTime'), 20))
        FROM bluesky.latest_partition
  ) AS next_to_process
SELECT
  data,
  kind,
  bluesky_ts,
  _partition_id AS _rmt_partition_id
FROM bluesky.bluesky_dedup
FINAL
--step 3 & 4
WHERE _partition_id = CAST(if(next_to_process = 1200, current_partition, if(current_partition >= next_to_process, next_to_process, 0)), 'String')
SETTINGS do_not_merge_across_partitions_select_final = 1

Это представление выполняется каждые 20 минут, передавая очищенные и дедуплицированные данные в уровень Gold. Следует отметить, что данные появляются в Gold с задержкой около 40 минут, хотя при необходимости пользователи могут выполнять запросы к уровню Silver для получения более свежих данных.

Внимательный читатель заметит, что в шаге 2 и на диаграмме выше наш запрос использует таблицу latest_partition, а не обращается напрямую к _rmt_partition_id в таблице bluesky уровня Gold.
Эта таблица создаётся с помощью инкрементного материализованного представления (incremental materialized view) и служит оптимизацией, которая ускоряет определение следующего раздела для обработки.

Это представление отслеживает последний вставленный раздел в таблицу Gold и выглядит следующим образом.

CREATE MATERIALIZED VIEW bluesky.latest_partition_mv TO bluesky.latest_partition
(
	`partition_id` UInt32
)
AS SELECT max(CAST(_rmt_partition_id, 'UInt32')) AS partition_id
FROM bluesky.bluesky

CREATE TABLE bluesky.latest_partition
(
	`partition_id` SimpleAggregateFunction(max, UInt32)
)
ENGINE = AggregatingMergeTree
ORDER BY tuple()

Золотой уровень для анализа данных (Gold Layer для аналитики)

Указанное выше refreshable materialized view периодически отправляет данные в таблицу уровня Gold — bluesky.

Схема этой таблицы показана ниже:

CREATE TABLE bluesky.bluesky
(
	`data` JSON(SKIP `commit.record.reply.root.record`, SKIP `commit.record.value.value`),
	`kind` LowCardinality(String),
	`bluesky_ts` DateTime64(6),
	`_rmt_partition_id` LowCardinality(String)
)
ENGINE = MergeTree
PARTITION BY toStartOfInterval(bluesky_ts, toIntervalMonth(1))
ORDER BY (kind, bluesky_ts)

Поскольку данные полностью дедуплицированы до момента вставки, мы можем использовать стандартный MergeTree.

Ключ сортировки (ORDER BY) выбирается исключительно на основе шаблонов доступа потребителей данных и с целью оптимизации сжатия.

Таблица разделена по месяцам (partitioned by month) — в первую очередь для удобства управления данными, а также потому, что ожидается, что большинство запросов будут обращаться к самым последним данным.

Обратите внимание: хотя мы по-прежнему используем тип данных JSON на этом уровне,
возможно выполнение дополнительных трансформаций данных на этапе предыдущего
refreshable materialized view — например:

• извлечение часто используемых полей в корень таблицы,
• использование столбцов типа ALIAS, чтобы упростить синтаксис запросов и повысить удобство анализа.

Материализованные представления для общих запросов (Для часто запрашиваемых метрик)

Этот слой gold должен быть полностью оптимизирован для выполнения запросов со стороны прикладных систем и потребителей данных. Хотя наш ключ сортировки направлен на то, чтобы облегчить этот процесс, не все шаблоны доступа будут одинаковыми. До настоящего времени наиболее распространённым применением инкрементных материализованных представлений было выполнение фильтрации и вставки данных между слоями. Однако наше более раннее использование представления для вычисления следующего раздела (partition) намекало на то, как ещё можно оптимизировать другие запросы.

Помимо фильтрации и отправки подмножеств данных в целевую таблицу с другими ключами сортировки (оптимизированными под иные шаблоны доступа), материализованные представления могут использоваться для предварительного вычисления агрегатов во время вставки данных в таблицу gold.

Результаты таких агрегатов будут представлять собой уменьшенную форму исходных данных (частичный набросок, если речь идёт об агрегации). Это не только упрощает последующие запросы к целевой таблице, но и обеспечивает более высокую скорость выполнения, поскольку вычисления переносятся с момента запроса на момент вставки, тем самым снижая время отклика при запросе.

Полное руководство по материализованным представлениям можно найти здесь.

В качестве примера рассмотрим наш предыдущий запрос, который вычисляет наиболее распространённые типы commit-событий:

SELECT data.commit.collection AS collection, count() AS c, uniq(data.did) AS users
FROM bluesky
WHERE kind = 'commit'
GROUP BY ALL
ORDER BY c DESC
LIMIT 10

┌─collection───────────────┬─────────c─┬───users─┐
│ app.bsky.feed.like       │ 269979403 │ 5270604 │
│ app.bsky.graph.follow    │ 150891706 │ 5631987 │
│ app.bsky.feed.post       │  46886207 │ 3083647 │
│ app.bsky.feed.repost     │  33249341 │ 1956986 │
│ app.bsky.graph.block     │   9789707 │  993578 │
│ app.bsky.graph.listitem  │   3231676 │  102020 │
│ app.bsky.actor.profile   │   1731669 │ 1280895 │
│ app.bsky.graph.listblock │  263667   │  105310 │
│ app.bsky.feed.threadgate │  215715   │   49871 │
│ app.bsky.feed.postgate   │   99625   │   19960 │
└──────────────────────────┴───────────┴─────────┘

10 rows in set. Elapsed: 6.445 sec. Processed 516.53 million rows, 45.50 GB (80.15 million rows/s., 7.06 GB/s.)
Peak memory usage: 986.51 MiB.

Для 500 миллионов событий выполнение этого запроса занимает около 6 секунд.
Чтобы преобразовать его в инкрементное материализованное представление, необходимо подготовить таблицу, которая будет получать результаты инкрементной агрегации:

CREATE TABLE bluesky.top_post_types
(
  `collection` LowCardinality(String),
  `posts` SimpleAggregateFunction(sum, UInt64),
  `users` AggregateFunction(uniq, String)
)
ENGINE = AggregatingMergeTree
ORDER BY collection

Обратите внимание, что нам необходимо использовать AggregatingMergeTree и указать ключ сортировки как ключ группировки — результаты агрегации с одинаковыми значениями этого столбца будут объединяться.

Инкрементные результаты должны храниться в специальных типах столбцов SimpleAggregateFunction и AggregateFunction — для этого необходимо указать саму функцию и связанный с ней тип данных.

Ниже показано соответствующее материализованное представление, которое заполняет эту таблицу при вставке строк в таблицу gold. Обратите внимание, что используется суффикс — State, чтобы явно сгенерировать состояние агрегации:

CREATE MATERIALIZED VIEW top_post_types_mv TO top_posts_types
AS
SELECT data.commit.collection AS collection, count() AS posts,
  uniqState(CAST(data.did, 'String')) AS users
FROM bluesky
WHERE kind = 'commit'
GROUP BY ALL

When querying this table, we use the -Merge suffix to merge aggregation states.


SELECT collection,
       sum(posts) AS posts,
       uniqMerge(users) AS users
FROM top_post_types
GROUP BY collection
ORDER BY posts DESC
LIMIT 10

10 rows in set. Elapsed: 0.042 sec.

Производительность запроса улучшилась более чем в 150 раз!

Ниже приведена финальная диаграмма архитектуры, показывающая все наши уровни:

Примеры запросов и визуализации на sql.clickhouse.com

Приведённый выше пример представляет собой очень простую демонстрацию. Эти данные доступны на сайте sql.clickhouse.com, где описанный выше рабочий процесс Medallion выполняется непрерывно. Мы также предоставили дополнительные материализованные представления в качестве примеров для эффективного выполнения запросов.

Например, чтобы определить, в какое время суток пользователи чаще всего ставят лайки, публикуют и репостят в Bluesky, можно выполнить следующий запрос:

SELECT event, hour_of_day, sum(count) as count
FROM bluesky.events_per_hour_of_day
WHERE event in ['post', 'repost', 'like']
GROUP BY event, hour_of_day
ORDER BY hour_of_day;

72 rows in set. Elapsed: 0.007 sec.

Запрос выполняется за 7 миллисекунд.

Вы можете запустить этот запрос в нашем playground, чтобы отобразить результат в виде графика.

Ниже приведено соответствующее материализованное представление и целевая таблица, которая заполняется по мере вставки строк в gold-таблицу:

CREATE TABLE bluesky.events_per_hour_of_day
(
    event LowCardinality(String),
    hour_of_day UInt8,
    count SimpleAggregateFunction(sum, UInt64)
)
ENGINE = AggregatingMergeTree
ORDER BY (event, hour_of_day);


CREATE MATERIALIZED VIEW bluesky.events_per_hour_of_day_mv TO bluesky.events_per_hour_of_day
AS SELECT
    extract(data.commit.collection, '\\.([^.]+)

Полный список запросов и соответствующих им представлений можно посмотреть здесь.
Кроме того, вы можете напрямую выполнять запросы к gold или silver таблицам!

Некоторые примеры, с которых можно начать:

• Общее количество событий (Total events)
• Когда пользователи чаще всего используют Bluesky (When do people use BlueSky)
• Самые популярные типы событий (Top event types)
• Топ типов событий по количеству (Top event types by count)
• Топ типов событий по уникальным пользователям (Top event types by unique users)
• Самые залайканные посты (Most liked posts)
• Самые залайканные посты о ClickHouse (Most liked posts about ClickHouse)
• Самые часто reposted посты (Most reposted posts)
• Самые используемые языки (Most used languages)
• Самые залайканные пользователи (Most liked users)
• Самые часто reposted пользователи (Most reposted users)

Заключительные мысли

В этом блоге мы продемонстрировали полностью реализованную архитектуру Medallion, построенную исключительно на ClickHouse, показав, как его мощные возможности позволяют преобразовывать “сырые”, полуструктурированные данные в качественные, готовые к запросам наборы данных.

Через уровни Bronze, Silver и Gold мы решили типичные проблемы, такие как повреждённые данные (malformed data), несогласованность структуры и значительное количество дубликатов.
Благодаря использованию типа данных JSON в ClickHouse, нам удалось эффективно обрабатывать по своей природе полуструктурированные и динамичные данные, при этом сохраняя высокую производительность.

Хотя эта архитектура обеспечивает надёжный и гибкий рабочий процесс, она всё же вносит определённые задержки по мере перемещения данных между слоями.
В нашем решении “окна дедупликации” (deduplication windows) помогли минимизировать эти задержки, однако остаётся компромисс между скоростью доставки данных в реальном времени и качеством данных.
Поэтому архитектура Medallion особенно хорошо подходит для наборов данных с высокой степенью дублирования и менее критичными требованиями к мгновенной доступности данных.

) AS event,
    toHour(bluesky_ts) as hour_of_day,
    count() AS count
FROM bluesky.bluesky
WHERE (kind = 'commit')
GROUP BY event, hour_of_day;

Полный список запросов и соответствующих им представлений можно посмотреть здесь.
Кроме того, вы можете напрямую выполнять запросы к gold или silver таблицам!

Некоторые примеры, с которых можно начать:

• Общее количество событий (Total events)
• Когда пользователи чаще всего используют Bluesky (When do people use BlueSky)
• Самые популярные типы событий (Top event types)
• Топ типов событий по количеству (Top event types by count)
• Топ типов событий по уникальным пользователям (Top event types by unique users)
• Самые залайканные посты (Most liked posts)
• Самые залайканные посты о ClickHouse (Most liked posts about ClickHouse)
• Самые часто reposted посты (Most reposted posts)
• Самые используемые языки (Most used languages)
• Самые залайканные пользователи (Most liked users)
• Самые часто reposted пользователи (Most reposted users)

Заключительные мысли

В этом блоге мы продемонстрировали полностью реализованную архитектуру Medallion, построенную исключительно на ClickHouse, показав, как его мощные возможности позволяют преобразовывать “сырые”, полуструктурированные данные в качественные, готовые к запросам наборы данных.

Через уровни Bronze, Silver и Gold мы решили типичные проблемы, такие как повреждённые данные (malformed data), несогласованность структуры и значительное количество дубликатов.
Благодаря использованию типа данных JSON в ClickHouse, нам удалось эффективно обрабатывать по своей природе полуструктурированные и динамичные данные, при этом сохраняя высокую производительность.

Хотя эта архитектура обеспечивает надёжный и гибкий рабочий процесс, она всё же вносит определённые задержки по мере перемещения данных между слоями.

В нашем решении “окна дедупликации” (deduplication windows) помогли минимизировать эти задержки, однако остаётся компромисс между скоростью доставки данных в реальном времени и качеством данных.

Поэтому архитектура Medallion особенно хорошо подходит для наборов данных с высокой степенью дублирования и менее критичными требованиями к мгновенной доступности данных.

Сообщение Построение архитектуры Medallion для данных Bluesky в формате JSON с помощью ClickHouse появились сначала на DataTalks.RU. Data Engineering / DWH / Data Pipeline.

Глава 5. Кодирование и эволюция

Всё изменяется и ничто не стоит на месте.
Гераклит Эфесский, цитата у Платона в «Кратиле» (360 г. до н. э.)

Приложения неизбежно со временем меняются. Новые фичи добавляются или модифицируются, когда запускаются новые продукты, пользовательские требования становятся лучше понятны или меняются бизнес-обстоятельства. В Главе 2 мы ввели понятие Эволюционности (Расширяемости): мы должны стремиться строить системы так, чтобы адаптация к изменениям была максимально простой.

В большинстве случаев изменение функциональности приложения также требует изменения данных, которые оно хранит: возможно, нужно захватить новое поле или тип записи, или, возможно, существующие данные должны быть представлены по-новому.

Модели данных по-разному справляются с такими изменениями. Реляционные базы данных обычно предполагают, что все данные в базе соответствуют одной схеме: хотя эта схема может быть изменена (через миграции схемы, т. е. операторы ALTER), в любой момент времени действует ровно одна схема. Для сравнения, базы данных со схемой «на чтение» (schema-on-read, «безсхемные») схему не навязывают, поэтому база может содержать смесь старых и новых форматов данных, записанных в разное время (см. «Гибкость схемы в документной модели»).

Когда формат данных или схема меняется, часто требуется соответствующее изменение в коде приложения (например, вы добавляете новое поле в запись, и код приложения начинает читать и записывать это поле). Однако в большом приложении изменения в коде не всегда могут быть выполнены мгновенно:

В серверных приложениях вы можете захотеть выполнить rolling upgrade (также называемый staged rollout) — выкатывать новую версию на несколько нод за раз, проверять, что новая версия работает стабильно, и постепенно проходить через все ноды. Это позволяет деплоить новые версии без даунтайма сервиса и таким образом стимулирует более частые релизы и лучшую эволюционность (расширяемость).

В клиентских приложениях вы полностью зависите от пользователя, который может не установить обновление ещё какое-то время.

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

• Обратная совместимость
  Новый код может читать данные, которые были записаны старым кодом.
• Прямая совместимость
  Старый код может читать данные, которые были записаны новым кодом.

Обратная совместимость обычно несложно достигается: как автор нового кода вы знаете формат данных, записанных старым кодом, и можете явно обрабатывать их (при необходимости просто сохранив старый код для чтения старых данных). Прямая совместимость может быть более сложной, так как она требует, чтобы старый код игнорировал добавления, сделанные более новой версией кода.

Ещё одна проблема с прямой совместимостью проиллюстрирована на рисунке 5-1. Допустим, вы добавляете поле в схему записи, и новый код создаёт запись с этим новым полем и сохраняет её в базу. Затем более старая версия кода (которая ещё не знает о новом поле) читает эту запись, обновляет её и записывает обратно. В этой ситуации желаемым поведением обычно является сохранение старым кодом нового поля нетронутым, даже если оно не может быть интерпретировано. Но если запись декодируется в объект модели, который явно не сохраняет неизвестные поля, данные могут быть утеряны — как на рисунке 5-1.

Рисунок 5-1. Когда более старая версия приложения обновляет данные, ранее записанные более новой версией приложения, данные могут быть потеряны, если не быть осторожным

В этой главе мы рассмотрим несколько форматов кодирования данных, включая JSON, XML, Protocol Buffers и Avro. В частности, мы посмотрим, как они обрабатывают изменения схем и как они поддерживают системы, в которых старые и новые данные и код должны сосуществовать. Затем мы обсудим, как эти форматы используются для хранения данных и для коммуникации: в базах данных, веб-сервисах, REST API, удалённых вызовах процедур (RPC), движках workflow и системах, основанных на событиях, таких как акторы и очереди сообщений.

Форматы кодирования данных

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

1. В памяти данные хранятся в объектах, структурах (structs), списках, массивах, хэш-таблицах, деревьях и т. д. Эти структуры данных оптимизированы для эффективного доступа и манипуляций со стороны CPU (обычно с использованием указателей).
2. Когда вы хотите записать данные в файл или отправить их по сети, необходимо закодировать их как некоторую самодостаточную последовательность байт (например, JSON-документ). Так как указатель не имеет смысла для любого другого процесса, это представление в виде последовательности байт зачастую выглядит совсем иначе, чем структуры данных, которые обычно используются в памяти.

Таким образом, необходим некий перевод между двумя представлениями. Преобразование из представления в памяти в последовательность байт называется кодированием (также известно как сериализация или маршаллинг), а обратное преобразование — декодированием (парсинг, десериализация, анмаршаллинг).

КОНФЛИКТ ТЕРМИНОВ

Термин «сериализация» к сожалению также используется в контексте транзакций, но с совершенно иным значением. Чтобы избежать перегрузки слова, в этой книге мы будем придерживаться термина «кодирование», хотя «сериализация» является, возможно, более распространённым термином.

Есть исключения, когда кодирование/декодирование не требуется — например, когда база данных работает напрямую с сжатыми данными, загруженными с диска, как обсуждается в разделе «Выполнение запросов: компиляция и векторизация». Существуют также zero-copy форматы данных, которые спроектированы для использования как во время выполнения, так и на диске/в сети без явного шага преобразования, такие как Cap’n Proto и FlatBuffers.

Однако большинство систем нуждаются в преобразовании между объектами в памяти и плоскими последовательностями байт. Так как это настолько распространённая задача, существует множество различных библиотек и форматов кодирования на выбор. Давайте сделаем краткий обзор.

Языко-специфичные форматы

Многие языки программирования поставляются со встроенной поддержкой кодирования объектов из памяти в последовательности байт. Например, в Java это java.io.Serializable, в Python — pickle, в Ruby — Marshal и т. д. Также существует множество сторонних библиотек, например Kryo для Java.

Эти библиотеки кодирования очень удобны, так как позволяют сохранять и восстанавливать объекты из памяти с минимальным дополнительным кодом. Однако у них есть несколько серьёзных проблем:

• Кодирование часто привязано к конкретному языку программирования, и чтение данных на другом языке крайне затруднительно. Если вы храните или передаёте данные в таком кодировании, вы фактически связываете себя с текущим языком программирования на очень долгое время и исключаете возможность интеграции ваших систем с системами других организаций (которые могут использовать другие языки).
• Чтобы восстановить данные в тех же типах объектов, процесс декодирования должен уметь инстанцировать произвольные классы. Это часто является источником проблем с безопасностью: если злоумышленник сможет заставить ваше приложение декодировать произвольную последовательность байт, он сможет инстанцировать произвольные классы, что в свою очередь зачастую позволяет делать ужасные вещи, такие как удалённое выполнение произвольного кода.
• Версионирование данных часто является второстепенной задачей в этих библиотеках: так как они предназначены для быстрого и лёгкого кодирования данных, они часто пренебрегают неудобными проблемами прямой и обратной совместимости.
• Эффективность (время CPU на кодирование или декодирование, а также размер закодированной структуры) также часто является второстепенной. Например, встроенная сериализация Java печально известна своей низкой производительностью и раздутым кодированием.

По этим причинам, как правило, плохая идея использовать встроенное в язык кодирование для чего-либо, кроме очень временных целей.

JSON, XML и бинарные варианты

При переходе на стандартизированные кодирования, которые могут быть записаны и прочитаны многими языками программирования, JSON и XML — очевидные претенденты. Они широко известны, широко поддерживаются и почти так же широко нелюбимы. XML часто критикуют за излишнюю многословность и ненужную сложность. Популярность JSON в основном связана с его встроенной поддержкой в веб-браузерах и простотой по сравнению с XML. CSV — ещё один популярный формат, независимый от языка, но он поддерживает только табличные данные без вложенности.

JSON, XML и CSV являются текстовыми форматами и, таким образом, в какой-то степени человекочитаемыми (хотя синтаксис — популярная тема для дискуссий). Помимо поверхностных синтаксических проблем, у них есть также более тонкие недостатки:

• Существует много неоднозначностей вокруг кодирования чисел. В XML и CSV невозможно различить число и строку, состоящую из цифр (кроме как ссылаясь на внешнюю схему). JSON различает строки и числа, но не различает целые и числа с плавающей точкой и не указывает точность.
  Это становится проблемой при работе с большими числами; например, целые числа больше 2⁵³ не могут быть точно представлены в числе с плавающей точкой двойной точности IEEE 754, поэтому такие числа становятся неточными при парсинге в языке, который использует числа с плавающей точкой, таком как JavaScript. Пример чисел больше 2⁵³ встречается в X (ранее Twitter), где для идентификации каждого поста используется 64-битное число. JSON, возвращаемый API, включает идентификаторы постов дважды: один раз как JSON-число и один раз как десятичную строку, чтобы обойти тот факт, что числа некорректно парсятся приложениями на JavaScript.

• JSON и XML имеют хорошую поддержку строк символов в Unicode (т. е. человекочитаемого текста), но они не поддерживают бинарные строки (последовательности байт без кодировки символов). Бинарные строки — полезная фича, поэтому люди обходят это ограничение, кодируя бинарные данные в текст с помощью Base64. Схема затем используется для указания, что значение должно интерпретироваться как Base64-кодированное. Это работает, но выглядит несколько костыльно и увеличивает размер данных на 33%.
• XML Schema и JSON Schema мощные, и поэтому довольно сложные для изучения и реализации. Так как правильная интерпретация данных (например, чисел и бинарных строк) зависит от информации в схеме, приложения, которые не используют схемы XML/JSON, потенциально должны хардкодить соответствующую логику кодирования/декодирования.
• У CSV вообще нет схемы, поэтому приложение должно само определять значение каждой строки и каждого столбца. Если изменение в приложении добавляет новую строку или столбец, необходимо обрабатывать это изменение вручную. CSV также является довольно размытым форматом (что произойдёт, если значение содержит запятую или символ новой строки?). Хотя его правила экранирования формально задокументированы, не все парсеры корректно их реализуют.

Несмотря на эти недостатки, JSON, XML и CSV достаточно хороши для многих целей. Скорее всего, они останутся популярными, особенно как форматы обмена данными (т. е. для отправки данных от одной организации другой). В таких ситуациях, пока стороны согласны относительно формата, часто не имеет значения, насколько красив или эффективен этот формат. Сложность заставить разные организации договориться хоть о чём-то перевешивает большинство других соображений.

JSON Schema

JSON Schema получил широкое распространение как способ моделирования данных всякий раз, когда они обмениваются между системами или записываются в хранилище. Вы найдёте JSON-схемы в веб-сервисах (см. «Web services») как часть спецификации веб-сервисов OpenAPI, в регистрах схем, таких как Confluent Schema Registry и Red Hat Apicurio Registry, а также в базах данных, таких как расширение валидатора pg_jsonschema в PostgreSQL и синтаксис валидатора $jsonSchema в MongoDB.

Спецификация JSON Schema предлагает ряд возможностей. Схемы включают стандартные примитивные типы, включая строки, числа, целые, объекты, массивы, булевы значения или null. Но JSON Schema также предоставляет отдельную спецификацию валидации, которая позволяет разработчикам накладывать ограничения на поля. Например, поле порта может иметь минимум 1 и максимум 65535.

JSON Schema может иметь либо открытую, либо закрытую модель содержимого. Открытая модель содержимого допускает существование любых полей, не определённых в схеме, с любыми типами данных, тогда как закрытая модель содержимого разрешает только явно определённые поля. Открытая модель содержимого в JSON Schema включена, когда additionalProperties установлено в true, что является значением по умолчанию. Таким образом, JSON Schema обычно является определением того, что не разрешено (а именно, недопустимые значения для любых определённых полей), а не того, что разрешено в схеме.

Открытые модели содержимого мощные, но могут быть сложными. Например, предположим, вы хотите определить отображение от целых чисел (например, ID) к строкам. JSON не имеет типа «map» или «dictionary», только тип «object», который может содержать строковые ключи и значения любого типа. Вы можете затем ограничить этот тип с помощью JSON Schema так, чтобы ключи могли содержать только цифры, а значения могли быть только строками, используя patternProperties и additionalProperties, как показано в Примере 5-1.

Пример 5-1. Пример JSON Schema с целочисленными ключами и строковыми значениями. Целочисленные ключи представлены как строки, содержащие только целые числа, так как JSON Schema требует, чтобы все ключи были строками.

{
  "$schema": "http://json-schema.org/draft-07/schema#",
  "type": "object",
  "patternProperties": {
    "^[0-9]+$": {
      "type": "string"
    }
  },
  "additionalProperties": false
}

В дополнение к открытым и закрытым моделям содержимого и валидаторам, JSON Schema поддерживает условную if/else-логику схемы, именованные типы, ссылки на удалённые схемы и многое другое. Всё это делает язык схем очень мощным. Такие возможности также делают определения громоздкими. Может быть сложно разрешать удалённые схемы, рассуждать об условных правилах или эволюционировать схемы в направлении прямой или обратной совместимости. Подобные проблемы применимы и к XML Schema.

Бинарное кодирование

JSON менее многословен, чем XML, но оба всё равно занимают много места по сравнению с бинарными форматами. Это наблюдение привело к разработке множества бинарных кодирований для JSON (MessagePack, CBOR, BSON, BJSON, UBJSON, BISON, Hessian и Smile, например) и для XML (WBXML и Fast Infoset, к примеру). Эти форматы были приняты в различных нишах, так как они более компактны и иногда быстрее парсятся, но ни один из них не получил такого широкого распространения, как текстовые версии JSON и XML.

Некоторые из этих форматов расширяют набор типов данных (например, различают целые числа и числа с плавающей точкой или добавляют поддержку бинарных строк), но в остальном они сохраняют модель данных JSON/XML неизменной. В частности, так как они не предписывают схему, они должны включать все имена полей объекта внутри закодированных данных. То есть, в бинарном кодировании JSON-документа из Примера 5-2 им придётся где-то включить строки userName, favoriteNumber и interests.

Пример 5-2. Пример записи, которую мы будем кодировать в нескольких бинарных форматах в этой главе

{
    "userName": "Martin",
    "favoriteNumber": 1337,
    "interests": ["daydreaming", "hacking"]
}

Давайте посмотрим на пример MessagePack, бинарного кодирования для JSON. На рисунке 5-2 показана последовательность байт, которую вы получите, если закодируете JSON-документ из Примера 5-2 с помощью MessagePack. Первые несколько байт выглядят так:

• Первый байт, 0x83, указывает, что далее идёт объект (старшие четыре бита = 0x80) с тремя полями (младшие четыре бита = 0x03). (Если вы задаётесь вопросом, что происходит, если объект содержит больше 15 полей, так что число полей не помещается в четыре бита, тогда используется другой индикатор типа, а число полей кодируется в двух или четырёх байтах.)
• Второй байт, 0xa8, указывает, что далее идёт строка (старшие четыре бита = 0xa0), которая имеет длину восемь байт (младшие четыре бита = 0x08).
• Следующие восемь байт — это имя поля userName в ASCII. Так как длина была указана ранее, нет необходимости в каком-либо маркере, чтобы сказать нам, где строка заканчивается (или в экранировании).
• Следующие семь байт кодируют шестибуквенное строковое значение Martin с префиксом 0xa6, и так далее.

Бинарное кодирование имеет длину 66 байт, что всего лишь немного меньше, чем 81 байт, занимаемый текстовым JSON-кодированием (с удалёнными пробелами). Все бинарные кодирования JSON похожи в этом отношении. Неясно, стоит ли такое небольшое сокращение пространства (и, возможно, ускорение парсинга) потери человекочитаемости.

В следующих разделах мы увидим, как можно добиться гораздо лучших результатов и закодировать ту же запись всего в 32 байта.

Рисунок 5-2. Пример записи (Пример 5-2), закодированной с использованием MessagePack

Protocol Buffers

Protocol Buffers (protobuf) — это библиотека бинарного кодирования, разработанная в Google. Она похожа на Apache Thrift, который был изначально разработан Facebook; большинство того, что говорится в этом разделе о Protocol Buffers, также применимо к Thrift.

Protocol Buffers требует наличия схемы для любых данных, которые кодируются. Чтобы закодировать данные из Примера 5-2 в Protocol Buffers, вы должны описать схему на языке определения интерфейсов (IDL) Protocol Buffers следующим образом:

syntax = "proto3";

message Person {
    string user_name = 1;
    int64 favorite_number = 2;
    repeated string interests = 3;
}

Protocol Buffers поставляется с инструментом генерации кода, который принимает определение схемы, подобное показанному здесь, и генерирует классы, реализующие схему на различных языках программирования. Код вашего приложения может вызывать этот сгенерированный код для кодирования или декодирования записей схемы. Язык схемы очень прост по сравнению с JSON Schema: он определяет только поля записей и их типы, но не поддерживает другие ограничения на возможные значения полей.
Кодирование Примера 5-2 с использованием кодировщика Protocol Buffers требует 33 байт, как показано на рисунке 5-3.

Рисунок 5-3. Пример записи, закодированной с использованием Protocol Buffers

Аналогично рисунку 5-2, каждое поле имеет аннотацию типа (чтобы указать, является ли оно строкой, целым числом и т. д.) и, где необходимо, указание длины (например, длина строки). Строки, встречающиеся в данных («Martin», «daydreaming», «hacking»), также закодированы как ASCII (точнее, UTF-8), аналогично предыдущему примеру.

Большое отличие по сравнению с рисунком 5-2 заключается в том, что здесь нет имён полей (userName, favoriteNumber, interests). Вместо этого закодированные данные содержат теги полей, которые являются числами (1, 2 и 3). Это те самые числа, которые указаны в определении схемы. Теги полей подобны псевдонимам для полей — это компактный способ указать, о каком поле идёт речь, без необходимости явно указывать имя поля.

Как видно, Protocol Buffers экономит ещё больше места, упаковывая тип поля и номер тега в один байт. Используются целые числа переменной длины: число 1337 кодируется в два байта, при этом старший бит каждого байта используется для указания, есть ли ещё байты далее. Это означает, что числа от –64 до 63 кодируются в одном байте, числа от –8192 до 8191 — в двух байтах и т. д. Более крупные числа используют больше байт.

Protocol Buffers не имеет явного типа списка или массива. Вместо этого модификатор repeated у поля interests указывает, что поле содержит список значений, а не одно значение. В бинарном кодировании элементы списка представлены просто как повторяющиеся вхождения одного и того же тега поля внутри одной записи.

Теги полей и эволюция схем

Мы уже говорили, что схемы неизбежно должны меняться со временем. Мы называем это эволюцией схемы. Как Protocol Buffers обрабатывает изменения схем при сохранении обратной и прямой совместимости?

Как видно из примеров, закодированная запись — это просто конкатенация её закодированных полей. Каждое поле идентифицируется по своему номеру тега (числа 1, 2, 3 в примере схемы) и аннотируется типом данных (например, строка или целое число). Если значение поля не установлено, оно просто опускается из закодированной записи. Из этого видно, что теги полей критически важны для смысла закодированных данных. Вы можете изменить имя поля в схеме, так как закодированные данные никогда не ссылаются на имена полей, но вы не можете изменить тег поля, так как это сделает все существующие закодированные данные недействительными.
Вы можете добавлять новые поля в схему, при условии, что вы присвоите каждому полю новый номер тега. Если старый код (который не знает о новых тегах, которые вы добавили) попытается прочитать данные, записанные новым кодом, включая новое поле с номером тега, который он не распознаёт, он может просто проигнорировать это поле. Аннотация типа данных позволяет парсеру определить, сколько байт нужно пропустить, и сохранить неизвестные поля, чтобы избежать проблемы, показанной на рисунке 5-1. Это сохраняет прямую совместимость: старый код может читать записи, которые были записаны новым кодом.

А как насчёт обратной совместимости? Пока у каждого поля уникальный номер тега, новый код всегда может читать старые данные, потому что номера тегов всё ещё имеют то же значение. Если поле было добавлено в новой схеме, а вы читаете старые данные, которые ещё не содержат этого поля, оно заполняется значением по умолчанию (например, пустой строкой, если тип поля — строка, или нулём, если это число).

Удаление поля — это то же самое, что добавление поля, только с обратными требованиями по обратной и прямой совместимости. Вы никогда не можете снова использовать тот же номер тега, так как где-то могут существовать данные, записанные с этим старым номером тега, и это поле должно игнорироваться новым кодом. Номера тегов, использовавшиеся в прошлом, можно зарезервировать в определении схемы, чтобы они не были забыты.

А что насчёт изменения типа данных поля? Это возможно для некоторых типов — подробности см. в документации — но есть риск, что значения будут усечены. Например, допустим, вы изменяете 32-битное целое число на 64-битное. Новый код может легко читать данные, записанные старым кодом, так как парсер может дополнить отсутствующие биты нулями. Однако если старый код читает данные, записанные новым кодом, старый код всё ещё использует 32-битную переменную для хранения значения. Если декодированное 64-битное значение не помещается в 32 бита, оно будет усечено.

Avro

Apache Avro — ещё один бинарный формат кодирования, который примечателен своей отличием от Protocol Buffers. Он был запущен в 2009 году как подпроект Hadoop в результате того, что Protocol Buffers плохо подходил для кейсов использования Hadoop.

Avro также использует схему для задания структуры кодируемых данных. У него есть два языка схем: один (Avro IDL), предназначенный для редактирования человеком, и один (основанный на JSON), который легче читается машиной. Как и в Protocol Buffers, этот язык схемы определяет только поля и их типы, но не сложные правила валидации, как в JSON Schema.

Наша примерная схема, написанная на Avro IDL, может выглядеть так:

record Person {
    string               userName;
    union { null, long } favoriteNumber = null;
    array<string>        interests;
}

Эквивалентное JSON-представление этой схемы выглядит следующим образом:

{
    "type": "record",
    "name": "Person",
    "fields": [
        {"name": "userName",       "type": "string"},
        {"name": "favoriteNumber", "type": ["null", "long"], "default": null},
        {"name": "interests",      "type": {"type": "array", "items": "string"}}
    ]
}

Прежде всего, обратите внимание, что в схеме нет номеров тегов. Если мы закодируем нашу примерную запись (Пример 5-2) с использованием этой схемы, бинарное кодирование Avro занимает всего 32 байта — самое компактное из всех рассмотренных нами кодирований. Подробное разбиение последовательности закодированных байтов показано на рисунке 5-4.
Если вы изучите последовательность байтов, вы увидите, что там нет ничего, что идентифицировало бы поля или их типы данных. Кодировка просто состоит из значений, объединённых вместе. Строка — это просто префикс длины, за которым следуют байты UTF-8, но в закодированных данных нет ничего, что указывало бы, что это строка. Это вполне может быть целое число или что-то ещё. Целое число кодируется с использованием кодирования переменной длины.

Рисунок 5-4. Пример записи, закодированной с использованием Avro

Чтобы разобрать бинарные данные, вы проходите по полям в том порядке, в котором они указаны в схеме, и используете схему, чтобы определить тип данных каждого поля. Это означает, что бинарные данные могут быть корректно декодированы только в том случае, если код, читающий данные, использует ту же самую схему, что и код, записывающий данные. Любое несоответствие в схеме между читателем и писателем приведёт к некорректно декодированным данным.
Так каким же образом Avro поддерживает эволюцию схем?

Схема писателя и схема читателя

Когда приложение хочет закодировать какие-то данные (записать их в файл или базу данных, отправить по сети и т. д.), оно кодирует данные с использованием той версии схемы, о которой ему известно — например, эта схема может быть встроена в приложение. Это называется схемой писателя.

Когда приложение хочет декодировать какие-то данные (прочитать их из файла или базы данных, получить их из сети и т. д.), оно использует две схемы: схему писателя, которая идентична использованной для кодирования, и схему читателя, которая может отличаться. Это показано на рисунке 5-5. Схема читателя определяет поля каждой записи, которые ожидает код приложения, и их типы.

Рисунок 5-5. В Protocol Buffers кодирование и декодирование могут использовать разные версии схемы. В Avro для декодирования используются две схемы: схема писателя должна быть идентична использованной при кодировании, но схема читателя может быть более старой или новой версией.

Если схема читателя и схема писателя совпадают, декодирование простое. Если они различаются, Avro устраняет расхождения, сравнивая схему писателя и схему читателя бок о бок и преобразуя данные из схемы писателя в схему читателя. Спецификация Avro точно определяет, как работает это согласование, и это показано на рисунке 5-6.
Например, не проблема, если схема писателя и схема читателя имеют поля в разном порядке, потому что при согласовании полей они сопоставляются по имени. Если код, читающий данные, встречает поле, которое присутствует в схеме писателя, но отсутствует в схеме читателя, оно игнорируется. Если код, читающий данные, ожидает какое-то поле, но схема писателя не содержит поле с таким именем, оно заполняется значением по умолчанию, объявленным в схеме читателя.

Рисунок 5-6. Читатель Avro устраняет различия между схемой писателя и схемой читателя

Правила эволюции схем

В Avro прямая совместимость (forward compatibility) означает, что в качестве писателя вы можете использовать новую версию схемы, а в качестве читателя — старую. Обратная совместимость (backward compatibility), напротив, означает, что в качестве читателя вы можете использовать новую версию схемы, а в качестве писателя — старую.

Чтобы сохранить совместимость, вы можете добавлять или удалять только те поля, которые имеют значение по умолчанию. (Поле favoriteNumber в нашей Avro-схеме имеет значение по умолчанию null.) Например, допустим, вы добавляете поле со значением по умолчанию, так что это новое поле существует в новой схеме, но отсутствует в старой. Когда читатель, использующий новую схему, читает запись, созданную со старой схемой, для отсутствующего поля подставляется значение по умолчанию.

Если вы добавите поле без значения по умолчанию, новые читатели не смогут прочитать данные, созданные старыми писателями, и это нарушит обратную совместимость. Если вы удалите поле без значения по умолчанию, старые читатели не смогут прочитать данные, созданные новыми писателями, и это нарушит прямую совместимость.

В некоторых языках программирования null допустим в качестве значения по умолчанию для любой переменной, но в Avro это не так: если вы хотите, чтобы поле могло быть равно null, вы должны использовать объединённый тип (union type). Например,

union { null, long, string } field;

указывает, что поле может быть числом, строкой или null. Вы можете использовать null в качестве значения по умолчанию только в том случае, если оно является первой ветвью объединения. Это немного более многословно, чем если бы все поля были допускающими null по умолчанию, но такая явность помогает предотвращать ошибки, точно определяя, что может, а что не может быть null.

Изменение типа данных поля возможно, при условии что Avro может преобразовать этот тип. Изменение имени поля также возможно, но немного сложнее: схема читателя может содержать псевдонимы (aliases) для имён полей, чтобы сопоставлять имена полей старой схемы писателя с этими псевдонимами. Это означает, что изменение имени поля совместимо с прошлыми версиями (backward compatible), но не с будущими (not forward compatible). Аналогично, добавление новой ветви в объединённый тип совместимо с прошлыми версиями, но не с будущими.

Но что такое схема писателя?

Здесь есть важный вопрос, который мы до сих пор обходили стороной: как читатель узнаёт схему писателя, с которой были закодированы конкретные данные? Мы не можем просто включать полную схему в каждую запись, потому что схема, скорее всего, будет намного больше самих закодированных данных, что сведёт на нет все преимущества экономии места при бинарном кодировании.

Ответ зависит от контекста, в котором используется Avro. Вот несколько примеров:

• Большой файл с множеством записей
  Распространённый вариант использования Avro — хранение большого файла, содержащего миллионы записей, все закодированные с одной и той же схемой. (Мы обсудим такую ситуацию далее.) В этом случае писатель файла может просто включить схему писателя один раз в начале файла. Avro определяет файловый формат (object container files) для этого.
• База данных с индивидуально записанными записями
  В базе данных разные записи могут быть записаны в разное время с использованием разных схем писателей — нельзя предполагать, что у всех записей будет одинаковая схема. Самое простое решение — включать номер версии в начало каждой закодированной записи и хранить список версий схем в базе данных. Читатель может получить запись, извлечь номер версии, а затем получить схему писателя для этой версии из базы данных. Используя эту схему писателя, он может декодировать остальную часть записи. Например, реестр схем Confluent для Apache Kafka и Espresso от LinkedIn работают именно так.
• Передача записей по сетевому соединению
  Когда два процесса обмениваются данными по двунаправленному сетевому соединению, они могут согласовать версию схемы при установке соединения, а затем использовать эту схему в течение всего времени соединения. Протокол RPC Avro (см. «Поток данных через сервисы: REST и RPC») работает именно так.

База данных версий схем полезна в любом случае, так как она служит документацией и даёт возможность проверить совместимость схем. В качестве номера версии можно использовать простой увеличивающийся целочисленный идентификатор или хэш от самой схемы.

Динамически генерируемые схемы

Одним из преимуществ подхода Avro по сравнению с Protocol Buffers является то, что схема не содержит никаких тегов-полей (tag numbers). Но почему это важно? В чём проблема в том, чтобы хранить в схеме несколько чисел?

Разница в том, что Avro лучше подходит для динамически генерируемых схем. Например, представим, что у вас есть реляционная база данных, содержимое которой вы хотите выгрузить в файл, и вы хотите использовать бинарный формат, чтобы избежать упомянутых ранее проблем с текстовыми форматами (JSON, CSV, XML). Если вы используете Avro, то довольно легко можете сгенерировать Avro-схему (в JSON-представлении, которое мы видели ранее) из реляционной схемы и закодировать содержимое базы данных с использованием этой схемы, выгрузив всё это в объектный контейнерный файл Avro. Вы можете сгенерировать схему записи для каждой таблицы базы данных, и каждый столбец станет полем в этой записи. Имя столбца в базе данных сопоставляется с именем поля в Avro.

Теперь, если схема базы данных изменится (например, в таблицу добавят один столбец и удалят другой), вы можете просто сгенерировать новую Avro-схему из обновлённой схемы базы данных и экспортировать данные в новой Avro-схеме. Процесс экспорта данных не должен обращать внимание на изменения схемы — он может просто выполнять преобразование схемы каждый раз при запуске. Любой, кто будет читать новые файлы данных, увидит, что поля записи изменились, но так как поля идентифицируются по имени, обновлённая схема писателя всё равно сможет быть сопоставлена со старой схемой читателя.

Напротив, если бы вы использовали Protocol Buffers для этой цели, теги полей, скорее всего, пришлось бы назначать вручную: каждый раз, когда схема базы данных меняется, администратору пришлось бы вручную обновлять сопоставление между именами столбцов базы данных и тегами полей. (Теоретически это можно автоматизировать, но генератор схем должен был бы очень осторожно следить за тем, чтобы не назначить уже использовавшиеся ранее теги.) Подобные динамически генерируемые схемы просто не были целью проектирования Protocol Buffers, тогда как для Avro это было одной из задач.

Преимущества схем

Как мы видели, Protocol Buffers и Avro используют схему для описания формата бинарного кодирования. Их языки схем намного проще, чем XML Schema или JSON Schema, которые поддерживают гораздо более детализированные правила валидации (например, «строковое значение этого поля должно соответствовать этому регулярному выражению» или «целочисленное значение этого поля должно находиться в диапазоне от 0 до 100»). Так как Protocol Buffers и Avro проще реализовать и проще использовать, они получили широкую поддержку во множестве языков программирования.

Идеи, на которых основаны эти кодировки, отнюдь не новые. Например, у них много общего с ASN.1 — языком описания схем, впервые стандартизованным в 1984 году. Он использовался для определения различных сетевых протоколов, и его бинарное кодирование (DER) до сих пор используется, например, для кодирования SSL-сертификатов (X.509). ASN.1 поддерживает эволюцию схем с помощью тегов-полей, аналогично Protocol Buffers. Однако он также очень сложный и плохо документированный, поэтому ASN.1 вряд ли является хорошим выбором для новых приложений.

Многие системы данных также реализуют собственные проприетарные бинарные форматы кодирования для своих данных. Например, большинство реляционных баз данных имеют сетевой протокол, по которому вы можете отправлять запросы в базу данных и получать ответы. Эти протоколы, как правило, специфичны для конкретной базы данных, и вендор базы данных предоставляет драйвер (например, через API ODBC или JDBC), который декодирует ответы из сетевого протокола базы в структуры данных в памяти.

Таким образом, мы видим, что хотя текстовые форматы данных, такие как JSON, XML и CSV, широко распространены, бинарные кодировки, основанные на схемах, также являются жизнеспособным вариантом. У них есть ряд полезных свойств:

• Они могут быть гораздо более компактными, чем различные «бинарные JSON»-варианты, поскольку могут опускать имена полей из закодированных данных.
• Схема является ценным видом документации, и так как схема требуется для декодирования, можно быть уверенным, что она актуальна (в то время как вручную поддерживаемая документация легко может разойтись с реальностью).
• Ведение базы данных схем позволяет проверять прямую и обратную совместимость изменений схем до того, как что-либо будет развернуто.
• Для пользователей статически типизированных языков программирования возможность генерировать код из схемы полезна, поскольку она позволяет выполнять проверку типов на этапе компиляции.

В итоге, эволюция схем обеспечивает такую же гибкость, как и базы данных JSON без схемы/схемой-на-чтение (см. «Гибкость схемы в документной модели»), при этом предоставляя лучшие гарантии для ваших данных и лучшее инструментальное обеспечение.

Режимы потоков данных

В начале этой главы мы сказали, что всякий раз, когда вы хотите отправить какие-то данные другому процессу, с которым вы не разделяете память — например, когда вы хотите отправить данные по сети или записать их в файл, — вам нужно закодировать их в виде последовательности байтов. Затем мы обсудили различные способы кодирования для этого.
Мы поговорили о прямой и обратной совместимости, которые важны для эволюционируемости (возможности легко вносить изменения, позволяя обновлять разные части вашей системы независимо и не вынуждая менять всё сразу). Совместимость — это отношение между одним процессом, который кодирует данные, и другим процессом, который их декодирует.

Это довольно абстрактная идея — существует множество способов, которыми данные могут перемещаться от одного процесса к другому. Кто кодирует данные, а кто их декодирует? В оставшейся части этой главы мы рассмотрим некоторые из наиболее распространённых способов, которыми данные передаются между процессами:

• Через базы данных (см. «Потоки данных через базы данных»)
• Через вызовы сервисов (см. «Потоки данных через сервисы: REST и RPC»)
• Через движки рабочих процессов (см. «Долговременное выполнение и рабочие процессы»)
• Через асинхронные сообщения (см. «Архитектуры, управляемые событиями»)

Потоки данных через базы данных

В базе данных процесс, который записывает данные в базу, кодирует их, а процесс, который считывает данные из базы, декодирует их. Может существовать всего один процесс, обращающийся к базе данных, и в этом случае читателем будет просто более поздняя версия того же самого процесса — тогда хранение чего-либо в базе можно рассматривать как отправку сообщения самому себе в будущем.
Обратная совместимость здесь явно необходима; в противном случае вы сами в будущем не сможете декодировать то, что записали раньше.

В общем случае несколько различных процессов часто обращаются к базе данных одновременно. Эти процессы могут быть разными приложениями или сервисами, или же просто несколькими экземплярами одного и того же сервиса (работающими параллельно ради масштабируемости или отказоустойчивости). Так или иначе, в среде, где приложение изменяется, вероятно, что некоторые процессы, обращающиеся к базе данных, будут работать на более новой версии кода, а некоторые — на более старой (например, потому что новая версия развёртывается поэтапно, и часть экземпляров уже обновлена, а часть ещё нет).

Это означает, что значение в базе данных может быть записано более новой версией кода, а затем прочитано более старой версией кода, которая всё ещё работает. Таким образом, прямая совместимость также часто требуется для баз данных.

Разные значения, записанные в разное время

База данных в целом позволяет обновлять любое значение в любое время. Это означает, что в одной и той же базе у вас могут быть некоторые значения, записанные пять миллисекунд назад, и некоторые значения, записанные пять лет назад.
Когда вы разворачиваете новую версию своего приложения (по крайней мере серверного приложения), вы можете полностью заменить старую версию на новую за несколько минут. Для содержимого базы данных это не так: пятилетние данные всё ещё будут там, в своём исходном кодировании, если вы их явно не переписали с тех пор. Это наблюдение иногда суммируют выражением «данные переживают код».

Переписать (мигрировать) данные в новую схему, безусловно, возможно, но это дорогостоящая операция на больших объёмах данных, поэтому большинство баз данных избегают её, если это возможно. Большинство реляционных баз данных позволяют выполнять простые изменения схемы, например добавлять новый столбец со значением null по умолчанию, без переписывания существующих данных. Когда старая строка считывается, база данных подставляет null для любых столбцов, которых нет в закодированных данных на диске. Таким образом, эволюция схем позволяет всей базе данных выглядеть так, будто она закодирована с помощью одной схемы, даже если в нижележащем хранилище содержатся записи, закодированные с использованием различных исторических версий схемы.

Более сложные изменения схемы — например, изменение однозначного атрибута на многозначный или перенос части данных в отдельную таблицу — всё ещё требуют переписывания данных, часто на уровне приложения. Поддержание прямой и обратной совместимости при таких миграциях остаётся исследовательской проблемой.

Архивное хранилище

Возможно, вы время от времени делаете снимок своей базы данных, скажем, для целей резервного копирования или для загрузки в хранилище данных (см. «Хранилище данных»). В этом случае дамп данных, как правило, будет закодирован с использованием последней схемы, даже если исходное кодирование в исходной базе содержало смесь версий схем разных эпох. Так как вы всё равно копируете данные, имеет смысл закодировать их копию последовательно.

Так как дамп данных записывается за один раз и впоследствии является неизменным, такие форматы, как объектные контейнерные файлы Avro, хорошо подходят. Это также хорошая возможность закодировать данные в аналитически-удобном колонко-ориентированном формате, таком как Parquet (см. «Сжатие колонок»).

Потоки данных через сервисы: REST и RPC

Когда у вас есть процессы, которым нужно обмениваться данными по сети, существует несколько способов организации такого взаимодействия. Наиболее распространённый вариант предполагает две роли: клиенты и серверы. Серверы предоставляют API по сети, а клиенты могут подключаться к серверам, чтобы делать запросы к этому API. API, предоставляемый сервером, называется сервисом.

Веб работает именно так: клиенты (веб-браузеры) делают запросы к веб-серверам, выполняя GET-запросы для загрузки HTML, CSS, JavaScript, изображений и т. д., и POST-запросы для отправки данных на сервер. API состоит из стандартизированного набора протоколов и форматов данных (HTTP, URL, SSL/TLS, HTML и т. д.). Поскольку веб-браузеры, веб-серверы и авторы сайтов в основном соглашаются с этими стандартами, вы можете использовать любой веб-браузер для доступа к любому сайту (по крайней мере, в теории!).

Веб-браузеры — не единственный тип клиентов. Например, нативные приложения, работающие на мобильных устройствах и настольных компьютерах, часто взаимодействуют с серверами, а клиентские JavaScript-приложения, работающие внутри веб-браузеров, также могут делать HTTP-запросы. В этом случае ответ сервера обычно не является HTML для отображения человеку, а представляет собой данные в кодировке, удобной для дальнейшей обработки клиентским приложением (чаще всего JSON). Хотя HTTP может использоваться как транспортный протокол, API, реализуемый поверх него, является специфичным для приложения, и клиент с сервером должны договориться о деталях этого API.

В некотором смысле сервисы похожи на базы данных: они обычно позволяют клиентам отправлять и запрашивать данные. Однако, в то время как базы данных позволяют выполнять произвольные запросы с использованием языков запросов, которые мы обсуждали в Главе 3, сервисы предоставляют специфичный для приложения API, который позволяет только те входы и выходы, которые заранее определены бизнес-логикой (кодом приложения) сервиса. Это ограничение обеспечивает определённую степень инкапсуляции: сервисы могут накладывать детальные ограничения на то, что клиенты могут и не могут делать.

Ключевая цель проектирования сервис-ориентированной/микросервисной архитектуры — упростить изменение и сопровождение приложения, сделав сервисы независимо развёртываемыми и эволюционируемыми. Общий принцип заключается в том, что каждый сервис должен находиться в ведении одной команды, и эта команда должна иметь возможность часто выпускать новые версии сервиса, не координируясь с другими командами. Следовательно, мы должны ожидать, что старые и новые версии серверов и клиентов будут работать одновременно, и поэтому кодировка данных, используемая серверами и клиентами, должна быть совместима между версиями API сервиса.

Веб-сервисы

Когда HTTP используется как базовый протокол для взаимодействия с сервисом, это называется веб-сервисом. Веб-сервисы обычно применяются при построении сервис-ориентированной или микросервисной архитектуры (обсуждалось ранее в «Микросервисы и serverless»). Термин «веб-сервис» — возможно, немного неточен, потому что веб-сервисы используются не только в вебе, но и в ряде других контекстов. Например:

• клиентское приложение, работающее на устройстве пользователя (например, нативное приложение на мобильном устройстве или веб-приложение на JavaScript в браузере), отправляющее запросы к сервису по HTTP. Эти запросы обычно идут через публичный интернет;
• один сервис, отправляющий запросы другому сервису, принадлежащему той же организации, часто находящемуся в том же дата-центре, как часть сервис-ориентированной/микросервисной архитектуры;
• один сервис, отправляющий запросы сервису, принадлежащему другой организации, обычно через интернет. Это используется для обмена данными между бэкенд-системами разных организаций. В эту категорию входят публичные API, предоставляемые онлайн-сервисами, такими как системы обработки кредитных карт или OAuth для совместного доступа к пользовательским данным.

Наиболее популярная философия проектирования сервисов — REST, которая строится на принципах HTTP. Она делает акцент на простых форматах данных, использовании URL для идентификации ресурсов и использовании функций HTTP для управления кэшированием, аутентификацией и согласованием типа содержимого. API, спроектированный в соответствии с принципами REST, называется RESTful.

Код, которому нужно вызвать API веб-сервиса, должен знать, к какому HTTP-эндпоинту обращаться и какие форматы данных отправлять и ожидать в ответ. Даже если сервис использует принципы RESTful-дизайна, клиентам всё равно нужно каким-то образом узнавать эти детали. Разработчики сервисов часто используют язык описания интерфейсов (IDL), чтобы определить и задокументировать эндпоинты API своего сервиса и модели данных, а также эволюционировать их со временем. Другие разработчики могут затем использовать описание сервиса, чтобы понять, как делать к нему запросы. Два наиболее популярных IDL для сервисов — это OpenAPI (также известный как Swagger) и gRPC. OpenAPI используется для веб-сервисов, которые отправляют и принимают JSON-данные, в то время как gRPC-сервисы отправляют и принимают Protocol Buffers.

Разработчики обычно пишут описания сервисов OpenAPI в формате JSON или YAML; см. Пример 5-3. Определение сервиса позволяет разработчикам задавать эндпоинты сервиса, документацию, версии, модели данных и многое другое. Определения gRPC выглядят похоже, но задаются с использованием описаний сервисов на Protocol Buffers.

Пример 5-3. Пример описания сервиса OpenAPI в YAML

openapi: 3.0.0
info:
  title: Ping, Pong
  version: 1.0.0
servers:
  - url: http://localhost:8080
paths:
  /ping:
    get:
      summary: Given a ping, returns a pong message
      responses:
        '200':
          description: A pong
          content:
            application/json:
              schema:
                type: object
                properties:
                  message:
                    type: string
                    example: Pong!

Даже если философия проектирования и IDL приняты, разработчикам всё равно нужно написать код, реализующий вызовы API их сервиса. Чтобы упростить эту задачу, часто используется фреймворк сервисов. Фреймворки сервисов, такие как Spring Boot, FastAPI и gRPC, позволяют разработчикам писать бизнес-логику для каждого API-эндпоинта, в то время как код фреймворка обрабатывает маршрутизацию, метрики, кэширование, аутентификацию и так далее. Пример 5-4 показывает пример реализации на Python сервиса, определённого в Примере 5-3.

Пример 5-4. Пример сервиса FastAPI, реализующего определение из Примера 5-3

from fastapi import FastAPI
from pydantic import BaseModel

app = FastAPI(title="Ping, Pong", version="1.0.0")

class PongResponse(BaseModel):
    message: str = "Pong!"

@app.get("/ping", response_model=PongResponse,
         summary="Given a ping, returns a pong message")
async def ping():
    return PongResponse()

Многие фреймворки связывают определения сервисов и серверный код. В некоторых случаях, например с популярным Python-фреймворком FastAPI, серверы пишутся в коде, а IDL генерируется автоматически. В других случаях, например с gRPC, сначала пишется определение сервиса, а затем генерируется каркас серверного кода. Оба подхода позволяют разработчикам генерировать клиентские библиотеки и SDK на различных языках из определения сервиса. Помимо генерации кода, инструменты IDL, такие как Swagger, могут генерировать документацию, проверять совместимость изменений схемы и предоставлять графический интерфейс для разработчиков для выполнения запросов и тестирования сервисов.

Проблемы удалённых вызовов процедур (RPC)

Веб-сервисы — это лишь последняя инкарнация длинной линии технологий для выполнения API-запросов по сети, многие из которых получили много шума, но имеют серьёзные проблемы. Enterprise JavaBeans (EJB) и удалённые вызовы методов Java (RMI) ограничены только Java. Distributed Component Object Model (DCOM) ограничен платформами Microsoft. Common Object Request Broker Architecture (CORBA) чрезмерно сложен и не обеспечивает обратной или прямой совместимости. SOAP и фреймворк веб-сервисов WS-* нацелены на обеспечение взаимодействия между поставщиками, но также страдают от сложности и проблем совместимости.

Все они основаны на идее удалённого вызова процедуры (RPC), существующей с 1970-х годов. Модель RPC пытается сделать так, чтобы запрос к удалённому сетевому сервису выглядел так же, как вызов функции или метода в вашем языке программирования, внутри одного процесса (эта абстракция называется прозрачность расположения). Хотя RPC поначалу кажется удобным, подход фундаментально ошибочен. Сетевой запрос сильно отличается от локального вызова функции:

Локальный вызов функции предсказуем и либо выполняется успешно, либо завершается сбоем, в зависимости только от параметров, которые находятся под вашим контролем. Сетевой запрос непредсказуем: запрос или ответ может быть потерян из-за сетевой проблемы, удалённая машина может быть медленной или недоступной, и такие проблемы полностью вне вашего контроля. Сетевые проблемы распространены, поэтому нужно предвидеть их, например, повторяя неудачный запрос.

Локальный вызов функции либо возвращает результат, либо генерирует исключение, либо не возвращает вовсе (например, зацикливается или процесс падает). У сетевого запроса есть ещё один возможный исход: он может завершиться без результата из-за таймаута. В этом случае вы просто не знаете, что произошло: если вы не получили ответ от удалённого сервиса, у вас нет способа понять, дошёл ли запрос или нет.

Если вы повторите неудачный сетевой запрос, может оказаться, что предыдущий запрос всё-таки дошёл, но был потерян только ответ. В этом случае повтор приведёт к выполнению действия несколько раз, если только вы не встроите в протокол механизм дедупликации (идемпотентность) . У локальных вызовов функций такой проблемы нет.

Каждый раз при вызове локальной функции выполнение обычно занимает примерно одно и то же время. Сетевой запрос намного медленнее вызова функции, и его задержка также крайне вариативна: в хорошие моменты он может выполняться менее чем за миллисекунду, но при перегруженной сети или перегруженном удалённом сервисе выполнение того же самого может занять много секунд.

При вызове локальной функции вы можете эффективно передавать ей ссылки (указатели) на объекты в локальной памяти. При выполнении сетевого запроса все эти параметры нужно закодировать в последовательность байтов, которую можно передать по сети. Это допустимо, если параметры — неизменяемые примитивы вроде чисел или коротких строк, но это быстро становится проблематичным при больших объёмах данных и изменяемых объектах.

Клиент и сервис могут быть реализованы на разных языках программирования, поэтому фреймворк RPC должен преобразовывать типы данных из одного языка в другой. Это может выглядеть некрасиво, так как не все языки имеют одинаковые типы — вспомните, например, проблемы JavaScript с числами больше 2⁵³ (см. «JSON, XML и бинарные варианты»). Внутри одного процесса, написанного на одном языке, такой проблемы не существует.

Все эти факторы означают, что нет смысла пытаться сделать так, чтобы удалённый сервис выглядел слишком похожим на локальный объект в вашем языке программирования, потому что это принципиально разные вещи. Часть привлекательности REST заключается в том, что он рассматривает передачу состояния по сети как процесс, отличный от вызова функции.

Балансировщики нагрузки, обнаружение сервисов и сервисные mesh

Все сервисы взаимодействуют по сети. По этой причине клиент должен знать адрес сервиса, к которому он подключается — эта задача известна как обнаружение сервисов. Самый простой подход — настроить клиент на подключение к IP-адресу и порту, на которых работает сервис. Такая конфигурация будет работать, но если сервер отключится, будет перенесён на новую машину или окажется перегружен, клиент придётся перенастраивать вручную.

Чтобы обеспечить более высокую доступность и масштабируемость, обычно запускается несколько экземпляров сервиса на разных машинах, и любой из них может обработать входящий запрос. Распределение запросов между этими экземплярами называется балансировкой нагрузки. Существует множество решений для балансировки нагрузки и обнаружения сервисов:

Аппаратные балансировщики нагрузки — это специализированное оборудование, устанавливаемое в дата-центрах. Они позволяют клиентам подключаться к одному хосту и порту, а входящие соединения перенаправляются на один из серверов, на которых запущен сервис. Такие балансировщики выявляют сетевые сбои при подключении к downstream-серверу и переключают трафик на другие серверы.

Программные балансировщики нагрузки работают почти так же, как аппаратные, но не требуют специализированного устройства. Программные балансировщики, такие как Nginx и HAProxy, представляют собой приложения, которые можно установить на стандартный сервер.

Служба доменных имён (DNS) используется для разрешения доменных имён в Интернете, когда вы открываете веб-страницу. Она поддерживает балансировку нагрузки, позволяя привязать несколько IP-адресов к одному доменному имени. Клиенты могут быть настроены на подключение к сервису по доменному имени вместо IP-адреса, а сетевая подсистема клиента выбирает, какой IP-адрес использовать при подключении. Недостаток этого подхода в том, что DNS изначально спроектирован для распространения изменений с течением времени и кэширования записей. Если серверы часто запускаются, останавливаются или перемещаются, клиенты могут видеть устаревшие IP-адреса, на которых сервис больше не работает.

Системы обнаружения сервисов используют централизованный реестр вместо DNS для отслеживания доступных конечных точек сервиса. Когда запускается новый экземпляр сервиса, он регистрируется в системе обнаружения, указывая хост и порт, на которых слушает, а также соответствующие метаданные, такие как информация о шардировании, расположение дата-центра и другое. Затем сервис периодически отправляет heartbeat-сигнал системе обнаружения, подтверждая, что он всё ещё доступен.

Когда клиент хочет подключиться к сервису, он сначала запрашивает список доступных конечных точек у системы обнаружения, а затем подключается напрямую. По сравнению с DNS, системы обнаружения лучше подходят для динамичной среды, где экземпляры сервисов часто меняются. Кроме того, они дают клиентам больше метаданных о сервисе, что позволяет им принимать более разумные решения по балансировке нагрузки.

Сервисные mesh — это сложная форма балансировки нагрузки, сочетающая программные балансировщики и системы обнаружения. В отличие от традиционных программных балансировщиков, работающих на отдельной машине, балансировщики в сервисной mesh обычно разворачиваются как встроенная клиентская библиотека или как процесс/«sidecar»-контейнер как на стороне клиента, так и на стороне сервера. Клиентские приложения подключаются к своему локальному балансировщику сервиса, который соединяется с балансировщиком на стороне сервера. Оттуда соединение маршрутизируется в локальный серверный процесс.

Хотя такая топология сложна, она имеет ряд преимуществ. Так как клиенты и серверы подключаются только через локальные соединения, шифрование соединений может полностью обрабатываться на уровне балансировщика. Это избавляет клиентов и серверы от необходимости разбираться в сложностях SSL-сертификатов и TLS. Mesh-системы также обеспечивают развитую наблюдаемость: они могут отслеживать, какие сервисы вызывают друг друга в реальном времени, выявлять сбои, фиксировать нагрузку трафика и многое другое.

Выбор подходящего решения зависит от потребностей организации. В очень динамичных средах с оркестратором, таким как Kubernetes, часто используют сервисные mesh, например Istio или Linkerd. Специализированная инфраструктура, такая как базы данных или системы обмена сообщениями, может требовать собственных специализированных балансировщиков. Более простые развёртывания лучше всего работают с программными балансировщиками нагрузки.

Кодирование данных и эволюция для RPC

Для эволюционности важно, чтобы RPC-клиенты и серверы могли изменяться и развёртываться независимо друг от друга. В отличие от потока данных через базы данных (описанных в предыдущем разделе), в случае потока данных через сервисы можно упростить задачу: разумно предположить, что сначала будут обновлены все серверы, а затем все клиенты. Таким образом, нужна только обратная совместимость для запросов и прямая совместимость для ответов.

Свойства обратной и прямой совместимости схемы RPC наследуются от используемого формата кодирования:

• gRPC (Protocol Buffers) и Avro RPC могут эволюционировать в соответствии с правилами совместимости их форматов кодирования.
• RESTful API чаще всего используют JSON для ответов и JSON или URI-encoded/form-encoded параметры запроса для запросов. Добавление необязательных параметров запроса и новых полей в объекты ответов обычно считается изменениями, сохраняющими совместимость.

Совместимость сервисов усложняется тем, что RPC часто используется для взаимодействия между организациями, и поставщик сервиса зачастую не имеет контроля над своими клиентами и не может заставить их обновиться. Поэтому совместимость должна сохраняться долго, возможно, бесконечно. Если требуется несовместимое изменение, поставщик сервиса часто вынужден поддерживать несколько версий API сервиса одновременно.

Нет единого соглашения о том, как должно работать версионирование API (то есть как клиент может указать, какую версию API он хочет использовать). Для RESTful API распространённые подходы — использовать номер версии в URL или в HTTP-заголовке Accept. Для сервисов, которые используют API-ключи для идентификации конкретного клиента, есть ещё один вариант: хранить запрашиваемую клиентом версию API на сервере и позволять обновлять этот выбор версии через отдельный административный интерфейс.

Долговременное выполнение и рабочие процессы

По определению, архитектуры на основе сервисов включают несколько сервисов, каждый из которых отвечает за разные части приложения. Рассмотрим приложение для обработки платежей, которое списывает деньги с кредитной карты и зачисляет средства на банковский счёт. Такая система, вероятно, будет иметь отдельные сервисы, отвечающие за обнаружение мошенничества, интеграцию с кредитными картами, интеграцию с банками и так далее.

Обработка одного платежа в нашем примере требует множества вызовов сервисов. Сервис процессинга платежей может вызвать сервис обнаружения мошенничества для проверки, затем вызвать сервис кредитных карт для списания средств, а затем вызвать банковский сервис для зачисления средств, как показано на Рисунке 5-7. Мы называем эту последовательность шагов рабочим процессом (workflow), а каждый шаг — задачей (task). Рабочие процессы обычно определяются как граф задач. Определения рабочих процессов могут быть написаны на языке общего назначения, на предметно-ориентированном языке (DSL) или на языке разметки, таком как Business Process Execution Language (BPEL).

ЗАДАЧИ, АКТИВНОСТИ И ФУНКЦИИ

Разные движки рабочих процессов используют разные названия для задач. Temporal, например, использует термин activity (активность). Другие называют задачи durable functions (долговременные функции). Хотя названия различаются, концепции остаются одинаковыми.

Рисунок 5-7. Пример рабочего процесса, выраженного с использованием Business Process Model and Notation (BPMN) — графической нотации

Рабочие процессы запускаются или выполняются движком рабочих процессов. Движки рабочих процессов определяют, когда запускать каждую задачу, на какой машине задача должна выполняться, что делать, если задача завершилась сбоем (например, если машина вышла из строя во время выполнения задачи), сколько задач допускается выполнять параллельно и многое другое.

Обычно движки рабочих процессов состоят из оркестратора и исполнителя. Оркестратор отвечает за планирование задач для выполнения, а исполнитель отвечает за выполнение задач. Выполнение начинается, когда рабочий процесс запускается. Оркестратор инициирует сам рабочий процесс, если пользователи определили расписание, основанное на времени, например выполнение каждый час. Также запуск выполнения рабочего процесса могут инициировать внешние источники, такие как веб-сервис или даже человек. После запуска вызываются исполнители для выполнения задач.

Существует множество видов движков рабочих процессов, которые решают разные задачи. Некоторые, такие как Airflow, Dagster и Prefect, интегрируются с системами данных и оркестрируют ETL-задачи. Другие, такие как Camunda и Orkes, предоставляют графическую нотацию для рабочих процессов (например, BPMN, используемую на рисунке 5-7), чтобы не-инженеры могли проще определять и выполнять рабочие процессы. Третьи, такие как Temporal и Restate, обеспечивают долговременное выполнение.

Долговременное выполнение

Фреймворки долговременного выполнения стали популярным способом построения архитектур на основе сервисов, которым требуется транзакционность. В нашем примере с платежами мы хотим обработать каждый платёж ровно один раз. Сбой во время выполнения рабочего процесса может привести к списанию с кредитной карты без соответствующего зачисления средств на банковский счёт. В архитектуре на основе сервисов мы не можем просто обернуть эти две задачи в транзакцию базы данных. Более того, мы можем взаимодействовать с внешними платёжными шлюзами, над которыми у нас ограниченный контроль.

Фреймворки долговременного выполнения — это способ обеспечить семантику «ровно один раз» для рабочих процессов. Если задача завершается сбоем, фреймворк перезапустит задачу, но пропустит любые RPC-вызовы или изменения состояния, которые задача успешно выполнила до сбоя. Вместо этого фреймворк «притворится», что совершает вызов, но вернёт результаты из предыдущего вызова. Это возможно потому, что фреймворки долговременного выполнения записывают все RPC и изменения состояния в надёжное хранилище, например в журнал предварительной записи (write-ahead log).

Пример 5-5. Фрагмент определения рабочего процесса в Temporal для платёжного процесса, показанного на рисунке 5-7.

@workflow.defn
class PaymentWorkflow:
    @workflow.run
    async def run(self, payment: PaymentRequest) -> PaymentResult:
        is_fraud = await workflow.execute_activity(
            check_fraud,
            payment,
            start_to_close_timeout=timedelta(seconds=15),
        )
        if is_fraud:
            return PaymentResultFraudulent
        credit_card_response = await workflow.execute_activity(
            debit_credit_card,
            payment,
            start_to_close_timeout=timedelta(seconds=15),
        )
        # ...

Фреймворки, такие как Temporal, не лишены своих сложностей. Внешние сервисы, такие как сторонний платёжный шлюз в нашем примере, всё равно должны предоставлять идемпотентный API. Разработчики должны помнить о необходимости использовать уникальные идентификаторы для этих API, чтобы предотвратить повторное выполнение. И поскольку фреймворки долговременного выполнения логируют каждый RPC-вызов по порядку, они ожидают, что последующее выполнение будет совершать те же RPC-вызовы в том же порядке. Это делает изменения в коде хрупкими. Вы можете внести неопределённое поведение просто изменив порядок вызовов функций.

Аналогично, поскольку фреймворки долговременного выполнения ожидают воспроизведения всего кода детерминированным образом (одни и те же входные данные дают одни и те же выходные), недетерминированный код, такой как генераторы случайных чисел или системные часы, является проблемой. Фреймворки часто предоставляют собственные, детерминированные реализации таких библиотечных функций, но нужно помнить, чтобы именно их использовать. В некоторых случаях, таких как инструмент workflowcheck в Temporal, фреймворки предоставляют статические анализаторы, чтобы определить, введено ли недетерминированное поведение.

ПРИМЕЧАНИЕ
Сделать код детерминированным — мощная идея, но трудно реализуемая надёжным образом.

Архитектуры, управляемые событиями

В этом заключительном разделе мы кратко рассмотрим архитектуры, управляемые событиями, которые представляют собой ещё один способ передачи закодированных данных от одного процесса к другому. Запрос называется событием или сообщением; в отличие от RPC, отправитель обычно не ждёт, пока получатель обработает событие. Более того, события, как правило, не отправляются получателю через прямое сетевое соединение, а проходят через посредника, называемого брокером сообщений (также event broker, message queue или message-oriented middleware), который временно сохраняет сообщение.

Использование брокера сообщений имеет несколько преимуществ по сравнению с прямым RPC:

• Он может выступать в роли буфера, если получатель недоступен или перегружен, тем самым повышая надёжность системы.
• Он может автоматически повторно доставлять сообщения процессу, который вышел из строя, и тем самым предотвращает их потерю.
• Он устраняет необходимость в обнаружении сервисов, так как отправителям не нужно напрямую подключаться к IP-адресу получателя.
• Он позволяет отправить одно и то же сообщение нескольким получателям.
• Он логически отделяет отправителя от получателя (отправитель просто публикует сообщения и не заботится о том, кто их потребляет).

Общение через брокера сообщений является асинхронным: отправитель не ждёт доставки сообщения, а просто отправляет его и забывает. Однако можно реализовать синхронную модель, похожую на RPC, если заставить отправителя ждать ответа на отдельном канале.

Брокеры сообщений

В прошлом рынок брокеров сообщений был под контролем коммерческого корпоративного ПО от компаний, таких как TIBCO, IBM WebSphere и webMethods, прежде чем популярность приобрели открытые реализации, такие как RabbitMQ, ActiveMQ, HornetQ, NATS и Apache Kafka. Совсем недавно получили распространение облачные сервисы, такие как Amazon Kinesis, Azure Service Bus и Google Cloud Pub/Sub.

Подробная семантика доставки зависит от реализации и конфигурации, но в целом чаще всего используются два шаблона распределения сообщений:

Один процесс добавляет сообщение в именованную очередь, и брокер доставляет это сообщение потребителю этой очереди. Если потребителей несколько, сообщение получает один из них.

Один процесс публикует сообщение в именованную тему, и брокер доставляет это сообщение всем подписчикам этой темы. Если подписчиков несколько, сообщение получает каждый.

Брокеры сообщений, как правило, не навязывают какой-либо конкретной модели данных — сообщение представляет собой просто последовательность байтов с некоторыми метаданными, поэтому можно использовать любой формат кодирования. Общий подход — использовать Protocol Buffers, Avro или JSON, а вместе с брокером сообщений развёртывать реестр схем, чтобы хранить все допустимые версии схем и проверять их совместимость. Также можно использовать AsyncAPI, эквивалент OpenAPI для обмена сообщениями, чтобы задавать схему сообщений.

Брокеры сообщений различаются по степени долговечности хранения сообщений. Многие записывают сообщения на диск, чтобы они не были потеряны в случае сбоя брокера или необходимости его перезапуска. В отличие от баз данных, многие брокеры сообщений автоматически удаляют сообщения после того, как они были потреблены. Некоторые брокеры можно настроить на хранение сообщений бессрочно — это требуется, если вы хотите использовать event sourcing (см. “Event Sourcing and CQRS”).

Если потребитель публикует сообщения повторно в другую тему, возможно, потребуется позаботиться о сохранении неизвестных полей, чтобы предотвратить проблему, описанную ранее в контексте баз данных (рисунок 5-1).

Распределённые акторные фреймворки

Модель акторов — это модель программирования для организации параллелизма в рамках одного процесса. Вместо того чтобы работать напрямую с потоками (и связанными с ними проблемами гонок, блокировок и взаимоблокировок), логика инкапсулируется в акторах. Каждый актор обычно представляет одного клиента или сущность, может иметь некоторое локальное состояние (которое не разделяется ни с какими другими акторами) и обменивается сообщениями с другими акторами посредством отправки и получения асинхронных сообщений. Доставка сообщений не гарантируется: в определённых сценариях ошибок сообщения будут потеряны. Так как каждый актор обрабатывает только одно сообщение за раз, ему не нужно беспокоиться о потоках, и каждый актор может планироваться независимо фреймворком.

В распределённых акторных фреймворках, таких как Akka, Orleans и Erlang/OTP, эта модель программирования используется для масштабирования приложения на несколько узлов. Механизм передачи сообщений используется тот же, независимо от того, находятся ли отправитель и получатель на одном узле или на разных. Если они находятся на разных узлах, сообщение прозрачно кодируется в последовательность байтов, отправляется по сети и декодируется на другой стороне.

Прозрачность расположения работает лучше в акторной модели, чем в RPC, потому что акторная модель уже предполагает, что сообщения могут быть потеряны даже в пределах одного процесса. Хотя задержка по сети, вероятно, выше, чем в пределах одного процесса, при использовании акторной модели существует меньше фундаментального несоответствия между локальной и удалённой коммуникацией.

Распределённый акторный фреймворк по сути объединяет брокер сообщений и модель акторов в единый фреймворк. Однако если вы хотите выполнять пошаговые обновления вашего акторного приложения, вам всё равно нужно учитывать прямую и обратную совместимость, поскольку сообщения могут отправляться с узла, работающего на новой версии, на узел со старой версией, и наоборот. Это можно реализовать с помощью одного из форматов кодирования, рассмотренных в этой главе.

Резюме по главе 5

В этой главе мы рассмотрели несколько способов преобразования структур данных в байты в сети или байты на диске. Мы увидели, что детали этих кодировок влияют не только на их эффективность, но, что более важно, на архитектуру приложений и ваши возможности по их развитию.

В частности, многим сервисам необходимо поддерживать пошаговые обновления, при которых новая версия сервиса развёртывается постепенно на нескольких узлах, а не сразу на всех. Пошаговые обновления позволяют выпускать новые версии сервиса без простоев (тем самым поощряя частые небольшие релизы вместо редких крупных) и делают развёртывания менее рискованными (так как ошибочные релизы могут быть обнаружены и откатаны до того, как они затронут большое количество пользователей). Эти свойства чрезвычайно полезны для эволюционности — простоты внесения изменений в приложение.

Во время пошаговых обновлений или по разным другим причинам мы должны предполагать, что разные узлы запускают разные версии кода нашего приложения. Таким образом, важно, чтобы все данные, циркулирующие в системе, кодировались таким образом, чтобы обеспечивать обратную совместимость (новый код может читать старые данные) и прямую совместимость (старый код может читать новые данные).

Мы обсудили несколько форматов кодирования данных и их свойства совместимости:

• Зависимые от языка программирования кодировки ограничены одним языком и часто не обеспечивают прямой и обратной совместимости.
• Текстовые форматы вроде JSON, XML и CSV широко распространены, и их совместимость зависит от того, как именно вы их используете. У них есть необязательные языки схем, которые иногда помогают, а иногда мешают. Эти форматы несколько расплывчаты в отношении типов данных, поэтому нужно быть осторожным с числами и бинарными строками.
• Бинарные форматы, управляемые схемами, такие как Protocol Buffers и Avro, позволяют выполнять компактное и эффективное кодирование с чётко определёнными правилами прямой и обратной совместимости. Схемы могут быть полезны для документации и генерации кода в статически типизированных языках. Однако у этих форматов есть недостаток: данные нужно декодировать, прежде чем они станут читаемыми человеком.

Мы также обсудили несколько моделей передачи данных, показывающих различные сценарии, в которых кодировки данных имеют значение:

• Базы данных, где процесс записи в базу кодирует данные, а процесс чтения из базы их декодирует.
• RPC и REST API, где клиент кодирует запрос, сервер декодирует запрос и кодирует ответ, а клиент в конце концов декодирует ответ.
• Архитектуры, управляемые событиями (с использованием брокеров сообщений или акторов), где узлы обмениваются сообщениями, закодированными отправителем и декодированными получателем.

Мы можем заключить, что при должном внимании обратная/прямая совместимость и пошаговые обновления вполне достижимы. Пусть эволюция вашего приложения будет быстрой, а развёртывания — частыми.

Сообщение Глава 5. Кодирование и Эволюция (Encoding and Evolution) появились сначала на DataTalks.RU. Data Engineering / DWH / Data Pipeline.