როგორ წავიკითხოთ ეს სტატია: ბოდიშს ვიხდი, რომ ტექსტი ასეთი გრძელი და ქაოტურია. დროის დაზოგვის მიზნით, მე ვიწყებ თითოეულ თავს "რა ვისწავლე" შესავალით, რომელიც აჯამებს თავის არსს ერთ ან ორ წინადადებაში.

"უბრალოდ მაჩვენე გამოსავალი!" თუ უბრალოდ გსურთ ნახოთ, საიდან მოვედი, გადადით თავში „გახდი უფრო გამომგონებელი“, მაგრამ ვფიქრობ, რომ წარუმატებლობის შესახებ წაკითხვა უფრო საინტერესო და სასარგებლოა.

მე ახლახან დამევალა დამეყენებინა პროცესი დიდი მოცულობის ნედლეული დნმ-ის თანმიმდევრობის (ტექნიკურად SNP ჩიპი) დამუშავებისთვის. საჭირო იყო მონაცემთა სწრაფად მოპოვება მოცემული გენეტიკური მდებარეობის შესახებ (ე.წ. SNP) შემდგომი მოდელირებისთვის და სხვა ამოცანებისთვის. R-ისა და AWK-ის გამოყენებით შევძელი მონაცემთა ბუნებრივი გზით გაწმენდა და ორგანიზება, რაც მნიშვნელოვნად აჩქარებს შეკითხვის დამუშავებას. ეს ჩემთვის ადვილი არ იყო და ბევრ გამეორებას მოითხოვდა. ეს სტატია დაგეხმარებათ თავიდან აიცილოთ ჩემი ზოგიერთი შეცდომა და გაჩვენოთ, რა დავამთავრე.

პირველი, რამდენიმე შესავალი ახსნა.

მონაცემთა

ჩვენმა უნივერსიტეტის გენეტიკური ინფორმაციის დამუშავების ცენტრმა მოგვაწოდა მონაცემები 25 ტბ TSV-ის სახით. მე მივიღე ისინი დაყოფილი 5 პაკეტად, შეკუმშული Gzip-ით, რომელთაგან თითოეული შეიცავდა დაახლოებით 240 ოთხ გიგაბაიტიან ფაილს. თითოეული მწკრივი შეიცავდა მონაცემებს ერთი SNP-ისთვის ერთი ინდივიდისგან. საერთო ჯამში გადაცემულია ~2,5 მილიონი SNP-ის და ~60 ათასი ადამიანის შესახებ მონაცემები. SNP ინფორმაციის გარდა, ფაილები შეიცავდა უამრავ სვეტს რიცხვებით, რომლებიც ასახავს სხვადასხვა მახასიათებლებს, როგორიცაა წაკითხვის ინტენსივობა, სხვადასხვა ალელების სიხშირე და ა.შ. საერთო ჯამში იყო დაახლოებით 30 სვეტი უნიკალური მნიშვნელობებით.

მიზანი

როგორც მონაცემთა მართვის ნებისმიერ პროექტში, ყველაზე მნიშვნელოვანი იყო იმის დადგენა, თუ როგორ იქნებოდა გამოყენებული მონაცემები. Ამ შემთხვევაში ჩვენ ძირითადად შევარჩევთ მოდელებსა და სამუშაო პროცესებს SNP-ისთვის SNP-ზე დაყრდნობით. ანუ, ჩვენ დაგვჭირდება მხოლოდ მონაცემები ერთ SNP-ზე ერთდროულად. მე უნდა მესწავლა, როგორ აღმედგინა ყველა ჩანაწერი, რომელიც დაკავშირებულია 2,5 მილიონი SNP-დან ერთ-ერთთან, რაც შეიძლება მარტივად, სწრაფად და იაფად.

როგორ არ უნდა გავაკეთოთ ეს

შესაფერისი კლიშეს ციტირება:

მე ათასჯერ არ დავმარცხდი, უბრალოდ აღმოვაჩინე ათასი გზა, რათა თავიდან ავიცილოთ მონაცემთა კრებულის გაანალიზება შეკითხვისთვის მოსახერხებელი ფორმატში.

პირველი სცადეთ

რა ვისწავლე: არ არსებობს იაფი გზა 25 ტბ ერთდროულად გასაანალიზებლად.

ვანდერბილტის უნივერსიტეტში „დიდი მონაცემთა დამუშავების გაფართოებული მეთოდები“ კურსის გავლის შემდეგ, დარწმუნებული ვიყავი, რომ ეს ხრიკი ჩანთაში იყო. სავარაუდოდ, ერთი ან ორი საათი დასჭირდება Hive სერვერის დაყენებას, რათა გაიაროს ყველა მონაცემი და მოახსენოს შედეგი. ვინაიდან ჩვენი მონაცემები ინახება AWS S3-ში, მე გამოვიყენე სერვისი Athena, რომელიც საშუალებას გაძლევთ გამოიყენოთ Hive SQL მოთხოვნები S3 მონაცემებზე. თქვენ არ გჭირდებათ Hive კლასტერის დაყენება/ამაღლება და ასევე იხდით მხოლოდ იმ მონაცემებს, რომლებსაც ეძებთ.

