22 ਨਵੰ 2025·8 ਮਿੰਟ
ਡੌਗ ਕਟਿੰਗ ਦੀ Lucene ਅਤੇ Hadoop: ਖੋਜ ਤੋਂ ਬੱਡੇ ਡੇਟਾ ਤੱਕ
कैਸੇ Doug Cutting ਦੀਆਂ Lucene ਅਤੇ Hadoop ਨੇ ਖੋਜ ਅਤੇ ਵੰਡਿਆ ਡੇਟਾ ਪ੍ਰੋਸੈਸਿੰਗ ਨੂੰ ਆਮ ਖੁੱਲ੍ਹੇ-ਸੋਰਸ ਬਿਲਡਿੰਗ ਬਲਾਕ ਬਣਾਇਆ, ਜੋ ਆਧੁਨਿਕ ਡੇਟਾ ਟੀਮਾਂ ਲਈ ਵਿਕਸਿਤ ਹੋਏ।
ਕਿਉਂ Lucene ਅਤੇ Hadoop ਅਜੇ ਵੀ ਮਹੱਤਵਪੂਰਨ ਹਨ
Lucene ਅਤੇ Hadoop ਇੱਕ ਅਚੰਭੇ ਰੂپ ਵਿੱਚ ਪ੍ਰਯੋਗਕਰਤਾ ਕਹਾਣੀ ਦੱਸਦੇ ਹਨ: ਇੱਕ ਵਾਰੀ ਤੁਸੀਂ ਜਾਣਕਾਰੀ ਨੂੰ ਤੇਜ਼ ਖੋਜ ਲਈ ਇੰਡੈਕਸ ਕਰ ਸਕਦੇ ਹੋ, ਅਗਲਾ ਚੈਲੈਂਜ ਹੁੰਦਾ ਹੈ ਉਸ ਤੋਂ ਵੱਧ ਡੇਟਾ ਪ੍ਰੋਸੈਸ ਕਰਨਾ ਜੋ ਇਕ ਮਸ਼ੀਨ ਸਮਭਾਲ ਸਕੇ। ਇਕੱਠੇ, ਇਨ੍ਹਾਂ ਨੇ “ਖੋਜ” ਅਤੇ “ਵੰਡਿਆ ਕੰਪਿਊਟਿੰਗ” ਨੂੰ ਨਿਚ-ਪ੍ਰਾਈਸ ਜਾਂ ਮਹਿੰਗੇ ਵਿਸ਼ੇਸ਼ ਸਮਰਥਨਾਂ ਤੋਂ ਐਸੇ ਬਿਲਡਿੰਗ ਬਲਾਕ ਬਣਾਇਆ ਜੋ ਆਮ ਹਾਰਡਵੇਅਰ ਨਾਲ ਟੀਮਾਂ ਅਪਣਾਉ ਸਕਦੀਆਂ ਸਨ।
ਇਹ ਲੇਖ ਇੱਕ ਕੰਮ ਕਰ ਰਹੀ ਇਤਿਹਾਸਕ ਰਿਪੋਰਟ ਹੈ, ਗਹਿਰਾਈ ਵਿੱਚ scoring ਫਾਰਮੂਲਜ਼ ਜਾਂ ਵੰਡਿਆ ਪ੍ਰਣਾਲੀ ਸਿਧਾਂਤ ਵਿੱਚ ਨਹੀਂ। ਮਕਸਦ ਇਹ ਜੋੜਨਾ ਹੈ ਕਿ ਲੋਕਾਂ ਕੋਲ ਕਿਹੜੀਆਂ ਸਮੱਸਿਆਵਾਂ ਸਨ, ਉਹ ਸਾਦੇ ਖ਼ਿਆਲ ਜਿਹੜੇ ਤਰੱਕੀ ਖੋਲ੍ਹੇ, ਅਤੇ ਕਿਉਂ ਉਹ ਖ਼ਿਆਲ ਅਜੇ ਵੀ ਆਧੁਨਿਕ ਟੂਲਾਂ ਵਿੱਚ ਨਜ਼ਰ ਆਉਂਦੇ ਹਨ।
ਦੋ ਪ੍ਰੋਜੈਕਟ, ਦੋ ਬਹੁਤ ਮਨੁੱਖੀ ਸਮੱਸਿਆਵਾਂ
Apache Lucene ਨੇ ਵਿਕਾਸਕਾਰਾਂ ਲਈ ਐਪਲੀਕੇਸ਼ਨ ਵਿੱਚ ਉੱਚ-ਗੁਣਵੱਤਾ ਵਾਲੀ ਖੋਜ ਜੋੜਨਾ ਸੌਖਾ ਕੀਤਾ: ਟੈਕਸਟ ਦਾ ਇੰਡੈਕਸ ਬਣਾਉਣਾ, ਤੇਜ਼ੀ ਨਾਲ ਕ્વੈਰੀ ਕਰਨਾ, ਅਤੇ ਸਬ ਕੁਝ ਨਵੇਂ ਸਿਰੇ ਤੋਂ ਬਣਾਉਣ ਦੀ ਜ਼ਰੂਰਤ ਬਿਨਾਂ ਦੁਹਰਾਉਣ ਦੇ।
Apache Hadoop ਨੇ ਇੱਕ ਵੱਖਰੀ ਪীੜਾ ਹੱਲ ਕੀਤੀ: ਸੰਗਠਨਾਂ ਵੱਲੋਂ ਲਾਗਜ਼, ਕਲਿਕਸਟਰੀਮ ਅਤੇ ਐਸੇ ਡੇਟਾਸੇਟ ਇਕੱਠੇ ਕੀਤੇ ਜਾ ਰਹੇ ਸਨ ਜੋ ਇੱਕ ਸਰਵਰ 'ਤੇ ਆਸਾਨੀ ਨਾਲ ਫਿੱਟ ਨਹੀਂ ਹੁੰਦੇ ਸਨ। Hadoop ਇੱਕ ਤਰੀਕਾ ਦਿੱਤਾ ਕਿ ਉਹ ਡੇਟਾ ਬਹੁਤ ਸਾਰੀਆਂ ਮਸ਼ੀਨਾਂ 'ਤੇ ਸਟੋਰ ਕੀਤਾ ਜਾਵੇ (HDFS) ਅਤੇ ਇਸ 'ਤੇ ਬੈਚ ਪ੍ਰੋਸੈਸਿੰਗ ਜੌਬਸ (MapReduce) ਚਲਾਏ ਜਾ ਸਕਣ—ਬਿਨਾਂ ਹੱਥੋਂ-ਹੱਥ ਇੱਕ ਵੰਡਿਆ ਸਿਸਟਮ ਬਣਾਉਣ ਦੀ ਲੋੜ ਦੇ।
ਹਰ ਰੋਜ਼ ਦੇ ਨਿਰਮਾਤਿਆਂ ਲਈ ਕਿਉਂ ਇਹ ਮਹੱਤਵਪੂਰਨ ਸੀ
ਇਨ੍ਹਾਂ ਪ੍ਰੋਜੈਕਟਾਂ ਤੋਂ ਪਹਿਲਾਂ ਕਈ ਟੀਮਾਂ ਕੋਲ ਇਕ ਮੁਸ਼ਕਲ ਚੋਣ ਸੀ: ਮਹੰਗੇ ਪ੍ਰੋਪ੍ਰਾਇਟਰੀ ਸਿਸਟਮ ਖਰੀਦੋ ਜਾਂ ਹੌਲੀ-ਹੌਲੀ, ਨਿਰਲਜ ਅਤੇ ਗਲਤੀਆਂ ਭਰੇ ਮੈਨੂਅਲ ਕੰਮਾਂ ਨੂੰ ਕਬੂਲ ਕਰੋ। Lucene ਅਤੇ Hadoop ਨੇ ਬਾਧਾ ਥੱਲੇ ਕੀਤੀ।
- Lucene ਐਪਲੀਕੇਸ਼ਨ ਟੀਮਾਂ ਨੂੰ ਸਾਈਟ ਖੋਜ, ਦਸਤਾਵੇਜ਼ ਖੋਜ ਅਤੇ ਪ੍ਰਸੰਗਤਾ ਟਿਊਨਿੰਗ ਵਰਗੀਆਂ ਫੀਚਰਜ਼ ਸ਼ਿਪ ਕਰਨ ਵਿੱਚ ਮਦਦ ਕੀਤੀ ਬਿਨਾਂ ਖੋਜ ਵਿੱਚ ਪੀਐਚਡੀ ਬਣਨ ਦੀ ਲੋੜ ਦੇ।
- Hadoop ਡਾਟਾ ਟੀਮਾਂ ਨੂੰ “ਵੱਡੇ ਜੌਬਸ” (ਲਾਗ ਪ੍ਰੋਸੈਸਿੰਗ, ਐਨਾਲਿਟਿਕਸ, ETL) ਚਲਾਉਣ ਦੀ ਆਸਾਨੀ ਦਿੱਤੀ ਬਿਨਾਂ ਕਿਸੇ ਸੁਪਰਕੰਪਿਊਟਰ ਦੇ ਮਾਲਕ ਹੋਣ ਦੀ।
ਤੁਸੀਂ ਇਸ ਪੋਸਟ ਵਿੱਚ ਕੀ ਸਿੱਖੋਗੇ
ਤੁਸੀਂ ਵੇਖੋਗੇ Lucene ਅਤੇ Hadoop ਤੋਂ ਪਹਿਲਾਂ ਕੀ ਸਮੱਸਿਆਵਾਂ ਸੀ, ਕਿਉਂ Doug Cutting ਦਾ ਕੰਮ ਨਿਰਮਾਤਿਆਂ ਨੂੰ ਖਿੱਚਿਆ, ਅਤੇ ਕਿਵੇਂ ਇਹ ਖ਼ਿਆਲ ਜੋੜੇ ਗਏ—ਦਸਤਾਵੇਜ਼ਾਂ ਨੂੰ ਇੰਡੈਕਸ ਕਰਨ ਤੋਂ ਲੈ ਕੇ ਕਲੱਸਟਰਾਂ ਦਾ ਕੋਆਰਡੀਨੇਸ਼ਨ ਕਰਨ ਤੱਕ।
ਅਖੀਰ ਵਿੱਚ, ਤੁਸੀਂ ਝਾੜਕ ਦੇ ਤੌਰ 'ਤੇ ਸਮਝ ਪਾਓਗੇ: ਭਾਵੇਂ ਤੁਹਾਡਾ ਸਟੈਕ Elasticsearch, Spark, ਕਲਾਊਡ ਆਬਜੈਕਟ ਸਟੋਰੇਜ, ਜਾਂ ਮੈਨੇਜਡ ਸਰਵਿਸਜ਼ ਵਰਤੇ, ਬਹੁਤ ਸਾਰੇ ਮੂਲ ਧਾਰਣਾਂ ਉਹਨਾਂ ਵਿਚੋਂ ਆਉਂਦੀਆਂ ਹਨ ਜਿਹੜੀਆਂ Lucene ਅਤੇ Hadoop ਨੇ ਆਮ ਕੀਤਾ।
Doug Cutting ਦਾ ਓਪਨ ਸੋਰਸ ਵਿੱਚ ਭੂਮਿਕਾ
Doug Cutting ਉਹਨਾਂ ਦੁਰਲਭ ਇੰਜੀਨੀਅਰਾਂ ਵਿੱਚੋਂ ਇੱਕ ਹਨ ਜਿਨ੍ਹਾਂ ਦਾ ਕੰਮ ਦੋ ਵੱਖ-ਵੱਖ “ਡਿਫ਼ਾਫ਼ੋਲਟ” ਟੂਲਾਂ ਨੂੰ ਰੂਪ ਦਿੱਤਾ: ਆਧੁਨਿਕ ਡਾਟਾ ਟੀਮਾਂ ਲਈ Apache Lucene ਖੋਜ ਲਈ, ਅਤੇ Apache Hadoop ਵੰਡਿਆ ਡੇਟਾ ਪ੍ਰੋਸੈਸਿੰਗ ਲਈ। ਦੋਹਾਂ ਪ੍ਰੋਜੈਕਟਾਂ ਨੇ ਕਿਸੇ ਇੱਕ ਵਿਅਕਤੀ ਤੋਂ ਕਾਫੀ ਵੱਧ ਪ੍ਰਸਾਰ ਕੀਤਾ, ਪਰ Cutting ਦੇ ਸ਼ੁਰੂਆਤੀ ਟੈਕਨੀਕੀ ਫੈਸਲਿਆਂ ਅਤੇ ਖੁੱਲ੍ਹੀ ਸਹਿਯੋਗੀ ਵ੍ਯਵਹਾਰ ਨੇ ਦਿੱਸ਼ਾ ਨਿਰਧਾਰਤ ਕੀਤੀ।
ਪ੍ਰਯੋਗਕਰਤਾ ਲਈ ਕਾਰਗਰ ਬਿਲਡਿੰਗ ਬਲਾਕਾਂ ਦੇ ਨਿਰਮਾਤਾ
Cutting ਦਾ ਲਗਾਤਾਰ ਥੀਮ ਪਹੁੰਚਯੋਗਤਾ ਸੀ। Lucene ਨੇ ਉੱਚ-ਗੁਣਵੱਤਾ ਵਾਲੀ ਖੋਜ ਨੂੰ ਇੱਕ ਲਾਇਬ੍ਰੇਰੀ ਵਾਂਗ ਮਹਿਸੂਸ ਕਰਵਾਇਆ ਜਿਸਨੂੰ ਤੁਸੀਂ ਆਪਣੀ ਐਪ ਵਿੱਚ ਏਂਬੇਡ ਕਰ ਸਕਦੇ ਸੀ, ਨ ਕਿ ਇਕ ਵਿਸ਼ੇਸ਼ਿਤ ਪ੍ਰਣਾਲੀ ਜੋ ਸਿਰਫ ਵੱਡੀਆਂ ਕੰਪਨੀਆਂ ਹੀ ਬਣਵਾ ਸਕਦੀਆਂ। ਬਾਅਦ ਵਿੱਚ, Hadoop ਦਾ ਮਕਸਦ ਸੀ ਕਿ ਆਮ ਮਸ਼ੀਨਾਂ ਦੇ ਕਲੱਸਟਰਾਂ 'ਤੇ ਵੱਡੇ ਪੈਮਾਨੇ ਦੀ ਸਟੋਰੇਜ ਅਤੇ ਕੰਪਿਊਟੇਸ਼ਨ ਸੰਭਵ ਬਣੇ, ਨਾ ਕਿ ਸਿਰਫ ਮਹਿੰਗੇ ਪ੍ਰੋਪ੍ਰਾਇਟਰੀ ਹਾਰਡਵੇਅਰ।
ਇਹ ਪ੍ਰੇਰਨਾ ਮਹੱਤਵਪੂਰਨ ਹੈ: ਇਹ “ਵੱਡੇ ਡੇਟਾ ਸਿਰਫ ਵੱਡੇ ਲਈ” ਨਹੀਂ ਸੀ, ਬਲਕਿ ਛੋਟੀਆਂ ਟੀਮਾਂ ਨੂੰ ਸੀਮਿਤ ਬਜਟ ਨਾਲ ਸ਼ਕਤੀਸ਼ਾਲੀ ਸਮਰਥਨ ਉਪਲਬਧ ਕਰਵਾਉਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਸੀ।
Apache-ਸਟਾਈਲ ਸਹਿਯੋਗ
ਦੋਹਾਂ Lucene ਅਤੇ Hadoop Apache Software Foundation ਹੇਠ ਵਧੇ, ਜਿੱਥੇ ਫੈਸਲੇ ਖੁੱਲ੍ਹੇ ਤੌਰ 'ਤੇ ਕੀਤੇ ਜਾਂਦੇ ਹਨ ਅਤੇ ਅਧਿਕਾਰ ਯੋਗਦਾਨ ਰਾਹੀਂ ਮਿਲਦਾ ਹੈ। ਇਹ ਮਾਡਲ ਸੁਧਾਰਾਂ ਦਾ ਸਥਿਰ ਪ੍ਰਵਾਹ ਉਤਸ਼ਾਹਿਤ ਕਰਦਾ ਸੀ: ਬੱਗ ਫਿਕਸ, ਪ੍ਰਦਰਸ਼ਨ ਕੰਮ, ਦਸਤਾਵੇਜ਼ੀਕਰਨ ਅਤੇ ਕੰਪਨੀਆਂ ਤੇ ਯੂਨੀਵਰਸਿਟੀਆਂ ਤੋਂ ਹਕੀਕਤੀ ਫੀਡਬੈਕ।
Cutting ਦੀ ਕੀ ਕਿਰਦਾਰ ਸੀ, ਅਤੇ ਕੌਮ ਦੀ ਕੀ?
Cutting ਦੀ ਨਿੱਜੀ ਯੋਗਦਾਨ ਸ਼ੁਰੂਆਤ ਵਿੱਚ ਸਭ ਤੋਂ ਮਜ਼ਬੂਤ ਸੀ: ਪਹਿਲੀ ਆਰਕੀਟੈਕਚਰ, ਸ਼ੁਰੂਆਤੀ ਇੰਪਲੇਮੈਂਟੇਸ਼ਨ, ਅਤੇ ਹੋਰ ਯੋਗਦਾਨਕਾਰਾਂ ਨੂੰ ਆਕਰਸ਼ਿਤ ਕਰਨ ਲਈ ਕਰੇਡਿਬਿਲਿਟੀ। ਜਿਵੇਂ ਜੇਹੜੀ ਗ੍ਰਾਹਕੀ ਵਧੀ, ਕਮਿਊਨਿਟੀ (ਅਤੇ ਬਾਅਦ ਵਿੱਚ ਬਹੁਤ ਸਾਰੀਆਂ ਕੰਪਨੀਆਂ) ਨੇ ਮੁੱਖ ਜੁਟਦੇ ਜੋੜੇ: ਨਵੇਂ ਫੀਚਰ, ਇੰਟਿਗ੍ਰੇਸ਼ਨ, ਸਕੇਲਿੰਗ ਕੰਮ, ਅਤੇ ਓਪਰੇਸ਼ਨਲ ਟੂਲਿੰਗ।
ਇੱਕ ਉਪਯੋਗੀ ਢੰਗ ਸੋਚਣ ਦਾ: Cutting ਨੇ “ਪਹਿਲੀ ਵਰਕਿੰਗ ਵਰਜਨ” ਅਤੇ ਉਸਦੇ ਇर्द-ਗਿਰਦ ਸੱਭਿਆਚਾਰ ਨੂੰ ਬਣਾਇਆ; ਓਪਨ-ਸੋਰਸ ਕਮਿਊਨਿਟੀ ਨੇ ਉਹਨਾਂ ਵਿਚਾਰਾਂ ਨੂੰ ਲੰਬੇ ਸਮੇਂ ਵਾਲੀ ਇਨਫਰਾਸਟ੍ਰਕਚਰ ਵਿੱਚ ਬਦਲ ਦਿੱਤਾ।
Lucene ਤੋਂ ਪਹਿਲਾਂ ਖੋਜ ਸਮੱਸਿਆ
Lucene ਤੋਂ ਪਹਿਲਾਂ, ਪ੍ਰੋਡਕਟ ਵਿੱਚ “ਖੋਜ” ਜੋੜਨਾ ਅਕਸਰ ਇਕ ਛੋਟਾ ਰਿਸਰਚ ਪ੍ਰੋਜੈਕਟ ਬਣਾਉਣ ਵਰਗਾ ਸੀ। ਕਈ ਟੀਮਾਂ ਜਾਂ ਤਾਂ ਮਹਿੰਗਾ ਪ੍ਰੋਪ੍ਰਾਇਟਰੀ ਸਾਫਟਵੇਅਰ ਖਰੀਦਦੀਆਂ ਜਾਂ ਘਰੇਲੂ ਹੱਲ ਸਿਲਾਈਆਂ ਕਰਦੀਆਂ ਜੋ ਟਿਊਨ ਕਰਨ ਵਿੱਚ ਔਖੀਆਂ, ਸਕੇਲ ਕਰਨ ਵਿੱਚ ਮੁਸ਼ਕਲ ਅਤੇ ਗਲਤੀਆਂ ਭਰਪੂਰ ਹੁੰਦੀਆਂ।
ਖੋਜ ਮਹਿੰਗੀ ਅਤੇ ਮੁਸ਼ਕਲ ਕਿਉਂ ਸਨ
ਖੋਜ ਸਿਰਫ ਕਿਸੇ ਸ਼ਬਦ ਦੀ ਥਾਂ ਲਭਣ ਹੀ ਨਹੀਂ ਹੈ। ਇਹ ਗਤੀ, ਰੈਂਕਿੰਗ ਅਤੇ ਗੰਦੇ-ਹਕੀਕਤੀ ਟੈਕਸਟ ਨਾਲ ਨਜਿੱਠਣ ਬਾਰੇ ਹੈ। ਜੇ ਤੁਸੀਂ ਚਾਹੁੰਦੇ ਹੋ ਕਿ ਯੂਜ਼ਰ “running shoes” ਟਾਈਪ ਕਰਨ ਤੇ ਮਿਲੀ-ਸੈਕਿੰਡਾਂ ਵਿੱਚ ਉਪਯੁਕਤ ਨਤੀਜੇ ਮਿਲਣ, ਤਾਂ ਤੁਹਾਨੂੰ ਵਿਸ਼ੇਸ਼ ਡੇਟਾ ਸਟ੍ਰੱਕਚਰ ਅਤੇ ਅਲਗੋਰਿਦਮ ਦੀ ਲੋੜ ਹੁੰਦੀ—ਨਾਲ ਹੀ ਇੰਡੈਕਸਿੰਗ, ਅਪਡੇਟਸ, ਅਤੇ ਕਵੇਰੀਜ਼ ਨੂੰ ਭਰੋਸੇਯੋਗ ਰੱਖਣ ਲਈ ਧਿਆਨਪੂਰਵਕ ਇੰਜੀਨੀਅਰਿੰਗ।
"ਇੰਡੈਕਸ" ਅਤੇ "ਪ੍ਰਸੰਗਤਾ" ਸਧਾਰਣ ਭਾਸ਼ਾ ਵਿੱਚ
ਇੱਕ ਇੰਡੈਕਸ ਕਿਤਾਬ ਦੇ ਪਿੱਠ ਦੇ ਇੰਡੈਕਸ ਵਾਂਗ ਹੈ, ਪਰ ਤੁਹਾਡੇ ਸਾਰੇ ਦਸਤਾਵੇਜ਼ਾਂ ਲਈ: ਹਰ ਵਾਰੀ ਹਰ ਇਕ ਪੰਨਾ ਸਕੈਨ ਕਰਨ ਦੀ ਬਜਾਏ ਤੁਸੀਂ ਕਿਸੇ ਸ਼ਬਦ ਲਈ ਲੁੱਕ-ਅੱਪ ਕਰਦੇ ਹੋ ਅਤੇ ਸਿੱਧੇ ਓਥੇ ਪਹੁੰਚਦੇ ਹੋ ਜਿੱਥੇ ਉਹ ਨਜ਼ਰ ਆਉਂਦਾ ਹੈ। ਇੰਡੈਕਸ ਬਿਨਾਂ, ਖੋਜ ਹੌਲੀ ਹੋ ਜਾਂਦੀ ਹੈ ਕਿਉਂਕਿ ਤੁਸੀਂ ਹਰ ਵਾਰੀ ਫਿਰ-ਫਿਰ ਸਭ ਕੁਝ ਪੜ੍ਹ ਰਹੇ ਹੁੰਦੇ ਹੋ।
ਪ੍ਰਸੰਗਤਾ (relevance) ਇਹ ਫੈਸਲਾ ਕਰਦੀ ਹੈ ਕਿ ਕੀ ਪਹਿਲਾਂ ਦਿਖਾਇਆ ਜਾਵੇ। ਜੇ 10,000 ਦਸਤਾਵੇਜ਼ “shoes” ਨਾਲ ਮਿਲਦੇ ਹਨ, ਤਾਂ relevance ਦੱਸਦਾ ਹੈ: ਪਹਿਲੇ ਪੇਜ 'ਤੇ ਕਿਹੜੇ 10 ਦਿਖਾਏ ਜਾਣ? ਇਹ ਅਕਸਰ ਸੂਚਕਾਂ ਤੇ ਨਿਰਭਰ ਹੁੰਦਾ ਹੈ ਜਿਵੇਂ ਟਰਮ ਦੀ ਤ੍ਰਿਕਤਾ, ਇਹ ਕਿੱਥੇ ਆਇਆ (ਸਿਰਲੇਖ ਵੱਲੋਂ ਬਾਡੀ ਵੱਲ), ਅਤੇ ਕਿੰਨਾ ਦੁਰਲਭ ਹੈ।
ਵੈੱਬ ਨੇ ਸਮੱਸਿਆ ਨੂੰ ਜ਼ਰੂਰੀ ਬਣਾ ਦਿੱਤਾ
ਜਿਵੇਂ-ਜਿਵੇਂ ਵੈੱਪਸਾਈਟਾਂ ਅਤੇ ਆਨਲਾਈਨ ਕੈਟਾਲੌਗ ਵਧੇ, “ਠੀਕ-ਠਾਕ” ਖੋਜ ਕਾਫੀ ਨਹੀਂ ਰਹੀ। ਯੂਜ਼ਰ ਤੇਜ਼ ਨਤੀਜੇ, ਟਾਇਪੋ ਟੋਲਰੇੰਸ ਅਤੇ ਸਮਝਦਾਰ ਰੈਂਕਿੰਗ ਦੀ ਉਮੀਦ ਕਰਨ ਲੱਗੇ। ਕੰਪਨੀਆਂ ਜਿਹੜੀਆਂ ਇਹ ਨਹੀਂ ਦਿੰਦੀਆਂ, ਉਹ ਐੰਗੇਜਮੈਂਟ ਅਤੇ ਵਿਕਰੀ ਗੁੰਵਾ ਬੈਠਦੀਆਂ।
ਇੱਕ ਪੁਨਰ-ਉਪਯੋਗ ਲਾਇਬ੍ਰੇਰੀ ਕਿਉਂ ਮੱਤਵਪੂਰਨ ਸੀ
ਇੱਕ ਪੁਨਰ-ਉਪਯੋਗ ਲਾਇਬ੍ਰੇਰੀ ਨਾਲ ਟੀਮਾਂ ਨੂੰ ਇੰਡੈਕਸਿੰਗ ਅਤੇ ਰੈਂਕਿੰਗ ਨੂੰ ਨਵੇਂ ਸਿਰੇ ਤੋਂ ਦੁਹਰਾਉਣ ਦੀ ਲੋੜ ਨਹੀਂ ਰਹੀ। ਇਸ ਨਾਲ ਖੋਜ ਬਣਾਉਣ ਦੀ ਲਾਗਤ ਘੱਟ ਹੋਈ, ਵਧੀਆ ਅਮਲ ਸਾਂਝੇ ਹੋ ਸਕੇ, ਅਤੇ ਡਿਵੈਲਪੜਾਂ ਨੂੰ ਆਪਣੇ ਉਤਪਾਦ ਦੀਆਂ ਖ਼ਾਸ ਲੋੜਾਂ 'ਤੇ ਧਿਆਨ ਕਰਨ ਦੀ ਆਜ਼ਾਦੀ ਮਿਲੀ।
Lucene ਨੇ ਕੀ ਸੌਖਾ ਕੀਤਾ
Lucene ਨੇ “ਖੋਜ” ਨੂੰ ਐਸਾ ਫੀਚਰ ਬਣਾਇਆ ਜੋ ਤੁਸੀਂ ਆਪਣੇ ਉਤਪਾਦ ਵਿੱਚ ਜੋੜ ਸਕਦੇ ਸੀ, ਨਾ ਕਿ ਇੱਕ ਰੀਸਰਚ ਪ੍ਰੋਜੈਕਟ ਜੋ ਤੁਹਾਨੂੰ ਨਵੇਂ ਸਿਰੇ ਤੋਂ ਲੈ ਕੇ ਜਾਣਾ ਪਏ। ਮੁੱਢ 'ਤੇ, ਇਹ ਇੱਕ ਲਾਇਬ੍ਰੇਰੀ ਹੈ ਜੋ ਗੰਦੇ ਟੈਕਸਟ ਨੂੰ ਐਸੇ ਬਣਾਉਂਦੀ ਹੈ ਕਿ ਤੁਸੀਂ ਉਸਨੂੰ ਤੇਜ਼ ਅਤੇ ਸਥਿਰ ਤਰੀਕੇ ਨਾਲ ਖੋਜ ਸਕੋ।
ਸਧਾਰਨ ਸ਼ਬਦਾਂ ਵਿੱਚ ਇੱਕ ਖੋਜ ਲਾਇਬ੍ਰੇਰੀ
Lucene ਚਾਰ ਪ੍ਰਯੋਗਿਕ ਕੰਮਾਂ 'ਤੇ ਧਿਆਨ ਕੇਂਦ੍ਰਿਤ ਕਰਦਾ ਹੈ:
- ਇੰਡੈਕਸਿੰਗ: ਇਹ ਸਮੱਗਰੀ (ਜਿਵੇਂ ਉਤਪਾਦ ਵੇਰਵੇ ਜਾਂ ਦਸਤਾਵੇਜ਼) ਪੜ੍ਹਦਾ ਹੈ ਅਤੇ ਇੱਕ ਇੰਡੈਕਸ ਬਣਾਉਂਦਾ ਹੈ—ਕਿਤਾਬ ਦੇ ਅੰਤ wale ਇੰਡੈਕਸ ਵਾਂਗ—ਤਾਂ ਜੋ ਖੋਜ ਸਭ ਕੁਝ ਲਾਈਨ ਦਰ ਲਾਈਨ ਸਕੈਨ ਨਾ ਕਰੇ।
- ਕੁਐਰੀੰਗ: ਇਹ ਇੱਕ ਕਵੇਰੀ ਭਾਸ਼ਾ ਅਤੇ ਟੂਲ ਦਿੰਦਾ ਹੈ ਜੋ ਯੂਜ਼ਰ ਦੇ ਕੀ ਮਤਲਬ ਹਨ ਜਦੋਂ ਉਹ ਕੀਵਰਡ, ਫਰੇਜ਼ ਜਾਂ ਫਿਲਟਰ ਟਾਈਪ ਕਰਦਾ ਹੈ, ਸਮਝਨ ਲਈ।
- ਸਕੋਰਿੰਗ: ਇਹ ਨਤੀਜਿਆਂ ਨੂੰ relevance ਅਨੁਸਾਰ ਰੈਂਕ ਕਰਦਾ ਹੈ। ਦੋ ਪੰਨੇ ਇੱਕੋ ਹੀ ਕੀਵਰਡ ਨਾਲ ਮਿਲ ਸਕਦੇ ਹਨ, ਪਰ Lucene ਇੱਕ ਨੂੰ ਉੱਚ ਸਕੋਰ ਦੇ ਸਕਦਾ ਹੈ ਕਿਉਂਕਿ ਟਰਮ ਸਿਰਲੇਖ ਵਿੱਚ ਆਇਆ, ਜ਼ਿਆਦਾ ਵਾਰ ਆਇਆ, ਜਾਂ ਕਿਸੇ ਮਹੱਤਵਪੂਰਨ ਫੀਲਡ ਵਿੱਚ ਆਇਆ।
- ਅਪਡੇਟਿੰਗ: ਇਹ ਨਵੀਂ ਸਮੱਗਰੀ ਜੋੜਨ ਅਤੇ ਜੋ ਕੁਝ ਖੋਜਯੋਗ ਹੈ ਉਸਨੂੰ ਤਾਜਾ ਕਰਨ ਦਾ ਸਹারা ਦਿੰਦਾ ਹੈ ਬਿਨਾਂ ਸਾਰਾ ਕੁਝ ਨਵੇਂ ਸਿਰੇ ਤੋਂ ਮੁੜ ਬਣਾਉਣ ਦੇ।
ਅਸਲੀ ਉਤਪਾਦਾਂ ਨਾਲ ਨਕਸ਼ੇ ਵਾਲੇ ਸਧਾਰਨ ਉਦਾਹਰਣ
Lucene ਪਹਿਲਾਂ (ਅਤੇ ਹੁਣ ਵੀ) ਦੈਨੀਕ ਖੋਜ ਲੋੜਾਂ ਲਈ ਵਧੀਆ ਸੀ:
- ਉਤਪਾਦ ਕੈਟਾਲਾਗ: “waterproof hiking boots” ਖੋਜੋ ਅਤੇ ਬਰਾਂਡ, ਵਰਗ ਜਾਂ ਸਮੀਖਿਆਂ ਲਈ ਬੂਸਟ ਨਾਲ ਆਈਟਮ ਰੈਂਕ ਹੋ ਕੇ ਆਉਣ।
- ਅੰਦਰੂਨੀ ਦਸਤਾਵੇਜ਼: PDFs, ਵਿਸਕੀ ਪੰਨੇ ਜਾਂ ਨੋਲੇਜ-ਬੇਸ ਆਰਟੀਕਲਾਂ 'ਤੇ ਖੋਜ ਕਰੋ, ਫਰੇਜ਼ ਖੋਜ ਜਿਵੇਂ "return policy" ਨਾਲ।
- ਲਾਗ ਅਤੇ ਟ੍ਰਬਲਸ਼ੂਟਿੰਗ ਨੋਟਸ: ਐਰਰ ਸੁਨੇਹੇ, ਰਿਕਵੇਸਟ ID ਅਤੇ ਸਰਵਿਸ ਨਾਮਾਂ ਨੂੰ ਖੋਜੋ ਤਾਂ ਜੋ ਸੰਬੰਧਿਤ ਘਟਨਾਵਾਂ ਤੇਜ਼ੀ ਨਾਲ ਮਿਲ ਸਕਣ।
ਟੀਮਾਂ ਲਈ ਇਹਨਾ ਆਕਰਸ਼ਕ ਕਿਉਂ ਸੀ
Lucene ਦੀ ਖ਼ਾਸੀਅਤ ਕੋਈ ਜਾਦੂ ਨਹੀਂ ਸੀ—ਇਹ ਵਰਤਣ ਯੋਗਤਾ ਸੀ:
- ਇੰਟਰਐਕਟਿਵ ਖੋਜ ਲਈ ਕਾਫੀ ਤੇਜ਼ ਕਿਉਂਕਿ ਇੰਡੈਕਸ ਸਟਰੱਕਚਰ ਰੀਟਰੀਵਲ ਲਈ ਬਣਾਇਆ ਗਿਆ ਹੈ।
- ਲਚਕੀਲਾ: ਤੁਸੀਂ ਫੀਲਡ ਦੀ ਪਰਿਭਾਸ਼ਾ ਕਰ ਸਕਦੇ ਹੋ (ਸਿਰਲੇਖ, ਬਾਡੀ, ਟੈਗਸ), analyzers (ਪਾਠ ਨੂੰ ਕਿਵੇਂ ਟੋਕਨ ਕੀਤਾ ਜਾਏ), ਅਤੇ ਰੈਂਕਿੰਗ ਲਈ ਟਿਊਨਿੰਗ ਨਾਬ।
- ਏਂਬੇਡੇਬਲ: ਇਹ ਇੱਕ ਲਾਇਬ੍ਰੇਰੀ ਹੈ ਜੋ ਤੁਸੀਂ ਸਿੱਧਾ ਆਪਣੀ ਐਪ ਵਿੱਚ ਜੋੜ ਸਕਦੇ ਹੋ, ਜੋ ਟੀਮਾਂ ਨੂੰ ਇੱਕ ਵੱਖਰਾ “ਖੋਜ ਸਿਸਟਮ” ਦੇ ਉਪਭੋਗ ਦੀ ਉਡੀਕ ਕੀਤੇ ਬਿਨਾਂ ਫੀਚਰ ਜਾਰੀ ਕਰਨ ਯੋਗ ਬਣਾਉਂਦਾ।
ਇੱਕ ਵਿਆਪਕ ਇਕੋ-ਆਧਾਰ
Lucene ਨੇ ਸਿਰਫ ਇੱਕ ਕੰਪਨੀ ਦੀ ਸਮੱਸਿਆ ਨਹੀਂ ਹੱਲ ਕੀਤੀ; ਇਹ ਇੱਕ ਭਰੋਸੇਯੋਗ ਬੇਸ ਲੇਅਰ ਬਣ ਗਿਆ ਜਿਸ 'ਤੇ ਕਈ ਖੋਜ ਐਪਲੀਕੇਸ਼ਨਾਂ ਅਤੇ ਸਰਵਿਸਜ਼ ਨੇ ਨਿਰਮਾਣ ਕੀਤਾ। ਬਹੁਤ ਸਾਰੇ ਬਾਅਦ ਦੇ ਖੋਜ ਟੂਲਾਂ ਨੇ Lucene ਦੇ ਇੰਡੈਕਸਿੰਗ ਅਤੇ relevance ਢੰਗ ਨੂੰ ਧਾਰ ਕੀਤਾ—ਜਾਂ ਸਿੱਧਾ Lucene ਨੂੰ ਅੰਦਰੂਨੀ ਇੰਜਣ ਵਜੋਂ ਵਰਤਿਆ।
ਕਿਉਂ ਵੰਡਿਆ ਡੇਟਾ ਪ੍ਰੋਸੈਸਿੰਗ ਜ਼ਰੂਰੀ ਹੋ ਗਿਆ
ਲੌਗਸ, ਕਲਿਕਸਟਰੀਮ, ਈਮੇਲ ਆਰਕਾਈਵ, ਸੈਂਸਰ ਰੀਡਿੰਗ ਅਤੇ ਵੈੱਬ ਪੇਜਾਂ ਸਾਰੀਆਂ ਇਸ ਸਾਦੇ ਗੁਣ ਨੂੰ ਸਾਂਝਾ ਕਰਦੀਆਂ ਹਨ: ਉਹ ਉਸ ਰਫਤਾਰ ਨਾਲ ਵਧਦੀਆਂ ਹਨ ਜੋ ਤੁਸੀਂ ਪਿਛਲੇ ਸਾਲ ਖਰੀਦੇ ਸਰਵਰਾਂ ਦੀ ਦੇਣਸ਼ਕਤੀ ਤੋਂ ਤੇਜ਼ ਹੈ। ਇਕ ਵਾਰੀ ਟੀਮਾਂ “ਸਭ ਕੁਝ ਰੱਖਣ” ਲੱਗੀਆਂ, ਡੇਟਾਸੇਟ ਇੱਕ ਸਰਵਰ 'ਤੇ ਫਿੱਟ ਹੋਣਾ ਰੋਕ ਦਿਤਾ—ਨਾ ਸਿਰਫ ਸਟੋਰੇਜ ਵਿੱਚ, ਬਲਕਿ ਉਹ ਸਮਾਂ ਵਿੱਚ ਵੀ ਜੋ ਉਹਨਾਂ ਨੂੰ ਪ੍ਰੋਸੈਸ ਕਰਨ ਲਈ ਲੱਗਦਾ।
ਜਦ “ਸਿਰਫ ਵੱਡਾ ਸਰਵਰ ਖਰੀਦੋ” ਕੰਮ ਕਰਨਾ ਬੰਦ ਕਰ ਦਿੰਦਾ
ਪਹਿਲੀ ਪ੍ਰਤੀਕਿਰਿਆ ਸਕੇਲ-ਅੱਪ ਸੀ: ਵੱਧ CPU, ਵੱਧ RAM, ਵੱਡੇ ਡਿਸਕ। ਇਹ ਚੱਲਦਾ ਹੈ…ਜਦ ਤਕ ਉਹ ਨਹੀਂ ਕਰਦਾ।
ਹਾਈ-ਐਂਡ ਸਰਵਰ ਤੇਜ਼ੀ ਨਾਲ ਮਹਿੰਗੇ ਹੋ ਜਾਂਦੇ ਹਨ, ਅਤੇ ਕੀਮਤ ਉੱਚੀ ਹੋਣ 'ਤੇ ਲੀਕੇ ਨਹੀਂ ਹੁੰਦੀ। ਤੁਸੀਂ ਆਪਣੇ ਪੂਰੇ ਪਾਇਪਲਾਈਨ 'ਤੇ ਇਕ ਹੀ ਬਾਕਸ ਤਹ ਨਿਰਭਰ ਹੋ ਜਾਂਦੇ ਹੋ। ਜੇ ਇਹ ਫੇਲ ਹੋ ਜਾਵੇ, ਸਭ ਕੁਝ ਫੇਲ ਹੁੰਦਾ ਹੈ। ਅਤੇ ਭਾਵੇਂ ਫੇਲ ਨ ਹੋਵੇ, ਫਿਜ਼ਿਕਲ ਸੀਮਾਵਾਂ ਹਨ: ਡਿਸਕ ਇੱਕ ਨਿਰਧਾਰਿਤ ਰਫਤਾਰ 'ਤੇ ਘੁੰਮ ਸਕਦੇ ਹਨ, ਮੈਮੋਰੀ ਦੀ ਛੱਤ ਹੁੰਦੀ ਹੈ, ਅਤੇ ਕੁਝ ਵਰਕਲੋਡ ਇਸ ਤਰ੍ਹਾਂ ਹੁੰਦੇ ਹਨ ਜੋ ਡੇਟਾ ਜਿਵੇਂ-ਜਿਵੇਂ ਡਬਲ ਹੁੰਦਾ ਹੈ, ਸਮੇਂ 'ਚ ਮੁਕੰਮਲ ਨਹੀਂ ਹੁੰਦੇ।
ਸਕੇਲ-ਆਊਟ: ਬਹੁਤ ਸਾਰੀਆਂ ਮਸ਼ੀਨਾਂ, ਇੱਕ ਨੌਕਰੀ
ਸਕੇਲ-ਆਊਟ ਦ੍ਰਿਸ਼ਟੀਕੋਣ ਨੂੰ ਉਲਟ ਦਿੰਦਾ ਹੈ। ਇਕ ਤਾਕਤਵਰ ਕੰਪਿਊਟਰ ਦੀ ਥਾਂ, ਤੁਸੀਂ ਕਈ ਆਮ ਕੰਪਿਊਟਰ ਵਰਤਦੇ ਹੋ ਅਤੇ ਕੰਮ ਵੰਡ ਦਿੰਦੇ ਹੋ।
ਇੱਕ ਮਦਦਗਾਰ ਮਾਨਸਿਕ ਮਾਡਲ ਹੈ: ਇਕ ਲਾਇਬ੍ਰੇਰੀ ਦੇ ਪਰਿਵਾਹ ਦਿਨ—ਇੱਕ ਵਿਅਕਤੀ ਭਾਰੀਆਂ ਡੱਬਿਆਂ ਨੂੰ ਥਾਮ ਸਕਦਾ ਹੈ, ਪਰ ਦਸ ਲੋਕ ਛੋਟੀਆਂ ਡੱਬੀਆਂ ਲੈ ਕੇ ਜਲਦੀ ਮੁਕੰਮਲ ਕਰ ਲੈਂਦੇ ਹਨ—ਅਤੇ ਜੇ ਇਕ ਥੱਕ ਜਾਂਦਾ ਹੈ ਤਾਂ ਬਾਕੀ ਫਿਰ ਵੀ ਅੱਗੇ ਬਢੰਦੇ ਹਨ। ਵੰਡਿਆ ਡੇਟਾ ਪ੍ਰੋਸੈਸਿੰਗ ਇਸੇ ਵਿਚਾਰ ਨੂੰ ਸਟੋਰੇਜ ਅਤੇ ਗਣਨਾ 'ਤੇ ਲਾਗੂ ਕਰਦਾ ਹੈ।
ਕਾਮੋਡੀਟੀ ਹਾਰਡਵੇਅਰ ਲਈ ਫੋਲਟ ਟੋਲਰੈਂਸ ਦੀ ਲੋੜ
ਕਈ ਸਸਤੇ ਮਸ਼ੀਨਾਂ ਵਰਤਣ ਨਾਲ ਨਵਾਂ ਅਨੁਮਾਨ ਆਉਂਦਾ ਹੈ: ਕੁਝ ਨਾ ਕੁਝ ਹਮੇਸ਼ਾ ਟੁੱਟ ਰਿਹਾ ਹੁੰਦਾ ਹੈ। ਡਿਸਕ ਖਰਾਬ ਹੁੰਦੇ ਹਨ, ਨੈੱਟਵਰਕ ਹਿੱਕਪ ਕਰਦੇ ਹਨ, ਨੋਡਸ ਰੀਬੂਟ ਹੁੰਦੇ ਹਨ।
ਇਸ ਲਈ ਲਕੜੀ ਇਹ ਬਣ ਗਈ ਕਿ ਸਿਸਟਮ ਫੇਲਿਅਰ ਦੀ ਉਮੀਦ ਕਰੇ ਅਤੇ ਚੱਲਦਾ ਰਹੇ—ਡੇਟਾ ਦੀਆਂ ਕਾਪੀਆਂ ਰੱਖ ਕੇ, ਇਹ ਟਰੈਕ ਕਰਕੇ ਕਿ ਨੌਕਰੀਆਂ ਦੇ ਕਿਹੜੇ ਹਿੱਸੇ ਮੁੱਕ ਗਏ ਹਨ, ਅਤੇ ਆਪੋ-ਆਪਣੇ ਤੌਰ 'ਤੇ ਉਸ ਹਿੱਸੇ ਨੂੰ ਦੁਬਾਰਾ ਚਲਾਕੇ ਜੋ ਰੁਕ ਗਏ ਸਨ। ਇਹ ਦਬਾਅ—ਇੱਕ ਮਸ਼ੀਨ ਤੋਂ ਵੱਧ ਡੇਟਾ, ਅਤੇ ਵੱਡੇ ਪੈਮाने 'ਤੇ ਅਕਸਰ ਫੇਲਿਅਰ—Hadoop ਦੀ ਵੰਡਿਆ ਪ੍ਰੋਸੈਸਿੰਗ ਦੇ ਰਵੱਈਏ ਲਈ ਸੈੱਟ ਕਰਦਾ ਹੈ।
Hadoop ਸਧਾਰਨ ਭਾਸ਼ਾ ਵਿੱਚ: HDFS ਅਤੇ MapReduce
ਖੋਜ ਨੂੰ ਮੋਬਾਈਲ 'ਤੇ ਲਿਆਓ
ਆਨ-ਕਾਲ ਖੋਜ, ਇੰਸੀਡੈਂਟ ਨੋਟਸ ਜਾਂ ਤੇਜ਼ ਡੈਸ਼ਬੋਰਡ ਲਈ ਇੱਕ Flutter ਸਹਾਇਕ ਐਪ ਬਣਾਓ।
Hadoop ਨੂੰ ਸਭ ਤੋਂ ਅਸਾਨ ਤਰੀਕੇ ਨਾਲ ਦੋ ਸਧਾਰਨ ਵਾਅਦਿਆਂ ਵਜੋਂ ਸਮਝਿਆ ਜਾ ਸਕਦਾ ਹੈ: ਕਈ ਆਮ ਮਸ਼ੀਨਾਂ 'ਤੇ ਬਹੁਤ ਵੱਡਾ ਡੇਟਾ ਸਟੋਰ ਕਰੋ ਅਤੇ ਉਹ ਡੇਟਾ ਸਮਕਾਲੀ ਤੌਰ 'ਤੇ ਪ੍ਰੋਸੈਸ ਕਰੋ। ਇਹ ਦੋ ਕੋਰ ਹਿੱਸਿਆਂ ਵਜੋਂ ਦਿਖਾਈ ਦਿੰਦਾ ਹੈ: HDFS ਸਟੋਰੇਜ ਲਈ ਅਤੇ MapReduce ਪ੍ਰੋਸੈਸਿੰਗ ਲਈ।
HDFS: ਕਈ ਡਿਸਕਾਂ ਤੋਂ ਬਣਿਆ ਇਕ ਵੱਡਾ ਫਾਇਲ ਸਿਸਟਮ
HDFS (Hadoop Distributed File System) ਉਹਨਾਂ ਫਾਇਲਾਂ ਨੂੰ ਜੋ ਇੱਕ ਕੰਪਿਊਟਰ ਲਈ ਬਹੁਤ ਵੱਡੀਆਂ ਹਨ, ਨਿਰਧਾਰਿਤ-ਆਕਾਰ ਦੇ ਬਲੌਕ ਵਿੱਚ ਵੰਡਦਾ ਹੈ (ਸੋਚੋ “ਚੰਕਸ”)। ਉਹ ਬਲੌਕਜ਼ ਫਿਰ ਕਲੱਸਟਰ ਦੀਆਂ ਵੱਖ-ਵੱਖ ਮਸ਼ੀਨਾਂ 'ਤੇ ਫੈਲੇ ਹੋਏ ਹੁੰਦੇ ਹਨ।
ਮਸ਼ੀਨ ਫੇਲ ਹੋ ਜਾਣ 'ਤੇ ਡੇਟਾ ਸੁਰੱਖਿਅਤ ਰਹੇ, ਇਹ ਲਈ HDFS ਹਰ ਬਲੌਕ ਦੀਆਂ ਕਾਪੀਆਂ ਵੀ ਵੱਖ-ਵੱਖ ਮਸ਼ੀਨਾਂ 'ਤੇ ਰੱਖਦਾ ਹੈ। ਜੇ ਇਕ ਕੰਪਿਊਟਰ ਡਾਊਨ ਹੋ ਜਾਏ, ਸਿਸਟਮ ਫਿਰ ਵੀ ਫਾਇਲ ਨੂੰ ਹੋਰ ਕਾਪੀ ਤੋਂ ਪੜ੍ਹ ਸਕਦਾ ਹੈ—ਬਿਨਾਂ ਤੁਹਾਨੂੰ ਬੈਕਅੱਪਾਂ ਦੀ تلاش ਕਰਨ ਦੇ।
ਪਰੈਕਟਿਕਲ ਨਤੀਜਾ: HDFS ਵਿੱਚ ਇੱਕ ਡਾਇਰੈਕਟਰੀ ਇੱਕ ਆਮ ਫੋਲਡਰ ਵਾਂਗ ਵਰਤਦੀ ਹੈ, ਪਰ ਪਿਛੋਕੜ ਵਿੱਚ ਇਹ ਕਈ ਡਿਸਕਾਂ ਤੋਂ ਜੁੜੀ ਹੋਈ ਹੁੰਦੀ ਹੈ।
MapReduce: ਕੰਮ ਵੰਡੋ, ਫਿਰ ਜਵਾਬ ਜੋੜੋ
MapReduce ਇੱਕ ਬੈਚ ਪ੍ਰੋਸੈਸਿੰਗ ਲਈ ਪ੍ਰੋਗ੍ਰਾਮਿੰਗ ਮਾਡਲ ਹੈ। ਇਸਦੇ ਦੋ ਨਾਮਿਤ ਚਰਣ ਹਨ:
- Map: ਹਰ ਮਸ਼ੀਨ ਆਪਣੀਆਂ ਸਥਾਨਕ ਬਲੌਕਾਂ ਨੂੰ ਪ੍ਰੋਸੈਸ ਕਰਦੀ ਹੈ ਅਤੇ ਮੱਧ-ਨਤੀਜੇ ਜਾਰੀ ਕਰਦੀ ਹੈ (ਅਕਸਰ ਸਧਾਰਨ key–value ਜੋੜੇ)।
- Reduce: ਸਿਸਟਮ ਇਕੋ-ਜਿਹੇ ਕੀਜ਼ ਨੂੰ ਇਕੱਠਾ ਕਰਦਾ ਹੈ ਅਤੇ ਉਹਨਾਂ ਨੂੰ ਅਖੀਰੀ ਨਤੀਜੇ ਵਿੱਚ ਜੋੜਦਾ ਹੈ।
ਇੱਕ ਲਾਜ਼ਮੀ ਉਦਾਹਰਣ ਬਹੁਤ ਸਾਰੀਆਂ ਲੋਗ ਫਾਈਲਾਂ 'ਚ ਸ਼ਬਦ ਗਿਣਤੀ ਕਰਨ ਦੀ ਹੈ: ਮੈਪਰ ਆਪਣੇ ਚੰਕਸ ਵਿੱਚ ਸ਼ਬਦ ਗਿਣਦੇ ਹਨ; ਰੀਡਿਊਸਰ ਹਰ ਸ਼ਬਦ ਲਈ ਕੁੱਲ ਜੋੜਦੇ ਹਨ।
ਇਸ ਨਾਲ ਕੀ ਸੰਭਵ ਹੋਇਆ
HDFS + MapReduce ਨੂੰ ਇਕੱਠਾ ਕਰਕੇ ਵੱਡੇ ਬੈਚ ਜੌਬਸ—ਲਾਗ ਵਿਸ਼ਲੇਸ਼ਣ, ਇੰਡੈਕਸਿੰਗ ਪਾਈਪਲਾਈਨ, ਕਲਿਕਸਟ੍ਰੀਮ ਐਗਰੀਗੇਸ਼ਨ, ਡੇਟਾ ਸਫਾਈ—ਉਹਨਾਂ ਡੇਟਾਸੇਟਸ 'ਤੇ ਚਲਾਉਣਾ ਪ੍ਰਭਾਵਸ਼ਾਲੀ ਬਣ ਗਿਆ ਜੋ ਇਕ ਸਰਵਰ ਲਈ ਬਹੁਤ ਵੱਡੇ ਸਨ। ਇੱਕ ਵੱਡੇ ਮਸ਼ੀਨ ਨੂੰ ਖਰੀਦਣ ਦੀ ਥਾਂ, ਟੀਮਾਂ ਹੋਰ ਆਮ ਬਾਕਸ ਮਿਲਾ ਕੇ ਸਕੇਲ ਕਰ ਸਕਦੀਆਂ ਸਨ ਅਤੇ Hadoop ਸਟੋਰੇਜ, ਰੀਟ੍ਰਾਈਜ਼, ਅਤੇ ਸਮਕਾਲੀ ਐਕਸਿਕਿ600ਨ ਕੋਆਰਡੀਨੇਟ ਕਰਦਾ।
ਖੋਜ ਤੋਂ ਕਲੱਸਟਰ ਤੱਕ: ਖਿਆਲ ਕਿਵੇਂ ਜੋੜੇ ਗਏ
Lucene ਅਤੇ Hadoop ਵੱਖ-ਵੱਖ ਅਧਿਆਇ ਵਰਗੇ ਦਿੱਸ ਸਕਦੇ ਹਨ—ਇੱਕ ਖੋਜ ਬਾਰੇ, ਦੂਜਾ “ਬਿਗ ਡੇਟਾ” ਬਾਰੇ। ਪਰ ਉਹ ਇੱਕ ਹੀ ਮਨੋਭਾਵ ਸਾਂਝਾ ਕਰਦੇ ਹਨ: ਕਾਰਗਰ ਟੂਲ ਬਣਾਓ ਜੋ ਅਸਲ ਟੀਮਾਂ ਚਲਾ ਸਕਣ, ਵਧਾ ਸਕਣ ਅਤੇ ਭਰੋਸਾ ਕਰ ਸਕਣ, ਨ ਕਿ ਸਿਰਫ ਇਕ ਚਤੁਰ ਨਮੂਨਾ ਪ੍ਰਕਾਸ਼ਿਤ ਕਰੋ ਅਤੇ ਅੱਗੇ ਵਧੋ।
“Lucene ਮਨੋਭਾਵ”: ਕੁਝ ਅਜਿਹੇ ਚੀਜਾਂ ਜੋ ਲੋਕ ਵਰਤ ਸਕਣ
Lucene ਨੇ ਇੱਕ-ਦੋ ਮੁਸ਼ਕਲ ਕੰਮ ਬਹੁਤ ਖੁਬ ਕੀਤੇ—ਇੰਡੈਕਸਿੰਗ, ਕਵੇਰੀ ਅਤੇ ਰੈਂਕਿੰਗ—ਇਹਨਾਂ ਨੂੰ ਇਕ ਲਾਇਬ੍ਰੇਰੀ ਵਜੋਂ ਪੈਕ ਕੀਤਾ ਜੋ ਕੋਈ ਵੀ ਐਪ ਵਿੱਚ ਏਂਬੇਡ ਕਰ ਸਕਦਾ। ਇਸ ਚੋਣ ਨੇ ਇਹ ਸਿਖਾਇਆ: ਗ੍ਰਹਿਣਯੋਗਤਾ ਉਪਯੋਗੀਤਾ ਨਾਲ ਆਉਂਦੀ ਹੈ। ਜੇ ਇੱਕ ਟੂਲ ਵਰਤਣਾ ਆਸਾਨ, ਡੀਬੱਗਬਲ ਅਤੇ ਚੰਗੀ ਦਸਤਾਵੇਜ਼ੀਕਰਨ ਵਾਲਾ ਹੋਵੇ, ਤਾਂ ਇਹ ਆਪਣੀ ਮੂਲ ਵਰਤੋਂ ਤੋਂ ਬਾਹਰ ਵੀ ਫੈਲ ਜਾਂਦਾ ਹੈ।
Hadoop ਨੇ ਉਹੀ ਦ੍ਰਿਸ਼ਟੀ Distributed ਡੇਟਾ ਪ੍ਰੋਸੈਸਿੰਗ 'ਤੇ ਲਗਾਈ। ਇਹ ਨਿਸ਼ਚਿਤ ਕੀਤਾ ਕਿ ਨਿਸ਼ਚਿਤ ਹਾਰਡਵੇਅਰ ਜਾਂ ਨੀਚ ਪ੍ਰਣਾਲੀਆਂ ਦੀ ਲੋੜ ਨਹੀਂ, ਪਰ ਆਮ ਮਸ਼ੀਨਾਂ 'ਤੇ ਚੱਲਣ ਦੀ ਯੋਗਤਾ ਹੋਵੇ ਅਤੇ ਉਨ੍ਹਾਂ ਦੁਆਰਾ ਉਹ ਦਿਨ-ਪ੍ਰਤੀਦਿਨ ਦਾ ਦਰਦ ਹੱਲ ਹੋ ਜਾਵੇ—ਡੇਟਾ ਜੋ ਇਕ ਹੀ ਸਰਵਰ ਵਿੱਚ ਆਸਾਨੀ ਨਾਲ ਫਿੱਟ ਨਹੀਂ ਹੁੰਦਾ।
“ਕੰਪਿਊਟੇਸ਼ਨ ਨੂੰ ਡੇਟਾ ਕੋਲ ਲਿਜਾਣਾ”, ਸਧਾਰਨ ਸ਼ਬਦਾਂ ਵਿੱਚ
ਜੇ ਤੁਹਾਡਾ ਡੇਟਾ ਵੱਡਾ ਹੈ, ਤਾਂ ਉਹਨੂੰ ਨੈੱਟਵਰਕ 'ਤੇ ਇੱਕ ਤਾਕਤਵਰ ਮਸ਼ੀਨ ਨੂੰ ਕਾਪੀ ਕਰਨਾ ਉਸੇ ਤਰ੍ਹਾਂ ਹੈ ਜਿਵੇਂ ਲਾਇਬ੍ਰੇਰੀ ਦੀਆਂ ਸਾਰੀਆਂ ਕਿਤਾਬਾਂ ਨੂੰ ਇੱਕ ਡੈਸਕ ਤੇ ਲਿਆਉਣਾ। Hadoop ਦਾ ਤਰੀਕਾ ਇਹ ਹੈ ਕਿ ਕੰਮ ਉਸੇ ਜਗ੍ਹਾ ਭੇਜੋ ਜਿੱਥੇ ਡੇਟਾ ਪਹਿਲਾਂ ਹੀ ਹੁੰਦਾ ਹੈ: ਛੋਟੇ-ਟੁਕੜੇ ਕੋਡ ਨੂੰ ਕਈ ਮਸ਼ੀਨਾਂ 'ਤੇ ਭੇਜੋ, ਹਰ ਇਕ ਆਪਣਾ ਸਥਾਨਕ ਕੰਮ ਕਰੋ, ਫਿਰ ਨਤੀਜੇ ਜੋੜੋ।
ਇਹ ਵਿਚਾਰ ਖੋਜ ਇੰਡੈਕਸਿੰਗ ਨਾਲ ਮਿਲਦਾ ਹੈ: ਤੁਸੀਂ ਡੇਟਾ ਨੂੰ ਉਸ ਥਾਂ ਸੱਜਾ ਦਿੰਦੇ ਹੋ (ਇੰਡੈਕਸ) ਤਾਂ ਜੋ ਕਵੇਰੀਆਂ ਹਰ ਵਾਰੀ ਸਭ ਕੁਝ ਸਕੈਨ ਨਾ ਕਰਨ।
ਗ੍ਰਹਿਣਯੋਗਤਾ ਲਈ ਓਪਨ ਸੋਰਸ
ਦੋਹਾਂ ਪ੍ਰੋਜੈਕਟਾਂ ਨੂੰ ਓਪਨ ਸਹਿਯੋਗ ਤੋਂ ਲਾਭ ਮਿਲਿਆ: ਯੂਜ਼ਰ ਬੱਗ ਰਿਪੋਰਟ ਕਰ ਸਕਦੇ ਸਨ, ਫਿਕਸਜ਼ ਸਬਮਿਟ ਕਰ ਸਕਦੇ ਸਨ, ਅਤੇ ਓਪਰੇਸ਼ਨਲ ਗਿਆਨ ਸਾਂਝਾ ਕਰ ਸਕਦੇ ਸਨ। ਅਡਾਪਸ਼ਨ ਦੇ ਮੁੱਖ ਚਾਲਕ ਸੀ ਸਧਾਰਨ ਪਰ ਨਿਸ਼ਚਿਤ ਚੀਜ਼ਾਂ—ਸਪਸ਼ਟ ਦਸਤਾਵੇਜ਼ੀਕਰਨ, ਵਾਤਾਵਰਨਾਂ 'ਚ ਪੋ੍ਰਟੇਬਿਲਟੀ, ਅਤੇ Apache ਸਕੀਮ ਜੋ ਕੰਪਨੀਆਂ ਨੂੰ ਇਹ ਯਕੀਨ ਦਿਵਾਉਂਦੀ ਸੀ ਕਿ ਉਹ ਰੁਕ-ਵੈਂਡਰ ਲਾਕ-ਇਨ ਦੀ ਚਿੰਤਾ ਨਾ ਕਰਨ।
ਪ੍ਰਾਰੰਭਿਕ ਵਰਤੋਂ ਕੇਸ ਜਿਹੜਿਆਂ ਨੇ ਗ੍ਰਹਿਣਯੋਗਤਾ ਚਲਾਈ
ਇੱਕ ਡੇਟਾ ਟੂਲ ਐਂਡ-ਟੂ-ਐਂਡ ਭੇਜੋ
ਲੌਗ ਅਤੇ ਕਲਿਕਸਟਰੀਮ ਵਿਚਾਰਾਂ ਨੂੰ React, Go ਅਤੇ Postgres ਨਾਲ ਇੱਕ ਕੰਮ ਕਰਨ ਵਾਲੀ ਵੈੱਬ ਐਪ ਵਿੱਚ ਬਦਲੋ।
Hadoop ਇਸ ਲਈ ਫੈਲਿਆ ਨਹੀਂ ਕਿ ਟੀਮਾਂ ਸਵੇਰ-ਸਵੇਰ "ਬਿਗ ਡੇਟਾ" ਚਾਹੁੰਦੀਆਂ ਸਨ। ਇਹ ਫੈਲਿਆ ਕਿਉਂਕਿ ਕੁਝ ਆਮ ਕੰਮ ਉਸ ਵੇਲੇ ਇਕ ਸਰਵਰ ਅਤੇ ਰਵਾਇਤੀ ਡੇਟਾਬੇਸ 'ਤੇ ਮਹਿੰਗੇ ਅਤੇ ਅਣ-ਭਰੋਸੇਯੋਗ ਹੋ ਰਹੇ ਸਨ।
ਉਹ ਪਹਿਲੇ ਸਮੱਸਿਆਵਾਂ ਜਿਨ੍ਹਾਂ ਲਈ Hadoop ਅਚਾਨਕ ਮਦਦਗਾਰ ਸੀ
ਲੌਗ ਪ੍ਰੋਸੈਸਿੰਗ ਇੱਕ ਪਹਿਲੀ ਵੱਡੀ ਜਿੱਤ ਸੀ। ਵੈੱਬ ਸਰਵਰ, ਐਪਸ, ਅਤੇ ਨੈੱਟਵਰਕ ਡਿਵਾਈਸ ਬਹੁਤ ਮਾਤਰਾ ਵਿੱਚ ਐਪੈਂਡ-ਓਨਲੀ ਰਿਕਾਰਡ ਜਨਰੇਟ ਕਰਦੇ ਹਨ। ਟੀਮਾਂ ਨੂੰ ਰੋਜ਼ਾਨਾ (ਜਾਂ ਘੰਟੇਦਾਰ) ਰੂਪ-ਸਾਰੈਂਪਜ: ਐਰਰਜ਼ ਬਾਇ ਐਂਡਪੋਇੰਟ, ਲੇਟੈਂਸੀ ਪ੍ਰਤੀਸ਼ਤ, ਖੇਤਰ-ਅਨੁਸਾਰ ਟ੍ਰੈਫਿਕ, ਟਾਪ ਰੀਫਰਰ ਆਦਿ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ। Hadoop ਨੇ ਉਨ੍ਹਾਂ ਨੂੰ ਕੱਚੇ ਲੌਗ HDFS ਵਿੱਚ ਡਾਲ ਕੇ ਨਿਰਧਾਰਿਤ ਸਮੇਂ ਤੇ ਸੰਖੇਪ ਪੁਸਤਕ ਬਣਾਉਣ ਦੀ ਆਸਾਨੀ ਦਿੱਤੀ।
ਕਲਿਕਸਟ੍ਰੀਮ ਵਿਸ਼ਲੇਸ਼ਣ ਨੇ ਕੁਝ ਹੀ ਦੇਰ ਵਿੱਚ ਅਨੁਕੂਲਤਾ ਪਾਈ। ਪ੍ਰੋਡਕਟ ਟੀਮਾਂ ਜਾਣਨਾ ਚਾਹੁੰਦੀਆਂ ਸਨ ਕਿ ਉਪਭੋਗਤਾ ਕਿਸ ਤਰ੍ਹਾਂ ਯਾਤਰਾ ਕਰਦੇ ਹਨ—ਕਿਸ ਤੇ ਕਲਿੀ ਕੀਤਾ ਗਿਆ ਪਹਿਲਾਂ, ਕਿੱਥੇ ਉਹ ਰੁਕਦੇ ਹਨ, ਕੋਹੋਰਟ ਕਿਵੇਂ ਵਰਤ ਰਹੇ ਹਨ। ਇਹ ਡੇਟਾ ਗੰਦ ਅਤੇ ਉੱਚ-ਵਾਲਿਊਮ ਹੁੰਦਾ ਹੈ, ਅਤੇ ਮੁੱਲ ਅਕਸਰ ਵੱਡੇ ਏਗਰੀਗੇਟ ਤੋਂ ਆਉਂਦਾ ਹੈ ਨਾ ਕਿ ਵਿਅਕਤੀਗਤ ਲੁੱਕਅਪਸ ਤੋਂ।
ETL (extract, transform, load) ਇੱਕ ਮੂਲ ਵਰਤੋਂ ਕੇਸ ਬਣ ਗਿਆ। ਸੰਗਠਨਾਂ ਕੋਲ ਡੇਟਾ ਵੱਖ-ਵੱਖ ਡੇਟਾਬੇਸ, ਫਾਇਲਾਂ, ਅਤੇ ਵੇਨਡਰ ਐਕਸਪੋਰਟਸ ਵਿੱਚ ਫੈਲਾ ਹੋਇਆ ਹੁੰਦਾ ਸੀ। Hadoop ਨੇ ਕੱਚਾ ਡੇਟਾ ਲੈਂਡ ਕਰਨ, ਵੱਡੇ ਪੈਮਾਨੇ 'ਤੇ ਰੂਪਾਂਤਰ ਕਰਨ, ਅਤੇ ਫਿਰ curated ਨਤੀਜੇ ਡੇਟਾ ਵੈਅਰਹਾਊਸ ਜਾਂ ਡਾਊਨਸਟਰੀਮ ਸਿਸਟਮਾਂ ਵਿੱਚ ਲੋਡ ਕਰਨ ਲਈ ਕੇਂਦਰੀ ਥਾਂ ਦਿੱਤੀ।
“ਬੈਚ” ਦਾ ਕੀ ਮਤਲਬ ਹੈ—ਅਤੇ ਕਿਉਂ ਇਹ ਮਿਲਦਾ ਸੀ
ਇਨ੍ਹਾਂ ਵਿੱਚੋਂ ਜ਼ਿਆਦਾਤਰ ਵਰਕਫਲੋ ਬੈਚ ਸਨ: ਤੁਸੀਂ ਇੱਕ ਖਿੜਕੀ ਦੇ ਦੌਰਾਨ (ਕਹੋ ਇੱਕ ਘੰਟਾ ਜਾਂ ਦਿਨ) ਡੇਟਾ ਇਕਠਾ ਕਰਦੇ ਹੋ, ਫਿਰ ਇਸ ਨੂੰ ਇੱਕ ਨੌਕਰੀ ਵਜੋਂ ਪ੍ਰੋਸੈਸ ਕਰਦੇ ਹੋ ਜੋ ਮਿੰਟਾਂ ਜਾਂ ਘੰਟਿਆਂ ਲੱਗ ਸਕਦੀ ਹੈ। ਬੈਚ ਸਾਰੀਆਂ ਰੁਪਾਂਤਰ ਤੇਜ਼ੀ ਨਾਲ ਨਹੀਂ ਮੰਗਦਾ—ਇਹ ਉਤਮ ਹੈ ਜਦ ਸਵਾਲ ਰੁਝਾਨਾਂ ਅਤੇ ਕੁੱਲਤਾਂ ਬਾਰੇ ਹੋਵੇ, ਨਾ ਕਿ ਤੁਰੰਤ ਪ੍ਰਤੀ-ਯੂਜ਼ਰ ਜਵਾਬ ਲਈ।
ਵਾਸਤਵ ਵਿੱਚ, ਇਸਦਾ ਮਤਲਬ ਸੀ ਕਿ Hadoop ਰਾਤ-भर ਰਿਪੋਰਟਿੰਗ, ਪੀਰੀਓਡਿਕ ਡੈਸ਼ਬੋਰਡ ਅਤੇ ਵੱਡੇ ਬੈਕਫਿਲਸ ("ਨਵੇਂ ਲਾਜਿਕ ਨਾਲ ਪਿਛਲੇ ਸਾਲ ਦੀ ਮੁੜ-ਗਣਨਾ") ਦਾ ਢਾਂਚਾ ਸੀ। ਇਹ ਇੰਟਰਐਕਟਿਵ, ਉਪ-ਸੈਕਿੰਡ ਖੋਜ ਲਈ ਨਹੀਂ ਬਣਿਆ ਸੀ।
ਟੀਮਾਂ ਨੂੰ ਜੋ ਨਤੀਜੇ ਚਾਹੀਦੇ ਸਨ
ਇੱਕ ਵੱਡੀ ਚੀਜ਼ ਸੀ ਸਸਤੀ ਪ੍ਰੋਸੈਸਿੰਗ: ਇੱਕ ਮਹਿੰਗੇ ਇਕ-ਬਕਸ ਨੂੰ ਸਕੇਲ-ਅੱਪ ਕਰਨ ਦੀ ਥਾਂ, ਕਾਮੋਡੀਟੀ ਹਾਰਡਵੇਅਰ ਨਾਲ ਸਕੇਲ-ਆਊਟ।
ਹੋਰ ਇੱਕ ਸੀ ਰਿਡੰਡੈੰਸੀ ਰਾਹੀਂ ਭਰੋਸੇਯੋਗਤਾ। HDFS ਡੇਟਾ ਬਲੌਕਾਂ ਦੀਆਂ ਕਈ ਕਾਪੀਆਂ ਰੱਖਦਾ ਹੈ, ਇਸ ਲਈ ਨੋਡ ਫੇਲ ਹੋਣ 'ਤੇ ਡੇਟਾ ਗੁਆਉਣ ਜਾਂ ਦੁਬਾਰਾ ਸ਼ੁਰੂ ਕਰਨ ਦੀ ਲੋੜ ਨਹੀ ਹੁੰਦੀ।
ਦੇਣ-ਲੇਣ (ਟ੍ਰੇਡਆਫ) ਜੋ ਮਾਨੇ ਜਾਣੇ ਲਾਇਕ ਹਨ
Hadoop ਦੀ ਸ਼ੁਰੂਆਤੀ ਸਟੈਕ ଇੰਟਰਐਕਟਿਵ ਕਵੇਰੀਆਂ ਲਈ ਢਿੱਲਾ ਹੋ ਸਕਦੀ ਸੀ, ਖਾਸ ਕਰਕੇ ਉਹਨਾਂ ਡੇਟਾਬੇਸਾਂ ਦੇ ਮੁਕਾਬਲੇ ਜੋ ਤੇਜ਼ ਰੀਡ ਲਈ ਤਿਆਰ ਕੀਤੇ ਗਏ ਸਨ।
ਇਸ ਨੇ ਓਪਰੇਸ਼ਨਲ ਜਟਿਲਤਾ ਵੀ ਲਾਈ: ਕਲੱਸਟਰਾਂ ਦਾ ਪ੍ਰਬੰਧਨ, ਜੌਬ ਸਥਾਪਨਾ, ਡੇਟਾ ਫਾਰਮੈਟ, ਅਤੇ ਬਹੁਤ-ਸਾਰੀਆਂ ਮਸ਼ੀਨਾਂ 'ਤੇ ਫੇਲਿਅਰਾਂ ਨੂੰ ਟ੍ਰਬਲਸ਼ੂਟ ਕਰਨਾ। ਅੰਦਰ ਮਾਮਲਿਆਂ ਵਿੱਚ, ਜਦ ਟੀਮ ਕੋਲ ਇੱਕ ਸਪਸ਼ਟ ਬੈਚ ਵਰਕਲੋਡ ਅਤੇ ਪਾਈਪਲਾਈਨ ਨੂੰ ਸਥਿਰ ਕਰਨ ਦੀ ਅਨੁਸ਼ਾਸਨ ਹੋਵੇ, ਤਾਂ ਗ੍ਰਹਿਣਯੋਗਤਾ ਜ਼ਿਆਦਾ ਹੋਣੀ ਸੀ—ਬਜਾਏ ਇਹ ਕਿ Hadoop ਨੂੰ ਹਰ ਕੰਮ ਲਈ ਮਜ਼ਬੂਰ ਕੀਤਾ ਜਾਵੇ।
Lucene ਅਤੇ Hadoop ਇਕ-ਦੂਜੇ ਨੂੰ ਕਿਵੇਂ ਪੂਰਾ ਕਰਦੇ ਹਨ
Lucene ਅਤੇ Hadoop ਵੱਖ-ਵੱਖ ਸਮੱਸਿਆਵਾਂ ਹੱਲ ਕਰਦੇ ਹਨ, ਜੋ ਉਨ੍ਹਾਂ ਨੂੰ ਇੱਕੱਠੇ ਬਹੁਤ ਹੀ ਸੁਟਦੇ ਬਣਾਉਂਦਾ ਹੈ।
ਸਾਫ਼ ਭੂਮਿਕਾਵਾਂ: ਇੰਡੈਕਸ ਬਨਾਮ ਸਟੋਰ/ਪ੍ਰੋਸੈਸ
Lucene ਤੇਜ਼ ਰੀਟਰੀਵਲ ਬਾਰੇ ਹੈ: ਇਹ ਇੱਕ ਇੰਡੈਕਸ ਬਣਾਉਂਦਾ ਹੈ ਤਾਂ ਜੋ ਤੁਸੀਂ ਟੈਕਸਟ ਅਤੇ ਸੰਰਚਿਤ ਫੀਲਡਾਂ ਨੂੰ ਤੇਜ਼ੀ ਨਾਲ ਖੋਜ ਸਕੋ (ਸੋਚੋ “ਇਸ ਕਵੇਰੀ ਲਈ 200 ਸਭ ਤੋਂ ਪ੍ਰਸੰਗਿਕ ਘਟਨਾਵਾਂ ਹੁਣੇ ਦਿਖਾਓ”)।
Hadoop ਵੱਡੀਆਂ ਫਾਈਲਾਂ ਨਾਲ ਕੰਮ ਕਰਨ ਬਾਰੇ ਹੈ: ਇਹ ਉਨ੍ਹਾਂ ਨੂੰ ਵਿਸ਼ਵਾਸਯੋਗ ਤਰੀਕੇ ਨਾਲ HDFS ਵਿੱਚ ਸਟੋਰ ਕਰਦਾ ਹੈ ਅਤੇ ਸਮਕਾਲੀ ਤੌਰ 'ਤੇ ਪ੍ਰੋਸੈਸ ਕਰਦਾ ਹੈ (ਇਤਿਹਾਸਕ ਤੌਰ 'ਤੇ MapReduce) ਤਾਂ ਜੋ ਤੁਸੀਂ ਉਹਨਾਂ ਨੂੰ ਤਬਦੀਲ, ਏਗਰੀਗੇਟ ਅਤੇ ਰਿਚ-ਕਰ ਸਕੋ ਜੋ ਇਕ ਸਰਵਰ ਲਈ ਬਹੁਤ ਵੱਡੇ ਹੋ।
ਸਧਾਰਨ ਤੌਰ 'ਤੇ: Hadoop ਡੇਟਾ ਤਿਆਰ ਅਤੇ ਕ੍ਰੰਚ ਕਰਦਾ ਹੈ; Lucene ਨਤੀਜਿਆਂ ਨੂੰ ਖੋਜਯੋਗ ਬਣਾਉਂਦਾ ਹੈ।
ਇੱਕ ਪ੍ਰਯੋਗਿਕ ਉਦਾ-ਹਰਨ ਪਾਈਪਲਾਈਨ
ਕਲਪਨਾ ਕਰੋ ਤੁਹਾਡੇ ਕੋਲ ਮਹੀਨੇ ਭਰ ਦੇ ਕੱਚੇ ਐਪਲੀਕੇਸ਼ਨ ਲੌਗ ਹਨ।
- HDFS ਵਿੱਚ ਇੰਗੇਸਟ ਕਰੋ: ਕੰਪ੍ਰੈੱਸਡ ਲੌਗ ਫਾਇਲਾਂ HDFS ਵਿੱਚ ਸਟੋਰ ਕਰੋ।
- Hadoop ਵਿੱਚ ਪ੍ਰੋਸੈਸ ਕਰੋ: ਜੌਬ ਚਲਾਓ ਜੋ ਲਾਈਨਾਂ ਨੂੰ ਪਾਰਸ ਕਰਦੇ, ਖਰਾਬ ਰਿਕਾਰਡ ਸੁੱਧਦੇ, ਫੀਲਡ ਕਢਦੇ (ਯੂਜ਼ਰ ID, ਐਂਡਪੋਇੰਟ, ਲੇਟੈਂਸੀ), ਅਤੇ ਰੋਜ਼ਾਨਾ ਏਗਰੀਗੇਟ ਗਣਨਾ ਕਰਦੇ।
- “ਖੋਜ-ਤਿਆਰ” ਡੇਟਾਸੇਟ ਐਕਸਪੋਰਟ ਕਰੋ: ਸੁਧਰੇ ਆਉਟਪੁੱਟ (ਜਿਵੇਂ JSON ਰਿਕਾਰਡ) ਐਸੇ ਸਥਾਨ ਵਿੱਚ ਲਿਖੋ ਜਿਸਨੂੰ ਤੁਹਾਡਾ ਇੰਡੈਕਸ ਕਰਨ ਵਾਲਾ ਜੌਬ ਪੜ੍ਹ ਸਕੇ।
- Lucene ਨਾਲ ਇੰਡੈਕਸ ਕਰੋ (ਜਾਂ Lucene-ਆਧਾਰਿਤ ਸਿਸਟਮ): ਮੁੱਖ ਫੀਲਡਾਂ ਅਤੇ ਟੈਕਸਟ 'ਤੇ ਇੰਡੈਕਸ ਬਣਾਓ ਤਾਂ ਕਿ ਵਿਸ਼ਲੇਸ਼ਕ ਐਰਰ ਸੁਨੇਹਿਆਂ ਨੂੰ ਖੋਜ ਸੱਕਣ, ਸਰਵਿਸ ਦੁਆਰਾ ਫਿਲਟਰ ਕਰ ਸਕਣ, ਅਤੇ ਸਮੇਂ ਅਨੁਸਾਰ ਸੌਰਟ ਕਰ ਸਕਣ।
ਹੁਣ ਤੁਹਾਨੂੰ ਦੋਹਾਂ ਦਾ ਵਧੀਆ ਮਿਲਾਪ ਮਿਲਦਾ ਹੈ: ਵੱਡੇ ਕੱਚੇ ਡੇਟਾ 'ਤੇ ਭਾਰੀ-ਡਿਾਨ ਬੈਚ ਪ੍ਰੋਸੈਸਿੰਗ, ਨਾਲ ਹੀ ਇੰਟਰਐਕਟिव ਖੋਜ ਜਾਂਚ ਲਈ Lucene।
ਕਿਉਂ ਇਹ ਜੋੜ ਸ਼ਕਤੀਸ਼ਾਲੀ ਸੀ
ਐਨਾਲਿਟਿਕਸ ਅਕਸਰ “ਕُل ਕੀ ਹੋਇਆ?” ਦਾ ਜਵਾਬ ਦਿੰਦੀ ਹੈ, ਜਦੋਂ ਕਿ ਖੋਜ ਮਦਦ ਕਰਦੀ ਹੈ “ਮੈਨੂੰ ਵਿਸ਼ੇਸ਼ ਸਬੂਤ ਦਿਖਾਓ”। Hadoop ਨੇ ਵੱਡੇ ਇਨਪੁੱਟ ਤੋਂ ਨਿਕਲੇ ਡੇਰੀਵਡ ਡੇਟਾਸੇਟ ਨੂੰ ਗਣਨਾ ਕਰਨਯੋਗ ਬਣਾਇਆ; Lucene ਨੇ ਉਹਨਾਂ ਡੇਟਾਸੇਟਸ ਨੂੰ ਖੋਜਯੋਗ ਬਣਾਇਆ—ਫਾਇਲਾਂ ਦੇ ਢੇਰ ਨੂੰ ਕੁਝ ਇਸੇ ਤਰ੍ਹਾਂ ਤਬਦੀਲ ਕਰ ਦਿੱਤਾ ਕਿ ਲੋਕ ਅਸਲ ਵਿੱਚ ਉਹਨਾਂ ਨੂੰ ਨੇਵੀਗੇਟ ਕਰ ਸਕਣ।
ਜੋੜ ਨੂੰ ਜਬਰਦਸਤ ਬਣਾਣ ਦੀ ਲੋੜ ਨਹੀਂ
ਇਹ ਜੋੜ ਲਾਜ਼ਮੀ ਨਹੀਂ ਹੈ। ਜੇ ਤੁਸੀਂ ਡੇਟਾ ਨੂੰ ਇਕ ਸਰਵਰ ਵਿੱਚ ਆਸਾਨੀ ਨਾਲ ਫਿੱਟ ਕਰ ਸਕਦੇ ਹੋ, ਜਾਂ ਮੈਨੇਜਡ ਖੋਜ ਅਤੇ ਮੈਨੇਜਡ ਐਨਾਲਿਟਿਕਸ ਤੁਹਾਡੇ ਲੋੜਾਂ ਨੂੰ ਪਹਿਲਾਂ ਹੀ ਪੂਰਾ ਕਰ ਰਹੇ ਹਨ, ਤਾਂ Hadoop + Lucene ਨੂੰ ਇਕ-ਦੂਜੇ ਨਾਲ ਵਾਇਰਿੰਗ ਕਰਨਾ ਓਪਰੇਸ਼ਨਲ ਔਬਰਹੈੱਡ ਵਧਾ ਸਕਦਾ ਹੈ। ਜੋੜ ਇਸ ਵੇਲੇ ਵਰਤੋ ਜਦ ਤੁਹਾਨੂੰ ਦੋਹਾਂ ਦੀ ਸੱਚਮੁਚ ਲੋੜ ਹੋਵੇ: ਵੱਡੇ ਪੈਮਾਨੇ ਦੀ ਪ੍ਰੋਸੈਸਿੰਗ ਅਤੇ ਤੇਜ਼, ਲਚਕੀਲੀ ਖੋਜ।
Hadoop ਦਾ ਡੇਟਾ ਪਲੇਟਫਾਰਮਾਂ 'ਤੇ ਝਰਨਾ ਪ੍ਰਭਾਵ
Hadoop ਸਿਰਫ਼ ਵੱਡੀਆਂ ਫਾਇਲਾਂ ਨੂੰ ਪ੍ਰੋਸੈਸ ਕਰਨ ਦਾ ਨਵਾਂ ਤਰੀਕਾ ਨਹੀਂ ਦਿੱਤਾ; ਇਸਨੇ ਕਈ ਸੰਗਠਨਾਂ ਨੂੰ ਇੱਕ ਸਾਂਝੇ ਡੇਟਾ ਪਲੇਟਫਾਰਮ ਦੀ ਸੋਚ ਵੱਲ ਮੋੜ ਦਿੱਤਾ। ਹਰ ਵਾਰੀ ਹਰ ਵਿਸ਼ਲੇਸ਼ਣ ਪ੍ਰਾਜੈਕਟ ਲਈ ਵੱਖਰਾ ਸਿਸਟਮ ਬਣਾਉਣ ਦੀ ਥਾਂ, ਟੀਮਾਂ ਇੱਕ ਵਾਰ ਕੱਚਾ ਡੇਟਾ ਲੈਂਡ ਕਰ ਸਕਦੀਆਂ ਸਨ, ਉਹਨੂੰ ਸਸਤੇ ਤਰੀਕੇ ਨਾਲ ਰੱਖ ਸਕਦੀਆਂ ਸਨ, ਅਤੇ ਵੱਖ-ਵੱਖ ਗਰੁੱਪ ਵੱਖ-ਵੱਖ ਸਵਾਲਾਂ ਲਈ ਦੁਬਾਰਾ ਵਰਤ ਸਕਦੇ ਸਨ।
“ਇਕ-ਬਾਰ-ਲੈੱਡ” ਪਾਈਪਲਾਈਨਾਂ ਤੋਂ ਸਾਂਝੇ ਬੁਨਿਆਦ ਤੱਕ
ਜਿਵੇਂ HDFS-ਸਟਾਈਲ ਸਟੋਰੇਜ ਅਤੇ ਬੈਚ ਪ੍ਰੋਸੈਸਿੰਗ ਜਾਣ ਪਛਾਣ ਹੋਏ, ਇੱਕ ਪੈਟਰਨ ਉਭਰਿਆ: ਡੇਟਾ ਕੇਂਦਰੀ ਬਣਾਇਆ ਜਾਵੇ, ਫਿਰ ਉਸ 'ਤੇ ਪੇਰ ਲਾਏ ਜਾਣ। ਉਸ ਬਦਲਾਅ ਨੇ ਸਪਸ਼ਟ ਵੱਖਰਾ ਕੀਤਾ:
- ਸਟੋਰੇਜ (ਟਿਕਾਊ, ਸਾਂਝਾ, ਸਕੇਲਯੋਗ)
- ਕੰਪਿਊਟ (ਜੌਬ ਜੋ ਸ਼ੈਡਿਊਲ ਅਤੇ ਦੁਹਰਾਏ ਜਾ ਸਕਦੇ ਹਨ)
- ਐਕਸੈਸ (ਵੱਖ-ਵੱਖ ਯੂਜ਼ਰਾਂ ਲਈ ਵੱਖ-ਵੱਖ ਟੂਲ)
ਇਹ ਇੱਕ ਤਕਨੀਕੀ ਬਦਲਾਅ ਨਾਲੋਂ ਜ਼ਿਆਦਾ ਧਾਰਣਾਤਮਕ ਬਦਲਾਅ ਸੀ। ਇਸਨੇ ਉਮੀਦਾਂ ਸੈਟ ਕੀਤੀਆਂ ਕਿ ਡੇਟਾ ਇਨਫਰਾਸਟ੍ਰਕਚਰ ਦੁਬਾਰਾ ਵਰਤਣਯੋਗ, ਗਵਰਨਡ ਅਤੇ ਟੀਮਾਂ ਲਈ ਪਹੁੰਚਯੋਗ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ।
ਪਰਿਸਰ ਵਾਧਾ: SQL, ਸ਼ੈਡਿਊਲਿੰਗ ਅਤੇ ਇੰਜੇਸਟ
ਕਮਿਊਨਿਟੀ ਗਤੀਸ਼ੀਲ ਹੋ ਗਈ: ਲੋਕਾਂ ਨੇ ਡੇਟਾ ਨੂੰ ਆਸਾਨ ਤਰੀਕੇ ਨਾਲ ਕਵੇਰੀ ਕਰਨ, ਇਸਨੂੰ ਭਰੋਸੇਯੋਗ ਤਰੀਕੇ ਨਾਲ ਲਿਆਉਣ, ਅਤੇ ਰਿਕਰਿੰਗ ਵਰਕਫਲੋ ਚਲਾਉਣ ਦੀ ਚਾਹ ਰੱਖੀ। ਉੱਚ-ਪੱਧਰੀ ਤੌਰ 'ਤੇ, ਇਸ ਨਾਲ ਉਤਪੱਤੀ ਹੋਈ:
- SQL-on-Hadoop-ਸਟਾਈਲ ਕੁਐਰੀング, ਤਾਂ ਜੋ ਵਿਸ਼ਲੇਸ਼ਕ ਜਾਣੇਪਛਾਣੇ ਭਾਸ਼ਾ ਵਰਤ ਸਕਣ ਬਜਾਏ ਕਿ ਰੀਝ-ਕਸਟਮ ਪ੍ਰੋਗਰਾਮ ਲਿੱਕਣ
- ਸ਼ੈਡਿਊਲਿੰਗ ਅਤੇ ਵਰਕਫਲੋ ਓਰਕੇਸਟਰਸ਼ਨ, ਤਾਂ ਜੋ ਐਡ-ਹਾਕ ਸਕ੍ਰਿਪਟਜ਼ ਨੂੰ ਪ੍ਰਬੰਧਤ, ਦੁਹਰਾਏ ਜਾਣਯੋਗ ਪਾਈਪਲਾਈਨਾਂ ਬਣਾਇਆ ਜਾ ਸਕੇ
- ਇੰਜੇਸਟ ਟੂਲਜ਼, ਤਾਂ ਕਿ ਲੌਗ, ਈਵੇਂਟ ਅਤੇ ਡੇਟਾਬੇਸ ਨਿਕਾਸੀਆਂ ਨੂੰ ਘੱਟ ਮਨੂਅਲ ਗਲੂ ਨਾਲ ਸਾਂਝੇ ਸਟੋਰੇਜ ਵਿੱਚ ਲਿਆਂਦਾ ਜਾ ਸਕੇ
ਕਿਉਂ ਮਿਆਰਾਂ (ਸਟੈਂਡਰਡ) ਮਹੱਤਵਪੂਰਨ ਹੋਏ
ਜਦ ਹੋਰ-ਹੋਰ ਟੂਲ ਉਸੇ ਪਲੇਟਫਾਰਮ ਵਿਚ ਜੋੜੇ ਗਏ, ਮਿਆਰਾਂ glue ਬਣ ਗਈਆਂ। ਆਮ ਫਾਇਲ ਫਾਰਮੈਟ ਅਤੇ ਸਾਂਝੇ ਸਟੋਰੇਜ ਪੈਟਰਨ ਡੇਟਾ ਨੂੰ ਵੱਖ-ਵੱਖ ਇੰਜਨਾਂ ਅਤੇ ਟੀਮਾਂ ਵਿਚ ਅਦਲਾ-ਬਦਲੀ ਕਰਨ ਵਿੱਚ ਆਸਾਨ ਬਣਾਉਂਦੇ ਸਨ। ਹਰ ਪਾਈਪਲਾਈਨ ਨੂੰ ਹਰ ਇਕ ਟੂਲ ਲਈ ਦੁਬਾਰਾ ਲਿਖਣ ਦੀ ਬਜਾਏ, ਸੰਗਠਨਾਂ ਕੁਝ “ਡਿਫਾਲਟ” ਫਾਰਮੈਟ ਅਤੇ ਡਾਇਰੈਕਟਰੀ ਰਿਵਾਜਾਂ 'ਤੇ ਸਹਿਮਤ ਹੋ ਗਈਆਂ—ਅਤੇ ਪਲੇਟਫਾਰਮ ਆਪਣੇ ਹਿੱਸਿਆਂ ਨਾਲੋਂ ਵੱਧ ਬਣ ਗਿਆ।
Hadoop ਦੇ ਚਰਮ-ਕਾਲ ਤੋਂ ਬਾਅਦ ਕੀ ਬਦਲਿਆ
ਆਪਣੇ ਡੋਮੇਨ ਨਾਲ ਲਾਂਚ ਕਰੋ
ਜਦੋਂ ਇਹ ਵਿਆਪਕ ਵਰਤੋਂ ਲਈ ਤਿਆਰ ਹੋਵੇ ਤਾਂ ਆਪਣੇ ਅੰਦਰੂਨੀ ਟੂਲ ਨੂੰ ਇਕ ਕਸਟਮ ਡੋਮੇਨ 'ਤੇ ਰੱਖੋ।
Hadoop ਦੇ ਚਰਮ-ਸਾਲ ਉਹ ਸਨ ਜਦ ਵੱਡੇ, ਬੈਚ-ਓਰੀਏਂਟਡ ਜੌਬਸ ਪ੍ਰਚਲਿਤ ਸਨ: ਡੇਟਾ HDFS ਵਿੱਚ ਕਾਪੀ ਕਰੋ, ਰਾਤ ਨੂੰ MapReduce ਚਲਾਓ, ਫਿਰ ਨਤੀਜੇ ਪ੍ਰਕਾਸ਼ਿਤ ਕਰੋ। ਉਹ ਮਾਡਲ ਖਤਮ ਨਹੀਂ ਹੋਇਆ, ਪਰ ਜਦ ਉਮੀਦਾਂ “ਹੁਣ ਜਵਾਬ” ਅਤੇ “ਲਗਾਤਾਰ ਅੱਪਡੇਟ” ਵੱਲ ਮੁੜੀਆਂ ਤਾਂ ਇਹ ਡੀਫਾਲਟ ਨਹੀਂ ਰਹਿਣਾ ਲੱਗਾ।
ਹੋਰ ਸਟ੍ਰੀਮਿੰਗ, ਤੇਜ਼-ਇੰਜਨਾਂ ਅਤੇ ਕਲਾਊਡ ਸਟੋਰੇਜ
ਟੀਮਾਂ ਨੇ ਖਾਲੀ ਬੈਚ ਤੋਂ ਸਟ੍ਰੀਮਿੰਗ ਅਤੇ ਨਿਯਰ-ਰੀਅਲ-ਟਾਈਮ ਪਾਈਪਲਾਈਨਾਂ ਵੱਲ ਮੋੜਿਆ। ਰੋਜ਼ਾਨਾ MapReduce ਚਲਾਉਣ ਦੀ ਥਾਂ, ਸਿਸਟਮ ਘਟਨਾਵਾਂ ਆਉਂਦੀਆਂ ਹੀ ਪ੍ਰੋਸੈਸ ਕਰਨ ਲੱਗੇ ਅਤੇ ਡੈਸ਼ਬੋਰਡ ਜਾਂ ਅਲਰਟ ਤੁਰੰਤ ਅੱਪਡੇਟ ਹੋਣ ਲੱਗੇ।
ਇਸੇ ਸਮੇਂ, ਨਵੇਂ ਕੰਪਿਊਟ ਇੰਜਨਾਂ ਨੇ ਇੰਟਰਐਕਟਿਵ ਵਿਸ਼ਲੇਸ਼ਣ ਨੂੰ ਅਸਾਨ ਬਣਾਇਆ। ਇਨ-ਮੇਮੋਰੀ ਪ੍ਰੋਸੈਸਿੰਗ ਅਤੇ ਅਪਟਿਮਾਈਜ਼ਡ ਕੁਐਰੀ ਐਗਜ਼ੀਕਿਨ ਵਾਲੇ ਫਰੇਮਵਰਕ ਆਮ ਤੌਰ 'ਤੇ ਕਈ ਰਣਨੀਤੀਆਂ ਵਿੱਚ ਪਰੰਪਰਾਗਤ MapReduce ਨੂੰ ਹਰਾ ਦਿੰਦੇ ਸਨ—ਖਾਸ ਕਰਕੇ ਇਤਰੈਟਿਵ ਕੰਮ, ਐਕਸਪਲੋਰੇਟਰੀ ਐਨਾਲਿਟਿਕਸ, ਅਤੇ SQL-ਸਟਾਈਲ ਕੁਐਰੀਆਂ ਲਈ।
ਸਟੋਰੇਜ ਵੀ ਬਦਲਿਆ। ਬਹੁਤ ਸਾਰੀਆਂ ਸੰਸਥਾਵਾਂ ਨੇ “HDFS ਕੇਂਦਰ ਤੋਂ ਬਦਲ ਕੇ” ਕਲਾਊਡ ਆਬਜੈਕਟ ਸਟੋਰੇਜ ਨੂੰ ਇੱਕ ਸਸਤਾ, ਸਧਾਰਨ ਸਾਂਝਾ ਡੇਟਾ ਲੇਅਰ ਦੇ ਰੂਪ ਵਿੱਚ ਵਰਤਣਾ ਸ਼ੁਰੂ ਕੀਤਾ। ਕੰਪਿਊਟ ਹੋਰ ਵੱਧ ਡਿਸਪੋਜ਼ਬਲ ਹੋ ਗਿਆ: ਜਦ ਲੋੜ ਹੋਵੇ ਉਸਨੂੰ ਚਲਾ ਕੇ, ਕੰਮ ਮੁਕੰਮਲ ਹੋਣ 'ਤੇ ਬੰਦ ਕਰ ਦਿੰਦੇ।
Hadoop ਦੀ ਵਿਰਾਸਤ: ਉਹ ਫੈਸਲੇ ਜੋ ਰਹਿ ਗਏ
ਕੁਝ Hadoop-ਨਾਮੀ ਘਟਕ ਘਟ ਗਏ, ਪਰ ਵਿਚਾਰ ਸਾਰਿਆਂ ਜਗ੍ਹਾਂ ਫੈਲ ਗਏ: ਵੰਡਿਆ ਸਟੋਰੇਜ, ਕੰਪਿਊਟ ਨੂੰ ਡੇਟਾ ਕੋਲ ਲਿਜਾਣਾ, ਕਾਮੋਡੀਟੀ ਹਾਰਡਵੇਅਰ 'ਤੇ ਫੋਲਟ ਟੋਲਰੈਂਸ, ਅਤੇ ਸਾਂਝਾ “ਡੇਟਾ ਲੇਕ” ਮਨੋਭਾਵ। ਯਾਦ ਰੱਖੋ ਕਿ ਜੰਤਰ-ਟੂਲ ਭਿੰਨ ਹੋ ਸਕਦੇ ਹਨ, ਪਰ ਆਰਕੀਟੈਕਚਰ ਪੈਟਰਨ ਆਮ ਹੋ ਗਏ।
ਕਿਉਂ Lucene ਅਜੇ ਵੀ ਮਹੱਤਵਪੂਰਨ ਹੈ
Lucene ਨੂੰ ਉਹਨਾਂ ਚਰਮ-ਅਰੰਭੀ ਸਾਈਕਲਾਂ ਵਾਲੀ ਗਿਰਾਵਟ ਨਹੀਂ ਮਿਲੀ ਕਿਉਂਕਿ ਇਹ ਇੱਕ ਕੋਰ ਲਾਇਬ੍ਰੇਰੀ ਹੈ ਜੋ ਆਧੁਨਿਕ ਖੋਜ ਸਟੈਕਾਂ ਵਿੱਚ ਏਂਬੇਡ ਕੀਤੀ ਜਾਂਦੀ ਹੈ। Elasticsearch, Solr, ਅਤੇ ਹੋਰ ਖੋਜ ਹੱਲ ਅਜੇ ਵੀ Lucene 'ਤੇ ਨਿਰਭਰ ਕਰਦੀਆਂ ਹਨ—ਇੰਡੈਕਸਿੰਗ, ਸਕੋਰਿੰਗ, ਅਤੇ ਕੁਐਰੀ ਪਾਰਸਿੰਗ ਜਿਹੜੇ ਖੋਜ, ਨਿਗਰਾਨੀ ਅਤੇ ਉਤਪਾਦ ਖੋਜ ਲਈ ਕੇਂਦਰੀ ਹਨ।
ਇੱਕ ਸੰਤੁਲਿਤ ਰਾਇਆ
Hadoop ਇੱਕ ਬੰਨ੍ਹੇ ਹੋਏ ਪਲੇਟਫਾਰਮ ਵਜੋਂ ਘੱਟ ਆਮ ਹੋ ਗਿਆ ਹੈ, ਪਰ ਇਸ ਦੀਆਂ ਬੁਨਿਆਦੀਆਂ ਨੇ ਆਧੁਨਿਕ ਡੇਟਾ ਇੰਜੀਨੀਅਰਿੰਗ ਨੂੰ ਰੂਪ ਦਿੱਤਾ। Lucene, ਇਸਦਰਮਿਆਨ, ਖੋਜ-ਭਾਰੇ ਐਪਲੀਕੇਸ਼ਨਾਂ ਨੂੰ ਸ਼ਕਤੀ ਪ੍ਰਦਾਨ ਕਰਦਾ ਰਹਿੰਦਾ ਹੈ, ਭਾਵੇਂ ਉਹ ਨਵੇਂ ਸਰਵਿਸਜ਼ ਅਤੇ APIs ਵਿੱਚ ਲਪੇਟਿਆ ਗਿਆ ਹੋਵੇ।
ਆਧੁਨਿਕ ਟੀਮਾਂ ਲਈ ਪ੍ਰਯੋਗਿਕ ਨਤੀਜੇ
ਤੁਹਾਨੂੰ “ਬਿਗ ਡੇਟਾ” ਸਿਸਟਮ ਨਹੀਂ ਬਣਾਉਣ ਦੀ ਲੋੜ ਹੈ ਤਾ ਕਿ Lucene ਅਤੇ Hadoop ਦੇ ਵਿਚਾਰਾਂ ਤੋਂ ਫਾਇਦਾ ਹੋ ਸਕੇ। ਲਿਆਣਯੋਗ ਹਿੱਸਾ ਇਹ ਜਾਣਨਾ ਹੈ ਕਿ ਤੁਸੀਂ ਕਿਹੜੀ ਸਮੱਸਿਆ ਹੱਲ ਕਰ ਰਹੇ ਹੋ: ਚੀਜ਼ਾਂ ਨੂੰ ਤੇਜ਼ੀ ਨਾਲ ਲੱਭਣਾ (ਖੋਜ) ਜਾਂ ਜ਼ਿਆਦਾ ਡੇਟਾ ਪ੍ਰਭਾਵਸ਼ਾਲੀ ਤਰੀਕੇ ਨਾਲ ਪ੍ਰੋਸੈਸ ਕਰਨਾ (ਬੈਚ/ਵੰਡਿਆ ਕੰਪਿਊਟ)।
ਇਕ ਸਧਾਰਣ ਫੈਸਲਾ ਗਾਈਡ
ਜੇ ਯੂਜ਼ਰ (ਜਾਂ ਅੰਦਰੂਨੀ ਟੂਲ) ਨੂੰ ਕਵੇਰੀ ਟਾਈਪ ਕਰਨੀ ਹੈ ਅਤੇ ਸਬੰਧਿਤ ਨਤੀਆਂ ਤੁਰੰਤ ਮਿਲਣੀ ਚਾਹੀਦੀ ਹੋਵੇ—ਕੀਵਰਡਸ, ਫਰੇਜ਼, ਫਿਲਟਰ, ਅਤੇ ਰੈਂਕਿੰਗ ਨਾਲ—ਤੁਸੀਂ search indexing ਖੇਤਰ ਵਿੱਚ ਹੋ। ਇੱਥੇ Lucene-ਸਟਾਈਲ ਇੰਡੈਕਸਿੰਗ ਚਮਕਦਾ ਹੈ।
ਜੇ ਤੁਹਾਡਾ ਮਕਸਦ ਵੱਡੇ ਪੈਮਾਨੇ ਦਾ ਡੇਟਾ ਕਰੰਚ ਕਰਨਾ ਹੈ ਤਾਂ ਕਿ ਤੁਸੀਂ ਏਗਰੀਗੇਟਸ, ਫੀਚਰ, ਐਕਸਪੋਰਟ, ਰਿਪੋਰਟ ਉਤਪੰਨ ਕਰੋ—ਅਕਸਰ ਸ਼ੈਡਿਊਲ 'ਤੇ—ਤਾਂ ਤੁਸੀਂ batch processing ਖੇਤਰ ਵਿੱਚ ਹੋ। ਇਹ ਉਹ ਸਮੱਸਿਆ ਹੈ ਜਿਨ੍ਹਾਂ ਨੂੰ Hadoop ਸਨਹਿਲ ਕੀਤਾ।
ਇੱਕ ਛੋਟੀ ਸਹਾਇਕ ਨੁਸਖਾ:
- ਇੰਟਰਐਕਟਿਵ ਕਵੇਰੀ ਸਪੀਡ, relevance ਸਕੋਰਿੰਗ, ਫੇਸਟੀਡ, ਹਾਈਲਾਈਟਿੰਗ, ਅਤੇ “ਖੋਜ ਅਨੁਭਵ” ਜੇ ਤੁਹਾਡੀ ਲੋੜ ਹੈ ਤਾਂ search indexing ਚੁਣੋ।
- ਜੇ throughput, ਬੜੇ ਡੇਟਾਸੇਟਾਂ ਦਾ ਐਂਡ-ਟੂ-ਐਂਡ ਸਕੈਨ, ਅਤੇ ਨਵੇਂ ਡੇਟਾ/ਸੰਖੇਪ ਬਣਾਉਣਾ ਮੁੱਖ ਹੈ, ਤਾਂ batch processing ਚੁਣੋ।
ਟੀਮਾਂ ਨੂੰ ਗਲਤ ਮੋੜ ਤੋਂ ਬਚਾਉਣ ਲਈ ਮੁਲਾਂਕਣ ਪ੍ਰਸ਼ਨ
ਟੂਲ ਚੁਣਨ (ਜਾਂ ਖਰੀਦਣ) ਤੋਂ ਪਹਿਲਾਂ ਆਪਣੀਆਂ ਲੋੜਾਂ ਨੂੰ ਟੈਸਟ ਕਰੋ:\n
- ਲੈਟੈਂਸੀ: ਨਤੀਜੇ ਮਿਲੀਸੈਕਿੰਡਾਂ ਵਿੱਚ ਚਾਹੀਦੇ ਹਨ (ਖੋਜ) ਜਾਂ ਮਿੰਟ/ਘੰਟੇ ਠੀਕ ਹਨ (ਬੈਚ)?\n- ਡੇਟਾ ਆਕਾਰ ਅਤੇ ਵਾਧਾ: ਤੁਸੀਂ ਦਸ ਹਜ਼ਾਰ, ਮਿਲੀਅਨ, ਜਾਂ ਅਰਬਾਂ ਰਿਕਾਰਡਾਂ ਦੀ ਇੰਡੈਕਸਿੰਗ ਕਰ ਰਹੇ ਹੋ? ਇਹ ਕਿੰਨੀ ਤੇਜ਼ੀ ਨਾਲ ਵਧਦਾ ਹੈ?\n- ਅੱਪਡੇਟ ਪੈਟਰਨ: ਜ਼ਿਆਦਾਤਰ ਰੀਡ ਹਨ, ਜਾਂ ਲਗਾਤਾਰ ਅਪਡੇਟਸ ਅਤੇ ਡਿਲੀਟਸ ਹਨ? ਕੀ ਜੀਵੰਤ-ਨਜ਼ਦੀਕੀ ਤਾਜ਼ਗੀ ਦੀ ਲੋੜ ਹੈ?\n- ਕੁਐਰੀ ਆਕਾਰ-ਰੂਪ: ਖੁੱਲਾ-ਪਾਠਿ(ਫ੍ਰੀ-ਟੈਕਸਟ) ਸਿਨੋਨਿਮਜ਼ ਨਾਲ, ਜਾਂ SQL-ਸਟਾਈਲ ਐਗਰੀਗੇਸ਼ਨ ਅਤੇ ਜੋਇਨਾਂ?\n- ਟੀਮ ਸਕਿਲਜ਼: ਕੀ ਤੁਹਾਡੇ ਕੋਲ ਉਹ ਲੋਕ ਹਨ ਜੋ ਕਲੱਸਟਰ ਚਲਾਉਣ, ਸਟੋਰੇਜ ਟਿਊਨ ਕਰਨ ਅਤੇ ਫੇਲਿਅਰਾਂ ਨੂੰ ਠੀਕ ਕਰਨ ਵਿੱਚ ਸਹਿਯੋਗੀ ਹਨ?\n- ਓਪਸ ਲੋਡ: ਰਾਤ 2 ਵਜੇ ਜਦ ਇਕ ਨੋਡ ਡਾਊਨ ਹੋ ਜਾਏ—ਕੌਣ ਠੀਕ ਕਰਦਾ ਹੈ, ਅਤੇ ਕਿੰਨੀ ਤੇਜ਼ੀ ਨਾਲ?
ਜੇ ਤੁਸੀਂ ਵਿਕਲਪਾਂ ਦੀ ਜਾਂਚ ਕਰ ਰਹੇ ਹੋ, ਆਪਣੇ ਲੋੜਾਂ ਨੂੰ ਆਮ ਪੈਟਰਨਾਂ ਅਤੇ ਟਰੇਡ-ਆਫ ਨਾਲ ਮਿਲਾਉਣਾ ਮਦਦਗਾਰ ਹੁੰਦਾ ਹੈ; /blog ਦੇ ਲੇਖਾਂ ਨੂੰ ਦੇਖਣਾ ਇੱਕ ਸੂਚੀਬੱਢ ਸਰਵੇਟਿੰਗ ਕਰ ਸਕਦਾ ਹੈ। ਜੇ ਤੁਸੀਂ ਮੈਨੇਜਡ ਵਰਨਾਮਾਂ ਅਤੇ ਸੈਲਫ-ਹੋਸਟਿਡ ਵਿਚਕਾਰ ਵਿਚਾਰ ਕਰ ਰਹੇ ਹੋ, ਤਾਂ /pricing ਨੂੰ ਦੇਖਣਾ ਅਕਸਰ ਓਪਰੇਸ਼ਨਲ ਜਿੰਮੇਵਾਰੀਆਂ ਨੂੰ ਸਮਝਾਉਂਦਾ ਹੈ ਜੋ ਕੱਚੇ ਫੀਚਰ-ਲਿਸਟ ਤੋਂ ਵਧ ਕੇ ਹੁੰਦੀਆਂ ਹਨ।
Koder.ai ਆਧੁਨਿਕ ਨਿਰਮਾਤਿਆਂ ਲਈ ਕਿੱਥੇ ਫਿੱਟ ਹੁੰਦਾ ਹੈ
Lucene/Hadoop ਯੁੱਗ ਤੋਂ ਇੱਕ ਕਾਰਗਰ ਸਬਕ ਇਹ ਹੈ ਕਿ ਟੀਮਾਂ ਜਿਨ੍ਹਾਂ ਇਹ “ਇੰਫਰਾਸਟ੍ਰਕਚਰ ਆਈਡੀਅਸ” ਨੂੰ ਕਾਮਯਾਬ ਪ੍ਰੋਡਕਟ ਵਿੱਚ ਬਦਲ ਸਕਦੀਆਂ ਹਨ, ਉਹ ਜਿੱਤਦੀਆਂ ਹਨ। ਜੇ ਤੁਸੀਂ ਇੱਕ ਅੰਦਰੂਨੀ ਲੌਗ ਏਕਸਪਲੋਰਰ, ਦਸਤਾਵੇਜ਼ ਖੋਜ ਐਪ, ਜਾਂ ਛੋਟਾ ਐਨਾਲਿਟਿਕਸ ਡੈਸ਼ਬੋਰਡ ਪ੍ਰੋਟੋਟਾਈਪ ਕਰ ਰਹੇ ਹੋ, ਤਾਂ Koder.ai ਵਰਗਾ ਇਕ vibe-coding ਪਲੇਟਫਾਰਮ ਤੁਹਾਨੂੰ ਉਚਿਤ ਅੰਤ-ਟੂ-ਅੰਤ ਐਪ ਤੇਜ਼ੀ ਨਾਲ ਲੈ ਕੇ ਜਾਣ ਵਿੱਚ ਮਦਦ ਕਰ ਸਕਦਾ ਹੈ: frontend 'ਤੇ React, Go backend ਨਾਲ PostgreSQL, ਅਤੇ ਇਕ ਇੰਟਰਫੇਸ ਜਿੱਥੇ ਤੁਸੀਂ ਚੈਟ ਰਾਹੀਂ ਇਟਰੈਟ ਕਰ ਸਕਦੇ ਹੋ।
ਇਹ ਖ਼ਾਸ ਕਰਕੇ ਉਸ ਵੇਲੇ ਲਾਭਦਾਇਕ ਹੁੰਦਾ ਹੈ ਜਦ ਤੁਸੀਂ ਅਜੇ ਵੀ ਲੋੜਾਂ ਨੂੰ ਵੈਰੀਫਾਈ ਕਰ ਰਹੇ ਹੋ (ਫੀਲਡਜ਼, ਫਿਲਟਰ, ਰੀਟੇਨਸ਼ਨ, ਅਤੇ UX)। Planning mode, snapshots, ਅਤੇ rollback ਵਰਗੀਆਂ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਸ਼ੁਰੂਆਤੀ ਪ੍ਰਯੋਗਨੂੰ ਘੱਟ ਖਤਰੇ ਵਾਲਾ ਬਣਾ ਦਿੰਦੀਆਂ ਹਨ—ਇਸ ਤੋਂ ਪਹਿਲਾਂ ਕਿ ਤੁਸੀਂ ਭਾਰੀ ਓਪਰੇਸ਼ਨਲ ਚੋਣਾਂ ਜਿਵੇਂ ਕਿ ਕਲੱਸਟਰ ਚਲਾਉਣਾ ਜਾਂ ਖੋਜ ਸਟੈਕ ਟਿਊਨ ਕਰਨਾ ਸ਼ੁਰੂ ਕਰੋ।
ਅਖ਼ੀਰੀ ਨਤੀਜਾ
Lucene ਅਤੇ Hadoop ਇਸ ਲਈ ਪ੍ਰਮੁੱਖ ਨਹੀਂ ਬਣੇ ਕਿ ਉਹ ਜਾਦੂਈ ਸਨ, ਪਰ ਕਿਉਂਕਿ ਉਨ੍ਹਾਂ ਨੇ ਦੁਹਰਾਏ ਜਾ ਸਕਣ ਵਾਲੇ ਪ੍ਰਮੁੱਖ ਘਟਕ—ਇੰਡੈਕਸਿੰਗ ਅਤੇ ਵੰਡਿਆ ਪ੍ਰੋਸੈਸਿੰਗ—ਨੂੰ ਐਸੇ ਬਿਲਡਿੰਗ ਬਲਾਕਾਂ ਦੇ ਰੂਪ ਵਿੱਚ ਪੇਸ਼ ਕੀਤਾ ਜੋ ਟੀਮਾਂ ਅਪਣਾ ਸਕਦੀਆਂ, ਵਧਾ ਸਕਦੀਆਂ, ਅਤੇ ਆਮਣ-ਸਾਮਣੇ ਸਾਂਝਾ ਕਰ ਸਕਦੀਆਂ।
ਅਕਸਰ ਪੁੱਛੇ ਜਾਣ ਵਾਲੇ ਸਵਾਲ
Lucene ਸਾਦੇ ਸ਼ਬਦਾਂ ਵਿੱਚ ਕਿਹੜਾ ਸਮੱਸਿਆ ਹੱਲ ਕਰਦਾ ਹੈ?
Lucene ਇੱਕ ਖੋਜ ਲਾਇਬ੍ਰੇਰੀ ਹੈ ਜੋ ਇੱਕ ਇੰਡੈਕਸ ਬਣਾਉਂਦੀ ਹੈ ਤਾਂ ਜੋ ਤੁਸੀਂ ਮਿਲਦੀਆਂ ਦਸਤਾਵੇਜ਼ਾਂ ਨੂੰ ਹਰ ਵਾਰ ਸਾਰਾ ਸਮੱਗਰੀ ਨਹੀਂ ਪੜ੍ਹ ਕੇ ਤੇਜ਼ੀ ਨਾਲ ਹਾਸਲ ਕਰ ਸਕੋ। ਇਹ ਉਤਪਾਦਾਂ ਵਿੱਚ ਲੋੜੀਂਦੇ ਪ੍ਰਯੋਗਿਕ ਹਿੱਸੇ ਵੀ ਦਿੰਦੀ ਹੈ: analyzers (ਪাঠ ਨੂੰ ਕਿਵੇਂ ਟੋਕਨ ਕੀਤਾ ਜਾਂਦਾ ਹੈ), query parsing, ਅਤੇ relevance scoring.
ਜੇ ਟੀਮ ਦੇ ਕੋਲ ਪਹਿਲਾਂ ਹੀ ਡੇਟਾਬੇਸ ਅਤੇ ਵੱਡੇ ਸਰਵਰ ਸਨ ਤਾਂ Hadoop ਦੀ ਲੋੜ ਕਿਉਂ ਸੀ?
Hadoop ਉਸ ਬਿੰਦੂ ਨੂੰ ਹੱਲ ਕਰਦਾ ਹੈ ਜਿੱਥੇ “ਵੱਡਾ ਸਰਵਰ ਖਰੀਦ ਲਓ” ਕੰਮ ਕਰਨਾ ਬੰਦ ਕਰ ਦੇਂਦਾ ਹੈ। ਇਹ ਤੁਹਾਨੂੰ ਕਈ ਮਸ਼ੀਨਾਂ 'ਤੇ ਵੱਡੇ ਡੇਟਾਸੇਟ ਸਟੋਰ ਕਰਨ ਅਤੇ ਉਨ੍ਹਾਂ 'ਤੇ ਸਮਾਂਤਰੀ ਬੈਚ ਪ੍ਰੋਸੈਸਿੰਗ ਚਲਾਉਣ ਦੀ ਆਗਿਆ ਦਿੰਦਾ ਹੈ, ਜਿਸ ਵਿੱਚ ਮਸ਼ੀਨੀ ਫੇਲਿਅਰਾਂ ਲਈ ਰੀਟ੍ਰਾਈਜ਼ ਅਤੇ ਰਿਡੰਡੈੰਸੀ ਦੀ ਬਣੀ-ਬਨਾਈ ਦੇਖਭਾਲ ਸ਼ਾਮਿਲ ਹੁੰਦੀ ਹੈ।
ਇੱਕ “ਇੰਡੈਕਸ” ਕੀ ਹੁੰਦਾ ਹੈ, ਅਤੇ ਇਹ ਖੋਜ ਨੂੰ ਤੇਜ਼ ਕਿਵੇਂ ਬਣਾਂਦਾ ਹੈ?
ਇੱਕ ਇੰਡੈਕਸ ਇੱਕ ਡੇਟਾ ਸਟਰੱਕਚਰ ਹੈ ਜੋ terms (ਜਾਂ ਹੋਰ ਟੋਕਨ) ਨੂੰ ਉਹਨਾਂ ਦਸਤਾਵੇਜ਼ਾਂ/ਫੀਲਡਾਂ ਨਾਲ ਜੋੜਦਾ ਹੈ ਜਿੱਥੇ ਉਹ ਨਜ਼ਰ ਆਉਂਦੇ ਹਨ—ਪਿੱਠੇ ਵਾਲੇ-ਕਿਤਾਬ ਦੇ ਇੰਡੈਕਸ ਵਾਂਗ।
ਵਿਆਹਕ ਤੌਰ 'ਤੇ: ਇੰਡੈਕਸਿੰਗ ਉਹ ਕੰਮ ਹੈ ਜੋ ਤੁਸੀਂ ਇੱਕ ਵਾਰੀ ਅੱਗੇ ਕਰਦੇ ਹੋ ਤਾਂ ਜੋ ਯੂਜ਼ਰ ਦੀਆਂ ਕਵੇਰੀਆਂ ਮਿੰਟਾਂ ਨਹੀਂ, ਮਿਲੀਸੈਕਿੰਡਾਂ ਵਿੱਚ ਨਤੀਜੇ ਦੇ ਸਕਣ।
“Relevance” ਦਾ ਕੀ ਮਤਲਬ ਹੈ, ਅਤੇ ਆਮ ਤੌਰ 'ਤੇ ਇਸ 'ਤੇ ਕੀ ਅਸਰ ਪੈਂਦਾ ਹੈ?
Relevance ਇਹ ਹੈ ਕਿ ਖੋਜ ਇੰਜਣ ਇਹ ਫੈਸਲਾ ਕਿਵੇਂ ਕਰਦਾ ਹੈ ਕਿ ਕਿਹੜੇ ਮਿਲਦੇ ਨਤੀਜੇ ਪਹਿਲਾਂ ਦਿਖਾਏ ਜਾਣ।
ਅਮੂਮਨ ਸੰਕੇਤਾਂ ਵਿੱਚ ਸ਼ਾਮਿਲ ਹਨ:
- ਕਿਸ ਹੱਦ ਤੱਕ ਇੱਕ ਟਰਮ ਆਉਂਦਾ ਹੈ
- ਇਹ ਕਿੱਥੇ ਆਉਂਦਾ ਹੈ (ਸਿਰਲੇਖ vs. ਬਾਡੀ)
- ਪੂਰੇ ਕਲੀਕਸ਼ਨ ਵਿੱਚ ਉਹ ਟਰਮ ਕਿੰਨਾ ਦੁਰਲਭ ਹੈ
ਜੇ ਤੁਸੀਂ ਉਤਪਾਦ ਖੋਜ ਬਣਾ ਰਹੇ ਹੋ, ਤਾਂ relevance ਟਿਊਨਿੰਗ (ਫੀਲਡ ਬੂਸਟ, analyzers, synonyms) ਲਈ ਸਮਾਂ ਰੱਖੋ—ਇਸ ਨੂੰ ਬਾਦ ਵਿੱਚ ਠੀਕ ਕਰਨ ਦੀ ਵਜਾਇ ਸ਼ੁਰੂ ਵਿੱਚ ਨਜ਼ਰਅੰਦਾਜ਼ ਨਾ ਕਰੋ।
HDFS ਵੱਡੀਆਂ ਫਾਇਲਾਂ ਨੂੰ ਭਰੋਸੇਯੋਗ ਢੰਗ ਨਾਲ ਕਿਵੇਂ ਸਟੋਰ ਕਰਦਾ ਹੈ?
HDFS (Hadoop Distributed File System) ਵੱਡੀਆਂ ਫਾਇਲਾਂ ਨੂੰ ਨਿਰਧਾਰਿਤ-ਆਕਾਰ ਦੇ ਬਲੌਕਾਂ ਵਿੱਚ ਵੰਡ ਕਰਦਾ ਹੈ ਅਤੇ ਉਨ੍ਹਾਂ ਨੂੰ ਕਲੱਸਟਰ ਵਿੱਚ ਵੱਖ-ਵੱਖ ਮਸ਼ੀਨਾਂ 'ਤੇ ਫੈਲਾਉਂਦਾ ਹੈ। ਇਹ ਵੀ ਹਰ ਬਲੌਕ ਦੀਆਂ ਕਾਪੀਆਂ ਵੱਖ-ਵੱਖ ਮਸ਼ੀਨਾਂ 'ਤੇ ਰੱਖਦਾ ਹੈ ਤਾਂ ਕਿ ਜੇ ਇਕ ਨੋਡ ਡਾਊਨ ਹੋ ਜਾਏ ਤਾਂ ਡੇਟਾ ਹੋਰ ਕਾਪੀ ਤੋਂ ਪਹੁੰਚਯੋਗ ਰਹੇ।
ਆਪਰੇਸ਼ਨ ਵਜੋਂ, ਤੁਸੀਂ ਇਸਨੂੰ ਇੱਕ ਫਾਇਲ ਸਿਸਟਮ ਵਾਂਗ ਵਰਤਦੇ ਹੋ, ਜਦ ਕਿ Hadoop ਪਿਛੋਕੜ 'ਚ ਪਲੇਸਮੈਂਟ ਅਤੇ ਰਿਡੰਡੈਂਸੀ ਨੂੰ ਦੇਖਦਾ ਹੈ।
MapReduce ਸਭ ਤੋਂ ਵਧੀਆ ਕਿਸ ਲਈ ਵਰਤਿਆ ਜਾਂਦਾ ਹੈ?
MapReduce ਇੱਕ ਬੈਚ ਪ੍ਰੋਗ੍ਰਾਮਿੰਗ ਮਾਡਲ ਹੈ ਜਿਸਦੇ ਦੋ ਚਰਨ ਹਨ:
- Map: ਸਥਾਨਕ ਡੇਟਾ ਚੰਕਸ ਨੂੰ ਪ੍ਰੋਸੈਸ ਕਰੋ ਅਤੇ ਅੰਤਰਿਮ key–value ਨਤੀਜੇ ਜਾਰੀ ਕਰੋ
- Reduce: ਕੁੰਜੀ ਵਾਰ ਗ੍ਰੂਪ ਕਰਕੇ ਅਖੀਰੀ ਨਤੀਜੇ ਬਣਾਓ
ਇਹ ਉਨ੍ਹਾਂ ਨੌਕਰੀਆਂ ਲਈ ਵਰਤੋ ਜਿੱਥੇ ਤੁਸੀਂ ਕੁੱਲ ਡੇਟਾ ਨੂੰ ਸਕੈਨ ਕਰਦੇ ਹੋ, ਸੰਖੇਪ ਬਣਾਉਂਦੇ ਹੋ ਅਤੇ ਨਤੀਜੇ ਲਿਖਦੇ ਹੋ—ਜਿਵੇਂ ਲੌਗ ਰੋਲਅਪ ਜਾਂ ਵੱਡੇ ਬੈਕਫਿਲਸ।
“ਕੰਪਿਊਟੇਸ਼ਨ ਨੂੰ ਡੇਟਾ ਕੋਲ ਲਿਜਾਣਾ” ਅਸਲ ਵਿੱਚ ਕੀ ਮਤਲਬ ਹੈ?
“ਡੇਟਾ ਵੱਲ ਕੰਪਿਊਟੇਸ਼ਨ ਲਿਜਾਣਾ” ਦਾ ਮਤਲਬ ਹੈ ਉਹਨਾਂ ਮਸ਼ੀਨਾਂ ਨੂੰ ਛੋਟੀ ਕੋਡ ਟੁਕੜੀਆਂ ਭੇਜਣਾ ਜਿਹੜਿਆਂ ਕੋਲ ਡੇਟਾ ਪਹਿਲਾਂ ਹੀ ਮੌਜੂਦ ਹੈ, ਬਜਾਏ ਇਸਦੇ ਕਿ ਵੱਡੇ ਡੇਟਾਸੇਟ ਨੂੰ ਨੈਟਵਰਕ 'ਤੇ ਇੱਕ ਥਾਂ ਤੇ ਕਾਪੀ ਕੀਤਾ ਜਾਏ।
ਇਸ ਨਾਲ ਨੈਟਵਰਕ ਜਾਮ ਘਟਦਾ ਹੈ ਅਤੇ ਜਿਵੇਂ ਡੇਟਾ ਵਧਦਾ ਹੈ, ਮਾਪਨੇਯੋਗਤਾ ਵਧਦੀ ਹੈ—ਖਾਸ ਕਰਕੇ ਵੱਡੇ ਬੈਚ ਵਰਕਲੋਡ ਲਈ।
ਅਸਲ ਪਾਈਪਲਾਈਨ ਵਿੱਚ Lucene ਅਤੇ Hadoop ਇਕ ਦੂਜੇ ਨੂੰ ਕਿਵੇਂ ਪੂਰਾ ਕਰਦੇ ਹਨ?
ਆਮ ਪੈਟਰਨ ਇਹ ਹੈ:
- ਕੱਚੇ ਲੌਗ/ਈਵੇਂਟਸ ਨੂੰ ਵਿਤਰਿਤ ਸਟੋਰੇਜ (ਇਤਿਹਾਸਕ ਤੌਰ 'ਤੇ HDFS) ਵਿੱਚ ਰੱਖੋ
- ਪਾਰਸ/ਕਲੀਨ/ਇੰਰਿਚ ਕਰਨ ਲਈ ਬੈਚ ਜੌਬ ਚਲਾਓ ਅਤੇ “ਖੋਜ-ਤਿਆਰ” ਰਿਕਾਰਡ ਬਣਾਓ
- ਸੁਧਰੇ ਨਤੀਜੇ ਨੂੰ Lucene (ਜਾਂ Lucene-ਆਧਾਰਿਤ ਸਿਸਟਮ) ਨਾਲ ਇੰਡੈਕਸ ਕਰੋ
ਇਸ ਵਿਭਾਜਨ ਨਾਲ ਭਾਰੀ ਪ੍ਰੋਸੈਸਿੰਗ ਅਤੇ ਇੰਟਰਐਕਟਿਵ ਖੋਜ ਇੱਕ-ਦੂਜੇ ਨਾਲ ਟਕਰਾਉਂਦੇ ਨਹੀਂ।
Hadoop ਦੇ ਸਭ ਤੋਂ ਸ਼ੁਰੂਆਤੀ “ਕਿਲਰ ਯੂਜ਼ ਕੇਸ” ਕਿਹੜੇ ਸਨ?
ਅਰੰਭੀ ਜਿੱਤਾਂ ਉਹ ਉੱਚ-ਵਾਲਿਊਮ, ਅੱਡ-ਹੈਵੀ ਡੇਟਾ ਸਨ ਜਿੱਥੇ ਮੁੱਲ ਅਕਸਰ ਸਮੂਹਿਕ ਹੈ:
- ਲੌਗ ਪ੍ਰੋਸੈਸਿੰਗ (ਬਗਆਂ, ਲੇਟेंसी ਪਰਸੈਂਟਾਈਲ, ਟ੍ਰੈਫਿਕ ਰੋਲਅਪ)
- ਕਲਿਕਸਟ੍ਰੀਮ ਵਿਸ਼ਲੇਸ਼ਣ (ਫਨਲ, ਕੋਹੋਰਟ)
- ETL (ਕੱਚਾ ਡੇਟਾ ਲੈਂਡ ਕਰਨਾ, ਵੱਡੇ ਪੈਮਾਨੇ 'ਤੇ ਰੂਪਾਂਤਰ)
ਇਹ ਆਮ ਤੌਰ 'ਤੇ ਬੈਚ ਵਰਕਫਲੋ ਹਨ ਜਿੱਥੇ ਮਿਲੀਨ-ਸਟੈਂਡੀ ਰਿਪੋਰਟਿੰਗ/ਅਗਰਿਗੇਟਸ ਲਈ ਮਿੰਟਾਂ/ਘੰਟਿਆਂ ਦੀ ਦੇਰੀ ਸਵੀਕਾਰਯੋਗ ਹੁੰਦੀ ਹੈ।
ਆਧੁਨਿਕ ਟੀਮ ਇਕ search indexing ਅਤੇ distributed batch processing ਦੇ ਵਿਚਕਾਰ ਕਿਵੇਂ ਫੈਸਲਾ ਕਰੇ?
ਸ਼ੁਰੂ ਕਰੋ ਨਾਲ ਲੋੜਾਂ ਨੂੰ ਸਮਝੋ, ਫਿਰ ਉਹ ਸਭ ਤੋਂ ਸਧਾਰਣ ਟੂਲ ਚੁਨੋ ਜੋ ਉਨ੍ਹਾਂ ਨੂੰ ਪੂਰਾ ਕਰੇ:
- ਜੇ ਤੁਹਾਨੂੰ ਇੰਟਰਐਕਟਿਵ ਨਤੀਜੇ ਚਾਹੀਦੇ ਹਨ—ਕੀਵਰਡ, ਫਰੇਜ਼, ਫਿਲਟਰ ਅਤੇ ਸਕੋਰਿੰਗ—ਤਾਂ search indexing ਚੁਣੋ।
- ਜੇ ਤੁਹਾਨੂੰ ਵੱਡੇ ਡੇਟਾਸੇਟਾਂ 'ਤੇ transforms, aggregates ਜਾਂ exports ਚਾਹੀਦੇ ਹਨ—ਆਕਸਰ ਸਮਾਂ-ਅਨੁਸਾਰ—ਤਾਂ batch/distributed processing ਚੁਣੋ।
Latency, ਡੇਟਾ ਆਕਾਰ/ਵਾਧਾ, ਅੱਪਡੇਟ ਪੈਟਰਨ ਅਤੇ ਓਪਰੇਸ਼ਨਲ ਲੋਡ ਨੂੰ ਪ੍ਰੈਸ਼ਰ-ਟੈਸਟ ਕਰੋ। ਜੇ ਤੁਸੀਂ ਸਬੰਧਤ ਤੁਲਨਾਵਾਂ ਦੀ ਖੋਜ ਕਰਨਾ ਚਾਹੁੰਦੇ ਹੋ ਤਾਂ /blog ਦੇਖੋ; ਜੇ ਤੁਸੀਂ ਮੈਨੇਜਡ ਬਨਾਮ ਸੈਲਫ-ਹੋਸਟਿਡ ਦੇ ਵਿਚਕਾਰ ਤੌਲਣਾ ਕਰ ਰਹੇ ਹੋ ਤਾਂ /pricing ਆਪਰੇਸ਼ਨਲ ਜ਼ਿੰਮੇਵਾਰੀਆਂ ਨੂੰ ਸਮਝਣ ਵਿੱਚ ਮੱਦਦ ਕਰ ਸਕਦਾ ਹੈ।