प्रसिद्ध: स्पार्क डेटाफ्रेम के साथ काम करता है, जो परिवर्तन एल्गोरिदम हैं। एल्गोरिथ्म को अनुकूलन के लिए "अधिक स्थान देने" के लिए और इसे यथासंभव कुशलतापूर्वक निष्पादित करने के लिए अनुकूलन के कारण बहुत ही अंतिम समय में लॉन्च किया गया है।

कटौती के तहत, हम विश्लेषण करेंगे कि एक बहु-पृष्ठ एसक्यूएल क्वेरी को परमाणुओं में कैसे विघटित किया जाए (दक्षता में कमी के बिना) और इसके कारण ईटीएल पाइपलाइन के निष्पादन समय को काफी कम कैसे किया जाए।

आलसी मूल्यांकन

स्पार्क की एक दिलचस्प कार्यात्मक विशेषता आलसी मूल्यांकन है: परिवर्तन केवल तब निष्पादित होते हैं जब कार्रवाई पूरी हो जाती है। यह कैसे काम करता है (मोटे तौर पर): कार्रवाई से पहले डेटा फ़्रेमों के निर्माण के लिए एल्गोरिदम "एक साथ अटक जाते हैं", ऑप्टिमाइज़र अपने दृष्टिकोण से सबसे कुशल अंतिम एल्गोरिथ्म का निर्माण करता है, जो शुरू होता है और परिणाम देता है (जिस पर कार्रवाई का अनुरोध किया गया था)।

हमारी प्रस्तुति के संदर्भ में यहाँ क्या दिलचस्प है: किसी भी जटिल प्रश्न को दक्षता के नुकसान के बिना "परमाणुओं" में विघटित किया जा सकता है। थोड़ा और विश्लेषण करें।

मल्टिपेज एसक्यूएल

कई कारण हैं कि हम "मल्टी-पेज" एसक्यूएल प्रश्नों को क्यों लिखते हैं, मुख्य में से एक, संभवतः, मध्यवर्ती ऑब्जेक्ट्स बनाने के लिए अनिच्छा (दक्षता आवश्यकताओं द्वारा समर्थित अनिच्छा)। निम्नलिखित एक अपेक्षाकृत जटिल क्वेरी का उदाहरण है (बेशक, यह बहुत सरल है, लेकिन आगे की प्रस्तुति के प्रयोजनों के लिए, हमारे पास पर्याप्त है)।

qSel = """ select con.contract_id as con_contract_id, con.begin_date as con_begin_date, con.product_id as con_product_id, cst.contract_status_type_id as cst_status_type_id, sbj.subject_id as sbj_subject_id, sbj.subject_name as sbj_subject_name, pp.birth_date as pp_birth_date from kasko.contract con join kasko.contract_status cst on cst.contract_status_id = con.contract_status_id join kasko.subject sbj on sbj.subject_id = con.owner_subject_id left join kasko.physical_person pp on pp.subject_id = con.owner_subject_id """ dfSel = sp.sql(qSel) 

हम क्या देखते हैं:

• डेटा को कई तालिकाओं से चुना गया है
• विभिन्न प्रकार के जुड़ने का उपयोग किया जाता है
• चुनिंदा कॉलम को चुनिंदा भाग द्वारा वितरित किया जाता है, भाग में शामिल हों (और जहां भाग है, लेकिन यहां यह यहां नहीं है - मैंने इसे सादगी के लिए हटा दिया है)

इस क्वेरी को सरल लोगों में विघटित किया जा सकता है (उदाहरण के लिए, पहले अनुबंध और कॉन्ट्रैक्ट_स्टैटस टेबल को मिलाएं, परिणाम को एक अस्थायी तालिका में सहेजें, फिर इसे विषय के साथ संयोजित करें, परिणाम को एक अस्थायी तालिका में भी सहेजें, आदि)। निश्चित रूप से, जब हम वास्तव में जटिल प्रश्न बनाते हैं, तो हम ऐसा करते हैं, बस - डिबगिंग के बाद - हम यह सब एक बहु-पृष्ठ ब्लॉक में इकट्ठा करते हैं।

यहाँ क्या बुरा है? कुछ भी नहीं, वास्तव में, हर कोई उसी तरह काम करता है और इसके लिए उपयोग किया जाता है।

लेकिन कमियां हैं - या बल्कि, क्या सुधार करना है - इस पर पढ़ें।

चिंगारी में एक ही क्वेरी

परिवर्तन के लिए स्पार्क का उपयोग करते समय, निश्चित रूप से, आप बस इस अनुरोध को ले सकते हैं और निष्पादित कर सकते हैं (और यह अच्छा होगा, वास्तव में, हम इसे भी निष्पादित करेंगे), लेकिन आप दूसरे तरीके से जा सकते हैं, आइए इसे आज़माएं।

