Nagy adatok, nagy számlázás: Big Data a telekommunikációban

2008-ban a BigData új kifejezés és divatos trend volt. 2019-re a BigData értékesítési tárgy, nyereségforrás és új törvényjavaslatok alapja lett.

Tavaly ősszel az orosz kormány törvényjavaslatot indított a nagy adatok szabályozására. Tilos az emberek azonosítása az információk alapján, de ezt a szövetségi hatóságok kérésére meg lehet tenni. A BigData harmadik fél általi feldolgozása csak a Roskomnadzor értesítése után engedélyezett. A törvény alá tartoznak azok a vállalatok, amelyeknél több mint 100 ezer IP-cím található. És természetesen nem lehet elkerülni a nyilvántartásokat - várhatóan létrehoznak egyet az adatbázis-üzemeltetők listájával. És ha eddig a BigData-t nem mindenki vette komolyan, most már figyelembe kell venni.

Nem kerülhetem el a BigData-t, mint a billing fejlesztőcég igazgatója, amely éppen ezt a BigData-t dolgozza fel. A nagy adatokra a telekommunikációs szolgáltatók szemszögéből fogok gondolkodni, akiknek billing rendszerein nap mint nap információs áramlások mennek át ezer ügyfélről.

Tétele

Kezdjük, mint egy matematikai feladattal: először is bizonyítsuk be, hogy a telekommunikációs szolgáltatók adatait BigDatának lehet nevezni. Szabványos módon a nagy adatokat három V-vel jellemzik, bár szabad értelmezésekben a «V» száma akár hétig is elérhette.

Tömeg. Csak a Rostelecom MVNO több mint egymillió előfizetőt szolgál ki. A kulcsfontosságú hoszt-szolgáltatók 44-78 millió ember adatait dolgozzák fel. A forgalom másodpercenként növekszik: 2019 első negyedévében az előfizetők már 3,3 milliárd GB adatot neteztek mobiltelefonon.

Sebesség. Senki sem tud jobban mesélni a dinamizmusról, mint a statisztika, ezért végigmegyek a Cisco előrejelzésein. 2021-re az IP-forgalom 20%-a a mobil forgalomra fog jutni - ez majdnem háromszoros növekedést jelent öt év alatt. A mobil kapcsolatok egyharmada M2M-re fog jutni - az IoT fejlődése hatszoros növekedést fog okozni a kapcsolatok számában. Az Internet of Things nemcsak jövedelmező, hanem erőforrásigényes irányvonal lesz, ezért egyes szolgáltatók csak erre fognak összpontosítani. Akik külön szolgáltatásként fejlesztik ki az IoT-t, azok dupla forgalmat fognak kapni.

Változatosság. A sokszínűség egy szubjektív fogalom, de a szolgáltatók szinte mindent tudnak az előfizetőikről. A névtől és személyazonosító adatoktól kezdve a telefonmodellhez, a vásárlásokig, a látogatott helyekig és az érdeklődési körökig. A Jarov törvény értelmében a médiafájlokat legalább fél évig kell tárolni. Tehát, tételezzük fel, hogy az összegyűjtött adatok valóban változatosak.

Szoftver és módszertan

A szolgáltatók a Big Data egyik legfontosabb felhasználói, így a nagyméretű adatelemzés módszerei többnyire alkalmazhatók a telekommunikációs iparágban. A kérdés már csak az, hogy ki hajlandó befektetni a ML, AI, Deep Learning fejlesztésébe, és beruházni a adatközpontokba és az adatbányászatba. A megfelelő adatbázis kezelése az infrastruktúrából és a csapatból áll, aminek költségeit nem mindenki engedheti meg magának. A Big Data-ba való befektetésre azoknak a vállalatoknak érdemes, akik már rendelkeznek vállalati tárolóval vagy fejlesztik a Data Governance módszert. Akik még nem készülnek hosszú távú befektetésekre, azoknak javaslom, hogy fokozatosan építsék fel a szoftver architektúráját, és fokozatosan telepítsenek komponenseket. A nehéz modulokat és a Hadoop-ot érdemes a végére hagyni. Csak kevesen vásárolnak kész megoldást az olyan feladatokhoz, mint a Data Quality és Data Mining, a cégek általában a rendszerüket saját specifikációikhoz és igényeikhez igazítják – akár maguk, akár fejlesztők segítségével.

