Elämme hämmästyttävää aikaa, jolloin voit nopeasti ja helposti yhdistää useita valmiita avoimen lähdekoodin työkaluja, asettaa ne "tietoisuutesi pois päältä" stackoverflow-ohjeiden mukaan "useita kirjaimia" syventymättä ja käynnistää ne kaupalliseen käyttöön. Ja kun sinun on päivitettävä/laajennettava tai joku käynnistää vahingossa uudelleen pari konetta - huomaat, että jonkinlainen pakkomielteinen paha unelma on alkanut, kaikesta on tullut dramaattisesti monimutkaista tunnistamatta, paluuta ei ole, tulevaisuus on epämääräinen ja turvallisempi, ohjelmoinnin sijasta kasvattaa mehiläisiä ja tee juustoa.
Ei ole turhaa, että kokeneemmat kollegat, joiden päät ovat vikoja täynnä ja siksi jo harmaita, harkitsevat "kuutioiden" "konttipakkausten" uskomattoman nopeaa käyttöönottoa kymmenillä palvelimilla "muodikkailla kielillä", joissa on sisäänrakennettu tuki asynkroninen ei-esto I/O, hymyile vaatimattomasti . Ja he jatkavat äänettömästi "man ps" -koodin uudelleen lukemista, "nginx"-lähdekoodia, kunnes heidän silmänsä vuotaa verta, ja kirjoittavat, kirjoittavat, kirjoittavat yksikkötestejä. Kollegat tietävät, että mielenkiintoisin asia tulee, kun "kaikki tämä" jonain päivänä panoksiin tulee yöllä uudenvuodenaattona. Ja niitä auttaa vain syvä ymmärrys unixin luonteesta, muistiin tallennetusta TCP/IP-tilataulukosta ja peruslajittelu-hakualgoritmeista. Järjestelmän herättämiseksi eloon kellojen iskeessä.
Ai niin, olin hieman hajamielinen, mutta toivon, että onnistuin välittämään odotuksen tilan.
Tänään haluan jakaa kokemuksemme kätevän ja edullisen DataLake-pinon käyttöönotosta, joka ratkaisee suurimman osan yrityksen analyyttisista tehtävistä täysin erilaisille rakennejaostoille.
Jokin aika sitten tulimme ymmärrykseen, että yritykset tarvitsevat yhä enemmän sekä tuote- että teknisen analytiikan hedelmiä (puhumattakaan koneoppimisen kirsikka kakun päällä) ja trendien ja riskien ymmärtämiseksi - meidän on kerättävä ja analysoitava yhä enemmän mittareita.
Tekninen perusanalytiikka Bitrix24:ssä
Useita vuosia sitten, samanaikaisesti Bitrix24-palvelun lanseerauksen kanssa, panostimme aktiivisesti aikaa ja resursseja luodaksemme yksinkertaisen ja luotettavan analyyttisen alustan, joka auttaisi nopeasti näkemään infrastruktuurin ongelmat ja suunnittelemaan seuraavan askeleen. Tietysti oli suositeltavaa ottaa valmiita työkaluja, jotka olivat mahdollisimman yksinkertaisia ja ymmärrettäviä. Tämän seurauksena nagios valittiin seurantaan ja munin analytiikkaan ja visualisointiin. Nyt meillä on tuhansia shekkejä nagiosissa, satoja kaavioita muninissa, ja kollegamme käyttävät niitä menestyksekkäästi joka päivä. Mittarit ovat selkeitä, kaaviot selkeät, järjestelmä on toiminut luotettavasti useiden vuosien ajan ja siihen lisätään säännöllisesti uusia testejä ja kaavioita: kun otamme uuden palvelun käyttöön, lisäämme useita testejä ja kaavioita. Onnea.
Finger on the Pulse – edistynyt tekninen analyysi
Halu saada tietoa ongelmista "mahdollisimman nopeasti" johti meidät aktiivisiin kokeiluihin yksinkertaisilla ja ymmärrettävillä työkaluilla - pinba ja xhprof.
Pinba lähetti meille UDP-paketteina tilastoja web-sivujen osien toimintanopeuksista PHP:llä, ja näimme verkossa MySQL-tallennustilassa (Pinbassa on oma MySQL-moottori nopeaan tapahtumaanalysointiin) lyhyen luettelon ongelmista ja reagoida niihin. niitä. Ja xhprof antoi meille automaattisesti mahdollisuuden kerätä kaavioita asiakkailta hitaimpien PHP-sivujen suorituksesta ja analysoida, mikä voisi johtaa tähän - rauhallisesti, kaatamalla teetä tai jotain vahvempaa.
Jokin aika sitten työkalupakkia täydennettiin toisella melko yksinkertaisella ja ymmärrettävällä käänteiseen indeksointialgoritmiin perustuvalla moottorilla, joka on täydellisesti toteutettu legendaarisessa Lucenen kirjastossa - Elastic/Kibana. Yksinkertainen idea monisäikeisestä dokumenttien tallentamisesta käänteiseen Lucene-indeksiin perustuen lokien tapahtumiin ja nopea haku niiden läpi fasettijaolla osoittautui todella hyödylliseksi.
Huolimatta Kibanan visualisointien melko teknisestä ulkonäöstä matalan tason käsitteillä, kuten "ämpäri" "virtaa ylöspäin", ja vielä täysin unohdetun relaatioalgebran uudelleen keksitystä kielestä, työkalu alkoi auttaa meitä hyvin seuraavissa tehtävissä:
- Kuinka monta PHP-virhettä Bitrix24-asiakkaalla oli p1-portaalissa viimeisen tunnin aikana ja mitkä? Ymmärrä, anna anteeksi ja korjaa nopeasti.
- Kuinka monta videopuhelua soitettiin portaaleihin Saksassa viimeisen 24 tunnin aikana, millä laadulla ja oliko kanavan/verkon kanssa ongelmia?
- Kuinka hyvin uusimmassa palvelupäivityksessä lähteestä koottu ja asiakkaille levitetty järjestelmätoiminto (C-laajennus PHP:lle) toimii? Onko vikaa?
- Mahtuuko asiakasdata PHP-muistiin? Onko prosesseille varatun muistin ylittyessä virheitä: "muisti loppu"? Etsi ja neutraloi.
Tässä konkreettinen esimerkki. Huolimatta perusteellisesta ja monitasoisesta testauksesta, asiakas, jolla oli erittäin epästandardi kotelo ja vaurioituneet syöttötiedot, sai ärsyttävän ja odottamattoman virheen, sireeni soi ja sen nopea korjausprosessi alkoi:
Lisäksi kibanan avulla voit järjestää ilmoituksia tietyistä tapahtumista, ja lyhyessä ajassa yrityksen työkalu alkoi olla kymmenien eri osastojen työntekijöiden käytössä - teknisestä tuesta ja kehityksestä laadunvarmistukseen.
Yrityksen minkä tahansa osaston toiminnasta on tullut kätevää seurata ja mitata - sen sijaan, että analysoisit lokeja manuaalisesti palvelimilla, sinun tarvitsee vain määrittää jäsennyslokit kerran ja lähettää ne elastiseen klusteriin nauttiaksesi esimerkiksi kibanassa mietiskelystä. dashboard myytyjen kaksipäisten kissanpentujen määrä 3D-tulostimella tulostettuna viimeisen kuun aikana.
Liiketoiminnan perusanalyysi
Kaikki tietävät, että yritysten liiketoimintaanalytiikka alkaa usein erittäin aktiivisesta, kyllä, Excelin käytöstä. Mutta pääasia on, ettei se lopu tähän. Pilvipohjainen Google Analytics lisää myös öljyä tuleen – alat nopeasti tottua hyviin asioihin.
Sopusointuisesti kehittyvässä yrityksessämme alkoi ilmaantua siellä täällä "profeettoja" intensiivisemmästä työstä suuremman datan kanssa. Tarve perusteellisempiin ja monipuolisempiin raportteihin alkoi ilmaantua säännöllisesti, ja eri osastojen ystävien ponnisteluilla järjestettiin jokin aika sitten yksinkertainen ja käytännöllinen ratkaisu - ClickHousen ja PowerBI:n yhdistelmä.
Pitkään tämä joustava ratkaisu auttoi paljon, mutta vähitellen alkoi tulla ymmärrys, että ClickHouse ei ole kumia eikä sitä voi pilata niin.
Tässä on tärkeää ymmärtää hyvin, että ClickHouse, kuten Druid, kuten Vertica, kuten Amazon RedShift (joka perustuu postgresiin), ovat analyyttisiä moottoreita, jotka on optimoitu melko kätevään analytiikkaan (summat, aggregaatiot, minimi-maksimi sarakkeittain ja muutama mahdollinen liitos). ), koska järjestetty relaatiotaulukoiden sarakkeiden tehokkaaseen tallentamiseen, toisin kuin MySQL ja muut tuntemamme (rivisuuntaiset) tietokannat.
Pohjimmiltaan ClickHouse on vain tilavampi "tietokanta", jossa ei ole kovin kätevää pistekohtaista lisäystä (näin se on tarkoitettu, kaikki on ok), mutta miellyttävä analytiikka ja joukko mielenkiintoisia tehokkaita toimintoja tietojen kanssa työskentelemiseen. Kyllä, voit jopa luoda klusterin - mutta ymmärrät, että naulojen lyöminen mikroskoopilla ei ole täysin oikein, ja aloimme etsiä muita ratkaisuja.
Pythonin ja analyytikoiden kysyntä
Yrityksellämme on monia kehittäjiä, jotka kirjoittavat koodia lähes päivittäin 10-20 vuoden ajan PHP:llä, JavaScriptillä, C#:lla, C/C++:lla, Javalla, Golla, Rustilla, Pythonilla, Bashilla. On myös monia kokeneita järjestelmänvalvojia, jotka ovat kokeneet useamman kuin yhden täysin uskomattoman katastrofin, joka ei sovi tilastojen lakiin (esimerkiksi kun suurin osa raid-10:n levyistä tuhoutuu voimakkaalla salamaniskulla). Tällaisissa olosuhteissa ei pitkään aikaan ollut selvää, mikä "python-analyytikko" oli. Python on kuin PHP, vain nimi on hieman pidempi ja tulkin lähdekoodissa on hieman vähemmän jälkiä mieltä muuttavista aineista. Kuitenkin, kun yhä enemmän luotiin analyyttisiä raportteja, kokeneet kehittäjät alkoivat yhä paremmin ymmärtää suppean erikoistumisen tärkeyttä työkaluihin, kuten numpy, pandas, matplotlib, seaborn.
Ratkaiseva rooli oli todennäköisesti työntekijöiden äkillinen pyörtyminen sanojen "logistinen regressio" yhdistelmästä ja tehokkaan raportoinnin osoittaminen suurista tiedoista käyttämällä kyllä, kyllä, pysparkia.
Apache Spark, sen toiminnallinen paradigma, johon relaatioalgebra sopii täydellisesti, ja sen ominaisuudet tekivät MySQL:ään tottuneisiin kehittäjiin niin suuren vaikutuksen, että tarve vahvistaa rivejä kokeneiden analyytikoiden avulla tuli selväksi kuin päivä.
Apache Spark/Hadoopin lisäyritykset nousuun ja mikä ei mennyt aivan käsikirjoituksen mukaan
Pian kuitenkin kävi selväksi, että Sparkissa oli systeemisesti jotain pielessä tai kädet oli yksinkertaisesti pestävä paremmin. Jos Hadoop/MapReduce/Lucene-pinon tekivät melko kokeneet ohjelmoijat, mikä on ilmeistä, jos tarkastellaan tarkasti Java-lähdekoodia tai Doug Cuttingin ajatuksia Lucenessa, niin Spark on yhtäkkiä kirjoitettu eksoottisella kielellä Scala, joka on erittäin kiistanalainen käytännöllisyyden kannalta, eikä sitä tällä hetkellä kehitetä. Ja Spark-klusterin laskelmien säännöllinen pudotus, joka johtuu epäloogisesta ja ei kovin läpinäkyvästä työstä muistin allokoinnissa vähennystoimintoihin (monia avaimia saapuu kerralla) on luonut sen ympärille kehäkehän jostakin, jolla on tilaa kasvaa. Lisäksi tilannetta pahensi suuri määrä outoja avoimia portteja, käsittämättömimpiin paikkoihin kasvavat väliaikaiset tiedostot ja helvetin jar-riippuvuudet - mikä sai järjestelmänvalvojilta yhden lapsuudesta tutun tunteen: kova viha (tai ehkä heidän piti pestä kätensä saippualla).
Tämän seurauksena olemme selviytyneet useista sisäisistä analyyttisista projekteista, jotka käyttävät aktiivisesti Apache Sparkia (mukaan lukien Spark Streaming, Spark SQL) ja Hadoop-ekosysteemiä (ja niin edelleen ja niin edelleen). Huolimatta siitä, että ajan myötä opimme valmistautumaan ja valvomaan "se" melko hyvin, ja "se" käytännössä lakkasi yhtäkkiä kaatumasta datan luonteen muutosten ja yhtenäisen RDD-hajautusjärjestelmän epätasapainon vuoksi, halu ottaa jotain jo valmiiksi , päivitetty ja hallinnoitu jossain pilvessä vahvistui ja vahvistui. Juuri tähän aikaan yritimme käyttää Amazon Web Servicesin valmista pilvikokoonpanoa - ja myöhemmin yrittänyt ratkaista ongelmia sen avulla. EMR on Apache Spark, jonka Amazon on valmistellut ekosysteemin lisäohjelmistoilla, aivan kuten Cloudera/Hortonworks rakentaa.
Kumitiedostojen tallennus analytiikkaa varten on kiireellinen tarve
Kokemus Hadoop/Sparkin "keittämisestä" eri kehon osien palovammoilla ei ollut turha. Tarve luoda yksi, edullinen ja luotettava tiedostovarasto, joka kestäisi laitteistovikoja ja johon olisi mahdollista tallentaa eri muodoissa olevia tiedostoja eri järjestelmistä ja tehdä näistä tiedoista tehokkaita ja aikaa säästäviä näytteitä raportteihin asia selvä.
Halusin myös, että tämän alustan ohjelmistojen päivittäminen ei muuttuisi uudenvuoden painajaiseksi 20-sivuisten Java-jälkien lukemisen ja kilometrien mittaisten yksityiskohtaisten klusterin lokien analysoinnin avulla Spark History Serverin ja taustavalaistun suurennuslasin avulla. Halusin yksinkertaisen ja läpinäkyvän työkalun, joka ei edellytä säännöllistä sukeltamista konepellin alle, jos kehittäjän vakio MapReduce-pyyntö lakkasi suorittamasta, kun datatyöntekijä putosi muistista huonosti valitun lähdedatan osiointialgoritmin takia.
Onko Amazon S3 ehdokas DataLakeen?
Kokemus Hadoop/MapReduce-sovelluksesta opetti meille, että tarvitsemme skaalautuvan, luotettavan tiedostojärjestelmän ja sen päälle skaalautuvia työntekijöitä, jotka "tulevat" lähemmäksi tietoja, jotta ne eivät kulje verkon yli. Työntekijöiden tulee pystyä lukemaan tietoja eri muodoissa, mutta mielellään välttämään tarpeettomia tietoja ja pystyttävä tallentamaan tiedot etukäteen työntekijöille sopivissa muodoissa.
Jälleen kerran perusidea. Big dataa ei haluta "kaataa" yhteen klusterianalyyttiseen moottoriin, joka ennemmin tai myöhemmin tukehtuu ja joudut sirpaltelemaan sen rumaksi. Haluan tallentaa tiedostoja, pelkkiä tiedostoja, ymmärrettävässä muodossa ja tehdä niille tehokkaita analyyttisiä kyselyitä erilaisilla mutta ymmärrettävillä työkaluilla. Ja tiedostoja tulee olemaan yhä enemmän eri muodoissa. Ja on parempi sirpata ei moottoria, vaan lähdetietoja. Tarvitsemme laajennettavan ja universaalin DataLaken, päätimme...
Entä jos tallennat tiedostoja tuttuun ja tunnettuun skaalautuvaan Amazon S3:n pilvitallennustilaan ilman, että sinun tarvitsee valmistaa omia palojasi Hadoopista?
On selvää, että henkilötietoja on "vähän", mutta entä muut tiedot, jos otamme ne pois ja "ohjaamme niitä tehokkaasti"?
Amazon Web Servicesin klusteri-bigdata-analytiikkaekosysteemi - hyvin yksinkertaisin sanoin
AWS-kokemuksemme perusteella Apache Hadoop/MapReduce on ollut siellä aktiivisesti käytössä pitkään eri kastikkeiden alla, esimerkiksi DataPipeline-palvelussa (kadehdin kollegoilleni, he oppivat valmistamaan sen oikein). Täällä asetamme varmuuskopiot eri palveluista DynamoDB-taulukoista:
Ja ne ovat toimineet säännöllisesti sulautetuissa Hadoop/MapReduce-klustereissa, kuten kellokoneistossa, useiden vuosien ajan. "Aseta se ja unohda se":
Voit myös harjoittaa tehokkaasti datasatanismia asettamalla Jupiter-kannettavia analyytikoille pilveen ja käyttämällä AWS SageMaker -palvelua AI-mallien harjoittamiseen ja käyttöönottamiseksi taisteluun. Tältä se näyttää meille:
Ja kyllä, voit poimia kannettavan tietokoneen itsellesi tai analyytikolle pilvestä ja liittää sen Hadoop/Spark-klusteriin, tehdä laskelmat ja sitten naulata kaiken:
Todella kätevä yksittäisiin analyyttisiin projekteihin ja joidenkin kohdalla olemme menestyksekkäästi käyttäneet EMR-palvelua laajamittaisiin laskelmiin ja analytiikkaan. Entä DataLaken järjestelmäratkaisu, toimiiko se? Tällä hetkellä olimme toivon ja epätoivon partaalla ja jatkoimme etsintää.
AWS Glue - siististi pakattu Apache Spark steroideihin
Kävi ilmi, että AWS:llä on oma versio "Hive/Pig/Spark" -pinosta. Hiven rooli, ts. DataLakessa olevien tiedostojen ja niiden tyyppien luettelon suorittaa "Data catalog" -palvelu, joka ei piilota yhteensopivuuttaan Apache Hive -muodon kanssa. Sinun on lisättävä tähän palveluun tietoja siitä, missä tiedostosi sijaitsevat ja missä muodossa ne ovat. Tiedot voivat olla paitsi s3:ssa myös tietokannassa, mutta se ei ole tämän viestin aihe. DataLake-tietohakemistomme on järjestetty seuraavasti:
Tiedostot on rekisteröity, hienoa. Jos tiedostot on päivitetty, käynnistämme joko manuaalisesti tai aikataulun mukaan indeksointirobotit, jotka päivittävät niistä tiedot järvestä ja tallentavat ne. Sitten järven tiedot voidaan käsitellä ja tulokset ladata jonnekin. Yksinkertaisimmassa tapauksessa lataamme myös s3:een. Tietojen käsittely voidaan suorittaa missä tahansa, mutta on suositeltavaa, että määrität käsittelyn Apache Spark -klusterissa käyttämällä edistyneitä ominaisuuksia AWS Glue API:n kautta. Itse asiassa voit ottaa vanhan hyvän ja tutun python-koodin käyttämällä pyspark-kirjastoa ja määrittää sen suorittamisen N:ssä jonkin kapasiteetin klusterin solmussa valvonnan avulla ilman, että sinun tarvitsee kaivaa Hadoopin sisimpään ja vetää docker-moker-säiliöitä ja eliminoi riippuvuusristiriitoja. .
Jälleen kerran yksinkertainen idea. Apache Sparkia ei tarvitse määrittää, sinun on vain kirjoitettava pysparkille python-koodi, testattava se paikallisesti työpöydälläsi ja suoritettava se sitten suuressa klusterissa pilvessä, määrittäen missä lähdetiedot ovat ja mihin tulos sijoitetaan. Joskus tämä on tarpeellista ja hyödyllistä, ja asennamme sen seuraavasti:
Jos sinun on siis laskettava jotain Spark-klusterissa s3:n datan avulla, kirjoitamme koodin python/pysparkiin, testaamme sitä ja onnea pilvelle.
Entä orkestraatio? Entä jos tehtävä putoaa ja katoaa? Kyllä, ehdotetaan tehdä kaunis putki Apache Pig -tyyliin ja me jopa kokeilimme niitä, mutta toistaiseksi päätimme käyttää syvästi räätälöityä orkestrointiamme PHP:ssä ja JavaScriptissä (ymmärrän, kognitiivista dissonanssia on, mutta se toimii, vuotta ja ilman virheitä).
Järveen tallennettujen tiedostojen muoto on avain suorituskykyyn
On erittäin, erittäin tärkeää ymmärtää kaksi muuta avainkohtaa. Jotta järven tiedostotietojen kyselyt suoritettaisiin mahdollisimman nopeasti ja suorituskyky ei heikkene, kun uusia tietoja lisätään, sinun on:
- Tallenna tiedostosarakkeet erikseen (jotta sinun ei tarvitse lukea kaikkia rivejä ymmärtääksesi sarakkeiden sisältöä). Tätä varten otimme parkettimuodon puristamalla
- On erittäin tärkeää jakaa tiedostot kansioihin, kuten: kieli, vuosi, kuukausi, päivä, viikko. Moottorit, jotka ymmärtävät tämän tyyppisen jakamisen, tarkastelevat vain tarvittavia kansioita ilman, että ne seulovat kaikkia tietoja peräkkäin.
Pohjimmiltaan tällä tavalla asetat lähdetiedot tehokkaimmassa muodossa päälle ripustetuille analyyttisille koneille, jotka jopa sirpaloituihin kansioihin voivat valikoivasti syöttää ja lukea tiedostoista vain tarvittavat sarakkeet. Sinun ei tarvitse "täyttää" tietoja mihinkään (tallennustila yksinkertaisesti räjähtää) - laita ne heti viisaasti tiedostojärjestelmään oikeassa muodossa. Tietenkin tässä pitäisi olla selvää, että valtavan csv-tiedoston tallentaminen DataLakeen, joka klusterin on ensin luettava rivi riviltä, jotta sarakkeet voidaan purkaa, ei ole kovin suositeltavaa. Mieti näitä kahta seikkaa uudelleen, jos et ole vielä selvää, miksi kaikki tämä tapahtuu.
AWS Athena - jack-in-the-box
Ja sitten kun luomme järveä, törmäsimme jotenkin vahingossa Amazon Athenaan. Yhtäkkiä kävi ilmi, että järjestämällä valtavat lokitiedostomme huolellisesti kansion sirpaleiksi oikeassa (parketti) sarakemuodossa, voit nopeasti tehdä niistä erittäin informatiivisia valintoja ja rakentaa raportteja ILMAN, ilman Apache Spark/Glue -klusteria.
S3:n datalla toimiva Athena-moottori perustuu legendaariseen - MPP (massive parallel processing) -lähestymistapojen edustaja tietojenkäsittelyyn, joka ottaa tiedot sieltä missä ne ovat, s3:sta ja Hadoopista Cassandraan ja tavallisiin tekstitiedostoihin. Sinun tarvitsee vain pyytää Athenaa suorittamaan SQL-kysely, ja sitten kaikki "toimii nopeasti ja automaattisesti". On tärkeää huomata, että Athena on "älykäs", se menee vain tarvittaviin sirpaloituihin kansioihin ja lukee vain pyynnössä tarvittavat sarakkeet.
Myös Athena-pyyntöjen hinnoittelu on mielenkiintoinen. Me maksamme . Nuo. ei klusterin koneiden määrälle minuutissa, vaan... 100-500 koneella todella skannatulle tiedolle, vain pyynnön suorittamiseen tarvittavat tiedot.
Ja pyytämällä vain tarvittavat sarakkeet oikein sirpaloiduista kansioista, kävi ilmi, että Athena-palvelu maksaa meille kymmeniä dollareita kuukaudessa. Hienoa, melkein ilmainen verrattuna klusterien analytiikkaan!
Muuten, näin sirpaloimme tietomme s3:ssa:
Tämän seurauksena yrityksen täysin erilaiset osastot tietoturvasta analytiikkaan alkoivat lyhyessä ajassa tehdä aktiivisesti pyyntöjä Athenalle ja saada nopeasti, sekunneissa hyödyllisiä vastauksia "isoista" tiedoista melko pitkien ajanjaksojen aikana: kuukausia, puoli vuotta jne. P.
Mutta menimme pidemmälle ja aloimme mennä pilveen etsimään vastauksia : analyytikko kirjoittaa tutussa konsolissa SQL-kyselyn, joka 100-500 koneella "penneillä" lähettää dataa s3:lle ja palauttaa vastauksen yleensä muutamassa sekunnissa. Mukava. Ja nopeasti. En voi vieläkään uskoa sitä.
Lopputuloksena, kun olemme päättäneet tallentaa tiedot s3:ssa, tehokkaassa sarakemuodossa ja järkevällä datan kansioihin jakamalla... saimme DataLaken ja nopean ja halvan analyyttisen moottorin - ilmaiseksi. Ja hänestä tuli erittäin suosittu yrityksessä, koska... ymmärtää SQL:n ja toimii suuruusluokkaa nopeammin kuin käynnistämällä/pysäyttämällä/asettamalla klustereita. "Ja jos tulos on sama, miksi maksaa enemmän?"
Pyyntö Athenalle näyttää suunnilleen tältä. Halutessasi voit tietysti muotoilla tarpeeksi , mutta rajoitamme yksinkertaiseen ryhmittelyyn. Katsotaan, mitä vastauskoodeja asiakkaalla oli muutama viikko sitten verkkopalvelimen lokeissa, ja varmistetaan, ettei virheitä ole:
Tulokset
Kävimme läpi, ei sanoa, että pitkän, mutta tuskallisen polun, arvioimme jatkuvasti asianmukaisesti riskejä ja tuen monimutkaisuuden tasoa ja kustannuksia, löysimme DataLakeen ja analytiikkaan ratkaisun, joka ei aina lakkaa ilahduttamasta meitä sekä nopeudella että omistuskustannuksilla.
Kävi ilmi, että tehokkaan, nopean ja halvan toimivan DataLaken rakentaminen täysin eri osastojen tarpeisiin on täysin kokeneidenkin kehittäjien kykyjä, jotka eivät ole koskaan työskennelleet arkkitehdina eivätkä osaa piirtää neliöitä nuolia ja tietää 50 termiä Hadoop-ekosysteemistä.
Matkan alussa pääni särkyi monista villeistä avoimien ja suljettujen ohjelmistojen eläintarhoista ja jälkeläisten vastuutaakan ymmärtämisestä. Aloita DataLakesi rakentaminen yksinkertaisilla työkaluilla: nagios/munin -> elastic/kibana -> Hadoop/Spark/s3..., kerää palautetta ja ymmärrä syvästi tapahtuvien prosessien fysiikka. Kaikki monimutkaista ja hämärää - anna se vihollisille ja kilpailijoille.
Jos et halua mennä pilveen ja haluat tukea, päivittää ja korjata avoimen lähdekoodin projekteja, voit rakentaa meidän kaltaisen järjestelmän paikallisesti, edullisille toimistokoneille Hadoopilla ja Prestolla päällä. Tärkeintä ei ole pysähtyä ja siirtyä eteenpäin, laskea, etsiä yksinkertaisia ja selkeitä ratkaisuja, ja kaikki onnistuu varmasti! Onnea kaikille ja nähdään taas!
Lähde: will.com