ਡਾਟਾ ਸਾਇੰਸ ਨਾਲ ਕੀ ਗਲਤ ਹੋ ਸਕਦਾ ਹੈ? ਡਾਟਾ ਇਕੱਠਾ ਕਰਨ

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

ਇਸ ਲਈ, ਅਸੀਂ ਮੇਰੇ, ਮੇਰੇ ਸਾਥੀਆਂ ਅਤੇ ਸਾਥੀਆਂ ਨਾਲ ਵਾਪਰੀਆਂ ਅਸਲ ਘਟਨਾਵਾਂ ਦੇ ਅਧਾਰ 'ਤੇ, "ਡੇਟਾ ਸਾਇੰਸ ਵਿੱਚ ਕੀ ਗਲਤ ਹੋ ਸਕਦਾ ਹੈ" ਨੋਟਸ ਦੀ ਇੱਕ ਲੜੀ ਸ਼ੁਰੂ ਕਰ ਰਹੇ ਹਾਂ। ਅਸੀਂ ਅਸਲ ਉਦਾਹਰਣਾਂ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋਏ ਆਮ ਡੇਟਾ ਸਾਇੰਸ ਕੰਮਾਂ ਦਾ ਵਿਸ਼ਲੇਸ਼ਣ ਕਰਾਂਗੇ: ਇਹ ਅਸਲ ਵਿੱਚ ਕਿਵੇਂ ਹੁੰਦਾ ਹੈ। ਆਉ ਅੱਜ ਡਾਟਾ ਇਕੱਠਾ ਕਰਨ ਦੇ ਕੰਮ ਨਾਲ ਸ਼ੁਰੂ ਕਰੀਏ।

ਅਤੇ ਸਭ ਤੋਂ ਪਹਿਲਾਂ ਜਦੋਂ ਲੋਕ ਅਸਲ ਡੇਟਾ ਨਾਲ ਕੰਮ ਕਰਨਾ ਸ਼ੁਰੂ ਕਰਦੇ ਹਨ ਤਾਂ ਉਹ ਅਸਲ ਵਿੱਚ ਇਸ ਡੇਟਾ ਨੂੰ ਇਕੱਠਾ ਕਰ ਰਿਹਾ ਹੈ ਜੋ ਸਾਡੇ ਲਈ ਸਭ ਤੋਂ ਢੁਕਵਾਂ ਹੈ। ਇਸ ਲੇਖ ਦਾ ਮੁੱਖ ਸੰਦੇਸ਼:

ਅਸੀਂ ਡੇਟਾ ਨੂੰ ਇਕੱਠਾ ਕਰਨ, ਸਾਫ਼ ਕਰਨ ਅਤੇ ਤਿਆਰ ਕਰਨ ਲਈ ਲੋੜੀਂਦੇ ਸਮੇਂ, ਸਰੋਤਾਂ ਅਤੇ ਮਿਹਨਤ ਨੂੰ ਯੋਜਨਾਬੱਧ ਢੰਗ ਨਾਲ ਘੱਟ ਸਮਝਦੇ ਹਾਂ।

ਅਤੇ ਸਭ ਤੋਂ ਮਹੱਤਵਪੂਰਨ, ਅਸੀਂ ਇਸ ਬਾਰੇ ਚਰਚਾ ਕਰਾਂਗੇ ਕਿ ਇਸ ਨੂੰ ਰੋਕਣ ਲਈ ਕੀ ਕਰਨਾ ਹੈ।

ਵੱਖ-ਵੱਖ ਅਨੁਮਾਨਾਂ ਦੇ ਅਨੁਸਾਰ, ਸਫਾਈ, ਪਰਿਵਰਤਨ, ਡੇਟਾ ਪ੍ਰੋਸੈਸਿੰਗ, ਵਿਸ਼ੇਸ਼ਤਾ ਇੰਜੀਨੀਅਰਿੰਗ, ਆਦਿ ਵਿੱਚ 80-90% ਸਮਾਂ ਲੱਗਦਾ ਹੈ, ਅਤੇ ਵਿਸ਼ਲੇਸ਼ਣ 10-20%, ਜਦੋਂ ਕਿ ਲਗਭਗ ਸਾਰੀ ਵਿਦਿਅਕ ਸਮੱਗਰੀ ਵਿਸ਼ਲੇਸ਼ਣ 'ਤੇ ਵਿਸ਼ੇਸ਼ ਤੌਰ 'ਤੇ ਕੇਂਦਰਿਤ ਹੁੰਦੀ ਹੈ।

ਆਉ ਇੱਕ ਸਧਾਰਨ ਉਦਾਹਰਨ ਦੇ ਤੌਰ ਤੇ ਤਿੰਨ ਸੰਸਕਰਣਾਂ ਵਿੱਚ ਇੱਕ ਸਧਾਰਨ ਵਿਸ਼ਲੇਸ਼ਣਾਤਮਕ ਸਮੱਸਿਆ ਨੂੰ ਵੇਖੀਏ ਅਤੇ ਵੇਖੀਏ ਕਿ "ਵਧਾਉਣ ਵਾਲੇ ਹਾਲਾਤ" ਕੀ ਹਨ।

