Как LinkedIn случайно создал идеальную архитектуру для ИИ-агентов (история Apache Kafka и Pinot)

TL;DR: LinkedIn создал функцию «Кто смотрел профиль» → Породил Apache Kafka и Pinot → Случайно решил проблемы ИИ-агентов за 10 лет до их появления. Главный инсайт: Ваша база данных не готова к тому, что ИИ-агент будет запускать 100 запросов параллельно вместо одного.

Введение: От простого счетчика к революции в данных

Представьте: вы заходите в LinkedIn и видите «23 человека просмотрели ваш профиль». Простая цифра, правда?

Неправда.

За этой цифрой стоит архитектура, которая:

Обрабатывает 10 000 запросов в секунду
Отвечает за 100 миллисекунд
Породила два open-source гиганта (Apache Kafka и Pinot)
Случайно решила проблемы ИИ-агентов за 10 лет до их появления

История этой функции — это не просто техническая байка из Кремниевой долины. Это blueprint для будущего, где вашими главными пользователями станут не люди, а автономные ИИ-агенты.

Давайте разберем 4 ключевых урока.

Урок 1: Одна функция → Два open-source гиганта

Проблема LinkedIn (2010)

В 2010 году LinkedIn был «кладбищем резюме». Люди загружали профили и… всё. Никакой активности, никакого engagement.

Команда запустила эксперимент: «Кто просматривал ваш профиль?»

Результат? 💥 Взрывной рост активности.

Но возникла техническая проблема:

1 миллиард пользователей хотят знать, кто их смотрел
10 000 запросов в секунду в пиковые часы
Задержка должна быть < 100 мс (иначе приложение «тормозит»)
Данные должны быть свежими (не вчерашними)

Рождение Apache Kafka (2010)

Существующие message queue системы не справлялись. LinkedIn создал Kafka — распределенную платформу потоковой передачи данных.

Ключевые принципы Kafka:

1
2
3
4
1. События как граждане первого класса
2. Горизонтальное масштабирование
3. Fault-tolerance из коробки
4. Throughput > 1M событий/сек

Каждый клик, просмотр, лайк — это событие в Kafka. Система стала «центральной нервной системой» LinkedIn.

Рождение Apache Pinot (2013)

Kafka собирала события, но как их мгновенно анализировать?

Традиционные OLAP системы:

❌ Слишком медленные (секунды, не миллисекунды)
❌ Не справляются с concurrency (1000+ параллельных запросов)
❌ Batch-ориентированные (данные устаревают)

LinkedIn создал Pinot — real-time OLAP базу данных.

Архитектура Pinot:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
Ingestion:
  - Real-time: прямо из Kafka
  - Batch: исторические данные

Indexing:
  - Inverted Index: текстовый поиск
  - Range Index: числовые диапазоны
  - JSON Index: nested структуры
  - Vector Index: семантический поиск (новое!)

Query:
  - Latency: < 100ms на 99 перцентиле
  - Concurrency: 10K+ QPS
  - Freshness: секунды от события до query

Результат: Одна user-facing функция породила две технологии, которые сегодня используют Uber, Stripe, Walmart и десятки других компаний.

Урок 2: Лучшая аналитика — та, что видит клиент

Два мира аналитики

Мир 1: Internal Analytics (для менеджеров)

1
2
3
4
# Типичный сценарий
analyst.run_query("SELECT revenue FROM sales WHERE date = yesterday")
analyst.go_get_coffee()  # Запрос выполняется 30 секунд
analyst.view_dashboard()  # T+1 данные (вчерашние)

Мир 2: User-Facing Analytics (для клиентов)

1
2
3
4
5
# LinkedIn сценарий
user.clicks("Who viewed my profile")
# Ожидание: < 100ms
# Свежесть: real-time
# Concurrency: 1M+ users одновременно

Триединый вызов user-facing analytics

1. Data Freshness (Свежесть)

Internal: «Данные за вчера? Норм.»
User-facing: «Кто-то посмотрел профиль? Хочу знать СЕЙЧАС.»

