[Про автора: Богдан Павлишенко — Data Scientist в компанії SoftServe (Business Systems), доцент (канд.фіз.-мат. наук) факультету електроніки та комп’ютерних технологій у Львівському національному університеті імені Івана Франка, а також займається науковою роботою в області аналізу даних (LinkedIn, блог)]
Біля пам’ятника Т.Шевченку у Вашингтоні
Data Science, Big Data, Predictive Analytics, Machine Learning — популярні тренди у сучасних інформаційних технологіях. Посади спеціалістів з аналізу даних стали одними із найбажаніших в ІТ-секторі. З’явилась велика кількість Data Scientists та популяризаторів цього напрямку, які розказують про фантастичні можливості сучасного аналізу даних, машинного навчання, зокрема, нейронних мереж.
Цього року я брав участь у двох науково-практичних конференцій в області аналізу даних: Data Stream Mining & Processing (August
Також я є учасником змагань з аналізу даних на платформі Kaggle, де у складі команди виграв змагання Grupo Bimbo Inventory Demandз прогнозування попиту товарів, отримавши перше місце серед майже 2000 учасників (наш розв’язок тут).
Як Data Scientist у SoftServe (Business Systems) я маю справу із прикладними задачами аналізу даних, бізнес-аналітикою, зокрема, прогнозуванням продажів, аналізом факторів, які впливають на попит товарів, поведінкою споживачів товарів та послуг, fraud detection тощо. Коло моїх наукових інтересів пов’язане із Machine Learning, аналізом текстових масивів та слабоструктурованих даних, аналізом соціальних мереж, зокрема, прогнозуванням подій на основі потоків даних у соціальних мережах.
Все це дало мені змогу побачити різні аспекти аналізу даних, спілкуватись із широкими колами спеціалістів зі всього світу на конфереціях, на платформі Kaggle, а також з реальними замовниками аналізу даних. Хочу поділитись своїм баченням цього напрямку інформаційних технологій.
Про спеціалістів з аналізу даних
Дехто вважає, щоб стати Data Scientist, достатньо вивчити один або декілька засобів аналізу даних, таких як R або Python із відповідними пакетами. Насправді, аналіз даних — це в першу чергу розуміння даних, їхньої статистики та відповідних алгоритмів аналізу. Без такого розуміння ніякого якісного аналізу не вийде. І для цього потрібно мати як мінімум фундаментальну базу математичних знань на рівні вищої фізико-математичної або технічної освіти, на основі якої можна вивчити відповідні алгоритми з машинного навчання, регресії чи статистичної обробки.
З іншої сторони, від вузівської спільноти можна почути, ніби основне — це алгоритми, методи та підходи, а мови програмування постійно змінюються, тому, знаючи методи та алгоритми, завжди можна реалізувати аналіз даних на C чи Паскалі. Із цим я також не погоджуюсь.
Звичайно, теоретично можна написати складну програму з аналізу даних, однак, якщо ваша модель складається із тисяч рівнянь, а історичних даних для аналізу є десятки гігабайт, тоді знаючи лише алгоритми, розробити програмне забезпечення з перших принципів практично неможливо, враховуючи часові рамки проекту з аналізу даних та складність складових частин аналізу.
Реальний аналіз даних складається не з одного алгоритму, а з багаторівневої комбінації різних алгоритмів та підходів. Тому виходом є використання спеціалізованих середовищ, зокрема програмного середовища R та відповідних пакетів. Аналізуючи реальні дані великих розмірів, виникають різні проблемні моменти, які наперед не є очевидними, зокрема, ефекти перенавчання (overfitting), які значною мірою визначені структурою та областю знань аналізованих даних. Значний об’єм роботи в аналізі даних полягає у вирішенні конкретних рутинних проблем, як, наприклад, об’єднання даних із різних джерел, очистка даних, виявлення випадкових значень, не властивих аналізованому процесу, заповнення невідомих даних найбільш ймовірними значеннями, завантаження та робота з даними у хмаркових сервісах, різного роду агрегація даних тощо.
Інколи зустрічаю серед спеціалістів таку думку, що науковець по даних лише генерує ідеї, на реалізацію яких у нього просто немає часу. Для реалізації нібито існують інженери, які всі його ідеї реалізують у коді. Це також хибна позиція. На практиці ніхто вам не реалізує ваші ідеї. Науковець по даних повинен сам реалізовувати свої ідеї в коді, як мінімум на рівні працюючого прототипу. Він сам повинен отримувати числа, розподіли, розпізнавати патерни, кластеризувати та класифікувати надані йому десятки гігабайт даних. Максимум, що він може просити — це надати йому дані у зручному вигляді, наприклад у текстовому форматі з відповідними розділювачами між полями. Подальша робота з даними, об’єднання фреймів даних за відповідними ключами, очистка даних, агрегування даних, генерація нових ознак лягає на його плечі.
Спеціаліст по аналізу даних повинен поєднувати в собі як науковця зі знанням математики, відповідних алгоритмів та методів, так і програміста, який володіє мовами програмування та спеціалізованими пакетами по обробці та аналізу даних.
Одним із основних завдань науковця з аналізу даних є проведення такої трансформації даних, яка дала б можливість побачити нові закономірності, наприклад, у діяльності компанії, поведінці клієнтів чи динаміці кількісних показників, і прийняти відповідні рішення в управлінні відповідними бізнес процесами компанії. Які саме трансформації необхідно провести визначається власним досвідом спеціаліста і часто не є очевидними наперед. Потрібно багато експериментувати з конкретними даними, щоб побачити цікаві структурні закономірності та отримати інсайти. З великої кількості проведених аналітичних досліджень часто відбирають лише декілька, які можуть бути корисними. Тому Data Science містить значну експериментальну складову, для якої необхідно володіти як предметною областю аналізу, так і програмними засобами роботи з даними.
Про конференцію Big Data 2016
Конференція 2016 IEEE International Conference on Big Data проходила з 5 по 8 грудня у Вашингтоні у готелі Hyatt поруч із Капітолієм. Багато чим всі наукові конференції, у тому числі українські, подібні між собою за організаційними моментами, дружньою атмосферою, стилем доповідей та дискусій. На цій конференції було багато як науковців, так і представників технологічних компаній та урядових структур. Не всі учасники мали доповіді, багато учасників приїхали послухати доповіді та взяти участь у дискусіях. Із програмою та матеріалами можна ознайомитись на сайті конференції. Я отримав грант на поїздку на цю конференцію від компанії Bosch (більше інформації тут), а також підтримку від компанії SoftServe (Business Systems). Доповідав на симпозіумі Symposium on Data Analytics for Advanced Manufacturing, який проходив у рамках конференції. Тема моєї доповіді «Machine Learning, Linear and Bayesian Models for Logistic Regression in the Failure Detection Problems» (pdf-файл).
Конференція BigData 2016. Доповідає M. Stonebraker(M. Stonebraker, D. Deng and M. L. Brodie, Database Decay and How to Avoid It)
Конференція BigData 2016. Слайд із доповіді Dr. Frank W.Gayle, Advanced Manufacturing National Program Office (AMNPO), NIST
Одна із стендових доповідей на конференції BigData 2016
Про кваліфікаційний рівень Data Scientist та змагання Kaggle
Гостро стоїть питання про кількісний вимір кваліфікаційного рівня спеціаліста з аналізу даних. Часто про свій рівень заявляють самі спеціалісти. Не показуючи при цьому результатів своїх досліджень, посилаючись на договір про нерозголошення. І часто оточуючі судять про їх кваліфікацію, опираючись на впевненість поведінки і частоту та кількість вживаних термінів із області аналізу даних. Теорія сучасного Data Science не є надто складною, в той же час успіх аналізу даних значною мірою визначається власним досвідом та інтуїцією спеціаліста, його обізнаністю у предметній області аналізу.
Цей суб’єктивізм в основному і визначає значимість посади науковця з аналізу даних. При однакових використаних алгоритмах та даних один спеціаліст може дати суттєво більше інформації необхідної для прийняття рішень, ніж інший. Тому важливо знайти кількісні характеристики експертного рівня компетентності спеціаліста.
На мою думку, найбільш об’єктивними характеристиками такого типу можуть бути рейтинг та здобутки спеціаліста на загально визнаних платформах з аналізу даних. Однією з таких платформ є Kaggle. На цій платформі різні компанії дають свої завдання з аналізу даних широким колам спеціалістів із усього світу. І запропоновані розв’язки часом мають складові елементи більш ефективні, ніж розв’язки власних спеціалістів цих компаній.
Сайт Kaggle.com
У декого виникає питання: «А який резон серйозним спеціалістам світового рівня брати участь у таких змаганнях, адже призові отримують лише переважно перші три команди, а участь у змаганні можуть брати декілька тисяч?» Справа у тому, що ви маєте можливість спробувати свої методи на реальних даних із бізнесу, а з іншого боку система Kaggle оцінює результати вашого моделювання і виставляє вам рейтинг, який базується на ваших результатах. Цей рейтинг і є одним з найбільших стимулів участі у таких змаганнях. Розмовляючи у кулуарах згаданої вище конференції у Вашингтоні, я побачив, що рейтинг у Kaggle є загальнопризнаним і високі позиції характеризують високий кваліфікаційний рівень спеціаліста.
Однак, парадоксом є те, що в українських ІТ-колах побутує думка, що такого типу змагання недостойні уваги справжнього науковця по даних, для якого нібито не по рангу займатись задачками олімпіадного типу, тому що до нього і так стоїть черга із замовників на аналіз даних. Підозрюю, носії таких позицій самі намагались брати участь, однак не досягли значних результатів, а відтак заперечують ефективність такого підходу, відводячи йому рівень пісочниці для початківців.
Хочу сказати, що отримати високий загальний рейтинг чи потрапити у топ-10 на змаганні надзвичайно важко. Це щоденна кропітка праця, тестування різних моделей, параметрів, комбінацій підходів.
Leaderboard на змаганні Grupo Bimbo Inventory Demand, у якому наша команда The Slippery Appraisals отримала перемогу
Особисто для мене, участь у таких змаганнях дала дуже багато у розумінні аналізу даних (мій Kaggle-профіль). Звичайно, що у таких змаганнях є особливі підходи, які визначаються специфікою змагань. Однак, основне, що отримує учасник змагань — це практичний досвід роботи з даними з різних предметних областей. Дехто стверджує, що боротьба на таких змаганнях йде за незначні долі у результатах прогнозування, а це ніби не так важливо у реальних задачах, де важливішим є стабільність розв’язку. Частково це так. Однак, аналіз підходів, валідація моделей, побудова ансамблів класифікаторів, технології беггінгу та стекінгу також можна застосовувати у реальних задачах. Їх неможливо освоїти теоретично, потрібна практика на реальних масивах даних. Коли ви, наприклад, готуєтесь поступати на математичний чи фізичний факультет, то також здаєте екзамен чи тести по складних алгебраїчних чи тригонометричних перетвореннях, які пізніше не будете застосовувати на практиці. Але цим ви показуєте свою здатність мислити і свій стартовий аналітичний рівень. Подібну аналогію я бачу і в участі у змаганнях на Kaggle, які можна розглядати як додатковий фактор росту рівня компетентності в області аналізу даних.
Про ілюзії в Data Science
Існує думка, що для аналізу даних обов’язково необхідні технології Big Data, до яких відносять Hadoop, MapReduce, Spark. Насправді, названі технології Big Data стають ефективними при розмірах даних починаючи від декількох терабайт. У реальному бізнесі лише дуже малий відсоток даних мають таких розмір. Я маю на увазі не загальний розмір бази даних, а розмір однієї таблиці, рядки якої необхідно аналізувати одночасно, наприклад, методами машинного навчання чи здійснювати аналіз на основі лінійних параметричних моделей.
Більшість сучасних систем аналізу, зокрема R, розміщують аналізовані дані в оперативній пам’яті. Наприклад, мій робочий настільний комп’ютер має розмір оперативної пам’яті 128Гб, і я можу аналізувати дані розміром в десятки гігабайт. Навіть якщо початкових даних є більше терабайта, то часто необхідна попередня агрегація даних, яку можна виконати відповідними пакетами без завантаження всіх даних в оперативну пам’ять і далі аналізувати агреговані дані суттєво меншого розміру. Або, наприклад, розбити дані на відповідні частини, а розв’язки об’єднати у відповідні ансамблі.
Коли наша команда брала участь у згаданому вище змаганні Kaggle, ми використовували арендований на Amazon ресурс із 128 процесорів та 2Tb оперативної пам’яті (x1.32xlarge Amazon EC2), що було одним із важливих чинників нашої перемоги на змаганні, оскільки дало можливість нам випробувати велику кількість моделей з великим набором створених ознак. Все це говорить про те, що навіть аналізуючи дані достатньо великих розмірів, у багатьох випадках можна обійтись без технологій Big Data.
На мою думку, також перебільшеною є роль нейронних мереж. Термін «нейронні мережі» асоціюється з розумовою діяльністю людського мозку і тому став дуже популярним. Те, що в області розпізнавання оптичних образів нейронні мережі мають успіх — очевидний факт. Однак, коли мова йде про широке коло задач машинного навчання, таких як нелінійна регресія, прогнозування попиту та цін, класифікація користувачів, виявлення обманних дій, аналіз фінансових ринків тощо, то нейронні мережі не завжди є найкращим вибором, часто цей вибір пов’язаний із рекламним ходом, щоб підкреслити сучасність та інтелектуальність рекламованої системи.
У своєму аналізі на згаданому змаганні Kaggle, ми також використовували нейронні мережі. Але ми використовували їх на другому рівні нашої моделі для реалізації стекінгу з метою незначного покращення результату. Розрахунок із використанням нейронних моделей був одним із найбільш трудомістких, хоч для цього використовувались потужні графічні процесори. І в кінцевому варіанті нашого розв’язку ми відмовились від нейронних мереж у нашій моделі, віддавши перевагу простішому варіанту моделі.
Про організацію роботи спеціалістів з аналізу даних
Існує два підходи до організації роботи спеціалістів з аналізу даних в ІТ-компаніях. Перший полягає у створенні універсального відділу Data Science, а другий — в інтеграції науковців з аналізу даних у спеціалізовані підрозділи, які займаються вузькою проблематикою. Я є прихильником другого підходу. На мою думку, особливості предметної області аналізу даних важливіші, ніж наявність спільних принципів аналізу даних. Саме глибоке розуміння предметної області та специфіки аналізованих даних є одним із основних факторів успішного аналізу даних. Важливим кроком в аналізі даних, зокрема у прогнозній аналітиці є відбір та генерація нових ознак на основі історичних даних та правильний вибір валідації моделі.
Одним із факторів перемоги нашої команди на Kaggle було те, що в коло моїх професійних інтересів входить аналіз динаміки продажів товарів, тому в генерації великої кількості нових ознак я вкладав відомі мені структурні зв’язки, які існують у бізнесі продажів та поставок. Одні з них давали покращення результатів, інші ні, але нам вдалося відібрати найефективніші ознаки. Тому я є більше прихильником вузькоспеціалізованих науковців з аналізу даних у відповідних ІТ-підрозділах.
Особливістю Data Science є те, що в цій області практично неможливо працювати фрілансером, як, наприклад, в області веб-програмування. Дані відображають багато чутливих моментів діяльності компаній. Особлива увага приділяється юридичним аспектам при передачі даних для аналізу. Тому у цій сфері аналізу даних замовники надають перевагу ІТ-компаніям, з якими можна підписати відповідні юридичні договори, зокрема договір про нерозголошення.
Про співпрацю із вузами
В Україні на даний час склалась успішна ІТ-індустрія, яка, на мою думку, дещо перебуває у легкій ейфорії. Одна з основних проблем — це слабка диверсифікація напрямків діяльності. Основний акцент зроблено на аутсорс, у розвитку якого є свої об’єктивні тренди як зростаючого, так і спадного характеру. Для стабільнішого розвитку потрібно було б збільшити частку наукоємких проектів та продуктів. Аналіз даних як у вигляді сервісу, так і у вигляді розробки спеціалізованих продуктів є одним із таких перспективних напрямків. За моїми спостереженнями реальних комерційних проектів з аналізу даних є суттєво менше, ніж самих розмов про Data Science.
Одним з чинників успішного розвитку Data Science в ІТ-бізнесі я бачу тісну співпрацю між ІТ-компаніями та вузами. Є багато прикладів такої співпраці, але її загальний обсяг недостатній. Одна з основних перепон у такій співпраці — це гонор та зверхність, які властиві обом сторонам. Серед викладачів чути, що вони не будуть займатись набиванням на клавіатурі нібито примітивного коду, що вони — академічна організація, а не бізнес структура. Інші кажуть, що ІТ-сектор і так мав би підтримувати вузи, бо ми готуємо для них спеціалістів. Зі сторони ІТ чути інші думки — у вузах не вчать сучасному програмуванню, курси застарілі, наука дає нульовий результат.
Знаючи ці дві сторони, можу сказати, що своя правда є у кожного. Успішні ІТ-шники часто недооцінюють те середовище, у якому вони формувались протягом
З іншого боку співпраця із ІТ-компаніями — це один з небагатьох варіантів, які дадуть можливість розвиватись як науковим школам, так і педагогічним колективам вузів. Адже у сучасних умовах мало хто з перспективних випускників йде займатись науковою роботою, немає можливості поїхати на значиму наукову конференцію, запросити відомого спеціаліста. Сформувавши відповідну співпрацю, можна створити базу для прикладних наукових напрямків, зокрема з аналізу даних. У цій співпраці можна було б поєднати фундаментальні знання та доробки викладачів, а зі сторони ІТ-компаній — практичні навички розробки програмного забезпечення та менеджменту.
Потрібно йти назустріч один одному, шукати різні форми співпраці. Це може бути і стажування викладачів у ІТ-компаніях, проходження практики студентами, курсові та дипломні роботи на основі реальних проектів та сучасних технологій у ІТ-компаніях. Викладачів та науковців можна залучати до проблемних наукомістких задач з області аналізу даних. Та співпраця, яку я бачу зараз, здебільшого спрямована на відбір кращих студентів з подальшим залученням їх до програмування в аутсорсі. На світовому ринку конкуренція в аутсорсі загострюється. В той же час вважаю, що наш науковий потенціал є досить значним. Тому одним із перспективних напрямків є залучення цього потенціалу в ІТ-галузь для розвитку наукоємких технологій.
Теоретично, аналізу даних можна навчитись з відповідної літератури чи на on-line курсах. Однак, виходячи із свого досвіду, я не бачу можливості розвитку Data Science без залучення науковців фізико-математичного напрямку. Потрібний особливий науковий підхід до проблеми, який виробляється роками в процесі наукової діяльності.
Багато з того, що я бачив зі сторони українського ІТ-бізнесу в області аналізу даних — це поверхневий погляд на проблему, тестові приклади, доповіді з узагальненими блок-схемами. З іншого боку, академічне товариство представляє свої ідеї з надскладними алгоритмами та формулами. Однак, немає співставлень про те наскільки нові підходи є кращими за ті, що вже існують та працюють, які результати можна отримати на відомих тестових даних.
Не всі викладачі можуть відразу почати співпрацю у новому для них ритмі з особливим форматом взаємодії з ІТ-бізнесом, це також нелегко. Зі сторони вузів мають бути зміни. Наприклад, для викладачів, які співпрацюють із ІТ-компаніями повинен бути гнучкий графік педагогічного навантаження, у яке мала б зараховуватись робота над спільними ІТ-проектами. Ентузіасти із ІТ-компаній, могли б читати відповідні лекції у вузах із зарахуванням їх до викладацького складу цих вузів. На згаданій вище конференції у Вашингтоні також обговорювалась співпраця вузів із бізнесом та урядовими установами. Основні проблеми чимось подібні у нас і на Заході. Маючи не гірший фундаментальний рівень, ми могли б співпрацювати на більш привабливих для іноземних компаній фінансових умовах.
Я висловив свій погляд лише на деякі аспекти Data Science з точки зору усередненого українського спеціаліста на основі власного досвіду і бачення даної проблеми. Хотілось би почути також думки інших спеціалістів з цього напрямку інформаційних технологій.
Останнім часом у все більшої кількості молодих спеціалістів виникають проблеми із заповненням колонки «про себе» у їхніх без того ідеальних резюме. «Цілеспрямованість», «працьовитість» і «здатність до самонавчання» вже всім замилили очі і викликають лише стомлену посмішку благородного рекрутера.
Railswarian-ы обмениваются опытом и подходами с командой Pivotal Labs
Незадолго перед Новым годом у нас в Харькове случилась отличая новость, которая закладывает хорошие перспективы на 
с гражданством или permanent resident и супер-DevOps на краткосрочный контракт. Все вопросы в личку.
Первый настоящий совет — обучить специалистов, которые хотят с вами работать и развиваться, новым технологиям! Но снова возвращаемся к вопросу рисков: специалисты станут гораздо востребованней, появится больше конкурентоспособных предложений, они уйдут. Есть на этот случай пагубная, на мой взгляд, практика подписывать кабальные контракты, в которых «нижеподписавшийся обязуется быть благодарным компании» и не расторгать соглашение, скажем, год, два, три (нужное подчеркнуть). Это плохо работает в наших реалиях. Во-первых, репутация пострадает: о компании может пойти дурная слава. Во-вторых, в любом, даже самом продуманном контракте можно найти лазейку. Да и в-третьих, насильно мил не будешь. Специалист, который пишет для вас код только по принуждению «ценной бумаги», вряд ли будет искренне болеть за качество предоставляемой услуги. 
Четвертая опция — самая сложная, на мой взгляд, — научиться расставаться с людьми красиво. Всегда обидно, когда «яркие птицы» улетают в теплые края, но это закон природы. Птица не выдержит зимы, или же будет, как Серая шейка из сказки Мамина-Сибиряка, сидеть в сужающейся день от дня лужице. Поэтому, как бы ни жалко было расставаться с теми, в кого были вложены силы и деньги, сделайте это не на эмоциях, а руководствуясь здравым смыслом. Когда очередной мой студент говорит мне, что уходит — я всегда вежливо отшучиваюсь, иду пить чай, дабы не наговорить или не наобещать чего лишнего. Когда эмоции схлынули — спокойно поговорить, понять, чего именно не хватало человеку. Запомните, хорошие родители — те, которые вовремя отпускают свое дитя во внешний мир. Иначе есть риск обломать крылья, испортить отношения, терпеть скандалы и вообще закрыть его от всех возможностей и перспектив, испортив будущее. 
[Про автора: Зеновій Верес — керівник освітнього напрямку Lviv IT Cluster, Solution Architect в компанії SoftServe, асистент кафедри комп’ютеризованих систем автоматики у Львівській політехніці]
[Катя Осадчук — СEO Indigo Tech Recruiters, экономист, профессиональный психолог и в прошлом HRD с более чем 
[Об авторе: Николай Лотоцкий — более 15 лет занимается разработкой программного обеспечения. Знаком со всеми этапами работы на проекте и развил карьеру от должности QA Engineer до Technology Expert. Несколько лет был JavaScript Software Architect и принимал активное участие в разработке сложных масштабируемых приложений. Кроме того, есть опыт работы с PHP, .NET, Python. Более трех лет проводит различные курсы и тренинги] 
[Максим Почебут — директор образовательных программ ЕРАМ в Украине, вице-президент ассоциации «ИТ Украина». Прошел путь от преподавателя до заместителя декана факультета, является кандидатом технических наук, доцентом. Развивает сотрудничество ЕРАМ с 15 ведущими техническими вузами Украины, реализовывая образовательные программы для студентов]
Когда приходится начинать или перенимать новый проект, всегда возникает заветное «а давайте все перепишем», «а почему технология X а не Y» и под конец — «а этот код писали индусы». Резюмируется все фразой «давайте перепишем и вместо Y используем X». Но когда начинаешь спрашивать: «Почему технология Y применима к этому проекту?». В ответ слышится невнятное: «Ну, новее, интереснее...», «Мне было бы интересно получить опыт по ней».
