কিভাবে এই নিবন্ধটি পড়তে: লেখাটি এত দীর্ঘ এবং বিশৃঙ্খল হওয়ার জন্য আমি ক্ষমাপ্রার্থী। আপনার সময় বাঁচাতে, আমি প্রতিটি অধ্যায় একটি "আমি যা শিখেছি" ভূমিকা দিয়ে শুরু করি, যা এক বা দুটি বাক্যে অধ্যায়ের সারমর্মকে সংক্ষিপ্ত করে।

"শুধু আমাকে সমাধান দেখান!" আপনি যদি দেখতে চান আমি কোথা থেকে এসেছি, তাহলে "আরো উদ্ভাবনী হওয়া" অধ্যায়ে যান, তবে আমি মনে করি এটি ব্যর্থতা সম্পর্কে পড়া আরও আকর্ষণীয় এবং দরকারী।

আমাকে সম্প্রতি প্রচুর পরিমাণে কাঁচা ডিএনএ সিকোয়েন্স (প্রযুক্তিগতভাবে একটি এসএনপি চিপ) প্রক্রিয়াকরণের জন্য একটি প্রক্রিয়া সেট আপ করার দায়িত্ব দেওয়া হয়েছিল। পরবর্তী মডেলিং এবং অন্যান্য কাজের জন্য একটি প্রদত্ত জেনেটিক অবস্থান (একটি SNP বলা হয়) সম্পর্কে দ্রুত ডেটা প্রাপ্ত করার প্রয়োজন ছিল। R এবং AWK ব্যবহার করে, আমি একটি প্রাকৃতিক উপায়ে ডেটা পরিষ্কার এবং সংগঠিত করতে সক্ষম হয়েছি, ব্যাপকভাবে ক্যোয়ারী প্রক্রিয়াকরণের গতি বাড়িয়েছি। এটি আমার জন্য সহজ ছিল না এবং অসংখ্য পুনরাবৃত্তির প্রয়োজন ছিল। এই নিবন্ধটি আপনাকে আমার কিছু ভুল এড়াতে এবং আমি কী দিয়ে শেষ করেছি তা দেখাতে সাহায্য করবে।

প্রথমত, কিছু পরিচায়ক ব্যাখ্যা।

উপাত্ত

আমাদের বিশ্ববিদ্যালয়ের জেনেটিক তথ্য প্রক্রিয়াকরণ কেন্দ্র 25 টিবি টিএসভি আকারে আমাদের ডেটা সরবরাহ করেছে। আমি সেগুলিকে জিজিপ দ্বারা সংকুচিত 5টি প্যাকেজে বিভক্ত পেয়েছি, যার প্রতিটিতে প্রায় 240টি চার-গিগাবাইট ফাইল রয়েছে৷ প্রতিটি সারিতে একজন ব্যক্তির থেকে একটি SNP-এর জন্য ডেটা রয়েছে। মোট, ~ 2,5 মিলিয়ন SNP এবং ~ 60 হাজার লোকের ডেটা প্রেরণ করা হয়েছিল। SNP তথ্য ছাড়াও, ফাইলগুলিতে সংখ্যা সহ অসংখ্য কলাম রয়েছে যা বিভিন্ন বৈশিষ্ট্য প্রতিফলিত করে, যেমন পড়ার তীব্রতা, বিভিন্ন অ্যালিলের ফ্রিকোয়েন্সি ইত্যাদি। সর্বমোট প্রায় 30টি কলাম অনন্য মান সহ ছিল।

লক্ষ্য

যেকোন ডেটা ম্যানেজমেন্ট প্রজেক্টের মতো, সবচেয়ে গুরুত্বপূর্ণ বিষয় ছিল ডেটা কীভাবে ব্যবহার করা হবে তা নির্ধারণ করা। এক্ষেত্রে আমরা SNP-এর উপর ভিত্তি করে SNP-এর জন্য বেশিরভাগ মডেল এবং ওয়ার্কফ্লো নির্বাচন করব. অর্থাৎ, আমাদের একবারে শুধুমাত্র একটি SNP-এ ডেটার প্রয়োজন হবে। আমাকে শিখতে হয়েছিল কিভাবে 2,5 মিলিয়ন SNP-এর সাথে সম্পর্কিত সমস্ত রেকর্ড যতটা সহজে, দ্রুত এবং সস্তায় সম্ভব পুনরুদ্ধার করতে হয়।

এটা কিভাবে করবেন না

একটি উপযুক্ত ক্লিচ উদ্ধৃত করতে:

আমি এক হাজার বার ব্যর্থ হইনি, আমি একটি ক্যোয়ারী-বান্ধব বিন্যাসে একগুচ্ছ ডেটা পার্স করা এড়াতে এক হাজার উপায় আবিষ্কার করেছি।

প্রথম চেষ্টা

আমি কি শিখেছি: একবারে 25 টিবি পার্স করার কোন সস্তা উপায় নেই।

