Vi lever i en fantastisk tid när du snabbt och enkelt kan koppla ihop flera färdiga verktyg med öppen källkod, ställa in dem med ditt "medvetande avstängt" enligt råd från stackoverflow, utan att fördjupa dig i "flera bokstäver" och starta dem i kommersiell drift. Och när du behöver uppdatera/expandera eller någon av misstag startar om ett par maskiner - du inser att någon form av tvångsmässig dålig dröm har börjat, allt har blivit dramatiskt komplicerat till oigenkännlighet, det finns ingen återvändo, framtiden är vag och säkrare, istället för att programmera, föda upp bin och göra ost.
Det är inte för inte som mer erfarna kollegor, med huvuden överströdda med buggar och därför redan grå, överväger den otroligt snabba distributionen av paket med "behållare" i "kuber" på dussintals servrar på "fashionabla språk" med inbyggt stöd för asynkron icke-blockerande I/O, le blygsamt. Och de fortsätter tyst att läsa om "man ps", fördjupa sig i "nginx"-källkoden tills deras ögon blöder och skriva, skriva, skriva enhetstester. Kollegor vet att det mest intressanta kommer att komma när "allt detta" en dag blir utspelat på natten på nyårsafton. Och de kommer bara att få hjälp av en djup förståelse av Unixs natur, den memorerade TCP/IP-tillståndstabellen och grundläggande sorterings-sökningsalgoritmer. För att återuppliva systemet när klockspelet slår till.
Åh ja, jag blev lite distraherad, men jag hoppas att jag lyckades förmedla tillståndet av förväntan.
Idag vill jag dela med mig av vår erfarenhet av att distribuera en bekväm och billig stack för DataLake, som löser majoriteten av analytiska uppgifter i företaget för helt andra strukturella divisioner.
För en tid sedan kom vi till insikten att företag i allt större utsträckning behöver frukterna av både produktanalys och teknisk analys (för att inte tala om grädden på moset i form av maskininlärning) och för att förstå trender och risker – vi behöver samla in och analysera fler och fler mätvärden.
Grundläggande teknisk analys i Bitrix24
För flera år sedan, samtidigt med lanseringen av Bitrix24-tjänsten, investerade vi aktivt tid och resurser på att skapa en enkel och pålitlig analytisk plattform som skulle hjälpa till att snabbt se problem i infrastrukturen och planera nästa steg. Naturligtvis var det lämpligt att ta färdiga verktyg som var så enkla och begripliga som möjligt. Som ett resultat valdes nagios för övervakning och munin för analys och visualisering. Nu har vi tusentals checkar i nagios, hundratals diagram i munin, och våra kollegor använder dem framgångsrikt varje dag. Måtten är tydlig, graferna är tydliga, systemet har fungerat tillförlitligt i flera år och nya tester och grafer läggs regelbundet till: när vi sätter igång en ny tjänst lägger vi till flera tester och grafer. Lycka till.
Finger on the Pulse - Avancerad teknisk analys
Viljan att få information om problem "så snabbt som möjligt" ledde oss till aktiva experiment med enkla och begripliga verktyg - pinba och xhprof.
Pinba skickade oss statistik i UDP-paket om hastigheten för driften av delar av webbsidor i PHP, och vi kunde se online i MySQL-lagringen (Pinba kommer med en egen MySQL-motor för snabb händelseanalys) en kort lista över problem och svara på dem. Och xhprof tillät oss automatiskt att samla in grafer över exekveringen av de långsammaste PHP-sidorna från klienter och analysera vad som kunde leda till detta - lugnt, hälla upp te eller något starkare.
För en tid sedan fylldes verktygslådan på med en annan ganska enkel och begriplig motor baserad på den omvända indexeringsalgoritmen, perfekt implementerad i det legendariska Lucene-biblioteket - Elastic/Kibana. Den enkla idén med flertrådsregistrering av dokument i ett omvänt Lucene-index baserat på händelser i loggarna och en snabb sökning genom dem med hjälp av facettdelning visade sig vara riktigt användbar.
Trots det ganska tekniska utseendet av visualiseringar i Kibana med lågnivåbegrepp som "hink" "flytande uppåt" och det återuppfunna språket i den ännu inte helt bortglömda relationalgebra, började verktyget hjälpa oss väl i följande uppgifter:
- Hur många PHP-fel hade Bitrix24-klienten på p1-portalen den senaste timmen och vilka? Förstå, förlåt och rätt snabbt.
- Hur många videosamtal gjordes på portaler i Tyskland under de senaste 24 timmarna, med vilken kvalitet och fanns det några problem med kanalen/nätverket?
- Hur väl fungerar systemfunktionaliteten (vår C-tillägg för PHP), kompilerad från källan i den senaste tjänstuppdateringen och rullad ut till klienter? Finns det sigfel?
- Passar kunddata in i PHP-minnet? Finns det några fel om att överskrida minnet som allokerats till processer: "tomt minne"? Hitta och neutralisera.
Här är ett konkret exempel. Trots noggranna tester på flera nivåer fick klienten, med ett mycket icke-standardiserat fodral och skadade indata, ett irriterande och oväntat fel, en siren ljöd och processen att snabbt fixa det började:
Dessutom låter kibana dig organisera aviseringar för specifika händelser, och på kort tid började verktyget i företaget användas av dussintals anställda från olika avdelningar - från teknisk support och utveckling till QA.
Aktiviteten för vilken avdelning som helst inom företaget har blivit bekväm att spåra och mäta - istället för att manuellt analysera loggar på servrar behöver du bara ställa in parsningsloggar en gång och skicka dem till det elastiska klustret för att till exempel njuta av att tänka i kibanan instrumentpanelen antalet sålda tvåhövdade kattungar som skrivits ut på 3D-skrivare under den senaste månmånaden.
Grundläggande affärsanalys
Alla vet att affärsanalys i företag ofta börjar med extremt aktiv användning av, ja, Excel. Men huvudsaken är att det inte slutar där. Molnbaserad Google Analytics lägger också bränsle på elden – du börjar snabbt vänja dig vid det goda.
I vårt harmoniskt utvecklande företag började här och där "profeter" för mer intensivt arbete med större data dyka upp. Behovet av mer djupgående och mångfacetterade rapporter började dyka upp regelbundet, och genom insatser från killar från olika avdelningar organiserades för en tid sedan en enkel och praktisk lösning - en kombination av ClickHouse och PowerBI.
Under ganska lång tid hjälpte denna smidiga lösning mycket, men så småningom började förståelsen komma att ClickHouse inte är gummi och inte kan hånas så.
Här är det viktigt att förstå väl att ClickHouse, som Druid, som Vertica, som Amazon RedShift (som är baserad på postgres), är analytiska motorer optimerade för ganska bekväma analyser (summor, aggregationer, minimum-maximum per kolumn och några möjliga kopplingar ), därför att organiserad för effektiv lagring av kolumner i relationstabeller, till skillnad från MySQL och andra (radorienterade) databaser som vi känner till.
I huvudsak är ClickHouse bara en mer rymlig "databas", med inte särskilt bekväm punkt-för-punkt-insättning (det är så det är tänkt, allt är ok), men trevlig analys och en uppsättning intressanta kraftfulla funktioner för att arbeta med data. Ja, du kan till och med skapa ett kluster - men du förstår att det inte är helt korrekt att slå spikar med ett mikroskop och vi började leta efter andra lösningar.
Efterfrågan på python och analytiker
Vårt företag har många utvecklare som skriver kod nästan varje dag i 10-20 år i PHP, JavaScript, C#, C/C++, Java, Go, Rust, Python, Bash. Det finns också många erfarna systemadministratörer som har upplevt mer än en helt otrolig katastrof som inte passar in i statistikens lagar (till exempel när majoriteten av diskarna i en raid-10 förstörs av ett kraftigt blixtnedslag). Under sådana omständigheter var det länge inte klart vad en "pytonanalytiker" var. Python är som PHP, bara namnet är lite längre och det finns lite mindre spår av sinnesförändrande ämnen i tolkens källkod. Men när fler och fler analytiska rapporter skapades, började erfarna utvecklare alltmer förstå vikten av smal specialisering i verktyg som numpy, pandas, matplotlib, seaborn.
Den avgörande rollen spelades troligen av den plötsliga svimningen av anställda från kombinationen av orden "logistisk regression" och demonstrationen av effektiv rapportering av stora data med hjälp av, ja, ja, pyspark.
Apache Spark, dess funktionella paradigm som relationsalgebra passar perfekt in på, och dess kapacitet gjorde ett sådant intryck på MySQL-vana utvecklare att behovet av att stärka leden med erfarna analytiker blev tydligt.
Ytterligare försök av Apache Spark/Hadoop att ta fart och det som inte gick riktigt enligt manuset
Det stod dock snart klart att något systemmässigt inte stod rätt till med Spark, eller så var det helt enkelt nödvändigt att tvätta händerna bättre. Om Hadoop/MapReduce/Lucene-stacken gjordes av ganska erfarna programmerare, vilket är uppenbart om man tittar noga på källkoden i Java eller Doug Cuttings idéer i Lucene, så är Spark plötsligt skriven på det exotiska språket Scala, vilket är mycket kontroversiellt ur praktisk synvinkel och håller för närvarande inte på att utvecklas. Och den regelbundna nedgången i beräkningar på Spark-klustret på grund av ologiskt och inte särskilt transparent arbete med minnesallokering för reducerade operationer (många nycklar kommer på en gång) har skapat en gloria runt det av något som har utrymme att växa. Dessutom förvärrades situationen av ett stort antal konstiga öppna portar, temporära filer som växte på de mest obegripliga platser och ett helvete av jar-beroenden - vilket fick systemadministratörer att ha en känsla som var välkänd från barndomen: våldsamt hat (eller kanske de behövde tvätta händerna med tvål).
Som ett resultat har vi "överlevt" flera interna analytiska projekt som aktivt använder Apache Spark (inklusive Spark Streaming, Spark SQL) och Hadoop-ekosystemet (och så vidare och så vidare). Trots det faktum att vi med tiden lärde oss att förbereda och övervaka "det" ganska bra, och "det" praktiskt taget slutade plötsligt krascha på grund av förändringar i uppgifternas natur och obalansen i enhetlig RDD-hashning, önskan att ta något som redan är klart , uppdaterad och administrerad någonstans i molnet blev starkare och starkare. Det var vid denna tidpunkt som vi försökte använda den färdiga molnenheten av Amazon Web Services - och försökte sedan lösa problem med att använda den. EMR är Apache Spark framställt av Amazon med ytterligare programvara från ekosystemet, ungefär som Cloudera/Hortonworks bygger.
Gummifillagring för analys är ett akut behov
Upplevelsen av att ”laga” Hadoop/Spark med brännskador på olika delar av kroppen var inte förgäves. Behovet av att skapa en enda, billig och pålitlig fillagring som skulle vara resistent mot hårdvarufel och där det skulle vara möjligt att lagra filer i olika format från olika system och göra effektiva och tidseffektiva prover för rapporter från dessa data blev alltmer klar.
Jag ville också att uppdatering av programvaran för den här plattformen inte skulle bli en nyårsmardröm med att läsa 20-sidiga Java-spår och analysera kilometerlånga detaljerade loggar av klustret med hjälp av Spark History Server och ett bakgrundsbelyst förstoringsglas. Jag ville ha ett enkelt och transparent verktyg som inte krävde regelbunden dykning under huven om utvecklarens standard MapReduce-begäran slutade köras när reduceringsdataarbetaren tappade ur minnet på grund av en inte särskilt väl vald källdatapartitioneringsalgoritm.
Är Amazon S3 en kandidat för DataLake?
Erfarenhet av Hadoop/MapReduce lärde oss att vi behöver ett skalbart, pålitligt filsystem och skalbara arbetare ovanpå det, som "kommer" närmare data för att inte driva data över nätverket. Arbetare ska kunna läsa data i olika format, men helst inte läsa onödig information och kunna lagra data i förväg i format som är lämpliga för arbetarna.
Återigen grundidén. Det finns ingen önskan att "hälla" big data i en enda klusteranalysmotor, som förr eller senare kommer att kvävas och du kommer att behöva skära den ful. Jag vill lagra filer, bara filer, i ett begripligt format och utföra effektiva analytiska frågor på dem med hjälp av olika men begripliga verktyg. Och det blir fler och fler filer i olika format. Och det är bättre att skära inte motorn, utan källdata. Vi behöver en utbyggbar och universell DataLake, vi bestämde oss...
Vad händer om du lagrar filer i den välbekanta och välkända skalbara molnlagringen Amazon S3, utan att behöva förbereda dina egna kotletter från Hadoop?
Det är uppenbart att personuppgifterna är "låg", men hur är det med andra uppgifter om vi tar ut dem och "driver dem effektivt"?
Cluster-bigdata-analytics ekosystem för Amazon Web Services - i mycket enkla ord
Att döma av vår erfarenhet av AWS har Apache Hadoop/MapReduce använts aktivt där under en längre tid under olika såser, till exempel i tjänsten DataPipeline (jag avundas mina kollegor, de lärde sig hur man förbereder det rätt). Här ställer vi upp säkerhetskopior från olika tjänster från DynamoDB-tabeller:
Och de har körts regelbundet på inbäddade Hadoop/MapReduce-kluster som clockwork i flera år nu. "Ställ in det och glöm det":
Du kan också effektivt engagera dig i datasatanism genom att installera Jupiters bärbara datorer i molnet för analytiker och använda AWS SageMaker-tjänsten för att träna och distribuera AI-modeller i strid. Så här ser det ut för oss:
Och ja, du kan plocka upp en bärbar dator till dig själv eller en analytiker i molnet och koppla den till ett Hadoop/Spark-kluster, göra beräkningarna och sedan spika allt:
Verkligen praktiskt för enskilda analysprojekt och för vissa har vi framgångsrikt använt EMR-tjänsten för storskaliga beräkningar och analyser. Hur är det med en systemlösning för DataLake, kommer den att fungera? I detta ögonblick var vi på gränsen till hopp och förtvivlan och fortsatte sökandet.
AWS Glue - snyggt förpackad Apache Spark på steroider
Det visade sig att AWS har sin egen version av "Hive/Pig/Spark"-stacken. Rollen som Hive, dvs. Katalogen över filer och deras typer i DataLake utförs av tjänsten "Datakatalog", som inte döljer dess kompatibilitet med Apache Hive-formatet. Du måste lägga till information till den här tjänsten om var dina filer finns och i vilket format de är. Data kan inte bara finnas i s3, utan också i databasen, men det är inte ämnet för det här inlägget. Så här är vår DataLake-datakatalog organiserad:
Filerna är registrerade, bra. Om filerna har uppdaterats startar vi sökrobotar antingen manuellt eller enligt ett schema, som uppdaterar information om dem från sjön och sparar dem. Då kan data från sjön bearbetas och resultaten laddas upp någonstans. I det enklaste fallet laddar vi även upp till s3. Databearbetning kan göras var som helst, men det föreslås att du konfigurerar bearbetningen på ett Apache Spark-kluster med hjälp av avancerade funktioner via AWS Glue API. Faktum är att du kan ta den gamla och välbekanta pythonkoden med hjälp av pyspark-biblioteket och konfigurera dess exekvering på N noder i ett kluster med viss kapacitet med övervakning, utan att gräva i Hadoops inälvor och dra i hamnarbetare-rökare och eliminera beroendekonflikter .
Återigen, en enkel idé. Det finns inget behov av att konfigurera Apache Spark, du behöver bara skriva python-kod för pyspark, testa den lokalt på ditt skrivbord och sedan köra den på ett stort kluster i molnet, och specificera var källdata finns och var du ska placera resultatet. Ibland är detta nödvändigt och användbart, och så här ställer vi in det:
Således, om du behöver beräkna något på ett Spark-kluster med hjälp av data i s3, skriver vi kod i python/pyspark, testar det och lycka till till molnet.
Hur är det med orkestreringen? Tänk om uppgiften föll och försvann? Ja, det föreslås att göra en vacker pipeline i Apache Pig-stilen och vi har till och med provat dem, men för närvarande bestämde vi oss för att använda vår djupt anpassade orkestrering i PHP och JavaScript (jag förstår, det finns kognitiv dissonans, men det fungerar, för år och utan fel).
Formatet på filer som lagras i sjön är nyckeln till prestanda
Det är väldigt, väldigt viktigt att förstå ytterligare två nyckelpunkter. För att frågor om fildata i sjön ska exekveras så snabbt som möjligt och prestandan inte försämras när ny information läggs till behöver du:
- Lagra kolumner med filer separat (så att du inte behöver läsa alla rader för att förstå vad som finns i kolumnerna). För detta tog vi parkettformatet med kompression
- Det är mycket viktigt att dela filer i mappar som: språk, år, månad, dag, vecka. Motorer som förstår denna typ av skärning kommer bara att titta på de nödvändiga mapparna, utan att sålla igenom all data i rad.
I huvudsak, på detta sätt, lägger du ut källdata i den mest effektiva formen för de analytiska motorerna som hängde ovanpå, som även i sönderdelade mappar kan selektivt gå in och läsa endast de nödvändiga kolumnerna från filer. Du behöver inte "fylla upp" data någonstans (lagringen kommer helt enkelt att spricka) - bara omedelbart sätt in den i filsystemet i rätt format. Naturligtvis bör det stå klart här att det inte är särskilt lämpligt att lagra en enorm csv-fil i DataLake, som först måste läsas rad för rad av klustret för att extrahera kolumnerna. Tänk på ovanstående två punkter igen om det ännu inte är klart varför allt detta händer.
AWS Athena - jack-in-the-boxen
Och sedan, när vi skapade en sjö, kom vi på något sätt av misstag över Amazon Athena. Plötsligt visade det sig att genom att noggrant ordna upp våra enorma loggfiler i mappskärvor i rätt (parkett)kolumnformat, så kan man väldigt snabbt göra extremt informativa val från dem och bygga rapporter UTAN, utan ett Apache Spark/Glue-kluster.
Athena-motorn som drivs av data i s3 är baserad på den legendariska - en representant för MPP-familjen (massiv parallell bearbetning) av tillvägagångssätt för databehandling, som tar data där den ligger, från s3 och Hadoop till Cassandra och vanliga textfiler. Du behöver bara be Athena att köra en SQL-fråga, och sedan fungerar allt snabbt och automatiskt. Det är viktigt att notera att Athena är "smart", den går bara till de nödvändiga delade mappar och läser endast de kolumner som behövs i begäran.
Prissättningen för förfrågningar till Athena är också intressant. Vi betalar för . De där. inte för antalet maskiner i klustret per minut, utan... för de data som faktiskt skannas på 100-500 maskiner, endast de data som behövs för att slutföra begäran.
Och genom att bara begära de nödvändiga kolumnerna från korrekt klippta mappar, visade det sig att Athena-tjänsten kostar oss tiotals dollar i månaden. Bra, nästan gratis, jämfört med analyser på kluster!
Förresten, så här delar vi våra data i s3:
Som ett resultat, på kort tid, började helt olika avdelningar i företaget, från informationssäkerhet till analys, aktivt göra förfrågningar till Athena och snabbt, på några sekunder, få användbara svar från "big" data under ganska långa perioder: månader, ett halvår osv. P.
Men vi gick längre och började gå till molnet för att få svar : en analytiker skriver en SQL-fråga i en bekant konsol, som på 100-500 maskiner "för pennies" skickar data till s3 och returnerar ett svar vanligtvis inom några sekunder. Bekväm. Och snabbt. Jag kan fortfarande inte tro det.
Som ett resultat, efter att ha beslutat att lagra data i s3, i ett effektivt kolumnformat och med rimlig delning av data till mappar... fick vi DataLake och en snabb och billig analysmotor - gratis. Och han blev väldigt populär i företaget, eftersom... förstår SQL och arbetar i storleksordningar snabbare än genom att starta/stoppa/sätta upp kluster. "Och om resultatet är detsamma, varför betala mer?"
En förfrågan till Athena ser ut ungefär så här. Om så önskas kan du naturligtvis bilda tillräckligt , men vi kommer att begränsa oss till enkel gruppering. Låt oss se vilka svarskoder klienten hade för några veckor sedan i webbserverloggarna och se till att det inte finns några fel:
Resultat
Efter att ha gått igenom, för att inte säga en lång, men smärtsam väg, och ständigt adekvat bedömt riskerna och komplexiteten och kostnaden för support, hittade vi en lösning för DataLake och analys som aldrig slutar att tillfredsställa oss med både hastighet och ägandekostnad.
Det visade sig att att bygga ett effektivt, snabbt och billigt att driva DataLake för behoven hos helt olika avdelningar inom företaget ligger helt inom kapaciteten för även erfarna utvecklare som aldrig har arbetat som arkitekter och inte vet hur man ritar rutor på rutor med pilar och känner till 50 termer från Hadoop-ekosystemet.
I början av resan splittrades mitt huvud från de många vilda djurparkerna med öppen och stängd mjukvara och förståelsen av ansvarsbördan för ättlingar. Börja bara bygga din DataLake från enkla verktyg: nagios/munin -> elastic/kibana -> Hadoop/Spark/s3..., samla in feedback och djup förståelse av fysiken i de processer som äger rum. Allt komplext och grumligt - ge det till fiender och konkurrenter.
Om du inte vill gå till molnet och gillar att stödja, uppdatera och korrigera projekt med öppen källkod, kan du bygga ett schema som liknar vårt lokalt, på billiga kontorsmaskiner med Hadoop och Presto ovanpå. Det viktigaste är att inte stanna och gå framåt, räkna, leta efter enkla och tydliga lösningar, och allt kommer definitivt att lösa sig! Lycka till alla och vi ses igen!
Källa: will.com