?

Log in

No account? Create an account
dump -0f - /dev/mind
Я знаю Haskell, OCaml, GSM, эндофункторы и много других страшных слов
GSM: почему биллинг делается так долго? 
20th-Nov-2006 04:14 pm
(заказной пост для en_vision) Допустим, ваш оператор делает биллинг (готовит ежемесячные счета) в течении 5-10 дней? Почему так долго? Казалось бы, делов-то - "select sum(rated_amount) from rated_calls group by contract_id", и вперед - печатать счета. Давайте попробуем разобраться, где же порылась собака.

Допустим, у компании-оператора два миллиона абонентов, которым надо выставить счета. Каждый из этих абонентов за день в среднем совершает 10 тарифицируемых событий (исходящие звонки, SMS, ...) и еще столько же нетарифицируемых (входящие звонки, SMS, ...).

За месяц получаем: 2*10^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]

Теперь посчитаем налоги и все цифры для налоговых накладных (это, правда, можно делать только для абонентов-юрлиц).

В принципе, дальше уже можно не продолжать, думаю, что и так все должно быть понятно. Если кто-то сможет втиснуть это все в рамки нескольких часов - ему прямая дорога писать и продавать биллинговые системы. Можно миллионы будет на этом деле заработать.

На реплики "так это ж можно распараллелить на 100 серверов!" я, наверное, реагировать не буду, уж извините :)

PS
Предваряя отдельный рассказ про Intelligent Network, NextGenerationOSS, конвергентные, hot, almost-hot и другие "быстрые" решения, хочу закинуть такую "удочку": в системе, которая Сразу после события подбивает достоверный и окончательный баланс абонента, и абонент не может уйти в минус, невозможна нормальная реализация услуг, описаных в пунктах [1],[2],[3],[4].

А реализовывать такие услуги отделу маркетинга хочется. Вот и получается, что либо модные услуги, контракт и длинный биллинг, либо без модных услуг, препейд и невозможность биллинга, как такового.

UPD: тем не менее, многие все-таки решили написать мне о том, как прекрасно параллелится биллинг и, в частности, как прекрасно разделяется для этого на части база данных. Коллеги! Я сам придерживаюсь мнения, что среди биллингописателей множество идиотов. Множество - но не все. Подумайте о том, почему такое, казалось бы, тривиальное решение не было реализовано на практике кем-то из major players. А еще подумайте о том, что биллинг - он раз в месяц, а все остальные 27 дней с этой базой и этой таблицей тоже что-то происходит. Причем очень активно происходит, практически без перерыва. И разделение базы на части для этих процессов .... ээээ ... ну, скажем, не самое лучшее решение.
Comments 
20th-Nov-2006 02:43 pm (UTC)
Да уж, коммунизм много вычислительных ресурсов съекономил бы :-).
Как человек, участвовавший в разработке биллинговой системы интернет-провайдера говорю.
20th-Nov-2006 03:08 pm (UTC)
Интересно, а при коммунизьме что должно быть _мерилом_всего_?
При капитализьме - развивать мобильную связь или летающие автомобили - решают деньги.
20th-Nov-2006 02:57 pm (UTC)
Ну вообще-то, учитывая что статистика одного абонента от статистики другого зависит очень слабо, это всё таки прекрасно распараллеливается. ;)

Так что (as for me), ключевой фактор в объяснении "отделу маркетинга .." непрерывно ".. хочется" - и невозможность заводить под каждый чих оптимизационные фишки. :)
20th-Nov-2006 03:09 pm (UTC)
Распараллеливая биллинг, надо думать вот о чем:
1)Ну, допустим мы распараллелили подсчет - что мы будем делать с базой?
2)Допустим, мы распараллелили базу (Oracle partitioning? или как? порежем базу на куски?). Что у нас получается с процессами, которые наполняют/модифицируют эту базу в течении месяца? :)

Доводим эту мысль до экстрима - каждый абонент в одтельной базе на отдельном компе :) Ведь нужна же будет центральная сущность, которая помнит, на каком компе хранится какой абонент, nest pas? :) И ведь этой сущности прийдется роутить через себя все запросы. И ведь такая организация хранения данных похерит производительность запросов вида "select sum(...) from all_contracts" ...
(no subject) - Anonymous - Expand
20th-Nov-2006 03:08 pm (UTC)
Честно говоря, не вижу причин, почему в hot-billing'е нельзя реализовать [1],[2],[3]. Мало того, большинство этого успешно реализуется на pre-paid пакетах. Да, возможны некоторые другие виды тарификации, которые сложно реализовать в hot-billing'е. Но это не [1],[2],[3].

