Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / OLAP и DWH Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 [2] 3   вперед  Ctrl      все
 Re: Изучаю Informatica - вопросы для понимания  [new]
Бумбараш
Member

Откуда: никем не победимая, самая любимая
Сообщений: 2748
psamv

1) Возвращаясь к лукапам. Пока не очень понятно чем они хороши и почему сделаны отдельным инструментом. Кажется, что их почти всегда можно заменить SQL-транс-ями и это будет выгодней.
Исключение может - совсем простенькие лукапы, без Override.

они нужны, чтобы их продавать

за 10 лет работы с инфой, основной её lifecycle: пользователь всё больше начинают использовать SQL, переходя на полный ELT, а потом выкидывают инфу. Потому что уже непонятно, зачем она нужна.
9 сен 20, 12:27    [22194113]     Ответить | Цитировать Сообщить модератору
 Re: Изучаю Informatica - вопросы для понимания  [new]
alexdr
Member

Откуда:
Сообщений: 249
Бумбараш
за 10 лет работы с инфой, основной её lifecycle: пользователь всё больше начинают использовать SQL, переходя на полный ELT, а потом выкидывают инфу.

Хм... Всё страньше и страньше! Всё чудесатее и чудесатее!(с)перто.
9 сен 20, 12:59    [22194153]     Ответить | Цитировать Сообщить модератору
 Re: Изучаю Informatica - вопросы для понимания  [new]
.Евгений
Member

Откуда:
Сообщений: 574
alexdr
Бумбараш
за 10 лет работы с инфой, основной её lifecycle: пользователь всё больше начинают использовать SQL, переходя на полный ELT, а потом выкидывают инфу.

Хм... Всё страньше и страньше! Всё чудесатее и чудесатее!(с)перто.
Я не исключаю, что так оно во многом и есть. Во-первых, потому что большинство программистов ETL рекрутируются из базистов, которым SQL наиболее привычен и понятен, и так оно для них и остается. Во-вторых, из-за отсутствия тщательно подготовленных кейсов сравнения с детальным разбором производительности и узких мест.
9 сен 20, 13:17    [22194169]     Ответить | Цитировать Сообщить модератору
 Re: Изучаю Informatica - вопросы для понимания  [new]
psamv
Member

Откуда:
Сообщений: 26
.Евгений
Я не исключаю, что так оно во многом и есть. Во-первых, потому что большинство программистов ETL рекрутируются из базистов, которым SQL наиболее привычен и понятен, и так оно для них и остается. Во-вторых, из-за отсутствия тщательно подготовленных кейсов сравнения с детальным разбором производительности и узких мест.
Т.е. в целом - Informatica - хороший инструмент, если уметь его правильно и гибко использовать. Тогда проявляются её преимущества.

Мне не очень по душе негативный взгляд (разочаровывает). Думаю - кто бы стал делать крупномасштабную ерунду - на этом далеко не уедешь.

Мне кажется и лукапы - скрывают в себе много полезного, если знать, как их правильно использовать (только кажется, что они - фигня). Хотелось бы понимать как они правильно применяются.

Вы писали:
Евгений:
Соединение двух потоков данных требует их обоюдной сортировки. Лукап - нет (хотя кешированный неявно сортирует себя). В результате денормализация звезды или снежинки в одну "простыню" через соединения фактически невозможна.
Для меня немного высокий уровень понимания.

1) Да, разные потоки нужно сортировать, чтобы объединить, причём один должен полностью включать в себя другой иначе Full Join-ом красиво не получится.

2) Лукап довыбирает данные из подключенных таблиц. Его узкое место - добавляет условие связи потом, а не сразу при выборе (или оно видится таковым).

3) Но через Joiner-ы можно соединить любую снежинку, главное, чтобы у всех этих потоков был общий ID и один (основной) поток содержал все ID остальных. Тогда можно последовательно их Jioner-ами все объединить. (Если правильно Вас понял).

C SQL-трансформацией так и не смог пока разобраться. Выбирает пустоту, хоть вроде всё везде настроил. Интересно - в Query Mode, статический запрос, пассивная. Получается ли у вас её использовать?
10 сен 20, 10:50    [22194620]     Ответить | Цитировать Сообщить модератору
 Re: Изучаю Informatica - вопросы для понимания  [new]
