របៀបអានអត្ថបទនេះ។: ខ្ញុំសូមអភ័យទោសចំពោះអត្ថបទដែលវែង ហើយច្របូកច្របល់។ ដើម្បីសន្សំពេលវេលាអ្នក ខ្ញុំចាប់ផ្តើមជំពូកនីមួយៗដោយការណែនាំ "អ្វីដែលខ្ញុំបានរៀន" ដែលសង្ខេបខ្លឹមសារនៃជំពូកក្នុងប្រយោគមួយ ឬពីរ។

“គ្រាន់តែបង្ហាញដំណោះស្រាយមកខ្ញុំ!” ប្រសិនបើអ្នកគ្រាន់តែចង់មើលកន្លែងដែលខ្ញុំបានមកពីនោះ សូមរំលងទៅជំពូក "ក្លាយជាការច្នៃប្រឌិតបន្ថែមទៀត" ប៉ុន្តែខ្ញុំគិតថាវាគួរឱ្យចាប់អារម្មណ៍ និងមានប្រយោជន៍ជាងក្នុងការអានអំពីការបរាជ័យ។

ថ្មីៗនេះខ្ញុំត្រូវបានប្រគល់ភារកិច្ចឱ្យរៀបចំដំណើរការសម្រាប់ដំណើរការបរិមាណដ៏ធំនៃលំដាប់ DNA ឆៅ (តាមបច្ចេកទេសបន្ទះឈីប SNP) ។ តម្រូវការគឺដើម្បីទទួលបានទិន្នន័យយ៉ាងឆាប់រហ័សអំពីទីតាំងហ្សែនដែលបានផ្តល់ឱ្យ (ហៅថា SNP) សម្រាប់ការបង្កើតគំរូជាបន្តបន្ទាប់ និងកិច្ចការផ្សេងៗទៀត។ ដោយប្រើ R និង AWK ខ្ញុំអាចសម្អាត និងរៀបចំទិន្នន័យតាមរបៀបធម្មជាតិ បង្កើនល្បឿនដំណើរការសំណួរ។ នេះ​មិន​មែន​ជា​ការ​ងាយ​ស្រួល​សម្រាប់​ខ្ញុំ​ទេ ហើយ​តម្រូវ​ឱ្យ​មាន​ការ​លើក​ឡើង​ជា​ច្រើន​ទៀត។ អត្ថបទនេះនឹងជួយអ្នកជៀសវាងកំហុសមួយចំនួនរបស់ខ្ញុំ ហើយបង្ហាញអ្នកពីអ្វីដែលខ្ញុំបានបញ្ចប់។

ជាដំបូង ការពន្យល់ណែនាំមួយចំនួន។

ទិន្នន័យ

មជ្ឈមណ្ឌលដំណើរការព័ត៌មានហ្សែនរបស់សាកលវិទ្យាល័យរបស់យើងបានផ្តល់ទិន្នន័យដល់យើងក្នុងទម្រង់ 25 TB TSV ។ ខ្ញុំបានទទួលពួកវាចែកជា 5 កញ្ចប់ បង្រួមដោយ Gzip ដែលនីមួយៗមានឯកសារប្រហែល 240 បួនជីហ្គាបៃ។ ជួរនីមួយៗមានទិន្នន័យសម្រាប់ SNP មួយពីបុគ្គលម្នាក់។ សរុបមក ទិន្នន័យអំពី ~2,5 លាន SNPs និង ~ 60 ពាន់នាក់ត្រូវបានបញ្ជូន។ បន្ថែមពីលើព័ត៌មាន SNP ឯកសារមានជួរឈរជាច្រើនដែលមានលេខដែលឆ្លុះបញ្ចាំងពីលក្ខណៈផ្សេងៗ ដូចជាអាំងតង់ស៊ីតេនៃការអាន ភាពញឹកញាប់នៃអាឡឺឡែរផ្សេងៗជាដើម។ សរុបមកមានជួរឈរប្រហែល 30 ដែលមានតម្លៃពិសេស។

គោលដៅ

ដូចទៅនឹងគម្រោងគ្រប់គ្រងទិន្នន័យណាមួយដែរ អ្វីដែលសំខាន់បំផុតគឺត្រូវកំណត់ពីរបៀបដែលទិន្នន័យនឹងត្រូវប្រើប្រាស់។ ក្នុងករណី​នេះ យើងភាគច្រើននឹងជ្រើសរើសម៉ូដែល និងលំហូរការងារសម្រាប់ SNP ដោយផ្អែកលើ SNP. នោះគឺយើងនឹងត្រូវការទិន្នន័យនៅលើ SNP មួយក្នុងពេលតែមួយ។ ខ្ញុំត្រូវរៀនពីរបៀបដើម្បីទាញយកកំណត់ត្រាទាំងអស់ដែលទាក់ទងនឹង SNP មួយក្នុងចំណោម 2,5 លាន យ៉ាងងាយស្រួល រហ័ស និងថោកតាមដែលអាចធ្វើទៅបាន។

ធ្វើម៉េចមិនធ្វើបែបនេះ

ដើម្បីដកស្រង់ cliché សមរម្យ:

ខ្ញុំមិនបានបរាជ័យមួយពាន់ដងទេ ខ្ញុំទើបតែរកឃើញវិធីមួយពាន់ដើម្បីជៀសវាងការញែកទិន្នន័យជាក្រុមក្នុងទម្រង់សំណួរដែលងាយស្រួលប្រើ។

សាកល្បងដំបូង

ខ្ញុំបានរៀនអ្វីខ្លះ៖ មិនមានវិធីថោកដើម្បីញែក 25 TB ក្នុងពេលតែមួយនោះទេ។

ដោយបានសិក្សាវគ្គ "វិធីសាស្រ្តកម្រិតខ្ពស់សម្រាប់ដំណើរការទិន្នន័យធំ" នៅសាកលវិទ្យាល័យ Vanderbilt ខ្ញុំប្រាកដថាល្បិចនេះគឺនៅក្នុងកាបូប។ វានឹងចំណាយពេលមួយម៉ោង ឬពីរម៉ោង ដើម្បីដំឡើងម៉ាស៊ីនមេ Hive ដើម្បីដំណើរការទិន្នន័យទាំងអស់ និងរាយការណ៍លទ្ធផល។ ដោយសារទិន្នន័យរបស់យើងត្រូវបានរក្សាទុកក្នុង AWS S3 ខ្ញុំបានប្រើសេវាកម្មនេះ។ Athenaដែលអនុញ្ញាតឱ្យអ្នកអនុវត្តសំណួរ Hive SQL ទៅទិន្នន័យ S3 ។ អ្នកមិនចាំបាច់ដំឡើង/បង្កើនក្រុម Hive ទេ ហើយអ្នកក៏ចំណាយសម្រាប់តែទិន្នន័យដែលអ្នកកំពុងស្វែងរកផងដែរ។

