Хорошо ли хранить годами данные в Kafka

Хранение Данных в Kafka: Антипаттерны и Правильный Подход

Этот вопрос касается фундаментального непонимания роли Kafka в архитектуре. Коротко: нет, это плохая идея. Давайте разберёмся почему.

Что такое Kafka?

Kafka — это event streaming platform, а не data warehouse. Её основное предназначение:

Производитель1 → [Topic: events] → Потребитель1
                                    Потребитель2
                                    Потребитель3

Это очередь сообщений, которая:

• Буферизирует события
• Распределяет нагрузку
• Позволяет асинхронной обработке

Почему хранить годами данные в Kafka — плохо?

1. Kafka предназначена для потока, не для хранилища

// ❌ Плохо: полагаться на Kafka как на основное хранилище
public class BadArchitecture {
    // "Давайте хранить все события Kafka 10 лет"
    // И если Kafka падает, теряем 10 лет данных
    public void dangerous() {
        kafkaProducer.send("events", userData);
        // Данные хранятся в Kafka ТОЛЬКО
        // Нет backup, нет репликации в БД
    }
}

// ✅ Хорошо: Kafka как временный буфер
public class GoodArchitecture {
    // Kafka = краткосрочный буфер (дни, недели)
    // Database = долгосрочное хранилище (годы)
    public void correct() {
        kafkaProducer.send("events", userData);
        // Параллельно сохраняем в БД
        database.save(userData);
        // Kafka может быть очищена через 7 дней
        // Данные в БД останутся
    }
}

2. Экономические причины

Kafka дорогая для длительного хранения:

Вариант 1: Хранить в Kafka 10 лет
├─ Нужна огромная дисковая емкость на каждом broker
├─ Высокие затраты на репликацию (3x по умолчанию)
├─ Дорогая инфраструктура (SSD, сеть, CPU)
└─ Total Cost: Миллионы долларов в год

Вариант 2: Хранить в S3/GCS (холодное хранилище)
├─ Дешёвое долгосрочное хранилище
├─ Масштабируется до petabytes
├─ Платишь только за хранение, не за compute
└─ Total Cost: Тысячи долларов в год

Пример реальных затрат:

Kafka (3 broker cluster, 10TB/день):
- Hardware: $500k/год
- Network: $100k/год  
- Support: $200k/год
- Total: $800k/год

S3 для архива:
- $0.023/GB/месяц
- 10TB * 365 дней * 0.023 = $84k/год
- Экономия: 90%+ дешевле!

3. Проблемы производительности

// Kafka деградирует с очень большим retention
public class PerformanceIssues {
    // С 10 годами данных в Kafka:
    
    // Проблема 1: Log compaction становится кошмаром
    // Kafka будет часами сжимать 365TB логов
    public void logCompactionNightmare() {
        // Topic с 365TB данных
        // Log compaction может занять часы
        // В это время I/O нагрузка на кластер огромная
    }
    
    // Проблема 2: Consumer lag
    public void consumerLagHell() {
        // Новый consumer присоединяется
        // Нужно прочитать 365TB
        // Это займёт дни/недели, не часы
    }
    
    // Проблема 3: Реплика
    public void replicationHell() {
        // Новый broker присоединяется к кластеру
        // Нужно скопировать 365TB
        // Это займёт дни, сеть забита
    }
}

4. Отказоустойчивость

Kafka не предназначена для долгосрочной надежности:

public class ReliabilityIssues {
    
    // В Kafka есть риски:
    
    // 1. Битые сегменты
    public void corruptedSegments() {
        // Если один из 1000 файлов повреждается
        // Все данные в этом сегменте теряются
        // Это небольшой риск в 2 неделях
        // Это ОГРОМНЫЙ риск за 10 лет
    }
    
