Ez az analitikai rendszerekkel foglalkozó cikksorozat második része ().
Ma már nem kétséges, hogy az adatok pontos feldolgozása, az eredmények értelmezése szinte minden vállalkozástípust segíthet. E tekintetben az elemző rendszerek egyre jobban megterhelődnek paraméterekkel, az alkalmazásokban egyre növekszik a triggerek és felhasználói események száma.
Emiatt a vállalatok egyre több "nyers" információt adnak át elemzőiknek, hogy elemezzék és helyes döntésekké alakítsák. Nem szabad alábecsülni az analitikai rendszer jelentőségét egy vállalat számára, magának a rendszernek pedig megbízhatónak és fenntarthatónak kell lennie.
Ügyfélelemzők
Az ügyfélelemzés egy olyan szolgáltatás, amelyet a vállalat a hivatalos SDK-n keresztül csatlakozik webhelyéhez vagy alkalmazásához, integrálja azt saját kódbázisába, és kiválasztja az eseményindítókat. Ennek a megközelítésnek van egy nyilvánvaló hátránya: az összes összegyűjtött adatot nem lehet az Ön által kívánt módon feldolgozni, a választott szolgáltatás korlátai miatt. Például az egyik rendszeren nem lesz egyszerű a MapReduce feladatok futtatása, a másikon nem tudja futtatni a modellt. További hátránya lesz a rendszeres (lenyűgöző) szolgáltatások számla.
Számos ügyfélelemzési megoldás létezik a piacon, de az elemzők előbb-utóbb szembesülnek azzal, hogy nincs egyetlen feladatra alkalmas univerzális szolgáltatás (miközben ezeknek a szolgáltatásoknak az ára folyamatosan nő). Ilyen helyzetben a vállalatok gyakran úgy döntenek, hogy saját analitikai rendszert hoznak létre az összes szükséges egyéni beállítással és funkcióval.
Szerverelemzők
A szerveroldali elemzés egy olyan szolgáltatás, amely a vállalat saját szerverein belül és (általában) házon belül telepíthető. Ebben a modellben az összes felhasználói eseményt belső szervereken tárolják, így a fejlesztők különböző adatbázisokat próbálhatnak ki tárolás céljából, és kiválaszthatják a legkényelmesebb architektúrát. És még akkor is, ha bizonyos feladatokhoz harmadik féltől származó ügyféloldali elemzést szeretne használni, ez továbbra is lehetséges.
A szerveroldali elemzés kétféleképpen telepíthető. Először is: válasszon néhány nyílt forráskódú segédprogramot, telepítse azokat a gépeire, és fejlessze az üzleti logikát.
Érvek
Hátrányok
Bármit testre szabhat
Ez gyakran nagyon nehéz, és külön fejlesztőkre van szükség
Másodszor: vegye igénybe a SaaS-szolgáltatásokat (Amazon, Google, Azure), ahelyett, hogy saját maga telepítené. A SaaS-ről részletesebben a harmadik részben lesz szó.
Érvek
Hátrányok
Közepes mennyiségnél olcsóbb lehet, de nagy emeléssel még mindig túl drága lesz
Nem tud minden paramétert szabályozni
Az adminisztráció teljes mértékben a szolgáltató vállára hárul
Nem mindig tudni, hogy mi van a szolgáltatáson belül (lehet, hogy nincs rá szükség)
Hogyan gyűjtsünk szerverelemzést
Ha meg akarunk szabadulni a kliens analitika használatától, és saját magunkat szeretnénk felépíteni, akkor mindenekelőtt át kell gondolnunk az új rendszer architektúráját. Az alábbiakban lépésről lépésre elmondom, mit kell figyelembe vennie, miért van szükség az egyes lépésekre, és milyen eszközöket használhat.
1. Adatgyűjtés
Csakúgy, mint az ügyfélelemzés esetében, a vállalati elemzők mindenekelőtt kiválasztják azokat az események típusait, amelyeket tovább kívánnak vizsgálni, és listába gyűjtik. Általában ezek az események egy bizonyos sorrendben történnek, amit "eseménysémának" neveznek.
Továbbá képzeljük el, hogy egy mobilalkalmazásnak (webhelynek) rendszeres felhasználók (eszközök) és sok szervere van. Az események eszközökről a szerverekre történő biztonságos átviteléhez köztes rétegre van szükség. Az architektúrától függően több különböző eseménysor is előfordulhat.
- Van , amelyet az események gyűjtésére szolgáló sorként használnak.
Szerint 2014-ben az Apache Kafka alkotója úgy döntött, hogy Franz Kafkáról nevezi el a szoftvert, mert „írásra optimalizált rendszer”, és mert szerette Kafka írásait. —
Példánkban sok adattermelő és fogyasztóik (eszközök és szerverek) szerepelnek, és a Kafka segít összekapcsolni őket. A fogyasztókat a következő lépésekben ismertetjük részletesebben, ahol ők lesznek a főszereplők. Most csak az adatelőállítókat (eseményeket) fogjuk figyelembe venni.
Kafka magába foglalja a sor és a partíció fogalmát, pontosabban erről érdemes máshol olvasni (pl. ). Anélkül, hogy belemennénk a részletekbe, képzeljük el, hogy két különböző operációs rendszerre indul el egy mobilalkalmazás. Ezután minden verzió külön eseményfolyamot hoz létre. A producerek Kafkának küldik az eseményeket, azokat megfelelő sorban rögzítik.
(kép )
Ugyanakkor a Kafka lehetővé teszi, hogy részletekben olvasson, és mini kötegekben dolgozza fel az események folyamatát. A Kafka egy nagyon kényelmes eszköz, amely jól skálázható a növekvő igényekhez (például az események földrajzi elhelyezkedése alapján).
Általában elég egy szilánk, de a méretezés során a kommunikáció bonyolultabbá válik (mint mindig). Valószínűleg senki sem akar csak egy fizikai szilánkot használni a termelésben, mivel az architektúrának hibatűrőnek kell lennie. A Kafka mellett van egy másik jól ismert megoldás - a RabbitMQ. A termelésben nem használtuk eseményelemzési sorként (ha van ilyen tapasztalatod, írd meg nekünk kommentben!). Azonban AWS Kinesis-t használtak.
Mielőtt a következő lépésre lépnénk, meg kell említeni a rendszer egy további rétegét - a nyers naplók tárolását. Ez nem kötelező réteg, de hasznos lehet abban az esetben, ha valami elromlik, és a Kafka eseménysorait nullára állítják vissza. A nyers naplók tárolása nem igényel bonyolult és költséges megoldást, egyszerűen felírhatja őket a megfelelő sorrendben valahova (akár merevlemezre).
2. Eseményfolyamok kezelése
Miután az összes eseményt előkészítettük és a megfelelő sorba helyeztük, továbblépünk a feldolgozási lépésre. Itt a két leggyakoribb feldolgozási lehetőségről fogok beszélni.
Az első lehetőség a Spark Streaming engedélyezése Apache rendszeren. Minden Apache-termék HDFS-en, egy biztonságos replikafájlrendszeren él. A Spark Streaming egy könnyen használható eszköz, amely jól feldolgozza a streamelési adatokat és jól skálázható. Azonban nehéz lehet fenntartani.
Egy másik lehetőség a saját eseménykezelő létrehozása. Ehhez például meg kell írnia egy Python-alkalmazást, össze kell építenie a dockerben, és elő kell fizetnie a Kafka-sorokra. Amikor az eseményindítók megérkeznek a docker kezelőihez, elindul a feldolgozás. Ezzel a módszerrel folyamatosan futni kell az alkalmazásokat.
Tegyük fel, hogy a fent leírt lehetőségek közül választottunk egyet, és térjünk át magára a feldolgozásra. A processzoroknak az adatok érvényességének ellenőrzésével kell kezdeniük, kiszűrniük a szemetet és a "törött" eseményeket. Az érvényesítéshez általában azt használjuk . Ezt követően elvégezhető az adatleképezés: a különböző forrásokból származó adatokat normalizáljuk és szabványosítjuk, hogy egy közös táblázatba kerüljenek.
3. Adatbázis
A harmadik lépés a normalizált események mentése. Amikor egy kész elemző rendszerrel dolgozunk, gyakran hozzá kell férnünk hozzájuk, ezért fontos a kényelmes adatbázis kiválasztása.
Ha az adatok jól illeszkednek egy rögzített sémára, választhat vagy más oszlop adatbázis. Tehát az aggregációk nagyon gyorsan működnek. Hátránya, hogy a séma mereven rögzítve van, ezért nem fog tetszőleges objektumokat hozzáadni finomítás nélkül (például, ha nem szabványos esemény történik). De nagyon gyorsan meg lehet csinálni.
Strukturálatlan adatokhoz használhatja például a NoSQL-t, . HDFS-en fut, jól replikálódik, sok példányt hozhat létre, és hibatűrő.
Felvethetsz valami egyszerűbbet is, pl. . Kis mennyiségeknél is elég lassú. De az a plusz, hogy nagyon egyszerű, ezért alkalmas az indításhoz.
4. Aggregációk
Az összes esemény gondos elmentése után minden fontos információt össze akarunk gyűjteni a érkezett kötegből, és frissíteni szeretnénk az adatbázist. Globálisan releváns irányítópultokat és mutatókat akarunk. Például eseményekből felhasználói profil gyűjtése és viselkedés mérése. Az események összesítése, összegyűjtése és ismételt mentése (már felhasználói táblákban). Ugyanakkor lehetőség van úgy is rendszert építeni, hogy a koordináló aggregátorhoz egy szűrő is csatlakozzon: csak bizonyos típusú eseményekről gyűjtsön felhasználókat.
Ezt követően, ha valakinek a csapatból csak magas szintű elemzésre van szüksége, külső elemzőrendszereket is csatlakoztathat. Újra beveheti a Mixpanelt. de mivel elég drága, nem minden felhasználói esemény kerül oda, hanem csak ami kell. Ehhez létre kell hoznunk egy koordinátort, aki néhány nyers eseményt vagy valamit, amit korábban mi magunk összesítettünk, továbbít külső rendszerekre, API-kra vagy hirdetési platformokra.
5. Frontend
A frontendet csatlakoztatnia kell a létrehozott rendszerhez. Jó példa erre a szolgáltatás. , egy adatbázis GUI, amely segít panelek létrehozásában. Hogyan működik az interakció:
- A felhasználó SQL lekérdezést hajt végre.
- Válaszul egy jelet kap.
- Létrehoz egy „új vizualizációt”, és egy gyönyörű grafikont kap, amelyet már el is menthet.
A szolgáltatásban lévő vizualizációk automatikusan frissülnek, Ön konfigurálhatja és nyomon követheti a megfigyelést. A Redash ingyenes, saját hosztolás esetén, de SaaS-ként havi 50 dollárba kerül.
Következtetés
A fenti lépések végrehajtása után létrehozza a szerveroldali elemzést. Kérjük, vegye figyelembe, hogy ez nem olyan egyszerű, mint az ügyfélelemzés összekapcsolása, mert mindent saját magának kell konfigurálnia. Ezért a saját rendszer létrehozása előtt érdemes összevetni egy komoly analitikai rendszer szükségességét azokkal az erőforrásokkal, amelyeket erre készen áll.
Ha minden számítást elvégzett, és úgy találta, hogy a költségek túl magasak, a következő részben arról fogok beszélni, hogyan készíthetek olcsóbb háttérelemzést.
Köszönöm, hogy elolvasta! Szívesen válaszolok kérdésekre a megjegyzésekben.
Forrás: will.com