ਅਤੇ ਇੱਕ ਉਦਾਹਰਨ ਦੇ ਤੌਰ 'ਤੇ, ਦੁਬਾਰਾ, ਅਸੀਂ ਡੇਟਾ ਇਕੱਠਾ ਕਰਨ ਅਤੇ ਭਾਈਚਾਰਿਆਂ ਦੀ ਤੁਲਨਾ ਕਰਨ ਦੇ ਕੰਮ ਦੇ ਸਮਾਨ ਭਿੰਨਤਾਵਾਂ 'ਤੇ ਵਿਚਾਰ ਕਰਾਂਗੇ:

1. ਦੋ Reddit subreddits
2. ਹਬਰ ਦੇ ਦੋ ਭਾਗ
3. Odnoklassniki ਦੇ ਦੋ ਗਰੁੱਪ

ਸਿਧਾਂਤ ਵਿੱਚ ਸ਼ਰਤੀਆ ਪਹੁੰਚ

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

ਮੁੱਖ ਬਿੰਦੂ: ਸਮੇਂ ਦੇ ਅਨੁਮਾਨ ਅਨੁਮਾਨਾਂ ਅਤੇ ਅਨੁਮਾਨਾਂ 'ਤੇ ਅਧਾਰਤ ਹੁੰਦੇ ਹਨ ਕਿ ਇਹ ਕਿੰਨਾ ਸਮਾਂ ਲਵੇਗਾ।

ਉੱਪਰ ਦੱਸੇ ਗਏ ਸ਼ਰਤੀਆ ਸਮੱਸਿਆ ਲਈ ਹੇਠਾਂ ਦਿੱਤੇ ਮਾਪਦੰਡਾਂ ਦਾ ਅੰਦਾਜ਼ਾ ਲਗਾ ਕੇ ਸਮਾਂ ਵਿਸ਼ਲੇਸ਼ਣ ਸ਼ੁਰੂ ਕਰਨਾ ਜ਼ਰੂਰੀ ਹੈ:

• ਡੇਟਾ ਦਾ ਆਕਾਰ ਕੀ ਹੈ ਅਤੇ ਇਸ ਨੂੰ ਸਰੀਰਕ ਤੌਰ 'ਤੇ ਇਕੱਠਾ ਕਰਨ ਦੀ ਕਿੰਨੀ ਲੋੜ ਹੈ (*ਹੇਠਾਂ ਦੇਖੋ*)।
• ਇੱਕ ਰਿਕਾਰਡ ਲਈ ਇਕੱਠਾ ਕਰਨ ਦਾ ਸਮਾਂ ਕੀ ਹੈ ਅਤੇ ਦੂਜਾ ਇਕੱਠਾ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਤੁਹਾਨੂੰ ਕਿੰਨਾ ਸਮਾਂ ਉਡੀਕ ਕਰਨੀ ਪਵੇਗੀ?
• ਕੋਡ ਲਿਖਣ 'ਤੇ ਵਿਚਾਰ ਕਰੋ ਜੋ ਰਾਜ ਨੂੰ ਬਚਾਉਂਦਾ ਹੈ ਅਤੇ (ਜੇ ਨਹੀਂ) ਸਭ ਕੁਝ ਅਸਫਲ ਹੋਣ 'ਤੇ ਮੁੜ ਚਾਲੂ ਹੁੰਦਾ ਹੈ।
• ਇਹ ਪਤਾ ਲਗਾਓ ਕਿ ਕੀ ਸਾਨੂੰ ਅਧਿਕਾਰ ਦੀ ਲੋੜ ਹੈ ਅਤੇ API ਦੁਆਰਾ ਪਹੁੰਚ ਪ੍ਰਾਪਤ ਕਰਨ ਲਈ ਸਮਾਂ ਸੈੱਟ ਕਰੋ।
• ਡਾਟਾ ਗੁੰਝਲਤਾ ਦੇ ਇੱਕ ਫੰਕਸ਼ਨ ਦੇ ਤੌਰ ਤੇ ਗਲਤੀਆਂ ਦੀ ਸੰਖਿਆ ਸੈਟ ਕਰੋ - ਇੱਕ ਖਾਸ ਕੰਮ ਲਈ ਮੁਲਾਂਕਣ ਕਰੋ: ਬਣਤਰ, ਕਿੰਨੇ ਪਰਿਵਰਤਨ, ਕੀ ਅਤੇ ਕਿਵੇਂ ਐਕਸਟਰੈਕਟ ਕਰਨਾ ਹੈ।
• ਗੈਰ-ਮਿਆਰੀ ਪ੍ਰੋਜੈਕਟ ਵਿਵਹਾਰ ਨਾਲ ਨੈਟਵਰਕ ਦੀਆਂ ਗਲਤੀਆਂ ਅਤੇ ਸਮੱਸਿਆਵਾਂ ਨੂੰ ਠੀਕ ਕਰੋ।
• ਮੁਲਾਂਕਣ ਕਰੋ ਕਿ ਕੀ ਲੋੜੀਂਦੇ ਫੰਕਸ਼ਨ ਦਸਤਾਵੇਜ਼ਾਂ ਵਿੱਚ ਹਨ ਅਤੇ ਜੇਕਰ ਨਹੀਂ, ਤਾਂ ਇੱਕ ਹੱਲ ਲਈ ਕਿਵੇਂ ਅਤੇ ਕਿੰਨੀ ਲੋੜ ਹੈ।

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

