Какие данные из звонилок хранятся: метаданные или аудио/видео записи
Что проверяют
Умеете ли вы уточнять требования перед проектированием хранилища: метаданные звонка и сами записи различаются по объёму, формату, стоимости хранения и юридическим рискам на порядки. Следом спрашивают, как вы разложите их по хранилищам и сколько места уйдёт за год.
Как отвечать
Чаще всего хранят оба вида, но совсем по-разному.
- метаданные (CDR): id звонка, участники, время начала и конца, длительность, направление, статус (отвечен, пропущен, сброшен), оператор и очередь для колл-центра, кодек, метрики качества вроде потерь пакетов и джиттера. Это узкие строки, их миллионы, и они живут в колоночном хранилище вроде ClickHouse с партиционированием по дате;
- медиа: аудио и видео лежат в объектном S3-совместимом хранилище, в таблице только ссылка на объект, размер и длительность;
- производные данные: транскрипт после распознавания речи, разметка по спикерам, тональность, темы, эмбеддинги для поиска. Для аналитики и ML их обычно достаточно, и работать с текстом дешевле, чем с аудио.
Прикиньте объём вслух: телефонный G.711 это 64 кбит/с, около 29 МБ на час разговора, Opus на низком битрейте в несколько раз меньше, видео на порядки больше. Отсюда политики жизненного цикла: через N дней запись уходит в холодный класс хранения, потом удаляется, а метаданные и транскрипты живут дольше.
Обязательно назовите юридическую часть: номер телефона и голос это персональные данные, в России на них действует 152-ФЗ, запись требует уведомления собеседника. В аналитическом слое номера псевдонимизируют хешем, доступ к сырым записям дают отдельной ролью и логируют.
Где спотыкаются
Кладут аудио в базу бинарной колонкой. Растут бэкапы, падает скорость запросов, а объектное хранилище решает задачу дешевле.
Не считают объём и стоимость, поэтому не могут обосновать срок хранения.
Забывают про согласие и доступы. Сырая запись разговора с данными клиента в общем озере данных это готовый инцидент.