AWK እና R በመጠቀም 25 ቴባ በመተንተን ላይ

AWK እና R በመጠቀም 25 ቴባ በመተንተን ላይ
ይህን ጽሑፍ እንዴት ማንበብ እንደሚቻል: ጽሑፉ በጣም ረጅም እና የተመሰቃቀለ በመሆኑ ይቅርታ እጠይቃለሁ። ጊዜህን ለመቆጠብ፣ እያንዳንዱን ምዕራፍ የምዕራፉን ፍሬ ነገር በአንድ ወይም በሁለት ዓረፍተ ነገሮች በሚያጠቃልል “የተማርኩትን” መግቢያ እጀምራለሁ።

"መፍትሄውን ብቻ አሳየኝ!" ከየት እንደመጣሁ ማየት ከፈለግክ፣ ወደ “ተጨማሪ ፈጠራ መሆን” የሚለውን ምዕራፍ ይዝለሉ፣ ግን ስለ ውድቀት ማንበብ የበለጠ አስደሳች እና ጠቃሚ ይመስለኛል።

ብዙ ጥሬ የዲ ኤን ኤ ቅደም ተከተሎችን (በቴክኒክ የ SNP ቺፕ) ለማስኬድ ሂደት የማዘጋጀት ኃላፊነት በቅርቡ ተሰጠኝ። ለቀጣይ ሞዴሊንግ እና ሌሎች ስራዎች ስለተሰጠው የዘረመል ቦታ (ኤስኤንፒ ተብሎ የሚጠራው) መረጃ በፍጥነት ማግኘት ነበረበት። R እና AWKን ተጠቅሜ መረጃን በተፈጥሯዊ መንገድ ማጽዳት እና ማደራጀት ችያለሁ፣ ይህም የጥያቄ ሂደትን በጣም አፋጥን። ይህ ለእኔ ቀላል አልነበረም እና ብዙ ድግግሞሾችን ፈልጎ ነበር። ይህ ጽሑፍ አንዳንድ ስህተቶቼን እንዲያስወግዱ እና ያጋጠመኝን ያሳየዎታል።

በመጀመሪያ, አንዳንድ የመግቢያ ማብራሪያዎች.

መረጃ

የዩኒቨርሲቲያችን የጄኔቲክ መረጃ ማቀናበሪያ ማዕከል በ 25 ቲቢ ቲኤስቪ መልክ መረጃ ሰጥቶናል. በ 5 ፓኬጆች ተከፋፍለው በጂዚፕ ተጨምቀው እያንዳንዳቸው 240 አራት ጊጋባይት ፋይሎችን ያዙ። እያንዳንዱ ረድፍ ከአንድ ግለሰብ የመጣ የአንድ SNP ውሂብ ይዟል። በጠቅላላው, በ ~ 2,5 ሚሊዮን SNPs እና ~ 60 ሺህ ሰዎች ላይ መረጃ ተላልፏል. ከ SNP መረጃ በተጨማሪ ፋይሎቹ የተለያዩ ባህሪያትን የሚያንፀባርቁ ቁጥሮች ያሏቸው በርካታ ዓምዶች እንደ የንባብ ጥንካሬ፣ የተለያዩ alleles ድግግሞሽ፣ ወዘተ. በጠቅላላው ወደ 30 የሚጠጉ ልዩ እሴቶች ያላቸው አምዶች ነበሩ።

ግብ

እንደ ማንኛውም የውሂብ አስተዳደር ፕሮጀክት በጣም አስፈላጊው ነገር መረጃው እንዴት ጥቅም ላይ እንደሚውል መወሰን ነበር. በዚህ ጉዳይ ላይ በ SNP ላይ በመመስረት ለ SNP በአብዛኛው ሞዴሎችን እና የስራ ሂደቶችን እንመርጣለን. ያም ማለት በአንድ ጊዜ ውሂብ በአንድ SNP ላይ ብቻ ያስፈልገናል. ከ 2,5 ሚሊዮን SNPs ጋር የተያያዙትን ሁሉንም መዝገቦች በተቻለ መጠን በቀላሉ፣ በፍጥነት እና በርካሽ እንዴት ማግኘት እንደምችል መማር ነበረብኝ።

ይህንን እንዴት እንደማያደርጉት

ተስማሚ ክሊቸን ለመጥቀስ፡-

አንድ ሺህ ጊዜ አልተሳካልኝም ፣ ብዙ የውሂብ ስብስቦችን ለጥያቄ ተስማሚ በሆነ ቅርጸት ላለመተንተን አንድ ሺህ መንገዶችን ብቻ አገኘሁ።

መጀመሪያ ሞክር

ምን ተማርኩኝበአንድ ጊዜ 25 ቲቢን ለመተንተን ርካሽ መንገድ የለም።

