မြစ်ဝကျွန်းပေါ်ရေကန်သို့ ခုန်ဆင်းပါ- Schema Enforcement နှင့် Evolution

ဟေး ဟာဘ! ဆောင်းပါးရဲ့ ဘာသာပြန်ချက်ကို မင်းရဲ့အာရုံကို ငါတင်ပြတယ်။ "မြစ်ဝကျွန်းပေါ်ရေကန်သို့ ဒိုင်ဗင်ထိုးခြင်း- အစီအစဉ်အား တွန်းအားပေးမှုနှင့် ဆင့်ကဲဖြစ်စဉ်" စာရေးဆရာ Burak Yavuz၊ Brenner Heintz နှင့် Denny Lee၊ ဒေတာအင်ဂျင်နီယာ OTUS မှ

ကျွန်ုပ်တို့၏ အတွေ့အကြုံကဲ့သို့ ဒေတာသည် အဆက်မပြတ် စုဆောင်းနေပြီး တိုးတက်နေပါသည်။ လိုက်လျောညီထွေဖြစ်စေရန်၊ ကျွန်ုပ်တို့၏ကမ္ဘာ၏စိတ်ပိုင်းဆိုင်ရာပုံစံများသည် ကိန်းဂဏန်းအသစ်များ—ယခင်ကကျွန်ုပ်တို့မသိခဲ့သောအရာများကိုကြည့်ရှုရန်နည်းလမ်းအသစ်များပါရှိသော အတိုင်းအတာအသစ်အချို့ပါရှိသော ဒေတာအသစ်များနှင့် လိုက်လျောညီထွေရှိရပါမည်။ ဤစိတ်ပိုင်းဆိုင်ရာ မော်ဒယ်များသည် အချက်အလက်အသစ်များကို အမျိုးအစားခွဲပုံနှင့် စီမံဆောင်ရွက်ပုံကို ဆုံးဖြတ်သည့် ဇယားဇယားများနှင့် များစွာကွာခြားမှုမရှိပါ။

၎င်းသည် schema စီမံခန့်ခွဲမှုဆိုင်ရာပြဿနာကိုကျွန်ုပ်တို့ထံရောက်စေသည်။ လုပ်ငန်းစိန်ခေါ်မှုများနှင့် လိုအပ်ချက်များသည် အချိန်နှင့်အမျှ ပြောင်းလဲလာသည်နှင့်အမျှ သင့်ဒေတာ၏ဖွဲ့စည်းပုံသည်လည်း အလားတူပင်ဖြစ်သည်။ ဒေတာပြောင်းလဲမှုကြောင့် Delta Lake သည် တိုင်းတာမှုအသစ်များကို မိတ်ဆက်ရန် လွယ်ကူစေသည်။ အသုံးပြုသူများသည် ၎င်းတို့၏ table schemas ကို စီမံခန့်ခွဲရန် ရိုးရှင်းသော ဝေါဟာရများကို အသုံးပြုခွင့်ရှိသည်။ ဤကိရိယာများတွင် အသုံးပြုသူများကို အမှားအယွင်းများ သို့မဟုတ် မလိုအပ်သောဒေတာများဖြင့် ၎င်းတို့၏ဇယားများကို မရည်ရွယ်ဘဲ ညစ်ညမ်းစေခြင်းမှ ကာကွယ်ပေးသည့် Schema Enforcement နှင့် Schema Evolution ၊ တန်ဖိုးရှိသောဒေတာကော်လံအသစ်များကို သင့်လျော်သောနေရာများတွင် အလိုအလျောက်ထည့်သွင်းနိုင်စေမည့် Schema Evolution ပါဝင်သည်။ ဤဆောင်းပါးတွင်၊ ဤကိရိယာများကို အသုံးပြုခြင်းသို့ ပိုမိုနက်ရှိုင်းစွာ နက်နက်နဲနဲ လေ့လာပါမည်။

Table Schemas နားလည်ခြင်း။

