ReSQL.ru
     
powered by simpleCommunicator - 2.0.29     © 2024 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Map
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / OLAP и DWH [игнор отключен] [закрыт для гостей] / Идеально, если DWH должен подключаться базе. Но ведь база в любой момент может измениться
25 сообщений из 25, страница 1 из 1
Идеально, если DWH должен подключаться базе. Но ведь база в любой момент может измениться
    #40111156
Charles Weyland
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Charles Weyland
Участник
В любой "методичке" говорится, что ETL хранилища должен подключаться непосредственно к базам данных OLTP систем.
Такое требование выкатывает любой интегратор, который примется за работу и т.д.

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

Как у вас в таком случае выстраивается работа?
...
Рейтинг: 0 / 0
11.11.2021, 22:00
| Ответить | Цитировать | Написать  
Идеально, если DWH должен подключаться базе. Но ведь база в любой момент может измениться
    #40111159
montoya.
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
montoya.
Гость
Charles Weyland
В любой "методичке" говорится, что ETL хранилища должен подключаться непосредственно к базам данных OLTP систем.
Такое требование выкатывает любой интегратор, который примется за работу и т.д.

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

Как у вас в таком случае выстраивается работа?


1. siss пакеты должны быть настроены не на всю таблицу, а только select на нужные поля.
что бы вновь добавленные поля не ломали существующий процесс.
2. релизы OLTP должны быть предсказуемыми, ну т.е. каждый вторник например.
3. желательно что бы можно было сравнить схему баз до и после и отловить все изменения.
4. после релиза как минимум прогнать ETL как максимум ещё просмотреть пакеты на валидность.
5. если команда OLTP - "гуд ребята" то можно настраиваться не на таблицы а на процедуры например и что бы после релиза их валидировать.

как-то так...
...
Рейтинг: 0 / 0
11.11.2021, 22:09
| Ответить | Цитировать | Написать  
Идеально, если DWH должен подключаться базе. Но ведь база в любой момент может измениться
    #40111161
Фотография Критик
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Критик
Участник
montoya.,

1. Не на нужные поля таблицы, а на все имеющиеся поля.
И SSIS - пакет не ломается после добавления полей в источнике.

Просто должен быть желателен контроль "той командой" над теми таблицами, из которых качаются данные. Это может быть частью тестирования релиза OLTP-системы. Желателен - потому что это не всегда возможно, например, можно качать данные из гугла или яндекса, а они могут поменять источник, "проинформировав" об этом на своем сайте.
...
Рейтинг: 0 / 0
11.11.2021, 22:22
| Ответить | Цитировать | Написать  
Идеально, если DWH должен подключаться базе. Но ведь база в любой момент может измениться
    #40111162
.Евгений
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
.Евгений
Участник
Charles Weyland,

В моем случае ETL взаимодействует с другими системами через шину, получая на вход документы, сформированные системой-источником. Поэтому большинство изменений в БД источников (равно как и сами БД) никак не затрагивают ETL.
...
Рейтинг: 0 / 0
11.11.2021, 22:24
| Ответить | Цитировать | Написать  
Идеально, если DWH должен подключаться базе. Но ведь база в любой момент может измениться
    #40111172
Charles Weyland
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Charles Weyland
Участник
ответы - супер.
Спасибо! Хотя тему мониторить продолжаю, интересно, у кого ещё какая практика.
...
Рейтинг: 0 / 0
11.11.2021, 23:09
| Ответить | Цитировать | Написать  
Идеально, если DWH должен подключаться базе. Но ведь база в любой момент может измениться
    #40111243
montoya.
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
montoya.
Гость
Критик
montoya.,

1. Не на нужные поля таблицы, а на все имеющиеся поля.
И SSIS - пакет не ломается после добавления полей в источнике.

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