.Евгений
Member

Откуда:
Сообщений: 574
psamv
3) Но через Joiner-ы можно соединить любую снежинку, главное, чтобы у всех этих потоков был общий ID и один (основной) поток содержал все ID остальных. Тогда можно последовательно их Jioner-ами все объединить. (Если правильно Вас понял).

Нет, не совсем правильно. Например, есть десять измерений (справочников клиентов, счетов и т.д.) и большая таблица фактов с десятью идентификаторами (ссылками на каждый справочник: сделка с таким-то клиентом по такому-то счету и т.д.). Для реализации соединений вы будете вынуждены сортировать факты десять раз по каждому идентификатору, тогда как для лукапов этого делать не требуется.
10 сен 20, 11:36    [22194663]     Ответить | Цитировать Сообщить модератору
 Re: Изучаю Informatica - вопросы для понимания  [new]
psamv
Member

Откуда:
Сообщений: 26
.Евгений
psamv
3) Но через Joiner-ы можно соединить любую снежинку, главное, чтобы у всех этих потоков был общий ID и один (основной) поток содержал все ID остальных. Тогда можно последовательно их Jioner-ами все объединить. (Если правильно Вас понял).

Нет, не совсем правильно. Например, есть десять измерений (справочников клиентов, счетов и т.д.) и большая таблица фактов с десятью идентификаторами (ссылками на каждый справочник: сделка с таким-то клиентом по такому-то счету и т.д.). Для реализации соединений вы будете вынуждены сортировать факты десять раз по каждому идентификатору, тогда как для лукапов этого делать не требуется.
Вы имеете в виду, что если выбирать каждую табличку снежинки через SQ, потом Joiner-ить с фактами, то каждый раз проигрываешь на сортировке. А если сразу лукапами цеплять к одной выбранной таблице фактов, то такого не будет.

Единственное, лукапы каждый раз берут всю свою выборку (которая у них в Override или просто одну таблицу), а условие связи с таблицей фактов они применяют потом.

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

Т.е. их надо применять, не когда нужно отфильтровать выборку в лукапе, а когда лукапом основную? Но вроде он так не умеет, основную же берёт целиком.

Что-то я с лукапами совсем запутался )
Но чувствую, хожу вокруг да около и где-то рядом с пониманием (чего-то просто не хватает)

Сообщение было отредактировано: 10 сен 20, 13:30
10 сен 20, 13:32    [22194752]     Ответить | Цитировать Сообщить модератору
 Re: Изучаю Informatica - вопросы для понимания  [new]
psamv
Member

Откуда:
Сообщений: 26
автор
Т.е. их надо применять, не когда нужно отфильтровать выборку в лукапе, а когда лукапом основную? Но вроде он так не умеет, основную же берёт целиком.
Что-то здесь у меня какой-то бред по-моему.
Лукап довыбирает поля из своей выборки, основную он никогда не фильтрует. Наоборот - она его.
Значит он всегда избыточный?
Но в случае со снежинкой мне сложно судить. Я только примерно представляю себе эту архитектуру.
10 сен 20, 14:08    [22194786]     Ответить | Цитировать Сообщить модератору
 Re: Изучаю Informatica - вопросы для понимания  [new]
.Евгений
Member

Откуда:
Сообщений: 574
psamv
Вы имеете в виду, что если выбирать каждую табличку снежинки через SQ, потом Joiner-ить с фактами, то каждый раз проигрываешь на сортировке. А если сразу лукапами цеплять к одной выбранной таблице фактов, то такого не будет.
Да.
psamv
Единственное, лукапы каждый раз берут всю свою выборку (которая у них в Override или просто одну таблицу), а условие связи с таблицей фактов они применяют потом.
Необязательно, это зависит от выбранного типа кеширования (данные хранятся либо в локальной памяти, либо как ссылка на удаленный объект). У каждого варианта свои достоинства и недостатки. Если справочник относительно мал, то локальное кеширование выгодно. Напротив, при разрешении небольшого количества записей через большой справочник последний можно не кешировать и не тратит ресурсы на загрузку в локальную память, а обращаться для каждой записи в удаленную БД.
10 сен 20, 14:28    [22194811]     Ответить | Цитировать Сообщить модератору
 Re: Изучаю Informatica - вопросы для понимания  [new]
