Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
Кто как осуществляет логгирование ETL-процесса?
|
|||
|---|---|---|---|
|
#18+
У меня хранилище данных - на SQL2005 OLTP-системы - на SQL2000 В данный моент пишу скрипт (хранимую процедуру) по наполнению хранилища (далее планируется ежедневный запуск этой процедуры ночью по расписанию) При этом возник вопрос: как бы лучше и куда сбрасывать уведомления о процессе выполнения процедуры, при этом чтобы этот лог можно было смотреть в период, пока процедура ещё выполняется. что прошло: - сколько новых записей было добавлено в какую таблицу - сколь записей было обновлено в тех таблицах, где не предусматривается SCD2 что не прошло: - в какую таблицу хранилища какие записи не удалось вставить из соотв. OLTP-источника Пока что есть два варианта: 1. Создать специальную таблицу(ы) на сервере, в которую писать время, имя обработанной таблицы, сколь записей добавилось, сколь обновлено, идентификаторы записи, которые не импортировались и др. 2. Каким-то образом непосредственно из хранимки писать инфу в текстовый файл (а вот как сразу-то и не соображу)......да и чё-то в.1 предпочтительнее ИМХО :-) Но мож, кто чего присоветуетЪ ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.06.2006, 20:22 |
|
||
|
Кто как осуществляет логгирование ETL-процесса?
|
|||
|---|---|---|---|
|
#18+
P.S. да и ещё забыл, а кто как организует процесс импорта, если хочется НЕ прерывать процесс загрузки, в том случае когда по какой-либо причине хоть одна (или несколько) записей не импортируются? т.е. дилемма: 1. либо прерывается весь процесс загрузки 2. либо импортируются только успешные записи (а с выбраковыннами :-) записи разбираемся позже), чтобы пользователи хоть что-то могли видеть новые данные за прошедший день, а не голосил: "Где свежие данные?" (хотя в этом плане вопрос риторический) Ну мож кто на киакие размышления наведёт? спасибо ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.06.2006, 20:58 |
|
||
|
Кто как осуществляет логгирование ETL-процесса?
|
|||
|---|---|---|---|
|
#18+
Я бы всех начинающих BI-щиков садил на год за какой-нибудь промышленный ETL, дабы не изобретали велосипедов. :) Скачайте SOLONDE например - триал и ключ выдают без задержек. Посмотрите, как сделано. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.06.2006, 23:14 |
|
||
|
Кто как осуществляет логгирование ETL-процесса?
|
|||
|---|---|---|---|
|
#18+
токо с "мейл.ру" в SOLONDE не пишите А то "задержка" будет до конца света... )) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.06.2006, 14:47 |
|
||
|
Кто как осуществляет логгирование ETL-процесса?
|
|||
|---|---|---|---|
|
#18+
Если не все записи импортируются - значит ошибочно написана процедура. Нужно просто предусмотреть все условия (жёсткие условия) отбора свежих данных. Тогда никаких ошибок не будет. Если в Вашей ситуации это не возможно, значит изначально нужно привести в порядок данные в OLTP. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.06.2006, 16:56 |
|
||
|
Кто как осуществляет логгирование ETL-процесса?
|
|||
|---|---|---|---|
|
#18+
То: -=MIX=- Жёсткости я в процедуры натолкаю, что называется мама-не-горюй. Я вот что имел ввиду - имеется цепочка: страна->регион->город->компания->договор->объекты->фин.показатели(факты) По первым трём таблицам версионность не ведём (т.к. не суть важно), а вот далее - да - это так, кстати, для полноты картины. Предположим, при очередной загрузке из OLTP-системы проваливается Insert на 4-ой таблице (скажем, сработал check-констрэйнт для некоторог поля таблицы компаний). Возможны решения: 1. процедура загрузки прекращается, а администратор оповещается, что в OLTP-системе срочно надо разобраться с такой-то записью (записями) 2. Не прошедшие проверку на добавление новые компании - выбраковываются, но остальны добавляются, соотвественно и все нижлежащие по цепочке записи добавляются. При этом пользователи видят хотя бы что-то загруженное из новых данных за прошлый день. Однако при этом есть некая вероятность что имеено от выбракованных новых компаний поступили договора, по котором очень дорогие по стоимости объекты ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.06.2006, 17:24 |
|
||
|
Кто как осуществляет логгирование ETL-процесса?
|
|||
|---|---|---|---|
|
#18+
superbluesmanТо: -=MIX=- Жёсткости я в процедуры натолкаю, что называется мама-не-горюй. Я вот что имел ввиду - имеется цепочка: страна->регион->город->компания->договор->объекты->фин.показатели(факты) По первым трём таблицам версионность не ведём (т.к. не суть важно), а вот далее - да - это так, кстати, для полноты картины. Предположим, при очередной загрузке из OLTP-системы проваливается Insert на 4-ой таблице (скажем, сработал check-констрэйнт для некоторог поля таблицы компаний). Возможны решения: 1. процедура загрузки прекращается, а администратор оповещается, что в OLTP-системе срочно надо разобраться с такой-то записью (записями) 2. Не прошедшие проверку на добавление новые компании - выбраковываются, но остальны добавляются, соотвественно и все нижлежащие по цепочке записи добавляются. При этом пользователи видят хотя бы что-то загруженное из новых данных за прошлый день. Однако при этом есть некая вероятность что имеено от выбракованных новых компаний поступили договора, по котором очень дорогие по стоимости объекты Как один из вариантов решения проблемы можно рассматривать следующее: Разделить все ошибки на группы - например: критические, средние, незначительные. При возникновении критических ошибок - откат (например вытирание всех записей текущей загрузки) При возникновении менее серьезных ошибок - ручная корректировка, например. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.06.2006, 09:52 |
|
||
|
Кто как осуществляет логгирование ETL-процесса?
|
|||
|---|---|---|---|
|
#18+
To inga: согласен с Вами, да я тоже пришёл к такой мысли думаю как лучше это организовать. Прежде чем добавлять записи в таблицы хранилища, то выполнять ряд проверок: 1) на наличие грубых ошибок в добавляемых данных (нарушение NOT NULL-условия, нарушение ссылочной целостности и т.п.), т.е. IF EXISTS().... RETURN - если такое случилось, то процесс загрузки прекращается и администратору направляется срочное уведомление и он должен кака можно быстрее разобраться и устранить проблему 2) неправильные значения в добавляемых данных (вроде отрицательной тарифной ставки,...) - если такое случается, то такие записи откладываются в сторону (например, в специальную лог-таблицу сбрасываются значения их ключевых полей), а успешно прошедшие проверку записи добавляются в хранилище. Администратору направляется уведомление, и он может позже разобраться с проблемой. Чтобы обеспечить п.2, то похоже, не всегда удастся по определению или по соображениям производительности обходиться только SELECT-конструкциями, а прибегать к курсорам. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.06.2006, 10:34 |
|
||
|
Кто как осуществляет логгирование ETL-процесса?
|
|||
|---|---|---|---|
|
#18+
[quote] Чтобы обеспечить п.2, то похоже, не всегда удастся по определению или по соображениям производительности обходиться только SELECT-конструкциями, а прибегать к курсорам. [/quote] Не обязательно - можно осуществлять проверки в INSERT - SELECT конструкции (проверка not null, join c таблицами измерений), а потом все записи не попавшие в хранилище скидывать в специальную log таблицу с оповещением администратора. Владимир ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.06.2006, 11:03 |
|
||
|
|

start [/forum/topic.php?fid=49&msg=33801120&tid=1869979]: |
0ms |
get settings: |
5ms |
get forum list: |
8ms |
check forum access: |
2ms |
check topic access: |
2ms |
track hit: |
25ms |
get topic data: |
5ms |
get forum data: |
1ms |
get page messages: |
24ms |
get tp. blocked users: |
1ms |
| others: | 215ms |
| total: | 288ms |

| 0 / 0 |
