(बाइनरी) डेटा की बड़ी मात्रा के संस्करण नियंत्रण से कैसे निपटें


46

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

अपने स्वामी के अध्ययन में मैंने समान आकार (छवियों) के डेटा सेट पर काम किया और विभिन्न सर्वरों / उपकरणों पर अलग-अलग संस्करण का ध्यान रखने में बहुत सारी समस्याएं थीं। नेटवर्क पर 100GB तक की कठिनाई वास्तव में मज़ेदार नहीं है, और मुझे बहुत समय और प्रयास खर्च करना पड़ता है।

मुझे पता है कि विज्ञान के अन्य लोगों को भी इसी तरह की समस्या है, फिर भी मुझे एक अच्छा समाधान नहीं मिला।

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

अंत में, मुझे वास्तव में कुछ ऐसा चाहिए जो अन्य शोधकर्ता उपयोग कर सकें, इसलिए इसे सुपर सरल होने की आवश्यकता नहीं है, लेकिन कुछ घंटों में सीखना चाहिए।

मैंने कई अलग-अलग समाधानों का मूल्यांकन किया है, लेकिन कोई भी बिल फिट नहीं करता है:

  • svn कुछ हद तक अक्षम है और एक स्मार्ट सर्वर की जरूरत है
  • hg bigfile / bigfile केवल एक रिमोट का उपयोग कर सकता है
  • git bigfile / media केवल एक रिमोट का उपयोग कर सकता है, लेकिन यह बहुत कुशल भी नहीं है
  • अटारी में एक लॉग, या अलग क्षमता नहीं है
  • bup वास्तव में अच्छा दिखता है, लेकिन काम करने के लिए "स्मार्ट" सर्वर की आवश्यकता होती है

मैंने कोशिश की है git-annex, जो मुझे (और बहुत कुछ) करने के लिए सब कुछ चाहिए, लेकिन इसका उपयोग करना बहुत मुश्किल है और अच्छी तरह से प्रलेखित नहीं है। मैंने कई दिनों तक इसका उपयोग किया है और इसके चारों ओर अपना सिर नहीं मिला है, इसलिए मुझे संदेह है कि किसी अन्य सहकर्मी को दिलचस्पी होगी।

शोधकर्ता बड़े डेटासेट के साथ कैसे व्यवहार करते हैं, और अन्य शोध समूह क्या उपयोग कर रहे हैं?

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


1
@scaaahu मुझे नहीं लगता कि यह जरूरी एक सॉफ्टवेयर सवाल है; एक स्वीकार्य जवाब भी एक कार्यप्रवाह या उपकरण और प्रणालियों के संयोजन का वर्णन कर सकता है। (वैसे भी, विषय पर कहीं और होने के नाते एक प्रश्न यहाँ बंद करने के निर्णय में नहीं खेलना चाहिए।)

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

1
@JukkaSuomela मुझे लगता है कि यह एक उचित प्रश्न है जब आपको बहुत बड़े डेटासेट मिल गए हैं, यदि वे डेटासेट अक्सर बदलते हैं ... उन मामलों में, बैकअप अक्सर वह होता है जो संस्करण नियंत्रण के रूप में उपयोग किया जाता है।

1
मैं इस प्रश्न को ऑफ-टॉपिक के रूप में बंद करने के लिए मतदान कर रहा हूं क्योंकि यह अकादमिक के लिए कुछ विशेष के बजाय डेटा / डेटाबेस से संबंधित है। प्रश्न बहुत अच्छे हैं, और (IMHO) को DataScience.SE या (शायद) Dat.S.SE में ले जाना चाहिए।
पायोत्र मिग्डल

1
@ जोहान डेटा वैज्ञानिक की अलग पृष्ठभूमि है। उदाहरण के लिए, क्वांटम यांत्रिकी में मेरा है। यहाँ पूरी बात यह है कि: 1. StackExchange तथाकथित नाव प्रश्नों को हतोत्साहित करता है और 2. इसके बजाय इसे हल करने के लिए सबसे अच्छा अभ्यास प्राप्त करना बेहतर है, जिन्हें इसे हल करना था लेकिन कोई विचार नहीं था।
पायोत्र मिग्डल

जवाबों:


12

मैं जो प्रयोग कर रहा हूं वह एक प्रकार का हाइब्रिड समाधान है:

  • कच्चे डेटा का बैकअप
  • वर्कफ़्लो की पकड़
  • वर्कफ़्लो + संसाधित डेटा के मैनुअल स्नैपशॉट, जो प्रासंगिकता के हैं, उदाहरण के लिए:
    • मानक प्रीप्रोसेसिंग
    • वास्तव में समय लेने वाली
    • प्रकाशन के लिए

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