បន្ទាប់​ពី​ខ្ញុំ​បង្ហាញ Athena ទិន្នន័យ​របស់​ខ្ញុំ និង​ទម្រង់​របស់​វា ខ្ញុំ​បាន​ធ្វើ​តេស្ត​មួយ​ចំនួន​ជាមួយ​នឹង​សំណួរ​ដូច​នេះ៖

select * from intensityData limit 10;

ហើយ​បាន​ទទួល​លទ្ធផល​យ៉ាង​ឆាប់​រហ័ស។ រួចរាល់។

រហូតដល់យើងព្យាយាមប្រើទិន្នន័យក្នុងការងាររបស់យើង...

ខ្ញុំ​ត្រូវ​បាន​ស្នើ​ឱ្យ​ទាញ​យក​ព័ត៌មាន SNP ទាំងអស់​ដើម្បី​សាកល្បង​ម៉ូដែល​លើ។ ខ្ញុំបានដំណើរការសំណួរ៖

select * from intensityData 
where snp = 'rs123456';

... ហើយចាប់ផ្តើមរង់ចាំ។ បន្ទាប់ពីប្រាំបីនាទី និងទិន្នន័យដែលបានស្នើសុំច្រើនជាង 4 TB ខ្ញុំបានទទួលលទ្ធផល។ Athena គិតថ្លៃតាមបរិមាណទិន្នន័យដែលបានរកឃើញ 5 ដុល្លារក្នុងមួយតេរ៉ាបៃ។ ដូច្នេះសំណើតែមួយនេះចំណាយអស់ 20 ដុល្លារ និងរង់ចាំប្រាំបីនាទី។ ដើម្បីដំណើរការគំរូលើទិន្នន័យទាំងអស់ យើងត្រូវរង់ចាំ 38 ឆ្នាំ ហើយបង់ប្រាក់ចំនួន 50 លានដុល្លារ។ ជាក់ស្តែង វាមិនសមរម្យសម្រាប់យើងទេ។

ចាំបាច់ត្រូវប្រើ ផាកឃីត...

ខ្ញុំបានរៀនអ្វីខ្លះ៖ សូមប្រយ័ត្នជាមួយទំហំនៃឯកសារ Parquet របស់អ្នក និងស្ថាប័នរបស់វា។

ដំបូងខ្ញុំបានព្យាយាមជួសជុលស្ថានភាពដោយបំប្លែង TSV ទាំងអស់ទៅជា ឯកសារ parquet. ពួកវាងាយស្រួលសម្រាប់ធ្វើការជាមួយសំណុំទិន្នន័យធំ ពីព្រោះព័ត៌មាននៅក្នុងពួកវាត្រូវបានរក្សាទុកក្នុងទម្រង់ជួរឈរ៖ ជួរឈរនីមួយៗស្ថិតនៅក្នុងផ្នែកអង្គចងចាំ/ថាសរបស់វា ផ្ទុយពីឯកសារអត្ថបទ ដែលជួរមានធាតុនៃជួរឈរនីមួយៗ។ ហើយប្រសិនបើអ្នកត្រូវការស្វែងរកអ្វីមួយ នោះគ្រាន់តែអានជួរឈរដែលត្រូវការ។ លើសពីនេះ ឯកសារនីមួយៗរក្សាទុកជួរនៃតម្លៃនៅក្នុងជួរឈរមួយ ដូច្នេះប្រសិនបើតម្លៃដែលអ្នកកំពុងស្វែងរកមិនស្ថិតនៅក្នុងជួរនៃជួរឈរនោះ Spark នឹងមិនខ្ជះខ្ជាយពេលវេលាក្នុងការស្កេនឯកសារទាំងមូលនោះទេ។

ខ្ញុំបានដំណើរការកិច្ចការសាមញ្ញមួយ។ កាវអេវ ដើម្បីបំប្លែង TSV របស់យើងទៅជា Parquet ហើយទម្លាក់ឯកសារថ្មីទៅក្នុង Athena ។ វាចំណាយពេលប្រហែល 5 ម៉ោង។ ប៉ុន្តែ​នៅពេល​ខ្ញុំ​ដំណើរការ​សំណើ​នេះ វា​ចំណាយ​ពេល​ប្រហែល​ដូចគ្នា​និង​ប្រាក់​តិច​បន្តិច​ដើម្បី​បំពេញ។ ការពិតគឺថា Spark ដែលព្យាយាមបង្កើនប្រសិទ្ធភាពការងារនោះ គ្រាន់តែពន្លាកំណាត់ TSV មួយ ហើយដាក់វានៅក្នុងកំណាត់ Parquet របស់វា។ ហើយដោយសារតែកំណាត់នីមួយៗមានទំហំធំល្មមសម្រាប់ផ្ទុកកំណត់ត្រាទាំងមូលរបស់មនុស្សជាច្រើន ឯកសារនីមួយៗមាន SNPs ទាំងអស់ ដូច្នេះ Spark ត្រូវបើកឯកសារទាំងអស់ដើម្បីទាញយកព័ត៌មានដែលវាត្រូវការ។

គួរឱ្យចាប់អារម្មណ៍, ប្រភេទការបង្ហាប់លំនាំដើមរបស់ Parquet (និងបានណែនាំ), snappy, មិនអាចបំបែកបាន។ ដូច្នេះ ប្រតិបត្តិករនីមួយៗត្រូវជាប់គាំងលើភារកិច្ចនៃការពន្លា និងទាញយកសំណុំទិន្នន័យ 3,5 GB ពេញលេញ។

ចូរយើងយល់ពីបញ្ហា

ខ្ញុំបានរៀនអ្វីខ្លះ៖ ការតម្រៀបគឺពិបាក ជាពិសេសប្រសិនបើទិន្នន័យត្រូវបានចែកចាយ។

