На самом элементарном уровне вы можете вести список таблиц.имя полей, извлеченных из исходной системы. Если вы извлекаете из файлов или других источников, не относящихся к базе данных, то вы можете или не сможете перечислить зависимости столь же детально, как и уровень поля. Такие метаданные скажут вам только, что If (поле источника / fileFormat / таблица изменяется), то (некоторое изменение может потребоваться в процессе ETL). Я говорю, что может , потому что некоторые изменения могут быть достаточно незначительными, чтобы процесс ETL не нарушался, но все же следует выполнить тестирование и профилирование данных, чтобы убедиться, что оно не лишает законной силы любые предположения, которые были на месте во время первоначального проектирования. процесса ETL.
Хотя разработчик ETL может быть близко знаком с исходной системой и процессом ETL, для больших проектов ETL, вероятно, было бы целесообразно связывать каждую зависимость в исходной системе с конкретными процессами / компонентами системы ETL. Например, если ваш процесс ETL состоит из множества хранимых процедур, то вы бы хотели, чтобы метаданные связывали каждое поле исходной системы / fileFormat / table / etc. к каждой хранимой процедуре. Это будет отношение «многие ко многим», поскольку многие хранимые процедуры могут зависеть от конкретного поля, а одна хранимая процедура может зависеть от многих исходных полей. Это было бы что-то, что вручную обновлялось разработчиками ETL, поскольку они создавали или обновляли систему ETL, они должны были бы распознать, какие поля они загружают / очищают / согласовывают, и впоследствии вводить эту информацию в метаданные, которые отслеживают эти зависимости.
Если ваша система ETL работает на чем-то, кроме хранимых процедур или какой-то их комбинации, то вам нужно будет придумать какую-то схему именования для ссылки на эти компоненты. Но концепция та же самая, вы связываете исходные поля / форматы файлов / и т.д. к компонентам системы ETL.
Это даст вам достаточно информации, чтобы сказать, что если «Person.FirstName» каким-либо образом изменяется в исходной системе, то вы можете скомпилировать отчет, который показывает все хранимые процедуры, которые необходимо проверить, потенциально обновить и проверено, чтобы справиться с изменением в исходной системе.
Этот тип подразумевает, что знание того, что Person.FirstName каким-либо образом изменилось, либо размер, тип данных и / или полностью удален, требует ручного шага уведомления об изменении через какого-либо дизайнера базы данных и принятия действий в ответ. Если вам нужна действительно сложная система, вам потребуется триггер / аудит DDL, который изменяет исходную систему, чтобы вы могли автоматически регистрировать и уведомлять своих ETL-архитекторов об изменениях.
В случае такого изменения вы бы знали, что хранимые процедуры sp_Person_Load, sp_Person_Clean, sp_Person_Transform имеют отношение к полю Person.FirstName, поскольку автор этих хранимых процедур отметил, что в метаданных документируются зависимости.
Вы могли бы сделать это более сложным, когда sp_Person_Clean не зависит от Person.Firstname, но фактически зависит от sp_Person_Load. Такой, что вы строите цепочку зависимостей. Это усложнит отчетность об изменениях, потому что вам придется объединять зависимости, чтобы определить влияние изменений в исходной системе. Кроме того, вы создаете сложную цепочку зависимостей и потенциальных циклических ссылок, которые могут затруднить ведение метаданных так же, как и сам процесс ETL. Если система ETL достаточно проста, чтобы архитектор ETL мог определять зависимости в терминах полей / файлов / таблиц из исходной системы, тогда сделайте это для простоты.
В зависимости от того, кто имеет полномочия над вашим хранилищем данных, системой назначения, вам может потребоваться отслеживать эти зависимости. Часто разработчик ETL является также разработчиком хранилища данных. Однако, если кто-то еще является разработчиком хранилища данных и имеет полномочия вносить изменения в хранилище данных, разработчикам ETL потребуется аналогичная система, будь то автоматизированная или ручная, для отслеживания и уведомления об изменениях. и влияние, которое они будут иметь на процесс ETL.
Действительно, когда я думаю о том, как следует отслеживать изменения, я думаю о границах власти. Если разработчик ETL изменяет свою процедуру sp_Person_Clean, ему не нужны emtadata, чтобы сообщить ему, что sp_Person_Transform необходимо будет обновить / протестировать. Он уже знает это очень интуитивно. С другой стороны, если система стороннего поставщика / поставщика изменяется или бизнес-отдел в той же организации меняет электронную таблицу или формат файла, то это вещи, не принятые разработчиком ETL. У него не будет такого же уровня близости с исходными системами, как у его собственной системы ETL и хранилища данных. Таким образом, он получит наибольшую пользу от метаданных, которые показывают, как компоненты исходной системы связаны с компонентами системы ETL.
Решение о том, насколько детализированным вы хотите определить «компоненты», будет зависеть от того, как спроектированы системы и сколько метаданных вы хотите, чтобы разработчик задокументировал. Слишком гранулированный, и вы утонете в метаданных. Слишком конечно, и это все равно, что сказать «Мой дом во Флориде», что не очень помогает разработчику ETL в его работе. Если весь процесс ETL закодирован в одном сценарии SQL, то у вас есть только один компонент. Поэтому система должна быть спроектирована заранее, зная, что вы должны иметь возможность ссылаться на конкретные компоненты и / или этапы процесса ETL.
Метаданные будут полезны только в том случае, если разработчик будет старательно обновлять их. Существуют системы / наборы инструментов, которые могут автоматически обновлять метаданные такого типа, но они должны будут поместить вас в свой набор инструментов, чтобы инструмент мог анализировать зависимости. У меня мало уверенности в том, что эти системы очень надежны. Временами вам приходится совершать по-настоящему хакерские вещи, чтобы получить данные из исходной системы в место назначения в нужном формате, и я могу себе представить, что анализатор зависимостей не может понять зависимости. Например, если вы использовали динамический SQL, сформированный из строк, то инструментарий не может понять, каковы зависимости.
Однако я скажу, что я никогда не углублялся в инструменты, чтобы действительно знать, насколько они хороши. Я всегда дошел до того, что находил вещи, которые обычно бывают простыми в SQL, очень трудоемкими в инструменте, и решил, что это было больше проблем, чем оно того стоило. Я продолжаю говорить себе, что я найду что-то вроде Talend и действительно стану экспертом в этом, прежде чем принять окончательное решение, но всегда есть другие приоритеты, которые тянут меня в других направлениях.