Сучасна диджитал-освіта для дітей — безоплатне заняття в GoITeens ×
Mazda CX 30
×

Особливості роботи Big Data Engineer: що знадобиться на практиці

Вітаю всіх. Мене звати Максим Сафтюк, я Big Data Engineer у SoftServe. У цій статті хотілося б трохи поділитися з вами своїми думками щодо професії Big Data Engineer. Адже кожен вкладає в цю професію своє розуміння і через це часто з’являються невиправдані стереотипи. Розберемо деякі з них, а також намагатимусь описати реальну красу роботи Інженера великих даних.

Ця стаття буде корисна тим, хто цікавиться цим напрямком та прагне перейти в нього, а також фахівцям, які хотіли б краще зрозуміти свої колег-big data інженерів.

Великі дані

Для початку розберемося у найголовнішому — терміні Big Data.

Звучить наче просто. Ми маємо певні дані, і вони великого обсягу. Прямо під час прочитання у голові уявляєш якийсь обсяг даних, який ми чомусь вважаємо великим. І обговорюючи цей великий «обсяг» з людьми поряд, часто чуємо подібні діалоги:

Дизайнер: блін, вивів макет логобука/ гайдбука/ брендбука на 1 гігабайт. Тепер півтора року заливати його...
PM: та й не кажи. Мені так надіслали колись 4 макети, які треба було одночасно показувати клієнту на мітингу. Думав, мій комп загориться.
Розробник: понамальовують ось це складних макетів, а ти потім роби так, щоб 10 Мб «корисних картинок» вантажилися за пів секунди.
Аналітик: не знаю, у мене ось звіт готується вночі п’ять годин. Головне, щоб сервери не падали.

Комічність у тому, що у таких обговореннях і народжувалися основи визначення «більшовизни» даних. І на цей час найпоширенішим визначенням big data є його опис через 7 ключових характеристик або 7V. І це вже розширена версія, адже спочатку у статті Дуга Лейні від 2001 року було лише три такі характеристики — 3V. Вони й залишаються зараз найпростішими та зрозумілішими — volume, velocity, variety (обсяг, швидкість, різноманітність).

Далі до них почали поступово додавати додаткові V — viability (життєздатність), value (цінність), variability (мінливість) та visualization (демонстрація). Докладніше можна почитати тут.

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

Момент переходу даних до категорії великих зазвичай відбувається непомітно. Я навіть сказав би — несподівано. Якийсь щоденний звіт будувався 5 годин уночі. Дані росли, росли й ось уже потрібно 7 годин, потім — 10, потім — 14. І ось щоденний звіт стає не щоденним. :)

Або ж всі дані зберігаються за проєктами, все за теками розкладено охайно, загалом — рай перфекціоніста. Через 4 роки випадково виявляється, що місце чарівним чином починає закінчуватися і треба якось видалити старі проєкти. Але вони дуже потрібні якійсь частині команди. І ось уже через пів року цілий відділ DB інженерів і кілька архітекторів працюють на потреби команди Data Science у збереженні всіх вхідних даних. Не те щоб вони всі потрібні, але нехай будуть.

Основні bottle necks роботи з великими даними

У роботі з будь-якими даними завжди є нюанси. Нижче наведу кілька важливих моментів, знання яких потрібні для будь-якого дата інженера, не важливо big чи ні.

Потужність

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

І тут настав час паралельних обчислень. Не те щоб це була панацея, але й вибору особливо немає. Однак 9 жінок народять одну дитину все одно через 9 місяців. Так само в роботі з великими даними потрібно уникати не розпаралелюваних процесів. І навіть якщо ця проблема не здається важливою зараз, то в майбутньому це може зробити вам нерви.

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

Приклад:

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

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

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

Сховище даних

Під час роботи з big data загострюється момент систематизації та зберігання даних. Існують певні патерни (DWH, DL, DM і т.д.), за якими вдасться уникнути стандартних проблем зі зберіганням даних. Докладніше можна глянути тут.

Важливо розуміти, що запис та читання інформації відбувається не миттєво. І обмеження є не лише з боку HDD/SSD/будь-якого іншого місця зчитування даних. Сам спосіб зчитування також може стати вузьким місцем.

Приклад:

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

