Didžiųjų duomenų didelis atsiskaitymas: apie „BigData“ telekomunikacijoje

2008 m. BigData buvo naujas terminas ir madinga tendencija. 2019 metais BigData yra pardavimo objektas, pelno šaltinis ir naujų sąskaitų priežastis.

Praėjusį rudenį Rusijos vyriausybė inicijavo didžiųjų duomenų reguliavimo įstatymo projektą. Asmenys gali būti nenustatyti pagal informaciją, bet gali tai padaryti federalinių institucijų prašymu. „BigData“ trečiosioms šalims apdorojama tik pranešus „Roskomnadzor“. Įmonės, turinčios daugiau nei 100 tūkstančių tinklo adresų, patenka į įstatymą. Ir, žinoma, kur be registrų – neva sukurti vieną su duomenų bazių operatorių sąrašu. Ir jei anksčiau į šiuos „Big Data“ ne visi žiūrėjo rimtai, dabar į tai teks atsižvelgti.

Aš, kaip atsiskaitymo kūrėjų įmonės, kuri apdoroja šiuos didelius duomenis, direktorius, negaliu ignoruoti duomenų bazės. Apie didžiuosius duomenis galvosiu per telekomunikacijų operatorių prizmę, per kurių atsiskaitymo sistemas kasdien slenka informacijos srautai apie tūkstančius abonentų.

Teorema

Pradėkime kaip matematikos uždavinyje: pirmiausia įrodome, kad telekomunikacijų operatorių duomenis galima vadinti BigDat. Paprastai dideliems duomenims būdingos trys VVV charakteristikos, nors laisvosiose interpretacijose „V“ skaičius siekė septynis.

Apimtis. Vien Rostelecom MVNO aptarnauja daugiau nei milijoną abonentų. Pagrindiniai prieglobos operatoriai tvarko 44–78 milijonų žmonių duomenis. Srautas auga kas sekundę: pirmąjį 2019 m. ketvirtį abonentai mobiliaisiais telefonais jau pasiekė 3,3 mlrd. GB.

Greitis. Niekas negali papasakoti apie dinamiką geriau nei statistika, todėl peržvelgsiu Cisco prognozes. Iki 2021 m. 20% IP srauto atiteks mobiliajam srautui – per penkerius metus jis beveik patrigubės. Trečdalis mobiliųjų jungčių bus M2M – IoT plėtra lems šešis kartus daugiau jungčių. Daiktų internetas taps ne tik pelningas, bet ir imlus resursams, todėl kai kurie operatoriai susitelks tik į jį. O tie, kurie kuria IoT kaip atskirą paslaugą, gaus dvigubą srautą.

Įvairovė. Įvairovė yra subjektyvi sąvoka, tačiau telekomunikacijų operatoriai tikrai žino beveik viską apie savo abonentus. Nuo vardo ir paso duomenų iki telefono modelio, pirkinių, aplankytų vietų ir pomėgių. Pagal Yarovaya įstatymą medijos failai saugomi šešis mėnesius. Taigi laikykime aksioma, kad renkami duomenys yra įvairūs.

Programinė įranga ir metodika

Teikėjai yra vieni iš pagrindinių BigData vartotojų, todėl dauguma didelių duomenų analizės metodų tinka telekomunikacijų pramonei. Kitas klausimas – kas yra pasirengęs investuoti į ML, AI, Deep Learning plėtrą, investuoti į duomenų centrus ir duomenų gavybą. Visavertis darbas su duomenų baze susideda iš infrastruktūros ir komandos, kurių išlaidas gali sau leisti ne kiekvienas. Įmonės, kurios jau turi įmonės sandėlį arba kuria duomenų valdymo metodiką, turėtų lažintis dėl BigData. Tiems, kurie dar nėra pasiruošę ilgalaikėms investicijoms, patariu palaipsniui kurti programinės įrangos architektūrą ir įdiegti komponentus po vieną. Sunkius modulius ir „Hadoop“ galite palikti paskutiniam. Nedaug žmonių perka paruoštus sprendimus tokioms problemoms kaip duomenų kokybė ir duomenų gavyba; įmonės paprastai pritaiko sistemą pagal savo specifines specifikacijas ir poreikius – pačios arba padedamos kūrėjų.

