Hierdie is die tweede deel van 'n reeks artikels oor analitiese stelsels ().
Vandag is daar geen twyfel dat die akkurate verwerking van data en die interpretasie van resultate byna enige tipe besigheid kan help nie. In hierdie verband word analitiese stelsels meer en meer gelaai met parameters, die aantal snellers en gebruikergebeurtenisse in toepassings groei.
As gevolg hiervan gee maatskappye hul ontleders al hoe meer "rou" inligting om dit te ontleed en in die regte besluite te omskep. Die belangrikheid van 'n ontledingstelsel vir 'n maatskappy moet nie onderskat word nie, en die stelsel self moet betroubaar en volhoubaar wees.
Kliënte ontleders
Kliëntanalise is 'n diens wat 'n maatskappy vir sy webwerf of toepassing deur die amptelike SDK koppel, dit in sy eie kodebasis integreer en gebeurtenissnellers kies. Hierdie benadering het 'n ooglopende nadeel: al die versamelde data kan nie volledig verwerk word soos jy wil nie, as gevolg van die beperkings van enige gekose diens. Byvoorbeeld, op een stelsel sal dit nie maklik wees om MapReduce-take uit te voer nie, op 'n ander sal jy nie jou model kan laat loop nie. Nog 'n nadeel sal 'n gereelde (indrukwekkende) rekening vir dienste wees.
Daar is baie kliëntontledingsoplossings op die mark, maar vroeër of later word ontleders gekonfronteer met die feit dat daar nie een universele diens is wat vir enige taak geskik is nie (terwyl die pryse vir al hierdie dienste voortdurend groei). In so 'n situasie besluit maatskappye dikwels om hul eie ontledingstelsel te skep met al die nodige pasgemaakte instellings en kenmerke.
Bediener Ontleders
Bedienerkant-analise is 'n diens wat intern op 'n maatskappy se eie bedieners en (gewoonlik) intern ontplooi kan word. In hierdie model word alle gebruikergebeurtenisse op interne bedieners gestoor, wat ontwikkelaars in staat stel om verskillende databasisse vir berging te probeer en die gerieflikste argitektuur te kies. En selfs as jy steeds derdeparty-kliënt-kant-analise vir sommige take wil gebruik, sal dit steeds moontlik wees.
Bedienerkant-analise kan op twee maniere ontplooi word. Eerstens: kies 'n paar oopbronhulpprogramme, ontplooi dit op u masjiene en ontwikkel besigheidslogika.
Pros
Nadele
Jy kan enigiets pasmaak
Dikwels is dit baie moeilik en aparte ontwikkelaars is nodig
Tweedens: neem SaaS-dienste (Amazon, Google, Azure) in plaas daarvan om dit self te ontplooi. Ons sal in die derde deel in meer besonderhede oor SaaS praat.
Pros
Nadele
Dit kan goedkoper wees op medium volumes, maar met 'n groot verhoging sal dit steeds te duur word
Nie in staat om alle parameters te beheer nie
Administrasie word geheel en al na die skouers van die diensverskaffer verskuif
Dit is nie altyd bekend wat binne die diens is nie (mag nie nodig wees nie)
Hoe om bedieneranalise te versamel
As ons wil wegkom van die gebruik van kliëntanalise en ons eie wil bou, moet ons eerstens oor die argitektuur van die nuwe stelsel dink. Hieronder sal ek jou stap vir stap vertel wat jy moet oorweeg, hoekom elkeen van die stappe nodig is en watter gereedskap jy kan gebruik.
1. Data-verkryging
Net soos in die geval van kliëntanalise, kies maatskappyontleders eerstens die tipe gebeurtenisse wat hulle verder wil bestudeer en versamel dit in 'n lys. Gewoonlik vind hierdie gebeure in 'n sekere volgorde plaas, wat die "gebeurtenisskema" genoem word.
Kom ons stel ons verder voor dat 'n mobiele toepassing (webwerf) gereelde gebruikers (toestelle) en baie bedieners het. Om gebeurtenisse veilig van toestelle na bedieners oor te dra, is 'n tussenlaag nodig. Afhangende van die argitektuur, kan verskeie verskillende gebeurtenisrye voorkom.
- Is , wat gebruik word as 'n tou om geleenthede in te samel.
Volgens in 2014 het die skepper van Apache Kafka besluit om die sagteware na Franz Kafka te vernoem omdat “dit 'n skryf-geoptimaliseerde stelsel is” en omdat hy lief was vir Kafka se geskrifte. —
In ons voorbeeld is daar baie datavervaardigers en hul verbruikers (toestelle en bedieners), en Kafka help om hulle aan mekaar te koppel. Verbruikers sal in die volgende stappe in meer besonderhede beskryf word, waar hulle die hoofrolspelers sal wees. Nou sal ons slegs dataprodusente (gebeurtenisse) oorweeg.
Kafka vat die konsepte van tou en partisie saam, meer spesifiek hieroor is dit beter om elders te lees (byvoorbeeld in ). Sonder om in besonderhede in te gaan, laat ons ons voorstel dat 'n mobiele toepassing vir twee verskillende bedryfstelsels bekendgestel word. Dan skep elke weergawe sy eie afsonderlike gebeurtenisstroom. Produsente stuur geleenthede aan Kafka, dit word in 'n geskikte tou opgeneem.
(prent )
Terselfdertyd laat Kafka jou toe om in stukke te lees en die vloei van gebeure in mini-groepe te verwerk. Kafka is 'n baie gerieflike hulpmiddel wat goed skaal met groeiende behoeftes (byvoorbeeld deur geoligging van gebeurtenisse).
Gewoonlik is een skerf genoeg, maar dinge raak meer ingewikkeld met kommunikasie wanneer skaal (soos altyd). Waarskynlik wil niemand net een fisiese skerf in produksie gebruik nie, aangesien die argitektuur foutverdraagsaam moet wees. Benewens Kafka is daar nog 'n bekende oplossing - RabbitMQ. Ons het dit nie in produksie gebruik as 'n tou vir gebeurtenisanalise nie (as jy sulke ondervinding het, vertel ons daarvan in die kommentaar!). AWS Kinesis is egter gebruik.
Voordat u na die volgende stap gaan, moet nog 'n addisionele laag van die stelsel genoem word - die berging van rou stompe. Dit is nie 'n verpligte laag nie, maar dit sal nuttig wees as iets verkeerd gaan en die gebeurtenisrye in Kafka na nul teruggestel word. Die stoor van rou logs vereis nie 'n komplekse en duur oplossing nie, jy kan dit eenvoudig iewers in die regte volgorde skryf (selfs op 'n hardeskyf).
2. Hantering van gebeurtenisstrome
Nadat ons al die gebeure voorberei en in die toepaslike rye geplaas het, gaan ons aan na die verwerkingstap. Hier sal ek praat oor die twee mees algemene verwerkingsopsies.
Die eerste opsie is om Spark Streaming op 'n Apache-stelsel te aktiveer. Alle Apache-produkte leef op HDFS, 'n veilige replika-lêerstelsel. Spark Streaming is 'n maklik-om-te gebruik hulpmiddel wat stroomdata verwerk en goed skaal. Dit kan egter moeilik wees om te onderhou.
Nog 'n opsie is om jou eie gebeurtenis hanteerder te bou. Om dit te doen, moet jy byvoorbeeld 'n Python-toepassing skryf, dit in docker bou en inteken op Kafka se toue. Wanneer snellers na hanteerders in die koppelaar kom, sal verwerking begin. Met hierdie metode moet u voortdurend toepassings laat loop.
Kom ons neem aan dat ons een van die opsies hierbo beskryf het gekies en gaan aan na die verwerking self. Verwerkers moet begin deur die geldigheid van die data na te gaan, vullis en "gebroke" gebeure uit te filter. Vir validering gebruik ons gewoonlik . Daarna kan datakartering gedoen word: data van verskillende bronne word genormaliseer en gestandaardiseer om by 'n gemeenskaplike tabel gevoeg te word.
3. Databasis
Die derde stap is om genormaliseerde gebeure te stoor. Wanneer ons met 'n klaargemaakte analitiese stelsel werk, sal ons dikwels toegang daartoe moet kry, daarom is dit belangrik om 'n gerieflike databasis te kies.
As die data goed op 'n vaste skema pas, kan jy kies of 'n ander kolom databasis. Aggregasies sal dus baie vinnig werk. Die nadeel is dat die skema streng vasgestel is en daarom sal dit nie werk om arbitrêre voorwerpe sonder verfyning by te voeg nie (byvoorbeeld wanneer 'n nie-standaard gebeurtenis plaasvind). Maar dit kan baie vinnig gedoen word.
Vir ongestruktureerde data kan jy byvoorbeeld NoSQL neem, . Dit werk op HDFS, repliseer goed, jy kan baie gevalle opdoen en is foutverdraagsaam.
Jy kan iets eenvoudiger insamel, byvoorbeeld, . Dit is redelik stadig, selfs vir klein volumes. Maar die pluspunt is dat dit baie eenvoudig is en dus geskik is om te begin.
4. Aggregasies
Nadat ons al die gebeure noukeurig gestoor het, wil ons al die belangrike inligting van die bondel wat gekom het, versamel en die databasis opdateer. Wêreldwyd wil ons relevante kontroleskerms en maatstawwe hê. Byvoorbeeld, van gebeurtenisse om 'n gebruikersprofiel te versamel en op een of ander manier gedrag te meet. Gebeurtenisse word saamgevoeg, versamel en weer gestoor (reeds in gebruikerstabelle). Terselfdertyd is dit moontlik om 'n stelsel op so 'n manier te bou dat 'n filter ook aan die koördinerende aggregator gekoppel word: om gebruikers slegs van 'n sekere tipe gebeurtenisse te versamel.
Daarna, as iemand in die span net hoëvlak-analise benodig, kan jy eksterne ontledingstelsels koppel. Jy kan weer Mixpanel neem. maar aangesien dit redelik duur is, word nie alle gebruikergebeurtenisse daarheen gestuur nie, maar slegs wat nodig is. Om dit te doen, moet ons 'n koördineerder skep wat 'n paar rou gebeurtenisse of iets wat ons self vroeër saamgevoeg het na eksterne stelsels, API's of advertensieplatforms sal oordra.
5. Voorkant
U moet die frontend aan die geskepte stelsel koppel. 'n Goeie voorbeeld is diens. , is 'n databasis GUI wat help om panele te bou. Hoe die interaksie werk:
- Die gebruiker maak 'n SQL-navraag.
- In reaksie ontvang hy 'n teken.
- Skep 'n 'nuwe visualisering' daarvoor en kry 'n pragtige grafiek wat jy self reeds kan red.
Visualisasies in die diens word outomaties opgedateer, u kan u monitering instel en opspoor. Redash is gratis, in die geval van self-gasheer, maar as SaaS sal dit $50 per maand kos.
Gevolgtrekking
Nadat u al die stappe hierbo voltooi het, sal u u analise aan die bedienerkant skep. Neem asseblief kennis dat dit nie so maklik is soos om net kliëntanalise te koppel nie, want alles moet op jou eie gekonfigureer word. Daarom, voordat u u eie stelsel skep, is dit die moeite werd om die behoefte aan 'n ernstige ontledingstelsel te vergelyk met die hulpbronne wat u gereed is om daaraan toe te ken.
As jy al die wiskunde gedoen het en gevind het dat die koste te hoog is, sal ek in die volgende deel praat oor hoe om 'n goedkoper weergawe van back-end-analise te maak.
Dankie vir die lees! Ek sal bly wees oor vrae in die kommentaar.
Bron: will.com