उबेर में प्रेस्टो लोकल कैश का डिजाइन और कार्यान्वयन

पिछले ब्लॉग में, हमने उबेर के प्रेस्टो उपयोग के मामलों को पेश किया था और हमने प्रेस्टो प्रश्नों को तेज करने में विभिन्न चुनौतियों को दूर करने के लिए ऑलक्सियो स्थानीय कैश को लागू करने के लिए कैसे सहयोग किया। दूसरा भाग स्थानीय कैश मेटाडेटा में सुधार पर चर्चा करता है।

स्थानीय कैश के लिए फ़ाइल स्तर मेटाडेटा

प्रेरणा

सबसे पहले, हम बासी कैशिंग को रोकना चाहते हैं। अंतर्निहित डेटा फ़ाइलों को तृतीय-पक्ष फ़्रेमवर्क द्वारा बदला जा सकता है। ध्यान दें कि हाइव टेबल में यह स्थिति दुर्लभ हो सकती है लेकिन हुडी टेबल में बहुत आम है।

दूसरा, एचडीएफएस से अनडुप्लिकेट डेटा की दैनिक रीडिंग बड़ी हो सकती है, लेकिन हमारे पास सभी डेटा को कैश करने के लिए पर्याप्त कैश स्पेस नहीं है। इसलिए, हम प्रत्येक तालिका के लिए कोटा निर्धारित करके स्कोप्ड कोटा प्रबंधन शुरू कर सकते हैं।

तीसरा, सर्वर पुनरारंभ होने के बाद मेटाडेटा पुनर्प्राप्त करने योग्य होना चाहिए। हमने मेटाडेटा को डिस्क के बजाय मेमोरी में स्थानीय कैश में संग्रहीत किया है, जिससे सर्वर डाउन और पुनरारंभ होने पर मेटाडेटा को पुनर्प्राप्त करना असंभव हो जाता है।

उच्च स्तरीय दृष्टिकोण

इसलिए, हम फ़ाइल स्तर मेटाडेटा का प्रस्ताव करते हैं, जो पिछले संशोधित समय और हमारे द्वारा कैश की गई प्रत्येक डेटा फ़ाइल के दायरे को रखता है और रखता है। फ़ाइल-स्तरीय मेटाडेटा स्टोर डिस्क पर स्थिर होना चाहिए ताकि पुनरारंभ करने के बाद डेटा गायब न हो।

फ़ाइल-स्तरीय मेटाडेटा की शुरुआत के साथ, डेटा के कई संस्करण होंगे। नए संस्करण के अनुरूप डेटा अपडेट होने पर एक नया टाइमस्टैम्प उत्पन्न होता है। इस नए टाइमस्टैम्प के अनुरूप नया पृष्ठ संग्रहीत करने वाला एक नया फ़ोल्डर बनाया जाता है। साथ ही हम पुराने टाइमस्टैम्प को हटाने की कोशिश करेंगे।

कैश डेटा और मेटाडेटा संरचना

जैसा कि ऊपर दिखाया गया है, हमारे पास दो टाइमस्टैम्प के अनुरूप दो फ़ोल्डर हैं: टाइमस्टैम्प1 और टाइमस्टैम्प2। आमतौर पर, जब सिस्टम चल रहा होता है, तो एक साथ दो टाइमस्टैम्प नहीं होंगे क्योंकि हम पुराने टाइमस्टैम्प 1 को हटा देंगे और केवल टाइमस्टैम्प 2 रखेंगे। हालांकि, एक व्यस्त सर्वर या उच्च संगामिति के मामले में, हम समय पर टाइमस्टैम्प को हटाने में सक्षम नहीं हो सकते हैं, इस स्थिति में हमारे पास एक ही समय में दो टाइमस्टैम्प हो सकते हैं। इसके अलावा, हम एक मेटाडेटा फ़ाइल बनाए रखते हैं जो फ़ाइल जानकारी को प्रोटोबफ़ प्रारूप और नवीनतम टाइमस्टैम्प में रखती है। यह सुनिश्चित करता है कि Alluxio का स्थानीय कैश केवल नवीनतम टाइमस्टैम्प से डेटा पढ़ता है। जब सर्वर पुनरारंभ होता है, तो टाइमस्टैम्प जानकारी मेटाडेटा फ़ाइल से पढ़ी जाती है ताकि कोटा और अंतिम संशोधित समय को सही ढंग से प्रबंधित किया जा सके।

मेटाडेटा जागरूकता

कैश संदर्भ

चूँकि Alluxio एक सामान्य कैशिंग समाधान है, इसे अभी भी Alluxio को मेटाडेटा पास करने के लिए प्रेस्टो की तरह कंप्यूट इंजन की आवश्यकता है। इसलिए, प्रेस्टो साइट पर, हम HiveFileContext का उपयोग करते हैं। Hive तालिका या Hudi तालिका से प्रत्येक डेटा फ़ाइल के लिए, Presto एक HiveFileContext बनाता है। प्रेस्टो फ़ाइल खोलते समय Alluxio इस जानकारी का उपयोग करता है।

ओपनफाइल को कॉल करते समय, Alluxio PrestoCacheContext का एक नया उदाहरण बनाता है, जिसमें HiveFileContext होता है और इसमें स्कोप (चार स्तर: डेटाबेस, स्कीमा, टेबल, पार्टीशन), कोटा, कैश आइडेंटिफ़ायर (यानी, फ़ाइल पथ का md5 मान) होता है, और अन्य सूचना। हम इस कैश संदर्भ को स्थानीय फाइल सिस्टम में पास करेंगे। Alluxio इस प्रकार मेटाडेटा का प्रबंधन कर सकता है और मेट्रिक्स एकत्र कर सकता है।

