Data Science: шлях до професіоналізму

Привіт всі!

На хвилі безперервних дискусій про Hadoop і інших великих даних ми не могли пройти повз чудової публікації Джеррі Овертон, що розповідає про професійному підході до аналізу великих даних в компаніях будь-якого розміру. Зрозумілі картинки, надані автором, а також короткий парад технологій, без яких сучасного Data scientist'у не обійтися. Тому нехай стаття починається з (помилковою!) посилки: «Не читайте книги по Data Science», вона заслуговує публікації в блозі нашого видавництва.

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


Мій досвід роботи в якості дослідника даних зовсім не нагадує історії, які можна прочитати в книгах і блогах. Там розповідають про моїх колег, які працюють в компаніях-сверхгигантах. Вони здаються супергероями, пишуть автоматизовані (вважай, одушевлені) алгоритми, які видають безперервний потік інсайтів. Я читав про дослідників даних, хитромудрих як агент Мак-Гайвер, здатних врятувати становище, витягуючи корисні дані практично з усього, що їх оточує.

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

На світі багато «звичайних дослідників даних», таких, як ми. Ми більш організовані порівняно з хакерами, але, на відміну від всяких супергероїв, ми обходимося без «секретного штабу». Ми просто збираємося і влаштовуємо мозковий штурм, в ході якого обговорюємо найкращі способи створення надійного коду. У цій статті викладено квінтесенція наших бесід; я спробував зібрати наші знання, відсікти все зайве і коротко представити наші напрацювання в одній публікації.

Як стати професіоналом

Дослідник даних повинен володіти навичками програміста — але не всіма, якими користується в роботі програміст. Я називаю дослідників даних, що володіють основними навиками розробки інформаційних продуктів, «програмістами-датологами». Професіоналізм – не просто навик, який можна підкріпити сертифікатом або придбати на досвіді; я маю на увазі професіоналізм як образ дій.

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

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

Мислити як професіонал

Щоб стати професійним програмістом-дослідником даних, не досить знати загальних принципів структурування систем. Потрібно уявляти, як спроектувати рішення, вміти розпізнавати, коли рішення у вас є, а також розрізняти ті випадки, в яких ви не повністю розумієте власне рішення. Останній пункт критично важливий, щоб ви могли коригувати власну роботу. Коли ви розпізнаєте принципові прогалини у власному підході, то самі можете їх заповнити. Щоб підібрати таке рішення проблеми, пов'язаної з даними, яке можна коригувати по ходу роботи, я віддаю перевагу дотримуватися базової парадигми «дивитися, бачити, уявляти, показувати».

Етап 1: Дивитися. Для початку зорієнтуйтеся на місцевості. Зробіть попереднє дослідження, ознайомтеся з усіма компонентами, які можуть бути пов'язані зі стоїть перед вами завданням. Розгляньте проблему в самому широкому контексті. Постарайтеся розібратися з максимальною кількістю аспектів поставленого завдання, приведіть у порядок розрізнені фрагменти інформації.

Етап 2: Бачити. Візьміть вищезазначені розрізнені фрагменти і узагальніть їх у вигляді абстракцій, відповідних елементам патерну класної дошки. На даному етапі ви перетворюєте елементи проблеми в осмислені технічні концепції. Бачення проблеми — найважливіший підготовчий крок на шляху до створення життєздатного проекту.

Етап 3: Уявити. Спираючись на технічні концепції, які ви вже бачите на даному етапі, уявіть реалізацію, яка дозволить перейти з початкового стану до цільового. Якщо уявити реалізацію не вдається, то, ймовірно, ви щось упустили при розгляді проблеми.

Етап 4: Показати. Поясніть отримане рішення спочатку собі, потім колезі, начальнику і потім, нарешті, потенційному користувачу. Для них потрібна мінімальна формалізація — не більше, ніж потрібно для донесення вашої ідеї. Припустимо, це можна зробити при розмові за кавою, поштою, під час недовгої прогулянки. Це найважливіша регулярна практика, що допомагає професійному досліднику даних навчитися коригувати власну роботу. Якщо у вашій стратегії є вади, то вони, ймовірно, виявляться, як тільки ви спробуєте її пояснити. Саме на даному етапі можна усунути прогалини і переконатися, що ви можете досконально пояснити як проблему, так і її рішення.

Проектувати як професіонал

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



Оскільки продукти для роботи з даними експлуатуються у відповідності з певною парадигмою (в реальному часі, в пакетному режимі або у відповідності з якою-небудь гібридною моделлю), то ви, ймовірно, будете брати участь як у підтримку вищезгаданої логістичного ланцюжка, так і в реалізації парадигми цього продукту: виконувати прийом та видалення пакетно-оновлюваних даних, будувати алгоритм для аналізу даних у реальному часі, організовувати спільне використання даних і т. д. До щастя, архітектурний патерн «класної дошки» подібний до базового креслення, допомагає якісно реалізувати будь-який з цих сценаріїв на рівні програмування.