Tačiau ne kiekvienas atsiskaitymas gali būti pakeistas, kad veiktų su BigData. Tiksliau, ne tik viską galima modifikuoti. Nedaug žmonių gali tai padaryti.

Trys požymiai, kad atsiskaitymo sistema gali tapti duomenų bazės apdorojimo įrankiu:

  • Horizontalus mastelio keitimas. Programinė įranga turi būti lanksti – kalbame apie didelius duomenis. Informacijos kiekio padidėjimas turėtų būti traktuojamas proporcingai padidinus aparatinę įrangą klasteryje.
  • Gedimų tolerancija. Rimtos išankstinio mokėjimo sistemos pagal numatytuosius nustatymus paprastai yra atsparios gedimams: atsiskaitymas yra įdiegtas grupėje keliose geografinėse vietose, kad jos automatiškai apdraustų viena kitą. „Hadoop“ klasteryje taip pat turėtų būti pakankamai kompiuterių, jei vienas ar keli nepavyktų.
  • Vietovė. Duomenys turi būti saugomi ir apdorojami viename serveryje, priešingu atveju galite suklysti dėl duomenų perdavimo. Viena iš populiarių Map-Reduce metodo schemų: HDFS parduotuvės, Spark procesai. Idealiu atveju programinė įranga turėtų sklandžiai integruotis į duomenų centro infrastruktūrą ir vienu metu atlikti tris dalykus: rinkti, tvarkyti ir analizuoti informaciją.

Komanda

Ką, kaip ir kokiu tikslu programa apdoros didžiuosius duomenis, sprendžia komanda. Dažnai jį sudaro vienas asmuo – duomenų mokslininkas. Nors, mano nuomone, minimaliame „Big Data“ darbuotojų pakete taip pat yra produktų vadovas, duomenų inžinierius ir vadovas. Pirmasis supranta paslaugas, verčia techninę kalbą į žmonių kalbą ir atvirkščiai. „Data Engineer“ modelius atgaivina naudodama „Java“ / „Scala“ ir eksperimentuoja su mašininiu mokymusi. Vadovas koordinuoja, nustato tikslus ir kontroliuoja etapus.

Problemos

Būtent BigData komandai dažniausiai kyla problemų renkant ir apdorojant duomenis. Programa turi paaiškinti, ką rinkti ir kaip apdoroti – norint tai paaiškinti, pirmiausia reikia pačiam tai suprasti. Tačiau paslaugų teikėjams viskas nėra taip paprasta. Kalbu apie problemas naudodamas pavyzdį, kaip sumažinti abonentų trūkumą - būtent tai telekomunikacijų operatoriai bando išspręsti pirmiausia naudodami „Big Data“.

Tikslų nustatymas. Gerai parašytos techninės specifikacijos ir skirtingas terminų supratimas buvo šimtmečių senumo kančia ne tik laisvai samdomiems darbuotojams. Net „nukritę“ abonentai gali būti interpretuojami įvairiai - kaip tie, kurie nesinaudojo operatoriaus paslaugomis mėnesį, šešis mėnesius ar metus. O norėdami sukurti MVP pagal istorinius duomenis, turite suprasti abonentų sugrįžimo dažnumą iš churn - tų, kurie bandė kitus operatorius arba paliko miestą ir naudojo kitą numerį. Kitas svarbus klausimas: kiek laiko iki numatomo abonento išvykimo paslaugų teikėjas turėtų tai nustatyti ir imtis veiksmų? Šeši mėnesiai per anksti, savaite per vėlu.

Sąvokų pakeitimas. Paprastai operatoriai identifikuoja klientą pagal telefono numerį, todėl logiška, kad ženklai turėtų būti įkelti jį naudojant. O kaip jūsų asmeninės paskyros ar paslaugos prašymo numeris? Būtina nuspręsti, kurį įrenginį laikyti klientu, kad duomenys operatoriaus sistemoje nesiskirtų. Abejotina ir kliento vertės vertinimas – kuris abonentas įmonei yra vertingesnis, kurį vartotoją išlaikyti reikia daugiau pastangų, o kurie bet kokiu atveju „nukris“ ir nėra prasmės jiems leisti resursų.