ਅਤੇ ਹੁਣ ਅਸੀਂ ਖਾਸ ਉਦਾਹਰਣਾਂ ਦਾ ਪ੍ਰਦਰਸ਼ਨ ਕਰਾਂਗੇ ਜਿੱਥੇ ਅਜਿਹੇ ਮਾਪਦੰਡ ਬਦਲ ਜਾਣਗੇ।

ਮੁੱਖ ਬਿੰਦੂ: ਅਨੁਮਾਨ ਕੰਮ ਦੀ ਗੁੰਜਾਇਸ਼ ਅਤੇ ਜਟਿਲਤਾ ਨੂੰ ਪ੍ਰਭਾਵਿਤ ਕਰਨ ਵਾਲੇ ਮੁੱਖ ਕਾਰਕਾਂ ਦੇ ਵਿਸ਼ਲੇਸ਼ਣ 'ਤੇ ਅਧਾਰਤ ਹੈ।

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

Reddit ਭਾਈਚਾਰਿਆਂ ਦੀ ਤੁਲਨਾ

ਆਉ ਸਭ ਤੋਂ ਸਰਲ ਕੇਸ ਨਾਲ ਸ਼ੁਰੂ ਕਰੀਏ (ਜਿਵੇਂ ਕਿ ਇਹ ਬਾਅਦ ਵਿੱਚ ਪਤਾ ਚੱਲਦਾ ਹੈ)। ਆਮ ਤੌਰ 'ਤੇ, ਪੂਰੀ ਤਰ੍ਹਾਂ ਈਮਾਨਦਾਰ ਹੋਣ ਲਈ, ਸਾਡੇ ਕੋਲ ਇੱਕ ਲਗਭਗ ਆਦਰਸ਼ ਕੇਸ ਹੈ, ਆਓ ਸਾਡੀ ਗੁੰਝਲਤਾ ਦੀ ਜਾਂਚ ਸੂਚੀ ਦੀ ਜਾਂਚ ਕਰੀਏ:

• ਇੱਕ ਸਾਫ਼, ਸਮਝਣ ਯੋਗ ਅਤੇ ਦਸਤਾਵੇਜ਼ੀ API ਹੈ।
• ਇਹ ਬਹੁਤ ਹੀ ਸਧਾਰਨ ਹੈ ਅਤੇ ਸਭ ਤੋਂ ਮਹੱਤਵਪੂਰਨ, ਇੱਕ ਟੋਕਨ ਆਪਣੇ ਆਪ ਪ੍ਰਾਪਤ ਹੋ ਜਾਂਦਾ ਹੈ।
• ਹਨ python ਰੈਪਰ - ਬਹੁਤ ਸਾਰੀਆਂ ਉਦਾਹਰਣਾਂ ਦੇ ਨਾਲ.
• ਇੱਕ ਭਾਈਚਾਰਾ ਜੋ reddit 'ਤੇ ਡੇਟਾ ਦਾ ਵਿਸ਼ਲੇਸ਼ਣ ਕਰਦਾ ਹੈ ਅਤੇ ਇਕੱਠਾ ਕਰਦਾ ਹੈ (ਪਾਇਥਨ ਰੈਪਰ ਦੀ ਵਰਤੋਂ ਕਿਵੇਂ ਕਰਨੀ ਹੈ ਬਾਰੇ ਦੱਸਣ ਵਾਲੇ YouTube ਵੀਡੀਓ ਤੱਕ ਵੀ) ਉਦਾਹਰਣ ਲਈ.
• ਜਿਨ੍ਹਾਂ ਤਰੀਕਿਆਂ ਦੀ ਸਾਨੂੰ ਸਭ ਤੋਂ ਵੱਧ ਲੋੜ ਹੈ ਉਹ API ਵਿੱਚ ਮੌਜੂਦ ਹਨ। ਇਸ ਤੋਂ ਇਲਾਵਾ, ਕੋਡ ਸੰਖੇਪ ਅਤੇ ਸਾਫ਼ ਦਿਖਾਈ ਦਿੰਦਾ ਹੈ, ਹੇਠਾਂ ਇੱਕ ਫੰਕਸ਼ਨ ਦੀ ਇੱਕ ਉਦਾਹਰਨ ਹੈ ਜੋ ਇੱਕ ਪੋਸਟ 'ਤੇ ਟਿੱਪਣੀਆਂ ਨੂੰ ਇਕੱਠਾ ਕਰਦਾ ਹੈ।

def get_comments(submission_id):
    reddit = Reddit(check_for_updates=False, user_agent=AGENT)
    submission = reddit.submission(id=submission_id)
    more_comments = submission.comments.replace_more()
    if more_comments:
        skipped_comments = sum(x.count for x in more_comments)
        logger.debug('Skipped %d MoreComments (%d comments)',
                     len(more_comments), skipped_comments)
    return submission.comments.list()

ਤੋਂ ਲਿਆ ਗਿਆ ਇਹ ਲਪੇਟਣ ਲਈ ਸੁਵਿਧਾਜਨਕ ਉਪਯੋਗਤਾਵਾਂ ਦੀ ਚੋਣ।