វាហាក់ដូចជាខ្ញុំថាឥឡូវនេះខ្ញុំបានយល់ពីខ្លឹមសារនៃបញ្ហា។ ខ្ញុំគ្រាន់តែត្រូវការតម្រៀបទិន្នន័យតាមជួរឈរ SNP មិនមែនដោយមនុស្សទេ។ បន្ទាប់មក SNPs ជាច្រើននឹងត្រូវបានរក្សាទុកនៅក្នុងកំណាត់ទិន្នន័យដាច់ដោយឡែកមួយ ហើយបន្ទាប់មកមុខងារ "smart" របស់ Parquet "បើកបានលុះត្រាតែតម្លៃស្ថិតនៅក្នុងជួរ" នឹងបង្ហាញខ្លួនឯងនៅក្នុងភាពរុងរឿងរបស់វា។ ជាអកុសល ការតម្រៀបតាមជួររាប់ពាន់លានដែលរាយប៉ាយពាសពេញចង្កោមបានបង្ហាញថាជាកិច្ចការដ៏លំបាកមួយ។

ខ្ញុំចូលរៀនថ្នាក់ algorithms នៅមហាវិទ្យាល័យ៖ "Ugh គ្មាននរណាម្នាក់ខ្វល់ពីភាពស្មុគស្មាញនៃការគណនានៃក្បួនដោះស្រាយការតម្រៀបទាំងអស់នេះទេ"

ខ្ញុំកំពុងព្យាយាមតម្រៀបលើជួរឈរក្នុងទំហំ 20TB #ផ្កាភ្លើង តារាង៖ "ហេតុអ្វីបានជាវាចំណាយពេលយូរដូច្នេះ?" # ឌីតាសាស្តា ការ​តស៊ូ។

- Nick Strayer (@NicholasStrayer) ខែមីនា 11, 2019

AWS ពិតជាមិនចង់ចេញការសងប្រាក់វិញទេ ដោយសារហេតុផល "ខ្ញុំជាសិស្សដែលរំខាន"។ បន្ទាប់ពីខ្ញុំបានរត់តម្រៀបនៅលើ Amazon Glue វាបានដំណើរការអស់រយៈពេល 2 ថ្ងៃហើយគាំង។

ចុះការបែងចែកវិញ?

ខ្ញុំបានរៀនអ្វីខ្លះ៖ ភាគថាសនៅក្នុង Spark ត្រូវតែមានតុល្យភាព។

បន្ទាប់មកខ្ញុំបានបង្កើតគំនិតនៃការបែងចែកទិន្នន័យនៅក្នុងក្រូម៉ូសូម។ មាន 23 ក្នុងចំណោមពួកគេ (និងជាច្រើនទៀតប្រសិនបើអ្នកយកទៅក្នុងគណនី mitochondrial DNA និងតំបន់ដែលមិនបានគូសផែនទី)។
វានឹងអនុញ្ញាតឱ្យអ្នកបំបែកទិន្នន័យទៅជាបំណែកតូចៗ។ ប្រសិនបើអ្នកបន្ថែមបន្ទាត់តែមួយទៅមុខងារនាំចេញ Spark នៅក្នុងស្គ្រីប Glue partition_by = "chr"បន្ទាប់មកទិន្នន័យគួរតែត្រូវបានបែងចែកទៅជាធុង។

ហ្សែននេះមានបំណែកជាច្រើនដែលហៅថា ក្រូម៉ូសូម។

ជាអកុសល វាមិនដំណើរការទេ។ ក្រូម៉ូសូមមានទំហំខុសៗគ្នា ដែលមានន័យថាចំនួនព័ត៌មានខុសៗគ្នា។ នេះមានន័យថា កិច្ចការដែល Spark ផ្ញើទៅកម្មករមិនមានតុល្យភាព និងបានបញ្ចប់យឺតៗ ដោយសារថ្នាំងមួយចំនួនបានបញ្ចប់មុនគេ ហើយនៅទំនេរ។ ទោះយ៉ាងណាក៏ដោយភារកិច្ចត្រូវបានបញ្ចប់។ ប៉ុន្តែនៅពេលស្នើសុំ SNP មួយ អតុល្យភាពបានបង្កបញ្ហាម្តងទៀត។ តម្លៃនៃដំណើរការ SNPs នៅលើក្រូម៉ូសូមធំជាង (នោះគឺជាកន្លែងដែលយើងចង់ទទួលបានទិន្នន័យ) បានថយចុះត្រឹមតែប្រហែល 10 ប៉ុណ្ណោះ។ ច្រើន ប៉ុន្តែមិនគ្រប់គ្រាន់ទេ។

ចុះបើយើងបែងចែកវាទៅជាផ្នែកតូចៗ?

ខ្ញុំបានរៀនអ្វីខ្លះ៖ កុំព្យាយាមធ្វើ 2,5 លានភាគថាសទាល់តែសោះ។

ខ្ញុំបានសម្រេចចិត្តចេញទៅក្រៅទាំងអស់ ហើយបែងចែក SNP នីមួយៗ។ នេះធានាថាភាគថាសមានទំហំស្មើគ្នា។ វាជាគំនិតអាក្រក់. ខ្ញុំបានប្រើ Glue និងបន្ថែមបន្ទាត់គ្មានកំហុស partition_by = 'snp'. កិច្ចការបានចាប់ផ្តើម ហើយចាប់ផ្តើមអនុវត្ត។ មួយថ្ងៃក្រោយមក ខ្ញុំបានពិនិត្យ ហើយឃើញថា នៅតែមិនមានអ្វីសរសេរទៅ S3 ដូច្នេះខ្ញុំបានសម្លាប់កិច្ចការនេះ។ វាហាក់ដូចជា Glue កំពុងសរសេរឯកសារកម្រិតមធ្យមទៅទីតាំងលាក់នៅក្នុង S3 ឯកសារជាច្រើន ប្រហែលជាពីរបីលាន។ ជាលទ្ធផល កំហុសរបស់ខ្ញុំត្រូវចំណាយអស់ជាងមួយពាន់ដុល្លារ ហើយមិនពេញចិត្តអ្នកណែនាំរបស់ខ្ញុំ។

ការបែងចែក + តម្រៀប

ខ្ញុំបានរៀនអ្វីខ្លះ៖ ការ​តម្រៀប​គឺ​នៅ​តែ​មាន​ការ​លំបាក​ដូច​នឹង​ការ​លៃតម្រូវ Spark ។

