Сколько должно быть Partition в Topic?

Сколько должно быть Partition в Topic

Это фундаментальный вопрос о дизайне Kafka системы. Правильное количество partitions критично для производительности.

Основной принцип

Количество partitions определяет:
1. Максимальный throughput (параллелизм)
2. Возможность масштабирования
3. Задержку обработки (latency)
4. Хранилище и ресурсы broker

Как рассчитать оптимальное количество partitions

Формула

Min Partitions = (Target Throughput) / (Consumer Throughput)

Примеры:

1. Topic: "orders"
   Target throughput: 100,000 msg/sec
   Single consumer throughput: 30,000 msg/sec
   
   Partitions = 100,000 / 30,000 = 3.33 → 4 partitions

2. Topic: "page_views" 
   Target throughput: 1,000,000 msg/sec
   Single consumer throughput: 30,000 msg/sec
   
   Partitions = 1,000,000 / 30,000 = 33.33 → 34 partitions

Факторы для расчета

1. Текущая нагрузка (messages/sec)
2. Планируемая нагрузка через 1-2 года
3. Время обработки сообщения
4. Требования по latency (задержка)
5. Replication factor (безопасность)
6. Storage constraints (место на диске)

Практические рекомендации

Малые topic (< 1000 msg/sec)

Опция 1: Single partition
- Используйте: нет требований к parallelism
- Пример: "admin_logs", "config_changes"
- Плюсы: просто, нет rebalancing
- Минусы: нет масштабирования

Опция 2: 2-3 partitions
- Используйте: есть несколько consumers
- Пример: "user_events"
- Плюсы: базовый parallelism
- Минусы: ограниченное масштабирование

Средние topic (1k - 100k msg/sec)

Рекомендация: 4-8 partitions

Примеры:
- "payments" (high value, moderate throughput) → 6 partitions
- "click_events" → 8 partitions
- "notifications" → 4 partitions

Основание:
- Хороший баланс между parallelism и complexity
- Достаточно для масштабирования
- Manageable для мониторинга

Большие topic (> 100k msg/sec)

Рекомендация: 16-128 partitions

Примеры:
- "pageviews" (миллионы в день) → 64 partitions
- "metrics" (очень активна) → 128 partitions
- "events" (общая очередь) → 32 partitions

Основание:
- Максимальный parallelism
- Множество consumers

Практический расчёт на примере

Сценарий: E-commerce platform

1. Topic: "orders"
   - Текущая нагрузка: 10,000 orders/sec
   - Планируемая за 2 года: 50,000 orders/sec
   - Processing time per order: 100ms
   - Concurrency (parallelism): нужен максимальный
   
   Расчёт:
   Single consumer throughput = 1000ms / 100ms = 10 orders/sec
   
   Для 10k: 10,000 / 10 = 1000 consumers (слишком много!)
   Нереально иметь 1000 consumers
   
   Вывод: обработка слишком долгая, нужна оптимизация
   
   Если оптимизировать до 10ms processing:
   Single consumer throughput = 1000ms / 10ms = 100 orders/sec
   
   Для 10k: 10,000 / 100 = 100 consumers (все ещё много)
   Для 50k: 50,000 / 100 = 500 consumers (impossible)
   
   Вывод: нужна параллелизация на стороне consumer
   (несколько потоков в приложении)
   
   Практический расчёт:
   - Один сервер может иметь максимум ~50 threads
   - Типично 10 consumers на сервер
   - Для 50,000 orders/sec нужно: 500 потоков = 50 серверов
   
   Но Kafka partitions != потоки consumer
   
   Рекомендация:
   Partitions = 50,000 / 500 = 100 partitions
   (каждый partition обрабатывается 1 consumer, но consumer может быть многопоточный)

Когда изменять количество partitions

Увеличение partitions

Признаки необходимости:
1. Consumer lag > 1000 messages (отстаём от producer)
2. Latency растёт (сообщение ждёт долго в очереди)
3. CPU на consumers на 100% (все потоки заняты)