ਇਸ ਤੱਥ ਦੇ ਬਾਵਜੂਦ ਕਿ ਇਹ ਸਭ ਤੋਂ ਵਧੀਆ ਕੇਸ ਹੈ, ਇਹ ਅਸਲ ਜੀਵਨ ਦੇ ਕਈ ਮਹੱਤਵਪੂਰਨ ਕਾਰਕਾਂ ਨੂੰ ਧਿਆਨ ਵਿੱਚ ਰੱਖਣ ਦੇ ਯੋਗ ਹੈ:

• API ਸੀਮਾਵਾਂ - ਸਾਨੂੰ ਬੈਚਾਂ ਵਿੱਚ ਡੇਟਾ ਲੈਣ ਲਈ ਮਜ਼ਬੂਰ ਕੀਤਾ ਜਾਂਦਾ ਹੈ (ਬੇਨਤੀ ਦੇ ਵਿਚਕਾਰ ਨੀਂਦ, ਆਦਿ)।
• ਸੰਗ੍ਰਹਿ ਦਾ ਸਮਾਂ - ਇੱਕ ਪੂਰਨ ਵਿਸ਼ਲੇਸ਼ਣ ਅਤੇ ਤੁਲਨਾ ਲਈ, ਤੁਹਾਨੂੰ ਮੱਕੜੀ ਦੇ ਸਬਰੇਡਿਟ ਵਿੱਚੋਂ ਲੰਘਣ ਲਈ ਮਹੱਤਵਪੂਰਨ ਸਮਾਂ ਨਿਰਧਾਰਤ ਕਰਨਾ ਹੋਵੇਗਾ।
• ਬੋਟ ਨੂੰ ਸਰਵਰ 'ਤੇ ਚੱਲਣਾ ਚਾਹੀਦਾ ਹੈ - ਤੁਸੀਂ ਇਸਨੂੰ ਆਪਣੇ ਲੈਪਟਾਪ 'ਤੇ ਨਹੀਂ ਚਲਾ ਸਕਦੇ, ਇਸਨੂੰ ਆਪਣੇ ਬੈਕਪੈਕ ਵਿੱਚ ਪਾ ਸਕਦੇ ਹੋ, ਅਤੇ ਆਪਣੇ ਕਾਰੋਬਾਰ ਬਾਰੇ ਜਾ ਸਕਦੇ ਹੋ। ਇਸ ਲਈ ਮੈਂ ਇੱਕ VPS 'ਤੇ ਸਭ ਕੁਝ ਚਲਾਇਆ. ਪ੍ਰਚਾਰ ਕੋਡ habrahabr10 ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਤੁਸੀਂ ਲਾਗਤ ਦਾ ਹੋਰ 10% ਬਚਾ ਸਕਦੇ ਹੋ।
• ਕੁਝ ਡੇਟਾ ਦੀ ਭੌਤਿਕ ਪਹੁੰਚਯੋਗਤਾ (ਉਹ ਪ੍ਰਸ਼ਾਸਕਾਂ ਨੂੰ ਦਿਖਾਈ ਦਿੰਦੇ ਹਨ ਜਾਂ ਇਕੱਤਰ ਕਰਨ ਵਿੱਚ ਬਹੁਤ ਮੁਸ਼ਕਲ ਹਨ) - ਇਸ ਨੂੰ ਧਿਆਨ ਵਿੱਚ ਰੱਖਿਆ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ; ਸਿਧਾਂਤ ਵਿੱਚ, ਸਾਰਾ ਡੇਟਾ ਢੁਕਵੇਂ ਸਮੇਂ ਵਿੱਚ ਇਕੱਠਾ ਨਹੀਂ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ।
• ਨੈੱਟਵਰਕ ਗਲਤੀਆਂ: ਨੈੱਟਵਰਕਿੰਗ ਇੱਕ ਦਰਦ ਹੈ।
• ਇਹ ਅਸਲ ਡਾਟਾ ਜੀ ਰਿਹਾ ਹੈ - ਇਹ ਕਦੇ ਵੀ ਸ਼ੁੱਧ ਨਹੀਂ ਹੁੰਦਾ.

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

ਹਾਬਰ ਭਾਗਾਂ ਦੀ ਤੁਲਨਾ

ਆਉ ਹਬਰ ਦੇ ਥਰਿੱਡਾਂ ਅਤੇ/ਜਾਂ ਭਾਗਾਂ ਦੀ ਤੁਲਨਾ ਕਰਨ ਦੇ ਇੱਕ ਹੋਰ ਦਿਲਚਸਪ ਅਤੇ ਗੈਰ-ਮਾਮੂਲੀ ਮਾਮਲੇ ਵੱਲ ਵਧੀਏ।

ਆਉ ਸਾਡੀ ਗੁੰਝਲਦਾਰਤਾ ਦੀ ਜਾਂਚ-ਸੂਚੀ ਦੀ ਜਾਂਚ ਕਰੀਏ - ਇੱਥੇ, ਹਰੇਕ ਬਿੰਦੂ ਨੂੰ ਸਮਝਣ ਲਈ, ਤੁਹਾਨੂੰ ਕੰਮ ਵਿੱਚ ਥੋੜਾ ਜਿਹਾ ਖੋਦਣ ਅਤੇ ਪ੍ਰਯੋਗ ਕਰਨਾ ਹੋਵੇਗਾ।