ការប៉ុនប៉ងចុងក្រោយរបស់ខ្ញុំក្នុងការបែងចែក ពាក់ព័ន្ធនឹងខ្ញុំបែងចែកក្រូម៉ូសូម ហើយបន្ទាប់មកតម្រៀបភាគថាសនីមួយៗ។ តាមទ្រឹស្ដី វានឹងបង្កើនល្បឿនសំណួរនីមួយៗ ពីព្រោះទិន្នន័យ 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

- Nick Strayer (@NicholasStrayer) ថ្ងៃទី 15 ខែ ឧសភា ឆ្នាំ 2019

ខ្ញុំកាន់តែមានភាពច្នៃប្រឌិត

ខ្ញុំបានរៀនអ្វីខ្លះ៖ ពេលខ្លះទិន្នន័យពិសេសទាមទារដំណោះស្រាយពិសេស។

SNP នីមួយៗមានតម្លៃទីតាំង។ នេះគឺជាលេខដែលត្រូវនឹងចំនួនមូលដ្ឋាននៅតាមបណ្តោយក្រូម៉ូសូមរបស់វា។ នេះជាវិធីល្អ និងធម្មជាតិក្នុងការរៀបចំទិន្នន័យរបស់យើង។ ដំបូងខ្ញុំចង់បែងចែកតាមតំបន់នៃក្រូម៉ូសូមនីមួយៗ។ ឧទាហរណ៍ មុខតំណែង 1 - 2000, 2001 - 4000 ។ល។ ប៉ុន្តែបញ្ហាគឺថា SNPs មិនត្រូវបានចែកចាយស្មើៗគ្នានៅទូទាំងក្រូម៉ូសូមទេ ដូច្នេះទំហំក្រុមនឹងប្រែប្រួលយ៉ាងខ្លាំង។

ជាលទ្ធផលខ្ញុំបានមកបំបែកមុខតំណែងជាប្រភេទ (ឋានៈ)។ ដោយប្រើទិន្នន័យដែលបានទាញយករួចហើយ ខ្ញុំបានដំណើរការសំណើមួយដើម្បីទទួលបានបញ្ជីនៃ SNPs តែមួយគត់ ទីតាំង និងក្រូម៉ូសូមរបស់ពួកគេ។ បន្ទាប់មកខ្ញុំបានតម្រៀបទិន្នន័យនៅក្នុងក្រូម៉ូសូមនីមួយៗ ហើយប្រមូល SNPs ទៅជាក្រុម (bin) នៃទំហំដែលបានផ្តល់ឱ្យ។ ចូរនិយាយថា 1000 SNPs នីមួយៗ។ នេះបានផ្តល់ឱ្យខ្ញុំនូវទំនាក់ទំនង SNP-to-group-per-chromosome ។

នៅទីបញ្ចប់ខ្ញុំបានបង្កើតក្រុម (bin) នៃ 75 SNPs ហេតុផលនឹងត្រូវបានពន្យល់ដូចខាងក្រោម។

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 ដើម្បីសាកល្បង។ បានទាញយក 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 MB ។ ដើម្បីដោះស្រាយបញ្ហា និងកុំឱ្យខាតលុយច្រើន យើងត្រូវរកវិធីធ្វើកិច្ចការស្របគ្នា។ ជាសំណាងល្អនៅក្នុងសៀវភៅដ៏អស្ចារ្យ វិទ្យាសាស្ត្រទិន្នន័យនៅបន្ទាត់ពាក្យបញ្ជា ខ្ញុំបានរកឃើញជំពូកមួយដោយ Jeron Janssens ស្តីពីភាពស្របគ្នា។ ពីវាខ្ញុំបានរៀនអំពី gnu parallelវិធីសាស្រ្តដែលអាចបត់បែនបានសម្រាប់ការអនុវត្ត multithreading នៅក្នុង Unix ។

នៅពេលខ្ញុំចាប់ផ្តើមការបែងចែកដោយប្រើដំណើរការថ្មី អ្វីគ្រប់យ៉ាងគឺល្អ ប៉ុន្តែនៅតែមានការជាប់គាំង - ការទាញយកវត្ថុ S3 ទៅកាន់ថាសគឺមិនលឿនទេ ហើយមិនស្របគ្នាពេញលេញទេ។ ដើម្បីជួសជុលនេះខ្ញុំបានធ្វើដូចនេះ៖

1. ខ្ញុំបានរកឃើញថាវាអាចធ្វើទៅបានដើម្បីអនុវត្តដំណាក់កាលទាញយក S3 ដោយផ្ទាល់នៅក្នុងបំពង់បង្ហូរប្រេងដោយលុបបំបាត់ទាំងស្រុងនូវការផ្ទុកកម្រិតមធ្យមនៅលើថាស។ នេះមានន័យថាខ្ញុំអាចជៀសវាងការសរសេរទិន្នន័យឆៅទៅឌីស ហើយប្រើទំហំតូចជាងមុន ដូច្នេះហើយតម្លៃថោកជាង ការផ្ទុកនៅលើ AWS ។
2. ក្រុម aws configure set default.s3.max_concurrent_requests 50 បង្កើនចំនួនខ្សែស្រឡាយដែល AWS CLI ប្រើ (តាមលំនាំដើមមាន 10) ។
3. ខ្ញុំបានប្តូរទៅឧទាហរណ៍ EC2 ដែលត្រូវបានធ្វើឱ្យប្រសើរឡើងសម្រាប់ល្បឿនបណ្តាញ ដោយមានអក្សរ n នៅក្នុងឈ្មោះ។ ខ្ញុំបានរកឃើញថាការបាត់បង់ថាមពលដំណើរការនៅពេលប្រើ n-instances គឺច្រើនជាងទូទាត់ដោយការកើនឡើងនៃល្បឿនផ្ទុក។ សម្រាប់កិច្ចការភាគច្រើនខ្ញុំបានប្រើ 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 terabyte ក្នុងរយៈពេលតែប៉ុន្មានម៉ោងប៉ុណ្ណោះ។