በቫንደርቢልት ዩኒቨርሲቲ “የላቁ ዘዴዎች ለትልቅ መረጃ ማቀናበሪያ” የሚለውን ኮርስ ከወሰድኩ በኋላ ዘዴው በከረጢቱ ውስጥ እንዳለ እርግጠኛ ነበርኩ። ሁሉንም መረጃዎች ለማሄድ እና ውጤቱን ሪፖርት ለማድረግ የሂቭ አገልጋይን ለማዘጋጀት አንድ ወይም ሁለት ሰአት ሊወስድ ይችላል. የእኛ መረጃ በAWS S3 ውስጥ ስለሚከማች አገልግሎቱን ተጠቀምኩ። አቴና, ይህም የ Hive SQL መጠይቆችን ወደ S3 ውሂብ እንድትተገብሩ ያስችልዎታል. የ Hive ክላስተርን ማዋቀር/ማሳደግ አያስፈልግዎትም፣ እና እርስዎም ለሚፈልጉት ውሂብ ብቻ ይከፍላሉ።

አቴናን ውሂቤን እና ቅርጸቱን ካሳየኋቸው በኋላ አንዳንድ ሙከራዎችን ከእንደዚህ አይነት ጥያቄዎች ጋር ሮጥኩ፡-

select * from intensityData limit 10;

እና በፍጥነት በደንብ የተዋቀሩ ውጤቶችን አግኝቷል. ዝግጁ።

መረጃውን በስራችን ለመጠቀም እስክንሞክር ድረስ...

ሞዴሉን ለመፈተሽ ሁሉንም የ SNP መረጃ እንዳወጣ ተጠየቅሁ. ጥያቄውን ሮጥኩ፡-


select * from intensityData 
where snp = 'rs123456';

... እና መጠበቅ ጀመረ. ከስምንት ደቂቃ በኋላ እና ከ4 ቴባ በላይ የተጠየቀ መረጃ ውጤቱን አገኘሁ። አቴና በተገኘው የውሂብ መጠን፣ በቴራባይት 5 ዶላር ያስከፍላል። ስለዚህ ይህ ነጠላ ጥያቄ 20 ዶላር እና ስምንት ደቂቃ ለመጠበቅ ያስወጣል. ሞዴሉን በሁሉም መረጃዎች ላይ ለማስኬድ 38 አመታትን መጠበቅ እና 50 ሚሊዮን ዶላር መክፈል ነበረብን።በእርግጥ ይህ ለእኛ ተስማሚ አልነበረም።

Parquet መጠቀም አስፈላጊ ነበር ...

ምን ተማርኩኝበፓርኬት ፋይሎችዎ መጠን እና በድርጅታቸው መጠን ይጠንቀቁ።

በመጀመሪያ ሁሉንም TSVs በመቀየር ሁኔታውን ለማስተካከል ሞከርኩ። የፓርኬት ፋይሎች. ከትልቅ የውሂብ ስብስቦች ጋር ለመስራት ምቹ ናቸው ምክንያቱም በውስጣቸው ያለው መረጃ በአምድ ቅርጽ ውስጥ ስለሚከማች እያንዳንዱ አምድ በራሱ ማህደረ ትውስታ / ዲስክ ክፍል ውስጥ ይገኛል, ከጽሑፍ ፋይሎች በተቃራኒው, ረድፎች የእያንዳንዱን አምድ አካላት ይይዛሉ. እና የሆነ ነገር ማግኘት ከፈለጉ, አስፈላጊውን አምድ ብቻ ያንብቡ. በተጨማሪም፣ እያንዳንዱ ፋይል በአምድ ውስጥ የተለያዩ እሴቶችን ያከማቻል፣ ስለዚህ የሚፈልጉት እሴት በአምዱ ክልል ውስጥ ካልሆነ፣ ስፓርክ ሙሉውን ፋይል በመቃኘት ጊዜ አያጠፋም።

አንድ ቀላል ሥራ ሠራሁ AWS ሙጫ የእኛን TSVs ወደ Parquet ለመቀየር እና አዲሶቹን ፋይሎች ወደ አቴና ጣልን። 5 ሰአታት ያህል ፈጅቷል። ነገር ግን ጥያቄውን ስጠይቅ፣ ለማጠናቀቅ ተመሳሳይ ጊዜ እና ትንሽ ገንዘብ ወስዷል። እውነታው ግን ስፓርክ ስራውን ለማመቻቸት እየሞከረ በቀላሉ አንድ የ TSV ቁርጥራጭን አውጥቶ በራሱ የፓርኬት ቁራጭ ውስጥ አስቀመጠው። እና እያንዳንዱ ቁራጭ የብዙ ሰዎችን አጠቃላይ መዝገቦች ለመያዝ በቂ ትልቅ ስለነበረ፣ እያንዳንዱ ፋይል ሁሉንም SNPs ይዟል፣ ስለዚህ Spark የሚፈልገውን መረጃ ለማውጣት ሁሉንም ፋይሎች መክፈት ነበረበት።

የሚገርመው፣ የፓርኬት ነባሪ (እና የሚመከር) የመጭመቂያ አይነት፣ ፈጣን፣ የማይከፋፈል አይደለም። ስለዚህ፣ እያንዳንዱ ፈጻሚ ሙሉውን 3,5 ጂቢ የውሂብ ስብስብ በማንሳት እና በማውረድ ስራ ላይ ተጣብቋል።