De nem minden billing rendszer módosítható Big Data-de való együttműködéshez. Valójában nem minden módosítható.

Három jel, hogy egy billing rendszer eséllyel válhat az adatbázisok feldolgozásának eszközévé:

  • Horizontális skálázhatóság. A szoftvernek rugalmasnak kell lennie – hiszen hatalmas adatmennyiségekről beszélünk. Az információ mennyiségének növekedését a klaszterben lévő "hardware" arányos növekedésével kell kezelni.
  • Hibatűrés. A komoly prepaid rendszerek általában alapértelmezés szerint hibatűrőek: a billing rendszer klaszterben, több földrajzi helyszínen kerül telepítésre, hogy így automatikusan védjék egymást. A Hadoop klaszterben is elegendő számú számítógépnek kell lennie, hogy egy vagy több hiba esetén is működjön.
  • Helyi tárolás. Az adatoknak ugyanott kell tárolódniuk és feldolgozódniuk szerveren, különben az adatátvitel nagyon költséges lehet. Az egyik népszerű Map-Reduce megközelítési séma: az HDFS tárol, a Spark feldolgoz. Ideális esetben a szoftvernek problémamentesen kell integrálódnia az adatközpont infrastruktúrájába, és három az egyben kell, hogy tudja: gyűjteni, szervezni és elemezni az információt.

A parancs

A csapat dönt arról, hogy miért, hogyan és milyen céllal fogja a program a nagy adatokat feldolgozni. Gyakran egyetlen emberből, a data scientist-ből áll. Véleményem szerint a BigData-hoz szükséges minimális dolgozói csapat magában foglalja a Product menedzsert, a Data Engineert és egy vezetőt. Az első a szolgáltatásokkal foglalkozik, lefordítja a technikai nyelvet emberi nyelvre és vissza. A Data Engineer életre kelti a modelleket Java/Scala segítségével és kísérletezik a Machine Learning-gel. A vezető koordinál, célokat kitűz és ellenőrzi a szakaszokat.

Problems

Éppen a BigData csapat részéről merülnek fel problémák az adatok gyűjtése és feldolgozása során. A programnak magyarázatot kell adni arra, hogy mit és hogyan kell gyűjteni – ehhez először meg kell érteni a problémát. Az szolgáltatóknál nem minden olyan egyszerű. Az alábbiakban a problémákat a felhasználók elvándorlásának csökkentését célzó feladat példáján mutatom be – éppen ezt próbálják először megoldani a szolgáltatók BigData segítségével.

Feladatok megfogalmazása. A jól megfogalmazott műszaki követelmény és a különböző kifejezések értelmezése évezredes fájdalom, nem csak a szabadúszók számára. Még a "lemorzsolódott" felhasználókat is eltérően lehet értelmezni – mint akiket egy hónapja, fél éve vagy egy éve nem szolgál ki a szolgáltató. Az MVP létrehozásához a történeti adatok alapján meg kell érteni a felhasználók visszatéréseinek gyakoriságát az elvándorlás során – azokat, akik más szolgáltató kapcsolatát próbálták ki, vagy akik elhagyták a várost és más számot használtak. Egy másik fontos kérdés: mennyi idővel az elvándorlás tervezett időpontja előtt kell a szolgáltatónak ezt azonosítani és intézkedéseket tenni? Fél évvel korábban – korai, egy héttel korábban – már késő.

Fogalomcsere. A szolgáltatók általában a telefonszám alapján határozzák meg az ügyfelet, így logikus, hogy a jeleket róla kell kiadni. De mi a helyzet a számlaszámmal vagy a szolgáltató alkalmazásának számával? Meg kell határozni, hogy milyen egységet kell ügyfélként kezelni, hogy az operátor rendszerében az adatok ne térjenek el. Az ügyfél értékének értékelése szintén kérdéses – melyik felhasználó értékesebb a cég számára, kit kell nagyobb erőfeszítésekkel megtartani, és kik azok, akik úgyis "lemorzsolódnak" és nincs értelme erőforrást fecsérelni rájuk.

