Big Data на практиці: очікування VS реальність

Привіт, хабр!

Після останньої публікації «Ваш персональний курс за Big Data» мені прийшло кілька сотень листів з питаннями, читаючи які, я з подивом виявив, що люди дуже сильно занурюються в теорію, приділяючи мало часу вирішення практичних завдань, в яких навички необхідні інші. Сьогодні я розповім, які складнощі з'являються на практиці і з чим доводиться працювати при вирішенні реальних завдань.


Ті, хто вже пройшов велику кількість курсів за машинного навчання і почали розв'язувати задачі на Kaggle прекрасно знають, як виглядає типова постановка завдання: "Дан набір об'єктів навчальної вибірки, кожного, з котрих є ознаки, а також дано значення цільової змінної. Також дана тестова вибірка, для кожного об'єкта якій значення цільової змінної необхідно передбачити". Існують і більш складні постановки, тут я лише навів найбільш типову для завдань регресії та класифікації. З цього починається рішення задачі на kaggle.com — Ви благополучно читаєте умову задачі, дивіться на метрику якості, завантажуєте датасет, запускаєте IPython Notebook, підключаєте Ваші улюблені бібліотеки і починаєте довго і наполегливо працювати з даними, підбирати гиперпараметры моделей, робити відбір ознак, навчати безліч класифікаторів та зважувати їх, знаходити складні об'єкти і дивитися на них більш уважно і т. д. Тим самим Ви боріться за те, щоб оптимізувати метрику якості і отримати гідну позицію у Leader Board.

На жаль, на практиці все виглядає зовсім по-іншому. Насправді, 90% роботи вже зроблено до Вас. Навички побудови якісних моделей звичайно важливі, але не першорядні. Зверніть увагу на виділені вище в постановці задачі слова — вони не випадкові, тому що в реальному житті вам нічого «не дано», ні «метрики якості», ні «навчальної вибірки», не кажучи вже про те, що по-суті немає і завдання — є лише неясне опис того, яка мета переслідується при рішенні тієї або іншої задачі. І тут починається справжня робота вченого з даними, в якій велику частину займає рутина, а думати треба далеко наперед і задовго до того, як є чітка постановка завдання і побудована матриця «об'єкт-ознака».

Якщо коротко, то найпоширенішими проблемами, з якими доводиться стикатися є наступні:

  • Нечітка постановка завдання
  • Велика кількість ступенів свободи
  • Велику кількість різних джерел даних
  • Якість даних і пропуски в них
  • «Сире» для роботи з даними
  • Незручність роботи з великими даними
  • Наявність навчальної вибірки
Отже, розберемо по порядку кожну з проблем:

Нечітка постановка завдання
Завдання не виникає сама по собі — кожну річ, яку ми робимо, робиться для конкретної мети. А цілі бізнесу часто формулюються досить неформально: «зменшити відтік клієнтів», «збільшити виручку від партнерських програм», «утримати користувачів», «знизити навантаження на конкретний відділ бізнесу за рахунок оптимізації бізнес-процесів». Саме в такому формулюванні (частіше — трохи точніше) завдання потрапляє до Data Scientist'у. Ось саме тому цей чоловік і повинен бути знайомий з бізнесом, щоб розуміти те, що ж насправді потрібно. Якщо, наприклад, вирішується завдання просування послуг або розробляється таргетированное пропозиція — необхідно розуміти, як надалі буде влаштований процес взаємодії з клієнтом, як буде проводитися рекламна кампанія, як буде визначатися критерій її успіху — і для чого тут врешті-решт потрібно машинне навчання — все це необхідно знати з точністю до деталей. Але як тільки Ви починаєте розбиратися з деталями — у вас з'являється наступна проблема.

Велика кількість ступенів свободи
Що таке — «клієнт пішов у відтік» — мовою бізнесу зрозуміло — бізнес починає втрачати гроші. Але сховища, в яких міститься інформація про клієнта цього не розуміють — у них зберігаються десятки статусів, в яких відтік може означати блокування, розірвання договору, невикористання послуг протягом певного проміжку часу, несвоєчасну оплату рахунків — все це можна назвати відтоком клієнта в тій чи іншій мірі. А як Ви думаєте — якщо формулювання цільового параметра і постановки задачі допускає стільки ступенів свободи — як легко при цьому генерувати ознаки для завдання? Вірно! — це зробити ще складніше. Тепер на хвилину уявіть, що ми визначилися з самої завданням і з ознаками. А як буде здійснюватися контакт з клієнтом? — і тут виявляється, що процес утримання клієнта — це складна процедура, яка займає певний час і у якої є певні особливості. Якщо, скажімо, Ви передбачаєте, що клієнт схильний піти у відтік з певною ймовірність на яку-небудь дату, тобто також ймовірність що Ви просто не встигнете з ним провзаимодействовать. І все це необхідно врахувати задовго до розробки алгоритму. Саме тому необхідно навчитися швидко занурюватися у певну предметну область, щоб знати весь процес і всі деталі. Припустимо, що і з цим ми впоралися, визначилися також з тим, які ознаки нам знадобляться для вирішення завдання. Але тут виникає нова проблема.

