Evoluzione dello schema in formato parquet

Question

Attualmente stiamo utilizzando il formato dati Avro in produzione. Fuori da N punti positivi di Avro, sappiamo che è buono nell'evoluzione dello schema.

Ora stiamo valutando Formato parquet a causa della sua efficienza durante la lettura di colonne casuali. Quindi, prima di andare avanti, la nostra preoccupazione è evoluzione dello schema!

Qualcuno sa se l'evoluzione dello schema è possibile in legno, in caso affermativo Come, se non perché. Alcuni presentation dicendo che è possibile, ma solo aggiungere colonne alla fine

Cosa significa?

Grazie, ~ Novizio sviluppatori

Answer 1

evoluzione schema può essere (molto) costoso, perché per capire lo schema si deve leggere praticamente tutti i file in parquet e reconsile/unire i suoi schemi in fase di lettura che può essere costoso a seconda quanti file/quante colonne nel set di dati.

Ecco perché in Spark 1.5, hanno disattivato l'evoluzione dello schema (per impostazione predefinita ma possono essere riattivati). http://spark.apache.org/docs/latest/sql-programming-guide.html:

Poiché schema fusione è un'operazione relativamente costosa, e non è una necessità nella maggioranza dei casi, abbiamo spenta per impostazione predefinita partendo da 1.5.0.

Senza l'evoluzione dello schema è possibile leggere lo schema da un file parquet, e mentre si legge il resto dei file si assume che rimanga lo stesso.

L'evoluzione dello schema del parquet è dipendente dall'implementazione.

Hive per esempio ha una manopola

parquet.column.index.access = false

che è possibile impostare per mappare lo schema per i nomi delle colonne, piuttosto che in base all'indice di colonna. Quindi potresti anche eliminare le colonne, non solo aggiungere.

Come detto, è dipendente, ad esempio, Impala non leggerebbe tali tabelle parquet correttamente (fissato recente rilascio Impala 2.6): http://community.cloudera.com/t5/Interactive-Short-cycle-SQL/external-table-stored-as-parquet-can-not-use-field-inside-a/m-p/36012

scintilla dalla versione 2.0.2 sembra ancora solo supporto colonne aggiungendo: http://spark.apache.org/docs/latest/sql-programming-guide.html#schema-merging

Gli utenti possono iniziare con un semplice schema, e aggiungere gradualmente più colonne allo schema in base alle esigenze. In questo modo, gli utenti potrebbero ritrovarsi con più file Parquet con schemi diversi ma reciprocamente compatibili. L'origine dati Parquet è ora in grado di rilevare automaticamente questo caso e gli schemi di unione di tutti questi file.

PS. Quello che ho visto fare ad alcune persone per avere più agilità sui cambiamenti dello schema, è che creano una vista in cima alle attuali tabelle del parquet che mappano due (o più) schemi diversi ma compatibili con uno schema comune. Diciamo che è stato aggiunto un nuovo campo (registration_date) e lasciò cadere un'altra colonna (last_login_date) nella nuova release, allora questo sarebbe simile:

CREATE VIEW datamart.unified_fact_vw 
AS 
SELECT f1..., NULL as registration_date 
FROM datamart.unified_fact_schema1 f1 
UNION ALL 
SELECT f2..., NULL as last_login_date 
FROM datamart.unified_fact_schema2 f2 
; 

è venuta l'idea .. La cosa bella che avrebbe funzionato lo stesso in tutta tutti i dialetti Hadoop su sql (come ho accennato sopra Hive, Impala e Spark), e hanno ancora tutti i vantaggi dei tavoli Parquet (archiviazione colonnare, push down del predicato, ecc.).