psamv
Member

Откуда:
Сообщений: 26
.Евгений
psamv
Единственное, лукапы каждый раз берут всю свою выборку (которая у них в Override или просто одну таблицу), а условие связи с таблицей фактов они применяют потом.
Необязательно, это зависит от выбранного типа кеширования (данные хранятся либо в локальной памяти, либо как ссылка на удаленный объект). У каждого варианта свои достоинства и недостатки. Если справочник относительно мал, то локальное кеширование выгодно. Напротив, при разрешении небольшого количества записей через большой справочник последний можно не кешировать и не тратит ресурсы на загрузку в локальную память, а обращаться для каждой записи в удаленную БД.
Спасибо.
Это уже многое проясняет, весьма для меня ценно. А я не знал, думал почему-то, что он всегда связывает потом.

Если из большого справочника нужно немного записей, то конечно, кэшировать очень затратно.
Если справочник небольшой, то выгодно. Т.е. это зависит от % нужных в справочнике строк.

Но если этот справочник БОЛЬШОЙ и берётся его значительный объём, то нужно проверять - кэшировать или нет, что выгоднее с учётом нагрузки на базу. Но если выполнять его на стороне БД, то работа лукапа здесь не будет отличаться от выборки в SQ (самой-по-себе). Но SQ + Joiner будет затратнее, чем такой лукап.

Всё верно?
10 сен 20, 15:41    [22194884]     Ответить | Цитировать Сообщить модератору
 Re: Изучаю Informatica - вопросы для понимания  [new]
.Евгений
Member

Откуда:
Сообщений: 574
psamv,

лукап выполняет запрос к источнику для каждой записи в потоке. Запрос в память быстр, к дисковому кешу медленнее. Некешированный лукап самый медленный, зато ему не нужна предварительная загрузка данных. Join двух SQ требует их одинаковой сортировки - если она уже выполнена, то соединение работает быстро.
10 сен 20, 17:08    [22194962]     Ответить | Цитировать Сообщить модератору
 Re: Изучаю Informatica - вопросы для понимания  [new]
psamv
Member

Откуда:
Сообщений: 26
.Евгений
psamv,

лукап выполняет запрос к источнику для каждой записи в потоке. Запрос в память быстр, к дисковому кешу медленнее. Некешированный лукап самый медленный, зато ему не нужна предварительная загрузка данных. Join двух SQ требует их одинаковой сортировки - если она уже выполнена, то соединение работает быстро.
Получается 1000 записей - некэшированный 1000 раз соединится с удалённой БД, а кэшированный - то же, но со своим локальным кэшем - поэтому быстрее. Но закэшировать тоже нужно время, поэтому если маленький % строк, то не кэшированный лукап может быть выгоднее.

?) "Запрос в память быстр" - вы написали для полноты картины? Но сам Лукап же в такую память не обращается? Он только в кэш или на базу )

И получается тогда, что если большой справочник и там берётся больше половины записей, то скорее всего выгодней кэшировать его всё же )

Теперь, наверное, я правильно понял ) (надеюсь:)

Сообщение было отредактировано: 10 сен 20, 17:42
10 сен 20, 17:44    [22195002]     Ответить | Цитировать Сообщить модератору
 Re: Изучаю Informatica - вопросы для понимания  [new]
.Евгений
Member

Откуда:
Сообщений: 574
psamv
Получается 1000 записей - некэшированный 1000 раз соединится с пошлет SQL запрос удалённой БД, а кэшированный - то же, но со прочтет свой локальный кэш - поэтому быстрее. Но закэшировать тоже нужно время, поэтому если маленький % строк, то не кэшированный лукап может быть выгоднее.
Локальный кеш, в зависимости от настроек и объема, может храниться в памяти или на диске в виде файла.
10 сен 20, 19:07    [22195033]     Ответить | Цитировать Сообщить модератору
 Re: Изучаю Informatica - вопросы для понимания  [new]
psamv
Member

