ਇਸ ਲੇਖ ਨੂੰ ਕਿਵੇਂ ਪੜ੍ਹਨਾ ਹੈ: ਲਿਖਤ ਦੇ ਇੰਨੇ ਲੰਬੇ ਅਤੇ ਅਰਾਜਕ ਹੋਣ ਲਈ ਮੈਂ ਮੁਆਫੀ ਚਾਹੁੰਦਾ ਹਾਂ। ਤੁਹਾਡਾ ਸਮਾਂ ਬਚਾਉਣ ਲਈ, ਮੈਂ ਹਰੇਕ ਅਧਿਆਇ ਨੂੰ "ਮੈਂ ਕੀ ਸਿੱਖਿਆ" ਦੀ ਜਾਣ-ਪਛਾਣ ਨਾਲ ਸ਼ੁਰੂ ਕਰਦਾ ਹਾਂ, ਜੋ ਅਧਿਆਇ ਦੇ ਸਾਰ ਨੂੰ ਇੱਕ ਜਾਂ ਦੋ ਵਾਕਾਂ ਵਿੱਚ ਸੰਖੇਪ ਕਰਦਾ ਹੈ।

"ਬੱਸ ਮੈਨੂੰ ਹੱਲ ਦਿਖਾਓ!" ਜੇਕਰ ਤੁਸੀਂ ਸਿਰਫ਼ ਇਹ ਦੇਖਣਾ ਚਾਹੁੰਦੇ ਹੋ ਕਿ ਮੈਂ ਕਿੱਥੋਂ ਆਇਆ ਹਾਂ, ਤਾਂ "ਹੋਰ ਖੋਜੀ ਬਣਨਾ" ਅਧਿਆਇ 'ਤੇ ਜਾਓ, ਪਰ ਮੈਨੂੰ ਲੱਗਦਾ ਹੈ ਕਿ ਅਸਫਲਤਾ ਬਾਰੇ ਪੜ੍ਹਨਾ ਵਧੇਰੇ ਦਿਲਚਸਪ ਅਤੇ ਲਾਭਦਾਇਕ ਹੈ।