AWK እና R በመጠቀም 25 ቴባ በመተንተን ላይ

ችግሩን እንረዳው።

ምን ተማርኩኝ: መደርደር አስቸጋሪ ነው፣ በተለይ መረጃው ከተሰራጨ።

አሁን የችግሩን ፍሬ ነገር የተረዳሁ መሰለኝ። ውሂቡን በሰዎች ሳይሆን በ SNP አምድ ብቻ መደርደር ያስፈልገኝ ነበር። ከዚያ ብዙ SNPs በተለየ የውሂብ ክፍል ውስጥ ይቀመጣሉ, ከዚያም የፓርኬት "ስማርት" ተግባር "እሴቱ በክልል ውስጥ ከሆነ ብቻ ይከፈታል" እራሱን በሙሉ ክብር ያሳያል. እንደ አለመታደል ሆኖ በቢሊዮኖች የሚቆጠሩ ረድፎችን በክላስተር ላይ ተበታትነው መደርደር ከባድ ስራ ሆኖ ተገኝቷል።

AWS በእርግጠኝነት "የተዘናጋሁ ተማሪ ነኝ" በሚለው ምክንያት ገንዘቡን መመለስ አይፈልግም። በአማዞን ሙጫ ላይ ለመደርደር ከሮጥኩ በኋላ፣ ለ2 ቀናት ሮጦ ተከሰከሰ።

ስለ መከፋፈልስ?

ምን ተማርኩኝበስፓርክ ውስጥ ያሉ ክፍፍሎች ሚዛናዊ መሆን አለባቸው።

ከዚያ በክሮሞሶም ውስጥ መረጃን የመከፋፈል ሀሳብ አመጣሁ። ከእነዚህ ውስጥ 23ቱ አሉ (እና ብዙ ተጨማሪ ሚቶኮንድሪያል ዲ ኤን ኤ እና ካርታ የሌላቸው ክልሎችን ከግምት ውስጥ ካስገቡ)።
ይህ ውሂቡን ወደ ትናንሽ ቁርጥራጮች እንዲከፍሉ ያስችልዎታል። በ Glue ስክሪፕት ውስጥ ወደ ስፓርክ ኤክስፖርት ተግባር አንድ መስመር ብቻ ካከሉ partition_by = "chr", ከዚያም መረጃው ወደ ባልዲዎች መከፋፈል አለበት.

AWK እና R በመጠቀም 25 ቴባ በመተንተን ላይ
ጂኖም ክሮሞሶም የሚባሉ በርካታ ቁርጥራጮች አሉት።

በሚያሳዝን ሁኔታ, አልሰራም. ክሮሞሶምች የተለያዩ መጠኖች አሏቸው ይህም ማለት የተለያየ መጠን ያለው መረጃ ማለት ነው። ይህ ማለት ስፓርክ ለሰራተኞች የላካቸው ተግባራት ሚዛናዊ እና በዝግታ የተጠናቀቁ አልነበሩም ምክንያቱም አንዳንድ አንጓዎች ቀደም ብለው ስላጠናቀቁ እና ስራ ፈት ስለነበሩ ነው። ይሁን እንጂ ተግባሮቹ ተጠናቅቀዋል. ነገር ግን አንድ SNP ሲጠየቅ፣ አለመመጣጠን እንደገና ችግር አስከትሏል። በትልልቅ ክሮሞሶምች (ማለትም፣ መረጃ ማግኘት የምንፈልግበት) ላይ SNPዎችን የማቀናበር ዋጋ በ10 ጊዜ ያህል ቀንሷል። ብዙ, ግን በቂ አይደለም.

በትናንሽ ክፍሎች ብንከፋፍለውስ?

ምን ተማርኩኝ: በጭራሽ 2,5 ሚሊዮን ክፍልፋዮችን ለመስራት አይሞክሩ ።

ሁሉንም ለመውጣት ወሰንኩ እና እያንዳንዱን SNP ከፋፍያለሁ። ይህ ክፍልፋዮች እኩል መጠን ያላቸው መሆናቸውን አረጋግጧል. መጥፎ ሀሳብ ነበር።. ሙጫ ተጠቀምኩ እና ንጹህ መስመር ጨምሬያለሁ partition_by = 'snp'. ተግባሩ ተጀምሮ መፈፀም ጀመረ። ከአንድ ቀን በኋላ በ S3 ላይ የተጻፈ ምንም ነገር እንደሌለ ፈትሼ አየሁ፣ ስለዚህ ተግባሩን ገደልኩት። ማጣበቂያ መካከለኛ ፋይሎችን በS3 ውስጥ ወደተደበቀ ቦታ፣ ብዙ ፋይሎች፣ ምናልባትም ሁለት ሚሊዮን የሚሆኑ ፋይሎችን እየጻፈ ይመስላል። በዚህ ምክንያት ስህተቴ ከአንድ ሺህ ዶላር በላይ ስለፈጀ መካሪዬን አላስደሰተም።