चलो इस "जटिल" क्वेरी को "परमाणुओं" में बदल देते हैं - प्राथमिक डेटा फ़्रेम। हम उनमें से कई को क्वेरी में शामिल तालिकाओं की संख्या (इस मामले में, 4) के रूप में प्राप्त करेंगे।

यहाँ वे हैं - "परमाणु":

 dfCon = sp.sql("""select contract_id as con_contract_id, begin_date as con_begin_date, product_id as con_product_id, owner_subject_id as con_owner_subject_id, contract_status_id as con_contract_status_id from kasko.contract""") dfCStat = sp.sql("""select contract_status_id as cst_status_id, contract_status_type_id as cst_status_type_id from kasko.contract_status""") dfSubj = sp.sql("""select subject_id as sbj_subject_id, subject_type_id as sbj_subject_type_id, subject_name as sbj_subject_name from kasko.subject""") dfPPers = sp.sql("""select subject_id as pp_subject_id, birth_date as pp_birth_date from kasko.physical_person""") 

स्पार्क उन्हें वास्तविक "परमाणुओं" से अलग किए गए भावों का उपयोग करके जुड़ने (जुड़ने) की अनुमति देता है, आइए यह करते हैं:

 con_stat = f.col("cst_status_id")==f.col("con_contract_status_id") con_subj_own = f.col("con_owner_subject_id")==f.col("sbj_subject_id") con_ppers_own = f.col("con_owner_subject_id")==f.col("pp_subject_id") 

तब हमारी "जटिल क्वेरी" इस तरह दिखाई देगी:

 dfAtom = dfCon.join(dfCStat,con_stat, "inner")\ .join(dfSubj,con_subj_own,"inner") \ .join(dfPPers,con_ppers_own, "left") \ .drop("con_contract_status_id","sbj_subject_type_id", "pp_subject_id","con_owner_subject_id","cst_status_id") 

यहाँ क्या अच्छा है? पहली नज़र में, यह कुछ भी नहीं है, इसके विपरीत: "जटिल" एसक्यूएल का उपयोग करके आप समझ सकते हैं कि क्या हो रहा है, हमारे "परमाणु" क्वेरी द्वारा यह समझना अधिक कठिन है, आपको "परमाणुओं" और अभिव्यक्तियों को देखने की आवश्यकता है।

आइए पहले यह सुनिश्चित करें कि ये प्रश्न समतुल्य हैं - संदर्भ के अनुसार ज्यूपिटर पुस्तक में मैंने दोनों प्रश्नों को पूरा करने की योजना दी (जिज्ञासु 10 अंतर पा सकते हैं, लेकिन सार - समतुल्य - स्पष्ट है)। यह, ज़ाहिर है, यह कोई चमत्कार नहीं है, ऐसा होना चाहिए (आलसी मूल्यांकन और अनुकूलन के लिए ऊपर देखें)।

हमारे पास अंत में क्या है - "बहु-पृष्ठ" अनुरोध और "परमाणु" अनुरोध समान दक्षता के साथ काम करते हैं (यह महत्वपूर्ण है, इसके बिना आगे के विचार आंशिक रूप से अपना अर्थ खो देते हैं)।

ठीक है, अब चलिए प्रश्नों के निर्माण के "परमाणु" तरीके को अच्छा पाते हैं।

एक "परमाणु" (प्रारंभिक डेटा फ़्रेम) क्या है, यह विषय क्षेत्र (रिलेशनल टेबल का हिस्सा) के सबसेट का हमारा ज्ञान है। ऐसे "परमाणुओं" को अलग करके हम स्वचालित रूप से (और, महत्वपूर्ण रूप से, एल्गोरिथम और प्रतिलिपि प्रस्तुत करने योग्य) "भौतिक डेटा मॉडल" नामक हमारे लिए असीम चीज़ का एक महत्वपूर्ण हिस्सा चुनते हैं।

शामिल होने पर हमने किस अभिव्यक्ति का उपयोग किया है? यह विषय क्षेत्र के बारे में भी ज्ञान है - यह इस प्रकार है (जैसा कि अभिव्यक्ति में दर्शाया गया है) विषय क्षेत्र (डेटाबेस में तालिकाओं) की इकाइयां परस्पर जुड़ी हुई हैं।

मैं दोहराता हूं - यह महत्वपूर्ण है - यह "ज्ञान" (परमाणु और अभिव्यक्ति) निष्पादन योग्य कोड (आरेख या मौखिक विवरण में नहीं) में उत्प्रेरित है, यह कोड है जिसे हर बार ईटीएल पाइपलाइन निष्पादित होने पर निष्पादित किया जाता है (उदाहरण, वास्तविक जीवन से, वैसे, लिया जाता है)।

