🥇Դելտա լճի սուզում. կիրարկում և սխեմայի էվոլյուցիա

Հե՜յ Հաբր։ Ձեր ուշադրությանն եմ ներկայացնում հոդվածի թարգմանությունը «Սուզվել Դելտա լճի մեջ. սխեմայի կիրառում և էվոլյուցիա» հեղինակներ Բուրակ Յավուզը, Բրեներ Հայնցը և Դեննի Լին, որը պատրաստվել է դասընթացի մեկնարկին ընդառաջ Տվյալների ինժեներ OTUS-ից:

Տվյալները, ինչպես և մեր փորձը, անընդհատ կուտակվում և զարգանում են: Հետևելու համար աշխարհի մեր մտավոր մոդելները պետք է հարմարվեն նոր տվյալներին, որոնցից մի քանիսը պարունակում են նոր չափումներ՝ դիտարկելու նոր եղանակներ, որոնց մասին նախկինում պատկերացում չունեինք: Այս մտավոր մոդելները շատ չեն տարբերվում աղյուսակի սխեմաներից, որոնք որոշում են, թե ինչպես ենք մենք դասակարգում և մշակում նոր տեղեկատվությունը:

Սա մեզ բերում է սխեմաների կառավարման խնդրին: Քանի որ բիզնեսի մարտահրավերներն ու պահանջները ժամանակի ընթացքում փոխվում են, ձեր տվյալների կառուցվածքը նույնպես փոխվում է: Դելտա լիճը հեշտացնում է նոր չափումների ներդրումը տվյալների փոփոխության հետ մեկտեղ: Օգտագործողները մուտք ունեն պարզ իմաստաբանության՝ իրենց աղյուսակի սխեմաները կառավարելու համար: Այս գործիքները ներառում են Schema Enforcement-ը, որը պաշտպանում է օգտատերերին իրենց աղյուսակները սխալներով կամ ավելորդ տվյալներով անգիտակցաբար աղտոտելուց, և Schema Evolution-ը, որը թույլ է տալիս արժեքավոր տվյալների նոր սյունակներ ավտոմատ կերպով ավելացնել համապատասխան վայրերում: Այս հոդվածում մենք ավելի խորը կանդրադառնանք այս գործիքների օգտագործմանը:

Հասկանալով աղյուսակի սխեմաները

Apache Spark-ի յուրաքանչյուր DataFrame պարունակում է սխեմա, որը սահմանում է տվյալների ձևը, ինչպիսիք են տվյալների տեսակները, սյունակները և մետատվյալները: Delta Lake-ի հետ սեղանի սխեման պահվում է JSON ձևաչափով գործարքների մատյանում:

Ի՞նչ է սխեմայի կիրարկումը:

Schema Enforcement-ը, որը նաև հայտնի է որպես Schema Validation, Դելտա լճի անվտանգության մեխանիզմ է, որն ապահովում է տվյալների որակը՝ մերժելով աղյուսակի սխեմային չհամապատասխանող գրառումները: Հանրաճանաչ ռեստորանի դիմացի սեղանի տիրուհու նման, նա ստուգում է, թե արդյոք աղյուսակում մուտքագրված տվյալների յուրաքանչյուր սյունակ կա սպասվող սյունակների համապատասխան ցանկում (այլ կերպ ասած՝ կա արդյոք նրանցից յուրաքանչյուրի համար «ամրագրում». ) և մերժում է ցանկում չգտնվող սյունակներով գրառումները:

Ինչպե՞ս է գործում սխեմայի կիրարկումը:

Delta Lake-ն օգտագործում է schema-on-write ստուգում, ինչը նշանակում է, որ բոլոր նոր գրառումները աղյուսակում ստուգվում են նպատակային աղյուսակի սխեմայի հետ համապատասխանության համար գրելու պահին: Եթե սխեման անհամապատասխան է, Delta Lake-ն ամբողջությամբ դադարեցնում է գործարքը (տվյալներ չեն գրվում) և բացառություն է ստեղծում անհամապատասխանության մասին օգտվողին ծանուցելու համար:
Դելտա Լեյքը օգտագործում է հետևյալ կանոնները՝ որոշելու, թե արդյոք գրառումը համապատասխանում է աղյուսակին: Գրելու ենթակա DataFrame:

