მოკლე პასუხი: ხელოვნური ინტელექტი მონაცემთა ინჟინრებს სრულად ვერ ჩაანაცვლებს; ის ავტომატიზირებს განმეორებად სამუშაოებს, როგორიცაა SQL-ის ნახატი, მილსადენის სკაფოლდირება, ტესტები და დოკუმენტაცია. თუ თქვენი როლი ძირითადად დაბალი საკუთრების, ბილეთებზე დაფუძნებული სამუშაოა, ის უფრო გამოკვეთილია; თუ თქვენ ფლობთ საიმედოობას, განმარტებებს, მმართველობას და ინციდენტებზე რეაგირებას, ხელოვნური ინტელექტი ძირითადად უფრო სწრაფს გხდით.
ძირითადი დასკვნები:
საკუთრება : პრიორიტეტი მიანიჭეთ შედეგებზე პასუხისმგებლობას და არა მხოლოდ კოდის სწრაფად შექმნას.
ხარისხი : ტესტების, დაკვირვებადობისა და კონტრაქტების შედგენა, რათა მილსადენები სანდო დარჩეს.
მმართველობა : კონფიდენციალურობის, წვდომის კონტროლის, შენახვისა და აუდიტის კვალის ადამიანის საკუთრებაში შენარჩუნება.
ბოროტად გამოყენების წინააღმდეგობა : ხელოვნური ინტელექტის მიერ გამოტანილი მონაცემები ჩათვალეთ მონახაზებად; გადახედეთ მათ, რათა თავიდან აიცილოთ დანამდვილებით დაშვებული შეცდომები.
როლების შეცვლა : ნაკლები დრო დაუთმეთ სტანდარტული ვერსიების აკრეფას და მეტი დრო გამძლე სისტემების დიზაინს.
თუ მონაცემთა გუნდებთან ხუთ წუთზე მეტი გაატარეთ, გსმენიათ რეფრენი - ზოგჯერ ჩურჩულით, ზოგჯერ შეხვედრის დროს სიუჟეტური შემობრუნების მსგავსად წამოჭრილი: ჩაანაცვლებს თუ არა ხელოვნური ინტელექტი მონაცემთა ინჟინრებს?
და... მესმის. ხელოვნურ ინტელექტს შეუძლია SQL-ის გენერირება, მილსადენების აგება, დასტის ტრასების ახსნა, dbt მოდელების მონახაზების შედგენა, საწყობის სქემების შემოთავაზებაც კი შემაშფოთებელი ნდობით. GitHub Copilot SQL-ისთვის dbt მოდელების შესახებ GitHub Copilot
ეს ისეთი შეგრძნებაა, თითქოს ამწე-სატვირთოს ყურება ჟონგლიორობას სწავლობს. შთამბეჭდავია, ოდნავ საგანგაშო და ბოლომდე არ ხართ დარწმუნებული, რას ნიშნავს ეს თქვენი სამუშაოსთვის 😅
თუმცა სიმართლე სათაურზე ნაკლებად მოწესრიგებულია. ხელოვნური ინტელექტი აბსოლუტურად ცვლის მონაცემთა ინჟინერიას. ის ავტომატიზირებს მოსაწყენ, განმეორებად ნაწილებს. ის აჩქარებს „ვიცი, რა მინდა, მაგრამ სინტაქსი არ მახსოვს“ მომენტებს. ის ასევე ქაოსის სრულიად ახალ სახეებს წარმოშობს.
მაშ ასე, მოდით, სწორად ჩამოვაყალიბოთ, ხელისგულისებური ოპტიმიზმისა და „საბედისწერო სქროლინგის“ პანიკის გარეშე.
სტატიები, რომელთა წაკითხვაც შეიძლება მოგეწონოთ ამის შემდეგ:
🔗 ჩაანაცვლებს თუ არა ხელოვნური ინტელექტი რადიოლოგებს?
როგორ ცვლის ვიზუალიზაციის ხელოვნური ინტელექტი სამუშაო პროცესს, სიზუსტეს და მომავალ როლებს.
🔗 ჩაანაცვლებს თუ არა ხელოვნური ინტელექტი ბუღალტერებს?
ნახეთ, რომელ ბუღალტრულ ამოცანებს ავტომატიზირებს ხელოვნური ინტელექტი და რა რჩება ადამიანურად.
🔗 ჩაანაცვლებს თუ არა ხელოვნური ინტელექტი საინვესტიციო ბანკირებს?
გაიგეთ ხელოვნური ინტელექტის გავლენა გარიგებებზე, კვლევასა და კლიენტებთან ურთიერთობაზე.
🔗 ჩაანაცვლებს თუ არა ხელოვნური ინტელექტი სადაზღვევო აგენტებს?
გაიგეთ, თუ როგორ გარდაქმნის ხელოვნური ინტელექტი ანდერრაიტინგს, გაყიდვებსა და მომხმარებელთა მხარდაჭერას.
რატომ ჩნდება კითხვა „ხელოვნური ინტელექტი ცვლის მონაცემთა ინჟინრებს“ მუდმივად 😬
შიში ძალიან კონკრეტული ადგილიდან მოდის: მონაცემთა ინჟინერიას ბევრი განმეორებადი სამუშაო აქვს .
-
SQL-ის წერა და რეფაქტორინგი
-
შეყვანის სკრიპტების შექმნა
-
ველების ერთი სქემიდან მეორეზე გადატანა
-
ტესტების და ძირითადი დოკუმენტაციის შექმნა
-
მილსადენის გაუმართაობების გამართვა, რომლებიც… გარკვეულწილად პროგნოზირებადია
ხელოვნური ინტელექტი უჩვეულოდ კარგია განმეორებადი ნიმუშების კუთხით. მონაცემთა ინჟინერიის დიდი ნაწილი კი სწორედ ეს არის - ნიმუშები, რომლებიც ერთმანეთზეა დაწყობილი. GitHub Copilot-ის კოდის შემოთავაზებები.
ასევე, ინსტრუმენტების ეკოსისტემა უკვე „მალავს“ სირთულეს:
-
მართული ELT კონექტორები Fivetran-ის დოკუმენტაცია
-
სერვერის გარეშე გამოთვლა AWS Lambda (სერვერის გარეშე გამოთვლა)
-
ერთი დაწკაპუნებით საწყობის უზრუნველყოფა
-
ავტომატური მასშტაბირების ორკესტრირება Apache Airflow-ის დოკუმენტაცია
-
დეკლარაციული ტრანსფორმაციის ჩარჩოები რა არის dbt?
ასე რომ, როდესაც ხელოვნური ინტელექტი ჩნდება, შეიძლება იგრძნოთ, რომ ის ბოლო ნაწილია. თუ დასტა უკვე აბსტრაგირებულია და ხელოვნურ ინტელექტს შეუძლია წებოვანი კოდის დაწერა... რა რჩება? 🤷
მაგრამ აი, რა გამორჩათ ხალხს: მონაცემთა ინჟინერია ძირითადად აკრეფა არ არის . აკრეფა მარტივი ნაწილია. რთული ნაწილია ბუნდოვანი, პოლიტიკური, ცვალებადი ბიზნეს რეალობის საიმედო სისტემად ქცევა.
და ხელოვნური ინტელექტი კვლავ ებრძვის ამ სიბნელეს. ადამიანებსაც უჭირთ - ისინი უბრალოდ უკეთესად იმპროვიზაციას ახდენენ.
რას აკეთებენ მონაცემთა ინჟინრები სინამდვილეში მთელი დღის განმავლობაში (არამომხიბვლელი სიმართლე) 🧱
მოდით, გულახდილად ვთქვათ - სამუშაოს სახელწოდება „მონაცემთა ინჟინერი“ ისე ჟღერს, თითქოს სუფთა მათემატიკიდან რაკეტის ძრავებს აშენებთ. პრაქტიკაში, თქვენ ნდობას .
ტიპიური დღე ნაკლებად „ახალი ალგორითმების გამოგონებას“ და უფრო მეტს მოიცავს:
-
მონაცემთა განმარტებებთან დაკავშირებით ზედა დონის გუნდებთან მოლაპარაკება (მტკივნეული, მაგრამ აუცილებელი)
-
იმის გამოკვლევა, თუ რატომ შეიცვალა მეტრიკა (და რეალურია თუ არა ის)
-
სქემის დრიფტის და „ვიღაცამ შუაღამისას სვეტი დაამატა“ სიურპრიზების დამუშავება
-
იმის უზრუნველყოფა, რომ მილსადენები იყოს იდემპოტენტი, აღდგენილი და დაკვირვებადი
-
დამცავი ბარიერების შექმნა, რათა ანალიტიკოსებმა შემთხვევით არ შექმნან უაზრო დაფები
-
ხარჯების მართვა, რათა თქვენი საწყობი ფულის კოცონად არ გადაიქცეს 🔥
-
წვდომის, აუდიტის, შესაბამისობის, შენახვის პოლიტიკის უზრუნველყოფა GDPR პრინციპები (ევროკომისია) შენახვის შეზღუდვა (ICO)
-
მონაცემთა პროდუქტების შექმნა, რომელთა გამოყენებაც ადამიანებს რეალურად შეეძლებათ თქვენთვის პირადი შეტყობინების გაგზავნის გარეშე - 20 კითხვა
სამუშაოს დიდი ნაწილი სოციალური და ოპერაციულია:
-
„ვის ეკუთვნის ეს მაგიდა?“
-
„ეს განმარტება ისევ ძალაშია?“
-
„რატომ ექსპორტს უკეთებს CRM დუბლიკატებს?“
-
„შეგვიძლია ეს მეტრიკა აღმასრულებლებისთვის უხერხულობის გარეშე გავუგზავნოთ?“ 😭
ხელოვნურ ინტელექტს, რა თქმა უნდა, შეუძლია ამ საკითხში დახმარება. თუმცა, მისი სრული ჩანაცვლება... საკმაოდ რთულია.
რა ხდის მონაცემთა ინჟინერიის პოზიციას ძლიერ ვერსიას? ✅
ეს ნაწილი მნიშვნელოვანია, რადგან ჩანაცვლებაზე საუბარი, როგორც წესი, ვარაუდობს, რომ მონაცემთა ინჟინრები ძირითადად „მილსადენების მშენებლები“ არიან. ეს იგივეა, რომ ვივარაუდოთ, რომ შეფ-მზარეულები ძირითადად „ბოსტნეულს ჭრიან“. ეს სამუშაოს ნაწილია, მაგრამ ეს არ არის სამუშაო.
მონაცემთა ინჟინრის ძლიერი ვერსია, როგორც წესი, ნიშნავს, რომ მას შეუძლია შემდეგი ფუნქციების უმეტესობის შესრულება:
-
ცვლილებებისთვის დიზაინი
. მონაცემები იცვლება. გუნდები იცვლება. ინსტრუმენტები იცვლება. კარგი ინჟინერი ქმნის სისტემებს, რომლებიც არ იშლება ყოველ ჯერზე, როდესაც რეალობა აცემინებს 🤧 -
კონტრაქტებისა და მოლოდინების განსაზღვრა
რას ნიშნავს „მომხმარებელი“? რას ნიშნავს „აქტიური“? რა ხდება, როდესაც რიგი დაგვიანებით მოდის? კონტრაქტები ქაოსს უფრო მეტად უშლის ხელს, ვიდრე დახვეწილი კოდი. ღია მონაცემების კონტრაქტის სტანდარტი (ODCS) ODCS (GitHub) -
ყველაფერში დაკვირვებადობა უნდა იყოს ჩართული
არა მხოლოდ „გაშვებული იყო თუ არა“, არამედ „სწორად მუშაობდა თუ არა“. სიახლე, მოცულობის ანომალიები, ნულოვანი აფეთქებები, განაწილების ცვლილებები. მონაცემთა დაკვირვებადობა (Dynatrace) რა არის მონაცემთა დაკვირვებადობა? -
ზრდასრულივით გააკეთეთ კომპრომისები
სიჩქარესა და სიზუსტეს, ღირებულებასა და შეყოვნებას შორის, მოქნილობასა და სიმარტივეს შორის. იდეალური არხი არ არსებობს, მხოლოდ ის არხი არსებობს, რომელთანაც შეგიძლიათ თანაცხოვრება. -
ბიზნესის საჭიროებების მდგრად სისტემებად გარდაქმნა.
ადამიანები ითხოვენ მეტრიკას, მაგრამ მათ მხოლოდ მონაცემთა პროდუქტი სჭირდებათ. ხელოვნურ ინტელექტს შეუძლია კოდის შედგენა, მაგრამ მას არ შეუძლია ჯადოსნურად ამოიცნოს ბიზნესისთვის დამახასიათებელი საფრთხეები. -
მონაცემების გასაიდუმლოება
მონაცემთა პლატფორმის ყველაზე დიდი კომპლიმენტი ის არის, რომ მასზე არავინ საუბრობს. უწყვეტი მონაცემები კარგი მონაცემებია. სანტექნიკის მსგავსად. მხოლოდ მაშინ ამჩნევთ, როცა ის გაფუჭებულია 🚽
თუ ამ ყველაფერს აკეთებთ, კითხვა „ჩაანაცვლებს თუ არა ხელოვნური ინტელექტი მონაცემთა ინჟინრებს?“ ცოტა არასწორად ჟღერს. ხელოვნურ ინტელექტს შეუძლია ამოცანების და არა საკუთრების .
სადაც ხელოვნური ინტელექტი უკვე ეხმარება მონაცემთა ინჟინრებს (და ეს ნამდვილად შესანიშნავია) 🤖✨
ხელოვნური ინტელექტი მხოლოდ მარკეტინგი არ არის. კარგად გამოყენებული, ის ლეგიტიმური ძალის გამამრავლებელია.
1) უფრო სწრაფი SQL და ტრანსფორმაციის მუშაობა
-
რთული შეერთებების შედგენა
-
ფანჯრის ფუნქციების წერა, რომლებზეც არ გსურთ იფიქროთ
-
მარტივი ენის ლოგიკის შეკითხვის ჩონჩხებად გადაქცევა
-
არასასიამოვნო მოთხოვნების რეფაქტორიზაცია წაკითხვად CTE-ებად GitHub Copilot SQL-ისთვის
ეს ძალიან მნიშვნელოვანია, რადგან ამცირებს „ცარიელი გვერდის“ ეფექტს. თქვენ მაინც გჭირდებათ ვალიდაცია, მაგრამ 0%-ის ნაცვლად 70%-დან იწყებთ.
2) გამართვა და ძირეული მიზეზის პურის ნამცეცების აღმოჩენა
ხელოვნური ინტელექტი კარგად მუშაობს:
-
შეცდომის შეტყობინებების ახსნა
-
გირჩევთ, სად უნდა ნახოთ
-
„სქემის შეუსაბამობის შემოწმების“ ტიპის ნაბიჯების რეკომენდაცია GitHub Copilot-ისთვის.
ეს ჰგავს დაუღალავი უმცროსი ინჟინერის ყოლას, რომელიც არასდროს სძინავს და ზოგჯერ თავდაჯერებულად იტყუება 😅
3) დოკუმენტაცია და მონაცემთა კატალოგის გამდიდრება
ავტომატურად გენერირებული:
-
სვეტის აღწერილობები
-
მოდელის შეჯამებები
-
წარმომავლობის განმარტებები
-
„რისთვის გამოიყენება ეს ცხრილი?“ - dbt დოკუმენტაციის
ეს იდეალური არ არის, მაგრამ არადოკუმენტირებული მილსადენების წყევლას არღვევს.
4) ხარაჩოების ტესტირება და შემოწმება
ხელოვნურ ინტელექტს შეუძლია შემოგვთავაზოს:
-
ძირითადი ნულოვანი ტესტები
-
უნიკალურობის შემოწმებები
-
რეფერენციული მთლიანობის იდეები
-
„ეს მეტრიკა არასდროს უნდა შემცირდეს“ სტილის მტკიცებები dbt მონაცემთა ტესტები დიდი მოლოდინები: მოლოდინები
კიდევ ერთხელ - თქვენ მაინც წყვეტთ, რა არის მნიშვნელოვანი, მაგრამ ეს აჩქარებს რუტინულ ნაწილებს.
5) მილსადენის „წებოს“ კოდი
კონფიგურაციის შაბლონები, YAML სკაფოლდები, ორკესტრირების DAG-ის დრაფტები. ეს ყველაფერი განმეორებადია და ხელოვნური ინტელექტი საუზმეზე განმეორებადს მიირთმევს 🥣 Apache Airflow DAG-ები
სადაც ხელოვნური ინტელექტი კვლავ იბრძვის (და ეს არის მისი არსი) 🧠🧩
ეს არის ყველაზე მნიშვნელოვანი ნაწილი, რადგან ის რეალური ტექსტურით პასუხობს ჩანაცვლების კითხვას.
1) ბუნდოვანება და ცვალებადი განმარტებები
ბიზნეს ლოგიკა იშვიათად არის მკვეთრი. ადამიანები წინადადების შუაში იცვლებიან აზრს. „აქტიური მომხმარებელი“ ხდება „აქტიური გადამხდელი მომხმარებელი“, ხდება „აქტიური გადამხდელი მომხმარებელი, თანხის დაბრუნების გარდა, გარდა იშვიათი შემთხვევებისა“... თქვენ იცით, როგორ არის საქმე.
ხელოვნურ ინტელექტს არ შეუძლია ამ ორაზროვნების ათვისება. მას მხოლოდ ვარაუდი შეუძლია.
2) ანგარიშვალდებულება და რისკი
როდესაც მილსადენი წყდება და აღმასრულებელი დირექტორის დაფა აბსურდულ ინფორმაციას აჩვენებს, ვიღაცამ უნდა:
-
ტრიაჟი
-
გავლენის კომუნიკაცია
-
შეასწორე
-
რეციდივის თავიდან აცილება
-
დაწერეთ სიკვდილის შემდგომი დასკვნა
-
გადაწყვიტეთ, შეუძლია თუ არა ბიზნესს კვლავ ენდოს გასული კვირის ციფრებს
ხელოვნურ ინტელექტს შეუძლია დახმარება, მაგრამ მას არ შეუძლია მნიშვნელოვანი ანგარიშვალდებულება. ორგანიზაციები არ მოქმედებენ ვიბრაციებით - ისინი პასუხისმგებლობით მოქმედებენ.
3) სისტემური აზროვნება
მონაცემთა პლატფორმები ეკოსისტემებია: მიღება, შენახვა, ტრანსფორმაციები, ორკესტრირება, მმართველობა, ხარჯების კონტროლი, მომსახურების ხელშეკრულებები. ერთ ფენაში ცვლილება გავლენას ახდენს. Apache Airflow-ის კონცეფციები
ხელოვნურ ინტელექტს შეუძლია შემოგვთავაზოს ლოკალური ოპტიმიზაცია, რომელიც გლობალურ პრობლემებს შექმნის. ეს იგივეა, რომ კარის აღებით ჭრიალა კარის შეკეთება მოახდინო 😬
4) უსაფრთხოება, კონფიდენციალურობა, შესაბამისობა
სწორედ აქ კვდება ჩანაცვლების ფანტაზიები.
-
წვდომის კონტროლი
-
რიგის დონის უსაფრთხოება Snowflake-ის რიგებზე წვდომის პოლიტიკა BigQuery-ის რიგის დონის უსაფრთხოება
-
პირადი ინფორმაციის დამუშავება NIST კონფიდენციალურობის ჩარჩოში
-
შენახვის წესები შენახვის შეზღუდვა (ICO) ევროკავშირის სახელმძღვანელო პრინციპები შენახვის შესახებ
-
აუდიტის კვალი NIST SP 800-92 (ჟურნალის მართვა) CIS Control 8 (აუდიტის ჟურნალის მართვა)
-
მონაცემთა რეზიდენტობის შეზღუდვები
ხელოვნურ ინტელექტს შეუძლია პოლიტიკის შემუშავება, მაგრამ მათი უსაფრთხოდ განხორციელება ნამდვილი ინჟინერიაა.
5) „უცნობი უცნობები“
მონაცემთა ინციდენტები ხშირად არაპროგნოზირებადია:
-
გამყიდველის API ჩუმად ცვლის სემანტიკას
-
დროის სარტყლის ვარაუდი იცვლება
-
უკანა შევსება დუბლირებს დანაყოფს
-
ხელახალი ცდის მექანიზმი იწვევს ორმაგ ჩაწერას
-
პროდუქტის ახალი ფუნქცია ახალ მოვლენათა ნიმუშებს წარმოგვიდგენს
ხელოვნური ინტელექტი უფრო სუსტია, როდესაც სიტუაცია ცნობილი კანონზომიერება არ არის.
შედარების ცხრილი: რა რას ამცირებს პრაქტიკაში 🧾🤔
ქვემოთ მოცემულია პრაქტიკული ხედვა. არა „ინსტრუმენტები, რომლებიც ადამიანებს ცვლიან“, არამედ ინსტრუმენტები და მიდგომები, რომლებიც გარკვეულ ამოცანებს ამცირებენ.
| ინსტრუმენტი / მიდგომა | აუდიტორია | ფასის განწყობა | რატომ მუშაობს |
|---|---|---|---|
| ხელოვნური ინტელექტის კოდის თანაპილოტები (SQL + Python-ის დამხმარეები) GitHub-ის თანაპილოტი | ინჟინრები, რომლებიც ბევრ კოდს წერენ | უფასოდან ფასიანამდე | შესანიშნავია სკაფოლდინგში, რეფაქტორებში, სინტაქსში... ზოგჯერ თვითკმაყოფილია ძალიან სპეციფიკური გზით |
| მართული ELT კონექტორები Fivetran | გუნდები დაიღალნენ შეწოვის ტემპის შექმნით | გამოწერა-y | ხსნის ყლაპვის დროს გამოწვეულ ტკივილს, თუმცა ხსნის ახალი, სახალისო გზებით |
| მონაცემთა დაკვირვების პლატფორმები მონაცემთა დაკვირვება (Dynatrace) | ნებისმიერი პირი, ვისაც აქვს მომსახურების გაწევის ხელშეკრულებები (SLA), | საშუალო და საწარმო | ადრეულ ეტაპზე აფიქსირებს ანომალიებს - მაგალითად, მილსადენების კვამლის დეტექტორები 🔔 |
| ტრანსფორმაციის ჩარჩოები (დეკლარაციული მოდელირება) dbt | ანალიტიკა + დეტექტიური ტექნოლოგიის ჰიბრიდები | როგორც წესი, ინსტრუმენტი + გამოთვლა | ლოგიკას მოდულარულს და ტესტირებადს ხდის, ნაკლებად სპაგეტისებურად |
| მონაცემთა კატალოგები + სემანტიკური ფენები dbt სემანტიკური ფენა | ორგანიზაციები მეტრული დაბნეულობით | პრაქტიკაში, დამოკიდებულია | „ჭეშმარიტების“ ერთხელ განსაზღვრა - ამცირებს გაუთავებელ მეტრულ დებატებს |
| ორკესტრირება შაბლონებით Apache Airflow | პლატფორმის მოყვარული გუნდები | ღია + ოპერაციების ღირებულება | სტანდარტიზებს სამუშაო პროცესებს; ნაკლები ფიფქისებრი DAG-ები |
| ხელოვნური ინტელექტის დახმარებით შექმნილი დოკუმენტაციის dbt დოკუმენტების გენერირება | გუნდები, რომლებსაც სძულთ დოკუმენტების წერა | იაფიდან საშუალომდე | ქმნის „საკმარისად კარგ“ დოკუმენტებს, რათა ცოდნა არ გაქრეს |
| ავტომატიზირებული მართვის პოლიტიკა NIST კონფიდენციალურობის ჩარჩო | რეგულირებადი გარემო | საწარმოს ტიპის | ხელს უწყობს წესების აღსრულებას - თუმცა, წესების შესაქმნელად მაინც ადამიანები სჭირდებათ |
ყურადღება მიაქციეთ, რა აკლია: სტრიქონი წარწერით „მონაცემთა ინჟინრების წასაშლელად დააჭირეთ ღილაკს“. დიახ... ეს სტრიქონი არ არსებობს 🙃
მაშ ასე… ხელოვნური ინტელექტი ჩაანაცვლებს მონაცემთა ინჟინრებს, თუ უბრალოდ როლს შეცვლიან? 🛠️
აი, არადრამატული პასუხი: ხელოვნური ინტელექტი სამუშაო პროცესის ნაწილს ჩაანაცვლებს და არა პროფესიას.
მაგრამ ეს მოახდენს . და თუ ამას უგულებელყოფთ, ზეწოლას იგრძნობთ.
რა ცვლილებები:
-
ნაკლები დრო სტანდარტული ვერსიის წერაზე
-
ნაკლები დრო დოკუმენტების მოსაძებნად
-
მეტი დრო განხილვისთვის, დადასტურებისთვის, დიზაინის შესაქმნელად
-
კონტრაქტებისა და ხარისხის მოლოდინების განსაზღვრის მეტი დრო ღია მონაცემების კონტრაქტის სტანდარტის (ODCS) გამოყენებით
-
მეტი დრო პროდუქტებთან, უსაფრთხოებასთან და ფინანსებთან პარტნიორობისთვის
ეს არის დახვეწილი ცვლილება: მონაცემთა ინჟინერია ნაკლებად ეხება „მილსადენების მშენებლობას“ და უფრო მეტად ეხება „საიმედო მონაცემთა პროდუქტის სისტემის შექმნას“
და ერთი სიტყვით, ეს უფრო ღირებულია და არა ნაკლები.
ასევე - და ამას ვიტყვი, მიუხედავად იმისა, რომ დრამატულად ჟღერს - ხელოვნური ინტელექტი ზრდის იმ ადამიანების რაოდენობას, რომლებსაც შეუძლიათ მონაცემთა არტეფაქტების შექმნა , რაც ზრდის საჭიროებას, რომ ვინმემ მთელი ეს საკითხი გონივრულად შეინარჩუნოს. მეტი გამომავალი ნიშნავს მეტ პოტენციურ დაბნეულობას. GitHub-ის თანაპილოტი
ეს ყველას ელექტრობურღის მიცემას ჰგავს. შესანიშნავია! ახლა ვიღაცამ უნდა აღასრულოს წესი „გთხოვთ, წყლის მილში არ გაბურღოთ“ 🪠
ახალი უნარების დასტა, რომელიც ღირებული რჩება (მაშინაც კი, როცა ხელოვნური ინტელექტი ყველგან არის) 🧠⚙️
თუ გსურთ პრაქტიკული, „მომავლისთვის მზად“ საკონტროლო სია, ის ასე გამოიყურება:
სისტემის დიზაინის აზროვნება
-
მონაცემთა მოდელირება, რომელიც ცვლილებებს უძლებს
-
პარტიული და სტრიმინგის კომპრომისები
-
შეყოვნება, ღირებულება, საიმედოობაზე ფიქრი
მონაცემთა ხარისხის ინჟინერია
-
კონტრაქტები, ვალიდაციები, ანომალიების აღმოჩენა; ღია მონაცემთა კონტრაქტის სტანდარტი (ODCS); მონაცემთა დაკვირვებადობა (Dynatrace).
-
მომსახურების ხარისხის შეთანხმებები (SLA), მომსახურების ხარისხის შეთანხმებები (SLO), ინციდენტებზე რეაგირების ჩვევები
-
ძირეული მიზეზის ანალიზი დისციპლინით (და არა ვიბრაციებით)
მმართველობა და ნდობის არქიტექტურა
-
წვდომის შაბლონები
-
აუდიტირება NIST SP 800-92 (ჟურნალის მართვა)
-
კონფიდენციალურობა დიზაინით NIST კონფიდენციალურობის ჩარჩო
-
მონაცემთა სასიცოცხლო ციკლის მართვა ევროკავშირის სახელმძღვანელო პრინციპები შენახვის შესახებ
პლატფორმული აზროვნება
-
მრავალჯერადი გამოყენების შაბლონები, ოქროს ბილიკები
-
სტანდარტიზებული შაბლონები მიღების, ტრანსფორმაციების, ტესტირებისთვის და Fivetran dbt მონაცემთა ტესტებისთვის
-
თვითმომსახურების ხელსაწყოები, რომლებიც არ დნება
კომუნიკაცია (დიახ, ნამდვილად)
-
გამჭვირვალე დოკუმენტების წერა
-
განმარტებების გასწორება
-
თავაზიანად, მაგრამ მტკიცედ „არას“ თქმა
-
კომპრომისების ახსნა რობოტის ჟღერადობის გარეშე 🤖
თუ ამის გაკეთებას შეძლებთ, კითხვა „ჩაანაცვლებს თუ არა ხელოვნური ინტელექტი მონაცემთა ინჟინრებს?“ ნაკლებად საშიში ხდება. ხელოვნური ინტელექტი თქვენი ეგზოსკელეტი ხდება და არა თქვენი შემცვლელი.
რეალისტური სცენარები, სადაც მონაცემთა ინჟინერიის ზოგიერთი როლი მცირდება 📉
კარგი, რეალობის სწრაფი შემოწმება, რადგან ყველაფერი მზის შუქითა და ემოჯი კონფეტით არ შემოიფარგლება 🎉
ზოგიერთი როლი უფრო გამოკვეთილია:
-
მხოლოდ გადაყლაპვის როლები, სადაც ყველაფერი სტანდარტული კონექტორებია Fivetran კონექტორები
-
გუნდები ძირითადად განმეორებითი ანგარიშგების არხებს აწარმოებენ მინიმალური დომენური ნიუანსებით
-
ორგანიზაციები, სადაც მონაცემთა ინჟინერიას „SQL მაიმუნებად“ მიიჩნევენ (მკაცრი, მაგრამ სიმართლეა)
-
დაბალი საკუთრების მქონე პოზიციები, სადაც სამუშაო მხოლოდ ბილეთები და კოპირება-ჩასმაა
ხელოვნურ ინტელექტს და მართულ ინსტრუმენტებს შეუძლიათ ამ საჭიროებების შემცირება.
მაგრამ იქაც კი, ჩანაცვლება ჩვეულებრივ ასე გამოიყურება:
-
ნაკლები ადამიანი ასრულებს ერთსა და იმავე განმეორებად სამუშაოს
-
მეტი აქცენტი პლატფორმის საკუთრებასა და საიმედოობაზე
-
გადასვლა მიმართულებით „ერთ ადამიანს შეუძლია მეტი მილსადენის მხარდაჭერა“
ასე რომ, დიახ - დასაქმებულთა რაოდენობის სქემა შეიძლება შეიცვალოს. როლები იცვლება. ტიტულები იცვლება. ეს ნაწილი რეალურია.
მიუხედავად ამისა, როლის მაღალი საკუთრებისა და ნდობის ვერსია შენარჩუნებულია.
დასკვნითი შეჯამება 🧾✅
ჩაანაცვლებს თუ არა ხელოვნური ინტელექტი მონაცემთა ინჟინრებს? არა ისე, როგორც ხალხს წარმოუდგენია.
ხელოვნური ინტელექტი გააკეთებს:
-
განმეორებითი დავალებების ავტომატიზაცია
-
კოდირების, გამართვისა და დოკუმენტაციის დაჩქარება GitHub Copilot SQL dbt დოკუმენტაციისთვის
-
მილსადენების წარმოების ღირებულების შემცირება
მაგრამ მონაცემთა ინჟინერია ფუნდამენტურად ეხება:
-
ანგარიშვალდებულება
-
სისტემის დიზაინი
-
ნდობა, ხარისხი და მმართველობა ღია მონაცემთა კონტრაქტის სტანდარტი (ODCS) NIST კონფიდენციალურობის ჩარჩო
-
ბუნდოვანი ბიზნეს რეალობის სანდო მონაცემთა პროდუქტებად გადაქცევა
ხელოვნურ ინტელექტს შეუძლია ამაში დახმარება... მაგრამ ის ამას „არ ფლობს“.
თუ თქვენ მონაცემთა ინჟინერი ხართ, ნაბიჯი მარტივია (არც ისე ადვილი, მაგრამ მარტივია):
ყურადღება გაამახვილეთ საკუთრებაზე, ხარისხზე, პლატფორმულ აზროვნებასა და კომუნიკაციაზე. მიეცით ხელოვნურ ინტელექტს საშუალება, რომ სტანდარტული სამუშაო გარემო მოაგვაროს, თქვენ კი მნიშვნელოვანი ნაწილებით იხელმძღვანელოთ.
და კი - ზოგჯერ ეს ნიშნავს, რომ ოთახში ზრდასრული ადამიანი ხარ. არა მომხიბვლელი. თუმცა, საკმაოდ ძლიერი 😄
ჩაანაცვლებს თუ არა ხელოვნური ინტელექტი მონაცემთა ინჟინრებს?
ის ჩაანაცვლებს ზოგიერთ დავალებას, გადააადგილებს სამსახურს და საუკეთესო მონაცემთა ინჟინრებს კიდევ უფრო ღირებულს გახდის. ეს არის რეალური ისტორია.
ხშირად დასმული კითხვები
ხელოვნური ინტელექტი მთლიანად ჩაანაცვლებს მონაცემთა ინჟინრებს?
უმეტეს ორგანიზაციებში ხელოვნური ინტელექტი უფრო მეტად კონკრეტული ამოცანების შესრულებას ცდილობს, ვიდრე როლის მთლიანად წაშლას. მას შეუძლია დააჩქაროს SQL-ის ნახატი, პროცესორის სკაფოლდირება, დოკუმენტაციის პირველი გავლა და საბაზისო ტესტების შექმნა. თუმცა, მონაცემთა ინჟინერია ასევე გულისხმობს საკუთრებისა და პასუხისმგებლობის აღებას, პლუს არასაინტერესო სამუშაოს, რომელიც არეულ-დარეული ბიზნეს რეალობის საიმედო სისტემად წარმოჩენას გულისხმობს. ამ ნაწილებს ჯერ კიდევ სჭირდებათ ადამიანები, რათა გადაწყვიტონ, როგორ გამოიყურება „სწორი“ და აიღონ პასუხისმგებლობა, როდესაც რაღაც იშლება.
მონაცემთა ინჟინერიის რომელ ნაწილებს ავტომატიზირებს უკვე ხელოვნური ინტელექტი?
ხელოვნური ინტელექტი საუკეთესოდ ასრულებს განმეორებად სამუშაოს: SQL-ის შედგენასა და რეფაქტორიზაციას, მონაცემთა ბაზის მოდელის ჩონჩხების გენერირებას, გავრცელებული შეცდომების ახსნას და დოკუმენტაციის მონახაზების შექმნას. მას ასევე შეუძლია ტესტების, როგორიცაა ნულის ან უნიკალურობის შემოწმება, და შაბლონის „წებოს“ კოდის გენერირება ორკესტრაციის ხელსაწყოებისთვის. გამარჯვება იმპულსშია - თქვენ იწყებთ სამუშაო გადაწყვეტასთან უფრო ახლოს - მაგრამ მაინც უნდა დაადასტუროთ სისწორე და დარწმუნდეთ, რომ ის თქვენს გარემოს შეესაბამება.
თუ ხელოვნურ ინტელექტს შეუძლია SQL-ისა და მილსადენების დაწერა, რა რჩება მონაცემთა ინჟინრებს?
ბევრი რამ: მონაცემთა კონტრაქტების განსაზღვრა, სქემების დრიფტის მართვა და იმის უზრუნველყოფა, რომ მილსადენები იყოს იდემპოტენტი, დაკვირვებადი და აღდგენადი. მონაცემთა ინჟინრები დროს ხარჯავენ მეტრული ცვლილებების შესწავლაზე, შემდგომი მომხმარებლებისთვის დამცავი ბარიერების აგებასა და ხარჯებისა და საიმედოობის კომპრომისების მართვაზე. სამუშაო ხშირად ნდობის მოპოვებასა და მონაცემთა პლატფორმის „მშვიდად“ შენარჩუნებაზე, რაც ნიშნავს, რომ არავის უწევს ამაზე ყოველდღიურად ფიქრი.
როგორ ცვლის ხელოვნური ინტელექტი მონაცემთა ინჟინრის ყოველდღიურ მუშაობას?
როგორც წესი, ის ამცირებს სტანდარტული და „ძიების დროს“, ამიტომ ნაკლებ დროს ხარჯავთ აკრეფაზე და მეტს - განხილვაზე, დადასტურებასა და დიზაინზე. ეს ცვლილება როლს უბიძგებს მოლოდინების, ხარისხის სტანდარტებისა და მრავალჯერადი გამოყენების ნიმუშების განსაზღვრისკენ, ყველაფრის ხელით კოდირების ნაცვლად. პრაქტიკაში, თქვენ, სავარაუდოდ, მეტ პარტნიორულ მუშაობას განახორციელებთ პროდუქტთან, უსაფრთხოებასთან და ფინანსებთან დაკავშირებით - რადგან ტექნიკური შედეგის შექმნა უფრო ადვილი ხდება, მაგრამ მართვა უფრო რთული.
რატომ უჭირს ხელოვნურ ინტელექტს ისეთი ორაზროვანი ბიზნესის განმარტებების გამოყენება, როგორიცაა „აქტიური მომხმარებელი“?
რადგან ბიზნეს ლოგიკა არ არის სტატიკური ან ზუსტი - ის იცვლება პროექტის შუაში და განსხვავდება დაინტერესებული მხარეების მიხედვით. ხელოვნურ ინტელექტს შეუძლია ინტერპრეტაციის შედგენა, მაგრამ მას არ შეუძლია გადაწყვეტილების მიღება, როდესაც განმარტებები იცვლება ან კონფლიქტი ჩნდება. მონაცემთა ინჟინერია ხშირად მოითხოვს მოლაპარაკებებს, ვარაუდების დოკუმენტირებას და ბუნდოვანი მოთხოვნების მდგრად კონტრაქტებად გადაქცევას. სწორედ „ადამიანური გასწორების“ სამუშაოა მთავარი მიზეზი, რის გამოც ეს როლი არ ქრება ინსტრუმენტების გაუმჯობესების მიუხედავად.
შეუძლია თუ არა ხელოვნურ ინტელექტს მონაცემთა მართვის, კონფიდენციალურობისა და შესაბამისობის სამუშაოების უსაფრთხოდ მართვა?
ხელოვნურ ინტელექტს შეუძლია დაეხმაროს პოლიტიკის შემუშავებაში ან მიდგომების შეთავაზებაში, თუმცა უსაფრთხო განხორციელება მაინც მოითხოვს რეალურ ინჟინერიას და ფრთხილ ზედამხედველობას. მმართველობა მოიცავს წვდომის კონტროლს, პირადი ინფორმაციის დამუშავებას, შენახვის წესებს, აუდიტის კვალს და ზოგჯერ რეზიდენტობის შეზღუდვებს. ეს არის მაღალი რისკის სფეროები, სადაც „თითქმის სწორი“ მიუღებელია. ადამიანებმა უნდა შეიმუშაონ წესები, გადაამოწმონ აღსრულება და დარჩნენ პასუხისმგებელნი შესაბამისობის შედეგებზე.
რა უნარები რჩება ღირებული მონაცემთა ინჟინრებისთვის ხელოვნური ინტელექტის გაუმჯობესებისას?
უნარ-ჩვევები, რომლებიც სისტემებს მდგრადს ხდის: სისტემური დიზაინის აზროვნება, მონაცემთა ხარისხის ინჟინერია და პლატფორმაზე ორიენტირებული სტანდარტიზაცია. კონტრაქტები, დაკვირვებადობა, ინციდენტებზე რეაგირების ჩვევები და დისციპლინირებული ძირეული მიზეზების ანალიზი კიდევ უფრო მნიშვნელოვანი ხდება, როდესაც მეტ ადამიანს შეუძლია მონაცემთა არტეფაქტების სწრაფად გენერირება. კომუნიკაცია ასევე განმასხვავებელი ფაქტორი ხდება - განმარტებების შესაბამისობა, მკაფიო დოკუმენტების დაწერა და კომპრომისების ახსნა დრამის გარეშე მონაცემების სანდოობის შენარჩუნების დიდი ნაწილია.
რომელი მონაცემთა ინჟინერიის პოზიციებია ყველაზე მეტად რისკის ქვეშ ხელოვნური ინტელექტისა და მართული ინსტრუმენტებისგან?
განმეორებითი ინჰალაციის ან სტანდარტული ანგარიშგების მილსადენებზე ვიწროდ ორიენტირებული როლები უფრო დაუცველია, განსაკუთრებით მაშინ, როდესაც მართული ELT კონექტორები მოიცავს წყაროების უმეტესობას. დაბალი პასუხისმგებლობის, ბილეთებზე დაფუძნებული სამუშაო შეიძლება შემცირდეს, რადგან ხელოვნური ინტელექტი და აბსტრაქცია ამცირებს თითოეული მილსადენის ძალისხმევას. თუმცა, როგორც წესი, ეს უფრო ნაკლები ადამიანის მიერ განმეორებითი ამოცანების შესრულების შთაბეჭდილებას ტოვებს და არა „მონაცემთა ინჟინრების არარსებობას“. მაღალი პასუხისმგებლობის მქონე როლები, რომლებიც ორიენტირებულია საიმედოობაზე, ხარისხსა და ნდობაზე, გამძლე რჩება.
როგორ უნდა გამოვიყენო ისეთი ინსტრუმენტები, როგორიცაა GitHub Copilot ან dbt ხელოვნური ინტელექტით, ქაოსის შექმნის გარეშე?
ხელოვნური ინტელექტის მიერ მიღებულ მონაცემებს განიხილეთ როგორც პროექტი და არა როგორც გადაწყვეტილება. გამოიყენეთ ის შეკითხვის ჩონჩხების გენერირებისთვის, წაკითხვის გასაუმჯობესებლად ან მონაცემთა ბაზის ტესტებისა და დოკუმენტების დასაფუძნებლად, შემდეგ კი რეალურ მონაცემებთან და უპირატეს შემთხვევებთან ვალიდაციისთვის. შეადარეთ ის ძლიერ კონვენციებს: კონტრაქტებს, დასახელების სტანდარტებს, დაკვირვებადობის შემოწმებას და მიმოხილვის პრაქტიკას. მიზანია უფრო სწრაფი მიწოდება საიმედოობის, ხარჯების კონტროლის ან მმართველობის შეწირვის გარეშე.
ცნობები
-
ევროკომისია - მონაცემთა დაცვის განმარტება: GDPR პრინციპები - commission.europa.eu
-
ინფორმაციის კომისრის ოფისი (ICO) - შენახვის შეზღუდვა - ico.org.uk
-
ევროკომისია - რამდენ ხანს შეიძლება მონაცემების შენახვა და აუცილებელია თუ არა მათი განახლება? - commission.europa.eu
-
სტანდარტებისა და ტექნოლოგიების ეროვნული ინსტიტუტი (NIST) - კონფიდენციალურობის ჩარჩო - nist.gov
-
NIST-ის კომპიუტერული უსაფრთხოების რესურსების ცენტრი (CSRC) - SP 800-92: კომპიუტერული უსაფრთხოების ჟურნალების მართვის სახელმძღვანელო - csrc.nist.gov
-
ინტერნეტ უსაფრთხოების ცენტრი (CIS) - აუდიტის ჟურნალის მართვა (CIS კონტროლი) - cisecurity.org
-
Snowflake-ის დოკუმენტაცია - რიგებზე წვდომის პოლიტიკა - docs.snowflake.com
-
Google Cloud-ის დოკუმენტაცია - BigQuery-ის რიგის დონის უსაფრთხოება - docs.cloud.google.com
-
BITOL - ღია მონაცემების კონტრაქტის სტანდარტი (ODCS) v3.1.0 - bitol-io.github.io
-
BITOL (GitHub) - ღია მონაცემების კონტრაქტის სტანდარტი - github.com
-
Apache Airflow - დოკუმენტაცია (სტაბილური) - airflow.apache.org
-
Apache Airflow - DAG-ები (ძირითადი კონცეფციები) - airflow.apache.org
-
dbt Labs-ის დოკუმენტაცია - რა არის dbt? - docs.getdbt.com
-
dbt Labs-ის დოკუმენტაცია - dbt მოდელების შესახებ - docs.getdbt.com
-
dbt Labs-ის დოკუმენტაცია - დოკუმენტაცია - docs.getdbt.com
-
dbt Labs დოკუმენტაცია - მონაცემთა ტესტები - docs.getdbt.com
-
dbt Labs-ის დოკუმენტაცია - dbt სემანტიკური ფენა - docs.getdbt.com
-
Fivetran-ის დოკუმენტაცია - დაწყება - fivetran.com
-
Fivetran - კონექტორები - fivetran.com
-
AWS დოკუმენტაცია - AWS Lambda-ს დეველოპერის სახელმძღვანელო - docs.aws.amazon.com
-
GitHub - GitHub-ის თანაპილოტი - github.com
-
GitHub Docs - კოდის შემოთავაზებების მიღება თქვენს IDE-ში GitHub Copilot-ის გამოყენებით - docs.github.com
-
Microsoft Learn - GitHub Copilot SQL-ისთვის (VS Code გაფართოება) - learn.microsoft.com
-
Dynatrace-ის დოკუმენტაცია - მონაცემთა დაკვირვებადობა - docs.dynatrace.com
-
DataGalaxy - რა არის მონაცემთა დაკვირვებადობა? - datagalaxy.com
-
დიდი მოლოდინების დოკუმენტაცია - მოლოდინების მიმოხილვა - docs.greatexpectations.io