ერიკ გფესერი, SPR-ის მონაცემთა პრაქტიკის მთავარი არქიტექტორი - ინტერვიუს სერია

ერიკი შეუერთდა მონაცემთა პრაქტიკას SPR's Emerging Technology Group, როგორც მთავარი არქიტექტორი 2018 წელს.

ერიკი გახდა სპეციალიზირებული მონაცემთა, ღია კოდის შემუშავებაში Java-ს გამოყენებით და პრაქტიკული საწარმოს არქიტექტურაში, მათ შორის PoC-ების, პროტოტიპების და MVP-ების მშენებლობაში.

თავიდან რამ მიგიზიდათ მანქანური სწავლებით?

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

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

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

თქვენ ხართ ღია წყაროს უზარმაზარი ადვოკატი, შეგიძლიათ განიხილოთ, რატომ არის ღია წყარო ასე მნიშვნელოვანი?

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

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

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

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

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

თქვენ გამოიყენეთ ღია წყარო PoC-ების, პროტოტიპების და MVP-ების შესაქმნელად. შეგიძლიათ გააზიაროთ თქვენი მოგზაურობა ზოგიერთი ამ პროდუქტის უკან?

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

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

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

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

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

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

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

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

გარდა ამისა, ასეთი კომპონენტების დოკუმენტაცია დიდწილად არ არის საჯაროდ ხელმისაწვდომი, რაც აიძულებს დეველოპერების მუდმივ დამოკიდებულებას ამ ფირმებზე. როდესაც ფართოდ მიღებული ღია კოდის კომპონენტები, როგორიცაა Apache Spark არის ცენტრალური აქცენტი, როგორიცაა ისეთი პროდუქტები, როგორიცაა Databricks Unified Analytics Platform, ამ ელემენტებიდან ბევრი უკვე ხელმისაწვდომია საზოგადოებაში, რაც ამცირებს იმ ნაწილებს, რომლებზეც განვითარების გუნდები უნდა იყვნენ დამოკიდებულნი კომერციულ სუბიექტებზე. თავიანთი სამუშაოს შესასრულებლად.

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

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

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

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

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

თქვენ გადახედეთ 100 წიგნს თქვენს ვებსაიტზე, არის თუ არა სამი, რომელსაც ურჩევდით ჩვენს მკითხველს?

ამ დღეებში მე ვკითხულობ ძალიან ცოტა პროგრამირების წიგნებს და მიუხედავად იმისა, რომ არსებობს გამონაკლისები, რეალობა ის არის, რომ ისინი, როგორც წესი, ძალიან სწრაფად მოძველებულია და დეველოპერის საზოგადოება ჩვეულებრივ უკეთეს ალტერნატივებს იძლევა სადისკუსიო ფორუმებისა და დოკუმენტაციის საშუალებით. ბევრი წიგნი, რომელსაც ამჟამად ვკითხულობ, თავისუფლად არის ხელმისაწვდომი ჩემთვის, ან ტექნოლოგიური საინფორმაციო ბიულეტენების საშუალებით, რომლებზეც მე გამოვიწერე, ავტორებსა და პუბლიცისტებს, რომლებიც მომმართავენ, ან იმ წიგნებს, რომლებსაც Amazon მიგზავნის. მაგალითად, ამაზონმა გამომიგზავნა "The Lean Startup"-ის წინასწარ გამოქვეყნებული დაუზუსტებელი მტკიცებულება ჩემი განხილვისთვის 2011 წელს, გამაცნო MVP-ის კონცეფცია და ახლახან გამომიგზავნა "Julia for Beginners"-ის ასლი.

(1) ერთი წიგნი O'Reilly-დან, რომელიც მე გირჩევთ არის "Nirvana მონაცემთა ბაზის ძიებაში". ავტორი დეტალურად მოიცავს მონაცემთა შეკითხვის ძრავის გამოწვევებს, რათა მხარი დაუჭიროს სამუშაო დატვირთვას, რომელიც მოიცავს OLTP სპექტრს ერთი ბოლოდან, ანალიტიკამდე მეორე ბოლოზე, შუაში ოპერატიული და საქმიანი დაზვერვის დატვირთვით. ეს წიგნი შეიძლება გამოყენებულ იქნას, როგორც გზამკვლევი მონაცემთა ბაზის ძრავის ან შეკითხვისა და შენახვის ძრავების კომბინაციის შესაფასებლად, რომელიც მიმართულია სამუშაო დატვირთვის მოთხოვნების დაკმაყოფილებაზე, იქნება ეს ტრანზაქციული, ანალიტიკური თუ ამ ორის ნაზავი. გარდა ამისა, ავტორის მიერ ბოლო წლებში განსაკუთრებით კარგად არის გაშუქებული „ბაზის მოძრავი ქანქარა“.

