Нагрузочные синтетические транзакции для стресс-тестов

Соблюдай все обязательные требования ниже. Верни только итоговый результат в требуемом формате. Не добавляй вступления, комментарии о процессе, предупреждения, альтернативные версии или просьбы что-либо уточнить. Если часть входных данных отсутствует и исходный промпт допускает рабочие предположения, явно фиксируй их только там, где это прямо требуется. Сохраняй placeholders, JSON, YAML, SQL, код, формулы, названия метрик, пороги, порядок разделов и другие обязательные технические элементы без искажений.

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

Вы — системный инженер, задача — сгенерировать реалистичные синтетические данные для нагрузочного тестирования. Перед выполнением замените все фигурные плейсхолдеры на конкретные значения: {system_type}, {data_volume}, {transaction_type}, {usage_patterns}, {data_attributes}, {business_rules}, {peak_load_scenarios}, {stress_conditions}.

Входные параметры (обязательно заменить плейсхолдеры):
- system_type: тип тестируемой системы (например, "онлайн-банк", "электронная коммерция", "POS-система").
- data_volume: требуемое количество записей (например, 5_000_000).
- transaction_type: тип транзакций (например, "платеж", "заказ", "логин").
- usage_patterns: ключевые модели поведения пользователей, которые нужно смоделировать (перечислить коротко: например, "чаще покупки вечером, корзины брошены, периодические подписки").
- data_attributes: список требуемых полей/атрибутов для каждой записи (например, "transaction_id, user_id, amount, currency, status, timestamp, device, ip_address, session_id, product_id").
- business_rules: ключевые правила целостности и валидации (перечислить: например, "баланс пользователя не может уйти в отрицательное, статус транзакции зависит от проверки KYC, суммы в пределах X–Y").
- peak_load_scenarios: описать сценарии пиков (перечислить: например, "часы пик 18:00–20:00, распродажа 3 дня в месяц, запуск кампании маркетинга").
- stress_conditions: условия для стресс-тестирования (перечислить: например, "удвоенный трафик в течение 30 минут; длительные всплески; высокая доля невалидных запросов; медленные отклики БД").

Задача (четко): сгенерировать {data_volume} реалистичных синтетических записей типа {transaction_type}, которые:
- отражают указанные {usage_patterns},
- содержат все указанные {data_attributes} в реалистичных форматах и типах данных,
- полностью соответствуют перечисленным {business_rules},
- моделируют указанные {peak_load_scenarios} и {stress_conditions},
- сохраняют ссылочную целостность (реальные связи между таблицами/объектами: user↔transaction, product↔transaction и т.д.),
- воспроизводимы (использовать и указать seed для генератора случайных чисел).

Требования к содержанию и качеству данных:
- Схема: явно перечислите поля, типы данных (int/uuid/string/decimal/timestamp/boolean), ограничения (PK, FK, nullable), длины строк и допустимые форматы (например, timestamp — ISO 8601 UTC).
- Форматы значений: идентификаторы — UUID или целые; суммы — десятичные с 2 знаками; валюты — ISO-4217; IP — IPv4/IPv6 синтаксис; device — enum (mobile, desktop, tablet); статус — enum (pending, success, failed и т.д.).
- Распределения и временные паттерны: для каждого поля укажите распределение (например, amount — логнормальное с μ=..., σ=... или эмпирическое), временные интервалы и частоты (например, inter-arrival times — пуассон, пиковые часы — увеличенное кратное базовой интенсивности), сессии пользователей и последовательности действий (sessionization: session_id, события в сессии, средняя длина сессии).
- Пиковые сценарии: в сгенерированных данных должны быть явные всплески нагрузки, соответствующие {peak_load_scenarios} (укажите время начала/длительность/мультимножитель трафика).
- Наличие шума и ошибок: в пределах заданных бизнес-правил включите реалистичные неуспешные транзакции, отклонённые проверки, повторные попытки, таймауты, частично заполненные данные (но не нарушающие жизненно важные FK/PK).
- Справочные таблицы: если требуется, создайте данные для связанных сущностей (users, products, accounts) и обеспечьте согласованность ссылок.
- Безопасность/анонимность: не используйте реальные персональные данные; генерируйте псевдо-реалистичные имена/адреса/телефоны согласно локали, если это указано.

Требования к выходу (формат вывода — строго):
1) Основной набор данных:
   - CSV (один файл) и/или JSONL (newline-delimited JSON), размер/разбиение на файлы при большом объёме (например, по 1M записей).
   - Имя файла(ов) и кодировка (UTF-8).
   - Первые 10 записей в обоих форматах как пример (sample).
2) Схема и словарь данных (data dictionary) в JSON:
   - для каждого поля: имя, тип, допустимые значения/enum, распределение и параметры, nullable, примеры.
3) Манифест генерации (metadata.json):
   - seed, количество записей, дата/время генерации, версия генератора, суммарные статистики (mean/median/std/min/max по числовым полям, распределение статусов, количество уникальных пользователей, степень повторных транзакций).
4) Отчёт по качеству/валидности:
   - подтверждение соблюдения всех {business_rules},
   - доля нарушений (если моделируются), список типов ошибок,
   - проверка ссылочной целостности (число нарушений = 0).
5) Краткая инструкция загрузки (README): как импортировать данные в тестовую БД (включая рекомендации по параллельной загрузке для воспроизведения нагрузки).

Дополнительные технические требования:
- Укажите используемый seed для воспроизводимости.
- Укажите конкретные параметры распределений и алгоритмы генерации (например, пуассон для inter-arrival, логнормальное для сумм, периодические корреляции для сессий).
- Объём файлов должен соответствовать {data_volume}; если полный дамп слишком велик для одного ответа, сгенерируйте методику и первые N записей + код/манифест. (Если вы не можете отдать весь набор прямо в ответе, верните генеративную спецификацию и 10–100 примеров.)
- Соблюдайте ограничения приватности (никаких реальных PII).

Ожидаемый конечный результат (в ответ модели):
- Набор данных в указанных форматах (или детальная спецификация + примеры, если полный набор не помещается),
- data_dictionary.json,
- metadata.json (включая seed),
- sample CSV/JSONL (первые 10 строк),
- краткий README с инструкциями по загрузке и проверке целостности.