यो लेख कसरी पढ्ने: पाठ यति लामो र अव्यवस्थित भएकोमा क्षमा चाहन्छु। तपाईको समय बचाउनको लागि, म प्रत्येक अध्याय "मैले के सिकें" परिचयको साथ सुरु गर्छु, जसले अध्यायको सारलाई एक वा दुई वाक्यमा संक्षेप गर्दछ।

"मलाई मात्र समाधान देखाउनुहोस्!" यदि तपाईं म कहाँबाट आएको देख्न चाहनुहुन्छ भने, त्यसपछि "धेरै आविष्कारक बन्ने" अध्यायमा जानुहोस्, तर मलाई लाग्छ कि यो असफलताको बारेमा पढ्न थप रोचक र उपयोगी छ।

मलाई भर्खरै कच्चा DNA अनुक्रमहरूको ठूलो मात्रा (प्राविधिक रूपमा एक SNP चिप) प्रशोधन गर्न प्रक्रिया सेटअप गर्ने काम दिइएको थियो। पछिको मोडलिङ र अन्य कार्यहरूको लागि दिइएको आनुवंशिक स्थान (SNP भनिन्छ) को बारे मा छिटो डेटा प्राप्त गर्न आवश्यक थियो। R र AWK को प्रयोग गरेर, मैले डेटालाई प्राकृतिक तरिकाले सफा र व्यवस्थित गर्न सक्षम भएँ, क्वेरी प्रशोधनलाई धेरै गतिमा बढाउँदै। यो मेरो लागि सजिलो थिएन र धेरै पुनरावृत्तिहरू आवश्यक थियो। यस लेखले तपाईंलाई मेरा केही गल्तीहरूबाट बच्न र मैले के समाप्त गरें भनेर देखाउन मद्दत गर्नेछ।

पहिलो, केही परिचयात्मक व्याख्या।

डाटा

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

लक्ष्य

कुनै पनि डाटा व्यवस्थापन परियोजनाको रूपमा, सबैभन्दा महत्त्वपूर्ण कुरा डाटा कसरी प्रयोग गरिनेछ भनेर निर्धारण गर्न थियो। यस मामला मा हामी SNP को आधारमा SNP को लागि धेरै जसो मोडेल र कार्यप्रवाहहरू चयन गर्नेछौं। त्यो हो, हामीलाई एक पटकमा एक SNP मा मात्र डाटा चाहिन्छ। मैले 2,5 मिलियन SNPs मध्ये एउटासँग सम्बद्ध सबै रेकर्डहरू कसरी सजिलै, छिटो र सस्तो रूपमा प्राप्त गर्ने भनेर सिक्नुपर्‍यो।

यो कसरी नगर्ने

उपयुक्त क्लिच उद्धृत गर्न:

म हजार पटक असफल भइनँ, मैले भर्खरै प्रश्न-अनुकूल ढाँचामा डाटाको गुच्छा पार्स गर्नबाट बच्न हजारौं तरिकाहरू पत्ता लगाए।

पहिलो प्रयास

मैले के सिकेको छु: एक पटकमा 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 प्रयोग गर्न आवश्यक थियो ...

मैले के सिकेको छु: तपाईंको Parquet फाइलहरूको आकार र तिनीहरूको संगठनसँग सावधान रहनुहोस्।

मैले पहिले सबै TSV लाई रूपान्तरण गरेर स्थिति ठीक गर्ने प्रयास गरें पर्केट फाइलहरू। तिनीहरू ठूला डेटा सेटहरूसँग काम गर्नका लागि सुविधाजनक छन् किनभने तिनीहरूमा जानकारी स्तम्भको रूपमा भण्डार गरिएको छ: प्रत्येक स्तम्भ पाठ फाइलहरूको विपरीत, यसको आफ्नै मेमोरी/डिस्क खण्डमा हुन्छ, जसमा पङ्क्तिहरूमा प्रत्येक स्तम्भका तत्वहरू हुन्छन्। र यदि तपाइँ केहि फेला पार्न आवश्यक छ भने, केवल आवश्यक स्तम्भ पढ्नुहोस्। थप रूपमा, प्रत्येक फाइलले स्तम्भमा मानहरूको दायरा भण्डार गर्दछ, त्यसैले यदि तपाईंले खोज्नु भएको मान स्तम्भको दायरामा छैन भने, स्पार्कले सम्पूर्ण फाइल स्क्यान गर्न समय बर्बाद गर्दैन।

