Þetta er seinni hluti af greinaröð um greiningarkerfi ().
Í dag er enginn vafi lengur á því að nákvæm gagnavinnsla og túlkun á niðurstöðum getur hjálpað nánast hvers kyns viðskiptum. Í þessu sambandi eru greiningarkerfi sífellt hlaðin breytum og fjöldi kveikja og notendaviðburða í forritum fer vaxandi.
Vegna þessa eru fyrirtæki að gefa sérfræðingum sínum sífellt meiri hráar upplýsingar til að greina og breyta í skynsamlegar ákvarðanir. Ekki má vanmeta mikilvægi greiningarkerfis fyrir fyrirtæki og kerfið sjálft þarf að vera áreiðanlegt og stöðugt.
Sérfræðingar viðskiptavina
Viðskiptavinagreining er þjónusta sem fyrirtæki tengir við vefsíðu sína eða forrit í gegnum opinbera SDK, fellur inn í eigin kóðagrunn og velur atburðakveikjur. Það er augljós ókostur við þessa nálgun: ekki er víst að öll gögn sem safnað sé unnin nákvæmlega eins og þú vilt vegna takmarkana hvaða þjónustu sem þú velur. Til dæmis, á einu kerfi verður ekki auðvelt að keyra MapReduce verkefni, á öðru muntu ekki geta keyrt líkanið þitt. Annar ókostur verður venjulegur (áhrifamikill) reikningur fyrir þjónustu.
Á markaðnum eru margar greiningarlausnir fyrir viðskiptavini, en fyrr eða síðar standa greiningaraðilar frammi fyrir því að það er engin alþjónusta sem hentar hverju verkefni (á meðan verð fyrir alla þessa þjónustu hækkar stöðugt). Við slíkar aðstæður ákveða fyrirtæki oft að búa til sitt eigið greiningarkerfi með öllum nauðsynlegum sérstillingum og getu.
Sérfræðingar á netþjónum
Greining á netþjóni er þjónusta sem hægt er að nota innan fyrirtækis á eigin netþjónum og (venjulega) með eigin krafti. Í þessu líkani eru allir notendaviðburðir geymdir á innri netþjónum, sem gerir forriturum kleift að prófa mismunandi geymslugagnagrunna og velja hentugasta arkitektúrinn. Og jafnvel þótt þú viljir enn nota þriðja aðila greiningar viðskiptavina fyrir sum verkefni, þá mun það samt vera mögulegt.
Hægt er að beita greiningum á netþjóni á tvo vegu. Í fyrsta lagi: veldu nokkur opinn hugbúnað, settu þau upp á vélarnar þínar og þróaðu viðskiptarökfræði.
Kostir
Gallar
Þú getur sérsniðið hvað sem þú vilt
Þetta er oft mjög erfitt og krefst sérstakra forritara
Í öðru lagi: taktu SaaS þjónustu (Amazon, Google, Azure) í stað þess að nota hana sjálfur. Við munum tala um SaaS nánar í þriðja hluta.
Kostir
Gallar
Það getur verið ódýrara í miðlungs magni, en með miklum vexti verður það samt of dýrt
Ekki verður hægt að stjórna öllum breytum
Stjórnsýsla er alfarið færð á herðar þjónustuveitanda
Það er ekki alltaf vitað hvað er inni í þjónustunni (það er kannski ekki þörf)
Hvernig á að safna greiningum á netþjónum
Ef við viljum hverfa frá því að nota viðskiptavinagreiningar og byggja okkar eigin, þurfum við fyrst og fremst að hugsa í gegnum arkitektúr nýja kerfisins. Hér að neðan mun ég segja þér skref fyrir skref hvað þú þarft að hafa í huga, hvers vegna hvert skref er nauðsynlegt og hvaða verkfæri þú getur notað.
1. Móttaka gagna
Rétt eins og í tilviki viðskiptavinagreiningar, þá velja fyrirtækissérfræðingar í fyrsta lagi þær tegundir atburða sem þeir vilja rannsaka í framtíðinni og safna þeim á lista. Venjulega gerast þessir atburðir í ákveðinni röð, kallað "atburðarmynstur".
Næst skaltu ímynda þér að farsímaforrit (vefsíða) hafi venjulega notendur (tæki) og marga netþjóna. Til að flytja atburði á öruggan hátt frá tækjum yfir á netþjóna þarf millilag. Það fer eftir arkitektúrnum, það geta verið nokkrar mismunandi viðburðarraðir.
- Er , sem er notað sem biðröð til að safna viðburðum.
Samkvæmt árið 2014 ákvað skapari Apache Kafka að nefna hugbúnaðinn eftir Franz Kafka vegna þess að „það er fínstillt kerfi til að skrifa“ og vegna þess að hann elskaði verk Kafka. —
Í dæminu okkar eru margir gagnaframleiðendur og gagnaneytendur (tæki og netþjónar) og Kafka hjálpar til við að tengja þá hver við annan. Neytendum verður lýst nánar í eftirfarandi skrefum þar sem þeir verða aðalviðfangsefni. Nú munum við aðeins fjalla um gagnaframleiðendur (atburði).
Kafka tekur saman hugtökin biðröð og skipting; það er betra að lesa nánar um þetta annars staðar (td í ). Án þess að fara í smáatriði, við skulum ímynda okkur að farsímaforrit sé hleypt af stokkunum fyrir tvö mismunandi stýrikerfi. Síðan býr hver útgáfa til sinn eigin viðburðarstraum. Framleiðendur senda viðburði til Kafka, þeir eru skráðir í viðeigandi biðröð.
(mynd )
Á sama tíma gerir Kafka þér kleift að lesa í bita og vinna úr straumi atburða í litlum lotum. Kafka er mjög þægilegt tól sem mælist vel með vaxandi þörfum (til dæmis með landfræðilegri staðsetningu viðburða).
Venjulega dugar eitt brot, en hlutirnir verða flóknari við skala (eins og þeir gera alltaf). Líklega mun enginn vilja nota aðeins eina líkamlega brot í framleiðslu, þar sem arkitektúrinn verður að vera bilunarþolinn. Auk Kafka er önnur vel þekkt lausn - RabbitMQ. Við notuðum það ekki í framleiðslu sem biðröð fyrir viðburðagreiningu (ef þú hefur slíka reynslu, segðu okkur frá því í athugasemdunum!). Hins vegar notuðum við AWS Kinesis.
Áður en haldið er áfram í næsta skref verðum við að minnast á enn eitt lag kerfisins til viðbótar - óunnið loggeymsla. Þetta er ekki áskilið lag, en það mun vera gagnlegt ef eitthvað fer úrskeiðis og viðburðarraðir í Kafka eru endurstilltar. Að geyma hráa annála krefst ekki flóknar og dýrrar lausnar; þú getur einfaldlega skrifað þá einhvers staðar í réttri röð (jafnvel á harða disknum).
2. Vinnsla atburðarstrauma
Eftir að við höfum undirbúið alla atburði og sett þá í viðeigandi biðraðir förum við yfir í vinnsluþrepið. Hér mun ég segja þér frá tveimur algengustu vinnslumöguleikunum.
Fyrsti kosturinn er að virkja Spark Streaming í Apache kerfinu. Allar Apache vörur lifa á HDFS, öruggu skráarkerfi með skráarafmyndum. Spark Streaming er auðvelt í notkun tól sem meðhöndlar streymigögn og skalar vel. Hins vegar getur verið erfitt að viðhalda því.
Annar valkostur er að smíða þinn eigin atburðastjórnun. Til að gera þetta þarftu til dæmis að skrifa Python forrit, smíða það í Docker og gerast áskrifandi að Kafka biðröðinni. Þegar kveikjur berast til hafnarstjóranna mun vinnsla hefjast. Með þessari aðferð þarftu að halda forritum í gangi alltaf.
Gerum ráð fyrir að við höfum valið einn af valkostunum sem lýst er hér að ofan og förum yfir í vinnsluna sjálfa. Örgjörvar ættu að byrja á því að athuga réttmæti gagnanna, sía sorp og „brotna“ atburði. Til staðfestingar notum við venjulega . Eftir þetta er hægt að gera kortlagningu gagna: gögn frá mismunandi aðilum eru staðlað og staðlað til að bætast við sameiginlega töflu.
3. Gagnagrunnur
Þriðja skrefið er að viðhalda eðlilegum atburðum. Þegar unnið er með tilbúið greiningarkerfi verðum við að hafa aðgang að þeim oft og því er mikilvægt að velja hentugan gagnagrunn.
Ef gögnin passa vel inn í fast kerfi geturðu valið eða einhvern annan dálkagagnagrunn. Þannig munu samsöfnunin virka mjög hratt. Gallinn er sá að kerfið er stíft fast og því verður ekki hægt að bæta við handahófskenndum hlutum án breytinga (til dæmis þegar óstöðluð atburður á sér stað). En þú getur talið mjög fljótt.
Fyrir ómótuð gögn geturðu tekið NoSQL, til dæmis, . Það keyrir á HDFS, endurtekur sig vel, þú getur hækkað mörg tilvik og er bilunarþolin.
Þú getur líka hækkað eitthvað einfaldara, td. . Það er frekar hægt og fyrir lítið magn. En plúsinn er að hann er mjög einfaldur og því hentugur til að byrja.
4. Söfnun
Eftir að hafa vistað alla atburði vandlega, viljum við safna öllum mikilvægum upplýsingum úr lotunni sem kom og uppfæra gagnagrunninn. Á heimsvísu viljum við fá viðeigandi mælaborð og mælikvarða. Safnaðu til dæmis notendasniði frá atburðum og mældu hegðun á einhvern hátt. Atburðum er safnað saman, safnað og vistað aftur (í notendatöflum). Á sama tíma geturðu byggt upp kerfi þannig að þú getur líka tengt síu við samhæfingaraðilann: safna notendum aðeins frá ákveðinni tegund atburðar.
Eftir það, ef einhver í teyminu þarf aðeins háþróaða greiningu, er hægt að tengja ytri greiningarkerfi. Þú getur tekið Mixpanel aftur. en þar sem það er frekar dýrt þá eru ekki allir notendaviðburðir sendir þangað heldur bara það sem þarf. Til að gera þetta þurfum við að búa til umsjónarmann sem mun flytja einhverja hráa atburði eða eitthvað sem við sjálf söfnuðum saman fyrr yfir á ytri kerfi, API eða auglýsingapalla.
5. Framhlið
Þú þarft að tengja framendann við búið kerfi. Gott dæmi er þjónusta , er GUI gagnagrunns sem hjálpar til við að byggja upp mælaborð. Hvernig samspilið virkar:
- Notandinn gerir SQL fyrirspurn.
- Sem svar fær hann skilti.
- Það býr til „nýja sjónmynd“ fyrir það og fær fallegt graf sem þú getur vistað fyrir sjálfan þig.
Sjónmyndir í þjónustunni eru sjálfvirkar uppfærslur, þú getur sérsniðið og fylgst með vöktun þinni. Redash er ókeypis ef það er hýst sjálft, en sem SaaS mun það kosta $50 á mánuði.
Ályktun
Eftir að hafa lokið öllum skrefunum hér að ofan muntu búa til greininguna þína á netþjóninum. Vinsamlegast athugaðu að þetta er ekki eins einfalt og bara að tengja saman greiningar viðskiptavina, því allt þarf að stilla sjálfur. Þess vegna, áður en þú býrð til þitt eigið kerfi, er það þess virði að bera saman þörfina fyrir alvarlegt greiningarkerfi við það fjármagn sem þú ert tilbúinn að úthluta til þess.
Ef þú hefur reiknað út og komist að því að kostnaðurinn er of hár, í næsta hluta mun ég tala um hvernig á að búa til ódýrari útgáfu af greiningum á netþjóni.
Takk fyrir að lesa! Ég mun með ánægju spyrja spurninga í athugasemdunum.
Heimild: www.habr.com