🥇डेल्टा लेक डायव्ह: अंमलबजावणी आणि योजना उत्क्रांती

अहो हाब्र! लेखाचा अनुवाद मी तुमच्या लक्षात आणून देत आहे "डेल्टा लेकमध्ये डुबकी मारणे: स्कीमा अंमलबजावणी आणि उत्क्रांती" लेखक बुराक यावुझ, ब्रेनर हेंट्झ आणि डेनी ली, जे अभ्यासक्रम सुरू होण्याच्या अपेक्षेने तयार केले गेले होते डेटा अभियंता OTUS कडून.

डेटा, आमच्या अनुभवाप्रमाणे, सतत जमा होत आहे आणि विकसित होत आहे. चालू ठेवण्यासाठी, जगाच्या आमच्या मानसिक मॉडेल्सना नवीन डेटाशी जुळवून घेणे आवश्यक आहे, ज्यापैकी काही नवीन परिमाणे आहेत—आम्हाला आधी कल्पना नसलेल्या गोष्टींचे निरीक्षण करण्याचे नवीन मार्ग. हे मानसिक मॉडेल टेबल स्कीमापेक्षा फारसे वेगळे नाहीत जे आम्ही नवीन माहितीचे वर्गीकरण आणि प्रक्रिया कशी करतो हे निर्धारित करतात.

हे आम्हाला स्कीमा व्यवस्थापनाच्या समस्येवर आणते. व्यवसायातील आव्हाने आणि आवश्यकता कालांतराने बदलतात, त्याचप्रमाणे तुमच्या डेटाची रचनाही बदलते. डेल्टा लेक डेटा बदलते म्हणून नवीन मोजमाप सादर करणे सोपे करते. वापरकर्त्यांना त्यांचे सारणी स्कीमा व्यवस्थापित करण्यासाठी साध्या शब्दार्थांमध्ये प्रवेश आहे. या साधनांमध्ये स्कीमा एन्फोर्समेंट समाविष्ट आहे, जे वापरकर्त्यांना त्रुटी किंवा अनावश्यक डेटासह त्यांच्या टेबलचे अनावधानाने प्रदूषण करण्यापासून संरक्षण करते आणि स्कीमा इव्होल्यूशन, ज्यामुळे मौल्यवान डेटाचे नवीन स्तंभ योग्य ठिकाणी स्वयंचलितपणे जोडले जाऊ शकतात. या लेखात, आम्ही ही साधने वापरण्यात अधिक खोलवर जाऊ.

सारणी योजना समजून घेणे

Apache Spark मधील प्रत्येक DataFrame मध्ये डेटा प्रकार, स्तंभ आणि मेटाडेटा यासारख्या डेटाचे स्वरूप परिभाषित करणारी स्कीमा असते. डेल्टा लेकसह, टेबल स्कीमा व्यवहार लॉगमध्ये JSON फॉरमॅटमध्ये संग्रहित केला जातो.

योजना अंमलबजावणी म्हणजे काय?

स्कीमा अंमलबजावणी, ज्याला स्कीमा व्हॅलिडेशन असेही म्हणतात, ही डेल्टा लेकमधील एक सुरक्षा यंत्रणा आहे जी टेबलच्या स्कीमाशी जुळत नसलेल्या नोंदी नाकारून डेटा गुणवत्ता सुनिश्चित करते. केवळ-रिझर्व्हेशन असलेल्या लोकप्रिय रेस्टॉरंटच्या फ्रंट डेस्कवरील होस्टेसप्रमाणे, ती टेबलमध्ये प्रविष्ट केलेला डेटाचा प्रत्येक स्तंभ अपेक्षित स्तंभांच्या संबंधित सूचीमध्ये आहे की नाही हे तपासते (दुसर्‍या शब्दात, त्या प्रत्येकासाठी "आरक्षण" आहे की नाही. ), आणि सूचीमध्ये नसलेल्या स्तंभांसह कोणतेही रेकॉर्ड नाकारते.

स्कीमा अंमलबजावणी कशी कार्य करते?

डेल्टा लेक स्कीमा-ऑन-राइट चेकिंग वापरते, याचा अर्थ असा की टेबलवरील सर्व नवीन लेखन लेखनाच्या वेळी लक्ष्य सारणीच्या स्कीमाशी सुसंगततेसाठी तपासले जाते. स्कीमा विसंगत असल्यास, डेल्टा लेक व्यवहार पूर्णपणे रद्द करते (कोणताही डेटा लिहिलेला नाही) आणि विसंगती वापरकर्त्यास सूचित करण्यासाठी अपवाद वाढवते.
रेकॉर्ड टेबलशी सुसंगत आहे की नाही हे निर्धारित करण्यासाठी डेल्टा लेक खालील नियम वापरते. लिहिण्यायोग्य डेटाफ्रेम:

लक्ष्य सारणीच्या स्कीमामध्ये नसलेले अतिरिक्त स्तंभ असू शकत नाहीत. याउलट, जर येणार्‍या डेटामध्ये सारणीतील सर्व स्तंभ नसतील तर सर्वकाही ठीक आहे - या स्तंभांना फक्त शून्य मूल्ये नियुक्त केली जातील.
लक्ष्य सारणीमधील स्तंभांच्या डेटा प्रकारांपेक्षा भिन्न स्तंभ डेटा प्रकार असू शकत नाहीत. लक्ष्य सारणी स्तंभामध्ये स्ट्रिंगटाइप डेटा असल्यास, परंतु डेटाफ्रेममधील संबंधित स्तंभामध्ये इंटीजरटाइप डेटा असल्यास, स्कीमा अंमलबजावणी अपवाद करेल आणि लेखन ऑपरेशन होण्यापासून प्रतिबंधित करेल.
कॉलमची नावे असू शकत नाहीत जी फक्त केसमध्ये भिन्न असतील. याचा अर्थ असा की तुमच्याकडे 'फू' आणि 'फू' नावाचे स्तंभ एकाच टेबलमध्ये परिभाषित केले जाऊ शकत नाहीत. स्पार्क केस-संवेदनशील किंवा केस-संवेदनशील (डीफॉल्ट) मोडमध्ये वापरला जाऊ शकतो, तर डेल्टा लेक केस-संरक्षित आहे परंतु स्कीमा स्टोरेजमध्ये असंवेदनशील आहे. स्तंभ माहिती संचयित आणि परत करताना Parquet केस संवेदनशील असते. संभाव्य त्रुटी, डेटा भ्रष्टाचार किंवा डेटा हानी टाळण्यासाठी (डेटाब्रिक्सवर आम्ही वैयक्तिकरित्या अनुभवलेले काहीतरी), आम्ही ही मर्यादा जोडण्याचा निर्णय घेतला.

हे स्पष्ट करण्यासाठी, जेव्हा आम्ही डेल्टा लेक टेबलमध्ये काही नवीन व्युत्पन्न स्तंभ जोडण्याचा प्रयत्न करतो तेव्हा खालील कोडमध्ये काय होते ते पाहू या जे अद्याप स्वीकारण्यासाठी कॉन्फिगर केलेले नाहीत.

# Сгенерируем 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.

आपोआप नवीन स्तंभ जोडण्याऐवजी, डेल्टा लेक स्कीमा लादते आणि लेखन थांबवते. कोणता स्तंभ (किंवा स्तंभांचा संच) विसंगती निर्माण करत आहे हे निर्धारित करण्यात मदत करण्यासाठी, तुलनेसाठी स्पार्क स्टॅक ट्रेसमधून दोन्ही स्कीमा आउटपुट करते.

स्कीमा लागू करण्याचा फायदा काय आहे?

स्कीमा अंमलबजावणी ही एक अत्यंत कडक तपासणी असल्यामुळे, उत्पादन किंवा वापरासाठी तयार असलेल्या स्वच्छ, पूर्णपणे बदललेल्या डेटा सेटसाठी द्वारपाल म्हणून वापरण्यासाठी हे एक उत्कृष्ट साधन आहे. सामान्यत: थेट डेटा फीड करणार्‍या सारण्यांवर लागू करा:

मशीन लर्निंग अल्गोरिदम
BI डॅशबोर्ड
डेटा विश्लेषण आणि व्हिज्युअलायझेशन साधने
कोणतीही उत्पादन प्रणाली ज्यासाठी अत्यंत संरचित, जोरदार टाईप केलेले सिमेंटिक स्कीमा आवश्यक असतात.

या अंतिम अडथळ्यासाठी त्यांचा डेटा तयार करण्यासाठी, बरेच वापरकर्ते एक साधे "मल्टी-हॉप" आर्किटेक्चर वापरतात जे त्यांच्या टेबलमध्ये हळूहळू रचना सादर करतात. याबद्दल अधिक जाणून घेण्यासाठी, आपण लेख पाहू शकता डेल्टा लेकसह प्रोडक्शन-ग्रेड मशीन लर्निंग.

अर्थात, स्कीमा अंमलबजावणी आपल्या पाइपलाइनमध्ये कुठेही वापरली जाऊ शकते, परंतु लक्षात ठेवा की या प्रकरणात टेबलवर प्रवाहित करणे निराशाजनक असू शकते कारण, उदाहरणार्थ, आपण विसरलात की आपण येणार्‍या डेटामध्ये दुसरा स्तंभ जोडला आहे.

डेटा सौम्य करणे प्रतिबंधित

