Full stack data science і GCP

Сьогоднішній пост буде про специфіку роботи  data scientist в  бізнес (не research) проектах.

 Часто бізнесу потрібно мати просто хороше рішення сьогодні, а не ідеальне післязавтра. Але при цьому це “сьогоднішнє рішення” має бути достатньо якісним (щоб отримати шанс бути покращеним в майбутньому).

Згідно стандарту CRISP-DM виділяють такі етапи data science процесу:

• Business Understanding - розуміння бізенс проблеми та можливих шляхів її вирішення
• Data Understanding - розуміння які дані допоможуть вирішити цю проблему і де їх взяти
• Data Preparation - підготовка даних (налаштування ETL, очищення, збагачення)
• Modeling - підбір моделей та алгоритмів, які найкраще підходят для вирішення задачі
• Evaluation - перевірка моделі, основне питання - "Чи вирішує наша модель бізнес задачу?"
• Results communication - представлення результатів дослідження в зрозумілій всім учасникам формі.
• Deployment - розгортання моделі для подальшого використання.

В ідеалі цим займається команда, яка включає:
Data Scientist (або Data Analyst + Machine Learning Engineer)- моделювання, підготовка даних, підготовка звітів/комунікація результатів.
Data Engineer - підготовка даних, підготовка до розгортання;
Business Analyst - комунікація з бізнесом,
DevOps - розгортання.

Часто кожен з цих спеціалістів має вузьку спеціалізацію із специфічним набором скілів. Часом у спеціаліста нема бажання виходити за межі власної зони відповідальності. Часом у бізнесу нема ресурсів/бажання платити за таку кількість (часто дорогих) спеціалістів, оплачувати  оверхед по неохідному комунікуванню між ними, налогоджування/контролю процесу взаємодії в команді. Та й побудова команди, де всі будуть доповнювати один одного задача не з легких. Подібні проблеми не нові і у споріднених  галузях. Наприклад, у software development одним із способів вирішити проблеми такого типу є спеціалізація full stack developer (а також практики DevOps). По аналогії,  такого "спеціаліста на всі руки" можна назвати full stack datas cientist.

Під full stack data scientist будемо далі розуміти людину, яка:

• спілкується з замовником, визначає вимоги до проекту, критерії успішності
• будує pipeline збору та підготовки даних до моделювання
• підбирає найкращий алгоритм
• робить валідацію результатів (з точки зору бізнесу)
• готує/презентує результати дослідження
• розгортає модель (як мінімум на етапах POC та MVP)

Тепер про інструменти.

Раніше, як і більшість моїх колег, використовувала такий стек:

Препроцесінг/підготовка даних - R/Python/Spark або спеціалізоване рішення типу Trifacta.

При цьому дані зберігаються локально або в базі даних (в 90% це SQL бази).

Побудова моделі - R /Python/Spark/TensorFlow

Тут швидкість обробки та кількість даних, які можна обробити залежать від локальної машини/сервера. Швидкість тренування моделей теж. 

Комунікація результатів:

Може бути статичною або інтерактивною.
Набір інструментів:

• PowerPoint/Google Slides
• R(Shiny), Python (matplotlib/seaborn)
• Tableau
• JavaScript (d3.js)

Deployment:

• веб додаток з використанням R Shiny (якщо потрібне візуальне представлення результатів роботи моделі)
• веб додаток з використанням Python/Flask (якщо в результаті маємо сервіс, який видає результати через API)

Виглядає непогано, однак треба вирішувати багато питань, які мало відносяться до data science:

• вимоги до заліза
• розробка/тестування веб додатку (frontend, backend, tests)
• налаштування середовища (VM, Docker container, локально, в хмарі? )
• розгортання додатку (Vagrant, Ansible?)
• моніторінг
• підтримка 
• scaling (коли, як, хто?)

Тобто, впроваджуючи ваше рішення ви frontend розробник, backend розробник, тестувальник, devops інженер. Це забирає дуже багато часу та зусиль, оскільки всі інструменти змінюються.

Крім того,  світ data science теж змінюється (Вжух, і всюди XGBoost).

Чи є інший шлях?

Для себе використовую Google Cloud Platform інфраструктуру.

Як це працює:

Поточні дані збираються з допомогою GoogleAnalytics (оскільки це веб-сайт + мобільні додатки це природній та найбільш простий спосіб отримати дані) та кількох ETL і потрапляють в BigQuery. Це DWH, який дозволяє супер швидке виконання SQL запитів на великих об'ємах даних. Там  роблю і первинне дослідження даних. Середовище налаштовувати не потрібно. При цьому запит, який обробляє 67 GB виконується за 40 секунд.
Додатковий плюс:  не маємо звичної проблеми, коли аналітичні квері сповільнюють роботу SQL продакшен бази.

Вивчення даних та тестування гіпотез роблю з допомогою в Datalab. Це побудований на основі Jupyter notebook,  дозволяє звертатись до BigQuery/Google Storage/ML Engine, а також використовувати python та  його бібліотеки (pandas, scikit-learn, seaboarn).

Будувати візуалізації можна як з використанням python бібліотек, так і з використанням Google Charts API.  Для запуску достатньо команди
datalab create datalab-vm -- machine-type "machine type"
яка автоматично стартує машину вказаного типу та встановить з'єднання з цією машиною з вашого локального комп'ютера.

Для тренування та збереження моделей  використовую Google ML Engine. ML Engine використовує Tensor Flow.  Весною 2017 з'явилась можливість тренування на GPU.

Основна переваги GCP для мене:
Big Query:

• швидка обробка великого об'єму даних
• зручна мова запитів

ML Engine:

• API для використання моделі готовий відразу після розгортання моделі. 
• Це serverless рішення, тобто ресурси для нього виділяються лише на час виклику. 
• Автоматично масштабується - ресурси виділяються пропорційно до викликів
• Можна викликати prediction у online (near real time) та batch форматах.
• Можна одночасно розгорнути кілька версій API

Datalab досить зручний, однак в принципі, може бути замінений Jupiter notebook з налаштуванням доступу то GCP сервісів через API.  Найбільше подобається можливість легкої зміни типу машини під задачу.

Крім того, Google Cloud Platform має ще кілька цікавих рішень:

• Cloud Dataprep - препроцесінг даних. На основі сервісу Trifacta. Мала невеликий досвід використання Trifacta - тоді були проблеми якраз з Ops частиною.
• Dataproc - дозволяє підняти кластер з Hadoop, Spark, Hive, Pig, etc
• Dataflow - можна використовувати для побудови ETL.
• Pub/Sub - message flow
• Google Data Studio - для побудови дешбордів.
• Cloud Functions - serverless середовище для виконання функцій

Отже, що ми отримали в результаті:

• frontend/backend development, DevOps та Ops зкоротилися до мінімуму - нарешті data scientist може займатися своєю роботою (юххху!)
• платимо лише за використані ресурси (запити до апі, час тренування, місце) і не оплачуємо неефективний час роботи віртуальної машини або докер контейнера
• ми можемо вибрати (і оплатити) для реалізації проекту лише реально необхідну кількість ресурсів
• маємо розумний варіант для масштабування (по часу і вартості)
• продакшен рішення представлені у вигляді добре задокументованих і відомих у галузі API.

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

В серпні на DataFest в Києві планую розповісти детальніше та показати на прикладах, як це працює.