    // 2. Баги в JVM
    public void jvmBugs() {
        // Крайне редкий баг в GC может потерять данные
        // В 2 недельной Kafka это случится 1 раз в 1000 лет
        // В 10-летней Kafka это произойдёт гарантированно
    }
    
    // 3. Ошибки операций
    public void operationalErrors() {
        // Один неправильный команда ops-инженера
        // И 10 лет данных потеряны
    }
}

Правильный Подход: Event Sourcing

Если нужна история всех событий, используй правильную архитектуру:

// Архитектура Event Sourcing
public class ProperEventSourcing {
    // 1. События пишутся в event store (PostgreSQL, DynamoDB)
    private EventStore eventStore;
    
    // 2. Kafka используется для реал-тайм потока
    private KafkaProducer<String, Event> kafkaProducer;
    
    // 3. Хранилище данных для оптимизированных запросов
    private Database database;
    
    public void processEvent(Event event) {
        // Шаг 1: Сохраняем в event store (долгосрочное хранилище)
        eventStore.append(event); // Надежно, дешево, навсегда
        
        // Шаг 2: Публикуем в Kafka (реал-тайм поток)
        kafkaProducer.send("events", event); // Для консьюмеров
        
        // Шаг 3: Обновляем read model
        database.updateSnapshot(event); // Для быстрых запросов
    }
    
    public List<Event> getHistoricalData(long userId, Date from, Date to) {
        // Запрашиваем из event store, не из Kafka
        return eventStore.query(userId, from, to);
    }
}

Это лучше, потому что:

• Event Store (PostgreSQL) == надежное, дешевое долгосрочное хранилище
• Kafka == быстрый реал-тайм поток для живых консьюмеров
• Database == оптимизированное хранилище для быстрых запросов

Практический Пример: Event Sourcing с Kafka

public class EventSourcingArchitecture {
    
    // Долгосрочное хранилище (Event Store)
    @Repository
    interface EventStoreRepository extends JpaRepository<Event, UUID> {
        List<Event> findByAggregateIdOrderByTimestamp(UUID aggregateId);
    }
    
    @Service
    public class EventService {
        private EventStoreRepository eventStore;
        private KafkaTemplate<String, Event> kafkaTemplate;
        private UserRepository userRepository;
        
        public void recordUserCreated(String userId, String email) {
            // Запись события
            Event event = new Event(
                UUID.randomUUID(),
                userId,
                "user.created",
                Map.of("email", email),
                Instant.now()
            );
            
            // Сохраняем в Event Store (PostgreSQL) — дешево и навсегда
            eventStore.save(event);
            
            // Публикуем в Kafka для реал-тайм консьюмеров (7 дней retention)
            kafkaTemplate.send("user-events", event.getId().toString(), event);
            
            // Обновляем read model для быстрых запросов
            User user = new User(userId, email);
            userRepository.save(user);
        }
        
        public List<Event> getEventHistory(String userId) {
            // Запрашиваем из Event Store, не из Kafka!
            return eventStore.findByAggregateIdOrderByTimestamp(
                UUID.fromString(userId)
            );
        }
    }
}

Когда Kafka retention имеет смысл?

✅ Небольшие retention периоды:
- 7 дней (стандартный default)
- 1 месяц (для медленных консьюмеров)
- 3 месяца (максимум для большинства cases)

❌ Никогда не используй для:
- 1+ года (слишком дорого)
- Основного хранилища (ненадежно)
- Архива данных (не предназначена)

Заключение

Нет, хранить годами данные в Kafka — плохая идея по всем параметрам:

1. Экономически — в 10 раз дороже чем нужно
2. Технически — Kafka не масштабируется на такие объёмы
3. Архитектурно — это не её предназначение
4. Надежность — растёт риск потери данных

Правильный подход:

• Event Store (DB) для долгосрочного хранения
• Kafka для реал-тайм потока (дни/недели)
• Read model для быстрых запросов

Это Event Sourcing архитектура, которая разделяет ответственность правильно и экономит деньги.