ਅਸੀਂ ਇੱਕ ਉੱਚ ਕੁਸ਼ਲ ਅਤੇ ਸਸਤੇ ਡੇਟਾਲੇਕ ਨੂੰ ਕਿਵੇਂ ਆਯੋਜਿਤ ਕੀਤਾ ਅਤੇ ਅਜਿਹਾ ਕਿਉਂ ਹੈ

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

ਇਹ ਬੇਕਾਰ ਨਹੀਂ ਹੈ ਕਿ ਵਧੇਰੇ ਤਜਰਬੇਕਾਰ ਸਹਿਕਰਮੀ, ਜਿਨ੍ਹਾਂ ਦੇ ਸਿਰ ਬੱਗਾਂ ਨਾਲ ਫੈਲੇ ਹੋਏ ਹਨ ਅਤੇ ਇਸਲਈ ਪਹਿਲਾਂ ਹੀ ਸਲੇਟੀ ਹਨ, "ਕਿਊਬਜ਼" ਵਿੱਚ "ਕੰਟੇਨਰਾਂ" ਦੇ ਪੈਕ ਦੀ ਅਵਿਸ਼ਵਾਸ਼ਯੋਗ ਤੇਜ਼ੀ ਨਾਲ ਤੈਨਾਤੀ ਬਾਰੇ ਵਿਚਾਰ ਕਰ ਰਹੇ ਹਨ, "ਫੈਸ਼ਨੇਬਲ ਭਾਸ਼ਾਵਾਂ" ਵਿੱਚ ਦਰਜਨਾਂ ਸਰਵਰਾਂ 'ਤੇ ਬਿਲਟ-ਇਨ ਸਮਰਥਨ ਨਾਲ ਅਸਿੰਕ੍ਰੋਨਸ ਗੈਰ-ਬਲਾਕਿੰਗ I/O, ਨਿਮਰਤਾ ਨਾਲ ਮੁਸਕਰਾਓ। ਅਤੇ ਉਹ ਚੁੱਪਚਾਪ “ਮੈਨ ps” ਨੂੰ ਦੁਬਾਰਾ ਪੜ੍ਹਨਾ ਜਾਰੀ ਰੱਖਦੇ ਹਨ, “nginx” ਸੋਰਸ ਕੋਡ ਵਿੱਚ ਖੋਜ ਕਰਦੇ ਹਨ ਜਦੋਂ ਤੱਕ ਉਹਨਾਂ ਦੀਆਂ ਅੱਖਾਂ ਵਿੱਚੋਂ ਖੂਨ ਨਹੀਂ ਨਿਕਲਦਾ, ਅਤੇ ਯੂਨਿਟ ਟੈਸਟ ਲਿਖਣਾ, ਲਿਖਣਾ, ਲਿਖਣਾ। ਸਾਥੀ ਜਾਣਦੇ ਹਨ ਕਿ ਸਭ ਤੋਂ ਦਿਲਚਸਪ ਗੱਲ ਉਦੋਂ ਆਵੇਗੀ ਜਦੋਂ "ਇਹ ਸਭ" ਇੱਕ ਦਿਨ ਨਵੇਂ ਸਾਲ ਦੀ ਸ਼ਾਮ ਨੂੰ ਰਾਤ ਨੂੰ ਦਾਅ 'ਤੇ ਲੱਗ ਜਾਵੇਗਾ। ਅਤੇ ਉਹਨਾਂ ਨੂੰ ਕੇਵਲ ਯੂਨਿਕਸ ਦੀ ਪ੍ਰਕਿਰਤੀ, ਯਾਦ ਕੀਤੇ TCP/IP ਸਟੇਟ ਟੇਬਲ ਅਤੇ ਬੁਨਿਆਦੀ ਛਾਂਟੀ-ਖੋਜ ਐਲਗੋਰਿਦਮ ਦੀ ਡੂੰਘੀ ਸਮਝ ਦੁਆਰਾ ਮਦਦ ਕੀਤੀ ਜਾਵੇਗੀ। ਸਿਸਟਮ ਨੂੰ ਮੁੜ ਜੀਵਨ ਵਿੱਚ ਲਿਆਉਣ ਲਈ ਜਿਵੇਂ ਕਿ ਚਾਈਮਜ਼ ਹੜਤਾਲ ਹੁੰਦੀ ਹੈ।

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

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