መከፋፈል + መደርደር

ምን ተማርኩኝስፓርክን ማስተካከል አሁንም አስቸጋሪ ነው።

ለመከፋፈል ያደረኩት የመጨረሻ ሙከራ ክሮሞሶሞችን መከፋፈል እና እያንዳንዱን ክፍል መደርደርን ያካትታል። በንድፈ ሀሳብ፣ ይህ እያንዳንዱን ጥያቄ ያፋጥነዋል ምክንያቱም የሚፈለገው የ SNP ውሂብ በተወሰነ ክልል ውስጥ በጥቂት የፓርኬት ቁርጥራጮች ውስጥ መሆን ነበረበት። እንደ አለመታደል ሆኖ የተከፋፈለ ውሂብ እንኳን መደርደር ከባድ ስራ ሆኖ ተገኝቷል። በዚህ ምክንያት ወደ 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')
  )

...ነገር ግን ተግባሩ አሁንም አልተጠናቀቀም። በተለያየ መንገድ አዋቀርኩት፡ ለእያንዳንዱ መጠይቅ አስፈፃሚ የማህደረ ትውስታ ድልድልን ጨምሯል፣ ከፍተኛ መጠን ያለው ማህደረ ትውስታ ያለው ኖዶች ተጠቅሟል፣ የስርጭት ተለዋዋጮችን (የስርጭት ተለዋዋጮችን) ተጠቀምኩ፣ ግን በእያንዳንዱ ጊዜ እነዚህ ግማሽ መለኪያዎች ሲሆኑ እና ቀስ በቀስ አስፈፃሚዎቹ ጀመሩ። ሁሉም ነገር እስኪቆም ድረስ ውድቀት.

የበለጠ ፈጣሪ እየሆንኩ ነው።

ምን ተማርኩኝ: አንዳንድ ጊዜ ልዩ ውሂብ ልዩ መፍትሄዎችን ይፈልጋል.

እያንዳንዱ SNP የቦታ ዋጋ አለው። ይህ በክሮሞሶም ውስጥ ካሉት የመሠረት ብዛት ጋር የሚዛመድ ቁጥር ነው። ይህ የእኛን ውሂብ ለማደራጀት ጥሩ እና ተፈጥሯዊ መንገድ ነው። መጀመሪያ ላይ በእያንዳንዱ ክሮሞሶም ክልሎች መከፋፈል ፈለግሁ። ለምሳሌ ከ1-2000፣ 2001-4000፣ ወዘተ. ነገር ግን ችግሩ SNPs በክሮሞሶም ውስጥ እኩል ስላልተከፋፈሉ የቡድን መጠኖች በጣም ይለያያሉ.

AWK እና R በመጠቀም 25 ቴባ በመተንተን ላይ

በውጤቱም, ወደ መደቦች ክፍፍል (ደረጃ) መጣሁ. አስቀድሞ የወረደውን ውሂብ በመጠቀም፣ ልዩ የሆኑ 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()

በመጀመሪያ በስፓርክ ይሞክሩ

ምን ተማርኩኝስፓርክ ማሰባሰብ ፈጣን ነው ነገርግን መከፋፈል አሁንም ውድ ነው።

ይህንን ትንሽ (2,5 ሚሊዮን ረድፎች) የውሂብ ፍሬም ወደ ስፓርክ ለማንበብ፣ ከጥሬው መረጃ ጋር በማጣመር እና ከዚያም በአዲስ በተጨመረው አምድ ለመከፋፈል ፈለግሁ። 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.

እሱን ለመሞከር የ Bash ስክሪፕት ጻፍኩኝ። ከታሸጉት TSVs አንዱን አውርደዋል፣ ከዚያም ተጠቅመው አወጡት። 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 ሜባ ማህደረ ትውስታ እየተጠቀምኩ እንደሆነ ታወቀ። ችግሩን ለመፍታት እና ብዙ ገንዘብ ላለማጣት, ስራውን እንዴት ማመሳሰል እንዳለብን ማወቅ ነበረብን. እንደ እድል ሆኖ, ፍጹም በሚያስደንቅ መጽሐፍ ውስጥ የውሂብ ሳይንስ በትእዛዝ መስመር በጄሮን Janssens ትይዩ ላይ አንድ ምዕራፍ አገኘሁ። ከእሱ የተማርኩት gnu parallel, በዩኒክስ ውስጥ ባለ ብዙ ክርችቶችን ለመተግበር በጣም ተለዋዋጭ ዘዴ.