Велику кількість різних джерел даних
Дані, особливо у великій компанії, далеко не завжди зберігаються в одному джерелі. І далеко не завжди засоби для роботи з цими даними однакові, оскільки це можуть бути як sequence-файли, що лежать в HDFS, noSQL бази даних, а також реляційні джерела. Але ж нам часто потрібна матриця «об'єкт-ознака» — а значить доведеться робити велику кількість всіма улюблених join'ов — що в разі великих даних змушує думати про те, як зробити запити оптимально. Тут потрібні навички роботи з різними інструментами, починаючи від SQL, Hive, Pig і закінчуючи тим, що найчастіше простіше написати код на Java/Scala, ніж використовувати SQL-подібні мови. Однак, якщо ви знайомі з усіма цими інструментами і уявляєте, як правильно писати складні join', виникають інші проблеми.

Якість даних і пропуски в них
Дуже часто (чим більше компанія, тим частіше) у Вас буде велика кількість пропусків у даних — наприклад, якщо завдання вимагає для вирішення якихось певних ознак — може виявитися так, що більша частина цих ознак доступна лише для невеликої групи клієнтів. Далі, якщо навіть дані по клієнтах є в наявності, виявляється, що в частині даних є так звані викиди, не кажучи вже про те, що т. к. і джерела даних різні — то одні і ті ж дані можуть зберігатися в різних форматах і доводиться при тому ж join'е приводити все до одного виду. Але, припустимо, що і з цим Ви впоралися. Написали хороший скрипт на Hive/Pig або на Spark і запустили. Думаєте це все? Не зовсім.

«Сире» для роботи з даними
Основною причиною популярності Big Data у свій час була дешевизна. Зокрема — більшість популярних інструментів для роботи з великими даними — є open-source розробкою, будь то Hive, Pig або всіма улюблений Apache Spark. Але ті, хто хоч раз мав досвід роботи з open-source інструментами, прекрасно знають, що на них розраховувати зовсім не коштує і що з першого разу все запускається далеко не завжди. Наприклад, якщо Ви написали простий скрипт, який послідовно читає файли з HDFS і відійшли на кілька годин. З приходом Ви можете легко виявити, що скрипт «впав» просто тому, що серед папки з файлами, яку Ви читали випадково виявився який-небудь *.tmp файл, який Pig, наприклад, не зміг прочитати. Всі, хто працював з Apache Spark можуть розповісти Вам про проблеми читання дрібних файлів, про те, що часто важко на ньому зберегти побудовані моделі — доводиться писати власні сериализаторы. Таких прикладів можна навести дуже багато. Але, припустимо, ви довго запускали і тестували код і ось, начебто, є у Вас довгоочікувана матриця «об'єкт-ознака».

Незручність роботи з великими даними
І от Ви уявіть, що у Вас є великий обсяг даних. Припустимо навіть, що у Вас невелика навчальна вибірка, яка поміщається в оперативній пам'яті, і Ви вже побудували гарну модель. Як правило, при цьому Ви нагенерили велику кількість нових ознак (зробили Feature Engineering, з яким ми з Вами знайомилися тут і тут). А що робити з тією самою великою вибіркою об'єктів, для яких потрібно викликати Вашу довгоочікувану функцію Predict? Адже для неї теж потрібно зробити все ті ж перетворення, які ви робили з навчальною вибіркою — додати нові стовпці, заповнити пропуски, нормувати дані. При побудові моделі Ви напевно це робили з допомогою чудових пакетів на зразок Pandas, в якому мали справу з DataFrame'ами. Все, тепер їх більше немає — доведеться все робити своїми руками. Єдине, чого тут залишається порадіти — в Apache Spark версії 1.3 є підтримка DataFrame, яка дозволить працювати з великими даними також швидко, як це робиться у R або Python. Напевно.

Наявність навчальної вибірки
Це, напевно, не сама приємна, але в той же час важлива проблема, яка виникає на практиці — де брати навчальну вибірку? Тут вже доводиться багато думати, т. к. важливо дотримати баланс між розміром навчальної вибірки та її якістю. Наприклад, в деяких завданнях часто є певний набір навчальних об'єктів і можна шляхом кластеризації та накладення навчальних об'єктів намагатися збільшити розмір навчальної вибірки. Можна також знайти навчальну вибірку шляхом вирішення безлічі допоміжних завдань — єдиних методів тут немає — доводиться викручуватися кожен раз під конкретну задачу.

Разом
Отже, я сподіваюся, що після прочитання цього посту Вам ще хочеться активно займатися аналізом даних. Адже всі ці проблеми з часом так чи інакше вирішуються (можу сказати це в моєму випадку, а також шляхом опитування своїх колег з інших компаній). Так буває завжди, коли з'являються нові інструменти, як це відбувається у випадку з Apache Spark. Однак, важливо про всі ці особливості і труднощі знати заздалегідь.

Саме для цього (а також тому, що після останньої публікації моя пошта виявилася завалена листами і я не встигаю відповідати всім) був створений ресурс MLCLass.uk, на якому я збираю кращих практиків, які готові поділитися знаннями, а також допомогти новачкам у вирішенні завдань! Приєднуйтесь і не соромтеся писати свої питання і кликати друзів, а також активно писати на support! Я і мої колеги зацікавлені в розвитку Data Science і готові відповідати на всі Ваші запитання!

Успіхів всім і відмінних починань! Зустрінемося на MLCLass.uk!

Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.