छह महीने पहले, मैंने लिखा था कि । उस समय, हम SQL स्टेटमेंट के ऑटो-जनरेशन से जूझ रहे थे। जैसे-जैसे दिन बीतते हैं, हमने आपके लिए संदर्भ बनने के लिए काफी प्रगति की है, इसलिए मैं फिर से यहां हूं। हमने अपने डेटा प्रबंधन सिस्टम के लिए ओएलएपी इंजन के रूप में क्लिकहाउस को अपाचे डोरिस से क्यों बदल दिया हमने अपनी डोरिस-आधारित OLAP सेवाओं को सशक्त बनाने के लिए बड़े भाषा मॉडल (एलएलएम) को अपनाया है। एलएलएम + ओएलएपी हमारा प्रोत्साहन अपने आंतरिक कर्मचारियों को एसक्यूएल लेखन की कठिन सीखने की अवस्था से बचाना था। इस प्रकार, हमने एलएलएम को मध्यवर्ती के रूप में उपयोग किया। यह प्राकृतिक भाषा के प्रश्नों को SQL कथनों में परिवर्तित करता है और SQL को निष्पादन के लिए OLAP इंजन में भेजता है। एआई से संबंधित हर अनुभव की तरह, हमें कुछ मतभेद का सामना करना पड़ा: एलएलएम "फ़ील्ड", "पंक्तियाँ", "कॉलम" और "टेबल" जैसे डेटा शब्दजाल को नहीं समझता है। इसके बजाय, वे "कॉर्पोरेट आय" और "डीएयू" जैसे व्यावसायिक शब्दों का पूरी तरह से अनुवाद कर सकते हैं, जो मूल रूप से फ़ील्ड/पंक्तियों/स्तंभों के बारे में हैं। इसका मतलब यह है कि यह केवल तभी अच्छी तरह से काम कर सकता है जब विश्लेषक अपने प्रश्न टाइप करते समय आवश्यक मीट्रिक को संदर्भित करने के लिए सटीक सही शब्द का उपयोग करते हैं। हम जिस एलएलएम का उपयोग कर रहे हैं वह अनुमान लगाने में धीमा है। प्रतिक्रिया देने में 10 सेकंड से अधिक का समय लगता है। चूँकि यह टोकन द्वारा शुल्क लेता है, लागत-प्रभावशीलता एक समस्या बन जाती है। यद्यपि एलएलएम को सार्वजनिक डेटासेट के एक बड़े संग्रह पर प्रशिक्षित किया जाता है, लेकिन इसमें विशिष्ट ज्ञान की जानकारी कम होती है। हमारे मामले में, एलएलएम इंडी गानों से बहुत अपरिचित है, इसलिए भले ही गाने हमारे डेटाबेस में शामिल हों, एलएलएम उन्हें ठीक से पहचानने में सक्षम नहीं होगा। कभी-कभी हमारे इनपुट प्रश्नों के लिए पर्याप्त और नवीनतम कानूनी, राजनीतिक, वित्तीय और नियामक जानकारी की आवश्यकता होती है, जिसे प्रशिक्षण डेटासेट या ज्ञान आधार में शामिल करना कठिन होता है। अधिक विविध कार्य करने के लिए हमें एलएलएम को व्यापक सूचना आधारों से जोड़ने की आवश्यकता है। हम इन समस्याओं को एक-एक करके ख़त्म करते हैं। 1. एक अर्थपरक परत समस्या नंबर 1 के लिए, हम एलएलएम और ओएलएपी इंजन के बीच एक सिमेंटिक परत पेश करते हैं। यह परत व्यावसायिक शब्दों को संबंधित डेटा फ़ील्ड में अनुवादित करती है। यह विभिन्न प्राकृतिक भाषा शब्दों से डेटा फ़िल्टरिंग स्थितियों की पहचान कर सकता है, उन्हें शामिल मेट्रिक्स से जोड़ सकता है, और फिर SQL स्टेटमेंट उत्पन्न कर सकता है। इसके अलावा, सिमेंटिक परत गणना तर्क को अनुकूलित कर सकती है। जब विश्लेषक एक ऐसा प्रश्न इनपुट करते हैं जिसमें एक जटिल क्वेरी शामिल होती है, मान लीजिए, एक मल्टी-टेबल जॉइन, तो सिमेंटिक परत सिमेंटिक विकृति को कम करने के लिए इसे कई सिंगल-टेबल क्वेरीज़ में विभाजित कर सकती है। 2. एलएलएम पार्सिंग नियम एलएलएम का उपयोग करने में लागत-प्रभावशीलता बढ़ाने के लिए, हम सभी परिदृश्यों की गणना जटिलता का मूल्यांकन करते हैं, जैसे मीट्रिक गणना, विस्तृत रिकॉर्ड पुनर्प्राप्ति और उपयोगकर्ता विभाजन। फिर, हम नियम बनाते हैं और एलएलएम-पार्सिंग चरण को केवल जटिल कार्यों के लिए समर्पित करते हैं। इसका मतलब है कि सरल गणना कार्यों के लिए, यह पार्सिंग को छोड़ देगा। उदाहरण के लिए, जब एक विश्लेषक इनपुट करता है "मुझे प्रमुख संगीत प्लेटफार्मों की कमाई बताएं", एलएलएम पहचानता है कि यह प्रश्न केवल कई मैट्रिक्स या आयामों पर जोर देता है, इसलिए यह इसे आगे पार्स नहीं करेगा बल्कि इसे सीधे SQL पीढ़ी और निष्पादन के लिए भेज देगा। यह क्वेरी प्रतिक्रिया समय को काफी हद तक कम कर सकता है और एपीआई खर्चों को कम कर सकता है। 3. स्कीमा मैपर और बाहरी ज्ञान का आधार एलएलएम को विशिष्ट ज्ञान से सशक्त बनाने के लिए, हमने एलएलएम से एक स्कीमा मैपर अपस्ट्रीम जोड़ा है। स्कीमा मैपर इनपुट प्रश्न को बाहरी ज्ञान आधार पर मैप करता है, और फिर एलएलएम पार्सिंग करेगा। हम स्कीमा मैपर का लगातार परीक्षण और अनुकूलन कर रहे हैं। हम बाहरी ज्ञान आधार में सामग्री को वर्गीकृत और रेट करते हैं, और बेहतर सिमेंटिक पार्सिंग को सक्षम करने के लिए मैपिंग के विभिन्न स्तर (पूर्ण-पाठ मैपिंग और फ़ज़ी मैपिंग) करते हैं। 4. प्लगइन्स हमने एलएलएम को जानकारी के अधिक क्षेत्रों से जोड़ने के लिए प्लगइन्स का उपयोग किया, और हमारे पास विभिन्न प्रकार के प्लगइन्स के लिए अलग-अलग एकीकरण विधियां हैं: : यह विशेष रूप से तब उपयोगी होता है जब हमें एलएलएम को नवीनतम नियामक नीतियों को "सिखाने" की आवश्यकता होती है, जो अक्सर टेक्स्ट फ़ाइलें होती हैं। सबसे पहले, सिस्टम स्थानीय टेक्स्ट फ़ाइल को वेक्टराइज़ करता है, स्थानीय फ़ाइल में मिलान या समान शब्दों को खोजने के लिए सिमेंटिक खोज निष्पादित करता है, प्रासंगिक सामग्री निकालता है और आउटपुट उत्पन्न करने के लिए उन्हें एलएलएम पार्सिंग विंडो में डालता है। स्थानीय फ़ाइलें एम्बेड करना : बाज़ार तृतीय-पक्ष प्लगइन्स से भरा है जो सभी प्रकार के क्षेत्रों के लिए डिज़ाइन किए गए हैं। उनके साथ, एलएलएम व्यापक विषयों से निपटने में सक्षम है। प्रत्येक प्लगइन के अपने संकेत और कॉलिंग फ़ंक्शन होते हैं। एक बार जब इनपुट प्रश्न प्रॉम्प्ट पर आ जाता है, तो संबंधित प्लगइन को कॉल किया जाएगा। तृतीय-पक्ष प्लगइन्स उपरोक्त चार अनुकूलन पूरा करने के बाद, सुपरसोनिक ढांचा अस्तित्व में आता है। सुपरसोनिक ढांचा अब मैं आपको इस के बारे में बताता हूँ: रूपरेखा एक विश्लेषक एक प्रश्न पूछता है। स्कीमा मैपर प्रश्न को बाहरी ज्ञान आधार पर मैप करता है। यदि बाहरी ज्ञान आधार में मेल खाने वाले फ़ील्ड हैं, तो प्रश्न एलएलएम द्वारा पार्स नहीं किया जाएगा। इसके बजाय, एक मीट्रिक गणना सूत्र क्वेरी शुरू करने के लिए OLAP इंजन को ट्रिगर करेगा। यदि कोई मिलान फ़ील्ड नहीं है, तो प्रश्न एलएलएम में प्रवेश करेगा। पूर्व-निर्धारित नियमों के आधार पर, एलएलएम प्रश्न के जटिलता स्तर का मूल्यांकन करता है। यदि यह एक साधारण क्वेरी है, तो यह सीधे OLAP इंजन पर जाएगी; यदि यह एक जटिल क्वेरी है, तो इसे शब्दार्थ रूप से पार्स किया जाएगा और डीएसएल स्टेटमेंट में परिवर्तित किया जाएगा। सिमेंटिक लेयर पर, डीएसएल स्टेटमेंट को उसके क्वेरी परिदृश्य के आधार पर विभाजित किया जाएगा। उदाहरण के लिए, यदि यह एक मल्टी-टेबल जॉइन क्वेरी है, तो यह लेयर कई सिंगल-टेबल क्वेरी SQL स्टेटमेंट उत्पन्न करेगी। यदि प्रश्न में बाहरी ज्ञान शामिल है, तो एलएलएम तीसरे पक्ष के प्लगइन को कॉल करेगा। उदाहरण: यह उत्तर देने के लिए कि क्या एक निश्चित गीत को विभिन्न शो में प्रदर्शित किया जा सकता है, सिस्टम गीत के बारे में विवरण के लिए OLAP डेटा वेयरहाउस को पुनः प्राप्त करता है, और इसे वाणिज्यिक उपयोग क्वेरी तृतीय-पक्ष प्लगइन से परिणामों के साथ प्रस्तुत करता है। ओएलएपी वास्तुकला जहां तक इस ढांचे के OLAP भाग का सवाल है, वास्तुशिल्प विकास के कई दौरों के बाद, हमारी वर्तमान OLAP पाइपलाइन इस तरह दिखती है। कच्चे डेटा को टैग और मेट्रिक्स में क्रमबद्ध किया जाता है, जो विश्लेषकों द्वारा कस्टम-परिभाषित होते हैं। असंगत परिभाषाओं से बचने के लिए टैग और मेट्रिक्स एकीकृत प्रबंधन के अंतर्गत हैं। फिर, उन्हें विभिन्न प्रश्नों के लिए विभिन्न टैगसेट और मेट्रिकसेट में संयोजित किया जाता है। हमने अपने वास्तुशिल्प अनुकूलन अनुभव से आपके लिए दो मुख्य निष्कर्ष निकाले हैं। 1. लिंक को सुव्यवस्थित करें अपाचे डोरिस को अपनाने से पहले, हमारे पास टैग और मेट्रिक्स की गणना में तेजी लाने के लिए ClickHouse और आयामी डेटा को संसाधित करने के लिए Elasticsearch हुआ करता था। ये दो विश्लेषणात्मक इंजन हैं और हमें उन दोनों के लिए क्वेरी स्टेटमेंट को अनुकूलित करने की आवश्यकता है। यह उच्च-रखरखाव वाला था। इस प्रकार, हमने ClickHouse को Apache Doris से बदल दिया, और Elasticsearch डेटा को डोरिस से जोड़ने के लिए कार्यक्षमता का उपयोग किया। इस तरह, हम डोरिस को अपना एकीकृत क्वेरी गेटवे बनाते हैं। Elasticsearch कैटलॉग 2. समतल मेजों को विभाजित करें हमारे OLAP आर्किटेक्चर के शुरुआती संस्करणों में, हम डेटा को फ्लैट टेबल में डालते थे, जिससे चीजें मुश्किल हो जाती थीं। एक बात के लिए, फ्लैट टेबल ने अपस्ट्रीम से सभी लेखन विलंबता को अवशोषित कर लिया, और इससे डेटा की वास्तविक समयबद्धता में काफी नुकसान हुआ। दूसरे के लिए, एक फ्लैट टेबल में 50% डेटा आयामी डेटा था, जिसे शायद ही कभी अपडेट किया गया था। प्रत्येक नई फ्लैट टेबल के साथ कुछ भारी आयामी डेटा आते थे जो बहुत अधिक भंडारण स्थान की खपत करते थे। इसलिए, हम फ़्लैट तालिकाओं को मीट्रिक तालिकाओं और आयाम तालिकाओं में विभाजित करते हैं। चूंकि उन्हें अलग-अलग गति से अपडेट किया जाता है, हम उन्हें अलग-अलग डेटा मॉडल में डालते हैं। : हम अपाचे डोरिस के एग्रीगेट कुंजी मॉडल में मीट्रिक डेटा की व्यवस्था करते हैं, जिसका अर्थ है कि नए डेटा को SUM, MAX, MIN, आदि के माध्यम से पुराने डेटा के साथ विलय कर दिया जाएगा। मीट्रिक तालिकाएँ : ये तालिकाएँ अपाचे डोरिस के अद्वितीय कुंजी मॉडल में हैं, जिसका अर्थ है कि नया डेटा रिकॉर्ड पुराने की जगह लेगा। यह हमारे क्वेरी परिदृश्यों में प्रदर्शन को काफी बढ़ा सकता है। आयाम तालिकाएँ आप पूछ सकते हैं कि क्या इससे प्रश्नों में परेशानी होती है, क्योंकि अधिकांश प्रश्नों के लिए दोनों प्रकार की तालिकाओं से डेटा की आवश्यकता होती है? चिंता न करें, हम इसका समाधान डोरिस की रोलअप सुविधा से करते हैं। आधार तालिकाओं के आधार पर, हम रोलअप दृश्य बनाने के लिए आवश्यक आयामों का चयन कर सकते हैं, जो स्वचालित रूप से निष्पादित करेगा। यह हमें प्रत्येक रोलअप दृश्य के लिए टैग परिभाषित करने की आवश्यकता से छुटकारा दिलाता है और काफी हद तक प्रश्नों की गति बढ़ाता है। GROUP BY अन्य तरकीबें अपाचे डोरिस के साथ हमारे अनुभव में, हमें कुछ अन्य कार्यात्मकताएँ भी उपयोगी लगीं, इसलिए मैं उन्हें भी यहाँ आपके लिए सूचीबद्ध कर रहा हूँ: 1. भौतिक दृश्य मटेरियलाइज्ड व्यू एक पूर्व-गणना किया गया डेटासेट है। जब आपको बार-बार कुछ आयामों के डेटा तक पहुंचने की आवश्यकता होती है तो यह प्रश्नों में तेजी लाने का एक तरीका है। इन परिदृश्यों में, हम मूल टैग और मेट्रिक्स को मूल टैग और मेट्रिक्स के आधार पर परिभाषित करते हैं। उदाहरण के लिए, हम मीट्रिक 1, मीट्रिक 2 और मीट्रिक 3 को मिलाकर एक व्युत्पन्न मीट्रिक बनाते हैं: फिर, हम इसके लिए एक भौतिकीकृत दृश्य बना सकते हैं। डोरिस रिलीज़ शेड्यूल के अनुसार, संस्करण 2.1 मल्टी-टेबल मटेरियलाइज़्ड व्यू का समर्थन करेगा, और हम इसके लिए तत्पर हैं। sum(m1+m2+m3) 2. फ्लिंक-डोरिस-कनेक्टर यह डेटा अंतर्ग्रहण में एक्ज़ेक्टली-वन्स गारंटी के लिए है। फ़्लिंक-डोरिस-कनेक्टर एक चेकपॉइंट तंत्र और दो-चरण प्रतिबद्धता को कार्यान्वित करता है, और रिलेशनल डेटाबेस से डोरिस तक ऑटो डेटा सिंक्रनाइज़ेशन की अनुमति देता है। 3. संघनन जब एकत्रीकरण कार्यों की संख्या या डेटा की मात्रा फ़्लिंक के लिए अत्यधिक हो जाती है, तो डेटा संकलन में भारी विलंबता हो सकती है। हम इसे वर्टिकल कॉम्पैक्शन और सेगमेंट कॉम्पैक्शन के साथ हल करते हैं। वर्टिकल कॉम्पैक्शन कॉलम के केवल भाग को लोड करने का समर्थन करता है, इसलिए यह फ्लैट टेबल को कॉम्पैक्ट करते समय भंडारण खपत को कम कर सकता है। सेगमेंट कॉम्पैक्शन डेटा लेखन के दौरान बहुत अधिक सेगमेंट उत्पन्न करने से बच सकता है, और एक साथ लिखते समय कॉम्पैक्शन की अनुमति देता है। आगे क्या होगा लागत कम करने और सेवा उपलब्धता बढ़ाने के उद्देश्य से, हम डोरिस के नए जारी स्टोरेज-कंप्यूट सेपरेशन और क्रॉस-क्लस्टर प्रतिकृति का परीक्षण करने की योजना बना रहे हैं, और हम सुपरसोनिक फ्रेमवर्क और अपाचे डोरिस प्रोजेक्ट के बारे में किसी भी विचार और इनपुट को स्वीकार करते हैं।