आतापर्यंत तुम्हाला प्रश्न पडला असेल की, ही सगळी गडबड कशासाठी आहे? शेवटी, काहीवेळा अनपेक्षित "स्कीमा जुळत नाही" त्रुटी तुम्हाला तुमच्या वर्कफ्लोमध्ये ट्रिप करू शकते, विशेषत: तुम्ही डेल्टा लेकमध्ये नवीन असल्यास. फक्त गरजेनुसार स्कीमा का बदलू देऊ नये जेणेकरून मी काहीही असले तरी माझा डेटाफ्रेम लिहू शकेन?

जुन्या म्हणीप्रमाणे, "प्रतिबंधाचा एक औंस हा एक पौंड बरा आहे." एखाद्या वेळी, तुम्ही तुमची योजना लागू करण्याची काळजी न घेतल्यास, डेटा प्रकार सुसंगतता समस्या त्यांच्या कुरूप डोके वर काढतील - वरवर एकसंध कच्च्या डेटा स्रोतांमध्ये एज केसेस, दूषित स्तंभ, विकृत मॅपिंग किंवा स्वप्नात पाहण्यासारख्या इतर भयानक गोष्टी असू शकतात. भयानक स्वप्ने या शत्रूंना गेटवर थांबवणे - स्कीमा अंमलबजावणीसह - आणि नंतर ते तुमच्या उत्पादन कोडच्या गडद खोलीत लपून बसू लागण्याऐवजी त्यांच्याशी प्रकाशात सामोरे जाणे हा सर्वोत्तम मार्ग आहे.

स्कीमा लागू केल्याने तुम्हाला खात्री मिळते की तुम्ही बदल मंजूर केल्याशिवाय तुमच्या टेबलचा स्कीमा बदलणार नाही. हे डेटा कमी होण्यापासून प्रतिबंधित करते, जे नवीन स्तंभ इतक्या वारंवार जोडले जातात तेव्हा उद्भवू शकतात की पूर्वी मौल्यवान, संकुचित सारण्या डेटाच्या प्रवाहामुळे त्यांचा अर्थ आणि उपयुक्तता गमावतात. तुम्हाला हेतुपुरस्सर होण्यासाठी, उच्च मानके सेट करण्यासाठी आणि उच्च गुणवत्तेची अपेक्षा करण्यास प्रोत्साहित करून, स्कीमा अंमलबजावणी नेमके तेच करते जे ते करण्यासाठी डिझाइन केले होते—तुम्हाला प्रामाणिक राहण्यास आणि तुमची स्प्रेडशीट स्वच्छ ठेवण्यात मदत करते.

पुढील विचारात घेतल्यास, आपण निश्चित केले की आपण खरोखर गरज एक नवीन स्तंभ जोडा - काही हरकत नाही, खाली एक-लाइन निराकरण आहे. त्यावर उपाय म्हणजे सर्किटची उत्क्रांती!

स्कीमा उत्क्रांती म्हणजे काय?

स्कीमा उत्क्रांती हे एक वैशिष्ट्य आहे जे वापरकर्त्यांना वेळोवेळी बदलणाऱ्या डेटानुसार वर्तमान सारणी स्कीमा सहजपणे बदलू देते. एक किंवा अधिक नवीन स्तंभ समाविष्ट करण्यासाठी स्कीमा आपोआप जुळवून घेण्यासाठी जोडणी किंवा पुनर्लेखन ऑपरेशन करत असताना बहुतेकदा याचा वापर केला जातो.

स्कीमा उत्क्रांती कशी कार्य करते?

मागील विभागातील उदाहरणाचे अनुसरण करून, स्कीमा विसंगतीमुळे पूर्वी नाकारलेले नवीन स्तंभ जोडण्यासाठी विकासक सहजपणे स्कीमा उत्क्रांती वापरू शकतात. सर्किट उत्क्रांती जोडून सक्रिय केली जाते .option('mergeSchema', 'true') तुमच्या स्पार्क टीमला .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.databricks.delta.schema.autoMerge = True स्पार्क कॉन्फिगरेशनमध्ये. परंतु हे सावधगिरीने वापरा, कारण स्कीमा अंमलबजावणी तुम्हाला यापुढे अनावधानाने स्कीमा विसंगतींबद्दल सतर्क करणार नाही.

विनंतीमध्ये पॅरामीटर समाविष्ट करून mergeSchema, डेटाफ्रेममध्ये उपस्थित असलेले परंतु लक्ष्य तक्त्यामध्ये नसलेले सर्व स्तंभ लेखन व्यवहाराचा भाग म्हणून स्कीमाच्या शेवटी स्वयंचलितपणे जोडले जातात. नेस्टेड फील्ड देखील जोडले जाऊ शकतात आणि ते संबंधित संरचना स्तंभांच्या शेवटी देखील जोडले जातील.

