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

Сиддхарт Арун

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

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

Один из клиентов это заметил. Его рекламная кампания не показывала хороших результатов. Мы выяснили, что причина заключалась в переименовании одного поля в одной из исходных схем.

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

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

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

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

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

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

Почему это постоянно происходит?

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

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

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

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

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

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

Мой нынешний подход: проверка схемы на границе приема данных. Проверка схем входящих событий на соответствие реестру перед выполнением каких-либо преобразований.

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

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

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

Что я сейчас отслеживаю:

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

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

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

• Проверка полноты разделов : количество файлов, количество байтов, а не только наличие раздела.

• Окна завершения SLA трубопровода

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

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

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

Что будет дальше?

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

Одна строка для инженеров

Сначала разберитесь с данными, а затем уже используйте инструменты.

Каждый инструмент в вашем наборе инструментов существует для перемещения или преобразования данных. Если вы не понимаете, что представляют собой данные, каковы их инварианты и как они дают сбои, ни один инструмент вас не спасёт. Научитесь понимать, как выглядит исправная строка. Поймите, что, по мнению бизнеса, означает это число. Узнайте, где исходная система уязвима. Инструменты меняются каждые два года. А вот умение понимать свои данные — нет.

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

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

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

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

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

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

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

Источник: venturebeat.com