მონაცემთა ინჟინერი ან მოკვდი: ერთი დეველოპერის ისტორია

დეკემბრის დასაწყისში, მე დავუშვი საბედისწერო შეცდომა და ჩემს ცხოვრებაში, როგორც დეველოპერი, გარდამტეხი მომენტი მოვახერხე და გადავედი მონაცემთა ინჟინერიის (DE) გუნდში კომპანიის შიგნით. ამ სტატიაში მე გაგიზიარებთ რამდენიმე დაკვირვებას, რომელიც მე გავაკეთე DE გუნდში მუშაობის ორი თვის განმავლობაში.

რატომ მონაცემთა ინჟინერია?

ჩემი მოგზაურობა DE-ში დაიწყო 2019 წლის ზაფხულში, როდესაც ჩვენ Xneg წავიდეთ განაწილებული გამოთვლების სკოლადა იქ მივაღწიე განმანათლებლობას. დავიწყე თემით დაინტერესება, ალგორითმების შესწავლა და მათ შესახებაც კი წერენ, და შემდეგ დაფიქრდა გამოყენების ფარგლებს და სწრაფად გაარკვია, რომ ჩვენს კომპანიაში პრაქტიკული აპლიკაციის მონაცემთა ბაზებია განაწილებული.

კონკრეტულად რას აკეთებს ჩვენი გუნდი? ჩვენ, როგორც ყველა მოდურ ბიჭს და გოგოს, გვინდა გავხდეთ მონაცემთა ორიენტირებული კომპანია. და იმისათვის, რომ ეს შესაძლებელი გახდეს, ჩვენ მაინც უნდა ავაშენოთ საიმედო საცავი, რომელიც შეიძლება გამოყენებულ იქნას კომპანიისთვის საჭირო ნებისმიერი ანგარიშის შესაქმნელად. მაგრამ ყველაზე მნიშვნელოვანი ის არის, რომ ამ საცავში არსებული მონაცემები უნდა იყოს სანდო. უფრო მეტიც, ამ მონაცემების გამოყენებით, თქვენ უნდა შეძლოთ სისტემის მდგომარეობის აღდგენა დროში t. ამ ყველაფერს ართულებს ის ფაქტი, რომ ჩვენ ვცხოვრობთ მიკროსერვისების ახალ, მამაც სამყაროში და ეს იდეოლოგია გულისხმობს, რომ თითოეული სერვისი ახორციელებს თავის მცირე ფუნქციონირებას, მისი მონაცემთა ბაზა მისი საქმეა და მას შეუძლია წაშალოს იგი ყოველ დღე მაინც, მაგრამ ამავე დროს, ჩვენ უნდა შევძლოთ სერვისის მდგომარეობის მიღება და დამუშავება.

თუ გსურთ იყოთ მონაცემების მართვადი, ჯერ გახდით მოვლენებზე ორიენტირებული

არც ისე მარტივი. მოვლენები განსხვავებულია და დეველოპერი და მონაცემთა ინჟინერი მათ განსხვავებულად უყურებენ. მოვლენებზე საუბარი ცალკე სტატიის თემაა, ამიტომ აქ არ შევალ. გარდა ამისა, ასეთი სტატია უკვე написал ვიღაც მარტინ ფაულერს, მე არ წავართმევ დაფნას, დაე, ისიც ცნობილი გახდეს.

ზოგადად, საფიქრალი ბევრია და ამიტომ არის ეს ტერიტორია მიმზიდველი. ისე ხდება, რომ ჩვენს კომპანიაში მონაცემთა ინჟინერი პასუხისმგებლობის ბევრად უფრო ფართო სფეროა, ვიდრე უბრალოდ ადამიანი, რომელიც წერს ETL/ELT მილსადენებს (თუ არ იცით რას ნიშნავს ეს აბრევიატურები, მობრძანდით შეხვედრა. როგორც კონტექსტური რეკლამა).

ჩვენ საქმე გვაქვს შენახვის არქიტექტურასთან, მონაცემთა მოდელირებასთან, მონაცემთა უსაფრთხოებასთან დაკავშირებულ საკითხებთან და თავად მილსადენებთან, რა თქმა უნდა. ჩვენ ასევე უნდა დავრწმუნდეთ, რომ, ერთი მხრივ, ჩვენი ყოფნა არ არის ძალიან მძიმე პროდუქტის დეველოპერებისთვის და ისინი რაც შეიძლება ნაკლებად უნდა განადგურდნენ ჩვენი მოთხოვნებით სისტემაში ახალი ფუნქციების შეყვანისას, ხოლო მეორე მხრივ, ჩვენ უნდა მიაწოდოს ისინი მოხერხებულად ასახული ანალიტიკოსებისა და BI გუნდისთვის შესანახ მონაცემებში. ასე ვცხოვრობთ.