दिनांक अभियंते आणि डेटा शास्त्रज्ञ जुन्या स्तंभांवर आधारित विद्यमान मॉडेल्स न मोडता त्यांच्या विद्यमान मशीन शिक्षण उत्पादन सारण्यांमध्ये नवीन स्तंभ (कदाचित नुकतेच ट्रॅक केलेले मेट्रिक किंवा या महिन्याचे विक्री कार्यप्रदर्शन स्तंभ) जोडण्यासाठी हा पर्याय वापरू शकतात.

टेबल जोडताना किंवा पुन्हा लिहिताना स्कीमा उत्क्रांतीचा भाग म्हणून खालील प्रकारच्या स्कीमा बदलांना परवानगी आहे:

नवीन स्तंभ जोडणे (हे सर्वात सामान्य परिस्थिती आहे)
NullType वरून डेटा प्रकार बदलणे -> इतर कोणताही प्रकार किंवा ByteType -> ShortType -> IntegerType वरून प्रचार करणे

स्कीमा उत्क्रांतीमध्ये परवानगी नसलेल्या इतर बदलांसाठी स्कीमा आणि डेटा जोडून पुन्हा लिहिणे आवश्यक आहे .option("overwriteSchema", "true"). उदाहरणार्थ, जेथे स्तंभ "Foo" मूळतः पूर्णांक होता आणि नवीन स्कीमा हा स्ट्रिंग डेटा प्रकार होता, तेव्हा सर्व Parquet(data) फायली पुन्हा लिहिल्या जाव्या लागतील. अशा बदलांमध्ये हे समाविष्ट आहे:

स्तंभ हटवत आहे
विद्यमान स्तंभाचा डेटा प्रकार बदलणे (स्थानिक)
स्तंभांचे नाव बदलणे जे केवळ बाबतीत भिन्न असतात (उदाहरणार्थ, "फू" आणि "फू")

शेवटी, Spark 3.0 च्या पुढील रिलीझसह, स्पष्ट DDL पूर्णपणे समर्थित असेल (ALTER TABLE वापरून), वापरकर्त्यांना टेबल स्कीमावर खालील क्रिया करण्यास अनुमती देईल:

स्तंभ जोडत आहे
स्तंभ टिप्पण्या बदलणे
टेबल गुणधर्म सेट करणे जे टेबलच्या वर्तनावर नियंत्रण ठेवते, जसे की व्यवहार लॉग संग्रहित केल्याची लांबी सेट करणे.

सर्किट उत्क्रांतीचा फायदा काय आहे?

स्कीमा उत्क्रांती आपण कधीही वापरू शकता हेतू तुमच्या टेबलचा स्कीमा बदला (जेव्हा तुम्ही चुकून तुमच्या डेटाफ्रेममध्ये कॉलम जोडले होते जे तिथे नसावेत). तुमचा स्कीमा स्थलांतरित करण्याचा हा सर्वात सोपा मार्ग आहे कारण ते स्पष्टपणे घोषित न करता योग्य स्तंभ नावे आणि डेटा प्रकार स्वयंचलितपणे जोडते.

निष्कर्ष

स्कीमा अंमलबजावणी तुमच्या सारणीशी सुसंगत नसलेले कोणतेही नवीन स्तंभ किंवा इतर स्कीमा बदल नाकारते. ही उच्च मानके सेट करून आणि त्यांची देखरेख करून, विश्लेषक आणि अभियंते विश्वास ठेवू शकतात की त्यांच्या डेटामध्ये उच्च पातळीची अखंडता आहे, ते स्पष्टपणे आणि स्पष्टपणे संप्रेषण करून, त्यांना अधिक चांगले व्यावसायिक निर्णय घेण्यास अनुमती देतात.

दुसरीकडे, स्कीमा उत्क्रांती सरलीकरण करून अंमलबजावणीला पूरक आहे आरोप स्वयंचलित स्कीमा बदल. शेवटी, स्तंभ जोडणे कठीण नसावे.

योजनेचा सक्तीचा अर्ज यांग आहे, जेथे योजनेची उत्क्रांती यिन आहे. एकत्र वापरल्यास, ही वैशिष्ट्ये आवाज दाबणे आणि सिग्नल ट्यूनिंग नेहमीपेक्षा सोपे करतात.

या लेखातील योगदानाबद्दल आम्ही मुकुल मूर्ती आणि प्रणव आनंद यांचेही आभार मानू इच्छितो.

या मालिकेतील इतर लेख:

डेल्टा लेकमध्ये जा: व्यवहार लॉग अनपॅक करणे

डेल्टा लेकमध्ये जा: स्कीमा अंमलबजावणी आणि उत्क्रांती