Хей Хабр! Представям на вашето внимание превода на статията автори Бурак Явуз, Бренер Хайнц и Дени Лий, който беше подготвен в очакване на началото на курса от OTUS.
Данните, подобно на нашия опит, непрекъснато се натрупват и развиват. За да бъдат в крак, нашите умствени модели на света трябва да се адаптират към нови данни, някои от които съдържат нови измерения - нови начини за наблюдение на неща, за които не сме имали представа преди. Тези ментални модели не се различават много от табличните схеми, които определят как категоризираме и обработваме нова информация.
Това ни води до въпроса за управлението на схемата. Тъй като бизнес предизвикателствата и изискванията се променят с времето, структурата на вашите данни също се променя. Delta Lake улеснява въвеждането на нови измервания при промяна на данните. Потребителите имат достъп до проста семантика, за да управляват своите схеми на таблици. Тези инструменти включват Schema Enforcement, който предпазва потребителите от неволно замърсяване на техните таблици с грешки или ненужни данни, и Schema Evolution, който позволява автоматично добавяне на нови колони с ценни данни към подходящите места. В тази статия ще се потопим по-задълбочено в използването на тези инструменти.
Разбиране на схемите на таблици
Всеки DataFrame в Apache Spark съдържа схема, която дефинира формата на данните, като типове данни, колони и метаданни. С Delta Lake схемата на таблицата се съхранява във формат JSON в регистъра на транзакциите.
Какво представлява прилагането на схемата?
Schema Enforcement, известен също като Schema Validation, е механизъм за сигурност в Delta Lake, който гарантира качеството на данните чрез отхвърляне на записи, които не съответстват на схемата на таблицата. Подобно на домакинята на рецепцията на популярен ресторант само с резервации, тя проверява дали всяка колона с данни, въведена в таблицата, е в съответния списък с очаквани колони (с други думи, дали има „резервация“ за всяка от тях ).и отхвърля всички записи с колони, които не са в списъка.
Как работи прилагането на схемата?
Delta Lake използва проверка на схемата при запис, което означава, че всички нови записи в таблицата се проверяват за съвместимост със схемата на целевата таблица по време на запис. Ако схемата е несъвместима, Delta Lake прекратява изцяло транзакцията (не се записват данни) и предизвиква изключение, за да уведоми потребителя за несъответствието.
Delta Lake използва следните правила, за да определи дали даден запис е съвместим с таблица. DataFrame с възможност за запис:
- не може да съдържа допълнителни колони, които не са в схемата на целевата таблица. Обратно, всичко е наред, ако входящите данни не съдържат абсолютно всички колони от таблицата - на тези колони просто ще бъдат присвоени нулеви стойности.
- не може да има типове данни на колони, които са различни от типовете данни на колоните в целевата таблица. Ако колоната на целевата таблица съдържа StringType данни, но съответната колона в DataFrame съдържа IntegerType данни, прилагането на схемата ще хвърли изключение и ще предотврати извършването на операцията за запис.
- не може да съдържа имена на колони, които се различават само по регистър. Това означава, че не можете да имате дефинирани колони с имена „Foo“ и „foo“ в една и съща таблица. Докато Spark може да се използва в режим, чувствителен към малки или малки букви (по подразбиране), Delta Lake запазва регистъра на буквите, но не е чувствителен към хранилището на схемата. Parquet е чувствителен към главни и малки букви, когато съхранява и връща информация за колони. За да избегнем възможни грешки, повреда на данни или загуба на данни (нещо, което лично изпитахме в Databricks), решихме да добавим това ограничение.
За да илюстрираме това, нека да разгледаме какво се случва в кода по-долу, когато се опитаме да добавим някои новогенерирани колони към таблица на Delta Lake, която все още не е конфигурирана да ги приема.
# Сгенерируем 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.Вместо автоматично да добавя нови колони, Delta Lake налага схема и спира да пише. За да помогне да се определи коя колона (или набор от колони) причинява несъответствието, Spark извежда и двете схеми от трасирането на стека за сравнение.
Каква е ползата от налагането на схема?
Тъй като прилагането на схемата е доста строга проверка, това е отличен инструмент за използване като вратар към чист, напълно трансформиран набор от данни, който е готов за производство или потребление. Обикновено се прилага към таблици, които директно подават данни:
- Алгоритми за машинно обучение
- BI табла за управление
- Инструменти за анализ на данни и визуализация
- Всяка производствена система, която изисква силно структурирани, строго типизирани семантични схеми.
За да подготвят своите данни за това последно препятствие, много потребители използват проста „multi-hop“ архитектура, която постепенно въвежда структура в техните таблици. За да научите повече за това, можете да разгледате статията
Разбира се, прилагането на схемата може да се използва навсякъде във вашия конвейер, но не забравяйте, че стриймингът към таблица в този случай може да бъде разочароващ, защото например сте забравили, че сте добавили друга колона към входящите данни.
Предотвратяване на размиването на данни
Досега може би се чудите за какво е целият този шум? В края на краищата понякога неочаквана грешка „несъответствие на схемата“ може да ви спъне в работния процес, особено ако сте нов в Delta Lake. Защо просто не оставя схемата да се промени, ако е необходимо, така че да мога да напиша своя DataFrame независимо от всичко?
Както се казва в старата поговорка, „унция превенция струва половин килограм лечение“. В един момент, ако не се погрижите да наложите схемата си, проблемите със съвместимостта на типа данни ще излязат нагоре - привидно хомогенните източници на необработени данни може да съдържат крайни случаи, повредени колони, неправилно формирани съпоставяния или други страшни неща, за които да мечтаете кошмари. Най-добрият подход е да спрете тези врагове на вратата - с прилагане на схема - и да се справите с тях на светло, а не по-късно, когато започнат да се спотайват в тъмните дълбини на вашия производствен код.
Налагането на схема ви дава сигурността, че схемата на вашата таблица няма да се промени, освен ако не одобрите промяната. Това предотвратява разреждането на данни, което може да възникне, когато нови колони се добавят толкова често, че предишните ценни, компресирани таблици губят своето значение и полезност поради наводняване на данни. Като ви насърчава да сте преднамерени, да поставяте високи стандарти и да очаквате високо качество, прилагането на схема прави точно това, за което е предназначено – да ви помогне да останете съвестни и вашите електронни таблици чисти.
Ако след допълнително обмисляне решите, че наистина нужда добавете нова колона - няма проблем, по-долу е поправка от един ред. Решението е еволюцията на веригата!
Какво представлява еволюцията на схемата?
Развитието на схемата е функция, която позволява на потребителите лесно да променят текущата схема на таблица според данните, които се променят с течение на времето. Най-често се използва при извършване на операция за добавяне или пренаписване за автоматично адаптиране на схемата, за да включи една или повече нови колони.
Как работи еволюцията на схемата?
Следвайки примера от предишния раздел, разработчиците могат лесно да използват еволюцията на схемата, за да добавят нови колони, които преди това са били отхвърлени поради несъответствие на схемата. Развитието на веригата се активира чрез добавяне .option('mergeSchema', 'true') към вашия екип на Spark .write или .writeStream.
# Добавьте параметр mergeSchema
loans.write.format("delta")
.option("mergeSchema", "true")
.mode("append")
.save(DELTALAKE_SILVER_PATH)За да видите графиката, изпълнете следната 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
Като алтернатива можете да зададете тази опция за цялата сесия на Spark, като добавите spark.databricks.delta.schema.autoMerge = True към конфигурацията на Spark. Но използвайте това с повишено внимание, тъй като прилагането на схема вече няма да ви предупреждава за неволни несъответствия в схемата.
Чрез включване на параметъра в заявката mergeSchema, всички колони, които присъстват в DataFrame, но не и в целевата таблица, се добавят автоматично в края на схемата като част от транзакция за запис. Могат да се добавят и вложени полета, които също ще бъдат добавени в края на съответните структурни колони.
Инженерите по данни и специалистите по данни могат да използват тази опция, за да добавят нови колони (може би наскоро проследен показател или колона за ефективност на продажбите за този месец) към своите съществуващи производствени таблици за машинно обучение, без да нарушават съществуващите модели, базирани на стари колони.
Следните типове промени в схемата са разрешени като част от еволюцията на схемата по време на добавяне или пренаписване на таблица:
- Добавяне на нови колони (това е най-честият сценарий)
- Промяна на типове данни от NullType -> всеки друг тип или повишаване от ByteType -> ShortType -> IntegerType
Други промени, които не са разрешени в рамките на еволюцията на схемата, изискват схемата и данните да бъдат пренаписани чрез добавяне .option("overwriteSchema", "true"). Например, в случай, че колоната "Foo" първоначално е била цяло число и новата схема е низов тип данни, тогава всички файлове Parquet(data) ще трябва да бъдат пренаписани. Такива промени включват:
- изтриване на колона
- промяна на типа данни на съществуваща колона (на място)
- преименуване на колони, които се различават само по регистър (например "Foo" и "foo")
И накрая, със следващото издание на Spark 3.0, изричният DDL ще бъде напълно поддържан (използвайки ALTER TABLE), позволявайки на потребителите да извършват следните действия върху схеми на таблици:
- добавяне на колони
- промяна на коментарите в колоните
- задаване на свойства на таблицата, които контролират поведението на таблицата, като например задаване на продължителността на времето, през което се съхранява регистърът на транзакциите.
Каква е ползата от еволюцията на веригата?
Развитието на схемата може да се използва винаги, когато възнамерявам променете схемата на вашата таблица (за разлика от случайно добавяне на колони към вашата DataFrame, които не трябва да са там). Това е най-лесният начин за мигриране на вашата схема, защото автоматично добавя правилните имена на колони и типове данни, без да се налага изрично да ги декларирате.
Заключение
Прилагането на схема отхвърля всички нови колони или други промени в схемата, които не са съвместими с вашата таблица. Като определят и поддържат тези високи стандарти, анализаторите и инженерите могат да се доверят, че техните данни имат най-високо ниво на интегритет, съобщавайки ги ясно и ясно, което им позволява да вземат по-добри бизнес решения.
От друга страна, еволюцията на схемата допълва прилагането чрез опростяване предполагаем автоматични промени в схемата. В крайна сметка не би трябвало да е трудно да добавите колона.
Принудителното прилагане на схемата е ян, където еволюцията на схемата е ин. Когато се използват заедно, тези функции правят потискането на шума и настройката на сигнала по-лесни от всякога.
Бихме искали също да благодарим на Мукул Мурти и Пранав Ананд за техния принос към тази статия.
Други статии от тази серия:
Свързани статии
Източник: www.habr.com