हा लेख कसा वाचायचा: मजकूर इतका लांब आणि गोंधळलेला असल्याबद्दल मी दिलगीर आहोत. तुमचा वेळ वाचवण्यासाठी, मी प्रत्येक अध्यायाची सुरुवात “मी काय शिकलो” प्रस्तावनेने करतो, जे एक किंवा दोन वाक्यांमध्ये अध्यायाचे सार सारांशित करते.

"फक्त मला उपाय दाखवा!" मी कोठून आलो हे तुम्हाला फक्त पहायचे असेल, तर “अधिक कल्पक बनणे” या धड्याकडे जा, परंतु मला वाटते की अपयशाबद्दल वाचणे अधिक मनोरंजक आणि उपयुक्त आहे.

मला अलीकडेच मोठ्या प्रमाणात कच्च्या DNA अनुक्रमांवर (तांत्रिकदृष्ट्या एक SNP चिप) प्रक्रिया करण्यासाठी प्रक्रिया सेट करण्याचे काम देण्यात आले होते. त्यानंतरच्या मॉडेलिंग आणि इतर कामांसाठी दिलेल्या अनुवांशिक स्थानाबद्दल (ज्याला SNP म्हणतात) त्वरीत डेटा मिळवण्याची गरज होती. R आणि AWK वापरून, मी क्वेरी प्रक्रियेला मोठ्या प्रमाणात गती देऊन, नैसर्गिक पद्धतीने डेटा साफ आणि व्यवस्थित करण्यात सक्षम होतो. हे माझ्यासाठी सोपे नव्हते आणि त्यासाठी अनेक पुनरावृत्ती आवश्यक होत्या. हा लेख तुम्हाला माझ्या काही चुका टाळण्यात मदत करेल आणि मी काय केले ते तुम्हाला दाखवेल.

प्रथम, काही प्रास्ताविक स्पष्टीकरण.

डेटा

आमच्या विद्यापीठाच्या अनुवांशिक माहिती प्रक्रिया केंद्राने आम्हाला 25 TB TSV स्वरूपात डेटा प्रदान केला आहे. मला ते 5 Gzip-संकुचित पॅकेजेसमध्ये विभागले गेले आहेत, प्रत्येकामध्ये सुमारे 240 चार-गीगाबाइट फायली आहेत. प्रत्येक पंक्तीमध्ये एका व्यक्तीकडून एका SNP साठी डेटा असतो. एकूण, ~ 2,5 दशलक्ष SNP आणि ~ 60 हजार लोकांवरील डेटा प्रसारित केला गेला. SNP माहिती व्यतिरिक्त, फायलींमध्ये असंख्य स्तंभ आहेत ज्यामध्ये विविध वैशिष्ट्ये प्रतिबिंबित होतात, जसे की वाचण्याची तीव्रता, भिन्न एलीलची वारंवारता इ. एकूण, अद्वितीय मूल्यांसह सुमारे 30 स्तंभ होते.

गोल

कोणत्याही डेटा व्यवस्थापन प्रकल्पाप्रमाणे, डेटा कसा वापरला जाईल हे निर्धारित करणे ही सर्वात महत्त्वाची गोष्ट होती. या प्रकरणात आम्ही SNP वर आधारित SNP साठी मॉडेल्स आणि वर्कफ्लो मुख्यतः निवडू. म्हणजेच, आम्हाला एका वेळी फक्त एका SNP वर डेटाची आवश्यकता असेल. मला 2,5 दशलक्ष SNP पैकी एकाशी संबंधित सर्व रेकॉर्ड शक्य तितक्या सहज, जलद आणि स्वस्तात कसे मिळवायचे हे शिकायचे होते.

हे कसे करू नये

एक योग्य क्लिच उद्धृत करण्यासाठी:

मी हजार वेळा अयशस्वी झालो नाही, क्वेरी-फ्रेंडली फॉरमॅटमध्ये डेटाचा समूह पार्स करणे टाळण्यासाठी मी फक्त हजार मार्ग शोधले आहेत.

प्रथम प्रयत्न

मी काय शिकलो: एका वेळी 25 TB पार्स करण्याचा कोणताही स्वस्त मार्ग नाही.

व्हँडरबिल्ट विद्यापीठात “अ‍ॅडव्हान्स्ड मेथड्स फॉर बिग डेटा प्रोसेसिंग” हा कोर्स घेतल्यावर, मला खात्री होती की युक्ती बॅगमध्ये होती. सर्व डेटावर चालण्यासाठी आणि निकालाचा अहवाल देण्यासाठी Hive सर्व्हर सेट करण्यासाठी कदाचित एक किंवा दोन तास लागतील. आमचा डेटा AWS S3 मध्ये संग्रहित असल्याने, मी सेवा वापरली अथेना, जे तुम्हाला S3 डेटावर Hive SQL क्वेरी लागू करण्याची परवानगी देते. तुम्हाला Hive क्लस्टर सेट अप/वाढवण्याची गरज नाही आणि तुम्ही फक्त तुम्ही शोधत असलेल्या डेटासाठी पैसे द्या.

मी अथेनाला माझा डेटा आणि त्याचे स्वरूप दर्शविल्यानंतर, मी यासारख्या प्रश्नांसह काही चाचण्या केल्या:

select * from intensityData limit 10;

आणि त्वरीत सु-संरचित परिणाम प्राप्त झाले. तयार.

आम्ही आमच्या कामात डेटा वापरण्याचा प्रयत्न करेपर्यंत...

मॉडेलची चाचणी घेण्यासाठी मला सर्व SNP माहिती काढण्यास सांगितले होते. मी क्वेरी चालवली:


select * from intensityData 
where snp = 'rs123456';

...आणि वाट पाहू लागली. आठ मिनिटांनंतर आणि 4 TB पेक्षा जास्त विनंती केलेल्या डेटानंतर, मला निकाल मिळाला. सापडलेल्या डेटाच्या प्रमाणानुसार अथेना शुल्क आकारते, प्रति टेराबाइट $5. त्यामुळे या एकाच विनंतीसाठी $20 आणि आठ मिनिटे प्रतीक्षा करावी लागेल. सर्व डेटावर मॉडेल चालविण्यासाठी, आम्हाला 38 वर्षे प्रतीक्षा करावी लागली आणि $50 दशलक्ष भरावे लागले. अर्थात, हे आमच्यासाठी योग्य नव्हते.

पर्केट वापरणे आवश्यक होते...

मी काय शिकलो: तुमच्या Parquet फाइल्सचा आकार आणि त्यांच्या संस्थेची काळजी घ्या.

