Вопрос
“Допустим, мой оператор делает биллинг (готовит ежемесячные счета) в течении 5-10 дней. Почему так долго? Казалось бы, делов-то:”select sum(rated_amount) from rated_calls group by contract_id“, и вперед – печатать счета…”
Ответ
Давайте попробуем разобраться, где же порылась собака. Допустим, у компании-оператора два миллиона абонентов, которым надо выставить счета. Каждый из этих абонентов за день в среднем совершает 10 тарифицируемых событий (исходящие звонки, SMS, …) и еще столько же нетарифицируемых (входящие звонки, SMS, …).
За месяц получаем: 210^6 20 * 30 = 12 * 10^8 (1 млрд 200 млн). Это количество записей, прошедших через rating.
Что делает процесс биллинга в простейшем случае? Для каждого из 2-х млн абонентов он смотрит, какие контракты принадлежат каждому абоненту, выбирает звонки, сделанные контрактами, суммирует их, добавляет все необходимые ежемесячные абонплаты, и начисляет сверху налоги. По окончании расчета полученные данные засовываются в красивую печатную форму (например, в виде PostScript).
Тут все желающие уже могут провести пару простых экспериментов. Например, взять любую базу данных, засунуть в нее миллиард-другой записей и попробовать выполнить select, вынесеный мной в первые строчки поста. Результаты отмасштабировать в предположении, что у оператора процессоры будут СуперМощные, а памяти будет Дофигищща.
Все? Нет, не все. Стрижка только начата. Это мы построили самый простой биллинг, практически - сферический биллинг в вакууме.
Давайте добавим в картину мира услуги, плата за которые зависит от месячной активности абонента. Например, “абонент платит за сервис фиксированную сумму в день, но только в дни, когда он пользовался этой услугой” или “сумма ежемесячной абонплаты зависит от кол-ва дней, в течении которых контракт был активен”. Чтобы рассчитывать такие суммы, нам придется делать детальный анализ таблицы событий в разрезе дней. Допустим, что такие услуги популярны, и нам надо делать это для бОльшей части абонентской базы.[1]
Давайте также добавим в картину мира так популярные нынче “бесплатные” (или входящие в абонплату) минуты/SMS-ы/MMS-ы и т.п. В терминах нашей модели это означает, что для каждого контракта существует некое кол-во минут N, и определенные (не все) звонки суммарной продолжительностью не более N должны быть исключены из счета. Учтем, что, как правило, N бесплатных минут не будут исчерпаны при помощи целого числа звонков - будет какой-то звонок, который попадет “на границу” и его придется порезать на две части - платную и бесплатную. И это тоже делает биллинг.[2]
Давайте еще учтем смену тарифных моделей. Если у абонента была модель A (X_1 грн в месяц, Y_1 “бесплатных” минут) и он 20-го числа поменял ее на модель B (X_2 грн в месяц, Y_2 бесплатных минут), то с абонента надо снять X_1*(20/30) грн и дать ему Y_1*(20/30) минут в рамках модели А, а в рамках модели B снять X_2*(10/30) грн и дать ему Y_2*(10/30) минут - пропорционально времени, которое он провел в каждой тарифной модели. После этого надо пересмотреть все его звонки и понять, какие из них бесплатные, и в какой из “периодов бесплатности” они попали. Да, попутно надо не забыть пересчитать все абонплаты за услуги, которые зависят от месячной активности.[3]
Как, все еще помещаемся в пару часов? Сомневаюсь.
Погодите, но кроме счетов для абонента есть еще бухгалтерия. Надо показать, какие звонки абонента “закрывают” те или иные его платежи. Другими словами, если абонент заплатил два раза по 100 грн, а наговорил на 200 грн, то биллинг должен для каждого звонка указать, к какому платежу он “отнесен” - к первому или второму. И так для всех звонков всех абонентов.[4]
После этого посчитаем налоги и все цифры для налоговых накладных (это, правда, можно делать только для абонентов-юрлиц, но их еще тоже надо отделить от физлиц).
В принципе, дальше уже можно не продолжать, думаю, что и так все должно быть понятно. Если кто-то сможет втиснуть это все в рамки нескольких часов - ему прямая дорога писать и продавать биллинговые системы. Можно миллионы будет на этом деле заработать.
У меня есть отдельная статья про Intelligent Network, NextGenerationOSS, конвергентные, hot, almost-hot и другие “быстрые” решения, которые могут быть использованы для более оперативного подсчета баланса абонента. Однако, есть нюанс: в системе, которая сразу после события подбивает достоверный и окончательный баланс абонента, и абонент не может уйти в минус, невозможна нормальная реализация услуг, описаных в пунктах [1],[2],[3],[4].
А реализовывать такие услуги отделу маркетинга хочется. Вот и получается, что либо модные услуги, контракт и длинный биллинг, либо без модных услуг, препейд и невозможность биллинга, как такового.
После прочтения этой статьи у вас может возникнуть соблазн сказать: “Так надо распараллелить биллинг на 100 серверов, и все будет быстро! Распределить по ним базу абонентов, звонки …”. Коллеги! Я сам придерживаюсь мнения, что среди биллингописателей множество идиотов. Множество - но не все. Подумайте о том, почему такое, казалось бы, тривиальное решение не было реализовано на практике кем-то из major players. Я могу предложить вам несколько пунктов для самостоятельного обдумывания:
- Любое разделение/распараллеливание как правило является попыткой выиграть время ценой больших затрат какого-то другого ресурса. Обычно - памяти (на информацию о том, как мы поделили информацию между “кластерами”, на хранение промежуточных результатов обработки каждого кластера и т.п.). Учитывая, что мы и так ведем речь о немаленьких объемах, может оказаться, что память - не такой уж и “шаровой” ресурс, чтобы его ценой “покупать” время.
- Биллинг - это множество мелких процессов, результаты которых сводятся воедино. Расммотрев каждый из процессов по отдельности, мы можем предложить такую схему разделения исходных данных по “кластерам”, которое позволит распараллелить и ускорить этот процесс. Загвоздка может быть в том, чтобы придумать такое разделение данных на “кластеры”, которое ускорит (или по крайней мере не замедлит) все процессы, входящие в биллинг.
- Не надо забывать, что не только биллинг работает с базой абонентов и звонков - наше разделение на “кластеры” не должно усложнять/замедлять аналитическую отчетность, процессы продаж и CRM, оказания услуг и т.п.