सैकड़ों हजारों पंक्तियों पर एक्सेल बनाम जाओ

इस साल हमने अपने स्मार्टकाल्स.आईओ प्रोजेक्ट के बारे में हैबर पर पहले ही लिखा था - व्यापार उपयोगकर्ताओं के लिए बनाई गई कॉल के दृश्य डिजाइनर। यह परियोजना बड़े पैमाने पर ग्राहक कॉल की व्यावसायिक समस्या को हल करती है: एक दृश्य कॉल स्क्रिप्ट बनाई जाती है, फोन नंबर के साथ एक एक्सेल फ़ाइल लोड होती है, और फिर कॉल अभियान बनाया जाता है। अभियान शुरू किया गया है - ग्राहकों को कॉल शुरू; किसी भी समय आप आंकड़े देख सकते हैं, अभियान को रोक सकते हैं, सेटिंग्स को मोड़ सकते हैं। ग्राहक संतुष्ट थे जब तक कि यह स्पष्ट नहीं हो गया था कि कभी-कभी यह न केवल बहुत से लोगों को बजाना आवश्यक है, बल्कि बहुत, बहुत ज्यादा है। कटौती के तहत समस्या का सार है और हमने HYIP (अनुचित रूप से नहीं) प्रोग्रामिंग भाषा का उपयोग करके इसे कैसे हराया।

समस्या

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

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

इसलिए, टीम का एक काम था - फ़ॉनिंग के लिए अभियान में बड़ी फ़ाइलों के अपलोड को लागू करना।

निर्णय

हम जावा विकास में बहुत सक्षम हैं - उदाहरण के लिए, इस भाषा में आंशिक रूप से वोक्सिमप्लांट एपीआई लागू किया गया है; हम PHP में भी अच्छे हैं (ऊपर उदाहरण देखें - कैप्टन एविडेंस बताते हैं)। यही है, हम इन भाषाओं में से किसी एक का उपयोग करके इस कार्य को जल्दी से बंद कर सकते हैं, लेकिन हमने अपनी प्रौद्योगिकी स्टैक का विस्तार करने के लिए एक लंबे समय के लिए सोचा था, और यहां हमने याद किया कि बहुत अच्छी तरह से जाना है: यह काफी तेज़ है (मेमोरी के साथ अच्छी तरह से काम करता है), बहु-थ्रेडेड और एक रनटाइम की आवश्यकता नहीं है क्योंकि एक निष्पादन योग्य बाइनरी में संकलित करें। इसके अलावा, हम कंटेनरों के आकार के बारे में कह सकते हैं, लेकिन उस पर और बाद में ...

नतीजतन, हमने गो भाषा में एक माइक्रो सर्विस लिखी, जो बड़े आकार की शीट (300 हजार तक की रेखाएं) और प्रारूप (xls, xlsx और उनकी सभी विविधताएं) को स्वीकार करता है। अब विवरण के लिए समय है।

कार्यान्वयन

जब कोई ग्राहक SmartCalls अभियान में एक फ़ाइल> 10 हजार लाइनें अपलोड करता है, तो इसके लिए एक माइक्रोसैस सर्विस लिया जाता है। यह इनपुट पॉइंटर्स लेता है:

• S3 संग्रहण में डाउनलोड की गई फ़ाइल के लिए;
• जिस अभियान के लिए इस फ़ाइल को अपलोड करने की आवश्यकता है।

तब माइक्रोसॉर्स्ट फ़ाइल के माध्यम से चलता है, इसे 10 हज़ार लाइनों (प्लेटफ़ॉर्म के लिए अधिकतम) के टुकड़ों में हिट करता है और प्रत्येक चंक को एस 3 स्टोरेज में सीएसवी फ़ाइल के रूप में लोड करता है, डेटाबेस में प्रत्येक चंक के बारे में नोट्स बनाता है (फ़ाइल के लिए पथ, लाइनों की संख्या)। प्रत्येक चंक को एक अलग स्ट्रीम में संसाधित और लोड किया जाता है, जो निष्पादन की गति में एक अतिरिक्त वृद्धि देता है।

एक्सेल-फाइलों को पढ़ने के लिए टेगेल और एक्सट्रैम से ओपन सोर्स लाइब्रेरी का इस्तेमाल किया। यह अच्छा है कि उनके पास न केवल बहुत सारे सितारे हैं, बल्कि ताज़ा भी हैं :)

import ( "github.com/tealeg/xlsx" "github.com/extrame/xls" //   ) 

और सब कुछ ठीक होगा, लेकिन इसकी बारीकियों के बिना नहीं। विकास के दौरान, यह पता चला कि विभिन्न संपादकों में बनाए गए xlsx और xls, उनके साथ काम करने के लिए प्रारूप और नियमों में बहुत भिन्न हैं। मुझे कई परीक्षण करने पड़े - ओपनऑफिस, विभिन्न संस्करणों के एक्सेल, लिब्रे ऑफिस, गूगल शीट्स, एक एकल फॉर्म - सीएसवी में फाइल लाने के लिए माइक्रोसिस्टवर्क सिखाने के लिए। Microservice के बाद "chews" एक बड़ी फाइल है और इसे CSV में बदल देता है, SmartCalls API चालू है और पहले से ही इस csv फ़ाइल के साथ काम करता है। माइक्रोसैस सर्विस के लिए, हमने 300 हजार लाइनों की एक सीमा छोड़ दी, क्योंकि यह ग्राहकों की जरूरतों को बहुत कवर करती है, और हमने किसी भी बड़ी जरूरतों का सामना नहीं किया।

नतीजतन, कार्यान्वयन ने परीक्षणों और प्रीप्रोड में उत्कृष्ट परिणाम दिखाए, जिसके बाद हमने इसे ठेस में रोल किया।

निष्कर्ष

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