Apache Spark ရှိ DataFrame တစ်ခုစီတွင် ဒေတာအမျိုးအစားများ၊ ကော်လံများနှင့် မက်တာဒေတာကဲ့သို့သော ဒေတာပုံစံကို သတ်မှတ်ပေးသည့် schema ပါရှိသည်။ Delta Lake ဖြင့်၊ ဇယားအစီအစဉ်ကို ငွေပေးငွေယူမှတ်တမ်းအတွင်း JSON ဖော်မတ်ဖြင့် သိမ်းဆည်းထားသည်။

အစီအစဥ်ပြဋ္ဌာန်းခြင်းဟူသည် အဘယ်နည်း။

Schema Validation ဟုလည်းလူသိများသော Schema Enforcement သည် ဇယား၏ schema နှင့်မကိုက်ညီသော မှတ်တမ်းများကို ပယ်ချခြင်းဖြင့် ဒေတာအရည်အသွေးကို သေချာစေသည့် Delta Lake ရှိ လုံခြုံရေးယန္တရားတစ်ခုဖြစ်သည်။ လူကြိုက်များသော ကြိုတင်မှာယူမှုသီးသန့် စားသောက်ဆိုင်တစ်ခု၏ ရှေ့စားပွဲမှ အိမ်ရှင်မကဲ့သို့ပင်၊ ဇယားထဲသို့ ထည့်လိုက်သော ဒေတာကော်လံတစ်ခုစီသည် မျှော်မှန်းထားသော ကော်လံများစာရင်းတွင် ပါဝင်ခြင်း ရှိ၊ ) နှင့် စာရင်းထဲမပါသော ကော်လံများပါသည့် မည်သည့်မှတ်တမ်းကိုမဆို ငြင်းပယ်သည်။

schema enforcement သည်မည်သို့အလုပ်လုပ်သနည်း။

Delta Lake သည် schema-on-write checking ကိုအသုံးပြုသည်၊ ဆိုလိုသည်မှာ ဇယားတွင်ရေးထားသည့်အသစ်များအားလုံးသည် စာရေးချိန်၌ ပစ်မှတ်ဇယား၏ schema နှင့် လိုက်ဖက်မှုရှိမရှိ စစ်ဆေးပြီးဖြစ်သည်။ schema သည် မကိုက်ညီပါက၊ Delta Lake သည် ငွေပေးငွေယူကို လုံးလုံးလျားလျား ပျက်ပြယ်သွားသည် (ဒေတာမရေးထား) နှင့် ကွဲလွဲမှုရှိကြောင်း သုံးစွဲသူအား အသိပေးရန် ခြွင်းချက်တစ်ခု ပေါ်ပေါက်လာသည်။
မှတ်တမ်းတစ်ခုသည် ဇယားတစ်ခုနှင့် ကိုက်ညီမှုရှိမရှိ ဆုံးဖြတ်ရန် Delta Lake သည် အောက်ပါစည်းမျဉ်းများကို အသုံးပြုသည်။ ရေးနိုင်သော ဒေတာဘောင်-