មិនមានអ្វីផ្អែមល្ហែមជាងការមើលឃើញស្នូលទាំងអស់ដែលអ្នកកំពុងចំណាយលើ AWS ដែលត្រូវបានប្រើ។ សូមអរគុណចំពោះ gnu-parallel ខ្ញុំអាចពន្លា និងបំបែក 19gig csv បានលឿនតាមដែលខ្ញុំអាចទាញយកវាបាន។ ខ្ញុំ​មិន​អាច​ទទួល​បាន​ភ្លើង​ដើម្បី​ដំណើរការ​នេះ​។ # ឌីតាសាស្តា # លីនជូ pic.twitter.com/Nqyba2zqEk

- Nick Strayer (@NicholasStrayer) ថ្ងៃទី 17 ខែ ឧសភា ឆ្នាំ 2019

Tweet នេះគួរតែនិយាយអំពី 'TSV' ។ អាឡា។

ការប្រើប្រាស់ទិន្នន័យដែលបានញែកថ្មីៗ

ខ្ញុំបានរៀនអ្វីខ្លះ៖ Spark ចូល​ចិត្ត​ទិន្នន័យ​ដែល​មិន​បាន​បង្ហាប់ ហើយ​មិន​ចូល​ចិត្ត​ការ​ផ្សំ​ភាគ​ថា​ស​។

ឥឡូវនេះទិន្នន័យគឺនៅក្នុង S3 នៅក្នុងទម្រង់ unpacked (អាន: ចែករំលែក) និងពាក់កណ្តាលលំដាប់ ហើយខ្ញុំអាចត្រលប់ទៅ Spark ម្តងទៀត។ ការភ្ញាក់ផ្អើលមួយកំពុងរង់ចាំខ្ញុំ៖ ខ្ញុំបរាជ័យម្តងទៀតក្នុងការសម្រេចអ្វីដែលខ្ញុំចង់បាន! វាពិបាកណាស់ក្នុងការប្រាប់ Spark ឱ្យច្បាស់អំពីរបៀបដែលទិន្នន័យត្រូវបានបែងចែក។ ហើយសូម្បីតែនៅពេលដែលខ្ញុំបានធ្វើនេះវាបានប្រែក្លាយថាមានភាគថាសច្រើនពេក (95 ពាន់) ហើយនៅពេលដែលខ្ញុំប្រើ coalesce កាត់បន្ថយចំនួនរបស់ពួកគេទៅដែនកំណត់សមហេតុផល វាបានបំផ្លាញការបែងចែករបស់ខ្ញុំ។ ខ្ញុំ​ប្រាកដ​ថា​វា​អាច​ត្រូវ​បាន​ជួសជុល ប៉ុន្តែ​បន្ទាប់​ពី​ការ​ស្វែងរក​ពីរ​បី​ថ្ងៃ ខ្ញុំ​មិន​អាច​រក​ឃើញ​ដំណោះស្រាយ​បាន​ទេ។ នៅទីបំផុតខ្ញុំបានបញ្ចប់កិច្ចការទាំងអស់នៅក្នុង Spark ទោះបីជាវាចំណាយពេលមួយរយៈ ហើយឯកសារ Parquet របស់ខ្ញុំដែលបំបែកមិនតូចណាស់ (~200 KB) ។ ទោះយ៉ាងណាក៏ដោយទិន្នន័យគឺជាកន្លែងដែលវាត្រូវការ។

តូចពេកហើយមិនស្មើគ្នា អស្ចារ្យណាស់!

សាកល្បងសំណួរ Spark ក្នុងតំបន់

ខ្ញុំបានរៀនអ្វីខ្លះ៖ Spark មាន​បញ្ហា​ច្រើន​ពេក​ពេល​ដោះស្រាយ​បញ្ហា​សាមញ្ញ។

ដោយការទាញយកទិន្នន័យជាទម្រង់ដ៏ឆ្លាតវៃ ខ្ញុំអាចសាកល្បងល្បឿនបាន។ ដំឡើងស្គ្រីប R ដើម្បីដំណើរការម៉ាស៊ីនមេ Spark មូលដ្ឋាន ហើយបន្ទាប់មកបានផ្ទុកស៊ុមទិន្នន័យ Spark ពីកន្លែងផ្ទុកក្រុម Parquet ដែលបានបញ្ជាក់ (bin) ។ ខ្ញុំបានព្យាយាមផ្ទុកទិន្នន័យទាំងអស់ ប៉ុន្តែមិនអាចទទួលបាន 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 GB ទៅសំណុំទិន្នន័យដែលមានទម្ងន់តិចជាង 15 ក៏ដោយ។

ត្រឡប់ទៅ AWK វិញ

ខ្ញុំបានរៀនអ្វីខ្លះ៖ Associative arrays in AWK មានប្រសិទ្ធភាពណាស់។