2. Query Latency (Задержка)

Internal: «30 секунд? Схожу за кофе.»
User-facing: «100ms или пользователь уйдет.»

3. Concurrency (Параллелизм)

Internal: 10-100 аналитиков
User-facing: 1M+ пользователей одновременно

Почему это революция?

«Настоящая ценность данных раскрывается, когда вы возвращаете их клиентам, а не запираете в дашбордах для менеджеров.»

Примеры user-facing analytics сегодня:

Spotify Wrapped: Ваша музыкальная статистика
Strava: Анализ тренировок в real-time
Uber: «Ваш водитель прибудет через 3 минуты»
Trading apps: Котировки и портфель в real-time

Урок 3: ИИ-агенты — это машины, а не люди (и ваша БД не готова)

Человек vs ИИ-агент: Паттерны запросов

Человек:

1
2
3
4
5
-- Один запрос, жду ответ
SELECT * FROM users WHERE country = 'Russia'
-- Думаю...
-- Еще один запрос
SELECT avg(age) FROM users WHERE country = 'Russia'

ИИ-агент:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
# Задача: "Найди аномалии в данных"
# Агент генерирует 20 запросов ПАРАЛЛЕЛЬНО:

queries = [
    "SELECT * FROM posts WHERE likes > 10000 AND comments < 10",
    "SELECT user_id, follower_growth FROM users WHERE growth_rate > 1000%",
    "SELECT content FROM posts WHERE created_at - user_created_at < 1_day",
    # ... еще 17 запросов
]

# Запускает все одновременно
results = parallel_execute(queries)
# Анализирует корреляции
find_patterns(results)

Реальный пример из демо

В одной демонстрации ИИ-агенту дали задачу: «Найди подозрительные аккаунты в соцсети»

Агент самостоятельно:

Сгенерировал 15-20 SQL запросов
Искал паттерны:
- «Посты с 10K+ лайков, но < 10 комментов»
- «Рост подписчиков > 1000% за день»
- «Аккаунты, созданные вчера с 100K подписчиков»
Выполнил все запросы параллельно
Нашел корреляции между результатами

Что это значит для вашей архитектуры?

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
Традиционная БД:
  Оптимизирована для: Sequential queries от людей
  Concurrency: 10-100 users
  Pattern: Query → Wait → Query

Требования ИИ-агентов:
  Оптимизирована для: Parallel burst queries
  Concurrency: 1000+ queries от ОДНОГО агента
  Pattern: 100 queries одновременно → Analyze

Решение: Apache Pinot
  - Designed для 10K+ QPS
  - Sub-100ms latency на 99%
  - Real-time freshness

Ключевой инсайт: Если ваша БД «тормозит» от 10 аналитиков, представьте, что будет, когда 100 ИИ-агентов начнут по 100 запросов каждый.

Урок 4: Будущее = Векторный поиск + Real-time фильтры

Почему чистого векторного поиска недостаточно

Типичный векторный поиск:

1
2
# Найди документы, похожие по смыслу на "authentication failure"
vector_db.search("authentication failure", k=10)

Реальный бизнес-запрос:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
# Найди похожее на "authentication failure", НО:
# - Только за последний час
# - Только для Enterprise клиентов
# - Только в EU регионе
# - Отсортируй по severity

vector_db.search(
    query="authentication failure",
    filters={
        "timestamp": "> now() - 1h",
        "plan": "Enterprise",
        "region": "EU"
    },
    order_by="severity DESC"
)

Проблема векторных БД

Чистые векторные БД (Pinecone, Weaviate) плохо справляются с гибридными запросами:

Сначала векторный поиск (медленно на большом объеме)
Потом фильтрация (неэффективно)
Производительность деградирует с ростом фильтров

Решение Pinot: Гибридная архитектура

1
2
3
4
5
6
7
8
Apache Pinot индексы:
  Inverted Index: Текстовый поиск
  Range Index: Числовые диапазоны
  JSON Index: Nested структуры
  Timestamp Index: Time-series данные
  Vector Index: Семантический поиск (NEW!)

