YARN 'ਤੇ ਸਪਾਰਕ ਨੂੰ ਕੌਂਫਿਗਰ ਕਰਨਾ

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

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

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

ਅੱਗੇ, ਮੈਂ ਤੁਹਾਨੂੰ ਦੱਸਾਂਗਾ ਕਿ ਅਸੀਂ ਕੁਝ ਸੰਰਚਨਾ ਪੈਰਾਮੀਟਰਾਂ ਨੂੰ ਕਿਵੇਂ ਅਤੇ ਕਿਉਂ ਚੁਣਿਆ ਹੈ।

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

spark.master=yarn

ਹੋਰ ਵੀ ਦਿਲਚਸਪ. ਇਹਨਾਂ 3 ਡਿਪਲਾਇਮੈਂਟ ਵਿਕਲਪਾਂ ਵਿੱਚੋਂ ਹਰੇਕ ਵਿੱਚ 2 ਡਿਪਲਾਇਮੈਂਟ ਵਿਕਲਪ ਹਨ: ਕਲਾਇੰਟ ਅਤੇ ਕਲੱਸਟਰ। ਅਧਾਰਿਤ ਦਸਤਾਵੇਜ਼ ਅਤੇ ਇੰਟਰਨੈੱਟ 'ਤੇ ਵੱਖ-ਵੱਖ ਲਿੰਕਾਂ, ਅਸੀਂ ਇਹ ਸਿੱਟਾ ਕੱਢ ਸਕਦੇ ਹਾਂ ਕਿ ਕਲਾਇੰਟ ਇੰਟਰਐਕਟਿਵ ਕੰਮ ਲਈ ਢੁਕਵਾਂ ਹੈ - ਉਦਾਹਰਨ ਲਈ, ਜੂਪੀਟਰ ਨੋਟਬੁੱਕ ਰਾਹੀਂ, ਅਤੇ ਕਲੱਸਟਰ ਉਤਪਾਦਨ ਹੱਲ ਲਈ ਵਧੇਰੇ ਢੁਕਵਾਂ ਹੈ। ਸਾਡੇ ਕੇਸ ਵਿੱਚ, ਅਸੀਂ ਇੰਟਰਐਕਟਿਵ ਕੰਮ ਵਿੱਚ ਦਿਲਚਸਪੀ ਰੱਖਦੇ ਸੀ, ਇਸ ਲਈ:

spark.deploy-mode=client

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

spark.dynamicAllocation.enabled=true

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

spark.shuffle.service.enabled=true

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

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

spark.dynamicAllocation.executorIdleTimeout=120s

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

spark.dynamicAllocation.cachedExecutorIdleTimeout=600s

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

spark.dynamicAllocation.maxExecutors=19

ਹੁਣ, ਬੇਸ਼ੱਕ, ਦੂਜੇ ਪਾਸੇ ਅਸੰਤੁਸ਼ਟ ਲੋਕ ਹਨ - "ਕਲੱਸਟਰ ਵਿਹਲਾ ਹੈ, ਅਤੇ ਮੇਰੇ ਕੋਲ ਸਿਰਫ 19 ਐਗਜ਼ੀਕਿਊਟਰ ਹਨ," ਪਰ ਤੁਸੀਂ ਕੀ ਕਰ ਸਕਦੇ ਹੋ? ਸਾਨੂੰ ਕਿਸੇ ਕਿਸਮ ਦਾ ਸਹੀ ਸੰਤੁਲਨ ਚਾਹੀਦਾ ਹੈ। ਤੁਸੀਂ ਸਾਰਿਆਂ ਨੂੰ ਖੁਸ਼ ਨਹੀਂ ਕਰ ਸਕਦੇ।

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

spark.port.maxRetries=50

ਅੱਗੇ ਮੈਂ ਤੁਹਾਨੂੰ ਕੁਝ ਸੈਟਿੰਗਾਂ ਬਾਰੇ ਦੱਸਾਂਗਾ ਜੋ ਸਾਡੇ ਕੇਸ ਦੀਆਂ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਨਾਲ ਬਹੁਤ ਸਬੰਧਤ ਨਹੀਂ ਹਨ।

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

