Við lifum á ótrúlegum tíma þegar þú getur fljótt og auðveldlega tengt nokkur tilbúin opinn hugbúnað, sett þau upp með „slökkt meðvitund“ samkvæmt ráðleggingum stackoverflow, án þess að kafa ofan í „marga stafina“ og ræsa þá í atvinnurekstur. Og þegar þú þarft að uppfæra/stækka eða einhver endurræsir óvart nokkrar vélar - þú áttar þig á því að einhvers konar þráhyggju slæmur draumur er hafinn, allt er orðið verulega flókið óþekkjanlega, það er ekki aftur snúið, framtíðin er óljós og öruggari, í stað þess að forrita, rækta býflugur og gera osta.
Það er ekki fyrir neitt sem reyndari samstarfsmenn, með höfuðið stráð pöddum og því þegar grátt, íhuga ótrúlega hraðvirka dreifingu pakka af „ílátum“ í „kubba“ á tugum netþjóna á „tískumálum“ með innbyggðum stuðningi fyrir ósamstilltur I/O, sem ekki hindrar, brostu hóflega. Og þeir halda þegjandi áfram að lesa „man ps“ aftur, kafa ofan í „nginx“ frumkóðann þar til það blæðir úr augum þeirra og skrifa, skrifa, skrifa einingapróf. Samstarfsmenn vita að það áhugaverðasta kemur þegar „allt þetta“ einn daginn verður teflt á nóttunni á gamlárskvöld. Og þeim verður aðeins hjálpað með djúpum skilningi á eðli unix, minnisinni TCP/IP ástandstöflu og grunnflokkunarleitaralgrímum. Til að koma kerfinu aftur til lífsins þegar bjöllurnar slá inn.
Ó já, ég varð svolítið annars hugar, en ég vona að mér hafi tekist að koma tilhlökkunarástandinu á framfæri.
Í dag vil ég deila reynslu okkar af því að nota þægilegan og ódýran stafla fyrir DataLake, sem leysir meirihluta greiningarverkefna í fyrirtækinu fyrir gjörólíkar skipulagsdeildir.
Fyrir nokkru síðan komumst við að því að fyrirtæki þurfa í auknum mæli ávexti bæði vöru- og tæknigreiningar (svo ekki sé minnst á rúsínan í pylsuendanum í formi vélanáms) og til að skilja þróun og áhættu - við þurfum að safna og greina fleiri og fleiri mæligildi.
Grunntæknigreining í Bitrix24
Fyrir nokkrum árum, samtímis kynningu á Bitrix24 þjónustunni, lögðum við virkan tíma og fjármagn í að búa til einfaldan og áreiðanlegan greiningarvettvang sem myndi hjálpa fljótt að sjá vandamál í innviðum og skipuleggja næsta skref. Auðvitað var ráðlegt að taka tilbúin verkfæri sem væru eins einföld og skiljanleg og hægt var. Fyrir vikið var nagios valið til eftirlits og munin til greiningar og sjónrænnar. Núna erum við með þúsundir ávísana í nagios, hundruð korta í munin, og samstarfsmenn okkar nota þau með góðum árangri á hverjum degi. Mælurnar eru skýrar, línuritin eru skýr, kerfið hefur virkað áreiðanlega í nokkur ár og ný próf og línurit bætast reglulega við það: þegar við tökum nýja þjónustu í notkun bætum við nokkrum prófum og línuritum. Gangi þér vel.
Finger on the Pulse - Ítarleg tæknigreining
Löngunin til að fá upplýsingar um vandamál "eins fljótt og auðið er" leiddi okkur til virkra tilrauna með einföldum og skiljanlegum verkfærum - pinba og xhprof.
Pinba sendi okkur tölfræði í UDP pökkum um hraða notkunar hluta vefsíðna í PHP og við gátum séð á netinu í MySQL geymslunni (Pinba kemur með sína eigin MySQL vél fyrir hraðvirka atburðagreiningu) stuttan lista yfir vandamál og brugðist við þeim. Og xhprof leyfði okkur sjálfkrafa að safna línuritum um framkvæmd hægustu PHP síðna frá viðskiptavinum og greina hvað gæti leitt til þessa - rólega, hella upp á te eða eitthvað sterkara.
Fyrir nokkru síðan var verkfærakistan endurnýjuð með annarri frekar einfaldri og skiljanlegri vél byggða á öfugri flokkunaralgrími, fullkomlega útfærð í hinu goðsagnakennda Lucene bókasafni - Elastic/Kibana. Hin einfalda hugmynd um fjölþráða skráningu á skjölum í andhverfa Lucene vísitölu byggða á atburðum í annálunum og fljótleg leit í gegnum þá með hliðarskiptingu reyndist vera mjög gagnleg.
Þrátt fyrir frekar tæknilegt útlit sjónmynda í Kibana með lágu stigi hugtaka eins og „fötu“ „flæðir upp“ og endurfundið tungumál hinnar ekki alveg gleymdu tengslalgebru, byrjaði tólið að hjálpa okkur vel í eftirfarandi verkefnum:
- Hversu margar PHP villur var Bitrix24 viðskiptavinurinn með á p1 gáttinni á síðustu klukkustund og hverjar? Skilja, fyrirgefa og leiðrétta fljótt.
- Hversu mörg myndsímtöl voru hringd á gáttum í Þýskalandi síðasta sólarhringinn, með hvaða gæðum og voru einhverjir erfiðleikar með rásina/netið?
- Hversu vel virkar kerfisvirkni (C viðbótin okkar fyrir PHP), sett saman úr uppruna í nýjustu þjónustuuppfærslunni og sett út til viðskiptavina? Eru það bilanir?
- Passa gögn viðskiptavina inn í PHP minni? Eru einhverjar villur um að fara yfir minni sem er úthlutað til ferla: „minni er ekki lengur til“? Finndu og hlutleystu.
Hér er áþreifanlegt dæmi. Þrátt fyrir ítarlegar og margþættar prófanir fékk viðskiptavinurinn, með mjög óhefðbundið hulstur og skemmd inntaksgögn, pirrandi og óvænta villu, sírena heyrðist og ferlið við að laga það fljótt hófst:
Að auki gerir kibana þér kleift að skipuleggja tilkynningar fyrir tiltekna viðburði og á stuttum tíma fór tólið í fyrirtækinu að vera notað af tugum starfsmanna frá mismunandi deildum - allt frá tækniaðstoð og þróun til QA.
Það er orðið þægilegt að rekja og mæla virkni hvaða deildar sem er innan fyrirtækisins - í stað þess að greina logs handvirkt á netþjónum þarftu bara að setja upp þáttunarlogga einu sinni og senda þá í teygjanlega klasann til að njóta, til dæmis, íhuga í kibana mælaborð fjölda seldra tvíhöfða kettlinga sem prentaðir voru á þrívíddarprentara fyrir síðasta tunglmánuð.
Basic Business Analytics
Það vita allir að viðskiptagreiningar í fyrirtækjum byrja oft á mjög virkri notkun á, já, Excel. En aðalatriðið er að það endar ekki þar. Skýbundið Google Analytics bætir líka olíu á eldinn - þú byrjar fljótt að venjast góðu hlutunum.
Í fyrirtækinu okkar sem er í samfelldri þróun, fóru að birtast hér og þar „spámenn“ í ákafari vinnu með stærri gögn. Þörfin fyrir ítarlegri og margþættari skýrslur fór að birtast reglulega og með viðleitni krakka frá mismunandi deildum var fyrir nokkru skipulögð einföld og hagnýt lausn - sambland af ClickHouse og PowerBI.
Í nokkuð langan tíma hjálpaði þessi sveigjanlega lausn mikið, en smám saman fór sá skilningur að koma að ClickHouse er ekki gúmmí og það er ekki hægt að hæðast að því.
Hér er mikilvægt að skilja vel að ClickHouse, eins og Druid, eins og Vertica, eins og Amazon RedShift (sem er byggt á postgres), eru greiningarvélar sem eru fínstilltar fyrir nokkuð þægilegar greiningar (upphæðir, samansafn, lágmark-hámark eftir dálkum og nokkrar mögulegar tengingar ), vegna þess skipulagt fyrir skilvirka geymslu á dálkum venslatöflur, ólíkt MySQL og öðrum (raðamiðuðum) gagnagrunnum sem við þekkjum.
Í meginatriðum er ClickHouse bara rýmri „gagnagrunnur“ með ekki mjög þægilegri innsetningu punkt fyrir punkt (þannig er það ætlað, allt er í lagi), en skemmtilega greiningu og safn áhugaverðra öflugra aðgerða til að vinna með gögn. Já, þú getur jafnvel búið til klasa - en þú skilur að það er ekki alveg rétt að hamra neglur með smásjá og við byrjuðum að leita að öðrum lausnum.
Eftirspurn eftir python og sérfræðingum
Fyrirtækið okkar hefur marga forritara sem skrifa kóða nánast á hverjum degi í 10-20 ár í PHP, JavaScript, C#, C/C++, Java, Go, Rust, Python, Bash. Það eru líka margir reyndir kerfisstjórar sem hafa lent í fleiri en einni alveg ótrúlegri hörmung sem passar ekki inn í lögmál tölfræði (til dæmis þegar meirihluti diska í raid-10 eyðileggst með sterkri eldingu). Við slíkar aðstæður var í langan tíma ekki ljóst hvað „python sérfræðingur“ væri. Python er eins og PHP, aðeins nafnið er aðeins lengra og aðeins minna ummerki um hugarbreytandi efni í frumkóða túlksins. Hins vegar, eftir því sem fleiri og fleiri greiningarskýrslur voru búnar til, fóru reyndir verktaki að skilja í auknum mæli mikilvægi þröngrar sérhæfingar í verkfærum eins og numpy, pandas, matplotlib, seaborn.
Afgerandi hlutverkið var að öllum líkindum gegnt með skyndilegum yfirliðum starfsmanna vegna samsetningar orðanna „logistic regression“ og sýna árangursríka skýrslugjöf um stór gögn með því að nota, já, já, pyspark.
Apache Spark, hagnýtur hugmyndafræði þess sem tengslalgebra passar fullkomlega við, og hæfileikar hennar settu svo mikinn svip á forritara sem vanir voru MySQL að þörfin á að styrkja röðina með reyndum greinendum varð ljós sem dagurinn.
Frekari tilraunir Apache Spark/Hadoop til að taka af skarið og það sem gekk ekki alveg samkvæmt handritinu
Hins vegar kom fljótlega í ljós að eitthvað var kerfisbundið ekki alveg í lagi með Spark, eða það var einfaldlega nauðsynlegt að þvo hendurnar betur. Ef Hadoop/MapReduce/Lucene staflan var gerður af nokkuð reyndum forriturum, sem er augljóst ef þú skoðar frumkóðann í Java eða hugmyndir Doug Cutting í Lucene, þá er Spark skyndilega skrifaður á framandi tungumálinu Scala, sem er mjög umdeilt frá sjónarhóli hagkvæmni og er ekki í þróun eins og er. Og reglulega lækkun á útreikningum á Spark klasanum vegna órökréttrar og ekki mjög gagnsærrar vinnu með minnisúthlutun fyrir minnkunaraðgerðir (margir lyklar koma í einu) hefur skapað geislabaug í kringum hann af einhverju sem hefur pláss til að vaxa. Að auki versnaði ástandið af miklum fjölda undarlegra opinna hafna, tímabundinna skráa sem stækkuðu á óskiljanlegustu stöðum og helvítis krukkufíkn - sem olli því að kerfisstjórar höfðu eina tilfinningu sem var vel þekkt frá barnæsku: brennandi hatri (eða kannski þeir þurftu að þvo sér um hendurnar með sápu).
Fyrir vikið höfum við „lifað af“ nokkur innri greiningarverkefni sem nota virkan Apache Spark (þar á meðal Spark Streaming, Spark SQL) og Hadoop vistkerfið (og svo framvegis og svo framvegis). Þrátt fyrir þá staðreynd að með tímanum lærðum við að undirbúa og fylgjast vel með „það“ og „það“ hætti nánast skyndilega að hrynja vegna breytinga á eðli gagnanna og ójafnvægis á samræmdu RDD hass, löngunin til að taka eitthvað sem þegar var tilbúið , uppfærð og gefin einhvers staðar í skýinu varð sterkari og sterkari. Það var á þessum tíma sem við reyndum að nota tilbúna skýjasamsetningu Amazon Web Services - og í kjölfarið reynt að leysa vandamál með því að nota það. EMR er Apache Spark útbúinn af Amazon með viðbótarhugbúnaði frá vistkerfinu, líkt og Cloudera/Hortonworks smíðar.
Gúmmískráargeymsla fyrir greiningar er brýn þörf
Reynslan af því að „elda“ Hadoop/Spark með brunasárum á ýmsum hlutum líkamans var ekki til einskis. Þörfin fyrir að búa til eina, ódýra og áreiðanlega skráageymslu sem væri ónæm fyrir vélbúnaðarbilunum og þar sem hægt væri að geyma skrár á mismunandi sniði úr mismunandi kerfum og gera skilvirk og tímahagkvæm sýnishorn fyrir skýrslur úr þessum gögnum varð sífellt meiri. skýr.
Ég vildi líka að uppfærsla á hugbúnaði þessa vettvangs breyttist ekki í martröð áramóta með því að lesa 20 blaðsíðna Java spor og greina kílómetra langa nákvæma annála af þyrpingunni með því að nota Spark History Server og baklýst stækkunargler. Ég vildi hafa einfalt og gagnsætt tól sem krefst ekki reglulegrar köfun undir hettunni ef staðlað MapReduce beiðni þróunaraðila hætti að keyra þegar minnkandi gagnastarfsmaðurinn féll úr minni vegna ekki mjög vel valinnar frumgagnaskiptingaralgríms.
Er Amazon S3 frambjóðandi fyrir DataLake?
Reynsla af Hadoop/MapReduce kenndi okkur að við þurfum skalanlegt, áreiðanlegt skráarkerfi og stigstærða starfsmenn ofan á það, sem „koma“ nær gögnunum til að keyra gögnin ekki yfir netið. Starfsmenn ættu að geta lesið gögn á mismunandi sniði, en helst ekki lesið óþarfa upplýsingar og geta geymt gögn fyrirfram á sniði sem henta starfsmönnum.
Enn og aftur, grunnhugmyndin. Það er engin löngun til að „hella“ stórum gögnum í eina greiningarvél fyrir klasa, sem mun fyrr eða síðar kæfa og þú verður að brjóta þau ljótt. Ég vil geyma skrár, bara skrár, á skiljanlegu sniði og framkvæma árangursríkar greiningarfyrirspurnir um þær með mismunandi en skiljanlegum verkfærum. Og það verða fleiri og fleiri skrár á mismunandi sniðum. Og það er betra að brjóta ekki vélina, heldur upprunagögnin. Við þurfum stækkanlegt og alhliða DataLake, við ákváðum...
Hvað ef þú geymir skrár í kunnuglegu og vel þekktu skalanlegu skýjageymslunni Amazon S3, án þess að þurfa að útbúa eigin kótelettur frá Hadoop?
Það er ljóst að persónuupplýsingarnar eru „lítil“, en hvað með önnur gögn ef við tökum þau út og „drifum þeim á áhrifaríkan hátt“?
Cluster-bigdata-analytics vistkerfi Amazon Web Services - í mjög einföldum orðum
Af reynslu okkar af AWS að dæma hefur Apache Hadoop/MapReduce verið virkt þar í langan tíma undir ýmsum sósum, til dæmis í DataPipeline þjónustunni (ég öfunda samstarfsmenn mína, þeir lærðu hvernig á að undirbúa hana rétt). Hér setjum við upp afrit frá mismunandi þjónustu frá DynamoDB töflum:
Og þeir hafa verið í gangi reglulega á innbyggðum Hadoop/MapReduce klösum eins og klukkuverk í nokkur ár núna. „Settu það og gleymdu því“:
Þú getur líka á áhrifaríkan hátt tekið þátt í gagnasatani með því að setja upp Jupiter fartölvur í skýinu fyrir greiningaraðila og nota AWS SageMaker þjónustuna til að þjálfa og dreifa gervigreindarlíkönum í bardaga. Svona lítur það út fyrir okkur:
Og já, þú getur tekið upp fartölvu fyrir sjálfan þig eða sérfræðing í skýinu og tengt hana við Hadoop/Spark þyrping, gert útreikningana og neglt síðan allt niður:
Virkilega þægilegt fyrir einstök greiningarverkefni og fyrir suma höfum við notað EMR þjónustuna með góðum árangri fyrir útreikninga og greiningar í stórum stíl. Hvað með kerfislausn fyrir DataLake, mun hún virka? Á þessari stundu vorum við á barmi vonar og örvæntingar og héldum leitinni áfram.
AWS lím - snyrtilega pakkað Apache Spark á sterum
Það kom í ljós að AWS er með sína eigin útgáfu af „Hive/Pig/Spark“ staflanum. Hlutverk Hive, þ.e. Skrá yfir skrár og gerðir þeirra í DataLake er framkvæmt af „Data catalogue“ þjónustunni, sem leynir ekki samhæfni sinni við Apache Hive sniðið. Þú þarft að bæta upplýsingum við þessa þjónustu um hvar skrárnar þínar eru staðsettar og á hvaða sniði þær eru. Gögnin geta ekki aðeins verið í s3, heldur einnig í gagnagrunninum, en það er ekki efni þessarar færslu. Svona er DataLake gagnaskráin okkar skipulögð:
Skrárnar eru skráðar, frábært. Ef skrárnar hafa verið uppfærðar ræsum við vefskriðara annað hvort handvirkt eða samkvæmt áætlun, sem mun uppfæra upplýsingar um þær úr vatninu og vista þær. Þá er hægt að vinna úr gögnunum úr vatninu og hlaða niðurstöðunum upp einhvers staðar. Í einfaldasta tilvikinu hlaðum við líka upp á s3. Gagnavinnsla er hægt að framkvæma hvar sem er, en lagt er til að þú stillir vinnsluna á Apache Spark klasa með því að nota háþróaða möguleika í gegnum AWS Glue API. Reyndar geturðu tekið gamla góða og kunnuglega python kóðann með því að nota pyspark bókasafnið og stillt framkvæmd hans á N hnútum þyrpings með einhverri getu með vöktun, án þess að grafa í innyflum Hadoop og draga docker-smoer gáma og útrýma ágreiningi um ósjálfstæði. .
Enn og aftur einföld hugmynd. Það er engin þörf á að stilla Apache Spark, þú þarft bara að skrifa python kóða fyrir pyspark, prófa hann á staðnum á skjáborðinu þínu og keyra hann síðan á stórum þyrping í skýinu, tilgreina hvar upprunagögnin eru og hvar á að setja niðurstöðuna. Stundum er þetta nauðsynlegt og gagnlegt og hér er hvernig við setjum það upp:
Þannig að ef þú þarft að reikna eitthvað út á Spark þyrping með því að nota gögn í s3, skrifum við kóða í python/pyspark, prófum hann og gangi þér vel í skýinu.
Hvað með hljómsveitina? Hvað ef verkefnið féll og hvarf? Já, það er lagt til að búa til fallega leiðslu í Apache Pig stílnum og við prófuðum þær meira að segja, en í bili ákváðum við að nota djúpt sérsniðna hljómsveitina okkar í PHP og JavaScript (mér skilst að það er vitsmunaleg mismunun, en það virkar, t.d. ár og án villna).
Snið skráa sem geymdar eru í vatninu er lykillinn að frammistöðu
Það er mjög, mjög mikilvægt að skilja tvö lykilatriði í viðbót. Til þess að fyrirspurnir um skráargögn í vatninu verði keyrðar eins fljótt og auðið er og árangur minnki ekki þegar nýjum upplýsingum er bætt við þarftu að:
- Geymdu dálka af skrám sérstaklega (svo að þú þurfir ekki að lesa allar línurnar til að skilja hvað er í dálkunum). Fyrir þetta tókum við parketsniðið með þjöppun
- Það er mjög mikilvægt að skipta skrám í möppur eins og: tungumál, ár, mánuður, dagur, vika. Vélar sem skilja þessa tegund af klippingu munu aðeins skoða nauðsynlegar möppur, án þess að sigta í gegnum öll gögnin í röð.
Í meginatriðum, á þennan hátt, setur þú upprunagögnin á skilvirkasta formi fyrir greiningarvélarnar sem hanga ofan á, sem jafnvel í sundurlausum möppum geta valið valið inn og lesið aðeins nauðsynlega dálka úr skrám. Þú þarft ekki að "fylla upp" gögnin hvar sem er (geymslan mun einfaldlega springa) - settu þau strax skynsamlega í skráarkerfið á réttu sniði. Auðvitað ætti það að vera ljóst hér að það er ekki mjög ráðlegt að geyma risastóra csv skrá í DataLake, sem þarf fyrst að lesa línu fyrir línu af þyrpingunni til að draga dálkana út. Hugsaðu aftur um ofangreind tvö atriði ef það er ekki enn ljóst hvers vegna allt þetta er að gerast.
AWS Athena - tjakkurinn í kassanum
Og svo, þegar við bjuggum til vatn, rákumst við einhvern veginn óvart á Amazon Aþenu. Allt í einu kom í ljós að með því að raða risastóru annálaskrám okkar vandlega í möppuslit á réttu (parket)dálkasniði, geturðu mjög fljótt valið ákaflega fróðlegt úr þeim og byggt skýrslur ÁN, án Apache Spark/Lím klasa.
Athena vélin sem knúin er áfram af gögnum í s3 er byggð á hinni goðsagnakenndu - fulltrúi MPP (massive parallel processing) fjölskyldu nálgun við gagnavinnslu, sem tekur gögn þar sem þau liggja, frá s3 og Hadoop til Cassandra og venjulegra textaskráa. Þú þarft bara að biðja Aþenu um að framkvæma SQL fyrirspurn og þá „virkar allt hratt og sjálfkrafa“. Það er mikilvægt að hafa í huga að Aþena er „snjöll“, hún fer aðeins í nauðsynlegar rifnar möppur og les aðeins dálkana sem þarf í beiðninni.
Verðlagning fyrir beiðnir til Aþenu er líka áhugaverð. Við borgum fyrir . Þeir. ekki fyrir fjölda véla í klasanum á mínútu, heldur... fyrir gögnin sem eru í raun skönnuð á 100-500 vélum, aðeins þau gögn sem nauðsynleg eru til að ljúka beiðninni.
Og með því að biðja aðeins um nauðsynlega dálka úr rétt rifnum möppum, kom í ljós að Athena þjónustan kostar okkur tugi dollara á mánuði. Jæja, frábært, næstum ókeypis, miðað við greiningar á klasa!
Við the vegur, hér er hvernig við skerum gögnin okkar í s3:
Þess vegna, á stuttum tíma, fóru gjörólíkar deildir í fyrirtækinu, allt frá upplýsingaöryggi til greiningar, að senda á virkan hátt til Aþenu og fljótt, á nokkrum sekúndum, fá gagnleg svör frá „stórum“ gögnum yfir nokkuð langan tíma: mánuði, hálft ár o.s.frv. P.
En við fórum lengra og fórum að fara í skýið eftir svörum : sérfræðingur skrifar SQL fyrirspurn í kunnuglega stjórnborði, sem á 100-500 vélum „fyrir smáaura“ sendir gögn til s3 og skilar svari venjulega á nokkrum sekúndum. Þægilegt. Og hratt. Ég trúi því varla enn.
Þar af leiðandi, eftir að hafa ákveðið að geyma gögn í s3, á skilvirku dálkaformi og með hæfilegri skiptingu gagna í möppur... fengum við DataLake og hraðvirka og ódýra greiningarvél - frítt. Og hann varð mjög vinsæll í fyrirtækinu, vegna þess að... skilur SQL og vinnur stærðargráður hraðar en með því að ræsa/stöðva/setja upp klasa. "Og ef niðurstaðan er sú sama, hvers vegna að borga meira?"
Beiðni til Aþenu lítur einhvern veginn svona út. Ef þess er óskað geturðu auðvitað myndað nóg , en við munum takmarka okkur við einfaldan flokkun. Við skulum sjá hvaða svarkóða viðskiptavinurinn hafði fyrir nokkrum vikum í vefþjónaskránum og ganga úr skugga um að engar villur séu:
Niðurstöður
Eftir að hafa farið í gegnum, ekki að segja langa, en sársaukafulla leið, stöðugt að meta áhættuna og hversu flókið og kostnaður við stuðning er, fundum við lausn fyrir DataLake og greiningar sem aldrei hættir að gleðja okkur bæði með hraða og eignarkostnaði.
Í ljós kom að það að byggja skilvirkt, fljótlegt og ódýrt í rekstri DataLake fyrir þarfir gjörólíkra deilda fyrirtækisins er algjörlega innan getu jafnvel reyndra hönnuða sem hafa aldrei starfað sem arkitektar og kunna ekki að teikna ferninga á ferninga með örvar og þekki 50 hugtök úr Hadoop vistkerfinu.
Í upphafi ferðar klofnaði hausinn á mér frá mörgum villtum dýragörðum opins og lokaðs hugbúnaðar og skilningi á ábyrgð afkomenda. Byrjaðu bara að byggja upp DataLake úr einföldum verkfærum: nagios/munin -> elastic/kibana -> Hadoop/Spark/s3..., safnaðu endurgjöf og skildu djúpan eðlisfræði ferlanna sem eiga sér stað. Allt flókið og gruggugt - gefðu það óvinum og keppinautum.
Ef þú vilt ekki fara í skýið og líkar við að styðja, uppfæra og lagfæra opinn hugbúnað, geturðu smíðað kerfi svipað og okkar á staðnum, á ódýrum skrifstofuvélum með Hadoop og Presto ofan á. Aðalatriðið er ekki að stoppa og halda áfram, telja, leita að einföldum og skýrum lausnum og allt mun örugglega ganga upp! Gangi ykkur öllum vel og sjáumst aftur!
Heimild: www.habr.com