Vai al contenuto principale

Migrazione

Running a large Hadoop or Cloudera CDP migration?

For the business overview (drivers, cost models, case studies, ROI), see the Ilum Hadoop & Cloudera Migration Platform page. For the implementation reference once a migration is in flight, see the migration toolkit documentation, which covers discovery, phased execution, data validation, and rollback.

The rest of this page describes a high-level, self-directed migration path and covers product-version migration notes for Ilum itself, including the MongoDB to PostgreSQL metadata-store transition and the Konvert library pilot for data-conversion workloads.

See also

For migrating the bundled object storage between providers (the MinIO to RustFS path; RustFS is planned to become the default in 6.8.0), refer to the Object Storage section, and in particular Migrate Between Providers.

La migrazione da Apache Hadoop a Ilum prevede diversi passaggi, in genere a partire dalla configurazione del nuovo ambiente, seguita dalla migrazione di dati e applicazioni e infine dai test e dall'ottimizzazione. Ecco uno schema generale del processo:

  1. Preparazione: comprendere la distribuzione Hadoop corrente, inclusi i dati, le applicazioni e le dipendenze in essa contenute. Documenta tutti i dettagli rilevanti per assicurarti che nulla vada perso durante la transizione.

  2. Configurazione dell'ambiente Kubernetes: installa e configura il cluster Kubernetes in base alle esigenze dell'organizzazione. Questo servirà come base per i cluster Spark gestiti da Ilum.

  3. Installa Ilum: Distribuisci Ilum sul tuo cluster Kubernetes utilizzando Helm, un gestore di pacchetti per Kubernetes. Assicurarsi che Ilum sia configurato correttamente per gestire i cluster Spark.

  4. Migrazione dei dati: inizia la migrazione dei dati dal cluster Hadoop al nuovo ambiente. Ciò potrebbe comportare lo spostamento dei dati in un file system distribuito accessibile dal cluster Kubernetes o in un sistema di archiviazione compatibile con S3, se fa parte della nuova architettura.

  5. Migrazione delle applicazioni: Esegui la migrazione delle applicazioni Spark dall'ambiente Hadoop al nuovo ambiente Kubernetes. Ciò potrebbe comportare modifiche alle applicazioni per adattarle alle differenze tra Hadoop Yarn e Kubernetes.

  6. Aggiorna dipendenze: aggiorna tutte le dipendenze delle applicazioni, ad esempio la modifica delle origini dati da HDFS alla nuova posizione di archiviazione.

  7. Collaudo: eseguire test approfonditi per assicurarsi che le applicazioni vengano eseguite correttamente nel nuovo ambiente. Ciò dovrebbe includere test funzionali e test delle prestazioni per garantire che le applicazioni funzionino almeno come nell'ambiente Hadoop.

  8. Ottimizzazione: in base ai test, ottimizza le configurazioni di Kubernetes e Ilum per ottenere le migliori prestazioni.

  9. Monitoraggio: Una volta eseguita la migrazione e l'ottimizzazione di tutto, continua a monitorare le applicazioni e l'infrastruttura per assicurarti che tutto funzioni senza problemi. Ilum fornisce un'interfaccia Web che semplifica il monitoraggio dei cluster e dei processi Spark.

Si tratta di uno schema di alto livello e le specifiche variano a seconda della configurazione corrente di Hadoop, dei casi d'uso specifici e dell'architettura del nuovo ambiente. Vale anche la pena notare che la migrazione può essere un processo complesso e può essere utile lavorare con esperti o cercare guide o risorse dettagliate per assistere con la migrazione.

Supporto alla migrazione​

La transizione da Apache Hadoop a un nuovo ambiente gestito da Ilum può sembrare impegnativa, ma non sei solo in questo processo. Sappiamo che la migrazione di dati e applicazioni, la configurazione di un nuovo ambiente e la garanzia che tutto funzioni come previsto possono essere un'attività complessa.

Per assistervi in questo processo, il nostro team di Ilum è pronto a fornirvi un supporto completo. Se hai bisogno di aiuto per la configurazione di Ilum, la migrazione dei cluster Spark o qualsiasi altro aspetto del processo di transizione, non esitare a contattarci. Possiamo fornire un grafico Helm per una facile implementazione di Ilum e guidarti attraverso i passaggi necessari per migrare il tuo cluster Hadoop esistente al nuovo ambiente.

Ci impegniamo a rendere il processo di migrazione il più agevole possibile per te. Se hai domande tecniche, hai bisogno di indicazioni sulle best practice o riscontri problemi durante la migrazione, siamo qui per aiutarti.

Contattateci all'indirizzo [email protected] in qualsiasi momento per assistenza durante la migrazione a Ilum. Il nostro team di supporto dedicato è pronto e desideroso di assisterti nel tuo percorso verso una gestione efficiente e gestibile dei cluster Apache Spark con Ilum.

