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

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

यह पिछले प्रकाशनों का एक सिलसिला है।

आमतौर पर, एक सतही "माथे" दृष्टिकोण सबसे प्रभावी नहीं है। डेटा के विश्लेषण और प्रसंस्करण से जुड़े 99% कार्य उनके आयात से शुरू होते हैं। इस संक्षिप्त निबंध में, हम जीरा प्रारूप डेटा के "गहन" विश्लेषण के एक विशिष्ट कार्य के उदाहरण का उपयोग करते हुए, json प्रारूप में डेटा के साथ डेटा आयात करने के मूल चरण में आने वाली समस्याओं पर विचार करते हैं। json csv विपरीत एक जटिल ऑब्जेक्ट मॉडल का समर्थन करता है, इसलिए इसे जटिल संरचनाओं के मामले में पार्स करना बहुत मुश्किल और लंबा हो सकता है।

समस्या का बयान

दिए गए:

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

आकृति में एक नियमित जीरा जोंस का एक उदाहरण।

यह आवश्यक है:

• जीरा डेटा के आधार पर, विकास प्रक्रियाओं की दक्षता में संभावित वृद्धि की बाधाओं और बिंदुओं को खोजना और सभी पंजीकृत कार्यों के विश्लेषण के आधार पर परिणामी उत्पाद की गुणवत्ता में सुधार करना आवश्यक है।

निर्णय

सैद्धांतिक रूप से, JSON लोड करने और उन्हें data.frame कनवर्ट करने के लिए R में कई अलग-अलग पैकेज हैं। सबसे सुविधाजनक पैकेज jsonlite । हालाँकि, data.frame के लिए json पदानुक्रम का प्रत्यक्ष रूपांतरण बहु-स्तरीय नेस्टिंग और रिकॉर्ड संरचना के मजबूत पैरामीटर के कारण मुश्किल है। संबंधित मापदंडों के क्लचिंग, उदाहरण के लिए, कार्यों के इतिहास के लिए, विभिन्न एक्सट की आवश्यकता हो सकती है। जाँच और छोरों। यानी समस्या को हल किया जा सकता है, लेकिन 32 कार्यों की एक json फ़ाइल के लिए (सभी कलाकृतियों और कार्यों का पूरा इतिहास शामिल है) इस तरह के गैर-रैखिक विश्लेषण में jsonlite और tidyverse का उपयोग करके औसत प्रदर्शन लैपटॉप पर ~ 10 सेकंड लगते हैं।

अकेले 10 सेकंड ज्यादा नहीं है। लेकिन ठीक उस क्षण तक जब इनमें से बहुत सारी फाइलें नहीं हैं। एक समान "प्रत्यक्ष" विधि ~ 4000 फ़ाइलों (~ 4 जीबी) का उपयोग करके एक नमूना पार्सिंग और लोडिंग पर मूल्यांकन ने 8-9 घंटे का काम दिया।

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

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

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

परिणामस्वरूप समाधान निम्न 10 लाइनों तक कम हो जाता है (यह एक नकली कंकाल है, बाद में गैर-कार्यात्मक शरीर किट के बिना):

 library(tidyverse) library(jsonlite) library(readtext) fnames <- fs::dir_ls(here::here("input_data"), glob = "*.txt") ff <- function(fname){ json_vec <- readtext(fname, text_field = "texts", encoding = "UTF-8") %>% .$text %>% jqr::jq('[. | {issues: .issues}[] | .[]', '{id: .id, key: .key, created: .fields.created, type: .fields.issuetype.name, summary: .fields.summary, descr: .fields.description}]') jsonlite::fromJSON(json_vec, flatten = TRUE) } tictoc::tic("Loading with jqr-jsonlite single-threaded technique") issues_df <- fnames %>% purrr::map(ff) %>% data.table::rbindlist(use.names = FALSE) tictoc::toc() system.time({fst::write_fst(issues_df, here::here("data", "issues.fst"))}) 

यहाँ क्या दिलचस्प है?

