एसएपी रिपोर्टिंग ब्रह्मांड

लगभग 4 साल पहले, हमने अपने रिपोर्टिंग सिस्टम को Oracle से SAP हाना में स्थानांतरित कर दिया। आज, यह लगभग 10,000 तालिकाओं को संग्रहीत करता है, 38,000 लोग इसका उपयोग करते हैं, और प्रतिदिन 5,000 से अधिक लोडिंग प्रक्रियाएं होती हैं। फिलहाल, हमारा कॉम्प्लेक्स, जिस पर सिस्टम काम करता है, में 14 टीबी मेमोरी वाले 8 सर्वर होते हैं। हर दिन, रिपोर्टिंग सिस्टम 1.5 pb डेटा संसाधित करता है। उसी समय, हाना Oracle, DB2 और MySQL की तुलना में लगभग 20 गुना अधिक उत्पादक था। और आज मैं यह बताना चाहता हूं कि, एम। विडियो और एल्डोरैडो के एकीकरण के ढांचे के भीतर, हमने रिपोर्टिंग प्रणाली के प्रदर्शन को बढ़ा दिया है, जो हमने अनुकूलन किए।

भार

आज, सिस्टम द्वारा बनाई गई कई हजार रिपोर्टों में से, कुल भार का केवल 10% उत्पन्न होता है। हाना डेटाबेस में सबसे भारी रिपोर्ट वीकली बुसिन्स रिव्यू है। यह 30 मिनट के लिए चलता है और 4 टीबी मेमोरी का उपभोग करता है। सभी रिपोर्ट का 90% संपर्क केंद्र द्वारा जनरेट किया जाता है: हमने एक सेवा बनाई है, जब कोई ग्राहक अपने फोन नंबर से कॉल करता है, स्वचालित रूप से एक रिपोर्ट खोलता है और ऑपरेटर को कॉलर की खरीदारी का पूरा इतिहास और कंपनी के साथ उसकी बातचीत दिखाता है।

डेटा मॉडल

प्रमुख डेटा मॉडल जिस पर रिपोर्ट का थोक बनाया गया है उसमें 1,500 टेबल हैं। उनमें से ज्यादातर संदर्भ टेबल हैं। इस मॉडल का उपयोग करके, आप कंपनी की किसी भी दिशा का विश्लेषण कर सकते हैं। एक उदाहरण यूनिवर्स डिजाइनर का उपयोग करके बनाए गए डेटा मॉडल का दृश्य है। सच है, यह हमारे सिस्टम का केवल दसवां हिस्सा दर्शाता है।

उत्पादकता

M.Video और Eldorado के विलय के समय, दो रिपोर्टिंग प्रणालियों में डेटा की मात्रा लगभग 10 TB थी: Hana M.Video प्रणाली पर BW में 7 TB, Hana Eldado पर BW में 2 TB और 1 TB HADOOP (ऐतिहासिक डेटा) में अतिरिक्त डेटा। सिस्टम को संयोजित करते समय, हमारे पास हार्डवेयर सीमाएँ थीं: एम। वीडियो कॉम्प्लेक्स में एक बैकअप सहित 6 नोड्स (2 टीबी प्रत्येक) शामिल थे। इस प्रणाली को अधिकतम 8 नोड तक विस्तारित किया जा सकता है, जिनमें से एक बैकअप।

विलय की तैयारी में, हमने माना कि सभी डेटा की कुल मात्रा 13 टीबी तक पहुंच जाएगी। इसलिए, SAP सिफारिशों के आधार पर, हमें दो टीबी नोड्स सहित प्रत्येक 2 टीबी के 16 नोड्स की एक प्रणाली की आवश्यकता थी। इसके अलावा, एक नोड को एक मास्टर नोड के रूप में आवंटित किया जाना था, जो इस तरह की जानकारी के साथ प्रबंधन कार्यों को संभालेंगे। यही है, सही संचालन के लिए 13 नोड्स को तैनात करना आवश्यक था।