Bitrix24 ਵਿੱਚ ਬੁਨਿਆਦੀ ਤਕਨੀਕੀ ਵਿਸ਼ਲੇਸ਼ਣ

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

ਨਬਜ਼ 'ਤੇ ਫਿੰਗਰ - ਐਡਵਾਂਸਡ ਤਕਨੀਕੀ ਵਿਸ਼ਲੇਸ਼ਣ

"ਜਿੰਨੀ ਜਲਦੀ ਹੋ ਸਕੇ" ਸਮੱਸਿਆਵਾਂ ਬਾਰੇ ਜਾਣਕਾਰੀ ਪ੍ਰਾਪਤ ਕਰਨ ਦੀ ਇੱਛਾ ਨੇ ਸਾਨੂੰ ਸਰਲ ਅਤੇ ਸਮਝਣ ਯੋਗ ਟੂਲਸ - pinba ਅਤੇ xhprof ਦੇ ਨਾਲ ਸਰਗਰਮ ਪ੍ਰਯੋਗਾਂ ਲਈ ਅਗਵਾਈ ਕੀਤੀ।

ਪਿਨਬਾ ਨੇ ਸਾਨੂੰ PHP ਵਿੱਚ ਵੈਬ ਪੇਜਾਂ ਦੇ ਭਾਗਾਂ ਦੇ ਸੰਚਾਲਨ ਦੀ ਗਤੀ ਬਾਰੇ UDP ਪੈਕੇਟ ਵਿੱਚ ਅੰਕੜੇ ਭੇਜੇ, ਅਤੇ ਅਸੀਂ MySQL ਸਟੋਰੇਜ ਵਿੱਚ ਔਨਲਾਈਨ ਦੇਖ ਸਕਦੇ ਹਾਂ (Pinba ਤੇਜ਼ ਇਵੈਂਟ ਵਿਸ਼ਲੇਸ਼ਣ ਲਈ ਆਪਣੇ MySQL ਇੰਜਣ ਦੇ ਨਾਲ ਆਉਂਦਾ ਹੈ) ਸਮੱਸਿਆਵਾਂ ਦੀ ਇੱਕ ਛੋਟੀ ਸੂਚੀ ਅਤੇ ਜਵਾਬ ਉਹਨਾਂ ਨੂੰ। ਅਤੇ xhprof ਨੇ ਸਾਨੂੰ ਗਾਹਕਾਂ ਤੋਂ ਸਭ ਤੋਂ ਹੌਲੀ PHP ਪੰਨਿਆਂ ਦੇ ਐਗਜ਼ੀਕਿਊਸ਼ਨ ਦੇ ਗ੍ਰਾਫਾਂ ਨੂੰ ਇਕੱਠਾ ਕਰਨ ਅਤੇ ਵਿਸ਼ਲੇਸ਼ਣ ਕਰਨ ਦੀ ਇਜਾਜ਼ਤ ਦਿੱਤੀ ਕਿ ਇਸ ਨਾਲ ਕੀ ਹੋ ਸਕਦਾ ਹੈ - ਸ਼ਾਂਤੀ ਨਾਲ, ਚਾਹ ਡੋਲ੍ਹਣਾ ਜਾਂ ਕੁਝ ਮਜ਼ਬੂਤ.

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

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