ভ্যান্ডারবিল্ট ইউনিভার্সিটিতে "অ্যাডভান্সড মেথডস ফর বিগ ডেটা প্রসেসিং" কোর্সটি নেওয়ার পর, আমি নিশ্চিত ছিলাম যে কৌশলটি ব্যাগে ছিল। 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-এ রূপান্তর করে পরিস্থিতি ঠিক করার চেষ্টা করেছি Parquet ফাইল. এগুলি বড় ডেটা সেটগুলির সাথে কাজ করার জন্য সুবিধাজনক কারণ তাদের মধ্যে তথ্যগুলি কলামার আকারে সংরক্ষণ করা হয়: প্রতিটি কলাম তার নিজস্ব মেমরি/ডিস্ক বিভাগে থাকে, টেক্সট ফাইলের বিপরীতে, যে সারিতে প্রতিটি কলামের উপাদান থাকে। এবং যদি আপনার কিছু খুঁজে বের করার প্রয়োজন হয়, তাহলে শুধু প্রয়োজনীয় কলামটি পড়ুন। অতিরিক্তভাবে, প্রতিটি ফাইল একটি কলামে মানগুলির একটি পরিসীমা সঞ্চয় করে, তাই আপনি যে মানটি খুঁজছেন তা যদি কলামের পরিসরে না হয়, স্পার্ক পুরো ফাইলটি স্ক্যান করার সময় নষ্ট করবে না।

আমি একটি সহজ কাজ দৌড়ে এডাব্লুএস আঠালো আমাদের TSVগুলিকে Parquet-এ রূপান্তর করতে এবং নতুন ফাইলগুলি এথেনায় ফেলে দিতে। প্রায় 5 ঘন্টা লেগেছিল। কিন্তু যখন আমি অনুরোধটি চালাই, তখন এটি সম্পূর্ণ করতে প্রায় একই পরিমাণ সময় এবং কিছুটা কম টাকা লেগেছিল। আসল বিষয়টি হ'ল স্পার্ক, টাস্কটি অপ্টিমাইজ করার চেষ্টা করে, কেবল একটি TSV খণ্ডটি আনপ্যাক করে এবং এটিকে নিজস্ব Parquet খণ্ডে রাখে। এবং যেহেতু প্রতিটি খণ্ড অনেক লোকের সম্পূর্ণ রেকর্ড ধারণ করার জন্য যথেষ্ট বড় ছিল, প্রতিটি ফাইলে সমস্ত SNP রয়েছে, তাই স্পার্ককে প্রয়োজনীয় তথ্য বের করতে সমস্ত ফাইল খুলতে হয়েছিল।

মজার বিষয় হল, Parquet এর ডিফল্ট (এবং প্রস্তাবিত) কম্প্রেশন টাইপ, স্ন্যাপি, বিভাজনযোগ্য নয়। অতএব, প্রতিটি নির্বাহক সম্পূর্ণ 3,5 জিবি ডেটাসেট আনপ্যাক এবং ডাউনলোড করার কাজে আটকে ছিল।

আসুন সমস্যাটি বুঝতে পারি

আমি কি শিখেছি: বাছাই করা কঠিন, বিশেষ করে যদি ডেটা বিতরণ করা হয়।

আমার কাছে মনে হচ্ছিল এখন আমি সমস্যার সারমর্ম বুঝতে পেরেছি। আমার শুধুমাত্র SNP কলাম দ্বারা ডেটা বাছাই করা দরকার, লোকেদের দ্বারা নয়। তারপরে বেশ কয়েকটি SNP একটি পৃথক ডেটা খণ্ডে সংরক্ষণ করা হবে এবং তারপরে Parquet-এর "স্মার্ট" ফাংশন "শুধুমাত্র যদি মানটি পরিসরে থাকে তবেই খুলবে" তার সমস্ত মহিমায় নিজেকে দেখাবে। দুর্ভাগ্যবশত, একটি ক্লাস্টার জুড়ে ছড়িয়ে ছিটিয়ে থাকা বিলিয়ন সারিগুলির মধ্য দিয়ে সাজানো একটি কঠিন কাজ বলে প্রমাণিত হয়েছে।

আমি কলেজে অ্যালগরিদম ক্লাস নিচ্ছি: "ওহ, এই সমস্ত সাজানোর অ্যালগরিদমের গণনাগত জটিলতা সম্পর্কে কেউই চিন্তা করে না"

আমি একটি 20TB এ একটি কলামে সাজানোর চেষ্টা করছি # স্পার্ক টেবিল: "এত সময় লাগছে কেন?" # ডেটাসায়েন্স সংগ্রাম।

— নিক স্ট্রেয়ার (@নিকোলাসস্ট্রেয়ার) মার্চ 11, 2019

"আমি একজন বিভ্রান্ত ছাত্র" কারণের কারণে AWS নিশ্চিতভাবে কোনো টাকা ফেরত দিতে চায় না। আমি অ্যামাজন গ্লুতে বাছাই করার পরে, এটি 2 দিন ধরে চলল এবং ক্র্যাশ হয়ে গেল।

বিভাজন সম্পর্কে কি?

আমি কি শিখেছি: স্পার্কের পার্টিশন অবশ্যই ভারসাম্যপূর্ণ হতে হবে।