मी प्रथम सर्व TSV चे रुपांतर करून परिस्थिती निश्चित करण्याचा प्रयत्न केला पर्केट फाइल्स. ते मोठ्या डेटा सेटसह कार्य करण्यासाठी सोयीस्कर आहेत कारण त्यातील माहिती स्तंभीय स्वरूपात संग्रहित केली जाते: प्रत्येक स्तंभ त्याच्या स्वतःच्या मेमरी/डिस्क विभागात असतो, मजकूर फाइल्सच्या विरूद्ध, ज्या पंक्तींमध्ये प्रत्येक स्तंभाचे घटक असतात. आणि जर तुम्हाला काही शोधायचे असेल तर फक्त आवश्यक कॉलम वाचा. याव्यतिरिक्त, प्रत्येक फाइल स्तंभामध्ये मूल्यांची श्रेणी संग्रहित करते, म्हणून तुम्ही शोधत असलेले मूल्य स्तंभाच्या श्रेणीमध्ये नसल्यास, स्पार्क संपूर्ण फाइल स्कॅन करण्यात वेळ वाया घालवणार नाही.

मी एक साधे कार्य केले एडब्ल्यूएस गोंद आमच्या TSV ला Parquet मध्ये रूपांतरित करण्यासाठी आणि नवीन फाइल्स Athena मध्ये टाकण्यासाठी. सुमारे 5 तास लागले. पण जेव्हा मी विनंती केली तेव्हा ती पूर्ण होण्यासाठी तेवढाच वेळ आणि थोडे कमी पैसे लागले. वस्तुस्थिती अशी आहे की स्पार्कने, कार्य ऑप्टिमाइझ करण्याचा प्रयत्न केला, फक्त एक TSV भाग अनपॅक केला आणि तो स्वतःच्या Parquet भागामध्ये ठेवला. आणि प्रत्येक भाग अनेक लोकांच्या संपूर्ण नोंदी ठेवण्याइतका मोठा असल्याने, प्रत्येक फाइलमध्ये सर्व SNP समाविष्ट होते, म्हणून स्पार्कला आवश्यक माहिती काढण्यासाठी सर्व फाईल्स उघडाव्या लागल्या.

विशेष म्हणजे, Parquet चे डीफॉल्ट (आणि शिफारस केलेले) कॉम्प्रेशन प्रकार, स्नॅपी, विभाजित करण्यायोग्य नाही. त्यामुळे, प्रत्येक एक्झिक्युटर पूर्ण 3,5 GB डेटासेट अनपॅकिंग आणि डाउनलोड करण्याच्या कामावर अडकला होता.

चला समस्या समजून घेऊया

मी काय शिकलो: क्रमवारी लावणे कठीण आहे, विशेषतः जर डेटा वितरित केला असेल.

मला असे वाटले की आता मला समस्येचे सार समजले आहे. मला फक्त SNP स्तंभानुसार डेटा क्रमवारी लावायचा होता, लोकांनुसार नाही. नंतर अनेक SNPs वेगळ्या डेटा चंकमध्ये संग्रहित केले जातील आणि नंतर Parquet चे “स्मार्ट” फंक्शन “मूल्य श्रेणीत असेल तरच उघडेल” सर्व वैभवात स्वतःला दर्शवेल. दुर्दैवाने, क्लस्टरमध्ये विखुरलेल्या अब्जावधी पंक्तींमध्ये क्रमवारी लावणे हे एक कठीण काम असल्याचे सिद्ध झाले.

मी कॉलेजमध्ये अल्गोरिदमचे वर्ग घेत आहे: “अरे, या सर्व वर्गीकरण अल्गोरिदमच्या संगणकीय जटिलतेची कोणीही काळजी घेत नाही”

मी 20TB मध्ये स्तंभावर क्रमवारी लावण्याचा प्रयत्न करत आहे #स्पार्क टेबल: "याला इतका वेळ का लागतोय?" # डेटासायन्स संघर्ष.

— निक स्ट्रायर (@ निकोलस स्ट्रेयर) मार्च 11, 2019

"मी एक विचलित विद्यार्थी आहे" या कारणामुळे AWS निश्चितपणे परतावा जारी करू इच्छित नाही. मी Amazon Glue वर क्रमवारी लावल्यानंतर, ते 2 दिवस चालले आणि क्रॅश झाले.

विभाजनाचे काय?

मी काय शिकलो: स्पार्कमधील विभाजने संतुलित असणे आवश्यक आहे.

मग मला गुणसूत्रांमध्ये डेटाचे विभाजन करण्याची कल्पना सुचली. त्यापैकी 23 आहेत (आणि जर तुम्ही मायटोकॉन्ड्रियल डीएनए आणि मॅप न केलेले क्षेत्र विचारात घेतले तर बरेच काही).
हे आपल्याला डेटा लहान भागांमध्ये विभाजित करण्यास अनुमती देईल. तुम्ही ग्लू स्क्रिप्टमधील स्पार्क एक्सपोर्ट फंक्शनमध्ये फक्त एक ओळ जोडल्यास partition_by = "chr", नंतर डेटा बादल्यांमध्ये विभागला गेला पाहिजे.

जीनोममध्ये क्रोमोसोम नावाच्या असंख्य तुकड्यांचा समावेश असतो.

दुर्दैवाने, ते कार्य केले नाही. क्रोमोसोमचे आकार वेगवेगळे असतात, याचा अर्थ वेगवेगळ्या प्रमाणात माहिती असते. याचा अर्थ असा की स्पार्कने कामगारांना पाठवलेले कार्य संतुलित नव्हते आणि हळूहळू पूर्ण झाले कारण काही नोड्स लवकर पूर्ण झाले आणि निष्क्रिय होते. मात्र, कामे पूर्ण झाली. परंतु एक एसएनपी विचारताना, असंतुलनामुळे पुन्हा समस्या निर्माण झाली. मोठ्या गुणसूत्रांवर (म्हणजे जिथे आम्हाला डेटा मिळवायचा आहे) SNPs वर प्रक्रिया करण्याची किंमत फक्त 10 च्या घटकांनी कमी झाली आहे. भरपूर, पण पुरेसे नाही.

जर आपण ते आणखी लहान भागांमध्ये विभागले तर?

मी काय शिकलो: कधीही 2,5 दशलक्ष विभाजने करण्याचा प्रयत्न करू नका.

मी सर्व बाहेर जाण्याचा निर्णय घेतला आणि प्रत्येक एसएनपीचे विभाजन केले. यामुळे विभाजने समान आकाराची असल्याची खात्री झाली. ही एक वाईट कल्पना होती. मी गोंद वापरला आणि एक निर्दोष ओळ जोडली partition_by = 'snp'. कार्य सुरू केले आणि कार्यान्वित होऊ लागले. एका दिवसानंतर मी तपासले आणि पाहिले की S3 वर अद्याप काहीही लिहिलेले नाही, म्हणून मी टास्क मारला. असे दिसते की Glue S3 मधील लपलेल्या ठिकाणी इंटरमीडिएट फाइल्स लिहित होता, अनेक फाइल्स, कदाचित काही दशलक्ष. परिणामी, माझ्या चुकीची किंमत एक हजार डॉलर्सपेक्षा जास्त आहे आणि माझ्या गुरूला संतुष्ट केले नाही.

विभाजन + वर्गीकरण

मी काय शिकलो: ट्यूनिंग स्पार्कप्रमाणे क्रमवारी लावणे अजूनही अवघड आहे.

