Сходження дата-інженера

image

Я приєднався до команди Facebook в 2011 році в якості інженера бізнес-аналітика. До моменту, коли я залишив команду в 2013 році я вже був дата-інженером.

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

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

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

У зв'язку з раніше встановленими ролями, дата-інжиніринг можна було б розглядати як надмножество бізнес-аналітики і баз даних, яка привносить більше елементів програмування. Ця дисципліна включає в себе спеціалізацію по роботі з системами Big Data, розширену екосистему Hadoop, потокову обробку даних і роботу з Scale.

В невеликих компаніях, де досі немає остаточної інфраструктури для зберігання даних, на інженерів покладається роль на її створення і підтримку всередині організації. Це включає в себе завдання по підтримці платфорт на Hadoop/Hive/HBase, Spark або чогось подібного.

У невеликих екосистемах люди, як правило, користуються послугами хостингу, наприклад, Amazon або Databricks, або отримують підтримку від таких компаній як Cloudera або Hortonworks, які, по суті, грають роль посередників між іншими компаніями.

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

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

ETL змінюється
Ми спостерігали масовий відхід від практики drag-and-drop ETL (Extract Transform and Load) до програмного підходу. Продукти, засновані на ноу-хау платформах виду Informatica, IBM DataStage, Cognos, AbInitio або Microsoft SSIS не поширені серед сучасних дата-інженерів і замінюються більш загальним програмним забезпеченням і навичками програмування, поряд з розумінням програмних або конфігурованих платформ виду Airflow, Oozie, Azkabhan або Луїджі. Це досить поширена практика серед дата-інженерів, які управляють своїм робочим процесом через, наприклад, планувальник.

Існує безліч причин, чому складні елементи програмного забезпечення не розробляються за принципом «drag and drop»-інструментів: в кінцевому рахунку самописний код є кращим рішенням для ПО. Хоч міркування на цю тему і виходять за рамки даної публікації, легко зробити висновок, що все вищеописане стосується і до написання ETL, як застосувати і до будь-якого іншого програмного забезпечення.

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