• ਪਹਿਲਾਂ ਤੁਸੀਂ ਸੋਚਦੇ ਹੋ ਕਿ ਇੱਕ API ਹੈ, ਪਰ ਉੱਥੇ ਨਹੀਂ ਹੈ. ਹਾਂ, ਹਾਂ, ਹੈਬਰ ਕੋਲ ਇੱਕ API ਹੈ, ਪਰ ਇਹ ਉਪਭੋਗਤਾਵਾਂ ਲਈ ਪਹੁੰਚਯੋਗ ਨਹੀਂ ਹੈ (ਜਾਂ ਹੋ ਸਕਦਾ ਹੈ ਕਿ ਇਹ ਬਿਲਕੁਲ ਕੰਮ ਨਾ ਕਰੇ).
• ਫਿਰ ਤੁਸੀਂ ਹੁਣੇ ਹੀ html - "ਅਯਾਤ ਬੇਨਤੀਆਂ" ਨੂੰ ਪਾਰਸ ਕਰਨਾ ਸ਼ੁਰੂ ਕਰਦੇ ਹੋ, ਕੀ ਗਲਤ ਹੋ ਸਕਦਾ ਹੈ?
• ਕਿਸੇ ਵੀ ਤਰ੍ਹਾਂ ਪਾਰਸ ਕਿਵੇਂ ਕਰੀਏ? ਸਭ ਤੋਂ ਸਰਲ ਅਤੇ ਸਭ ਤੋਂ ਵੱਧ ਵਰਤੀ ਜਾਣ ਵਾਲੀ ਪਹੁੰਚ IDs ਨੂੰ ਦੁਹਰਾਉਣਾ ਹੈ, ਨੋਟ ਕਰੋ ਕਿ ਇਹ ਸਭ ਤੋਂ ਵੱਧ ਕੁਸ਼ਲ ਨਹੀਂ ਹੈ ਅਤੇ ਵੱਖ-ਵੱਖ ਮਾਮਲਿਆਂ ਨੂੰ ਸੰਭਾਲਣਾ ਪਵੇਗਾ - ਇੱਥੇ ਸਾਰੇ ਮੌਜੂਦਾ ਲੋਕਾਂ ਵਿੱਚ ਅਸਲ ID ਦੀ ਘਣਤਾ ਦਾ ਇੱਕ ਉਦਾਹਰਨ ਹੈ।

  
  ਤੋਂ ਲਿਆ ਗਿਆ ਇਹ ਲੇਖ.

• ਵੈੱਬ ਦੇ ਸਿਖਰ 'ਤੇ HTML ਵਿੱਚ ਲਪੇਟਿਆ ਕੱਚਾ ਡੇਟਾ ਇੱਕ ਦਰਦ ਹੈ. ਉਦਾਹਰਨ ਲਈ, ਤੁਸੀਂ ਇੱਕ ਲੇਖ ਦੀ ਰੇਟਿੰਗ ਨੂੰ ਇਕੱਠਾ ਕਰਨਾ ਅਤੇ ਸੁਰੱਖਿਅਤ ਕਰਨਾ ਚਾਹੁੰਦੇ ਹੋ: ਤੁਸੀਂ html ਵਿੱਚੋਂ ਸਕੋਰ ਪਾੜ ਦਿੱਤਾ ਹੈ ਅਤੇ ਅੱਗੇ ਦੀ ਪ੍ਰਕਿਰਿਆ ਲਈ ਇਸਨੂੰ ਇੱਕ ਨੰਬਰ ਵਜੋਂ ਸੁਰੱਖਿਅਤ ਕਰਨ ਦਾ ਫੈਸਲਾ ਕੀਤਾ ਹੈ: 

  1) int(ਸਕੋਰ) ਇੱਕ ਗਲਤੀ ਸੁੱਟਦਾ ਹੈ: ਕਿਉਂਕਿ ਹੈਬਰੇ 'ਤੇ ਇੱਕ ਘਟਾਓ ਹੈ, ਜਿਵੇਂ ਕਿ, ਉਦਾਹਰਨ ਲਈ, ਲਾਈਨ "–5" ਵਿੱਚ - ਇਹ ਇੱਕ ਐਨ ਡੈਸ਼ ਹੈ, ਇੱਕ ਘਟਾਓ ਚਿੰਨ੍ਹ ਨਹੀਂ (ਅਚਾਨਕ, ਸਹੀ?), ਇਸ ਲਈ ਕੁਝ ਬਿੰਦੂ ਮੈਨੂੰ ਅਜਿਹੇ ਭਿਆਨਕ ਫਿਕਸ ਦੇ ਨਾਲ ਪਾਰਸਰ ਨੂੰ ਜੀਵਨ ਵਿੱਚ ਵਧਾਉਣਾ ਪਿਆ.

  try:
        score_txt = post.find(class_="score").text.replace(u"–","-").replace(u"+","+")
        score = int(score_txt)
        if check_date(date):
          post_score += score
  

  ਇੱਥੇ ਕੋਈ ਮਿਤੀ, ਪਲੱਸ ਅਤੇ ਮਾਇਨਸ ਬਿਲਕੁਲ ਨਹੀਂ ਹੋ ਸਕਦੇ ਹਨ (ਜਿਵੇਂ ਕਿ ਅਸੀਂ ਉੱਪਰ ਚੈੱਕ_ਡੇਟ ਫੰਕਸ਼ਨ ਵਿੱਚ ਦੇਖਦੇ ਹਾਂ, ਅਜਿਹਾ ਹੋਇਆ)।

  2) ਅਨਸਕੇਪਡ ਵਿਸ਼ੇਸ਼ ਅੱਖਰ - ਉਹ ਆਉਣਗੇ, ਤੁਹਾਨੂੰ ਤਿਆਰ ਰਹਿਣ ਦੀ ਲੋੜ ਹੈ।

  3) ਪੋਸਟ ਦੀ ਕਿਸਮ 'ਤੇ ਨਿਰਭਰ ਕਰਦਿਆਂ ਬਣਤਰ ਬਦਲਦਾ ਹੈ।

  4) ਪੁਰਾਣੀਆਂ ਪੋਸਟਾਂ ਵਿੱਚ ਇੱਕ **ਅਜੀਬ ਢਾਂਚਾ** ਹੋ ਸਕਦਾ ਹੈ।

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