სირთულეები განვითარებისგან გადასვლისას

მუშაობის პირველ დღეს შევხვდი არაერთ სირთულეს, რომელიც მინდა გაგიზიაროთ.

1. პირველი რაც დავინახე იყო ტილინგის არარსებობა და გარკვეული პრაქტიკა. ავიღოთ, მაგალითად, კოდის დაფარვა ტესტებით. ჩვენ გვაქვს ასობით ტესტირების ჩარჩო დამუშავების პროცესში. მონაცემებთან მუშაობისას ყველაფერი უფრო რთულია. დიახ, ჩვენ შეგვიძლია შევამოწმოთ ETL მილსადენები ტესტის მონაცემებზე, მაგრამ ეს ყველაფერი ხელით უნდა გავაკეთოთ და ვეძიოთ გადაწყვეტილებები თითოეული კონკრეტული შემთხვევისთვის. შედეგად, ტესტის გაშუქება გაცილებით უარესია. საბედნიეროდ, არსებობს უკუკავშირის კიდევ ერთი ფენა მონიტორინგისა და ჟურნალების სახით, მაგრამ ეს უკვე მოითხოვს ჩვენგან რეაქტიულ რეაქციას და არა პროაქტიულად, რაც აღმაშფოთებელია და ნერვიულობს.

2. სამყარო DE-ს პერსპექტივიდან სულაც არ არის ისეთი, როგორიც ჩვეულებრივი პროდუქტის დეველოპერს ეჩვენება (კარგი, რა თქმა უნდა, მკითხველი ასეთი არ არის და მან უკვე ყველაფერი იცის, მაგრამ მე არ ვიცოდი და ახლა ვარ ხრაშუნა). როგორც დეველოპერი, მე ვქმნი ჩემს საკუთარ მიკროსერვისს, ვათავსებ მონაცემებს [თქვენი არჩევანის მონაცემთა ბაზაში], იქ ვინახავ ჩემს შტატს, ვიღებ რამეს ID-ით და კარგია. სერვისი ნელია, შეკვეთები დამაბნეველია, ეს ყველაფერია. ისინი მთხოვენ მოძებნო ჩემი მდგომარეობა სხვა სერვისში, ასე რომ, მე გადავაგდებ ღონისძიებას RabbitMQ-ში და ეს არის ის. და აქ ჩვენ კვლავ დავუბრუნდით ზემოთ აღწერილი მოვლენების საკითხს.

ის, რაც სერვისს სჭირდება ოპერატიული მუშაობისთვის, არ გვიწყობს ისტორიულ მონაცემებს, ამიტომ იწყება სერვისის კონტრაქტების გადამუშავებისა და განვითარების გუნდებთან მჭიდრო მუშაობის საკითხი. თქვენ ვერც კი წარმოიდგენთ, რამდენი საათი დაგვჭირდა რომ შევთანხმდეთ: როგორი Event Driven არის ის ჩვენს კომპანიაში.

3. თქვენ უნდა იფიქროთ თქვენი თავით. არა, მე არ ვგულისხმობ იმას, რომ დეველოპერები არ ფიქრობენ (თუმცა ვინ ვარ მე, რომ ყველასთვის ვილაპარაკო), უბრალოდ, პროდუქტის შემუშავებისას ძალიან ხშირად თქვენ უკვე გაქვთ რაიმე სახის არქიტექტურა და წყვეტთ სხვადასხვა აურზაურს ნარჩენებისგან. რა თქმა უნდა, ამას სჭირდება დაგეგმვა და ფიქრი, მაგრამ ეს არის ნაკადული სამუშაო, სადაც მთავარი პრობლემა უბრალოდ კარგად და ეფექტურად შესრულებაა.

ჩვენთვის ეს არც ისე მარტივია, რადგან სისტემის სხვადასხვა კომპონენტის გადატანა თბილი და მყუდრო მონოლითიდან ველური მიკროსერვისის ჯუნგლების სამყაროში არც ისე მარტივია. როდესაც სერვისი იწყებს მოვლენების გაშვებას, თქვენ უნდა გადახედოთ მეხსიერების შევსების ლოგიკას, რადგან მონაცემები ახლა სხვაგვარად გამოიყურება. აქ თქვენ უნდა იფიქროთ ბევრი და საფუძვლიანად, არა როგორც დეველოპერი, არამედ როგორც მონაცემთა ინჟინერი. ჩვეულებრივი ამბავია, როცა დღეებს ატარებ რვეულთან და კალმით ან დაფაზე მარკერით. ძალიან რთულია, ფიქრი არ მიყვარს, წარმოებაც მიყვარს.