მას შემდეგ რაც ათენას ვაჩვენე ჩემი მონაცემები და მისი ფორმატი, ჩავატარე რამდენიმე ტესტი ასეთი მოთხოვნებით:

select * from intensityData limit 10;

და სწრაფად მიიღო კარგად სტრუქტურირებული შედეგები. მზადაა.

სანამ ჩვენ ვცდილობდით მონაცემების გამოყენებაში მუშაობაში...

მე მთხოვეს ამეღო ყველა SNP ინფორმაცია მოდელის შესამოწმებლად. მე ჩავატარე შეკითხვა:

select * from intensityData 
where snp = 'rs123456';

...და დაიწყო ლოდინი. რვა წუთის შემდეგ და 4 ტბ-ზე მეტი მოთხოვნილი მონაცემების შემდეგ მივიღე შედეგი. Athena ანაზღაურებს ნაპოვნი მონაცემების მოცულობის მიხედვით, $5 ტერაბაიტზე. ასე რომ, ეს ერთი მოთხოვნა ღირდა $20 და რვა წუთი ლოდინი. მოდელის ყველა მონაცემზე გასაშვებად მოგვიწია 38 წელი ლოდინი და 50 მილიონი დოლარის გადახდა, ცხადია, ეს ჩვენთვის არ იყო შესაფერისი.

საჭირო იყო პარკეტის გამოყენება...

რა ვისწავლე: ფრთხილად იყავით თქვენი პარკეტის ფაილების ზომასთან და მათ ორგანიზაციასთან.

მე პირველად ვცადე სიტუაციის გამოსწორება ყველა TSV-ის კონვერტაციით პარკეტის ფაილები. ისინი მოსახერხებელია მონაცემთა დიდ ნაკრებებთან მუშაობისთვის, რადგან მათში არსებული ინფორმაცია ინახება სვეტის სახით: თითოეული სვეტი დევს თავის მეხსიერებაში/დისკის სეგმენტში, ტექსტური ფაილებისგან განსხვავებით, რომლებშიც რიგები შეიცავს თითოეული სვეტის ელემენტებს. და თუ რაიმეს პოვნა გჭირდებათ, უბრალოდ წაიკითხეთ საჭირო სვეტი. გარდა ამისა, თითოეული ფაილი ინახავს მნიშვნელობების დიაპაზონს სვეტში, ასე რომ, თუ მნიშვნელობა, რომელსაც ეძებთ, არ არის სვეტის დიაპაზონში, Spark არ დაკარგავს დროს მთელი ფაილის სკანირებაზე.

მე შევასრულე მარტივი დავალება AWS წებო ჩვენი TSV-ების პარკეტად გადაქცევა და ახალი ფაილები Athena-ში ჩაშვება. დაახლოებით 5 საათი დასჭირდა. მაგრამ როდესაც მე შევასრულე მოთხოვნა, დაახლოებით იგივე დრო და ცოტა ნაკლები ფული დამჭირდა დასრულებას. ფაქტია, რომ Spark-მა, რომელიც ცდილობდა ამოცანის ოპტიმიზაციას, უბრალოდ ამოშალა ერთი TSV ნაჭერი და მოათავსა პარკეტის საკუთარ ნაჭერში. და იმის გამო, რომ თითოეული ნაწილი საკმარისად დიდი იყო, რომ შეიცავდეს მრავალი ადამიანის მთლიან ჩანაწერს, თითოეული ფაილი შეიცავდა ყველა SNP-ს, ამიტომ Spark-ს უნდა გაეხსნა ყველა ფაილი საჭირო ინფორმაციის გამოსატანად.

საინტერესოა, რომ პარკეტის ნაგულისხმევი (და რეკომენდებული) შეკუმშვის ტიპი, snappy, არ არის გაყოფილი. აქედან გამომდინარე, თითოეული შემსრულებელი ჩერდებოდა 3,5 GB სრული მონაცემთა პაკეტის ამოხსნისა და ჩამოტვირთვის ამოცანაზე.

მოდით გავიგოთ პრობლემა

რა ვისწავლე: დახარისხება რთულია, მით უმეტეს, თუ მონაცემები განაწილებულია.