• ပစ်မှတ်ဇယား၏ အစီအစဉ်တွင် မရှိသော နောက်ထပ်ကော်လံများ မပါဝင်နိုင်ပါ။ အပြန်အလှန်အားဖြင့်၊ ဝင်လာသောဒေတာတွင်ဇယားမှကော်လံများလုံးဝမပါဝင်ပါက၊ ဤကော်လံများကို ရိုးရိုးရှင်းရှင်း null တန်ဖိုးများသတ်မှတ်ပေးမည်ဖြစ်သည်။
• ပစ်မှတ်ဇယားရှိ ကော်လံများ၏ ဒေတာအမျိုးအစားများနှင့် ကွဲပြားသော ကော်လံဒေတာအမျိုးအစားများ မရရှိနိုင်ပါ။ ပစ်မှတ်ဇယားကော်လံတွင် StringType ဒေတာပါရှိသည်၊ သို့သော် DataFrame ရှိ သက်ဆိုင်ရာကော်လံတွင် IntegerType ဒေတာပါဝင်နေပါက၊ schema enforcement သည် ခြွင်းချက်တစ်ခုအား ထုတ်ပစ်မည်ဖြစ်ပြီး စာရေးခြင်းလုပ်ဆောင်မှုကို တားဆီးမည်ဖြစ်သည်။
• ကိစ္စရပ်အတွက်သာ ကွဲပြားသော ကော်လံအမည်များ မပါဝင်နိုင်ပါ။ ဆိုလိုသည်မှာ သင့်တွင် 'Foo' နှင့် 'foo' ဟု အမည်ပေးထားသော ကော်လံများကို ဇယားတစ်ခုတည်းတွင် သတ်မှတ်၍မရပါ။ Spark ကို case-sensitive သို့မဟုတ် case-insensitive (မူလ) မုဒ်တွင် သုံးနိုင်သော်လည်း Delta Lake သည် case-preserving ဖြစ်သော်လည်း schema storage အတွင်းတွင် အာရုံမခံနိုင်ပါ။ ကော်လံအချက်အလက်ကို သိမ်းဆည်းပြီး ပြန်ပို့သည့်အခါ ပါကေးသည် အသေးအဖွဲဖြစ်သည်။ ဖြစ်နိုင်ချေရှိသော အမှားအယွင်းများ၊ ဒေတာပျက်စီးခြင်း သို့မဟုတ် ဒေတာဆုံးရှုံးခြင်း (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 သည် schema တစ်ခုကို သတ်မှတ်ပြီး ရေးသားခြင်းကို ရပ်လိုက်သည်။ ကွဲလွဲမှုကိုဖြစ်စေသော မည်သည့်ကော်လံ (သို့မဟုတ် ကော်လံအစုံ) ကို ဆုံးဖြတ်ရာတွင် ကူညီရန်အတွက် Spark သည် နှိုင်းယှဉ်မှုအတွက် stack trace မှ schemas နှစ်ခုလုံးကို ထုတ်သည်။

အစီအစဥ်ကို ကျင့်သုံးခြင်း၏ အကျိုးကျေးဇူးကား အဘယ်နည်း။

schema enforcement သည် အတော်အတန်တင်းကြပ်သောစစ်ဆေးမှုတစ်ခုဖြစ်သောကြောင့်၊ ထုတ်လုပ်ရန် သို့မဟုတ် သုံးစွဲရန်အဆင်သင့်ဖြစ်သည့် သန့်ရှင်းပြီး အပြည့်အဝပြောင်းလဲထားသောဒေတာအစုံအတွက် တံခါးစောင့်အဖြစ်အသုံးပြုရန် အကောင်းဆုံးကိရိယာတစ်ခုဖြစ်သည်။ ပုံမှန်အားဖြင့် ဒေတာကို တိုက်ရိုက်ကျွေးသော ဇယားများတွင် အသုံးပြုသည်-

• စက်သင်ယူမှု algorithms
• BI ဒက်ရှ်ဘုတ်များ
• ဒေတာခွဲခြမ်းစိတ်ဖြာခြင်းနှင့် စိတ်ကူးပုံဖော်ခြင်း ကိရိယာများ
• မြင့်မားသောဖွဲ့စည်းပုံ၊ ပြင်းထန်စွာရိုက်ထားသော ဝေါဟာရအစီအစဉ်များ လိုအပ်သည့် မည်သည့်ထုတ်လုပ်မှုစနစ်မဆို။

ဤနောက်ဆုံးအတားအဆီးအတွက် ၎င်းတို့၏ဒေတာကို ပြင်ဆင်ရန်၊ အသုံးပြုသူအများအပြားသည် ၎င်းတို့၏ဇယားများတွင် တည်ဆောက်ပုံကို တဖြည်းဖြည်းမိတ်ဆက်သည့် ရိုးရှင်းသော "multi-hop" ဗိသုကာကို အသုံးပြုကြသည်။ ဤအကြောင်းပိုမိုလေ့လာရန်၊ ဆောင်းပါးကိုသင်စစ်ဆေးနိုင်သည်။ Delta Lake ဖြင့် ထုတ်လုပ်မှုအဆင့် စက်သင်ယူခြင်း။

ဟုတ်ပါတယ်၊ schema enforcement ကို သင့်ပိုက်လိုင်းရဲ့ ဘယ်နေရာမှာမဆို သုံးနိုင်ပေမယ့် ဒီကိစ္စမှာ ဇယားတစ်ခုဆီ streaming ကို စိတ်ရှုပ်စေနိုင်ပါတယ် ဥပမာ၊ ဝင်လာတဲ့ data ထဲကို နောက်ထပ်ကော်လံတစ်ခုထပ်ထည့်လိုက်တာကို မေ့သွားလို့ပါပဲ။

Data dilution ကို ကာကွယ်ပေးခြင်း။

အခုအချိန်မှာ မင်းဘာတွေ ရှုပ်နေလဲလို့ တွေးနေလိမ့်မယ်။ အထူးသဖြင့် သင်သည် Delta Lake သို့အသစ်ဖြစ်နေပါက၊ တစ်ခါတစ်ရံတွင် မမျှော်လင့်ထားသော "schema mismatch" အမှားတစ်ခုသည် သင့်လုပ်ငန်းအသွားအလာတွင် သင့်အား အနှောင့်အယှက်ပေးနိုင်ပါသည်။ ကျွန်ုပ်သည် ကျွန်ုပ်၏ DataFrame ကို မည်သို့ပင်ဖြစ်စေ ကျွန်ုပ်၏ DataFrame ကို ရေးနိုင်စေရန် လိုအပ်သလို schema ကို အဘယ်ကြောင့် ပြောင်းလဲစေသနည်း။

ရှေးဆိုရိုးစကားအတိုင်း "ကာကွယ်ခြင်းတစ်အောင်စသည် ကုသခြင်း၏တန်ဖိုး" တစ်ချိန်ချိန်တွင် သင့်အစီအစဉ်ကို အကောင်အထည်ဖော်ရန် ဂရုမစိုက်ပါက၊ ဒေတာအမျိုးအစား လိုက်ဖက်ညီမှု ပြဿနာများသည် ၎င်းတို့၏ ရုပ်ဆိုးအကျည်းတန်သော ဦးခေါင်းများကို ကျောခိုင်းသွားလိမ့်မည် - တစ်သားတည်းဖြစ်ပုံရသော ဒေတာအရင်းအမြစ်များတွင် အနားသတ်ကိစ္စများ၊ ပျက်စီးနေသောကော်လံများ၊ ပုံစံမမှန်သောမြေပုံဆွဲခြင်း သို့မဟုတ် အခြားကြောက်မက်ဖွယ်အရာများကို စိတ်ကူးယဉ်ကြည့်ရန် အိပ်မက်ဆိုးများ။ အကောင်းဆုံးနည်းလမ်းမှာ - schema enforcement ဖြင့် ဂိတ်ပေါက်တွင် ဤရန်သူများကို ရပ်တန့်ပြီး သင့်ထုတ်လုပ်ရေးကုဒ်၏ နက်နဲသောအမှောင်ထဲတွင် ပုန်းအောင်းနေမည့်အစား နောက်ပိုင်းတွင် ၎င်းတို့ကို အလင်းထဲတွင် ကိုင်တွယ်ဖြေရှင်းရန်ဖြစ်သည်။

ဇယားကွက်ကို လိုက်နာခြင်းက အပြောင်းအလဲကို သင်အတည်ပြုမပေးပါက သင့်ဇယား၏ပုံစံသည် ပြောင်းလဲမည်မဟုတ်ကြောင်း အာမခံချက်ပေးသည်။ ၎င်းသည် ကော်လံအသစ်များကို မကြာခဏ ပေါင်းထည့်သောအခါတွင် ဒေတာများ ပျော့သွားခြင်းကို တားဆီးပေးပါသည်။ ယခင်က တန်ဖိုးရှိသော၊ ချုံ့ထားသော ဇယားများသည် ဒေတာများ ရေလျှံမှုကြောင့် အဓိပ္ပါယ်နှင့် အသုံးဝင်မှု ဆုံးရှုံးသွားနိုင်သည်။ သင့်အား ရည်ရွယ်ချက်ရှိရှိဖြစ်စေရန်၊ မြင့်မားသောစံနှုန်းများချမှတ်ကာ အရည်အသွေးမြင့်မားမှုကို မျှော်လင့်ခြင်းဖြင့်၊ schema enforcement သည် ၎င်းလုပ်ဆောင်ရန် ဒီဇိုင်းထုတ်ထားသည့်အတိုင်း လုပ်ဆောင်ပေးသည်—သင့်အား အသိစိတ်ရှိနေရန်နှင့် သင်၏စာရင်းဇယားများကို သန့်ရှင်းစေရန် ကူညီပေးပါသည်။

ထပ်လောင်းစဉ်းစားရင် မင်းတကယ်ပဲ ဆုံးဖြတ်မှာ လိုအပ် ကော်လံအသစ်တစ်ခုထည့်ပါ - ပြဿနာမရှိပါ၊ အောက်တွင်ဖော်ပြထားသည်မှာ စာကြောင်းတစ်ကြောင်းတည်းဖြစ်သည်။ ဖြေရှင်းချက်သည် circuit ၏ဆင့်ကဲဖြစ်စဉ်ဖြစ်သည်။

schema ဆင့်ကဲဖြစ်စဉ်ဆိုတာဘာလဲ။

Schema ဆင့်ကဲဖြစ်စဉ်သည် အသုံးပြုသူများအား အချိန်နှင့်အမျှပြောင်းလဲနေသောဒေတာအရ လက်ရှိဇယားပုံစံကို အလွယ်တကူပြောင်းလဲနိုင်စေမည့် အင်္ဂါရပ်တစ်ခုဖြစ်သည်။ ကော်လံအသစ်တစ်ခု သို့မဟုတ် တစ်ခုထက်ပိုသောကော်လံအသစ်များပါဝင်ရန် schema ကို အလိုအလျောက်လိုက်လျောညီထွေဖြစ်စေရန်အတွက် နောက်ဆက်တွဲတစ်ခု သို့မဟုတ် ပြန်လည်ရေးခြင်းလုပ်ဆောင်သည့်အခါတွင် ၎င်းကို အများဆုံးအသုံးပြုသည်။

schema ဆင့်ကဲဖြစ်စဉ် မည်သို့အလုပ်လုပ်သနည်း။

ယခင်အပိုင်းမှ နမူနာကို လိုက်နာခြင်းဖြင့်၊ developer များသည် schema ကွဲလွဲမှုကြောင့် ယခင်က ပယ်ချခံခဲ့ရသော ကော်လံအသစ်များကို ထည့်သွင်းရန်အတွက် ဆော့ဖ်ဝဲအင်ဂျင်နီယာများသည် schema ဆင့်ကဲဖြစ်စဉ်ကို အလွယ်တကူ အသုံးပြုနိုင်သည်။ ပေါင်းထည့်ခြင်းဖြင့် circuit ဆင့်ကဲဖြစ်စဉ်ကို အသက်သွင်းသည်။ .option('mergeSchema', 'true') မင်းရဲ့ Spark အဖွဲ့ဆီ .write или .writeStream.

# Добавьте параметр mergeSchema
loans.write.format("delta") 
           .option("mergeSchema", "true") 
           .mode("append") 
           .save(DELTALAKE_SILVER_PATH)

ဂရပ်ကိုကြည့်ရန်၊ အောက်ပါ Spark SQL query ကို run ပါ။

# Создайте график с новым столбцом, чтобы подтвердить, что запись прошла успешно
%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 configuration သို့။ သို့သော် schema enforcement သည် သင့်အား မရည်ရွယ်ဘဲ schema ကွဲလွဲမှုများကို သတိပေးတော့မည်ဖြစ်သောကြောင့် ၎င်းကို သတိဖြင့်အသုံးပြုပါ။

တောင်းဆိုမှုတွင် ပါရာမီတာကို ထည့်သွင်းခြင်းဖြင့် mergeSchemaDataFrame တွင်ပါဝင်သော်လည်း ပစ်မှတ်ဇယားတွင်မပါဝင်သည့် ကော်လံအားလုံးကို စာရေးခြင်းလုပ်ငန်း၏တစ်စိတ်တစ်ပိုင်းအဖြစ် schema ၏အဆုံးတွင် အလိုအလျောက်ထည့်သွင်းပါသည်။ Nested အကွက်များကိုလည်း ထည့်နိုင်ပြီး သက်ဆိုင်ရာဖွဲ့စည်းပုံကော်လံများ၏အဆုံးတွင် ၎င်းတို့ကိုလည်း ပေါင်းထည့်မည်ဖြစ်သည်။

ဒေတာအင်ဂျင်နီယာများနှင့် ဒေတာသိပ္ပံပညာရှင်များသည် ကော်လံအသစ်များ (မကြာသေးမီက ခြေရာခံလိုက်သော မက်ထရစ် သို့မဟုတ် ယခုလ၏ အရောင်းစွမ်းဆောင်ရည်ကော်လံ) တွင် ကော်လံအသစ်များထည့်ရန် ဤရွေးချယ်မှုကို အသုံးပြုနိုင်ပြီး ၎င်းတို့၏ လက်ရှိစက်သင်ယူမှုထုတ်လုပ်မှုဇယားများတွင် ကော်လံအဟောင်းများကို အခြေခံ၍ မော်ဒယ်များကို ချိုးဖျက်ခြင်းမပြုဘဲ၊

ဇယားတစ်ခုထပ်တိုးခြင်း သို့မဟုတ် ပြန်လည်ရေးနေစဉ်အတွင်း အောက်ပါ schema ပြောင်းလဲမှုအမျိုးအစားများကို schema ဆင့်ကဲဖြစ်စဉ်၏ တစ်စိတ်တစ်ပိုင်းအဖြစ် ခွင့်ပြုသည်-

• ကော်လံအသစ်များထည့်ခြင်း (၎င်းသည် အဖြစ်အများဆုံး မြင်ကွင်းဖြစ်သည်)
• NullType -> အခြားအမျိုးအစားမှ ဒေတာအမျိုးအစားများကို ပြောင်းလဲခြင်း သို့မဟုတ် ByteType -> ShortType -> IntegerType မှ မြှင့်တင်ခြင်း

schema ဆင့်ကဲဖြစ်စဉ်အတွင်း ခွင့်မပြုသော အခြားပြောင်းလဲမှုများသည် schema နှင့် data ကို ပေါင်းထည့်ခြင်းဖြင့် ပြန်လည်ရေးသားရန် လိုအပ်သည် .option("overwriteSchema", "true"). ဥပမာအားဖြင့်၊ ကော်လံ "Foo" သည် မူလက ကိန်းပြည့်ဖြစ်ပြီး schema အသစ်သည် string data type ဖြစ်ပါက၊ Parquet(data) ဖိုင်များအားလုံး ပြန်လည်ရေးသားရန် လိုအပ်မည်ဖြစ်ပါသည်။ ဤကဲ့သို့သောပြောင်းလဲမှုများပါဝင်သည်-

• ကော်လံကိုဖျက်ခြင်း။
• ရှိပြီးသား ကော်လံတစ်ခု၏ ဒေတာအမျိုးအစားကို ပြောင်းလဲခြင်း (နေရာ)၊
• ကိစ္စအတွက်သာ ကွဲပြားသော ကော်လံများကို အမည်ပြောင်းခြင်း (ဥပမာ၊ "Foo" နှင့် "foo")

နောက်ဆုံးတွင်၊ Spark 3.0 ၏နောက်ထွက်ရှိမှုနှင့်အတူ၊ တိကျပြတ်သားသော DDL ကို အပြည့်အဝပံ့ပိုးပေးမည် (ALTER TABLE ကိုအသုံးပြု၍) သုံးစွဲသူများသည် ဇယားကွက်ပုံစံများပေါ်တွင် အောက်ပါလုပ်ဆောင်ချက်များကို လုပ်ဆောင်ခွင့်ပြုသည်-

• ကော်လံများထည့်ခြင်း။
• ကော်လံ မှတ်ချက်များ ပြောင်းလဲခြင်း။
• ငွေပေးငွေယူမှတ်တမ်းကို သိမ်းဆည်းသည့်အချိန်ကို သတ်မှတ်ခြင်းကဲ့သို့သော ဇယား၏အပြုအမူကို ထိန်းချုပ်သည့် ဇယားဂုဏ်သတ္တိများ သတ်မှတ်ခြင်း။

ပတ်လမ်းဆင့်ကဲဖြစ်စဉ်၏ အကျိုးကျေးဇူးကား အဘယ်နည်း။

Schema ဆင့်ကဲဖြစ်စဉ်ကို သင်အချိန်တိုင်းတွင် အသုံးပြုနိုင်သည်။ ရည်ရွယ်သည်။ သင့်ဇယား၏ schema ကိုပြောင်းပါ (ထိုနေရာတွင် မဖြစ်သင့်သော သင်၏ DataFrame သို့ ကော်လံများကို မတော်တဆ ထည့်လိုက်သောအခါနှင့် ဆန့်ကျင်ဘက်ဖြစ်သည်)။ ၎င်းသည် မှန်ကန်သောကော်လံအမည်များနှင့် ဒေတာအမျိုးအစားများကို အတိအလင်းကြေညာစရာမလိုဘဲ သင့်အစီအစဉ်ကို ပြောင်းရွှေ့ရန် အလွယ်ကူဆုံးနည်းလမ်းဖြစ်သည်။

ကောက်ချက်

Schema enforcement သည် သင့်ဇယားနှင့် ကိုက်ညီမှုမရှိသော ကော်လံအသစ်များ သို့မဟုတ် အခြားသော schema အပြောင်းအလဲများကို ငြင်းပယ်သည်။ ဤမြင့်မားသောစံနှုန်းများကို သတ်မှတ်ထိန်းသိမ်းခြင်းဖြင့်၊ လေ့လာသုံးသပ်သူများနှင့် အင်ဂျင်နီယာများသည် ၎င်းတို့၏ဒေတာသည် ခိုင်မာမှုအမြင့်ဆုံးအဆင့်ရှိကြောင်း ယုံကြည်နိုင်ပြီး ၎င်းကို ရှင်းလင်းပြတ်သားစွာ ဆက်သွယ်နိုင်ပြီး ပိုမိုကောင်းမွန်သော စီးပွားရေးဆိုင်ရာ ဆုံးဖြတ်ချက်များချနိုင်စေမည်ဖြစ်သည်။

အခြားတစ်ဖက်တွင်၊ schema ဆင့်ကဲဖြစ်စဉ်သည် ရိုးရှင်းစေခြင်းဖြင့် ပြဋ္ဌာန်းချက်များကို ဖြည့်စွက်ပေးသည်။ စွပ်စွဲသည်။ အလိုအလျောက် schema အပြောင်းအလဲများ။ ပြီးနောက်၊ ကော်လံတစ်ခုထည့်ရန် မခက်ခဲသင့်ပါ။

အစီအစဥ်၏အတင်းအကြပ်အသုံးချမှုသည် ယန်ဖြစ်ပြီး၊ အစီအစဥ်၏ဆင့်ကဲပြောင်းလဲမှုမှာ ယင်ဖြစ်သည်။ တွဲသုံးသောအခါတွင်၊ ဤအင်္ဂါရပ်များသည် ဆူညံသံများကို ထိန်းညှိပေးပြီး အချက်ပြချိန်ညှိခြင်းကို ယခင်ကထက် ပိုမိုလွယ်ကူစေသည်။

Mukul Murthy နှင့် Pranav Anand တို့ကိုလည်း ဤဆောင်းပါးအတွက် ၎င်းတို့၏ ပံ့ပိုးကူညီမှုများကိုလည်း ကျေးဇူးတင်ရှိပါသည်။

ဤစီးရီးရှိ အခြားဆောင်းပါးများ-

မြစ်ဝကျွန်းပေါ်ရေကန်သို့ ခုန်ဆင်းပါ- ငွေပေးငွေယူမှတ်တမ်းကို ထုပ်ပိုးခြင်း။

ဆက်စပ်ဆောင်းပါးများ

Delta Lake ဖြင့် ထုတ်လုပ်မှုအဆင့် စက်သင်ယူခြင်း။

Data lake ဆိုတာဘာလဲ။

သင်တန်းအကြောင်းပိုမိုလေ့လာပါ။

source: www.habr.com