spark.yarn.archive=hdfs:///tmp/spark-archive.zip

ਤੇਜ਼ ਕਾਰਵਾਈ ਲਈ ਕ੍ਰੀਓ ਨੂੰ ਸੀਰੀਅਲਾਈਜ਼ਰ ਵਜੋਂ ਵਰਤਣ ਦੀ ਵੀ ਸਿਫਾਰਸ਼ ਕੀਤੀ ਜਾਂਦੀ ਹੈ। ਇਹ ਡਿਫੌਲਟ ਨਾਲੋਂ ਵਧੇਰੇ ਅਨੁਕੂਲਿਤ ਹੈ।

spark.serializer=org.apache.spark.serializer.KryoSerializer

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

spark.driver.maxResultSize=3072

ਅਤੇ ਅੰਤ ਵਿੱਚ, ਇੱਕ ਮਿਠਆਈ ਦੇ ਰੂਪ ਵਿੱਚ. HortonWorks ਡਿਸਟਰੀਬਿਊਸ਼ਨ - HDP 2.1 'ਤੇ ਸਪਾਰਕ ਨੂੰ ਵਰਜਨ 2.5.3.0 ਵਿੱਚ ਕਿਵੇਂ ਅੱਪਡੇਟ ਕਰਨਾ ਹੈ। HDP ਦੇ ਇਸ ਸੰਸਕਰਣ ਵਿੱਚ ਪਹਿਲਾਂ ਤੋਂ ਸਥਾਪਿਤ ਸੰਸਕਰਣ 2.0 ਹੈ, ਪਰ ਅਸੀਂ ਇੱਕ ਵਾਰ ਆਪਣੇ ਲਈ ਫੈਸਲਾ ਕੀਤਾ ਸੀ ਕਿ ਸਪਾਰਕ ਕਾਫ਼ੀ ਸਰਗਰਮੀ ਨਾਲ ਵਿਕਸਤ ਹੋ ਰਿਹਾ ਹੈ, ਅਤੇ ਹਰ ਨਵਾਂ ਸੰਸਕਰਣ ਕੁਝ ਬੱਗ ਠੀਕ ਕਰਦਾ ਹੈ ਅਤੇ ਵਾਧੂ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ, ਜਿਸ ਵਿੱਚ ਪਾਈਥਨ API ਲਈ ਵੀ ਸ਼ਾਮਲ ਹੈ, ਇਸਲਈ ਅਸੀਂ ਫੈਸਲਾ ਕੀਤਾ ਹੈ, ਕੀ ਕਰਨ ਦੀ ਲੋੜ ਹੈ ਕੀਤਾ ਜਾਣਾ ਇੱਕ ਅੱਪਡੇਟ ਹੈ।

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

java.lang.NoClassDefFoundError: com/sun/jersey/api/client/config/ClientConfig

ਗੂਗਲਿੰਗ ਤੋਂ ਬਾਅਦ, ਸਾਨੂੰ ਪਤਾ ਲੱਗਾ ਕਿ ਸਪਾਰਕ ਨੇ ਹਾਡੂਪ ਦੇ ਜਨਮ ਤੱਕ ਉਡੀਕ ਨਾ ਕਰਨ ਦਾ ਫੈਸਲਾ ਕੀਤਾ, ਅਤੇ ਜਰਸੀ ਦੇ ਨਵੇਂ ਸੰਸਕਰਣ ਦੀ ਵਰਤੋਂ ਕਰਨ ਦਾ ਫੈਸਲਾ ਕੀਤਾ। ਉਹ ਆਪ ਜੀਰਾ ਵਿੱਚ ਇਸ ਵਿਸ਼ੇ ਬਾਰੇ ਆਪਸ ਵਿੱਚ ਬਹਿਸ ਕਰਦੇ ਹਨ। ਹੱਲ ਡਾਊਨਲੋਡ ਕਰਨਾ ਸੀ ਜਰਸੀ ਸੰਸਕਰਣ 1.17.1. ਇਸਨੂੰ SPARK_HOME ਵਿੱਚ ਜਾਰ ਫੋਲਡਰ ਵਿੱਚ ਰੱਖੋ, ਇਸਨੂੰ ਦੁਬਾਰਾ ਜ਼ਿਪ ਕਰੋ ਅਤੇ ਇਸਨੂੰ HDFS ਵਿੱਚ ਅੱਪਲੋਡ ਕਰੋ।