მომეჩვენა, რომ ახლა მივხვდი პრობლემის არსს. მე მხოლოდ მონაცემების დალაგება მჭირდებოდა SNP სვეტის მიხედვით და არა ადამიანების მიხედვით. შემდეგ რამდენიმე SNP შეინახება ცალკეულ მონაცემთა ბლოკში, შემდეგ კი პარკეტის "ჭკვიანი" ფუნქცია "ღია მხოლოდ იმ შემთხვევაში, თუ მნიშვნელობა არის დიაპაზონში" გამოჩნდება მთელი თავისი დიდებით. სამწუხაროდ, კლასტერზე მიმოფანტული მილიარდობით მწკრივის დალაგება რთული ამოცანა აღმოჩნდა.

კოლეჯში ვატარებ ალგორითმების გაკვეთილს: ”აჰ, არავის აინტერესებს ყველა ამ დახარისხების ალგორითმის გამოთვლითი სირთულე”

ვცდილობ დაალაგო სვეტი 20 ტბ-ში #ნაპერწკალი ცხრილი: "რატომ ჭირდება ამას ამდენი დრო?" #მონაცემთა მეცნიერება ბრძოლას.

- ნიკ სტრეიერი (@NicholasStrayer) მარტი 11, 2019

AWS-ს ნამდვილად არ სურს თანხის დაბრუნება „მე ვარ ყურადღების მიღმა სტუდენტი“ მიზეზის გამო. მას შემდეგ, რაც Amazon Glue-ზე დალაგება გავიქეცი, ის 2 დღე მუშაობდა და ჩამოვარდა.

რაც შეეხება დაყოფას?

რა ვისწავლე: Spark-ში ტიხრები უნდა იყოს დაბალანსებული.

შემდეგ გამიჩნდა ქრომოსომებში მონაცემების დაყოფის იდეა. არის 23 მათგანი (და კიდევ რამდენიმე, თუ გაითვალისწინებთ მიტოქონდრიულ დნმ-ს და დაუზუსტებელ რეგიონებს).
ეს საშუალებას მოგცემთ დაყოთ მონაცემები პატარა ნაწილებად. თუ თქვენ დაამატებთ მხოლოდ ერთ ხაზს Spark ექსპორტის ფუნქციას Glue სკრიპტში partition_by = "chr", მაშინ მონაცემები უნდა დაიყოს თაიგულებად.

გენომი შედგება მრავალი ფრაგმენტისგან, რომელსაც ქრომოსომა ეწოდება.

სამწუხაროდ, არ მუშაობდა. ქრომოსომებს აქვთ სხვადასხვა ზომები, რაც ნიშნავს ინფორმაციის სხვადასხვა რაოდენობას. ეს ნიშნავს, რომ დავალებები, რომლებიც სპარკმა გაუგზავნა მუშებს, არ იყო დაბალანსებული და ნელა სრულდებოდა, რადგან ზოგიერთი კვანძი ადრე დასრულდა და უმოქმედო იყო. თუმცა, დავალებები შესრულდა. მაგრამ ერთი SNP-ის მოთხოვნისას, დისბალანსმა კვლავ პრობლემები გამოიწვია. უფრო დიდ ქრომოსომებზე SNP-ების დამუშავების ღირებულება (ანუ სადაც გვინდა მონაცემების მიღება) მხოლოდ 10-ჯერ შემცირდა. ბევრი, მაგრამ არა საკმარისი.

რა მოხდება, თუ მას კიდევ უფრო პატარა ნაწილებად დავყოფთ?

რა ვისწავლე: არასოდეს სცადოთ 2,5 მილიონი დანაყოფის გაკეთება საერთოდ.

მე გადავწყვიტე გამეკეთებინა ყველაფერი და გავანაწილე თითოეული SNP. ეს უზრუნველყოფდა, რომ დანაყოფები თანაბარი ზომის იყო. ეს იყო ცუდი იდეა. გამოვიყენე წებო და დავამატე უდანაშაულო ხაზი partition_by = 'snp'. დავალება დაიწყო და დაიწყო შესრულება. ერთი დღის შემდეგ შევამოწმე და დავინახე, რომ S3-ზე ჯერ კიდევ არაფერი ეწერა და დავალება მოვკალი. როგორც ჩანს, Glue წერდა შუალედურ ფაილებს S3-ში დამალულ ადგილას, უამრავ ფაილს, შესაძლოა, რამდენიმე მილიონს. შედეგად, ჩემი შეცდომა ათას დოლარზე მეტი დაჯდა და არ მოეწონა ჩემს მენტორს.

დაყოფა + დახარისხება

რა ვისწავლე: დახარისხება ჯერ კიდევ რთულია, ისევე როგორც Spark-ის ტიუნინგი.

დაყოფის ჩემი ბოლო მცდელობა მოიცავდა ქრომოსომების დაყოფას და შემდეგ თითოეული დანაყოფის დახარისხებას. თეორიულად, ეს დააჩქარებს თითოეულ შეკითხვას, რადგან სასურველი 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')
  )