তারপর আমি ক্রোমোজোমে ডেটা পার্টিশন করার ধারণা নিয়ে এসেছি। তাদের মধ্যে 23টি রয়েছে (এবং আপনি যদি মাইটোকন্ড্রিয়াল ডিএনএ এবং আনম্যাপ করা অঞ্চলগুলিকে বিবেচনা করেন তবে আরও অনেকগুলি)।
এটি আপনাকে ছোট খণ্ডে ডেটা বিভক্ত করার অনুমতি দেবে। আপনি যদি আঠালো স্ক্রিপ্টে স্পার্ক এক্সপোর্ট ফাংশনে মাত্র একটি লাইন যোগ করেন partition_by = "chr", তারপর তথ্য buckets মধ্যে বিভক্ত করা উচিত.

জিনোম ক্রোমোজোম নামক অসংখ্য খণ্ড নিয়ে গঠিত।

দুর্ভাগ্যবশত, এটি কাজ করেনি। ক্রোমোজোমের বিভিন্ন আকার রয়েছে, যার অর্থ বিভিন্ন পরিমাণ তথ্য। এর মানে হল যে স্পার্ক কর্মীদের কাছে পাঠানো কাজগুলি ভারসাম্যপূর্ণ ছিল না এবং ধীরে ধীরে সম্পন্ন হয়েছিল কারণ কিছু নোড তাড়াতাড়ি শেষ হয়েছিল এবং নিষ্ক্রিয় ছিল। তবে কাজগুলো সম্পন্ন হয়েছে। কিন্তু একটি 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গুলি ক্রোমোজোম জুড়ে সমানভাবে বিতরণ করা হয় না, তাই গ্রুপের আকারগুলি ব্যাপকভাবে পরিবর্তিত হবে।

ফলস্বরূপ, আমি বিভাগগুলিতে (র্যাঙ্ক) অবস্থানের ভাঙ্গনে এসেছি। ইতিমধ্যে ডাউনলোড করা ডেটা ব্যবহার করে, আমি অনন্য 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()

প্রথমে স্পার্ক দিয়ে চেষ্টা করুন

আমি কি শিখেছি: স্পার্ক অ্যাগ্রিগেশন দ্রুত, কিন্তু পার্টিশন এখনও ব্যয়বহুল।