Informacijos stoka. Ne visi paslaugų teikėjo darbuotojai gali paaiškinti „BigData“ komandai, kas konkrečiai įtakoja abonentų trūkumą ir kaip apskaičiuojami galimi atsiskaitymo veiksniai. Net jei vieną iš jų pavadintų – ARPU – paaiškėja, kad jį galima apskaičiuoti įvairiai: arba periodiniais klientų mokėjimais, arba automatiniais atsiskaitymo mokesčiais. O darbo procese iškyla milijonas kitų klausimų. Ar modelis apima visus klientus, kokia yra kliento išlaikymo kaina, ar yra prasmės galvoti apie alternatyvius modelius ir ką daryti su klientais, kurie buvo per klaidą dirbtinai išlaikyti.

Tikslų nustatymas. Žinau trijų tipų rezultatų klaidas, dėl kurių operatoriai nusivilia duomenų baze.

  1. Teikėjas investuoja į BigData, apdoroja gigabaitus informacijos, bet gauna rezultatą, kurį būtų buvę galima gauti pigiau. Naudojamos paprastos diagramos ir modeliai, primityvi analitika. Kaina daug kartų didesnė, bet rezultatas tas pats.
  2. Operatorius gauna daugialypius duomenis kaip išvestį, bet nesupranta, kaip juos naudoti. Yra analitika – čia ji suprantama ir didelė, bet neduoda jokios naudos. Galutinis rezultatas, kurio negali sudaryti „duomenų apdorojimo“ tikslas, nebuvo apgalvotas. Neužtenka apdoroti – analitika turėtų tapti verslo procesų atnaujinimo pagrindu.
  3. „BigData analytics“ naudojimo kliūtys gali būti pasenę verslo procesai ir programinė įranga, netinkama naujiems tikslams. Tai reiškia, kad jie padarė klaidą pasiruošimo etape – neapgalvojo veiksmų algoritmo ir didelių duomenų įvedimo į darbą etapų.

Už ką

Kalbant apie rezultatus. Apžvelgsiu būdus, kaip naudoti didelius duomenis ir gauti pinigų iš jų, kuriuos jau naudoja telekomunikacijų operatoriai.
Teikėjai prognozuoja ne tik abonentų nutekėjimą, bet ir bazinių stočių apkrovą.

  1. Analizuojama informacija apie abonentų judėjimą, aktyvumą ir dažnio paslaugas. Rezultatas: perkrovų skaičiaus sumažėjimas optimizuojant ir modernizuojant infrastruktūros problemines sritis.
  2. Atidarydami prekybos vietas, telekomunikacijų operatoriai naudoja informaciją apie abonentų geografinę vietą ir srauto tankį. Taigi „BigData“ analizę jau naudoja MTS ir VimpelCom planuodami naujų biurų vietą.
  3. Teikėjai užsidirba pinigų iš savo didelių duomenų, siūlydami juos trečiosioms šalims. Pagrindiniai BigData operatorių klientai yra komerciniai bankai. Naudodamiesi duomenų baze, jie stebi įtartiną abonento SIM kortelės, su kuria yra susietos kortelės, veiklą, naudojasi rizikos balų, tikrinimo ir stebėjimo paslaugomis. O 2017 metais Maskvos vyriausybė paprašė „Tele2“ atlikti judėjimo dinamiką, pagrįstą „BigData“ duomenimis, kad galėtų planuoti techninę ir transporto infrastruktūrą.
  4. „BigData analytics“ yra aukso kasykla rinkodaros specialistams, kurie, jei nori, gali sukurti individualizuotas reklamos kampanijas tūkstančiams prenumeratorių grupių. Telekomunikacijų įmonės apibendrina socialinius profilius, vartotojų interesus ir abonentų elgesio modelius, o tada naudoja surinktus „BigData“ naujiems klientams pritraukti. Tačiau didelio masto reklamai ir viešųjų ryšių planavimui atsiskaitymas ne visada turi pakankamai funkcijų: programa turi tuo pačiu metu atsižvelgti į daugelį veiksnių kartu su išsamia informacija apie klientus.

Nors kai kurie „BigData“ vis dar laiko tuščia fraze, Didysis ketvertas jau uždirba iš to pinigų. MTS iš didžiųjų duomenų apdorojimo per šešis mėnesius uždirba 14 milijardų rublių, o „Tele2“ pajamas iš projektų padidino tris su puse karto. „BigData“ iš tendencijos virsta „must have“, pagal kurią bus pertvarkyta visa telekomunikacijų operatorių struktūra.

Šaltinis: www.habr.com

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