Хабрахабр

Большим данным большой биллинг: о BigData в телекоме

В 2008 BigData была новым термином и модным трендом. В 2019 BigData – это объект продажи, источник прибыли и повод для новых законопроектов.

Запрещается идентифицировать по информации людей, но разрешается делать это по запросу федеральных органов. Осенью прошлого года российское правительство инициировало законопроект о регулировании больших данных. Под закон попадают компании, в распоряжении которых больше 100 тысяч сетевых адресов. Обработка BigData для третьих лиц – только после уведомления Роскомнадзора. И если до этого BigData не всеми воспринималась всерьез, то теперь с ней придется считаться. И, конечно, куда без реестров – предполагается создание такового со списком операторов БД.

Поразмышляю о больших данных через призму операторов связи, через чьи биллинговые системы ежедневно проходят потоки информации о тысячах абонентов.
Не могу обойти стороной БД и я, как директор компании-разработчика биллинга, который эту самую BigData обрабатывает.

Теорема

Начнем, как в задаче по математике: сначала докажем, что данные операторов связи можно именовать BigDat’ой. Стандартно большие данные характеризуются тремя признаками VVV, хотя в вольных интерпретациях количество «V» доходило и до семи.

Один только MVNO Ростелекома обслуживает больше миллиона абонентов. Volume. Трафик растет ежесекундно: за первый квартал 2019 абоненты уже насерфили с мобильных телефонов 3,3 миллиарда Гб. Ключевые хост-операторы обрабатывают данные от 44 до 78 миллионов человек.

Никто лучше статистики не расскажет о динамике, поэтому пройдусь по прогнозам Cisco. Velocity. Треть мобильных подключений придется на M2M – развитие IoT обусловит шестикратный рост соединений. К 2021 году 20% IP-трафика достанется мобильному трафику – он вырастет почти в три раза за пять лет. А те, кто разовьет 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 на исторических данных нужно понимать частоту возвратов абонентов из оттока – тех, кто пробовал связь других операторов или уезжал из города и пользовался другим номером. За полгода – рано, за неделю – уже поздно.

А что насчет лицевого счета или номера обслуживающего приложения? Подмена понятий. Обычно операторы определяют клиента по номеру телефона, поэтому логично, что признаки нужно выгружать по нему. Оценка ценности клиента тоже под вопросом – какой абонент более ценный для компании, для удержания какого пользователя нужно приложить больше усилий, а какие «отвалятся» в любом случае и нет смысла тратить на них ресурсы. Нужно определиться, какую единицу следует принимать за клиента, чтобы данные в системе оператора не разнились.

Даже если назвали один из них – ARPU, – оказывается, что и его посчитать можно по-разному: или по периодическим платежам клиента, или по автоматическим начислениям биллинга. Недостаток информации. Далеко не все сотрудники провайдера способны объяснить команде BigData, что конкретно влияет на отток абонентов и как считаются возможные факторы в биллинге. Всех ли клиентов охватывает модель, какова цена за удержание клиента, есть ли смысл продумывать альтернативные модели и что делать с клиентами, которых стали по ошибке искусственно удерживать. А в процессе работы возникает миллион других вопросов.

Целеполагание. Я знаю три вида ошибок, связанных с результатом, которые заставляют операторов разочаровываться в БД.

  1. Провайдер вкладывается в BigData, обрабатывает гигабайты информации, но получает итог, который мог бы получить и дешевле. Используются простые схемы и модели, примитивная аналитика. Себестоимость в разы выше, а результат тот же.
  2. Оператор получает на выходе многогранные данные, а как их использовать – не понимает. Аналитика есть – вот она, понятная и объемная, а толку от нее – ноль. Не продуман конечный результат, который не может состоять из цели «обработать данные». Обработать мало – аналитика должна стать базой для обновления бизнес-процессов.
  3. Препятствием для использования аналитики BigData могут становятся устаревшие бизнес-процессы и неподходящий для новых целей софт. Значит, сплоховали на этапе подготовки – не продумали алгоритм действий и этапы внедрения BigData в работу.

Зачем

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

  1. Анализируется информация о перемещении абонентов, активности и частотных сервисах. Результат: снижение количества перегрузок за счет оптимизации и модернизации проблемных участков инфраструктуры,.
  2. Информацию о геолокации абонентов и плотности потока операторы связи используют при открытии точек продаж. Так аналитику BigData уже используют МТС и Вымпелком для планирования расположения новых офисов.
  3. Провайдеры монетизируют собственные большие данные, предлагая их сторонним фирмам. Основные заказчики BigData операторов – коммерческие банки. С помощью БД они отслеживают подозрительные активности SIM-карты абонента, к которой привязаны карты, пользуются сервисами рискового скоринга, верификации и мониторинга. А в 2017 динамику передвижения по данным BigData запросило у Tele2 правительство Москвы – для планирования технической и транспортной инфрастуктуры.
  4. Аналитика BigData – золотая жила для маркетологов, которые могут создавать персонализированные рекламные кампании для целых тысяч групп абонентов, если захотят. Телеком-компании агрегируют социальные профили, потребительские интересы и поведенческие модели абонентов, а потом используют собранную BigData для привлечения новых клиентов. Но для масштабного планирования продвижения и PR у биллинга не всегда хватает функционала: программа должна одновременно учитывать множество факторов параллельно с детальной информацией о клиентах.

Пока кто-то до сих пор считает BigData пустым звуком, «большая четверка» уже делает на ней деньги. МТС за полгода зарабатывает на обработке больших данных 14 миллиардов рублей, а Tele2 увеличил выручку от проектов в три с половиной раза. BigData превращается из тренда в must have, под который будет перестраиваться вся структура операторов связи.

Теги
Показать больше

Похожие статьи

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Кнопка «Наверх»
Закрыть