...თუმცა დავალება მაინც არ შესრულებულა. მე დავაყენე მისი კონფიგურაცია სხვადასხვა გზით: გავზარდე მეხსიერების განაწილება თითოეული მოთხოვნის შემსრულებლისთვის, ვიყენებდი კვანძებს დიდი რაოდენობით მეხსიერებით, ვიყენებდი სამაუწყებლო ცვლადებს (მაუწყებლობის ცვლადები), მაგრამ ყოველ ჯერზე ეს ნახევრად საზომი აღმოჩნდა და თანდათანობით შემსრულებლები იწყებდნენ მარცხი სანამ ყველაფერი არ შეჩერდება.

განახლება: ასე იწყება. pic.twitter.com/agY4GU2ru5

- ნიკ სტრეიერი (@NicholasStrayer) შეიძლება 15, 2019

უფრო კრეატიული ვხდები

რა ვისწავლე: ზოგჯერ სპეციალური მონაცემები მოითხოვს სპეციალურ გადაწყვეტილებებს.

თითოეულ SNP-ს აქვს პოზიციის მნიშვნელობა. ეს არის რიცხვი, რომელიც შეესაბამება მისი ქრომოსომის გასწვრივ ფუძეების რაოდენობას. ეს არის კარგი და ბუნებრივი გზა ჩვენი მონაცემების ორგანიზებისთვის. თავიდან მინდოდა დაყოფა თითოეული ქრომოსომის რეგიონების მიხედვით. მაგალითად, პოზიციები 1 - 2000, 2001 - 4000 და ა.შ. მაგრამ პრობლემა ის არის, რომ SNP არ არის თანაბრად განაწილებული ქრომოსომებზე, ამიტომ ჯგუფის ზომები მნიშვნელოვნად განსხვავდება.

შედეგად, მივედი პოზიციების კატეგორიებად დაყოფამდე (რანგი). უკვე გადმოწერილი მონაცემების გამოყენებით, მე შევიტანე მოთხოვნა უნიკალური SNP-ების სიის, მათი პოზიციებისა და ქრომოსომების მოპოვებისთვის. შემდეგ დავახარისხე მონაცემები თითოეულ ქრომოსომაში და შევაგროვე 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()

ჯერ სცადეთ Spark-ით

რა ვისწავლე: ნაპერწკლის აგრეგაცია სწრაფია, მაგრამ დაყოფა მაინც ძვირია.

მსურდა ამ მცირე (2,5 მილიონი მწკრივი) მონაცემთა ჩარჩოს წაკითხვა Spark-ში, გაერთიანდა იგი ნედლეულ მონაცემებთან და შემდეგ დაყოფა ახლად დამატებული სვეტით. 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()ასე რომ, Spark-მა იცის, რომ მან უნდა გაგზავნოს მონაცემთა ჩარჩო ყველა კვანძში. ეს სასარგებლოა, თუ მონაცემები მცირე ზომისაა და საჭიროა ყველა ამოცანისთვის. წინააღმდეგ შემთხვევაში, Spark ცდილობს იყოს ჭკვიანი და საჭიროებისამებრ ავრცელებს მონაცემებს, რამაც შეიძლება გამოიწვიოს შენელება.

და ისევ, ჩემმა იდეამ არ გაამართლა: ამოცანები მუშაობდა გარკვეული პერიოდის განმავლობაში, დაასრულეს გაერთიანება და შემდეგ, დაყოფით დაწყებული შემსრულებლების მსგავსად, მათ დაიწყეს მარცხი.

AWK-ის დამატება

რა ვისწავლე: არ დაიძინო, როცა საფუძვლებს გასწავლიან. რა თქმა უნდა, ვინმემ უკვე მოაგვარა თქვენი პრობლემა ჯერ კიდევ 1980-იან წლებში.

ამ დრომდე, Spark-თან ჩემი ყველა წარუმატებლობის მიზეზი იყო კლასტერში არსებული მონაცემების არეულობა. შესაძლოა, მდგომარეობა გამოსწორდეს წინასწარი მკურნალობით. გადავწყვიტე, გამომეყენებინა დაუმუშავებელი ტექსტის მონაცემები ქრომოსომების სვეტებად, ამიტომ იმედი მქონდა, რომ Spark-ს „წინასწარ დაყოფილ“ მონაცემებს მივაწოდებდი.

StackOverflow-ზე ვეძებე როგორ გავყო სვეტის მნიშვნელობები და ვიპოვე ასეთი დიდი პასუხი. AWK-ით შეგიძლიათ ტექსტური ფაილი გაყოთ სვეტის მნიშვნელობებით, სკრიპტში ჩაწერით, ვიდრე შედეგების გაგზავნით stdout.

