Granda datuma fakturado: pri BigData en telekomunikado

En 2008, BigData estis nova esprimo kaj moda tendenco. En 2019, BigData estas objekto de vendo, fonto de profito kaj kialo por novaj fakturoj.

La pasinta aŭtuno, la rusa registaro iniciatis leĝproponon por reguligi grandajn datumojn. Individuoj eble ne estas identigitaj el informoj, sed povas fari tion laŭ la peto de federaciaj aŭtoritatoj. Prilaborado de BigData por triaj estas nur post sciigo pri Roskomnadzor. Firmaoj, kiuj havas pli ol 100 mil retajn adresojn, estas sub la leĝo. Kaj, kompreneble, kie sen registroj - oni supozas krei unu kun listo de datumbazaj operatoroj. Kaj se antaŭe ĉi tiu Big Data ne estis serioze prenita de ĉiuj, nun ĝi devos esti konsiderata.

Mi, kiel la direktoro de faktura ellaboranto-firmao kiu prilaboras ĉi tiujn tre Grandajn Datumojn, ne povas ignori la datumbazon. Mi pensos pri grandaj datumoj per la prismo de telekomunikaj telefonistoj, tra kies fakturaj sistemoj pasas ĉiutage fluoj de informoj pri miloj da abonantoj.

Teoremo

Ni komencu, kiel en matematika problemo: unue ni pruvas, ke la datumoj de telekomunikaj telefonistoj povas nomi BigDat. Tipe, grandaj datumoj estas karakterizitaj per tri VVV-karakterizaĵoj, kvankam en liberaj interpretoj la nombro da "Vs" atingis sep.

Volumo. La MVNO de Rostelecom sole servas pli ol milionon da abonantoj. Ĉefaj mastro-funkciigistoj pritraktas datumojn por 44 ĝis 78 milionoj da homoj. Trafiko kreskas ĉiun sekundon: en la unua trimonato de 2019, abonantoj jam aliris 3,3 miliardojn GB de poŝtelefonoj.

Rapideco. Neniu povas diri al vi pri la dinamiko pli bone ol statistiko, do mi trarigardos la prognozojn de Cisco. Ĝis 2021, 20% de IP-trafiko iros al movebla trafiko - ĝi preskaŭ triobliĝos en kvin jaroj. Triono de moveblaj konektoj estos M2M - la evoluo de IoT kondukos al sesobla pliiĝo de konektoj. La Interreto de Aĵoj fariĝos ne nur enspeziga, sed ankaŭ rimeda intensiva, do iuj funkciigistoj koncentriĝos nur pri ĝi. Kaj tiuj, kiuj disvolvas IoT kiel apartan servon, ricevos duoblan trafikon.

Vario. Diverseco estas subjektiva koncepto, sed teleentreprenistoj vere scias preskaŭ ĉion pri siaj abonantoj. De nomo kaj pasportdetaloj ĝis telefona modelo, aĉetoj, vizititaj lokoj kaj interesoj. Laŭ la leĝo Yarovaya, amaskomunikiloj estas konservitaj dum ses monatoj. Do ni prenu ĝin kiel aksiomon, ke la datumoj kolektitaj estas diversaj.

Programaro kaj metodiko

Provizantoj estas unu el la ĉefaj konsumantoj de BigData, do plej multaj analizteknikoj de grandaj datumoj estas aplikeblaj al la telekomunika industrio. Alia demando estas kiu pretas investi en la disvolviĝo de ML, AI, Deep Learning, investi en datumcentroj kaj datumminado. Plena laboro kun datumbazo konsistas el infrastrukturo kaj teamo, kies kostojn ne ĉiuj povas pagi. Entreprenoj, kiuj jam havas kompanian magazenon aŭ disvolvas metodologion pri Data Governance, devus veti pri BigData. Por tiuj, kiuj ankoraŭ ne estas pretaj por longdaŭraj investoj, mi konsilas al vi iom post iom konstrui la programaran arkitekturon kaj instali komponantojn unu post la alia. Vi povas lasi la pezajn modulojn kaj Hadoop por la lasta. Malmultaj homoj aĉetas pretan solvon por problemoj kiel Datumkvalito kaj Data Mining; kompanioj ĝenerale personigas la sistemon laŭ siaj specifaj specifoj kaj bezonoj - mem aŭ kun la helpo de programistoj.