Про [4] вообще не совсем понятно - зачем точно вычислять, какие платежи что покрывают. А что если звонок покрывается одновоременно двумя или больше платежами? Обычно просто баланс по счету и все.

Я думаю, что проблемы в post-paid биллингах зачастую в том, что они были введены гораздо раньше pre-paid, и там все ограничения сложились исторически. Pre-paid появились гораздо позже, и скорее всего на других биллинговых платформах (думаю, что из-за этого также долгое время были ограничения по переносу номера с pre-paid на контракт). А мигрировать с одного биллинга на другой это геморройно и дорого.
20th-Nov-2006 03:18 pm (UTC)
Мало того, большинство этого успешно реализуется на pre-paid пакетах.

Успешно? Я не соглашусь. Если на SCP нельзя завести произвольное кол-во произвольных счетчиков, то делаются костылики. Типа, вместо 30 "пакетных" минут в месяц человеку дается 1 минута в день. Которая, каждый день, "покрывает" 1 минуту разговоров. Что есть слабое подобие левой руки. Аналогично делается pro-rating (пересчет абонплаты).

А часто ли на SCP можно заводить произвольные счетчики и связанные с ними правила? А нечасто. Вот если уже вместо пары SSP+SCP завести SoftSwitch - то там можно выгнуться как угодно. Но это (софт-свитч) - что-то новое, модное и дорогое. Не все на него апгрейдятся просто "за красивые глаза".

Про [4]. В бухгалтерии, как в армии, приказы не обсуждаются и здравый смысл отключается. Т.е. нет вопроса "зачем?". Есть ответ "так точно, будет сделано!" :)

Последний абзац - сущая правда.
20th-Nov-2006 03:23 pm (UTC)
В T-Mobile и Cingular лёгким движением руки делается up to the day минутосчитание (точнее реально он работает с точностью примерно до часа, и для припейд абонентов даётся баланс, для контрактников это актуально только после выхода за данные им несколько сотен минут) %) Ужасов с многомиллиардными селектами нет %) Просто в момент прохода записи (например отпинываемой по MQ главному серверу) во "временном балансе" звонившего номера делается +стоимость и всё :)
Разумеется по окончанию включенных в стоимость плана минут N минут стоит Х баксов, но изгалятельств с разной стоимостью из-за направления нет (анахронизм стоимости межгорода был изжит давно, международка стоит одинаково вне зависимости от состояния счёта) так что от перемены слагаемых число минут не изменится :)
20th-Nov-2006 10:34 pm (UTC)
В T-Mobile и Cingular лёгким движением руки делается up to the day минутосчитание (точнее реально он работает с точностью примерно до часа

Теперь берем наши или российские реалии. У лидеров рынка хот-биллинг (реально мы говорим, конечно, про хот-рейтинг) работает с точностью до, округляя, четырех часов. Про то, что биллинг у них радикально другой - не поверю, особенно зная, что любит внедрять Т-Мобил.

Возвращаемся к нам. Через четыре часа мы имеем хорошее представление текущем балансе, ровно как ты описываешь.

Разумеется по окончании месяца биллинг все пересчитывает и зачастую получает чуть другие цифры.

Но вот скажи мне - что скажет американец, который 30-го числа видел на балансе 51 бакс, а после биллинга там осталось 49 (пересчитали, получилось на 2 бакса дороже)? Скорее всего он не скажет ничего, т.к. 30-го числа свой баланс не проверял, а смотрит только в бумажный счет.

А что скажут у нас? Скажут - компания сперла два рубля. Однозначно.

Или, например, станет ли американец после совершения звонка выжидать ровно час (т.к. ему на форуме друганы сказали, что ровно столько работает биллинг), после чего проверять свой баланс, еще через пол-часа проверять его еще раз, и если он вдруг уменьшился - опять-таки говорить, что воруют деньги (пофиг, что там мог хот-рейтинг задержаться, например)? Мне слабо это видится. А у нас - повсеместно.

Доходит до смешного - на лицевом два контракта, муж и жена. Муж приходит ругаться, что воруют деньги - он специально все выходные(!) не говорил и регулярно проверял баланс(!), а деньги куда-то уходят. Первая версия оператора - это расходы на звонки жены. "Нет, я с ней говорил - она никуда не звонила". Делают распечатку. Там куча исходящих СМС от жены. Муж краснеет, бледнеет, уходит....
20th-Nov-2006 03:32 pm (UTC)
Биллинг - жопа. Телефонный биллинг - жопа вдвойне. Я убеждаюсь в этом каждый день. Криво написаный - это вообще караул.
20th-Nov-2006 10:38 pm (UTC)
А где ж он есть прямо написаный? :)
20th-Nov-2006 04:20 pm (UTC)
Подписываюсь под каждым словом и в посте, и в комментах адепта.
20th-Nov-2006 10:38 pm (UTC)
Вот! Хоть одна родственная душа меня поняла :)
20th-Nov-2006 04:22 pm (UTC)
Либо будет и [1], и [2], и [3], и [4] и т.д. - но с точностью "+/- два лаптя по карте". А в конце месяца это всё равно будет повторно подбиваться.
20th-Nov-2006 10:39 pm (UTC)
На практике почему-то обычно получается "+/- два лаптя по карте", т.к. если хранить всю историю событий и пересчитывать раз в месяц - то это очень быстро получается postpaid со всеми его "прелестям" и тормозами.
20th-Nov-2006 11:42 pm (UTC)
PS Похвастаюсь: [1][2][3][4] работает у одного действительно крупного broadband оператора в реальном времени (за небольшим исключением). В минус уйти можно, но ненамного [хотя математически точной верхней границы нет]. Правда при реализации и тьюнинге раз 5 казалось что полная жопа.
22nd-Nov-2006 07:17 am (UTC)
Что на это можно сказать?

