В 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. Вернее, модифицировать могут не только лишь все. Мало кто может это делать.
Три признака, что у биллинговой системы есть шанс стать инструментом обработки БД:
Что, как и для какой цели программа будет обрабатывать большие данные – решает команда. Часто она состоит из одного человека – data scientist’а. Хотя, на мой взгляд, минимальный пакет сотрудников для BigData включает в себя еще и Product-менеджера, Data Engineer’а, руководителя. Первый разбирается в услугах, переводит технический язык на человеческий и обратно. Data Engineer воплощает модели в жизнь с помощью Java/Scala и экспериментирует с Machine Learning. Руководитель координирует, ставит цели, контролирует этапы.
Как раз со стороны команды BigData обычно возникают проблемы при сборе и обработке данных. Программе нужно объяснить, что собирать и как обрабатывать – для того, чтобы это объяснить, нужно сначала самому понять. А у провайдеров не все не так просто. Рассказываю о проблемах на примере задачи по сокращению оттока абонентов – именно ее операторы связи пытаются решить с помощью BigData в первую очередь.
Постановка задач. Грамотно составленное ТЗ и разное понимание терминов – многовековая боль не только для фрилансеров. Даже «отвалившихся» абонентов можно интерпретировать по-разному – как не пользующихся услугами оператора месяц, полгода или год. А для создания MVP на исторических данных нужно понимать частоту возвратов абонентов из оттока – тех, кто пробовал связь других операторов или уезжал из города и пользовался другим номером. Еще один важный вопрос: за сколько времени до предполагаемого ухода абонента провайдер должен это определить и принять меры? За полгода – рано, за неделю – уже поздно.
Подмена понятий. Обычно операторы определяют клиента по номеру телефона, поэтому логично, что признаки нужно выгружать по нему. А что насчет лицевого счета или номера обслуживающего приложения? Нужно определиться, какую единицу следует принимать за клиента, чтобы данные в системе оператора не разнились. Оценка ценности клиента тоже под вопросом – какой абонент более ценный для компании, для удержания какого пользователя нужно приложить больше усилий, а какие «отвалятся» в любом случае и нет смысла тратить на них ресурсы.
Недостаток информации. Далеко не все сотрудники провайдера способны объяснить команде BigData, что конкретно влияет на отток абонентов и как считаются возможные факторы в биллинге. Даже если назвали один из них – ARPU, – оказывается, что и его посчитать можно по-разному: или по периодическим платежам клиента, или по автоматическим начислениям биллинга. А в процессе работы возникает миллион других вопросов. Всех ли клиентов охватывает модель, какова цена за удержание клиента, есть ли смысл продумывать альтернативные модели и что делать с клиентами, которых стали по ошибке искусственно удерживать.
Целеполагание. Я знаю три вида ошибок, связанных с результатом, которые заставляют операторов разочаровываться в БД.
К слову о результатах. Пробегусь по способам использования и монетизации BigData, которыми уже пользуются операторы связи.
Провайдеры прогнозируют не только отток абонентов, но и нагрузки на базовые станции.
Пока кто-то до сих пор считает BigData пустым звуком, «большая четверка» уже делает на ней деньги. МТС за полгода зарабатывает на обработке больших данных 14 миллиардов рублей, а Tele2 увеличил выручку от проектов в три с половиной раза. BigData превращается из тренда в must have, под который будет перестраиваться вся структура операторов связи.
Осенью прошлого года российское правительство инициировало законопроект о регулировании больших данных. Запрещается идентифицировать по информации людей, но разрешается делать это по запросу федеральных органов. Обработка 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, под который будет перестраиваться вся структура операторов связи.