Sed ne ĉiu fakturado povas esti modifita por labori kun BigData. Aŭ pli ĝuste, ne nur ĉio povas esti modifita. Malmultaj homoj povas fari ĉi tion.

Tri signoj, ke faktura sistemo havas ŝancon fariĝi datumbaza prilaborado:

• Horizontala skaleblo. Programaro devas esti fleksebla - ni parolas pri grandaj datumoj. Pliiĝo en la kvanto de informoj devus esti traktita per proporcia pliiĝo en aparataro en la areto.
• Kulpo toleremo. Seriozaj antaŭpagitaj sistemoj estas kutime misfunkciaj defaŭlte: fakturado estas deplojita en areto en pluraj geolokoj tiel ke ili aŭtomate asekuras unu la alian. Devus ekzisti ankaŭ sufiĉe da komputiloj en la Hadoop-areo en la okazo ke unu aŭ pluraj malsukcesos.
• Loko. Datumoj devas esti stokitaj kaj prilaboritaj sur unu servilo, alie vi povas rompi datumojn. Unu el la popularaj Map-Reduce alirskemoj: HDFS-butikoj, Spark-procezoj. Ideale, la programaro devus perfekte integriĝi en la datumcentran infrastrukturon kaj povi fari tri aferojn en unu: kolekti, organizi kaj analizi informojn.

teamo

Kion, kiel kaj por kia celo la programo prilaboros grandajn datumojn estas decidita de la teamo. Ofte ĝi konsistas el unu persono - datuma sciencisto. Kvankam, laŭ mi, la minimuma pako de dungitoj por Big Data ankaŭ inkluzivas Produktan Administranton, Datuman Inĝenieron kaj Administranton. La unua komprenas la servojn, tradukas teknikan lingvon en homan lingvon kaj inverse. Datuma Inĝeniero vivigas modelojn uzante Java/Scala kaj eksperimentas kun Maŝina Lernado. La administranto kunordigas, metas celojn kaj kontrolas la stadiojn.

Problemoj

Estas flanke de la BigData-teamo, ke problemoj kutime aperas dum kolektado kaj prilaborado de datumoj. La programo devas klarigi kion kolekti kaj kiel prilabori ĝin - por klarigi tion, vi unue devas kompreni ĝin mem. Sed por provizantoj, aferoj ne estas tiel simplaj. Mi parolas pri la problemoj uzante la ekzemplon de la tasko redukti la abonantaron - jen kion telekomunikaj operatoroj provas solvi unue kun la helpo de Big Data.

Fiksante celojn. Bone verkitaj teknikaj specifoj kaj malsamaj komprenoj de terminoj estis jarcenta doloro ne nur por sendependaj dungitoj. Eĉ "faligitaj" abonantoj povas esti interpretitaj en malsamaj manieroj - kiel tiuj, kiuj ne uzis la servojn de la funkciigisto dum monato, ses monatoj aŭ jaro. Kaj por krei MVP bazitan sur historiaj datumoj, vi devas kompreni la oftecon de revenoj de abonantoj de churn - tiuj, kiuj provis aliajn funkciigistojn aŭ forlasis la urbon kaj uzis malsaman nombron. Alia grava demando: kiom longe antaŭ ol la abonanto estas atendita foriri, la provizanto devus determini tion kaj ekagi? Ses monatoj estas tro frue, semajno estas tro malfrue.

Anstataŭigo de konceptoj. Tipe, telefonistoj identigas klienton per telefonnumero, do estas logike, ke la signoj estu alŝutitaj uzante ĝin. Kio pri via persona konto aŭ serva aplika numero? Estas necese decidi, kiu unuo devas esti prenita kiel kliento, por ke la datumoj en la sistemo de la operaciisto ne variu. Taksi la valoron de kliento ankaŭ estas dubinda - kiu abonanto estas pli valora por la kompanio, kiu uzanto postulas pli da peno reteni, kaj kiuj "falos" ĉiukaze kaj ne utilas elspezi rimedojn por ili.