Патерн класної дошки



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

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

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



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

Професійна збірка

Ви не зобов'язані збирати елементи вашого продукту в строго визначеному порядку (тобто, спочатку створити репозиторій, потім алгоритми і, нарешті, контролер). Професіонали організовують складання в порядку зниження технічного ризику. Тобто, спочатку реалізується той елемент, для якого такий ризик найбільш високий. Елемент може представляти технічний ризик по безлічі причин. Найбільш ризикованою може бути компонент, що знаходиться під найвищою навантаженням, або той, який ви найгірше розумієте.
Можна створювати компоненти в будь-якому порядку, зосередившись на одному з них, а для решти залишаючи заглушки. Наприклад, якщо ви вирішите почати з розробки алгоритму, зробіть формальну реалізацію даних, що вводяться, а також визначте місце, куди буде тимчасово записуватися висновок алгоритму.



Далі реалізуйте продукт в такому ж порядку: спочатку самі ризиковані елементи. Зосередьтеся на одному елементі, для інших поставте заглушки, замінити їх завжди встигнете.

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

Інструменти для професіонала

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

Візуалізація
  • D3.js: D3.js (або просто D3, Data-Driven Documents) — це бібліотека JavaScript для створення динамічних, інтерактивних візуалізацію даних в браузері. В ній використовуються широко поширені стандарти SVG, HTML5 та CSS.


Контроль версій

  • GitHub це веб-хостинг репозиторіїв Git, що забезпечує повний набір функцій з распределенному контролю версій і управління вихідним кодом (SCM). При цьому GitHub не тільки працює з Git, але і додає власні можливості. GitHub надає як браузерний веб-інтерфейс, так і локальний інтерфейс для ПК, а також інтегрується з мобільними платформами.


Мови програмування

  • R: це мова програмування і програмне середовище для статистичних обчислень і їх графічного подання. Мова R широко застосовується фахівцями за статистикою і дата-майнингу як для розробки статистичного, так і для аналізу даних.
  • Python: це широко поширений універсальний високорівнева мова програмування. У філософії Python особлива увага приділяється читання коду, а синтаксис дозволяє програмістам висловлювати концепції більш лаконічно, ніж на мовах зразок C++ або Java.
  • Scala: це функціональний об'єктно-орієнтована мова загального призначення. В Scala повністю підтримуються всі можливості функціонального програмування, є дуже сильна статична система типів. Тому програми, створювані на Scala, виходять дуже короткими і більш компактними, ніж програми на інших більш розповсюджених універсальних мовах.
  • Javaце виключно поширений універсальний об'єктно-орієнтована мова програмування, що забезпечує конкурентну обробку, має систему класів, спеціально спроектований з таким прицілом, щоб програми на ньому містили якомога менше залежностей. Він призначений для того, щоб програму можна було написати одного разу і запустити скрізь» (принцип WORA).


Екосистема Hadoop

  • Hadoop: це вільний софтверний фреймворк, написаний на мові Java і призначений для розподіленого зберігання і розподіленої обробки дуже великих наборів даних в комп'ютерних кластерах, збудованих з порівняно дешевого апаратного забезпечення.
  • Pig: це високорівнева платформа для створення програм MapReduce, що використовуються з Hadoop.
  • Hive: це інфраструктура сховищ даних, що вибудовується на основі Hadoop і забезпечує підсумовування, запит і аналіз даних.
  • Spark: примітиви Spark, збережені в пам'яті, збільшують продуктивність, для деяких додатків – у 100 разів.
Розумна книга на тему Big Data, яку я б точно купив

/>
/>


<input type=«checkbox» id=«vv68307»
class=«checkbox js-field-data»
name=«variant[]»
value=«68307» />
Hadoop
<input type=«checkbox» id=«vv68309»
class=«checkbox js-field-data»
name=«variant[]»
value=«68309» />
Hive
<input type=«checkbox» id=«vv68311»
class=«checkbox js-field-data»
name=«variant[]»
value=«68311» />
MapReduce
<input type=«checkbox» id=«vv68313»
class=«checkbox js-field-data»
name=«variant[]»
value=«68313» />
Pig
<input type=«checkbox» id=«vv68315»
class=«checkbox js-field-data»
name=«variant[]»
value=«68315» />
Spark
<input type=«checkbox» id=«vv68317»
class=«checkbox js-field-data»
name=«variant[]»
value=«68317» />
Нічого з перерахованого вище

Проголосував 21 людина. Утрималося 6 осіб.


Тільки зареєстровані користувачі можуть брати участь в опитуванні. Увійдіть, будь ласка.


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

0 коментарів

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