Note sulla migrazione​

Migrazione dalla versione 5.*.* alla versione 6.0.0​

Con il rilascio della versione 6.0.0, abbiamo introdotto una nuova implementazione della sicurezza che richiede attenzione durante il processo di migrazione. Gli account utente esistenti devono essere ricreati se sono state apportate modifiche all'account amministratore predefinito.

Segui i passaggi seguenti per eseguire correttamente la migrazione alla versione 6.0.0. Un comando di esempio crea due account: uno per un amministratore e un secondo per un utente normale.

Aggiornamento dell'elmo \
    --mettere ilum-core.security.internal.users[0].username=Admin \
	--mettere ilum-core.security.internal.users[0].password=adminPassword \
	--mettere ilum-core.security.internal.users[0].roles[0]=ADMIN \
	--mettere ilum-core.security.internal.users[1].username=utente \
	--mettere ilum-core.security.internal.users[1].password=userPassword \
	--mettere ilum-core.security.internal.users[1].roles[0]=UTENTE \
	--riutilizzare-valori ilum ilum/ilum

Per verificare tutti i metodi di autenticazione supportati e i relativi parametri, visita i file README.md nei grafici ilum-core.

Migrazione dalla versione 6.0.* alla versione 6.1.0​

Con il rilascio della versione 6.1.0, è stata introdotta una nuova implementazione dell'archiviazione Spark di ilum che richiede attenzione durante il processo di migrazione. La configurazione del bucket esistente deve essere formattata in modo che corrisponda al nuovo schema.

In precedenza, il bucket s3 utilizzato da ilum per l'archiviazione delle risorse spark veniva configurato utilizzando il ilum-core.kubernetes.s3.bucket valore del timone. Dalla versione 6.1.0 è stato sostituito con due nuovi parametri:

  1. ilum-core.kubernetes.s3.sparkBucket - svolge lo stesso ruolo del parametro precedente
  2. ilum-core.kubernetes.s3.dataBucket - utilizzato per configurare il bucket per la memorizzazione di ilum-tables

Metadata store: MongoDB to PostgreSQL​

Recent Ilum releases promote PostgreSQL to the primary metadata store per ilum-core. Access is reactive (R2DBC) with jOOQ-generated SQL DSL. MongoDB remains supported for legacy deployments and continues to receive bug fixes, but new deployments should default to PostgreSQL.

Why the change​

  • Consistency with the rest of the stack: Marquez, Hive Metastore, Airflow, Superset, MLflow, Hydra, Gitea, n8n, and Kestra already share PostgreSQL. Consolidating ilum-core removes one stateful system from the deployment surface.
  • Schema-first metadata: jOOQ codegen produces type-safe SQL, replacing the schemaless reads against MongoDB collections that grew brittle as the metadata model expanded.
  • Operational tooling: Standard Postgres backup, replication, and observability tooling applies to Ilum metadata without bespoke MongoDB pipelines.

Default configuration​

PostgreSQL is enabled out of the box in the umbrella Helm chart (postgresql.enabled: true). MongoDB is also enabled by default for backwards compatibility. Operators can disable MongoDB once they have migrated:

mongodb:
  Abilitato: falso

Migrating an existing MongoDB-backed deployment​

A migration tooling chain ships with Ilum (script set M001 through M009) that reads metadata from MongoDB and writes it to PostgreSQL in the new schema. The migration is run once during the upgrade window:

  1. Stop incoming traffic to ilum-core (drain or scale to zero).
  2. Verify a PostgreSQL deployment is reachable from the ilum-core namespace and the ilum database exists.
  3. Run the migration job through the umbrella chart's migration runner. Each step (M001 through M009) runs sequentially; failures roll back to the prior checkpoint.
  4. Update the ilum-core configuration to point its primary store at PostgreSQL.
  5. Restart ilum-core. Verify clusters, jobs, schedules, and saved queries are present in the UI.
  6. After a soak period, scale MongoDB down or disable it via mongodb.enabled: false.

For deployment-specific migration assistance, contact [email protected].

Both backends in parallel​

ilum-core supports running with either backend during the transition. The mongo.uri and PostgreSQL connection settings remain configurable independently, allowing operators to validate the PostgreSQL backend on a non-production cluster before promoting it.

Konvert library (pilot)​

Ilum includes an integration with Konvert, a data-conversion library currently in pilot integration. Konvert is intended to streamline conversion of data and code between source formats and Ilum-native targets during migration projects (for example, transforming legacy ETL definitions into Ilum job specifications).

The pilot is opt-in and not yet covered by a stable public API. Teams interested in evaluating Konvert for a migration project should contact [email protected] for the current scope and an enablement walkthrough.

For large estate migrations from Hadoop or Cloudera CDP, the recommended starting point remains the Bifrost migration toolkit, which covers discovery, phased execution, data validation, and rollback.

Last updated on