ਅਸੀਂ ਇਸ ਗਲਤੀ ਦੇ ਆਲੇ-ਦੁਆਲੇ ਮਿਲ ਗਏ, ਪਰ ਇੱਕ ਨਵੀਂ ਅਤੇ ਬਜਾਏ ਸੁਚਾਰੂ ਢੰਗ ਨਾਲ ਪੈਦਾ ਹੋਇਆ.

org.apache.spark.SparkException: Yarn application has already ended! It might have been killed or unable to launch application master

ਉਸੇ ਸਮੇਂ, ਅਸੀਂ ਸੰਸਕਰਣ 2.0 ਨੂੰ ਚਲਾਉਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਦੇ ਹਾਂ - ਸਭ ਕੁਝ ਠੀਕ ਹੈ। ਅੰਦਾਜ਼ਾ ਲਗਾਉਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰੋ ਕਿ ਕੀ ਹੋ ਰਿਹਾ ਹੈ। ਅਸੀਂ ਇਸ ਐਪਲੀਕੇਸ਼ਨ ਦੇ ਲੌਗਸ ਵਿੱਚ ਦੇਖਿਆ ਅਤੇ ਕੁਝ ਅਜਿਹਾ ਦੇਖਿਆ:

/usr/hdp/${hdp.version}/hadoop/lib/hadoop-lzo-0.6.0.${hdp.version}.jar

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

hdp.version=2.5.3.0-37

ਇਸ ਜਾਦੂ ਨੇ ਮਦਦ ਕੀਤੀ, ਅਤੇ ਸਪਾਰਕ ਬੰਦ ਹੋ ਗਿਆ। ਅਸੀਂ ਆਪਣੇ ਕਈ ਜੁਪੀਟਰ ਲੈਪਟਾਪਾਂ ਦੀ ਜਾਂਚ ਕੀਤੀ। ਸਭ ਕੁਝ ਕੰਮ ਕਰ ਰਿਹਾ ਹੈ। ਅਸੀਂ ਸ਼ਨੀਵਾਰ (ਕੱਲ੍ਹ) ਨੂੰ ਪਹਿਲੇ ਸਪਾਰਕ ਪਾਠ ਲਈ ਤਿਆਰ ਹਾਂ!

ਯੂ.ਪੀ.ਡੀ. ਪਾਠ ਦੌਰਾਨ, ਇੱਕ ਹੋਰ ਸਮੱਸਿਆ ਸਾਹਮਣੇ ਆਈ। ਕਿਸੇ ਸਮੇਂ, ਯਾਰਨ ਨੇ ਸਪਾਰਕ ਲਈ ਕੰਟੇਨਰ ਪ੍ਰਦਾਨ ਕਰਨਾ ਬੰਦ ਕਰ ਦਿੱਤਾ। ਯਾਰਨ ਵਿੱਚ ਪੈਰਾਮੀਟਰ ਨੂੰ ਠੀਕ ਕਰਨਾ ਜ਼ਰੂਰੀ ਸੀ, ਜੋ ਕਿ ਮੂਲ ਰੂਪ ਵਿੱਚ 0.2 ਸੀ:

yarn.scheduler.capacity.maximum-am-resource-percent=0.8

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

ਸਰੋਤ: www.habr.com