Data Scientists і Data Engineers: особливості роботи з даними

💡 Усі статті, обговорення, новини для початківців — в одному місці. Приєднуйтесь до Junior спільноти!

Привіт, мене звати Оля Назаренко, наразі я Lead DW/BI Engineer у SoftServe. Працюю з даними вже понад 10 років і за цей час була також Data Analyst і Data Scientist. На одному з проєктів, де моя роль починалася з обов’язків Data Scientist, реальність виявилася, як на малюнку нижче, — і мені довелося дуже оперативно освоювати нове для себе поле data engineering.

З того часу тема різноманіття спеціальностей, які працюють з даними, мене зачепила, і я стала уважно аналізувати потреби проєкту, виокремлювати сфери відповідальності й необхідний набір навичок для успішної роботи. Я задумалася про переваги і недоліки цієї спеціалізації у нашій сфері. Адже колись весь процес аналізу даних могла виконувати одна людина в Excel. Життя її було непростим, але принаймні не доводилося витрачати півдня на координацію.

Наразі ми користуємося досить складними й різноманітним інструментами на кожному етапі (у кожній сфері) проєкту. І це призводить до більшої спеціалізації, з одної сторони, і більших зусиль на комунікацію — з іншої, адже тепер один в полі даних не воїн. Також через спеціалізацію люди часто не бачать загальної картинки продукту, що будується, і не відчувають зв’язку між своєю роботою і кінцевим результатом, що негативно впливає на мотивацію.

Особливості роботи з даними. Загальна картина

Мені сподобалася ієрархія потреб у роботі з даними, створена Монікою Рогатті. Вона гарно відображає у собі основні етапи роботи з даними, відповідні активності та ролі, які їх виконують.

Діаграма гарно доносить ідею про пріоритетність залучення спеціалістів з базових рівнів на самому початку проєкту, адже без надійного фундаменту не буде змоги добратися до вершини. Також видно, що всі зазначені спеціальності гребуть в одному човні і від їхньої якісної взаємодії і взаєморозуміння залежить успіх проєкту.

Чого мені бракує в цій схемі, так це:

• відображення взаємодії між різними рівнями піраміди та відповідно людьми на відповідних посадах, адже в реальності ця піраміда дуже динамічна, різні рівні повинні мати можливість комунікувати між собою ефективно. І щоб ця система трималася купи, важливим є впровадження і якісних бізнес процесів, і процесів розробки та комунікацій;
• відсутність ролі розпорядника даних (Data Steward). Я цілком припускаю, що для розробки та запуску data-продукту може бути достатньо описаних у піраміді ролей, але впевнена, щоб цей «data-потяг» безпечно рухався далі своїх шляхом, без розпорядника даних не обійтись.

Типи data-ролей

У статті Guide to Data Roles гарно описано навички, необхідні для кожної спеціальності.

Отже розгляньмо детальніше різні ролі і їхні навички.

Почнемо з Data Engineers, які мають створити фундамент для роботи своїх колег — забезпечити притік, зберігання й оновлення потрібних даних. Це виражається в побудові пайплайнів і релевантних сховищ даних.

Діяльність Data Scientist наразі передбачається в основному в моделюванні, експериментуванні та пошуку інсайтів з даних. Тобто саме ці люди комунікують з Product Owner, щоб зрозуміти проблеми бізнесу й ідентифікувати математичні моделі, які можуть допомогти у їхньому вирішенні. Потім беруть дані, які підготували Data Engineers й застосовують до них моделі. Потім ще багато-пребагато експериментують і налаштовують свої моделі, після чого діляться результатами для подальшого їхнього застосування в рішеннях чи розробці продукту.

ML Engineer найчастіше займається підбором і налаштуванням уже розроблених моделей, також можуть відповідати за розгортання необхідної інфраструктури, подальше вбудування моделей у продукт.

Аналітики даних зосереджені на пошуку інсайтів у самих даних і подальшій презентації своїх знахідок стейкхолдерам (зацікавленим особам). На мою думку, їхня роль полягає у забезпеченні підтримки рішень команди на основі даних.

Є окрема категорія спеціалістів DW/BI Engineers, які працюють над створенням аналітичних баз даних і розробкою необхідних зручних інтерфейсів для користувачів для подальшого споживання даних, результатів застосування моделей чи звичайного моніторингу роботи відповідних систем.

Красива квіточка картинка виходить, якщо поєднати всіх описаних спеціалістів в одну діаграму 😊.

На жаль, у цій системі також не відображена роль розпорядника даних, але як на мене, саме ця роль має стати тим стеблом, на якому триматиметься «квіточка data-продукту».

Проблеми комунікації