विभाजन करण्याच्या माझ्या शेवटच्या प्रयत्नात मी गुणसूत्रांचे विभाजन केले आणि नंतर प्रत्येक विभाजनाची क्रमवारी लावली. सिद्धांतानुसार, हे प्रत्येक क्वेरीला गती देईल कारण इच्छित SNP डेटा दिलेल्या श्रेणीमध्ये काही Parquet भागांमध्ये असणे आवश्यक आहे. दुर्दैवाने, अगदी विभाजन केलेल्या डेटाची क्रमवारी लावणे हे एक कठीण काम ठरले. परिणामी, मी कस्टम क्लस्टरसाठी EMR वर स्विच केले आणि अधिक लवचिक वर्कफ्लो तयार करण्यासाठी आठ शक्तिशाली उदाहरणे (C5.4xl) आणि Sparklyr वापरले...

# Sparklyr snippet to partition by chr and sort w/in partition
# Join the raw data with the snp bins
raw_data
  group_by(chr) %>%
  arrange(Position) %>% 
  Spark_write_Parquet(
    path = DUMP_LOC,
    mode = 'overwrite',
    partition_by = c('chr')
  )

तथापि, अद्याप कार्य पूर्ण झाले नाही. मी ते वेगवेगळ्या प्रकारे कॉन्फिगर केले: प्रत्येक क्वेरी एक्झिक्यूटरसाठी मेमरी वाटप वाढवले, मोठ्या प्रमाणात मेमरी असलेले नोड्स वापरले, ब्रॉडकास्ट व्हेरिएबल्स (ब्रॉडकास्टिंग व्हेरिएबल्स) वापरले, परंतु प्रत्येक वेळी हे अर्ध-उपाय झाले आणि हळूहळू एक्झिक्युटर सुरू झाले. सर्वकाही थांबेपर्यंत अयशस्वी होणे.

अद्यतन: म्हणून ते सुरू होते. pic.twitter.com/agY4GU2ru5

— निक स्ट्रायर (@ निकोलस स्ट्रेयर) 15 शकते, 2019

मी अधिक सर्जनशील होत आहे

मी काय शिकलो: काहीवेळा विशेष डेटासाठी विशेष उपायांची आवश्यकता असते.

प्रत्येक SNP चे स्थान मूल्य असते. ही संख्या त्याच्या गुणसूत्राच्या बाजूने असलेल्या पायाच्या संख्येशी संबंधित आहे. आमचा डेटा व्यवस्थित करण्याचा हा एक छान आणि नैसर्गिक मार्ग आहे. सुरुवातीला मला प्रत्येक गुणसूत्राच्या प्रदेशानुसार विभाजन करायचे होते. उदाहरणार्थ, पोझिशन्स 1 - 2000, 2001 - 4000, इ. परंतु समस्या अशी आहे की SNPs सर्व गुणसूत्रांमध्ये समान रीतीने वितरीत केले जात नाहीत, म्हणून गटाचे आकार मोठ्या प्रमाणात बदलतील.

परिणामी, मी श्रेणींमध्ये (रँक) पदांचे विभाजन केले. आधीच डाउनलोड केलेला डेटा वापरून, मी अद्वितीय SNPs, त्यांची स्थिती आणि गुणसूत्रांची यादी मिळविण्यासाठी विनंती केली. मग मी प्रत्येक गुणसूत्रातील डेटाची क्रमवारी लावली आणि दिलेल्या आकाराच्या गटांमध्ये (बिन) SNP गोळा केले. प्रत्येकी 1000 SNP म्हणू. यामुळे मला SNP-ते-गट-प्रति-गुणसूत्र संबंध मिळाले.

सरतेशेवटी, मी 75 SNP चे गट (बिन) बनवले, कारण खाली स्पष्ट केले जाईल.

snp_to_bin <- unique_snps %>% 
  group_by(chr) %>% 
  arrange(position) %>% 
  mutate(
    rank = 1:n()
    bin = floor(rank/snps_per_bin)
  ) %>% 
  ungroup()

प्रथम स्पार्क वापरून पहा

मी काय शिकलो: स्पार्क एकत्रीकरण जलद आहे, परंतु विभाजन करणे अद्याप महाग आहे.

मला ही छोटी (२.५ दशलक्ष पंक्ती) डेटा फ्रेम स्पार्कमध्ये वाचायची होती, ती कच्च्या डेटासह एकत्र करायची होती आणि नंतर नव्याने जोडलेल्या स्तंभाद्वारे त्याचे विभाजन करायचे होते. bin.


# Join the raw data with the snp bins
data_w_bin <- raw_data %>%
  left_join(sdf_broadcast(snp_to_bin), by ='snp_name') %>%
  group_by(chr_bin) %>%
  arrange(Position) %>% 
  Spark_write_Parquet(
    path = DUMP_LOC,
    mode = 'overwrite',
    partition_by = c('chr_bin')
  )

मी वापरले sdf_broadcast(), म्हणून स्पार्कला माहित आहे की त्याने सर्व नोड्सवर डेटा फ्रेम पाठवला पाहिजे. जर डेटा आकाराने लहान असेल आणि सर्व कार्यांसाठी आवश्यक असेल तर हे उपयुक्त आहे. अन्यथा, स्पार्क स्मार्ट होण्याचा प्रयत्न करते आणि आवश्यकतेनुसार डेटा वितरित करते, ज्यामुळे मंदी येऊ शकते.

आणि पुन्हा, माझी कल्पना कार्य करत नाही: कार्यांनी काही काळ काम केले, युनियन पूर्ण केली आणि नंतर, विभाजनाद्वारे लॉन्च केलेल्या एक्झिक्यूटरप्रमाणे, ते अयशस्वी होऊ लागले.

AWK जोडत आहे

मी काय शिकलो: तुम्हाला मूलभूत गोष्टी शिकवल्या जात असताना झोपू नका. 1980 च्या दशकात नक्कीच कोणीतरी तुमची समस्या सोडवली आहे.

या क्षणापर्यंत, स्पार्कसह माझ्या सर्व अपयशांचे कारण क्लस्टरमधील डेटाची गोंधळ होती. कदाचित पूर्व-उपचाराने परिस्थिती सुधारली जाऊ शकते. स्पार्कला “पूर्व-विभाजित” डेटा प्रदान करण्याच्या आशेने मी कच्चा मजकूर डेटा गुणसूत्रांच्या स्तंभांमध्ये विभाजित करण्याचा प्रयत्न करण्याचा निर्णय घेतला.

स्तंभ मूल्यांनुसार विभाजित कसे करावे यासाठी मी StackOverflow वर शोधले आणि सापडले इतके छान उत्तर. AWK सह तुम्ही परिणाम पाठवण्याऐवजी स्क्रिप्टमध्ये लिहून स्तंभ मूल्यांनुसार मजकूर फाईल विभाजित करू शकता stdout.