खैर, मैं find . -type f -print0 | xargs -0 md5sum > checksums.md5चेकसमों और चेकसमों की गणना करने के लिए उपयोग कर रहा हूं md5sum -c checksums.md5, और चेकसमों को संस्करण नियंत्रित करता हूं । यह विभिन्न स्थानों पर / विभिन्न मशीनों पर डेटा की जांच करने में मदद करता है। सबसे अच्छा लगता है कि हम इस समय कर सकते हैं,
जोहान

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

@ नोरोक आपने एक महान सामान्य रूपरेखा का वर्णन किया है। मैंने डीवीसी टूल में कुछ समान लागू किया है - कृपया नीचे मेरे उत्तर पर एक नज़र डालें। मैं आपकी प्रतिक्रिया की सराहना करता हूं।
दिमित्री पेत्रोव

9

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

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


ड्रॉपबॉक्स का एक लोकप्रिय ओपन सोर्स संस्करण है, खुदक्लाउड। मैंने इसे आजमाया नहीं है, हालांकि।

9

मैंने 10-100 फाइलों में 10-100GB का प्रबंधन करने के लिए Amazon S3 बाल्टी पर वर्जनिंग का उपयोग किया है। स्थानांतरण धीमा हो सकता है, इसलिए इसने समानांतर में संपीड़ित करने और स्थानांतरित करने में मदद की है, या ईसी 2 पर बस कम्प्यूटेशन चलाया है। Boto पुस्तकालय एक अच्छा अजगर इंटरफेस प्रदान करता है।


8

Git लार्ज फाइल स्टोरेज (LFS) को देखने का प्रयास करें । यह नया है, लेकिन देखने लायक बात हो सकती है।

जैसा कि मैंने देखा, हैकर न्यूज़ पर एक चर्चा में बड़ी फ़ाइलों से निपटने के कुछ अन्य तरीकों का उल्लेख किया गया है:


6

हम वास्तविक डेटा फ़ाइलों को नियंत्रित नहीं करते हैं। यदि हम इसे बाइनरी फॉर्म के बजाय सीएसवी के रूप में संग्रहीत करते हैं तो भी हम नहीं चाहते हैं। जैसा कि रिकार्डो एम ने कहा, हम अपना समय 10M पंक्ति डेटा सेट पर पंक्ति-दर-पंक्ति परिवर्तनों की समीक्षा करने में व्यतीत नहीं कर रहे हैं।

इसके बजाय, प्रसंस्करण कोड के साथ, मैं संस्करण मेटाडेटा को नियंत्रित करता हूं:

  • सुधार की तारीख
  • फाइल का आकार
  • पंक्ति गिनती
  • स्तंभ नाम

यह मुझे पता करने के लिए पर्याप्त जानकारी देता है , तो कोई डेटा फ़ाइल बदल गया है और की एक विचार क्या VCS पर बल देते बिना, (जैसे, पंक्तियां जोड़ी गईं / नष्ट कर दिया, नए / बदले नामों वाले कॉलमों) बदल गया है।


5

यह एक बहुत ही आम समस्या है। मुझे यह दर्द तब हुआ जब मैंने एक विश्वविद्यालय और अब - औद्योगिक डेटा विज्ञान परियोजनाओं के लिए अनुसंधान परियोजनाएँ कीं।

मैंने इस समस्या को हल करने के लिए एक खुला स्रोत उपकरण बनाया है और हाल ही में - डीवीसी

यह मूल रूप से आपके कोड को आपके स्थानीय डिस्क या बादलों (S3 और GCP संग्रहण) में Git और डेटा से जोड़ता है। DVC डेटा और कोड के बीच निर्भरता को ट्रैक करता है और निर्भरता ग्राफ (DAG) बनाता है। यह आपको अपनी परियोजना को प्रजनन योग्य बनाने में मदद करता है।

डीवीसी परियोजना को आसानी से साझा किया जा सकता है - अपने डेटा को क्लाउड में (डीवीसी सिंक कमांड) सिंक करें, अपने गिट रिपॉजिटरी को साझा करें और क्लाउड में अपने डेटा बाल्टी तक पहुंच प्रदान करें।