(2) მიუხედავად იმისა, რომ ბევრი რამ შეიცვალა მონაცემთა სივრცეში ბოლო რამდენიმე წლის განმავლობაში, მას შემდეგ, რაც ახალი მონაცემთა ანალიტიკური პროდუქტების დანერგვა გრძელდება, "დარღვევის ანალიტიკა" წარმოგიდგენთ ანალიტიკაში ბოლო 50 წლის ინოვაციის მოკლე ისტორიას, რომელიც მე სხვაგან არ მინახავს და განიხილავს ორი სახის შეფერხებას: დამრღვევი ინოვაცია ანალიტიკის ღირებულების ჯაჭვში და ინდუსტრიის დარღვევა ანალიტიკაში ინოვაციებით. სტარტაპებისა და ანალიტიკის პრაქტიკოსების პერსპექტივიდან, წარმატება მიიღწევა მათი ინდუსტრიების შეფერხებით, რადგან ანალიტიკის გამოყენება პროდუქტის დიფერენცირებისთვის არის გზა დამრღვევი ბიზნეს მოდელის შესაქმნელად ან ახალი ბაზრების შესაქმნელად. მათი ორგანიზაციებისთვის ანალიტიკურ ტექნოლოგიაში ინვესტირების პერსპექტივიდან, ლოდინისა და ნახვის მიდგომის მიღებას შეიძლება ჰქონდეს აზრი, რადგან შეფერხების რისკის ქვეშ მყოფი ტექნოლოგიები სარისკო ინვესტიციებია მოკლე სასარგებლო სიცოცხლის ხანგრძლივობის გამო.

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

თქვენ ხართ SPR-ის მონაცემთა პრაქტიკის მთავარი არქიტექტორი. შეგიძლიათ აღწეროთ რას აკეთებს SPR?

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

რა არის თქვენი პასუხისმგებლობა SPR-თან დაკავშირებით?

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

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

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

რა არის საინტერესო პროექტი, რომელზეც ამჟამად მუშაობთ SPR-თან?

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

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

არის კიდევ რაიმე, რისი გაზიარებაც გსურთ ღია კოდის, SPR-ის ან სხვა პროექტის შესახებ, რომელზეც მუშაობთ?  

კიდევ ერთი პროექტი (წაიკითხეთ ამის შესახებ აქ დაწკაპუნებით მდე აქ დაწკაპუნებით) რომელსაც ახლახან ვხელმძღვანელობდი მოიცავს Databricks Unified Analytics პლატფორმის წარმატებულ დანერგვას და მასზე მანქანური სწავლების მოდელების აღსრულების მიგრაციას Azure HDInsight-დან, Hadoop დისტრიბუციიდან, დიდი მზღვეველის მონაცემთა ინჟინერიის დირექტორისთვის.

ყველა ეს მიგრირებული მოდელი მიზნად ისახავდა მომხმარებელთა მიღების დონის პროგნოზირებას, რომელიც შეიძლება მოსალოდნელი იყოს სხვადასხვა სადაზღვევო პროდუქტისთვის, ზოგიერთი მათგანი გადავიდა SAS-დან რამდენიმე წლით ადრე, რა დროსაც კომპანია გადავიდა HDInsight-ის გამოყენებაზე. ყველაზე დიდი გამოწვევა იყო მონაცემთა ცუდი ხარისხი, მაგრამ სხვა გამოწვევები მოიცავდა ყოვლისმომცველი ვერსიების ნაკლებობას, ტომის ცოდნას და არასრული დოკუმენტაციას, და მონაცემთა გაუაზრებელ დოკუმენტაციას და მხარდაჭერას R გამოყენებასთან დაკავშირებით იმ დროისთვის (Databricks-ის Azure დანერგვა ახლახან იყო ხელმისაწვდომი. ამ პროექტამდე რამდენიმე თვით ადრე).

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

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