• Bitrix24 ਕਲਾਇੰਟ ਨੇ ਪਿਛਲੇ ਘੰਟੇ ਵਿੱਚ p1 ਪੋਰਟਲ ਤੇ ਕਿੰਨੀਆਂ PHP ਗਲਤੀਆਂ ਕੀਤੀਆਂ ਅਤੇ ਕਿਹੜੀਆਂ? ਸਮਝੋ, ਮਾਫ਼ ਕਰੋ ਅਤੇ ਜਲਦੀ ਠੀਕ ਕਰੋ।
• ਪਿਛਲੇ 24 ਘੰਟਿਆਂ ਵਿੱਚ ਜਰਮਨੀ ਵਿੱਚ ਪੋਰਟਲਾਂ 'ਤੇ ਕਿੰਨੀਆਂ ਵੀਡੀਓ ਕਾਲਾਂ ਕੀਤੀਆਂ ਗਈਆਂ ਸਨ, ਕਿਸ ਕੁਆਲਿਟੀ ਨਾਲ ਅਤੇ ਕੀ ਚੈਨਲ/ਨੈੱਟਵਰਕ ਵਿੱਚ ਕੋਈ ਮੁਸ਼ਕਲਾਂ ਸਨ?
• ਸਿਸਟਮ ਕਾਰਜਕੁਸ਼ਲਤਾ (PHP ਲਈ ਸਾਡਾ C ਐਕਸਟੈਂਸ਼ਨ), ਨਵੀਨਤਮ ਸੇਵਾ ਅੱਪਡੇਟ ਵਿੱਚ ਸਰੋਤ ਤੋਂ ਕੰਪਾਇਲ ਕੀਤੀ ਗਈ ਅਤੇ ਗਾਹਕਾਂ ਲਈ ਰੋਲਆਊਟ ਕੀਤੀ ਗਈ, ਕਿੰਨੀ ਚੰਗੀ ਤਰ੍ਹਾਂ ਕੰਮ ਕਰਦੀ ਹੈ? ਕੀ ਉੱਥੇ segfaults ਹਨ?
• ਕੀ ਗਾਹਕ ਡੇਟਾ PHP ਮੈਮੋਰੀ ਵਿੱਚ ਫਿੱਟ ਹੈ? ਕੀ ਪ੍ਰਕਿਰਿਆਵਾਂ ਨੂੰ ਨਿਰਧਾਰਤ ਕੀਤੀ ਗਈ ਮੈਮੋਰੀ ਤੋਂ ਵੱਧ ਜਾਣ ਬਾਰੇ ਕੋਈ ਤਰੁੱਟੀਆਂ ਹਨ: "ਮੈਮੋਰੀ ਤੋਂ ਬਾਹਰ"? ਲੱਭੋ ਅਤੇ ਨਿਰਪੱਖ ਕਰੋ.

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

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

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

ਬੁਨਿਆਦੀ ਵਪਾਰ ਵਿਸ਼ਲੇਸ਼ਣ

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

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

ਲੰਬੇ ਸਮੇਂ ਤੱਕ, ਇਸ ਲਚਕਦਾਰ ਹੱਲ ਨੇ ਬਹੁਤ ਮਦਦ ਕੀਤੀ, ਪਰ ਹੌਲੀ-ਹੌਲੀ ਇਹ ਸਮਝ ਆਉਣ ਲੱਗੀ ਕਿ ਕਲਿਕਹਾਊਸ ਰਬੜ ਨਹੀਂ ਹੈ ਅਤੇ ਇਸ ਤਰ੍ਹਾਂ ਦਾ ਮਜ਼ਾਕ ਨਹੀਂ ਉਡਾਇਆ ਜਾ ਸਕਦਾ ਹੈ।

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

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

ਪਾਇਥਨ ਅਤੇ ਵਿਸ਼ਲੇਸ਼ਕਾਂ ਦੀ ਮੰਗ