значит удалённые поля ломают) или вдруг увеличат размер данных и будет переполнение.
а зачем тянуть поля всей таблицы
например в таблице 100 полей
а мне нужно 15. для хранилища.
в остальных нет смысла.
...
Рейтинг: 0 / 0
12.11.2021, 11:18
| Ответить | Цитировать | Написать  
Идеально, если DWH должен подключаться базе. Но ведь база в любой момент может измениться
    #40111249
montoya.
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
montoya.
Гость
с добавленными полями я загнул)))
спасибо за корректировку)
...
Рейтинг: 0 / 0
12.11.2021, 11:36
| Ответить | Цитировать | Написать  
Идеально, если DWH должен подключаться базе. Но ведь база в любой момент может измениться
    #40111466
bideveloper
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
bideveloper
Участник
Еще частый вариант, что в OLTP увеличивают размер строкового поля, которое передается через SSIS. И тогда через какое-то время пакет обязательно упадет) но не сразу, а когда в это поле реально будут записаны данные по размеру больше, чем раньше.
...
Рейтинг: 0 / 0
12.11.2021, 18:17
| Ответить | Цитировать | Написать  
Идеально, если DWH должен подключаться базе. Но ведь база в любой момент может измениться
    #40111519
Фотография Критик
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Критик
Участник
montoya.
а зачем тянуть поля всей таблицы
например в таблице 100 полей
а мне нужно 15. для хранилища.
в остальных нет смысла.


потому что потом будут задачи типа "мне бы вот еще это поле", и так несколько раз...
и каждый раз придется все перегружать, а работа человека стоит дороже хранения "лишнего"
...
Рейтинг: 0 / 0
12.11.2021, 19:55
| Ответить | Цитировать | Написать  
Идеально, если DWH должен подключаться базе. Но ведь база в любой момент может измениться
    #40111527
.Евгений
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
.Евгений
Участник
Критик
montoya.
а зачем тянуть поля всей таблицы
например в таблице 100 полей
а мне нужно 15. для хранилища.
в остальных нет смысла.


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

Такой логикой уже пытались перейти от реляционных СУБД к документоориентированным. Зачем человеку трудиться над добавлением полей в таблицы или оптимизировать запросы, если есть XML?
bideveloper
Еще частый вариант, что в OLTP увеличивают размер строкового поля, которое передается через SSIS. И тогда через какое-то время пакет обязательно упадет) но не сразу, а когда в это поле реально будут записаны данные по размеру больше, чем раньше.

Поработав с различными ETL средствами, часто испытываешь желание скрестить их между собой, иметь возможность выбирать между неуправляемой начинкой буфера SSIS и, скажем, управляемыми коллекциями Таленда: если в первом случае строковое поле имеет фиксированную длину, то во втором это обычный класс Java String. Спасаюсь от этого фразой Мичурина: «Мы не можем ждать милостей от природывендоров. Взять их у неё – наша задача. Человек может и должен создавать новые формы растений компонентов лучше природы стандартных».
...
Рейтинг: 0 / 0
12.11.2021, 20:28
| Ответить | Цитировать | Написать  
Идеально, если DWH должен подключаться базе. Но ведь база в любой момент может измениться
    #40111614
montoya.
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
montoya.
Гость
Критик
montoya.
а зачем тянуть поля всей таблицы
например в таблице 100 полей
а мне нужно 15. для хранилища.
в остальных нет смысла.


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


видимо кто на что напоролся в практике)
в моей практике часто сталкивался с тем, что на PROD'e ряд "секретных" атрибутов клиентов вначале прятали, потом отображали
потом таблицу делили на 2 с секретными данными и без.
потом снова прятали, потом снова отображали...
весело было)))
после чего взял за привычку тянуть ровно столько сколько нужно.
...
Рейтинг: 0 / 0
12.11.2021, 23:47
| Ответить | Цитировать | Написать  
Идеально, если DWH должен подключаться базе. Но ведь база в любой момент может измениться
    #40111623