निष्पादन योग्य कोड - जैसा कि हम साफ कोडर से जानते हैं - दो उद्देश्यपूर्ण मौजूदा कलाकृतियों में से एक है जो दस्तावेज के "शीर्षक" होने का दावा करते हैं। यही है, "परमाणुओं" का उपयोग हमें डेटा के दस्तावेजीकरण जैसी महत्वपूर्ण प्रक्रिया में एक कदम आगे ले जाने की अनुमति देता है।

"परमाणु" में और क्या मिल सकता है?

कन्वेयर अनुकूलन

वास्तविक जीवन में, एक डेटा इंजीनियर - वैसे, मैंने अपना परिचय नहीं दिया था - एक ईटीएल पाइपलाइन में ऊपर के समान दर्जनों परिवर्तन होते हैं। तालिकाओं को अक्सर उनमें दोहराया जाता है (मैं किसी तरह एक्सेल में गणना करता हूं - कुछ तालिकाओं का उपयोग 40% प्रश्नों में किया जाता है)।

दक्षता की दृष्टि से क्या होता है? मेस - एक ही तालिका स्रोत से कई बार पढ़ी जाती है ...

इसे कैसे सुधारा जाए? स्पार्क में डेटा फ़्रेम को कैशिंग करने के लिए एक तंत्र है - हम स्पष्ट रूप से निर्दिष्ट कर सकते हैं कि कौन से डेटा फ़्रेम और हम कैश में कितना रखना चाहते हैं।

इसके लिए हमें क्या करना है डुप्लिकेट टेबल का चयन करना और इस तरह से प्रश्नों का निर्माण करना है जैसे कुल कैश आकार को कम करना (क्योंकि सभी टेबल, परिभाषा के अनुसार, इसमें फिट नहीं होंगे, तो बड़ा डेटा है)।

क्या यह बहु-पृष्ठ SSQ प्रश्नों का उपयोग करके किया जा सकता है? हां, लेकिन ... थोड़ा जटिल है (हमारे पास वास्तव में डेटा फ़्रेम नहीं हैं, केवल टेबल हैं, उन्हें भी कैश किया जा सकता है - स्पार्क समुदाय इस पर काम कर रहा है)।

क्या यह परमाणु प्रश्नों का उपयोग करके किया जा सकता है? हाँ! और यह मुश्किल नहीं है, हमें केवल "परमाणुओं" को सामान्य करने की आवश्यकता है - हमारे पाइप लाइन के सभी प्रश्नों में उपयोग किए गए स्तंभों को उनके साथ जोड़ें। यदि आप इसके बारे में सोचते हैं, तो यह प्रलेखन के दृष्टिकोण से "सही" है: यदि किसी कॉलम का उपयोग कुछ क्वेरी में किया जाता है (भले ही जहां भाग में), यह उस विषय क्षेत्र के डेटा का हिस्सा है जो हमारे लिए दिलचस्प है।

और फिर सब कुछ सरल है - हम परमाणुओं (डेटा फ़्रेम) को दोहराते हुए कैश करते हैं, हम परिवर्तनों की एक श्रृंखला बनाते हैं ताकि कैश्ड डेटा फ़्रेमों का प्रतिच्छेदन न्यूनतम हो (यह तुच्छ नहीं है, लेकिन एल्गोरिदम, वैसे)।

और हमें सबसे कुशल कन्वेयर पूरी तरह से "मुक्त" मिलता है। और इसके अलावा, एक उपयोगी और महत्वपूर्ण कलाकृति विषय क्षेत्र पर डेटा के प्रलेखन के लिए "तैयारी" है।

रोबोटाइजेशन और ऑटोमेशन

परमाणु "महान और शक्तिशाली SQL" की तुलना में स्वचालित प्रसंस्करण के लिए अतिसंवेदनशील होते हैं - उनकी संरचना सरल और स्पष्ट है, स्पार्क हमारे लिए पार्सिंग करता है (जिसके लिए उसके लिए विशेष धन्यवाद), वह क्वेरी प्लान भी बनाता है, जिसका विश्लेषण करके आप स्वचालित रूप से क्वेरी प्रसंस्करण का क्रम बदल सकते हैं।

तो यहाँ आप कुछ खेल सकते हैं।

निष्कर्ष में

शायद मैं बहुत आशावादी हूं - मुझे ऐसा लगता है कि यह पथ (क्वेरी परमाणुकरण) तथ्य के बाद एक डेटा स्रोत का वर्णन करने की कोशिश करने की तुलना में अधिक काम कर रहा है। इसके अलावा - वैसे, "एडिटिव्स" का उपयोग क्या है - हमें दक्षता में वृद्धि मिलती है। मैं परमाणु दृष्टिकोण को "काम" क्यों मानता हूं? यह नियमित प्रक्रिया का हिस्सा है, जिसका अर्थ है कि वर्णित कलाकृतियों के पास लंबे समय में प्रासंगिक होने का एक वास्तविक मौका है।

मैं शायद कुछ याद किया - मदद मिल सकती है (टिप्पणियों में)?