ਸਾਡੀ ਕੰਪਨੀ ਵਿੱਚ ਬਹੁਤ ਸਾਰੇ ਡਿਵੈਲਪਰ ਹਨ ਜੋ PHP, JavaScript, C#, C/C++, Java, Go, Rust, Python, Bash ਵਿੱਚ ਲਗਭਗ ਹਰ ਰੋਜ਼ 10-20 ਸਾਲਾਂ ਲਈ ਕੋਡ ਲਿਖਦੇ ਹਨ। ਇੱਥੇ ਬਹੁਤ ਸਾਰੇ ਤਜਰਬੇਕਾਰ ਸਿਸਟਮ ਪ੍ਰਸ਼ਾਸਕ ਵੀ ਹਨ ਜਿਨ੍ਹਾਂ ਨੇ ਇੱਕ ਤੋਂ ਵੱਧ ਬਿਲਕੁਲ ਅਵਿਸ਼ਵਾਸ਼ਯੋਗ ਤਬਾਹੀ ਦਾ ਅਨੁਭਵ ਕੀਤਾ ਹੈ ਜੋ ਅੰਕੜਿਆਂ ਦੇ ਨਿਯਮਾਂ ਵਿੱਚ ਫਿੱਟ ਨਹੀਂ ਹੁੰਦੇ (ਉਦਾਹਰਣ ਵਜੋਂ, ਜਦੋਂ ਇੱਕ ਰੇਡ -10 ਵਿੱਚ ਜ਼ਿਆਦਾਤਰ ਡਿਸਕਾਂ ਇੱਕ ਤੇਜ਼ ਬਿਜਲੀ ਦੀ ਹੜਤਾਲ ਨਾਲ ਨਸ਼ਟ ਹੋ ਜਾਂਦੀਆਂ ਹਨ)। ਅਜਿਹੇ ਹਾਲਾਤ ਵਿੱਚ, ਲੰਬੇ ਸਮੇਂ ਤੋਂ ਇਹ ਸਪੱਸ਼ਟ ਨਹੀਂ ਸੀ ਕਿ "ਪਾਈਥਨ ਵਿਸ਼ਲੇਸ਼ਕ" ਕੀ ਹੁੰਦਾ ਹੈ. ਪਾਈਥਨ PHP ਵਰਗਾ ਹੈ, ਸਿਰਫ ਨਾਮ ਥੋੜਾ ਲੰਬਾ ਹੈ ਅਤੇ ਦੁਭਾਸ਼ੀਏ ਦੇ ਸਰੋਤ ਕੋਡ ਵਿੱਚ ਦਿਮਾਗ ਨੂੰ ਬਦਲਣ ਵਾਲੇ ਪਦਾਰਥਾਂ ਦੇ ਥੋੜੇ ਘੱਟ ਨਿਸ਼ਾਨ ਹਨ। ਹਾਲਾਂਕਿ, ਜਿਵੇਂ ਕਿ ਵੱਧ ਤੋਂ ਵੱਧ ਵਿਸ਼ਲੇਸ਼ਣਾਤਮਕ ਰਿਪੋਰਟਾਂ ਬਣਾਈਆਂ ਗਈਆਂ, ਤਜਰਬੇਕਾਰ ਡਿਵੈਲਪਰਾਂ ਨੇ ਨੰਪੀ, ਪਾਂਡਾ, ਮੈਟਪਲੋਟਲਿਬ, ਸੀਬੋਰਨ ਵਰਗੇ ਸਾਧਨਾਂ ਵਿੱਚ ਤੰਗ ਮੁਹਾਰਤ ਦੇ ਮਹੱਤਵ ਨੂੰ ਤੇਜ਼ੀ ਨਾਲ ਸਮਝਣਾ ਸ਼ੁਰੂ ਕਰ ਦਿੱਤਾ।
ਨਿਰਣਾਇਕ ਭੂਮਿਕਾ, ਸੰਭਾਵਤ ਤੌਰ 'ਤੇ, "ਲੌਜਿਸਟਿਕ ਰਿਗਰੈਸ਼ਨ" ਸ਼ਬਦਾਂ ਦੇ ਸੁਮੇਲ ਤੋਂ ਕਰਮਚਾਰੀਆਂ ਦੇ ਅਚਾਨਕ ਬੇਹੋਸ਼ ਹੋ ਜਾਣ ਅਤੇ ਹਾਂ, ਹਾਂ, ਪਾਈਸਪਾਰਕ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋਏ ਵੱਡੇ ਡੇਟਾ 'ਤੇ ਪ੍ਰਭਾਵਸ਼ਾਲੀ ਰਿਪੋਰਟਿੰਗ ਦੇ ਪ੍ਰਦਰਸ਼ਨ ਦੁਆਰਾ ਖੇਡੀ ਗਈ ਸੀ।

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

ਅਪਾਚੇ ਸਪਾਰਕ/ਹਡੂਪ ਦੀਆਂ ਹੋਰ ਕੋਸ਼ਿਸ਼ਾਂ ਅਤੇ ਸਕ੍ਰਿਪਟ ਦੇ ਅਨੁਸਾਰ ਕੀ ਨਹੀਂ ਹੋਇਆ

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