Ivan Durak
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Ivan Durak
Участник
чтобы сгружать таблицы целиком, со всеми полями придумали даталейк с файл стораджем на S3 или Azure
там и места много и выгрузка в файл не сломается при новых полях.
А уже оттуда затягивать в DWH только необходимое.
...
Рейтинг: 0 / 0
13.11.2021, 01:23
| Ответить | Цитировать | Написать  
Идеально, если DWH должен подключаться базе. Но ведь база в любой момент может измениться
    #40111635
Александр Бердышев
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Александр Бердышев
Участник
Прод/препрод.
На препроде отлавливаем ошибки, изменения на прод заливаем только по заявке.
Если ошибка просочилась - тогда быстро исправляем или откатываем изменения.
...
Рейтинг: 0 / 0
13.11.2021, 02:40
| Ответить | Цитировать | Написать  
Идеально, если DWH должен подключаться базе. Но ведь база в любой момент может измениться
    #40111657
Ferdipux
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Ferdipux
Гость
Charles Weyland,

Из исходной системы данные выгребает CDC. Потом эти данные собираются назад в Hadoop, выполняется синтез полного описания объекта по данным CDC, и уже оттуда забираются в DWH.
Появилось новое поле - мы его "когда-нибудь" интегрируем в DWH. Или нет.

Другой подход - на источнике формируется "интерфейсный слой" из view, которые читает ETL. Это более legacy подход и скорее на темную сторону силы.
...
Рейтинг: 0 / 0
13.11.2021, 11:25
| Ответить | Цитировать | Написать  
Идеально, если DWH должен подключаться базе. Но ведь база в любой момент может измениться
    #40111659
Ferdipux
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Ferdipux
Гость
.Евгений
В моем случае ETL взаимодействует с другими системами через шину, получая на вход документы, сформированные системой-источником. Поэтому большинство изменений в БД источников (равно как и сами БД) никак не затрагивают ETL.

Это сильно напоминает работу с SAP BW году в 2005 :).
Там, чтобы добавить новое поле:
  • сначала по скудной документации ищешь в какой объект оно может быть добавлено.
  • затем ищешь какой метод этот объект формирует и обогащает
  • затем ищешь подходящий по времени выполнения user exit. И плачешь если такого нет, пишешь в поддержку SAP и т.п.
  • расширяешь структуры
  • пишешь user exit по наполнению данными
  • расширяешь обменные структуры SAP BW
  • перегенерируешь интерфейс
И затем - начинаешь что-то делать в самом SAP BW ETL, мапить поле куда-то.

Все это сопровождается скудной документацией, вопросами "какой объект, какой user exit" и так далее. На третьей задаче - думаешь что ну его такой правильный архитектурный подход, лучше бы грузили таблицами в stage и там растаскивали.
...
Рейтинг: 0 / 0
13.11.2021, 11:32
| Ответить | Цитировать | Написать  
Идеально, если DWH должен подключаться базе. Но ведь база в любой момент может измениться
    #40111669
artel.dev
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
artel.dev
Гость
Много лет назад работал с банковским хранилищем.

Там ETL не завершался на каждый второй раз и заказчик начинал нервничать и винить команду внедрения.

Мы завели журнал ошибок, с указанием когда ошибка возникла, источник ошибки, ответственный за устранение и т.д.

Оказалось что не всегда виновата команда внедрения, бывает что источник внезапно отключается и сыпется весь ETL-процесс.

Поэтому из источника брали минимум + это ускоряет процесс копирования, который мог длиться до часа, а тебе еще до утра надо успеть все витрины и отчёты обновить.

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

Вообще отлично иметь SLA в котором прописано какие таблицы из источника используются хранилищем и сколько времени должно занимать их копирование.
...
Рейтинг: 0 / 0
13.11.2021, 12:48
| Ответить | Цитировать | Написать  
Идеально, если DWH должен подключаться базе. Но ведь база в любой момент может измениться
    #40111711
