Vi lever i en fantastisk tid, hvor du hurtigt og nemt kan forbinde flere færdige open source-værktøjer, sætte dem op med din "bevidsthed slukket" i henhold til rådene fra stackoverflow, uden at dykke ned i "flere bogstaver" og starte dem i kommerciel drift. Og når du har brug for at opdatere/udvide, eller nogen ved et uheld genstarter et par maskiner - indser du, at en form for tvangspræget dårlig drøm er begyndt, alt er blevet dramatisk kompliceret til ukendelighed, der er ingen vej tilbage, fremtiden er vag og sikrere, i stedet for at programmere, avle bier og lave ost.
Det er ikke for ingenting, at mere erfarne kolleger, med hovedet strøet med fejl og derfor allerede gråt, overvejer den utroligt hurtige udrulning af pakker med "containere" i "kuber" på snesevis af servere på "fashionable sprog" med indbygget understøttelse af asynkron ikke-blokerende I/O, smil beskedent. Og de fortsætter lydløst med at genlæse "man ps", dykke ned i "nginx"-kildekoden, indtil deres øjne bløder, og skrive, skrive, skrive enhedstests. Kolleger ved, at det mest interessante vil komme, når "alt dette" en dag bliver satset om natten nytårsaften. Og de vil kun blive hjulpet af en dyb forståelse af karakteren af unix, den huskede TCP/IP-tilstandstabel og grundlæggende sorterings-søgningsalgoritmer. At bringe systemet tilbage til live, mens klokkespillet slår til.
Åh ja, jeg blev lidt distraheret, men jeg håber, det lykkedes mig at formidle forventningens tilstand.
I dag vil jeg dele vores erfaring med at implementere en bekvem og billig stack til DataLake, som løser størstedelen af analytiske opgaver i virksomheden for helt andre strukturelle divisioner.
For noget tid siden nåede vi til den forståelse, at virksomheder i stigende grad har brug for frugterne af både produkt- og tekniske analyser (for ikke at nævne prikken over i'et i form af maskinlæring) og for at forstå tendenser og risici - vi skal indsamle og analysere flere og flere flere målinger.
Grundlæggende teknisk analyse i Bitrix24
For adskillige år siden, samtidig med lanceringen af Bitrix24-tjenesten, investerede vi aktivt tid og ressourcer i at skabe en enkel og pålidelig analytisk platform, der kunne hjælpe med hurtigt at se problemer i infrastrukturen og planlægge det næste skridt. Det var selvfølgelig tilrådeligt at tage færdige værktøjer, der var så enkle og forståelige som muligt. Som et resultat blev nagios valgt til overvågning og munin til analyse og visualisering. Nu har vi tusindvis af checks i nagios, hundredvis af diagrammer i munin, og vores kolleger bruger dem med succes hver dag. Målingerne er klare, graferne er klare, systemet har fungeret pålideligt i flere år, og der tilføjes jævnligt nye tests og grafer: Når vi sætter en ny tjeneste i drift, tilføjer vi flere test og grafer. Held og lykke.
Fingeren på pulsen - Avanceret teknisk analyse
Ønsket om at modtage information om problemer "så hurtigt som muligt" førte os til aktive eksperimenter med enkle og forståelige værktøjer - pinba og xhprof.
Pinba sendte os statistik i UDP-pakker om hastigheden af driften af dele af websider i PHP, og vi kunne online i MySQL-lageret (Pinba kommer med sin egen MySQL-motor til hurtig hændelsesanalyse) se en kort liste over problemer og svare på dem. Og xhprof tillod os automatisk at indsamle grafer over udførelsen af de langsomste PHP-sider fra klienter og analysere, hvad der kunne føre til dette - roligt, hælde te eller noget stærkere.
For noget tid siden blev værktøjssættet genopfyldt med en anden ret enkel og forståelig motor baseret på den omvendte indekseringsalgoritme, perfekt implementeret i det legendariske Lucene-bibliotek - Elastic/Kibana. Den enkle idé med multi-threaded registrering af dokumenter i et omvendt Lucene-indeks baseret på hændelser i logfilerne og en hurtig søgning gennem dem ved hjælp af facetdeling viste sig at være virkelig nyttig.
På trods af det ret tekniske udseende af visualiseringer i Kibana med begreber på lavt niveau som "spand", "flyder opad" og det genopfundne sprog i den endnu ikke helt glemte relationelle algebra, begyndte værktøjet at hjælpe os godt i følgende opgaver:
- Hvor mange PHP-fejl havde Bitrix24-klienten på p1-portalen inden for den sidste time, og hvilke? Forstå, tilgiv og ret hurtigt.
- Hvor mange videoopkald blev der foretaget på portaler i Tyskland i de foregående 24 timer, med hvilken kvalitet og var der problemer med kanalen/netværket?
- Hvor godt virker systemfunktionaliteten (vores C-udvidelse til PHP), kompileret fra kilden i den seneste serviceopdatering og udrullet til klienter? Er der sigfaults?
- Passer kundedata ind i PHP-hukommelsen? Er der nogen fejl ved at overskride den hukommelse, der er allokeret til processer: "mangler hukommelse"? Find og neutraliser.
Her er et konkret eksempel. På trods af grundig test på flere niveauer modtog klienten med en meget ikke-standard sag og beskadigede inputdata en irriterende og uventet fejl, en sirene lød, og processen med at rette den hurtigt begyndte:
Derudover giver kibana dig mulighed for at organisere meddelelser om bestemte begivenheder, og på kort tid begyndte værktøjet i virksomheden at blive brugt af snesevis af medarbejdere fra forskellige afdelinger - fra teknisk support og udvikling til QA.
Aktiviteten i enhver afdeling i virksomheden er blevet praktisk at spore og måle - i stedet for manuelt at analysere logfiler på servere, skal du blot oprette parsing-logfiler én gang og sende dem til den elastiske klynge for at nyde, for eksempel at overveje i kibana dashboard antallet af solgte tohovede killinger printet på 3-D printer for den sidste månemåned.
Grundlæggende Business Analytics
Alle ved, at forretningsanalyse i virksomheder ofte begynder med ekstremt aktiv brug af, ja, Excel. Men det vigtigste er, at det ikke slutter der. Cloud-baseret Google Analytics tilføjer også brændstof til bålet - du begynder hurtigt at vænne dig til de gode ting.
I vores harmonisk udviklende virksomhed begyndte der hist og her at dukke op "profeter" af mere intensivt arbejde med større data. Behovet for mere dybdegående og mangefacetterede rapporter begyndte at dukke op regelmæssigt, og gennem indsatsen fra fyre fra forskellige afdelinger blev der for nogen tid siden organiseret en enkel og praktisk løsning - en kombination af ClickHouse og PowerBI.
I temmelig lang tid hjalp denne fleksible løsning meget, men efterhånden begyndte forståelsen at komme, at ClickHouse ikke er gummi og ikke kan hånes på den måde.
Her er det vigtigt at forstå godt, at ClickHouse, ligesom Druid, ligesom Vertica, ligesom Amazon RedShift (der er baseret på postgres), er analytiske motorer optimeret til ret praktiske analyser (summer, aggregeringer, minimum-maksimum efter kolonne og et par mulige joinforbindelser). ), fordi organiseret til effektiv lagring af kolonner af relationelle tabeller, i modsætning til MySQL og andre (rækkeorienterede) databaser, vi kender.
I det væsentlige er ClickHouse bare en mere rummelig "database", med ikke særlig praktisk punkt-for-punkt-indsættelse (det er sådan det er tænkt, alt er ok), men behagelige analyser og et sæt interessante kraftfulde funktioner til at arbejde med data. Ja, du kan endda oprette en klynge - men du forstår, at det ikke er helt korrekt at hamre søm med et mikroskop, og vi begyndte at lede efter andre løsninger.
Efterspørgsel efter python og analytikere
Vores virksomhed har mange udviklere, der skriver kode næsten hver dag i 10-20 år i PHP, JavaScript, C#, C/C++, Java, Go, Rust, Python, Bash. Der er også mange erfarne systemadministratorer, der har oplevet mere end én helt utrolig katastrofe, der ikke passer ind i statistikkens love (f.eks. når størstedelen af diske i en raid-10 bliver ødelagt af et stærkt lynnedslag). Under sådanne omstændigheder var det i lang tid ikke klart, hvad en "pythonanalytiker" var. Python er ligesom PHP, kun navnet er lidt længere, og der er lidt færre spor af sindændrende stoffer i tolkens kildekode. Men efterhånden som flere og flere analytiske rapporter blev oprettet, begyndte erfarne udviklere i stigende grad at forstå vigtigheden af snæver specialisering i værktøjer som numpy, pandas, matplotlib, seaborn.
Den afgørende rolle blev højst sandsynligt spillet af den pludselige besvimelse af medarbejdere fra kombinationen af ordene "logistisk regression" og demonstrationen af effektiv rapportering om store data ved hjælp af, ja, ja, pyspark.
Apache Spark, dets funktionelle paradigme, som relationel algebra passer perfekt til, og dens evner gjorde et så stort indtryk på udviklere, der var vant til MySQL, at behovet for at styrke rækkerne med erfarne analytikere blev klart som dag.
Yderligere forsøg fra Apache Spark/Hadoop på at komme i gang, og hvad der ikke gik helt i henhold til manuskriptet
Det stod dog hurtigt klart, at noget systemisk ikke var helt rigtigt med Spark, eller også var det nødvendigt at vaske hænder bedre. Hvis Hadoop/MapReduce/Lucene-stakken er lavet af ret erfarne programmører, hvilket er indlysende, hvis man ser nærmere på kildekoden i Java eller Doug Cuttings ideer i Lucene, så er Spark pludselig skrevet på det eksotiske sprog Scala, som er meget kontroversielt set ud fra et praktisk synspunkt og er i øjeblikket ikke under udvikling. Og det regelmæssige fald i beregninger på Spark-klyngen på grund af ulogisk og ikke særlig gennemsigtigt arbejde med hukommelsesallokering til reducerende operationer (mange nøgler ankommer på én gang) har skabt en glorie omkring det af noget, der har plads til at vokse. Derudover blev situationen forværret af et stort antal mærkelige åbne porte, midlertidige filer, der voksede på de mest uforståelige steder og et helvede af jar-afhængigheder - hvilket fik systemadministratorer til at have en følelse, som var velkendt fra barndommen: voldsomt had (eller måske de skulle vaske deres hænder med sæbe).
Som et resultat har vi "overlevet" adskillige interne analytiske projekter, der aktivt bruger Apache Spark (inklusive Spark Streaming, Spark SQL) og Hadoop-økosystemet (og så videre og så videre). På trods af det faktum, at vi med tiden lærte at forberede og overvåge "det" ret godt, og "det" praktisk talt stoppede pludseligt med at gå ned på grund af ændringer i dataenes karakter og ubalancen i ensartet RDD-hash, ønsket om at tage noget allerede klar , opdateret og administreret et sted i skyen blev stærkere og stærkere. Det var på dette tidspunkt, at vi forsøgte at bruge den færdige cloud-samling fra Amazon Web Services - og efterfølgende forsøgte at løse problemer ved at bruge det. EMR er Apache Spark udarbejdet af Amazon med ekstra software fra økosystemet, ligesom Cloudera/Hortonworks bygger.
Opbevaring af gummifiler til analyser er et presserende behov
Oplevelsen af at "koge" Hadoop/Spark med forbrændinger på forskellige dele af kroppen var ikke forgæves. Behovet for at skabe et enkelt, billigt og pålideligt fillager, der ville være modstandsdygtigt over for hardwarefejl, og hvor det ville være muligt at gemme filer i forskellige formater fra forskellige systemer og lave effektive og tidseffektive prøver til rapporter fra disse data blev i stigende grad klar.
Jeg ønskede også, at opdatering af softwaren på denne platform ikke blev til et nytårsmareridt med at læse 20-siders Java-spor og analysere kilometerlange detaljerede logfiler af klyngen ved hjælp af Spark History Server og et baggrundsbelyst forstørrelsesglas. Jeg ønskede at have et enkelt og gennemsigtigt værktøj, der ikke krævede regelmæssig dykning under motorhjelmen, hvis udviklerens standard MapReduce-anmodning holdt op med at udføre, da reduceringsdataarbejderen faldt ud af hukommelsen på grund af en ikke særlig velvalgt kildedatapartitioneringsalgoritme.
Er Amazon S3 en kandidat til DataLake?
Erfaring med Hadoop/MapReduce lærte os, at vi har brug for et skalerbart, pålideligt filsystem og skalerbare arbejdere oven i det, der "kommer" tættere på dataene for ikke at drive dataene over netværket. Arbejdere skal være i stand til at læse data i forskellige formater, men helst ikke læse unødvendig information og være i stand til at lagre data på forhånd i formater, der er passende for arbejderne.
Endnu en gang den grundlæggende idé. Der er ikke noget ønske om at "hælde" big data ind i en enkelt klyngeanalysemotor, som før eller siden vil kvæle, og du bliver nødt til at sønderdele det grimt. Jeg vil gemme filer, kun filer, i et forståeligt format og udføre effektive analytiske forespørgsler på dem ved hjælp af forskellige, men forståelige værktøjer. Og der kommer flere og flere filer i forskellige formater. Og det er bedre at skære ikke motoren, men kildedataene. Vi har brug for en udvidelig og universel DataLake, besluttede vi...
Hvad hvis du gemmer filer i det velkendte og velkendte skalerbare skylager Amazon S3, uden at skulle tilberede dine egne koteletter fra Hadoop?
Det er klart, at de personlige data er "lave", men hvad med andre data, hvis vi tager dem derud og "driver dem effektivt"?
Cluster-bigdata-analytics økosystem af Amazon Web Services - i meget enkle ord
At dømme efter vores erfaring med AWS, har Apache Hadoop/MapReduce været aktivt brugt der i lang tid under forskellige saucer, for eksempel i DataPipeline-tjenesten (jeg misunder mine kolleger, de lærte at forberede det korrekt). Her opsætter vi sikkerhedskopier fra forskellige tjenester fra DynamoDB-tabeller:
Og de har kørt regelmæssigt på indlejrede Hadoop/MapReduce-klynger som urværk i flere år nu. "Sæt det og glem det":
Du kan også effektivt engagere dig i datasatanisme ved at opsætte Jupiter-laptops i skyen for analytikere og bruge AWS SageMaker-tjenesten til at træne og implementere AI-modeller i kamp. Sådan ser det ud for os:
Og ja, du kan hente en bærbar computer til dig selv eller en analytiker i skyen og vedhæfte den til en Hadoop/Spark-klynge, lave beregningerne og så slå alt fast:
Virkelig praktisk til individuelle analyseprojekter, og for nogle har vi med succes brugt EMR-tjenesten til storskalaberegninger og analyser. Hvad med en systemløsning til DataLake, vil den virke? I dette øjeblik var vi på grænsen til håb og fortvivlelse og fortsatte eftersøgningen.
AWS Glue - pænt pakket Apache Spark på steroider
Det viste sig, at AWS har sin egen version af "Hive/Pig/Spark"-stakken. Rollen som Hive, dvs. Kataloget over filer og deres typer i DataLake udføres af "Data catalog"-tjenesten, som ikke skjuler dets kompatibilitet med Apache Hive-formatet. Du skal tilføje oplysninger til denne tjeneste om, hvor dine filer er placeret, og i hvilket format de er. Dataene kan ikke kun være i s3, men også i databasen, men det er ikke emnet for dette indlæg. Sådan er vores DataLake-datakatalog organiseret:
Filerne er registreret, fantastisk. Hvis filerne er blevet opdateret, starter vi crawlere enten manuelt eller efter en tidsplan, som vil opdatere oplysninger om dem fra søen og gemme dem. Så kan data fra søen behandles og resultaterne uploades et sted. I det enkleste tilfælde uploader vi også til s3. Databehandling kan udføres hvor som helst, men det foreslås, at du konfigurerer behandlingen på en Apache Spark-klynge ved hjælp af avancerede funktioner gennem AWS Glue API. Faktisk kan du tage den gode gamle og velkendte python-kode ved hjælp af pyspark-biblioteket og konfigurere dens eksekvering på N noder i en klynge med en vis kapacitet med overvågning uden at grave ind i Hadoops indvolde og trække docker-moker-containere og eliminere afhængighedskonflikter .
Endnu en gang en simpel idé. Der er ingen grund til at konfigurere Apache Spark, du skal bare skrive python-kode til pyspark, teste den lokalt på dit skrivebord og derefter køre den på en stor klynge i skyen, og specificere, hvor kildedataene er, og hvor resultatet skal placeres. Nogle gange er dette nødvendigt og nyttigt, og her er, hvordan vi konfigurerer det:
Skal du således beregne noget på en Spark-klynge ved hjælp af data i s3, skriver vi kode i python/pyspark, tester det, og held og lykke til skyen.
Hvad med orkestreringen? Hvad hvis opgaven faldt og forsvandt? Ja, det foreslås at lave en smuk pipeline i Apache Pig-stilen, og vi har endda prøvet dem, men indtil videre besluttede vi at bruge vores dybt tilpassede orkestrering i PHP og JavaScript (jeg forstår, der er kognitiv dissonans, men det virker, for år og uden fejl).
Formatet af filer gemt i søen er nøglen til ydeevne
Det er meget, meget vigtigt at forstå yderligere to nøglepunkter. For at forespørgsler om fildata i søen skal udføres så hurtigt som muligt og ydeevnen ikke forringes, når der tilføjes nye oplysninger, skal du:
- Gem kolonner med filer separat (så du ikke behøver at læse alle linjerne for at forstå, hvad der er i kolonnerne). Til dette tog vi parketformatet med kompression
- Det er meget vigtigt at skære filer i mapper som: sprog, år, måned, dag, uge. Motorer, der forstår denne type sharding, vil kun se på de nødvendige mapper uden at gennemse alle data i en række.
I bund og grund udlægger du på denne måde kildedataene i den mest effektive form for de analytiske motorer, der hang ovenpå, som selv i opdelte mapper selektivt kan indtaste og kun læse de nødvendige kolonner fra filer. Du behøver ikke at "fylde" dataene nogen steder (lageret vil simpelthen briste) - bare med det samme klogt at sætte dem i filsystemet i det korrekte format. Det skal selvfølgelig være klart her, at det ikke er særlig tilrådeligt at gemme en enorm csv-fil i DataLake, som først skal læses linje for linje af klyngen for at udtrække kolonnerne. Tænk på de to ovenstående punkter igen, hvis det endnu ikke er klart, hvorfor alt dette sker.
AWS Athena - jack-in-the-boxen
Og så, mens vi skabte en sø, stødte vi på en eller anden måde ved et uheld på Amazon Athena. Pludselig viste det sig, at man ved omhyggeligt at arrangere vores enorme logfiler i mappeskår i det korrekte (parket)søjleformat, meget hurtigt kan foretage ekstremt informative valg fra dem og opbygge rapporter UDEN, uden en Apache Spark/Glue-klynge.
Athena-motoren drevet af data i s3 er baseret på det legendariske - en repræsentant for MPP (massive parallel processing)-familien af tilgange til databehandling, der tager data, hvor de ligger, fra s3 og Hadoop til Cassandra og almindelige tekstfiler. Du skal bare bede Athena om at udføre en SQL-forespørgsel, og så fungerer alt hurtigt og automatisk. Det er vigtigt at bemærke, at Athena er "smart", den går kun til de nødvendige sønderdelte mapper og læser kun de kolonner, der er nødvendige i anmodningen.
Prisen for anmodninger til Athena er også interessant. vi betaler for . De der. ikke for antallet af maskiner i klyngen pr. minut, men... for de data, der faktisk scannes på 100-500 maskiner, kun de data, der er nødvendige for at fuldføre anmodningen.
Og ved kun at anmode om de nødvendige kolonner fra korrekt sønderdelte mapper, viste det sig, at Athena-tjenesten koster os titusinder af dollars om måneden. Godt, næsten gratis sammenlignet med analyser på klynger!
Forresten, her er, hvordan vi sønderdeler vores data i s3:
Som følge heraf begyndte helt forskellige afdelinger i virksomheden, fra informationssikkerhed til analyse, aktivt at sende anmodninger til Athena og hurtigt på få sekunder modtage nyttige svar fra "store" data over ret lange perioder: måneder, et halvt år osv. P.
Men vi gik videre og begyndte at gå til skyen for at få svar : en analytiker skriver en SQL-forespørgsel i en velkendt konsol, som på 100-500 maskiner "for pennies" sender data til s3 og returnerer et svar normalt på få sekunder. Komfortabel. Og hurtigt. Jeg kan stadig ikke tro det.
Som et resultat, efter at have besluttet at gemme data i s3, i et effektivt søjleformat og med rimelig opdeling af data i mapper... modtog vi DataLake og en hurtig og billig analytisk motor - gratis. Og han blev meget populær i virksomheden, fordi... forstår SQL og arbejder i størrelsesordener hurtigere end gennem start/stop/opsætning af klynger. "Og hvis resultatet er det samme, hvorfor betale mere?"
En anmodning til Athena ser nogenlunde sådan ud. Hvis det ønskes, kan du selvfølgelig danne nok , men vi vil begrænse os til simpel gruppering. Lad os se, hvilke svarkoder klienten havde for et par uger siden i webserverloggene, og sørg for, at der ikke er nogen fejl:
Fund
Efter at have gennemgået, for ikke at sige en lang, men smertefuld vej, konstant tilstrækkeligt at vurdere risici og niveau af kompleksitet og omkostninger ved support, fandt vi en løsning til DataLake og analytics, der aldrig ophører med at glæde os med både hastighed og ejerskabsomkostninger.
Det viste sig, at det at bygge et effektivt, hurtigt og billigt at drive DataLake til behovene i helt forskellige afdelinger af virksomheden er helt inden for evnerne hos selv erfarne udviklere, der aldrig har arbejdet som arkitekter og ikke ved, hvordan man tegner firkanter på firkanter med pile og kender 50 udtryk fra Hadoop-økosystemet.
I begyndelsen af rejsen splittede mit hoved sig fra de mange vilde zoologiske haver af åben og lukket software og forståelsen af ansvaret for efterkommerne. Bare begynd at bygge din DataLake ud fra simple værktøjer: nagios/munin -> elastic/kibana -> Hadoop/Spark/s3..., indsamling af feedback og dyb forståelse af fysikken i de processer, der finder sted. Alt komplekst og grumset - giv det til fjender og konkurrenter.
Hvis du ikke ønsker at gå til skyen og kan lide at understøtte, opdatere og patche open source-projekter, kan du bygge en ordning, der ligner vores lokalt, på billige kontormaskiner med Hadoop og Presto ovenpå. Det vigtigste er ikke at stoppe og komme videre, tælle, se efter enkle og klare løsninger, og alt vil helt sikkert fungere! Held og lykke til alle og på gensyn!
Kilde: www.habr.com