Магия: ВСЕ индексы работают ВМЕСТЕ в одном запросе

Пример гибридного запроса в Pinot:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
SELECT
  log_message,
  COSINE_DISTANCE(embedding, [0.1, 0.2, ...]) as similarity
FROM logs
WHERE
  timestamp > NOW() - INTERVAL '1' HOUR
  AND customer_tier = 'Enterprise'
  AND region = 'EU'
  AND TEXT_MATCH(log_message, 'error OR failure')
ORDER BY similarity ASC
LIMIT 100

Результат:

⚡ 10-100x быстрее чистых векторных БД на гибридных запросах
✅ Один движок для всех типов поиска
🔄 Real-time ingestion из Kafka

Практические выводы: Что делать прямо сейчас?

Если вы строите user-facing продукт:

Переосмыслите аналитику
- Не «дашборды для менеджеров»
- А «инсайты для пользователей»

Проверьте готовность к real-time

1
2
3
4
5
6
# Ваш чек-лист:
□ Data freshness < 1 секунда?
□ Query latency < 100ms?
□ Concurrency > 1000 QPS?

Если хотя бы один "нет" → изучайте Kafka + Pinot

Если вы внедряете ИИ-агентов:

Протестируйте нагрузку

1
2
3
4
# Симуляция ИИ-агента
for _ in range(100):
    thread.start(run_random_query)
# Ваша БД выжила?

Подготовьте архитектуру
- Event streaming (Kafka) для сбора данных
- Real-time OLAP (Pinot) для аналитики
- Гибридные индексы для векторного + структурированного поиска

Если вы data engineer:

Изучите стек LinkedIn
- Apache Kafka — уже industry standard
- Apache Pinot — набирает momentum

Попробуйте в песочнице

1
2
3
# Quick start с Docker
docker run -p 9000:9000 apachepinot/pinot:latest \
  QuickStart -type hybrid

Заключение: История повторяется

2010: LinkedIn создал user-facing analytics → Породил Kafka и Pinot

2025: ИИ-агенты становятся новыми «users» → Требуют ту же архитектуру

История LinkedIn учит нас главному:

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

Функция «Кто смотрел профиль» была создана для увеличения engagement.

Но случайно решила проблемы, которые появятся через 15 лет — когда ИИ-агенты начнут «смотреть» наши данные со скоростью 10 000 запросов в секунду.

Вопрос не в том, готова ли ваша инфраструктура к ИИ-агентам.

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

Полезные ссылки

Технологии

Кейсы использования

Для разработчиков

Есть опыт работы с Kafka или Pinot? Внедряете ИИ-агентов? Поделитесь в комментариях или напишите мне в Telegram!

Как LinkedIn случайно создал идеальную архитектуру для ИИ-агентов (история Apache Kafka и Pinot)#

Введение: От простого счетчика к революции в данных#

Урок 1: Одна функция → Два open-source гиганта#

Проблема LinkedIn (2010)#

Рождение Apache Kafka (2010)#

Рождение Apache Pinot (2013)#

Урок 2: Лучшая аналитика — та, что видит клиент#

Два мира аналитики#

Триединый вызов user-facing analytics#

Почему это революция?#

Урок 3: ИИ-агенты — это машины, а не люди (и ваша БД не готова)#

Человек vs ИИ-агент: Паттерны запросов#

Реальный пример из демо#

Что это значит для вашей архитектуры?#

Урок 4: Будущее = Векторный поиск + Real-time фильтры#

Почему чистого векторного поиска недостаточно#

Проблема векторных БД#

Решение Pinot: Гибридная архитектура#

Практические выводы: Что делать прямо сейчас?#

Если вы строите user-facing продукт:#

Если вы внедряете ИИ-агентов:#

Если вы data engineer:#

Заключение: История повторяется#

Полезные ссылки#

Технологии#

Кейсы использования#

Для разработчиков#