AWK እና R በመጠቀም 25 ቴባ በመተንተን ላይ
አዲሱን ሂደት በመጠቀም ክፍፍሉን ስጀምር ሁሉም ነገር ጥሩ ነበር ነገር ግን አሁንም ማነቆ ነበር - S3 ነገሮችን ወደ ዲስክ ማውረድ በጣም ፈጣን እና ሙሉ በሙሉ ትይዩ አልነበረም። ይህንን ለማስተካከል ይህን አደረግሁ፡-

  1. በዲስክ ላይ መካከለኛ ማከማቻን ሙሉ በሙሉ በማስወገድ የ S3 ማውረድ ደረጃን በቀጥታ በቧንቧ ውስጥ መተግበር እንደሚቻል ተረድቻለሁ። ይህ ማለት ጥሬ መረጃን ወደ ዲስክ ከመፃፍ መቆጠብ እና በትንሹም ቢሆን መጠቀም እችላለሁ እና በ AWS ላይ ማከማቻ ርካሽ ነው።
  2. ቡድን aws configure set default.s3.max_concurrent_requests 50 AWS CLI የሚጠቀመውን የክሮች ብዛት በእጅጉ ጨምሯል (በነባሪ 10)።
  3. ለኔትወርክ ፍጥነት ወደተመቻቸ የ EC2 ምሳሌ ቀይሬያለሁ፣ በስሙ n በሚለው ፊደል። n- ምሳሌዎችን በሚጠቀሙበት ጊዜ የማቀነባበሪያ ኃይልን ማጣት የመጫኛ ፍጥነት መጨመር ከማካካሻ በላይ እንደሆነ ተረድቻለሁ. ለአብዛኛዎቹ ተግባራት c5n.4xl እጠቀማለሁ።
  4. ተለውጧል 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 ቴራባይት ፓኬጅ ማካሄድ ችያለሁ።

ይህ ትዊተር 'TSV'ን መጥቀስ ነበረበት። ወዮ።

አዲስ የተተነተነ ውሂብ በመጠቀም

ምን ተማርኩኝስፓርክ ያልተጨመቀ ውሂብን ይወዳል እና ክፍልፋዮችን ማዋሃድ አይወድም።

አሁን ውሂቡ በS3 ውስጥ ባልታሸገ (አንብብ፡ የተጋራ) እና በከፊል በታዘዘ ቅርጸት ነበር፣ እና እንደገና ወደ ስፓርክ ልመለስ እችላለሁ። አንድ አስገራሚ ነገር ጠበቀኝ፡ የፈለግኩትን ማሳካት ተስኖኝ ነበር! መረጃው እንዴት እንደተከፋፈለ በትክክል ለ Spark መንገር በጣም ከባድ ነበር። እና ይህን ሳደርግ እንኳን በጣም ብዙ ክፍልፋዮች (95 ሺህ) እንደነበሩ እና እኔ በተጠቀምኩበት ጊዜ ታየ coalesce ቁጥራቸውን ወደ ምክንያታዊ ገደቦች ቀንሰዋል፣ ይህ የእኔን ክፍፍል አጠፋው። ይህ ሊስተካከል እንደሚችል እርግጠኛ ነኝ፣ ግን ከሁለት ቀናት ፍለጋ በኋላ መፍትሄ አላገኘሁም። ምንም እንኳን ትንሽ ጊዜ ቢፈጅም እና የእኔ የተከፋፈሉ የፓርኬት ፋይሎቼ በጣም ትንሽ አይደሉም (~ 200 ኪ.ባ.) በመጨረሻ በስፓርክ ውስጥ ያሉትን ሁሉንም ተግባራት ጨረስኩ። ይሁን እንጂ መረጃው በሚፈለገው ቦታ ነበር.

AWK እና R በመጠቀም 25 ቴባ በመተንተን ላይ
በጣም ትንሽ እና ያልተስተካከለ, ድንቅ!

የአካባቢ የስፓርክ መጠይቆችን በመሞከር ላይ

ምን ተማርኩኝቀላል ችግሮችን በሚፈታበት ጊዜ ስፓርክ ከመጠን በላይ ከመጠን በላይ ነው.

መረጃውን በብልህነት በማውረድ ፍጥነቱን መሞከር ችያለሁ። አካባቢያዊ የስፓርክ አገልጋይን ለማስኬድ የR ስክሪፕት ያዋቅሩ እና ከዚያ ከተጠቀሰው የፓርኬት ቡድን ማከማቻ (ቢን) የስፓርክ ዳታ ፍሬም ጫኑ። ሁሉንም ውሂብ ለመጫን ሞከርኩ ነገር ግን 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 ጂቢ በላይ ሚሞሪ ስመድብ።

ወደ AWK ተመለስ

ምን ተማርኩኝበAWK ውስጥ ያሉ ተጓዳኝ ድርድሮች በጣም ቀልጣፋ ናቸው።

