Еј Хабр! Ви го презентирам преводот на статијата авторите Бурак Јавуз, Бренер Хајнц и Дени Ли, кој беше подготвен во пресрет на почетокот на курсот од ОТУС.
Податоците, како и нашето искуство, постојано се акумулираат и се развиваат. За да останеме во чекор, нашите ментални модели на светот мора да се прилагодат на новите податоци, од кои некои содржат нови димензии - нови начини на набљудување на нештата за кои претходно немавме поим. Овие ментални модели не се многу различни од шемите на табелата кои одредуваат како ги категоризираме и обработуваме новите информации.
Ова нè доведува до прашањето за управување со шеми. Како што деловните предизвици и барања се менуваат со текот на времето, така се менува и структурата на вашите податоци. Делта Лејк го олеснува воведувањето нови мерења како што се менуваат податоците. Корисниците имаат пристап до едноставна семантика за да управуваат со нивните шеми на табели. Овие алатки вклучуваат Schema Enforcement, која ги штити корисниците од ненамерно загадување на нивните табели со грешки или непотребни податоци, и Schema Evolution, која овозможува нови колони со вредни податоци автоматски да се додаваат на соодветните локации. Во оваа статија, ќе се нурнеме подлабоко во користењето на овие алатки.
Разбирање на шеми за табели
Секоја DataFrame во Apache Spark содржи шема која ја дефинира формата на податоците, како што се типови на податоци, колони и метаподатоци. Со Delta Lake, шемата на табелата се зачувува во формат JSON во дневникот на трансакциите.
Што е спроведување на шема?
Schema Enforcement, исто така познат како Schema Validation, е безбедносен механизам во Delta Lake кој обезбедува квалитет на податоците со отфрлање на записите што не се совпаѓаат со шемата на табелата. Како домаќинката на рецепцијата на популарен ресторан само за резервации, таа проверува дали секоја колона со податоци внесена во табелата е во соодветната листа на очекувани колони (со други зборови, дали има „резервација“ за секоја од нив ), и ги отфрла сите записи со колони што не се во списокот.
Како функционира спроведувањето на шемата?
Делта Лејк користи проверка на шема-на-пишување, што значи дека сите нови запишувања на табелата се проверуваат за компатибилност со шемата на целната табела во времето на запишување. Ако шемата е неконзистентна, Делта Лејк целосно ја прекинува трансакцијата (не се пишуваат податоци) и поставува исклучок за да го извести корисникот за недоследноста.
Делта Лејк ги користи следниве правила за да утврди дали записот е компатибилен со табела. Рамка на податоци што може да се запише:
- не може да содржи дополнителни колони кои не се во шемата на целната табела. Спротивно на тоа, сè е во ред ако дојдовните податоци не ги содржат апсолутно сите колони од табелата - на овие колони едноставно ќе им се доделат нула вредности.
- не може да има типови на податоци за колони што се различни од типовите на податоци на колоните во целната табела. Ако колоната за целната табела содржи податоци за StringType, но соодветната колона во DataFrame содржи податоци од IntegerType, спроведувањето на шемата ќе направи исклучок и ќе спречи извршување на операцијата за запишување.
- не може да содржи имиња на колони кои се разликуваат само во случај. Ова значи дека не можете да имате дефинирани колони со име „Foo“ и „foo“ во истата табела. Додека Spark може да се користи во режим со чувствителност на букви или големи букви (стандардно), Delta Lake зачувува мали букви, но е нечувствителен во складирањето на шемата. Паркетот е осетлив на букви при складирање и враќање на информациите за колоната. За да избегнеме можни грешки, оштетување на податоците или загуба на податоци (нешто што лично го доживеавме во Databricks), решивме да го додадеме ова ограничување.
За да го илустрираме ова, ајде да погледнеме што се случува во кодот подолу кога се обидуваме да додадеме некои новогенерирани колони на табелата на Делта Лејк која сè уште не е конфигурирана да ги прифаќа.
# Сгенерируем 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.Наместо автоматски да додава нови колони, Делта Лејк наметнува шема и престанува да пишува. За да помогне да се одреди која колона (или множество колони) го предизвикува несовпаѓањето, Spark ги прикажува двете шеми од трагата на стек за споредба.
Која е користа од спроведувањето на шемата?
Бидејќи спроведувањето на шемата е прилично строга проверка, тоа е одлична алатка за користење како чувар на чист, целосно трансформиран збир на податоци што е подготвен за производство или потрошувачка. Обично се применува на табели кои директно ги снабдуваат податоците:
- Алгоритми за машинско учење
- BI контролни табли
- Алатки за анализа на податоци и визуелизација
- Секој производствен систем кој бара високо структурирани, силно типизирани семантички шеми.
За да ги подготват своите податоци за оваа последна пречка, многу корисници користат едноставна архитектура „мулти-хоп“ која постепено воведува структура во нивните табели. За да дознаете повеќе за ова, можете да ја проверите статијата
Се разбира, спроведувањето на шемата може да се користи каде било во вашата линија, но запомнете дека преносот до табела во овој случај може да биде фрустрирачки затоа што, на пример, сте заборавиле дека додадовте друга колона на дојдовните податоци.
Спречување на разредување на податоците
Досега можеби се прашувате, за што е целата врева? На крајот на краиштата, понекогаш неочекуваната грешка „несовпаѓање на шемата“ може да ве сопне во работниот тек, особено ако сте нови во Делта Лејк. Зошто да не дозволите шемата да се менува по потреба за да можам да ја напишам мојата 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