Broadband модемы обладают сразу несколькими полезными (с точки зрения биллинга) свойствами:
1)Они не переключаются сами по себе между access server-ами провайдера
2)Они не ездят в роуминг. Они вообще не ездят
3)Тарифицируется транспортный уровень, а не application.

А теперь представь, что у пользователя broadband модем - в телефоне :)
И тарифицировать надо не ip-пакеты, а ICQ сообщения - отдельно, Skype calls - отдельно, фалый по ftp - отдельно, по http - отдельно, причем картинки по http - совсем отдельно.

И с учетом [1][2][3][4] :)
21st-Nov-2006 12:02 am (UTC) - Цитата в тему
http://bash.org.ru/quote.php?num=60455
LJ: r00fless
Тем, кто шарит, думаю, не надо объяснять связь между словами "биллинг", "упасть" и "анальный секс"
21st-Nov-2006 04:45 am (UTC)
Наверняка можно написать систему оптимизированную до определённого уровня. Я не спец в биллинге, так что если бы взялся писать, то первым делом провёл бы анализ предметной области на вычислительную сложность. Типа, сколько событий в месяц, каково их распределение, каковы планы оплаты и т.д. Потом предложил бы набор алгоритмов и варианты распараллелливания.

Отвлечённое - где нагрузка на систему выше - в биллинге или в в трейдинге?
21st-Nov-2006 07:52 am (UTC)
Ага. Посчитали, определили алгоритмы, реализовали... А потом хренакс! - и приходит главный маркетолог и предлагает закинуть левую ногу за правое ухо и реализовать очередную нивроткасмическую систему скидок и бонусов. Вариант "послать нах" - не принимается :)
21st-Nov-2006 07:05 am (UTC)
Вот оно как... Я знал: всё зло от маркетологов :)

Если серьёзно - то всякие хитрозакрученные тарифные планы с левой резьбой, с громадными заголовками и сносками мелким шрифтом лично у меня вызывают ощущение, что в чём-то меня дурят. Раз всё так сложно - значит, в этом тарифном плане платить надо за чёрт знает что, а не за осязаемые сервисы.
22nd-Nov-2006 07:31 am (UTC)
... лично у меня вызывают ощущение, что в чём-то меня дурят.

Прикольно то, что в 80% случаев "задурить голову абоненту" - это "неожиданное" следствие внедрения нового тарифного плана, а не цель :)

Допустим, цель была "выпустить на рынок что-то новенькое", но в процессе придумывания этого новенького за деревьями не заметили леса и придумали ТАКОЕ ...
21st-Nov-2006 01:35 pm (UTC)
Меня вот интересует вот какой вопрос. А как этот мегамоск под названием "процесс биллинга" программируется под необходимую логику?
Допустим пришел манагер, и сказал что надо тариф такой-то вот с такой-то логикой (дальше обычно идет что-то, что нормальному человеку в голову ни за что не придет). И что в этом случае делают люди саппортящие биллинг? Не переписывают же кусок кода для реализации этой "мечты идиота"?
24th-Nov-2006 09:37 pm (UTC)
А как этот мегамоск под названием "процесс биллинга" программируется под необходимую логику?

