Інженерія даних — це не лише скрипти: Уроки побудови ETL-пайплайну

Початкове уявлення про інженерію даних

На початку свого шляху до інженерії даних, автор вважав, що ця сфера зводиться до написання скриптів для процесу ETL (Extract, Transform, Load). Це уявлення ґрунтувалося на простому принципі: витягнути дані з одного місця, очистити їх, а потім завантажити кудись корисно. Як навчальний приклад, було створено ETL-пайплайн, що витягував дані з GitHub API, очищав їх та зберігав у CSV-файл. Цей скрипт працював і був зрозумілим, але його обмеження виявилися, коли виникла потреба зробити його "готовим до виробництва".

Перша перешкода: Пайплайн без пам'яті

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

Друга перешкода: Зникнення даних за ніч

Наступна проблема була пов'язана з персистентністю даних. База даних SQLite, створена в середовищі Colab, зникала після закриття сесії. Це означало, що щоранку доводилося запускати все знову, ризикуючи втратити роботу. Стало очевидним, що реальний пайплайн не може залежати від того, що хтось буде його перезапускати щодня. Дані повинні зберігатися в місці, яке переживає завершення сесії. Рішенням стало підключення Google Drive безпосередньо в Colab і збереження бази даних туди, забезпечуючи збереження даних незалежно від сесії.

Третя перешкода: Ніхто не може натискати "Запустити" вічно

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

Ключові зміни у пайплайні

Заміна CSV на SQLite: Замість збереження даних у CSV-файл, що є простим текстовим файлом, дані почали зберігатися в базу даних SQLite. Це дозволило виконувати SQL-запити, перевіряти вміст та масштабувати дані.
Виправлення проблеми дублювання: Реалізовано механізм ідемпотентності. Перед вставкою нових записів, пайплайн перевіряє, чи існує запис за унікальним URL. Якщо так, він видаляється, а потім вставляється свіжа версія, забезпечуючи відсутність дублікатів.
Персистентність даних у Google Drive: Змінено шлях збереження бази даних з тимчасового середовища Colab на Google Drive (/content/drive/MyDrive/github_repos.db). Це гарантує, що дані залишаються доступними після закриття сесії.

Переосмислення інженерії даних

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

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

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

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

Початкове уявлення про інженерію даних зводилося до написання скриптів ETL (Extract, Transform, Load).
Перша проблема: пайплайн без пам'яті призводив до дублювання даних при повторних запусках.
Вирішенням проблеми дублювання стала реалізація ідемпотентності – перевірка та видалення існуючих записів перед вставкою нових.
Друга проблема: дані, збережені в тимчасовому середовищі Colab, зникали після закриття сесії.
Вирішенням проблеми персистентності стало збереження бази даних SQLite на Google Drive.