Hola Habr! Presento a la vostra atenció la traducció de l'article autors Burak Yavuz, Brenner Heintz i Denny Lee, que es va preparar en previsió de l'inici del curs d'OTUS.
Les dades, com la nostra experiència, s'acumulen i evolucionen constantment. Per mantenir-se al dia, els nostres models mentals del món s'han d'adaptar a noves dades, algunes de les quals contenen noves dimensions: noves maneres d'observar coses que abans no teníem ni idea. Aquests models mentals no són gaire diferents dels esquemes de taula que defineixen com classifiquem i processem la nova informació.
Això ens porta al problema de la gestió d'esquemes. A mesura que els objectius i els requisits empresarials canvien amb el temps, també ho fa l'estructura de les vostres dades. Delta Lake facilita la implementació de noves mesures a mesura que canvien les dades. Els usuaris tenen accés a una semàntica senzilla per gestionar els seus esquemes de taules. Aquestes eines inclouen Schema Enforcement, que protegeix els usuaris de la contaminació inadvertida de les seves taules amb errors o dades innecessàries, i Schema Evolution, que permet afegir noves columnes de dades valuoses automàticament als llocs adequats. En aquest article, aprofundirem en l'ús d'aquestes eines.
Comprensió d'esquemes de taules
Cada DataFrame d'Apache Spark conté un esquema que defineix la forma de les dades, com ara tipus de dades, columnes i metadades. Amb Delta Lake, l'esquema de la taula s'emmagatzema en format JSON dins del registre de transaccions.
Què és l'aplicació d'esquemes?
L'aplicació d'esquemes, també coneguda com a validació d'esquemes, és un mecanisme de protecció a Delta Lake que garanteix la qualitat de les dades rebutjant els registres que no coincideixen amb l'esquema de la taula. Com una amfitriona a la recepció d'un restaurant popular que només accepta reserves, comprova si cada columna de dades introduïdes a la taula es troba a la llista corresponent de columnes esperades (és a dir, si hi ha una "reserva" per a cadascun d'ells) i rebutja qualsevol entrada amb columnes que no estiguin a la llista.
Com funciona l'aplicació d'esquemes?
Delta Lake utilitza la validació d'esquemes en escriptura, el que significa que totes les escriptures noves a la taula es comprova la compatibilitat amb l'esquema de la taula de destinació en el moment d'escriptura. Si l'esquema és inconsistent, Delta Lake inverteix completament la transacció (no s'escriu cap dada) i llança una excepció per informar l'usuari de la inconsistència.
Delta Lake utilitza les regles següents per determinar si un registre és compatible amb una taula. DataFrame escrit:
- no pot contenir columnes addicionals que no estiguin a l'esquema de la taula de destinació. Per contra, tot està bé si les dades entrants no contenen absolutament totes les columnes de la taula; a aquestes columnes simplement se'ls assignarà valors zero.
- no pot tenir tipus de dades de columna que siguin diferents dels tipus de dades de columna de la taula de destinació. Si una columna de la taula de destinació conté dades StringType, però la columna corresponent del DataFrame conté dades IntegerType, l'aplicació de l'esquema generarà una excepció i evitarà que es realitzi l'operació d'escriptura.
- no pot contenir noms de columnes que només difereixen per majúscules. Això vol dir que no podeu tenir columnes anomenades 'Foo' i 'foo' definides a la mateixa taula. Tot i que Spark es pot utilitzar en el mode que distingeix entre majúscules i minúscules (el predeterminat), Delta Lake conserva majúscules i minúscules però no distingeix en l'emmagatzematge d'esquemes. El parquet distingeix entre majúscules i minúscules quan emmagatzema i retorna la informació de la columna. Per evitar possibles errors, corrupció de dades o pèrdua de dades (que vam experimentar personalment a Databricks), vam decidir afegir aquesta limitació.
Per il·lustrar-ho, fem una ullada al que passa al codi següent quan s'intenta afegir algunes columnes recentment generades a una taula de Delta Lake que encara no està configurada per acceptar-les.
# Сгенерируем DataFrame ссуд, который мы добавим в нашу таблицу Delta Lake
loans = sql("""
SELECT addr_state, CAST(rand(10)*count as bigint) AS count,
CAST(rand(10) * 10000 * count AS double) AS amount
FROM loan_by_state_delta
""")
# Вывести исходную схему DataFrame
original_loans.printSchema()
root
|-- addr_state: string (nullable = true)
|-- count: integer (nullable = true)
# Вывести новую схему DataFrame
loans.printSchema()
root
|-- addr_state: string (nullable = true)
|-- count: integer (nullable = true)
|-- amount: double (nullable = true) # new column
# Попытка добавить новый DataFrame (с новым столбцом) в существующую таблицу
loans.write.format("delta")
.mode("append")
.save(DELTALAKE_PATH)
Returns:
A schema mismatch detected when writing to the Delta table.
To enable schema migration, please set:
'.option("mergeSchema", "true")'
Table schema:
root
-- addr_state: string (nullable = true)
-- count: long (nullable = true)
Data schema:
root
-- addr_state: string (nullable = true)
-- count: long (nullable = true)
-- amount: double (nullable = true)
If Table ACLs are enabled, these options will be ignored. Please use the ALTER TABLE command for changing the schema.En lloc d'afegir columnes noves automàticament, Delta Lake aplica un esquema i atura la gravació. Per ajudar a determinar quina columna (o conjunt d'elles) està causant el desajust, Spark treu els dos esquemes de la pila de traça per comparar-los.
Quin és el benefici de l'aplicació d'esquemes?
Com que l'aplicació d'esquemes és una comprovació bastant rigorosa, és una gran eina per utilitzar-la com a porter d'un conjunt de dades net i totalment transformat que està llest per ser produït o consumit. S'aplica normalment a taules que alimenten dades directament:
- Algoritmes d'aprenentatge automàtic
- Taulers de control de BI
- Eines d'anàlisi i visualització de dades
- Qualsevol sistema de producció que requereixi esquemes semàntics altament estructurats i fortament tipificats.
Per preparar les seves dades per a aquest últim obstacle, molts usuaris utilitzen una arquitectura simple "multi-hop" que introdueix gradualment l'estructura a les seves taules. Per obtenir més informació sobre això, podeu llegir l'article
Per descomptat, l'aplicació d'esquemes es pot utilitzar a qualsevol lloc del vostre pipeline, però tingueu en compte que l'escriptura en temps real a una taula pot ser frustrant en aquest cas, perquè, per exemple, heu oblidat que heu afegit una altra columna a les dades entrants.
Prevenció de l'aprimament de dades
En aquest punt, potser us preguntareu per què l'exageració? Al cap i a la fi, de vegades un error inesperat de "descoincidència d'esquemes" us pot provocar un error en el vostre flux de treball, sobretot si sou nou a Delta Lake. Per què no deixar que l'esquema canviï segons sigui necessari perquè pugui escriure el meu DataFrame sigui el que passi?
Com diu el vell refrany: "Una unça de prevenció val més que una lliura de cura". En algun moment, si no us cuideu d'aplicar el vostre esquema, els problemes de compatibilitat de tipus de dades s'aixecaran: fonts de dades en brut aparentment homogènies poden contenir casos extrems, columnes trencades, mapes mal formats o altres coses temudes amb les quals somieu. en malsons. El millor enfocament és aturar aquests enemics a la porta (amb l'aplicació d'esquemes) i tractar-los a la llum, no més tard quan comencin a rondar les fosques profunditats del vostre codi de producció.
L'aplicació de l'esquema us dóna la confiança que l'esquema de la vostra taula no canviarà tret que confirmeu el canvi vosaltres mateixos. Això evita la dilució de dades que es pot produir quan s'afegeixen columnes noves amb tanta freqüència que les taules comprimides anteriorment valuoses perden el seu valor i utilitat a causa de la inundació de dades. En animar-vos a ser intencionat, establir estàndards elevats i esperar una alta qualitat, l'aplicació d'esquemes fa exactament el que s'ha dissenyat: ajudar-vos a mantenir-vos en consciència i mantenir nets els vostres fulls de càlcul.
Si, després d'una consideració més profunda, decideixes que realment necessitat afegiu una columna nova; cap problema, a continuació hi ha una solució d'una línia. La solució és l'evolució del circuit!
Què és l'evolució de l'esquema?
L'evolució de l'esquema és una característica que permet als usuaris canviar fàcilment l'esquema actual d'una taula per fer coincidir les dades que canvien amb el temps. S'utilitza més habitualment quan es realitza una operació d'afegir o sobreescriure per adaptar automàticament l'esquema per incloure una o més columnes noves.
Com funciona l'evolució d'esquemes?
Seguint l'exemple de la secció anterior, els desenvolupadors poden utilitzar fàcilment l'evolució de l'esquema per afegir columnes noves que s'havien rebutjat prèviament a causa d'una inconsistència de l'esquema. L'evolució del circuit s'activa sumant .option('mergeSchema', 'true') al teu equip Spark .write или .writeStream.
# Добавьте параметр mergeSchema
loans.write.format("delta")
.option("mergeSchema", "true")
.mode("append")
.save(DELTALAKE_SILVER_PATH)Per veure el gràfic, executeu la següent consulta Spark SQL
# Создайте график с новым столбцом, чтобы подтвердить, что запись прошла успешно
%sql
SELECT addr_state, sum(`amount`) AS amount
FROM loan_by_state_delta
GROUP BY addr_state
ORDER BY sum(`amount`)
DESC LIMIT 10
Alternativament, podeu configurar aquesta opció per a tota la sessió de Spark afegint-hi spark.databricks.delta.schema.autoMerge = True a la configuració de Spark. Però utilitzeu-ho amb precaució, ja que l'aplicació de l'esquema ja no us avisarà de les inconsistències no intencionades de l'esquema.
Incloent un paràmetre a la sol·licitud mergeSchema, totes les columnes que estan presents al DataFrame però que no estan presents a la taula de destinació s'afegeixen automàticament al final de l'esquema com a part de la transacció d'escriptura. També es poden afegir camps imbricats, i aquests també s'afegiran al final de les columnes d'estructura corresponents.
Els enginyers de dates i els científics de dades poden utilitzar aquesta opció per afegir columnes noves (potser una mètrica amb un seguiment recent o la columna de xifres de vendes d'aquest mes) a les seves taules de producció d'aprenentatge automàtic existents sense trencar els models existents basats en les columnes antigues.
Els següents tipus de canvis d'esquema es permeten com a part d'una evolució d'esquema mentre s'afegeix o sobreescriu una taula:
- Afegir columnes noves (aquest és l'escenari més comú)
- Canviar els tipus de dades de NullType -> qualsevol altre tipus o promoció de ByteType -> ShortType -> IntegerType
Altres canvis que no es permeten com a part de l'evolució de l'esquema requereixen que l'esquema i les dades s'escriguin afegint-hi .option("overwriteSchema", "true"). Per exemple, en el cas en què la columna "Foo" fos originalment un nombre enter i el nou esquema seria un tipus de dades de cadena, s'haurien de sobreescriure tots els fitxers Parquet (dades). Aquests canvis inclouen:
- eliminant una columna
- canviar el tipus de dades d'una columna existent (al seu lloc)
- canviar el nom de columnes que només difereixen per majúscules i minúscules (per exemple, "Foo" i "foo")
Finalment, amb la propera versió de Spark 3.0, el DDL explícit (utilitzant ALTER TABLE) serà totalment compatible, permetent als usuaris realitzar les accions següents en esquemes de taula:
- afegint columnes
- canviant els comentaris de la columna
- establir les propietats de la taula que determinen com es comporta la taula, com ara establir quant de temps es conserva el registre de transaccions.
Quin és el benefici de l'evolució d'esquemes?
L'evolució esquemàtica es pot utilitzar sempre que tu pretenen canvieu l'esquema de la vostra taula (a diferència de quan heu afegit accidentalment columnes al vostre DataFrame que no hi haurien de ser). Aquesta és la manera més senzilla de migrar el vostre esquema perquè afegeix automàticament els noms de columna i els tipus de dades correctes sense haver de declarar-los explícitament.
Conclusió
L'aplicació d'esquemes rebutja les columnes noves o altres canvis d'esquema que no siguin compatibles amb la vostra taula. En establir i mantenir aquests estàndards elevats, els analistes i els enginyers poden confiar en les seves dades per tenir el màxim nivell d'integritat, raonant-hi de manera clara i concisa, que els permeti prendre millors decisions empresarials.
D'altra banda, l'evolució de l'esquema complementa l'aplicació mitjançant la simplificació suposada canvis automàtics d'esquema. Després de tot, no hauria de ser difícil afegir una columna.
L'aplicació d'esquemes és yang, on les evolucions d'esquemes són yin. Quan s'utilitzen juntes, aquestes funcions fan que la reducció de soroll i l'afinació del senyal siguin més fàcils que mai.
També ens agradaria donar les gràcies a Mukul Murthy i Pranav Anand per les seves contribucions a aquest article.
Altres articles d'aquesta sèrie:
Articles relacionats
Font: www.habr.com