Завдання відносно просте: є файл (~ 400ГБ), у якому зберігається великий обсяг даних на конкретний ідентифікатор (id, field1, field2, ..., field974). Дані з цього файлу використовують дві команди — Data Science Team (DS) та Data Analytics Team (DA). Завдання у цих команд різні: у DS — отримати всі колонки по id, у DA — саме звіти, де було б непогано працювати з конкретними колонками. І як зберігати дані?

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

І розв’язанням поставленої задачі може бути будь-який шлях, починаючи від дублювання цього файлу зі збереженням у різних форматах, і закінчуючи об’єднанням цих двох типів зберігання (’id’, ’someFilerField1′, ’someFilerField2′, ’id|field1|field2|field3...’), або комплексним підходом та побудовою повноцінного DHW.

З’єднання

У сфері великих даних доводиться стикатися з досить незвичними проблемами. Можна довго читати, що ваш тип СУБД може підтримувати швидкість читання до 10 ГБ/с, при цьому маючи сервер, підключений до мережі через звичайну виту пару на 100 Мбіт/с.

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

Робота Big Data Engineer

І ось ми підійшли до найцікавішого. Для людей не зі сфери IT людина Big Data Engineer — це логіст у світі даних. А для людей з IT:

— Ну, так, просто перекладаю файли з одного місця в інше...

І я залишаюся при думці, що це дуже точне визначення. Але якщо заглиблюватись, то робота Big Data Engineer — це вирішення інженерних завдань. Під словом «інженерний» я тут розумію жорсткий взаємозв’язок з реальністю. Сферичні коні у вакуумі потрібні у наукових статтях, а тут — життя.

Є проєкт з 30-річною історією даних, з якимось старим обладнанням, не зовсім придатним для нинішніх завдань, з якимось новим обладнанням, яке не зовсім підходить для нинішніх завдань тощо. Робота інженера великих даних — це пошук балансу між теоретично можливою вигодою різних підходів та поставленими реальними умовами. Не максимально швидко/не супер дешево/досить якісно — виберіть три пункти.

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

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

І, як і будь-якої іншої професії, краса роботи Big Data Engineer розкривається вже на високому рівні. Спочатку потрібно зрозуміти, як працювати з даними. І тут на будь-кого чекає маса відкриттів:

  • що унікальні дані, на жаль, можуть бути не унікальними;
  • що один \n може повністю поламати вам процес, який тривав понад 14 годин;
  • що баг в обробці даних може бути знайдено через рік, що зробило марним рік роботи цілого відділу DS.

І ще купа всяких що.

Big Data ком’юніті: як розвивати свою експертизу

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

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

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

Але головним пунктом серед усього спектру нетворкінгу для мене є корпоративний месенджер. У мене в списку контактів є набір людей, які використовують у роботі, мабуть, 99% всього наявного стека Big Data. Це супер зручно, коли стикаєшся зі складною проблемою і маєш кому поставити конкретне питання. Такий собі персональний стек оверфлоу.

👍ПодобаєтьсяСподобалось8
До обраногоВ обраному1
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Это один из тех терминов, которые появились в последнее время, но означают понятия, которые существовали десятилетиями. Лет 15 назад случилось переводить книгу по Agile. Подумал вначале: что за зверь такой, почему все по нему с ума сходят? Начал переводить и осенило: — Блин! Я же лет 20 работаю по методологии Agile, теперь узнал, как оно называется!

Честно говоря так и не понял, что конкретно делает инженер с big data, хотя пришел сюда за этим. Статья как будто не окончена.

На этот вопрос сложно ответить, даже написав прямую статью об этом. Big Data Engineer сравним с Software Developer. Достаточно обширное понятие, и так конкретно не сформулируешь)
В статье скорее описаны основные направления, знание которых пригодится в работе)

Было интересно, спасибо.

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

Та найчастіше вони й дають його, просто не за бажані терміни часу.

обчислювальна потужність досі залишається дорогим ресурсом

та зараз наче й не дуже, при грамотно побудованому дата-пайплайні можна швидко і дешево обробити великі обсяги даних

для людей з IT: Ну, так, просто перекладаю файли з одного місця в інше...

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

Це про те, що дата інженер не має розмірковувати у категоріях якогось вузького набору інструментів.

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

що один \n може повністю поламати вам процес, який тривав понад 14 годин;

ну \n не зустрічав, але non-unicode може і це найбільша біль :D

Підписатись на коментарі