प्रेस्टो साइड पर प्रति क्वेरी मेट्रिक्स एकत्रीकरण

Presto से Alluxio तक डेटा पास करने के अलावा, हम Presto को वापस कॉल भी कर सकते हैं। क्वेरी संचालन करते समय, हम कुछ आंतरिक मेट्रिक्स को जानेंगे, जैसे कि पढ़े गए डेटा के कितने बाइट्स कैश को प्रभावित करते हैं और कितने बाइट्स बाहरी HDFS स्टोरेज से पढ़े जाते हैं।

जैसा कि नीचे दिखाया गया है, हम PrestoCacheContext युक्त HiveFileContext को स्थानीय कैश फ़ाइल सिस्टम (LocalCacheFileSystem) में पास करते हैं, जिसके बाद स्थानीय कैश फ़ाइल सिस्टम CacheContext को वापस (IncremetCounter) कॉल करता है। फिर, यह कॉलबैक श्रृंखला HiveFileContext और फिर RuntimeStats पर जारी रहेगी।

Presto में, RuntimeStats का उपयोग क्वेरी निष्पादित करते समय मेट्रिक्स जानकारी एकत्र करने के लिए किया जाता है ताकि हम एकत्रीकरण संचालन कर सकें। उसके बाद, हम प्रेस्टो के UI या JSON फ़ाइल में स्थानीय कैश फ़ाइल सिस्टम के बारे में जानकारी देख सकते हैं। हम Alluxio और Presto को उपरोक्त प्रक्रिया के साथ मिलकर काम कर सकते हैं। प्रेस्टो की तरफ, हमारे पास बेहतर आंकड़े हैं; Alluxio पक्ष पर, हमारे पास मेटाडेटा की एक स्पष्ट तस्वीर है।

भविष्य का कार्य

प्रदर्शन सुधारना

क्योंकि ऊपर वर्णित कॉलबैक प्रक्रिया CacheContext के जीवनचक्र को काफी बढ़ा देती है, इसलिए हमें बढ़ती GC विलंबता के साथ कुछ समस्याओं का सामना करना पड़ा है, जिन्हें हम संबोधित करने के लिए काम कर रहे हैं।

सिमेंटिक कैश को अपनाएं (SC)

हम अपने द्वारा प्रस्तावित फ़ाइल-स्तरीय मेटाडेटा के आधार पर सिमेंटिक कैश (SC) को लागू करेंगे। उदाहरण के लिए, हम डेटा संरचनाओं को Parquet या ORC फ़ाइलों में सहेज सकते हैं, जैसे पाद लेख, अनुक्रमणिका, आदि।

अधिक कुशल अक्रमांकन

अधिक कुशल अक्रमांकन प्राप्त करने के लिए, हम प्रोटोबफ के बजाय फ्लैटबफ का उपयोग करेंगे। यद्यपि प्रोटोबफ का उपयोग ओआरसी कारखाने में मेटाडेटा को संग्रहीत करने के लिए किया जाता है, हमने पाया कि ओआरसी का मेटाडेटा फेसबुक के साथ ऑलक्सियो के सहयोग से कुल CPU उपयोग का 20-30% से अधिक लाता है। इसलिए, हम कैश और मेटाडेटा को स्टोर करने के लिए मौजूदा प्रोटोबफ को एक फ्लैटबफ के साथ बदलने की योजना बना रहे हैं, जिससे डिसेरिएलाइजेशन के प्रदर्शन में काफी सुधार होने की उम्मीद है।

संक्षेप में, पिछले ब्लॉग के साथ, यह दो-भाग वाली ब्लॉग श्रृंखला साझा करती है कि कैसे हमने अपने प्रेस्टो बेड़े के लिए आवश्यक हॉट डेटा की एक नई कैशिंग परत बनाई, जो हाल ही में उबेर में प्रेस्टो और ऑलक्सियो समुदायों के बीच ओपन-सोर्स सहयोग पर आधारित है। यह वास्तुशिल्प रूप से सरल और साफ दृष्टिकोण प्रबंधित एसएसडी और लगातार हैशिंग-आधारित सॉफ्ट एफिनिटी शेड्यूलिंग के साथ एचडीएफएस विलंबता को काफी कम कर सकता है। अधिक जानने के लिए हमारे कम्युनिटी स्लैक चैनल में 9000+ सदस्यों से जुड़ें।

लेखक के बारे में

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

डॉ. बीनन वांग Alluxio के एक सॉफ्टवेयर इंजीनियर हैं और PrestoDB के कमिटर हैं। Alluxio से पहले, वह Twitter में Presto टीम के टेक लीड थे, और उन्होंने Twitter के डेटा प्लेटफ़ॉर्म के लिए बड़े पैमाने पर वितरित SQL सिस्टम का निर्माण किया। उनके पास प्रदर्शन अनुकूलन, वितरित कैशिंग और वॉल्यूम डेटा प्रोसेसिंग पर काम करने का बारह साल का अनुभव है। उन्होंने अपनी पीएच.डी. वितरित प्रणालियों के प्रतीकात्मक मॉडल की जाँच और रनटाइम सत्यापन पर सिरैक्यूज़ विश्वविद्यालय से कंप्यूटर इंजीनियरिंग में।

यहाँ भी प्रकाशित हो चुकी है।.