Что такое инструменты построения происхождения данных?

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

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

В этой категории теперь появился открытый стандарт — OpenLineage, который собирает метаданные о происхождении из заданий по мере их выполнения. Каталоги и облачные платформы, включая универсальный каталог Dataplex в Google Cloud, принимают эти события.

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

Программное обеспечение для работы с происхождением данных поддерживает актуальность карты происхождения по мере изменения конвейеров, поэтому никому не приходится перерисовывать ее вручную. Основная концепция и причины ее важности рассматриваются в материале «Что такое происхождение данных.»

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

Как инструменты происхождения данных фиксируют связи

Инструменты автоматического отслеживания происхождения данных используют три основных метода сбора. Во многих случаях развертывания сочетаются сразу несколько из них.

При статическом анализе кода и синтаксиса SQL инструмент считывает код трансформаций, хранимые процедуры, определения заданий и определения отчетов BI, на основе чего выстраивает связи. Это охватывает устаревшие системы, которые не передают данные о происхождении самостоятельно, включая задания ETL, написанные много лет назад. Слабым местом является все, что определяется во время выполнения, например динамически сгенерированный SQL.

При сборе данных во время выполнения или на основе событий конвейеры передают события происхождения по мере выполнения заданий, описывая, что каждое задание прочитало, что оно записало и каким образом. OpenLineage — это открытый стандарт для данного метода. Системы обработки данных, реализующие его, публикуют во время выполнения информацию об источниках данных, которые читает задание, выполняемой обработке и пунктах назначения результатов, а модель расширяется за счет аспектов (facets), содержащих дополнительные метаданные. Такие системы, как Apache Airflow, Apache Spark и Apache Flink, имеют интеграции с OpenLineage, а Marquez является эталонной реализацией API OpenLineage. Поскольку события поступают из самого задания, они отражают то, что фактически выполнялось в каждом конвейере данных.

При сборе на уровне платформы хранилище или озеро данных записывает происхождение из собственной истории запросов. Это наиболее тщательный метод внутри одной платформы и наиболее ограниченный при работе между платформами.

Гранулярность также имеет значение. Происхождение на уровне таблиц показывает, что один набор данных зависит от другого. Происхождение на уровне столбцов показывает, какие поля сформировали те или иные выходные данные, что соответствует уровню детализации, необходимому для анализа влияния. Аспект уровня столбцов в OpenLineage идет дальше и разделяет прямые связи, где значение выходного столбца получено из входного поля, и косвенные, где входные данные (например, условие соединения или фильтр) влияют на выходные данные, не являясь их источником. Изменение ключа соединения может изменить отчет, не затрагивая ни один столбец, отображаемый в отчете, и только косвенное происхождение показывает это. Эта спецификация все еще развивается, и наряду с аспектом уровня столбцов внедряются новые аспекты происхождения.

Инструменты происхождения также предоставляют два представления. Техническое происхождение показывает задания, таблицы и столбцы для инженеров. Бизнес-происхождение суммирует тот же поток в терминах, используемых администраторами данных (data stewards) и аудиторами, таких как бизнес-термины и отчеты.

Типы инструментов происхождения данных

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

Инструменты с открытым исходным кодом

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

Каталоги данных и платформы управления

Корпоративные каталоги и платформы управления объединяют происхождение с бизнес-глоссариями, рабочими процессами управления и политиками. Примеры включают Atlan, который принимает события OpenLineage в свой каталог; Collibra, предлагающая специализированный продукт для отслеживания происхождения данных; и Informatica, предоставляющая автоматизированное сквозное происхождение для поддерживаемых источников данных. Эти платформы обычно собирают данные о происхождении с помощью коннекторов и парсинга, и многие из них также принимают события OpenLineage.

Встроенное (платформенное) происхождение

Основные платформы данных фиксируют происхождение для рабочих нагрузок, выполняемых на них:

• Databricks Unity Catalog: автоматически фиксирует происхождение для запросов, выполняемых в Databricks, вплоть до уровня столбцов, для рабочих областей, подключенных к одному хранилищу метаданных.
• Snowflake: записывает связи между объектами Snowflake, включая происхождение столбцов, и отображает их на вкладке «Происхождение» (Lineage) в Snowsight.
• Google Cloud Dataplex Universal Catalog: автоматически записывает происхождение для поддерживаемых сервисов Google Cloud и может импортировать события OpenLineage из других источников.

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

Инструменты трансформации и наблюдаемости

Инструменты трансформации, такие как dbt, строят граф зависимостей на основе управляемых ими моделей, а поставщики средств наблюдаемости за данными, такие как Monte Carlo и Datafold, располагают происхождение рядом со своими возможностями мониторинга и тестирования. Происхождение здесь поддерживает реагирование на инциденты и тестирование изменений, а не служит записями для целей управления.

Специалисты по парсингу кода

Некоторые инструменты ориентированы на глубокий статический анализ SQL, ETL и кода BI в сложных или устаревших средах. Например, Cloudera Data Lineage (ранее Octopai) автоматизирует сбор метаданных и сопоставление происхождения с возможностью обнаружения данных в гибридных средах.

Как оценивать инструменты происхождения данных

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

• Охват: подключается ли он ко всем системам, через которые проходят данные, включая устаревшие базы данных, приложения SaaS и конвейеры ИИ, или только к хранилищу данных?
• Гранулярность: фиксирует ли он происхождение на уровне столбцов и записывает ли косвенные связи, такие как соединения (joins) и фильтры?
• Стандарты: генерирует ли он или принимает события OpenLineage, или же информация о происхождении заперта внутри одного продукта?
• Актуальность: фиксируется ли происхождение непрерывно по мере выполнения заданий или перестраивается по расписанию?
• Представления: предлагает ли инструмент техническую линейность для инженеров и бизнес-линейность для стюардов и аудиторов?
• Контекст: может ли он показать, какие потоки переносят конфиденциальные или регулируемые данные — либо с помощью собственной классификации, либо путем интеграции с инструментом обнаружения и классификации?
• Открытость: существуют ли API и параметры экспорта, чтобы линейность могла наполнять каталоги, политики доступа и доказательства для аудита?

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

Почему линейности необходим контекст данных

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

Обнаружение и классификация добавляют эту информацию. Когда информационные активы обладают классификацией и контекстом (такими как конфиденциальность, принадлежность и разрешенное использование), линейность позволяет напрямую отвечать на вопросы управления. В какие нижестоящие отчеты попадает столбец, содержащий идентификаторы клиентов? Какие наборы данных для обучения ИИ использовали таблицу, содержащую медицинские данные? Этот контекст является предметом управления метаданными [LINK TK: metadata management PK URL to confirm], и он позволяет линейности поддерживать элементы контроля доступа и управления.

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

Как помогает Everpure

Everpure Data Intelligence предоставляет контекст данных, которого не хватает графам линейности. Это не инструмент линейности. Он работает выше по потоку относительно инструментов линейности и каталогов:

• Обнаружение по всей инфраструктуре: автоматически сканирует, идентифицирует и классифицирует наборы данных на Everpure Platform, в SaaS-приложениях, публичном облаке, векторных базах данных, мейнфреймах и сторонних хранилищах
• Идентификация конфиденциальных данных: определяет PII, PHI и другие конфиденциальные данные, благодаря чему узлы в графе линейности могут быть помечены в соответствии с тем, что они содержат
• Семантический контекст: генерирует контекст для каждого набора данных, позволяя инструментам, сопоставляющим потоки данных, показывать, какие потоки переносят конфиденциальные или регулируемые данные

Заключение

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

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

Часто задаваемые вопросы об инструментах линейности данных

Что такое пример линейности данных?

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

Почему компании инвестируют в инструменты линейности данных?

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

В чем разница между происхождением данных (provenance) и линейностью данных?

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

Можно ли фиксировать линейность данных вручную?

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

Работают ли инструменты линейности данных в облачных и локальных (on-premises) системах?

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