Как увеличить:
kafka-topics.sh --bootstrap-server localhost:9092 \
  --alter --topic my-topic \
  --partitions 32

Внимание: это может вызвать переупорядочивание сообщений
в разных partitions! (для одного partition порядок сохранится)

Уменьшение partitions

⚠️ НЕВОЗМОЖНО напрямую уменьшить количество partitions!

Если нужно меньше partitions:
1. Создать новый topic с меньшим количеством
2. Перемигрировать данные
3. Переключить потребителей
4. Удалить старый topic

Код: Расчет оптимальных partitions

public class PartitionCalculator {
    
    public static int calculateOptimalPartitions(
        long targetThroughputPerSec,
        long singleConsumerThroughputPerSec) {
        
        // Минимум для целевого throughput
        int minPartitions = (int) Math.ceil(
            (double) targetThroughputPerSec / singleConsumerThroughputPerSec
        );
        
        // Добавляем резерв для failover и future growth
        // Обычно +20-30%
        int withBuffer = (int) (minPartitions * 1.25);
        
        // Округляем до степени двойки (для лучшей балансировки)
        int powerOfTwo = 1;
        while (powerOfTwo < withBuffer) {
            powerOfTwo *= 2;
        }
        
        return powerOfTwo;
    }
    
    public static void main(String[] args) {
        // Пример: 100k msg/sec, consumer может 30k msg/sec
        int partitions = calculateOptimalPartitions(100_000, 30_000);
        System.out.println("Recommended partitions: " + partitions);
        // Output: 8 (2^3)
    }
}

Мониторинг partition health

@Service
public class PartitionHealthMonitor {
    
    @Scheduled(fixedRate = 60_000)  // Каждую минуту
    public void checkPartitionHealth() {
        // 1. Проверяем lag
        long totalLag = kafkaAdminClient.getConsumerGroupLag("my-group");
        if (totalLag > 100_000) {
            logger.warn("High lag detected: {}", totalLag);
            // Возможно, нужно больше partitions
        }
        
        // 2. Проверяем distribution
        checkPartitionDistribution();
        
        // 3. Проверяем replication
        checkReplicationFactor();
    }
}

Real-world примеры

Пример 1: LinkedIn-scale системы

Topic: "events"
Throughput: 5 million events/sec

Расчёт:
Consumer throughput: 100k/sec (хорошо оптимизированный)
Partitions = 5M / 100k = 50 partitions
Резерв: 50 * 1.3 = 65 → 64 partitions (2^6)

В production: обычно 128 partitions
(для future growth и failover tolerance)

Пример 2: финансовые транзакции

Topic: "transactions"
Throughput: 10k tx/sec
Latency requirement: < 100ms
Processing time: 50ms

Расчёт:
Consumer throughput = 1000ms / 50ms = 20 tx/sec
Partitions = 10k / 20 = 500

Влияние: каждый partition обслуживается 1 consumer
→ нужно 500 consumer instances
→ нужно 50 серверов по 10 consumers на каждом

Оптимизация: добавить batch processing
Processing: 1ms per batch of 50 tx
Consumer throughput: 50k tx/sec
Partitions = 10k / 50k = 1 partition достаточно! (с резервом: 2-4)

Резюме

Правило для определения partitions:

Partitions = (Target Throughput) / (Consumer Throughput) * 1.25 buffer

Практические рекомендации:
- Low:    1-3 partitions (< 1k msg/sec)
- Medium: 4-8 partitions (1k-100k msg/sec)
- High:   16-64 partitions (100k+ msg/sec)
- Massive: 64-256+ partitions (1M+ msg/sec)

Полезные подсказки:
- Начни с консервативного числа (4-8)
- Мониторь lag и latency
- Увеличивай если видишь проблемы
- Используй степени двойки для лучшей балансировки
- Помни: изменение partitions требует rebalancing
- Нельзя уменьшить количество partitions (только пересоздать topic)