Ci troviamo in un periodo straordinario, in cui è possibile mettere insieme rapidamente e facilmente diversi strumenti open-source già pronti, configurarli senza pensarci troppo, seguendo i consigli di stackoverflow, senza addentrarsi in complicate terminologie, e avviarli in un utilizzo commerciale. E quando sarà necessario aggiornarsi o espandersi, o qualcuno riavvierà accidentalmente alcune macchine, ci si renderà conto che è iniziato un incubo sgradevole, tutto è diventato all'improvviso complicato e irriconoscibile, non c'è via di ritorno, il futuro è nebuloso e più sicuro sarà allevare api e produrre formaggio invece di programmare.
Non per nulla, colleghi più esperti, con capelli grigi e pieni di bug, osservando l'incredibile e veloce distribuzione di pacchetti di "container" in "cubi" su decine di server utilizzando "linguaggi trendy" con supporto integrato per l'I/O asincrono non bloccante, sorridono modestamente. E silenziosamente continuano a leggere "man ps", analizzano fino a sanguinare gli occhi i sorgenti di "nginx" e scrivono, scrivono, scrivono unit test. Sanno che il bello deve ancora venire, quando "tutto questo" un giorno diventerà un incubo sotto il Capodanno. E solo una profonda comprensione della natura di Unix, la tabella degli stati TCP/IP memorizzata e i principali algoritmi di ordinamento-ricerca li aiuteranno a riportare il sistema in vita allo scoccare della mezzanotte.
Ah già, mi sono distratto un po', ma spero di essere riuscito a trasmettere il senso di attesa.
Oggi voglio condividere la nostra esperienza nella distribuzione di uno stack conveniente e pratico per il DataLake, in grado di risolvere la maggior parte delle problematiche analitiche in azienda per le diverse divisioni.
Tempo fa, ci siamo resi conto che le aziende hanno sempre più bisogno dei risultati sia dell'analisi di prodotto che di quella tecnica (per non parlare delle ciliegine sulla torta come il machine learning) e per comprendere tendenze e rischi, è necessario raccogliere e analizzare sempre più metriche.
Analisi tecnica di base in "Bitrix24"
Qualche anno fa, insieme al lancio del servizio "Bitrix24", abbiamo investito attivamente tempo e risorse nella creazione di una piattaforma analitica semplice e affidabile che aiutasse a identificare rapidamente i problemi nell'infrastruttura e a pianificare i passi successivi. Naturalmente, si voleva utilizzare strumenti già pronti, semplici e comprensibili. Alla fine, abbiamo scelto nagios per il monitoraggio e munin per l'analisi e la visualizzazione. Ora abbiamo migliaia di controlli in nagios, centinaia di grafici in munin e i colleghi li usano quotidianamente con successo. Le metriche sono chiare, i grafici sono comprensibili, il sistema funziona in modo affidabile da diversi anni e vengono regolarmente aggiunti nuovi test e grafici: quando introduciamo un nuovo servizio, aggiungiamo alcuni test e grafici. Buon viaggio.
Tenere il polso della situazione - analisi tecnica avanzata
Il desiderio di ricevere informazioni sui problemi "il più rapidamente possibile" ci ha portato a sperimentare attivamente con strumenti semplici e comprensibili - pinba e xhprof.
Pinba ci inviava in pacchetti UDP statistiche sulla velocità delle parti delle pagine web in PHP, e potevamo vedere in tempo reale in un'archiviazione MySQL (pinba ha il proprio motore MySQL per un'analisi rapida degli eventi) una lista di problemi e reagire a essi. Xhprof, in modo automatico, consentiva di raccogliere i grafi di esecuzione delle pagine PHP più lente dai clienti e analizzare cosa potesse aver causato il problema - tranquillamente, sorseggiando tè o qualcosa di più forte.
Tempo fa, il nostro strumento si è arricchito di un altro motore piuttosto semplice e comprensibile basato sull'algoritmo di indicizzazione inversa, splendidamente implementato nella leggendaria libreria Lucene - Elastic/Kibana. L'idea di base della registrazione multithreaded dei documenti nell'indice inverso di Lucene basato sugli eventi nei log e la ricerca rapida in essi tramite suddivisione a facce si è rivelata, davvero, utile.
Nonostante l'aspetto piuttosto tecnico delle visualizzazioni in Kibana con concetti low-level come "bucket" che spuntano verso l'alto e un linguaggio reinventato non completamente dimenticato dell'algebra relazionale, lo strumento ci ha dimostrato di essere molto utile nelle seguenti mansioni:
- Quante erano le errori PHP sul portale di Bitrix24 p1 nell'ultima ora e quali? Comprendere, perdonare e sistemare rapidamente.
- Quanti videochiamate sono state effettuate sui portali in Germania nelle ultime 24 ore, con quale qualità e ci sono stati problemi con il canale/rete?
- Quanto bene funziona la funzionalità di sistema (il nostro plugin in C per PHP), compilato dai sorgenti nell'ultimo aggiornamento del servizio e distribuito ai clienti? Ci sono segfault?
- I dati dei clienti vengono memorizzati nella memoria PHP? Ci sono errori di superamento della memoria allocata dal processo: «out of memory»? Identificare e risolvere.
Ecco un esempio concreto. Nonostante test approfonditi e multilivello, il cliente ha riscontrato un errore fastidioso e inaspettato in un caso estremamente non standard con dati di input danneggiati; è suonata una sirena e ha avuto inizio il processo di correzione rapida:
Inoltre, Kibana consente di organizzare avvisi per eventi specifici, e in breve tempo lo strumento è stato utilizzato da decine di dipendenti di diversi reparti, dal supporto tecnico e sviluppo a QA.
L'attività di qualsiasi reparto all'interno dell'azienda è diventata facile da monitorare e misurare: invece di un'analisi manuale dei log sui server, è sufficiente configurare una volta il parsing dei log e l'invio nel cluster Elastic, per godere, ad esempio, della visualizzazione nel dashboard di Kibana del numero di gattini a due teste stampati in 3D nel mese lunare scorso.
Analisi aziendale di base
Tutti sanno che spesso l'analisi aziendale nelle aziende inizia con l'uso estremamente attivo di Excel, sì, sì. Ma, cosa più importante, non deve finire lì. Inoltre, Google Analytics in cloud contribuisce a rendere le cose più semplici; ci si abitua rapidamente al buono.
Nella nostra azienda, in armoniosa crescita, sono cominciati a comparire qua e là dei 'profeti' che spingevano per un lavoro più intenso con dati più complessi. Si sono presentate regolarmente esigenze per rapporti più approfonditi e completi e con gli sforzi dei ragazzi di diversi reparti, tempo fa è stata organizzata una soluzione semplice e pratica: l'integrazione di ClickHouse e PowerBI.
Per un lungo periodo, questa soluzione flessibile ha funzionato molto bene, ma lentamente ci siamo resi conto che ClickHouse non è infinito, e non si può abusarne.
È importante capire che ClickHouse, come Druid, Vertica e Amazon RedShift (basato su Postgres), è un motore analitico ottimizzato per analisi piuttosto veloci (somme, aggregazioni, minimi e massimi su colonne e un po' di join), poiché è progettato per immagazzinare in modo efficiente colonne di tabelle relazionali, a differenza dei famosi database MySQL e altri (row-oriented).
In sostanza, ClickHouse è solo un «database» più capiente, con un'inserzione puntuale non molto comoda (è progettato in questo modo, va bene), ma con un'analisi piacevole e un insieme di potenti funzioni per lavorare con i dati. Sì, è possibile persino creare un cluster — ma capite che usare un microscopio per battere chiodi non è esattamente corretto, e abbiamo cominciato a cercare altre soluzioni.
Domanda di Python e analisti
Nella nostra azienda ci sono molti sviluppatori che scrivono codice praticamente ogni giorno da 10 a 20 anni in PHP, JavaScript, C#, C/C++, Java, Go, Rust, Python, Bash. Ci sono anche molti esperti amministratori di sistema che hanno vissuto non una ma molte catastrofi incredibili che non si inseriscono nelle leggi della statistica (ad esempio, quando la maggior parte dei dischi in raid-10 vengono distrutti da un forte fulmine). In tali condizioni, a lungo non è stato chiaro cosa intendere per 'analista in Python'. Python è simile a PHP, solo con un nome leggermente più lungo e con meno tracce di sostanze che alterano la coscienza nel codice sorgente dell'interprete. Tuttavia, con la creazione di sempre nuovi report analitici, gli sviluppatori esperti hanno cominciato a rendersi conto dell'importanza di specializzarsi in strumenti come numpy, pandas, matplotlib e seaborn.
La parola decisiva è stata probabilmente l'improvviso svenimento dei dipendenti all'udire la combinazione di parole 'regressione logistica' e la dimostrazione della costruzione efficace di report su dati voluminosi usando, sì sì, pyspark.
Apache Spark, la sua paradigma funzionale, si adatta perfettamente all'algebra relazionale e ha impressionato così tanto gli sviluppatori abituati a MySQL che è diventato chiaro, come il giorno, che c'era bisogno di rafforzare le fila con esperti analisti.
I successivi tentativi di Apache Spark/Hadoop di decollare e ciò che non è andato secondo programma.
Tuttavia, ben presto è diventato chiaro che con Spark forse c'era qualcosa di sistemico che non andava o semplicemente bisognava lavarsi le mani meglio. Se il stack Hadoop/MapReduce/Lucene era stato realizzato da programmatori abbastanza esperti, il che è evidente se si osservano con attenzione le fonti in Java o le idee di Doug Cutting in Lucene, Spark, improvvisamente, è stato scritto in un linguaggio molto controverso dal punto di vista pratico e attualmente non in sviluppo, Scala. La caduta regolare dei calcoli nel cluster Spark a causa di un lavoro non logico e poco trasparente nella gestione della memoria durante le operazioni di reduce (arrivano subito molte chiavi) ha creato intorno ad esso un'aura di qualcosa che ha ampio margine di crescita. Inoltre, la situazione era aggravata dalla grande quantità di porte aperte strane, file temporanei in crescita nei luoghi più incomprensibili e un'infinità di dipendenze jar, il che suscitava negli amministratori di sistema una familiarità ben nota sin dall'infanzia: un'acerba avversione (o forse dovevamo semplicemente lavarci le mani con sapone).
Alla fine, abbiamo "sopportato" diversi progetti analitici interni che utilizzavano attivamente Apache Spark (incluso Spark Streaming e Spark SQL) e l'ecosistema Hadoop (e altro ancora). Anche se col tempo abbiamo imparato a "prepararlo" e monitorarlo decentemente e "esso" ha praticamente smesso di cadere improvvisamente a causa del cambiamento nella natura dei dati e del disequilibrio nell'hashing uniforme degli RDD, il desiderio di utilizzare qualcosa di già pronto, aggiornato e amministrato da qualche parte nel cloud cresceva sempre di più. Proprio in quel momento abbiamo provato a utilizzare una costruzione cloud pronta di Amazon Web Services — e, successivamente, abbiamo cercato di risolvere i compiti già su di essa. EMR è una variante di Apache Spark preparata da Amazon con software aggiuntivo dall'ecosistema, simile ai pacchetti Cloudera/Hortonworks.
Uno storage "flessibile" per l'analisi è un'esigenza acuta.
L'esperienza di "preparare" Hadoop/Spark con scottature su varie parti del corpo non è stata vana. È stata sempre più evidente la necessità di creare un'unica soluzione di storage economica e affidabile, resistente a guasti hardware, in cui poter conservare file in vari formati da diversi sistemi e effettuare selezioni sui dati in modo efficace e in tempi ragionevoli per la reportistica.
Inoltre, si desiderava che l'aggiornamento del software di questa piattaforma non si trasformasse in un incubo notturno di Capodanno, con la lettura di tracce Java lunghe 20 pagine e l'analisi di chilometri di dettagli dei log di funzionamento del cluster tramite Spark History Server e una lente di ingrandimento. Si voleva avere uno strumento semplice e trasparente che non richiedesse regolari immersioni sotto il cofano, se lo sviluppatore smetteva di eseguire una richiesta standard di MapReduce a causa della perdita di dati reduce dalla memoria del worker a seguito di un algoritmo di partizionamento poco fortunato.
Amazon S3 — candidato per DataLake?
L'esperienza con Hadoop/MapReduce ci ha insegnato che è necessaria sia una filesystem affidabile e scalabile sia worker scalabili che "si avvicinano" ai dati, per non dover trasmettere dati attraverso la rete. I worker devono essere in grado di leggere dati in vari formati ma, preferibilmente, senza leggere informazioni superflue e con la possibilità di memorizzare preventivamente i dati in formati comodi per i worker.
Ancora una volta — l'idea principale. Non c'è voglia di "caricare" grandi dati in un unico motore analitico clusterizzato, che prima o poi si affogherà e sarà necessario shardarlo in modo poco bello. Si desidera conservare file, semplici file, in un formato comprensibile e svolgere su di essi analisi efficaci con strumenti diversi ma comprensibili. E il numero di file in vari formati aumenterà sempre di più. E sarebbe meglio shardare i dati sorgente piuttosto che il motore. Abbiamo deciso che ci serviva un DataLake espandibile e universale…
E se conservassimo i file in un noto e scalabile storage cloud di Amazon S3, senza doverci occupare della preparazione manuale di Hadoop?
Chiaramente, i dati personali "non possono" essere gestiti in questo modo, ma per gli altri dati, se vengono estratti e "trattati in modo efficace"?
L'ecosistema di analisi dati clusterizzata di Amazon Web Services — con parole molto semplici.
A giudicare dalla nostra esperienza con AWS, Apache Hadoop/MapReduce viene utilizzato da tempo e attivamente sotto diverse forme, ad esempio nel servizio DataPipeline (invidio i colleghi, hanno imparato a prepararlo correttamente). Qui abbiamo impostato backup da diversi servizi da tabelle DynamoDB:
E vengono eseguiti regolarmente su cluster incorporati Hadoop/MapReduce come un orologio da anni. "Impostato e dimenticato":
Inoltre, è possibile impegnarsi efficacemente nel data satanism, attivando i notebook Jupyter per gli analisti nel cloud e usando il servizio AWS SageMaker per l'addestramento e il deploy di modelli AI. Ecco come appare per noi:
E sì, è possibile sollevare un laptop nel cloud o analitica e collegarlo a un cluster Hadoop/Spark, eseguire calcoli e poi "fermarlo":
È davvero comodo per progetti analitici specifici e per alcuni di essi abbiamo utilizzato con successo il servizio EMR per calcoli su larga scala e analisi. E riguardo a una soluzione sistemica per DataLake, sarà possibile? In quel momento eravamo sul confine tra speranza e disperazione e continuavamo la ricerca.
AWS Glue è un Apache Spark "potenziato"
Si è scoperto che AWS ha una propria versione dello stack "Hive/Pig/Spark". Il ruolo di Hive, ovvero il catalogo dei file e dei loro tipi nel DataLake, è svolto dal servizio "Data catalog", che non nasconde la sua compatibilità con il formato Apache Hive. In questo servizio è necessario aggiungere informazioni su dove si trovano i file e in quale formato. I dati possono trovarsi non solo in s3, ma anche in un database, ma di questo non parleremo in questo post. Ecco come è organizzato il catalogo dei dati DataLake per noi:
I file sono registrati, ottimo. Se i file vengono aggiornati, avviamo manualmente o secondo un programma crawler che aggiorna le informazioni su di essi dal lago e le conserva. Successivamente, i dati dal lago possono essere elaborati e i risultati esportati. Nel caso più semplice, esportiamo anche in s3. I dati possono essere elaborati in qualsiasi luogo, ma è consigliato configurare il processo di elaborazione su un cluster Apache Spark sfruttando le funzionalità avanzate tramite l'API AWS Glue. Fondamentalmente, è possibile prendere il vecchio e familiare codice Python utilizzando la libreria pyspark e configurarne l'esecuzione su N nodi di un cluster di una certa potenza con monitoraggio, senza scavare nelle viscere di Hadoop e trascinare contenitori Docker e risolvere conflitti di dipendenze.
Ripeto: è un'idea semplice. Non è necessario configurare Apache Spark, basta scrivere codice in Python per pyspark, testarlo localmente sul desktop e poi eseguirlo su un grande cluster nel cloud, specificando dove si trovano i dati sorgente e dove mettere il risultato. A volte è necessario e utile ecco come è configurato da noi:
Quindi, se è necessario eseguire calcoli su un cluster Spark utilizzando dati in s3, scriviamo codice in Python/pyspark, testiamo e via nel cloud.
E per quanto riguarda l'orchestrazione? E se il compito fallisce e scompare? Sì, si propone di realizzare un bel pipeline in stile Apache Pig e persino abbiamo provato, ma abbiamo deciso di utilizzare per ora la nostra orchestrazione profondamente personalizzata in PHP e JavaScript (capisco che sorge un dissonanza cognitiva, ma funziona da anni senza errori).
Il formato dei file memorizzati nel lago è la chiave per le prestazioni
È molto, molto importante capire ancora due punti chiave. Affinché le query sui dati dei file nel lago vengano eseguite il più rapidamente possibile e che le prestazioni non degradino all'aggiunta di nuove informazioni, è necessario:
- Conservare le colonne dei file separatamente (per non dover leggere tutte le righe per capire cosa c'è nelle colonne). Per questo abbiamo scelto il formato parquet con compressione.
- È molto importante suddividere i file in cartelle secondo il principio: lingua, anno, mese, giorno, settimana. I motori incapaci di comprendere questo tipo di sharding esamineranno solo le cartelle necessarie, senza passare a setacciarli tutti in una volta.
In sostanza, in questo modo si forniscono i dati di origine nel modo più efficiente possibile per i motori analitici sovrapposti, i quali sanno come accedere in modo selettivo alle cartelle sharded e leggere solo le colonne necessarie dai file. Non è necessario "caricare" i dati da nessuna parte (il repository semplicemente esploderà) - basta semplicemente metterli in modo saggio nel file system nel formato corretto. Naturalmente, qui deve essere chiaro che memorizzare un enorme file csv in DataLake, che deve essere prima letto completamente riga per riga dal cluster per estrarre le colonne, non è molto funzionale. Riconsiderate i due punti sopra se non è ancora chiaro perché tutto ciò.
AWS Athena - un "diavolo" apparso all'improvviso
Ed ecco, creando un lago, abbiamo, in un certo senso, incappato in Amazon Athena. È emerso inaspettatamente che, disponendo con cura i nostri file di enormi log per sharding in un formato colonnare corretto (parquet), era possibile eseguire selezioni estremamente informative e generare rapporti in modo molto rapido SENZA, senza un cluster Apache Spark/Glue.
Il motore Athena, che lavora con dati in s3, è basato sul leggendario rappresentante della famiglia MPP (massive parallel processing) degli approcci al trattamento dei dati, che preleva i dati dove si trovano, da s3 e Hadoop a Cassandra e normali file di testo. Basta chiedere ad Athena di eseguire una query SQL, e tutto il resto "funziona rapidamente e da solo". È importante notare che Athena è "intelligente", accede solo alle cartelle sharded necessarie e legge solo le colonne richieste nella query.
Le richieste a Athena sono interessanti anche dal punto di vista della tariffazione. Paghiamo per . Cioè, non in base al numero di macchine nel cluster al minuto, ma… per i dati realmente analizzati su 100-500 macchine, solo quelli necessari per completare la richiesta.
Richiedendo solo le colonne necessarie dalle cartelle correttamente sharded, abbiamo scoperto che il servizio Athena ci costa solo decine di dollari al mese. È fantastico, quasi gratuito, rispetto all'analisi nei cluster!
Ecco come shardiamo i nostri dati in s3:
Di conseguenza, in breve tempo, diversi reparti dell'azienda, dalla sicurezza informatica all'analisi, hanno iniziato a fare richieste ad Athena e a ricevere risposte utili dai 'big data' in pochi secondi su periodi piuttosto lunghi: mesi, semestri, ecc.
Ma abbiamo deciso di andare oltre e cercare risposte nel cloud : l'analista, nella console abituale, scrive una query SQL che 'per pochi centesimi' analizza i dati in s3 su 100-500 macchine e restituisce la risposta solitamente in pochi secondi. Comodo. E veloce. È difficile da credere fino ad ora.
Di conseguenza, decidendo di conservare i dati in s3, in un formato di colonna efficiente e con uno shard ragionevole dei dati per le cartelle… abbiamo ottenuto un DataLake e un motore analitico veloce e a basso costo — gratuitamente. È diventato molto popolare in azienda, poiché comprende SQL e lavora molto più velocemente rispetto ai lanci/arresti/configurazioni dei cluster. 'Se il risultato è lo stesso, perché pagare di più?'
Una richiesta a Athena appare più o meno così. Se lo desideri, naturalmente, puoi formare una richiesta SQL piuttosto , ma ci limiteremo a una semplice aggregazione. Controlliamo quali codici di risposta ha avuto il cliente alcune settimane fa nei log del server web e assicuriamoci che non ci siano errori:
Conclusioni
Dopo aver percorso un cammino non dicasi lungo, ma doloroso, valutando costantemente i rischi e il livello di complessità e il costo del supporto, abbiamo trovato una soluzione per DataLake e analisi che continua a sorprenderci per velocità e costo di gestione.
Si è rivelato che costruire un DataLake efficace, veloce e a basso costo per le esigenze di reparti completamente diversi dell'azienda è fattibile anche per sviluppatori esperti che non hanno mai lavorato come architetti e non sanno disegnare quadrati con quadrati e frecce e non conoscono 50 termini dell'ecosistema Hadoop.
All'inizio, la testa scoppiava per la moltitudine di software open e closed di zootecnia e per la comprensione del carico di responsabilità verso le generazioni future. Inizia semplicemente a costruire il tuo DataLake con strumenti semplici: nagios/munin -> elastic/kibana -> Hadoop/Spark/s3…, raccogliendo feedback e comprendendo profondamente la fisica dei processi in corso. Tutto ciò che è complesso e confuso — lascialo agli avversari e ai concorrenti.
Se non vuoi andare nel cloud e ami mantenere, aggiornare e patchare progetti open, puoi costruire un schema simile al nostro a livello locale, su macchine economiche d'ufficio con Hadoop e Presto sopra. L'importante è non fermarsi e andare avanti, cercare soluzioni semplici e chiare e tutto andrà bene! Buona fortuna a tutti e ci vediamo!
Fonte: habr.com