Információhiány. Nem minden szolgáltató munkatársa képes megmagyarázni a BigData csapatának, hogy pontosan mi befolyásolja az előfizetők elvándorlását, és hogyan számítják ki a lehetséges tényezőket a billingben. Még ha egyet meg is említenek – ARPU –, kiderül, hogy azt is különböző módon lehet számítani: vagy az ügyfél időszakos befizetései alapján, vagy a billing automatikus elszámolása szerint. A munka során pedig egy millió más kérdés merül fel. Minden ügyfelet lefed a modell, mi a költsége az ügyfél megtartásának, van-e értelme alternatív modellek kidolgozásának, és mit tegyünk az ügyfelekkel, akiket tévedésből mesterségesen tartanak meg.

Célkitűzés. Háromféle, az eredménnyel kapcsolatos hibát ismerek, amelyek miatt az üzemeltetők csalódottak a BigData-ban.

  1. A szolgáltató fektet be a BigData-ba, feldolgoz gigabájtnyi információt, de olyan eredményt kap, amelyet olcsóbban is megszerezhetett volna. Egyszerű sémákat és modelleket használnak, primitív analitikával. Az önköltség többszöröse, de az eredmény ugyanaz.
  2. Az üzemeltető egy sokrétű adatot kap, de nem tudja, hogyan használja fel azokat. Az analitika itt van – érthető és átfogó, de semmi haszna. A végső eredmény nincs jól megfogalmazva, ami nem korlátozódhat arra, hogy "feldolgozzuk az adatokat". A feldolgozás kevés – az analitikának a vállalati folyamatok frissítésének alapjául kell szolgálnia.
  3. A BigData analitika használatának gátját képezhetik a elavult üzleti folyamatok és a nem megfelelő szoftver az új célokhoz. Ez azt jelenti, hogy a felkészülés során kudarcot vallottunk – nem dolgoztuk ki a lépéseket és a BigData bevezetésének algoritmusát.

Miért

Ami az eredményeket illeti. Futtatom le a BigData felhasználásának és monetizálásának módjait, amelyeket már használnak a szolgáltatók.
A szolgáltatók nemcsak az előfizetők elvándorlását, hanem az alapállomások terhelését is előrejelzik.

  1. Elemzik az előfizetők mozgására, aktivitására és a gyakorisági szolgáltatásokra vonatkozó információkat. Eredmény: a problémás területek infrastruktúrájának optimalizálásával és korszerűsítésével csökken a túlterhelések száma.
  2. Az előfizetők geolokációs és forgalmi sűrűségi információit a szolgáltatók az értékesítési pontok megnyitásakor használják. Így a BigData analitikáját már a MTS és a Vimpelcom is használja az új irodák elhelyezkedésének tervezéséhez.
  3. A szolgáltatók monetizálják saját nagy adataikat, külső cégeknek kínálva azokat. A BigData szolgáltatók fő megrendelői a kereskedelmi bankok. Az adatbázison keresztül nyomon követik a gyanús SIM-kártya tevékenységeket, amelyekhez a kártyák kapcsolódnak, és használják a kockázati minősítés, az azonosítás és a megfigyelés szolgáltatásait. 2017-ben a moszkvai kormány a Tele2-től kérte a BigData adatok mozgásdinamikáját a technikai és szállítási infrastruktúra tervezéséhez.
  4. A BigData elemzés a marketingesek aranybányája, akik személyre szabott hirdetési kampányokat hozhatnak létre akár ezer abonné csoport számára, ha szeretnék. A távközlési cégek aggregálják a társadalmi profilt, a fogyasztói érdeklődést és az abonné viselkedési mintáit, majd a begyűjtött BigData-t új ügyfelek vonzására használják. De a számlázási rendszer nem mindig rendelkezik elegendő funkcióval a nagyszabású promóciós és PR tervezéshez: a programnak egyidejűleg sok tényezőt kell figyelembe vennie, a részletes ügyféladatok mellett.

Míg valaki még mindig azt gondolja, hogy a BigData üres hangzás, a "nagy négyes" már pénzt keres rajta. Az MTS fél év alatt 14 milliárd rubelt keres a nagy adatok feldolgozásával, míg a Tele2 bevételei a projekteknél három és fél szeresére nőttek. A BigData a trendből alapvető szükségletté válik, amelyre az összes távközlési szolgáltató struktúrája át lesz alakítva.

Forrás: habr.com

Megbízható hosting vásárlása weboldalak számára, DDoS védelemmel, VPS VDS szerverek. 🔥 Megbízható webtárhely vásárlása DDoS védelemmel, VPS VDS szerverek | ProHoster