ਮੈਨੂੰ ਹਾਲ ਹੀ ਵਿੱਚ ਕੱਚੇ ਡੀਐਨਏ ਕ੍ਰਮ (ਤਕਨੀਕੀ ਤੌਰ 'ਤੇ ਇੱਕ SNP ਚਿੱਪ) ਦੀ ਇੱਕ ਵੱਡੀ ਮਾਤਰਾ ਨੂੰ ਪ੍ਰੋਸੈਸ ਕਰਨ ਲਈ ਇੱਕ ਪ੍ਰਕਿਰਿਆ ਸਥਾਪਤ ਕਰਨ ਦਾ ਕੰਮ ਸੌਂਪਿਆ ਗਿਆ ਸੀ। ਬਾਅਦ ਦੇ ਮਾਡਲਿੰਗ ਅਤੇ ਹੋਰ ਕੰਮਾਂ ਲਈ ਇੱਕ ਦਿੱਤੇ ਜੈਨੇਟਿਕ ਸਥਾਨ (ਜਿਸਨੂੰ SNP ਕਿਹਾ ਜਾਂਦਾ ਹੈ) ਬਾਰੇ ਤੇਜ਼ੀ ਨਾਲ ਡਾਟਾ ਪ੍ਰਾਪਤ ਕਰਨ ਦੀ ਲੋੜ ਸੀ। R ਅਤੇ AWK ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋਏ, ਮੈਂ ਇੱਕ ਕੁਦਰਤੀ ਤਰੀਕੇ ਨਾਲ ਡੇਟਾ ਨੂੰ ਸਾਫ਼ ਅਤੇ ਸੰਗਠਿਤ ਕਰਨ ਦੇ ਯੋਗ ਸੀ, ਜਿਸ ਨਾਲ ਪੁੱਛਗਿੱਛ ਪ੍ਰਕਿਰਿਆ ਨੂੰ ਬਹੁਤ ਤੇਜ਼ ਕੀਤਾ ਗਿਆ ਸੀ। ਇਹ ਮੇਰੇ ਲਈ ਆਸਾਨ ਨਹੀਂ ਸੀ ਅਤੇ ਕਈ ਦੁਹਰਾਓ ਦੀ ਲੋੜ ਸੀ। ਇਹ ਲੇਖ ਤੁਹਾਡੀਆਂ ਕੁਝ ਗਲਤੀਆਂ ਤੋਂ ਬਚਣ ਵਿੱਚ ਤੁਹਾਡੀ ਮਦਦ ਕਰੇਗਾ ਅਤੇ ਤੁਹਾਨੂੰ ਇਹ ਦਿਖਾਉਣ ਵਿੱਚ ਮਦਦ ਕਰੇਗਾ ਕਿ ਮੈਂ ਕੀ ਕੀਤਾ।

ਪਹਿਲਾਂ, ਕੁਝ ਸ਼ੁਰੂਆਤੀ ਵਿਆਖਿਆਵਾਂ।

ਡਾਟਾ

ਸਾਡੇ ਯੂਨੀਵਰਸਿਟੀ ਜੈਨੇਟਿਕ ਇਨਫਰਮੇਸ਼ਨ ਪ੍ਰੋਸੈਸਿੰਗ ਸੈਂਟਰ ਨੇ ਸਾਨੂੰ 25 TB TSV ਦੇ ਰੂਪ ਵਿੱਚ ਡੇਟਾ ਪ੍ਰਦਾਨ ਕੀਤਾ ਹੈ। ਮੈਂ ਉਹਨਾਂ ਨੂੰ 5 ਪੈਕੇਜਾਂ ਵਿੱਚ ਵੰਡਿਆ ਹੋਇਆ, Gzip ਦੁਆਰਾ ਸੰਕੁਚਿਤ ਕੀਤਾ, ਜਿਸ ਵਿੱਚ ਹਰ ਇੱਕ ਵਿੱਚ ਲਗਭਗ 240 ਚਾਰ-ਗੀਗਾਬਾਈਟ ਫਾਈਲਾਂ ਸਨ। ਹਰੇਕ ਕਤਾਰ ਵਿੱਚ ਇੱਕ ਵਿਅਕਤੀ ਤੋਂ ਇੱਕ SNP ਲਈ ਡੇਟਾ ਹੁੰਦਾ ਹੈ। ਕੁੱਲ ਮਿਲਾ ਕੇ, ~ 2,5 ਮਿਲੀਅਨ SNPs ਅਤੇ ~ 60 ਹਜ਼ਾਰ ਲੋਕਾਂ ਦਾ ਡੇਟਾ ਪ੍ਰਸਾਰਿਤ ਕੀਤਾ ਗਿਆ ਸੀ। SNP ਜਾਣਕਾਰੀ ਤੋਂ ਇਲਾਵਾ, ਫਾਈਲਾਂ ਵਿੱਚ ਵੱਖ-ਵੱਖ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਨੂੰ ਦਰਸਾਉਣ ਵਾਲੇ ਨੰਬਰਾਂ ਦੇ ਨਾਲ ਕਈ ਕਾਲਮ ਹੁੰਦੇ ਹਨ, ਜਿਵੇਂ ਕਿ ਪੜ੍ਹਨ ਦੀ ਤੀਬਰਤਾ, ​​ਵੱਖ-ਵੱਖ ਐਲੀਲਾਂ ਦੀ ਬਾਰੰਬਾਰਤਾ, ਆਦਿ। ਕੁੱਲ ਮਿਲਾ ਕੇ ਵਿਲੱਖਣ ਮੁੱਲਾਂ ਵਾਲੇ ਲਗਭਗ 30 ਕਾਲਮ ਸਨ।

ਟੀਚਾ

ਜਿਵੇਂ ਕਿ ਕਿਸੇ ਵੀ ਡੇਟਾ ਪ੍ਰਬੰਧਨ ਪ੍ਰੋਜੈਕਟ ਦੇ ਨਾਲ, ਸਭ ਤੋਂ ਮਹੱਤਵਪੂਰਨ ਗੱਲ ਇਹ ਨਿਰਧਾਰਤ ਕਰਨਾ ਸੀ ਕਿ ਡੇਟਾ ਦੀ ਵਰਤੋਂ ਕਿਵੇਂ ਕੀਤੀ ਜਾਵੇਗੀ। ਇਸ ਮਾਮਲੇ ਵਿੱਚ ਅਸੀਂ ਜਿਆਦਾਤਰ SNP ਦੇ ਅਧਾਰ ਤੇ SNP ਲਈ ਮਾਡਲ ਅਤੇ ਵਰਕਫਲੋ ਦੀ ਚੋਣ ਕਰਾਂਗੇ. ਭਾਵ, ਸਾਨੂੰ ਇੱਕ ਸਮੇਂ ਵਿੱਚ ਸਿਰਫ ਇੱਕ SNP 'ਤੇ ਡੇਟਾ ਦੀ ਲੋੜ ਪਵੇਗੀ। ਮੈਨੂੰ ਇਹ ਸਿੱਖਣਾ ਪਿਆ ਕਿ 2,5 ਮਿਲੀਅਨ SNPs ਵਿੱਚੋਂ ਇੱਕ ਨਾਲ ਜੁੜੇ ਸਾਰੇ ਰਿਕਾਰਡਾਂ ਨੂੰ ਜਿੰਨੀ ਆਸਾਨੀ ਨਾਲ, ਜਲਦੀ ਅਤੇ ਸਸਤੇ ਤੌਰ 'ਤੇ ਸੰਭਵ ਹੋ ਸਕੇ ਮੁੜ ਪ੍ਰਾਪਤ ਕਰਨਾ ਹੈ।

ਇਹ ਕਿਵੇਂ ਨਹੀਂ ਕਰਨਾ ਹੈ

ਇੱਕ ਢੁਕਵੀਂ ਕਲੀਚ ਦਾ ਹਵਾਲਾ ਦੇਣ ਲਈ:

ਮੈਂ ਇੱਕ ਹਜ਼ਾਰ ਵਾਰ ਅਸਫਲ ਨਹੀਂ ਹੋਇਆ, ਮੈਂ ਇੱਕ ਸਵਾਲ-ਅਨੁਕੂਲ ਫਾਰਮੈਟ ਵਿੱਚ ਡੇਟਾ ਦੇ ਇੱਕ ਸਮੂਹ ਨੂੰ ਪਾਰਸ ਕਰਨ ਤੋਂ ਬਚਣ ਦੇ ਇੱਕ ਹਜ਼ਾਰ ਤਰੀਕੇ ਲੱਭੇ ਹਨ।

ਪਹਿਲੀ ਕੋਸ਼ਿਸ਼

ਮੈਂ ਕੀ ਸਿੱਖਿਆ ਹੈ: ਇੱਕ ਵਾਰ ਵਿੱਚ 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 ਫਾਈਲਾਂ ਦੇ ਆਕਾਰ ਅਤੇ ਉਹਨਾਂ ਦੇ ਸੰਗਠਨ ਨਾਲ ਸਾਵਧਾਨ ਰਹੋ।

ਮੈਂ ਸਭ ਤੋਂ ਪਹਿਲਾਂ ਸਾਰੀਆਂ TSVs ਨੂੰ ਬਦਲ ਕੇ ਸਥਿਤੀ ਨੂੰ ਠੀਕ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕੀਤੀ Parquet ਫਾਇਲ. ਉਹ ਵੱਡੇ ਡੇਟਾ ਸੈੱਟਾਂ ਨਾਲ ਕੰਮ ਕਰਨ ਲਈ ਸੁਵਿਧਾਜਨਕ ਹਨ ਕਿਉਂਕਿ ਉਹਨਾਂ ਵਿੱਚ ਜਾਣਕਾਰੀ ਕਾਲਮ ਰੂਪ ਵਿੱਚ ਸਟੋਰ ਕੀਤੀ ਜਾਂਦੀ ਹੈ: ਹਰੇਕ ਕਾਲਮ ਟੈਕਸਟ ਫਾਈਲਾਂ ਦੇ ਉਲਟ, ਆਪਣੀ ਖੁਦ ਦੀ ਮੈਮੋਰੀ/ਡਿਸਕ ਹਿੱਸੇ ਵਿੱਚ ਹੁੰਦਾ ਹੈ, ਜਿਸ ਵਿੱਚ ਹਰ ਇੱਕ ਕਾਲਮ ਦੇ ਤੱਤ ਹੁੰਦੇ ਹਨ। ਅਤੇ ਜੇ ਤੁਹਾਨੂੰ ਕੁਝ ਲੱਭਣ ਦੀ ਲੋੜ ਹੈ, ਤਾਂ ਲੋੜੀਂਦੇ ਕਾਲਮ ਨੂੰ ਪੜ੍ਹੋ. ਇਸ ਤੋਂ ਇਲਾਵਾ, ਹਰੇਕ ਫਾਈਲ ਇੱਕ ਕਾਲਮ ਵਿੱਚ ਮੁੱਲਾਂ ਦੀ ਇੱਕ ਰੇਂਜ ਨੂੰ ਸਟੋਰ ਕਰਦੀ ਹੈ, ਇਸਲਈ ਜੇਕਰ ਤੁਸੀਂ ਜੋ ਮੁੱਲ ਲੱਭ ਰਹੇ ਹੋ ਉਹ ਕਾਲਮ ਦੀ ਰੇਂਜ ਵਿੱਚ ਨਹੀਂ ਹੈ, ਤਾਂ ਸਪਾਰਕ ਪੂਰੀ ਫਾਈਲ ਨੂੰ ਸਕੈਨ ਕਰਨ ਵਿੱਚ ਸਮਾਂ ਬਰਬਾਦ ਨਹੀਂ ਕਰੇਗਾ।

ਮੈਂ ਇੱਕ ਸਧਾਰਨ ਕੰਮ ਚਲਾਇਆ AWS ਗਲੂ ਸਾਡੇ TSVs ਨੂੰ Parquet ਵਿੱਚ ਤਬਦੀਲ ਕਰਨ ਲਈ ਅਤੇ ਨਵੀਂਆਂ ਫਾਈਲਾਂ ਨੂੰ ਐਥੀਨਾ ਵਿੱਚ ਛੱਡ ਦਿੱਤਾ ਗਿਆ ਹੈ। ਇਸ ਵਿੱਚ ਲਗਭਗ 5 ਘੰਟੇ ਲੱਗ ਗਏ। ਪਰ ਜਦੋਂ ਮੈਂ ਬੇਨਤੀ ਨੂੰ ਚਲਾਇਆ, ਤਾਂ ਇਸ ਨੂੰ ਪੂਰਾ ਕਰਨ ਲਈ ਲਗਭਗ ਉਨਾ ਹੀ ਸਮਾਂ ਅਤੇ ਥੋੜਾ ਘੱਟ ਪੈਸਾ ਲੱਗਾ। ਤੱਥ ਇਹ ਹੈ ਕਿ ਸਪਾਰਕ, ​​ਕੰਮ ਨੂੰ ਅਨੁਕੂਲ ਬਣਾਉਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰ ਰਿਹਾ ਹੈ, ਬਸ ਇੱਕ TSV ਟੁਕੜੇ ਨੂੰ ਅਨਪੈਕ ਕੀਤਾ ਗਿਆ ਹੈ ਅਤੇ ਇਸਨੂੰ ਇਸਦੇ ਆਪਣੇ ਪਾਰਕਵੇਟ ਹਿੱਸੇ ਵਿੱਚ ਪਾ ਦਿੱਤਾ ਗਿਆ ਹੈ। ਅਤੇ ਕਿਉਂਕਿ ਹਰੇਕ ਟੁਕੜਾ ਬਹੁਤ ਸਾਰੇ ਲੋਕਾਂ ਦੇ ਪੂਰੇ ਰਿਕਾਰਡਾਂ ਨੂੰ ਸ਼ਾਮਲ ਕਰਨ ਲਈ ਕਾਫੀ ਵੱਡਾ ਸੀ, ਹਰੇਕ ਫਾਈਲ ਵਿੱਚ ਸਾਰੇ SNP ਸ਼ਾਮਲ ਸਨ, ਇਸਲਈ ਸਪਾਰਕ ਨੂੰ ਲੋੜੀਂਦੀ ਜਾਣਕਾਰੀ ਨੂੰ ਐਕਸਟਰੈਕਟ ਕਰਨ ਲਈ ਸਾਰੀਆਂ ਫਾਈਲਾਂ ਨੂੰ ਖੋਲ੍ਹਣਾ ਪਿਆ।

ਦਿਲਚਸਪ ਗੱਲ ਇਹ ਹੈ ਕਿ, Parquet ਦੀ ਡਿਫਾਲਟ (ਅਤੇ ਸਿਫ਼ਾਰਿਸ਼ ਕੀਤੀ) ਕੰਪਰੈਸ਼ਨ ਕਿਸਮ, ਸਨੈਪੀ, ਵੰਡਣ ਯੋਗ ਨਹੀਂ ਹੈ। ਇਸ ਲਈ, ਹਰੇਕ ਐਗਜ਼ੀਕਿਊਟਰ ਪੂਰੇ 3,5 GB ਡੇਟਾਸੈਟ ਨੂੰ ਅਨਪੈਕ ਕਰਨ ਅਤੇ ਡਾਊਨਲੋਡ ਕਰਨ ਦੇ ਕੰਮ 'ਤੇ ਫਸਿਆ ਹੋਇਆ ਸੀ।

ਆਓ ਸਮੱਸਿਆ ਨੂੰ ਸਮਝੀਏ

ਮੈਂ ਕੀ ਸਿੱਖਿਆ ਹੈ: ਛਾਂਟੀ ਕਰਨਾ ਔਖਾ ਹੈ, ਖਾਸ ਕਰਕੇ ਜੇਕਰ ਡੇਟਾ ਵੰਡਿਆ ਜਾਂਦਾ ਹੈ।

ਇਹ ਮੈਨੂੰ ਜਾਪਦਾ ਸੀ ਕਿ ਹੁਣ ਮੈਂ ਸਮੱਸਿਆ ਦਾ ਸਾਰ ਸਮਝ ਗਿਆ ਹਾਂ. ਮੈਨੂੰ ਸਿਰਫ SNP ਕਾਲਮ ਦੁਆਰਾ ਡੇਟਾ ਨੂੰ ਕ੍ਰਮਬੱਧ ਕਰਨ ਦੀ ਲੋੜ ਸੀ, ਲੋਕਾਂ ਦੁਆਰਾ ਨਹੀਂ. ਫਿਰ ਕਈ SNPs ਨੂੰ ਇੱਕ ਵੱਖਰੇ ਡੇਟਾ ਹਿੱਸੇ ਵਿੱਚ ਸਟੋਰ ਕੀਤਾ ਜਾਵੇਗਾ, ਅਤੇ ਫਿਰ Parquet ਦਾ "ਸਮਾਰਟ" ਫੰਕਸ਼ਨ "ਸਿਰਫ਼ ਤਾਂ ਹੀ ਖੁੱਲ੍ਹਦਾ ਹੈ ਜੇਕਰ ਮੁੱਲ ਰੇਂਜ ਵਿੱਚ ਹੋਵੇ" ਆਪਣੇ ਆਪ ਨੂੰ ਆਪਣੀ ਪੂਰੀ ਸ਼ਾਨ ਵਿੱਚ ਦਿਖਾਏਗਾ। ਬਦਕਿਸਮਤੀ ਨਾਲ, ਇੱਕ ਕਲੱਸਟਰ ਵਿੱਚ ਖਿੰਡੇ ਹੋਏ ਅਰਬਾਂ ਕਤਾਰਾਂ ਵਿੱਚ ਛਾਂਟੀ ਕਰਨਾ ਇੱਕ ਮੁਸ਼ਕਲ ਕੰਮ ਸਾਬਤ ਹੋਇਆ।

ਮੈਂ ਕਾਲਜ ਵਿੱਚ ਐਲਗੋਰਿਦਮ ਦੀ ਕਲਾਸ ਲੈ ਰਿਹਾ ਹਾਂ: “ਉਏ, ਕੋਈ ਵੀ ਇਹਨਾਂ ਸਾਰੇ ਛਾਂਟਣ ਵਾਲੇ ਐਲਗੋਰਿਦਮ ਦੀ ਗਣਨਾਤਮਕ ਗੁੰਝਲਤਾ ਦੀ ਪਰਵਾਹ ਨਹੀਂ ਕਰਦਾ”

ਮੈਂ ਇੱਕ 20TB ਵਿੱਚ ਇੱਕ ਕਾਲਮ 'ਤੇ ਛਾਂਟਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰ ਰਿਹਾ ਹਾਂ #ਸਪਾਰਕ ਟੇਬਲ: "ਇਹ ਇੰਨਾ ਸਮਾਂ ਕਿਉਂ ਲੈ ਰਿਹਾ ਹੈ?" # ਡੇਟਾ ਸਾਇੰਸ ਸੰਘਰਸ਼.

- ਨਿਕ ਸਟ੍ਰੇਅਰ (@ ਨਿਕੋਲਸ ਸਟ੍ਰੇਅਰ) ਮਾਰਚ 11, 2019

AWS ਯਕੀਨੀ ਤੌਰ 'ਤੇ "ਮੈਂ ਇੱਕ ਵਿਚਲਿਤ ਵਿਦਿਆਰਥੀ ਹਾਂ" ਕਾਰਨ ਰਿਫੰਡ ਜਾਰੀ ਨਹੀਂ ਕਰਨਾ ਚਾਹੁੰਦਾ ਹੈ। ਮੈਂ ਐਮਾਜ਼ਾਨ ਗਲੂ 'ਤੇ ਛਾਂਟੀ ਕਰਨ ਤੋਂ ਬਾਅਦ, ਇਹ 2 ਦਿਨਾਂ ਲਈ ਚੱਲਿਆ ਅਤੇ ਕਰੈਸ਼ ਹੋ ਗਿਆ.

ਵੰਡ ਬਾਰੇ ਕੀ?

ਮੈਂ ਕੀ ਸਿੱਖਿਆ ਹੈ: ਸਪਾਰਕ ਵਿੱਚ ਭਾਗ ਸੰਤੁਲਿਤ ਹੋਣੇ ਚਾਹੀਦੇ ਹਨ।

ਫਿਰ ਮੈਨੂੰ ਕ੍ਰੋਮੋਸੋਮਜ਼ ਵਿੱਚ ਡਾਟਾ ਵੰਡਣ ਦਾ ਵਿਚਾਰ ਆਇਆ। ਉਹਨਾਂ ਵਿੱਚੋਂ 23 ਹਨ (ਅਤੇ ਕਈ ਹੋਰ ਜੇਕਰ ਤੁਸੀਂ ਮਾਈਟੋਕੌਂਡਰੀਅਲ ਡੀਐਨਏ ਅਤੇ ਅਣਮੈਪ ਕੀਤੇ ਖੇਤਰਾਂ ਨੂੰ ਧਿਆਨ ਵਿੱਚ ਰੱਖਦੇ ਹੋ)।
ਇਹ ਤੁਹਾਨੂੰ ਡੇਟਾ ਨੂੰ ਛੋਟੇ ਹਿੱਸਿਆਂ ਵਿੱਚ ਵੰਡਣ ਦੀ ਆਗਿਆ ਦੇਵੇਗਾ. ਜੇਕਰ ਤੁਸੀਂ ਗਲੂ ਸਕ੍ਰਿਪਟ ਵਿੱਚ ਸਪਾਰਕ ਐਕਸਪੋਰਟ ਫੰਕਸ਼ਨ ਵਿੱਚ ਸਿਰਫ਼ ਇੱਕ ਲਾਈਨ ਜੋੜਦੇ ਹੋ partition_by = "chr", ਫਿਰ ਡੇਟਾ ਨੂੰ ਬਾਲਟੀਆਂ ਵਿੱਚ ਵੰਡਿਆ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ।

ਜੀਨੋਮ ਵਿੱਚ ਕਈ ਟੁਕੜੇ ਹੁੰਦੇ ਹਨ ਜਿਨ੍ਹਾਂ ਨੂੰ ਕ੍ਰੋਮੋਸੋਮ ਕਿਹਾ ਜਾਂਦਾ ਹੈ।

ਬਦਕਿਸਮਤੀ ਨਾਲ, ਇਸ ਨੇ ਕੰਮ ਨਹੀਂ ਕੀਤਾ। ਕ੍ਰੋਮੋਸੋਮ ਦੇ ਵੱਖ-ਵੱਖ ਆਕਾਰ ਹੁੰਦੇ ਹਨ, ਜਿਸਦਾ ਮਤਲਬ ਵੱਖ-ਵੱਖ ਮਾਤਰਾਵਾਂ ਦੀ ਜਾਣਕਾਰੀ ਹੁੰਦੀ ਹੈ। ਇਸਦਾ ਮਤਲਬ ਹੈ ਕਿ ਸਪਾਰਕ ਦੁਆਰਾ ਕਰਮਚਾਰੀਆਂ ਨੂੰ ਭੇਜੇ ਗਏ ਕੰਮ ਸੰਤੁਲਿਤ ਨਹੀਂ ਸਨ ਅਤੇ ਹੌਲੀ-ਹੌਲੀ ਪੂਰੇ ਕੀਤੇ ਗਏ ਸਨ ਕਿਉਂਕਿ ਕੁਝ ਨੋਡ ਜਲਦੀ ਖਤਮ ਹੋ ਗਏ ਸਨ ਅਤੇ ਵਿਹਲੇ ਸਨ। ਹਾਲਾਂਕਿ, ਕੰਮ ਪੂਰੇ ਹੋ ਗਏ ਸਨ. ਪਰ ਜਦੋਂ ਇੱਕ SNP ਦੀ ਮੰਗ ਕੀਤੀ, ਤਾਂ ਅਸੰਤੁਲਨ ਨੇ ਦੁਬਾਰਾ ਸਮੱਸਿਆਵਾਂ ਪੈਦਾ ਕੀਤੀਆਂ। ਵੱਡੇ ਕ੍ਰੋਮੋਸੋਮਸ (ਜਿੱਥੇ ਅਸੀਂ ਡੇਟਾ ਪ੍ਰਾਪਤ ਕਰਨਾ ਚਾਹੁੰਦੇ ਹਾਂ) 'ਤੇ SNPs ਦੀ ਪ੍ਰਕਿਰਿਆ ਦੀ ਲਾਗਤ ਸਿਰਫ 10 ਦੇ ਇੱਕ ਕਾਰਕ ਦੁਆਰਾ ਘਟੀ ਹੈ। ਬਹੁਤ ਕੁਝ, ਪਰ ਕਾਫ਼ੀ ਨਹੀਂ।

ਜੇ ਅਸੀਂ ਇਸਨੂੰ ਹੋਰ ਛੋਟੇ ਹਿੱਸਿਆਂ ਵਿੱਚ ਵੰਡਦੇ ਹਾਂ ਤਾਂ ਕੀ ਹੋਵੇਗਾ?

ਮੈਂ ਕੀ ਸਿੱਖਿਆ ਹੈ: ਕਦੇ ਵੀ 2,5 ਮਿਲੀਅਨ ਪਾਰਟੀਸ਼ਨ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਨਾ ਕਰੋ।

ਮੈਂ ਸਭ ਤੋਂ ਬਾਹਰ ਜਾਣ ਦਾ ਫੈਸਲਾ ਕੀਤਾ ਅਤੇ ਹਰੇਕ SNP ਨੂੰ ਵੰਡਿਆ। ਇਹ ਯਕੀਨੀ ਬਣਾਉਂਦਾ ਹੈ ਕਿ ਭਾਗ ਬਰਾਬਰ ਆਕਾਰ ਦੇ ਸਨ। ਇਹ ਇੱਕ ਮਾੜਾ ਵਿਚਾਰ ਸੀ. ਮੈਂ ਗਲੂ ਦੀ ਵਰਤੋਂ ਕੀਤੀ ਅਤੇ ਇੱਕ ਨਿਰਦੋਸ਼ ਲਾਈਨ ਜੋੜੀ partition_by = 'snp'. ਕੰਮ ਸ਼ੁਰੂ ਕੀਤਾ ਅਤੇ ਚਲਾਉਣਾ ਸ਼ੁਰੂ ਕੀਤਾ। ਇੱਕ ਦਿਨ ਬਾਅਦ ਮੈਂ ਜਾਂਚ ਕੀਤੀ ਅਤੇ ਦੇਖਿਆ ਕਿ S3 ਨੂੰ ਅਜੇ ਵੀ ਕੁਝ ਨਹੀਂ ਲਿਖਿਆ ਗਿਆ ਸੀ, ਇਸ ਲਈ ਮੈਂ ਕੰਮ ਨੂੰ ਖਤਮ ਕਰ ਦਿੱਤਾ। ਅਜਿਹਾ ਲਗਦਾ ਹੈ ਕਿ ਗਲੂ S3 ਵਿੱਚ ਇੱਕ ਲੁਕਵੇਂ ਸਥਾਨ 'ਤੇ ਵਿਚਕਾਰਲੀ ਫਾਈਲਾਂ ਲਿਖ ਰਿਹਾ ਸੀ, ਬਹੁਤ ਸਾਰੀਆਂ ਫਾਈਲਾਂ, ਸ਼ਾਇਦ ਕੁਝ ਮਿਲੀਅਨ. ਨਤੀਜੇ ਵਜੋਂ, ਮੇਰੀ ਗਲਤੀ ਦੀ ਕੀਮਤ ਇੱਕ ਹਜ਼ਾਰ ਡਾਲਰ ਤੋਂ ਵੱਧ ਹੈ ਅਤੇ ਮੇਰੇ ਸਲਾਹਕਾਰ ਨੂੰ ਖੁਸ਼ ਨਹੀਂ ਕੀਤਾ.

ਵਿਭਾਗੀਕਰਨ + ਛਾਂਟੀ

ਮੈਂ ਕੀ ਸਿੱਖਿਆ ਹੈ: ਛਾਂਟੀ ਕਰਨਾ ਅਜੇ ਵੀ ਮੁਸ਼ਕਲ ਹੈ, ਜਿਵੇਂ ਕਿ ਸਪਾਰਕ ਨੂੰ ਟਿਊਨ ਕਰਨਾ ਹੈ।

ਵੰਡਣ ਦੀ ਮੇਰੀ ਆਖਰੀ ਕੋਸ਼ਿਸ਼ ਵਿੱਚ ਕ੍ਰੋਮੋਸੋਮ ਨੂੰ ਵੰਡਣਾ ਅਤੇ ਫਿਰ ਹਰੇਕ ਭਾਗ ਨੂੰ ਛਾਂਟਣਾ ਸ਼ਾਮਲ ਸੀ। ਸਿਧਾਂਤਕ ਤੌਰ 'ਤੇ, ਇਹ ਹਰੇਕ ਪੁੱਛਗਿੱਛ ਨੂੰ ਤੇਜ਼ ਕਰੇਗਾ ਕਿਉਂਕਿ ਲੋੜੀਂਦਾ SNP ਡੇਟਾ ਇੱਕ ਦਿੱਤੀ ਗਈ ਸੀਮਾ ਦੇ ਅੰਦਰ ਕੁਝ ਪਾਰਕੁਏਟ ਭਾਗਾਂ ਦੇ ਅੰਦਰ ਹੋਣਾ ਚਾਹੀਦਾ ਸੀ। ਬਦਕਿਸਮਤੀ ਨਾਲ, ਵਿਭਾਜਨਿਤ ਡੇਟਾ ਨੂੰ ਛਾਂਟਣਾ ਇੱਕ ਮੁਸ਼ਕਲ ਕੰਮ ਸਾਬਤ ਹੋਇਆ। ਨਤੀਜੇ ਵਜੋਂ, ਮੈਂ ਇੱਕ ਕਸਟਮ ਕਲੱਸਟਰ ਲਈ EMR ਵਿੱਚ ਸਵਿਚ ਕੀਤਾ ਅਤੇ ਇੱਕ ਵਧੇਰੇ ਲਚਕਦਾਰ ਵਰਕਫਲੋ ਬਣਾਉਣ ਲਈ ਅੱਠ ਸ਼ਕਤੀਸ਼ਾਲੀ ਉਦਾਹਰਣਾਂ (C5.4xl) ਅਤੇ ਸਪਾਰਕਲਾਈਰ ਦੀ ਵਰਤੋਂ ਕੀਤੀ...

# 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, ਆਦਿ। ਪਰ ਸਮੱਸਿਆ ਇਹ ਹੈ ਕਿ SNPs ਨੂੰ ਕ੍ਰੋਮੋਸੋਮ ਵਿੱਚ ਬਰਾਬਰ ਵੰਡਿਆ ਨਹੀਂ ਜਾਂਦਾ ਹੈ, ਇਸਲਈ ਸਮੂਹ ਦੇ ਆਕਾਰ ਬਹੁਤ ਵੱਖਰੇ ਹੋਣਗੇ।

ਨਤੀਜੇ ਵਜੋਂ, ਮੈਂ ਅਹੁਦਿਆਂ ਨੂੰ ਸ਼੍ਰੇਣੀਆਂ (ਰੈਂਕ) ਵਿੱਚ ਵੰਡਣ ਲਈ ਆਇਆ ਹਾਂ। ਪਹਿਲਾਂ ਹੀ ਡਾਉਨਲੋਡ ਕੀਤੇ ਡੇਟਾ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋਏ, ਮੈਂ ਵਿਲੱਖਣ SNPs, ਉਹਨਾਂ ਦੀਆਂ ਸਥਿਤੀਆਂ ਅਤੇ ਕ੍ਰੋਮੋਸੋਮਸ ਦੀ ਸੂਚੀ ਪ੍ਰਾਪਤ ਕਰਨ ਲਈ ਇੱਕ ਬੇਨਤੀ ਚਲਾਈ। ਫਿਰ ਮੈਂ ਹਰੇਕ ਕ੍ਰੋਮੋਸੋਮ ਦੇ ਅੰਦਰ ਡੇਟਾ ਨੂੰ ਕ੍ਰਮਬੱਧ ਕੀਤਾ ਅਤੇ ਇੱਕ ਦਿੱਤੇ ਆਕਾਰ ਦੇ ਸਮੂਹਾਂ (ਬਿਨ) ਵਿੱਚ SNPs ਨੂੰ ਇਕੱਠਾ ਕੀਤਾ। ਮੰਨ ਲਓ 1000 SNPs ਹਰੇਕ। ਇਸਨੇ ਮੈਨੂੰ SNP-ਤੋਂ-ਸਮੂਹ-ਪ੍ਰਤੀ-ਕ੍ਰੋਮੋਸੋਮ ਰਿਸ਼ਤਾ ਦਿੱਤਾ।

ਅੰਤ ਵਿੱਚ, ਮੈਂ 75 SNPs ਦੇ ਸਮੂਹ (ਬਿਨ) ਬਣਾਏ, ਕਾਰਨ ਹੇਠਾਂ ਦੱਸਿਆ ਜਾਵੇਗਾ।

snp_to_bin <- unique_snps %>% 
  group_by(chr) %>% 
  arrange(position) %>% 
  mutate(
    rank = 1:n()
    bin = floor(rank/snps_per_bin)
  ) %>% 
  ungroup()

ਪਹਿਲਾਂ ਸਪਾਰਕ ਨਾਲ ਕੋਸ਼ਿਸ਼ ਕਰੋ

ਮੈਂ ਕੀ ਸਿੱਖਿਆ ਹੈ: ਸਪਾਰਕ ਐਗਰੀਗੇਸ਼ਨ ਤੇਜ਼ ਹੈ, ਪਰ ਵਿਭਾਗੀਕਰਨ ਅਜੇ ਵੀ ਮਹਿੰਗਾ ਹੈ।

ਮੈਂ ਇਸ ਛੋਟੀ (2,5 ਮਿਲੀਅਨ ਕਤਾਰਾਂ) ਡੇਟਾ ਫਰੇਮ ਨੂੰ ਸਪਾਰਕ ਵਿੱਚ ਪੜ੍ਹਨਾ ਚਾਹੁੰਦਾ ਸੀ, ਇਸਨੂੰ ਕੱਚੇ ਡੇਟਾ ਨਾਲ ਜੋੜਨਾ, ਅਤੇ ਫਿਰ ਇਸਨੂੰ ਨਵੇਂ ਸ਼ਾਮਲ ਕੀਤੇ ਕਾਲਮ ਦੁਆਰਾ ਵੰਡਣਾ ਚਾਹੁੰਦਾ ਸੀ bin.

# Join the raw data with the snp bins
data_w_bin <- raw_data %>%
  left_join(sdf_broadcast(snp_to_bin), by ='snp_name') %>%
  group_by(chr_bin) %>%
  arrange(Position) %>% 
  Spark_write_Parquet(
    path = DUMP_LOC,
    mode = 'overwrite',
    partition_by = c('chr_bin')
  )

ਮੈਂ ਵਰਤਿਆ sdf_broadcast(), ਇਸਲਈ ਸਪਾਰਕ ਜਾਣਦਾ ਹੈ ਕਿ ਇਸਨੂੰ ਸਾਰੇ ਨੋਡਾਂ ਨੂੰ ਡੇਟਾ ਫਰੇਮ ਭੇਜਣਾ ਚਾਹੀਦਾ ਹੈ। ਇਹ ਲਾਭਦਾਇਕ ਹੈ ਜੇਕਰ ਡੇਟਾ ਆਕਾਰ ਵਿੱਚ ਛੋਟਾ ਹੈ ਅਤੇ ਸਾਰੇ ਕੰਮਾਂ ਲਈ ਲੋੜੀਂਦਾ ਹੈ। ਨਹੀਂ ਤਾਂ, ਸਪਾਰਕ ਸਮਾਰਟ ਬਣਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਦਾ ਹੈ ਅਤੇ ਲੋੜ ਅਨੁਸਾਰ ਡਾਟਾ ਵੰਡਦਾ ਹੈ, ਜਿਸ ਨਾਲ ਮੰਦੀ ਹੋ ਸਕਦੀ ਹੈ।

ਅਤੇ ਦੁਬਾਰਾ, ਮੇਰੇ ਵਿਚਾਰ ਨੇ ਕੰਮ ਨਹੀਂ ਕੀਤਾ: ਕਾਰਜਾਂ ਨੇ ਕੁਝ ਸਮੇਂ ਲਈ ਕੰਮ ਕੀਤਾ, ਯੂਨੀਅਨ ਨੂੰ ਪੂਰਾ ਕੀਤਾ, ਅਤੇ ਫਿਰ, ਵੰਡ ਦੁਆਰਾ ਸ਼ੁਰੂ ਕੀਤੇ ਗਏ ਐਗਜ਼ੈਕਟਰਾਂ ਵਾਂਗ, ਉਹ ਅਸਫਲ ਹੋਣ ਲੱਗੇ।

AWK ਸ਼ਾਮਲ ਕੀਤਾ ਜਾ ਰਿਹਾ ਹੈ

ਮੈਂ ਕੀ ਸਿੱਖਿਆ ਹੈ: ਜਦੋਂ ਤੁਹਾਨੂੰ ਮੂਲ ਗੱਲਾਂ ਸਿਖਾਈਆਂ ਜਾ ਰਹੀਆਂ ਹੋਣ ਤਾਂ ਨਾ ਸੌਂਵੋ। ਯਕੀਨਨ ਕਿਸੇ ਨੇ ਪਹਿਲਾਂ ਹੀ 1980 ਦੇ ਦਹਾਕੇ ਵਿੱਚ ਤੁਹਾਡੀ ਸਮੱਸਿਆ ਦਾ ਹੱਲ ਕੀਤਾ ਹੈ।

ਇਸ ਬਿੰਦੂ ਤੱਕ, ਸਪਾਰਕ ਨਾਲ ਮੇਰੀਆਂ ਸਾਰੀਆਂ ਅਸਫਲਤਾਵਾਂ ਦਾ ਕਾਰਨ ਕਲੱਸਟਰ ਵਿੱਚ ਡੇਟਾ ਦੀ ਗੜਬੜ ਸੀ। ਸ਼ਾਇਦ ਪੂਰਵ-ਇਲਾਜ ਨਾਲ ਸਥਿਤੀ ਨੂੰ ਸੁਧਾਰਿਆ ਜਾ ਸਕਦਾ ਹੈ. ਮੈਂ ਕੱਚੇ ਟੈਕਸਟ ਡੇਟਾ ਨੂੰ ਕ੍ਰੋਮੋਸੋਮਸ ਦੇ ਕਾਲਮਾਂ ਵਿੱਚ ਵੰਡਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਨ ਦਾ ਫੈਸਲਾ ਕੀਤਾ, ਇਸਲਈ ਮੈਂ "ਪੂਰਵ-ਵਿਭਾਜਨ" ਡੇਟਾ ਦੇ ਨਾਲ ਸਪਾਰਕ ਪ੍ਰਦਾਨ ਕਰਨ ਦੀ ਉਮੀਦ ਕੀਤੀ।

ਮੈਂ ਸਟੈਕਓਵਰਫਲੋ 'ਤੇ ਖੋਜ ਕੀਤੀ ਕਿ ਕਿਵੇਂ ਕਾਲਮ ਮੁੱਲਾਂ ਦੁਆਰਾ ਵੰਡਿਆ ਜਾਵੇ ਅਤੇ ਪਾਇਆ ਇੰਨਾ ਵਧੀਆ ਜਵਾਬ. 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 ਮੈਮੋਰੀ ਦੀ ਵਰਤੋਂ ਕਰ ਰਿਹਾ ਸੀ। ਸਮੱਸਿਆ ਨੂੰ ਹੱਲ ਕਰਨ ਅਤੇ ਬਹੁਤ ਸਾਰਾ ਪੈਸਾ ਨਾ ਗੁਆਉਣ ਲਈ, ਸਾਨੂੰ ਇਹ ਪਤਾ ਲਗਾਉਣਾ ਪਿਆ ਕਿ ਕੰਮ ਨੂੰ ਸਮਾਨਤਾ ਕਿਵੇਂ ਕਰਨਾ ਹੈ. ਖੁਸ਼ਕਿਸਮਤੀ ਨਾਲ, ਇੱਕ ਬਿਲਕੁਲ ਅਦਭੁਤ ਕਿਤਾਬ ਵਿੱਚ ਕਮਾਂਡ ਲਾਈਨ 'ਤੇ ਡਾਟਾ ਸਾਇੰਸ ਮੈਨੂੰ ਸਮਾਨਤਾ 'ਤੇ ਜੇਰੋਨ ਜੈਨਸੈਂਸ ਦੁਆਰਾ ਇੱਕ ਅਧਿਆਇ ਮਿਲਿਆ. ਇਸ ਤੋਂ ਮੈਨੂੰ ਪਤਾ ਲੱਗਾ gnu parallel, ਯੂਨਿਕਸ ਵਿੱਚ ਮਲਟੀਥ੍ਰੈਡਿੰਗ ਨੂੰ ਲਾਗੂ ਕਰਨ ਲਈ ਇੱਕ ਬਹੁਤ ਹੀ ਲਚਕਦਾਰ ਢੰਗ ਹੈ।

ਜਦੋਂ ਮੈਂ ਨਵੀਂ ਪ੍ਰਕਿਰਿਆ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਵਿਭਾਗੀਕਰਨ ਸ਼ੁਰੂ ਕੀਤਾ, ਸਭ ਕੁਝ ਠੀਕ ਸੀ, ਪਰ ਅਜੇ ਵੀ ਇੱਕ ਰੁਕਾਵਟ ਸੀ - ਡਿਸਕ 'ਤੇ S3 ਆਬਜੈਕਟਸ ਨੂੰ ਡਾਊਨਲੋਡ ਕਰਨਾ ਬਹੁਤ ਤੇਜ਼ ਨਹੀਂ ਸੀ ਅਤੇ ਪੂਰੀ ਤਰ੍ਹਾਂ ਸਮਾਨਾਂਤਰ ਨਹੀਂ ਸੀ। ਇਸ ਨੂੰ ਠੀਕ ਕਰਨ ਲਈ, ਮੈਂ ਇਹ ਕੀਤਾ:

1. ਮੈਨੂੰ ਪਤਾ ਲੱਗਾ ਕਿ S3 ਡਾਉਨਲੋਡ ਪੜਾਅ ਨੂੰ ਸਿੱਧੇ ਪਾਈਪਲਾਈਨ ਵਿੱਚ ਲਾਗੂ ਕਰਨਾ ਸੰਭਵ ਹੈ, ਡਿਸਕ 'ਤੇ ਇੰਟਰਮੀਡੀਏਟ ਸਟੋਰੇਜ ਨੂੰ ਪੂਰੀ ਤਰ੍ਹਾਂ ਖਤਮ ਕਰਨਾ. ਇਸਦਾ ਮਤਲਬ ਹੈ ਕਿ ਮੈਂ ਡਿਸਕ 'ਤੇ ਕੱਚਾ ਡੇਟਾ ਲਿਖਣ ਤੋਂ ਬਚ ਸਕਦਾ ਹਾਂ ਅਤੇ ਇਸ ਤੋਂ ਵੀ ਛੋਟਾ, ਅਤੇ ਇਸਲਈ ਸਸਤਾ, AWS 'ਤੇ ਸਟੋਰੇਜ ਦੀ ਵਰਤੋਂ ਕਰ ਸਕਦਾ ਹਾਂ।
2. ਟੀਮ aws configure set default.s3.max_concurrent_requests 50 AWS CLI ਦੀ ਵਰਤੋਂ ਕਰਨ ਵਾਲੇ ਥਰਿੱਡਾਂ ਦੀ ਗਿਣਤੀ ਵਿੱਚ ਬਹੁਤ ਵਾਧਾ ਹੋਇਆ ਹੈ (ਮੂਲ ਰੂਪ ਵਿੱਚ 10 ਹਨ)।
3. ਮੈਂ ਨਾਮ ਵਿੱਚ ਅੱਖਰ n ਦੇ ਨਾਲ, ਨੈੱਟਵਰਕ ਸਪੀਡ ਲਈ ਅਨੁਕੂਲਿਤ ਇੱਕ EC2 ਉਦਾਹਰਨ 'ਤੇ ਸਵਿਚ ਕੀਤਾ। ਮੈਂ ਪਾਇਆ ਹੈ ਕਿ n-ਇਨਸਟੈਂਸ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਸਮੇਂ ਪ੍ਰੋਸੈਸਿੰਗ ਪਾਵਰ ਦਾ ਨੁਕਸਾਨ ਲੋਡਿੰਗ ਸਪੀਡ ਵਿੱਚ ਵਾਧੇ ਦੁਆਰਾ ਮੁਆਵਜ਼ੇ ਨਾਲੋਂ ਵੱਧ ਹੈ। ਜ਼ਿਆਦਾਤਰ ਕੰਮਾਂ ਲਈ ਮੈਂ c5n.4xl ਦੀ ਵਰਤੋਂ ਕੀਤੀ।
4. ਬਦਲਿਆ gzip 'ਤੇ pigz, ਇਹ ਇੱਕ gzip ਟੂਲ ਹੈ ਜੋ ਫਾਈਲਾਂ ਨੂੰ ਡੀਕੰਪ੍ਰੈਸ ਕਰਨ ਦੇ ਸ਼ੁਰੂਆਤੀ ਤੌਰ 'ਤੇ ਗੈਰ-ਸਮਾਂਤਰ ਕਾਰਜ ਨੂੰ ਸਮਾਨਾਂਤਰ ਬਣਾਉਣ ਲਈ ਵਧੀਆ ਚੀਜ਼ਾਂ ਕਰ ਸਕਦਾ ਹੈ (ਇਸ ਨਾਲ ਘੱਟ ਤੋਂ ਘੱਟ ਮਦਦ ਹੋਈ)।

# Let S3 use as many threads as it wants
aws configure set default.s3.max_concurrent_requests 50

for chunk_file in $(aws s3 ls $DATA_LOC | awk '{print $4}' | grep 'chr'$DESIRED_CHR'.csv') ; do

        aws s3 cp s3://$batch_loc$chunk_file - |
        pigz -dc |
        parallel --block 100M --pipe  
        "awk -F 't' '{print $1",..."$30">"chunked/{#}_chr"$15".csv"}'"

       # Combine all the parallel process chunks to single files
        ls chunked/ |
        cut -d '_' -f 2 |
        sort -u |
        parallel 'cat chunked/*_{} | sort -k5 -n -S 80% -t, | aws s3 cp - '$s3_dest'/batch_'$batch_num'_{}'
        
         # Clean up intermediate data
       rm chunked/*
done

ਹਰ ਚੀਜ਼ ਨੂੰ ਬਹੁਤ ਤੇਜ਼ੀ ਨਾਲ ਕੰਮ ਕਰਨ ਲਈ ਇਹ ਕਦਮ ਇੱਕ ਦੂਜੇ ਨਾਲ ਮਿਲਾਏ ਜਾਂਦੇ ਹਨ। ਡਾਉਨਲੋਡ ਸਪੀਡ ਵਧਾ ਕੇ ਅਤੇ ਡਿਸਕ ਰਾਈਟਸ ਨੂੰ ਖਤਮ ਕਰਕੇ, ਮੈਂ ਹੁਣ ਕੁਝ ਘੰਟਿਆਂ ਵਿੱਚ 5 ਟੈਰਾਬਾਈਟ ਪੈਕੇਜ ਦੀ ਪ੍ਰਕਿਰਿਆ ਕਰ ਸਕਦਾ ਹਾਂ।

ਤੁਹਾਡੇ ਦੁਆਰਾ ਵਰਤੇ ਜਾ ਰਹੇ AWS 'ਤੇ ਭੁਗਤਾਨ ਕੀਤੇ ਜਾ ਰਹੇ ਸਾਰੇ ਕੋਰਾਂ ਨੂੰ ਦੇਖਣ ਤੋਂ ਇਲਾਵਾ ਹੋਰ ਕੁਝ ਵੀ ਮਿੱਠਾ ਨਹੀਂ ਹੈ। ਜੀਐਨਯੂ-ਪੈਰਲਲ ਲਈ ਧੰਨਵਾਦ ਮੈਂ 19gig csv ਨੂੰ ਓਨੀ ਹੀ ਤੇਜ਼ੀ ਨਾਲ ਅਨਜ਼ਿਪ ਅਤੇ ਵੰਡ ਸਕਦਾ ਹਾਂ ਜਿੰਨਾ ਮੈਂ ਇਸਨੂੰ ਡਾਊਨਲੋਡ ਕਰ ਸਕਦਾ ਹਾਂ। ਮੈਨੂੰ ਇਸ ਨੂੰ ਚਲਾਉਣ ਲਈ ਚੰਗਿਆੜੀ ਵੀ ਨਹੀਂ ਮਿਲ ਸਕੀ। # ਡੇਟਾ ਸਾਇੰਸ #Linux pic.twitter.com/Nqyba2zqEk

- ਨਿਕ ਸਟ੍ਰੇਅਰ (@ ਨਿਕੋਲਸ ਸਟ੍ਰੇਅਰ) 17 ਮਈ, 2019

ਇਸ ਟਵੀਟ 'ਚ 'TSV' ਦਾ ਜ਼ਿਕਰ ਹੋਣਾ ਚਾਹੀਦਾ ਸੀ। ਹਾਏ।

ਨਵੇਂ ਪਾਰਸ ਕੀਤੇ ਡੇਟਾ ਦੀ ਵਰਤੋਂ ਕਰਨਾ

ਮੈਂ ਕੀ ਸਿੱਖਿਆ ਹੈ: ਸਪਾਰਕ ਨੂੰ ਸੰਕੁਚਿਤ ਡੇਟਾ ਪਸੰਦ ਨਹੀਂ ਹੈ ਅਤੇ ਭਾਗਾਂ ਨੂੰ ਜੋੜਨਾ ਪਸੰਦ ਨਹੀਂ ਕਰਦਾ।

ਹੁਣ ਡੇਟਾ ਇੱਕ ਅਨਪੈਕਡ (ਪੜ੍ਹੋ: ਸਾਂਝਾ) ਅਤੇ ਅਰਧ-ਆਰਡਰਡ ਫਾਰਮੈਟ ਵਿੱਚ S3 ਵਿੱਚ ਸੀ, ਅਤੇ ਮੈਂ ਦੁਬਾਰਾ ਸਪਾਰਕ ਵਿੱਚ ਵਾਪਸ ਆ ਸਕਦਾ ਹਾਂ। ਇੱਕ ਹੈਰਾਨੀ ਮੇਰੇ ਲਈ ਉਡੀਕ ਕਰ ਰਹੀ ਸੀ: ਮੈਂ ਜੋ ਚਾਹੁੰਦਾ ਸੀ ਉਹ ਪ੍ਰਾਪਤ ਕਰਨ ਵਿੱਚ ਦੁਬਾਰਾ ਅਸਫਲ ਰਿਹਾ! ਸਪਾਰਕ ਨੂੰ ਇਹ ਦੱਸਣਾ ਬਹੁਤ ਮੁਸ਼ਕਲ ਸੀ ਕਿ ਡੇਟਾ ਨੂੰ ਕਿਵੇਂ ਵੰਡਿਆ ਗਿਆ ਸੀ। ਅਤੇ ਉਦੋਂ ਵੀ ਜਦੋਂ ਮੈਂ ਇਹ ਕੀਤਾ, ਇਹ ਪਤਾ ਚਲਿਆ ਕਿ ਬਹੁਤ ਸਾਰੇ ਭਾਗ ਸਨ (95 ਹਜ਼ਾਰ), ਅਤੇ ਜਦੋਂ ਮੈਂ ਵਰਤਿਆ coalesce ਉਹਨਾਂ ਦੀ ਸੰਖਿਆ ਨੂੰ ਵਾਜਬ ਸੀਮਾਵਾਂ ਤੱਕ ਘਟਾ ਦਿੱਤਾ, ਇਸ ਨਾਲ ਮੇਰਾ ਵਿਭਾਜਨ ਨਸ਼ਟ ਹੋ ਗਿਆ। ਮੈਨੂੰ ਯਕੀਨ ਹੈ ਕਿ ਇਹ ਹੱਲ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ, ਪਰ ਕੁਝ ਦਿਨਾਂ ਦੀ ਖੋਜ ਕਰਨ ਤੋਂ ਬਾਅਦ ਮੈਨੂੰ ਕੋਈ ਹੱਲ ਨਹੀਂ ਮਿਲਿਆ। ਮੈਂ ਆਖਰਕਾਰ ਸਪਾਰਕ ਵਿੱਚ ਸਾਰੇ ਕਾਰਜਾਂ ਨੂੰ ਪੂਰਾ ਕਰ ਲਿਆ, ਹਾਲਾਂਕਿ ਇਸ ਵਿੱਚ ਕੁਝ ਸਮਾਂ ਲੱਗਿਆ ਅਤੇ ਮੇਰੀਆਂ ਸਪਲਿਟ ਪਾਰਕੁਏਟ ਫਾਈਲਾਂ ਬਹੁਤ ਛੋਟੀਆਂ ਨਹੀਂ ਸਨ (~ 200 KB)। ਹਾਲਾਂਕਿ, ਡੇਟਾ ਉੱਥੇ ਸੀ ਜਿੱਥੇ ਇਸਦੀ ਲੋੜ ਸੀ।

ਬਹੁਤ ਛੋਟਾ ਅਤੇ ਅਸਮਾਨ, ਸ਼ਾਨਦਾਰ!

ਸਥਾਨਕ ਸਪਾਰਕ ਸਵਾਲਾਂ ਦੀ ਜਾਂਚ ਕਰ ਰਿਹਾ ਹੈ

ਮੈਂ ਕੀ ਸਿੱਖਿਆ ਹੈ: ਸਧਾਰਨ ਸਮੱਸਿਆਵਾਂ ਨੂੰ ਹੱਲ ਕਰਨ ਵੇਲੇ ਸਪਾਰਕ ਦਾ ਬਹੁਤ ਜ਼ਿਆਦਾ ਓਵਰਹੈੱਡ ਹੁੰਦਾ ਹੈ।

ਇੱਕ ਚਲਾਕ ਫਾਰਮੈਟ ਵਿੱਚ ਡੇਟਾ ਨੂੰ ਡਾਊਨਲੋਡ ਕਰਕੇ, ਮੈਂ ਗਤੀ ਦੀ ਜਾਂਚ ਕਰਨ ਦੇ ਯੋਗ ਸੀ. ਇੱਕ ਸਥਾਨਕ ਸਪਾਰਕ ਸਰਵਰ ਨੂੰ ਚਲਾਉਣ ਲਈ ਇੱਕ ਆਰ ਸਕ੍ਰਿਪਟ ਸੈਟ ਅਪ ਕਰੋ, ਅਤੇ ਫਿਰ ਨਿਰਧਾਰਤ Parquet ਗਰੁੱਪ ਸਟੋਰੇਜ (bin) ਤੋਂ ਇੱਕ ਸਪਾਰਕ ਡੇਟਾ ਫਰੇਮ ਲੋਡ ਕਰੋ। ਮੈਂ ਸਾਰਾ ਡਾਟਾ ਲੋਡ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕੀਤੀ ਪਰ ਸਪਾਰਕਲਾਈਰ ਨੂੰ ਵਿਭਾਗੀਕਰਨ ਦੀ ਪਛਾਣ ਨਹੀਂ ਕਰ ਸਕਿਆ।

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 GB ਤੋਂ ਵੱਧ ਮੈਮੋਰੀ ਨਿਰਧਾਰਤ ਕੀਤੀ ਹੋਵੇ।

AWK ’ਤੇ ਵਾਪਸ ਜਾਓ

ਮੈਂ ਕੀ ਸਿੱਖਿਆ ਹੈ: AWK ਵਿੱਚ ਐਸੋਸੀਏਟਿਵ ਐਰੇ ਬਹੁਤ ਕੁਸ਼ਲ ਹਨ।

ਮੈਨੂੰ ਅਹਿਸਾਸ ਹੋਇਆ ਕਿ ਮੈਂ ਉੱਚ ਗਤੀ ਪ੍ਰਾਪਤ ਕਰ ਸਕਦਾ ਹਾਂ. ਮੈਨੂੰ ਇੱਕ ਸ਼ਾਨਦਾਰ ਵਿੱਚ ਯਾਦ ਹੈ ਬਰੂਸ ਬਾਰਨੇਟ ਦੁਆਰਾ AWK ਟਿਊਟੋਰਿਅਲ ਮੈਂ ਇੱਕ ਸ਼ਾਨਦਾਰ ਵਿਸ਼ੇਸ਼ਤਾ ਬਾਰੇ ਪੜ੍ਹਿਆ ਜਿਸ ਨੂੰ "ਸਹਿਯੋਗੀ ਐਰੇ" ਜ਼ਰੂਰੀ ਤੌਰ 'ਤੇ, ਇਹ ਕੁੰਜੀ-ਮੁੱਲ ਦੇ ਜੋੜੇ ਹਨ, ਜਿਨ੍ਹਾਂ ਨੂੰ ਕਿਸੇ ਕਾਰਨ ਕਰਕੇ AWK ਵਿੱਚ ਵੱਖਰੇ ਤੌਰ 'ਤੇ ਕਿਹਾ ਜਾਂਦਾ ਸੀ, ਅਤੇ ਇਸਲਈ ਮੈਂ ਉਨ੍ਹਾਂ ਬਾਰੇ ਬਹੁਤਾ ਨਹੀਂ ਸੋਚਿਆ। ਰੋਮਨ ਚੇਪਲਿਆਕਾ ਯਾਦ ਕੀਤਾ ਕਿ ਸ਼ਬਦ "ਐਸੋਸੀਏਟਿਵ ਐਰੇ" ਸ਼ਬਦ "ਕੁੰਜੀ-ਮੁੱਲ ਜੋੜਾ" ਨਾਲੋਂ ਬਹੁਤ ਪੁਰਾਣਾ ਹੈ। ਭਾਵੇਂ ਤੁਸੀਂ ਗੂਗਲ ਐਨਗ੍ਰਾਮ ਵਿੱਚ ਕੁੰਜੀ-ਮੁੱਲ ਦੇਖੋ, ਤੁਸੀਂ ਉੱਥੇ ਇਹ ਸ਼ਬਦ ਨਹੀਂ ਦੇਖ ਸਕੋਗੇ, ਪਰ ਤੁਹਾਨੂੰ ਸਹਿਯੋਗੀ ਐਰੇ ਮਿਲਣਗੇ! ਇਸ ਤੋਂ ਇਲਾਵਾ, "ਕੁੰਜੀ-ਮੁੱਲ ਜੋੜਾ" ਅਕਸਰ ਡੇਟਾਬੇਸ ਨਾਲ ਜੁੜਿਆ ਹੁੰਦਾ ਹੈ, ਇਸਲਈ ਹੈਸ਼ਮੈਪ ਨਾਲ ਇਸਦੀ ਤੁਲਨਾ ਕਰਨਾ ਬਹੁਤ ਜ਼ਿਆਦਾ ਸਮਝਦਾਰੀ ਵਾਲਾ ਹੈ। ਮੈਨੂੰ ਅਹਿਸਾਸ ਹੋਇਆ ਕਿ ਮੈਂ ਸਪਾਰਕ ਦੀ ਵਰਤੋਂ ਕੀਤੇ ਬਿਨਾਂ ਆਪਣੇ SNPs ਨੂੰ ਬਿਨ ਟੇਬਲ ਅਤੇ ਕੱਚੇ ਡੇਟਾ ਨਾਲ ਜੋੜਨ ਲਈ ਇਹਨਾਂ ਸਹਿਯੋਗੀ ਐਰੇ ਦੀ ਵਰਤੋਂ ਕਰ ਸਕਦਾ ਹਾਂ।

ਅਜਿਹਾ ਕਰਨ ਲਈ, AWK ਸਕ੍ਰਿਪਟ ਵਿੱਚ ਮੈਂ ਬਲਾਕ ਦੀ ਵਰਤੋਂ ਕੀਤੀ BEGIN. ਇਹ ਕੋਡ ਦਾ ਇੱਕ ਟੁਕੜਾ ਹੈ ਜੋ ਸਕ੍ਰਿਪਟ ਦੇ ਮੁੱਖ ਭਾਗ ਵਿੱਚ ਡੇਟਾ ਦੀ ਪਹਿਲੀ ਲਾਈਨ ਦੇ ਪਾਸ ਹੋਣ ਤੋਂ ਪਹਿਲਾਂ ਚਲਾਇਆ ਜਾਂਦਾ ਹੈ।

join_data.awk
BEGIN {
  FS=",";
  batch_num=substr(chunk,7,1);
  chunk_id=substr(chunk,15,2);
  while(getline < "snp_to_bin.csv") {bin[$1] = $2}
}
{
  print $0 > "chunked/chr_"chr"_bin_"bin[$1]"_"batch_num"_"chunk_id".csv"
}

ਦੀ ਟੀਮ while(getline...) CSV ਸਮੂਹ (ਬਿਨ) ਤੋਂ ਸਾਰੀਆਂ ਕਤਾਰਾਂ ਨੂੰ ਲੋਡ ਕੀਤਾ, ਐਸੋਸਿਏਟਿਵ ਐਰੇ ਲਈ ਕੁੰਜੀ ਵਜੋਂ ਪਹਿਲੇ ਕਾਲਮ (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 ਇੱਕ ਆਰ ਸਕ੍ਰਿਪਟ ਤੋਂ, ਅਤੇ ਇਸਲਈ ਇਸਨੂੰ ਪਾਈਪਲਾਈਨ ਵਿੱਚ ਵਰਤੋ।

ਤੁਸੀਂ ਸ਼ਾਇਦ ਆਪਣੀ Bash ਸਕ੍ਰਿਪਟ ਵਿੱਚ ਇਸ ਲਾਈਨ ਨੂੰ ਦੇਖਿਆ ਹੋਵੇਗਾ: ...cat chunked/*_bin_{}_*.csv | ./upload_as_rds.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, ਆਰ ਸਕ੍ਰਿਪਟ ਵਿੱਚ ਅਨੁਵਾਦ ਕੀਤੇ ਗਏ ਡੇਟਾ ਨੂੰ ਇੱਕ ਫਰੇਮ ਵਿੱਚ ਲੋਡ ਕੀਤਾ ਜਾਂਦਾ ਹੈ, ਜੋ ਕਿ ਫਿਰ ਰੂਪ ਵਿੱਚ ਹੁੰਦਾ ਹੈ .rds-ਫਾਇਲ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋਏ aws.s3 S3 ਨੂੰ ਸਿੱਧਾ ਲਿਖਿਆ ਗਿਆ।

RDS Parquet ਦੇ ਜੂਨੀਅਰ ਸੰਸਕਰਣ ਵਰਗਾ ਹੈ, ਸਪੀਕਰ ਸਟੋਰੇਜ ਦੇ ਫਰਿੱਲਾਂ ਤੋਂ ਬਿਨਾਂ।

ਬਾਸ਼ ਸਕ੍ਰਿਪਟ ਖਤਮ ਕਰਨ ਤੋਂ ਬਾਅਦ ਮੈਨੂੰ ਇੱਕ ਬੰਡਲ ਮਿਲਿਆ .rds-S3 ਵਿੱਚ ਸਥਿਤ ਫਾਈਲਾਂ, ਜਿਸ ਨੇ ਮੈਨੂੰ ਕੁਸ਼ਲ ਕੰਪਰੈਸ਼ਨ ਅਤੇ ਬਿਲਟ-ਇਨ ਕਿਸਮਾਂ ਦੀ ਵਰਤੋਂ ਕਰਨ ਦੀ ਇਜਾਜ਼ਤ ਦਿੱਤੀ।

ਬ੍ਰੇਕ ਆਰ ਦੀ ਵਰਤੋਂ ਦੇ ਬਾਵਜੂਦ, ਸਭ ਕੁਝ ਬਹੁਤ ਤੇਜ਼ੀ ਨਾਲ ਕੰਮ ਕਰਦਾ ਹੈ. ਹੈਰਾਨੀ ਦੀ ਗੱਲ ਨਹੀਂ ਹੈ, R ਦੇ ਉਹ ਹਿੱਸੇ ਜੋ ਡੇਟਾ ਨੂੰ ਪੜ੍ਹਦੇ ਅਤੇ ਲਿਖਦੇ ਹਨ ਬਹੁਤ ਜ਼ਿਆਦਾ ਅਨੁਕੂਲਿਤ ਹੁੰਦੇ ਹਨ। ਇੱਕ ਮੱਧਮ ਆਕਾਰ ਦੇ ਕ੍ਰੋਮੋਸੋਮ 'ਤੇ ਟੈਸਟ ਕਰਨ ਤੋਂ ਬਾਅਦ, ਕੰਮ ਲਗਭਗ ਦੋ ਘੰਟਿਆਂ ਵਿੱਚ C5n.4xl ਮੌਕੇ 'ਤੇ ਪੂਰਾ ਹੋ ਗਿਆ।

S3 ਸੀਮਾਵਾਂ

ਮੈਂ ਕੀ ਸਿੱਖਿਆ ਹੈ: ਸਮਾਰਟ ਮਾਰਗ ਲਾਗੂ ਕਰਨ ਲਈ ਧੰਨਵਾਦ, S3 ਬਹੁਤ ਸਾਰੀਆਂ ਫਾਈਲਾਂ ਨੂੰ ਸੰਭਾਲ ਸਕਦਾ ਹੈ।

ਮੈਂ ਚਿੰਤਤ ਸੀ ਕਿ ਕੀ S3 ਬਹੁਤ ਸਾਰੀਆਂ ਫਾਈਲਾਂ ਨੂੰ ਸੰਭਾਲਣ ਦੇ ਯੋਗ ਹੋਵੇਗਾ ਜੋ ਇਸਨੂੰ ਟ੍ਰਾਂਸਫਰ ਕੀਤੀਆਂ ਗਈਆਂ ਸਨ. ਮੈਂ ਫਾਈਲ ਦੇ ਨਾਮਾਂ ਨੂੰ ਸਮਝਦਾਰ ਬਣਾ ਸਕਦਾ ਹਾਂ, ਪਰ S3 ਉਹਨਾਂ ਨੂੰ ਕਿਵੇਂ ਲੱਭੇਗਾ?

S3 ਵਿੱਚ ਫੋਲਡਰ ਸਿਰਫ ਪ੍ਰਦਰਸ਼ਨ ਲਈ ਹਨ, ਅਸਲ ਵਿੱਚ ਸਿਸਟਮ ਪ੍ਰਤੀਕ ਵਿੱਚ ਦਿਲਚਸਪੀ ਨਹੀਂ ਰੱਖਦਾ ਹੈ /. S3 FAQ ਪੰਨੇ ਤੋਂ।

ਅਜਿਹਾ ਲਗਦਾ ਹੈ ਕਿ S3 ਹੈਸ਼ ਟੇਬਲ ਜਾਂ ਦਸਤਾਵੇਜ਼-ਅਧਾਰਿਤ ਡੇਟਾਬੇਸ ਦੀ ਇੱਕ ਕਿਸਮ ਵਿੱਚ ਇੱਕ ਸਧਾਰਨ ਕੁੰਜੀ ਦੇ ਰੂਪ ਵਿੱਚ ਇੱਕ ਖਾਸ ਫਾਈਲ ਦੇ ਮਾਰਗ ਨੂੰ ਦਰਸਾਉਂਦਾ ਹੈ। ਇੱਕ ਬਾਲਟੀ ਨੂੰ ਇੱਕ ਸਾਰਣੀ ਦੇ ਰੂਪ ਵਿੱਚ ਸੋਚਿਆ ਜਾ ਸਕਦਾ ਹੈ, ਅਤੇ ਫਾਈਲਾਂ ਨੂੰ ਉਸ ਸਾਰਣੀ ਵਿੱਚ ਰਿਕਾਰਡ ਮੰਨਿਆ ਜਾ ਸਕਦਾ ਹੈ।

ਕਿਉਂਕਿ ਐਮਾਜ਼ਾਨ 'ਤੇ ਮੁਨਾਫ਼ਾ ਕਮਾਉਣ ਲਈ ਗਤੀ ਅਤੇ ਕੁਸ਼ਲਤਾ ਮਹੱਤਵਪੂਰਨ ਹਨ, ਇਸ ਲਈ ਇਹ ਕੋਈ ਹੈਰਾਨੀ ਦੀ ਗੱਲ ਨਹੀਂ ਹੈ ਕਿ ਇਹ ਕੁੰਜੀ-ਏ-ਏ-ਫਾਈਲ-ਪਾਥ ਸਿਸਟਮ ਨੂੰ ਅਨੁਕੂਲ ਬਣਾਇਆ ਗਿਆ ਹੈ। ਮੈਂ ਇੱਕ ਸੰਤੁਲਨ ਲੱਭਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਕੀਤੀ: ਤਾਂ ਜੋ ਮੈਨੂੰ ਬਹੁਤ ਸਾਰੀਆਂ ਬੇਨਤੀਆਂ ਕਰਨ ਦੀ ਲੋੜ ਨਾ ਪਵੇ, ਪਰ ਇਹ ਕਿ ਬੇਨਤੀਆਂ ਨੂੰ ਜਲਦੀ ਲਾਗੂ ਕੀਤਾ ਗਿਆ ਸੀ। ਇਹ ਪਤਾ ਚਲਿਆ ਕਿ ਲਗਭਗ 20 ਹਜ਼ਾਰ ਬਿਨ ਫਾਈਲਾਂ ਬਣਾਉਣਾ ਸਭ ਤੋਂ ਵਧੀਆ ਹੈ. ਮੈਨੂੰ ਲਗਦਾ ਹੈ ਕਿ ਜੇ ਅਸੀਂ ਅਨੁਕੂਲ ਬਣਾਉਣਾ ਜਾਰੀ ਰੱਖਦੇ ਹਾਂ, ਤਾਂ ਅਸੀਂ ਗਤੀ ਵਿੱਚ ਵਾਧਾ ਪ੍ਰਾਪਤ ਕਰ ਸਕਦੇ ਹਾਂ (ਉਦਾਹਰਣ ਵਜੋਂ, ਸਿਰਫ ਡੇਟਾ ਲਈ ਇੱਕ ਵਿਸ਼ੇਸ਼ ਬਾਲਟੀ ਬਣਾਉਣਾ, ਇਸ ਤਰ੍ਹਾਂ ਲੁੱਕਅਪ ਟੇਬਲ ਦੇ ਆਕਾਰ ਨੂੰ ਘਟਾਉਣਾ)। ਪਰ ਹੋਰ ਪ੍ਰਯੋਗਾਂ ਲਈ ਕੋਈ ਸਮਾਂ ਜਾਂ ਪੈਸਾ ਨਹੀਂ ਸੀ.

ਕਰਾਸ ਅਨੁਕੂਲਤਾ ਬਾਰੇ ਕੀ?

ਮੈਂ ਕੀ ਸਿੱਖਿਆ: ਸਮੇਂ ਦੀ ਬਰਬਾਦੀ ਦਾ ਨੰਬਰ ਇੱਕ ਕਾਰਨ ਤੁਹਾਡੀ ਸਟੋਰੇਜ ਵਿਧੀ ਨੂੰ ਸਮੇਂ ਤੋਂ ਪਹਿਲਾਂ ਅਨੁਕੂਲ ਬਣਾਉਣਾ ਹੈ।

ਇਸ ਮੌਕੇ 'ਤੇ, ਆਪਣੇ ਆਪ ਤੋਂ ਇਹ ਪੁੱਛਣਾ ਬਹੁਤ ਮਹੱਤਵਪੂਰਨ ਹੈ: "ਇੱਕ ਮਲਕੀਅਤ ਵਾਲੀ ਫਾਈਲ ਫਾਰਮੈਟ ਦੀ ਵਰਤੋਂ ਕਿਉਂ ਕਰੋ?" ਇਸ ਦਾ ਕਾਰਨ ਲੋਡ ਕਰਨ ਦੀ ਗਤੀ (gzipped CSV ਫਾਈਲਾਂ ਨੂੰ ਲੋਡ ਹੋਣ ਵਿੱਚ 7 ​​ਗੁਣਾ ਜ਼ਿਆਦਾ ਸਮਾਂ ਲੱਗਾ) ਅਤੇ ਸਾਡੇ ਵਰਕਫਲੋਜ਼ ਨਾਲ ਅਨੁਕੂਲਤਾ ਵਿੱਚ ਹੈ। ਮੈਂ ਮੁੜ ਵਿਚਾਰ ਕਰ ਸਕਦਾ ਹਾਂ ਕਿ ਕੀ R ਸਪਾਰਕ ਲੋਡ ਤੋਂ ਬਿਨਾਂ ਪਾਰਕੁਏਟ (ਜਾਂ ਐਰੋ) ਫਾਈਲਾਂ ਨੂੰ ਆਸਾਨੀ ਨਾਲ ਲੋਡ ਕਰ ਸਕਦਾ ਹੈ। ਸਾਡੀ ਲੈਬ ਵਿੱਚ ਹਰ ਕੋਈ R ਦੀ ਵਰਤੋਂ ਕਰਦਾ ਹੈ, ਅਤੇ ਜੇਕਰ ਮੈਨੂੰ ਡੇਟਾ ਨੂੰ ਕਿਸੇ ਹੋਰ ਫਾਰਮੈਟ ਵਿੱਚ ਬਦਲਣ ਦੀ ਲੋੜ ਹੈ, ਤਾਂ ਮੇਰੇ ਕੋਲ ਅਜੇ ਵੀ ਮੂਲ ਟੈਕਸਟ ਡੇਟਾ ਹੈ, ਇਸਲਈ ਮੈਂ ਦੁਬਾਰਾ ਪਾਈਪਲਾਈਨ ਚਲਾ ਸਕਦਾ ਹਾਂ।

ਕੰਮ ਦੀ ਵੰਡ

ਮੈਂ ਕੀ ਸਿੱਖਿਆ ਹੈ: ਨੌਕਰੀਆਂ ਨੂੰ ਹੱਥੀਂ ਅਨੁਕੂਲ ਬਣਾਉਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਨਾ ਕਰੋ, ਕੰਪਿਊਟਰ ਨੂੰ ਅਜਿਹਾ ਕਰਨ ਦਿਓ।

ਮੈਂ ਇੱਕ ਕ੍ਰੋਮੋਸੋਮ 'ਤੇ ਵਰਕਫਲੋ ਨੂੰ ਡੀਬੱਗ ਕੀਤਾ ਹੈ, ਹੁਣ ਮੈਨੂੰ ਬਾਕੀ ਸਾਰੇ ਡੇਟਾ ਦੀ ਪ੍ਰਕਿਰਿਆ ਕਰਨ ਦੀ ਲੋੜ ਹੈ।
ਮੈਂ ਪਰਿਵਰਤਨ ਲਈ ਕਈ EC2 ਉਦਾਹਰਨਾਂ ਨੂੰ ਵਧਾਉਣਾ ਚਾਹੁੰਦਾ ਸੀ, ਪਰ ਉਸੇ ਸਮੇਂ ਮੈਂ ਵੱਖ-ਵੱਖ ਪ੍ਰੋਸੈਸਿੰਗ ਨੌਕਰੀਆਂ ਵਿੱਚ ਬਹੁਤ ਅਸੰਤੁਲਿਤ ਲੋਡ ਪ੍ਰਾਪਤ ਕਰਨ ਤੋਂ ਡਰਦਾ ਸੀ (ਜਿਵੇਂ ਕਿ ਸਪਾਰਕ ਅਸੰਤੁਲਿਤ ਭਾਗਾਂ ਤੋਂ ਪੀੜਤ ਸੀ)। ਇਸ ਤੋਂ ਇਲਾਵਾ, ਮੈਨੂੰ ਪ੍ਰਤੀ ਕ੍ਰੋਮੋਸੋਮ ਇੱਕ ਉਦਾਹਰਨ ਵਧਾਉਣ ਵਿੱਚ ਕੋਈ ਦਿਲਚਸਪੀ ਨਹੀਂ ਸੀ, ਕਿਉਂਕਿ AWS ਖਾਤਿਆਂ ਲਈ 10 ਮੌਕਿਆਂ ਦੀ ਇੱਕ ਡਿਫੌਲਟ ਸੀਮਾ ਹੈ।

ਫਿਰ ਮੈਂ ਪ੍ਰੋਸੈਸਿੰਗ ਨੌਕਰੀਆਂ ਨੂੰ ਅਨੁਕੂਲ ਬਣਾਉਣ ਲਈ ਆਰ ਵਿੱਚ ਇੱਕ ਸਕ੍ਰਿਪਟ ਲਿਖਣ ਦਾ ਫੈਸਲਾ ਕੀਤਾ।

ਪਹਿਲਾਂ, ਮੈਂ 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

ਅੰਤ ਵਿੱਚ ਮੈਂ shutdown ਕਮਾਂਡ ਜੋੜਦਾ ਹਾਂ:

sudo shutdown -h now

... ਅਤੇ ਸਭ ਕੁਝ ਕੰਮ ਕੀਤਾ! AWS CLI ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋਏ, ਮੈਂ ਵਿਕਲਪ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਉਦਾਹਰਣਾਂ ਨੂੰ ਉਭਾਰਿਆ user_data ਉਹਨਾਂ ਨੂੰ ਪ੍ਰੋਸੈਸਿੰਗ ਲਈ ਉਹਨਾਂ ਦੇ ਕੰਮਾਂ ਦੀਆਂ Bash ਸਕ੍ਰਿਪਟਾਂ ਦਿੱਤੀਆਂ। ਉਹ ਦੌੜ ਗਏ ਅਤੇ ਆਪਣੇ ਆਪ ਬੰਦ ਹੋ ਗਏ, ਇਸਲਈ ਮੈਂ ਵਾਧੂ ਪ੍ਰੋਸੈਸਿੰਗ ਪਾਵਰ ਲਈ ਭੁਗਤਾਨ ਨਹੀਂ ਕਰ ਰਿਹਾ ਸੀ।

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

ਆਓ ਪੈਕ ਕਰੀਏ!

ਮੈਂ ਕੀ ਸਿੱਖਿਆ ਹੈ: API ਨੂੰ ਵਰਤੋਂ ਵਿੱਚ ਆਸਾਨੀ ਅਤੇ ਲਚਕਤਾ ਦੀ ਖ਼ਾਤਰ ਸਧਾਰਨ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ।

ਅੰਤ ਵਿੱਚ ਮੈਨੂੰ ਸਹੀ ਜਗ੍ਹਾ ਅਤੇ ਫਾਰਮ ਵਿੱਚ ਡੇਟਾ ਮਿਲਿਆ. ਮੇਰੇ ਸਾਥੀਆਂ ਲਈ ਇਸ ਨੂੰ ਆਸਾਨ ਬਣਾਉਣ ਲਈ ਜਿੰਨਾ ਸੰਭਵ ਹੋ ਸਕੇ ਡੇਟਾ ਦੀ ਵਰਤੋਂ ਕਰਨ ਦੀ ਪ੍ਰਕਿਰਿਆ ਨੂੰ ਸਰਲ ਬਣਾਉਣਾ ਬਾਕੀ ਸੀ। ਮੈਂ ਬੇਨਤੀਆਂ ਬਣਾਉਣ ਲਈ ਇੱਕ ਸਧਾਰਨ API ਬਣਾਉਣਾ ਚਾਹੁੰਦਾ ਸੀ. ਜੇਕਰ ਭਵਿੱਖ ਵਿੱਚ ਮੈਂ ਇਸ ਤੋਂ ਬਦਲਣ ਦਾ ਫੈਸਲਾ ਕਰਦਾ ਹਾਂ .rds Parquet ਫਾਈਲਾਂ ਲਈ, ਤਾਂ ਇਹ ਮੇਰੇ ਲਈ ਇੱਕ ਸਮੱਸਿਆ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ, ਮੇਰੇ ਸਾਥੀਆਂ ਲਈ ਨਹੀਂ। ਇਸਦੇ ਲਈ ਮੈਂ ਇੱਕ ਅੰਦਰੂਨੀ ਆਰ ਪੈਕੇਜ ਬਣਾਉਣ ਦਾ ਫੈਸਲਾ ਕੀਤਾ।

ਇੱਕ ਬਹੁਤ ਹੀ ਸਧਾਰਨ ਪੈਕੇਜ ਬਣਾਓ ਅਤੇ ਦਸਤਾਵੇਜ਼ ਬਣਾਓ ਜਿਸ ਵਿੱਚ ਇੱਕ ਫੰਕਸ਼ਨ ਦੇ ਆਲੇ-ਦੁਆਲੇ ਸੰਗਠਿਤ ਕੁਝ ਡਾਟਾ ਐਕਸੈਸ ਫੰਕਸ਼ਨਾਂ ਸ਼ਾਮਲ ਹਨ get_snp. ਮੈਂ ਆਪਣੇ ਸਾਥੀਆਂ ਲਈ ਇੱਕ ਵੈਬਸਾਈਟ ਵੀ ਬਣਾਈ ਹੈ pkgdown, ਤਾਂ ਜੋ ਉਹ ਆਸਾਨੀ ਨਾਲ ਉਦਾਹਰਣਾਂ ਅਤੇ ਦਸਤਾਵੇਜ਼ ਦੇਖ ਸਕਣ।

ਸਮਾਰਟ ਕੈਚਿੰਗ

ਮੈਂ ਕੀ ਸਿੱਖਿਆ ਹੈ: ਜੇਕਰ ਤੁਹਾਡਾ ਡੇਟਾ ਚੰਗੀ ਤਰ੍ਹਾਂ ਤਿਆਰ ਹੈ, ਤਾਂ ਕੈਚਿੰਗ ਆਸਾਨ ਹੋ ਜਾਵੇਗੀ!

ਕਿਉਂਕਿ ਮੁੱਖ ਵਰਕਫਲੋਜ਼ ਵਿੱਚੋਂ ਇੱਕ ਨੇ SNP ਪੈਕੇਜ ਲਈ ਇੱਕੋ ਵਿਸ਼ਲੇਸ਼ਣ ਮਾਡਲ ਨੂੰ ਲਾਗੂ ਕੀਤਾ ਹੈ, ਮੈਂ ਆਪਣੇ ਫਾਇਦੇ ਲਈ ਬਿਨਿੰਗ ਦੀ ਵਰਤੋਂ ਕਰਨ ਦਾ ਫੈਸਲਾ ਕੀਤਾ ਹੈ। SNP ਦੁਆਰਾ ਡੇਟਾ ਪ੍ਰਸਾਰਿਤ ਕਰਦੇ ਸਮੇਂ, ਸਮੂਹ (ਬਿਨ) ਤੋਂ ਸਾਰੀ ਜਾਣਕਾਰੀ ਵਾਪਸ ਕੀਤੀ ਵਸਤੂ ਨਾਲ ਜੁੜੀ ਹੁੰਦੀ ਹੈ। ਭਾਵ, ਪੁਰਾਣੀਆਂ ਪੁੱਛਗਿੱਛਾਂ (ਸਿਧਾਂਤਕ ਰੂਪ ਵਿੱਚ) ਨਵੀਆਂ ਪੁੱਛਗਿੱਛਾਂ ਦੀ ਪ੍ਰਕਿਰਿਆ ਨੂੰ ਤੇਜ਼ ਕਰ ਸਕਦੀਆਂ ਹਨ।

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

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

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

ਪੈਕੇਜ ਬਣਾਉਂਦੇ ਸਮੇਂ, ਮੈਂ ਵੱਖ-ਵੱਖ ਤਰੀਕਿਆਂ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਸਮੇਂ ਗਤੀ ਦੀ ਤੁਲਨਾ ਕਰਨ ਲਈ ਬਹੁਤ ਸਾਰੇ ਮਾਪਦੰਡ ਚਲਾਏ. ਮੈਂ ਇਸ ਨੂੰ ਨਜ਼ਰਅੰਦਾਜ਼ ਨਾ ਕਰਨ ਦੀ ਸਿਫਾਰਸ਼ ਕਰਦਾ ਹਾਂ, ਕਿਉਂਕਿ ਕਈ ਵਾਰ ਨਤੀਜੇ ਅਚਾਨਕ ਹੁੰਦੇ ਹਨ. ਉਦਾਹਰਣ ਲਈ, dplyr::filter ਇੰਡੈਕਸਿੰਗ-ਅਧਾਰਿਤ ਫਿਲਟਰਿੰਗ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਕਤਾਰਾਂ ਨੂੰ ਕੈਪਚਰ ਕਰਨ ਨਾਲੋਂ ਬਹੁਤ ਤੇਜ਼ ਸੀ, ਅਤੇ ਫਿਲਟਰ ਕੀਤੇ ਡੇਟਾ ਫਰੇਮ ਤੋਂ ਸਿੰਗਲ ਕਾਲਮ ਨੂੰ ਮੁੜ ਪ੍ਰਾਪਤ ਕਰਨਾ ਇੰਡੈਕਸਿੰਗ ਸੰਟੈਕਸ ਦੀ ਵਰਤੋਂ ਕਰਨ ਨਾਲੋਂ ਬਹੁਤ ਤੇਜ਼ ਸੀ।

ਕਿਰਪਾ ਕਰਕੇ ਧਿਆਨ ਦਿਓ ਕਿ ਵਸਤੂ prev_snp_results ਕੁੰਜੀ ਸ਼ਾਮਿਲ ਹੈ snps_in_bin. ਇਹ ਇੱਕ ਸਮੂਹ (ਬਿਨ) ਵਿੱਚ ਸਾਰੇ ਵਿਲੱਖਣ SNPs ਦੀ ਇੱਕ ਲੜੀ ਹੈ, ਜਿਸ ਨਾਲ ਤੁਸੀਂ ਤੁਰੰਤ ਜਾਂਚ ਕਰ ਸਕਦੇ ਹੋ ਕਿ ਕੀ ਤੁਹਾਡੇ ਕੋਲ ਪਹਿਲਾਂ ਤੋਂ ਹੀ ਪਿਛਲੀ ਪੁੱਛਗਿੱਛ ਤੋਂ ਡੇਟਾ ਹੈ ਜਾਂ ਨਹੀਂ। ਇਹ ਇਸ ਕੋਡ ਨਾਲ ਸਮੂਹ (ਬਿਨ) ਵਿੱਚ ਸਾਰੇ SNPs ਨੂੰ ਲੂਪ ਕਰਨਾ ਵੀ ਆਸਾਨ ਬਣਾਉਂਦਾ ਹੈ:

# Get bin-mates
snps_in_bin <- my_snp_results$snps_in_bin

for(current_snp in snps_in_bin){
  my_snp_results <- get_snp(current_snp, my_snp_results)
  # Do something with results 
}

Результаты

ਹੁਣ ਅਸੀਂ ਮਾਡਲਾਂ ਅਤੇ ਦ੍ਰਿਸ਼ਾਂ ਨੂੰ ਚਲਾ ਸਕਦੇ ਹਾਂ (ਅਤੇ ਗੰਭੀਰਤਾ ਨਾਲ ਸ਼ੁਰੂ ਕਰ ਦਿੱਤਾ ਹੈ) ਜੋ ਪਹਿਲਾਂ ਸਾਡੇ ਲਈ ਪਹੁੰਚ ਤੋਂ ਬਾਹਰ ਸਨ। ਸਭ ਤੋਂ ਵਧੀਆ ਗੱਲ ਇਹ ਹੈ ਕਿ ਮੇਰੇ ਲੈਬ ਸਾਥੀਆਂ ਨੂੰ ਕਿਸੇ ਵੀ ਪੇਚੀਦਗੀ ਬਾਰੇ ਸੋਚਣ ਦੀ ਲੋੜ ਨਹੀਂ ਹੈ। ਉਹਨਾਂ ਕੋਲ ਸਿਰਫ ਇੱਕ ਫੰਕਸ਼ਨ ਹੈ ਜੋ ਕੰਮ ਕਰਦਾ ਹੈ.

ਅਤੇ ਹਾਲਾਂਕਿ ਪੈਕੇਜ ਉਹਨਾਂ ਨੂੰ ਵੇਰਵਿਆਂ ਤੋਂ ਬਚਾਉਂਦਾ ਹੈ, ਮੈਂ ਡੇਟਾ ਫਾਰਮੈਟ ਨੂੰ ਇੰਨਾ ਸਰਲ ਬਣਾਉਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਕੀਤੀ ਕਿ ਉਹ ਇਸ ਗੱਲ ਦਾ ਪਤਾ ਲਗਾ ਸਕਣ ਕਿ ਕੀ ਮੈਂ ਕੱਲ੍ਹ ਅਚਾਨਕ ਗਾਇਬ ਹੋ ਗਿਆ ...

ਰਫ਼ਤਾਰ ਵਿੱਚ ਕਾਫ਼ੀ ਵਾਧਾ ਹੋਇਆ ਹੈ। ਅਸੀਂ ਆਮ ਤੌਰ 'ਤੇ ਕਾਰਜਸ਼ੀਲ ਤੌਰ 'ਤੇ ਮਹੱਤਵਪੂਰਨ ਜੀਨੋਮ ਦੇ ਟੁਕੜਿਆਂ ਨੂੰ ਸਕੈਨ ਕਰਦੇ ਹਾਂ। ਪਹਿਲਾਂ, ਅਸੀਂ ਅਜਿਹਾ ਨਹੀਂ ਕਰ ਸਕਦੇ ਸੀ (ਇਹ ਬਹੁਤ ਮਹਿੰਗਾ ਨਿਕਲਿਆ), ਪਰ ਹੁਣ, ਸਮੂਹ (ਬਿਨ) ਢਾਂਚੇ ਅਤੇ ਕੈਚਿੰਗ ਲਈ ਧੰਨਵਾਦ, ਇੱਕ SNP ਲਈ ਬੇਨਤੀ ਔਸਤਨ 0,1 ਸਕਿੰਟਾਂ ਤੋਂ ਘੱਟ ਲੈਂਦੀ ਹੈ, ਅਤੇ ਡੇਟਾ ਦੀ ਵਰਤੋਂ ਇੰਨੀ ਹੈ ਘੱਟ ਹੈ ਕਿ S3 ਦੀ ਲਾਗਤ ਮੂੰਗਫਲੀ ਹੈ।

ਹਾਲ ਹੀ ਵਿੱਚ ਮੈਨੂੰ ਆਪਣੀ ਲੈਬ ਲਈ ਕੱਚੇ ਜੀਨੋਟਾਈਪਿੰਗ ਡੇਟਾ ਦੇ 25+ ਟੀਬੀ ਦੇ ਝਗੜੇ ਵਿੱਚ ਤਬਦੀਲੀ ਕੀਤੀ ਗਈ ਹੈ। ਜਦੋਂ ਮੈਂ ਸ਼ੁਰੂ ਕੀਤਾ, ਸਪਾਰਕ ਦੀ ਵਰਤੋਂ ਕਰਨ ਵਿੱਚ 8 ਮਿੰਟ ਲੱਗੇ ਅਤੇ ਇੱਕ SNP ਦੀ ਪੁੱਛਗਿੱਛ ਲਈ $20 ਦੀ ਲਾਗਤ ਆਈ। AWK+ ਦੀ ਵਰਤੋਂ ਕਰਨ ਤੋਂ ਬਾਅਦ # ਅੰਕੜੇ ਪ੍ਰਕਿਰਿਆ ਕਰਨ ਲਈ, ਇਹ ਹੁਣ ਇੱਕ ਸਕਿੰਟ ਦੇ 10ਵੇਂ ਹਿੱਸੇ ਤੋਂ ਘੱਟ ਲੈਂਦਾ ਹੈ ਅਤੇ ਇਸਦੀ ਕੀਮਤ $0.00001 ਹੈ। ਮੇਰੀ ਨਿੱਜੀ # ਬਿਗਡਾਟਾ ਜਿੱਤ. pic.twitter.com/ANOXVGrmkk

- ਨਿਕ ਸਟ੍ਰੇਅਰ (@ ਨਿਕੋਲਸ ਸਟ੍ਰੇਅਰ) 30 ਮਈ, 2019

ਸਿੱਟਾ

ਇਹ ਲੇਖ ਬਿਲਕੁਲ ਵੀ ਗਾਈਡ ਨਹੀਂ ਹੈ। ਹੱਲ ਵਿਅਕਤੀਗਤ ਨਿਕਲਿਆ, ਅਤੇ ਲਗਭਗ ਯਕੀਨੀ ਤੌਰ 'ਤੇ ਅਨੁਕੂਲ ਨਹੀਂ ਹੈ. ਸਗੋਂ ਇਹ ਇੱਕ ਸਫ਼ਰਨਾਮਾ ਹੈ। ਮੈਂ ਚਾਹੁੰਦਾ ਹਾਂ ਕਿ ਦੂਸਰੇ ਇਹ ਸਮਝਣ ਕਿ ਅਜਿਹੇ ਫੈਸਲੇ ਸਿਰ ਵਿੱਚ ਪੂਰੀ ਤਰ੍ਹਾਂ ਬਣਦੇ ਨਹੀਂ ਦਿਖਾਈ ਦਿੰਦੇ ਹਨ, ਉਹ ਅਜ਼ਮਾਇਸ਼ ਅਤੇ ਗਲਤੀ ਦਾ ਨਤੀਜਾ ਹਨ। ਨਾਲ ਹੀ, ਜੇਕਰ ਤੁਸੀਂ ਇੱਕ ਡੇਟਾ ਸਾਇੰਟਿਸਟ ਦੀ ਭਾਲ ਕਰ ਰਹੇ ਹੋ, ਤਾਂ ਇਹ ਧਿਆਨ ਵਿੱਚ ਰੱਖੋ ਕਿ ਇਹਨਾਂ ਸਾਧਨਾਂ ਨੂੰ ਪ੍ਰਭਾਵਸ਼ਾਲੀ ਢੰਗ ਨਾਲ ਵਰਤਣ ਲਈ ਤਜਰਬੇ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ, ਅਤੇ ਤਜਰਬੇ ਦਾ ਖਰਚਾ ਹੁੰਦਾ ਹੈ। ਮੈਂ ਖੁਸ਼ ਹਾਂ ਕਿ ਮੇਰੇ ਕੋਲ ਭੁਗਤਾਨ ਕਰਨ ਦਾ ਸਾਧਨ ਸੀ, ਪਰ ਬਹੁਤ ਸਾਰੇ ਹੋਰ ਜੋ ਮੇਰੇ ਨਾਲੋਂ ਵਧੀਆ ਕੰਮ ਕਰ ਸਕਦੇ ਹਨ, ਪੈਸੇ ਦੀ ਘਾਟ ਕਾਰਨ ਕਦੇ ਵੀ ਕੋਸ਼ਿਸ਼ ਕਰਨ ਦਾ ਮੌਕਾ ਨਹੀਂ ਮਿਲੇਗਾ।

ਵੱਡੇ ਡੇਟਾ ਟੂਲ ਬਹੁਮੁਖੀ ਹਨ। ਜੇਕਰ ਤੁਹਾਡੇ ਕੋਲ ਸਮਾਂ ਹੈ, ਤਾਂ ਤੁਸੀਂ ਸਮਾਰਟ ਡਾਟਾ ਕਲੀਨਿੰਗ, ਸਟੋਰੇਜ, ਅਤੇ ਐਕਸਟਰੈਕਸ਼ਨ ਤਕਨੀਕਾਂ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਇੱਕ ਤੇਜ਼ ਹੱਲ ਲਿਖ ਸਕਦੇ ਹੋ। ਆਖਰਕਾਰ ਇਹ ਲਾਗਤ-ਲਾਭ ਵਿਸ਼ਲੇਸ਼ਣ 'ਤੇ ਆਉਂਦਾ ਹੈ।

ਮੈਂ ਕੀ ਸਿੱਖਿਆ:

• ਇੱਕ ਸਮੇਂ ਵਿੱਚ 25 ਟੀਬੀ ਨੂੰ ਪਾਰਸ ਕਰਨ ਦਾ ਕੋਈ ਸਸਤਾ ਤਰੀਕਾ ਨਹੀਂ ਹੈ;
• ਆਪਣੀਆਂ Parquet ਫਾਈਲਾਂ ਦੇ ਆਕਾਰ ਅਤੇ ਉਹਨਾਂ ਦੇ ਸੰਗਠਨ ਨਾਲ ਸਾਵਧਾਨ ਰਹੋ;
• ਸਪਾਰਕ ਵਿੱਚ ਭਾਗ ਸੰਤੁਲਿਤ ਹੋਣੇ ਚਾਹੀਦੇ ਹਨ;
• ਆਮ ਤੌਰ 'ਤੇ, ਕਦੇ ਵੀ 2,5 ਮਿਲੀਅਨ ਭਾਗ ਬਣਾਉਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਨਾ ਕਰੋ;
• ਛਾਂਟੀ ਕਰਨਾ ਅਜੇ ਵੀ ਮੁਸ਼ਕਲ ਹੈ, ਜਿਵੇਂ ਕਿ ਸਪਾਰਕ ਸਥਾਪਤ ਕਰਨਾ;
• ਕਈ ਵਾਰ ਵਿਸ਼ੇਸ਼ ਡੇਟਾ ਲਈ ਵਿਸ਼ੇਸ਼ ਹੱਲ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ;
• ਸਪਾਰਕ ਐਗਰੀਗੇਸ਼ਨ ਤੇਜ਼ ਹੈ, ਪਰ ਵਿਭਾਗੀਕਰਨ ਅਜੇ ਵੀ ਮਹਿੰਗਾ ਹੈ;
• ਜਦੋਂ ਉਹ ਤੁਹਾਨੂੰ ਬੁਨਿਆਦ ਸਿਖਾਉਂਦੇ ਹਨ ਤਾਂ ਨੀਂਦ ਨਾ ਲਓ, ਸ਼ਾਇਦ ਕਿਸੇ ਨੇ 1980 ਦੇ ਦਹਾਕੇ ਵਿੱਚ ਤੁਹਾਡੀ ਸਮੱਸਿਆ ਦਾ ਹੱਲ ਕੀਤਾ ਹੈ;
• gnu parallel - ਇਹ ਇੱਕ ਜਾਦੂਈ ਚੀਜ਼ ਹੈ, ਹਰ ਕਿਸੇ ਨੂੰ ਇਸਦੀ ਵਰਤੋਂ ਕਰਨੀ ਚਾਹੀਦੀ ਹੈ;
• ਸਪਾਰਕ ਅਸੰਕੁਚਿਤ ਡੇਟਾ ਨੂੰ ਪਸੰਦ ਕਰਦਾ ਹੈ ਅਤੇ ਭਾਗਾਂ ਨੂੰ ਜੋੜਨਾ ਪਸੰਦ ਨਹੀਂ ਕਰਦਾ;
• ਸਧਾਰਨ ਸਮੱਸਿਆਵਾਂ ਨੂੰ ਹੱਲ ਕਰਨ ਵੇਲੇ ਸਪਾਰਕ ਦਾ ਬਹੁਤ ਜ਼ਿਆਦਾ ਓਵਰਹੈੱਡ ਹੁੰਦਾ ਹੈ;
• AWK ਦੇ ਸਹਿਯੋਗੀ ਐਰੇ ਬਹੁਤ ਕੁਸ਼ਲ ਹਨ;
• ਤੁਸੀਂ ਸੰਪਰਕ ਕਰ ਸਕਦੇ ਹੋ stdin и stdout ਇੱਕ ਆਰ ਸਕ੍ਰਿਪਟ ਤੋਂ, ਅਤੇ ਇਸਲਈ ਇਸਨੂੰ ਪਾਈਪਲਾਈਨ ਵਿੱਚ ਵਰਤੋ;
• ਸਮਾਰਟ ਮਾਰਗ ਲਾਗੂ ਕਰਨ ਲਈ ਧੰਨਵਾਦ, S3 ਬਹੁਤ ਸਾਰੀਆਂ ਫਾਈਲਾਂ ਦੀ ਪ੍ਰਕਿਰਿਆ ਕਰ ਸਕਦਾ ਹੈ;
• ਸਮਾਂ ਬਰਬਾਦ ਕਰਨ ਦਾ ਮੁੱਖ ਕਾਰਨ ਸਮੇਂ ਤੋਂ ਪਹਿਲਾਂ ਤੁਹਾਡੀ ਸਟੋਰੇਜ ਵਿਧੀ ਨੂੰ ਅਨੁਕੂਲ ਬਣਾਉਣਾ ਹੈ;
• ਕਾਰਜਾਂ ਨੂੰ ਹੱਥੀਂ ਅਨੁਕੂਲ ਬਣਾਉਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਨਾ ਕਰੋ, ਕੰਪਿਊਟਰ ਨੂੰ ਇਹ ਕਰਨ ਦਿਓ;
• ਵਰਤੋਂ ਦੀ ਸੌਖ ਅਤੇ ਲਚਕਤਾ ਲਈ API ਨੂੰ ਸਧਾਰਨ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ;
• ਜੇ ਤੁਹਾਡਾ ਡੇਟਾ ਚੰਗੀ ਤਰ੍ਹਾਂ ਤਿਆਰ ਹੈ, ਤਾਂ ਕੈਚਿੰਗ ਆਸਾਨ ਹੋ ਜਾਵੇਗੀ!

ਸਰੋਤ: www.habr.com