Big data big billing: om BigData i telekom

I 2008 var BigData et nytt begrep og moteriktig trend. I 2019 er BigData et salgsobjekt, en kilde til fortjeneste og en årsak til nye regninger.

I fjor høst initierte den russiske regjeringen et lovforslag for å regulere big data. Enkeltpersoner kan ikke identifiseres fra informasjon, men kan gjøre det på forespørsel fra føderale myndigheter. Behandling av BigData for tredjeparter er kun etter varsel fra Roskomnadzor. Bedrifter som har mer enn 100 tusen nettverksadresser faller inn under loven. Og, selvfølgelig, der uten registre - det er ment å lage en med en liste over databaseoperatører. Og hvis før denne Big Data ikke ble tatt på alvor av alle, vil det nå måtte tas hensyn til.

Jeg, som direktør for et faktureringsutviklerselskap som behandler denne store dataen, kan ikke ignorere databasen. Jeg vil tenke på store data gjennom prismet til telekomoperatører, gjennom hvis faktureringssystemer strømmer av informasjon om tusenvis av abonnenter passerer hver dag.

Teorem

La oss starte, som i et matematisk problem: først beviser vi at dataene til teleoperatører kan kalles BigDat. Vanligvis er big data preget av tre VVV-karakteristikker, selv om antallet "Vs" i frie tolkninger nådde syv.

Volum. Rostelecoms MVNO alene betjener mer enn en million abonnenter. Nøkkelvertsoperatører håndterer data for 44 til 78 millioner mennesker. Trafikken vokser hvert sekund: i første kvartal 2019 har abonnenter allerede fått tilgang til 3,3 milliarder GB fra mobiltelefoner.

Hastighet. Ingen kan fortelle deg om dynamikken bedre enn statistikk, så jeg skal gå gjennom Ciscos prognoser. Innen 2021 vil 20 % av IP-trafikken gå til mobiltrafikk – den vil nesten tredobles på fem år. En tredjedel av mobilforbindelsene vil være M2M – utviklingen av IoT vil føre til en seksdobling av forbindelser. Internet of Things vil ikke bare bli lønnsomt, men også ressurskrevende, så noen operatører vil kun fokusere på det. Og de som utvikler IoT som en egen tjeneste vil få dobbel trafikk.

Variasjon. Mangfold er et subjektivt begrep, men teleoperatører vet egentlig nesten alt om abonnentene sine. Fra navn og passdetaljer til telefonmodell, kjøp, besøkte steder og interesser. I følge Yarovaya-loven lagres mediefiler i seks måneder. Så la oss ta det som et aksiom at dataene som samles inn er varierte.

Programvare og metodikk

Leverandører er en av hovedforbrukerne av BigData, så de fleste teknikker for stordataanalyse er anvendelige for telekomindustrien. Et annet spørsmål er hvem som er klar til å investere i utviklingen av ML, AI, Deep Learning, investere i datasentre og data mining. Fullverdig arbeid med en database består av infrastruktur og et team, som ikke alle har råd til. Bedrifter som allerede har et bedriftslager eller utvikler en Data Governance-metodikk bør satse på BigData. For de som ennå ikke er klare for langsiktige investeringer, anbefaler jeg deg å gradvis bygge opp programvarearkitekturen og installere komponenter én etter én. Du kan la de tunge modulene og Hadoop stå til sist. De færreste kjøper en ferdig løsning for problemer som datakvalitet og datautvinning; selskaper tilpasser generelt systemet til deres spesifikke spesifikasjoner og behov – selv eller med hjelp av utviklere.

Men ikke alle faktureringer kan endres for å fungere med BigData. Eller rettere sagt, ikke bare alt kan endres. Få mennesker kan gjøre dette.

Tre tegn på at et faktureringssystem har en sjanse til å bli et databasebehandlingsverktøy:

  • Horisontal skalerbarhet. Programvare må være fleksibel – vi snakker om big data. En økning i informasjonsmengden bør behandles med en proporsjonal økning i maskinvare i klyngen.
  • Feiltoleranse. Seriøse forhåndsbetalte systemer er vanligvis feiltolerante som standard: fakturering distribueres i en klynge i flere geolokasjoner slik at de automatisk forsikrer hverandre. Det bør også være nok datamaskiner i Hadoop-klyngen i tilfelle en eller flere feiler.
  • Lokalitet. Data må lagres og behandles på én server, ellers kan du gå blakk på dataoverføring. En av de populære Map-Reduce-tilnærmingsordningene: HDFS-butikker, Spark-prosesser. Ideelt sett bør programvaren integreres sømløst i datasenterinfrastrukturen og kunne gjøre tre ting i ett: samle inn, organisere og analysere informasjon.

Lag

Hva, hvordan og til hvilket formål programmet skal behandle stordata bestemmes av teamet. Ofte består den av én person – en dataforsker. Selv om, etter min mening, minimumspakken med ansatte for Big Data også inkluderer en produktsjef, dataingeniør og leder. Den første forstår tjenestene, oversetter fagspråk til menneskelig språk og omvendt. Data Engineer bringer modeller til live ved hjelp av Java/Scala og eksperimenterer med maskinlæring. Lederen koordinerer, setter mål og kontrollerer stadiene.

Problemer

Det er fra BigData-teamets side at det vanligvis oppstår problemer ved innsamling og behandling av data. Programmet må forklare hva du skal samle inn og hvordan du skal behandle det - for å forklare dette må du først forstå det selv. Men for tilbydere er ting ikke så enkelt. Jeg snakker om problemene ved å bruke eksemplet med oppgaven med å redusere abonnentavgang - dette er hva teleoperatører prøver å løse ved hjelp av Big Data i utgangspunktet.