მე დავწერე Bash სკრიპტი, რომ გამომეცადა. ჩამოტვირთა ერთ-ერთი შეფუთული 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 მბ მეხსიერებას. პრობლემის გადასაჭრელად და ბევრი ფული რომ არ დაგვეკარგა, უნდა გაგვერკვია, როგორ გავატაროთ სამუშაოს პარალელიზება. საბედნიეროდ, აბსოლუტურად გასაოცარ წიგნში მონაცემთა მეცნიერება ბრძანების ხაზზე მე ვიპოვე ჯერონ იანსენსის თავი პარალელიზების შესახებ. ამის შესახებ გავიგე gnu parallel, ძალიან მოქნილი მეთოდი Unix-ში მრავალნაკადის განხორციელებისთვის.

როდესაც დავიწყე დანაყოფის დაყოფა ახალი პროცესის გამოყენებით, ყველაფერი კარგად იყო, მაგრამ მაინც არსებობდა შეფერხება - 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 on 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-ის წყალობით შემიძლია გავხსნა და გავყო 19 გიგიანი csv ისევე სწრაფად, როგორც გადმოვწერ. ამის გასაშვებად ნაპერწკალიც კი ვერ მივიღე. #მონაცემთა მეცნიერება #Linux pic.twitter.com/Nqyba2zqEk

- ნიკ სტრეიერი (@NicholasStrayer) შეიძლება 17, 2019

ამ ტვიტში უნდა ყოფილიყო ნახსენები "TSV". ვაი.

ახლად გაანალიზებული მონაცემების გამოყენება

რა ვისწავლე: Spark-ს მოსწონს შეუკუმშული მონაცემები და არ მოსწონს ტიხრების გაერთიანება.

ახლა მონაცემები იყო S3-ში შეუფუთავი (წაიკითხეთ: გაზიარებული) და ნახევრად შეკვეთილი ფორმატით და შემეძლო ისევ დავბრუნებულიყავი Spark-ში. სიურპრიზი მელოდა: ისევ ვერ მივაღწიე იმას, რაც მინდოდა! ძალიან რთული იყო სპარკისთვის იმის თქმა, თუ როგორ იყო მონაცემების დაყოფა. და მაშინაც კი, როდესაც ეს გავაკეთე, აღმოჩნდა, რომ ძალიან ბევრი დანაყოფი იყო (95 ათასი) და როდესაც გამოვიყენე coalesce შეამცირა მათი რაოდენობა გონივრულ ზღვრამდე, ამან გაანადგურა ჩემი დანაყოფი. დარწმუნებული ვარ, ეს შეიძლება გამოსწორდეს, მაგრამ რამდენიმე დღის ძიების შემდეგ გამოსავალი ვერ ვიპოვე. საბოლოოდ დავასრულე ყველა დავალება Spark-ში, თუმცა ამას გარკვეული დრო დასჭირდა და ჩემი გაყოფილი პარკეტის ფაილები არც თუ ისე მცირე იყო (~200 KB). თუმცა, მონაცემები იქ იყო, სადაც საჭირო იყო.

ძალიან პატარა და არათანაბარი, მშვენიერი!

ადგილობრივი Spark მოთხოვნების ტესტირება

რა ვისწავლე: ნაპერწკლს ძალიან ბევრი ხარჯი აქვს მარტივი პრობლემების გადაჭრისას.

მონაცემების ჭკვიან ფორმატში ჩამოტვირთვის საშუალებით შევძელი სიჩქარის შემოწმება. დააყენეთ R სკრიპტი ლოკალური Spark სერვერის გასაშვებად და შემდეგ ჩატვირთეთ Spark მონაცემთა ჩარჩო მითითებული პარკეტის ჯგუფის საცავიდან (ბინიდან). ვცადე ყველა მონაცემის ჩატვირთვა, მაგრამ 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 წამი დასჭირდა. ბევრად უკეთესი, მაგრამ არც ისე კარგი რაიმეს მასობრივი ტესტირებისთვის. გარდა ამისა, მე ვერ დავაჩქარე ქეშირება, რადგან როცა მონაცემთა ჩარჩოს ქეშირებას ვცდილობდი მეხსიერებაში, Spark ყოველთვის იშლებოდა, მაშინაც კი, როცა 50 გბ-ზე მეტი მეხსიერება გამოვყავი მონაცემთა ნაკრებს, რომელიც იწონიდა 15-ზე ნაკლებს.

AWK-ზე დაბრუნება

რა ვისწავლე: ასოციაციური მასივები AWK-ში ძალიან ეფექტურია.