Откуда:
Сообщений: 26
.Евгений
лукап выполняет запрос к источнику для каждой записи в потоке. Запрос в память быстр, к дисковому кешу медленнее. Некешированный лукап самый медленный, зато ему не нужна предварительная загрузка данных. Join двух SQ требует их одинаковой сортировки - если она уже выполнена, то соединение работает быстро.
Если можно, как это будет на конкретном примере:

Есть внешний запрос, где выбираются поля, в т.ч. подселектами:

select
     ...
     <subselect к табличке sub_tab, содержащей 500 000 строк>
     ... (и другие подзапросы)
from main_tab

main_tab содержит 2 000 000 строк.
Таблицы связаны по полю ID в соотношении 1:1
Подзапрос, сам-по-себе, берёт только 5 записей по всем своим ограничениям. Это для 2-х миллионов строк основного.

В маппинге:
есть SQ по main_tab, берущий 2 млн. строк - основная выборка, содержащая поля, к которым нужно добавить поля выбранные такими подселектами.

Как в этом случае поведёт себя:
1) кэшированный
2) и некэшированный лукап
3) и если запрос сразу поместить в Sql Query в SQ ?


1) Если мы добавляем кэшированным лукапом этот подзапрос - он просто кэширует 5 строк (как понял). Потом, подставляя условие связи с основной выборкой, добавляет поле, заполняя его для этих 5-ти ID данными и всё - очень быстро.

2) Если лукап не кэшируется, то он будет таскать из базы все 2 000 000 по одной. А потом упадёт в обморок узнав, что нужно только 5.

3) Если делать не через лукап, а через ещё одно SQ (взяв нужное поле и ID, для связи с основной выборкой), то, как я понял, разница в том, что не будет бегать туда сюда а выберет все 2 млн. на стороне БД. Это конечно не_медленно (БД работает быстро), но, дольше, чем лукапом из кэша, и грузит базу. А потом сортировка и Join поля к основной выборке ещё потребуют времени.

Поэтому здесь лучше кашированный лукап. я так понял.

Между моим и Вашим пониманием - немалый пробел, поэтому мне немного сложновато понять так. Может быть, на таком примере будет проще, если у Вас есть время.
10 сен 20, 19:26    [22195038]     Ответить | Цитировать Сообщить модератору
 Re: Изучаю Informatica - вопросы для понимания  [new]
Anonymous_20
Member

Откуда:
Сообщений: 16
Бумбараш
psamv

1) Возвращаясь к лукапам. Пока не очень понятно чем они хороши и почему сделаны отдельным инструментом. Кажется, что их почти всегда можно заменить SQL-транс-ями и это будет выгодней.
Исключение может - совсем простенькие лукапы, без Override.

они нужны, чтобы их продавать

за 10 лет работы с инфой, основной её lifecycle: пользователь всё больше начинают использовать SQL, переходя на полный ELT, а потом выкидывают инфу. Потому что уже непонятно, зачем она нужна.


Самая большая проблема это отсутствие квалифицированных специалистов (их мало). Приходилось работать во многих конторах с информатикой. Рисовал не только стандартные процессы, но даже веб сервисы на информатики и другие режимы информатики задействовать приходилось. Приходилось заниматься подготовкой новичков и вот тут кроется главная проблема "молодых" кадров:
1. Чтобы качествено разрабатывать иногда необходимо забыть свой предыдущий опыт SQL разработчика или любой другой роли. Тут многое по другому. На этом этапе уже начинаются большие проблемы, некоторым разработчикам не могут переключится и пытаются все на sql перевести.
2. Не пытаются анализировать, что делают. Накидают трансформацией на дефолтных настройках, пройдут все контуры, но потом на бою может через месяц, может даже через несколько лет, такой мапинг перестает нормально работать, начинаешь разбираться и единственный вопрос в голове возникает, как все это работало.

Со своей колокольни могу сказать, для качественной разработки необходимо знать: Информатику, скриптовые языки (BASH например), ОС (на котором крутится инфа), основы СУБД (был опыт когда из за не оптимальных настроек инфа парализовала работу СУБД даже 1 потоком) с которыми придется работать, SQL, веб технологии, основы java (программировать, то что инфа не умеет). И самое главное умение договариваться. Иногда проще переложить часть функционала на информатику, иногда проще со смежником (разработчик в системе источника или получателя) договорится, чтобы он сделал на своей стороне.

