Dyma ail ran cyfres o erthyglau am systemau dadansoddol ().
Heddiw nid oes unrhyw amheuaeth bellach y gall prosesu data gofalus a dehongli canlyniadau helpu bron unrhyw fath o fusnes. Yn hyn o beth, mae systemau dadansoddol yn cael eu llwytho fwyfwy â pharamedrau, ac mae nifer y sbardunau a digwyddiadau defnyddwyr mewn cymwysiadau yn tyfu.
Oherwydd hyn, mae cwmnïau'n rhoi mwy a mwy o wybodaeth amrwd i'w dadansoddwyr i'w dadansoddi a'u troi'n benderfyniadau cadarn. Ni ddylid diystyru pwysigrwydd system ddadansoddeg i gwmni, a rhaid i'r system ei hun fod yn ddibynadwy ac yn sefydlog.
Dadansoddwyr cleient
Mae dadansoddeg cwsmeriaid yn wasanaeth y mae cwmni'n ei gysylltu â'i wefan neu raglen trwy'r SDK swyddogol, yn integreiddio i'w sylfaen cod ei hun ac yn dewis sbardunau digwyddiadau. Mae yna anfantais amlwg i’r dull hwn: mae’n bosibl na fydd yr holl ddata a gesglir yn cael ei brosesu’n union fel y dymunwch oherwydd cyfyngiadau unrhyw wasanaeth a ddewiswch. Er enghraifft, ar un system ni fydd yn hawdd rhedeg tasgau MapReduce, ar un arall ni fyddwch yn gallu rhedeg eich model. Anfantais arall fydd y bil rheolaidd (trawiadol) am wasanaethau.
Mae yna lawer o atebion dadansoddi cwsmeriaid ar y farchnad, ond yn hwyr neu'n hwyrach mae dadansoddwyr yn wynebu'r ffaith nad oes un gwasanaeth cyffredinol sy'n addas ar gyfer pob tasg (tra bod prisiau'r holl wasanaethau hyn yn codi drwy'r amser). Mewn sefyllfa o'r fath, mae cwmnïau'n aml yn penderfynu creu eu system ddadansoddeg eu hunain gyda'r holl osodiadau a galluoedd arfer angenrheidiol.
Dadansoddwyr gweinydd
Mae dadansoddeg ochr gweinydd yn wasanaeth y gellir ei ddefnyddio o fewn cwmni ar ei weinyddion ei hun ac (fel arfer) gyda'i ymdrechion ei hun. Yn y model hwn, mae holl ddigwyddiadau defnyddwyr yn cael eu storio ar weinyddion mewnol, gan ganiatáu i ddatblygwyr roi cynnig ar wahanol gronfeydd data storio a dewis y bensaernïaeth fwyaf cyfleus. A hyd yn oed os ydych chi dal eisiau defnyddio dadansoddeg cleientiaid trydydd parti ar gyfer rhai tasgau, bydd yn dal yn bosibl.
Gellir defnyddio dadansoddeg ochr y gweinydd mewn dwy ffordd. Yn gyntaf: dewiswch rai cyfleustodau ffynhonnell agored, eu defnyddio ar eich peiriannau a datblygu rhesymeg busnes.
Manteision
Cons
Gallwch chi addasu unrhyw beth rydych chi ei eisiau
Mae hyn yn aml yn anodd iawn ac mae angen datblygwyr ar wahân
Yn ail: cymerwch wasanaethau SaaS (Amazon, Google, Azure) yn lle eu defnyddio eich hun. Byddwn yn siarad am SaaS yn fanylach yn y drydedd ran.
Manteision
Cons
Gall fod yn rhatach ar gyfeintiau canolig, ond gyda thwf mawr bydd yn dal yn mynd yn rhy ddrud
Ni fydd yn bosibl rheoli'r holl baramedrau
Trosglwyddir gweinyddiaeth yn gyfan gwbl i ysgwyddau'r darparwr gwasanaeth
Nid yw bob amser yn hysbys beth sydd y tu mewn i'r gwasanaeth (efallai na fydd ei angen)
Sut i gasglu dadansoddiadau gweinydd
Os ydym am symud i ffwrdd o ddefnyddio dadansoddeg cleientiaid ac adeiladu ein rhai ein hunain, yn gyntaf oll mae angen i ni feddwl trwy bensaernïaeth y system newydd. Isod byddaf yn dweud wrthych gam wrth gam beth sydd angen i chi ei ystyried, pam mae angen pob cam a pha offer y gallwch eu defnyddio.
1. Derbyn data
Yn union fel yn achos dadansoddeg cwsmeriaid, yn gyntaf oll, mae dadansoddwyr cwmni yn dewis y mathau o ddigwyddiadau y maent am eu hastudio yn y dyfodol ac yn eu casglu i restr. Yn nodweddiadol, mae'r digwyddiadau hyn yn digwydd mewn trefn benodol, a elwir yn "batrwm digwyddiad."
Nesaf, dychmygwch fod gan raglen symudol (gwefan) ddefnyddwyr rheolaidd (dyfeisiau) a llawer o weinyddion. Er mwyn trosglwyddo digwyddiadau yn ddiogel o ddyfeisiau i weinyddion, mae angen haen ganolraddol. Yn dibynnu ar y bensaernïaeth, efallai y bydd sawl ciw digwyddiad gwahanol.
- A yw , a ddefnyddir fel ciw ar gyfer casglu digwyddiadau.
Yn ôl yn 2014, penderfynodd crëwr Apache Kafka enwi’r feddalwedd ar ôl Franz Kafka oherwydd “mae’n system sydd wedi’i optimeiddio ar gyfer ysgrifennu” ac oherwydd ei fod yn caru gweithiau Kafka. -
Yn ein hesiampl, mae yna lawer o gynhyrchwyr data a defnyddwyr data (dyfeisiau a gweinyddwyr), ac mae Kafka yn helpu i'w cysylltu â'i gilydd. Bydd defnyddwyr yn cael eu disgrifio'n fanylach yn y camau canlynol, a nhw fydd y prif bynciau. Nawr byddwn yn ystyried cynhyrchwyr data (digwyddiadau) yn unig.
Mae Kafka yn crynhoi cysyniadau ciw a rhaniad; mae'n well darllen yn fwy penodol am hyn mewn man arall (er enghraifft, yn ). Heb fynd i fanylion, gadewch i ni ddychmygu bod cymhwysiad symudol yn cael ei lansio ar gyfer dau OS gwahanol. Yna mae pob fersiwn yn creu ei ffrwd digwyddiad ar wahân ei hun. Mae cynhyrchwyr yn anfon digwyddiadau i Kafka, maent yn cael eu recordio mewn ciw addas.
(llun )
Ar yr un pryd, mae Kafka yn caniatáu ichi ddarllen mewn talpiau a phrosesu llif o ddigwyddiadau mewn sypiau bach. Mae Kafka yn offeryn cyfleus iawn sy'n cyd-fynd yn dda ag anghenion cynyddol (er enghraifft, trwy geoleoliad digwyddiadau).
Fel arfer mae un darn yn ddigon, ond mae pethau'n mynd yn fwy cymhleth wrth raddio (fel y maent bob amser yn ei wneud). Mae'n debyg na fydd neb eisiau defnyddio dim ond un darn ffisegol wrth gynhyrchu, gan fod yn rhaid i'r bensaernïaeth allu goddef diffygion. Yn ogystal â Kafka, mae datrysiad adnabyddus arall - RabbitMQ. Ni wnaethom ei ddefnyddio wrth gynhyrchu fel ciw ar gyfer dadansoddeg digwyddiadau (os oes gennych brofiad o'r fath, dywedwch wrthym amdano yn y sylwadau!). Fodd bynnag, gwnaethom ddefnyddio AWS Kinesis.
Cyn symud ymlaen i'r cam nesaf, mae angen i ni sôn am un haen ychwanegol arall o'r system - storio boncyffion amrwd. Nid yw hon yn haen ofynnol, ond bydd yn ddefnyddiol os aiff rhywbeth o'i le a bod y ciwiau digwyddiad yn Kafka yn cael eu hailosod. Nid oes angen ateb cymhleth a drud i storio boncyffion amrwd; yn syml, gallwch eu hysgrifennu yn rhywle yn y drefn gywir (hyd yn oed ar yriant caled).
2. Prosesu ffrydiau digwyddiad
Ar ôl i ni baratoi'r holl ddigwyddiadau a'u gosod yn y ciwiau priodol, symudwn ymlaen i'r cam prosesu. Yma dywedaf wrthych am y ddau opsiwn prosesu mwyaf cyffredin.
Yr opsiwn cyntaf yw galluogi Spark Streaming yn system Apache. Mae holl gynhyrchion Apache yn byw ar HDFS, system ffeiliau ddiogel gyda chopïau o ffeiliau. Offeryn hawdd ei ddefnyddio yw Spark Streaming sy'n trin data ffrydio a graddfeydd yn dda. Fodd bynnag, gall fod yn anodd ei gynnal.
Opsiwn arall yw adeiladu eich trefnydd digwyddiad eich hun. I wneud hyn, mae angen i chi, er enghraifft, ysgrifennu cymhwysiad Python, ei adeiladu yn Docker a thanysgrifio i'r ciw Kafka. Pan fydd sbardunau'n cyrraedd y trinwyr docwyr, bydd prosesu'n dechrau. Gyda'r dull hwn, mae angen i chi gadw cymwysiadau i redeg bob amser.
Gadewch i ni dybio ein bod wedi dewis un o'r opsiynau a ddisgrifir uchod a symud ymlaen i'r prosesu ei hun. Dylai proseswyr ddechrau trwy wirio dilysrwydd y data, hidlo sbwriel a digwyddiadau “toredig”. Ar gyfer dilysu rydym fel arfer yn defnyddio . Ar ôl hyn, gallwch chi wneud mapio data: mae data o wahanol ffynonellau yn cael eu normaleiddio a'u safoni er mwyn cael eu hychwanegu at dabl cyffredin.
3. Cronfa Ddata
Y trydydd cam yw cynnal digwyddiadau normaleiddio. Wrth weithio gyda system ddadansoddol parod, bydd yn rhaid inni gael mynediad iddynt yn aml, felly mae'n bwysig dewis cronfa ddata gyfleus.
Os yw'r data'n cyd-fynd yn dda â chynllun sefydlog, gallwch ddewis neu ryw gronfa ddata golofnog arall. Fel hyn bydd y cydgasgluoedd yn gweithio'n gyflym iawn. Yr anfantais yw bod y cynllun wedi'i osod yn anhyblyg ac felly ni fydd yn bosibl ychwanegu gwrthrychau mympwyol heb eu haddasu (er enghraifft, pan fydd digwyddiad ansafonol yn digwydd). Ond gallwch chi gyfrif yn gyflym iawn.
Ar gyfer data distrwythur, gallwch gymryd NoSQL, er enghraifft, . Mae'n rhedeg ar HDFS, yn atgynhyrchu'n dda, gallwch godi llawer o achosion, ac mae'n gallu goddef diffygion.
Gallwch hefyd godi rhywbeth symlach, er enghraifft, . Mae'n eithaf araf ac ar gyfer cyfeintiau bach. Ond y fantais yw ei fod yn syml iawn ac felly'n addas ar gyfer cychwyn.
4. Agregau
Ar ôl cadw'r holl ddigwyddiadau yn ofalus, rydym am gasglu'r holl wybodaeth bwysig o'r swp a gyrhaeddodd a diweddaru'r gronfa ddata. Yn fyd-eang, rydym am gael dangosfyrddau a metrigau perthnasol. Er enghraifft, casglwch broffil defnyddiwr o ddigwyddiadau a mesurwch ymddygiad rywsut. Caiff digwyddiadau eu hagregu, eu casglu a'u cadw eto (mewn tablau defnyddwyr). Ar yr un pryd, gallwch chi adeiladu system fel y gallwch chi hefyd gysylltu hidlydd â'r cydlynydd agregydd: casglwch ddefnyddwyr o fath penodol o ddigwyddiad yn unig.
Ar ôl hynny, os mai dim ond dadansoddeg lefel uchel sydd ei hangen ar rywun ar y tîm, gellir cysylltu systemau dadansoddeg allanol. Gallwch chi gymryd Mixpanel eto. ond gan ei fod yn eithaf drud, nid yw pob digwyddiad defnyddiwr yn cael ei anfon yno, ond dim ond yr hyn sydd ei angen. I wneud hyn, mae angen i ni greu cydlynydd a fydd yn trosglwyddo rhai digwyddiadau amrwd neu rywbeth yr ydym ni ein hunain wedi'i gyfuno'n gynharach i systemau allanol, APIs neu lwyfannau hysbysebu.
5. blaen
Mae angen i chi gysylltu'r blaen i'r system a grëwyd. Enghraifft dda yw gwasanaeth , yn GUI cronfa ddata sy'n helpu i adeiladu dangosfyrddau. Sut mae'r rhyngweithio'n gweithio:
- Mae'r defnyddiwr yn gwneud ymholiad SQL.
- Mewn ymateb mae'n derbyn arwydd.
- Mae'n creu 'delweddu newydd' ar ei gyfer ac yn cael graff hardd y gallwch chi ei arbed i chi'ch hun.
Mae delweddiadau yn y gwasanaeth yn cael eu diweddaru'n awtomatig, gallwch chi addasu ac olrhain eich monitro. Mae Redash am ddim os yw'n hunangynhaliol, ond fel SaaS bydd yn costio $50 y mis.
Casgliad
Ar ôl cwblhau'r holl gamau uchod, byddwch yn creu dadansoddiadau eich gweinydd. Sylwch nad yw hyn mor syml â chysylltu dadansoddeg cwsmeriaid yn unig, oherwydd mae angen i bopeth gael ei ffurfweddu eich hun. Felly, cyn creu eich system eich hun, mae'n werth cymharu'r angen am system ddadansoddeg ddifrifol â'r adnoddau yr ydych yn fodlon eu dyrannu iddi.
Os ydych chi wedi gwneud y mathemateg ac wedi canfod bod y costau'n rhy uchel, yn y rhan nesaf byddaf yn siarad am sut i wneud fersiwn rhatach o ddadansoddeg ochr y gweinydd.
Diolch am ddarllen! Byddaf yn falch o ofyn cwestiynau yn y sylwadau.
Ffynhonnell: hab.com