.Евгений
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
.Евгений
Участник
Ferdipux,
вы описываете проблемы SAPа, а не ETL. Если мне нужно загрузить новое поле, то я просто связываю XPath тега с полем БД, которое подтягиваю в пакет. На последнем этапе всегда жалею, что SSIS негибко работает с наборами столбцов: не умеет копипастить, хранить в глобальных метаданных, разрешать структуру на этапе выполнения...
...
Рейтинг: 0 / 0
13.11.2021, 16:12
| Ответить | Цитировать | Написать  
Идеально, если DWH должен подключаться базе. Но ведь база в любой момент может измениться
    #40111812
Полковник.
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Полковник.
Участник
Charles Weyland
В любой "методичке" говорится, что ETL хранилища должен подключаться непосредственно к базам данных OLTP систем.
Такое требование выкатывает любой интегратор, который примется за работу и т.д.

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

Как у вас в таком случае выстраивается работа?

1. ETL работает по метаданным, заранее известному набору полей и таблиц.
2. Если падает загрузка, должен быть разбор логов, с выявление причин, и наказанием виновных, шутка, логов в ETL нужно много
3. В больших компаниях есть процесс регресстонного тестирования, в котором проверяется повлияла ли доработка на работоспособность смежных систем и только после неё и остальных тестов и приемок доработка переносится в продакшен.
...
Рейтинг: 0 / 0
14.11.2021, 08:24
| Ответить | Цитировать | Написать  
Идеально, если DWH должен подключаться базе. Но ведь база в любой момент может измениться
    #40111817
Полковник.
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Полковник.
Участник
* регрессионного тестирования
...
Рейтинг: 0 / 0
14.11.2021, 09:56
| Ответить | Цитировать | Написать  
Идеально, если DWH должен подключаться базе. Но ведь база в любой момент может измениться
    #40111829
Ferdipux
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Ferdipux
Гость
.Евгений
вы описываете проблемы SAPа, а не ETL.

ТС задал такой общий вопрос - про подходы к обустройству ETL, архитектуре всего процесса с учетом изменений. По хорошему, ETL работает с интерфейсным слоем ИС, который как-то устроен и наполняется, меняется и т.п.
Мой пример - он про то, что в такой постановке вопроса ETL не может сказать "проблемы индейцев шерифа не волнуют". Если из-за красивой архитектурной модели интерфейсный слой модифицировать будет слишком тяжело - на это будут потихоньку забивать и костылить прямую передачу data frame - в виде прямого доступа к таблицам, csv или parquet файлов и т.п. А так конечно да - ETL очень удобно было работать с такой моделью через XPath и пр.

Вопрос подхода в другом. Исходные системы - они развиваются самостоятельно, быстро и agil-ово. Им этот интерфейсный слой хранилища - как гиря на ногах, ценности нет. Отсюда и растут подходы "свалим все в Hadoop, потом сами разберетесь как это все читать".
...
Рейтинг: 0 / 0
14.11.2021, 11:47
| Ответить | Цитировать | Написать  
Идеально, если DWH должен подключаться базе. Но ведь база в любой момент может измениться
    #40111849
.Евгений
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
.Евгений
Участник
Ferdipux
Мой пример - он про то, что в такой постановке вопроса ETL не может сказать "проблемы индейцев шерифа не волнуют". Если из-за красивой архитектурной модели интерфейсный слой модифицировать будет слишком тяжело - на это будут потихоньку забивать и костылить прямую передачу data frame - в виде прямого доступа к таблицам, csv или parquet файлов и т.п.(...)Отсюда и растут подходы "свалим все в Hadoop, потом сами разберетесь как это все читать".

У нас весь обмен между системами ведется документами через шину, каждая система отвечает только за свои документы (+ свой обмен с шиной). Их наполнение согласовывается на бизнес-уровне, что значительно упрощает жизнь программистов - нужно знать только свою систему (и проблемы индейцев шерифа действительно не волнуют). Прямое подключение практикуется лишь в исключительных случаях - можно сказать, на свой страх и риск.
...
Рейтинг: 0 / 0
14.11.2021, 13:53
| Ответить | Цитировать | Написать  
Идеально, если DWH должен подключаться базе. Но ведь база в любой момент может измениться
    #40111911
