Aveva con Apache Storm? Heron piomba in soccorso

L'anno scorso, Twitter ha lanciato due bombe. Innanzitutto, non avrebbe più utilizzato Apache Storm in produzione. In secondo luogo, l'aveva sostituito con un sistema di elaborazione dati interno, Heron.

Nonostante abbia pubblicato un documento che descrive in dettaglio l'architettura di Heron, l'alternativa di Twitter a Storm è rimasta nascosta nei data center di Twitter. Tutto è cambiato la scorsa settimana quando Twitter ha rilasciato Heron con una licenza open source. Cos'è Heron e dove si colloca nel mondo dell'elaborazione dei dati su larga scala?

Heron, un motore di elaborazione dati a grafo aciclico diretto (DAG), è un'altra voce in un campo molto affollato in questo momento. Ma Heron non è un "guarda, anche io!" soluzione o un tentativo di trasformare i motori DAG nell'equivalente per big data di FizzBuzz.

Heron è nato dalle reali preoccupazioni che Twitter stava avendo con la sua ampia distribuzione di topologie Storm. Questi includevano difficoltà con la profilazione e il ragionamento sui lavoratori Storm quando scalati a livello di dati e a livello di topologia, la natura statica dell'allocazione delle risorse rispetto a un sistema che gira su Mesos o YARN, mancanza di supporto per la contropressione e altro.

Sebbene Twitter avrebbe potuto adottare Apache Spark o Apache Flink, ciò avrebbe comportato la riscrittura di tutto il codice esistente di Twitter. (Non dimenticare, Twitter ha utilizzato Storm più a lungo di chiunque altro, acquisendo BackType, il creatore di Storm, nel 2011 prima che fosse open source.) Invece, Twitter ha adottato un approccio diverso: un nuovo framework di elaborazione del flusso con un'API compatibile con Storm. .

A questo punto della nostra passeggiata attraverso un nuovo framework, normalmente passerei attraverso alcuni esempi per mostrarti come si sente il codice nel framework, ma non ha molto senso con Heron: scrivi Storm bolts e tuple esattamente nello stesso modo di lo faresti con Storm. Tutto quello che devi fare per eseguire il tuo codice Storm su Heron è aggiungere questa sezione alle dipendenze del tuo pom.xml:

 com.twitter.heron

 heron-api

 SNAPSHOT

 compile

 com.twitter.heron

 heron-storm

 SNAPSHOT

 compile

Quindi rimuovi il codice Storm e le dipendenze del plug-in di clojure. Ricompila e il tuo codice verrà eseguito su Heron senza ulteriori modifiche necessarie. Semplice! (Per lo più, comunque, ma torneremo su questo.)

Operativamente, l'attuale implementazione di Heron gira su Apache Mesos, utilizzando Apache Aurora, il framework di pianificazione Mesos sviluppato da Twitter (sorpresa!). Da quando ha cambiato tutte le sue topologie Storm su Heron, Twitter è riuscito a ridurre le risorse hardware dedicate alle topologie di un fattore tre, aumentando il throughput e riducendo la latenza nell'elaborazione - non male.

Forse uno degli aspetti più interessanti di Heron è che mentre il codice per esso sarà scritto in Java (o Scala), ei componenti dell'interfaccia utente basata sul web sono scritti in Python, le parti critiche del framework, il codice che gestisce le topologie e le comunicazioni di rete non sono affatto scritte in un linguaggio JVM.

In effetti, nel cuore di Heron, troverai il codice in un linguaggio che potresti non aspettarti: C ++. Penso che questo sia un aspetto del mondo dei big data che vedremo di più negli anni a venire. 

I manutentori di Apache Storm hanno rimosso molti elementi del suo codice Clojure originale a favore delle reimplementazioni di Java e il progetto Apache Spark attualmente genera codice Java al volo per accelerare l'elaborazione DataFrame. Ma entrambi sono ancora legati alla JVM e la JVM ha problemi su larga scala. Non fraintendetemi, la JVM è una creazione straordinaria che ha resistito alla prova del tempo per 20 anni, ma quando si esegue su macchine con enormi quantità di RAM ed elaborano enormi quantità di dati, emergono problemi con la raccolta dei rifiuti, non importa quale schema di raccolta fantasia che usi.

A quel punto, tornare a un linguaggio come C ++ inizia a sembrare attraente. Ad esempio, Scylla, una reimplementazione C ++ di Apache Cassandra, ha un throughput 10 volte superiore a Cassandra con nessuna delle pause GC per le quali Cassandra è nota per le distribuzioni di grandi dimensioni. Sono abbastanza fiducioso che presto vedremo l'approccio di Heron diffondersi ad altri framework. Ciò può essere aiutato dal tentativo di Project Panama di migliorare l'interfaccia tra Java e altri linguaggi.

Dato che Heron richiede meno risorse e fornisce più throughput e meno latenza rispetto ad Apache Storm, dovresti spostare tutte le tue topologie su Heron adesso, sì? Beh forse. Heron è attualmente legato a Mesos, quindi se non disponi di un'infrastruttura Mesos esistente, dovrai configurarla anche tu, il che non è un'impresa da poco. Inoltre, se stai utilizzando le funzionalità DRPC di Storm, sono deprecate in Heron.

Tra i lati positivi, Heron ha gestito tutte le esigenze di elaborazione di Twitter in produzione da più di un anno, quindi dovrebbe essere in grado di gestire tutto ciò che puoi lanciare. Inoltre, Twitter sottolinea che Heron è utilizzato da Microsoft e da altre società Fortune 500, quindi puoi essere relativamente sicuro che rimarrà.

D'altra parte, Storm non è rimasto fermo. Il team di Apache Storm potrebbe cavillare con la descrizione di Twitter di Heron come "la prossima generazione di Apache Storm". Mentre Twitter lavorava su Heron, Apache Storm ha raggiunto 1.0, che include il supporto per la contropressione, migliori opzioni di debug e profiling, una riduzione del 60% della latenza e un miglioramento della velocità fino a 16 volte.

In addition, Storm 1.0 adds pacemaker, a daemon for offloading heartbeat traffic from ZooKeeper, freeing larger topologies from the infamous ZooKeeper bottleneck. Heron's speed improvements are measured from the Storm 0.8.x code it diverged from, not the current version; if you have migrated over to Storm 1.0 already, you might not see much more improvement over your current Storm topologies, and you may run into incompatibilities between the implementation of new features like back-pressure support between Storm and Heron.

Tutto sommato, non credo che Heron possa causare un grande impatto nell'adozione di framework di elaborazione dati come Apache Spark, Apache Flink o Apache Beam. Le loro astrazioni e API di livello superiore forniscono un'esperienza molto più intuitiva per gli sviluppatori rispetto alle API Storm / Trident di livello inferiore. Tuttavia, credo che la miscela di codice JVM con moduli non JVM per i percorsi critici sarà un approccio più popolare in futuro, e in questo aspetto, Heron ci mostra tutta la direzione che viaggeremo nei mesi e negli anni venire.