Ошибки конвейера данных: 40% неверных подсчетов аудитории

Одиннадцать дней.

Именно столько наш пайплайн работал идеально: с нулевым количеством ошибок, зелеными направленными ациклическими графами (DAG), чистой загрузкой в Snowflake и при этом выдавал показатели аудитории, которые в 40% случаев были неверными. Дата-пайплайн похож на цепочку перевода: если в источнике у какого-то слова меняется значение, а словарь никто не обновил, все последующие шаги превращаются в уверенный и ошибочный перевод. В нашем случае вышестоящая рекламная сеть тихо переименовала поле в полезной нагрузке своих событий. Наш ключ соединения Spark перестал совпадать. Счетчики сегментов рухнули. Не сработало ни единое оповещение.

Это заметил клиент. Его рекламная кампания не давала результатов. Мы проследили проблему до переименования одного поля в одной вышестоящей схеме.

Мы доверяли зеленым галочкам. Вместо этого нам следовало следить за цифрами.

Система, которая выглядела здоровой

Я работал старшим инженером по работе с данными (Senior Data Engineer) в InMarket (ранее NinthDecimal), ежедневно обрабатывая терабайты данных рекламных событий. Мы оперировали масштабами более чем в 1 ПБ данных о местоположении и рекламных событиях, изначально используя MapR, а затем мигрировав на S3. Мобильные SDK собирали сигналы IDFA/AAID, показы, клики, конверсии, события геолокации. Сырые события попадали в AWS S3. ETL-задания на Spark трансформировали их в структурированные наборы данных об аудитории. DAG-графы в Airflow оркестровали весь рабочий процесс. Преобразованные данные поступали в Snowflake. На выходе: дашпанели измерений и аналитика показов для рекламодателей.

Критический инвариант: показатели сегментов аудитории должны быть точными. Клиенты принимают реальные бюджетные решения на основе этих цифр. Если мой пайплайн ошибался, их расходы распределялись неверно.

Масштаб этой системы — одна из причин, почему тихие сбои настолько опасны. Когда вы обрабатываете миллиарды событий в день, падение счетчиков сегментов на 40% может днями маскироваться под обычную вариативность. Тот объем данных, который делает платформу ценной, одновременно делает сбои качества невидимыми, пока человек обычно не замечает, что что-то идет не так.

Рекламная сеть не дала нам никаких предупреждений, никаких уведомлений о миграции. Они переименовали одно поле и добавили новое. ETL-процесс на Spark продолжал работать без единой ошибки. Данные по-прежнему выглядели как данные. Результат по-прежнему выглядел как результат. Просто он был неверным.

Почему это повторяется снова и снова

Инцидент с отравлением схемы не был единичным случаем. Это паттерн. Каждый дата-инженер, с которым я общался, может рассказать свою версию этой истории. Детали меняются — переименованная колонка, сдвинутый часовой пояс, измененный перечисляемый тип (enum), — но структура всегда остается прежней: система успешно отработала, выдав некорректные результаты.

Согласно отчету Monte Carlo State of Data Quality Survey за 2023 год, 68% специалистов по работе с данными заявляют, что среднее время обнаружения инцидентов с данными составляет четыре часа или более — и это касается только тех инцидентов, которые они в итоге выявляют. Инциденты, которые никогда не вызывают тревогу и при которых цифры выглядят правдоподобно, но оказываются неверными, остаются незамеченными бесконечно долго.

Второй инцидент сделал этот паттерн неоспоримым. Ежедневный DAG в Airflow успешно завершился. Партиция S3 для этой даты существовала. Но сами файлы данных так и не поступили; вышестоящий фид SDK тихо прекратил передачу. Задание Spark обработало пустую партицию, записало пустой результат и отметило задачу как зеленую. Данные об аудитории за три дня исчезли до того, как кто-либо это заметил. Само существование партиции удовлетворяло любой проверке мониторинга, которая у нас была. Клиент заметил нули на своем дашпанеле раньше нас.

Оба инцидента имеют одну и ту же первопричину: система проверяла структурную полноту, а не семантическую корректность. DAG завершился успешно. Партиция существовала. В таблице были строки. Но цифры ничего не значили. Наш мониторинг был создан для отслеживания сбоев инфраструктуры — упавших заданий, пропавших файлов, тайм-аутов. Он никогда не проектировался для обнаружения данных, которые прибыли вовремя, в правильном формате, но при этом оказались просто неверными.

Как только мы назвали этот тип сбоя проверкой структуры вместо семантики, решение стало очевидным.

Куда я внедрил исправление

Мой подход теперь таков: валидация схем на границе приема данных (ingestion boundary). Проверяйте схемы входящих событий по реестру до того, как запустится какая-либо трансформация.

Большинство команд добавляют валидацию глубоко внутри пайплайна после трансформации. Я помещаю ее на входе. Несоответствие схем, обнаруженное на этапе приема, стоит считанные минуты. Обнаруженное после 11 дней распространения вниз по течению, оно стоит клиентских отношений.

В этом нет ничего сложного. Здесь нет инноваций. Но именно это отличает обнаружение тихого переименования поля за секунды от ситуации, когда оно портит 11 дней выходных данных.

Паттерн лейкхауса (lakehouse) не меняет эту математику. Лейкхаус, забитый плохими данными — это просто плохие данные с более удобным набором инструментов вокруг них. Архитектура дает вам инфраструктуру для выявления проблем с качеством, но только в том случае, если поверх нее вы выстраиваете семантическую дисциплину.

Что я отслеживаю теперь:

• Счетчики сегментов аудитории: бизнес-результат, а не системные метрики

• Свежесть данных: количество часов с момента последней успешной загрузки

• Показатели успешности/неуспешности валидации схем при приеме данных

• Проверки полноты партиций: количество файлов, объем в байтах, а не только факт существования партиции

• Окна выполнения SLA пайплайна

Ключевой сдвиг заключается в том, чтобы относиться к семантической корректности как к первоклассному измерению мониторинга. Не как к приятному дополнению. Не как к чему-то, что мы проверяем после жалобы клиента. А как к главному сигналу того, что пайплайн действительно работает.

Команды тратят колоссальные инженерные усилия на пропускную способность пайплайна, надежность инфраструктуры и стоимость хранения. Тихие сбои качества — цифры, которые неверны, но выглядят правильно — воспринимаются как чья-то чужая проблема до тех пор, пока их не заметит клиент. Большинство сбоев качества данных, с которыми я сталкивался, не были сбоями инфраструктуры. Это были ошибки в предположениях, которые никто не отслеживал.

Миф, который необходимо развеять: «Больше данных — всегда лучше». Больше данных означает больше затрат на хранение, больше затрат на вычисления, большую сложность схем и большую зону поражения для тихих сбоев качества. Прием абсолютно всех данных «на случай, если они понадобятся позже» — это верный путь к получению озера данных, которому никто не доверяет, и счетам за вычисления, которые никто не может объяснить.

Куда это движется дальше

Агентные рабочие процессы будут брать на себя операционные решения, которые в настоящее время требуют вмешательства человека: реагирование на дрифт схем, координация бэкфиллов (backfill), устранение проблем с качеством. Но агенты унаследуют ту же фундаментальную проблему: им нужно понимать, когда цифры неверны, а не только когда система «лежит».

Главная мысль для инженеров

Разберитесь в данных прежде, чем браться за инструменты.

Любой инструмент в вашем стеке существует для того, чтобы перемещать или трансформировать данные. Если вы не понимаете, что представляют собой данные, каковы их инварианты и где они ломаются, вас не спасет ни один инструмент. Узнайте, как выглядит здоровая строка. Узнайте, какой смысл бизнес вкладывает в это число. Узнайте, где вышестоящая система хрупка. Инструменты меняются каждые два года. Дисциплина понимания ваших данных — нет.

Проблема, которая у вас, вероятно, есть прямо сейчас

Пайплайн зеленый. DAG отработал. Данные доставили. Но цифры неверны — и об этом еще никто не знает. Именно с этой проблемой либо живут большинство дата-инженеров прямо сейчас, либо до нее отделяет всего одно изменение вышестоящей схемы. Не потому, что кто-то беспечен, а потому, что настройки по умолчанию в наших инструментах оптимизированы под вопрос «запустилось ли оно?», а не «правильно ли оно работает?».

Добавьте одну семантическую проверку сегодня. Это займет меньше времени, чем объяснение причин инцидента.

Сиддхарт Арун (Siddharth Arun) — старший специалист по техническому сопровождению (Senior MTS) в Salesforce, занимается созданием корпоративных пайплайнов миграции данных.

Добро пожаловать в сообщество VentureBeat!

Наша программа гостевых публикаций создана для того, чтобы технические эксперты делились инсайтами и предоставляли объективные, неангажированные глубокие обзоры по вопросам ИИ, инфраструктуры данных, кибербезопасности и других передовых технологий, формирующих будущее корпоративного сектора.

Читайте далее в рамках нашей программы гостевых публикаций и ознакомьтесь с нашими рекомендациями, если вы хотите опубликовать собственную статью!