Vi lever i en utrolig tid når du raskt og enkelt kan koble til flere ferdiglagde åpen kildekode-verktøy, sette dem opp med "bevisstheten slått av" i henhold til rådene fra stackoverflow, uten å dykke ned i "flere bokstaver", og starte dem i kommersiell drift. Og når du trenger å oppdatere/utvide eller noen ved et uhell starter et par maskiner på nytt - innser du at en slags obsessiv vond drøm har begynt, alt har blitt dramatisk komplisert til det ugjenkjennelige, det er ingen vei tilbake, fremtiden er vag og tryggere, i stedet for å programmere, avle bier og lage ost.
Det er ikke for ingenting at mer erfarne kolleger, med hodet strødd med feil og derfor allerede grå, vurderer den utrolig raske distribusjonen av pakker med "beholdere" i "kuber" på dusinvis av servere på "motespråk" med innebygd støtte for asynkron ikke-blokkerende I/O, smil beskjedent. Og de fortsetter stille å lese «man ps» på nytt, fordype seg i «nginx»-kildekoden til øynene deres blør, og skrive, skrive, skrive enhetstester. Kolleger vet at det mest interessante vil komme når "alt dette" en dag blir satset om natten på nyttårsaften. Og de vil bare bli hjulpet av en dyp forståelse av naturen til unix, den lagrede TCP/IP-tilstandstabellen og grunnleggende sorteringssøkealgoritmer. For å bringe systemet tilbake til live når klokkespillet slår til.
Å ja, jeg ble litt distrahert, men jeg håper jeg klarte å formidle forventningstilstanden.
I dag vil jeg dele vår erfaring med å distribuere en praktisk og rimelig stack for DataLake, som løser de fleste analytiske oppgaver i selskapet for helt andre strukturelle divisjoner.
For en tid siden kom vi til forståelsen av at bedrifter i økende grad trenger fruktene av både produkt- og teknisk analyse (for ikke å snakke om prikken over i-en i form av maskinlæring) og for å forstå trender og risikoer – vi må samle inn og analysere flere og flere beregninger.
Grunnleggende teknisk analyse i Bitrix24
For flere år siden, samtidig med lanseringen av Bitrix24-tjenesten, investerte vi aktivt tid og ressurser i å lage en enkel og pålitelig analytisk plattform som ville hjelpe raskt å se problemer i infrastrukturen og planlegge neste steg. Det var selvfølgelig lurt å ta med seg ferdige verktøy som var så enkle og forståelige som mulig. Som et resultat ble nagios valgt for overvåking og munin for analyse og visualisering. Nå har vi tusenvis av sjekker i nagios, hundrevis av diagrammer i munin, og kollegene våre bruker dem med suksess hver dag. Beregningene er klare, grafene er klare, systemet har fungert pålitelig i flere år, og nye tester og grafer blir jevnlig lagt til det: Når vi setter i drift en ny tjeneste, legger vi til flere tester og grafer. Lykke til.
Finger on the Pulse - Advanced Technical Analytics
Ønsket om å motta informasjon om problemer "så raskt som mulig" førte oss til aktive eksperimenter med enkle og forståelige verktøy - pinba og xhprof.
Pinba sendte oss statistikk i UDP-pakker om hastigheten på driften av deler av nettsider i PHP, og vi kunne se online i MySQL-lagringen (Pinba kommer med sin egen MySQL-motor for rask hendelsesanalyse) en kort liste over problemer og svare på dem. Og xhprof tillot oss automatisk å samle grafer over utførelsen av de tregeste PHP-sidene fra klienter og analysere hva som kan føre til dette - rolig, skjenke te eller noe sterkere.
For en tid siden ble verktøysettet fylt opp med en annen ganske enkel og forståelig motor basert på den omvendte indekseringsalgoritmen, perfekt implementert i det legendariske Lucene-biblioteket - Elastic/Kibana. Den enkle ideen om flertrådsregistrering av dokumenter i en invers Lucene-indeks basert på hendelser i loggene og et raskt søk gjennom dem ved hjelp av fasettdeling viste seg å være veldig nyttig.
Til tross for det ganske tekniske utseendet til visualiseringer i Kibana med konsepter på lavt nivå som «bøtte» som «flyter oppover» og det gjenoppfunnede språket til den ennå ikke helt glemte relasjonsalgebraen, begynte verktøyet å hjelpe oss godt i følgende oppgaver:
- Hvor mange PHP-feil hadde Bitrix24-klienten på p1-portalen den siste timen og hvilke? Forstå, tilgi og korriger raskt.
- Hvor mange videosamtaler ble det foretatt på portaler i Tyskland i løpet av de siste 24 timene, med hvilken kvalitet og var det noen problemer med kanalen/nettverket?
- Hvor godt fungerer systemfunksjonaliteten (vår C-utvidelse for PHP), kompilert fra kilden i den siste tjenesteoppdateringen og rullet ut til klienter? Er det segfeil?
- Passer kundedata inn i PHP-minnet? Er det noen feil ved å overskride minnet som er allokert til prosesser: "tomt minne"? Finn og nøytraliser.
Her er et konkret eksempel. Til tross for grundig testing på flere nivåer, mottok klienten, med en svært ikke-standard sak og skadede inngangsdata, en irriterende og uventet feil, en sirene hørtes og prosessen med å raskt fikse den begynte:
I tillegg lar kibana deg organisere varsler for spesifiserte hendelser, og i løpet av kort tid begynte verktøyet i selskapet å bli brukt av dusinvis av ansatte fra forskjellige avdelinger - fra teknisk støtte og utvikling til QA.
Aktiviteten til enhver avdeling i selskapet har blitt praktisk å spore og måle - i stedet for å manuelt analysere logger på servere, trenger du bare å sette opp parsing-logger én gang og sende dem til den elastiske klyngen for å nyte, for eksempel, kontemplere i kibana dashbord antall solgte tohodede kattunger skrevet ut på 3D-skriver for den siste månemåneden.
Grunnleggende Business Analytics
Alle vet at forretningsanalyse i bedrifter ofte begynner med ekstremt aktiv bruk av, ja, Excel. Men det viktigste er at det ikke slutter der. Skybasert Google Analytics legger også bensin på bålet – du begynner raskt å venne deg til de gode tingene.
I vårt harmonisk utviklende selskap begynte her og der "profeter" for mer intensivt arbeid med større data å dukke opp. Behovet for mer dyptgående og mangefasetterte rapporter begynte å dukke opp jevnlig, og gjennom innsatsen fra gutter fra forskjellige avdelinger ble det for en tid siden organisert en enkel og praktisk løsning - en kombinasjon av ClickHouse og PowerBI.
I ganske lang tid hjalp denne fleksible løsningen mye, men etter hvert begynte forståelsen å komme for at ClickHouse ikke er gummi og ikke kan hånes slik.
Her er det viktig å forstå godt at ClickHouse, som Druid, som Vertica, som Amazon RedShift (som er basert på postgres), er analytiske motorer optimalisert for ganske praktiske analyser (summer, aggregeringer, minimum-maksimum etter kolonne og noen få mulige sammenføyninger ), fordi organisert for effektiv lagring av kolonner med relasjonstabeller, i motsetning til MySQL og andre (radorienterte) databaser kjent for oss.
I hovedsak er ClickHouse bare en mer romslig "database", med ikke veldig praktisk punkt-for-punkt-innsetting (det er slik det er ment, alt er ok), men hyggelige analyser og et sett med interessante kraftige funksjoner for å jobbe med data. Ja, du kan til og med lage en klynge - men du forstår at det ikke er helt riktig å hamre spiker med et mikroskop, og vi begynte å se etter andre løsninger.
Etterspørsel etter python og analytikere
Vårt firma har mange utviklere som skriver kode nesten hver dag i 10-20 år i PHP, JavaScript, C#, C/C++, Java, Go, Rust, Python, Bash. Det er også mange erfarne systemadministratorer som har opplevd mer enn én helt utrolig katastrofe som ikke passer inn i statistikkens lover (for eksempel når flertallet av diskene i et raid-10 blir ødelagt av et kraftig lynnedslag). Under slike omstendigheter var det lenge ikke klart hva en "pytonanalytiker" var. Python er som PHP, bare navnet er litt lengre og det er litt mindre spor av sinnsendrende stoffer i tolkens kildekode. Men etter hvert som flere og flere analytiske rapporter ble opprettet, begynte erfarne utviklere i økende grad å forstå viktigheten av smal spesialisering i verktøy som numpy, pandaer, matplotlib, seaborn.
Den avgjørende rollen ble mest sannsynlig spilt av den plutselige besvimelsen av ansatte fra kombinasjonen av ordene "logistisk regresjon" og demonstrasjonen av effektiv rapportering om store data ved hjelp av, ja, ja, pyspark.
Apache Spark, dets funksjonelle paradigme som relasjonsalgebra passer perfekt til, og dens evner gjorde et så stort inntrykk på utviklere som var vant til MySQL at behovet for å styrke rekkene med erfarne analytikere ble tydelig.
Ytterligere forsøk fra Apache Spark/Hadoop på å ta av og det som ikke gikk helt i henhold til manuset
Det ble imidlertid raskt klart at noe systemmessig ikke var helt som det skulle med Spark, eller det var rett og slett nødvendig å vaske hendene bedre. Hvis Hadoop/MapReduce/Lucene-stabelen ble laget av ganske erfarne programmerere, noe som er åpenbart hvis du ser nøye på kildekoden i Java eller Doug Cuttings ideer i Lucene, så er Spark plutselig skrevet på det eksotiske språket Scala, som er svært kontroversielt fra et praktisk synspunkt og er foreløpig ikke under utvikling. Og det vanlige fallet i beregninger på Spark-klyngen på grunn av ulogisk og lite transparent arbeid med minneallokering for reduserte operasjoner (mange nøkler kommer på en gang) har skapt en glorie rundt den av noe som har plass til å vokse. I tillegg ble situasjonen forverret av et stort antall merkelige åpne porter, midlertidige filer som vokste på de mest uforståelige stedene og et helvete av jar-avhengigheter - noe som førte til at systemadministratorer hadde en følelse som var godt kjent fra barndommen: voldsomt hat (eller kanskje de trengte å vaske hendene med såpe).
Som et resultat har vi "overlevd" flere interne analytiske prosjekter som aktivt bruker Apache Spark (inkludert Spark Streaming, Spark SQL) og Hadoop-økosystemet (og så videre og så videre). Til tross for at vi over tid lærte å forberede og overvåke "det" ganske godt, og at "det" praktisk talt sluttet plutselig å krasje på grunn av endringer i dataenes natur og ubalansen i enhetlig RDD-hashing, ønsket om å ta noe allerede klart , oppdatert og administrert et sted i skyen ble sterkere og sterkere. Det var på dette tidspunktet vi prøvde å bruke den ferdige skymontasjen til Amazon Web Services - og prøvde deretter å løse problemer ved å bruke den. EMR er Apache Spark utarbeidet av Amazon med tilleggsprogramvare fra økosystemet, omtrent som Cloudera/Hortonworks bygger.
Gummifillagring for analyser er et presserende behov
Opplevelsen av å «koke» Hadoop/Spark med brannskader på ulike deler av kroppen var ikke forgjeves. Behovet for å lage en enkelt, rimelig og pålitelig fillagring som ville være motstandsdyktig mot maskinvarefeil og hvor det ville være mulig å lagre filer i forskjellige formater fra forskjellige systemer og lage effektive og tidseffektive prøver for rapporter fra disse dataene ble stadig mer. klar.
Jeg ønsket også at oppdatering av programvaren til denne plattformen ikke ble til et nyttårsmareritt med å lese 20-siders Java-spor og analysere kilometerlange detaljerte logger av klyngen ved hjelp av Spark History Server og et bakgrunnsbelyst forstørrelsesglass. Jeg ønsket å ha et enkelt og gjennomsiktig verktøy som ikke krevde regelmessig dykking under panseret hvis utviklerens standard MapReduce-forespørsel sluttet å kjøre når reduseringsdataarbeideren falt ut av minnet på grunn av en ikke særlig godt valgt kildedatapartisjonsalgoritme.
Er Amazon S3 en kandidat for DataLake?
Erfaring med Hadoop/MapReduce lærte oss at vi trenger et skalerbart, pålitelig filsystem og skalerbare arbeidere på toppen av det, som "kommer" nærmere dataene for ikke å drive dataene over nettverket. Arbeidstakere skal kunne lese data i forskjellige formater, men helst ikke lese unødvendig informasjon og kunne lagre data på forhånd i formater som er praktiske for arbeiderne.
Nok en gang, den grunnleggende ideen. Det er ikke noe ønske om å "helle" store data inn i en enkelt klyngeanalysemotor, som før eller siden vil kveles og du må sønderdele den stygg. Jeg ønsker å lagre filer, bare filer, i et forståelig format og utføre effektive analytiske spørringer på dem ved å bruke forskjellige, men forståelige verktøy. Og det blir flere og flere filer i forskjellige formater. Og det er bedre å sønderdele ikke motoren, men kildedataene. Vi trenger en utvidbar og universell DataLake, bestemte vi oss for...
Hva om du lagrer filer i den kjente og velkjente skalerbare skylagringen Amazon S3, uten å måtte tilberede dine egne koteletter fra Hadoop?
Det er klart at personopplysningene er "lave", men hva med andre data hvis vi tar dem ut og "driver dem effektivt"?
Cluster-bigdata-analytics-økosystemet til Amazon Web Services - med veldig enkle ord
Etter vår erfaring med AWS å dømme, har Apache Hadoop/MapReduce vært aktivt brukt der i lang tid under ulike sauser, for eksempel i DataPipeline-tjenesten (jeg misunner kollegene mine, de lærte å tilberede det riktig). Her setter vi opp sikkerhetskopier fra forskjellige tjenester fra DynamoDB-tabeller:
Og de har kjørt regelmessig på innebygde Hadoop/MapReduce-klynger som smurt i flere år nå. "Sett det og glem det":
Du kan også effektivt engasjere deg i datasatanisme ved å sette opp Jupiter bærbare datamaskiner i skyen for analytikere og bruke AWS SageMaker-tjenesten til å trene og distribuere AI-modeller i kamp. Slik ser det ut for oss:
Og ja, du kan plukke opp en bærbar datamaskin til deg selv eller en analytiker i skyen og koble den til en Hadoop/Spark-klynge, gjøre beregningene og så spikre alt ned:
Virkelig praktisk for individuelle analytiske prosjekter, og for noen har vi med hell brukt EMR-tjenesten for storskala beregninger og analyser. Hva med en systemløsning for DataLake, vil den fungere? I dette øyeblikket var vi på grensen til håp og fortvilelse og fortsatte letingen.
AWS Glue - pent pakket Apache Spark på steroider
Det viste seg at AWS har sin egen versjon av "Hive/Pig/Spark"-stabelen. Rollen til Hive, dvs. Katalogen over filer og deres typer i DataLake utføres av "Data catalog"-tjenesten, som ikke skjuler dens kompatibilitet med Apache Hive-formatet. Du må legge til informasjon til denne tjenesten om hvor filene dine er plassert og i hvilket format de er. Dataene kan ikke bare være i s3, men også i databasen, men det er ikke temaet for dette innlegget. Slik er DataLake-datakatalogen vår organisert:
Filene er registrert, flott. Hvis filene har blitt oppdatert, starter vi robotsøkeprogrammer enten manuelt eller etter en tidsplan, som vil oppdatere informasjon om dem fra innsjøen og lagre dem. Da kan dataene fra innsjøen behandles og resultatene lastes opp et sted. I det enkleste tilfellet laster vi også opp til s3. Databehandling kan gjøres hvor som helst, men det foreslås at du konfigurerer behandlingen på en Apache Spark-klynge ved å bruke avanserte funksjoner gjennom AWS Glue API. Faktisk kan du ta den gode gamle og velkjente python-koden ved å bruke pyspark-biblioteket og konfigurere dens utførelse på N noder i en klynge med en viss kapasitet med overvåking, uten å grave inn i innvollene til Hadoop og dra docker-smoker-containere og eliminere avhengighetskonflikter .
Nok en gang, en enkel idé. Det er ikke nødvendig å konfigurere Apache Spark, du trenger bare å skrive python-kode for pyspark, teste den lokalt på skrivebordet og deretter kjøre den på en stor klynge i skyen, spesifisere hvor kildedataene er og hvor du skal plassere resultatet. Noen ganger er dette nødvendig og nyttig, og her er hvordan vi setter det opp:
Derfor, hvis du trenger å beregne noe på en Spark-klynge ved hjelp av data i s3, skriver vi kode i python/pyspark, tester det, og lykke til til skyen.
Hva med orkestreringen? Hva om oppgaven falt og forsvant? Ja, det er foreslått å lage en vakker pipeline i Apache Pig-stilen, og vi prøvde dem til og med, men foreløpig bestemte vi oss for å bruke vår dypt tilpassede orkestrering i PHP og JavaScript (jeg forstår, det er kognitiv dissonans, men det fungerer, for år og uten feil).
Formatet på filer som er lagret i innsjøen er nøkkelen til ytelse
Det er veldig, veldig viktig å forstå ytterligere to nøkkelpunkter. For at forespørsler om fildata i innsjøen skal utføres så raskt som mulig og ytelsen ikke forringes når ny informasjon legges til, må du:
- Lagre kolonner med filer separat (slik at du ikke trenger å lese alle linjene for å forstå hva som står i kolonnene). For dette tok vi parkettformatet med kompresjon
- Det er veldig viktig å dele filer i mapper som: språk, år, måned, dag, uke. Motorer som forstår denne typen sharding vil bare se på de nødvendige mappene, uten å sile gjennom alle dataene på rad.
I hovedsak, på denne måten, legger du ut kildedataene i den mest effektive formen for de analytiske motorene som henger på toppen, som selv i oppdelte mapper selektivt kan gå inn og lese bare de nødvendige kolonnene fra filer. Du trenger ikke å "fylle opp" dataene hvor som helst (lagringen vil ganske enkelt sprekke) - bare umiddelbart legg den inn i filsystemet i riktig format. Selvfølgelig skal det være klart her at lagring av en enorm csv-fil i DataLake, som først må leses linje for linje av klyngen for å trekke ut kolonnene, er lite tilrådelig. Tenk på de to punktene ovenfor igjen hvis det ennå ikke er klart hvorfor alt dette skjer.
AWS Athena - jack-in-the-box
Og så, mens vi skapte en innsjø, kom vi på en eller annen måte tilfeldigvis over Amazon Athena. Plutselig viste det seg at ved å nøye ordne de enorme loggfilene våre i mappeskår i riktig (parkett)søyleformat, kan du veldig raskt gjøre ekstremt informative valg fra dem og bygge rapporter UTEN, uten en Apache Spark/Glue-klynge.
Athena-motoren drevet av data i s3 er basert på den legendariske - en representant for MPP (massive parallel processing)-familien av tilnærminger til databehandling, som tar data der de ligger, fra s3 og Hadoop til Cassandra og vanlige tekstfiler. Du trenger bare å be Athena om å utføre en SQL-spørring, og så fungerer alt raskt og automatisk. Det er viktig å merke seg at Athena er "smart", den går bare til de nødvendige sønderdelte mappene og leser bare kolonnene som trengs i forespørselen.
Prisen for forespørsler til Athena er også interessant. Vi betaler for . De. ikke for antall maskiner i klyngen per minutt, men... for data som faktisk er skannet på 100-500 maskiner, bare dataene som er nødvendige for å fullføre forespørselen.
Og ved å be om bare de nødvendige kolonnene fra korrekt sønderdelte mapper, viste det seg at Athena-tjenesten koster oss titalls dollar i måneden. Vel, flott, nesten gratis, sammenlignet med analyser på klynger!
Forresten, her er hvordan vi deler dataene våre i s3:
Som et resultat begynte helt andre avdelinger i selskapet på kort tid, fra informasjonssikkerhet til analyse, aktivt å sende forespørsler til Athena og raskt, på sekunder, motta nyttige svar fra "store" data over ganske lange perioder: måneder, et halvt år osv. P.
Men vi gikk videre og begynte å gå til skyen for å få svar : en analytiker skriver en SQL-spørring i en kjent konsoll, som på 100-500 maskiner "for pennies" sender data til s3 og returnerer et svar vanligvis i løpet av noen få sekunder. Komfortabel. Og raskt. Jeg kan fortsatt ikke tro det.
Som et resultat, etter å ha bestemt oss for å lagre data i s3, i et effektivt kolonneformat og med rimelig deling av data til mapper... mottok vi DataLake og en rask og billig analysemotor - gratis. Og han ble veldig populær i selskapet, fordi... forstår SQL og fungerer raskere i størrelsesordener enn ved å starte/stoppe/sette opp klynger. "Og hvis resultatet er det samme, hvorfor betale mer?"
En forespørsel til Athena ser omtrent slik ut. Om ønskelig kan du selvfølgelig danne nok , men vi vil begrense oss til enkel gruppering. La oss se hvilke svarkoder klienten hadde for noen uker siden i webserverloggene og sørge for at det ikke er noen feil:
Funn
Etter å ha gått gjennom, for ikke å si en lang, men smertefull vei, og kontinuerlig vurdert risikoene og kompleksitetsnivået og kostnadene for støtte, fant vi en løsning for DataLake og analyser som aldri slutter å glede oss med både hastighet og eierkostnader.
Det viste seg at det å bygge en effektiv, rask og billig å drifte DataLake for behovene til helt forskjellige avdelinger i selskapet er helt innenfor evnene til selv erfarne utviklere som aldri har jobbet som arkitekter og ikke vet hvordan de skal tegne firkanter på firkanter med piler og kjenner 50 termer fra Hadoop-økosystemet.
I begynnelsen av reisen splittet hodet mitt fra de mange ville dyreparkene med åpen og lukket programvare og forståelsen av ansvarsbyrden til etterkommere. Bare begynn å bygge din DataLake fra enkle verktøy: nagios/munin -> elastic/kibana -> Hadoop/Spark/s3..., samle tilbakemeldinger og forstå fysikken i prosessene som finner sted. Alt komplekst og grumsete - gi det til fiender og konkurrenter.
Hvis du ikke vil gå til skyen og liker å støtte, oppdatere og lappe åpen kildekode-prosjekter, kan du bygge et opplegg som ligner vårt lokalt, på rimelige kontormaskiner med Hadoop og Presto på toppen. Det viktigste er ikke å stoppe og gå videre, telle, se etter enkle og klare løsninger, og alt vil definitivt ordne seg! Lykke til alle sammen og på gjensyn!
Kilde: www.habr.com