"कुछ घंटों में सीखने योग्य" - एक अच्छा बिंदु है। यदि आप Git से परिचित हैं तो आपके पास DVC के साथ कोई समस्या नहीं होनी चाहिए। आपको वास्तव में केवल तीन कमांड सीखने की आवश्यकता है:

  1. dvc init- जैसे git init। एक मौजूदा गिट रिपॉजिटरी में किया जाना चाहिए।
  2. dvc import- अपनी डेटा फ़ाइलें (स्रोत) आयात करें। स्थानीय फ़ाइल या URL।
  3. dvc run- जैसे आपके वर्कफ़्लो के चरण dvc run python mycode.py data/input.jpg data/output.csv। DVC आपके चरणों के बीच निर्भरता को स्वचालित रूप से प्राप्त करता है, DAG बनाता है और इसे Git में रखता है।
  4. dvc repro- अपनी डेटा फ़ाइल पुन: पेश करें। उदाहरण: vi mycode.py- कोड बदलें, और फिर dvc repro data/output.csvफ़ाइल (और सभी निर्भरताएँ) को पुन: उत्पन्न करेगा।

आपको क्लाउड और बुनियादी S3 या GCP कौशल के माध्यम से डेटा साझा करने के लिए कुछ और DVC कमांड सीखने की आवश्यकता है।

डीवीसी ट्यूटोरियल सबसे अच्छा प्रारंभिक बिंदु है - "डेटा संस्करण नियंत्रण: पुनरावृत्ति मशीन सीखने"


1
क्या इसका उपयोग केवल बड़ी बाइनरी फ़ाइलों (ज्यादातर वीडियो) को संग्रहीत करने के साथ किया जा सकता है। एमएल लक्ष्य नहीं है। लक्ष्य के पास बड़ी द्विआधारी फ़ाइल को संग्रहीत करने के लिए रेपो है। रेपो में कैशिंग, चयनात्मक चेकआउट / पुल (जैसे कि लागू करना) और फ़ाइल / निर्देशिका लॉकिंग तंत्र होना चाहिए। क्या यह ऐसे उद्देश्य के लिए उपयुक्त है?
हेमू

1
@ किमू हाँ। डीवीसी एमएल सुविधाओं के बिना मूल बड़े डेटा फ़ाइल परिदृश्य के लिए ठीक काम करता है (जैसे एमएल पाइपलाइन और प्रतिलिपि सुरक्षा)। Git सिमेंटिक के कारण Perforce- लॉक सिमेंटिक समर्थित नहीं है। कृपया प्रति-फ़ाइल चेकआउट का उपयोग करें।
दिमित्री पेट्रोव


0

आप DOT: डिसटर्ब्यूटेड ऑब्जेक्ट ट्रैकर रिपॉजिटरी मैनेजर नामक मेरी परियोजना पर एक नज़र डाल सकते हैं।
यह व्यक्तिगत उपयोग (कोई सहयोग नहीं) के लिए बाइनरी फ़ाइलों के लिए एक बहुत ही सरल वीसीएस है।
यह SHA1 चेकसमिंग और ब्लॉक डुप्लीकेशन के लिए उपयोग करता है। पूर्ण पी 2 पी सिंकिंग।
एक अनूठी विशेषता: पुल / पुश के लिए एक बार टीसीपी सर्वर का उपयोग करें।
यह परिवहन के लिए एसएसएच का उपयोग भी कर सकता है।

यह अभी तक जारी नहीं हुआ है, लेकिन एक अच्छा प्रारंभिक बिंदु हो सकता है।
http://borg.uu3.net/cgit/cgit.cgi/dot/about/


0

आप हैंगर का उपयोग करके देख सकते हैं । यह डेटा संस्करण नियंत्रण की दुनिया के लिए एक अपेक्षाकृत नया खिलाड़ी है, लेकिन बूँद के संस्करण के बजाय टेंसरों को संस्करण देकर वास्तव में अच्छा काम करता है। प्रलेखन को शुरू करने के लिए सबसे अच्छी जगह होनी चाहिए। चूंकि डेटा को दसियों के रूप में संग्रहीत किया जा रहा है, इसलिए आपको इसे सीधे अपने एमएल कोड के अंदर उपयोग करने में सक्षम होना चाहिए (प्लस हैंगर में अब PyTorch और Tensorflow के लिए डेटा लोडर हैं)। हैंगर के साथ, आप इतिहास के माध्यम से शून्य-लागत ब्रांचिंग, विलय, समय यात्रा जैसे सभी लाभ प्राप्त कर सकते हैं। हैंगर में क्लोनिंग के बारे में एक अच्छी विशेषता यह है कि आप आंशिक क्लोनिंग कर सकते हैं । जिसका अर्थ है, यदि आपके पास अपने रिमोट पर 10 टीबी डेटा है और केवल अपने मॉडल को प्रोटोटाइप करने के लिए 100 एमबी की आवश्यकता है, तो आप पूर्ण क्लोन के बजाय आंशिक क्लोनिंग के माध्यम से केवल 100 एमबी प्राप्त कर सकते हैं।

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.