Технический долг в data pipeline: почему \"потом перепишем\" почти никогда не случается
Пайплайны данных стареют быстрее, чем кажется, особенно если никто не владеет схемой. Откладывание рефакторинга имеет конкретную цену.
В большинстве компаний первый pipeline данных строится быстро и под конкретную задачу. Выгрузка из базы, пара трансформаций, загрузка в хранилище или Excel. Работает - и ладно. "Потом, когда будет время, нормально перепишем."
Это "потом" в большинстве случаев не наступает никогда. В статье про ETL как производственную линию описаны структурные режимы сбоев; то, что описывается здесь - как эти режимы со временем затвердевают в технический долг. Не потому что команда ленивая или не понимает проблемы. А потому что система устроена так, что срочное всегда вытесняет важное - а пока pipeline работает, он не является срочным.
Но стареет он быстро. И незаметно.
Как накапливается долг в данных
Пайплайн данных не деградирует так, как ломается приложение. Он не падает - он тихо перестаёт быть правдой.
Схема источника изменилась - в поле появился новый тип значений, который никто не обработал. Появилась новая таблица, которую забыли включить в выгрузку. Логика трансформации написана так, что работает на текущих данных, но сломается на краевых случаях, которые пока не встречались.
Самое опасное - когда никто не владеет схемой. Это значит: никто точно не знает, что поле X означает в системе-источнике и как оно должно интерпретироваться на выходе. Грязные справочные данные ломают любой BI - проблема владения схемой и приводит справочность в это состояние. Этот контекст был у того, кто строил pipeline год назад. Теперь он живёт в устных преданиях или не живёт нигде.
Такой pipeline становится чёрным ящиком. Он что-то делает, результат похож на правдивый - но проверить нельзя.
Почему рефакторинг не происходит
Если технический долг понятен и известен - почему его не гасят? Я вижу три устойчивых причины.
Первая - нет владельца. Пайплайн написал аналитик или разработчик, который решал задачу. После решения задачи он перешёл к другой. Никто не назначил ответственного за поддержку и развитие этого куска инфраструктуры.
Вторая - нет видимости. Технический долг в данных невидим для бизнеса ровно до момента, когда он проявляется в неправильных отчётах или сбоях. Инвестиция в рефакторинг pipeline трудно обосновывается - "мы сделаем то, что уже работает, чтобы оно продолжало работать, только лучше". Это не звучит как приоритет.
Третья - страх сломать. Когда pipeline непонятен и не документирован, его страшно трогать. Любое изменение может что-то сломать - и непонятно что. Поэтому к нему добавляют костыли поверх, не трогая основу.
Это классическое поведение с техническим долгом. Пока не сломалось - не чинят. Когда сломалось - чинят в панике.
Когда долг становится критическим
Есть несколько признаков, что ситуация переходит в опасную зону.
Первый - когда изменение в источнике (смена структуры таблицы, переезд системы, обновление API) требует непропорционально большого времени на адаптацию pipeline. Если смена поля в источнике приводит к неделе работы на исправление цепочки - это долг, который стоит денег.
Второй - когда аналитики тратят значительную часть времени на "починку" данных вместо анализа. Если они регулярно знают, что "вот тут данные немного кривые, надо поправить руками" - pipeline не работает, работают люди вокруг него.
Третий - когда никто не может ответить на вопрос "почему в отчёте такое число". Если для объяснения результата нужно часа три и звонок коллеге - доверие к данным уже потеряно, даже если это пока не признаётся вслух.
Как выйти из этого состояния
Переписывать pipeline с нуля - дорого и рискованно. Инкрементальный подход работает лучше.
Начать с документации: описать, что делает каждый шаг, откуда приходят данные, что является источником правды для каждого поля. Это само по себе обнаруживает противоречия и пробелы.
Назначить владельца - человека, который отвечает за работоспособность и понимание pipeline. Это не обязательно разработчик полного времени. Это ответственность, а не должность.
Добавить мониторинг: объём данных, количество пустых значений, критические диапазоны. Если что-то ломается - это должно быть видно как сигнал, а не обнаруживаться при следующей попытке использовать отчёт.
Рефакторинг модулями: не переписывать всё сразу, а изолировать и переделывать по частям, начиная с самых хрупких.
Вопросы, которые помогают оценить текущее состояние:
- Кто последний раз вносил изменения в pipeline и помнит ли он зачем?
- Есть ли документация по схеме и логике трансформаций?
- Как долго занимает адаптация при изменении источника?
- Есть ли алерты, которые срабатывают до того, как аналитик обнаружит проблему?
- Знает ли кто-то из команды, какой процент данных проходит все шаги без исключений?
Если большинство ответов - "не знаем" или "надо проверить" - это и есть описание долга. Не абстрактного, а конкретного.