მივხვდი, რომ უფრო მაღალი სიჩქარის მიღწევა შემეძლო. მშვენივრად გამახსენდა AWK გაკვეთილი ბრიუს ბარნეტის მიერ წავიკითხე მაგარი მახასიათებლის შესახებ, სახელწოდებით "ასოციაციური მასივები" არსებითად, ეს არის გასაღები-მნიშვნელობის წყვილები, რომლებსაც რატომღაც სხვანაირად ეძახდნენ AWK-ში და ამიტომ რატომღაც მათზე ბევრი არ მიფიქრია. რომან ჩეპლიაკა გაიხსენა, რომ ტერმინი „ასოციაციური მასივები“ ბევრად უფრო ძველია, ვიდრე ტერმინი „გასაღები-მნიშვნელობის წყვილი“. თუნდაც შენ მოძებნეთ გასაღები-მნიშვნელობა Google Ngram-ში, თქვენ ვერ ნახავთ ამ ტერმინს იქ, მაგრამ ნახავთ ასოციაციურ მასივებს! გარდა ამისა, "გასაღები-მნიშვნელობის წყვილი" ყველაზე ხშირად ასოცირდება მონაცემთა ბაზებთან, ასე რომ, ბევრად უფრო აზრიანია მისი შედარება ჰეშმაქთან. მივხვდი, რომ შემეძლო გამომეყენებინა ეს ასოციაციური მასივები ჩემი SNP-ების დასაკავშირებლად ურნის ცხრილთან და ნედლეულ მონაცემებთან 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-სთან ჩემი წინა ექსპერიმენტიდან, ახლა შემიძლია დავწერო კიდევ ერთი Bash სკრიპტი, რომ დამუშავდეს ერთდროულად ერთი ქრომოსომა და გავაგზავნო უფრო ღრმა დანაწილებული მონაცემები 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. შედეგად, დისკზე იქმნება მრავალი პატარა ფაილი (ამისთვის გამოვიყენე ტერაბაიტის EBS ტომები).

კონვეიერი მეორე განყოფილებიდან parallel გადის ჯგუფებში (ბინაში) და აერთიანებს მათ ინდივიდუალურ ფაილებს საერთო CSV c catდა შემდეგ აგზავნის მათ ექსპორტზე.

მაუწყებლობა R-ში?

რა ვისწავლე: შეგიძლიათ დაუკავშირდეთ stdin и stdout R სკრიპტიდან და, შესაბამისად, გამოიყენეთ იგი მილსადენში.