Manko de informo. Ne ĉiuj provizantdungitoj kapablas klarigi al la BigData-teamo, kio specife influas la abonantaron kaj kiel eblaj faktoroj en fakturado estas kalkulitaj. Eĉ se ili nomis unu el ili - ARPU - rezultas, ke ĝi povas esti kalkulita en malsamaj manieroj: aŭ per periodaj klientpagoj, aŭ per aŭtomataj fakturaj kostoj. Kaj dum la laboro, miliono da aliaj demandoj ekestas. Ĉu la modelo kovras ĉiujn klientojn, kio estas la prezo por reteni klienton, ĉu ekzistas ia signifo pensi tra alternativaj modeloj, kaj kion fari kun klientoj, kiuj estis erare artefarite retenitaj.

Celo fikso. Mi scias pri tri specoj de rezultaj eraroj, kiuj igas funkciigistojn frustri kun la datumbazo.

1. La provizanto investas en BigData, prilaboras gigabajtojn da informoj, sed ricevas rezulton, kiu povus esti akirita pli malmultekosta. Simplaj diagramoj kaj modeloj, primitivaj analizoj estas uzataj. La kosto estas multoble pli alta, sed la rezulto estas la sama.
2. La funkciigisto ricevas multfacetajn datumojn kiel eligo, sed ne komprenas kiel uzi ĝin. Estas analizo - jen ĝi estas komprenebla kaj volumena, sed ĝi ne utilas. La fina rezulto, kiu ne povas konsisti el la celo de "prilaborado de datumoj", ne estis pripensita. Ne sufiĉas prilabori - analitiko devas fariĝi la bazo por ĝisdatigi komercajn procezojn.
3. Obstakloj al la uzo de BigData-analitiko povas esti malmodernaj komercaj procezoj kaj programaro netaŭga por novaj celoj. Ĉi tio signifas, ke ili faris eraron en la prepara stadio - ili ne pensis tra la algoritmo de agoj kaj la stadioj de enkonduko de Big Data en la laboron.

Kial

Parolante pri rezultoj. Mi trarigardos la manierojn uzi kaj monetigi Grandajn Datumojn, kiujn telekomunikaj telefonistoj jam uzas.
Provizantoj antaŭdiras ne nur la elfluon de abonantoj, sed ankaŭ la ŝarĝon sur bazstacioj.

1. Informoj pri abonantaj movoj, aktiveco kaj ofteco-servoj estas analizitaj. Rezulto: redukto de la nombro de superŝarĝoj pro optimumigo kaj modernigo de problemaj areoj de la infrastrukturo.
2. Telekomunikaj funkciigistoj uzas informojn pri la geolokigo de abonantoj kaj trafikdenseco kiam malfermas vendopunktojn. Tiel, BigData-analitiko jam estas uzata de MTS kaj VimpelCom por plani la lokon de novaj oficejoj.
3. Provizantoj monetigas siajn proprajn grandajn datumojn proponante ĝin al triaj partioj. La ĉefaj klientoj de BigData-funkciigistoj estas komercaj bankoj. Uzante la datumbazon, ili kontrolas suspektindajn agadojn de la SIM-karto de la abonanto al kiu la kartoj estas ligitaj, kaj uzas riskajn poentadojn, kontrolajn kaj kontrolajn servojn. Kaj en 2017, la Moskva registaro petis movadan dinamikon bazitan sur BigData-datumoj de Tele2 por plani teknikan kaj transportan infrastrukturon.
4. BigData-analitiko estas orminejo por merkatistoj, kiuj povas krei personigitajn reklamajn kampanjojn por eĉ miloj da abonantaj grupoj, se ili volas. Telekomunikaj kompanioj kunigas sociajn profilojn, konsumantajn interesojn kaj kondutajn ŝablonojn de abonantoj, kaj poste uzas la kolektitajn BigData-ojn por altiri novajn klientojn. Sed por grandskala reklamado kaj PR-planado, fakturado ne ĉiam havas sufiĉe da funkcieco: la programo devas samtempe konsideri multajn faktorojn paralele kun detalaj informoj pri klientoj.

Dum iuj ankoraŭ konsideras BigData malplena frazo, la Grandaj Kvar jam gajnas monon per ĝi. MTS gajnas 14 miliardojn da rubloj el granda datuma prilaborado en ses monatoj, kaj Tele2 pliigis enspezon de projektoj trifoje kaj duono. BigData turniĝas de tendenco al havendaĵo, sub kiu la tuta strukturo de telekomunikaj telefonistoj estos rekonstruita.

fonto: www.habr.com