मल्टीप्रोसेसिंग के लिए पाइथन में बड़ी फ़ाइलों को विभाजित करने का सबसे अच्छा तरीका क्या है?

Question

मैं कई "शर्मनाक समानांतर" परियोजनाओं में भाग लेता हूं जिन्हें मैं multiprocessing मॉड्यूल के साथ समानांतर करना चाहता हूं। हालांकि, वे अक्सर बड़ी फाइलों (2 जीबी से अधिक) में पढ़ने, लाइन से लाइन को संसाधित करने, मूल गणना चलाने, और फिर परिणाम लिखने में शामिल होते हैं। फ़ाइल को विभाजित करने और पायथन के मल्टीप्रोसेसिंग मॉड्यूल का उपयोग करके इसे संसाधित करने का सबसे अच्छा तरीका क्या है? Queue या JoinableQueuemultiprocessing में उपयोग किया जाना चाहिए? या Queue मॉड्यूल खुद ही? या, क्या मुझे multiprocessing का उपयोग कर प्रक्रियाओं के पूल पर फ़ाइल को पुन: प्रयोज्य करना चाहिए? मैंने इन दृष्टिकोणों के साथ प्रयोग किया है लेकिन लाइन के आधार पर डेटा लाइन वितरण में ओवरहेड बहुत अधिक है। मैं cat file | process1 --out-file out1 --num-processes 2 | process2 --out-file out2 का उपयोग कर हल्के पाइप-फ़िल्टर डिज़ाइन पर बस गया हूं, जो पहले इनपुट के इनपुट का एक निश्चित प्रतिशत सीधे दूसरे इनपुट में पास करता है (this post देखें), लेकिन मैं पूरी तरह से पाइथन में एक समाधान रखना चाहता हूं।

आश्चर्य की बात है कि पाइथन दस्तावेज ऐसा करने का एक वैधानिक तरीका सुझाता है (multiprocessing दस्तावेज़ीकरण में प्रोग्रामिंग दिशानिर्देशों पर एक लंबे खंड के बावजूद)।

धन्यवाद, विन्स

अतिरिक्त जानकारी: प्रति पंक्ति संसाधित करने में समय बदलता रहता है। कुछ समस्याएं तेज और मुश्किल से I/O बाध्य नहीं हैं, कुछ CPU-bound हैं। सीपीयू बाध्य, गैर-निर्भर कार्यों को समांतरता से पोस्ट प्राप्त होगा, जैसे कि एक प्रसंस्करण समारोह में डेटा आवंटित करने के अक्षम तरीके भी दीवार घड़ी के समय के मामले में फायदेमंद होंगे।

एक प्रमुख उदाहरण एक ऐसी स्क्रिप्ट है जो रेखाओं से खेतों को निकालती है, विभिन्न प्रकार के बिटवॉ झंडे के लिए जांच करती है, और एक पूरी फाइल के साथ एक पूरी तरह से नए प्रारूप में कुछ झंडे वाली रेखाएं लिखती है। यह एक I/O बाध्य समस्या की तरह लगता है, लेकिन जब मैंने इसे अपने सस्ते समवर्ती संस्करण के साथ पाइप के साथ चलाया, तो यह लगभग 20% तेज था। जब मैं इसे पूल और मानचित्र के साथ चलाता हूं, या multiprocessing में कतार यह हमेशा 100% से अधिक धीमी है।

Answer 1

सर्वश्रेष्ठ आर्किटेक्चर में से एक पहले से ही लिनक्स ओएस का हिस्सा है। कोई विशेष पुस्तकालयों की आवश्यकता नहीं है।

आप एक "प्रशंसक-आउट" डिज़ाइन चाहते हैं।

1. एक "मुख्य" प्रोग्राम पाइप द्वारा जुड़े कई उपप्रोसेसेस बनाता है।

2. मुख्य कार्यक्रम फ़ाइल को पढ़ता है, उचित उपप्रोसेसरों को लाइनों को सौदा करने के लिए आवश्यक न्यूनतम फ़िल्टरिंग करने वाले पाइपों को लाइनें लिखता है।

प्रत्येक उपप्रोसेसर शायद अलग-अलग प्रक्रियाओं की एक पाइपलाइन होनी चाहिए जो stdin से पढ़ और लिखना चाहिए।

आपको कतार डेटा संरचना की आवश्यकता नहीं है, यह वास्तव में एक इन-मेमोरी पाइपलाइन है - दो समवर्ती प्रक्रियाओं के बीच बाइट्स की कतार।

Answer 2