ते वापरून पाहण्यासाठी मी बॅश स्क्रिप्ट लिहिली. पॅकेज केलेल्या TSV पैकी एक डाउनलोड केले, नंतर ते वापरून अनपॅक करा gzip आणि कडे पाठवले awk.

gzip -dc path/to/chunk/file.gz |
awk -F 't' 
'{print $1",..."$30">"chunked/"$chr"_chr"$15".csv"}'

हे काम केले!

कोर भरणे

मी काय शिकलो: gnu parallel - ही एक जादूची गोष्ट आहे, प्रत्येकाने ती वापरली पाहिजे.

वेगळे होणे खूप हळू होते आणि जेव्हा मी सुरुवात केली htopशक्तिशाली (आणि महाग) EC2 उदाहरणाचा वापर तपासण्यासाठी, मी फक्त एक कोर आणि सुमारे 200 MB मेमरी वापरत असल्याचे निष्पन्न झाले. समस्येचे निराकरण करण्यासाठी आणि भरपूर पैसे गमावू नयेत, आम्हाला कामाचे समांतर कसे करावे हे शोधून काढावे लागले. सुदैवाने, पूर्णपणे आश्चर्यकारक पुस्तकात कमांड लाइनवर डेटा सायन्स मला समांतरीकरणावर जेरॉन जॅन्सेन्सचा एक अध्याय सापडला. त्यातून मला कळले gnu parallel, युनिक्समध्ये मल्टीथ्रेडिंग लागू करण्यासाठी एक अतिशय लवचिक पद्धत.

जेव्हा मी नवीन प्रक्रिया वापरून विभाजन सुरू केले, तेव्हा सर्वकाही ठीक होते, परंतु तरीही एक अडचण होती - डिस्कवर S3 ऑब्जेक्ट्स डाउनलोड करणे फार जलद नव्हते आणि पूर्णपणे समांतर नव्हते. याचे निराकरण करण्यासाठी, मी हे केले:

मला आढळले की डिस्कवरील इंटरमीडिएट स्टोरेज पूर्णपणे काढून टाकून, थेट पाइपलाइनमध्ये S3 डाउनलोड स्टेजची अंमलबजावणी करणे शक्य आहे. याचा अर्थ मी डिस्कवर कच्चा डेटा लिहिणे टाळू शकतो आणि त्याहून लहान, आणि म्हणून स्वस्त, AWS वर स्टोरेज वापरू शकतो.
संघ aws configure set default.s3.max_concurrent_requests 50 AWS CLI वापरत असलेल्या थ्रेड्सची संख्या मोठ्या प्रमाणात वाढवली (डिफॉल्टनुसार 10 आहेत).
मी नावातील n अक्षरासह नेटवर्क गतीसाठी ऑप्टिमाइझ केलेल्या EC2 उदाहरणावर स्विच केले. मला आढळले आहे की एन-इंस्टन्स वापरताना प्रोसेसिंग पॉवरची हानी लोडिंग स्पीडच्या वाढीमुळे भरपाईपेक्षा जास्त आहे. बहुतेक कामांसाठी मी c5n.4xl वापरले.
बदलले gzip वर pigz, हे एक gzip साधन आहे जे फायली डीकंप्रेस करण्याच्या सुरुवातीला नॉन-समांतर कार्य समांतर करण्यासाठी छान गोष्टी करू शकते (यामुळे कमीतकमी मदत झाली).

# Let S3 use as many threads as it wants
aws configure set default.s3.max_concurrent_requests 50

