Завдання дата-інженера — не лише налаштувати коректну роботу з даними, а й пояснити всім стейкхолдерам, як влаштована його робота. Інакше команда отримує нерелевантні запити, робочі процеси порушуються, а якщо хтось ще й використає hard delete замість soft delete — додаткового головного болю не уникнути.
Про те, що найбільше дратує Data Engineers, розповіла Тетяна Лелюх, Data Engineering Lead в Solidgate, партнерській компанії Genesis. Тетяна приєдналася до компанії чотири роки тому на позицію Data Analyst, а потім перейшла у Data Engineering й виросла до ліда команди.
Доступи для роботи з БД видають DevOps-інженери. Однак ці доступи мають властивість експайритися, тож ставити завдання на видачу нових потрібно часто. Оскільки команда DevOps робить це вручну, ймовірність помилки є завжди.
Видача доступів до нового сервісу — задача, яка потребує великої кількості кроків зі сторони DevOps-інженера, як-от створення користувача, відкриття мережевого доступу. Знову таки, є ризик помилитися через людський фактор: користувача створили, одну мережу відкрили, а другу — забули. Доводиться повертатися до цього завдання, просити виправити, чекати.
Окрема історія — ротація паролей до баз. Якщо це одна база даних, ситуація не критична. Але у дата-інженера таких баз десятки, й коли доступи заекспайрилися в декількох із них — стає сумно та боляче. Втім, зазначу що у фінтех-індустрії робота з доступами особливо необхідна з міркувань безпеки, тому це нормальне явище. Тут допомагає правильна комунікація та вибудовані процеси.
Посадові обов’язки дата-інженерів відрізняються від компанії до компанії: десь вони ближчі до аналітиків, десь займаються підготовкою даних до production. Через це не всі чітко розуміють, чим займається команда чи фахівець. Інформація з Google може згодитися, але її не завжди вийде застосувати до конкретної компанії.
Команда дата-інженерів в Solidgate виросла та нещодавно відокремилася від команди аналітики. Втім, деякі аналітичні запити, наприклад, наявність даних у Tableau-репортах, й досі за інерцією стікаються до нас. І навпаки — завдання щодо проєктування систем чи баз даних, які якраз належать до нашої зони відповідальності, відправляються до інших команд.
У Solidgate команда аналітиків займається доставкою даних з різних баз, які розкидані в системі, в єдине сховище. Ми також трансформуємо ці дані в потрібний для кінцевого споживача вигляд та займаємося їхньою валідацією. Аби уникнути непорозумінь у майбутньому, ми ввели практику: я роблю невеликий екскурс професією для новачків-аналітиків — а ми найтісніше співпрацюємо саме з цією командою — та пояснюю, за що відповідає наша команда, та як саме влаштовані дані у нас.
Самі по собі ні hard delete, ні soft delete не є поганими. Використання того чи іншого методу залежить від сутностей і того, як спроєктована система. Головне — не використовувати hard delete там, де може виникнути необхідність відновлювати дані.
Неправильне використання soft та hard delete може призвести до двох негативних наслідків. Перший — порушення зв’язків між сутностями. Наприклад, у нас є три таблиці, перша і третя пов’язані через другу. Якщо хоча б один рядок у ній видалити через hard delete, то зв'язок між першою й третьою таблицями зламається. Надалі це може призвести до непрогнозованих та неочевидних збоїв в системі.
Інший ризик пов’язаний з користувачами продукту. Уявіть, що юзер звертається з проханням, до прикладу, надати дані його платежу. Якщо їх чомусь видалили через hard delete, то відновити інформацію не вийде — і лояльність людини втрачено.
Тому натомість ми майже всюди рекомендуємо використовувати soft delete та маркування даних, а hard delete залишаємо лише для пари сервісів.
Дані не будуть корисними, якщо ми не впевнені в їхній якості. Висновки, сформульовані на хибних чи некоректних даних, можуть зашкодити більше, ніж їхня відсутність взагалі. Через це валідувати дані важливо на всіх етапах. Тобто, і розробники, і дата-інженери мають контролювати, що записується в БД, і чи записується туди щось взагалі. Останні також мають стежити, щоб дані залишалися валідними після їх маніпуляцій, як-от доставка чи трансформація.
Втім, для розробників це другорядне. У них є свій пул завдань — і часто до даних просто не доходять руки.
Виправити баг із записом не складно, складніше щось зробити з уже неправильно оформленими даними. Якщо їх багато — навантаження на БД зачепить і роботу інших систем. До того ж ручне втручання в сутності та помилки можуть призводити до непередбачуваних наслідків для системи.
Це класична проблема в усіх командах, що займаються IT-продуктами. Неочікувані запити не лише руйнують планування для команди дата-інженерів, а й суттєво ускладнюють роботу. Адже щоб дані були консистентними, після внесення змін код його потрібно «прогнати» на повному обсязі даних. Через це буває важко навіть розрахувати, скільки часу може зайняти робота. Особливо, коли мова йде про зміни історичних даних за три-чотири роки.
Натомість стейкхолдери часто очікують на швидке виконання запитів. І тут ми повертаємося до першого пункту — не всі розуміють, як працюють дата-інженери, та як налаштовані їхні процеси.
Аби подібних термінових запитів було менше, ми покращуємо планування на рівні всієї продуктово-технічної команди.
Таким можуть грішити новачки або ж ті, хто погано знає SQL. Якщо немає фільтра за датою, запит буде тягнути з БД не конкретну інформацію, а всі дані за декілька років. А тоді збільшується і час виконання завдання, і навантаження на систему. Всі ресурси починають працювати на читання, запис сповільнюється, сервіс починає деградувати — і врешті весь продукт «гальмує».
Крім того, якщо база даних погано спроєктована або дуже велика, решта запитів працює повільніше, тож вплив "SELECT * FROM Table" починає відчувати вся команда.
В аналітичному сховищі ми вирішуємо проблему через таймаути: база обробляє запит певний час, а потім відключає його.
У нашій системі — понад 15 різних БД на базі Postgres. Кожній відповідає конкретний сервіс, за які, своєю чергою, відповідає окрема команда розробників. За відсутності чіткої стандартизації, єдиної для усіх команд, дані «записуються» у різних форматах, а зв’язки між таблицями формуються за різними підходами.
Так, дані в колонці-ідентифікаторі в одній базі можуть зазначатися числами, в другій — за стандартом UUID, в третій буде ще якийсь формат. Або ще приклад — наявність поля, де зазначено час запису в базу. Наче як стандартна практика, але одні команди беруть його до уваги, а інші — ні. Через це бази даних у різних сервісах можуть проєктуватися різним чином — і на виході ми маємо таблиці в 15 БД, створені за 10 патернами. Як наслідок, інструмент для доставки даних, який розробляє команда дата-інженерів, треба дуже ускладнювати, прописуючи кілька варіантів обробки різних структур даних.
Вирішити проблему допомагає підготовка RFC зі стандартами проєктування БД та приведення власне баз до цього стандарту. Серйозність змін залежить від обсягу інформації: якщо історичних даних досить багато, то змінити все буде важко та ресурсозатратно. Тоді краще переробити інструмент відповідним чином та запровадити єдиний стандарт на майбутнє.