यह आपकी फ़ाइल के प्रारूप पर बहुत निर्भर करता है।

क्या इसे कहीं भी विभाजित करने का अर्थ है? या क्या आपको इसे एक नई लाइन में विभाजित करने की ज़रूरत है? या क्या आपको यह सुनिश्चित करने की ज़रूरत है कि आप इसे ऑब्जेक्ट परिभाषा के अंत में विभाजित करें?

फ़ाइल को विभाजित करने के बजाय, आपको फ़ाइल के उचित भाग पर जाने के लिए os.lseek का उपयोग करके, एक ही फ़ाइल पर एकाधिक पाठकों का उपयोग करना चाहिए।

अद्यतन: पोस्टर ने कहा कि वह नई लाइनों पर विभाजित करना चाहता है। फिर मैं निम्नलिखित का प्रस्ताव करता हूं:

मान लें कि आपके पास 4 प्रक्रियाएं हैं। फिर सरल समाधान oslseek 0%, 25%, 50% और 75% फ़ाइल के लिए है, और जब तक आप पहली नई पंक्ति को हिट नहीं करते हैं तब तक बाइट पढ़ें। यह प्रत्येक प्रक्रिया के लिए आपका शुरुआती बिंदु है। ऐसा करने के लिए आपको फ़ाइल को विभाजित करने की आवश्यकता नहीं है, बस प्रत्येक प्रक्रिया में बड़ी फ़ाइल में सही स्थान की तलाश करें और वहां से पढ़ना शुरू करें।

Answer 3

आप इस बात का जिक्र नहीं करते कि आप लाइनों को कैसे संसाधित कर रहे हैं; संभवतः जानकारी का सबसे महत्वपूर्ण टुकड़ा।

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

यदि रेखाएं स्वतंत्र हैं और फ़ाइल नहीं बढ़ती है, तो आपको केवल एक ही समन्वय की आवश्यकता है जो प्रत्येक कार्यकर्ता को "शुरुआती पते" और "लंबाई" का निर्माण करना है; वे स्वतंत्र रूप से खुले और फ़ाइल में खोज सकते हैं और फिर आपको अपने परिणामों को समन्वयित करना होगा; शायद एन परिणामों को एक कतार में वापस आने की प्रतीक्षा करके।

यदि लाइनें स्वतंत्र नहीं हैं, तो उत्तर फ़ाइल की संरचना पर निर्भर करेगा।

Answer 4

मुझे पता है कि आपने विशेष रूप से पायथन के बारे में पूछा है, लेकिन मैं आपको हडोप (http://hadoop.apache.org/) देखने के लिए प्रोत्साहित करता हूं: यह मानचित्र और कम एल्गोरिदम लागू करता है जिसे विशेष रूप से इस तरह की समस्या का समाधान करने के लिए डिज़ाइन किया गया था।

गुड लक

Answer 5

तो रन टाइम लंबा है, बजाय प्रत्येक प्रक्रिया होने एक Queue के माध्यम से अपनी अगली पंक्ति को पढ़ने, प्रक्रियाओं लाइनों के बैच को पढ़ने के लिए है। इस तरह ओवरहेड कई लाइनों (जैसे हजारों या अधिक) पर amortized है।

Answer 6

एक रणनीति प्रत्येक कार्यकर्ता को ऑफसेट असाइन करने के लिए है ताकि आपके पास आठ कार्यकर्ता प्रक्रियाएं हों, तो संख्या 0 से 7 हो। कार्यकर्ता संख्या 0 पहले रिकॉर्ड प्रक्रियाओं को पढ़ता है, फिर यह 7 छोड़ देता है और 8 वें रिकॉर्ड इत्यादि को संसाधित करता है। , कार्यकर्ता संख्या 1 दूसरे रिकॉर्ड को पढ़ता है और फिर 7 वें रिकॉर्ड को संसाधित करता है ..... 9

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

Answer 7

फ्रेड्रिक लुंड के Some Notes on Tim Bray's Wide Finder Benchmark बहुत अच्छी सलाह के साथ, एक बहुत ही समान उपयोग मामले के बारे में एक दिलचस्प पढ़ा है। कई अन्य लेखकों ने भी वही काम किया है, कुछ लेख से जुड़े हुए हैं, लेकिन हो सकता है कि आप "पायथन चौड़ा खोजक" या कुछ और ढूंढने के लिए कुछ भी करना चाहें। (multiprocessing मॉड्यूल के आधार पर कहीं भी एक समाधान था, लेकिन यह अब उपलब्ध नहीं प्रतीत होता है)