Необхідно підкреслити, що абстракції під впливом традиційних ETL-інструментів відхилилися від своєї первісної мети. Безсумнівно необхідність в абстрактній складності обробки даних існує, як і в обчисленні та зберіганні. Але я зауважу, що дані рішення не варто спрощувати допомогою ETL (наприклад зв'язка джерело/таргет, фільтрування і т. д) з-за моди використовувати drag-and-drop підхід. Абстракцій необхідно мати більш високий рівень. Наприклад, необхідної абстракцією сучасної середовища даних є конфігурація для експериментів з фреймворками A/B-тестування.

Що за експерименти? Як вони будуть проходити? З якими пов'язаними процедурами? Який відсоток користувачів повинен приймати участь в тесті? Коли очікується одержання результатів? Що ми будемо вимірювати? В даному випадку ми маємо конкретний фреймворк, за допомогою якого ми можемо з високою точністю визначити вхідні дані, вивантажити статистику і отримати кінцеві розрахунки. Ми очікуємо, що додавання нових даних призведе просто до додаткових обчислень і дані оновляться. Важливо розуміти, що в цьому прикладі параметри абстракції не визначаються традиційним ETL-інструментарієм і що завдання такої абстракції не відбувалося за допомогою drug-and-drop'a.

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

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

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

  • додаткова денормалізація (підтримку сурогатних ключів можна використовувати як хитрість, але це робить таблиці менш читання), використання реальних (людських) читаються ключів та атрибутів зміни таблиць стає все більш поширеним знижуючи потребу в дорогих з'єднаннях, які можуть бути дуже важкими для розподілених баз даних. Також зверніть увагу, що підтримка коду і стиснення в форматі серіалізації, наприклад Parquet або ORC, або в рамках СУБД за допомогою Vertica, призводить до серйозної втрати продуктивності, яку зазвичай пов'язують з денормализация. Ці системи були створені для нормалізації даних, а зберігання вже за бажанням.

  • BLOBs: сучасні бази даних створювалися з урахуванням підтримки «Блобов» через власні типи і функції. Це відкриває нові можливості в моделюванні обробки даних і може дозволити зберігати в таблиці відразу кілька функціональних гранул (grains — прим. пер.) схеми БД, коли потрібно динамічна схема.

  • Динамічні схеми: з моменту появи map reduce і з зростанням популярності документації за підтримки «блобов» і баз даних, розвивати схеми БД без виконання DML стало помітно простіше. Це спрощує ітеративний підхід до зберігання даних і усуває необхідність досягнення повного консенсусу між продажами і розробкою.

  • Систематичний снапшутинг розмірності (збереження повної копії розміру таблиці для кожного графіка ETL-циклу, проводиться, як правило, в різних розділах таблиці) використовується в якості простого способу впоратися з SCD (slowly changing dimension). При цьому він вимагає мало зусиль і його, на відміну від класичного підходу, легко зрозуміти при написанні ETL і запитів. З його допомогою також можна легко і відносно дешево денормировать атрибут розмірності і таблицю, щоб відстежити її свідчення на момент завершення операції. У ретроспективі, складні методи моделювання SCD не інтуїтивні та знижують доступність.

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

Ролі та обов'язки
Сховище даних
«Сховище даних являє собою копію всіх переданих даних, яка спеціально структурована для запитів і аналізу», — Ральф Кімбол.

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

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

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

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

Часто подібне сховище даних стає для команди інженерів «центром передових розробок», на якому визначаються стандарти і застосовуються кращі рішення і процеси для сертифікації об'єктів БД. Така команда може прийняти участь в утворенні інших фахівців, ділячись своїми кращими рішеннями. Все це робиться для того, щоб інші інженери удосконалювалися в області роботи зі сховищами даних. Наприклад, Facebook має власну освітню програму «Data camp», а у Airbmb це «Data University». Там інженери проходять навчання по роботі з БД.

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

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

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

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

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

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

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

Ось кілька прикладів послуг, які можуть створити дата-інженери та інженери з обслуговування інфраструктури БД, які можна експлуатувати.

  • Поглинання даних: сервіси та інструменти побудовані навколо «вишкрібання» БД, завантаження логів, витягу даних із зовнішніх джерел або API…

  • Обчислення метрик: фреймворки для обчислення і підсумовування участі, зростання або пов'язаних з сегментацією показників.

  • Виявлення аномалій: автоматизація вжитку даних і система попередження потрібних людей про аномальні події або появі тенденцій до істотних змін.

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

  • Експериментування: написання експериментальних A/B-тестів і фреймворків часто є важливою складовою аналітики компанії зі значним обсягом інженерних даних.

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

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

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

Необхідні навички
Знання SQL: якщо англійська є мовою світового бізнесу, то SQL є мовою даних. Наскільки успішним бізнесменом ви хочете бути, якщо не добре говорите по-англійськи? Змінюються технології і покоління, але SQL міцно стоїть на ногах, як Лінгва франка миру даних. Дата-інженер повинен бути в змозі за допомогою SQL висловити такі речі, як «кореляція підзапитів» і віконні функції будь-якої складності. SQL/DML/DDL примітивні і досить прості для того, щоб не мати ніяких секретів від дата-інженера. Крім декларативного характеру SQL, інженер повинен бути в змозі прочитати і зрозуміти плани виконання БД, а також мати уявлення про те, як працюють всі етапи, індекси та різні алгоритми з'єднання і розподіленого вимірювання в рамках цього плану.

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

Дизайн ETL: здатність написання ефективною, гнучкою і «еволюціонує» ETL є ключовим фактором. Я планую більш широко зачепити цю тему в наступних публікаціях.

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

висновок
За останні п'ять років роботи в Кремнієвій долині і компаніях FAcebook, Airbnb і Yahoo!, плюс побічно взаємодіючи з командами дата-інженерів Google, Netflix, Amazon, Uber, LYFT і ще десятками організацій усіх розмірів, я спостерігав за еволюцією дата-інжинірингу і відчув, що мені потрібно поділитися деякими висновками. Я сподіваюся, що ця стаття може послужити свого роду маніфестом для цієї сфери. Я сподіваюся, що вона знайде відгук з боку співтовариства, з боку фахівців, що працюють в суміжних областях!
Джерело: Хабрахабр

0 коментарів

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