yuryemeliyanov Nov 10 2015 at 13:15

Impact анализ на примере инфраструктуры корпоративного хранилища данных

8 min

14K

TINKOFF corporate blogSystem Analysis and Design*SQL*Data visualization*

+12

Comments 16

Wadime Nov 10 2015 at 17:08

Это крайне интересный инструмент!
Рассматривались какие-либо аналоги? Что можете сказать про политику лицензирования?

Wadime Nov 10 2015 at 18:17

Вдогонку вопрос от коллег — сколько времени заняло построение полной модели? Сколько человек этим занималось?

yuryemeliyanov Nov 10 2015 at 19:29

Полной модели чего? У нас сейчас построено четыре модели и они связаны между собой. Больше всего времени было потрачено на разработку модели SAS, т.к. сложная система метаданных. А так в среднем на одну модель уходит 2-3 недели. Это разобраться в метаданных истоника, спроектировать модель, ещё раз разобраться в метаданных источника, запрограммировать обновление метаданных, поставить на регламент. Ну или купить metadata exchange настроить регламент, связку с другими моделями. Одномоментно у нас Metadata Mamager занимался один человек. До текущего состояния внедрения мы дошли где то за 2,5-3 месяца.

yuryemeliyanov Nov 10 2015 at 19:22

Спасибо за комментарий. Аналоги если честно толком не трогали и не тестировали, толки читали. Есть аналоги у IBM и Oracle. По нашему мнению у Oracle ещё сыроватый продукт, а IBM не рассматривали т.к. у нас примерно год назад была закупка Informatica и Informatica Metadata Manager входит в Advanced Edition. Плюс дополнительно можно докупать metadata exchange к различным системам.

yusman Nov 10 2015 at 20:42

Очень интересный продукт, спасибо за статью.

yuryemeliyanov Nov 10 2015 at 21:53

Спасибо. Если будут вопросы по теме, обращайтесь.

Stas911 Nov 10 2015 at 23:14

Интересно, спасибо! А кроме lineage он что еще умеет?
Еще вопрос — а reverse engineering оно умеет или все надо ручками?

yuryemeliyanov Nov 11 2015 at 12:36

Спасибо. lineage это пожалуй основная его фишка. А что вы в контексте этого инструмента подразумеваете под reverse engineering?

Stas911 Nov 12 2015 at 21:38

Я имел ввиду, что если есть работающая система с тьмой таблиц, вьюшех, SP и т.д. — этот прибор может построить lineage сам в каком-то виде или все строго ручками?

yuryemeliyanov Nov 12 2015 at 22:45

Ну смотрите. Например у вас система построена на Oracle. У вас куча таблиц, представлений и хранимой логики. У вас стоит Informatica Metadata Manager и в нем есть metadata exchange for Oracle. То, для того что-бы настроить процесс выгрузки/загрузки метаданных у вас займет 15-20 минут и linage этот прибор сможет построить сам. А вот если у вас более сложная инфраструктура, то тут ручками надо будет поработать. Но поработать рачками здесь не заключается в том, что бы прописывать все зависимости метаданных между собой, а в том что бы описать модель метаданных и написать некий код наполнения этой модели метаданными.

Stas911 Nov 13 2015 at 00:32

То есть достаточно, грубо говоря, сказать ему где что искать, а остальное он сам подтянет

yuryemeliyanov Nov 13 2015 at 08:13

Ну в целом да, идея такая, как вы описали :)

aml Nov 11 2015 at 11:37

Статья могла бы быть лучше, если была бы дополнена глоссарием — что такое DWH, EBL, BI, SAS и т.д. Гугление даёт слишком много неоднозначных вариантов. В результате, мне например вообще не понятно, какие задачи решаются. Хотя, возможно, статья и рассчитана только на тех, кто знает, что это.

yuryemeliyanov Nov 11 2015 at 12:43

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

DWH — Data Warehouse
EBTL — Extract, Transform, Load
BI — Business intelligence
SAS — SAS

:)

jvs Nov 17 2015 at 13:39

Мы написали подобный продукт, который пытается ответить на те же вопросы, которые подняты в статье.
Добавьте к Информатике необходимость искать зависимости в коде PL/SQL в базе Оракл и аппликациях на Оракл формах, файлах Word. Кроме того, ведь важно как используется таблица, ведь для этого Вы выполняете поиск.
Может, я хочу знать где делается Update или селект поля.
В случае Информатики, Вы не хотите знать где и как используется поле: lookup/source/target/, может Pre/Post SQL?
Я не очень понял, какой загрузчик вытаскивает данные из репозитория Информатики?
Мы написали селекты из таблиц репозитория.
Построили иерархию
Workflow
Session
Mapplet
Mapping
Lookup
Source
Target
Expression
Мы также извлекаем данные из словаря Oracle, при помощи JDAPI получаем в том же формате данные из Оракл форм и отчетов и все это грузится в наш репозиторий и тогда можно получить один ответ где и как используется таблица в Информатике/PL/SQL пакете/форме.
Очень важно удобно показать зависимость. К сожалению, я не очень увидел как и что вы показываете, могу ли я на любом отрезке связи увидеть, какого рода эта связь.
Извините, за такой длинный комментарий, но мы пытались дать архитектору системы наиболее полный ответ. Поймите, здесь очень много дальнейших шагов, на мой взгляд, Вы прошли первые несколько на этом пути.
Успехов Вам.
Наш продукт можно посмотреть здесь(ODA Oracle Dependencies Analyzer)
Я не пиарюсь, не дай бог, просто посмотрите на наш опыт.

yuryemeliyanov Nov 21 2015 at 15:51

Спасибо за столь расширенный комментарий :)

Обсудил с вендером и вот что получилось:
1. Informatica MM позволяет обрабатывать простые PL/SQL код, указывая список используемых таблиц. Для сложных обработок всегда можно расширить функционал написав XConnect и свой парсер или использовав сторонние продукты, позволяющие распарсить код, например MANTA CHECKER, ну в том числе и ODA Oracle Dependencies Analyzer.

2. Lineage показывает зависимость полей и алгоритмы используемые при расчете значений. Этого вполне достаточно, чтобы понять является ли это поле входным Source, выходным Source или используется в Lookup. В любом случае, если есть необходимость сформировать отчет по метаданным, то для этого есть Reporting Service, входящий в поставку MM, который читает данные из репозитория. В рамках текущей задачи важно было получить информацию в графическом виде.

3. ODA Oracle Dependencies Analyzer не плохое решение, но не покрывает большинство систем, которые были интересны в текущем кейсе — Hadoop, Cloudera, Informatica 9.6 BDE. Суть в том, чтобы с одной стороны использовать решение поддерживаемое вендором и по части систем использовать уже готовые модели, настройка которых занимает 15 минут и с другой стороны иметь возможность адаптировать решение под свои нужды, опять таки без особых ресурсных затрат.