ਜਟਿਲਤਾ ਦੁਆਰਾ ਕੁੱਲ ਚੈਕਲਿਸਟ:

• ਨੈੱਟਵਰਕ ਨਾਲ ਕੰਮ ਕਰਨਾ ਅਤੇ ਆਈਡੀ ਦੁਆਰਾ ਦੁਹਰਾਓ ਅਤੇ ਖੋਜ ਨਾਲ html ਪਾਰਸ ਕਰਨਾ।
• ਵਿਪਰੀਤ ਬਣਤਰ ਦੇ ਦਸਤਾਵੇਜ਼।
• ਬਹੁਤ ਸਾਰੀਆਂ ਥਾਵਾਂ ਹਨ ਜਿੱਥੇ ਕੋਡ ਆਸਾਨੀ ਨਾਲ ਡਿੱਗ ਸਕਦਾ ਹੈ।
• ਲਿਖਣਾ ਜਰੂਰੀ ਹੈ || ਕੋਡ।
• ਲੋੜੀਂਦੇ ਦਸਤਾਵੇਜ਼, ਕੋਡ ਉਦਾਹਰਨਾਂ, ਅਤੇ/ਜਾਂ ਕਮਿਊਨਿਟੀ ਗੁੰਮ ਹੈ।

ਇਸ ਕੰਮ ਲਈ ਅਨੁਮਾਨਿਤ ਸਮਾਂ Reddit ਤੋਂ ਡੇਟਾ ਇਕੱਠਾ ਕਰਨ ਨਾਲੋਂ 3-5 ਗੁਣਾ ਵੱਧ ਹੋਵੇਗਾ।

ਓਡਨੋਕਲਾਸਨੀਕੀ ਸਮੂਹਾਂ ਦੀ ਤੁਲਨਾ

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

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