for chunk_file in $(aws s3 ls $DATA_LOC | awk '{print $4}' | grep 'chr'$DESIRED_CHR'.csv') ; do

        aws s3 cp s3://$batch_loc$chunk_file - |
        pigz -dc |
        parallel --block 100M --pipe  
        "awk -F 't' '{print $1",..."$30">"chunked/{#}_chr"$15".csv"}'"

       # Combine all the parallel process chunks to single files
        ls chunked/ |
        cut -d '_' -f 2 |
        sort -u |
        parallel 'cat chunked/*_{} | sort -k5 -n -S 80% -t, | aws s3 cp - '$s3_dest'/batch_'$batch_num'_{}'
        
         # Clean up intermediate data
       rm chunked/*
done

सर्व काही त्वरीत कार्य करण्यासाठी हे चरण एकमेकांशी एकत्र केले जातात. डाउनलोड गती वाढवून आणि डिस्क रायट्स काढून टाकून, मी आता काही तासांत 5 टेराबाइट पॅकेजवर प्रक्रिया करू शकतो.

AWS वर तुम्ही पैसे देत असलेले सर्व कोर पाहण्यापेक्षा काहीही गोड नाही. जीएनयू-पॅरललबद्दल धन्यवाद मी 19gig csv अनझिप आणि स्प्लिट करू शकतो तितक्याच वेगाने मी डाउनलोड करू शकतो. मला हे चालवण्यासाठी स्पार्क देखील मिळू शकला नाही. # डेटासायन्स #लिनक्स pic.twitter.com/Nqyba2zqEk

— निक स्ट्रायर (@ निकोलस स्ट्रेयर) 17 शकते, 2019

या ट्विटमध्ये 'TSV' असा उल्लेख असावा. अरेरे.

नवीन विश्लेषित डेटा वापरणे

मी काय शिकलो: स्पार्कला असंपीडित डेटा आवडतो आणि विभाजने एकत्र करणे आवडत नाही.

आता डेटा S3 मध्ये अनपॅक केलेला (वाचा: सामायिक केलेला) आणि अर्ध-संघटित स्वरूपात होता आणि मी पुन्हा स्पार्कवर परत येऊ शकलो. मला एक आश्चर्य वाटले: मला हवे ते साध्य करण्यात मी पुन्हा अयशस्वी झालो! डेटाचे विभाजन नेमके कसे झाले हे स्पार्कला सांगणे फार कठीण होते. आणि जेव्हा मी हे केले तेव्हाही असे दिसून आले की बरेच विभाजने आहेत (95 हजार), आणि जेव्हा मी वापरले coalesce त्यांची संख्या वाजवी मर्यादेपर्यंत कमी केली, यामुळे माझे विभाजन नष्ट झाले. मला खात्री आहे की हे निश्चित केले जाऊ शकते, परंतु काही दिवस शोध घेतल्यानंतर मला उपाय सापडला नाही. मी अखेरीस स्पार्क मधील सर्व कार्ये पूर्ण केली, जरी यास थोडा वेळ लागला आणि माझ्या स्प्लिट पर्केट फायली फार लहान नव्हत्या (~200 KB). तथापि, डेटा आवश्यक होता तेथे होता.

खूप लहान आणि असमान, अद्भुत!

स्थानिक स्पार्क प्रश्नांची चाचणी करत आहे

मी काय शिकलो: साध्या समस्या सोडवताना स्पार्कमध्ये खूप ओव्हरहेड असते.

हुशार स्वरूपात डेटा डाउनलोड करून, मी वेग तपासण्यास सक्षम होतो. स्थानिक स्पार्क सर्व्हर चालविण्यासाठी आर स्क्रिप्ट सेट करा आणि नंतर निर्दिष्ट Parquet ग्रुप स्टोरेज (बिन) मधून स्पार्क डेटा फ्रेम लोड करा. मी सर्व डेटा लोड करण्याचा प्रयत्न केला परंतु विभाजन ओळखण्यासाठी Sparklyr मिळवू शकलो नाही.

sc <- Spark_connect(master = "local")

desired_snp <- 'rs34771739'

# Start a timer
start_time <- Sys.time()

# Load the desired bin into Spark
intensity_data <- sc %>% 
  Spark_read_Parquet(
    name = 'intensity_data', 
    path = get_snp_location(desired_snp),
    memory = FALSE )

# Subset bin to snp and then collect to local
test_subset <- intensity_data %>% 
  filter(SNP_Name == desired_snp) %>% 
  collect()

print(Sys.time() - start_time)

अंमलबजावणीसाठी 29,415 सेकंद लागले. बरेच चांगले, परंतु कोणत्याही गोष्टीच्या वस्तुमान चाचणीसाठी खूप चांगले नाही. याव्यतिरिक्त, मी कॅशिंगसह गोष्टींचा वेग वाढवू शकलो नाही कारण जेव्हा मी मेमरीमध्ये डेटा फ्रेम कॅशे करण्याचा प्रयत्न केला तेव्हा स्पार्क नेहमी क्रॅश होते, जरी मी 50 पेक्षा कमी वजनाच्या डेटासेटला 15 GB पेक्षा जास्त मेमरी वाटप केली तरीही.

AWK कडे परत जा

मी काय शिकलो: AWK मधील सहयोगी अॅरे अतिशय कार्यक्षम आहेत.

मला जाणवले की मी जास्त वेग मिळवू शकतो. मला ते आश्चर्यकारकपणे आठवले ब्रूस बार्नेट द्वारे AWK ट्यूटोरियल मी एका छान वैशिष्ट्याबद्दल वाचले "सहयोगी अॅरे" मूलत:, या की-व्हॅल्यू जोड्या आहेत, ज्यांना काही कारणास्तव AWK मध्ये वेगळ्या प्रकारे संबोधले गेले होते आणि म्हणूनच मी त्यांच्याबद्दल फारसा विचार केला नाही. रोमन चेपल्याका आठवले की "असोसिएटिव्ह अॅरे" हा शब्द "की-व्हॅल्यू पेअर" या शब्दापेक्षा खूप जुना आहे. जरी आपण Google Ngram मध्ये की-व्हॅल्यू पहा, तुम्हाला तेथे ही संज्ञा दिसणार नाही, परंतु तुम्हाला सहयोगी अॅरे सापडतील! याव्यतिरिक्त, "की-व्हॅल्यू जोडी" बहुतेकदा डेटाबेसशी संबंधित असते, म्हणून हॅशमॅपशी तुलना करणे अधिक अर्थपूर्ण आहे. मला जाणवले की मी Spark न वापरता बिन टेबल आणि रॉ डेटासह माझे SNPs संबद्ध करण्यासाठी या सहयोगी अॅरे वापरू शकतो.

हे करण्यासाठी, AWK स्क्रिप्टमध्ये मी ब्लॉक वापरला BEGIN. हा कोडचा एक तुकडा आहे जो स्क्रिप्टच्या मुख्य भागामध्ये डेटाची पहिली ओळ पास करण्यापूर्वी कार्यान्वित केला जातो.

join_data.awk
BEGIN {
  FS=",";
  batch_num=substr(chunk,7,1);
  chunk_id=substr(chunk,15,2);
  while(getline < "snp_to_bin.csv") {bin[$1] = $2}
}
{
  print $0 > "chunked/chr_"chr"_bin_"bin[$1]"_"batch_num"_"chunk_id".csv"
}

संघ while(getline...) CSV गट (बिन) मधून सर्व पंक्ती लोड केल्या, असोसिएटिव्ह अॅरेसाठी की म्हणून पहिला स्तंभ (SNP नाव) सेट करा bin आणि दुसरे मूल्य (समूह) मूल्य म्हणून. मग ब्लॉक मध्ये { }, जी मुख्य फाईलच्या सर्व ओळींवर कार्यान्वित केली जाते, प्रत्येक ओळ आउटपुट फाइलवर पाठविली जाते, ज्याला त्याच्या गटावर अवलंबून एक अद्वितीय नाव प्राप्त होते (बिन): ..._bin_"bin[$1]"_....

चल batch_num и chunk_id पाइपलाइनद्वारे प्रदान केलेल्या डेटाशी जुळले, शर्यतीची स्थिती टाळून, आणि प्रत्येक अंमलबजावणी थ्रेड चालू आहे parallel, त्याच्या स्वतःच्या अनन्य फाइलवर लिहिले.

माझ्या AWK सोबतच्या आधीच्या प्रयोगातून उरलेला सर्व कच्चा डेटा मी गुणसूत्रांवर फोल्डरमध्ये विखुरला असल्याने, आता मी एकावेळी एका गुणसूत्रावर प्रक्रिया करण्यासाठी दुसरी बॅश स्क्रिप्ट लिहू शकेन आणि S3 वर सखोल विभाजन केलेला डेटा पाठवू शकेन.

DESIRED_CHR='13'

# Download chromosome data from s3 and split into bins
aws s3 ls $DATA_LOC |
awk '{print $4}' |
grep 'chr'$DESIRED_CHR'.csv' |
parallel "echo 'reading {}'; aws s3 cp "$DATA_LOC"{} - | awk -v chr=""$DESIRED_CHR"" -v chunk="{}" -f split_on_chr_bin.awk"

# Combine all the parallel process chunks to single files and upload to rds using R
ls chunked/ |
cut -d '_' -f 4 |
sort -u |
parallel "echo 'zipping bin {}'; cat chunked/*_bin_{}_*.csv | ./upload_as_rds.R '$S3_DEST'/chr_'$DESIRED_CHR'_bin_{}.rds"
rm chunked/*

स्क्रिप्टमध्ये दोन विभाग आहेत parallel.

पहिल्या विभागात, इच्छित गुणसूत्रावरील माहिती असलेल्या सर्व फायलींमधून डेटा वाचला जातो, त्यानंतर हा डेटा थ्रेड्समध्ये वितरीत केला जातो, जो फायली योग्य गटांमध्ये (बिन) वितरीत करतो. एकाच फाईलवर एकाधिक थ्रेड्स लिहिताना शर्यतीची परिस्थिती टाळण्यासाठी, AWK वेगवेगळ्या ठिकाणी डेटा लिहिण्यासाठी फाइलची नावे पास करते, उदा. chr_10_bin_52_batch_2_aa.csv. परिणामी, डिस्कवर अनेक लहान फायली तयार केल्या जातात (यासाठी मी टेराबाइट ईबीएस व्हॉल्यूम वापरले).

दुसऱ्या विभागातील कन्व्हेयर parallel गटांमधून (बिन) जातात आणि त्यांच्या वैयक्तिक फायली सामान्य CSV c मध्ये एकत्र करतात catआणि नंतर निर्यातीसाठी पाठवते.

आर मध्ये प्रसारण?

मी काय शिकलो: तुम्ही संपर्क करू शकता stdin и stdout आर स्क्रिप्टमधून, आणि म्हणून पाइपलाइनमध्ये वापरा.

तुमच्या बॅश स्क्रिप्टमध्ये ही ओळ तुमच्या लक्षात आली असेल: ...cat chunked/*_bin_{}_*.csv | ./upload_as_rds.R.... हे सर्व एकत्रित गट फायली (बिन) खालील R स्क्रिप्टमध्ये अनुवादित करते. {} एक विशेष तंत्र आहे parallel, जे निर्दिष्ट प्रवाहात पाठवणारा कोणताही डेटा थेट कमांडमध्येच समाविष्ट करते. पर्याय {#} एक अद्वितीय थ्रेड आयडी प्रदान करते, आणि {%} जॉब स्लॉट क्रमांकाचे प्रतिनिधित्व करते (पुनरावृत्ती, परंतु एकाच वेळी कधीही). सर्व पर्यायांची यादी मध्ये आढळू शकते दस्तऐवजीकरण.

#!/usr/bin/env Rscript
library(readr)
library(aws.s3)

# Read first command line argument
data_destination <- commandArgs(trailingOnly = TRUE)[1]

data_cols <- list(SNP_Name = 'c', ...)

s3saveRDS(
  read_csv(
        file("stdin"), 
        col_names = names(data_cols),
        col_types = data_cols 
    ),
  object = data_destination
)

जेव्हा व्हेरिएबल file("stdin") मध्ये प्रसारित केले readr::read_csv, आर स्क्रिप्टमध्ये अनुवादित केलेला डेटा फ्रेममध्ये लोड केला जातो, जो नंतर फॉर्ममध्ये असतो .rds- फाइल वापरून aws.s3 थेट S3 वर लिहिले.

RDS हे Parquet च्या कनिष्ठ आवृत्तीसारखे आहे, स्पीकर स्टोरेजच्या फ्रिल्सशिवाय.

बॅश स्क्रिप्ट पूर्ण केल्यानंतर मला एक बंडल मिळाले .rdsS3 मध्ये असलेल्या फाइल्स, ज्याने मला कार्यक्षम कॉम्प्रेशन आणि अंगभूत प्रकार वापरण्याची परवानगी दिली.

ब्रेक R चा वापर असूनही, सर्वकाही खूप लवकर कार्य करते. आश्चर्याची गोष्ट नाही की, R चे भाग जे डेटा वाचतात आणि लिहितात ते अत्यंत ऑप्टिमाइझ केलेले असतात. एका मध्यम आकाराच्या गुणसूत्रावर चाचणी केल्यानंतर, C5n.4xl उदाहरणावर काम सुमारे दोन तासांत पूर्ण झाले.

S3 मर्यादा

मी काय शिकलो: स्मार्ट पथ अंमलबजावणीसाठी धन्यवाद, S3 अनेक फाईल्स हाताळू शकते.

S3 मध्ये हस्तांतरित केलेल्या अनेक फाईल्स हाताळण्यास सक्षम असेल की नाही याची मला भिती होती. मी फाइलची नावे अर्थपूर्ण बनवू शकतो, परंतु S3 त्यांना कसे शोधेल?

S3 मधील फोल्डर्स फक्त शोसाठी आहेत, खरं तर सिस्टीमला चिन्हात रस नाही /. S3 FAQ पृष्ठावरून.

असे दिसते की S3 विशिष्ट फाईलचा मार्ग हॅश टेबल किंवा दस्तऐवज-आधारित डेटाबेसमध्ये एक साधी की म्हणून दर्शवते. बादलीचा टेबल म्हणून विचार केला जाऊ शकतो आणि फायली त्या टेबलमधील रेकॉर्ड मानल्या जाऊ शकतात.

Amazon वर नफा कमावण्‍यासाठी गती आणि कार्यक्षमता महत्‍त्‍वाच्‍या असल्‍याने, ही फाईल-पथ सिस्‍टम फ्रेकिंग ऑप्टिमाइझ झाली आहे यात नवल नाही. मी शिल्लक शोधण्याचा प्रयत्न केला: जेणेकरून मला खूप विनंत्या कराव्या लागल्या नाहीत, परंतु विनंत्या त्वरीत कार्यान्वित झाल्या. असे दिसून आले की सुमारे 20 हजार बिन फायली बनविणे चांगले आहे. मला वाटते की आम्ही ऑप्टिमाइझ करणे सुरू ठेवल्यास, आम्ही वेग वाढवू शकतो (उदाहरणार्थ, फक्त डेटासाठी एक विशेष बादली बनवणे, अशा प्रकारे लुकअप टेबलचा आकार कमी करणे). पण पुढच्या प्रयोगांसाठी वेळ किंवा पैसा नव्हता.

क्रॉस सुसंगतता बद्दल काय?

मी काय शिकलो: वाया गेलेल्या वेळेचे पहिले कारण म्हणजे तुमची स्टोरेज पद्धत अकाली अनुकूल करणे.

या टप्प्यावर, स्वतःला विचारणे खूप महत्वाचे आहे: "मालकीचे फाइल स्वरूप का वापरावे?" लोडिंग गती (gzipped CSV फायलींना लोड होण्यासाठी 7 पट जास्त वेळ लागला) आणि आमच्या वर्कफ्लोसह सुसंगतता हे कारण आहे. R ला स्पार्क लोड शिवाय Parquet (किंवा बाण) फाइल्स सहज लोड करता येतात का याचा मी पुनर्विचार करू शकतो. आमच्या लॅबमधील प्रत्येकजण आर वापरतो आणि मला डेटा दुसर्‍या फॉरमॅटमध्ये रूपांतरित करायचा असल्यास, माझ्याकडे मूळ मजकूर डेटा आहे, त्यामुळे मी पुन्हा पाइपलाइन चालवू शकतो.

कामाची विभागणी

मी काय शिकलो: जॉब्स मॅन्युअली ऑप्टिमाइझ करण्याचा प्रयत्न करू नका, संगणकाला करू द्या.

मी एका क्रोमोसोमवर वर्कफ्लो डीबग केला आहे, आता मला इतर सर्व डेटावर प्रक्रिया करायची आहे.
मला रूपांतरणासाठी अनेक EC2 उदाहरणे वाढवायची होती, परंतु त्याच वेळी मला वेगवेगळ्या प्रोसेसिंग जॉब्सवर खूप असंतुलित भार मिळण्याची भीती होती (जसे स्पार्कला असंतुलित विभाजनांचा त्रास झाला). याव्यतिरिक्त, मला प्रति गुणसूत्र एक उदाहरण वाढविण्यात स्वारस्य नव्हते, कारण AWS खात्यांसाठी 10 उदाहरणांची डीफॉल्ट मर्यादा आहे.

मग मी प्रक्रिया जॉब ऑप्टिमाइझ करण्यासाठी R मध्ये स्क्रिप्ट लिहिण्याचे ठरवले.

प्रथम, मी S3 ला प्रत्येक गुणसूत्राने किती स्टोरेज स्पेस व्यापली आहे याची गणना करण्यास सांगितले.

library(aws.s3)
library(tidyverse)

chr_sizes <- get_bucket_df(
  bucket = '...', prefix = '...', max = Inf
) %>% 
  mutate(Size = as.numeric(Size)) %>% 
  filter(Size != 0) %>% 
  mutate(
    # Extract chromosome from the file name 
    chr = str_extract(Key, 'chr.{1,4}.csv') %>%
             str_remove_all('chr|.csv')
  ) %>% 
  group_by(chr) %>% 
  summarise(total_size = sum(Size)/1e+9) # Divide to get value in GB



# A tibble: 27 x 2
   chr   total_size
   <chr>      <dbl>
 1 0           163.
 2 1           967.
 3 10          541.
 4 11          611.
 5 12          542.
 6 13          364.
 7 14          375.
 8 15          372.
 9 16          434.
10 17          443.
# … with 17 more rows

मग मी एक फंक्शन लिहिले जे एकूण आकार घेते, गुणसूत्रांचा क्रम बदलते, त्यांना गटांमध्ये विभाजित करते num_jobs आणि सर्व प्रक्रिया नोकऱ्यांचे आकार किती भिन्न आहेत हे तुम्हाला सांगतो.

num_jobs <- 7
# How big would each job be if perfectly split?
job_size <- sum(chr_sizes$total_size)/7

shuffle_job <- function(i){
  chr_sizes %>%
    sample_frac() %>% 
    mutate(
      cum_size = cumsum(total_size),
      job_num = ceiling(cum_size/job_size)
    ) %>% 
    group_by(job_num) %>% 
    summarise(
      job_chrs = paste(chr, collapse = ','),
      total_job_size = sum(total_size)
    ) %>% 
    mutate(sd = sd(total_job_size)) %>% 
    nest(-sd)
}

shuffle_job(1)



# A tibble: 1 x 2
     sd data            
  <dbl> <list>          
1  153. <tibble [7 × 3]>

मग मी purrr वापरून हजारो फेऱ्या मारल्या आणि सर्वोत्तम निवडले.

1:1000 %>% 
  map_df(shuffle_job) %>% 
  filter(sd == min(sd)) %>% 
  pull(data) %>% 
  pluck(1)

म्हणून मी कार्यांचा एक संच पूर्ण केला जे आकारात खूप सारखे होते. मग माझ्या मागील बॅश स्क्रिप्टला एका मोठ्या लूपमध्ये गुंडाळणे बाकी होते for. हे ऑप्टिमायझेशन लिहिण्यासाठी सुमारे 10 मिनिटे लागली. आणि हे असंतुलित असल्‍यास मी मॅन्युअली तयार करण्‍यावर खर्च करेन त्यापेक्षा हे खूपच कमी आहे. म्हणून, मला वाटते की मी या प्राथमिक ऑप्टिमायझेशनसह योग्य होतो.

for DESIRED_CHR in "16" "9" "7" "21" "MT"
do
# Code for processing a single chromosome
fi

शेवटी मी शटडाउन कमांड जोडतो:

sudo shutdown -h now

... आणि सर्वकाही कार्य केले! AWS CLI वापरून, मी पर्याय वापरून उदाहरणे मांडली user_data प्रक्रिया करण्यासाठी त्यांना त्यांच्या कार्यांच्या बॅश स्क्रिप्ट दिल्या. ते धावले आणि आपोआप बंद झाले, म्हणून मी अतिरिक्त प्रक्रिया शक्तीसाठी पैसे देत नव्हतो.

aws ec2 run-instances ...
--tag-specifications "ResourceType=instance,Tags=[{Key=Name,Value=<<job_name>>}]" 
--user-data file://<<job_script_loc>>

चला पॅक करूया!

मी काय शिकलो: एपीआय वापरण्याच्या सुलभतेसाठी आणि लवचिकतेसाठी सोपे असावे.

शेवटी मला योग्य ठिकाणी आणि फॉर्ममध्ये डेटा मिळाला. माझ्या सहकार्‍यांसाठी शक्य तितक्या डेटा वापरण्याची प्रक्रिया सुलभ करणे बाकी आहे. मला विनंत्या तयार करण्यासाठी एक साधा API बनवायचा होता. जर भविष्यात मी येथून स्विच करण्याचा निर्णय घेतला .rds Parquet फायलींसाठी, तर ही माझ्यासाठी समस्या असावी, माझ्या सहकाऱ्यांसाठी नाही. यासाठी मी अंतर्गत आर पॅकेज बनवण्याचा निर्णय घेतला.

फंक्शनच्या आसपास आयोजित केलेल्या फक्त काही डेटा ऍक्सेस फंक्शन्स असलेले एक अतिशय सोपे पॅकेज तयार आणि दस्तऐवजीकरण करा get_snp. मी माझ्या सहकाऱ्यांसाठी एक वेबसाइटही बनवली आहे pkgdown, त्यामुळे ते सहजपणे उदाहरणे आणि दस्तऐवजीकरण पाहू शकतात.

स्मार्ट कॅशिंग

मी काय शिकलो: तुमचा डेटा व्यवस्थित तयार असल्यास, कॅशिंग सोपे होईल!

मुख्य कार्यप्रवाहांपैकी एकाने SNP पॅकेजवर समान विश्लेषण मॉडेल लागू केल्यामुळे, मी माझ्या फायद्यासाठी बिनिंग वापरण्याचे ठरवले. SNP द्वारे डेटा प्रसारित करताना, समूहातील सर्व माहिती (बिन) परत केलेल्या ऑब्जेक्टशी संलग्न केली जाते. म्हणजेच, जुन्या प्रश्नांमुळे (सैद्धांतिकदृष्ट्या) नवीन प्रश्नांच्या प्रक्रियेस गती मिळू शकते.

# Part of get_snp()
...
  # Test if our current snp data has the desired snp.
  already_have_snp <- desired_snp %in% prev_snp_results$snps_in_bin

  if(!already_have_snp){
    # Grab info on the bin of the desired snp
    snp_results <- get_snp_bin(desired_snp)

    # Download the snp's bin data
    snp_results$bin_data <- aws.s3::s3readRDS(object = snp_results$data_loc)
  } else {
    # The previous snp data contained the right bin so just use it
    snp_results <- prev_snp_results
  }
...

पॅकेज तयार करताना, मी वेगवेगळ्या पद्धती वापरताना वेगाची तुलना करण्यासाठी अनेक बेंचमार्क चालवले. मी याकडे दुर्लक्ष न करण्याची शिफारस करतो, कारण कधीकधी परिणाम अनपेक्षित असतात. उदाहरणार्थ, dplyr::filter अनुक्रमणिका-आधारित फिल्टरिंग वापरून पंक्ती कॅप्चर करण्यापेक्षा खूप जलद होते आणि फिल्टर केलेल्या डेटा फ्रेममधून एकल स्तंभ पुनर्प्राप्त करणे अनुक्रमणिका वाक्यरचना वापरण्यापेक्षा खूप जलद होते.

कृपया लक्षात घ्या की ऑब्जेक्ट prev_snp_results की समाविष्टीत आहे snps_in_bin. हा समूह (बिन) मधील सर्व अनन्य SNPs चा एक अॅरे आहे, जो तुम्हाला आधीपासून आधीच्या क्वेरीमधील डेटा आहे का ते त्वरित तपासण्याची परवानगी देतो. या कोडसह गटातील (बिन) सर्व SNP मधून लूप करणे देखील सोपे करते:

# Get bin-mates
snps_in_bin <- my_snp_results$snps_in_bin

for(current_snp in snps_in_bin){
  my_snp_results <- get_snp(current_snp, my_snp_results)
  # Do something with results 
}

निकाल

आता आम्ही मॉडेल आणि परिस्थिती चालवू शकतो (आणि गांभीर्याने सुरुवात केली आहे) जी आमच्यासाठी पूर्वी अगम्य होती. सर्वात चांगली गोष्ट म्हणजे माझ्या प्रयोगशाळेतील सहकाऱ्यांना कोणत्याही गुंतागुंतीबद्दल विचार करण्याची गरज नाही. त्यांच्याकडे फक्त एक कार्य आहे जे कार्य करते.

आणि जरी पॅकेजने त्यांना तपशील दिलेला असला तरी, मी डेटाचे स्वरूप इतके सोपे करण्याचा प्रयत्न केला की मी उद्या अचानक गायब झालो तर ते समजू शकतील...

वेग लक्षणीय वाढला आहे. आम्ही सहसा कार्यात्मकदृष्ट्या महत्त्वपूर्ण जीनोमचे तुकडे स्कॅन करतो. पूर्वी, आम्ही हे करू शकत नव्हतो (ते खूप महाग होते), परंतु आता, गट (बिन) रचना आणि कॅशिंगबद्दल धन्यवाद, एका एसएनपीसाठी विनंती सरासरी 0,1 सेकंदांपेक्षा कमी वेळ घेते आणि डेटा वापर इतका आहे S3 ची किंमत शेंगदाण्यापेक्षा कमी आहे.

अलीकडेच मी माझ्या लॅबसाठी 25+ टीबी कच्च्या जीनोटाइपिंग डेटामध्ये बदल केला आहे. मी सुरू केल्यावर, स्पार्क वापरण्यासाठी 8 मिनिटे लागली आणि SNP ची चौकशी करण्यासाठी $20 खर्च आला. AWK+ वापरल्यानंतर #आकडेवारी प्रक्रिया करण्यासाठी, आता एका सेकंदाच्या 10व्या पेक्षा कमी वेळ लागतो आणि त्याची किंमत $0.00001 आहे. माझे वैयक्तिक #मोठी माहिती जिंकणे. pic.twitter.com/ANOXVGrmkk

— निक स्ट्रायर (@ निकोलस स्ट्रेयर) 30 शकते, 2019

निष्कर्ष

हा लेख अजिबात मार्गदर्शक नाही. उपाय वैयक्तिक असल्याचे दिसून आले आणि जवळजवळ नक्कीच इष्टतम नाही. उलट ते एक प्रवासवर्णन आहे. मला इतरांनी समजून घ्यायचे आहे की असे निर्णय पूर्णपणे डोक्यात तयार झालेले दिसत नाहीत, ते चाचणी आणि त्रुटीचे परिणाम आहेत. तसेच, जर तुम्ही डेटा सायंटिस्ट शोधत असाल, तर लक्षात ठेवा की ही साधने प्रभावीपणे वापरण्यासाठी अनुभवाची आवश्यकता असते आणि अनुभवासाठी पैसे लागतात. मला आनंद आहे की माझ्याकडे पैसे भरण्याचे साधन होते, परंतु माझ्यापेक्षा तेच काम चांगले करू शकणार्‍या इतर अनेकांना पैशांच्या कमतरतेमुळे प्रयत्न करण्याची संधी कधीच मिळणार नाही.

मोठी डेटा साधने बहुमुखी आहेत. तुमच्याकडे वेळ असल्यास, तुम्ही स्मार्ट डेटा क्लीनिंग, स्टोरेज आणि एक्सट्रॅक्शन तंत्रांचा वापर करून जलद समाधान नक्कीच लिहू शकता. शेवटी ते खर्च-लाभ विश्लेषणावर येते.

मी काय शिकलो:

एका वेळी 25 टीबी पार्स करण्याचा कोणताही स्वस्त मार्ग नाही;
आपल्या Parquet फाइल्स आणि त्यांच्या संस्थेच्या आकाराबद्दल सावधगिरी बाळगा;
स्पार्कमधील विभाजने संतुलित असणे आवश्यक आहे;
सर्वसाधारणपणे, 2,5 दशलक्ष विभाजने करण्याचा कधीही प्रयत्न करू नका;
सॉर्टिंग अजूनही कठीण आहे, जसे स्पार्क सेट करणे;
कधीकधी विशेष डेटासाठी विशेष उपाय आवश्यक असतात;
स्पार्क एकत्रीकरण जलद आहे, परंतु विभाजन करणे अद्याप महाग आहे;
जेव्हा ते तुम्हाला मूलभूत गोष्टी शिकवतील तेव्हा झोपू नका, कदाचित 1980 च्या दशकात कोणीतरी तुमची समस्या आधीच सोडवली असेल;
gnu parallel - ही एक जादूची गोष्ट आहे, प्रत्येकाने ती वापरली पाहिजे;
स्पार्कला असंपीडित डेटा आवडतो आणि विभाजने एकत्र करणे आवडत नाही;
साध्या समस्यांचे निराकरण करताना स्पार्कमध्ये खूप ओव्हरहेड आहे;
AWK च्या सहयोगी अॅरे अतिशय कार्यक्षम आहेत;
तुम्ही संपर्क करू शकता stdin и stdout आर स्क्रिप्टमधून, आणि म्हणून पाइपलाइनमध्ये वापरा;
स्मार्ट पथ अंमलबजावणीबद्दल धन्यवाद, S3 अनेक फायलींवर प्रक्रिया करू शकते;
वेळ वाया घालवण्याचे मुख्य कारण म्हणजे वेळेआधीच तुमची स्टोरेज पद्धत ऑप्टिमाइझ करणे;
कार्ये व्यक्तिचलितपणे ऑप्टिमाइझ करण्याचा प्रयत्न करू नका, संगणकाला करू द्या;
वापराच्या सुलभतेसाठी आणि लवचिकतेसाठी API सोपे असावे;
जर तुमचा डेटा चांगला तयार असेल, तर कॅशिंग सोपे होईल!

स्त्रोत: www.habr.com

AWK आणि R वापरून 25TB पार्सिंग