Sette mål. Velskrevne tekniske spesifikasjoner og ulike forståelser av begreper har vært en århundregammel smerte, ikke bare for frilansere. Selv "droppede" abonnenter kan tolkes på forskjellige måter - som de som ikke har brukt operatørens tjenester på en måned, seks måneder eller et år. Og for å lage en MVP basert på historiske data, må du forstå frekvensen av returer til abonnenter fra churn - de som prøvde andre operatører eller forlot byen og brukte et annet nummer. Et annet viktig spørsmål: hvor lang tid før abonnenten forventes å forlate bør leverandøren bestemme dette og iverksette tiltak? Seks måneder er for tidlig, en uke er for sent.

Substitusjon av begreper. Vanligvis identifiserer operatører en klient med telefonnummer, så det er logisk at skiltene skal lastes opp ved hjelp av det. Hva med din personlige konto eller tjenestesøknadsnummer? Det er nødvendig å bestemme hvilken enhet som skal tas som klient slik at dataene i operatørens system ikke varierer. Det er også tvilsomt å vurdere verdien av en klient - hvilken abonnent er mer verdifull for selskapet, hvilken bruker krever mer innsats for å beholde, og hvilke som vil "falle av" i alle fall, og det er ingen vits i å bruke ressurser på dem.

Mangel på informasjon. Ikke alle leverandøransatte er i stand til å forklare BigData-teamet hva som spesifikt påvirker abonnentavgang og hvordan mulige faktorer ved fakturering beregnes. Selv om de kalte en av dem - ARPU - viser det seg at den kan beregnes på forskjellige måter: enten ved periodiske klientbetalinger eller ved automatiske faktureringsgebyrer. Og i prosessen med arbeidet dukker det opp en million andre spørsmål. Dekker modellen alle oppdragsgivere, hva er prisen for å beholde en oppdragsgiver, er det noen vits i å tenke gjennom alternative modeller, og hva man skal gjøre med oppdragsgivere som feilaktig har blitt beholdt kunstig.

Målsetting. Jeg kjenner til tre typer utfallsfeil som gjør at operatører blir frustrerte over databasen.

  1. Tilbyderen investerer i BigData, behandler gigabyte med informasjon, men får et resultat som kunne vært oppnådd billigere. Enkle diagrammer og modeller, primitiv analyse brukes. Kostnaden er mange ganger høyere, men resultatet er det samme.
  2. Operatøren mottar mangefasetterte data som utdata, men forstår ikke hvordan de skal brukes. Det er analyser – her er det, forståelig og omfangsrikt, men det nytter ikke. Sluttresultatet, som ikke kan bestå av målet om å «behandle data», er ikke gjennomtenkt. Det er ikke nok å behandle – analyser bør bli grunnlaget for oppdatering av forretningsprosesser.
  3. Hindringer for bruken av BigData-analyse kan være utdaterte forretningsprosesser og programvare som er uegnet for nye formål. Dette betyr at de gjorde en feil på forberedelsesstadiet - de tenkte ikke gjennom handlingsalgoritmen og stadiene for å introdusere Big Data i arbeid.

Hva for

Apropos resultater. Jeg skal gå gjennom måtene å bruke og tjene penger på Big Data som teleoperatører allerede bruker.
Leverandører forutsier ikke bare utstrømming av abonnenter, men også belastningen på basestasjoner.

  1. Informasjon om abonnentens bevegelser, aktivitet og frekvenstjenester analyseres. Resultat: reduksjon i antall overbelastninger på grunn av optimalisering og modernisering av problemområder i infrastrukturen.
  2. Teleoperatører bruker informasjon om abonnentenes geolokalisering og trafikktetthet når de åpner salgssteder. Dermed brukes BigData-analyse allerede av MTS og VimpelCom for å planlegge plassering av nye kontorer.
  3. Leverandører tjener penger på sine egne store data ved å tilby dem til tredjeparter. Hovedkundene til BigData-operatører er kommersielle banker. Ved hjelp av databasen overvåker de mistenkelige aktiviteter på abonnentens SIM-kort som kortene er knyttet til, og bruker risikoscoring, verifisering og overvåkingstjenester. Og i 2017 ba Moskva-regjeringen om bevegelsesdynamikk basert på BigData-data fra Tele2 for å planlegge teknisk og transportinfrastruktur.
  4. BigData-analyse er en gullgruve for markedsførere, som kan lage personlig tilpassede reklamekampanjer for så mange som tusenvis av abonnentgrupper hvis de velger det. Telekomselskaper samler sosiale profiler, forbrukerinteresser og atferdsmønstre til abonnenter, og bruker deretter innsamlet BigData for å tiltrekke seg nye kunder. Men for storskala promotering og PR-planlegging har fakturering ikke alltid nok funksjonalitet: Programmet må samtidig ta hensyn til mange faktorer parallelt med detaljert informasjon om klienter.

Mens noen fortsatt anser BigData som en tom setning, tjener de fire store allerede penger på det. MTS tjener 14 milliarder rubler på stordatabehandling på seks måneder, og Tele2 økte inntektene fra prosjekter med tre og en halv ganger. BigData går fra en trend til et must, der hele strukturen til teleoperatører skal bygges opp igjen.

Kilde: www.habr.com

Legg til en kommentar