ਨਤੀਜੇ ਵਜੋਂ, ਅਸੀਂ "ਬਚ ਗਏ" ਕਈ ਅੰਦਰੂਨੀ ਵਿਸ਼ਲੇਸ਼ਣਾਤਮਕ ਪ੍ਰੋਜੈਕਟ ਜੋ ਸਰਗਰਮੀ ਨਾਲ ਅਪਾਚੇ ਸਪਾਰਕ (ਸਪਾਰਕ ਸਟ੍ਰੀਮਿੰਗ, ਸਪਾਰਕ SQL ਸਮੇਤ) ਅਤੇ ਹੈਡੂਪ ਈਕੋਸਿਸਟਮ (ਅਤੇ ਇਸ ਤਰ੍ਹਾਂ ਦੇ ਹੋਰ) ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹਨ। ਇਸ ਤੱਥ ਦੇ ਬਾਵਜੂਦ ਕਿ ਸਮੇਂ ਦੇ ਨਾਲ ਅਸੀਂ "ਇਸ" ਨੂੰ ਚੰਗੀ ਤਰ੍ਹਾਂ ਤਿਆਰ ਕਰਨਾ ਅਤੇ ਨਿਗਰਾਨੀ ਕਰਨਾ ਸਿੱਖ ਲਿਆ ਹੈ, ਅਤੇ ਡੇਟਾ ਦੀ ਪ੍ਰਕਿਰਤੀ ਵਿੱਚ ਤਬਦੀਲੀਆਂ ਅਤੇ ਯੂਨੀਫਾਰਮ ਆਰਡੀਡੀ ਹੈਸ਼ਿੰਗ ਦੇ ਅਸੰਤੁਲਨ ਦੇ ਕਾਰਨ "ਇਹ" ਅਮਲੀ ਤੌਰ 'ਤੇ ਅਚਾਨਕ ਕ੍ਰੈਸ਼ ਹੋਣਾ ਬੰਦ ਹੋ ਗਿਆ ਹੈ, ਪਹਿਲਾਂ ਹੀ ਤਿਆਰ ਕੁਝ ਲੈਣ ਦੀ ਇੱਛਾ. , ਅੱਪਡੇਟ ਕੀਤਾ ਗਿਆ ਹੈ ਅਤੇ ਬੱਦਲ ਵਿੱਚ ਕਿਤੇ ਪ੍ਰਬੰਧਿਤ ਮਜ਼ਬੂਤ ​​ਅਤੇ ਮਜ਼ਬੂਤ ​​​​ਹੋ ਗਿਆ ਹੈ। ਇਹ ਇਸ ਸਮੇਂ ਸੀ ਜਦੋਂ ਅਸੀਂ ਐਮਾਜ਼ਾਨ ਵੈੱਬ ਸੇਵਾਵਾਂ ਦੀ ਤਿਆਰ-ਕੀਤੀ ਕਲਾਉਡ ਅਸੈਂਬਲੀ ਦੀ ਵਰਤੋਂ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕੀਤੀ - ਈਐਮਆਰ ਅਤੇ, ਬਾਅਦ ਵਿੱਚ, ਇਸਦੀ ਵਰਤੋਂ ਕਰਕੇ ਸਮੱਸਿਆਵਾਂ ਨੂੰ ਹੱਲ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕੀਤੀ। EMR Apache Spark ਹੈ ਜੋ ਐਮਾਜ਼ਾਨ ਦੁਆਰਾ ਈਕੋਸਿਸਟਮ ਤੋਂ ਵਾਧੂ ਸੌਫਟਵੇਅਰ ਨਾਲ ਤਿਆਰ ਕੀਤਾ ਗਿਆ ਹੈ, ਜਿਵੇਂ ਕਿ ਕਲਾਉਡੇਰਾ/ਹੋਰਟਨਵਰਕਸ ਬਿਲਡਸ।

ਵਿਸ਼ਲੇਸ਼ਣ ਲਈ ਰਬੜ ਫਾਈਲ ਸਟੋਰੇਜ ਇੱਕ ਫੌਰੀ ਲੋੜ ਹੈ

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

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

ਕੀ Amazon S3 DataLake ਲਈ ਉਮੀਦਵਾਰ ਹੈ?

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

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

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