თქვენ შეიძლება შენიშნეთ ეს ხაზი თქვენს Bash სკრიპტში: ...cat chunked/*_bin_{}_*.csv | ./upload_as_rds.R.... ის თარგმნის ყველა თანმიმდევრულ ჯგუფურ ფაილს (ბინ) ქვემოთ მოცემულ R სკრიპტში. {} განსაკუთრებული ტექნიკაა parallel, რომელიც ათავსებს ნებისმიერ მონაცემს, რომელსაც ის უგზავნის მითითებულ ნაკადს უშუალოდ თავად ბრძანებაში. ვარიანტი {#} უზრუნველყოფს უნიკალურ თემატური ID-ს და {%} წარმოადგენს სამუშაო ადგილის ნომერს (განმეორდება, მაგრამ არასდროს ერთდროულად). ყველა ვარიანტის სია შეგიძლიათ ნახოთ დოკუმენტაცია.

#!/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 არის პარკეტის უმცროსი ვერსია, დინამიკების შესანახი წვრილმანის გარეშე.

Bash სკრიპტის დასრულების შემდეგ მივიღე პაკეტი .rds-S3-ში განთავსებული ფაილები, რომლებმაც მომცა საშუალება გამომეყენებინა ეფექტური შეკუმშვა და ჩაშენებული ტიპები.

სამუხრუჭე R-ის გამოყენების მიუხედავად, ყველაფერი ძალიან სწრაფად მუშაობდა. გასაკვირი არ არის, რომ R-ის ნაწილები, რომლებიც კითხულობენ და წერენ მონაცემებს, ძალიან ოპტიმიზირებულია. ერთ საშუალო ზომის ქრომოსომაზე ტესტირების შემდეგ, სამუშაო დასრულდა C5n.4xl მაგალითზე დაახლოებით ორ საათში.

S3 შეზღუდვები

რა ვისწავლე: ჭკვიანი ბილიკის განხორციელების წყალობით, S3-ს შეუძლია მრავალი ფაილის მართვა.

ვნერვიულობდი, შეძლებდა თუ არა S3 გაუმკლავდეს მასში გადატანილ ბევრ ფაილს. შემეძლო ფაილების სახელებს აზრი გამოვთქვა, მაგრამ როგორ ეძებს მათ S3?

საქაღალდეები S3-ში არის მხოლოდ საჩვენებლად, სინამდვილეში სისტემა არ აინტერესებს სიმბოლოს /. S3 FAQ გვერდიდან.

როგორც ჩანს, S3 წარმოადგენს კონკრეტული ფაილისკენ მიმავალ გზას, როგორც მარტივ კლავიშს ჰეშის ცხრილის ან დოკუმენტზე დაფუძნებული მონაცემთა ბაზაში. bucket შეიძლება ჩაითვალოს როგორც ცხრილი და ფაილები შეიძლება ჩაითვალოს ჩანაწერებად ამ ცხრილში.

იმის გამო, რომ სიჩქარე და ეფექტურობა მნიშვნელოვანია ამაზონში მოგების მისაღებად, გასაკვირი არ არის, რომ ეს გასაღები-როგორც-ფაილის გზა სისტემა საოცრად ოპტიმიზირებულია. ვცდილობდი მეპოვა ბალანსი: ისე, რომ ბევრი მოთხოვნის გაკეთება არ მომიწია, მაგრამ მოთხოვნები სწრაფად შესრულებულიყო. აღმოჩნდა, რომ უმჯობესია დაახლოებით 20 ათასი bin ფაილის შექმნა. ვფიქრობ, თუ გავაგრძელებთ ოპტიმიზაციას, შეგვიძლია მივაღწიოთ სიჩქარის ზრდას (მაგალითად, სპეციალური თაიგულის გაკეთება მხოლოდ მონაცემებისთვის, რითაც შევამცირებთ საძიებო ცხრილის ზომას). მაგრამ არ იყო დრო და ფული შემდგომი ექსპერიმენტებისთვის.

რაც შეეხება ჯვარედინი თავსებადობას?

რა ვისწავლე: დროის დაკარგვა ნომერ პირველი მიზეზია თქვენი შენახვის მეთოდის ნაადრევი ოპტიმიზაცია.

ამ ეტაპზე, ძალიან მნიშვნელოვანია საკუთარ თავს ჰკითხოთ: "რატომ გამოიყენოთ საკუთრების ფაილის ფორმატი?" მიზეზი მდგომარეობს ჩატვირთვის სიჩქარეში (gzipped CSV ფაილების ჩატვირთვას 7-ჯერ მეტი დრო დასჭირდა) და ჩვენს სამუშაო პროცესებთან თავსებადობაში. შეიძლება გადავიფიქრო, შეუძლია თუ არა R-ს ადვილად ჩატვირთოს პარკეტის (ან ისრის) ფაილები Spark დატვირთვის გარეშე. ჩვენს ლაბორატორიაში ყველა იყენებს R-ს და თუ მჭირდება მონაცემების სხვა ფორმატში გადაყვანა, მე მაინც მაქვს ორიგინალური ტექსტის მონაცემები, ასე რომ, შემიძლია უბრალოდ გავატარო მილსადენი.

სამუშაოს დაყოფა

რა ვისწავლე: ნუ ცდილობთ სამუშაოების ხელით ოპტიმიზაციას, მიეცით კომპიუტერს ამის გაკეთება.

მე გავმართე სამუშაო პროცესი ერთ ქრომოსომაზე, ახლა მჭირდება ყველა სხვა მონაცემის დამუშავება.
მსურდა რამდენიმე EC2 ინსტანციის გაზრდა კონვერტაციისთვის, მაგრამ ამავე დროს მეშინოდა ძალიან გაუწონასწორებელი დატვირთვა სხვადასხვა დამუშავების სამუშაოებზე (ისევე, როგორც Spark განიცდიდა გაუწონასწორებელ დანაყოფებს). გარდა ამისა, მე არ მაინტერესებდა თითო ქრომოსომაზე ერთი ინსტანციის გაზრდა, რადგან 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)

ასე რომ, მე დავასრულე ამოცანების ნაკრები, რომელიც ძალიან ჰგავდა ზომით. შემდეგ დარჩა მხოლოდ ჩემი წინა Bash სცენარის დიდ მარყუჟში გადატანა 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 პარკეტის ფაილებზე, მაშინ ეს ჩემთვის პრობლემა უნდა იყოს და არა ჩემი კოლეგებისთვის. ამისთვის გადავწყვიტე შიდა R პაკეტის გაკეთება.

შექმენით და დააფიქსირეთ ძალიან მარტივი პაკეტი, რომელიც შეიცავს ფუნქციის ირგვლივ ორგანიზებულ მონაცემებზე წვდომის მხოლოდ რამდენიმე ფუნქციას 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. ეს არის ყველა უნიკალური SNP-ის მასივი ჯგუფში (ურნაში), რომელიც საშუალებას გაძლევთ სწრაფად შეამოწმოთ, გაქვთ თუ არა მონაცემები წინა მოთხოვნიდან. ეს ასევე აადვილებს ჯგუფში (ბინაში) ყველა 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-ის მოთხოვნას საშუალოდ 0,1 წამზე ნაკლები სჭირდება და მონაცემთა გამოყენება ასეა. დაბალი, რომ ხარჯები S3 არის არაქისი.

ახლახან მე შევცვალე 25+ ტუბერკულოზის ნედლეული გენოტიპის მონაცემები ჩემი ლაბორატორიისთვის. როდესაც დავიწყე, ნაპერწკლის გამოყენებას 8 წუთი დასჭირდა და 20 დოლარი დაჯდა SNP-ის მოთხოვნით. AWK+ გამოყენების შემდეგ #rstats დამუშავებას ახლა წამის 10-ზე ნაკლები სჭირდება და ღირს $0.00001. ჩემი პირადი #Დიდი მონაცემები გამარჯვება. pic.twitter.com/ANOXVGrmkk

- ნიკ სტრეიერი (@NicholasStrayer) შეიძლება 30, 2019

დასკვნა

ეს სტატია საერთოდ არ არის სახელმძღვანელო. გამოსავალი აღმოჩნდა ინდივიდუალური და თითქმის არ არის ოპტიმალური. უფრო სწორად, ეს არის მოგზაურობის წიგნი. მინდა, სხვებმა გაიგონ, რომ ასეთი გადაწყვეტილებები არ ჩანს სრულყოფილად ჩამოყალიბებული თავში, ისინი ცდისა და შეცდომის შედეგია. ასევე, თუ თქვენ ეძებთ მონაცემთა მეცნიერს, გაითვალისწინეთ, რომ ამ ინსტრუმენტების ეფექტურად გამოყენება გამოცდილებას მოითხოვს, გამოცდილება კი ფული ღირს. მიხარია, რომ გადახდის საშუალება მქონდა, მაგრამ ბევრ სხვას, ვისაც ჩემზე უკეთ შეუძლია იგივე საქმის კეთება, არასდროს ექნება საშუალება, რომ უსახსრობის გამო ეცადოს.

დიდი მონაცემთა ინსტრუმენტები მრავალმხრივია. თუ დრო გაქვთ, შეგიძლიათ დაწეროთ უფრო სწრაფი გადაწყვეტა ჭკვიანური მონაცემების გაწმენდის, შენახვისა და ამოღების ტექნიკის გამოყენებით. საბოლოო ჯამში, საქმე ეხება ხარჯ-სარგებლის ანალიზს.

რაც ვისწავლე:

• არ არსებობს იაფი გზა 25 ტბ ერთდროულად გასაანალიზებლად;
• ფრთხილად იყავით თქვენი პარკეტის ფაილების ზომასთან და მათ ორგანიზაციასთან;
• Spark-ში ტიხრები უნდა იყოს დაბალანსებული;
• ზოგადად, არასოდეს სცადოთ 2,5 მილიონი დანაყოფის გაკეთება;
• დახარისხება ჯერ კიდევ რთულია, ისევე როგორც Spark-ის დაყენება;
• ზოგჯერ სპეციალური მონაცემები მოითხოვს სპეციალურ გადაწყვეტილებებს;
• ნაპერწკლის აგრეგაცია სწრაფია, მაგრამ დაყოფა მაინც ძვირია;
• არ დაიძინო, როცა საფუძვლებს გასწავლიან, ვიღაცამ ალბათ უკვე მოაგვარა შენი პრობლემა 1980-იან წლებში;
• gnu parallel - ეს არის ჯადოსნური რამ, ყველამ უნდა გამოიყენოს იგი;
• Spark-ს მოსწონს შეუკუმშული მონაცემები და არ მოსწონს ტიხრების გაერთიანება;
• ნაპერწკლს აქვს ძალიან ბევრი ზედნადები მარტივი პრობლემების გადაჭრისას;
• AWK-ის ასოციაციური მასივები ძალიან ეფექტურია;
• შეგიძლიათ დაუკავშირდეთ stdin и stdout R სკრიპტიდან და, შესაბამისად, გამოიყენეთ იგი მილსადენში;
• ჭკვიანი ბილიკის განხორციელების წყალობით, S3-ს შეუძლია მრავალი ფაილის დამუშავება;
• დროის დაკარგვის მთავარი მიზეზი არის თქვენი შენახვის მეთოდის ნაადრევი ოპტიმიზაცია;
• ნუ ეცდებით ამოცანების ხელით ოპტიმიზაციას, მიეცით კომპიუტერს ამის გაკეთება;
• API უნდა იყოს მარტივი გამოყენების სიმარტივისა და მოქნილობისთვის;
• თუ თქვენი მონაცემები კარგად არის მომზადებული, ქეშირება ადვილი იქნება!

წყარო: www.habr.com