मैले एउटा साधारण काम गरें AWS गोंद हाम्रो TSV हरूलाई Parquet मा रूपान्तरण गर्न र नयाँ फाइलहरूलाई एथेनामा छोड्न। करिब ५ घण्टा लाग्यो । तर जब मैले अनुरोध चलाएँ, यो पूरा गर्नको लागि समय र थोरै कम पैसा लाग्यो। तथ्य यो हो कि स्पार्कले कार्यलाई अप्टिमाइज गर्ने प्रयास गर्दै, केवल एउटा TSV खण्ड खोल्यो र यसलाई आफ्नै Parquet खण्डमा राख्यो। र किनभने प्रत्येक टुक्रा धेरै व्यक्तिहरूको सम्पूर्ण रेकर्डहरू समात्न पर्याप्त ठूलो थियो, प्रत्येक फाइलमा सबै SNP हरू समावेश थिए, त्यसैले स्पार्कले आवश्यक जानकारी निकाल्न सबै फाइलहरू खोल्नु परेको थियो।

चाखलाग्दो कुरा के छ भने, Parquet को पूर्वनिर्धारित (र सिफारिस गरिएको) कम्प्रेसन प्रकार, स्न्यापी, विभाजित गर्न योग्य छैन। त्यसकारण, प्रत्येक निर्वाहक पूर्ण 3,5 GB डाटासेट अनप्याक गर्ने र डाउनलोड गर्ने कार्यमा अड्किएको थियो।

समस्या बुझौं

मैले के सिकेको छु: क्रमबद्ध गर्न गाह्रो छ, विशेष गरी यदि डाटा वितरण गरिएको छ।

अब मैले समस्याको सार बुझेको जस्तो लाग्यो। मलाई केवल SNP स्तम्भ द्वारा डेटा क्रमबद्ध गर्न आवश्यक छ, मान्छे द्वारा होइन। त्यसपछि धेरै SNP हरू छुट्टै डाटा खण्डमा भण्डारण गरिनेछ, र त्यसपछि Parquet को "स्मार्ट" प्रकार्य "मान दायरामा छ भने मात्र खोल्नुहोस्" यसको सबै महिमामा देखाउनेछ। दुर्भाग्यवश, क्लस्टरमा छरिएका अरबौं पङ्क्तिहरू मार्फत क्रमबद्ध गर्न गाह्रो काम साबित भयो।

म कलेजमा एल्गोरिदम कक्षा लिइरहेको छु: "उह, यी सबै क्रमबद्ध एल्गोरिदमहरूको कम्प्यूटेशनल जटिलताको बारेमा कसैले वास्ता गर्दैन"

म 20TB मा स्तम्भमा क्रमबद्ध गर्न प्रयास गर्दैछु #स्पार्क तालिका: "यसले किन यति लामो समय लिइरहेको छ?" # डेटाडेन्स संघर्ष

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

AWS निश्चित रूपमा "म एक विचलित विद्यार्थी हुँ" कारणले गर्दा फिर्ता जारी गर्न चाहँदैन। मैले Amazon Glue मा क्रमबद्ध गरिसकेपछि, यो २ दिन चल्यो र क्र्यास भयो।

विभाजनको बारेमा के हो?

मैले के सिकेको छु: स्पार्कमा विभाजनहरू सन्तुलित हुनुपर्छ।