আমি এই ছোট (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 এর দশকে আপনার সমস্যার সমাধান করেছে।

এই বিন্দু পর্যন্ত, স্পার্কের সাথে আমার সমস্ত ব্যর্থতার কারণ ছিল ক্লাস্টারে ডেটার গোলমাল। সম্ভবত প্রাক-চিকিত্সা দিয়ে পরিস্থিতির উন্নতি করা যেতে পারে। আমি ক্রোমোজোমের কলামে কাঁচা টেক্সট ডেটা বিভক্ত করার চেষ্টা করার সিদ্ধান্ত নিয়েছি, তাই আমি "প্রি-পার্টিশনড" ডেটা দিয়ে স্পার্ক দেওয়ার আশা করেছি।

আমি স্ট্যাকওভারফ্লোতে অনুসন্ধান করেছি কিভাবে কলামের মান দ্বারা বিভক্ত করা যায় এবং খুঁজে পেয়েছি যেমন একটি মহান উত্তর। 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 এমবি মেমরি ব্যবহার করছি। সমস্যাটি সমাধান করতে এবং প্রচুর অর্থ হারাবেন না, আমাদের কাজটি কীভাবে সমান্তরাল করা যায় তা বের করতে হয়েছিল। ভাগ্যক্রমে, একটি একেবারে আশ্চর্যজনক বইয়ে কমান্ড লাইনে ডেটা সায়েন্স আমি সমান্তরালকরণের উপর Jeron Janssens এর একটি অধ্যায় খুঁজে পেয়েছি। এটা থেকে আমি সম্পর্কে শিখেছি gnu parallel, ইউনিক্সে মাল্টিথ্রেডিং বাস্তবায়নের জন্য একটি খুব নমনীয় পদ্ধতি।

যখন আমি নতুন প্রক্রিয়া ব্যবহার করে বিভাজন শুরু করি, তখন সবকিছু ঠিকঠাক ছিল, তবে এখনও একটি বাধা ছিল - ডিস্কে S3 অবজেক্ট ডাউনলোড করা খুব দ্রুত ছিল না এবং সম্পূর্ণ সমান্তরাল ছিল না। এটি ঠিক করতে, আমি এটি করেছি:

1. আমি খুঁজে পেয়েছি যে ডিস্কের মধ্যবর্তী সঞ্চয়স্থান সম্পূর্ণরূপে বাদ দিয়ে, পাইপলাইনে সরাসরি S3 ডাউনলোড স্টেজ বাস্তবায়ন করা সম্ভব। এর মানে হল আমি ডিস্কে কাঁচা ডেটা লেখা এড়াতে পারি এবং আরও ছোট, এবং সেইজন্য সস্তা, AWS-এ স্টোরেজ ব্যবহার করতে পারি।
2. টীম aws configure set default.s3.max_concurrent_requests 50 AWS CLI ব্যবহার করে এমন থ্রেডের সংখ্যা ব্যাপকভাবে বৃদ্ধি করেছে (ডিফল্টরূপে 10টি আছে)।
3. আমি নামের মধ্যে n অক্ষর সহ নেটওয়ার্ক গতির জন্য অপ্টিমাইজ করা একটি EC2 উদাহরণে স্যুইচ করেছি। আমি দেখেছি যে এন-ইনস্ট্যান্স ব্যবহার করার সময় প্রক্রিয়াকরণ শক্তির ক্ষতি লোডিং গতি বৃদ্ধির দ্বারা ক্ষতিপূরণের চেয়ে বেশি। বেশিরভাগ কাজের জন্য আমি c5n.4xl ব্যবহার করেছি।
4. পরিবর্তন করা হয়েছে gzip উপর pigz, এটি একটি জিজিপ টুল যা ফাইল ডিকম্প্রেস করার প্রাথমিকভাবে অ-সমান্তরাল কাজকে সমান্তরাল করার জন্য দুর্দান্ত জিনিস করতে পারে (এটি সবচেয়ে কম সাহায্য করেছে)।

# 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-সমান্তরালকে ধন্যবাদ আমি একটি 19gig csv আনজিপ এবং বিভক্ত করতে পারি যত দ্রুত আমি এটি ডাউনলোড করতে পারি। আমি এটি চালানোর জন্য স্পার্কও পেতে পারিনি। # ডেটাসায়েন্স #Linux pic.twitter.com/Nqyba2zqEk

— নিক স্ট্রেয়ার (@নিকোলাসস্ট্রেয়ার) 17 পারে, 2019

এই টুইটটিতে 'TSV' উল্লেখ করা উচিত ছিল। হায় হায়।

নতুন পার্স করা ডেটা ব্যবহার করা হচ্ছে

আমি কি শিখেছি: স্পার্ক অসংকুচিত ডেটা পছন্দ করে এবং পার্টিশনের সমন্বয় পছন্দ করে না।

এখন ডেটা S3 তে একটি আনপ্যাকড (পড়ুন: ভাগ করা) এবং আধা-অর্ডার ফরম্যাটে ছিল এবং আমি আবার স্পার্ক-এ ফিরে যেতে পারি। একটি বিস্ময় আমার জন্য অপেক্ষা করছিল: আমি যা চেয়েছিলাম তা অর্জন করতে আবার ব্যর্থ হয়েছি! স্পার্ককে ঠিক কীভাবে ডেটা বিভাজন করা হয়েছিল তা বলা খুব কঠিন ছিল। এবং এমনকি যখন আমি এটি করেছি, দেখা গেল যে অনেকগুলি পার্টিশন ছিল (95 হাজার), এবং যখন আমি ব্যবহার করি coalesce তাদের সংখ্যা যুক্তিসঙ্গত সীমাতে হ্রাস করেছে, এটি আমার পার্টিশন ধ্বংস করেছে। আমি নিশ্চিত যে এটি ঠিক করা যেতে পারে, কিন্তু কয়েক দিনের অনুসন্ধানের পরে আমি একটি সমাধান খুঁজে পাইনি। আমি অবশেষে স্পার্কের সমস্ত কাজ শেষ করেছি, যদিও এটি কিছু সময় নেয় এবং আমার বিভক্ত Parquet ফাইলগুলি খুব ছোট ছিল না (~200 KB)। যাইহোক, তথ্য যেখানে এটি প্রয়োজন ছিল.

খুব ছোট এবং অসম, বিস্ময়কর!

স্থানীয় স্পার্ক প্রশ্ন পরীক্ষা করা হচ্ছে

আমি কি শিখেছি: সহজ সমস্যা সমাধান করার সময় স্পার্কের খুব বেশি ওভারহেড আছে।

একটি চতুর বিন্যাসে ডেটা ডাউনলোড করে, আমি গতি পরীক্ষা করতে সক্ষম হয়েছি। একটি স্থানীয় স্পার্ক সার্ভার চালানোর জন্য একটি R স্ক্রিপ্ট সেট আপ করুন, এবং তারপর নির্দিষ্ট Parquet গ্রুপ স্টোরেজ (বিন) থেকে একটি স্পার্ক ডেটা ফ্রেম লোড করুন৷ আমি সমস্ত ডেটা লোড করার চেষ্টা করেছি কিন্তু পার্টিশন চিনতে Sparklyr পেতে পারিনি।

sc <- Spark_connect(master = "local")

desired_snp <- 'rs34771739'

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

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

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

print(Sys.time() - start_time)

মৃত্যুদন্ড কার্যকর করতে 29,415 সেকেন্ড সময় লেগেছিল। অনেক ভালো, কিন্তু কোনো কিছুর ভর পরীক্ষার জন্য খুব ভালো নয়। অতিরিক্তভাবে, আমি ক্যাশিংয়ের সাথে জিনিসগুলিকে গতি বাড়াতে পারিনি কারণ যখন আমি মেমরিতে একটি ডেটা ফ্রেম ক্যাশ করার চেষ্টা করেছি, তখন স্পার্ক সবসময় ক্র্যাশ হয়ে যায়, এমনকি যখন আমি 50-এর কম ওজনের ডেটাসেটে 15 গিগাবাইটের বেশি মেমরি বরাদ্দ করি।

AWK-এ ফেরত যান

আমি কি শিখেছি: AWK-তে সহযোগী অ্যারেগুলি খুব দক্ষ।

আমি বুঝতে পেরেছিলাম যে আমি উচ্চ গতি অর্জন করতে পারি। আমি একটি বিস্ময়কর মধ্যে যে মনে আছে ব্রুস বার্নেট দ্বারা AWK টিউটোরিয়াল আমি একটি দুর্দান্ত বৈশিষ্ট্য সম্পর্কে পড়েছি যার নাম "সহযোগী অ্যারে" মূলত, এগুলি কী-মানের জোড়া, যেগুলিকে কিছু কারণে AWK-তে আলাদাভাবে বলা হয়েছিল, এবং সেইজন্য আমি কোনওভাবে সেগুলি সম্পর্কে খুব বেশি ভাবিনি। রোমান চেপলিয়াকা প্রত্যাহার করা হয়েছে যে "সহযোগী অ্যারে" শব্দটি "কী-মান জোড়া" শব্দের চেয়ে অনেক পুরানো। এমনকি যদি আপনি গুগল এনগ্রামে কী-মান দেখুন, আপনি সেখানে এই শব্দটি দেখতে পাবেন না, তবে আপনি সহযোগী অ্যারেগুলি পাবেন! উপরন্তু, "কী-মান জোড়া" প্রায়শই ডাটাবেসের সাথে যুক্ত থাকে, তাই এটি একটি হ্যাশম্যাপের সাথে তুলনা করা অনেক বেশি বোধগম্য। আমি বুঝতে পেরেছিলাম যে স্পার্ক ব্যবহার না করেই আমি আমার এসএনপিগুলিকে একটি বিন টেবিল এবং কাঁচা ডেটার সাথে সংযুক্ত করতে এই সহযোগী অ্যারেগুলি ব্যবহার করতে পারি৷

এটি করার জন্য, 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 স্ক্রিপ্ট থেকে, এবং তাই এটি পাইপলাইনে ব্যবহার করুন।

আপনি আপনার ব্যাশ স্ক্রিপ্টে এই লাইনটি লক্ষ্য করেছেন: ...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 ব্যবহার সত্ত্বেও, সবকিছু খুব দ্রুত কাজ করে। আশ্চর্যের বিষয় নয়, R-এর অংশগুলি যেগুলি ডেটা পড়তে এবং লিখতে পারে সেগুলি অত্যন্ত অপ্টিমাইজ করা হয়েছে৷ একটি মাঝারি আকারের ক্রোমোজোমের উপর পরীক্ষা করার পরে, কাজটি প্রায় দুই ঘন্টার মধ্যে একটি C5n.4xl উদাহরণে সম্পন্ন হয়।

S3 সীমাবদ্ধতা

আমি কি শিখেছি: স্মার্ট পাথ বাস্তবায়নের জন্য ধন্যবাদ, S3 অনেক ফাইল পরিচালনা করতে পারে।

আমি চিন্তিত ছিলাম যে S3 এটিতে স্থানান্তরিত অনেক ফাইল পরিচালনা করতে সক্ষম হবে কিনা। আমি ফাইলের নামগুলিকে বোধগম্য করতে পারি, কিন্তু S3 কীভাবে তাদের সন্ধান করবে?

S3-এ ফোল্ডারগুলি কেবল দেখানোর জন্য, আসলে সিস্টেমটি প্রতীকটিতে আগ্রহী নয় /. S3 FAQ পৃষ্ঠা থেকে।

দেখা যাচ্ছে যে S3 হ্যাশ টেবিল বা ডকুমেন্ট-ভিত্তিক ডাটাবেসের একটি সাধারণ কী হিসাবে একটি নির্দিষ্ট ফাইলের পথকে উপস্থাপন করে। একটি বালতিকে একটি টেবিল হিসাবে ভাবা যেতে পারে এবং ফাইলগুলিকে সেই টেবিলের রেকর্ড হিসাবে বিবেচনা করা যেতে পারে।

যেহেতু অ্যামাজনে লাভ করার জন্য গতি এবং দক্ষতা গুরুত্বপূর্ণ, এতে অবাক হওয়ার কিছু নেই যে এই কী-এ-এ-ফাইল-পাথ সিস্টেমটি অপ্টিমাইজ করা হচ্ছে। আমি একটি ভারসাম্য খুঁজে বের করার চেষ্টা করেছি: যাতে আমাকে প্রচুর অনুরোধ করতে হয় না, তবে অনুরোধগুলি দ্রুত কার্যকর হয়। দেখা গেল যে প্রায় 20 হাজার বিন ফাইল তৈরি করা ভাল। আমি মনে করি যদি আমরা অপ্টিমাইজ করতে থাকি তবে আমরা গতি বৃদ্ধি পেতে পারি (উদাহরণস্বরূপ, শুধুমাত্র ডেটার জন্য একটি বিশেষ বালতি তৈরি করা, এইভাবে লুকআপ টেবিলের আকার হ্রাস করা)। কিন্তু পরবর্তী পরীক্ষার জন্য সময় বা অর্থ ছিল না।

ক্রস সামঞ্জস্য সম্পর্কে কি?

আমি যা শিখেছি: সময় নষ্ট করার এক নম্বর কারণ হল আপনার স্টোরেজ পদ্ধতিকে অসময়ে অপ্টিমাইজ করা।

এই মুহুর্তে, নিজেকে জিজ্ঞাসা করা খুবই গুরুত্বপূর্ণ: "কেন একটি মালিকানাধীন ফাইল বিন্যাস ব্যবহার করুন?" কারণটি লোড হওয়ার গতি (জিজিপড CSV ফাইলগুলি লোড হতে 7 গুণ বেশি সময় নেয়) এবং আমাদের ওয়ার্কফ্লোগুলির সাথে সামঞ্জস্যপূর্ণ। R যদি স্পার্ক লোড ছাড়াই Parquet (বা তীর) ফাইল সহজে লোড করতে পারে তাহলে আমি পুনর্বিবেচনা করতে পারি। আমাদের ল্যাবের প্রত্যেকেই আর ব্যবহার করে, এবং যদি আমার ডেটাটিকে অন্য ফর্ম্যাটে রূপান্তর করতে হয়, আমার কাছে এখনও মূল পাঠ্য ডেটা রয়েছে, তাই আমি আবার পাইপলাইন চালাতে পারি।

কাজ বণ্টন

আমি কি শিখেছি: ম্যানুয়ালি কাজ অপ্টিমাইজ করার চেষ্টা করবেন না, কম্পিউটারকে করতে দিন।

আমি একটি ক্রোমোসোমে ওয়ার্কফ্লো ডিবাগ করেছি, এখন আমাকে অন্যান্য সমস্ত ডেটা প্রক্রিয়া করতে হবে।
আমি রূপান্তরের জন্য বেশ কয়েকটি EC2 দৃষ্টান্ত বাড়াতে চেয়েছিলাম, কিন্তু একই সময়ে আমি বিভিন্ন প্রক্রিয়াকরণের কাজগুলিতে খুব ভারসাম্যহীন লোড পাওয়ার ভয় পেয়েছিলাম (যেমন স্পার্ক ভারসাম্যহীন পার্টিশনের কারণে ভুগছিল)। উপরন্তু, আমি প্রতি ক্রোমোজোমে একটি উদাহরণ বাড়াতে আগ্রহী ছিলাম না, কারণ AWS অ্যাকাউন্টের জন্য 10টি দৃষ্টান্তের একটি ডিফল্ট সীমা রয়েছে।

তারপরে আমি প্রক্রিয়াকরণের কাজগুলি অপ্টিমাইজ করার জন্য R এ একটি স্ক্রিপ্ট লেখার সিদ্ধান্ত নিয়েছি।

প্রথমে, আমি S3 কে প্রতিটি ক্রোমোজোমের কতটা স্টোরেজ স্পেস আছে তা গণনা করতে বলেছিলাম।

library(aws.s3)
library(tidyverse)

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



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

তারপরে আমি একটি ফাংশন লিখেছিলাম যা মোট আকার নেয়, ক্রোমোজোমের ক্রম পরিবর্তন করে, তাদের দলে ভাগ করে num_jobs এবং আপনাকে বলে যে সমস্ত প্রক্রিয়াকরণ কাজের মাপ কতটা আলাদা।

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

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

shuffle_job(1)



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

তারপর আমি purrr ব্যবহার করে এক হাজার হাতবদল দিয়ে দৌড়েছি এবং সেরাটি বেছে নিয়েছি।

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

তাই আমি কাজগুলির একটি সেট দিয়ে শেষ করেছি যা আকারে খুব একই রকম ছিল। তারপর যা বাকি ছিল তা হল একটি বড় লুপে আমার আগের ব্যাশ স্ক্রিপ্টটি মোড়ানো for. এই অপ্টিমাইজেশানটি লিখতে প্রায় 10 মিনিট সময় নিয়েছে৷ এবং এটি ভারসাম্যহীন থাকলে ম্যানুয়ালি কাজগুলি তৈরিতে আমি ব্যয় করার চেয়ে অনেক কম। অতএব, আমি মনে করি যে আমি এই প্রাথমিক অপ্টিমাইজেশনের সাথে সঠিক ছিলাম।

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

শেষে আমি শাটডাউন কমান্ড যোগ করি:

sudo shutdown -h now

... এবং সবকিছু কাজ করে! AWS CLI ব্যবহার করে, আমি বিকল্পটি ব্যবহার করে উদাহরণ উত্থাপন করেছি user_data প্রক্রিয়াকরণের জন্য তাদের কাজের ব্যাশ স্ক্রিপ্ট দিয়েছে। তারা দৌড়ে এবং স্বয়ংক্রিয়ভাবে বন্ধ হয়ে যায়, তাই আমি অতিরিক্ত প্রক্রিয়াকরণ শক্তির জন্য অর্থ প্রদান করছিলাম না।

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

এর প্যাক করা যাক!

আমি কি শিখেছি: এপিআই সহজ এবং ব্যবহারের নমনীয়তার জন্য সহজ হওয়া উচিত।

অবশেষে আমি সঠিক জায়গায় এবং ফর্ম তথ্য পেয়েছিলাম. আমার সহকর্মীদের জন্য এটি সহজ করার জন্য যতটা সম্ভব ডেটা ব্যবহার করার প্রক্রিয়াটিকে সহজ করা ছিল। আমি অনুরোধ তৈরি করার জন্য একটি সাধারণ API তৈরি করতে চেয়েছিলাম। ভবিষ্যতে যদি আমি থেকে স্যুইচ করার সিদ্ধান্ত নেয় .rds Parquet ফাইলে, তাহলে এটি আমার জন্য একটি সমস্যা হওয়া উচিত, আমার সহকর্মীদের জন্য নয়। এর জন্য আমি একটি অভ্যন্তরীণ আর প্যাকেজ তৈরি করার সিদ্ধান্ত নিয়েছি।

একটি ফাংশনের চারপাশে সংগঠিত মাত্র কয়েকটি ডেটা অ্যাক্সেস ফাংশন ধারণকারী একটি খুব সাধারণ প্যাকেজ তৈরি এবং নথিভুক্ত করুন get_snp. আমি আমার সহকর্মীদের জন্য একটি ওয়েবসাইটও তৈরি করেছি pkgdown, তাই তারা সহজেই উদাহরণ এবং ডকুমেন্টেশন দেখতে পারে।

স্মার্ট ক্যাশিং

আমি কি শিখেছি: আপনার ডেটা ভালোভাবে প্রস্তুত থাকলে ক্যাশে করা সহজ হবে!

যেহেতু প্রধান ওয়ার্কফ্লোগুলির মধ্যে একটি SNP প্যাকেজে একই বিশ্লেষণ মডেল প্রয়োগ করেছে, তাই আমি আমার সুবিধার জন্য বিনিং ব্যবহার করার সিদ্ধান্ত নিয়েছি। SNP এর মাধ্যমে ডেটা প্রেরণ করার সময়, গ্রুপ (বিন) থেকে সমস্ত তথ্য প্রত্যাবর্তিত বস্তুর সাথে সংযুক্ত থাকে। অর্থাৎ, পুরানো প্রশ্নগুলি (তত্ত্বগতভাবে) নতুন প্রশ্নের প্রক্রিয়াকরণের গতি বাড়িয়ে তুলতে পারে।

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

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

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

প্যাকেজ তৈরি করার সময়, আমি বিভিন্ন পদ্ধতি ব্যবহার করার সময় গতির তুলনা করার জন্য অনেক বেঞ্চমার্ক চালিয়েছিলাম। আমি এটিকে অবহেলা না করার পরামর্শ দিই, কারণ কখনও কখনও ফলাফল অপ্রত্যাশিত হয়। উদাহরণ স্বরূপ, dplyr::filter ইন্ডেক্সিং-ভিত্তিক ফিল্টারিং ব্যবহার করে সারি ক্যাপচার করার চেয়ে অনেক দ্রুত, এবং ফিল্টার করা ডেটা ফ্রেম থেকে একটি একক কলাম পুনরুদ্ধার করা ইন্ডেক্সিং সিনট্যাক্স ব্যবহার করার চেয়ে অনেক দ্রুত।

অনুগ্রহ করে লক্ষ্য করুন যে বস্তুটি prev_snp_results চাবি ধারণ করে snps_in_bin. এটি একটি গ্রুপে (বিন) সমস্ত অনন্য 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 
}

