Yimian è un fornitore leader di analisi dei dati basato su AI, specializzato in dati di commercio digitale. Offriamo intuizioni in tempo reale sulla strategia aziendale, sviluppo di prodotti e operazioni di commercio digitale. Molti dei nostri clienti sono leader nel settore della cura personale, trucco, F&B, animali domestici e auto, come Procter and Gamble, Unilever e Mars.
La nostra architettura tecnologica originale era un cluster di big data costruito utilizzando CDH (Cloudera Distributed Hadoop) in un data center on-premises. Con l’aumento della nostra attività, il volume dei dati è cresciuto esponenzialmente.
Per affrontare sfide come cicli di scalabilità lunghi, risorse di calcolo e archiviazione non allineate e costi di manutenzione elevati, abbiamo deciso di trasformare la nostra architettura dei dati e migrare nel cloud, adottando un approccio di separazione tra calcolo e archiviazione. Dopo una valutazione accurata, abbiamo scelto Alibaba Cloud Elastic MapReduce (EMR) + JuiceFS + Alibaba Cloud Object Storage Service (OSS).
Attualmente, con JuiceFS, abbiamo implementato un’architettura decuplicata tra calcolo e archiviazione, raddoppiando la nostra capacità di archiviazione totale. In particolare, non abbiamo riscontrato un impatto significativo sulle prestazioni e i nostri costi operativi sono stati notevolmente ridotti.
In questo articolo, condivideremo il nostro design dell’architettura per la migrazione di Hadoop nel cloud, perché abbiamo scelto JuiceFS+EMR+OSS e come trarremo vantaggio dalla nuova architettura. Il nostro obiettivo è offrire intuizioni preziose per coloro che affrontano sfide simili attraverso questo post.
La nostra vecchia architettura e le sfide
Per soddisfare le nostre crescenti richieste di applicazioni, abbiamo effettuato il crawling dei dati da centinaia di grandi siti web, con il numero attuale che supera i 500. Nel tempo, abbiamo accumulato grandi quantità di dati grezzi, intermedi e risultato. Poiché continuavamo ad espandere il nostro crawling dei siti web e la base di clienti, il volume dei nostri dati aumentava rapidamente. Pertanto, abbiamo deciso di scalare il nostro hardware per soddisfare le crescenti esigenze.
L’architettura originale
La seguente figura mostra la nostra precedente architettura, che coinvolgeva un cluster big data basato su CDH distribuito in un data center:
- I componenti chiave includevano Hive, Spark e HDFS.
- Diversi sistemi di produzione dei dati, con Kafka come uno di essi, alimentavano il cluster.
- Abbiamo utilizzato altre soluzioni di archiviazione, come TiDB, HBase e MySQL, insieme a Kafka.
I dati fluivano dagli upstream application systems e data collection systems, dove venivano scritti in Kafka. Abbiamo impiegato un cluster Kafka Connect per sincronizzare i dati in HDFS.
Sul top di questa architettura, abbiamo sviluppato una piattaforma di sviluppo dati personalizzata chiamata OneWork per gestire vari compiti. Questi compiti venivano programmati tramite Airflow e elaborati nei task queues.
I nostri punti dolenti
Le sfide che abbiamo affrontato erano le seguenti:
- Crescita rapida dei dati delle applicazioni e lunghi cicli di scalabilità: Il nostro cluster CDH, distribuito nel 2016, gestiva già petabyte di dati entro il 2021. Tuttavia, la crescita dei dati spesso superava la pianificazione hardware, portando a frequenti scalabilità ogni sei mesi. Ciò consumava risorse e tempo significativi.
- Accoppiamento di storage e calcolo e difficoltà nella pianificazione della capacità: La stretta connessione tra storage e calcolo nell’architettura tradizionale di Hadoop rende difficile scalare e pianificare in modo indipendente sulla base dei requisiti di storage o calcolo. Ad esempio, espandere lo storage richiederebbe anche l’acquisto di risorse di calcolo inutili. Ciò ha portato a un’allocazione di risorse inefficiente.
- Paura di aggiornare a causa della versione CDH: La nostra versione CDH era vecchia e ci siamo esitati ad aggiornare per paura di stabilità e compatibilità.
- Alti costi operativi: Con circa 200 dipendenti, avevamo solo un personale operativo a tempo pieno. Ciò ha causato un pesante carico di lavoro. Per alleviare questo, abbiamo cercato un’architettura più stabile e semplice.
- Singolo punto di fallimento del data center: La conservazione di tutti i dati in un singolo data center presentava un rischio a lungo termine. In caso di danni ai cavi o altri problemi, avere un singolo data center crea un singolo punto di fallimento.
I nostri Requisiti per la Nuova Architettura
Per affrontare le nostre sfide e soddisfare le crescenti richieste, abbiamo deciso alcuni cambiamenti architettonici. Gli aspetti principali che abbiamo considerato per l’aggiornamento includono quanto segue:
- Adozione di cloud, scalabilità elastica e flessibilità operativa: L’adozione di servizi cloud semplificherebbe le operazioni. Ad esempio, sfruttare il cloud-based storage ci consente di concentrarsi sull’applicazione evitando compiti di manutenzione. Inoltre, le risorse cloud consentono una scalabilità elastica senza lunghe distribuzioni di hardware e configurazioni di sistema.
- Decoupling storage-compute: Abbiamo mirato a separare storage e compute per ottenere maggiore flessibilità e prestazioni.
- Preferenza per componenti open-source, evitando il lock-in del fornitore: Sebbene utilizziamo servizi cloud, abbiamo cercato di minimizzare la dipendenza da fornitori specifici. Mentre utilizziamo AWS Redshift per i servizi ai clienti, tendiamo verso componenti open-source per le operazioni in-house.
- Compatibilità con soluzioni esistenti, controllo dei costi e rischi: Il nostro obiettivo era garantire la compatibilità con le soluzioni attuali per minimizzare i costi di sviluppo e l’impatto sulla nostra applicazione.
Perché Abbiamo Scelto JuiceFS+EMR+OSS
Dopo aver valutato varie soluzioni, abbiamo scelto EMR+JuiceFS+OSS per costruire una piattaforma big data con storage-compute separati e gradualmente migrato il nostro data center on-premises al cloud.
In questa configurazione, lo storage di oggetti sostituisce HDFS, e JuiceFS funge da livello di protocollo grazie al suo supporto per i protocolli POSIX e HDFS. In cima, utilizziamo una soluzione Hadoop semi-gestita, EMR. Include Hive, Impala, Spark, Presto/Trino e altri componenti.
Alibaba Cloud vs. Altre Cloud Pubbliche
Dopo una valutazione accurata, abbiamo scelto Alibaba Cloud rispetto a AWS e Azure a causa dei seguenti fattori:
- Prossimità: La disponibilità della zona di Alibaba Cloud nella stessa città del nostro data center garantisce bassa latenza e riduzione dei costi di rete.
- Componenti open-source completi: Alibaba Cloud EMR offre una vasta gamma di componenti open-source correlati a Hadoop. Oltre all’intenso utilizzo di Hive, Impala, Spark e Hue, offre anche integrazione perfetta con Presto, Hudi, Iceberg e altro ancora. Durante le nostre ricerche, abbiamo scoperto che solo EMR include nativamente Impala, mentre AWS e Azure offrono versioni inferiori o richiedono installazione e distribuzione manuale.
JuiceFS vs. JindoFS
Che cos’è JuiceFS?
JuiceFS è un file system distribuito, open-source e cloud-native ad alte prestazioni. Offre completa compatibilità POSIX, consentendo l’utilizzo dell’object storage come disco locale enorme attraverso diverse piattaforme e regioni.
JuiceFS adotta una architettura separata per dati e metadati, permettendo una progettazione di file system distribuito. Quando si utilizza JuiceFS per memorizzare i dati, questi vengono persistenti in object storage come Amazon S3, mentre i metadati possono essere memorizzati su Redis, MySQL, TiKV, SQLite e altri database.
Oltre a POSIX, JuiceFS è completamente compatibile con l’SDK HDFS, consentendo la sostituzione senza soluzione di continuità di HDFS per la separazione tra storage e calcolo.
Perché abbiamo scelto JuiceFS rispetto a JindoFS
Abbiamo scelto JuiceFS rispetto a JindoFS sulla base delle seguenti considerazioni:
- Progettazione dell’archiviazione: JuiceFS adotta un’architettura di archiviazione separata per dati e metadati, consentendo una progettazione di sistema di file distribuito. I dati vengono persistenti in archiviazione oggetto, mentre i metadati possono essere memorizzati in vari database come Redis, MySQL, TiKV e SQLite, offrendo maggiore flessibilità. Al contrario, i metadati di JindoFS sono memorizzati sul disco rigido locale del cluster EMR, rendendo la manutenzione, gli aggiornamenti e i trasferimenti meno convenienti.
- Flessibilità dell’archiviazione: JuiceFS offre varie soluzioni di archiviazione, supportando la migrazione online tra diversi schemi e aumentando la portabilità. JindoFS supporta solo OSS per i dati a blocchi.
- Supporto della comunità open-source: JuiceFS si basa su una comunità open-source, supportando tutte le aree di cloud pubbliche. Ciò facilita l’espansione futura verso un’architettura multi-cloud.
L’intera progettazione dell’architettura
Tenendo conto che alcune applicazioni saranno ancora mantenute nel cluster Hadoop del data center, in realtà adottiamo un’architettura ibrida cloud, come mostrato nella figura seguente.
Nella figura dell’architettura:
- In alto si trovano Airflow e OneWork, entrambi supportano la distribuzione distribuita, quindi possono essere facilmente scalati orizzontalmente.
- A sinistra si trova l’IDC, che utilizza l’architettura CDH tradizionale e alcuni cluster Kafka.
- A destra si trova il cluster EMR distribuito su Alibaba Cloud.
L’IDC e il cluster EMR sono collegati da una linea dedicata ad alta velocità.
Come Beneficiamo dalla Nuova Architettura
Vantaggi della Separazione Archiviazione-Calcolo
Con l’implementazione della separazione tra storage e calcolo, la nostra capacità di archiviazione totale è raddoppiata mentre le risorse di calcolo rimangono stabili. Di tanto in tanto, attiviamo nodi di task temporanei a seconda delle necessità. Nel nostro scenario, il volume dei dati cresce rapidamente mentre le richieste di query rimangono stabili. A partire dal 2021, il nostro volume di dati è raddoppiato. Abbiamo apportato modifiche minime alle risorse di calcolo dall’inizio fino ad ora, tranne che per l’attivazione occasionale di risorse elastiche e nodi di task temporanei per soddisfare specifiche esigenze di applicazione.
Cambiamenti nelle Prestazioni
Per il nostro scenario di applicazione, che riguarda principalmente elaborazioni batch su larga scala per calcolo offline, non c’è un impatto significativo sulle prestazioni. Tuttavia, durante la fase di PoC, abbiamo osservato miglioramenti nei tempi di risposta per le query ad hoc di Impala.
Durante la fase di PoC, abbiamo condotto alcuni semplici test. Tuttavia, interpretare con precisione i risultati è difficile a causa di vari fattori che influenzano:
- La transizione da HDFS a JuiceFS
- Aggiornamenti delle versioni dei componenti
- Modifiche all’engine Hive
- Modifiche al carico del cluster
Tutto ciò rende difficile trarre conclusioni definitive sulle differenze di prestazioni rispetto al nostro precedente deployment di CDH su server bare metal.
Praticità e Stabilità
Non abbiamo riscontrato problemi con JuiceFS.
Mentre utilizzavamo EMR, abbiamo avuto piccoli problemi. Nel complesso, CDH è percepito come più stabile e user-friendly.
Complessità di Implementazione
Nel nostro scenario, i processi più dispendiosi sono la scrittura incrementale duale e la verifica dei dati. A scanso d’ombra, abbiamo investito eccessivamente in verifica e potremmo semplificarla.
Molti fattori influenzano la complessità:
- Scenari applicativi (offline/real-time, numero di tabelle/task, applicazioni di livello superiore)
- Versioni dei componenti
- Strumenti di supporto e riserve
Piani Futuri
I nostri piani futuri includono:
- Continuare la migrazione delle restanti applicazioni nel cloud.
- Esplorare una strategia di storage a livelli freddi/caldi utilizzando JuiceFS+OSS. I file JuiceFS sono completamente smontati su OSS, rendendo difficile implementare il livellamento a livello di file. Il nostro approccio attuale prevede il trasferimento dei dati freddi da JuiceFS a OSS, impostandoli come storage di archiviazione e modificando il LOCATION delle tabelle Hive o delle partizioni senza influire sull’uso.
- Se il volume dei dati aumenta e c’è pressione nell’utilizzo di Redis, potremmo prendere in considerazione lo switch a TiKV o ad altri motori in futuro.
- Esplorare le istanze di calcolo elastiche di EMR per ridurre i costi di utilizzo pur rispettando gli accordi di servizio delle applicazioni.
Source:
https://dzone.com/articles/migrating-hadoop-to-the-cloud-2x-storage-capacity