त्यसपछि मैले क्रोमोजोमहरूमा डाटा विभाजन गर्ने विचार लिएँ। त्यहाँ ती मध्ये 23 छन् (र धेरै धेरै यदि तपाइँ खाता माइटोकोन्ड्रियल DNA र अनम्याप गरिएको क्षेत्रहरू लिनुहुन्छ भने)।
यसले तपाईंलाई डाटालाई सानो टुक्रामा विभाजन गर्न अनुमति दिनेछ। यदि तपाईंले ग्लु लिपिमा स्पार्क निर्यात प्रकार्यमा केवल एउटा लाइन थप्नुभयो भने partition_by = "chr", त्यसपछि डाटा बाल्टी मा विभाजित हुनुपर्छ।

जीनोममा क्रोमोजोम भनिने धेरै टुक्राहरू हुन्छन्।

दुर्भाग्यवश, यसले काम गरेन। क्रोमोजोमहरू फरक-फरक साइज हुन्छन्, जसको अर्थ जानकारीको फरक मात्रा हो। यसको मतलब यो हो कि स्पार्कले कामदारहरूलाई पठाएको कार्य सन्तुलित थिएन र बिस्तारै पूरा भयो किनभने केही नोडहरू चाँडै समाप्त भए र निष्क्रिय थिए। तर, कामहरू पूरा भए । तर एक SNP को लागी सोध्दा, असन्तुलनले फेरि समस्या निम्त्यायो। ठूला क्रोमोजोमहरूमा SNP हरू प्रशोधन गर्ने लागत (जहाँ हामी डेटा प्राप्त गर्न चाहन्छौं) केवल 10 को कारकले घटेको छ। धेरै, तर पर्याप्त छैन।

के हुन्छ यदि हामीले यसलाई अझ सानो भागमा विभाजन गर्छौं?

मैले के सिकेको छु: 2,5 मिलियन विभाजनहरू कहिल्यै गर्ने प्रयास नगर्नुहोस्।

मैले सबै बाहिर जाने निर्णय गरे र प्रत्येक SNP विभाजन गरे। यसले सुनिश्चित गर्‍यो कि विभाजनहरू समान आकारका थिए। यो एक खराब विचार थियो। मैले ग्लु प्रयोग गरें र एक निर्दोष रेखा थपे partition_by = 'snp'। कार्य सुरु भयो र कार्यान्वयन गर्न थाल्यो। एक दिन पछि मैले जाँच गरें र देखें कि त्यहाँ अझै पनि S3 मा केहि लेखिएको छैन, त्यसैले मैले कार्यलाई मारें। यस्तो देखिन्छ कि ग्लुले मध्यवर्ती फाइलहरू 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, आदि। तर समस्या यो हो कि SNP हरू क्रोमोजोमहरूमा समान रूपमा वितरित छैनन्, त्यसैले समूह आकारहरू धेरै फरक हुनेछन्।

नतिजाको रूपमा, म कोटिहरू (रैंक) मा पदहरूको ब्रेकडाउनमा आएँ। पहिले नै डाउनलोड गरिएको डाटा प्रयोग गरेर, मैले अद्वितीय SNPs, तिनीहरूको स्थिति र क्रोमोसोमहरूको सूची प्राप्त गर्न अनुरोध गरें। त्यसपछि मैले प्रत्येक क्रोमोजोम भित्र डेटा क्रमबद्ध गरें र दिइएको साइजको समूह (बिन) मा SNP हरू सङ्कलन गरें। प्रत्येक 1000 SNPs भनौं। यसले मलाई SNP-देखि-समूह-प्रति-क्रोमोजोम सम्बन्ध दियो।

अन्तमा, मैले 75 SNPs को समूह (बिन) बनाएको छु, कारण तल वर्णन गरिनेछ।

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 मा प्रयोग गरिरहनुभएको सबै कोरहरू हेर्नु भन्दा मीठो केहि छैन। Gnu-parallel को लागी धन्यवाद म 19gig csv लाई जति छिटो डाउनलोड गर्न सक्छु अनजिप र विभाजन गर्न सक्छु। मैले यो चलाउन स्पार्क पनि पाउन सकिन। # डेटाडेन्स #लिनक्स pic.twitter.com/Nqyba2zqEk

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