ខ្ញុំបានដឹងថាខ្ញុំអាចសម្រេចបាននូវល្បឿនខ្ពស់ជាងនេះ។ ខ្ញុំ​បាន​ចាំ​ថា​នៅ​ក្នុង​ការ​អស្ចារ្យ​មួយ​ ការបង្រៀន AWK ដោយ Bruce Barnett ខ្ញុំបានអានអំពីមុខងារដ៏ត្រជាក់មួយដែលមានឈ្មោះថា "អារេពាក់ព័ន្ធ" សំខាន់ ទាំងនេះគឺជាគូតម្លៃគន្លឹះ ដែលសម្រាប់ហេតុផលមួយចំនួនត្រូវបានហៅខុសគ្នានៅក្នុង AWK ដូច្នេះហើយ ខ្ញុំមិនគិតច្រើនអំពីពួកវាទេ។ រ៉ូម៉ាំង Cheplyaka បានរំលឹកថាពាក្យ "អារេសមាគម" គឺចាស់ជាងពាក្យ "គូតម្លៃគន្លឹះ" ។ ទោះបីជាអ្នក រកមើល key-value នៅក្នុង Google Ngramអ្នកនឹងមិនឃើញពាក្យនេះនៅទីនោះទេ ប៉ុន្តែអ្នកនឹងឃើញអារេសហការ! លើសពីនេះ "គូតម្លៃគន្លឹះ" ត្រូវបានភ្ជាប់ជាញឹកញាប់បំផុតជាមួយមូលដ្ឋានទិន្នន័យ ដូច្នេះវាមានន័យច្រើនក្នុងការប្រៀបធៀបវាជាមួយ hashmap ។ ខ្ញុំបានដឹងថាខ្ញុំអាចប្រើអារេសហការទាំងនេះដើម្បីភ្ជាប់ SNPs របស់ខ្ញុំជាមួយនឹងតារាង bin និងទិន្នន័យឆៅដោយមិនប្រើ 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 (bin) កំណត់​ជួរ​ឈរ​ដំបូង (ឈ្មោះ SNP) ជា​គន្លឹះ​សម្រាប់​អារេ​ពាក់ព័ន្ធ bin និងតម្លៃទីពីរ (ក្រុម) ជាតម្លៃ។ បន្ទាប់មកនៅក្នុងប្លុក { }ដែលត្រូវបានប្រតិបត្តិលើបន្ទាត់ទាំងអស់នៃឯកសារមេ បន្ទាត់នីមួយៗត្រូវបានបញ្ជូនទៅឯកសារលទ្ធផល ដែលទទួលបានឈ្មោះតែមួយគត់អាស្រ័យលើក្រុមរបស់វា (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.

នៅក្នុងផ្នែកទីមួយ ទិន្នន័យត្រូវបានអានពីឯកសារទាំងអស់ដែលមានព័ត៌មានអំពីក្រូម៉ូសូមដែលចង់បាន បន្ទាប់មកទិន្នន័យនេះត្រូវបានចែកចាយតាមខ្សែ ដែលចែកចាយឯកសារទៅក្នុងក្រុមសមស្រប (bin)។ ដើម្បីជៀសវាងលក្ខខណ្ឌនៃការប្រណាំងនៅពេលដែលខ្សែស្រឡាយច្រើនសរសេរទៅឯកសារដូចគ្នា AWK បញ្ជូនឈ្មោះឯកសារដើម្បីសរសេរទិន្នន័យទៅកន្លែងផ្សេងៗគ្នា ឧ. chr_10_bin_52_batch_2_aa.csv. ជាលទ្ធផល ឯកសារតូចៗជាច្រើនត្រូវបានបង្កើតនៅលើថាស (សម្រាប់នេះខ្ញុំបានប្រើ terabyte EBS volumes)។

អ្នកដឹកជញ្ជូនពីផ្នែកទីពីរ parallel ឆ្លងកាត់ក្រុម (bin) ហើយបញ្ចូលឯកសារនីមួយៗរបស់ពួកគេទៅជា CSV ទូទៅ catហើយបន្ទាប់មកបញ្ជូនពួកគេសម្រាប់ការនាំចេញ។

ការ​ផ្សាយ​នៅ R?

ខ្ញុំបានរៀនអ្វីខ្លះ: អាចទំនាក់ទំនងបាន។ 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 ដោយ​មិន​មាន​ទំហំ​ផ្ទុក​ឧបករណ៍​បំពង​សំឡេង។

បន្ទាប់ពីបញ្ចប់ស្គ្រីប Bash ខ្ញុំទទួលបានកញ្ចប់មួយ។ .rds-ឯកសារដែលមានទីតាំងនៅ S3 ដែលអនុញ្ញាតឱ្យខ្ញុំប្រើការបង្ហាប់ប្រកបដោយប្រសិទ្ធភាព និងប្រភេទដែលភ្ជាប់មកជាមួយ។

ទោះបីជាប្រើហ្វ្រាំង R ក៏ដោយក៏អ្វីៗដំណើរការលឿនណាស់។ មិនគួរឱ្យភ្ញាក់ផ្អើលទេផ្នែកនៃ R ដែលអាននិងសរសេរទិន្នន័យត្រូវបានធ្វើឱ្យប្រសើរខ្ពស់។ បន្ទាប់ពីការធ្វើតេស្តលើក្រូម៉ូសូមមធ្យមមួយ ការងារបានបញ្ចប់នៅលើឧទាហរណ៍ C5n.4xl ក្នុងរយៈពេលប្រហែលពីរម៉ោង។

ដែនកំណត់ S3

ខ្ញុំបានរៀនអ្វីខ្លះ៖ អរគុណចំពោះការអនុវត្តផ្លូវឆ្លាតវៃ S3 អាចគ្រប់គ្រងឯកសារជាច្រើន។

ខ្ញុំមានការព្រួយបារម្ភថាតើ S3 នឹងអាចគ្រប់គ្រងឯកសារជាច្រើនដែលត្រូវបានផ្ទេរទៅវាដែរឬទេ។ ខ្ញុំអាចធ្វើឱ្យឈ្មោះឯកសារមានអត្ថន័យ ប៉ុន្តែតើ S3 នឹងស្វែងរកពួកវាដោយរបៀបណា?

ថតឯកសារនៅក្នុង S3 គឺគ្រាន់តែសម្រាប់បង្ហាញប៉ុណ្ណោះ តាមពិតប្រព័ន្ធមិនចាប់អារម្មណ៍លើនិមិត្តសញ្ញាទេ។ /. ពីទំព័រសំណួរគេសួរញឹកញាប់ S3 ។

វាបង្ហាញថា S3 តំណាងឱ្យផ្លូវទៅកាន់ឯកសារជាក់លាក់មួយ ជាគន្លឹះសាមញ្ញមួយនៅក្នុងប្រភេទនៃតារាង hash ឬមូលដ្ឋានទិន្នន័យផ្អែកលើឯកសារ។ ធុងអាចត្រូវបានគេគិតថាជាតារាង ហើយឯកសារអាចត្រូវបានចាត់ទុកថាជាកំណត់ត្រានៅក្នុងតារាងនោះ។

ដោយសារល្បឿន និងប្រសិទ្ធភាពមានសារៈសំខាន់ក្នុងការរកប្រាក់ចំនេញនៅ Amazon វាមិនមែនជារឿងភ្ញាក់ផ្អើលទេដែលប្រព័ន្ធផ្លូវឯកសារសំខាន់នេះត្រូវបានធ្វើឱ្យប្រសើរ។ ខ្ញុំបានព្យាយាមស្វែងរកសមតុល្យ៖ ដូច្នេះខ្ញុំមិនចាំបាច់ធ្វើការស្នើសុំច្រើនទេ ប៉ុន្តែសំណើត្រូវបានប្រតិបត្តិយ៉ាងឆាប់រហ័ស។ វាបានប្រែក្លាយថាវាជាការល្អបំផុតក្នុងការបង្កើតឯកសារប្រហែល 20 ពាន់ធុង។ ខ្ញុំគិតថាប្រសិនបើយើងបន្តបង្កើនប្រសិទ្ធភាព យើងអាចសម្រេចបាននូវការកើនឡើងនៃល្បឿន (ឧទាហរណ៍ ការបង្កើតធុងពិសេសសម្រាប់តែទិន្នន័យ ដូច្នេះកាត់បន្ថយទំហំនៃតារាងរកមើល)។ ប៉ុន្តែ​គ្មាន​ពេល​វេលា ឬ​ប្រាក់​សម្រាប់​ការ​ពិសោធន៍​បន្ថែម​ទៀត​ទេ។

ចុះយ៉ាងណាចំពោះភាពឆបគ្នាឆ្លង?

អ្វី​ដែល​ខ្ញុំ​បាន​រៀន៖ មូលហេតុ​ទី​មួយ​នៃ​ការ​ខ្ជះខ្ជាយ​ពេល​វេលា​គឺ​ការ​បង្កើន​ប្រសិទ្ធភាព​វិធីសាស្ត្រ​ផ្ទុក​របស់​អ្នក​មុន​ពេល​កំណត់។

នៅចំណុចនេះ វាមានសារៈសំខាន់ខ្លាំងណាស់ក្នុងការសួរខ្លួនឯងថា "ហេតុអ្វីត្រូវប្រើទម្រង់ឯកសារដែលមានកម្មសិទ្ធិ?" ហេតុផលគឺស្ថិតនៅក្នុងល្បឿនផ្ទុក (ឯកសារ Gzipped CSV ចំណាយពេលផ្ទុកយូរជាង 7 ដង) និងភាពឆបគ្នាជាមួយលំហូរការងាររបស់យើង។ ខ្ញុំអាចពិចារណាឡើងវិញថាតើ R អាចផ្ទុកឯកសារ Parquet (ឬ Arrow) បានយ៉ាងងាយស្រួលដោយមិនមានផ្ទុក 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 ទៅឯកសារ Parquet បន្ទាប់មកនេះគួរតែជាបញ្ហាសម្រាប់ខ្ញុំ មិនមែនសម្រាប់មិត្តរួមការងាររបស់ខ្ញុំទេ។ សម្រាប់រឿងនេះខ្ញុំបានសម្រេចចិត្តបង្កើតកញ្ចប់ R ខាងក្នុង។

បង្កើត និងចងក្រងឯកសារកញ្ចប់ដ៏សាមញ្ញបំផុតដែលមានមុខងារចូលប្រើទិន្នន័យមួយចំនួនដែលរៀបចំជុំវិញមុខងារមួយ។ get_snp. ខ្ញុំក៏បានបង្កើតគេហទំព័រមួយសម្រាប់សហការីរបស់ខ្ញុំ pkgdownដូច្នេះពួកគេអាចមើលឧទាហរណ៍ និងឯកសារបានយ៉ាងងាយស្រួល។

ឃ្លាំងសម្ងាត់ឆ្លាតវៃ

ខ្ញុំបានរៀនអ្វីខ្លះ៖ ប្រសិនបើទិន្នន័យរបស់អ្នកត្រូវបានរៀបចំយ៉ាងល្អ ឃ្លាំងសម្ងាត់នឹងងាយស្រួល!

ចាប់តាំងពីលំហូរការងារសំខាន់មួយបានអនុវត្តគំរូវិភាគដូចគ្នាទៅនឹងកញ្ចប់ SNP ខ្ញុំបានសម្រេចចិត្តប្រើ binning ដើម្បីផលប្រយោជន៍របស់ខ្ញុំ។ នៅពេលបញ្ជូនទិន្នន័យតាមរយៈ 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 តែមួយគត់ទាំងអស់នៅក្នុងក្រុម (bin) ដែលអនុញ្ញាតឱ្យអ្នកពិនិត្យមើលយ៉ាងឆាប់រហ័សថាតើអ្នកមានទិន្នន័យពីសំណួរពីមុនរួចហើយឬអត់។ វាក៏ធ្វើឱ្យវាងាយស្រួលក្នុងការរង្វិលជុំតាមរយៈ SNPs ទាំងអស់នៅក្នុងក្រុម (bin) ជាមួយនឹងកូដនេះ៖

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

Результаты

ឥឡូវនេះយើងអាច (និងបានចាប់ផ្តើមយ៉ាងធ្ងន់ធ្ងរ) ដំណើរការគំរូ និងសេណារីយ៉ូដែលពីមុនមិនអាចចូលដំណើរការបានសម្រាប់ពួកយើង។ អ្វី​ដែល​ល្អ​បំផុត​គឺ​មិត្ត​រួម​ការងារ​មន្ទីរ​ពិសោធន៍​របស់​ខ្ញុំ​មិន​ចាំបាច់​គិត​អំពី​ផលវិបាក​អ្វី​ឡើយ។ ពួកគេគ្រាន់តែមានមុខងារដែលដំណើរការ។

ហើយទោះបីជាកញ្ចប់នេះទុកព័ត៌មានលម្អិតដល់ពួកគេក៏ដោយ ខ្ញុំបានព្យាយាមធ្វើឱ្យទម្រង់ទិន្នន័យមានលក្ខណៈសាមញ្ញគ្រប់គ្រាន់ដើម្បីឱ្យពួកគេអាចយល់បាន ប្រសិនបើខ្ញុំបាត់ខ្លួននៅថ្ងៃស្អែក...

ល្បឿនបានកើនឡើងគួរឱ្យកត់សម្គាល់។ ជាធម្មតាយើងស្កេនបំណែកហ្សែនសំខាន់ៗដែលមានមុខងារ។ ពីមុនយើងមិនអាចធ្វើបែបនេះបានទេ (វាហាក់ដូចជាថ្លៃពេក) ប៉ុន្តែឥឡូវនេះ ដោយសាររចនាសម្ព័ន្ធក្រុម (bin) និងឃ្លាំងសម្ងាត់ សំណើសម្រាប់ SNP មួយចំណាយពេលជាមធ្យមតិចជាង 0,1 វិនាទី ហើយការប្រើប្រាស់ទិន្នន័យគឺដូច្នេះ។ ទាបដែលតម្លៃសម្រាប់ S3 គឺសណ្តែកដី។

ថ្មីៗ​នេះ​ខ្ញុំ​បាន​ដាក់​ការ​ផ្លាស់​ប្តូ​រ​នៃ​ការ​ឈ្លោះ​គ្នា 25+ TB នៃ​ទិន្នន័យ genotyping ឆៅ​សម្រាប់​មន្ទីរ​ពិសោធន៍​របស់​ខ្ញុំ​។ នៅពេលខ្ញុំចាប់ផ្តើម ការប្រើ spark ចំណាយពេល 8 នាទី និងចំណាយអស់ 20 ដុល្លារដើម្បីសាកសួរ SNP ។ បន្ទាប់ពីប្រើ AWK+ # ស្ថិតិ ដើម្បីដំណើរការ ឥឡូវនេះវាចំណាយពេលតិចជាង 10 នៃវិនាទី ហើយមានតម្លៃ 0.00001 ដុល្លារ។ ផ្ទាល់ខ្លួនរបស់ខ្ញុំ #ទិន្នន័យ​ធំ ឈ្នះ pic.twitter.com/ANOXVGrmkk

- Nick Strayer (@NicholasStrayer) ថ្ងៃទី 30 ខែ ឧសភា ឆ្នាំ 2019

សេចក្តីសន្និដ្ឋាន

អត្ថបទនេះមិនមែនជាការណែនាំទាល់តែសោះ។ ដំណោះស្រាយបានប្រែទៅជាបុគ្គល ហើយស្ទើរតែមិនសមហេតុផលទេ។ ផ្ទុយទៅវិញ វាជាសៀវភៅទេសចរណ៍។ ខ្ញុំ​ចង់​ឲ្យ​អ្នក​ដទៃ​យល់​ថា ការ​សម្រេច​ចិត្ត​បែប​នេះ​មិន​បាន​បង្កើត​ឡើង​ពេញ​លេញ​នៅ​ក្នុង​ក្បាល​ទេ វា​ជា​លទ្ធផល​នៃ​ការ​សាកល្បង និង​កំហុស។ ដូចគ្នានេះផងដែរ ប្រសិនបើអ្នកកំពុងស្វែងរកអ្នកវិទ្យាសាស្ត្រទិន្នន័យ សូមចងចាំថាការប្រើប្រាស់ឧបករណ៍ទាំងនេះប្រកបដោយប្រសិទ្ធភាពទាមទារបទពិសោធន៍ ហើយបទពិសោធន៍ត្រូវចំណាយប្រាក់។ ខ្ញុំសប្បាយចិត្តដែលខ្ញុំមានមធ្យោបាយបង់ប្រាក់ ប៉ុន្តែអ្នកផ្សេងទៀតដែលអាចធ្វើការងារដូចគ្នាបានល្អជាងខ្ញុំ នឹងមិនមានឱកាសដោយសារតែខ្វះលុយសូម្បីតែព្យាយាម។

ឧបករណ៍ទិន្នន័យធំមានភាពចម្រុះ។ ប្រសិនបើអ្នកមានពេល អ្នកប្រាកដជាអាចសរសេរដំណោះស្រាយលឿនជាងមុនដោយប្រើបច្ចេកទេសសម្អាត ការផ្ទុក និងទាញយកទិន្នន័យដ៏ឆ្លាតវៃ។ ទីបំផុតវាមកលើការវិភាគតម្លៃ-អត្ថប្រយោជន៍។

អ្វីដែលខ្ញុំបានរៀន៖

• មិនមានវិធីថោកដើម្បីញែក 25 TB ក្នុងពេលតែមួយទេ។
• សូមប្រយ័ត្នជាមួយនឹងទំហំនៃឯកសារ Parquet របស់អ្នក និងស្ថាប័នរបស់ពួកគេ;
• ភាគថាសនៅក្នុង Spark ត្រូវតែមានតុល្យភាព;
• ជាទូទៅមិនដែលព្យាយាមបង្កើតភាគថាស 2,5 លាន;
• ការ​តម្រៀប​គឺ​នៅ​តែ​មាន​ការ​លំបាក​ដូច​ជា​ការ​រៀបចំ Spark;
• ពេលខ្លះទិន្នន័យពិសេសទាមទារដំណោះស្រាយពិសេស។
• ការប្រមូលផ្តុំផ្កាភ្លើងលឿន ប៉ុន្តែការបែងចែកនៅតែមានតម្លៃថ្លៃ។
• កុំដេកនៅពេលដែលពួកគេបង្រៀនអ្នកពីមូលដ្ឋានគ្រឹះ ប្រហែលជាមាននរណាម្នាក់បានដោះស្រាយបញ្ហារបស់អ្នករួចហើយនៅក្នុងទសវត្សរ៍ឆ្នាំ 1980 ។
• gnu parallel - នេះ​ជា​របស់​វេទមន្ត, អ្នក​រាល់​គ្នា​គួរ​តែ​ប្រើ​វា;
• Spark ចូលចិត្តទិន្នន័យដែលមិនបានបង្ហាប់ ហើយមិនចូលចិត្តការបញ្ចូលគ្នានៃភាគថាស
• Spark មានច្រើនពេកនៅពេលដោះស្រាយបញ្ហាសាមញ្ញ;
• អារេសហការរបស់ AWK មានប្រសិទ្ធភាពខ្លាំង។
• អ្នកអាចទាក់ទង stdin и stdout ពីអក្សរ R ហើយដូច្នេះប្រើវានៅក្នុងបំពង់។
• សូមអរគុណចំពោះការអនុវត្តផ្លូវឆ្លាតវៃ S3 អាចដំណើរការឯកសារជាច្រើន;
• ហេតុផលចម្បងសម្រាប់ការខ្ជះខ្ជាយពេលវេលាគឺការបង្កើនប្រសិទ្ធភាពវិធីសាស្ត្រផ្ទុករបស់អ្នកមុនអាយុ។
• កុំព្យាយាមបង្កើនប្រសិទ្ធភាពការងារដោយដៃ អនុញ្ញាតឱ្យកុំព្យូទ័រធ្វើវា។
• API គួរតែមានលក្ខណៈសាមញ្ញសម្រាប់ភាពងាយស្រួល និងភាពបត់បែននៃការប្រើប្រាស់។
• ប្រសិនបើទិន្នន័យរបស់អ្នកត្រូវបានរៀបចំយ៉ាងល្អ ឃ្លាំងសម្ងាត់នឹងងាយស្រួល!

ប្រភព: www.habr.com