اسان هڪ حيرت انگيز وقت ۾ رهون ٿا جڏهن توهان جلدي ۽ آساني سان ڪيترن ئي تيار ٿيل اوپن سورس اوزارن کي ڳنڍي سگهو ٿا، انهن کي سيٽ اپ ڪري سگهو ٿا توهان جي "شعور بند ٿيل" سان اسٽيڪ اوور فلو جي مشوري مطابق، "ڪيترن خطن" ۾ شامل ٿيڻ کان سواء، ۽ لانچ ڪريو. ان کي تجارتي آپريشن ۾. ۽ جڏهن توهان کي اپڊيٽ ڪرڻ/وڌائڻ جي ضرورت آهي يا ڪو اتفاقي طور تي ڪجهه مشينن کي ريبوٽ ڪري ٿو - توهان محسوس ڪيو آهي ته ڪنهن قسم جو جنوني خراب خواب شروع ٿي چڪو آهي، هر شيءِ ڊرامائي طور تي پيچيده ٿي چڪي آهي سڃاڻپ کان ٻاهر، پوئتي موٽڻ جي ڪا به ضرورت ناهي، مستقبل مبہم ۽ محفوظ آهي، پروگرامنگ جي بدران، ماکيء جو نسل ڪريو ۽ پنير ڪريو.
اهو ڪنهن به شيءِ لاءِ ناهي ته وڌيڪ تجربيڪار ساٿي ، جن جا مٿا بگڙيل آهن ۽ تنهن ڪري اڳ ۾ ئي گرين آهن ، ”ڪعب“ ۾ ”ڪنٽينرز“ جي پيڪن جي ناقابل یقین حد تائين تيزيءَ سان ترتيب ڏيڻ تي غور ڪري رهيا آهن ڪيترن ئي سرورن تي ”فيشنل ٻولين“ ۾ بلٽ ان سپورٽ سان. غير هم وقت سازي I/O، مسڪراهٽ معمولي. ۽ اھي خاموشيءَ سان ”مين پي ايس“ کي ٻيهر پڙھندا رھن ٿا، ”نگنڪس“ سورس ڪوڊ ۾ ڳنڍيندا رھن ٿا جيستائين سندن اکين مان رت وهي وڃي، ۽ لکندا، لکندا، لکندا يونٽ ٽيسٽ. ساٿين کي خبر آهي ته سڀ کان وڌيڪ دلچسپ شيء اچي ويندي جڏهن "هي سڀ" هڪ ڏينهن نئين سال جي شام تي رات جو دٻايو ويندو. ۽ انهن کي صرف يونڪس جي نوعيت، يادگار TCP/IP اسٽيٽ ٽيبل ۽ بنيادي ترتيب ڏيڻ-سرچ الگورٿمز جي تمام گهڻي ڄاڻ سان مدد ملندي. سسٽم کي زندگي ڏانهن واپس آڻڻ لاءِ جيئن چيمز هڙتال.
ها، مون کي ٿورو پريشان ٿي ويو، پر مون کي اميد آهي ته مان توقع جي حالت کي پهچائڻ ۾ ڪامياب ٿي چڪو آهيان.
اڄ مان DataLake لاءِ هڪ آسان ۽ سستي اسٽيڪ کي ترتيب ڏيڻ ۾ اسان جي تجربي کي حصيداري ڪرڻ چاهيان ٿو، جيڪو مڪمل طور تي مختلف ساختي ڊويزنن لاءِ ڪمپني ۾ تجزياتي ڪمن جي اڪثريت کي حل ڪري ٿو.
ڪجهه عرصو اڳ، اسان سمجھ ۾ آياسين ته ڪمپنين کي پراڊڪٽ ۽ ٽيڪنيڪل اينالائيٽڪس ٻنهي جي ميوي جي ضرورت آهي (مشين سکيا جي صورت ۾ ڪيڪ تي آئسنگ جو ذڪر نه ڪرڻ) ۽ رجحانات ۽ خطرن کي سمجهڻ لاءِ- اسان کي گڏ ڪرڻ ۽ تجزيو ڪرڻ جي ضرورت آهي. وڌيڪ ۽ وڌيڪ ميٽرڪ.
Bitrix24 ۾ بنيادي ٽيڪنيڪل اينالائيٽڪس
ڪيترائي سال اڳ، هڪ ئي وقت ۾ Bitrix24 سروس جي شروعات سان، اسان فعال طور تي هڪ سادي ۽ قابل اعتماد تجزياتي پليٽ فارم ٺاهڻ ۾ وقت ۽ وسيلا خرچ ڪيا جيڪي انفراسٽرڪچر ۾ مسئلن کي جلدي ڏسڻ ۽ ايندڙ قدم جي منصوبابندي ڪرڻ ۾ مدد ڪندا. يقينن، اهو مشورو ڏنو ويو آهي ته تيار ٿيل اوزار کڻڻ جيڪي ممڪن طور تي آسان ۽ سمجھڻ وارا هئا. نتيجي طور، ناگيوس مانيٽرنگ لاء چونڊيو ويو ۽ منين اينالائيٽڪس ۽ بصري لاء. ھاڻي اسان وٽ ناگيوس ۾ ھزارين چيڪ آھن، منين ۾ سوين چارٽ، ۽ اسان جا ساٿي انھن کي ھر روز ڪاميابيءَ سان استعمال ڪندا آھن. ميٽرڪس واضح آهن، گراف صاف آهن، سسٽم ڪيترن ئي سالن کان معتبر طور تي ڪم ڪري رهيو آهي ۽ نوان ٽيسٽ ۽ گرافس باقاعده شامل ڪيا ويا آهن: جڏهن اسان هڪ نئين خدمت کي آپريشن ۾ رکون ٿا، اسان ڪيترائي ٽيسٽ ۽ گراف شامل ڪندا آهيون. سدا خوشقسمت رهو.
نبض تي آڱر - ترقي يافته ٽيڪنيڪل اينالائيٽڪس
مسئلن جي باري ۾ معلومات حاصل ڪرڻ جي خواهش "جيتري جلدي ممڪن ٿي سگهي" اسان کي سادو ۽ سمجھڻ واري اوزار سان فعال تجربن ڏانهن راغب ڪيو - pinba ۽ xhprof.
پنبا اسان کي PHP ۾ ويب صفحن جي حصن جي آپريشن جي رفتار بابت UDP پيڪٽس ۾ انگ اکر موڪليا، ۽ اسان MySQL اسٽوريج ۾ آن لائن ڏسي سگهون ٿا (Pinba پنهنجي MySQL انجڻ سان اچي ٿو تيز واقعن جي تجزياتي لاءِ) مسئلن جي هڪ مختصر فهرست ۽ جواب انهن کي. ۽ xhprof خود بخود اسان کي اجازت ڏني ته اسان کي ڪلائنٽ کان سست PHP صفحن جي عملدرآمد جا گراف گڏ ڪريون ۽ تجزيو ڪيو ته ڇا ٿي سگهي ٿو اهو - آرام سان، چانهه وجهي يا ڪجهه مضبوط.
ڪجهه عرصو اڳ، ٽول ڪٽ هڪ ٻي بلڪل سادي ۽ سمجھڻ واري انجڻ سان ڀريو ويو، ريورس انڊيڪسنگ الگورٿم جي بنياد تي، مڪمل طور تي افسانوي لوسن لائبريري ۾ لاڳو ڪيو ويو - ايلسٽڪ/ڪيبانا. لاگز ۾ واقعن جي بنياد تي دستاويزن جي ملٽي ٿريڊ ٿيل رڪارڊنگ جو سادو خيال لاگز ۾ واقعن جي بنياد تي ۽ انهن جي ذريعي هڪ تڪڙي ڳولها فيڪٽ ڊويزن استعمال ڪندي واقعي ڪارائتو ثابت ٿيو.
ڪيبانا ۾ تصورن جي بجاءِ ٽيڪنيڪل ظهور جي باوجود گهٽ سطحي تصورن جهڙوڪ ”بالٽ“ ”اوڀر طرف وهڻ“ ۽ اڃا تائين مڪمل طور تي نه وساريل رشتيدار الجبرا جي ٻيهر ايجاد ٿيل ٻولي، اوزار اسان کي هيٺين ڪمن ۾ چڱيءَ طرح مدد ڏيڻ شروع ڪيو:
- Bitrix24 ڪلائنٽ کي گذريل ڪلاڪ ۾ p1 پورٽل تي ڪيتريون PHP غلطيون ٿيون ۽ ڪهڙيون؟ سمجھو، معاف ڪريو ۽ جلدي درست ڪريو.
- گذريل 24 ڪلاڪن ۾ جرمني ۾ پورٽلز تي ڪيتريون وڊيو ڪالون ڪيون ويون، ڪهڙي معيار سان ۽ چينل/نيٽ ورڪ ۾ ڪي مشڪلاتون هيون؟
- سسٽم جي ڪارڪردگي ڪيتري سٺي آهي (PHP لاءِ اسان جي سي ايڪسٽينشن)، تازه ترين سروس اپڊيٽ ۾ ماخذ کان مرتب ڪيل ۽ ڪلائنٽ تائين پهچايو، ڪم؟ ڇا اتي غلطيون آهن؟
- ڇا ڪسٽمر ڊيٽا PHP ياداشت ۾ مناسب آهي؟ ڇا ميموري کان وڌڻ جي باري ۾ ڪي غلطيون آھن جيڪي پروسيس کي مختص ڪيا ويا آھن: "ميموري کان ٻاھر"؟ ڳوليو ۽ غير جانبدار ڪريو.
هتي هڪ ڪنڪريٽ مثال آهي. مڪمل ۽ گھڻ-سطحي جاچ جي باوجود، ڪلائنٽ، هڪ تمام غير معياري ڪيس ۽ خراب ٿيل ان پٽ ڊيٽا سان، هڪ پريشان ڪندڙ ۽ غير متوقع غلطي ملي ٿي، هڪ سائرن وڄايو ۽ ان کي جلدي درست ڪرڻ جو عمل شروع ٿيو:
اضافي طور تي، kibana توهان کي مخصوص واقعن لاء اطلاعن کي منظم ڪرڻ جي اجازت ڏئي ٿو، ۽ ٿوري وقت ۾ ڪمپني ۾ اوزار مختلف شعبن جي ڪيترن ئي ملازمن پاران استعمال ٿيڻ شروع ڪيو - ٽيڪنيڪل سپورٽ ۽ ترقي کان وٺي QA تائين.
ڪمپني جي اندر ڪنهن به ڊپارٽمينٽ جي سرگرمي کي ٽريڪ ڪرڻ ۽ ماپڻ لاءِ آسان ٿي ويو آهي - سرور تي لاگز کي دستي طور تي تجزيو ڪرڻ جي بدران، توهان کي صرف هڪ ڀيرو پارسنگ لاگ سيٽ ڪرڻ جي ضرورت آهي ۽ انهن کي لچڪدار ڪلستر ڏانهن موڪلڻ لاءِ لطف اندوز ٿيڻ جي ضرورت آهي، مثال طور، ڪبانا ۾ غور ڪرڻ. ڊيش بورڊ گذريل قمري مهيني لاءِ 3-D پرنٽر تي ڇپيل ٻن سرن واري ڪتن جو تعداد.
بنيادي ڪاروباري تجزياتي
هرڪو ڄاڻي ٿو ته ڪمپنين ۾ ڪاروباري تجزياتي اڪثر ڪري انتهائي فعال استعمال سان شروع ٿئي ٿو، ها، ايڪسل. پر بنيادي شيء اها آهي ته اهو اتي ختم نٿو ٿئي. Cloud-based Google Analytics پڻ باهه ۾ ٻارڻ شامل ڪري ٿو - توهان جلدي سٺي شين جي عادت ٿيڻ شروع ڪيو.
اسان جي همٿ سان ترقي ڪندڙ ڪمپني ۾، هتي ۽ اتي "پيغمبر" وڏي ڊيٽا سان گڏ وڌيڪ سخت ڪم ظاهر ڪرڻ شروع ڪيو. وڌيڪ تفصيلي ۽ گهڻ رخي رپورٽن جي ضرورت باقاعدي ظاهر ٿيڻ لڳي، ۽ مختلف کاتن جي ماڻهن جي ڪوششن سان، ڪجهه عرصو اڳ هڪ سادي ۽ عملي حل ترتيب ڏنو ويو - ڪلڪ هائوس ۽ پاور بي آءِ جو ميلاپ.
ڪافي عرصي تائين، هن لچڪدار حل تمام گهڻي مدد ڪئي، پر آهستي آهستي سمجهه ۾ اچڻ لڳو ته ڪلڪ هاؤس ربر نه آهي ۽ اهڙي طرح ٺٺوليون نٿو ڪري سگهجي.
هتي اهو چڱي طرح سمجهڻ ضروري آهي ته ClickHouse، Druid وانگر، Vertica وانگر، Amazon RedShift (جيڪو پوسٽ گريس تي ٻڌل آهي)، تجزياتي انجڻ آهن جيڪي مناسب طور تي آسان اينالائيٽڪس لاءِ بهتر ڪيون ويون آهن (مجموعي، مجموعي، ڪالمن جي لحاظ کان گهٽ ۾ گهٽ وڌ ۾ وڌ ۽ ڪجهه ممڪن شامل آهن. )، ڇاڪاڻ ته منظم جدولن جي ڪالمن جي موثر اسٽوريج لاءِ، برعڪس MySQL ۽ ٻين (قطار تي مبني) ڊيٽابيس اسان جي ڄاڻ.
جوهر ۾، ClickHouse صرف هڪ وڌيڪ گنجائش وارو "ڊيٽابيس" آهي، تمام آسان نقطي نقطي جي داخل ٿيڻ سان (اهو ڪيئن مقصد آهي، سڀ ڪجهه ٺيڪ آهي)، پر خوشگوار تجزياتي ۽ ڊيٽا سان ڪم ڪرڻ لاء دلچسپ طاقتور افعال جو هڪ سيٽ. ها، توهان هڪ ڪلستر به ٺاهي سگهو ٿا - پر توهان سمجهو ٿا ته هڪ خوردبيني سان ناخن کي ڇڪڻ بلڪل صحيح ناهي ۽ اسان ٻين حل ڳولڻ شروع ڪيو.
پگهر ۽ تجزيه نگارن جو مطالبو
اسان جي ڪمپني ۾ ڪيترائي ڊولپر آھن جيڪي 10-20 سالن تائين PHP، JavaScript، C#، C/C++، Java، Go، Rust، Python، Bash ۾ تقريباً ھر روز ڪوڊ لکندا آھن. اتي پڻ ڪيترائي تجربا سسٽم منتظم آھن جن ھڪڙي کان وڌيڪ بلڪل ناقابل اعتبار آفت جو تجربو ڪيو آھي جيڪي انگ اکر جي قانونن ۾ مناسب نه آھن (مثال طور، جڏھن 10 ۾ ڊسڪ جي اڪثريت ھڪڙي مضبوط برقي هڙتال سان تباهه ٿي ويندي آھي). اهڙين حالتن ۾، هڪ ڊگهي وقت تائين اهو واضح نه هو ته "پٿون تجزيه نگار" ڇا آهي. Python PHP وانگر آهي، صرف نالو ٿورڙو ڊگهو آهي ۽ مترجم جي سورس ڪوڊ ۾ ذهن کي تبديل ڪرڻ واري مواد جا ٿورا گهٽ نشان آهن. بهرحال، جيئن جيئن وڌ کان وڌ تجزياتي رپورٽون ٺاهيون ويون، تيئن تجربيڪار ڊولپرز نمپي، پانڊاس، ميٽپلوٽليب، سيبورن جهڙن اوزارن ۾ تنگ اسپيشلائيزيشن جي اهميت کي وڌيڪ سمجهڻ شروع ڪيو.
فيصلي وارو ڪردار، گهڻو ڪري، "لاجسٽڪ ريگريشن" لفظن جي ميلاپ مان ملازمن جي اوچتو بي حسي ۽ استعمال ڪندي وڏي ڊيٽا تي مؤثر رپورٽنگ جو مظاهرو، ها، ها، پيسپارڪ طرفان ادا ڪيو ويو.
Apache Spark، ان جو فنڪشنل پيراڊم جنهن تي لاڳاپي وارو الجبرا بلڪل ٺهڪي اچي ٿو، ۽ ان جي صلاحيتن MySQL جا عادي ڊولپرز تي اهڙو تاثر پيدا ڪيو جو تجربيڪار تجزيه نگارن سان صفن کي مضبوط ڪرڻ جي ضرورت ڏينهون ڏينهن واضح ٿي وئي.
Apache Spark/Hadoop جي وڌيڪ ڪوششون بند ڪرڻ لاءِ ۽ ڇا نه ٿيو اسڪرپٽ مطابق
بهرحال، اهو جلد ئي واضح ٿي ويو ته ڪجهه سسٽم طور تي اسپارڪ سان بلڪل صحيح نه هو، يا اهو صرف ضروري هو ته توهان جي هٿن کي بهتر ڌوئڻ لاء. جيڪڏهن Hadoop/MapReduce/Lucene اسٽيڪ ڪافي تجربيڪار پروگرامرز پاران ٺاهيو ويو هو، جيڪو واضح آهي ته جيڪڏهن توهان جاوا ۾ سورس ڪوڊ يا لوسين ۾ ڊگ ڪٽنگ جي خيالن کي ويجهي نظر سان ڏسندا، ته پوءِ اسپارڪ، اوچتو، ڌارين ٻوليءَ ۾ لکيل آهي اسڪالا، جيڪو آهي. عملي جي نقطي نظر کان تمام گهڻو تڪرار آهي ۽ في الحال ترقي نه ڪري رهيو آهي. ۽ اسپارڪ ڪلستر تي حسابن ۾ باقاعده گھٽتائي جي ڪري غير منطقي ۽ تمام شفاف ڪم نه هجڻ جي ڪري ميموري مختص ڪرڻ سان گھٽ عملن لاءِ (ڪيترن ئي چابيون هڪ ڀيرو اچي وڃن ٿيون) ان جي چوڌاري هڪ هالو ٺاهي ڇڏيو آهي جنهن ۾ وڌڻ جي گنجائش آهي. اضافي طور تي، صورتحال وڏي تعداد ۾ عجيب کليل بندرگاهن جي ڪري بگڙيل هئي، عارضي فائلن جي تمام گهڻيون جڳهن ۾ وڌندڙ ۽ جار جي انحصار جي دوزخ - جنهن سبب سسٽم جي منتظمين کي هڪ احساس پيدا ڪيو جيڪو ننڍپڻ کان مشهور هو: سخت نفرت (يا شايد. انهن کي صابڻ سان پنهنجا هٿ ڌوئڻ گهرجن).
نتيجي طور، اسان ڪيترائي اندروني تجزياتي منصوبا "بچي" ويا آهن جيڪي فعال طور تي استعمال ڪن ٿا Apache Spark (بشمول اسپارڪ اسٽريمنگ، Spark SQL) ۽ Hadoop ايڪو سسٽم (۽ اڳتي وڌو). ان حقيقت جي باوجود ته وقت گذرڻ سان گڏ اسان ”ان“ کي چڱيءَ طرح تيار ڪرڻ ۽ مانيٽر ڪرڻ سکيو، ۽ ”اهو“ عملي طور تي اوچتو بند ٿي ويو ڊيٽا جي نوعيت ۾ تبديلين ۽ يونيفارم آر ڊي ڊي هيشنگ جي عدم توازن جي ڪري، ڪجهه وٺڻ جي خواهش اڳ ۾ ئي تيار ٿي وئي. ، بادل ۾ ڪٿي به اپڊيٽ ۽ انتظام مضبوط ۽ مضبوط ٿي ويا. اهو ئي وقت هو جڏهن اسان Amazon ويب سروسز جي تيار ڪيل بادل اسيمبلي کي استعمال ڪرڻ جي ڪوشش ڪئي. ۽، بعد ۾، ان کي استعمال ڪندي مسئلا حل ڪرڻ جي ڪوشش ڪئي. EMR Apache Spark آهي Amazon پاران تيار ڪيل اضافي سافٽ ويئر سان گڏ ايڪو سسٽم، گهڻو ڪري Cloudera/Hortonworks جي تعمير وانگر.
تجزياتي لاء ربر فائل اسٽوريج هڪ فوري ضرورت آهي
جسم جي مختلف حصن کي جلائڻ سان ”پائڻ“ هدوپ/ اسپارڪ جو تجربو بيڪار نه هو. هڪ واحد، سستي ۽ قابل اعتماد فائل اسٽوريج ٺاهڻ جي ضرورت آهي جيڪا هارڊويئر جي ناڪامي جي خلاف مزاحمتي هجي ۽ جنهن ۾ مختلف سسٽم کان مختلف فارميٽ ۾ فائلن کي ذخيرو ڪرڻ ۽ هن ڊيٽا مان رپورٽن لاء موثر ۽ وقت جي موثر نموني ٺاهڻ ممڪن هجي. صاف.
مان اهو به چاهيان ٿو ته هن پليٽ فارم جي سافٽ ويئر کي اپڊيٽ ڪرڻ 20 صفحن جي جاوا جا نشان پڙهڻ ۽ اسپارڪ هسٽري سرور ۽ هڪ بيڪ لِٽ ميگنفائنگ گلاس استعمال ڪندي ڪلسٽر جي ڪلوميٽر ڊگھي تفصيلي لاگز کي پڙهڻ سان نئين سال جي خواب ۾ تبديل نه ٿئي. مون چاهيو ٿي ته هڪ سادو ۽ شفاف اوزار هجي جنهن کي هوڊ جي هيٺان باقاعده ڊائيونگ جي ضرورت نه هجي جيڪڏهن ڊولپر جي معياري MapReduce درخواست تي عمل ٿيڻ بند ٿي ويو جڏهن ڊيٽا کي گهٽائڻ وارو ڪم ڪندڙ ياداشت کان ٻاهر ٿي ويو هڪ تمام سٺو نه چونڊيل ماخذ ڊيٽا ورهاڱي واري الگورتھم جي ڪري.
ڇا Amazon S3 DataLake لاءِ اميدوار آهي؟
Hadoop/MapReduce سان تجربو اسان کي سيکاريو ته اسان کي هڪ اسپيبلبل، قابل اعتماد فائل سسٽم ۽ ان جي چوٽي تي اسپيبلبل ڪارڪنن جي ضرورت آهي، ڊيٽا جي ويجهو "آندي" ته جيئن نيٽ ورڪ تي ڊيٽا کي ڊرائيو نه ڪيو وڃي. مزدورن کي ڊيٽا پڙهڻ جي قابل هجڻ گهرجي مختلف فارميٽ ۾، پر ترجيحي طور تي غير ضروري معلومات نه پڙهي ۽ ڪم ڪندڙن لاءِ آسان فارميٽ ۾ ڊيٽا اڳ ۾ محفوظ ڪرڻ جي قابل ٿي وڃن.
هڪ ڀيرو ٻيهر، بنيادي خيال. ھڪڙي ھڪڙي ڪلستر تجزياتي انجڻ ۾ وڏي ڊيٽا کي "ڊھڻ" جي ڪا به خواهش نه آھي، جيڪو جلدي يا بعد ۾ ڇڪيندو ۽ توھان کي ان کي بدصورت ڪرڻو پوندو. مان فائلن کي ذخيرو ڪرڻ چاهيان ٿو، صرف فائلون، هڪ سمجھڻ واري شڪل ۾ ۽ مختلف پر سمجھڻ وارا اوزار استعمال ڪندي انهن تي اثرائتي تجزياتي سوالن کي انجام ڏيڻ. ۽ مختلف شڪلين ۾ وڌيڪ ۽ وڌيڪ فائلون هونديون. ۽ اهو بهتر آهي ته انجڻ کي نه، پر ماخذ ڊيٽا. اسان کي ضرورت آھي ھڪ وسعت وارو ۽ آفاقي DataLake، اسان فيصلو ڪيو...
ڇا جيڪڏھن توھان فائلون ذخيرو ڪريو ٿا سڃاتل ۽ سڃاتل اسپيبلبل ڪلائوڊ اسٽوريج Amazon S3 ۾، بغير ھدوپ مان پنھنجون چپس تيار ڪرڻ جي؟
اهو واضح آهي ته ذاتي ڊيٽا "گهٽ" آهي، پر ڇا ٻين ڊيٽا بابت جيڪڏهن اسان ان کي اتي ڪڍي ڇڏيو ۽ "ان کي موثر طريقي سان ڊرائيو"؟
Amazon ويب سروسز جو Cluster-bigdata-analytics ecosystem - بلڪل سادو لفظن ۾
AWS سان اسان جي تجربي جو جائزو وٺندي، Apache Hadoop/MapReduce اتي ڪافي عرصي کان فعال طور تي استعمال ڪيو ويو آھي مختلف ساسز تحت، مثال طور DataPipeline سروس ۾ (مان پنھنجي ساٿين سان حسد ڪريان ٿو، انھن سکيو ته ان کي ڪيئن تيار ڪجي). هتي اسان DynamoDB جدولن مان مختلف خدمتن مان بيڪ اپ سيٽ ڪيو:
۽ اهي ڪيترن ئي سالن کان گھڙي جي ڪم وانگر ايمبيڊڊ Hadoop/MapReduce ڪلسٽرز تي باقاعدگي سان هلائي رهيا آهن. "ان کي سيٽ ڪريو ۽ ان کي وساريو":
توهان تجزيه نگارن لاءِ ڪلائوڊ ۾ Jupiter ليپ ٽاپ قائم ڪرڻ ۽ AWS SageMaker سروس استعمال ڪندي AI ماڊل کي جنگ ۾ ٽريننگ ۽ ترتيب ڏيڻ سان ڊيٽا شيطانيت ۾ مؤثر طريقي سان مشغول ٿي سگهو ٿا. ھتي اھو آھي جيڪو اسان لاءِ نظر اچي ٿو:
۽ ها، توهان ڪلائوڊ ۾ پنهنجي لاءِ يا هڪ تجزيه نگار لاءِ هڪ ليپ ٽاپ وٺي سگهو ٿا ۽ ان کي هڊوپ/اسپارڪ ڪلسٽر سان ڳنڍي سگهو ٿا، حساب ڪريو ۽ پوءِ هر شيءِ کي نيل ڪري سگهو ٿا:
واقعي آسان آهي انفرادي تجزياتي منصوبن لاءِ ۽ ڪجهه لاءِ اسان ڪاميابيءَ سان استعمال ڪيو آهي EMR سروس وڏي پئماني تي حسابن ۽ تجزياتي لاءِ. DataLake لاءِ سسٽم حل بابت ڇا ، ڇا اهو ڪم ڪندو؟ هن وقت اسان اميد ۽ نااميدي جي ڪناري تي هئاسين ۽ ڳولا جاري رکي.
AWS گلو - صاف طور تي پيڪيج ٿيل Apache Spark on steroids
اهو ظاهر ٿيو ته AWS وٽ "Hive/Pig/Spark" اسٽيڪ جو پنهنجو نسخو آهي. Hive جو ڪردار، i.e. DataLake ۾ فائلن جي فهرست ۽ انهن جي قسمن کي "ڊيٽا ڪيٽلاگ" سروس پاران انجام ڏنو ويو آهي، جيڪو اپاچي Hive فارميٽ سان ان جي مطابقت کي لڪائي نٿو سگهي. توهان کي هن خدمت ۾ معلومات شامل ڪرڻ جي ضرورت آهي ته توهان جون فائلون ڪٿي واقع آهن ۽ ڪهڙي فارميٽ ۾ آهن. ڊيٽا نه رڳو s3 ۾ ٿي سگهي ٿو، پر ڊيٽابيس ۾ پڻ، پر اهو هن پوسٽ جو موضوع ناهي. هتي اسان جي DataLake ڊيٽا ڊاريڪٽري کي ڪيئن منظم ڪيو ويو آهي:
فائلون رجسٽر ٿيل آهن، عظيم. جيڪڏهن فائلن کي اپڊيٽ ڪيو ويو آهي، اسان ڪريلر کي يا ته دستي طور تي يا هڪ شيڊول تي لانچ ڪندا آهيون، جيڪي انهن بابت معلومات کي تازه ڪاري ڪندا ۽ انهن کي محفوظ ڪندا. پوءِ ڍنڍ مان ڊيٽا کي پروسيس ڪري سگھجي ٿو ۽ نتيجن کي ڪٿي اپ لوڊ ڪيو وڃي. آسان ترين صورت ۾، اسان پڻ s3 تي اپلوڊ ڪيو. ڊيٽا پروسيسنگ ڪٿي به ٿي سگهي ٿي، پر اهو تجويز ڪيو ويو آهي ته توهان پروسيسنگ کي ترتيب ڏيو Apache Spark ڪلستر تي ترقي يافته صلاحيتون استعمال ڪندي AWS Glue API ذريعي. حقيقت ۾، توهان pyspark لائبريري کي استعمال ڪندي سٺو پراڻو ۽ واقف پٿون ڪوڊ وٺي سگهو ٿا ۽ ان جي عمل کي ترتيب ڏئي سگهو ٿا N نوڊس تي ڪجهه گنجائش جي ڪلسٽر جي نگراني سان، بغير هيڊوپ جي گٽ ۾ کوٽڻ ۽ ڊاکر-موڪر ڪنٽينرز کي ڇڪڻ ۽ انحصار جي تڪرار کي ختم ڪرڻ. .
هڪ ڀيرو ٻيهر، هڪ سادي خيال. Apache Spark کي ترتيب ڏيڻ جي ڪا ضرورت ناهي، توهان کي صرف python ڪوڊ لکڻ جي ضرورت آهي pyspark لاءِ، ان کي مقامي طور تي پنهنجي ڊيسڪ ٽاپ تي آزمايو ۽ پوءِ ان کي ڪلائوڊ ۾ هڪ وڏي ڪلستر تي هلايو، بيان ڪيو ته ماخذ ڊيٽا ڪٿي آهي ۽ نتيجو ڪٿي رکڻو آهي. ڪڏهن ڪڏهن اهو ضروري ۽ مفيد هوندو آهي، ۽ هتي اهو آهي ته اسان ان کي ڪيئن ترتيب ڏيون ٿا:
اهڙيءَ طرح، جيڪڏهن توهان کي s3 ۾ ڊيٽا استعمال ڪندي اسپارڪ ڪلسٽر تي ڪا شيءِ ڳڻڻ جي ضرورت آهي، ته اسان python/pyspark ۾ ڪوڊ لکون ٿا، ان کي آزمائيون ٿا، ۽ ڪلائوڊ لاءِ سٺي قسمت.
آرڪيسٽريشن بابت ڇا؟ ڇا جيڪڏهن ڪم ڪري پيو ۽ غائب ٿي ويو؟ ها، اپاچي پگ انداز ۾ هڪ خوبصورت پائيپ لائين ٺاهڻ جي تجويز ڏني وئي آهي ۽ اسان انهن کي آزمايو به، پر في الحال اسان فيصلو ڪيو آهي ته اسان پي ايڇ پي ۽ جاوا اسڪرپٽ ۾ تمام گهڻي ڪسٽمائيز آرڪسٽريشن کي استعمال ڪيو (مان سمجهان ٿو، اتي علم جي اختلاف آهي، پر اهو ڪم ڪري ٿو، ان لاءِ. سال ۽ بغير غلطي).
ڍنڍ ۾ محفوظ ڪيل فائلن جي شڪل ڪارڪردگي جي ڪنجي آهي
ٻه وڌيڪ اهم نقطا سمجهڻ تمام ضروري آهي. ڍنڍ ۾ فائل ڊيٽا تي سوالن لاء جلدي ممڪن طور تي عمل ڪيو وڃي ۽ ڪارڪردگي خراب نه ٿئي جڏهن نئين معلومات شامل ڪئي وڃي، توهان کي گهرجي:
- فائلن جي ڪالمن کي الڳ الڳ اسٽور ڪريو (انهي ڪري توهان کي ڪالمن ۾ ڇا آهي سمجهڻ لاءِ سڀئي لائينون پڙهڻ جي ضرورت نه آهي). ان لاءِ اسان ڪمپريشن سان parquet فارميٽ ورتو
- فائلن کي فولڊر ۾ شارڊ ڪرڻ تمام ضروري آھي جھڙوڪ: ٻولي، سال، مھينا، ڏينھن، ھفتو. انجڻ جيڪي سمجھندا آھن ھن قسم جي شارڊنگ کي صرف ضروري فولڊر تي نظر ايندو، بغير ھڪڙي قطار ۾ سڀني ڊيٽا کي ڇڪڻ کان سواء.
لازمي طور تي، هن طريقي سان، توهان تجزياتي انجڻين لاء سڀ کان وڌيڪ موثر شڪل ۾ ماخذ ڊيٽا کي مٿي تي ٽنگيو آهي، جيڪو پڻ شارڊ ٿيل فولڊر ۾ چونڊيل طور داخل ڪري سگهي ٿو ۽ فائلن مان صرف ضروري ڪالمن کي پڙهي سگهي ٿو. توهان کي ڪٿي به ڊيٽا کي "مڪمل ڪرڻ" جي ضرورت ناهي (اسٽوريج صرف ڦاٽندو) - صرف فوري طور تي ان کي درست فارميٽ ۾ فائل سسٽم ۾ وجهي ڇڏيو. يقينن، هتي اهو واضح هجڻ گهرجي ته DataLake ۾ هڪ وڏي csv فائل کي محفوظ ڪرڻ، جنهن کي ڪالمن کي ڪڍڻ لاء پهريون ڀيرو ڪلستر طرفان لائن پڙهڻ گهرجي، تمام گهڻو مشورو نه آهي. مٿين ٻن نقطن تي ٻيهر غور ڪريو جيڪڏهن اهو اڃا تائين واضح ناهي ته اهو سڀ ڪجهه ڇو ٿي رهيو آهي.
AWS Athena - جيڪ-ان-دي-باڪس
۽ پوء، هڪ ڍنڍ ٺاهيندي، اسان ڪنهن به حادثي سان Amazon Athena ۾ آياسين. اوچتو اهو ظاهر ٿيو ته اسان جي وڏي لاگ فائلن کي فولڊر شارڊز ۾ صحيح (پارڪيٽ) ڪالمن جي شڪل ۾ احتياط سان ترتيب ڏيڻ سان، توهان تمام جلدي انهن مان انتهائي معلوماتي چونڊون ڪري سگهو ٿا ۽ بغير اپاچي اسپارڪ/گلو ڪلستر کان سواءِ رپورٽون ٺاهي سگهو ٿا.
Athena انجڻ s3 ۾ ڊيٽا جي طاقت سان افسانوي تي ٻڌل آهي - ايم پي پي جو هڪ نمائندو (وڏي پيماني تي پروسيسنگ) ڊيٽا پروسيسنگ تائين پهچڻ جي خاندان، ڊيٽا کڻڻ جتي اهو آهي، s3 ۽ Hadoop کان Cassandra ۽ عام ٽيڪسٽ فائلن تائين. توهان کي صرف ايٿينا کان پڇڻ جي ضرورت آهي SQL سوال تي عمل ڪرڻ لاءِ، ۽ پوءِ سڀ ڪجهه ”جلدي ۽ خودڪار طريقي سان ڪم ڪري ٿو. اهو نوٽ ڪرڻ ضروري آهي ته ايٿينا "سمارٽ" آهي، اهو صرف ضروري شارڊ فولڊر ڏانهن وڃي ٿو ۽ صرف درخواست ۾ گهربل ڪالمن کي پڙهي ٿو.
Athena جي درخواستن جي قيمت پڻ دلچسپ آهي. اسان لاء ادا . اهي. في منٽ ڪلسٽر ۾ مشينن جي تعداد لاءِ نه، پر... اصل ۾ 100-500 مشينن تي اسڪين ٿيل ڊيٽا لاءِ، صرف ڊيٽا جي درخواست کي مڪمل ڪرڻ لاءِ ضروري آهي.
۽ صحيح طور تي شارڊ ٿيل فولڊر مان صرف ضروري ڪالمن جي درخواست ڪندي، اهو ظاهر ٿيو ته ايٿينا سروس اسان کي هڪ مهيني ۾ ڏهه ڊالر خرچ ڪري ٿو. چڱو، عظيم، تقريبن مفت، ڪلستر تي تجزياتي جي مقابلي ۾!
رستي جي ذريعي، هتي آهي اسان ڪيئن اسان جي ڊيٽا کي s3 ۾ شارٽ ڪيو:
نتيجي طور، ٿوري وقت ۾، ڪمپني ۾ مڪمل طور تي مختلف شعبن، معلومات جي حفاظت کان اينالائيٽڪس تائين، فعال طور تي ايٿينا کي درخواستون ڏيڻ شروع ڪيو ۽ جلدي، سيڪنڊن ۾، "وڏي" ڊيٽا کان مفيد جواب حاصل ڪرڻ لاء ڪافي ڊگهي عرصي دوران: مهينا، اڌ سال، وغيره پي.
پر اسان اڳتي وڌياسين ۽ جوابن لاءِ بادل ڏانهن وڃڻ شروع ڪيو : هڪ تجزيه نگار هڪ واقف ڪنسول ۾ SQL سوال لکي ٿو، جيڪا 100-500 مشينن تي ”پيني لاءِ“ ڊيٽا موڪلي ٿي s3 ڏانهن ۽ جواب ڏئي ٿو عام طور تي چند سيڪنڊن ۾. آرامده. ۽ تڪڙو. مان اڃا تائين يقين نه ٿو ڪري سگهان.
نتيجي طور، ڊيٽا کي s3 ۾ ذخيرو ڪرڻ جو فيصلو ڪيو ويو، هڪ موثر ڪالمن جي شڪل ۾ ۽ فولڊرن ۾ ڊيٽا جي مناسب شارڊنگ سان... اسان حاصل ڪيو DataLake ۽ هڪ تيز ۽ سستو تجزياتي انجڻ - مفت ۾. ۽ هو ڪمپني ۾ تمام گهڻو مشهور ٿيو، ڇاڪاڻ ته ... سمجھي ٿو SQL ۽ ڪم آرڊر جي شدت جي ڀيٽ ۾ تيزيءَ سان شروع ڪرڻ/روڪائڻ/سيٽنگ ڪرڻ جي ذريعي. "۽ جيڪڏهن نتيجو ساڳيو آهي، ڇو وڌيڪ ادا؟"
ايٿينا کي هڪ درخواست هن طرح ڪجهه ڏسڻ ۾ اچي ٿي. جيڪڏهن گهربل هجي، يقينا، توهان ڪافي ٺاهي سگهو ٿا ، پر اسان پاڻ کي سادي گروهه تائين محدود ڪنداسين. اچو ته ڏسون ته ڪھڙا جوابي ڪوڊ آھن ڪلائنٽ ڪجھ ھفتا اڳ ويب سرور لاگز ۾ ۽ پڪ ڪريو ته ڪو نقص نه آھي:
پهچڻ
گذرڻ کان پوءِ، نه چوڻ لاءِ هڪ ڊگهو، پر ڏکوئيندڙ رستو، مسلسل مناسب انداز ۾ خطرات ۽ سطح جي پيچيدگي ۽ سپورٽ جي قيمت جو اندازو لڳائيندي، اسان DataLake ۽ اينالائيٽڪس لاءِ هڪ اهڙو حل ڳولي لڌو آهي جيڪو اسان کي ملڪيت جي رفتار ۽ قيمت ٻنهي سان خوش ڪرڻ کان ڪڏهن به نه رهي.
اهو ظاهر ٿيو ته ڪمپني جي مڪمل طور تي مختلف شعبن جي ضرورتن لاءِ DataLake کي هلائڻ لاءِ هڪ موثر، تيز ۽ سستو تعمير مڪمل طور تي انهن تجربيڪار ڊولپرز جي قابليت ۾ آهي جن ڪڏهن به معمار طور ڪم نه ڪيو آهي ۽ نه ڄاڻندا آهن ته چوڪن تي چوڪن کي ڪيئن ٺاهيو. تير ۽ ڄاڻو 50 اصطلاحن کان Hadoop ماحولياتي نظام.
سفر جي شروعات ۾، منهنجو مٿو کليل ۽ بند سافٽ ويئر جي ڪيترن ئي جهنگلي زو کان جدا ٿي رهيو هو ۽ اولاد جي ذميواري جي بار کي سمجهي رهيو هو. بس پنهنجي DataLake کي سادو اوزارن مان ٺاهڻ شروع ڪريو: nagios/munin -> elastic/kibana -> Hadoop/Spark/s3...، راءِ گڏ ڪرڻ ۽ ٿيندڙ عملن جي فزڪس کي چڱيءَ طرح سمجھڻ. سڀ ڪجھ پيچيده ۽ گندو - ان کي دشمنن ۽ مقابلن کي ڏيو.
جيڪڏهن توهان ڪلائوڊ ڏانهن وڃڻ نٿا چاهيو ۽ اوپن سورس پروجيڪٽ کي سپورٽ ڪرڻ، تازه ڪاري ڪرڻ ۽ پيچ ڪرڻ چاهيو ٿا، ته توهان مقامي طور تي اسان جي جهڙي هڪ اسڪيم ٺاهي سگهو ٿا، سستي آفيس مشينن تي Hadoop ۽ Presto مٿان. اصلي شيء کي روڪڻ ۽ اڳتي وڌڻ نه آهي، ڳڻڻ، سادو ۽ واضح حل ڳولڻ، ۽ هر شي ضرور ڪم ڪندو! سڀني کي سٺي قسمت ۽ توهان کي ٻيهر ملن ٿا!
جو ذريعو: www.habr.com