Результаты

এখন আমরা এমন মডেল এবং দৃশ্যকল্প চালাতে পারি (এবং গুরুত্ব সহকারে শুরু করেছি) যা আগে আমাদের কাছে অ্যাক্সেসযোগ্য ছিল না। সবচেয়ে ভালো ব্যাপার হলো আমার ল্যাব সহকর্মীদের কোনো জটিলতা নিয়ে ভাবতে হবে না। তারা শুধু কাজ করে একটি ফাংশন আছে.

এবং যদিও প্যাকেজটি তাদের বিশদ বিবরণ দেয়, আমি ডেটা বিন্যাসটিকে যথেষ্ট সহজ করার চেষ্টা করেছি যাতে তারা এটি বের করতে পারে যদি আমি আগামীকাল হঠাৎ অদৃশ্য হয়ে যাই...

গতি লক্ষণীয়ভাবে বৃদ্ধি পেয়েছে। আমরা সাধারণত কার্যকরীভাবে উল্লেখযোগ্য জিনোম খণ্ড স্ক্যান করি। পূর্বে, আমরা এটি করতে পারিনি (এটি খুব ব্যয়বহুল ছিল), কিন্তু এখন, গ্রুপ (বিন) গঠন এবং ক্যাশিংয়ের জন্য ধন্যবাদ, একটি এসএনপির জন্য অনুরোধ গড়ে 0,1 সেকেন্ডের কম সময় নেয় এবং ডেটা ব্যবহার তাই কম যে S3 জন্য খরচ চিনাবাদাম হয়.