Возможно, про это будет отдельный пост
21st-Nov-2006 02:59 pm (UTC)
Спасибо! Да, идеи по оптимизации появляются (напр. часть рассчетов производить сразу после добавления записи в рейтинг), но не факт, что так не сделано, написать сложнее (=потенциальных ошибок больше), да и смысла особого в этом не вижу.

И, раз уж перешли на околософтовые темы, интересно бы узнать о софте, которым пользуються операторы и о архитектуре/конфигурации серверов, где этот софт живет.
22nd-Nov-2006 07:57 am (UTC)
Рейтинг сразу обновляет "текущий баланс" абонента, другое дело, что до биллинга это значение - не более чем хорошее приближение.

интересно бы узнать о софте, которым пользуються операторы и о архитектуре/конфигурации серверов, где этот софт живет.

Очень расплывчато. Детализируй.
23rd-Nov-2006 07:33 pm (UTC)
Anonymous
Наверное, я скажу какую-то глупость, но в комментариях и в после обьяснения не нашел: у меня московский билайн, prepeaid. В любой момент я могу сделать запрос баланса и посмотреть, сколько денег на счету. Если сделать запрос сразу после звонка или отправки smsки - видноЭ, что списали стоимость согласно тарифному плану.

Если счет пополнить, скажем, платежом через Webmoney или карточкой, баланс обновляется сразу же. При переходе баланся ниже какой-то суммы (ниже 10$, 3$), приходит соответтсвующая SMS от оператора.

Сколько всяких извратов и наворотов у Билайна в плане тарифных планов, маркетинговых акций и прочего, обьяснять, думаю, не надо. Получается, биллинг, который считает все в реальном времени, сделать можно. Вопрос - что я не так понял?
24th-Nov-2006 02:12 pm (UTC)
Сколько всяких извратов и наворотов у Билайна в плане тарифных планов, маркетинговых акций и прочего, обьяснять, думаю, не надо. Получается, биллинг, который считает все в реальном времени, сделать можно. Вопрос - что я не так понял?

Надо, надо объяснять. На какой из тарифов на http://www.msk.beeline.ru/tarifs/tarif.wbp смотреть?

Едем дальше.

Во-первых различаем rating (процесс определения стоимости) и billing (процесс формирования ежемесячного счета). Вполне может быть решение, в котором realtime rating, а биллинга нет вообще, или же realtime rating, а биллинг идет 4 дня (я подозреваю, что именно это имеет место у билайна)

Потом, я ж не говорил, что вообще ни за что и никогда нельзя сделать realtime rating. Вот тут описано, как устроен realtime rating для IN-based prepaid-а. Возможно, именно такое решение использует Beeline.

Теперь посмотрим, что же (как я утверждал) нельзя сделать при realtime rating-е.

Realtime rating подразумевает, что стоимость события известна непосредственно после его завершения (или еще в процессе). Соответственно (мне казалось, что этот перехо очевиден) непонятно, что делать с событиями, стоимость которых неизвестна.

Например, если в тарифах написано "звонки - 10 коп/минута, если наговорили больше часа в день - то 8 коп/минута", то сразу после совершения звонка известна только приблизительная стоимость, а окончательная может быть рассчитана только по истечении суток. Теперь заменяем "день" на "месяц". Что у нас там получается с realtime rating-ом? Правильно - ничего не получается. Прийдется пересчитывать стоимость и корректировать баланс по истичении месячного периода.

Если есть желание - давай ссылку на описание своего тарифа, разберем его и почти наверняка обнаружим, что "неудобных" правил тарификации там нет и тарифный план "заточен" под используемое техническое средство.

Что и требовалось доказать - быстрый рейтинг возможен, но ограничивает полет мысли сотрудников отдела маркетинга :)
(no subject) - Anonymous - Expand
24th-Nov-2006 09:58 am (UTC)
а причем здесь реплики. вообще-то есть такое понятие как data warehousing, когда OLAP и reporting (по сути которым является billing) тупо разносятся. а синк OLAP и WH можно вести тогда, когда нагрузка на OLAP ниже.
иначе как работают операторы у которых _десятки миллинов_ абонентов? :)
24th-Nov-2006 01:56 pm (UTC)
На практике, ETL в OLAP приходится вести тогда, когда нагрузка на биллинговую систему меньше :)

Модели данных в биллинге и WH обычно сильно различаются, и запросы по выгрузке всего/формировании дельты для WH обычно нехило грузят базу биллинга. Для этого иногда даже приходится делать standby-копию базы биллинга, и делать выгрузки в OLAP из нее.
Page 1 of 2
<<[1] [2] >>
This page was loaded Oct 19th 2018, 6:23 am GMT.