1. लोडिंग प्रक्रिया को गति देने के लिए, विशेष, प्रोफाइल पैकेज जैसे कि readtext का उपयोग करना अच्छा है।
2. jq स्ट्रीमिंग पार्सर का उपयोग jq आवश्यक विशेषताओं के सभी हुकिंग को एक कार्यात्मक भाषा में अनुवाद करने की अनुमति देता है, इसे CPP स्तर तक कम करता है और data.frame में data.frame सूचियों या सूचियों के मैनुअल हेरफेर को कम करता है।
3. माइक्रोबेनचर्च के लिए एक बहुत ही होनहार bench पैकेज दिखाई दिया है। यह आपको न केवल संचालन के निष्पादन समय का अध्ययन करने की अनुमति देता है, बल्कि स्मृति का हेरफेर भी करता है। यह कोई रहस्य नहीं है कि आप मेमोरी में डेटा कॉपी करने पर बहुत कुछ खो सकते हैं।
4. बड़ी मात्रा में डेटा और सरल प्रसंस्करण के लिए, अक्सर अंतिम निर्णय लेने के लिए आवश्यक है कि समय-समय पर छोड़ दिया tidyverse और समय लेने वाले भागों को data.table में स्थानांतरित किया data.table , विशेष रूप से, data.table . data.table का उपयोग करके यहां तालिकाओं को विलय कर दिया data.table । और पोस्टप्रोसेसिंग चरण पर सभी परिवर्तन (जो कि ff फ़ंक्शन के माध्यम से चक्र में शामिल हैं) भी डेटा द्वारा उपयोग किए जाते हैं। संदर्भ द्वारा बदलते डेटा के दृष्टिकोण के साथ डेटा टूल का उपयोग किया जाता है, या Rcpp का उपयोग करके Rcpp पैकेज, उदाहरण के लिए, तारीखों और समय के अनुसार काम करने के लिए anytime पैकेज।
5. किसी फ़ाइल में डेटा डंप करने और फिर उसे पढ़ने के लिए fst पैकेज बहुत अच्छा है। विशेष रूप से, यह 4 साल के लिए सभी जीरा इतिहास विश्लेषिकी को बचाने के लिए बस एक सेकंड का एक अंश लेता है, और डेटा बिल्कुल आर डेटा प्रकारों के रूप में सहेजा जाता है, जो उनके बाद के पुन: उपयोग के लिए अच्छा है।

समाधान के दौरान, rjson पैकेज का उपयोग करने वाले एक दृष्टिकोण पर rjson गया था। jsonlite::fromJSON rjson = rjson::fromJSON(json_vec) की तुलना में लगभग 2 गुना धीमा है rjson = rjson::fromJSON(json_vec) , लेकिन इसे छोड़ना आवश्यक था, क्योंकि डेटा में NULL मान हैं, और NULL को NA में परिवर्तित करने के चरण में rjson द्वारा rjson सूचियों में लाभ, और कोड भारी हो जाता है।

निष्कर्ष

1. इस तरह के रिफैक्टरिंग से 8-9 घंटे से लेकर 10 मिनट तक एक ही लैपटॉप पर सिंगल थ्रेडेड मोड में सभी जोंस फाइलों के प्रोसेसिंग समय में बदलाव होता है।
2. व्यावहारिक रूप से foreach का उपयोग करके कार्य के समानांतर जोड़ना ने कोड (+ 5 लाइनों) को बोझ नहीं बनाया बल्कि निष्पादन समय को 5 मिनट तक कम कर दिया।
3. कमजोर लिनक्स सर्वर (केवल 4 कोर) के समाधान को स्थानांतरित करना, लेकिन बहु-थ्रेडेड मोड में एसएसडी पर चलने से निष्पादन समय 40 सेकंड तक कम हो गया।
4. एक उत्पादक सर्किट पर प्रकाशन (20 कोर, 3 गीगाहर्ट्ज, एसएसडी) ने निष्पादन समय 6-8 सेकंड तक घटा दिया है, जो परिचालन विश्लेषिकी कार्यों के लिए स्वीकार्य से अधिक है।

कुल मिलाकर, R प्लेटफ़ॉर्म के ढांचे के भीतर, एक सरल कोड रीफैक्टरिंग निष्पादन समय को ~ 9 घंटे से ~ 9 सेकंड तक कम करने में सफल रहा।

R पर निर्णय काफी तेज हो सकते हैं। यदि आपके लिए कुछ काम नहीं करता है, तो इसे एक अलग कोण से देखने और नई तकनीकों का उपयोग करने का प्रयास करें।

पिछला प्रकाशन - "प्रबंधक के लिए विश्लेषणात्मक पैराशूट" ।