[quot psamv#22195038]
.Евгений


Как в этом случае поведёт себя:
1) кэшированный
2) и некэшированный лукап
3) и если запрос сразу поместить в Sql Query в SQ ?


1) Если мы добавляем кэшированным лукапом этот подзапрос - он просто кэширует 5 строк (как понял). Потом, подставляя условие связи с основной выборкой, добавляет поле, заполняя его для этих 5-ти ID данными и всё - очень быстро.

2) Если лукап не кэшируется, то он будет таскать из базы все 2 000 000 по одной. А потом упадёт в обморок узнав, что нужно только 5.

3) Если делать не через лукап, а через ещё одно SQ (взяв нужное поле и ID, для связи с основной выборкой), то, как я понял, разница в том, что не будет бегать туда сюда а выберет все 2 млн. на стороне БД. Это конечно не_медленно (БД работает быстро), но, дольше, чем лукапом из кэша, и грузит базу. А потом сортировка и Join поля к основной выборке ещё потребуют времени.

Поэтому здесь лучше кашированный лукап. я так понял.
.


В вашем случаи как понимаю должен быть активный, кешируемый лукап. На вкладке Condition делайте связь. 2 000 000 записей лукап закешировать за несколько минут максимум.
3 вариант ваш очень спорный. Вы просто так прожираете ресурсы информатики. Почитайте про JOINER https://kb.informatica.com/whitepapers/1/Pages/16632.aspx?myk=join cache
Запомнить все что ниже What are the Joiner caches?
Сортировщики дает только возможность параллельно считывать из 2 таблиц, но такой вариант и имеет свои минусы.
11 сен 20, 09:48    [22195219]     Ответить | Цитировать Сообщить модератору
 Re: Изучаю Informatica - вопросы для понимания  [new]
psamv
Member

Откуда:
Сообщений: 26
Anonymous_20

В вашем случаи как понимаю должен быть активный, кешируемый лукап. На вкладке Condition делайте связь. 2 000 000 записей лукап закешировать за несколько минут максимум.
3 вариант ваш очень спорный. Вы просто так прожираете ресурсы информатики. Почитайте про JOINER https://kb.informatica.com/whitepapers/1/Pages/16632.aspx?myk=join cache
Запомнить все что ниже What are the Joiner caches?
Сортировщики дает только возможность параллельно считывать из 2 таблиц, но такой вариант и имеет свои минусы.
Спасибо за комментарий и советы, обязательно почитаю вот, по той ссылке.
Единственное: насчёт 3-его моего спорного варианта: Он отрабатывает стабильно в 5-10 раз быстрее лукапа и выбирает только нужные записи (около 100 000) по своим фильтрам и связям, без всего лишнего.
Лукап же берёт все 2 000 000, достаточно долго.

Запрос в Sql Query в SQ срабатывает на стороне БД, поэтому насчёт расточительности Информатики.. сложно сказать. Вроде не особо - только Joiner, но на таком объёме данных он, мне кажется сработает быстро.

Пока понимаю так.
11 сен 20, 11:33    [22195280]     Ответить | Цитировать Сообщить модератору
 Re: Изучаю Informatica - вопросы для понимания  [new]
Anonymous_20
Member

Откуда:
Сообщений: 16
psamv,

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

Таблица A имеет 5 000 000 записей.
Таблица Б имеет 10 000 записей.

Если используем только Joiner.
Правильно делать Таблицу Б Master, а Таблицу А Detail. Как будет работать информатика Она частично скачает таблицу А, потом будет ожидать окончания загрузки таблицы Б. Результат загрузки таблицы Б она полностью закэширует для соединения.
Минус такого подхода. Если перепутать местами таблицы, или таблица Б будет очень огромная То загрузка, которая идет в Detail (А) может падать с ошибкой для ORACLE например ORA-1555: snapshot too old. Или был случай когда кэш генерировался по 500 ГБ.