• ਇੱਕ API ਹੈ, ਪਰ ਇਸ ਵਿੱਚ ਲਗਭਗ ਪੂਰੀ ਤਰ੍ਹਾਂ ਲੋੜੀਂਦੇ ਫੰਕਸ਼ਨਾਂ ਦੀ ਘਾਟ ਹੈ।
• ਕੁਝ ਫੰਕਸ਼ਨਾਂ ਲਈ ਤੁਹਾਨੂੰ ਡਾਕ ਦੁਆਰਾ ਪਹੁੰਚ ਦੀ ਬੇਨਤੀ ਕਰਨ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ, ਯਾਨੀ ਪਹੁੰਚ ਦੀ ਮਨਜ਼ੂਰੀ ਤੁਰੰਤ ਨਹੀਂ ਹੁੰਦੀ ਹੈ।
• ਇਹ ਬਹੁਤ ਹੀ ਦਸਤਾਵੇਜ਼ੀ ਤੌਰ 'ਤੇ ਤਿਆਰ ਕੀਤਾ ਗਿਆ ਹੈ (ਸ਼ੁਰੂ ਕਰਨ ਲਈ, ਰੂਸੀ ਅਤੇ ਅੰਗਰੇਜ਼ੀ ਸ਼ਬਦਾਂ ਨੂੰ ਹਰ ਜਗ੍ਹਾ ਮਿਲਾਇਆ ਜਾਂਦਾ ਹੈ, ਅਤੇ ਪੂਰੀ ਤਰ੍ਹਾਂ ਅਸੰਗਤ - ਕਈ ਵਾਰ ਤੁਹਾਨੂੰ ਇਹ ਅੰਦਾਜ਼ਾ ਲਗਾਉਣ ਦੀ ਜ਼ਰੂਰਤ ਹੁੰਦੀ ਹੈ ਕਿ ਉਹ ਤੁਹਾਡੇ ਤੋਂ ਕਿਤੇ ਕੀ ਚਾਹੁੰਦੇ ਹਨ) ਅਤੇ, ਇਸ ਤੋਂ ਇਲਾਵਾ, ਡਿਜ਼ਾਈਨ ਡੇਟਾ ਪ੍ਰਾਪਤ ਕਰਨ ਲਈ ਢੁਕਵਾਂ ਨਹੀਂ ਹੈ, ਉਦਾਹਰਨ ਲਈ , ਫੰਕਸ਼ਨ ਦੀ ਸਾਨੂੰ ਲੋੜ ਹੈ.
• ਦਸਤਾਵੇਜ਼ਾਂ ਵਿੱਚ ਇੱਕ ਸੈਸ਼ਨ ਦੀ ਲੋੜ ਹੈ, ਪਰ ਅਸਲ ਵਿੱਚ ਇਸਦੀ ਵਰਤੋਂ ਨਹੀਂ ਕਰਦਾ - ਅਤੇ ਏਪੀਆਈ ਮੋਡਾਂ ਦੀਆਂ ਸਾਰੀਆਂ ਪੇਚੀਦਗੀਆਂ ਨੂੰ ਸਮਝਣ ਦਾ ਕੋਈ ਤਰੀਕਾ ਨਹੀਂ ਹੈ ਆਸ ਪਾਸ ਘੁੰਮਣਾ ਅਤੇ ਉਮੀਦ ਕਰਨਾ ਕਿ ਕੁਝ ਕੰਮ ਕਰੇਗਾ।
• ਇੱਥੇ ਕੋਈ ਉਦਾਹਰਣ ਨਹੀਂ ਹਨ ਅਤੇ ਕੋਈ ਭਾਈਚਾਰਾ ਨਹੀਂ ਹੈ; ਜਾਣਕਾਰੀ ਇਕੱਠੀ ਕਰਨ ਵਿੱਚ ਸਹਾਇਤਾ ਦਾ ਇੱਕੋ ਇੱਕ ਬਿੰਦੂ ਇੱਕ ਛੋਟਾ ਹੈ ਰੈਪਰ ਪਾਈਥਨ ਵਿੱਚ (ਵਰਤੋਂ ਦੀਆਂ ਬਹੁਤ ਸਾਰੀਆਂ ਉਦਾਹਰਣਾਂ ਤੋਂ ਬਿਨਾਂ)।
• ਸੇਲੇਨਿਅਮ ਸਭ ਤੋਂ ਕੰਮ ਕਰਨ ਯੋਗ ਵਿਕਲਪ ਜਾਪਦਾ ਹੈ, ਕਿਉਂਕਿ ਬਹੁਤ ਸਾਰੇ ਲੋੜੀਂਦੇ ਡੇਟਾ ਨੂੰ ਲਾਕ ਕੀਤਾ ਗਿਆ ਹੈ.
  1) ਭਾਵ, ਪ੍ਰਮਾਣਿਕਤਾ ਇੱਕ ਫਰਜ਼ੀ ਉਪਭੋਗਤਾ (ਅਤੇ ਹੱਥ ਦੁਆਰਾ ਰਜਿਸਟ੍ਰੇਸ਼ਨ) ਦੁਆਰਾ ਹੁੰਦੀ ਹੈ।

  2) ਹਾਲਾਂਕਿ, ਸੇਲੇਨਿਅਮ ਦੇ ਨਾਲ ਸਹੀ ਅਤੇ ਦੁਹਰਾਉਣ ਯੋਗ ਕੰਮ ਲਈ ਕੋਈ ਗਾਰੰਟੀ ਨਹੀਂ ਹੈ (ਘੱਟੋ ਘੱਟ ok.ru ਦੇ ਮਾਮਲੇ ਵਿੱਚ ਯਕੀਨੀ ਤੌਰ 'ਤੇ)।

  3) Ok.ru ਵੈੱਬਸਾਈਟ ਵਿੱਚ JavaScript ਗਲਤੀਆਂ ਹਨ ਅਤੇ ਕਈ ਵਾਰ ਅਜੀਬ ਅਤੇ ਅਸੰਗਤ ਵਿਵਹਾਰ ਕਰਦੀ ਹੈ।

  4) ਤੁਹਾਨੂੰ ਪੰਨਾਬੰਦੀ, ਤੱਤ ਲੋਡ ਕਰਨ, ਆਦਿ ਕਰਨ ਦੀ ਲੋੜ ਹੈ ...

  5) API ਗਲਤੀਆਂ ਜੋ ਰੈਪਰ ਦਿੰਦਾ ਹੈ, ਉਹਨਾਂ ਨੂੰ ਅਜੀਬ ਢੰਗ ਨਾਲ ਸੰਭਾਲਣਾ ਪਵੇਗਾ, ਉਦਾਹਰਨ ਲਈ, ਇਸ ਤਰ੍ਹਾਂ (ਪ੍ਰਯੋਗਾਤਮਕ ਕੋਡ ਦਾ ਇੱਕ ਟੁਕੜਾ):

  def get_comments(args, context, discussions):
      pause = 1
      if args.extract_comments:
          all_comments = set()
  #makes sense to keep track of already processed discussions
          for discussion in tqdm(discussions): 
              try:
                  comments = get_comments_from_discussion_via_api(context, discussion)
              except odnoklassniki.api.OdnoklassnikiError as e:
                  if "NOT_FOUND" in str(e):
                      comments = set()
                  else:
                      print(e)
                      bp()
                      pass
              all_comments |= comments
              time.sleep(pause)
          return all_comments
  

  ਮੇਰੀ ਮਨਪਸੰਦ ਗਲਤੀ ਸੀ:

  OdnoklassnikiError("Error(code: 'None', description: 'HTTP error', method: 'discussions.getComments', params: …)”)

  6) ਆਖਰਕਾਰ, ਸੇਲੇਨਿਅਮ + ਏਪੀਆਈ ਸਭ ਤੋਂ ਤਰਕਸ਼ੀਲ ਵਿਕਲਪ ਦੀ ਤਰ੍ਹਾਂ ਦਿਖਾਈ ਦਿੰਦਾ ਹੈ.

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