जैसा कि आप देख सकते हैं, उपलब्ध संसाधन स्पष्ट रूप से पर्याप्त नहीं हैं। और वह पहली चुनौती थी।

विलय से पहले दूसरी मुख्य कठिनाई यह थी कि प्रणाली की गति अक्सर व्यापार की जरूरतों को पूरा नहीं करती थी। मुख्य कारण डेटाबेस के लिए समवर्ती कॉल की बड़ी संख्या थी। सिस्टम के दृष्टिकोण से, यह एक स्नोबॉल की तरह दिखता था, जो प्रक्रियाओं के हिस्से को ठंड या रुकावट या नोड्स पर "मेमोरी से बाहर" के वैश्विक डंप तक ले जा सकता था।

यह स्पष्ट था कि महत्वपूर्ण सुधारों के बिना, रिपोर्ट में डेटा की मात्रा में दो गुना वृद्धि (दो ब्रांडों के लिए) स्थिति के लगभग दो गुना खराब हो जाएगी।

इसलिए, हमने निम्नलिखित क्षेत्रों में सिस्टम का अनुकूलन करने का निर्णय लिया:

• जवाबदेही। सबसे महत्वपूर्ण और सबसे अधिक संसाधन-गहन रिपोर्ट और डेटा मॉडल के संशोधन का त्वरण।
  
• रिपोजिटरी । संग्रह और भंडारण अनुकूलन।
  
• डाउनलोड । प्रक्रिया को स्ट्रीमलाइन करें और डाउनलोड शेड्यूल बदलें।
  

अनुकूलन के लिए सामान्य दृष्टिकोण यह था:



सबसे पहले, हमने सभी दिशाओं में एक विश्लेषण किया, समस्याओं के कारणों की पहचान की, और फिर आवश्यक संसाधनों के साथ सिस्टम की क्षमताओं का विश्लेषण किया। हमने तुरंत इस प्रक्रिया को जितना संभव हो सके स्वचालित करने का प्रयास किया ताकि भविष्य में हम समस्याओं के कारणों को जल्दी से पहचान सकें और प्रदर्शन को जल्दी से बहाल कर सकें।

हमने क्या किया है:

• ABAP एप्लिकेशन सर्वरों का विन्यास बदला: उदाहरणों की संख्या, NUMA तकनीक का प्रभावी उपयोग और वर्कफ़्लो की इष्टतम संख्या।
  
• हमने हाना और लिनक्स ऑपरेटिंग सिस्टम के इष्टतम मापदंडों को लागू किया।
  
• हमने सीपीयू की खपत में कमी का विश्लेषण किया।
  
• हमने पूरे देखे गए समय अंतराल में रैम की खपत का विश्लेषण किया।
  
• हमने हाना पर ओओएम की घटना का विश्लेषण किया।
  
• हमने सिस्टम में ताले की घटना और प्रतीक्षा संचालन (प्रतीक्षा) के लिए सिस्टम संसाधनों की उपलब्धता का विश्लेषण किया।
  
• हमने SCALE-OUT HANA समाधान के लिए डेटा के पुनर्वितरण और पुनर्खरीद के लिए डेटा के संतुलन का विश्लेषण किया।
  
• हमने एबीएपी डंप के कारणों का विश्लेषण किया जो महत्वपूर्ण श्रृंखलाओं के संचालन को प्रभावित करते हैं।
  

परिणामों के आधार पर, प्रदर्शन रिपोर्ट संकलित की गई, साथ ही निर्देश भी दिए गए ताकि भविष्य में सिस्टम में स्वतंत्र रूप से अड़चनों और पीक टाइम अंतराल को निर्धारित करना संभव हो सके।

क्या परिणाम प्राप्त हुए:









कई अनुकूलित रिपोर्ट SAP BO ने कई बार तेज़ी से काम करना शुरू किया और सैकड़ों बार कम मेमोरी का उपभोग किया।