չի կարող պարունակել լրացուցիչ սյունակներ, որոնք նպատակային աղյուսակի սխեմայում չեն: Ընդհակառակը, ամեն ինչ լավ է, եթե մուտքային տվյալները չեն պարունակում աղյուսակի բացարձակապես բոլոր սյունակները. այս սյունակներին պարզապես վերագրվելու են զրոյական արժեքներ:
չի կարող ունենալ սյունակների տվյալների տեսակներ, որոնք տարբերվում են թիրախային աղյուսակի սյունակների տվյալների տեսակներից: Եթե թիրախային աղյուսակի սյունակը պարունակում է 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.

Ինքնաբերաբար նոր սյունակներ ավելացնելու փոխարեն, Delta Lake-ը պարտադրում է սխեմա և դադարում գրել: Որպեսզի օգնի որոշել, թե որ սյունակը (կամ սյունակների խումբն է) առաջացնում անհամապատասխանություն, Spark-ը համեմատության համար դուրս է հանում երկու սխեմաները stack-ի հետքից:

Ո՞րն է սխեմայի կիրառման օգուտը:

Քանի որ սխեմայի կիրարկումը բավականին խիստ ստուգում է, այն հիանալի գործիք է օգտագործել որպես մաքուր, լիովին փոխակերպված տվյալների հավաքածու, որը պատրաստ է արտադրության կամ սպառման: Սովորաբար կիրառվում է աղյուսակների վրա, որոնք ուղղակիորեն սնուցում են տվյալներ.

Մեքենայի ուսուցման ալգորիթմներ
BI վահանակներ
Տվյալների վերլուծության և վիզուալիզացիայի գործիքներ
Ցանկացած արտադրական համակարգ, որը պահանջում է բարձր կառուցվածքային, խիստ տպագրված իմաստային սխեմաներ:

Այս վերջին խոչընդոտին իրենց տվյալները պատրաստելու համար շատ օգտատերեր օգտագործում են պարզ «բազմ հոփ» ճարտարապետություն, որն աստիճանաբար ներդնում է կառուցվածքն իրենց աղյուսակներում: Այս մասին ավելին իմանալու համար կարող եք ծանոթանալ հոդվածին Արտադրական կարգի մեքենայական ուսուցում Delta Lake-ի հետ:

Իհարկե, սխեմայի կիրառումը կարող է օգտագործվել ձեր խողովակաշարի ցանկացած կետում, բայց հիշեք, որ այս դեպքում աղյուսակի հոսքը կարող է հիասթափեցնող լինել, քանի որ, օրինակ, մոռացել եք, որ մուտքային տվյալներին ավելացրել եք ևս մեկ սյունակ:

Տվյալների նոսրացման կանխարգելում

Մինչ այժմ դուք կարող եք մտածել, թե ինչի մասին է այս աղմուկը: Ի վերջո, երբեմն անսպասելի «սխեմայի անհամապատասխանության» սխալը կարող է խանգարել ձեզ ձեր աշխատանքային գործընթացում, հատկապես, եթե դուք նոր եք Դելտա լճում: Ինչու՞ թույլ չտալ, որ սխեման փոխվի ըստ անհրաժեշտության, որպեսզի ես կարողանամ գրել իմ DataFrame-ը, անկախ ամեն ինչից:

