Ola Habr! Presento á súa atención a tradución do artigo autores Burak Yavuz, Brenner Heintz e Denny Lee, que se preparou de cara ao comezo do curso de OTUS.
Os datos, como a nosa experiencia, acumúlanse e evolucionan constantemente. Para seguir o ritmo, os nosos modelos mentais do mundo deben adaptarse a novos datos, algúns dos cales conteñen novas dimensións: novas formas de observar cousas das que antes non tiñamos idea. Estes modelos mentais non son moi diferentes dos esquemas de táboa que determinan como categorizamos e procesamos a nova información.
Isto lévanos á cuestión da xestión de esquemas. A medida que os desafíos e requisitos empresariais cambian co paso do tempo, tamén o cambia a estrutura dos teus datos. Delta Lake facilita a introdución de novas medicións a medida que os datos cambian. Os usuarios teñen acceso a unha semántica sinxela para xestionar os seus esquemas de táboa. Estas ferramentas inclúen Schema Enforcement, que protexe aos usuarios de contaminar involuntariamente as súas táboas con erros ou datos innecesarios, e Schema Evolution, que permite engadir automaticamente novas columnas de datos valiosos ás localizacións adecuadas. Neste artigo, afondaremos no uso destas ferramentas.
Comprensión de esquemas de táboa
Cada DataFrame en Apache Spark contén un esquema que define a forma dos datos, como tipos de datos, columnas e metadatos. Con Delta Lake, o esquema da táboa gárdase en formato JSON dentro do rexistro de transaccións.
Que é a execución do réxime?
A aplicación de esquemas, tamén coñecida como Validación de esquemas, é un mecanismo de seguranza en Delta Lake que garante a calidade dos datos rexeitando os rexistros que non coinciden co esquema da táboa. Do mesmo xeito que a anfitrioa da recepción dun restaurante popular só con reservas, ela comproba se cada columna de datos introducidas na táboa está na correspondente lista de columnas esperadas (noutras palabras, se hai unha "reserva" para cada unha delas ), e rexeita calquera rexistro con columnas que non estean na lista.
Como funciona a aplicación do esquema?
Delta Lake usa a comprobación de esquema en escritura, o que significa que todas as novas escrituras na táboa compróbanse a compatibilidade co esquema da táboa de destino no momento da escritura. Se o esquema é inconsistente, Delta Lake aborta a transacción por completo (non se escriben datos) e xera unha excepción para notificarlle ao usuario a inconsistencia.
Delta Lake usa as seguintes regras para determinar se un rexistro é compatible cunha táboa. DataFrame escribible:
- non pode conter columnas adicionais que non estean no esquema da táboa de destino. Pola contra, todo está ben se os datos entrantes non conteñen absolutamente todas as columnas da táboa; a estas columnas simplemente asignaranse valores nulos.
- non pode ter tipos de datos de columna que sexan diferentes dos tipos de datos das columnas da táboa de destino. Se a columna da táboa de destino contén datos StringType, pero a columna correspondente no DataFrame contén datos IntegerType, a aplicación do esquema xerará unha excepción e impedirá que se realice a operación de escritura.
- non pode conter nomes de columna que difiran só por maiúsculas e minúsculas. Isto significa que non pode ter columnas chamadas 'Foo' e 'foo' definidas na mesma táboa. Aínda que Spark se pode usar no modo que distingue entre maiúsculas e minúsculas ou que non distingue entre maiúsculas e minúsculas (predeterminado), Delta Lake conserva as maiúsculas e minúsculas, pero non é sensible ao almacenamento do esquema. Parquet distingue entre maiúsculas e minúsculas ao almacenar e devolver información das columnas. Para evitar posibles erros, corrupción de datos ou perda de datos (algo que experimentamos persoalmente en Databricks), decidimos engadir esta limitación.
Para ilustralo, vexamos o que ocorre no código a continuación cando tentamos engadir algunhas columnas recentemente xeradas a unha táboa de Delta Lake que aínda non está configurada para aceptalas.
# Сгенерируем 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 lugar de engadir novas columnas automaticamente, Delta Lake impón un esquema e deixa de escribir. Para axudar a determinar que columna (ou conxunto de columnas) está a provocar a discrepancia, Spark saca os dous esquemas desde o rastrexo da pila para comparalos.
Cal é o beneficio de facer cumprir un esquema?
Debido a que a aplicación do esquema é unha comprobación bastante rigorosa, é unha excelente ferramenta para usar como garda dun conxunto de datos limpo e totalmente transformado que está listo para a produción ou o consumo. Normalmente aplícase ás táboas que alimentan datos directamente:
- Algoritmos de aprendizaxe automática
- Paneles de BI
- Ferramentas de análise e visualización de datos
- Calquera sistema de produción que requira esquemas semánticos moi estruturados e fortemente tipificados.
Para preparar os seus datos para este obstáculo final, moitos usuarios usan unha arquitectura simple "multi-hop" que introduce gradualmente estrutura nas súas táboas. Para saber máis sobre isto, podes consultar o artigo
Por suposto, a aplicación do esquema pódese usar en calquera lugar da túa canalización, pero recorda que a transmisión a unha táboa neste caso pode ser frustrante porque, por exemplo, esqueceches que engadiches outra columna aos datos entrantes.
Prevención da dilución dos datos
A estas alturas podes estarte preguntando, de que vai todo o alboroto? Despois de todo, ás veces un erro inesperado de "desajuste de esquemas" pode provocarche un erro no teu fluxo de traballo, especialmente se es novo en Delta Lake. Por que non deixas que o esquema cambie segundo sexa necesario para que eu poida escribir o meu DataFrame pase o que pase?
Como di o vello dito, "un gramo de prevención vale máis que un quilo de cura". Nalgún momento, se non te preocupas de facer cumprir o teu esquema, os problemas de compatibilidade do tipo de datos sairán as súas feas cabezas: as fontes de datos en bruto aparentemente homoxéneas poden conter casos extremos, columnas danadas, mapeamentos mal formados ou outras cousas terroríficas coas que soñar. pesadelos. O mellor enfoque é deter estes inimigos na porta -coa aplicación do esquema- e tratar con eles á luz, en lugar de máis tarde cando comecen a axexar nas profundidades escuras do teu código de produción.
Aplicar un esquema dáche a garantía de que o esquema da túa táboa non cambiará a menos que aprobes o cambio. Isto evita a dilución dos datos, que pode ocorrer cando se engaden novas columnas con tanta frecuencia que as táboas comprimidas previamente valiosas perden o seu significado e utilidade debido á inundación de datos. Ao animarte a ser intencionado, establecer estándares elevados e esperar alta calidade, a aplicación do esquema fai exactamente o que foi deseñada: axudarche a manter a conciencia e as follas de cálculo limpas.
Se despois de máis consideración decides que realmente necesidade engade unha nova columna; non hai problema, a continuación hai unha solución dunha liña. A solución é a evolución do circuíto!
Que é a evolución do esquema?
A evolución do esquema é unha característica que permite aos usuarios cambiar facilmente o esquema da táboa actual segundo os datos que cambien co paso do tempo. Utilízase con máis frecuencia cando se realiza unha operación de anexar ou reescritura para adaptar automaticamente o esquema para incluír unha ou máis columnas novas.
Como funciona a evolución do esquema?
Seguindo o exemplo da sección anterior, os desenvolvedores poden usar facilmente a evolución do esquema para engadir novas columnas que foron rexeitadas anteriormente debido a inconsistencia do esquema. A evolución do circuíto actívase engadindo .option('mergeSchema', 'true') ao teu equipo Spark .write или .writeStream.
# Добавьте параметр mergeSchema
loans.write.format("delta")
.option("mergeSchema", "true")
.mode("append")
.save(DELTALAKE_SILVER_PATH)Para ver o gráfico, execute a seguinte 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
Alternativamente, pode configurar esta opción para toda a sesión de Spark engadindo spark.databricks.delta.schema.autoMerge = True á configuración de Spark. Pero úsao con precaución, xa que a aplicación do esquema xa non che avisará de inconsistencias non intencionadas do esquema.
Ao incluír o parámetro na solicitude mergeSchema, todas as columnas que están presentes no DataFrame pero non na táboa de destino engádense automaticamente ao final do esquema como parte dunha transacción de escritura. Tamén se poden engadir campos anidados e estes tamén se engadirán ao final das columnas da estrutura correspondentes.
Os enxeñeiros de datas e os científicos de datos poden usar esta opción para engadir novas columnas (quizais unha métrica rexistrada recentemente ou a columna de rendemento de vendas deste mes) ás súas táboas de produción de aprendizaxe automática existentes sen romper os modelos existentes baseados en columnas antigas.
Permítense os seguintes tipos de cambios de esquema como parte da evolución do esquema durante unha adición ou reescritura de táboas:
- Engadindo novas columnas (este é o escenario máis común)
- Cambiando os tipos de datos desde NullType -> calquera outro tipo ou promocionando desde ByteType -> ShortType -> IntegerType
Outros cambios non permitidos na evolución do esquema requiren que o esquema e os datos sexan reescritos engadindo .option("overwriteSchema", "true"). Por exemplo, no caso de que a columna "Foo" fose orixinalmente un número enteiro e o novo esquema fose un tipo de datos de cadea, entón todos os ficheiros de Parquet (datos) deberían reescribirse. Tales cambios inclúen:
- eliminando unha columna
- cambiar o tipo de datos dunha columna existente (in situ)
- renomear columnas que só difiren no caso de maiúsculas e minúsculas (por exemplo, "Foo" e "foo")
Finalmente, coa próxima versión de Spark 3.0, DDL explícito será totalmente compatible (usando ALTER TABLE), permitindo aos usuarios realizar as seguintes accións nos esquemas de táboas:
- engadindo columnas
- cambiar os comentarios das columnas
- establecer propiedades da táboa que controlan o comportamento da táboa, como establecer o tempo de almacenamento dun rexistro de transaccións.
Cal é o beneficio da evolución do circuíto?
A evolución do esquema pódese usar sempre que ti pretender cambia o esquema da túa táboa (en oposición a cando engadiches accidentalmente columnas ao teu DataFrame que non deberían estar alí). Esta é a forma máis sinxela de migrar o teu esquema porque engade automaticamente os nomes de columna e os tipos de datos correctos sen ter que declaralos explícitamente.
Conclusión
A aplicación do esquema rexeita todas as columnas novas ou outras modificacións do esquema que non sexan compatibles coa túa táboa. Ao establecer e manter estes altos estándares, os analistas e enxeñeiros poden confiar en que os seus datos teñen o máis alto nivel de integridade, comunicándoos de forma clara e clara, permitíndolles tomar mellores decisións comerciais.
Por outra banda, a evolución do esquema complementa a aplicación simplificando alegada cambios automáticos de esquema. Despois de todo, non debería ser difícil engadir unha columna.
A aplicación forzada do esquema é yang, onde a evolución do esquema é yin. Cando se usan xuntos, estas funcións fan que a supresión de ruído e a sintonización do sinal sexan máis fáciles que nunca.
Tamén queremos agradecer a Mukul Murthy e Pranav Anand polas súas contribucións a este artigo.
Outros artigos desta serie:
Artigos relacionados
Fonte: www.habr.com