ਇਹ ਸਪੱਸ਼ਟ ਹੈ ਕਿ ਨਿੱਜੀ ਡੇਟਾ "ਘੱਟ" ਹੈ, ਪਰ ਦੂਜੇ ਡੇਟਾ ਬਾਰੇ ਕੀ ਜੇ ਅਸੀਂ ਇਸਨੂੰ ਉੱਥੇ ਲੈ ਜਾਂਦੇ ਹਾਂ ਅਤੇ "ਇਸ ਨੂੰ ਪ੍ਰਭਾਵਸ਼ਾਲੀ ਢੰਗ ਨਾਲ ਚਲਾਉਂਦੇ ਹਾਂ"?

ਐਮਾਜ਼ਾਨ ਵੈੱਬ ਸੇਵਾਵਾਂ ਦਾ ਕਲੱਸਟਰ-ਬਿਗਡਾਟਾ-ਵਿਸ਼ਲੇਸ਼ਣ ਈਕੋਸਿਸਟਮ - ਬਹੁਤ ਹੀ ਸਧਾਰਨ ਸ਼ਬਦਾਂ ਵਿੱਚ

AWS ਦੇ ਨਾਲ ਸਾਡੇ ਤਜ਼ਰਬੇ ਦਾ ਨਿਰਣਾ ਕਰਦੇ ਹੋਏ, Apache Hadoop/MapReduce ਨੂੰ ਵੱਖ-ਵੱਖ ਸਾਸ ਦੇ ਅਧੀਨ ਲੰਬੇ ਸਮੇਂ ਤੋਂ ਸਰਗਰਮੀ ਨਾਲ ਵਰਤਿਆ ਗਿਆ ਹੈ, ਉਦਾਹਰਨ ਲਈ DataPipeline ਸੇਵਾ ਵਿੱਚ (ਮੈਂ ਆਪਣੇ ਸਾਥੀਆਂ ਨਾਲ ਈਰਖਾ ਕਰਦਾ ਹਾਂ, ਉਹਨਾਂ ਨੇ ਇਸਨੂੰ ਸਹੀ ਢੰਗ ਨਾਲ ਤਿਆਰ ਕਰਨਾ ਸਿੱਖਿਆ)। ਇੱਥੇ ਅਸੀਂ DynamoDB ਟੇਬਲਾਂ ਤੋਂ ਵੱਖ-ਵੱਖ ਸੇਵਾਵਾਂ ਤੋਂ ਬੈਕਅੱਪ ਸੈਟ ਅਪ ਕਰਦੇ ਹਾਂ:


ਅਤੇ ਉਹ ਕਈ ਸਾਲਾਂ ਤੋਂ ਕਲਾਕਵਰਕ ਵਰਗੇ ਏਮਬੈਡਡ ਹੈਡੂਪ/ਮੈਪਰੀਡੂਸ ਕਲੱਸਟਰਾਂ 'ਤੇ ਨਿਯਮਤ ਤੌਰ 'ਤੇ ਚੱਲ ਰਹੇ ਹਨ। "ਇਸ ਨੂੰ ਸੈੱਟ ਕਰੋ ਅਤੇ ਇਸਨੂੰ ਭੁੱਲ ਜਾਓ":

ਤੁਸੀਂ ਵਿਸ਼ਲੇਸ਼ਕਾਂ ਲਈ ਕਲਾਉਡ ਵਿੱਚ ਜੁਪੀਟਰ ਲੈਪਟਾਪ ਸਥਾਪਤ ਕਰਕੇ ਅਤੇ ਏਆਈ ਮਾਡਲਾਂ ਨੂੰ ਲੜਾਈ ਵਿੱਚ ਸਿਖਲਾਈ ਅਤੇ ਤੈਨਾਤ ਕਰਨ ਲਈ AWS ਸੇਜਮੇਕਰ ਸੇਵਾ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਡਾਟਾ ਸ਼ੈਤਾਨਵਾਦ ਵਿੱਚ ਪ੍ਰਭਾਵਸ਼ਾਲੀ ਢੰਗ ਨਾਲ ਸ਼ਾਮਲ ਹੋ ਸਕਦੇ ਹੋ। ਇਹ ਸਾਡੇ ਲਈ ਇਸ ਤਰ੍ਹਾਂ ਦਾ ਦਿਖਾਈ ਦਿੰਦਾ ਹੈ:

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

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

AWS ਗੂੰਦ - ਸਟੀਰੌਇਡਜ਼ 'ਤੇ ਸਾਫ਼-ਸੁਥਰਾ ਪੈਕ ਕੀਤਾ ਅਪਾਚੇ ਸਪਾਰਕ

