У 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, під який буде перебудовуватися вся структура операторів зв'язку.
Джерело: habr.com