У 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