Конфлікти між членами команди часто виникають через різницю у їхніх ролях, підходах до роботи та очікуваннях.

Багато точок зіткнення можна звести до таких пунктів:

• Отримання даних чи налаштування оновлення даних. Важливо розрізняти одноразові запити на отримання певних даних і необхідність розробити інфраструктуру для їхнього постійного потоку й оновлення. Перший вид запитів може бути задачею кількох хвилин чи годин і може виконануватися досить швидко в рамках закладеного у спринт часу на технічне обслуговування (maintenance) продукту.
  Другий передбачає повний цикл розробки потоку даних, який може займати частину чи кілька спринтів. Досить часто розробка потоку починається саме з отримання екземпляру даних, який досліджують і визначають: чи відповідає він вимогам, чи вимагає змін. Завчасна задача на налаштування потоку даних з непідтвердженою структурою призводить до неефективного витрачання часу.
• Характер зміни даних в часі. Важливо розбиратися в природі даних, щоб правильно налаштувати їхню динаміку для уникнення непорозумінь щодо їхнього використання і споживання. Це питання багатогранне і вимагає глибокого розуміння, тому залучення бізнес аналітиків і SME (subject matter expert) є важливим. Якщо ви отримуєте запит створити статичну табличку / довідник — не вірте. У більшості випадків за ними ховається непахане поле прояснень хто / де / коли / як буде оновлювати ці дані. Але якщо не зануритися у це на березі, то ризик неактуальності створеного продукту стрімко зростатиме. Іноді рішенням може бути впровадження MDM (master data management) інструменту, який надасть інтерфейс для менеджменту даних самим Data Steward.
• Типи і формати даних на вході і виході, та і загалом що детальніше описані вимоги, то менше лишається місця для непорозумінь. Також важливим є спільне уявлення про якість даних — вимоги до даних і фактичний стан речей. Але змін не уникнути, тому варто сприймати запити як шлях самурая і тішитися, що з кожним закритим завданням продукт наближається до ідеалу :)
• Процес розробки коду та його продактуалізації. Data Scientist багато часу витрачає на експерименти та розробку моделей. Розроблений код потім часто переписується більш ресурсоефективними мовами для деплойменту в продакшн. У розробці модель намагаються зробити якомога точнішою. Коли її додають у продукт, вона ще й має працювати максимально швидко. На цій основі також може виникати багато непорозумінь за відсутності відлагоджених процесів і екосистеми.
• І купа інших питань, що притаманні взаємодії у будь-якій команді.

Якось я співбесідувала Data Engineer і мала необачність поцікавитися, чи був досвід роботи з Data Science-проєктами, на що отримала обурливе: «О так, це просто жах! Ці Data Scientists навіть не розуміють, що якщо я пишу пайплайн для CSV-файла, збереженого у Windows, то він не працюватиме для CSV-файла, збереженого у Mac». Описана ситуація, звичайно, комічна, але вона показує, наскільки важливе прояснення найменших деталей.

Як полегшити життя собі та команді

Спробуймо розібратися, що нам може допомогти з нівелюванням описаних гострих кутів:

• спільна методологія розробки з регулярною, узгодженою з усіма комунікацією (відеозустрічі, електронні листи, чати);
  
• пріоритезувати чистий код і документацію. Це речі, які уповільнюють розробку короткостроково, але на довгостроковому горизонті вони критично пришвидшують «обмін знаннями» і зменшують ймовірність конфліктів;
• спільна платформа розробки, яка містить управління версіями. Зараз існує вибір платформ, які дозволяють організувати роботу кожної з описаних ролей в межах одного простору. З іншого боку, існує багато спеціалізованих середовищ. На мою думку, навіть якщо вартість спільної платформи буде вищою, спрощені процеси комунікації й обміну артефактами принесуть (потенційно) вищу нематеріальну вигоду компанії;
• наявність ролі / функцій розпорядника даних за певною людиною. Ця роль може бути суміжною для якоїсь людини, але вона має бути сформульована і закріплена за людиною, з наданими необхідними ресурсами і повноваженнями для її виконання;
• якісна екологічна комунікація всередині команди і зовні, колегіальне ухвалення рішень, налаштованість на принесення користі проєкту / компанії всіма учасниками. Хоча я зазначаю цей пункт останнім, це не означає, що він менш важливий за інші. Навіть навпаки. Якщо серед усього зазначеного існуватиме тільки він, то перші пункти рано чи пізно з’являться.

Ну й на останок хочеться нагадати:

І побажати: MAY THE ACCURATE, COMPLETE, RELIABLE, RELEVANT, AND TIMELY DATA BE WITH YOU 😊