Большим данным большой биллинг: о BigData в телекоме
В 2008 BigData была новым термином и модным трендом. В 2019 BigData — это объект продажи, источник прибыли и повод для новых законопроектов.
Осенью прошлого года российское правительство инициировало законопроект о регулировании больших данных. Запрещается идентифицировать по информации людей, но разрешается делать это по запросу федеральных органов. Обработка BigData для третьих лиц — только после уведомления Роскомнадзора. Под закон попадают компании, в распоряжении которых больше 100 тысяч сетевых адресов. И, конечно, куда без реестров — предполагается создание такового со списком операторов БД. И если до этого BigData не всеми воспринималась всерьез, то теперь с ней придется считаться.
Не могу обойти стороной БД и я, как директор компании-разработчика биллинга, который эту самую BigData обрабатывает. Поразмышляю о больших данных через призму операторов связи, через чьи биллинговые системы ежедневно проходят потоки информации о тысячах абонентов.
Теорема
Начнем, как в задаче по математике: сначала докажем, что данные операторов связи можно именовать BigDat«ой. Стандартно большие данные характеризуются тремя признаками VVV, хотя в вольных интерпретациях количество «V» доходило и до семи.
Volume. Один только MVNO Ростелекома обслуживает больше миллиона абонентов. Ключевые хост-операторы обрабатывают данные от 44 до 78 миллионов человек. Трафик растет ежесекундно: за первый квартал 2019 абоненты уже насерфили с мобильных телефонов 3,3 миллиарда Гб.
Velocity. Никто лучше статистики не расскажет о динамике, поэтому пройдусь по прогнозам Cisco. К 2021 году 20% IP-трафика достанется мобильному трафику — он вырастет почти в три раза за пять лет. Треть мобильных подключений придется на M2M — развитие IoT обусловит шестикратный рост соединений. Интернет вещей станет не только прибыльным, но и ресурсозатратным направлением, поэтому некоторые операторы сосредоточатся только на нем. А те, кто разовьет IoT отдельной услугой, получат двойной трафик.
Variety. Многообразие — понятие субъективное, но операторы связи действительно знают о своих абонентах почти все. От имени и паспортных данных до модели телефона, покупок, посещаемых местах и интересах. Медиа-файлы по закону Яровой хранятся от полугода. Так что примем за аксиому, что собираемые данные разнообразны.
Софт и методология
Провайдеры — одни из главных потребителей BigData, поэтому большинство методик анализа больших данных применимы к отрасли телекома. Другой вопрос — кто готов вкладываться в развитие ML, AI, Deep Learning, инвестировать в ЦОДы и data mining. Полноценная работа с БД складывается из инфраструктуры и команды, затраты на которые не все могут себе позволить. Делать ставку на BigData стоит предприятиям, которые уже имеют корпоративное хранилище или развивают методику Data Governance. Тем же, кто еще не готов к длительным инвестициям, советую постепенно наращивать архитектуру ПО и ставить компоненты по очереди. Тяжелые модули и Hadoop можно оставить напоследок. Мало кто покупает готовое решение для задач типа Data Quality и Data Mining, в основном компании подгоняют систему под свою специфику и потребности — сами или с помощью разработчиков.
Но не любой биллинг можно модифицировать под работу с BigData. Вернее, модифицировать могут не только лишь все. Мало кто может это делать.
Три признака, что у биллинговой системы есть шанс стать инструментом обработки БД:
- Горизонтальная масштабируемость. Софт должен быть гибким — мы же говорим о больших данных. Увеличение количества информации должно лечиться пропорциональным увеличением «железа» в кластере.
- Отказоустойчивость. Серьезные prepaid-системы обычно по умолчанию отказоустойчивы: биллинг разворачивается в кластере в нескольких геолокациях, чтобы те автоматически страховали друг друга. Компьютеров в Hadoop-кластере тоже должно быть достаточно на случай поломки одного или нескольких.
- Локальность. Данные должны храниться и обрабатываться на одном сервере, а иначе на передаче данных можно разориться. Одна из популярных схем подхода Map-Reduce: HDFS хранит, Spark обрабатывает. В идеале софт должен безболезненно интегрироваться в инфрастуктуру ЦОД и уметь три в одном: собирать, организовывать и анализировать информацию.
Команда
Что, как и для какой цели программа будет обрабатывать большие данные — решает команда. Часто она состоит из одного человека — data scientist«а. Хотя, на мой взгляд, минимальный пакет сотрудников для BigData включает в себя еще и Product-менеджера, Data Engineer«а, руководителя. Первый разбирается в услугах, переводит технический язык на человеческий и обратно. Data Engineer воплощает модели в жизнь с помощью Java/Scala и экспериментирует с Machine Learning. Руководитель координирует, ставит цели, контролирует этапы.
Проблемы
Как раз со стороны команды BigData обычно возникают проблемы при сборе и обработке данных. Программе нужно объяснить, что собирать и как обрабатывать — для того, чтобы это объяснить, нужно сначала самому понять. А у провайдеров не все не так просто. Рассказываю о проблемах на примере задачи по сокращению оттока абонентов — именно ее операторы связи пытаются решить с помощью BigData в первую очередь.
Постановка задач. Грамотно составленное ТЗ и разное понимание терминов — многовековая боль не только для фрилансеров. Даже «отвалившихся» абонентов можно интерпретировать по-разному — как не пользующихся услугами оператора месяц, полгода или год. А для создания MVP на исторических данных нужно понимать частоту возвратов абонентов из оттока — тех, кто пробовал связь других операторов или уезжал из города и пользовался другим номером. Еще один важный вопрос: за сколько времени до предполагаемого ухода абонента провайдер должен это определить и принять меры? За полгода — рано, за неделю — уже поздно.
Подмена понятий. Обычно операторы определяют клиента по номеру телефона, поэтому логично, что признаки нужно выгружать по нему. А что насчет лицевого счета или номера обслуживающего приложения? Нужно определиться, какую единицу следует принимать за клиента, чтобы данные в системе оператора не разнились. Оценка ценности клиента тоже под вопросом — какой абонент более ценный для компании, для удержания какого пользователя нужно приложить больше усилий, а какие «отвалятся» в любом случае и нет смысла тратить на них ресурсы.
Недостаток информации. Далеко не все сотрудники провайдера способны объяснить команде BigData, что конкретно влияет на отток абонентов и как считаются возможные факторы в биллинге. Даже если назвали один из них — ARPU, — оказывается, что и его посчитать можно по-разному: или по периодическим платежам клиента, или по автоматическим начислениям биллинга. А в процессе работы возникает миллион других вопросов. Всех ли клиентов охватывает модель, какова цена за удержание клиента, есть ли смысл продумывать альтернативные модели и что делать с клиентами, которых стали по ошибке искусственно удерживать.
Целеполагание. Я знаю три вида ошибок, связанных с результатом, которые заставляют операторов разочаровываться в БД.
- Провайдер вкладывается в BigData, обрабатывает гигабайты информации, но получает итог, который мог бы получить и дешевле. Используются простые схемы и модели, примитивная аналитика. Себестоимость в разы выше, а результат тот же.
- Оператор получает на выходе многогранные данные, а как их использовать — не понимает. Аналитика есть — вот она, понятная и объемная, а толку от нее — ноль. Не продуман конечный результат, который не может состоять из цели «обработать данные». Обработать мало — аналитика должна стать базой для обновления бизнес-процессов.
- Препятствием для использования аналитики BigData могут становятся устаревшие бизнес-процессы и неподходящий для новых целей софт. Значит, сплоховали на этапе подготовки — не продумали алгоритм действий и этапы внедрения BigData в работу.
Зачем
К слову о результатах. Пробегусь по способам использования и монетизации BigData, которыми уже пользуются операторы связи.
Провайдеры прогнозируют не только отток абонентов, но и нагрузки на базовые станции.
- Анализируется информация о перемещении абонентов, активности и частотных сервисах. Результат: снижение количества перегрузок за счет оптимизации и модернизации проблемных участков инфраструктуры,.
- Информацию о геолокации абонентов и плотности потока операторы связи используют при открытии точек продаж. Так аналитику BigData уже используют МТС и Вымпелком для планирования расположения новых офисов.
- Провайдеры монетизируют собственные большие данные, предлагая их сторонним фирмам. Основные заказчики BigData операторов — коммерческие банки. С помощью БД они отслеживают подозрительные активности SIM-карты абонента, к которой привязаны карты, пользуются сервисами рискового скоринга, верификации и мониторинга. А в 2017 динамику передвижения по данным BigData запросило у Tele2 правительство Москвы — для планирования технической и транспортной инфрастуктуры.
- Аналитика BigData — золотая жила для маркетологов, которые могут создавать персонализированные рекламные кампании для целых тысяч групп абонентов, если захотят. Телеком-компании агрегируют социальные профили, потребительские интересы и поведенческие модели абонентов, а потом используют собранную BigData для привлечения новых клиентов. Но для масштабного планирования продвижения и PR у биллинга не всегда хватает функционала: программа должна одновременно учитывать множество факторов параллельно с детальной информацией о клиентах.
Пока кто-то до сих пор считает BigData пустым звуком, «большая четверка» уже делает на ней деньги. МТС за полгода зарабатывает на обработке больших данных 14 миллиардов рублей, а Tele2 увеличил выручку от проектов в три с половиной раза. BigData превращается из тренда в must have, под который будет перестраиваться вся структура операторов связи.