ਇਹ ਪਤਾ ਚਲਿਆ ਕਿ AWS ਕੋਲ "Hive/Pig/Spark" ਸਟੈਕ ਦਾ ਆਪਣਾ ਸੰਸਕਰਣ ਹੈ। Hive ਦੀ ਭੂਮਿਕਾ, i.e. DataLake ਵਿੱਚ ਫਾਈਲਾਂ ਅਤੇ ਉਹਨਾਂ ਦੀਆਂ ਕਿਸਮਾਂ ਦੀ ਕੈਟਾਲਾਗ "ਡੇਟਾ ਕੈਟਾਲਾਗ" ਸੇਵਾ ਦੁਆਰਾ ਕੀਤੀ ਜਾਂਦੀ ਹੈ, ਜੋ ਅਪਾਚੇ ਹਾਈਵ ਫਾਰਮੈਟ ਨਾਲ ਇਸਦੀ ਅਨੁਕੂਲਤਾ ਨੂੰ ਨਹੀਂ ਲੁਕਾਉਂਦੀ ਹੈ। ਤੁਹਾਨੂੰ ਇਸ ਸੇਵਾ ਵਿੱਚ ਜਾਣਕਾਰੀ ਜੋੜਨ ਦੀ ਲੋੜ ਹੈ ਕਿ ਤੁਹਾਡੀਆਂ ਫਾਈਲਾਂ ਕਿੱਥੇ ਸਥਿਤ ਹਨ ਅਤੇ ਉਹ ਕਿਸ ਫਾਰਮੈਟ ਵਿੱਚ ਹਨ। ਡੇਟਾ ਸਿਰਫ s3 ਵਿੱਚ ਹੀ ਨਹੀਂ, ਬਲਕਿ ਡੇਟਾਬੇਸ ਵਿੱਚ ਵੀ ਹੋ ਸਕਦਾ ਹੈ, ਪਰ ਇਹ ਇਸ ਪੋਸਟ ਦਾ ਵਿਸ਼ਾ ਨਹੀਂ ਹੈ. ਇੱਥੇ ਸਾਡੀ DataLake ਡਾਟਾ ਡਾਇਰੈਕਟਰੀ ਨੂੰ ਕਿਵੇਂ ਸੰਗਠਿਤ ਕੀਤਾ ਗਿਆ ਹੈ:

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

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

ਇਸ ਤਰ੍ਹਾਂ, ਜੇਕਰ ਤੁਹਾਨੂੰ s3 ਵਿੱਚ ਡੇਟਾ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਇੱਕ ਸਪਾਰਕ ਕਲੱਸਟਰ 'ਤੇ ਕਿਸੇ ਚੀਜ਼ ਦੀ ਗਣਨਾ ਕਰਨ ਦੀ ਲੋੜ ਹੈ, ਤਾਂ ਅਸੀਂ python/pyspark ਵਿੱਚ ਕੋਡ ਲਿਖਦੇ ਹਾਂ, ਇਸਦੀ ਜਾਂਚ ਕਰਦੇ ਹਾਂ, ਅਤੇ ਕਲਾਉਡ ਲਈ ਚੰਗੀ ਕਿਸਮਤ।

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

ਝੀਲ ਵਿੱਚ ਸਟੋਰ ਕੀਤੀਆਂ ਫਾਈਲਾਂ ਦਾ ਫਾਰਮੈਟ ਪ੍ਰਦਰਸ਼ਨ ਦੀ ਕੁੰਜੀ ਹੈ

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

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

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

AWS ਐਥੀਨਾ - ਜੈਕ-ਇਨ-ਦ-ਬਾਕਸ

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

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

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

