Від аналітика до інженера: ETL-пайплайн та інженерне мислення

Шлях до інженерії даних: Навчання через побудову

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

Перший досвід: ETL для GitHub

Першим проєктом був ETL-пайплайн для GitHub. Він починався як простий Python-скрипт для отримання даних репозиторіїв та експорту їх у CSV-файл. Згодом його вдосконалили: CSV-файли замінили на SQLite, пайплайн зробили ідемпотентним для запобігання дублюванню даних, а автоматизацію реалізували за допомогою GitHub Actions.

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

Мета другого проєкту: Навіщо ще один ETL?

Після першого проєкту автор вирішив побудувати ще один ETL-пайплайн — автоматизований пайплайн для отримання RSS-стрічок. Метою було не створення нового читача RSS, а дослідження інженерних рішень, які перетворюють Python-скрипт на надійний конвеєр даних.

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

Архітектурні рішення: Пошаровий підхід

Першим архітектурним рішенням було використання Docker. Автор вирішив будувати проєкт пошарово, спочатку розробивши Python ETL, який отримував RSS-стрічку, парсив її та зберігав у PostgreSQL. Для забезпечення безпечного повторного виконання вставки в базу даних були зроблені ідемпотентними за допомогою ON CONFLICT DO NOTHING у PostgreSQL.

Лише після того, як ETL та база даних працювали разом, було впроваджено Docker. Docker став одиницею виконання, роблячи застосунок самодостатнім. Це забезпечило послідовне середовище виконання, незалежно від того, де запускався контейнер, і значно спростило налагодження. Кожен шар перевірявся незалежно, перш ніж додавався наступний: Python ETL, потім PostgreSQL, потім Docker, і нарешті Kestra.

Розуміння ролі оркестратора: Kestra та Docker

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

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

Автоматизація та стійкість: Розклад, повтори та ідемпотентність

Після того, як пайплайн почав працювати автоматично, виникли нові виклики. Було налаштовано погодинний розклад у Kestra за допомогою cron-виразу.

Для обробки збоїв Kestra було налаштовано на автоматичні повторні спроби виконання з певним інтервалом. Це підкреслило розділення відповідальності: ETL зосереджений на обробці даних, а оркестратор — на стійкості.

Ідемпотентність, реалізована в базі даних за допомогою ON CONFLICT (id) DO NOTHING, гарантувала, що повторні запуски не створюватимуть дублікатів записів, навіть якщо одна й та сама стаття RSS з'являлася в кількох запусках.

Покращення видимості: Логування

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

Кінцева архітектура та ключові висновки

Кінцева архітектура виявилася простою: Python знає, як отримувати, парсити та зберігати статті RSS; PostgreSQL знає, як безпечно зберігати дані та запобігати дублікатам; Docker забезпечує послідовне середовище виконання; Kestra вирішує, коли робоче навантаження має запускатися та що робити у разі збою. Жоден з компонентів не намагається виконувати роботу іншого.

Найважливіший висновок полягає в тому, що інженерія починається після того, як скрипт працює. Це вимагає мислення про системи, а не лише про окремі функції. Розділення відповідальності між виконанням (Python-застосунок) та оркестрацією (Kestra) є ключовим. Docker став артефактом розгортання, що забезпечує впевненість у послідовності виконання. Найціннішим уроком стало інкрементальне будівництво: створювати найменшу робочу частину, перевіряти її, а потім додавати наступний шар.

Що це означає для розробників

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

Ключові факти

Перехід від аналітика до інженера даних через "навчання через побудову" з проєктами.
Перший ETL-проєкт (GitHub) виявив, що логіка ETL легка, а оркестрація та надійність — складніші.
Другий ETL-проєкт (RSS) був спрямований на вивчення інженерних рішень для надійних конвеєрів даних за допомогою Kestra.
Пошаровий підхід до розробки: Python ETL -> PostgreSQL (з ідемпотентністю) -> Docker -> Kestra.
Docker став одиницею виконання, забезпечуючи послідовне середовище та спрощуючи налагодження.