Калі вы разглядаеце магчымасць пераходу на IBM Cognos Analytics у воблаку, хочаце выкарыстоўваць драйверы JDBC замест уласнага кліента базы дадзеных або проста хочаце большага бачання характарыстык запытаў, звязаных з прадукцыйнасцю, прыняцце рэжыму дынамічнага запыту-выдатная ідэя.
Калі група прадукцыйнасці прадуктаў харчавання, адзін з самых надзейных лідэраў галіны харчовых паслуг, нядаўна перайшла з Cognos 10.2.1 на 11.0.12 у рамках працэсу пастаяннага ўдасканалення, яны вырашылі абнавіць свае пакеты з CQM да DQM. Суміт Кумар, ІТ -менеджэр PFG, адказны за нагляд за справаздачнасцю, аналізам і кансультаваннямі, адказваў за міграцыю пакетаў і меў задачу пераадолець усе праблемы, з якімі яны могуць сутыкнуцца падчас гэтага працэсу.
Перавагі пераўтварэння з CQM у DQM
Прычын міграцыі Performance Food Group было мноства. Адным з галоўных пераваг канвертавання для Sumit і PFG у цэлым была магчымасць выкарыстоўваць справаздачы, якія змяшчаюць дадзеныя з некалькіх пакетаў у гэтым жа справаздачы. Рэжым дынамічнага запыту дазволіў бы Sumit выкарыстоўваць справаздачы, якія змяшчаюць дадзеныя з розных тэматычных абласцей, такіх як продажу, закупкі і інвентар, нават калі яны знаходзяцца ў трох абсалютна розных пакетах. Сумяшчальны рэжым запытаў не мае такой магчымасці, таму выбар быў відавочны.
Пераўтварэнне з сумяшчальнага рэжыму запыту ў рэжым дынамічнага запыту таксама дазволіла б ім значна скараціць час выканання справаздачы, выкарыстоўваючы выкананне запыту на 64-разраднай архітэктуры. Перайшоўшы, Sumit зразумеў, што яны не толькі ствараюць інфраструктуру, каб палегчыць будучыя мадэрнізацыі, але і даюць Performance Food Group магчымасць запускаць прагнастычную аналітыку ў іх аўтаматызацыі.
Перавагі пераўтварэння былі відавочныя, але якія праблемы чакалі наперадзе?
Выбраўшы 13 пакетаў Cognos для пераўтварэння, Суміт сутыкнуўся са сваімі першымі перашкодамі на этапе планавання і выканання праекта.
Задачы планавання і выканання праекта
Першы roadБлок Sumit, з якім сутыкнуўся, быў выбар паміж вадаспадам або спрытнай дастаўкай. Sumit абраў апошняе для пераўтварэння CQM у DQM, таму што гэта дазволіла яму разгортваць кожны пакет незалежна адзін ад аднаго. Пакеты былі разгорнутыя, калі ўсе важныя справаздачы паспяхова выконваліся, і калі ў некаторых справаздачах з нізкім прыярытэтам былі памылкі, яны ўсё роўна разгортвалі пакет і пазней выпраўлялі справаздачы. Гэта дазволіла ім прадэманстраваць каштоўнасць бізнесу загадзя, не губляючы часу, але каб перастрахавацца, яны захавалі месячны буфер на выпадак, калі ім спатрэбіцца дадатковая дапамога ад групы падтрымкі прадуктаў IBM.
Цяпер, калі Sumit and Performance Food Group пераадолелі фазу планавання і выканання праекта, прыйшоў час ім вырашыць наступнае пытанне: тэхнічныя і інфраструктурныя праблемы, абумоўленыя паводзінамі пакетаў у рэжыме дынамічнага запыту.
«Паводле Суміта, пераход з CQM на DQM быў выдаткаваны час і намаганні. Пасля пераўтварэння час выканання справаздачы ў сярэднім скараціўся на 60%! »
Тэхнічныя і інфраструктурныя праблемы
Рэжым дынамічнага запыту прымяняе лепшыя практыкі, якія былі неабавязковымі ў сумяшчальным рэжыме запытаў. Прыкладам гэтага можа служыць злучок і зорачка з касой рыскай наперад у якасці каментаванага радка, напрыклад, '-' супраць '/*'. CQM прымае ўсё гэта, тады як DQM часам прымае гэта, а часам не, у залежнасці ад размяшчэння. Гэтыя, здавалася б, невялікія праблемы могуць выклікаць спарадычныя памылкі ці нават цэлыя справаздачы. Камэнтары ў пашыраных фільтрах, запыты SQL і карыстальніцкія вылічэнні таксама выклікалі памылкі. А Параўнайце запыт sql інструмент быў разгледжаны для фарматавання размяшчэння і памяншэння колькасці памылак з гэтай вобласці, але расследаванне пайшло далей, каб убачыць усе выпадкі памылак. Уключэнне функцыі сумы ў мадэль дадзеных або вызначэнне пакета таксама выклікала памылкі, але гэта можна выправіць, замяніўшы яе на функцыю total, або Sum () супраць Total ().
Рэжым дынамічнага запыту таксама робіць пэўныя здагадкі, што Сумяшчальны рэжым запытаў не робіць, у выніку чаго вынікі справаздачы адрозніваюцца. Запуск справаздач у CQM супраць DQM можа даць вам розныя вынікі выключна ў залежнасці ад таго, як яны інтэрпрэтуюць функцыю. Напрыклад, Total (Total (Sales)) у CQM дасць вам вынік, які эквівалентны агульнаму аб'ёму продажаў і ігнаруе дублікат агульнага аб'ёму, тады як у DQM ён не ігнаруе дублікат вынікаў, даючы вам іншы вывад справаздачы. Сапраўды гэтак жа адрозніваецца спосаб рэалізацыі параметраў агрэгавання ў CQM супраць DQM. Фільтры на слупках "Вылічаныя/сукупныя" могуць прыводзіць да розных вынікаў у залежнасці ад выбару ўласцівасці сукупнасці, напрыклад "Да агрэгавання" або "Пасля агрэгавання".
Іншыя выклікі
У рэжыме дынамічнага запыту можа прымяняцца іншы парадак дзеянняў, які можа выклікаць змены ў вывадзе справаздачы.
- Вызначэнне магутнасці ўзроўню справаздачы прыводзіць да зменаў у выніках справаздачы.
- Праверка справаздачы можа па -ранейшаму паказваць крытычныя памылкі нават пасля таго, як папярэджанні будуць вырашаны. Усе папераджальныя паведамленні павінны быць выпраўлены, перш чым кампілятар справаздачы зможа паказаць фактычную памылку. Калі справаздача не працуе і паказвае толькі папярэджанне, вы павінны спачатку выправіць папярэджанне, перш чым справаздача выявіць крытычную памылку і дазволіць яе выправіць.
- Афармленне справаздач з велізарнымі аб'ёмамі дадзеных можа не справіцца з праблемамі "Java out of memory", але іх можна выправіць, адключыўшы ўласцівасць лакальнага кэшавання ва ўласцівасцях справаздач для гэтых справаздач, а таксама можна дапамагчы, павялічыўшы наладжаную памяць для службы запытаў
- Каб прадухіліць праблемы ў будучыні, канфігурацыю JVM неабходна дапрацаваць у адпаведнасці з лепшымі практыкамі.
У Заключэннi
Па словах Суміта, міграцыйны працэс быў выдаткаваны вельмі шмат часу і намаганняў. Пасля пераўтварэння час выканання справаздачы ў сярэднім скараціўся на 60%! Ён вызначана рэкамендуе канвертаваць пакеты з CQM у DQM і ваша асяроддзе з 32-разраднага ў 64-разраднае.
Разглядаеце магчымасць пераходу з сумяшчальнага рэжыму запыту ў рэжым дынамічнага запыту або нядаўна ператворанага? Мы хацелі б, каб вы падзяліліся з намі сваім вопытам або якімі -небудзь падказкамі і хітрасцямі!
Хочаце даведацца больш? Мы прымалі а вебинар дзе мы абмяркоўвалі праблемы, з якімі сутыкаецца група прадукцыйнасці пры іх пераходзе ў рэжым дынамічнага запыту. Адкажыце на вебинар, націснуўшы тут.