4. ალბათ ყველაზე მნიშვნელოვანი ინფორმაციაა. რას ვაკეთებთ, როცა ცოდნა გვაკლია? ვინ თქვა stackoverflow? გაიტანეთ ეს ადამიანი ოთახიდან. ჩვენ მივდივართ, ვკითხულობთ დოკუმენტებს, წიგნებს ამ თემაზე და ასევე არის საზოგადოება, რომელიც აწყობს ფორუმებს, შეხვედრებს და კონფერენციებს. დოკუმენტაცია შესანიშნავია, მაგრამ სამწუხაროდ, ის შეიძლება არასრული იყოს. ჩვენ ვიყენებთ Cosmos DB-ს რიგ პროექტებში. წარმატებებს გისურვებთ ამ პროდუქტის დოკუმენტაციის კითხვაში. წიგნები ერთადერთი ხსნაა, საბედნიეროდ, ისინი არსებობს და გვხვდება, შეიცავს უამრავ ფუნდამენტურ ცოდნას და ბევრი და მუდმივად უნდა იკითხო. მაგრამ პრობლემა საზოგადოებაშია.

ახლა ძნელია მინიმუმ ერთი ადეკვატური კონფერენციის ან შეხვედრის პოვნა ჩვენს მხარეში. არა, რა თქმა უნდა, ბევრი შეხვედრაა სიტყვა Data-სთან, მაგრამ ამ სიტყვის გვერდით ჩვეულებრივ არის უცნაური აბრევიატურები, როგორიცაა ML ან AI. ასე რომ, ეს ჩვენთვის არ არის, ჩვენ ვსაუბრობთ იმაზე, თუ როგორ უნდა ავაშენოთ სათავსოები და არა იმაზე, თუ როგორ უნდა შევიწოვოთ თავი ნეირონებით. ამ ჰიპსტერებმა ყველაფერი აიღეს. შედეგად, ჩვენ ვართ საზოგადოების გარეშე. სხვათა შორის, თუ თქვენ ხართ მონაცემთა ინჟინერი და იცით კარგი თემები, გთხოვთ დაწეროთ კომენტარებში.

შეხვედრის დასკვნები და განცხადება

რითი დავამთავროთ? ჩემი პირველი გამოცდილება მეუბნება, რომ მონაცემთა ინჟინრის პოზიციაზე გრძნობა სასარგებლო იქნება ყველა დეველოპერისთვის. ეს უბრალოდ გვაძლევს საშუალებას, სხვანაირად შევხედოთ საგნებს და არ გაგვიკვირდეს, როცა თვალები გვისკდება, როცა ვხედავთ, როგორ ეპყრობიან დეველოპერები მათ მონაცემებს. ასე რომ, თუ თქვენს კომპანიაში არის DE, უბრალოდ გაესაუბრეთ ამ ბიჭებს, ბევრ ახალ რამეს გაიგებთ (თქვენს შესახებ).

და ბოლოს, განცხადება. იმის გამო, რომ ძნელია დღის განმავლობაში ჩვენს თემაზე შეხვედრების პოვნა, ჩვენ გადავწყვიტეთ შეგვექმნა საკუთარი. რატომ ვართ უარესები? საბედნიეროდ საოცარი გვაქვს შვეფსსს და ჩვენი მეგობრები ახალი პროფესიების ლაბორატორია, რომლებიც, ისევე როგორც ჩვენ, გრძნობენ, რომ მონაცემთა ინჟინრებს უსამართლოდ ართმევენ ყურადღებას.

ვისარგებლებ ამ შესაძლებლობით, ვიწვევ ყველას, ვინც ზრუნავს, მოვიდეს ჩვენი საზოგადოების პირველ შეხვედრაზე პერსპექტიული სათაურით „DE or Die“, რომელიც გაიმართება 27.02.2020 წლის XNUMX თებერვალს დოდო პიცას ოფისში. დეტალები მისამართზე TimePad.

თუ რამე მოხდება, მე იქ ვიქნები, შეგიძლიათ პირადად მითხრათ, როგორ ვცდები დეველოპერებთან დაკავშირებით.

წყარო: www.habr.com