यो ट्वीटमा 'TSV' उल्लेख हुनुपर्छ। काश।

नयाँ पार्स गरिएको डाटा प्रयोग गर्दै

मैले के सिकेको छु: स्पार्कले असम्पीडित डाटा मनपर्छ र विभाजनहरू संयोजन गर्न मन पराउँदैन।

अब डाटा अनप्याक गरिएको (पढ्नुहोस्: साझा गरिएको) र अर्ध-संगठित ढाँचामा S3 मा थियो, र म फेरि स्पार्कमा फर्कन सक्छु। एउटा आश्चर्यले मलाई पर्खिरहेको थियो: मैले चाहेको कुरा हासिल गर्न फेरि असफल भएँ! स्पार्कलाई डाटा कसरी विभाजन गरिएको थियो भन्ने कुरा बताउन धेरै गाह्रो थियो। र जब मैले यो गरें, यो बाहिर भयो कि त्यहाँ धेरै विभाजनहरू थिए (95 हजार), र जब मैले प्रयोग गरें coalesce तिनीहरूको संख्यालाई उचित सीमामा घटाइयो, यसले मेरो विभाजनलाई नष्ट गर्‍यो। म पक्का छु कि यो निश्चित हुन सक्छ, तर केहि दिनको खोजी पछि मैले समाधान पाउन सकिन। मैले अन्ततः स्पार्कमा सबै कार्यहरू समाप्त गरें, यद्यपि यसले केही समय लियो र मेरो विभाजन पर्केट फाइलहरू धेरै सानो थिएनन् (~ २०० KB)। तर, आवश्यक पर्ने ठाउँमा तथ्यांक थियो ।

धेरै सानो र असमान, अद्भुत!

स्थानीय स्पार्क प्रश्नहरू परीक्षण गर्दै

मैले के सिकेको छु: साधारण समस्याहरू समाधान गर्दा स्पार्कको धेरै ओभरहेड हुन्छ।

चतुर ढाँचामा डाटा डाउनलोड गरेर, म गति परीक्षण गर्न सक्षम थिएँ। स्थानीय स्पार्क सर्भर चलाउनको लागि R स्क्रिप्ट सेट अप गर्नुहोस्, र त्यसपछि निर्दिष्ट Parquet समूह भण्डारण (बिन) बाट स्पार्क डेटा फ्रेम लोड गर्नुहोस्। मैले सबै डाटा लोड गर्ने प्रयास गरें तर विभाजन पहिचान गर्न स्पार्कलर प्राप्त गर्न सकिन।

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 GB भन्दा बढी मेमोरी आवंटित गरे पनि।

AWK मा फर्कनुहोस्

मैले के सिकेको छु: AWK मा सहयोगी arrays धेरै कुशल छन्।

मैले महसुस गरें कि म उच्च गति हासिल गर्न सक्छु। मैले त्यो गजबमा सम्झें ब्रुस बार्नेट द्वारा AWK ट्यूटोरियल मैले एउटा सुन्दर सुविधाको बारेमा पढें "सहयोगी arrays" अनिवार्य रूपमा, यी कुञ्जी-मान जोडीहरू हुन्, जसलाई कुनै कारणले AWK मा फरक रूपमा बोलाइएको थियो, र त्यसैले मैले तिनीहरूको बारेमा धेरै सोचिन। रोमन चेपल्याका सम्झना भयो कि "सहयोगी arrays" शब्द "कुञ्जी-मान जोडी" शब्द भन्दा धेरै पुरानो छ। तिमी भए पनि गुगल एनग्राममा कुञ्जी-मान हेर्नुहोस्, तपाईंले त्यहाँ यो शब्द देख्नुहुने छैन, तर तपाईंले सहयोगी arrays फेला पार्नुहुनेछ! थप रूपमा, "कुञ्जी-मान जोडी" प्राय: डाटाबेसहरूसँग सम्बन्धित हुन्छ, त्यसैले यसलाई ह्याशम्यापसँग तुलना गर्न धेरै अर्थ लाग्छ। मैले महसुस गरें कि मैले यी एसोसिएटिभ एरेहरू मेरो SNPs लाई बिन टेबल र कच्चा डाटासँग Spark प्रयोग नगरी सम्बद्ध गर्न प्रयोग गर्न सक्छु।