ከፍተኛ ፍጥነት ማሳካት እንደምችል ተገነዘብኩ። ያንን በሚያስደንቅ ሁኔታ አስታወስኩት AWK አጋዥ ስልጠና በብሩስ ባርኔት ስለ አንድ ጥሩ ባህሪ አነባለሁ "ተባባሪ ድርድሮች" በመሠረቱ, እነዚህ ቁልፍ-እሴት ጥንዶች ናቸው, እሱም በሆነ ምክንያት በ AWK ውስጥ በተለየ መንገድ ተጠርቷል, እና ስለዚህ በሆነ መንገድ ስለእነሱ ብዙ አላሰብኩም ነበር. ሮማን Cheplyaka “ተያያዥ ድርድሮች” የሚለው ቃል “ቁልፍ-እሴት ጥንድ” ከሚለው ቃል በጣም የቆየ መሆኑን አስታውሰዋል። አንተም ብትሆን በ Google Ngram ውስጥ ቁልፍ-እሴቱን ይፈልጉ, ይህን ቃል እዚያ አያዩትም, ግን ተባባሪ ድርድሮችን ያገኛሉ! በተጨማሪም “ቁልፍ-እሴት ጥንድ” ብዙውን ጊዜ ከመረጃ ቋቶች ጋር የተቆራኘ ነው፣ ስለዚህ ከሃሽማፕ ጋር ማነፃፀር የበለጠ ምክንያታዊ ነው። ስፓርክን ሳልጠቀም የእኔን 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 ቡድን (ቢን) ጫነ፣ የመጀመሪያውን አምድ (የኤስኤንፒ ስም) ለአዛማጅ ድርድር ቁልፍ አድርገው ያቀናብሩት። bin እና ሁለተኛው እሴት (ቡድን) እንደ እሴቱ. ከዚያም በብሎክ ውስጥ { }, በሁሉም የዋናው ፋይል መስመሮች ላይ የሚፈጸመው, እያንዳንዱ መስመር ወደ የውጤት ፋይል ይላካል, እሱም እንደ ቡድኑ (ቢን) ልዩ ስም ይቀበላል. ..._bin_"bin[$1]"_....

ተለዋዋጮች batch_num и chunk_id የዘር ሁኔታን በማስወገድ እና እያንዳንዱ የማስፈጸሚያ ክር እየሮጠ በቧንቧው የቀረበውን መረጃ በማዛመድ parallel፣ ለራሱ ልዩ ፋይል ፃፈ።

ከቀድሞው የ AWK ሙከራዬ የተረፈውን ሁሉንም ጥሬ መረጃ ወደ ክሮሞሶምች አቃፊዎች ስለበተንኩ አሁን አንድ ክሮሞዞምን በአንድ ጊዜ ለማስኬድ እና ጥልቅ የተከፋፈለ መረጃን ወደ S3 ሌላ Bash ስክሪፕት ፃፍኩ።

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 ሐ catእና ከዚያ ወደ ውጭ ለመላክ ይልካቸዋል.

በ R ውስጥ ማሰራጨት?

ምን ተማርኩኝ: ማነጋገር ትችላለህ stdin и stdout ከ R ስክሪፕት, እና ስለዚህ በቧንቧ ውስጥ ይጠቀሙበት.