Можно перед Joiner поставить сортировщик. Тогда вычитка из таблиц будет идти параллельно, так как сортировщик чтобы отдал данные он должен все получить. Но есть баг у информатики, не знаю в 10.4 починили его или нет. Пока у вас низкая скорость работы нечего страшного не происходит. Но у меня был процесс со скоростью работы около 250 000 записей в секунду с каждой таблицы. Тогда сортировщики начинают неплохо забивать ядра CPU.
Плюс надо запомнить, информатика рассчитывает кэш не от объема данных (сумма символов с строке), а от максимального размера полей указанных в трансформации. И пару поле с максимальным размером 100 мб неплохо места на диске отъедает.
Одним словом здесь как в медицине, не видя клиента и анализы, диагноз адекватный и план лечения трудно назначить.

Встречался не раз с такими решениями которые хорошо работали первые пол года-год, а потом скорость резко падает. И когда начинаешь разбираться, понимаешь тут разработчик не заложился на объем роста данных. Тут он лишнею трансформацию активную поставил. Или текущие решение на такой объеме плохо будет всегда работать.
Также многое зависит от серверов и дисковых массивов на которых крутится информатика.
11 сен 20, 12:17    [22195310]     Ответить | Цитировать Сообщить модератору
 Re: Изучаю Informatica - вопросы для понимания  [new]
psamv
Member

Откуда:
Сообщений: 26
Anonymous_20, это верно, что учитывая больше параметров, достигается лучший результат.
У вас большой опыт. У меня пока не слишком. Но то что вы написали, будет мне полезно.
Конечно, показатель не только скорость, не только что-то одно, но для начала лучше не быть абсолютным перфикционистом и пока делать лучшее, что можешь. Развивать это по мере накопления знаний.
Спасибо.
11 сен 20, 13:06    [22195349]     Ответить | Цитировать Сообщить модератору
 Re: Изучаю Informatica - вопросы для понимания  [new]
Бумбараш
Member

Откуда: никем не победимая, самая любимая
Сообщений: 2748
Anonymous_20


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

Я про минусы информатики писал, когда был маленьким 14105796
Сейчас информатику никто в проектах с нуля не использует. Только в ригидных энтерпрайзах, которые уже обвешаны лицензиями информатики и там в ЛПР деревянные дяди.
Сейчас в основном пишут свой етль на питонах в основном, или попенсорс етли используют.
11 сен 20, 13:39    [22195373]     Ответить | Цитировать Сообщить модератору
 Re: Изучаю Informatica - вопросы для понимания  [new]
.Евгений
Member

Откуда:
Сообщений: 574
Бумбараш
Сейчас в основном пишут свой етль на питонах в основном

Т.н. "экосистема" с 1...n внешними модулями и полноценным программированием. Про скорость работы именно питонской части скромно умолчу.
Бумбараш
или попенсорс етли используют.

Безусловно, комьюнити версии Таленда или Пентахо дают заметный выигрыш на стоимости лицензирования в сравнении с СУБД или Информатикой.
11 сен 20, 19:24    [22195587]     Ответить | Цитировать Сообщить модератору
 Re: Изучаю Informatica - вопросы для понимания  [new]
Master_Detail
Member

Откуда:
Сообщений: 70
Бумбараш
Я про минусы информатики писал, когда был маленьким 14105796

Хороший текст у вас. Абсолютно те же наблюдения и мысли у меня появлялись. Для себя сделал пару выводов:
- если баз не одна, а 100500, то как некое централизованное ETL-средство - норм. Тем более в банках, где без нее приходилось бы кидать дблинки, открывать порты всем подряд. Безопасности это всегда не нравится
- если источники разнородные. Быстро подтянуть данные из разных СУБД, веб-сервиса, еще откуда-то и слить их в один таргет достаточно сложно будет иными средствами. Другое дело, что таких задач 1 на 1000
- Enterprise любит готовые решения, чтобы была поддержка и гарантии, что самописный питон завтра не свалится, а писавший его народ не разбежится

Сообщение было отредактировано: 13 сен 20, 20:46
13 сен 20, 20:46    [22196230]     Ответить | Цитировать Сообщить модератору
 Re: Изучаю Informatica - вопросы для понимания  [new]
Бумбараш
Member

Откуда: никем не победимая, самая любимая
Сообщений: 2748
Master_Detail