यो गर्नको लागि, 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 R स्क्रिप्टबाट, र त्यसैले यसलाई पाइपलाइनमा प्रयोग गर्नुहोस्।

तपाईंले आफ्नो Bash स्क्रिप्टमा यो रेखा याद गर्नुभएको हुन सक्छ: ...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, R स्क्रिप्टमा अनुवाद गरिएको डाटा फ्रेममा लोड हुन्छ, जुन त्यसपछि फारममा हुन्छ .rds- फाइल प्रयोग गरेर aws.s3 सिधै S3 मा लेखिएको।

RDS Parquet को जुनियर संस्करण जस्तै हो, स्पिकर भण्डारण को फ्रिल बिना।

बास लिपि समाप्त गरेपछि मैले एउटा बन्डल पाएँ .rdsS3 मा अवस्थित फाइलहरू, जसले मलाई कुशल कम्प्रेसन र निर्मित प्रकारहरू प्रयोग गर्न अनुमति दियो।

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

S3 सीमाहरू

मैले के सिकेको छु: स्मार्ट पथ कार्यान्वयनको लागि धन्यवाद, S3 ले धेरै फाइलहरू ह्यान्डल गर्न सक्छ।

म चिन्तित थिएँ कि S3 ले यसमा स्थानान्तरण गरिएका धेरै फाइलहरू ह्यान्डल गर्न सक्षम हुनेछ। मैले फाइल नामहरूलाई अर्थपूर्ण बनाउन सक्छु, तर S3 तिनीहरूलाई कसरी खोज्छ?

S3 मा फोल्डरहरू देखाउनको लागि मात्र हुन्, वास्तवमा प्रणाली प्रतीकमा रुचि राख्दैन /. S3 FAQ पृष्ठबाट।

यस्तो देखिन्छ कि S3 ले ह्यास तालिका वा कागजात-आधारित डाटाबेसमा एक साधारण कुञ्जीको रूपमा एक विशेष फाइलको मार्ग प्रतिनिधित्व गर्दछ। एउटा बाल्टीलाई तालिकाको रूपमा सोच्न सकिन्छ, र फाइलहरूलाई त्यो तालिकामा रेकर्डहरू मान्न सकिन्छ।

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

क्रस अनुकूलता बारे के?

मैले के सिकें: समय बर्बाद गर्नुको नम्बर एक कारण भनेको समय भन्दा पहिले नै तपाईंको भण्डारण विधिलाई अनुकूलन गर्नु हो।

यस बिन्दुमा, यो आफैलाई सोध्नु धेरै महत्त्वपूर्ण छ: "किन स्वामित्व फाइल ढाँचा प्रयोग गर्नुहोस्?" कारण लोडिङ गतिमा छ (gzipped CSV फाइलहरू लोड हुन ७ गुणा बढी समय लाग्यो) र हाम्रो कार्यप्रवाहसँग अनुकूलता। यदि R ले स्पार्क लोड बिना Parquet (वा Arrow) फाइलहरू सजिलै लोड गर्न सक्छ भने म पुनर्विचार गर्न सक्छु। हाम्रो प्रयोगशालामा सबैजनाले आर प्रयोग गर्दछ, र यदि मैले डाटालाई अर्को ढाँचामा रूपान्तरण गर्न आवश्यक छ भने, मसँग अझै पनि मूल पाठ डाटा छ, त्यसैले म फेरि पाइपलाइन चलाउन सक्छु।

कामको विभाजन