সম্প্রতি আমি আমার ল্যাবের জন্য 25+ টিবি কাঁচা জিনোটাইপিং ডেটার ঝগড়া পরিবর্তন করতে পেরেছি। আমি যখন শুরু করেছি, স্পার্ক ব্যবহার করতে 8 মিনিট সময় লেগেছে এবং একটি SNP জিজ্ঞাসা করতে $20 খরচ হয়েছে৷ AWK+ ব্যবহার করার পর #সংখ্যা প্রক্রিয়া করতে, এটি এখন সেকেন্ডের 10তমেরও কম সময় নেয় এবং খরচ হয় $0.00001৷ আমার ব্যক্তিগত # বিগডাটা জিত pic.twitter.com/ANOXVGrmkk

— নিক স্ট্রেয়ার (@নিকোলাসস্ট্রেয়ার) 30 পারে, 2019

উপসংহার

এই নিবন্ধটি মোটেই একটি নির্দেশিকা নয়। সমাধানটি স্বতন্ত্র হতে পরিণত হয়েছে এবং প্রায় অবশ্যই সর্বোত্তম নয়। বরং এটি একটি ভ্রমণকাহিনী। আমি অন্যদের বুঝতে চাই যে এই জাতীয় সিদ্ধান্তগুলি পুরোপুরি মাথার মধ্যে তৈরি হয় না, তারা বিচার এবং ত্রুটির ফলাফল। এছাড়াও, আপনি যদি একজন ডেটা সায়েন্টিস্ট খুঁজছেন, মনে রাখবেন যে এই টুলগুলি কার্যকরভাবে ব্যবহার করার জন্য অভিজ্ঞতা প্রয়োজন এবং অভিজ্ঞতার জন্য অর্থ খরচ হয়। আমি খুশি যে আমার অর্থ প্রদানের উপায় ছিল, তবে আরও অনেক যারা একই কাজটি আমার চেয়ে ভাল করতে পারে তারা অর্থের অভাবে চেষ্টা করার সুযোগ পাবে না।