ਇਸ ਕਾਰਜ ਲਈ ਸ਼ਰਤੀਆ ਸਮਾਂ ਅਨੁਮਾਨ ਹੈਬਰ ਤੋਂ ਡੇਟਾ ਇਕੱਠਾ ਕਰਨ ਨਾਲੋਂ 3-5 ਗੁਣਾ ਵੱਧ ਹੋਵੇਗਾ। ਇਸ ਤੱਥ ਦੇ ਬਾਵਜੂਦ ਕਿ ਹੈਬਰ ਦੇ ਮਾਮਲੇ ਵਿੱਚ ਅਸੀਂ HTML ਪਾਰਸਿੰਗ ਦੇ ਨਾਲ ਇੱਕ ਫਰੰਟਲ ਪਹੁੰਚ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹਾਂ, ਅਤੇ ਓਕੇ ਦੇ ਮਾਮਲੇ ਵਿੱਚ ਅਸੀਂ ਨਾਜ਼ੁਕ ਸਥਾਨਾਂ ਵਿੱਚ API ਦੇ ਨਾਲ ਕੰਮ ਕਰ ਸਕਦੇ ਹਾਂ.

ਸਿੱਟਾ

ਇੱਕ ਵਿਸ਼ਾਲ ਡੇਟਾ ਪ੍ਰੋਸੈਸਿੰਗ ਪਾਈਪਲਾਈਨ ਮੋਡੀਊਲ ਦੀ "ਮੌਕੇ 'ਤੇ" (ਅਸੀਂ ਅੱਜ ਦੀ ਯੋਜਨਾ ਬਣਾ ਰਹੇ ਹਾਂ!) ਦੀ ਸਮਾਂ-ਸੀਮਾ ਦਾ ਅੰਦਾਜ਼ਾ ਲਗਾਉਣ ਲਈ ਤੁਹਾਨੂੰ ਕਿੰਨਾ ਵੀ ਲੋੜੀਂਦਾ ਹੈ, ਕਾਰਜ ਮਾਪਦੰਡਾਂ ਦਾ ਵਿਸ਼ਲੇਸ਼ਣ ਕੀਤੇ ਬਿਨਾਂ ਗੁਣਾਤਮਕ ਤੌਰ 'ਤੇ ਅਨੁਮਾਨ ਲਗਾਉਣਾ ਲਗਭਗ ਕਦੇ ਵੀ ਸੰਭਵ ਨਹੀਂ ਹੈ।

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

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

ਜੇ ਤੁਸੀਂ ਵਾਧੂ ਪ੍ਰਯੋਗਾਂ ਦੇ ਬਿਨਾਂ ਕੰਮ ਦੀਆਂ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ 'ਤੇ ਨਜ਼ਰ ਮਾਰਦੇ ਹੋ, ਤਾਂ Reddit ਅਤੇ OK ਸਮਾਨ ਦਿਖਾਈ ਦਿੰਦੇ ਹਨ: ਇੱਥੇ ਇੱਕ API, ਇੱਕ ਪਾਈਥਨ ਰੈਪਰ ਹੈ, ਪਰ ਸੰਖੇਪ ਵਿੱਚ, ਅੰਤਰ ਬਹੁਤ ਵੱਡਾ ਹੈ। ਇਹਨਾਂ ਮਾਪਦੰਡਾਂ ਦੁਆਰਾ ਨਿਰਣਾ ਕਰਦੇ ਹੋਏ, ਹੈਬਰ ਦੇ ਪਾਰਸ ਠੀਕ ਨਾਲੋਂ ਵਧੇਰੇ ਗੁੰਝਲਦਾਰ ਦਿਖਾਈ ਦਿੰਦੇ ਹਨ - ਪਰ ਅਭਿਆਸ ਵਿੱਚ ਇਹ ਬਿਲਕੁਲ ਉਲਟ ਹੈ, ਅਤੇ ਇਹ ਉਹੀ ਹੈ ਜੋ ਸਮੱਸਿਆ ਦੇ ਮਾਪਦੰਡਾਂ ਦਾ ਵਿਸ਼ਲੇਸ਼ਣ ਕਰਨ ਲਈ ਸਧਾਰਨ ਪ੍ਰਯੋਗਾਂ ਦੁਆਰਾ ਖੋਜਿਆ ਜਾ ਸਕਦਾ ਹੈ।

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

ਇਸ ਲਈ, ਸਭ ਤੋਂ ਪ੍ਰਭਾਵਸ਼ਾਲੀ ਦਲੀਲ ਉਹ ਜਾਪਦੀ ਹੈ ਜੋ ਇੱਕ "ਗੈਰ-ਤਕਨੀਕੀ" ਮਾਹਰ ਨੂੰ ਦਰਸਾਏਗੀ ਕਿ ਕਿੰਨਾ ਸਮਾਂ ਅਤੇ ਸਰੋਤ ਪੈਰਾਮੀਟਰਾਂ 'ਤੇ ਨਿਰਭਰ ਕਰਦੇ ਹਨ ਜਿਨ੍ਹਾਂ ਦਾ ਅਜੇ ਮੁਲਾਂਕਣ ਕੀਤਾ ਜਾਣਾ ਬਾਕੀ ਹੈ।

ਸਰੋਤ: www.habr.com