Полковник.
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Полковник.
Участник
.Евгений,

Вы про модно-мрлодежную микросервисную архитектуру? Если я правильно понял. Хорошо, обмен сообщениями (документами) ежду системами ещё можно отследить по шине и затолкнуть это в дата-лайк, но что делать с процессами внутри самих систем, как доставать из них данные, тоже через шину?
По факту чем больше микросервисов, тем больше бардака и головная боль для интеграции, у нас в ВТБ дошло до того, что по некоторым системам нет никакой документации, ни описано ни одной модели данных до объектов и связей между ними, ничего нет.
...
Рейтинг: 0 / 0
14.11.2021, 17:29
| Ответить | Цитировать | Написать  
Идеально, если DWH должен подключаться базе. Но ведь база в любой момент может измениться
    #40111935
.Евгений
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
.Евгений
Участник
Полковник.
.Евгений,

Вы про модно-мрлодежную микросервисную архитектуру? Если я правильно понял. Хорошо, обмен сообщениями (документами) ежду системами ещё можно отследить по шине и затолкнуть это в дата-лайк, но что делать с процессами внутри самих систем, как доставать из них данные, тоже через шину?
По факту чем больше микросервисов, тем больше бардака и головная боль для интеграции, у нас в ВТБ дошло до того, что по некоторым системам нет никакой документации, ни описано ни одной модели данных до объектов и связей между ними, ничего нет.

Не-не-не, чур-чур-чур меня.
У нас есть несколько фронтовых систем, бэк, DWH, собственные витрины нескольких департаментов, и я говорил только про обмен между ними. Процессы внутри систем - это проблемы их владельцев, и с уверенностью я могу говорить только про свою: ничего модно-молодежного там нет. Недавно коллеги пытались продавить использование RPC-шаблона - пока отбился...
...
Рейтинг: 0 / 0
14.11.2021, 18:41
| Ответить | Цитировать | Написать  
Идеально, если DWH должен подключаться базе. Но ведь база в любой момент может измениться
    #40112115
Master_Detail
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Master_Detail
Гость
В системах-источниках очень уж редко меняются поля. А вот новые добавляются частенько, конечно. В случае изменения существующих обычно два варианта:
1. У нас же есть ХД, давайте их предупредим, вдруг нужно
2. Просто делаем и нам все-равно, что будет дальше

Работает примерно 50/50 :)
...
Рейтинг: 0 / 0
15.11.2021, 16:19
| Ответить | Цитировать | Написать  
Идеально, если DWH должен подключаться базе. Но ведь база в любой момент может измениться
    #40112191
artel.dev
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
artel.dev
Гость
На проекте был случай когда DWH подключался ко вьюхам источника.

Безопасники решили, что вьюх для хранилища достаточно.

Потом пользователи жаловались что не все данные есть в витрине ХД.

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

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

Процесс этот был медленный и печальный.
...
Рейтинг: 0 / 0
15.11.2021, 19:36
| Ответить | Цитировать | Написать  
25 сообщений из 25, страница 1 из 1
Форумы / OLAP и DWH [игнор отключен] [закрыт для гостей] / Идеально, если DWH должен подключаться базе. Но ведь база в любой момент может измениться
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
Польз. соглашение
NoSQL.ru, Чат Кролика       Пашэ: Рисунки, Чат       Фотоальбом: Участники, Встречи
Закрыть
start [/forum/topic.php?fid=49&fpage=2&gotolast=1&tid=1857065]:
 0ms
get settings:
 25ms
get forum list:
 18ms
check forum access:
 4ms
check topic access:
 4ms
track hit:
 44ms
get topic data:
 14ms
get forum data:
 3ms
get page messages:
 497ms
get tp. blocked users:
 2ms
others: 316ms
total:  927ms
созд. / загр.: 927ms
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]