यहां कुछ हड़ताली उदाहरण दिए गए हैं कि कैसे सिस्टम गलत तरीके से चयन की शर्तों को पूरा करता है, और हाना में प्रश्नों का सही तरीके से निर्माण कैसे करें।

गैर-भौतिक वस्तुओं द्वारा फ़िल्टर करने पर समस्याएँ सामने आईं, विशेष रूप से (!) जब COUNT DISTINCT संकेतकों का उपयोग किया जाता है (एक सीडी को ब्रह्मांड स्तर पर और CV में एक फ़ंक्शन में लिखा जा सकता है)।



यहां तक ​​कि अगर आप सीडी को क्वेरी से बाहर करते हैं, तो भी पहला विकल्प दूसरे की तुलना में 20 गुना धीमी गति से चलेगा, और सीडी के साथ, गति 500 ​​गुना अधिक होगी।



फ़िल्टरों में गैर-भौतिक वस्तुओं का उपयोग करने का एक विशेष मामला: दो या दो से अधिक वस्तुओं के मिश्रित फिल्टर, उदाहरण के लिए, एक सप्ताह और एक वर्ष में gluing:



सरेस से जोड़ा हुआ फिल्टर किसी तिथि में परिवर्तित होने के रूप में धीरे-धीरे काम नहीं करते हैं, लेकिन वे अभी भी प्रश्नों को धीमा कर देते हैं (लगभग 2-3 बार)।



रिपोर्टिंग प्रणाली, लोडिंग प्रक्रियाओं और श्रृंखलाओं के संचालन पर आंकड़े एकत्र करने के लिए, हमने निम्नलिखित योजना विकसित की:



उसी समय, हमने रिपोर्ट के नाम के साथ रिपोर्ट में एक विशेष टिप्पणी जोड़ी। इस प्रकार, हम सिस्टम के विभिन्न हिस्सों से लोड की तुलना कर सकते हैं और अवधि की अवधि की तुलना कर सकते हैं।

योजनाओं

हमारे पास व्यावसायिक कार्यक्षमता के विकास और डेटा विज़ुअलाइज़ेशन टूल के पर्याप्त संशोधन के लिए कई योजनाएं हैं। वैश्विक प्रवृत्ति जिसमें हम सक्रिय रूप से भाग ले रहे हैं, रिपोर्टिंग प्रणाली को डिजिटल परिवर्तन के प्रतिमान में एकीकृत करना है।

क्या मतलब?

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

फिर वे एक एल्गोरिथ्म के साथ आने के अनुरोधों के साथ हमारे पास आने लगे जो विशिष्ट कारकों के आधार पर एक शुद्ध लाभ के लिए एक योजना या पूर्वानुमान का निर्माण करेंगे।

और आज हम इस निष्कर्ष पर पहुंचे हैं कि उपयोगकर्ता शुद्ध लाभ का सटीक पूर्वानुमान जानना चाहते हैं। पूर्वानुमान एल्गोरिदम के विकास के लिए हमारे पास सभी आवश्यक डेटा हैं, और डेटा विश्लेषण विशेषज्ञ हैं जो मशीन लर्निंग मॉडल बना सकते हैं। जैसा कि आप जानते हैं, इसके लिए वास्तव में बड़ी मात्रा में डेटा की आवश्यकता होती है, इसलिए हमारी रिपोर्टिंग प्रणाली के विकास में मुख्य रुझानों में से एक बड़ा डेटा पर आधारित मॉडल के विश्लेषण और निर्माण के लिए संक्रमण है।

हमारी टीम के बारे में कुछ शब्द

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

यदि आप इन क्षेत्रों में रुचि रखते हैं, यदि आप अपने आप में ताकत महसूस करते हैं - स्वागत है! आप दिलचस्प और कठिन काम करेंगे, कभी-कभी तनावपूर्ण, लेकिन हमेशा रचनात्मक।