grazie ciao così ciao vieni di nuovo dentro
questo discorso andremo a illustrare il
evoluzione di Hadoop a 45 anni indipendentemente
del motivo per cui sei qui e forse
sei qui perché hai il tuo
Cluster o forse si vuole costruire la vostra
nuovo cluster o forse vuoi solo
impara bene Hadoop, speriamo
questo discorso ci sarà utile per
voi, perché abbiamo intenzione di portare con
esempi reali di incidenti e
problemi e bug che abbiamo avuto e come noi
affrontali a spotify ma per favore mantienili
in mente però che ogni singolo cluster
è diverso quindi cosa può non funzionare per noi
lavoro per te ma speriamo che la prossima volta
vedi un problema simile che puoi fare
questa conoscenza e rendere più guidati dai dati
decisione sui tuoi problemi prima di noi
immergiti nei dettagli anche se prima di tutto
presentarci quindi sono rafal e
questo è josh schivare il proprietario del prodotto e
Sono un ingegnere di tutta la squadra Hadoop e
entrambi ci innamoriamo di Hadoop
circa due anni fa quando ci trasferiamo nella nostra
bellissimo ufficio di Stoccolma e noi
iniziato a sostenere questo uno dei
i maggiori cluster di Hadoop in Europa e
era una grande responsabilità ma anche
grande privilegio così ora che tu
sai chi sei diamo un’occhiata a
l’agenda del discorso così prima di tutto
andando a parlare delle questioni il dolore
indica come stavamo cercando di mantenere il nostro
cluster in funzione e poi ci guadagneremo
messa a fuoco stabilizzerà il cluster e
poi alla fine lo finiremo duro
con il futuro e le nostre caratteristiche attuali
della nostra infrastruttura quindi diamo
è partito sicuro per cominciare, dice
menzione di Rafal che inizieremo
parlando dell’inizio dei big data
a individuare quando abbiamo iniziato con
Hadoop ma prima di farlo lo siamo
intenzione di tornare indietro di un secondo e parlare
su cosa sia Spotify, mi rendo conto che è così
probabilmente abbastanza conosciuto in
Scandinavia, ma nel caso lo fossimo
tutto nella stessa pagina Spotify è una musica
servizio di streaming alcune persone pensano di
è come iTunes sul cloud è tutto
è stato lanciato nel 2008 ce ne sono due principali
livelli di livello gratuito e un livello premium
questo costa circa 10 anni al mese
dà pieno accesso a tutti i nostri cataloghi
di canzoni è disponibile in 58 paesi
Ho appena visto oltre 48 di quelli
paesi diritti
flusso medio oltre 1 milione di stream
al giorno alcuni numeri mensili che abbiamo
oltre 75 milioni di utenti attivi mensilmente
quegli utenti chat scelgono da un catalogo
di oltre 30 milioni di canzoni oltre 4 milioni
artisti e si combinano per giocare
1 milione di flussi ogni giorno, quindi questo è un
molti dati e perché è molto
dati abbiamo dati piuttosto massicci
infrastruttura per elaborare su di esso noi
appena aggiornato abbiamo aggiunto altri tre o
quattrocento nodi ci siamo alzati in giro
1.700 nodi pensiamo che siamo probabilmente il
il più grande cluster Hadoop in Europa se
non ci piacerebbe sapere quanto è grande
il tuo cluster Hadoop è 62
petabyte di storage superiamo i 30
terabyte di log in arrivo ogni giorno
generato dagli utenti eseguiamo circa 20.000
Hadoop lavori al giorno e quei lavori
generare oltre 400 terabyte di dati così
ci sono molti dati che potresti essere
chiedendo cosa facciamo con tutti quei dati
ora fammi fare una domanda molto veloce è
c’è qualcuno qui che è un corridore
va bene se Spotify sei fortunato
qualche mese fa abbiamo rilasciato questo nuovo
applicazione una nuova funzionalità all’interno del
applicazione che è un’app in esecuzione e
ciò che è veramente interessante è questo
ti dà una lista suonata personalizzata basata fuori
il tuo tempio in corsa l’abbiamo trovato
in realtà correndo con un battito quando sei
a ritmo con la cadenza migliora
prestazioni fino al quindici percento
e ciò che è veramente grande è che noi
unisci le tue abitudini di ascolto al tuo
abitudini di ascolto personale e il
caratteristiche di tutte le canzoni che
ti piace ascoltare cose come la
l’umore e l’energia insieme alle canzoni
essere autorizzati a generare un mucchio di a
diverse playlist di esecuzione personalizzate
familiare in musica interessante ad ogni
battere al minuto per tutti i nostri utenti attivi
un’altra caratteristica che abbiamo di recente
lanciato che potresti avere familiarità con
se gli utenti di Spotify chiamano discovery
settimanalmente sono due ore di personalizzazione
musica consigliata consegnata ogni lunedì
per tutti i nostri 75 milioni attivi mensilmente
utenti e questo è stato davvero uno dei
le nostre funzionalità di maggior successo che abbiamo
mai lanciato ogni lunedì otteniamo a
flurry di nuove attività come Twitter
che dicono quanto è grande la loro playlist
settimana e quanto meglio era il migliore o
se siamo in ritardo con i dati otteniamo a
un sacco di lamentele su Twitter su come
la loro playlist non è ancora lì così noi
sappi che è davvero importante per il nostro
gli utenti dietro le quinte è in esecuzione a
varietà di machine learning differenti
tecniche che si basano tutte su
caratteristiche estratte dai dati questi
le funzionalità sono piuttosto interessanti ma prima di noi
tuffarsi in loro il suo primo dare un’occhiata a
uno molto semplice quindi questa è una lista in alto
per la Danimarca le 50 migliori canzoni di te
gli utenti stanno ascoltando in Danimarca così
prendiamo, passiamo due secondi e
pensa a come faresti fondamentalmente
implementare questa funzione, quindi se pensi
su di esso il più semplice il più bruto
la soluzione di forza sarà probabilmente troppo giusta
piace lanciare questi dati nel database
e quindi eseguire una query semplice come questa
uno qui in modo da selezionare qualche traccia
ID di alcuni artisti che hai conteggiato
addio hai un limite che hai crogiolato
hai la tua caratteristica proprio carina
semplice il problema è che non appena
si inizia a ottenere questa quantità di dati
di cui parlava Josh ricorda 30
terabyte di dati al giorno che abbiamo
ingerire quindi che inizia ad essere un
problema fondamentalmente quindi sapevamo da subito
l’inizio molto all’inizio che noi
bisogno di qualcosa che scalerà meglio
con la nostra scala della quantità di dati
che stiamo ricevendo e anche i tablas
solo un tipo di rapporto che dobbiamo
creare molti rapporti diversi di
quei diversi calcoli che noi
dobbiamo fare sui dati quindi dobbiamo essere
flessibile quando si tratta del tipo di
i calcoli che stiamo facendo e il terzo
motivo per cui riceviamo dati diversi da
diverse fonti in un altro
struttura quindi dobbiamo essere flessibili
sui dati e la struttura di esso
abbiamo basato qualcosa come Hadoop e
è per questo che abbiamo iniziato a giocare con a
nel 2009, quindi molto molto lo sai molto
all’inizio della vita di Hadoop e
abbiamo avuto un paio di informazioni a riguardo
fin dall’inizio così fondamentalmente ora noi
sappi che è abbastanza scalabile
bene e poi è flessibile e quando lo fa
arriva a che tipo di usura ti segna
voler eseguire su di esso e anche del
in realtà è un intreccio con il preside
flessibile e arriva a quale candidato I
voglio conservarci sopra ma poi c’è stato
anche un altro risultato interessante che è
Lo streaming Hadoop e lo streaming Hadoop lo sono
una caratteristica di Hadoop che ti permette di
implementare lavori MapReduce in una lingua
diverso da Java
e quello era importante per lei
Spotify perché Spotify era allora a
grande negozio di Python che ci permette di
prendere questa vasta conoscenza di Python
e mettilo sopra Hadoop e poi noi
iniziato a implementare questo è intensivo
pipeline usando Python e fondamentalmente noi
ho un sacco di informazioni e dati e questo
ci consente di prendere decisioni basate sui dati
e fare di Spotify un tale successo
è oggi ma ad essere sincero mi manca
un pezzo importante della storia che sono
dicendo che sì puoi scrivere questi
condutture e puoi farlo dentro
e puoi fare molte conoscenze ma
primo problema che probabilmente stai andando
ottenere è come spostare i dati su Hadoop
quindi sembra un semplice problema
beh, lo sappiamo solo memorizzarlo su HDFS
questa è la soluzione semplice, ma è così
in realtà non è così facile, prendiamoci un
guarda questo problema da Spotify sper
spettivo quindi a individuare questo abbiamo
nozione di punti di accesso che sono
macchine a cui tutti i client si connettono
quindi ogni volta che apri il tuo cliente e
vuoi richiedere la playlist o
qualsiasi cosa vogliate averne
servizio di back-end si passa attraverso il
punto di accesso e ogni volta che si richiede
qualcosa dall’accesso per un accesso
il punto lo registrerà su quello specifico
macchina in un formato separato da tabulazioni e
per questo è tutto
introduce un sacco di un tipo specifico di
problemi così il primo è che i dati
è abbastanza crudo e sporco, quindi dobbiamo
assicurati che le nostre pipeline ETA siano
solido e quello che ci assicuriamo
ogni singolo disco è pulito e quello
in realtà non è così semplice
valori celebrati un’altra cosa se tu
avere un valore separato da tab bene
l’evoluzione dello schema non è così semplice e
è specificamente difficile da individuare
perché abbiamo un sacco di piccoli team e
se vuoi cambiare qualcosa nel
struttura se si desidera aggiungere un campo o
rimuovi bene il campo devi parlare
a molte squadre diverse e non lo è
non comune per una squadra cambiare qualcosa
senza parlare con nessuno e poi tu
conoscilo solo avendo un
incidente a valle nella pipeline così
questo è un altro problema, c’è un altro set
di problemi e avrò perché noi
avere un cluster rigido solo un giorno
centro a Londra dobbiamo spostare tutto il
dati in un unico posto a Londra e
che introduce nei problemi con
networking e cosa succede se ci f
un duplicato di dati che dobbiamo duplicare
più tardi, così avanti
quindi dato il problema e abbiamo iniziato oh
c’è anche un altro problema importante
a spotify trattiamo molto bene i nostri log
con attenzione e dovremmo essere sicuri
che li prendiamo tutti perché trattiamo
loro come le transazioni finanziarie perché
dobbiamo ripagare i nostri artisti e
assicurarsi che siano soddisfatti
individuare così i registri sono super importanti per
noi così con quel problema che abbiamo implementato
la nostra prima iterazione che era log
archiviatore e quella soluzione in realtà
è durato molto a lungo in modo che l’acido sociale
dal 2009 2013 e rimarrai sorpreso
perché era molto banale, era solo
un insieme di script Python che lo faranno
in pratica comprimi i log e poi lo sono
dicendo o file SCP tra macchine tutto
il modo di aggiungere al data center di Londra
e che i lavori saranno sostanzialmente incoronati
e fondamentalmente aveva un sacco di problemi e
che tipo di problemi bene perché lo era
affogato e perché era banale
serie annuale di script Python che vorresti
fallire molto non era corretto
il monitoraggio non c’era avviso adeguato
quindi ogni volta c’era un problema nostro
i motori dovrebbero andare a uno specifico
i file SCP del data center manualmente tutti i
modo di aggiungere a Londra e assicurarsi che
tutti i log ci sono e se dovessimo
scala i nostri punti di accesso che dovevamo aggiungere
più macchine o dobbiamo rimuovere un
punto di accesso che sarebbe un altro
lavoro manuale e manuale per i nostri ingegneri
è stato un enorme magnifico fallimento ma
anche prima di bruciarlo era troppo
Devo anche introdurre una parte importante
della cultura di Spotify e questo è meglio
riassunti da due parole abbracciano il fallimento
questo è abbastanza semplice quando
stai fallendo stai imparando molto
stai imparando molto di più di se
sei molto conservatore e
muoversi lentamente e avere paura di fallire così
nel caso del log archiver, in realtà
imparato molto abbiamo imparato molto
cosa non fare con la consegna del registro per
esempio non lo fai contare su cron
se vuoi espandere i tuoi nodi e
scala in tutto il mondo
fallimenti e apprendimento o apprendimento
guidato la nostra prossima generazione di log
consegna che abbiamo costruito in cima a Kafka
ora lascia che ti chieda un’altra domanda
in nessuno c’è qualcuno che usa Kafka
il loro volume di produzione
in questa stanza è Ed è nessuno familiare
con esso ok così Kafka è fondamentalmente un
sistema di accodamento messaggi che era aperto
fonte da linkedin che ha un
modello di pubblicazione-sottoscrizione o turni di Kafka
consumatore produttore, quindi ne abbiamo provati alcuni
diversi sistemi di messaggistica quando eravamo
valutare la prossima generazione del nostro
registro di consegna e abbiamo trovato abbastanza presto
su quello Kafka aveva appena funzionato il meglio
abbiamo avuto una latenza dal nostro accesso
punto come rafal menzionato per il nostro HDFS
cluster andare da ore giù per i secondi
e questo ha aperto una grande varietà di nuovi
utilizzare i casi che potremmo fare con i dati
per esempio l’ elaborazione in tempo reale con
Apache storm quindi è un po ‘semplice
immagine di ciò che la nostra architettura sembra
così abbiamo i 30 terabyte di dati
questo è generato dagli utenti che si connettono
ai nostri punti di accesso e questo è passato
lungo il lato del sito per le cernie locali
consumare tutti gli eventi prodotti dal
punto di accesso li comprimono
crittografare li mandano su internet
a Londra dove viene consumato
il nostro cluster Hadoop quindi saremo belli
onestamente abbiamo avuto molti problemi
anche questo sistema di consegna dei registri, ma questo è
L’enigma era molto legato al sistema kafka
che stiamo usando stiamo usando Kafka 0.7
che è un’architettura un po ‘più vecchia
ed è anche dovuto al fatto che noi
avere il sistema di consegna Ende Ende
abbiamo costruito su Kafka davvero
ci consente di ottenere la consegna affidabile
perché questi registri come abbiamo detto sono carini
importante ma il nostro sistema di consegna dei registri è
in continua evoluzione come in ogni nuovo
problema che abbiamo colpito e in effetti proprio adesso
stiamo valutando a
gruppo di diversi sistemi di consegna dei registri
quindi possiamo migliorarlo e correggere alcuni dei
bug che esistono nel nostro sistema così ora
che abbiamo dati dentro di te
potrebbe voler iniziare a fare i dati come te
potrebbe voler iniziare a fare qualcosa con
dati in modo da eseguire alcuni lavori e si potrebbe
programmali ad esempio come nel crimine
come questo e eseguire i lavori di
tempi prevedibili potrebbero funzionare
inizialmente ma cosa succede
se il tuo precedente lavoro fallisce, non lo fai
vuoi elaborare dati incompleti
perché in realtà è peggio di
il processo non ha funzionato affatto
perché avrai risultati incoerenti
giù il tuo oleodotto di fronte a questo
sfida uno dei primi ingegneri a
il suo nome era eric berne hudson
affrontarlo creando un nuovo strumento
chiamato luigi perché gestisce a
impianto idraulico di lavori Hadoop e anche perché
è verde e lo schermo di Spotify è così
bello, quindi è Luigi un flusso di lavoro
orchestratore che è scritto in python
che ti consente di definire un lavoro
dipendenze programmaticamente quindi se per
ad esempio nel calcolo regalità tua
la pipeline di calcolo delle royalty dipende
upstream su alcuni lavori ETL sta per
assicurati che quelle dipendenze siano
completa prima di eseguire la royalty
lavori di calcolo se non è completo
pianificherà quindi è stato un
progetto di grande successo che è stato il primo
open source di Spotify nel 2011 è utilizzato
in tutto il mondo a centinaia di
aziende diverse che stiamo trovando nuove
quelli ogni giorno compresi alcuni
quelli veramente grandi come Foursquare e
striscia sfortunata non ne abbiamo così tante
tanto tempo per scendere nei dettagli
di Luigi ma se ti interessa
questo ti invitiamo a andare al
github pagina laggiù e check it out
così ora che abbiamo dati su HDFS e noi
avere un programmatore che possiamo pianificare
il lavoro con abbiamo iniziato a ottenere di più e
più ingegneri per elaborare i dati
è stato bello e ciò che viene fornito
ingegneri che sono perfetti io ci sono
feedback c’è una buona pace e
feedback positivo e anche costruire
costruire un feedback negativo costruttivo
e uno di questi era che non ci sono dati
catalogo quindi è difficile trovare set di dati
su HDFS e ogni tanto a
l’ingegnere dovrebbe andare su HDFS e
meno alcuni LS di alcune directory e
forse al taglio annuale è così piaciuto
questo caso cercando la barca sul
data lake ogni singola esecuzione di questo
Cliente HDFS vorrebbe un paio di
secondi perché deve caricare una JVM
librerie fluenti e così via e così via
quello era il punto dolente per gli ingegneri
e perché ci piace sperimentare che abbiamo
deciso che sperimenteremo con il
Protocollo RPC in HDFS ed è così
un altro progetto open source
ecco perché se fossi nato e così fosse
morso di serpente standby era originariamente
creato ma da wouter il raggio e in
in poche parole è fondamentalmente un puro
client HDFS Python che significa che
c’è tutto quello che succede dentro Python
nessun java sta accadendo in questo client e
in realtà è molto semplice e molto
intuitivo quando si tratta di una lettura semplice
operazioni su HDFS e quanto è veloce
lascia che ti mostri su un’altra diapositiva così qui
puoi vedere 100 esecuzioni di vaniglia
Client HDFS in alto e in basso puoi vedere
esecuzioni a una mano di client di morso di serpente
e puoi vedere che sono circa 10
volte più veloce e quindi vaniglia HDFS
cliente che è abbastanza bello ma buono
è anche un bello è che sarà effettivamente
usa meno risorse di Vanilla HDFS
client userà meno memoria e meno
CPU e questo è in realtà abbastanza utile
soprattutto se hai un servizio
interagisce con HDFS molto e come Spotify
in realtà abbiamo un servizio secondario ed è
luigi perché luigi in realtà da programmare
i posti di lavoro che dovranno fare un sacco di
esistenza ogni X su HDFS e quando tu
iniziare a gestire decine di migliaia di posti di lavoro
che può effettivamente caricare le macchine
su cui esegui lo scheduler e noi
in realtà ha avuto questo problema quindi abbiamo deciso
che passeremo dal client HDFS a
scommettere sul mio cliente e su ciò che abbiamo notato
subito dopo è quello nostro
i controlli sono più stabili sono più veloci e
programmare i libri più prontamente che è
carino e ti incoraggio a prendere
uno sguardo alla pagina github e una ricerca
per morsi di serpente così ora che abbiamo avuto un
cluster orribile attivo e funzionante e noi
avere il kafka che sta caricando i dati in
Hadoop e abbiamo alcuni strumenti come Luigi
e morso di serpente in modo che tutti gli sviluppatori
attorno a Spotify potrebbe accedere ai dati
ed eseguire i lavori Hadoop che abbiamo iniziato a correre
in esso un nuovo problema e questo era quello
gli sviluppatori in realtà stiamo correndo molto
di posti di lavoro stavano correndo sempre di più
lavori e loro erano l’importanza del
i lavori stavano aumentando nel tempo e
il problema era che la squadra che
gestito il cluster Hadoop era anche il
squadra che stava scrivendo anche lavori e loro
stavano anche sviluppando e supportando
strumenti come morso di serpente e Luigi e loro
non ha avuto molto tempo per Hadoop
manutenzione se si ha familiarità con
un cluster Hadoop senza tempo per
la manutenzione è un incidente in attesa di
succede e dopo un particolare
incidente particolarmente grave che ha causato
interruzione di più giorni abbiamo deciso che dovevamo
cambiare qualcosa e la decisione è stata
formare una squadra in modo che il team ha iniziato con
Rafal me stesso e un altro ingegnere a
individuare e abbiamo avuto una missione molto semplice
quando abbiamo iniziato la prima parte era quella
dovevamo migrare verso una nuova distribuzione
di Hadoop che includeva il filato il secondo
parte e la parte più importante è stata
che dovevamo rendere Hadoop affidabile e
quindi ti starai chiedendo come abbiamo fatto
lascia che ti mostri in questo grafico così nel
la prima sezione è quella in cui Hadoop era
essenzialmente proprietariless a spotify che abbiamo avuto
un sacco di problemi casuali e interruzioni
ha causato tempi morti in giro per l’azienda
Hadoop era una specie di parolaccia
perché anche se era davvero facile
per scrivere ed eseguire lavori sul cluster
non erano così sicuri se sarebbe successo
quando effettivamente hai davvero bisogno del
risultati la seconda sezione è in realtà
quando abbiamo iniziato il team Hadoop su
individuare che ci rivolgiamo a molti dei
frutta a basso impatto e ha iniziato a migliorare
affidabilità subito il terzo
sezioni quando abbiamo aggiornato il nostro Hadoop
cluster a una distribuzione inclusa
filato quindi c’erano alcune complicazioni
coinvolto in quello era tutto così
complicato cambiando le distribuzioni in
il primo trimestre 2014 abbiamo aggiunto il nome
nodo alta disponibilità e anche questo
ha introdotto i problemi da soli
a causa della nostra scala del nostro cluster
nella dimensione, niente è mai stato così facile
come faccio libri come è così nel
terza sezione questo è quando il quarto
sezione credo che questo è quando in realtà
iniziato ad essere abbastanza affidabile e
prevedibile e in realtà eravamo in giro
lo abbiamo fatto creando il nostro burattino
configurazioni che usiamo per controllare
la testa del grappolo fa davvero male alla sella
abbiamo aggiunto un bel po ‘di monitoraggio
avvisando in modo che prima che i problemi accadano noi
erano consapevoli del fatto che poteva
prevenirli e ne abbiamo anche costruiti alcuni
infrastruttura per rendere gli aggiornamenti più facili
quindi in realtà stavamo iniziando a essere
visto come un team di modello attorno a Spotify
perché stavamo davvero migliorando il
affidabilità e vestire i nostri utenti
i più grandi problemi era tutto a posto
tranne che alla fine puoi vedere l’ultimo
bar e questo è l’ultimo quarto e tu
può vedere un calo significativo in
disponibilità del nostro cluster Hadoop e
questo è principalmente a causa del nostro processo di
ridimensionamento del cluster Hadoop da 1.200 a
1700 note e come Josh ha detto di sì
la pipetta che avevamo monitorato e
avvisando e potremmo prevenire qualcosa
che sapevamo ma come si scopre
c’era un’altra classe di problemi
stiamo iniziando a guarire c’era una classe
di problemi erano fondamentalmente bug in Hadoop
un codice quindi la lezione è che quando noi
quando ridimensionate Hadoop, ridimensionate anche il
nascosto indietro che viene nel codice e in
il nostro caso vengono e possiamo vederli
non appena iniziamo a ridimensionare, facciamolo
Dì 1200 note così in questo caso puoi
vedi due problemi specifici che sono super
mortale per noi ma in termini di piccolo
i cluster non sarebbero davvero quello
mortale o non costerebbe tempo morto
nei nostri casi, fondamentalmente entrambi
ha portato l’intero cluster verso il basso
di un giorno quindi diamo un’occhiata al
primo numero per esempio così nel primo
problema ed è un problema con i file aperti
e failover così quando fallisci con uno
il nome guarda ad un altro in hia set up
e per essere attivo, la modalità denominata dovrà
passare attraverso tutti i file aperti assicurarsi
che sono ancora aperti e validi
il processo è stato implementato molto male
modo in cui era modo molto inefficiente per
implementalo e l’intera descrizione
è nel codice in un piccolo cluster che
non sarebbe un problema nel nostro caso in cui
abbiamo migliaia di decine aperte di
migliaia di file aperti in qualsiasi dato
punto che fondamentalmente porta il tutto
cluster in giù ciò che è divertente è che quando
noi quel problema ci ha effettivamente fatto passare
da una versione all’altra da 22 a
2.6 in realtà subito dopo l’aggiornamento noi
imbattersi in un altro problema il secondo
che permette in realtà anche portato il
intero cluster in basso ed è anche correlato
a un failover e quindi ricorda quando tu
scalare come cluster anche scalare il
scatola nascosta nel codice sì sì lì
sono stati un sacco di bug che ci siamo imbattuti in
che erano nel taglio Hadoop c’era
anche molte delle prime sfide che noi
incontrato solo con il nostro maiale
configurazione e sono necessari per
adattarsi costantemente al cambiamento ma lì
c’erano anche alcune cose e alcuni problemi
che ci siamo imbattuti in quello erano totalmente uno
cento percento evitabile come parlerò
in questo momento così un po ‘più di un
l’anno scorso la squadra del dupe stava facendo un
bel lavoro e ne siamo rimasti piuttosto orgogliosi
dell’affidabilità del nuovo cluster
e il successo che abbiamo avuto e
intorno alla compagnia conosci persone
venendo da noi e loro stavano dicendo
stai facendo un ottimo lavoro così noi
pensavo che saremmo andati a festeggiare e abbiamo deciso
per andare in un bar a Stoccolma e tu
sai avere un buon paio di birre e solo
celebrare il nostro successo così quando eravamo
camminando verso questo bar abbiamo tutti avuto un
messaggio in arrivo sui nostri telefoni che apriamo
su e il titolo ha detto qualcosa di simile
questo penso di aver sbagliato ora quando
apriamo l’e-mail ci siamo resi conto che
uno degli utenti di New York aveva eseguito a
comando sul cluster che appare
qualcosa del genere ora forse qualcuno
posso vedere cosa c’è che non va qui, forse ora
forse ora quando quando realizzo il
problema ho alzato gli occhi e l’ho vista falsa
faccia ed era come questa madre di dio
cos’hanno fatto così è venuto fuori
l’utente a New York aveva accidentalmente
metti uno spazio nel comando che era
correre tra il nome della sua squadra e
la cartella che lui in realtà voleva
cancella e ha cancellato il suo intero
la directory dei dati del team era oltre un
petabyte di dati raccolti
mesi e mesi di piuttosto intenso che faccio
elaborazione quindi siamo stati lì a
il marciapiede nella soleggiata Stoccolma e
stiamo cercando di decidere cosa facciamo
dovremmo tornare in ufficio chiuso
giù Hadoop prova a recuperare alcuni dei
blocchi prima che diventino permanentemente
cancellato o continuiamo semplicemente sul
bar e sai che occupartene domani
fingere di non averlo visto
fortunatamente non abbiamo dovuto farlo
prendere questa decisione perché un altro utente
dalla stessa squadra di questo ragazzo in New
York ha risposto al thread dicendo di no
preoccuparsi cato possiamo effettivamente
rigenerare alcuni dei più critici
i dati in pochi giorni lo conoscete
abbiamo appena risparmiato un sacco di spazio lasciandola fare
cluster così da questo abbiamo imparato alcuni
lezioni davvero importanti la prima
è dai nostri colleghi là fuori lui
dice sempre che questo è seduto sulle tue mani
prima di digitare sai soprattutto se
stai rimuovendo il cestino in HDFS
o stai usando una specie di super utente
sai prima di premere il tasto Invio
assicurati che ciò che hai digitato sia effettivamente
cosa vuoi eseguire sul cluster il
la seconda è che gli utenti vogliono sempre
conservare i loro dati e come abbiamo scoperto in
in questo caso specifico conosci questa squadra
potrebbe rigenerare tutto il loro reclutatore
detto atta e hanno davvero bisogno solo di un
porzione parziale di quel petabyte
dei dati e se lo sapessimo in anticipo
se li avessimo effettivamente sfidati a
un po ‘più difficile che avremmo potuto salvare a
sacco di soldi e spazio su un cluster e
costa il terzo è quello che dovresti
rimuovi i super utenti dal tuo nodo periferico
se hai familiarità con i super utenti loro
fondamentalmente hanno assi globali che hanno
super autorizzazioni sul tuo cluster Hadoop
ed è Spotify che abbiamo questo lo sai
Ideale svedese di uguaglianza e noi
avere ciò significa che tutti gli ingegneri di
la società ha accesso sudo al
macchine che hanno accesso a così se
questo utente aveva usato il superuser e aveva
quello spazio un po ‘ prima nel
comando di conoscermi e Rafal potrebbe non
essere qui dando questo discorso oggi così il
la quarta lezione che abbiamo imparato è quella commovente
nel cestino è in realtà un lato client
implementazione un dupe e in morso di serpente
non l’avevamo ancora implementato così noi
festeggiamo un piccolo fallimento che abbiamo fatto a
piccolo hacking e ora puoi tranquillamente
rimuovere dal morso di serpente che era carino
gambo pulito e divertente ma pochi
settimane dopo ce n’era un altro
quindi abbiamo avuto questo consulente esterno /
giochiamo a fi e il suo obiettivo era fondamentalmente
certificare il nostro cluster che significa questo
lui passerebbe attraverso tutto il diverso
parti della configurazione del clustering
fuori da
dire che questa classe è sana o no
e questo è ciò che devi migliorare
i primi giorni non erano davvero belli
liscio e siamo stati un po ‘come felici
di noi stessi e orgogliosi di te
sapere che non ha trovato nulla di simile
sì, stiamo andando alla grande, ma il giorno
numero tre a causa di problemi di comunicazione e
Miss configurazione uno dei compagni di squadra
Abbiamo ucciso il nostro stand per nome nodo e io ero
bene perché è un nodo di nome stand by
tranne poi ce n’era un altro
incomunicabilità e abbiamo ucciso il nostro
Nudo attivo che significa che c’era
nessun maestro ora l’ hdf che significa
non c’è HDFS, il che significa che non c’è
Hadoop non c’è elaborazione e questo
aggiungere le nostre scale significa circa due ore di
tempi di inattività ed è stato specificamente cattivo
perché c’era questo esterno
consulente / giusto ma non era così
quasi come il giorno numero quattro, quindi loro
il numero quattro siamo seduti in un altro
stanza c’è dis cos Alton c’è il
squadra e ci sono i nostri manager e noi siamo
parlando l’incidente e complessiva
sulla certificazione del consulente
sta dicendo qualcosa sulla falsariga di
il fatto che i nostri test e
le procedure di implementazione sono come wild wild
a ovest e questo è stato molto difficile
ascoltare, ma alla fine aveva ragione
e lo sapevamo subito dopo
incontrare l’intera squadra è andato in una stanza
e abbiamo deciso che non lo faremo
lascia la stanza finché non arriviamo a
piano per risolvere sostanzialmente questo problema e
abbiamo trovato qualcosa che potrebbe essere
in realtà piuttosto semplice e ovvio
tu che è un cluster di pre-produzione
e il cluster di pre-produzione è realizzato
della stessa classe di macchine esattamente
la stessa classe di macchine molto
configurazione simile quasi identica
e abbiamo creato una serie di test del fumo che
possiamo finire quella pre-produzione
cluster assicurati che ogni parte
di quel sistema è ben integrato e
funziona perfettamente bene e quindi possiamo usare
che entrambi fumano questa produzione di NP
cluster per distribuire le modifiche prima a
pre-produzione quindi intorno al fumo
il test ottiene un feedback immediato e quindi
decidere se vogliamo realmente
distribuire o non modificare effettivamente il
modo in cui testiamo e distribuiamo in produzione
che funzionano abbastanza bene come specificamente
ad esempio per il nostro recente aggiornamento siamo
in grado di scoprire attraverso di essa ai problemi
probabilmente ciò probabilmente causerebbe
un grave incidente sulla produzione se
non l’abbiamo scoperto prima
mentre la squadra Hadoop stava cercando di farlo
rendere l’infrastruttura stabile e lo è stata
lavorando alla pre-produzione di tutto questo
di roba ce n’era un altro e c’era
un altro sforzo per andare nei dati e quello
doveva passare da Python a JVM così come noi
detto prima di ragazzo se fossi un grande pitone
negozio e abbiamo implementato un sacco di
pipeline in Python su un Hadoop
streaming e nel tempo che ci siamo resi conto
questo è un problema perché abbiamo iniziato
vedere un sacco di fallimenti di questo
tipo di condutture perché ogni volta
qualcuno ha fatto il cambiamento in Python
codice è stato molto difficile cambiare test
così la gente fondamentalmente la butta al
cluster con le risorse di rifiuti solo per
ottenere un feedback se hanno fatto errori di battitura in a
codice o no o forse c’è una discrepanza
nel tipo a causa della natura di
Python era una classe di problemi
un altro era che c’era fondamentalmente
nessuna infrastruttura di test quindi le persone
getterebbe fondamentalmente una linea di tubi a
il gruppo e anche il
la performance non c’era, così è
a causa della natura e dell’architettura
di Hadoop streaming e anche Python
stesso così uno degli ingegneri di
individuare lo sbiancamento di David ha fatto un ampio
panoramica di tutti i quadri che puoi
usa su hadoop e puoi trovare i link
qui e poi dopo con me noi
c’è stata una discussione su tutto il
quadri e abbiamo deciso che lo faremo
scegli apache grunt come supportato
framework per eseguire MapReduce un batch
posti di lavoro a spotify e c’era una coppia
di ragioni dietro di esso sto andando portare in su
tre di loro che pensiamo siano nel
i più importanti quindi il primo è
che si ottiene il tipo reale in modo da ottenere il tipo
sicurezza che significa che puoi ottenere un
errori in fase di compilazione che non è necessario
lanciare il lavoro nel cluster per verificare
che è un lavoro vero senza
errori di battitura o uno schema non corrispondono a un altro
ottieni una torta di alto livello che significa
che puoi iniziare a pensare in termini di
gruppo di disegni acquista gruppi di chiamata sul nostro
tipo di fantasia a funzioni invece di
pensando in termini di questa vecchia mappa e
ridurre un paradigma che è molto bello e
rende l’intera pipeline meno dettagliata
e più facile da mantenere nel tempo
diversi ingegneri quindi il terzo
la ragione è la performance stessa e
che proviene da JVM e prendiamo un
guarda il grafico qui, quindi su questo
grafico che puoi
vedi il punto di riferimento di crunch e Hadoop
streaming e questo è un punto di riferimento per
il nostro carico di lavoro di produzione quindi questo non è un
sintetico questo è il nostro questi sono i nostri
carichi di lavoro di produzione e questo specifico
graph è una mappa di throughput in
puoi megabyte al secondo a sinistra
vedi lo scricchiolio a destra puoi vedere come
nuoto tubolare e puoi vederlo
Il crunch di Apache è circa 8 volte più veloce
in media e i nostri quasi settantacinque
percentuale di tutti i lavori di crunch di Apache
sono più veloci di tutti gli streaming Hadoop
lavori che è una buona ragione per
passare a JVM e anche noi siamo stati in grado di farlo
ha escogitato un test abbastanza carino
ambiente per Apache crunch in cima a
un mini cluster che in pratica significa ora
possiamo imporre ai nostri sviluppatori di creare
prova anche per le teglie a torta
molto bello e così è stato un sacco di
evoluzione, quindi rivediamo rapidamente
di cosa abbiamo parlato così all’inizio
discusso le difficoltà di pari
ottenere dati nel nostro cluster HDFS e come
lo risolviamo usando Kafka e poi abbiamo parlato
su alcune delle sfide che abbiamo avuto
quando stavamo iniziando per la prima volta
scrivendo lavori di Duke e usando cron come
programma e come risolviamo quelli usando
strumenti come Luigi e morso di serpente poi noi
parlato di alcuni dei problemi che noi
aveva presto con disponibilità e come
risolviamo la creazione di una squadra che era
davvero concentrato sull’Hadoop
solo l’infrastruttura e anche come noi
migliorare l’affidabilità facendo cose
come il mio monitoraggio e allerta adeguati
poi Rafael ha recentemente parlato di come noi
abbiamo iniziato a concentrarci davvero
prestazioni e migliorare spostando le cose
da Python e Hadoop streaming a
Apache crunch e quest’ultima sezione
parleremo del futuro voi
so a cosa stiamo lavorando ora cosa
stiamo pianificando di concentrarci su
i prossimi sei a 12 mesi a Hadoop
Spotify quindi questo è il grafico del
la crescita di Hadoop rispetto a fine Spotify
utenti dal 2012, quando Spotify aveva appena
ha attraversato oltre 10 milioni di utenti così da allora
quella volta Spotify è cresciuto di seicento
e il cinquanta percento che è piuttosto grande
crescita ma la crescita dell’utente no
confronta tutto con la crescita dell’utilizzo di Hadoop
la crescita
e richiesta di risorse di calcolo a
spotify quindi è cresciuto
quattromila per cento come potresti vedere
quindi ciò che ha causato così tanto crescita ora noi
attributo sono le tre cose principali
il primo è abbastanza ovvio con
maggiore visibilità degli utenti finali che stai andando
avere molti più dati tutti quegli utenti
stiamo ascoltando molto più canzone che
significa che tutta la pipeline è quella che tu
hai usato cose simili?
le condutture tascabili e la
i grafici migliori devono essere elaborati molto
più dati e hanno bisogno di molto di più
calcolare le risorse di risorse per farlo
il secondo è aumentare i casi di utilizzo così
quando abbiamo iniziato con Hadoop a
spotify lo abbiamo usato solo per l’analisi
e stiamo segnalando condutture che non abbiamo fatto
usarlo per un sacco di cose in questi giorni noi
usalo per potenziare funzioni come il
la scoperta settimanale è tutto alla fine
guidato da Hadoop e tutti questi enormi
apprendimento automatico e elaborazione grafica
posti di lavoro e abbiamo davvero visto tutto
i diversi casi d’uso significano che tu sei
sta andando a correre molti più lavori e
Avrai bisogno di molto di più
potenza di elaborazione l’ultima è
in realtà davvero interessante quindi abbiamo
aumentato un sacco di ingegneri che
Spotify quel processo su dati e
questo è che la crescita è guidato molto in
2014 Spotify ha acquisito questa società
chiamato il nido di eco che ha sede in
Boston gli Stati Uniti sono la loro compagnia musicale
è solo ossessionato dalla musica
intelligenza e prima che giochino a
Spotify in realtà non usano mai Hadoop
ma quando hanno iniziato e aveva accesso ai
il nostro tesoro di dati dell’utente loro
è diventato appassionato e ora c’è un po ‘di
i nostri utenti più pesanti ed eseguire alcuni dei
i lavori più impegnativi ora vengono appresi
tutta questa crescita non è ciò che abbiamo imparato
attraverso questa crescita è importante
la realizzazione è quella di ridimensionare le macchine
è in realtà un tipo di facile e abbiamo
avvisi abbiamo il monitoraggio corretto
monitoraggio abbiamo pupazzo davvero solido
configurazione che ci consente di aggiungere nuovi
macchine sai che è permesso a noi
andare da 120 macchine un po ‘
più di due anni fa alla missione del 1700
quasi 1700 macchine che abbiamo oggi
senza troppi problemi ora abbiamo corso
in alcuni problemi come noi
mentre menzionato con la recente aggiunta
di 400 nodi e in corso o 500 in corso
1200 1700 ma per la maggior parte è
sono state abbastanza fluide ma ridimensionano le persone
questo è davvero molto difficile ora
siamo ancora una squadra relativamente piccola a
spotify ma supportiamo centinaia di utenti
che stanno elaborando i dati e hanno
diversi livelli di competenza da
il principiante per l’esperto e abbiamo
problemi di stare al passo con tutti loro
problemi quindi potresti chiederti cosa siamo
stiamo pianificando di farlo
iniziando ad automatizzare il feedback che vogliamo
fornire informazioni sui lavori di Hadoop a
utenti immediatamente dopo il completamento del lavoro
cose come il tuo lavoro ha fallito con il
errore specifico forse sappiamo di che
Eric può collegarsi al biglietto jira e
forse la soluzione per questo forse è il tuo
il lavoro sta avviando con l’utente sbagliato
permessi quindi proveremo a mettere su
segnale di pericolo prima di eseguire il tuo lavoro così
non sprechi tutto il calcolo
risorse solo per venire con niente
ma perché stiamo lavorando su questo abbiamo
distribuito alcune cose che sono già
aiutandoci e potremmo aiutarti anche tu se
tu stai correndo io faccio il primo è un
progetto chiamato inviso questo è stato scritto
in rilasciato da Netflix un po ‘sopra
circa un anno fa il visto ti permette di vedere
che cosa sta succedendo con un cluster in tempo reale
tempo e fornisci qualcosa di veramente bello
visualizzazioni che lo rendono ovvio per
esempio se un singolo lavoro sta dominando
il cluster e utilizzando tutte le risorse
permetterà anche che ne contenga anche alcuni
strumenti di visualizzazione piuttosto interessanti che tu
può andare giù nel livello di lavoro individuale
e vedere come la vita del lavoro in e
come si comporta e puoi usarlo
per migliorare le prestazioni lavorative lo farei davvero
incoraggiarti a controllare l’altro
la cosa che abbiamo fatto sembra così ovvia
che siamo stati davvero sorpresi di come
efficace è stato così ogni trimestre
pubblica una newsletter che contiene tutto
tipi di informazioni diverse e
statistiche su lavori come Hadoop cose come
la crescita del calcolo Hadoop richiede
aumento dello spazio di archiviazione per i lavori in cui non si verificano i migliori risultati
del cluster o in quel trimestre o in
un mese
o semplice vecchia affidabilità hadoop ora noi
ottenere sempre ottimi feedback in giro
questa newsletter quindi sono ghetto freddo ma a
pochi mesi fa era ancora di più
efficace perché ha identificato un singolo
lavoro che stava funzionando ogni giorno e usando
sprecare oltre il dieci percento dei cluster
risorse perché stava sempre fallendo
ora prima di pubblicare la newsletter
lo usano in questo lavoro, non lo fanno nemmeno
rendersi conto che il suo lavoro era in corso ogni giorno
l’ammasso fallì ma quando vide
il suo nome sulla newsletter sociale
la pressione dei pari solo gli aveva causato ai
vai immediatamente a non pianificare il suo lavoro e
voto a noi che non aveva mai avviato un lavoro
sul cluster Hadoop senza correttamente
testarlo e senza alcun tipo di
certificando con noi così solo dal
pressione sociale tra pari e utente migliorato
prestazione che è stata grande per noi
perché non dovevamo entrare e e
sai manualmente dirgli che lui ha
smettere di fare quella roba che era grandiosa
dal momento che questo è a tutti i dati parlano che abbiamo
per menzionare la scintilla quindi c’è
si accende la luce quindi sì, noi siamo
valutando la scintilla e abbiamo giocato
con esso sin dall’inizio abbiamo avuto
alcuni problemi con esso e abbastanza recentemente
ricorrere ad un esperimento con Apache
Zeppelin in cima alla scintilla di apache così
probabilmente hai sentito parlare di scintilla ma
di quanti ne avete sentito parlare
Zeppelin è cool, quindi ce n’è un paio
persone fantastiche, quindi puoi pensare
Zeppelin come ipython su steroidi su
la parte superiore della scintilla è così buona che ti dà
è che puoi fondamentalmente immergerti nei dati
affetta e tira un po ‘e prendi un
risultato in un bel modo visivo proprio così
è come un’esperienza di un notebook
in cima alla tua scintilla e al modo in cui vogliamo
per usarlo è si vuole usarlo come un
strumento di colla dove puoi connetterti a tutti
i diversi pezzi del nostro
l’infrastruttura recupera rapidamente i dati
processarlo ottiene un bel risultato visivo e
allora l’ingegnere può decidere se
c’è valore in quei dati e se
c’è la necessità di distribuire un adeguato
conduttura pronta per la produzione in cima a
scottature o scricchiolii o altro
è così che è lì che lo vediamo
abbiamo alcuni buoni risultati fin
iniziando e incoraggiarti fortemente a
dare un’occhiata a un partecipante in questo
in realtà ci porta quasi alla fine
che è due take away quindi questo è gentile
della diapositiva più importante del
il discorso quindi due take away uno è quello
non c’è una Golden Path in particolare quando
si tratta di Big Data non ci sono
i modelli ci sono tipo di emergenti
modelli ma gli ingegneri sono un po ‘
definendolo o fino a definirlo così quando
hai un problema quando devi
progettare un sistema e mi occuperò di
dati che ti invitiamo a prendere a
guarda il problema e prova ad implementarlo
nella soluzione più semplice che puoi
cercare di evitare di essere prematuro
ottimizzazione il più possibile, se lo è
un anti-modello in generale rispetto a Big
Dati questo è come la radice di tutti i mali
e poi il secondo take-away è quello
l’evoluzione è un processo continuo così
qualunque cosa tu abbia intenzione di progettare
o lo strumento deve essere giocato via
progettare in un modo che lo renda facile
itera su di esso in modo così semplice da creare
qualcosa poi dovrai farlo di più
probabilmente lo butto via molto presto
subito dopo implementare qualcosa
in alto e devi implementare in a
modo che lo rende facile da scambiare
fondamentalmente così questi sono due tipi di
semplice togliere il suo tipo di tipo di
anche un po ‘generico ma se vieni gentile
di vivere fino a loro e questo lo farà
la tua vita è molto più facile come un Hadoop
amministratore o ingegnere dei dati e così
ci porta all’ultima diapositiva che siamo noi
stanno assumendo e tu sai che abbiamo bisogno
ingegneri a New York stoccolma quindi se
vuoi unirti a noi puoi parlare con noi
dopo o potete scrivere a noi su
Twitter e questa è la fine, va bene
la ringrazio molto Penso che abbiamo il tempo
per domande
va bene grazie ragazzi e così chi lo vuole
inizia questo perché sei tu che ti capita
per essere vicino ciao come si gestisce con FEMA
le modifiche che hai menzionato così questo è un
il problema è un formato come lo facciamo
i cambiamenti dello schema ci sono la domanda
come facciamo i cambiamenti di schema um okay così
la maggior parte è implementata come a
repository di schemi in questo momento in cui noi
avere un progetto chiamato parser lock lock
che fondamentalmente definisce quali sono i
campi e poi ogni volta che fai
una modifica puoi cambiarla in quel registro
parser ma bisogna fare in modo che
tutti sanno di questo cambiamento e di tutto
le condutture che sono a valle sono in aumento
ad oggi con quel cambiamento mmm che no
non funziona davvero tutto il tempo
e nell’architettura più recente
stiamo lavorando su quelli più centralizzati
repository di schemi in cui si desidera recuperare
lo schema da quel repository e
che fondamentalmente dipenderebbe dal
dati che hai nutrito quindi diciamo che tu
voglio elaborare qualcosa da cui proviene
due anni fa e lo schema sarà
fatto in questo rappresenta che puoi nutrire
ma non è in là, non lo è
c’è ancora e non riesco a ricordare se noi
match ma usiamo Patchy Avro in questo modo
aiuta molto, ma ce n’è uno sopra
qui hai menzionato che il cluster era
non stabile all’inizio quale era il
ragione per questo prima di Hadoop
la squadra era iniziata sì, quindi abbiamo avuto un sacco
di diversi problemi erano molti di loro
frutta molto bassa che pendeva come nessuno
gestire la crescita dei dati così ogni volta
tra un po ‘dovremmo espandere il cluster
quando si esaurisce lo spazio su disco e lì
era davvero no, era sempre reattivo
questo era il problema per cui ci saremmo incontrati
utilizzo del disco del novanta per cento che è
tipo di zona pericolosa che perché
significa che i singoli dischi sono uno
cento per cento pieno o hai
singoli nodi che sono sotto
pieno quando è correttamente bilanciato e
questo causerà un sacco di fallimenti di lavoro
e la vendetta si imbatterà in tutto
tipi di pazzi casi limite in Hadoop così
quello era uno dei grandi motivi lì
erano anche altri molto interessanti
problemi che abbiamo incontrato dovrei andare
indietro e guarda ma alcuni errori alcuni
errori di configurazione perché Hadoop non lo è
il miglior codice documentato c’era persino
alcuni parametri di configurazione dove
detto questo questo parametro è millisecondi
ma in realtà si è rivelato essere secondi
e quello come davvero ricordo che era
un grosso problema come lo era anche tutto
specie di piccole dimensioni era una specie di
come un piccolo come josh sta dicendo in a
piccole cose come non c’erano allarmi
quindi per esempio si esaurirebbe lo spazio
lì sui nodi così detti descritti
sarà come se sapessi che il nome morirà
e poi un burattino non stava correndo così
ogni volta c’era un cambiamento per
esempio in rete che era una specie di
serio e non sarebbe propagato
il nodo del nome del plugin all’improvviso no
si può collegare una e-mail che è anche a
problema tutto come un dischetto fallirebbe
come se non avessi un giusto set up
l’aria sulle note dei nomi e altri problemi
così gentile di cose semplici che puoi farti
può fare una specie di lunga sospensione in realtà
erano avvisi erano solo modo
troppi avvisi e erano totalmente
inutile mi ricordo quando ho iniziato
a spotify si inizia la tua e-mail
come poche settimane prima che tu in realtà
il tuo primo giorno e mi è piaciuto finita
10.000 email in come tutte erano
lo sai per nome, nessun disco è pieno
o sai solo che abbiamo finito
problema di apprendimento così tanti avvisi che
è assolutamente inutile e non lo erano
molto specifico come abbiamo fatto in seguito
era un c’era un note di dati di registro morto
anche io e ricordo che abbiamo fatto un
cambiare il tempo necessario
nome per non contrassegnare il nodo dati è morto
e quello era quello che penso il
millisecondi e secondi così nel modo
volevamo allungarlo ma noi abbiamo
reso più breve che ha reso il tutto
la cosa peggiora molto bene sorella ma era lì
c’erano alcuni bug c’erano alcuni
errori di configurazione stavano cercando a lungo
va bene
frutta bassa portata va bene ancora un po ‘
domande va bene quanto è grande il tuo
cluster di pre-produzione in questo momento è 12
nodi e due lo abbiamo ampliato a credo
circa 40 note non va bene oh è solo
recentemente sono state 12 note per molto tempo
ma poi abbiamo dovuto aggiornare di recente
circa ero un mese e mezzo fa o
anche un mese fa quindi abbiamo dovuto fare un salto
capacità perché eravamo 12 nodi in a
centomila trecentomila
settecento nodi era difficile
in realtà spostare i dati lì da fare
test di pre-produzione quindi abbiamo dovuto imbattersi
su capacità penso a circa 30 o 40
nota ma è abbastanza elastico che potremmo
sono tornato giù a 12 non lo so
okay più domande per i ragazzi che corrono
il più grande cluster Hadoop in Europa
lo farai, ragazzi, lo farete
ti prendi a calci quando arrivi a casa
e ti rendi conto di quella domanda che volevi
chiedere tutto bene è come oh
la domanda è se usiamo il fisico
ora è il nostro virtuale così abbiamo
clustering fisico come a in quello
Londra sì sì, io tre avevo davvero un
slide delle specifiche ma abbiamo deciso di farlo
rimuoverlo sì, ma eseguiamo i server dell
1700 abbiamo penso tre diversi
generazioni di server i nostri più vecchi
sono circa tre o quattro anni i nostri più nuovi
quelli che abbiamo avuto altri tre mesi fa
consegnati sono piuttosto muscolosi, corrono
che aggiungiamo abbiamo 12 dischi per macchina
quattro terabyte di disco
e dipendono circa ventiquattro nuclei
missione va bene più domande su
backup sì, è piuttosto divertente
storia di copertina così disconnessa di cui abbiamo parlato
prima facevano effettivamente i nostri backup in questo modo
scriverebbe a HDFS che scriverebbe anche
per amazon penso che fosse s3 così che se
avevamo bisogno di ripristinare potevamo solo
rielaborare i dati da raw sai se
abbiamo mai dovuto farlo davvero
sarebbe una storia diversa perché
ottenendo effettivamente i dati da s3 e
e rielaborandolo con vecchi formati e
roba sarebbe un incubo sì sì, quando
l’abbiamo ucciso, abbiamo dovuto inventare un
nuova soluzione quindi quello che facciamo ora è noi
non copiare i nostri dati grezzi perché salviamo
come la storia recente all’interno di Kafka
ci sono alcuni meccanismi meccanici
dentro Kafka che ti permette di persistere
dati per un certo periodo di tempo così noi
ho visto tutti i nostri set di dati principali che creiamo
backup backup copia il link li strappo e
abbiamo copiato nel cloud così ora se noi
voglio ripristinarli speriamo che lo farà
sarà molto più facile che possiamo sapere
scopri cosa è stato cancellato, copia
quel set di dati e rielaborare da lì
invece di tornare indietro
caricare i log grezzi utilizziamo anche le istantanee
sì è giusto che è anche un altro
come se ci fosse una caratteristica interessante Schneider
istantanee che in pratica significa che tu
non posso leggere facilmente l’istantanea elite che
fondamentalmente ti impedisce di fare
tutto almeno ti farai no
avviso nessun errore che tu ti conosca
non posso cancellare tutto perché c’è
un’istantanea lì e così è anche come
una bella funzionalità ma usiamo lo snap facciamo
e divertente piccola storia sulle istantanee
eravamo così eravamo nel nostro negozio che facciamo
tipo di stile di misfatto e abbiamo avuto un
demo sprint con molti dei nostri
le parti interessate nella stanza e noi eravamo
parlando di come abbiamo fatto istantanee e
come renderebbe più difficile per alcuni utenti
cancellare accidentalmente le sue squadre di pneumatici
directory in modo da implementare questa funzionalità
e tu sai che ci siamo testati nel nostro
pre-produzione
ha funzionato bene abbiamo deciso che nel nostro
demo che stavamo per lanciare sul
ambiente di produzione ma con noi
non aveva parlato di era in realtà
dovremmo testarla su una produzione
ambiente anche così uno dei nostri ingegneri
tipo è andato un po ‘canaglia Edo e lui
ho deciso di sapere che tu sai che ho letto
a questo proposito funzionerà, quindi è così
proprio lì davanti a tutti
lui è come ok eliminare root e c’era
circa un secondo o due eravamo seduti
lì come oh oh no oh no cosa sta succedendo
per caso e per fortuna ha detto che lo sai
non puoi farlo a causa di istantanee
quindi è stata una demo di successo ma probabilmente
un po ‘inutile che potremmo avere
fatto in pre-produzione proprio come
facile penso che siamo contenti che tu non l’abbia fatto
devo imparare dal fallimento lì perché
non ti sentiremo oggi, quindi tutto
tutti ringraziano per favore ricordati
per inviare una valutazione e anche ricordare se
hai altre domande o feedback
dai a questi ragazzi che puoi metterlo in
app e andrà tutto bene
grazie a tutti
tu
questo discorso andremo a illustrare il
evoluzione di Hadoop a 45 anni indipendentemente
del motivo per cui sei qui e forse
sei qui perché hai il tuo
Cluster o forse si vuole costruire la vostra
nuovo cluster o forse vuoi solo
impara bene Hadoop, speriamo
questo discorso ci sarà utile per
voi, perché abbiamo intenzione di portare con
esempi reali di incidenti e
problemi e bug che abbiamo avuto e come noi
affrontali a spotify ma per favore mantienili
in mente però che ogni singolo cluster
è diverso quindi cosa può non funzionare per noi
lavoro per te ma speriamo che la prossima volta
vedi un problema simile che puoi fare
questa conoscenza e rendere più guidati dai dati
decisione sui tuoi problemi prima di noi
immergiti nei dettagli anche se prima di tutto
presentarci quindi sono rafal e
questo è josh schivare il proprietario del prodotto e
Sono un ingegnere di tutta la squadra Hadoop e
entrambi ci innamoriamo di Hadoop
circa due anni fa quando ci trasferiamo nella nostra
bellissimo ufficio di Stoccolma e noi
iniziato a sostenere questo uno dei
i maggiori cluster di Hadoop in Europa e
era una grande responsabilità ma anche
grande privilegio così ora che tu
sai chi sei diamo un’occhiata a
l’agenda del discorso così prima di tutto
andando a parlare delle questioni il dolore
indica come stavamo cercando di mantenere il nostro
cluster in funzione e poi ci guadagneremo
messa a fuoco stabilizzerà il cluster e
poi alla fine lo finiremo duro
con il futuro e le nostre caratteristiche attuali
della nostra infrastruttura quindi diamo
è partito sicuro per cominciare, dice
menzione di Rafal che inizieremo
parlando dell’inizio dei big data
a individuare quando abbiamo iniziato con
Hadoop ma prima di farlo lo siamo
intenzione di tornare indietro di un secondo e parlare
su cosa sia Spotify, mi rendo conto che è così
probabilmente abbastanza conosciuto in
Scandinavia, ma nel caso lo fossimo
tutto nella stessa pagina Spotify è una musica
servizio di streaming alcune persone pensano di
è come iTunes sul cloud è tutto
è stato lanciato nel 2008 ce ne sono due principali
livelli di livello gratuito e un livello premium
questo costa circa 10 anni al mese
dà pieno accesso a tutti i nostri cataloghi
di canzoni è disponibile in 58 paesi
Ho appena visto oltre 48 di quelli
paesi diritti
flusso medio oltre 1 milione di stream
al giorno alcuni numeri mensili che abbiamo
oltre 75 milioni di utenti attivi mensilmente
quegli utenti chat scelgono da un catalogo
di oltre 30 milioni di canzoni oltre 4 milioni
artisti e si combinano per giocare
1 milione di flussi ogni giorno, quindi questo è un
molti dati e perché è molto
dati abbiamo dati piuttosto massicci
infrastruttura per elaborare su di esso noi
appena aggiornato abbiamo aggiunto altri tre o
quattrocento nodi ci siamo alzati in giro
1.700 nodi pensiamo che siamo probabilmente il
il più grande cluster Hadoop in Europa se
non ci piacerebbe sapere quanto è grande
il tuo cluster Hadoop è 62
petabyte di storage superiamo i 30
terabyte di log in arrivo ogni giorno
generato dagli utenti eseguiamo circa 20.000
Hadoop lavori al giorno e quei lavori
generare oltre 400 terabyte di dati così
ci sono molti dati che potresti essere
chiedendo cosa facciamo con tutti quei dati
ora fammi fare una domanda molto veloce è
c’è qualcuno qui che è un corridore
va bene se Spotify sei fortunato
qualche mese fa abbiamo rilasciato questo nuovo
applicazione una nuova funzionalità all’interno del
applicazione che è un’app in esecuzione e
ciò che è veramente interessante è questo
ti dà una lista suonata personalizzata basata fuori
il tuo tempio in corsa l’abbiamo trovato
in realtà correndo con un battito quando sei
a ritmo con la cadenza migliora
prestazioni fino al quindici percento
e ciò che è veramente grande è che noi
unisci le tue abitudini di ascolto al tuo
abitudini di ascolto personale e il
caratteristiche di tutte le canzoni che
ti piace ascoltare cose come la
l’umore e l’energia insieme alle canzoni
essere autorizzati a generare un mucchio di a
diverse playlist di esecuzione personalizzate
familiare in musica interessante ad ogni
battere al minuto per tutti i nostri utenti attivi
un’altra caratteristica che abbiamo di recente
lanciato che potresti avere familiarità con
se gli utenti di Spotify chiamano discovery
settimanalmente sono due ore di personalizzazione
musica consigliata consegnata ogni lunedì
per tutti i nostri 75 milioni attivi mensilmente
utenti e questo è stato davvero uno dei
le nostre funzionalità di maggior successo che abbiamo
mai lanciato ogni lunedì otteniamo a
flurry di nuove attività come Twitter
che dicono quanto è grande la loro playlist
settimana e quanto meglio era il migliore o
se siamo in ritardo con i dati otteniamo a
un sacco di lamentele su Twitter su come
la loro playlist non è ancora lì così noi
sappi che è davvero importante per il nostro
gli utenti dietro le quinte è in esecuzione a
varietà di machine learning differenti
tecniche che si basano tutte su
caratteristiche estratte dai dati questi
le funzionalità sono piuttosto interessanti ma prima di noi
tuffarsi in loro il suo primo dare un’occhiata a
uno molto semplice quindi questa è una lista in alto
per la Danimarca le 50 migliori canzoni di te
gli utenti stanno ascoltando in Danimarca così
prendiamo, passiamo due secondi e
pensa a come faresti fondamentalmente
implementare questa funzione, quindi se pensi
su di esso il più semplice il più bruto
la soluzione di forza sarà probabilmente troppo giusta
piace lanciare questi dati nel database
e quindi eseguire una query semplice come questa
uno qui in modo da selezionare qualche traccia
ID di alcuni artisti che hai conteggiato
addio hai un limite che hai crogiolato
hai la tua caratteristica proprio carina
semplice il problema è che non appena
si inizia a ottenere questa quantità di dati
di cui parlava Josh ricorda 30
terabyte di dati al giorno che abbiamo
ingerire quindi che inizia ad essere un
problema fondamentalmente quindi sapevamo da subito
l’inizio molto all’inizio che noi
bisogno di qualcosa che scalerà meglio
con la nostra scala della quantità di dati
che stiamo ricevendo e anche i tablas
solo un tipo di rapporto che dobbiamo
creare molti rapporti diversi di
quei diversi calcoli che noi
dobbiamo fare sui dati quindi dobbiamo essere
flessibile quando si tratta del tipo di
i calcoli che stiamo facendo e il terzo
motivo per cui riceviamo dati diversi da
diverse fonti in un altro
struttura quindi dobbiamo essere flessibili
sui dati e la struttura di esso
abbiamo basato qualcosa come Hadoop e
è per questo che abbiamo iniziato a giocare con a
nel 2009, quindi molto molto lo sai molto
all’inizio della vita di Hadoop e
abbiamo avuto un paio di informazioni a riguardo
fin dall’inizio così fondamentalmente ora noi
sappi che è abbastanza scalabile
bene e poi è flessibile e quando lo fa
arriva a che tipo di usura ti segna
voler eseguire su di esso e anche del
in realtà è un intreccio con il preside
flessibile e arriva a quale candidato I
voglio conservarci sopra ma poi c’è stato
anche un altro risultato interessante che è
Lo streaming Hadoop e lo streaming Hadoop lo sono
una caratteristica di Hadoop che ti permette di
implementare lavori MapReduce in una lingua
diverso da Java
e quello era importante per lei
Spotify perché Spotify era allora a
grande negozio di Python che ci permette di
prendere questa vasta conoscenza di Python
e mettilo sopra Hadoop e poi noi
iniziato a implementare questo è intensivo
pipeline usando Python e fondamentalmente noi
ho un sacco di informazioni e dati e questo
ci consente di prendere decisioni basate sui dati
e fare di Spotify un tale successo
è oggi ma ad essere sincero mi manca
un pezzo importante della storia che sono
dicendo che sì puoi scrivere questi
condutture e puoi farlo dentro
e puoi fare molte conoscenze ma
primo problema che probabilmente stai andando
ottenere è come spostare i dati su Hadoop
quindi sembra un semplice problema
beh, lo sappiamo solo memorizzarlo su HDFS
questa è la soluzione semplice, ma è così
in realtà non è così facile, prendiamoci un
guarda questo problema da Spotify sper
spettivo quindi a individuare questo abbiamo
nozione di punti di accesso che sono
macchine a cui tutti i client si connettono
quindi ogni volta che apri il tuo cliente e
vuoi richiedere la playlist o
qualsiasi cosa vogliate averne
servizio di back-end si passa attraverso il
punto di accesso e ogni volta che si richiede
qualcosa dall’accesso per un accesso
il punto lo registrerà su quello specifico
macchina in un formato separato da tabulazioni e
per questo è tutto
introduce un sacco di un tipo specifico di
problemi così il primo è che i dati
è abbastanza crudo e sporco, quindi dobbiamo
assicurati che le nostre pipeline ETA siano
solido e quello che ci assicuriamo
ogni singolo disco è pulito e quello
in realtà non è così semplice
valori celebrati un’altra cosa se tu
avere un valore separato da tab bene
l’evoluzione dello schema non è così semplice e
è specificamente difficile da individuare
perché abbiamo un sacco di piccoli team e
se vuoi cambiare qualcosa nel
struttura se si desidera aggiungere un campo o
rimuovi bene il campo devi parlare
a molte squadre diverse e non lo è
non comune per una squadra cambiare qualcosa
senza parlare con nessuno e poi tu
conoscilo solo avendo un
incidente a valle nella pipeline così
questo è un altro problema, c’è un altro set
di problemi e avrò perché noi
avere un cluster rigido solo un giorno
centro a Londra dobbiamo spostare tutto il
dati in un unico posto a Londra e
che introduce nei problemi con
networking e cosa succede se ci f
un duplicato di dati che dobbiamo duplicare
più tardi, così avanti
quindi dato il problema e abbiamo iniziato oh
c’è anche un altro problema importante
a spotify trattiamo molto bene i nostri log
con attenzione e dovremmo essere sicuri
che li prendiamo tutti perché trattiamo
loro come le transazioni finanziarie perché
dobbiamo ripagare i nostri artisti e
assicurarsi che siano soddisfatti
individuare così i registri sono super importanti per
noi così con quel problema che abbiamo implementato
la nostra prima iterazione che era log
archiviatore e quella soluzione in realtà
è durato molto a lungo in modo che l’acido sociale
dal 2009 2013 e rimarrai sorpreso
perché era molto banale, era solo
un insieme di script Python che lo faranno
in pratica comprimi i log e poi lo sono
dicendo o file SCP tra macchine tutto
il modo di aggiungere al data center di Londra
e che i lavori saranno sostanzialmente incoronati
e fondamentalmente aveva un sacco di problemi e
che tipo di problemi bene perché lo era
affogato e perché era banale
serie annuale di script Python che vorresti
fallire molto non era corretto
il monitoraggio non c’era avviso adeguato
quindi ogni volta c’era un problema nostro
i motori dovrebbero andare a uno specifico
i file SCP del data center manualmente tutti i
modo di aggiungere a Londra e assicurarsi che
tutti i log ci sono e se dovessimo
scala i nostri punti di accesso che dovevamo aggiungere
più macchine o dobbiamo rimuovere un
punto di accesso che sarebbe un altro
lavoro manuale e manuale per i nostri ingegneri
è stato un enorme magnifico fallimento ma
anche prima di bruciarlo era troppo
Devo anche introdurre una parte importante
della cultura di Spotify e questo è meglio
riassunti da due parole abbracciano il fallimento
questo è abbastanza semplice quando
stai fallendo stai imparando molto
stai imparando molto di più di se
sei molto conservatore e
muoversi lentamente e avere paura di fallire così
nel caso del log archiver, in realtà
imparato molto abbiamo imparato molto
cosa non fare con la consegna del registro per
esempio non lo fai contare su cron
se vuoi espandere i tuoi nodi e
scala in tutto il mondo
fallimenti e apprendimento o apprendimento
guidato la nostra prossima generazione di log
consegna che abbiamo costruito in cima a Kafka
ora lascia che ti chieda un’altra domanda
in nessuno c’è qualcuno che usa Kafka
il loro volume di produzione
in questa stanza è Ed è nessuno familiare
con esso ok così Kafka è fondamentalmente un
sistema di accodamento messaggi che era aperto
fonte da linkedin che ha un
modello di pubblicazione-sottoscrizione o turni di Kafka
consumatore produttore, quindi ne abbiamo provati alcuni
diversi sistemi di messaggistica quando eravamo
valutare la prossima generazione del nostro
registro di consegna e abbiamo trovato abbastanza presto
su quello Kafka aveva appena funzionato il meglio
abbiamo avuto una latenza dal nostro accesso
punto come rafal menzionato per il nostro HDFS
cluster andare da ore giù per i secondi
e questo ha aperto una grande varietà di nuovi
utilizzare i casi che potremmo fare con i dati
per esempio l’ elaborazione in tempo reale con
Apache storm quindi è un po ‘semplice
immagine di ciò che la nostra architettura sembra
così abbiamo i 30 terabyte di dati
questo è generato dagli utenti che si connettono
ai nostri punti di accesso e questo è passato
lungo il lato del sito per le cernie locali
consumare tutti gli eventi prodotti dal
punto di accesso li comprimono
crittografare li mandano su internet
a Londra dove viene consumato
il nostro cluster Hadoop quindi saremo belli
onestamente abbiamo avuto molti problemi
anche questo sistema di consegna dei registri, ma questo è
L’enigma era molto legato al sistema kafka
che stiamo usando stiamo usando Kafka 0.7
che è un’architettura un po ‘più vecchia
ed è anche dovuto al fatto che noi
avere il sistema di consegna Ende Ende
abbiamo costruito su Kafka davvero
ci consente di ottenere la consegna affidabile
perché questi registri come abbiamo detto sono carini
importante ma il nostro sistema di consegna dei registri è
in continua evoluzione come in ogni nuovo
problema che abbiamo colpito e in effetti proprio adesso
stiamo valutando a
gruppo di diversi sistemi di consegna dei registri
quindi possiamo migliorarlo e correggere alcuni dei
bug che esistono nel nostro sistema così ora
che abbiamo dati dentro di te
potrebbe voler iniziare a fare i dati come te
potrebbe voler iniziare a fare qualcosa con
dati in modo da eseguire alcuni lavori e si potrebbe
programmali ad esempio come nel crimine
come questo e eseguire i lavori di
tempi prevedibili potrebbero funzionare
inizialmente ma cosa succede
se il tuo precedente lavoro fallisce, non lo fai
vuoi elaborare dati incompleti
perché in realtà è peggio di
il processo non ha funzionato affatto
perché avrai risultati incoerenti
giù il tuo oleodotto di fronte a questo
sfida uno dei primi ingegneri a
il suo nome era eric berne hudson
affrontarlo creando un nuovo strumento
chiamato luigi perché gestisce a
impianto idraulico di lavori Hadoop e anche perché
è verde e lo schermo di Spotify è così
bello, quindi è Luigi un flusso di lavoro
orchestratore che è scritto in python
che ti consente di definire un lavoro
dipendenze programmaticamente quindi se per
ad esempio nel calcolo regalità tua
la pipeline di calcolo delle royalty dipende
upstream su alcuni lavori ETL sta per
assicurati che quelle dipendenze siano
completa prima di eseguire la royalty
lavori di calcolo se non è completo
pianificherà quindi è stato un
progetto di grande successo che è stato il primo
open source di Spotify nel 2011 è utilizzato
in tutto il mondo a centinaia di
aziende diverse che stiamo trovando nuove
quelli ogni giorno compresi alcuni
quelli veramente grandi come Foursquare e
striscia sfortunata non ne abbiamo così tante
tanto tempo per scendere nei dettagli
di Luigi ma se ti interessa
questo ti invitiamo a andare al
github pagina laggiù e check it out
così ora che abbiamo dati su HDFS e noi
avere un programmatore che possiamo pianificare
il lavoro con abbiamo iniziato a ottenere di più e
più ingegneri per elaborare i dati
è stato bello e ciò che viene fornito
ingegneri che sono perfetti io ci sono
feedback c’è una buona pace e
feedback positivo e anche costruire
costruire un feedback negativo costruttivo
e uno di questi era che non ci sono dati
catalogo quindi è difficile trovare set di dati
su HDFS e ogni tanto a
l’ingegnere dovrebbe andare su HDFS e
meno alcuni LS di alcune directory e
forse al taglio annuale è così piaciuto
questo caso cercando la barca sul
data lake ogni singola esecuzione di questo
Cliente HDFS vorrebbe un paio di
secondi perché deve caricare una JVM
librerie fluenti e così via e così via
quello era il punto dolente per gli ingegneri
e perché ci piace sperimentare che abbiamo
deciso che sperimenteremo con il
Protocollo RPC in HDFS ed è così
un altro progetto open source
ecco perché se fossi nato e così fosse
morso di serpente standby era originariamente
creato ma da wouter il raggio e in
in poche parole è fondamentalmente un puro
client HDFS Python che significa che
c’è tutto quello che succede dentro Python
nessun java sta accadendo in questo client e
in realtà è molto semplice e molto
intuitivo quando si tratta di una lettura semplice
operazioni su HDFS e quanto è veloce
lascia che ti mostri su un’altra diapositiva così qui
puoi vedere 100 esecuzioni di vaniglia
Client HDFS in alto e in basso puoi vedere
esecuzioni a una mano di client di morso di serpente
e puoi vedere che sono circa 10
volte più veloce e quindi vaniglia HDFS
cliente che è abbastanza bello ma buono
è anche un bello è che sarà effettivamente
usa meno risorse di Vanilla HDFS
client userà meno memoria e meno
CPU e questo è in realtà abbastanza utile
soprattutto se hai un servizio
interagisce con HDFS molto e come Spotify
in realtà abbiamo un servizio secondario ed è
luigi perché luigi in realtà da programmare
i posti di lavoro che dovranno fare un sacco di
esistenza ogni X su HDFS e quando tu
iniziare a gestire decine di migliaia di posti di lavoro
che può effettivamente caricare le macchine
su cui esegui lo scheduler e noi
in realtà ha avuto questo problema quindi abbiamo deciso
che passeremo dal client HDFS a
scommettere sul mio cliente e su ciò che abbiamo notato
subito dopo è quello nostro
i controlli sono più stabili sono più veloci e
programmare i libri più prontamente che è
carino e ti incoraggio a prendere
uno sguardo alla pagina github e una ricerca
per morsi di serpente così ora che abbiamo avuto un
cluster orribile attivo e funzionante e noi
avere il kafka che sta caricando i dati in
Hadoop e abbiamo alcuni strumenti come Luigi
e morso di serpente in modo che tutti gli sviluppatori
attorno a Spotify potrebbe accedere ai dati
ed eseguire i lavori Hadoop che abbiamo iniziato a correre
in esso un nuovo problema e questo era quello
gli sviluppatori in realtà stiamo correndo molto
di posti di lavoro stavano correndo sempre di più
lavori e loro erano l’importanza del
i lavori stavano aumentando nel tempo e
il problema era che la squadra che
gestito il cluster Hadoop era anche il
squadra che stava scrivendo anche lavori e loro
stavano anche sviluppando e supportando
strumenti come morso di serpente e Luigi e loro
non ha avuto molto tempo per Hadoop
manutenzione se si ha familiarità con
un cluster Hadoop senza tempo per
la manutenzione è un incidente in attesa di
succede e dopo un particolare
incidente particolarmente grave che ha causato
interruzione di più giorni abbiamo deciso che dovevamo
cambiare qualcosa e la decisione è stata
formare una squadra in modo che il team ha iniziato con
Rafal me stesso e un altro ingegnere a
individuare e abbiamo avuto una missione molto semplice
quando abbiamo iniziato la prima parte era quella
dovevamo migrare verso una nuova distribuzione
di Hadoop che includeva il filato il secondo
parte e la parte più importante è stata
che dovevamo rendere Hadoop affidabile e
quindi ti starai chiedendo come abbiamo fatto
lascia che ti mostri in questo grafico così nel
la prima sezione è quella in cui Hadoop era
essenzialmente proprietariless a spotify che abbiamo avuto
un sacco di problemi casuali e interruzioni
ha causato tempi morti in giro per l’azienda
Hadoop era una specie di parolaccia
perché anche se era davvero facile
per scrivere ed eseguire lavori sul cluster
non erano così sicuri se sarebbe successo
quando effettivamente hai davvero bisogno del
risultati la seconda sezione è in realtà
quando abbiamo iniziato il team Hadoop su
individuare che ci rivolgiamo a molti dei
frutta a basso impatto e ha iniziato a migliorare
affidabilità subito il terzo
sezioni quando abbiamo aggiornato il nostro Hadoop
cluster a una distribuzione inclusa
filato quindi c’erano alcune complicazioni
coinvolto in quello era tutto così
complicato cambiando le distribuzioni in
il primo trimestre 2014 abbiamo aggiunto il nome
nodo alta disponibilità e anche questo
ha introdotto i problemi da soli
a causa della nostra scala del nostro cluster
nella dimensione, niente è mai stato così facile
come faccio libri come è così nel
terza sezione questo è quando il quarto
sezione credo che questo è quando in realtà
iniziato ad essere abbastanza affidabile e
prevedibile e in realtà eravamo in giro
lo abbiamo fatto creando il nostro burattino
configurazioni che usiamo per controllare
la testa del grappolo fa davvero male alla sella
abbiamo aggiunto un bel po ‘di monitoraggio
avvisando in modo che prima che i problemi accadano noi
erano consapevoli del fatto che poteva
prevenirli e ne abbiamo anche costruiti alcuni
infrastruttura per rendere gli aggiornamenti più facili
quindi in realtà stavamo iniziando a essere
visto come un team di modello attorno a Spotify
perché stavamo davvero migliorando il
affidabilità e vestire i nostri utenti
i più grandi problemi era tutto a posto
tranne che alla fine puoi vedere l’ultimo
bar e questo è l’ultimo quarto e tu
può vedere un calo significativo in
disponibilità del nostro cluster Hadoop e
questo è principalmente a causa del nostro processo di
ridimensionamento del cluster Hadoop da 1.200 a
1700 note e come Josh ha detto di sì
la pipetta che avevamo monitorato e
avvisando e potremmo prevenire qualcosa
che sapevamo ma come si scopre
c’era un’altra classe di problemi
stiamo iniziando a guarire c’era una classe
di problemi erano fondamentalmente bug in Hadoop
un codice quindi la lezione è che quando noi
quando ridimensionate Hadoop, ridimensionate anche il
nascosto indietro che viene nel codice e in
il nostro caso vengono e possiamo vederli
non appena iniziamo a ridimensionare, facciamolo
Dì 1200 note così in questo caso puoi
vedi due problemi specifici che sono super
mortale per noi ma in termini di piccolo
i cluster non sarebbero davvero quello
mortale o non costerebbe tempo morto
nei nostri casi, fondamentalmente entrambi
ha portato l’intero cluster verso il basso
di un giorno quindi diamo un’occhiata al
primo numero per esempio così nel primo
problema ed è un problema con i file aperti
e failover così quando fallisci con uno
il nome guarda ad un altro in hia set up
e per essere attivo, la modalità denominata dovrà
passare attraverso tutti i file aperti assicurarsi
che sono ancora aperti e validi
il processo è stato implementato molto male
modo in cui era modo molto inefficiente per
implementalo e l’intera descrizione
è nel codice in un piccolo cluster che
non sarebbe un problema nel nostro caso in cui
abbiamo migliaia di decine aperte di
migliaia di file aperti in qualsiasi dato
punto che fondamentalmente porta il tutto
cluster in giù ciò che è divertente è che quando
noi quel problema ci ha effettivamente fatto passare
da una versione all’altra da 22 a
2.6 in realtà subito dopo l’aggiornamento noi
imbattersi in un altro problema il secondo
che permette in realtà anche portato il
intero cluster in basso ed è anche correlato
a un failover e quindi ricorda quando tu
scalare come cluster anche scalare il
scatola nascosta nel codice sì sì lì
sono stati un sacco di bug che ci siamo imbattuti in
che erano nel taglio Hadoop c’era
anche molte delle prime sfide che noi
incontrato solo con il nostro maiale
configurazione e sono necessari per
adattarsi costantemente al cambiamento ma lì
c’erano anche alcune cose e alcuni problemi
che ci siamo imbattuti in quello erano totalmente uno
cento percento evitabile come parlerò
in questo momento così un po ‘più di un
l’anno scorso la squadra del dupe stava facendo un
bel lavoro e ne siamo rimasti piuttosto orgogliosi
dell’affidabilità del nuovo cluster
e il successo che abbiamo avuto e
intorno alla compagnia conosci persone
venendo da noi e loro stavano dicendo
stai facendo un ottimo lavoro così noi
pensavo che saremmo andati a festeggiare e abbiamo deciso
per andare in un bar a Stoccolma e tu
sai avere un buon paio di birre e solo
celebrare il nostro successo così quando eravamo
camminando verso questo bar abbiamo tutti avuto un
messaggio in arrivo sui nostri telefoni che apriamo
su e il titolo ha detto qualcosa di simile
questo penso di aver sbagliato ora quando
apriamo l’e-mail ci siamo resi conto che
uno degli utenti di New York aveva eseguito a
comando sul cluster che appare
qualcosa del genere ora forse qualcuno
posso vedere cosa c’è che non va qui, forse ora
forse ora quando quando realizzo il
problema ho alzato gli occhi e l’ho vista falsa
faccia ed era come questa madre di dio
cos’hanno fatto così è venuto fuori
l’utente a New York aveva accidentalmente
metti uno spazio nel comando che era
correre tra il nome della sua squadra e
la cartella che lui in realtà voleva
cancella e ha cancellato il suo intero
la directory dei dati del team era oltre un
petabyte di dati raccolti
mesi e mesi di piuttosto intenso che faccio
elaborazione quindi siamo stati lì a
il marciapiede nella soleggiata Stoccolma e
stiamo cercando di decidere cosa facciamo
dovremmo tornare in ufficio chiuso
giù Hadoop prova a recuperare alcuni dei
blocchi prima che diventino permanentemente
cancellato o continuiamo semplicemente sul
bar e sai che occupartene domani
fingere di non averlo visto
fortunatamente non abbiamo dovuto farlo
prendere questa decisione perché un altro utente
dalla stessa squadra di questo ragazzo in New
York ha risposto al thread dicendo di no
preoccuparsi cato possiamo effettivamente
rigenerare alcuni dei più critici
i dati in pochi giorni lo conoscete
abbiamo appena risparmiato un sacco di spazio lasciandola fare
cluster così da questo abbiamo imparato alcuni
lezioni davvero importanti la prima
è dai nostri colleghi là fuori lui
dice sempre che questo è seduto sulle tue mani
prima di digitare sai soprattutto se
stai rimuovendo il cestino in HDFS
o stai usando una specie di super utente
sai prima di premere il tasto Invio
assicurati che ciò che hai digitato sia effettivamente
cosa vuoi eseguire sul cluster il
la seconda è che gli utenti vogliono sempre
conservare i loro dati e come abbiamo scoperto in
in questo caso specifico conosci questa squadra
potrebbe rigenerare tutto il loro reclutatore
detto atta e hanno davvero bisogno solo di un
porzione parziale di quel petabyte
dei dati e se lo sapessimo in anticipo
se li avessimo effettivamente sfidati a
un po ‘più difficile che avremmo potuto salvare a
sacco di soldi e spazio su un cluster e
costa il terzo è quello che dovresti
rimuovi i super utenti dal tuo nodo periferico
se hai familiarità con i super utenti loro
fondamentalmente hanno assi globali che hanno
super autorizzazioni sul tuo cluster Hadoop
ed è Spotify che abbiamo questo lo sai
Ideale svedese di uguaglianza e noi
avere ciò significa che tutti gli ingegneri di
la società ha accesso sudo al
macchine che hanno accesso a così se
questo utente aveva usato il superuser e aveva
quello spazio un po ‘ prima nel
comando di conoscermi e Rafal potrebbe non
essere qui dando questo discorso oggi così il
la quarta lezione che abbiamo imparato è quella commovente
nel cestino è in realtà un lato client
implementazione un dupe e in morso di serpente
non l’avevamo ancora implementato così noi
festeggiamo un piccolo fallimento che abbiamo fatto a
piccolo hacking e ora puoi tranquillamente
rimuovere dal morso di serpente che era carino
gambo pulito e divertente ma pochi
settimane dopo ce n’era un altro
quindi abbiamo avuto questo consulente esterno /
giochiamo a fi e il suo obiettivo era fondamentalmente
certificare il nostro cluster che significa questo
lui passerebbe attraverso tutto il diverso
parti della configurazione del clustering
fuori da
dire che questa classe è sana o no
e questo è ciò che devi migliorare
i primi giorni non erano davvero belli
liscio e siamo stati un po ‘come felici
di noi stessi e orgogliosi di te
sapere che non ha trovato nulla di simile
sì, stiamo andando alla grande, ma il giorno
numero tre a causa di problemi di comunicazione e
Miss configurazione uno dei compagni di squadra
Abbiamo ucciso il nostro stand per nome nodo e io ero
bene perché è un nodo di nome stand by
tranne poi ce n’era un altro
incomunicabilità e abbiamo ucciso il nostro
Nudo attivo che significa che c’era
nessun maestro ora l’ hdf che significa
non c’è HDFS, il che significa che non c’è
Hadoop non c’è elaborazione e questo
aggiungere le nostre scale significa circa due ore di
tempi di inattività ed è stato specificamente cattivo
perché c’era questo esterno
consulente / giusto ma non era così
quasi come il giorno numero quattro, quindi loro
il numero quattro siamo seduti in un altro
stanza c’è dis cos Alton c’è il
squadra e ci sono i nostri manager e noi siamo
parlando l’incidente e complessiva
sulla certificazione del consulente
sta dicendo qualcosa sulla falsariga di
il fatto che i nostri test e
le procedure di implementazione sono come wild wild
a ovest e questo è stato molto difficile
ascoltare, ma alla fine aveva ragione
e lo sapevamo subito dopo
incontrare l’intera squadra è andato in una stanza
e abbiamo deciso che non lo faremo
lascia la stanza finché non arriviamo a
piano per risolvere sostanzialmente questo problema e
abbiamo trovato qualcosa che potrebbe essere
in realtà piuttosto semplice e ovvio
tu che è un cluster di pre-produzione
e il cluster di pre-produzione è realizzato
della stessa classe di macchine esattamente
la stessa classe di macchine molto
configurazione simile quasi identica
e abbiamo creato una serie di test del fumo che
possiamo finire quella pre-produzione
cluster assicurati che ogni parte
di quel sistema è ben integrato e
funziona perfettamente bene e quindi possiamo usare
che entrambi fumano questa produzione di NP
cluster per distribuire le modifiche prima a
pre-produzione quindi intorno al fumo
il test ottiene un feedback immediato e quindi
decidere se vogliamo realmente
distribuire o non modificare effettivamente il
modo in cui testiamo e distribuiamo in produzione
che funzionano abbastanza bene come specificamente
ad esempio per il nostro recente aggiornamento siamo
in grado di scoprire attraverso di essa ai problemi
probabilmente ciò probabilmente causerebbe
un grave incidente sulla produzione se
non l’abbiamo scoperto prima
mentre la squadra Hadoop stava cercando di farlo
rendere l’infrastruttura stabile e lo è stata
lavorando alla pre-produzione di tutto questo
di roba ce n’era un altro e c’era
un altro sforzo per andare nei dati e quello
doveva passare da Python a JVM così come noi
detto prima di ragazzo se fossi un grande pitone
negozio e abbiamo implementato un sacco di
pipeline in Python su un Hadoop
streaming e nel tempo che ci siamo resi conto
questo è un problema perché abbiamo iniziato
vedere un sacco di fallimenti di questo
tipo di condutture perché ogni volta
qualcuno ha fatto il cambiamento in Python
codice è stato molto difficile cambiare test
così la gente fondamentalmente la butta al
cluster con le risorse di rifiuti solo per
ottenere un feedback se hanno fatto errori di battitura in a
codice o no o forse c’è una discrepanza
nel tipo a causa della natura di
Python era una classe di problemi
un altro era che c’era fondamentalmente
nessuna infrastruttura di test quindi le persone
getterebbe fondamentalmente una linea di tubi a
il gruppo e anche il
la performance non c’era, così è
a causa della natura e dell’architettura
di Hadoop streaming e anche Python
stesso così uno degli ingegneri di
individuare lo sbiancamento di David ha fatto un ampio
panoramica di tutti i quadri che puoi
usa su hadoop e puoi trovare i link
qui e poi dopo con me noi
c’è stata una discussione su tutto il
quadri e abbiamo deciso che lo faremo
scegli apache grunt come supportato
framework per eseguire MapReduce un batch
posti di lavoro a spotify e c’era una coppia
di ragioni dietro di esso sto andando portare in su
tre di loro che pensiamo siano nel
i più importanti quindi il primo è
che si ottiene il tipo reale in modo da ottenere il tipo
sicurezza che significa che puoi ottenere un
errori in fase di compilazione che non è necessario
lanciare il lavoro nel cluster per verificare
che è un lavoro vero senza
errori di battitura o uno schema non corrispondono a un altro
ottieni una torta di alto livello che significa
che puoi iniziare a pensare in termini di
gruppo di disegni acquista gruppi di chiamata sul nostro
tipo di fantasia a funzioni invece di
pensando in termini di questa vecchia mappa e
ridurre un paradigma che è molto bello e
rende l’intera pipeline meno dettagliata
e più facile da mantenere nel tempo
diversi ingegneri quindi il terzo
la ragione è la performance stessa e
che proviene da JVM e prendiamo un
guarda il grafico qui, quindi su questo
grafico che puoi
vedi il punto di riferimento di crunch e Hadoop
streaming e questo è un punto di riferimento per
il nostro carico di lavoro di produzione quindi questo non è un
sintetico questo è il nostro questi sono i nostri
carichi di lavoro di produzione e questo specifico
graph è una mappa di throughput in
puoi megabyte al secondo a sinistra
vedi lo scricchiolio a destra puoi vedere come
nuoto tubolare e puoi vederlo
Il crunch di Apache è circa 8 volte più veloce
in media e i nostri quasi settantacinque
percentuale di tutti i lavori di crunch di Apache
sono più veloci di tutti gli streaming Hadoop
lavori che è una buona ragione per
passare a JVM e anche noi siamo stati in grado di farlo
ha escogitato un test abbastanza carino
ambiente per Apache crunch in cima a
un mini cluster che in pratica significa ora
possiamo imporre ai nostri sviluppatori di creare
prova anche per le teglie a torta
molto bello e così è stato un sacco di
evoluzione, quindi rivediamo rapidamente
di cosa abbiamo parlato così all’inizio
discusso le difficoltà di pari
ottenere dati nel nostro cluster HDFS e come
lo risolviamo usando Kafka e poi abbiamo parlato
su alcune delle sfide che abbiamo avuto
quando stavamo iniziando per la prima volta
scrivendo lavori di Duke e usando cron come
programma e come risolviamo quelli usando
strumenti come Luigi e morso di serpente poi noi
parlato di alcuni dei problemi che noi
aveva presto con disponibilità e come
risolviamo la creazione di una squadra che era
davvero concentrato sull’Hadoop
solo l’infrastruttura e anche come noi
migliorare l’affidabilità facendo cose
come il mio monitoraggio e allerta adeguati
poi Rafael ha recentemente parlato di come noi
abbiamo iniziato a concentrarci davvero
prestazioni e migliorare spostando le cose
da Python e Hadoop streaming a
Apache crunch e quest’ultima sezione
parleremo del futuro voi
so a cosa stiamo lavorando ora cosa
stiamo pianificando di concentrarci su
i prossimi sei a 12 mesi a Hadoop
Spotify quindi questo è il grafico del
la crescita di Hadoop rispetto a fine Spotify
utenti dal 2012, quando Spotify aveva appena
ha attraversato oltre 10 milioni di utenti così da allora
quella volta Spotify è cresciuto di seicento
e il cinquanta percento che è piuttosto grande
crescita ma la crescita dell’utente no
confronta tutto con la crescita dell’utilizzo di Hadoop
la crescita
e richiesta di risorse di calcolo a
spotify quindi è cresciuto
quattromila per cento come potresti vedere
quindi ciò che ha causato così tanto crescita ora noi
attributo sono le tre cose principali
il primo è abbastanza ovvio con
maggiore visibilità degli utenti finali che stai andando
avere molti più dati tutti quegli utenti
stiamo ascoltando molto più canzone che
significa che tutta la pipeline è quella che tu
hai usato cose simili?
le condutture tascabili e la
i grafici migliori devono essere elaborati molto
più dati e hanno bisogno di molto di più
calcolare le risorse di risorse per farlo
il secondo è aumentare i casi di utilizzo così
quando abbiamo iniziato con Hadoop a
spotify lo abbiamo usato solo per l’analisi
e stiamo segnalando condutture che non abbiamo fatto
usarlo per un sacco di cose in questi giorni noi
usalo per potenziare funzioni come il
la scoperta settimanale è tutto alla fine
guidato da Hadoop e tutti questi enormi
apprendimento automatico e elaborazione grafica
posti di lavoro e abbiamo davvero visto tutto
i diversi casi d’uso significano che tu sei
sta andando a correre molti più lavori e
Avrai bisogno di molto di più
potenza di elaborazione l’ultima è
in realtà davvero interessante quindi abbiamo
aumentato un sacco di ingegneri che
Spotify quel processo su dati e
questo è che la crescita è guidato molto in
2014 Spotify ha acquisito questa società
chiamato il nido di eco che ha sede in
Boston gli Stati Uniti sono la loro compagnia musicale
è solo ossessionato dalla musica
intelligenza e prima che giochino a
Spotify in realtà non usano mai Hadoop
ma quando hanno iniziato e aveva accesso ai
il nostro tesoro di dati dell’utente loro
è diventato appassionato e ora c’è un po ‘di
i nostri utenti più pesanti ed eseguire alcuni dei
i lavori più impegnativi ora vengono appresi
tutta questa crescita non è ciò che abbiamo imparato
attraverso questa crescita è importante
la realizzazione è quella di ridimensionare le macchine
è in realtà un tipo di facile e abbiamo
avvisi abbiamo il monitoraggio corretto
monitoraggio abbiamo pupazzo davvero solido
configurazione che ci consente di aggiungere nuovi
macchine sai che è permesso a noi
andare da 120 macchine un po ‘
più di due anni fa alla missione del 1700
quasi 1700 macchine che abbiamo oggi
senza troppi problemi ora abbiamo corso
in alcuni problemi come noi
mentre menzionato con la recente aggiunta
di 400 nodi e in corso o 500 in corso
1200 1700 ma per la maggior parte è
sono state abbastanza fluide ma ridimensionano le persone
questo è davvero molto difficile ora
siamo ancora una squadra relativamente piccola a
spotify ma supportiamo centinaia di utenti
che stanno elaborando i dati e hanno
diversi livelli di competenza da
il principiante per l’esperto e abbiamo
problemi di stare al passo con tutti loro
problemi quindi potresti chiederti cosa siamo
stiamo pianificando di farlo
iniziando ad automatizzare il feedback che vogliamo
fornire informazioni sui lavori di Hadoop a
utenti immediatamente dopo il completamento del lavoro
cose come il tuo lavoro ha fallito con il
errore specifico forse sappiamo di che
Eric può collegarsi al biglietto jira e
forse la soluzione per questo forse è il tuo
il lavoro sta avviando con l’utente sbagliato
permessi quindi proveremo a mettere su
segnale di pericolo prima di eseguire il tuo lavoro così
non sprechi tutto il calcolo
risorse solo per venire con niente
ma perché stiamo lavorando su questo abbiamo
distribuito alcune cose che sono già
aiutandoci e potremmo aiutarti anche tu se
tu stai correndo io faccio il primo è un
progetto chiamato inviso questo è stato scritto
in rilasciato da Netflix un po ‘sopra
circa un anno fa il visto ti permette di vedere
che cosa sta succedendo con un cluster in tempo reale
tempo e fornisci qualcosa di veramente bello
visualizzazioni che lo rendono ovvio per
esempio se un singolo lavoro sta dominando
il cluster e utilizzando tutte le risorse
permetterà anche che ne contenga anche alcuni
strumenti di visualizzazione piuttosto interessanti che tu
può andare giù nel livello di lavoro individuale
e vedere come la vita del lavoro in e
come si comporta e puoi usarlo
per migliorare le prestazioni lavorative lo farei davvero
incoraggiarti a controllare l’altro
la cosa che abbiamo fatto sembra così ovvia
che siamo stati davvero sorpresi di come
efficace è stato così ogni trimestre
pubblica una newsletter che contiene tutto
tipi di informazioni diverse e
statistiche su lavori come Hadoop cose come
la crescita del calcolo Hadoop richiede
aumento dello spazio di archiviazione per i lavori in cui non si verificano i migliori risultati
del cluster o in quel trimestre o in
un mese
o semplice vecchia affidabilità hadoop ora noi
ottenere sempre ottimi feedback in giro
questa newsletter quindi sono ghetto freddo ma a
pochi mesi fa era ancora di più
efficace perché ha identificato un singolo
lavoro che stava funzionando ogni giorno e usando
sprecare oltre il dieci percento dei cluster
risorse perché stava sempre fallendo
ora prima di pubblicare la newsletter
lo usano in questo lavoro, non lo fanno nemmeno
rendersi conto che il suo lavoro era in corso ogni giorno
l’ammasso fallì ma quando vide
il suo nome sulla newsletter sociale
la pressione dei pari solo gli aveva causato ai
vai immediatamente a non pianificare il suo lavoro e
voto a noi che non aveva mai avviato un lavoro
sul cluster Hadoop senza correttamente
testarlo e senza alcun tipo di
certificando con noi così solo dal
pressione sociale tra pari e utente migliorato
prestazione che è stata grande per noi
perché non dovevamo entrare e e
sai manualmente dirgli che lui ha
smettere di fare quella roba che era grandiosa
dal momento che questo è a tutti i dati parlano che abbiamo
per menzionare la scintilla quindi c’è
si accende la luce quindi sì, noi siamo
valutando la scintilla e abbiamo giocato
con esso sin dall’inizio abbiamo avuto
alcuni problemi con esso e abbastanza recentemente
ricorrere ad un esperimento con Apache
Zeppelin in cima alla scintilla di apache così
probabilmente hai sentito parlare di scintilla ma
di quanti ne avete sentito parlare
Zeppelin è cool, quindi ce n’è un paio
persone fantastiche, quindi puoi pensare
Zeppelin come ipython su steroidi su
la parte superiore della scintilla è così buona che ti dà
è che puoi fondamentalmente immergerti nei dati
affetta e tira un po ‘e prendi un
risultato in un bel modo visivo proprio così
è come un’esperienza di un notebook
in cima alla tua scintilla e al modo in cui vogliamo
per usarlo è si vuole usarlo come un
strumento di colla dove puoi connetterti a tutti
i diversi pezzi del nostro
l’infrastruttura recupera rapidamente i dati
processarlo ottiene un bel risultato visivo e
allora l’ingegnere può decidere se
c’è valore in quei dati e se
c’è la necessità di distribuire un adeguato
conduttura pronta per la produzione in cima a
scottature o scricchiolii o altro
è così che è lì che lo vediamo
abbiamo alcuni buoni risultati fin
iniziando e incoraggiarti fortemente a
dare un’occhiata a un partecipante in questo
in realtà ci porta quasi alla fine
che è due take away quindi questo è gentile
della diapositiva più importante del
il discorso quindi due take away uno è quello
non c’è una Golden Path in particolare quando
si tratta di Big Data non ci sono
i modelli ci sono tipo di emergenti
modelli ma gli ingegneri sono un po ‘
definendolo o fino a definirlo così quando
hai un problema quando devi
progettare un sistema e mi occuperò di
dati che ti invitiamo a prendere a
guarda il problema e prova ad implementarlo
nella soluzione più semplice che puoi
cercare di evitare di essere prematuro
ottimizzazione il più possibile, se lo è
un anti-modello in generale rispetto a Big
Dati questo è come la radice di tutti i mali
e poi il secondo take-away è quello
l’evoluzione è un processo continuo così
qualunque cosa tu abbia intenzione di progettare
o lo strumento deve essere giocato via
progettare in un modo che lo renda facile
itera su di esso in modo così semplice da creare
qualcosa poi dovrai farlo di più
probabilmente lo butto via molto presto
subito dopo implementare qualcosa
in alto e devi implementare in a
modo che lo rende facile da scambiare
fondamentalmente così questi sono due tipi di
semplice togliere il suo tipo di tipo di
anche un po ‘generico ma se vieni gentile
di vivere fino a loro e questo lo farà
la tua vita è molto più facile come un Hadoop
amministratore o ingegnere dei dati e così
ci porta all’ultima diapositiva che siamo noi
stanno assumendo e tu sai che abbiamo bisogno
ingegneri a New York stoccolma quindi se
vuoi unirti a noi puoi parlare con noi
dopo o potete scrivere a noi su
Twitter e questa è la fine, va bene
la ringrazio molto Penso che abbiamo il tempo
per domande
va bene grazie ragazzi e così chi lo vuole
inizia questo perché sei tu che ti capita
per essere vicino ciao come si gestisce con FEMA
le modifiche che hai menzionato così questo è un
il problema è un formato come lo facciamo
i cambiamenti dello schema ci sono la domanda
come facciamo i cambiamenti di schema um okay così
la maggior parte è implementata come a
repository di schemi in questo momento in cui noi
avere un progetto chiamato parser lock lock
che fondamentalmente definisce quali sono i
campi e poi ogni volta che fai
una modifica puoi cambiarla in quel registro
parser ma bisogna fare in modo che
tutti sanno di questo cambiamento e di tutto
le condutture che sono a valle sono in aumento
ad oggi con quel cambiamento mmm che no
non funziona davvero tutto il tempo
e nell’architettura più recente
stiamo lavorando su quelli più centralizzati
repository di schemi in cui si desidera recuperare
lo schema da quel repository e
che fondamentalmente dipenderebbe dal
dati che hai nutrito quindi diciamo che tu
voglio elaborare qualcosa da cui proviene
due anni fa e lo schema sarà
fatto in questo rappresenta che puoi nutrire
ma non è in là, non lo è
c’è ancora e non riesco a ricordare se noi
match ma usiamo Patchy Avro in questo modo
aiuta molto, ma ce n’è uno sopra
qui hai menzionato che il cluster era
non stabile all’inizio quale era il
ragione per questo prima di Hadoop
la squadra era iniziata sì, quindi abbiamo avuto un sacco
di diversi problemi erano molti di loro
frutta molto bassa che pendeva come nessuno
gestire la crescita dei dati così ogni volta
tra un po ‘dovremmo espandere il cluster
quando si esaurisce lo spazio su disco e lì
era davvero no, era sempre reattivo
questo era il problema per cui ci saremmo incontrati
utilizzo del disco del novanta per cento che è
tipo di zona pericolosa che perché
significa che i singoli dischi sono uno
cento per cento pieno o hai
singoli nodi che sono sotto
pieno quando è correttamente bilanciato e
questo causerà un sacco di fallimenti di lavoro
e la vendetta si imbatterà in tutto
tipi di pazzi casi limite in Hadoop così
quello era uno dei grandi motivi lì
erano anche altri molto interessanti
problemi che abbiamo incontrato dovrei andare
indietro e guarda ma alcuni errori alcuni
errori di configurazione perché Hadoop non lo è
il miglior codice documentato c’era persino
alcuni parametri di configurazione dove
detto questo questo parametro è millisecondi
ma in realtà si è rivelato essere secondi
e quello come davvero ricordo che era
un grosso problema come lo era anche tutto
specie di piccole dimensioni era una specie di
come un piccolo come josh sta dicendo in a
piccole cose come non c’erano allarmi
quindi per esempio si esaurirebbe lo spazio
lì sui nodi così detti descritti
sarà come se sapessi che il nome morirà
e poi un burattino non stava correndo così
ogni volta c’era un cambiamento per
esempio in rete che era una specie di
serio e non sarebbe propagato
il nodo del nome del plugin all’improvviso no
si può collegare una e-mail che è anche a
problema tutto come un dischetto fallirebbe
come se non avessi un giusto set up
l’aria sulle note dei nomi e altri problemi
così gentile di cose semplici che puoi farti
può fare una specie di lunga sospensione in realtà
erano avvisi erano solo modo
troppi avvisi e erano totalmente
inutile mi ricordo quando ho iniziato
a spotify si inizia la tua e-mail
come poche settimane prima che tu in realtà
il tuo primo giorno e mi è piaciuto finita
10.000 email in come tutte erano
lo sai per nome, nessun disco è pieno
o sai solo che abbiamo finito
problema di apprendimento così tanti avvisi che
è assolutamente inutile e non lo erano
molto specifico come abbiamo fatto in seguito
era un c’era un note di dati di registro morto
anche io e ricordo che abbiamo fatto un
cambiare il tempo necessario
nome per non contrassegnare il nodo dati è morto
e quello era quello che penso il
millisecondi e secondi così nel modo
volevamo allungarlo ma noi abbiamo
reso più breve che ha reso il tutto
la cosa peggiora molto bene sorella ma era lì
c’erano alcuni bug c’erano alcuni
errori di configurazione stavano cercando a lungo
va bene
frutta bassa portata va bene ancora un po ‘
domande va bene quanto è grande il tuo
cluster di pre-produzione in questo momento è 12
nodi e due lo abbiamo ampliato a credo
circa 40 note non va bene oh è solo
recentemente sono state 12 note per molto tempo
ma poi abbiamo dovuto aggiornare di recente
circa ero un mese e mezzo fa o
anche un mese fa quindi abbiamo dovuto fare un salto
capacità perché eravamo 12 nodi in a
centomila trecentomila
settecento nodi era difficile
in realtà spostare i dati lì da fare
test di pre-produzione quindi abbiamo dovuto imbattersi
su capacità penso a circa 30 o 40
nota ma è abbastanza elastico che potremmo
sono tornato giù a 12 non lo so
okay più domande per i ragazzi che corrono
il più grande cluster Hadoop in Europa
lo farai, ragazzi, lo farete
ti prendi a calci quando arrivi a casa
e ti rendi conto di quella domanda che volevi
chiedere tutto bene è come oh
la domanda è se usiamo il fisico
ora è il nostro virtuale così abbiamo
clustering fisico come a in quello
Londra sì sì, io tre avevo davvero un
slide delle specifiche ma abbiamo deciso di farlo
rimuoverlo sì, ma eseguiamo i server dell
1700 abbiamo penso tre diversi
generazioni di server i nostri più vecchi
sono circa tre o quattro anni i nostri più nuovi
quelli che abbiamo avuto altri tre mesi fa
consegnati sono piuttosto muscolosi, corrono
che aggiungiamo abbiamo 12 dischi per macchina
quattro terabyte di disco
e dipendono circa ventiquattro nuclei
missione va bene più domande su
backup sì, è piuttosto divertente
storia di copertina così disconnessa di cui abbiamo parlato
prima facevano effettivamente i nostri backup in questo modo
scriverebbe a HDFS che scriverebbe anche
per amazon penso che fosse s3 così che se
avevamo bisogno di ripristinare potevamo solo
rielaborare i dati da raw sai se
abbiamo mai dovuto farlo davvero
sarebbe una storia diversa perché
ottenendo effettivamente i dati da s3 e
e rielaborandolo con vecchi formati e
roba sarebbe un incubo sì sì, quando
l’abbiamo ucciso, abbiamo dovuto inventare un
nuova soluzione quindi quello che facciamo ora è noi
non copiare i nostri dati grezzi perché salviamo
come la storia recente all’interno di Kafka
ci sono alcuni meccanismi meccanici
dentro Kafka che ti permette di persistere
dati per un certo periodo di tempo così noi
ho visto tutti i nostri set di dati principali che creiamo
backup backup copia il link li strappo e
abbiamo copiato nel cloud così ora se noi
voglio ripristinarli speriamo che lo farà
sarà molto più facile che possiamo sapere
scopri cosa è stato cancellato, copia
quel set di dati e rielaborare da lì
invece di tornare indietro
caricare i log grezzi utilizziamo anche le istantanee
sì è giusto che è anche un altro
come se ci fosse una caratteristica interessante Schneider
istantanee che in pratica significa che tu
non posso leggere facilmente l’istantanea elite che
fondamentalmente ti impedisce di fare
tutto almeno ti farai no
avviso nessun errore che tu ti conosca
non posso cancellare tutto perché c’è
un’istantanea lì e così è anche come
una bella funzionalità ma usiamo lo snap facciamo
e divertente piccola storia sulle istantanee
eravamo così eravamo nel nostro negozio che facciamo
tipo di stile di misfatto e abbiamo avuto un
demo sprint con molti dei nostri
le parti interessate nella stanza e noi eravamo
parlando di come abbiamo fatto istantanee e
come renderebbe più difficile per alcuni utenti
cancellare accidentalmente le sue squadre di pneumatici
directory in modo da implementare questa funzionalità
e tu sai che ci siamo testati nel nostro
pre-produzione
ha funzionato bene abbiamo deciso che nel nostro
demo che stavamo per lanciare sul
ambiente di produzione ma con noi
non aveva parlato di era in realtà
dovremmo testarla su una produzione
ambiente anche così uno dei nostri ingegneri
tipo è andato un po ‘canaglia Edo e lui
ho deciso di sapere che tu sai che ho letto
a questo proposito funzionerà, quindi è così
proprio lì davanti a tutti
lui è come ok eliminare root e c’era
circa un secondo o due eravamo seduti
lì come oh oh no oh no cosa sta succedendo
per caso e per fortuna ha detto che lo sai
non puoi farlo a causa di istantanee
quindi è stata una demo di successo ma probabilmente
un po ‘inutile che potremmo avere
fatto in pre-produzione proprio come
facile penso che siamo contenti che tu non l’abbia fatto
devo imparare dal fallimento lì perché
non ti sentiremo oggi, quindi tutto
tutti ringraziano per favore ricordati
per inviare una valutazione e anche ricordare se
hai altre domande o feedback
dai a questi ragazzi che puoi metterlo in
app e andrà tutto bene
grazie a tutti
tu
Please follow and like us: