Выше показан пример реального конвейера данных, который поддерживает критически важный для бизнеса конвейер с 10 источниками данных, структурами приема и преобразованиями ETL, выполняемыми на нескольких платформах обработки. Чтобы усложнить задачу, несколько команд в бизнес-единицах управляют разными частями этих конвейеров. Эти конвейеры работают ежедневно с соблюдением строгого времени выполнения SLA, а также должны иметь точную аналитическую информацию (представьте финансовую панель с неверными данными о продажах). Ежедневное управление тысячами таких конвейеров данных - сложная проблема для всей отрасли, особенно с использованием собственных инструментов и технической задолженности устаревших фреймворков.

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

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

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

  • Сканирование: отслеживание происхождения конвейеров данных от исходных баз данных до выходных панелей мониторинга и моделей.
  • Прогулка: запись трехуровневых событий отладки для каждого преобразования в конвейере данных: a) события инфра-уровня; б) События на уровне должностей; c) События на уровне данных
  • Выполнить: автоматическое обнаружение аномалий и автоматические выключатели для упреждающего решения проблем с конвейером данных.

Сканирование: отслеживание происхождения конвейеров данных

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

В Intuit мы разработали SuperGlue - инструмент, который беспрепятственно отслеживает происхождение сложных производственных конвейеров, что позволяет аналитикам, специалистам по данным, инженерам самостоятельно интерпретировать, отлаживать и повторять конвейеры данных. . Учитывая выходные данные конвейера данных (таблица или отчет), Superglue обеспечивает полное обратное происхождение. Ниже приведен пример конвейера отчетов Qlik.

Отслеживание происхождения данных осуществляется путем анализа запросов, связанных с заданиями конвейера. В частности, конвейер состоит из заданий; каждое задание состоит из одного или нескольких скриптов; каждый сценарий состоит из одного или нескольких операторов SQL. SQL-запрос анализируется для таблиц ввода и вывода. Происхождение конвейера определяется как массив троек ‹Имя задания, Таблицы ввода, Таблицы вывода›. Это не разовое мероприятие. Он постоянно развивается. Каждый сценарий состоит из одного или нескольких запросов на разных языках: SQL с некоторыми из Pig. Затем они склеиваются, и результат одного из них становится входом для следующего задания.

Прогулка: корреляция между 3-мя уровнями событий конвейера данных

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

  • События уровня инфраструктуры или структуры ориентированы на отслеживание событий и статистики из компонентов системы, а именно исходных баз данных, инструментов приема, сред планирования, аналитических механизмов, обслуживающих баз данных, платформ публикации (таких как Tableau, QlikView, SageMaker и т. д.) .)

  • События на уровне задания, связанные с приемом, очисткой, преобразованием, обработкой. Состояние работ включает в себя отслеживание связанной с выполнением статистики, такой как время завершения, время начала и т. Д.

  • На уровне данных или бизнес-событиях основное внимание в этом сегменте уделяется анализу шаблонов, связанных с данными, путем сопоставления бизнес-KPI. Захватывая поток бизнес-событий, мы можем создать широкое представление о сквозных потоках. Позволяет построить традиционный мониторинг и оповещение, а также диагностику событий «черный лебедь».

Бизнес-события помогают отладить несколько форм проблем несогласованности данных.

Run: Автоматическое обнаружение аномалий и автоматические выключатели для автоматической проверки данных

До сих пор мы обсуждали процесс разработки распределенной трассировки для Data Pipeline Observability. Учитывая масштаб, наша цель - автоматизировать изучение шаблонов, чтобы проактивно избегать проблем с конвейером данных. Стандартные методы обнаружения аномалий (такие как LinkedIn's Thirdeye) могут помочь выявить несоответствия в событиях выполнения на уровне заданий и бизнес-событиях.

По аналогии с архитектурой автоматические выключатели в микросервисах мы проектируем автоматические выключатели для конвейеров данных. При наличии проблем с качеством данных цепь размыкается, предотвращая распространение данных низкого качества на последующие процессы. В результате данные будут отсутствовать в отчетах за периоды времени низкого качества, но если они есть, то они гарантированно верны. Такой подход исключает часы / дни / недели отладки и проверки показателей / отчетов в каждом конкретном случае.

Таким образом, структура наблюдаемости для конвейеров данных в реальном мире сегодня просто необходима. Сложность этой проблемы зависит от масштаба (тысячи ежедневных конвейеров), качества данных (по источникам и преобразованиям) и технического долга в ETL и устаревших технологиях. Решение этой проблемы с помощью специального мониторинга аналогично войне с вилкой!