Ինչպես հին ասացվածքն է ասում, «կանխարգելման մեկ ունցիան արժե մեկ ֆունտ բուժել»: Ինչ-որ պահի, եթե չհոգնեք ձեր սխեմայի կիրառման վրա, տվյալների տիպի համատեղելիության խնդիրները կհանգեցնեն իրենց տգեղ գլուխներին. թվացյալ համասեռ չմշակված տվյալների աղբյուրները կարող են պարունակել եզրային դեպքեր, կոռումպացված սյունակներ, սխալ քարտեզագրումներ կամ այլ սարսափելի բաներ, որոնց մասին կարելի է երազել: մղձավանջներ. Լավագույն մոտեցումը այս թշնամիներին դարպասի մոտ կանգնեցնելն է` սխեմայի կիրառմամբ, և նրանց հետ վարվել լույսի ներքո, այլ ոչ թե ավելի ուշ, երբ նրանք սկսում են թաքնվել ձեր արտադրության կոդի մութ խորքերում:

Սխեմայի կիրառումը ձեզ երաշխավորում է, որ ձեր աղյուսակի սխեման չի փոխվի, քանի դեռ դուք չեք հաստատել փոփոխությունը: Սա կանխում է տվյալների նոսրացումը, որը կարող է առաջանալ, երբ նոր սյունակներն այնքան հաճախ են ավելացվում, որ նախկինում արժեքավոր, սեղմված աղյուսակները կորցնում են իրենց նշանակությունն ու օգտակարությունը տվյալների հեղեղման պատճառով: Խրախուսելով ձեզ դիտավորյալ լինել, սահմանել բարձր չափանիշներ և ակնկալել բարձր որակ, սխեմաների կիրառումն անում է հենց այն, ինչ նախատեսված էր անել՝ օգնում է ձեզ լինել բարեխիղճ և ձեր աղյուսակները մաքուր:

Եթե հետագա քննարկման արդյունքում որոշեք, որ դուք իսկապես անհրաժեշտության դեպքում ավելացնել նոր սյունակ. խնդիր չկա, ստորև ներկայացված է մեկ տողով ուղղում: Լուծումը շղթայի էվոլյուցիան է:

Ի՞նչ է սխեմայի էվոլյուցիան:

Schema evolution-ը հնարավորություն է տալիս օգտվողներին հեշտությամբ փոխել ընթացիկ աղյուսակի սխեման՝ համաձայն ժամանակի ընթացքում փոփոխվող տվյալների: Այն առավել հաճախ օգտագործվում է հավելվածի կամ վերագրանցման գործողություն կատարելիս՝ սխեման ավտոմատ կերպով հարմարեցնելու համար՝ ներառելու մեկ կամ մի քանի նոր սյունակներ:

Ինչպե՞ս է գործում սխեմայի էվոլյուցիան:

Հետևելով նախորդ բաժնի օրինակին՝ մշակողները կարող են հեշտությամբ օգտագործել սխեմայի էվոլյուցիան՝ ավելացնելու նոր սյունակներ, որոնք նախկինում մերժվել են սխեմայի անհամապատասխանության պատճառով: Շղթայի էվոլյուցիան ակտիվանում է ավելացնելով .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-ին, որոնք չպետք է այնտեղ լինեն): Սա ձեր սխեման տեղափոխելու ամենահեշտ ձևն է, քանի որ այն ավտոմատ կերպով ավելացնում է ճիշտ սյունակների անունները և տվյալների տեսակները՝ առանց դրանք հստակորեն հայտարարելու:

Ամփոփում

Սխեմայի կիրարկումը մերժում է ցանկացած նոր սյունակ կամ սխեմայի այլ փոփոխություններ, որոնք անհամատեղելի են ձեր աղյուսակի հետ: Սահմանելով և պահպանելով այս բարձր ստանդարտները՝ վերլուծաբաններն ու ինժեներները կարող են վստահել, որ իրենց տվյալները ունեն ամբողջականության ամենաբարձր մակարդակը՝ դրանք փոխանցելով հստակ և հստակ՝ թույլ տալով նրանց ավելի լավ բիզնես որոշումներ կայացնել:

Մյուս կողմից, սխեմայի էվոլյուցիան լրացնում է կիրարկումը՝ պարզեցնելով ենթադրյալ ավտոմատ սխեմայի փոփոխություններ: Ի վերջո, սյունակ ավելացնելը դժվար չպետք է լինի:

Սխեմայի հարկադիր կիրառումը յան է, որտեղ սխեմայի էվոլյուցիան ինն է: Միասին օգտագործման դեպքում այս հատկանիշները դարձնում են աղմուկի ճնշումը և ազդանշանի կարգավորումն ավելի հեշտ, քան երբևէ:

Ցանկանում ենք նաև շնորհակալություն հայտնել Մուկուլ Մուրթիին և Պրանավ Անանդին այս հոդվածում իրենց ներդրման համար:

Այս շարքի այլ հոդվածներ.

Սուզվեք Դելտա լճի մեջ. Գործարքների գրանցամատյանի բացում