Полное руководство по происхождению данных в 2022 году
Что такое происхождение данных?
Обновлено в ноябре 2021 г.
Традиционно происхождение данных (data lineage) рассматривалась как способ понять, по какому пути данные идут через все ваши системы обработки: из каких источников поступают, куда переходят в среде и, что не менее важно, что происходит с ними на протяжении всего пути.
Но реальное происхождение данных — это нечто гораздо большее. Происхождение данных представляет собой подробную карту всех прямых и косвенных зависимостей между объектами данных в среде. Почему это так важно? Вот несколько примеров, которые выходят за рамки традиционного определения происхождения данных. Подробная карта зависимостей расскажет вам:
- Как изменение алгоритма расчета бонусов в данных о продажах повлияет на ваш еженедельный финансовый прогноз (и понравится ли он вам)
- Какое лучшее подмножество тестовых случаев будет охватывать большинство сценариев потока данных для вашего недавно выпущенного приложения - базы данных ценообразования?
- Как разделить систему данных на более мелкие фрагменты, которые можно перенести в облако независимо друг от друга, не нарушая работу других частей системы.
Такая карта является основным компонентом современного стека данных, позволяя нам упростить его, сохранить эффективность и избежать нормативных или аналогичных штрафов.
Почему мы говорим о происхождении данных в 2022 году?
За последнее десятилетие процесс управления данными претерпел значительные изменения. С первых дней бизнес-аналитики, используя исторические данные для получения информации о бизнесе, мы перешли в эпоху больших данных, собирая данные и не задумываясь о том, зачем они нам и обучая современные алгоритмы AI/ML прогнозировать будущее нашего бизнеса. А потом мы начали задавать вопросы о конфиденциальности, пытаясь установить границы того, что этично, а что нет. И все это время наша инфраструктура данных усложнялась — от пакетной обработки структурных данных мы стали невероятной экосистемой с тысячами компонентов, нацеленных на одно: извлекать больше пользы из данных этическим путем. Такая экосистема слишком сложна для человеческого мозга, слишком разнообразна, и слишком взаимосвязана. И у нее есть последствия.
- Замедленное предоставление новых аналитических/прогнозных данных из-за ограниченного понимания и контроля среды. Статистика наших клиентов показывает, что до 40% ресурсов инженерии данных тратится на непродуктивный анализ воздействия, просто на оценку влияния новых требований к разработке. Это отвлекает разработчиков и замедляет выпуск новых функций почти на 100%.
- Снижение уровня доверия к отчетам, информационным панелям и аналитическим данным, поскольку мы не можем полностью объяснить, как были рассчитаны представляемые нами цифры, каково их происхождение и связанные с ними атрибуты качества или конфиденциальности данных. Это также приводит к разочарованию как со стороны бизнеса (в зависимости от данных, которым они не доверяют, долгое время ожидая ответов даже на основные вопросы), так и со стороны технологий (время, потраченное впустую на поиски одних и тех же ответов о происхождении данных снова и снова).
- Растущее количество инцидентов с данными из-за нашей ограниченной способности оценивать сквозное влияние изменений, которые должны быть реализованы. А с учетом нашей зависимости от данных один-единственный инцидент может нанести непоправимый ущерб бизнесу. У нас могут быть современные инструменты качества/наблюдаемости данных, но это по-прежнему очень реактивный подход. (Мы находим ошибки, а не предотвращаем их.) Согласно исследованиям, исправить ошибку в продакшеине в 20 раз дороже, чем исправить ту же ошибку в реализации, и в 100 раз дороже, чем исправить ее на этапе проектирования. (Ознакомьтесь с этой замечательной статьей IBM System Science Institute.) И это нечто!
- Острая нехватка специалистов по обработке данных, вызванная двумя основными факторами: (i) из-за растущей сложности стека данных инженеры по обработке данных стали более важными, чем любой другой специалист, поскольку они обеспечивают конвейеры данных и интегрированные структуры данных, и (ii) из-за разнообразия технологий и стратегий обработки данных роль инженера по обработке данных изменилась и теперь требует большего набора навыков, что затрудняет поиск хороших инженеров. Спрос на инженеров по обработке данных растет на 50% каждый год, а их зарплаты растут не менее стремительно. Тем не менее, мы тратим их драгоценное время на ручные рутинные задачи (такие как ручной анализ последствий или расследование инцидентов), увеличивая их разочарование и риск их увольнения.
- Возрастающий риск несоблюдения требований и нормативных санкций в связи с растущим числом нормативных актов, политик и общественных ожиданий, особенно в отношении этического использования данных и конфиденциальности данных (GDPR, CCPA/CPRA, HIPAA и т. д.) и качества данных (BCBS, SOX и др.). Было много случаев, когда один инцидент наносил ущерб компании на сотни миллионов (комиссионные, репутационный ущерб и т.д.).
Если нам удастся задействовать весь потенциал данных, возможности для бизнеса будут поистине безграничны. Для этого нам сначала нужно взять под контроль наши системы данных и найти способ оставаться эффективными, несмотря на стремительный рост сложности.
Не все метаданные одинаковы
Решения для управления метаданными уже довольно давно помогают нам управлять данными о данных. И хотя некоторые достаточно смелые, чтобы утверждать, что первыми решениями для управления метаданными были теги прокрутки в Великой Александрийской библиотеке, в наши дни как люди, так и компании имеют дело с гораздо большим хаосом данных, чем любой из тех древних библиотекарей в 280 г. до н.э.
Но у Великой Александрийской библиотеки было одно преимущество — им нужны были только очень статичные метаданные о книгах, которыми они и управляли. Но это совсем не так для соверменных систем данных. Они состоят из двух одинаково важных частей: самих данных и системного компонента, отвечающего за хранение, обработку, преобразование данных и т. д. Пока мы достаточно хорошо поработали с каталогизацией и профилированием данных, но никак не можем понять динамическую составляющую этого вопроса.
- Как элемент данных перемещается из одного места в другое?
- Как два (или более) элемента данных зависят друг от друга?
- Как изменяется профиль элемента данных в процессе его перемещения в среде?
Это лишь некоторые из вопросов, на которые мы должны искать ответы. И ответ — происхождение данных.
Активация метаданных — это ключ к успеху
Но независимо от того, насколько мощной является линия передачи данных (или линия передачи метаданных, или даже метаданные в целом), если она просто где-то находится, ни одна организация никогда не сможет максимально использовать свой потенциал. Это – одна из причин, почему исторически метаданные не были очень успешными. Мы потратили десятилетия, сосредоточившись на сборе метаданных, и забыли о важной части — сделать все это полезным и стоящим потраченных инвестиций. Теперь это меняется с акцентом на активные метаданные. Согласно Гартнеру:
- «В течение 2024 года активные возможности метаданных будут расширены и будут включать в себя мониторинг, оценку, рекомендации по изменениям дизайна и оркестровку процессов в сторонних решениях по управлению данными».
- «К 2024 году организации, применяющие агрессивный анализ метаданных в своей среде управления данными, сократят время доставки новых активов данных пользователям на целых 70%».
Чтобы лучше сформулировать эту мысль, вспомните о том, как вы сейчас водите автомобиль и сравните это с тем, как это было в прошлом. В настоящее время, благодаря развитию электроники в наших автомобилях, мы получаем предупреждение о том, когда следует долить жидкость для омывателя ветрового стекла или когда заменить масло и так далее. Тормоза даже сами срабатывают, если перед автомобилем возникает какой-то предмет! Все это возможно благодаря «процессору метаданных» в автомобиле. Он сканирует автомобиль, его детали, а затем окружающую среду и использует расширенный интеллект, чтобы помочь вам с различными рутинными, но важными задачами.
Звучит многообещающе, но что это значит в контексте управления данными? Вот несколько примеров, относящихся к происхождению данных.
- Непрерывное обнаружение «мертвых таблиц», в которых потенциально конфиденциальная информация хранится, но недоступна или не используется (например, когда мы создаем вспомогательную таблицу для обработки больших объемов данных и забываем ее удалить, или когда мы выводим из эксплуатации часть системы, фактически не зная каковы все его компоненты)
- Мгновенные оповещения, если в среде происходят какие-либо изменения, которые негативно влияют на тактические управленческие отчеты или ключевые функции данных, используемые группой специалистов по обработке и анализу данных (например, если вы меняете столбец пола в базе данных с «мужской/женский» на «мужской/женский/другой»), не понимая, что данные из этого столбца используются в качестве важного условия фильтрации в дальнейшем в алгоритме кредитного скоринга Python)
- Упреждающие уведомления для информирования пользователей о слишком сложных частях наших конвейеров данных, где рефакторинг или перепроектирование помогут снизить риск сбоя.
- Предупреждения, если мы проектируем конвейер данных, перемещающий данные между местоположениями, куда данные никогда не должны перемещаться (например, если мы случайно создадим поток данных между производственным и тестовым озерами данных или между двумя странами с несовместимыми политиками защиты данных).
Основная идея здесь состоит в том, чтобы объединить существующие метаданные с автоматизацией, интеллектом и вычислительной мощностью, которые могут предложить только компьютеры, переключиться с реактивного режима на проактивный и сделать все возможное, чтобы помочь людям лучше управлять данными и использовать их, даже в слишком сложных средах.
Бизнес преимущества происхождения данных
Существует несколько ключевых преимуществ наличия данных и связанных с ними шаблонов использования, которые помогают организациям достигать своих бизнес-целей.
НУЛЕВЫЕ ПРОИСШЕСТВИЯ С АНАЛИЗОМ ВОЗДЕЙСТВИЯ
Организации с лучшими стратегиями предотвращения инцидентов достигают более высокой производительности и значительного сокращения затрат. Одним из ключевых методов самых успешных компаний является широкое использование анализа последствий для всех запланированных изменений на ранней стадии процесса, на этапе проектирования. Наши клиенты сообщают о значительном снижении количества ошибочных релизов (менее 1%) и повышении производительности. (Восстановление после инцидента в производственной среде примерно в 100 раз дороже, чем его исправление на этапе проектирования.)
Есть и стратегический аспект. Правильно проведенный анализ воздействия позволяет компаниям заглянуть в будущее и определить, как изменения повлияют на организацию. Неправильные изменения могут привести к задержке и некачественной доставке, необходимости экстренных исправлений и другой дополнительной работе. Тем не менее, большинству организаций сложно проводить анализ воздействия, поскольку он требует значительных ресурсов, если выполняется вручную.
НАБЛЮДАЕМОСТЬ ПОТОКА ДАННЫХ И БЫСТРОЕ РАЗРЕШЕНИЕ ИНЦИДЕНТОВ
Происхождение данных расширяет рамки традиционного качества данных и наблюдаемости от только данных до инфраструктуры обработки данных (конвейеров данных). Большинство инцидентов с данными возникает не из-за исходных данных сомнительного качества (даже если это очень распространенная проблема), а из-за проблем с конвейером данных (например, вызовы API, не соответствующие типу столбца базы данных из-за недавних изменений в системе).
Благодаря передаче данных эти инциденты можно предотвратить на этапе проектирования (см. предыдущий раздел) или выявить на этапе внедрения и тестирования для повышения производительности и снижения затрат на обслуживание. (Устранение проблемы в производстве стоит примерно в 20 раз дороже и гораздо более трудоемко, чем ее устранение на этапе реализации, и в 100 раз дороже, чем на этапе проектирования.) Полное происхождение также позволяет организациям легко отслеживать любые проблемы, связанные с данными, вплоть до источника и на 90% быстрее по сравнению с традиционным ручным подходом, поэтому команды, ответственные за конкретные системы, могут решить любую проблему за считанные минуты.
НОРМАТИВНОЕ СООТВЕТСТВИЕ
Количество нормативных актов, требующих передачи данных, быстро увеличилось за последние несколько лет, и мы можем предположить, что в очереди их еще больше, включая BASEL, HIPAA, GDPR, CCPA/CPRA и CCAR, и это лишь некоторые из них. Всех объединяет одно — заинтересованные стороны компании (клиенты, аудиторы, сотрудники, контролирующие органы) требуют точного отслеживания данных, которые мы сообщаем.
- Откуда это взялось?
- Как оно туда попало?
- Можем ли мы доказать это современными доказательствами, если необходимо?
- Нужны ли нам недели или месяцы для завершения отчета, который в конечном счете даже не является полностью надежным?
БОЛЕЕ БЫСТРАЯ И ЭФФЕКТИВНАЯ (ОБЛАЧНАЯ) МИГРАЦИЯ
Новые облачные платформы данных (Snowflake, Amazon Redshift, Google Cloud, Microsoft Azure, IBM Cloud Paks и т. д.) стали факторами цифровой трансформации. Организации переносят свои операции в облако, чтобы повысить производительность и масштабируемость, а также сохранить конкурентоспособность. Однако любой, кто когда-либо видел процесс миграции системы данных, знает, насколько это сложно. Одной из ключевых проблем является определение масштаба проекта. Каждая система состоит из тысяч или миллионов взаимосвязанных частей, и ее невозможно перенести за один шаг.
Успешная стратегия состоит в том, чтобы разделить систему на более мелкие части объектов (отчеты, таблицы, рабочие процессы и т. д.), что создает другие проблемы — как перенести одну часть, не нарушая другую, и как мы вообще узнаем, какие части можно сгруппировать вместе. минимизировать количество внешних зависимостей? Проект миграции также предоставляет возможность консолидировать или полностью удалить компоненты, которые больше не используются, чтобы избежать переноса бесполезных данных. Но даже это сложно, так как перед миграцией требуется возможность просмотра всех зависимостей в среде. Успешные организации используют происхождение данных для выполнения своих проектов по миграции на 40 % быстрее, используя на 30 % меньше ресурсов.
РЕШЕНИЕ КРИЗИСА КАДРОВ В ИНЖЕНЕРИИ ДАННЫХ С ПОМОЩЬЮ САМООБСЛУЖИВАНИЯ
Нехватка специалистов по обработке данных была серьезной проблемой последние пару лет, превратившись из обычной проблемы в настоящий кризис, поскольку спрос на инженеров по обработке данных резко возрос из-за растущей сложности стека данных. Самое последнее, чего мы хотим, — это тратить время инженера по обработке данных стоимостью от 200 000 до 500 000 долларов в год на рутинные, ручные, разочаровывающие задачи, такие как отслеживание инцидентов с данными, оценка последствий запланированных изменений или терпеливые ответы на одни и те же вопросы о происхождение записей данных снова и снова. Точно так же мы сталкиваемся с нехваткой специалистов по данным.
Чтобы защитить эти ценные активы, успешные организации используют передачу данных для автоматизации рутинных задач и обеспечения самообслуживания везде, где это возможно. Вооружившись правильным решением, специалисты по данным и другие пользователи данных могут самостоятельно получать актуальную информацию обо всех деталях, связанных с происхождением данных, когда им это нужно. Подробная карта происхождения данных также обеспечивает более быструю адаптацию новых инженеров по обработке данных и позволяет организациям нанимать менее опытных людей на эту роль, не ставя под угрозу стабильность и надежность своей среды данных.
КОНСОЛИДАЦИЯ И ВИРТУАЛИЗАЦИЯ ДАННЫХ
Данные продолжают расти и усложняться. Многие компании консолидируют свои данные из нескольких источников в одном месте или изучают технологии виртуализации данных, которые создают видимость того, что данные находятся в одном месте. Называется ли оно озером данных, центральным репозиторием или другим термином, не так важно для этого обсуждения, чем возможность определить первоначальные источники данных и то, как они попали в свое текущее местоположение, или где они фактически находятся, если реализована виртуализация или репликация данных.
ДОВЕРИЕ К ДАННЫМ И ПОНИМАНИЕ ИХ
Если происхождение данных игнорируется или отображается неточно, ваши специалисты, принимающие решения, потеряют веру в свои отчеты и аналитические модели. Разработчики отчетов, специалисты по данным и «цифровые граждане», как их часто называют, заслуживают данных, которые вдохновляют на принятие точных, своевременных и уверенных решений. Только когда у вас есть полное представление о ваших данных, вы можете действительно положиться на них и извлечь из них максимальную пользу, повысив общую эффективность.
Давайте приступим к техническим вопросам: как создать происхождение данных и поддерживать его в актуальном состоянии
Теперь, когда мы знаем, что такое происхождение данных, ее важность для компании и ее преимущества, пришло время поговорить о том, как на самом деле можно реализовать происхождение данных.
Когда мы говорим о метаданных, мы очень часто думаем о простых вещах, таких как таблицы, столбцы и отчеты. Но метаданные происхождения больше связаны с логикой — инструкциями или кодом в любой форме. Это может быть сценарий SQL, хранимая процедура базы данных, задание в инструменте преобразования, вызов Java API или сложный макрос в электронной таблице Excel. Происхождение данных, в частности, может быть чем угодно, что перемещает ваши данные из одного места в другое, преобразовывает или модифицирует их. Итак, какие у вас есть варианты для описания, диаграммы и понимания этой логики? При ответе на эти вопросы следует учитывать два аспекта: из какого источника мы получаем информацию для построения карты происхождения данных и как мы ее строим.
Вопрос 1: Источник
Информацию о происхождении данных можно получить из трех основных источников: самих данных, журналов и кода.
ДАННЫЕ КАК ИСТОЧНИК
Этот метод расширяет существующие алгоритмы профилирования данных. Он считывает метаданные о таблицах и столбцах и использует информацию о профилях данных для создания ссылок, представляющих возможные потоки данных на основе общих шаблонов или сходств. Таблицы или столбцы с похожими именами и столбцы с очень похожими значениями данных – вот типичные примеры такого сходства. И если вы найдете их между двумя столбцами, вы свяжете их вместе на диаграмме происхождения данных.
У такого подхода есть одно большое преимущество — если вы смотрите только на данные, а не на алгоритмы, вам не нужно беспокоиться о технологиях, и это не имеет большого значения, если сайт использует Teradata, Oracle или MongoDB поверх Java. Но такой подход обычно не точен. Влияние на производительность может быть значительным (они работают с данными), а конфиденциальность данных находится под угрозой (они работают с данными). Также не хватает многих деталей, таких как:
- Так называемая «логика преобразования» — «как и где на самом деле данные преобразовываются и модифицируются?»
- Происхождение обычно ограничивается миром баз данных, игнорируя прикладную часть среды.
С другой стороны, в некоторых случаях этого подхода может быть достаточно, особенно когда невозможно прочитать логику, скрытую в вашем программном коде, потому что код недоступен или проприетарен и к нему нельзя получить доступ. Происхождение на основе шаблонов также является единственным подходом с малым шансом идентифицировать ручные потоки данных, происходящие вне какой-либо системы (например, копирование данных на флэш-накопитель, их изменение на другом компьютере и сохранение в другой части системы).
ЖУРНАЛЫ КАК ИСТОЧНИК
Этот метод основан на информации во время выполнения, извлеченной для среды данных. Это могут быть файлы журналов, рабочие процессы выполнения, экспортированные инструментами ETL/ELT, или любой другой источник с достаточной информацией о времени выполнения. Некоторые механизмы обработки данных используют специальный трюк, называемый тегированием данных, когда каждый фрагмент данных, который перемещается или преобразуется, помечается/маркируется механизмом преобразования, который затем отслеживает эту метку на всем пути от начала до конца. В отличие от происхождения на основе шаблонов, происхождение во время выполнения должно учитывать различные технологии в стеке данных, поскольку формат и структура информации журнала значительно различаются. Регулярные выражения, правила или AI/ML можно развернуть для идентификации соответствующих частей файлов журналов и получения информации о потоках данных.
Оперативный характер происхождения во время выполнения также ценен для разрешения инцидентов, поскольку он дает нам очень точную информацию о потоке определенного элемента данных, который был идентифицирован как ошибочный. Но эта сила также представляет собой его самую большую слабость. Происхождение во время выполнения собирает информацию только о недавно выполненных потоках данных. Представьте себе алгоритм ценообразования продукта — обычно это очень сложный расчет со множеством переменных и десятками или даже сотнями различных сценариев. Каждый сценарий представляет один возможный поток данных. Но эти сценарии не выполняются одинаково, так как у нас есть более и менее частые входные условия. Кто-то может возразить, что если мы будем ждать достаточно долго, сработают даже менее частые сценарии, но только в том случае, если система никогда не менялась. В традиционной среде от 20% до 40% изменений происходит всего за год. Это приводит к непоследовательному и неточному происхождению данных, поскольку некоторые части либо отсутствуют, либо более недействительны, поскольку основная логика изменена, даже если сценарий еще не был выполнен и, следовательно, его происхождение еще не зафиксировано.
Еще одним ограничением происхождения во время выполнения является отсутствие деталей о процессе преобразования. Не все документируют или могут документировать, особенно в случае более сложных алгоритмов и расчетов. То же самое относится и к обработке, выполняемой вне мира базы данных/ETL/ELT (например, в Java, Python и т. д.). В результате происхождение часто может захватывать только очень высокоуровневые и общие сопоставления таблиц с таблицами или даже меньше того.
Слепое использование таких метаданных представляет большой риск для организации.
- Если оно используется инженером по обработке данных для проведения анализа воздействия, это приводит к высокой вероятности инцидентов при разработке и реализации изменений в системе и новых требований.
- Точно так же, если оно используется аналитиком рисков для подготовки нормативного отчета, это приводит к неточностям в отчете и повышенному риску (публичных) инцидентов и штрафов.
- Если оно используется специалистом по данным для анализа и подготовки данных для обучения новой модели, это приводит к неотъемлемому неравенству, закодированному в разработанном алгоритме AI/ML.
КОД КАК ИСТОЧНИК, ОН ЖЕ - КАРКАС ПРОИСХОЖДЕНИЯ
Вместо того, чтобы использовать файлы журналов для идентификации потоков данных, мы можем взглянуть непосредственно на код, который обрабатывает и преобразует записи данных. Слово «код» здесь понимается в самом широком смысле. Код может быть сценарием SQL, процедурой PL/SQL, рабочим процессом ETL/ELT, закодированным в проприетарном формате XML, макросом в электронной таблице Excel, сопоставлением между полем в отчете и столбцом или таблицей базы данных, Java API, определением потока Kafka, преобразованием XSLT или алгоритмом Python в блокноте Jupyter. Это разнообразие представляет собой серьезную проблему, поскольку синтаксический анализ и обратное проектирование кода намного сложнее, чем синтаксический анализ файлов журналов, и для этого требуются специализированные сканеры для всех поддерживаемых технологий.
Тем не менее, этот подход предлагает несколько важных преимуществ, поэтому он является основной стратегией, используемой наиболее успешными поставщиками и организациями.
- Это очень точный подход без ложных срабатываний или с небольшим количеством ложных срабатываний (если происхождение данных неправильно определено между двумя столбцами), что имеет решающее значение для управления инцидентами, поскольку сужает область расследования и делает управление изменениями и анализ последствий более эффективным.
- Это единственный подход, который может надежно обнаруживать косвенные потоки данных, в которых один элемент данных влияет на другой, даже без прямой связи с линией передачи данных (например, столбец базы данных, используемый в качестве условия фильтрации для данных, представленных в отчете). Это необходимо для управления изменениями, анализа последствий, управления инцидентами, проектов миграции и нормативной отчетности.
- Крайне низкая, близкая к нулю, вероятность пропуска каких-либо, даже редко используемых (или вообще неиспользуемых) потоков данных. Это критически важно для процессов управления изменениями и анализа последствий, а также для проектов миграции, программ конфиденциальности и нормативной отчетности.
- Это единственный подход, при котором записываются сведения о преобразованиях и вычислениях, используемых для обработки данных, что особенно важно для соблюдения нормативных требований и отчетности. Это также позволяет поставщикам, использующим этот подход, выводить семантику анализируемых преобразований.
Вопрос 2: Процесс
Сегодня мы видим три основных подхода на рынке.
РУЧНОЙ АНАЛИЗ ПРОИСХОЖДЕНИЯ ДАННЫХ
Ручное определение происхождения обычно начинается с картографирования и документирования знаний в головах людей. Интервью с владельцами приложений, распорядителями данных и специалистами по интеграции данных дадут вам достаточный объем информации о перемещении данных в вашей организации. Из них можно определить происхождение, обычно в электронных таблицах или других простых механизмах отображения, чтобы отразить предмет, описанный экспертами.
Конечно, одним из недостатков этого подхода является то, что информация может (и, вероятно, будет) противоречивой, или если вы пропустите разговор с кем-то, о ком вы просто не знаете, часть потока может быть упущена! Это часто приводит к опасной ситуации, когда у вас есть данные о происхождении, но вы не можете использовать ее в реальных сценариях. Полученной информации о происхожднеии нельзя доверять.
Ручной анализ происхождения данных по своей сути выполняется с использованием кода в качестве источника (см. «Код как источник» выше), когда код анализируется его авторами или внешними ресурсами. Независимо от того, как это делается, вручную проверять код, сравнивать имена столбцов и просматривать таблицы и извлечения файлов вручную — утомительно! Возможно, даже не стоит пытаться, если у вас нет членов команды с необходимыми навыками и опытом работы с программами и модулями, которые вам нужно изучить. Из-за объемов кода, сложности и скорости изменений этот метод быстро становится неприемлемым. Рано или поздно такое управляемое вручную происхождение перестанет синхронизироваться с фактической передачей данных в среде, и снова у вас будет происхождение, которому вы не можете на самом деле доверять.
Несмотря на эти опасения, данный подход нельзя полностью исключить, так как именно с него нам всем нужно начать, чтобы получить представление о том, что на самом деле происходит во всей нашей среде. Иногда вообще нет никакого кода или каких-либо разрешений для прямого доступа и профилирования данных (особенно в устаревших системах), и эксперты в предметной области – это ваш единственный источник информации о происхождении данных.
АВТОНОМНЫЙ АНАЛИЗ ПРОИСХОЖДЕНИЯ ДАННЫХ
Этот подход, очень популярен среди поставщиков ETL/ELT, он полностью автоматизирован и его основная концепция заключается в том, что он полностью контролирует каждое перемещение данных, каждое изменение данных и весь рабочий процесс обработки данных, дает полное представление о нем (неограниченный доступ к внутренним журналам, сведениям о выполняемых рабочих процессах и инструкциях по обработке и т. д.). Поставщики и инструменты, применяющие этот подход к анализу происхождения данных, обычно используют журналы в качестве источника (см. раздел «Журналы как источник» выше) со всеми его преимуществами и недостатками.
Основным недостатком автономного анализа является тот факт, что передача данных ограничена управляющей платформой (обычно это инструмент ETL/ELT). Все, что происходит за пределами контролируемой среды, невидимо, как будто его не существует. Иногда даже более сложные компоненты платформы представляют собой проблему, например, компонент с пользовательским сопоставлением Python/Java/SQL. Организации, пытающиеся использовать этот подход, иногда навязывают единую платформу обработки данных или запрещают использование более сложных компонентов просто для того, чтобы быстро выяснить, насколько она ограничивает подавляющее большинство задач инженерии данных и насколько она замедляет новую разработку (даже с учетом разочарования инженеров по обработке данных).
ВНЕШНИЙ АВТОМАТИЗИРОВАННЫЙ АНАЛИЗ ПРОИСХОЖДЕНИЯ ДАННЫХ
Как следует из названия, этот подход тоже предлагает полностью автоматизированный анализ происхождения данных. В отличие от предыдущего варианта, внешний анализ по своей сути предназначен для работы с неоднородностью стека данных и не требует, чтобы вся обработка данных происходила в одном инструменте или на одной платформе. Вот почему это лучший вариант среди всех, предлагающих возможности передачи данных выше среднего.
Большинство поставщиков, использующих внешний анализ, используют либо журналы (см. «Журналы как источник» выше), либо код (см. «Код как источник» выше) в качестве источника для обнаружения происхождения данных. Но некоторые поставщики в основном используют данные (см. «Данные как источник» выше) или пытаются комбинировать несколько подходов.
Инструменты и решения по происхождению данных на рынке
По историческим причинам передача данных является частью очень широкого рынка управления метаданными. И это очень популярное место. Почему? Просто потому, что существует слишком много типов метаданных, слишком много способов их использования и слишком много разных персон/ролей в организации. (Мы рекомендуем прочитать короткую и забавную книгу Время убивать метаданные.)
Традиционным типом являются статичные метаданные — информация о таблицах, полях, столбцах, бизнес-терминах и их типах данных, расположении, атрибутах качества, тегах, которые они имеют, и т. д. Этот тип метаданных очень полезен для задач поиска и обнаружения данных. Типичными их возможностями являются поиск данных, обнаружение, профилирование, классификация, тегирование и маркировка. Статичные метаданные помогают специалистам по данным находить и лучше понимать характер данных, с которыми они работают.
Статичные метаданные — это основной домен менеджеров метаданных (старое название) и каталогов данных (современный ребрендинг). Существует много «местных» каталогов данных, но мы также видим, что поставщики данных, безопасности данных, ETL/ELT, подготовки данных, обработки данных и виртуализации данных также выходят на рынок каталогизации данных.
Другой тип метаданных, на который многие годы не обращали внимания из-за его сложности, — это динамичные метаданные — информация о путешествии данных от источника к цели, включая все изменения, преобразования и вычисления. Динамичные метаданные очень полезны для управления поведением данных и, для лучшего понимания и управления разнородными и сложными конвейерами данных в современных компаниях. Есть несколько «местных» игроков в области происхождения данных, но мы также видим, что и другие поставщики каталогов, подготовки, виртуализации данных и ETL/ELT тоже выходят на рынок.
Некоторые традиционные поставщики предлагают решения в области происхождения данных уже более десяти лет. Но на данный момент ни одному из них не удалось в полной мере использовать истинный потенциал задействования происхождения данных, чтобы избавиться от ручных процессов, повысить производительность организации и позволить нам восстановить доверие к данным, отчетам и идеям, которые мы будем использовать. Для достижения этой цели должны присутствовать следующие ключевые компоненты происхождения данных, описанные в последующих разделах: (1) точные и подробные метаданные; (2) семантика и ИИ; и (3) активация интеграции.
Точные и подробные метаданные
Успешные компании понимают, какая ценность скрыта в их данных, и неудивительно, что их основное внимание уделяется именно пониманию данных. Это приводит к сбору структурных метаданных и фиксации того, как данные организованы и отсортированы. Поступая таким образом, организации упускают из виду динамические аспекты данных и их зависимости, которые лучше всего представлены происхождением данных. Как сказано ранее, без понимания и контроля происхождения данных - управление данными все еще остается в индустриальной эпохе.
Но зависимости есть везде и обычно они хорошо спрятаны. Каждое отдельное преобразование, простое вычисление и перемещение данных представляет собой тип зависимости. Есть даже косвенные зависимости вроде условий фильтрации. Автоматическое обнаружение абсолютно необходимо. Еще одна проблема заключается в том, что зависимости должны отражаться очень точно и подробно; в противном случае результирующая карта будет содержать слишком много ложных срабатываний и/или пропустит несколько важных взаимосвязей между данными. Без детализации и точности любая попытка контролировать зависимости обречена на провал.
Семантика и ИИ
Очень распространенная проблема при автоматизации задач, выполняемых вручную, заключается в том, как научить компьютер реагировать на различные, иногда неожиданные сценарии. Традиционный подход, который использовался на протяжении десятилетий, называемый императивным программированием, представляет собой набор правил, которым может следовать компьютер. «Если происходит А, делай Б; в противном случае делай C”. Из-за сложности систем данных и большого объема (скрытых) зависимостей этот подход имеет свои ограничения на пути к автоматизации. С расширением и более широким внедрением ИИ расцветает другой подход, называемый декларативным программированием. Не углубляясь в подтипы парадигм программирования и различия между императивным и декларативным, мы сосредоточимся на том, что необходимо для полного развертывания ИИ и других передовых методов для лучшей поддержки автоматизации в контексте управления данными — семантике.
Просто отображать зависимости недостаточно. Основная информация о потоке данных и пути данных должна быть обогащена своим «значением». Что на самом деле происходит с данными или что означает конкретное преобразование и как оно влияет на данные? Возможность отвечать на такие вопросы дает нам больше возможностей и контроля над зависимостями и позволяет использовать более продвинутые методы автоматизации. Этот уровень проявляется через различные возможности — способность различать различные типы зависимостей (прямые, косвенные), способность понимать эволюцию происхождения данных в течение определенного периода времени (квантование времени, ревизии) или способность переводить фактический код обработки данных в более высокоуровневые, удобные для пользователя выражения.
Активация интеграций
Хотя исторически каталоги метаданных сосредоточены на пассивном хранении метаданных, на самом деле ключевая задача заключается в том, как интегрировать их во все процессы управления данными и как активно использовать этот дополнительный уровень знаний, чтобы ускорить все и сократить объем ручного труда.
Стратегии активации метаданных происхождения данных различаются в зависимости от домена, в который мы их интегрируем. Для каждого домена мы задаем один и тот же набор вопросов.
- Какие процессы и инструменты используются в настоящее время?
- Что еще делается вручную? А почему до сих пор не автоматизировали?
- Как точные, подробные и семантически богатые метаданные могут помочь в автоматизации?
- Есть ли что-то, что могло бы оказать серьезное влияние, чего мы не делаем сегодня, но могли бы сделать, если бы это было автоматизировано?
- Есть ли способ использовать автоматизацию для перепроектирования и улучшения существующего процесса?
Происхождение данных имеет огромный потенциал. Его можно активировать и использовать для предоставления прямых преимуществ специалистам по данным в любой организации (см. примеры, относящиеся к происхождению данных, в разделе «Активация метаданных — ключ к успеху»). Происхождение данных также позволяет активировать другие формы метаданных. Другими словами, если, например, каталог данных, средство обеспечения конфиденциальности данных или инструмент ETL/ELT имеют доступ к подробному, точному, семантически богатому происхождению данных, это открывает новые возможности в отношении того, что можно активировать, когда и как. Вот почему успешные организации развертывают общекорпоративные платформы передачи данных и интегрируют их с другими частями своей инфраструктуры данных.