- если баз не одна, а 100500, то как некое централизованное ETL-средство - норм. Тем более в банках, где без нее приходилось бы кидать дблинки, открывать порты всем подряд. Безопасности это всегда не нравится

открывать порты вы в любом случае будете. Информатика в этом плане ничем не отличается.
Master_Detail

- если источники разнородные. Быстро подтянуть данные из разных СУБД, веб-сервиса, еще откуда-то и слить их в один таргет достаточно сложно будет иными средствами. Другое дело, что таких задач 1 на 1000

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

Master_Detail

- Enterprise любит готовые решения, чтобы была поддержка и гарантии, что самописный питон завтра не свалится, а писавший его народ не разбежится

Я информатику видел в интерпрайзе много раз и покупал. У неё нет никакой поддержки и гарантии. Есть какая-то промежуточная контора, галера, которая продает лицензии и людей. Назовём её дис. С ней заключается контракт на определенный набор услуг. Если там нет поддержки, её не будет. Если будет поддержка, она будет. Но эта поддержка ничем не отличается от той поддержки, если вы заключите контракт с другой галерой на написание ETL на питоне, и поддержку его.
Никакой такой поддержки от самой компании Informatica и гарантий от неё у вас не будет. Когда поддержка от галеры закончится, и команда разбежится, у вас на информатике точно также может всё развалится, и собирать может быть еще сложнее. Потому что код разнесен на три части - саму информатику, питон и скль.
Кроме того у вас с информатикой могут возникать ошибки с описанием ofx12haxhtsr, ака синий экран, после чего информатика падает мертвой полностью. С питоном такого не бывает. Все такие ошибки поддержка информатики в 90% случаев рекомендует решать установкой новой версии.
13 сен 20, 22:14    [22196253]     Ответить | Цитировать Сообщить модератору
 Re: Изучаю Informatica - вопросы для понимания  [new]
Бумбараш
Member

Откуда: никем не победимая, самая любимая
Сообщений: 2748
Master_Detail

- Enterprise любит готовые решения, чтобы была поддержка и гарантии

ну и еще раз. Это положение дел на 2005 год. Тогда можно было говорить такое про информатику. Сейчас в любом самом большом энтерпрайзе никто её уже не внедряет, как тогда. А пользуются другими средствами.
13 сен 20, 22:15    [22196254]     Ответить | Цитировать Сообщить модератору
 Re: Изучаю Informatica - вопросы для понимания  [new]
Master_Detail
Member

Откуда:
Сообщений: 70
Бумбараш

открывать порты вы в любом случае будете. Информатика в этом плане ничем не отличается.

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

Бумбараш

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

Бесспорно. Но я о том, что такое решение уже должно быть. А информатика его как бы предоставляет заранее. Если деньги ляшку не жгут, то и идут и покупают информатику, наслушавшись ее продажников

Бумбараш
Я информатику видел в интерпрайзе много раз и покупал...

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

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

Сообщение было отредактировано: 15 сен 20, 10:51
15 сен 20, 10:55    [22197118]     Ответить | Цитировать Сообщить модератору
 Re: Изучаю Informatica - вопросы для понимания  [new]
netdiver
Member

Откуда:
Сообщений: 5
Критик,

Насчет БНП - врут частично. Инфа используется на корпоративном уровне. Скорее вынудили поставить ее, чтоб могли общаться "на одном" языке. Сам работаю в бнп (dwh) с информатикой.
25 сен 20, 14:37    [22204285]     Ответить | Цитировать Сообщить модератору
 Re: Изучаю Informatica - вопросы для понимания  [new]
netdiver
Member

Откуда:
Сообщений: 5
Бумбараш,

Бумбараш
за 10 лет работы с инфой, основной её lifecycle: пользователь всё больше начинают использовать SQL, переходя на полный ELT, а потом выкидывают инфу. Потому что уже непонятно, зачем она нужна.


Явно за 10 лет тебе просто не приходилось собирать и интегрировать в двх данные с 200+ офисов со всего мира из 10+ разных систем и в csv, xml, excel, oracle, db2, postgre и тп одновременно.
25 сен 20, 14:46    [22204293]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 [2] 3   вперед  Ctrl      все
Все форумы / OLAP и DWH Ответить