Тут ми налаштовуємо процеси як отримати потрібні нам дані і “завести” їх в систему.
Для грамотної роботи, дата інженери мусять скоординувати свою роботу з потребами інших команд, які можуть виступати у ролі подальших споживачів даних. Ingestion можна класифікувати по-різному, один з варіантів – за видом отримання даних.
Один з варіантів походження даних буде, скоріше за все, зрозумілий людям, що працюють у вебі. Якщо вам по http треба передати дані, то ви або маєте можливість зробити певний запит на якийсь ендпоінт, чи маєте налаштовані вебхуки, куди періодично надходять дані. Деякі компанії мають лише веб інтерфейси для даних у вигляді якихось JSON API (авжеж, і інші формати можливі). В цьому випадку інженеру треба знати за яким посиланням треба ходити на цей third party API, налаштувати відправку запитів, разово чи періодично, і відповідно обробляти відповіді системи (і помилки теж), і зберігати ці дані.
Більш нестандартними підходами, які поширені у дата-інженерів в більшій мірі, ніж звичайних розробників веб-додатків, – це scraping. Якщо хтось не хоче віддавати вам дані у підходящему машинозчитуваному форматі, але у них є html сторінки з потрібною вам інформацією, то ви можете налаштувати ваших павуків-кроулерів витягати всі необхідні вам дані, і вже на своїй стороні розкласти їх по колонках своєї бази. Щось подібне до того, що роблять пошукові системи, але з більшою кількістю регекспів і селекторів, які заточені під конкретну структуру сторінок, з якими ви працюєте. Можливо, це вже межує з дата рекетом, але це вважається прийнятним згідно чинного законодавства. I судячи з кількості заявок на фріланс біржах, веб-скрапінг набуває все більшої популярності. Люди починають розуміти, що дані – це така собі нафта, яку варто качати, а далі вже придумаєш, яку резину чи пластик будеш з неї робити.
Альтернативою веб запитів може бути робота з операційними базами даних напряму. Для цього інженери працюють безпосередньо зі снепшотами, або лише дельтами цієї операційної структури, щоб підготувати для подальшої роботи аналітиків. Для цього дата інженери налаштовують пайплайни-”трубопроводи”, що переливають ці операційні дані в аналітичні сховища даних чи дата лейки.
Ну і так само джерелом надходження даних можуть бути черги повідомлень, та ж Kafka. Це можливо, наприклад, у випадках, коли у вас система побудована у вигляді великої мікросервісної архітектури, де ваші дані відправляються у спільну чергу повідомлень, організовану за топіками-”темами”. В цьому випадку задачею дата-інженера буде налаштування ефективного зчитування цих даних і організації зберігання з подальшим доступом до них.
Дуже часто ingestion закінчується тим, що дані опиняються в дата лейку, адже це не вимагає якихось дуже важких зусиль по формуванню як самої структури даних так і дизайну бази, і в ролі дейта лейку може виступати будь-якийHDFS сторейдж або s3 / blob storage у авс / гугл клауді.
Після того, як ваші дані вже пройшли ingestion у вашу систему, і вони вже “перетравлені” вашим гейтвеєм, саме в цей момент ви можете починати отримувати певну корисну інформацію, трансформуючи ваші дані. Сам концепт ETL, по суті, – це доволі абстрактний перелік фаз, через які проходять ваші дані: Extract - transform - load. Але безпосередньо в вашій системі ETL для кожного домену і сховища даних буде відокремленим, як і баги в ньому, уж повірте. Кінцева мета – завантажити очищені і збагачені дані у потрібне місце. Цим місцем буде якась база даних, сховище даних чи інший рівень вашого дейта лейку.
Існує мільйон інструментів для імплементації ETL, і мабуть що найбільш явний поділ існує за характером проведення ETL: чи ж то streaming потоковий, чи ж то batch пакетами. Звісно, вибір виду ETL залежить від специфік вашої системи. Історично цей напрям розвивався з батчевого ETL, тому що це набагато легше імплементувати.
Що мається на увазі під батчевим ETL? Це конфігурація, коли ingestion система агрегує дані за певну кількість часу (по годині, дню, тижню, і т.д.). Після цього ваша ETL система забирає дані за цей проміжок часу і намагається зробити певні агрегації або якісь трансформації з цими даними, щоб привести їх до виду, коли ці дані вже можуть у своїй роботі використати аналітики, дата саєнтисти або люди з вмінням користуватися чимось на кшталт Power BI / Tableau для якогось базового бізнес аналізу. Батчевий ETL в такому випадку не вимагає глобальних змін у вашу систему. Все, що вам потрібно, це мати endpoint, куди можна класти ваші логи/метрики чи будь-які сутності вашої системи для подальшого накопичення. Вже класичним для батчевогу ETLу став інструмент Apache Spark. Зазвичай люди налаштовували Hadoop або Spark джоби поверх HDFS (файлова система для великих файлів, створена у Hadoop Foundation). Така джоба якраз буде брати подібний великий шматок даних, виконувати map-reduce операцію і давати на вихід згруповані дані, які або самі по собі можуть мати аналітичну цінність чи слугувати основою для OLAP кубів і чекати свого часу, коли аналітики на них подивляться. І вже ці дані ми зберігаємо у сховище даних.
Що ж до стрімінгового ETL, то тут, замість того, щоб накопичувати дані і періодично їх обробляти, має місце буквальний поток даних, які потрібно обробити. В цьому сенсі стрімінгови ETL вимагають більших попередніх інвестицій з точки зору роботи системи. Зазвичай, в концепції стрімінгу в нас мають бути певні пари publish/subscribe стрімів, куди б надходила наші дані.Наша задача – обробляти поток оновлених даних, що надходять, проводити певні трансформації і вже ці більш підготовлені дані складати або в сховище даних або зливати у дейта лейк. Така собі дата загата. Звісно, для потокового ETL є багато інструментів, які стали вже класичними. Важко не згадати в цьому контексті ту ж саму кафку, яку часто використовують для того, щоб стрімити дані. Але кафка, загалом, є низькорівневим інтерфейсом, тому поверх неї є більш високорівневі надбудови для ETL. Наприклад, Apache Flink, який дозволяє робити бізнес логіку поверх стрімів у реальному часі за допомогою абстракцій більш високого рівня.
Ну і наостанок можна зауважити, що бувають і варіанти, коли обидва типи співіснують і ми отримуємо третій вид – гібридний. Коли в нас є напівпакетна, напів потокова структура і від цього виграють всі, через те, що цей підхід не буде вимагати дуже великих інвестицій в плані реорганізації системи. Замість того, щоб робити батчевий ETL ми можемо мати батчевий ingestion і потім з цього створювати стрім даних. Або ж навпаки, ми можемо використовувати Spark Stream який в принципі забезпечує потокову обробку даних, але на мінібатчах. Тобто це все одно батчевий процесинг, але система за вас робить автоматичне накопичення даних за певне вікно часу і після цього його обробляє. В цьому сенсі streaming vs batching має все менш і менш чітке розмежування.
Розглянемо ці підходи на абстрактному прикладі у вакуумі. Припустимо, у нас є деяка кількість офлайн магазинів, і оскільки ми не дуже знаємо 1С, будемо вважати, що з компʼютеризацією все настільки погано, що на касі продавець реєструє кількість проданих товарів у Excel таблиці. І в кінці дня вони відправляють дані про продажі імейлами чи заливають на FTP. Тоді першим кроком для ingestion буде лізти на FTP і викачувати ці таблиці даних. Далі ми вже читаємо всі наші табличні файли і починаємо їх процесити, агрегувати і отримувати результати. І це наш перший сценарій. Візьмемо другий сценарій. В ньому знову ж таки є оффлайн магазини, але в цій мережі магазинів витратили більше грошей на айті відділ, і або побудували, або купили вже систему, в якій кожен факт продажу одразу передається у чергу повідомлень.
І тут одразу можно побачити плюси і мінуси кожного з варіантів підходів. Якщо ми працюємо з даними пакетно, то ми можемо у будь-який момент вирішити, як ми хочемо обробляти ці дані. Ми можемо обробляти дані раз в день, як вони приходять, або робити це рідше, до поки в нас місця на FTP сервері вистачить. Якщо в нас зламається щось при генерації нашого звіту, то це буде означати лише те, що нам треба внести відповідні зміни в код (чи інфрастуктуру) і повторити спробу обробити поточні файли. Якщо у нас в черзі повідомлень що працює в “реальному часі” щось піде не так, а ця черга буде мати якийсь ретеншн (повідомлення з нею будуть видалятися через деякий час), то це і буде нашим вікном, за яке ми мусимо встигнути все відремонтувати і отримати дані, інакше ми можемо їх втратити. У сценарії з потоковоими даними, є більше вимог до стабільності системи, які охоплюють і ваш код, і інструментарій, на якому побудована ваша дата платформа, і залізо, на якому це виконується. Але плюсом тут буде те, що в пакетній обробці даних отримувати інсайти повноцінно ви зможете лише в той момент, коли всі дані оброблені, а в потоковому варіанті у вас гіпотетично буде можливість мати швидку відповідь на питання CEO всієї цієї мережі магазинів про “що там, як сьогодні продається наш улюблений товар в порівнянні з учорашніми продажами після запуску реклами у метро”. В цьому сенсі підхід до отримання даних для аналітики може мати прямий вплив на те, як працює бізнес, оскільки більш швидка аналітика = більше можливості швидко реагувати на зміни і вживати заходів. У різних сценаріїв є різні компроміси.
Так, що там в нас далі… Дата інженери в принципі організували ingestion даних, дані потрапили в систему, провели ETL. Дата інженери отримали якісь формалізовані вимоги про те, до якого виду мусять бути приведені дані, які і як саме, і далі можуть передавати ці дані, кому треба: аналітикам, дата саєнтистам, бізнесу, і після цього з гордістю стверджувати “ми все зробили”. Аналітики, зазвичай, будуть хотіти щоб дані були у якомусь сховищі даних, щоб мати зручний SQL інтерфейс, або хоча б Spark SQL інтерфейс. Для дата саєнтистів же, в принципі, достатньо буде, щоб дані були у якомусь більш-менш агрегованому вигляді, навіть тому самому дейта лейку. Звідти вони можуть брати вхідні дані і почати роботу препроцесінгу даних і генерації ознак (feature extraction) для подальшої побудови моделей. Цим зазвичай робота дата-інженера тут і закінчується. На цьому етапі важливо, щоб в певний момент кінцеві користувачі даних дізналися, що а) дані є, дані зібрані, б) як і де до них можна отримати доступ, яка природа даних з точки зору структури колонок і можливих даних. В цьому плані сховища даних трішки ліпші у розумінні, тому що маючи SQL інтерфейс можна дізнатися схему таблиць, в яких дані зберігаються. Але деяка кількість формалізованих каналів комунікації та документації так чи інакше мусить бути присутня.