বড় ডেটা টুল বহুমুখী। আপনার কাছে সময় থাকলে, আপনি স্মার্ট ডেটা ক্লিনিং, স্টোরেজ এবং নিষ্কাশন কৌশলগুলি ব্যবহার করে প্রায় অবশ্যই একটি দ্রুত সমাধান লিখতে পারেন। শেষ পর্যন্ত এটি একটি খরচ-সুবিধা বিশ্লেষণে নেমে আসে।

আমি যা শিখেছি:

• একবারে 25 টিবি পার্স করার কোন সস্তা উপায় নেই;
• আপনার Parquet ফাইল এবং তাদের প্রতিষ্ঠানের আকার সম্পর্কে সতর্ক থাকুন;
• স্পার্কের পার্টিশন অবশ্যই ভারসাম্যপূর্ণ হতে হবে;
• সাধারণভাবে, 2,5 মিলিয়ন পার্টিশন করার চেষ্টা করবেন না;
• বাছাই করা এখনও কঠিন, যেমন স্পার্ক স্থাপন করা হচ্ছে;
• কখনও কখনও বিশেষ তথ্য বিশেষ সমাধান প্রয়োজন;
• স্পার্ক একত্রিতকরণ দ্রুত, কিন্তু পার্টিশন এখনও ব্যয়বহুল;
• যখন তারা আপনাকে মৌলিক বিষয়গুলি শেখায় তখন ঘুমাবেন না, কেউ সম্ভবত 1980 এর দশকে আপনার সমস্যার সমাধান করেছে;
• gnu parallel - এটি একটি যাদুকরী জিনিস, প্রত্যেকেরই এটি ব্যবহার করা উচিত;
• স্পার্ক অসংকুচিত ডেটা পছন্দ করে এবং পার্টিশনের সমন্বয় পছন্দ করে না;
• সহজ সমস্যা সমাধান করার সময় স্পার্কের অত্যধিক ওভারহেড আছে;
• AWK এর সহযোগী অ্যারেগুলি খুব দক্ষ;
• আপনি যোগাযোগ করতে পারেন stdin и stdout একটি R স্ক্রিপ্ট থেকে, এবং তাই এটি পাইপলাইনে ব্যবহার করুন;
• স্মার্ট পাথ বাস্তবায়নের জন্য ধন্যবাদ, S3 অনেক ফাইল প্রক্রিয়া করতে পারে;
• সময় নষ্ট করার প্রধান কারণ হল অকালে আপনার স্টোরেজ পদ্ধতি অপ্টিমাইজ করা;
• ম্যানুয়ালি কাজগুলি অপ্টিমাইজ করার চেষ্টা করবেন না, কম্পিউটারকে এটি করতে দিন;
• ব্যবহারের সহজতা এবং নমনীয়তার জন্য API সহজ হওয়া উচিত;
• আপনার ডেটা ভালভাবে প্রস্তুত থাকলে, ক্যাশে করা সহজ হবে!

উত্স: www.habr.com