ਅਤੇ ਸਹੀ ਢੰਗ ਨਾਲ ਕੱਟੇ ਹੋਏ ਫੋਲਡਰਾਂ ਤੋਂ ਸਿਰਫ ਲੋੜੀਂਦੇ ਕਾਲਮਾਂ ਦੀ ਬੇਨਤੀ ਕਰਨ ਨਾਲ, ਇਹ ਪਤਾ ਚਲਿਆ ਕਿ ਐਥੀਨਾ ਸੇਵਾ ਸਾਨੂੰ ਇੱਕ ਮਹੀਨੇ ਵਿੱਚ ਲੱਖਾਂ ਡਾਲਰ ਖਰਚ ਕਰਦੀ ਹੈ. ਖੈਰ, ਬਹੁਤ ਵਧੀਆ, ਲਗਭਗ ਮੁਫਤ, ਕਲੱਸਟਰਾਂ 'ਤੇ ਵਿਸ਼ਲੇਸ਼ਣ ਦੇ ਮੁਕਾਬਲੇ!

ਵੈਸੇ, ਇੱਥੇ ਅਸੀਂ ਆਪਣੇ ਡੇਟਾ ਨੂੰ s3 ਵਿੱਚ ਕਿਵੇਂ ਸਾਂਝਾ ਕਰਦੇ ਹਾਂ:

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

ਪਰ ਅਸੀਂ ਹੋਰ ਅੱਗੇ ਚਲੇ ਗਏ ਅਤੇ ਜਵਾਬਾਂ ਲਈ ਬੱਦਲ ਵੱਲ ਜਾਣ ਲੱਗੇ ODBC ਡਰਾਈਵਰ ਦੁਆਰਾ: ਇੱਕ ਵਿਸ਼ਲੇਸ਼ਕ ਇੱਕ ਜਾਣੇ-ਪਛਾਣੇ ਕੰਸੋਲ ਵਿੱਚ ਇੱਕ SQL ਪੁੱਛਗਿੱਛ ਲਿਖਦਾ ਹੈ, ਜੋ 100-500 ਮਸ਼ੀਨਾਂ 'ਤੇ "ਪੈਨੀਜ਼ ਲਈ" s3 ਨੂੰ ਡੇਟਾ ਭੇਜਦਾ ਹੈ ਅਤੇ ਆਮ ਤੌਰ 'ਤੇ ਕੁਝ ਸਕਿੰਟਾਂ ਵਿੱਚ ਜਵਾਬ ਦਿੰਦਾ ਹੈ। ਆਰਾਮਦਾਇਕ. ਅਤੇ ਤੇਜ਼. ਮੈਨੂੰ ਅਜੇ ਵੀ ਯਕੀਨ ਨਹੀਂ ਆ ਰਿਹਾ।

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

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

ਸਿੱਟਾ

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

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

ਸਫ਼ਰ ਦੀ ਸ਼ੁਰੂਆਤ ਵਿੱਚ, ਮੇਰਾ ਸਿਰ ਖੁੱਲੇ ਅਤੇ ਬੰਦ ਸਾਫਟਵੇਅਰ ਦੇ ਬਹੁਤ ਸਾਰੇ ਜੰਗਲੀ ਚਿੜੀਆਘਰਾਂ ਤੋਂ ਵੱਖ ਹੋ ਰਿਹਾ ਸੀ ਅਤੇ ਉੱਤਰਾਧਿਕਾਰੀਆਂ ਨੂੰ ਜ਼ਿੰਮੇਵਾਰੀ ਦੇ ਬੋਝ ਦੀ ਸਮਝ ਸੀ. ਬਸ ਸਧਾਰਨ ਸਾਧਨਾਂ ਤੋਂ ਆਪਣਾ ਡੇਟਾਲੇਕ ਬਣਾਉਣਾ ਸ਼ੁਰੂ ਕਰੋ: nagios/munin -> elastic/kibana -> Hadoop/Spark/s3..., ਫੀਡਬੈਕ ਇਕੱਠਾ ਕਰਨਾ ਅਤੇ ਹੋ ਰਹੀਆਂ ਪ੍ਰਕਿਰਿਆਵਾਂ ਦੇ ਭੌਤਿਕ ਵਿਗਿਆਨ ਨੂੰ ਡੂੰਘਾਈ ਨਾਲ ਸਮਝਣਾ। ਹਰ ਚੀਜ਼ ਗੁੰਝਲਦਾਰ ਅਤੇ ਗੁੰਝਲਦਾਰ - ਇਸਨੂੰ ਦੁਸ਼ਮਣਾਂ ਅਤੇ ਪ੍ਰਤੀਯੋਗੀਆਂ ਨੂੰ ਦਿਓ.

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

ਸਰੋਤ: www.habr.com