ይህን መስመር በእርስዎ ባሽ ስክሪፕት ላይ አስተውለው ይሆናል፡- ...cat chunked/*_bin_{}_*.csv | ./upload_as_rds.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 ልክ እንደ ጁኒየር የፓርኬት ስሪት የሆነ ነገር ነው፣ ያለ የድምጽ ማጉያ ማከማቻ።

የባሽ ስክሪፕቱን ከጨረስኩ በኋላ ጥቅል አገኘሁ .rdsቀልጣፋ መጭመቂያ እና አብሮ የተሰሩ አይነቶችን እንድጠቀም የፈቀደልኝ በ S3 ውስጥ የሚገኙ ፋይሎች።

ብሬክ R ቢጠቀሙም, ሁሉም ነገር በጣም በፍጥነት ይሰራል. ምንም አያስደንቅም፣ መረጃን የሚያነቡ እና የሚጽፉ የ R ክፍሎች በጣም የተመቻቹ ናቸው። በአንድ መካከለኛ መጠን ያለው ክሮሞሶም ላይ ከተፈተነ በኋላ፣ ስራው በC5n.4xl ምሳሌ በሁለት ሰዓታት ውስጥ ተጠናቀቀ።

S3 ገደቦች

ምን ተማርኩኝለስማርት መንገድ አተገባበር ምስጋና ይግባውና S3 ብዙ ፋይሎችን ማስተናገድ ይችላል።

S3 ወደ እሱ የተላለፉትን ብዙ ፋይሎች ማስተናገድ ይችል እንደሆነ ተጨንቄ ነበር። የፋይል ስሞች ትርጉም እንዲኖራቸው ማድረግ እችላለሁ፣ ግን S3 እንዴት ይፈልጋቸዋል?

AWK እና R በመጠቀም 25 ቴባ በመተንተን ላይ
በ S3 ውስጥ ያሉ ማህደሮች ለእይታ ብቻ ናቸው, በእውነቱ ስርዓቱ ለምልክቱ ፍላጎት የለውም /. ከS3 FAQ ገጽ።

ኤስ 3 ወደ አንድ የተወሰነ ፋይል የሚወስደውን መንገድ እንደ ሃሽ ሠንጠረዥ ወይም በሰነድ ላይ የተመሰረተ ዳታቤዝ ውስጥ እንደ ቀላል ቁልፍ የሚወክል ይመስላል። አንድ ባልዲ እንደ ጠረጴዛ ሊታሰብ ይችላል, እና ፋይሎች በዚያ ሰንጠረዥ ውስጥ እንደ መዝገቦች ሊቆጠሩ ይችላሉ.

በአማዞን ላይ ትርፍ ለማግኘት ፍጥነት እና ቅልጥፍና አስፈላጊ ስለሆኑ ይህ ቁልፍ-እንደ-ፋይል-መንገድ ስርዓት በጣም እየተሻሻለ መምጣቱ ምንም አያስደንቅም. ሚዛን ለማግኘት ሞከርኩ፡ ብዙ ጥያቄ እንዳላቀርብ፣ ነገር ግን ጥያቄዎቹ በፍጥነት እንዲፈጸሙ። ወደ 20 ሺህ የሚጠጉ የቢን ፋይሎችን መሥራት በጣም ጥሩ እንደሆነ ተገለጠ። እኔ እንደማስበው ማመቻቸትን ከቀጠልን የፍጥነት መጨመርን ማሳካት እንችላለን (ለምሳሌ ልዩ ባልዲ ለውሂብ ብቻ በማዘጋጀት የመፈለጊያ ጠረጴዛውን መጠን በመቀነስ)። ግን ለተጨማሪ ሙከራዎች ጊዜ ወይም ገንዘብ አልነበረም።

ስለ መስቀል ተኳሃኝነትስ?

የተማርኩት፡ ለባከነ ጊዜ ቁጥር አንድ ምክንያት የማከማቻ ዘዴህን ያለጊዜው ማመቻቸት ነው።

በዚህ ጊዜ፣ እራስዎን መጠየቅ በጣም አስፈላጊ ነው፡- “ለምን የባለቤትነት ፋይል ፎርማት ይጠቀሙ?” ምክንያቱ የመጫኛ ፍጥነት (የጂዚፕ CSV ፋይሎች ለመጫን 7 ጊዜ ወስደዋል) እና ከስራ ፍሰቶቻችን ጋር በመስማማት ላይ ነው። R በቀላሉ የፓርኬትን (ወይም ቀስት) ፋይሎችን ያለ Spark ጭነት መጫን ከቻለ እንደገና ላስብበት እችላለሁ። በእኛ ቤተ ሙከራ ውስጥ ያለ ሁሉም ሰው R ይጠቀማል፣ እና ውሂቡን ወደ ሌላ ቅርጸት መለወጥ ካስፈለገኝ ዋናው የጽሑፍ መረጃ አሁንም አለኝ፣ ስለዚህ የቧንቧ መስመርን እንደገና ማስኬድ እችላለሁ።

የሥራ ክፍፍል

ምን ተማርኩኝ: ስራዎችን በእጅ ለማመቻቸት አይሞክሩ, ኮምፒዩተሩ እንዲሰራ ያድርጉት.

በአንድ ክሮሞሶም ላይ ያለውን የስራ ሂደት አርምቻለሁ፣ አሁን ሁሉንም ሌሎች መረጃዎች ማሄድ አለብኝ።
ለለውጥ ብዙ የ 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 በመጠቀም አንድ ሺህ shuffles ውስጥ ሮጥ እና ምርጡን መረጥኩ.

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>>

እንሸከም!

ምን ተማርኩኝለአጠቃቀም ቀላል እና ተለዋዋጭነት ሲባል ኤፒአይ ቀላል መሆን አለበት።

በመጨረሻም መረጃውን በትክክለኛው ቦታ እና ቅጽ ላይ አግኝቻለሁ. የቀረው ሁሉ ለሥራ ባልደረቦቼ ቀላል እንዲሆን በተቻለ መጠን መረጃን የመጠቀም ሂደቱን ቀላል ማድረግ ነበር። ጥያቄዎችን ለመፍጠር ቀላል ኤፒአይ ለመስራት ፈልጌ ነበር። ወደፊት ከ ለመቀየር ከወሰንኩ .rds ወደ Parquet ፋይሎች, ይህ ለእኔ ችግር ሊሆን ይገባል, ለሥራ ባልደረቦቼ አይደለም. ለዚህም ውስጣዊ R ጥቅል ለመሥራት ወሰንኩ.

በአንድ ተግባር ዙሪያ የተደራጁ ጥቂት የውሂብ መዳረሻ ተግባራትን የያዘ በጣም ቀላል ጥቅል ይገንቡ እና ይመዝግቡ get_snp. ለባልደረቦቼም ድህረ ገጽ ሠራሁ pkgdown, ስለዚህ በቀላሉ ምሳሌዎችን እና ሰነዶችን ማየት ይችላሉ.

AWK እና R በመጠቀም 25 ቴባ በመተንተን ላይ

ብልጥ መሸጎጫ

ምን ተማርኩኝውሂብዎ በደንብ ከተዘጋጀ መሸጎጫ ቀላል ይሆናል!

ከዋና ዋና የስራ ፍሰቶች አንዱ ተመሳሳይ የትንታኔ ሞዴል በ 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. ይህ በቡድን (ቢን) ውስጥ ያሉ የሁሉም ልዩ SNPዎች ስብስብ ነው፣ ይህም ካለፈው መጠይቅ ላይ ያለዎትን መረጃ በፍጥነት እንዲያረጋግጡ ያስችልዎታል። እንዲሁም በዚህ ኮድ ሁሉንም SNPs በቡድን (ቢን) ውስጥ ማዞር ቀላል ያደርገዋል።

# 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 ጥያቄ በአማካይ ከ 0,1 ሰከንድ ያነሰ ጊዜ ይወስዳል, እና የውሂብ አጠቃቀም እንዲሁ ነው. ዝቅተኛ ለ S3 ወጪዎች ኦቾሎኒ ናቸው.

መደምደሚያ

ይህ ጽሑፍ በጭራሽ መመሪያ አይደለም. መፍትሄው ግለሰባዊ ሆኖ ተገኝቷል, እና በእርግጠኝነት ጥሩ አይደለም. ይልቁንም የጉዞ ማስታወሻ ነው። ሌሎች እንዲረዱት እፈልጋለሁ እንደዚህ ያሉ ውሳኔዎች በጭንቅላቱ ውስጥ ሙሉ በሙሉ አልተፈጠሩም ፣ እነሱ የሙከራ እና የስህተት ውጤቶች ናቸው። እንዲሁም የውሂብ ሳይንቲስት እየፈለጉ ከሆነ እነዚህን መሳሪያዎች በብቃት መጠቀም ልምድ እንደሚያስፈልግ እና ልምድ ገንዘብ እንደሚያስወጣ ያስታውሱ። ለመክፈል የሚያስችል አቅም በማግኘቴ ደስተኛ ነኝ፣ ነገር ግን ከኔ በተሻለ ተመሳሳይ ስራ የሚሰሩ ብዙ ሰዎች በገንዘብ እጦት ምክንያት የመሞከር እድል ፈጽሞ አይኖራቸውም።

ትላልቅ የመረጃ መሳሪያዎች ሁለገብ ናቸው። ጊዜ ካሎት፣ ዘመናዊ ውሂብን ማፅዳትን፣ ማከማቻን እና የማስወጫ ቴክኒኮችን በመጠቀም ፈጣን መፍትሄ በእርግጠኝነት መጻፍ ይችላሉ። በመጨረሻ ወደ ወጪ-ጥቅማ ጥቅም ትንተና ይመጣል።

የተማርኩት፡-

  • በአንድ ጊዜ 25 ቲቢን ለመተንተን ርካሽ መንገድ የለም;
  • በፓርኬትዎ ፋይሎች እና በድርጅታቸው መጠን ይጠንቀቁ;
  • በስፓርክ ውስጥ ያሉ ክፍፍሎች ሚዛናዊ መሆን አለባቸው;
  • በአጠቃላይ 2,5 ሚሊዮን ክፍልፋዮችን ለመሥራት በጭራሽ አይሞክሩ;
  • ስፓርክን እንደማዘጋጀት መደርደር አሁንም አስቸጋሪ ነው;
  • አንዳንድ ጊዜ ልዩ ውሂብ ልዩ መፍትሄዎችን ይፈልጋል;
  • ስፓርክ ማሰባሰብ ፈጣን ነው, ግን ክፍፍል አሁንም ውድ ነው;
  • መሠረታዊ ነገሮችን ሲያስተምሩ አትተኛ፣ አንድ ሰው ምናልባት በ1980ዎቹ ውስጥ ችግርህን ፈትቶት ሊሆን ይችላል።
  • gnu parallel - ይህ አስማታዊ ነገር ነው, ሁሉም ሰው ሊጠቀምበት ይገባል;
  • ስፓርክ ያልተጨመቀ ውሂብን ይወዳል እና ክፍልፋዮችን ማዋሃድ አይወድም;
  • ቀላል ችግሮችን በሚፈታበት ጊዜ ስፓርክ ከመጠን በላይ ከመጠን በላይ ነው;
  • የAWK ተባባሪ ድርድሮች በጣም ቀልጣፋ ናቸው;
  • ማነጋገር ይችላሉ። stdin и stdout ከ R ስክሪፕት, እና ስለዚህ በቧንቧ ውስጥ ይጠቀሙበት;
  • ለዘመናዊ መንገድ አተገባበር ምስጋና ይግባውና S3 ብዙ ፋይሎችን ማካሄድ ይችላል;
  • ጊዜን ለማባከን ዋናው ምክንያት የማከማቻ ዘዴዎን ያለጊዜው ማመቻቸት ነው;
  • ስራዎችን በእጅ ለማመቻቸት አይሞክሩ, ኮምፒዩተሩ እንዲሰራ ያድርጉት;
  • ለአጠቃቀም ቀላል እና ተለዋዋጭነት ሲባል ኤፒአይ ቀላል መሆን አለበት;
  • የእርስዎ ውሂብ በደንብ ከተዘጋጀ መሸጎጫ ቀላል ይሆናል!

ምንጭ: hab.com

አስተያየት ያክሉ