मैले के सिकेको छु: म्यानुअल रूपमा कामहरू अप्टिमाइज गर्ने प्रयास नगर्नुहोस्, कम्प्युटरलाई गर्न दिनुहोस्।

मैले एउटा क्रोमोजोममा कार्यप्रवाह डिबग गरेको छु, अब मैले अन्य सबै डाटालाई प्रशोधन गर्न आवश्यक छ।
म रूपान्तरणको लागि धेरै 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 तिनीहरूलाई प्रशोधनका लागि तिनीहरूको कार्यहरूको Bash स्क्रिप्टहरू दिनुभयो। तिनीहरू दौडिए र स्वचालित रूपमा बन्द भए, त्यसैले मैले अतिरिक्त प्रशोधन शक्तिको लागि भुक्तान गरिन।

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

प्याक गरौं!

मैले के सिकेको छु: API प्रयोगको सहजता र लचिलोपनको लागि सरल हुनुपर्छ।

अन्ततः मैले सही ठाउँ र फारममा डाटा पाएँ। मेरा सहकर्मीहरूलाई सजिलो बनाउनको लागि सकेसम्म डाटा प्रयोग गर्ने प्रक्रियालाई सरल बनाउन बाँकी रहेको थियो। म अनुरोधहरू सिर्जना गर्नको लागि एक साधारण 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 
}

Результаты

अब हामी (र गम्भीरताका साथ सुरु गरेका छौं) मोडेलहरू र परिदृश्यहरू चलाउन सक्छौं जुन पहिले हामीलाई पहुँच थिएन। सबैभन्दा राम्रो कुरा यो हो कि मेरो प्रयोगशाला सहकर्मीहरूले कुनै पनि जटिलताहरूको बारेमा सोच्नु पर्दैन। तिनीहरूसँग केवल एक प्रकार्य छ जुन काम गर्दछ।

र यद्यपि प्याकेजले तिनीहरूलाई विवरणहरू छोड्छ, मैले डेटा ढाँचालाई पर्याप्त सरल बनाउन प्रयास गरें कि यदि म भोलि अचानक गायब भएमा तिनीहरूले यो पत्ता लगाउन सक्छन् ...

गति उल्लेखनीय रूपमा बढेको छ। हामी सामान्यतया कार्यात्मक रूपमा महत्त्वपूर्ण जीनोम टुक्राहरू स्क्यान गर्छौं। पहिले, हामीले यो गर्न सकेनौं (यो धेरै महँगो भयो), तर अब, समूह (बिन) संरचना र क्यासिङको लागि धन्यवाद, एक SNP को लागी अनुरोधले औसतमा ०.१ सेकेन्ड भन्दा कम समय लिन्छ, र डाटा उपयोग यति छ। कम कि S0,1 को लागत मूंगफली हो।

भर्खरै मैले मेरो ल्याबको लागि कच्चा जीनोटाइपिङ डाटाको 25+ TB रङ्गलिंग परिवर्तनमा राखें। मैले सुरु गर्दा, स्पार्क प्रयोग गर्न 8 मिनेट लाग्यो र SNP सोध्न $20 खर्च भयो। AWK+ प्रयोग गरेपछि #rstats प्रशोधन गर्न, यसले अब सेकेन्डको 10 औं भन्दा कम लिन्छ र $ 0.00001 लागत लाग्छ। मेरो व्यक्तिगत # बिगडाटा जीत pic.twitter.com/ANOXVGrmkk

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

निष्कर्षमा

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

ठूला डाटा उपकरणहरू बहुमुखी छन्। यदि तपाइँसँग समय छ भने, तपाइँ लगभग निश्चित रूपमा स्मार्ट डेटा सफाई, भण्डारण, र निकासी प्रविधिहरू प्रयोग गरेर छिटो समाधान लेख्न सक्नुहुन्छ। अन्ततः यो लागत-लाभ विश्लेषणमा आउँछ।

मैले के सिकें:

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

स्रोत: www.habr.com

AWK र R प्रयोग गरेर 25TB पार्स गर्दै