З 1999 года для абслугоўвання бэк-офіса ў нашым банку выкарыстоўваецца інтэграваная банкаўская сістэма БІСКВІТ на платформе Progress OpenEdge, якая дастаткова шырока выкарыстоўваецца ва ўсім свеце, у тым ліку і ў фінансавым сектары. Прадукцыйнасць дадзенай СКБД дазваляе чытаць да мільёна і больш запісаў у секунду ў адной базе базы даных (БД). У нас Progress OpenEdge абслугоўвае каля 1,5 млн дэпазітаў фізічных асоб і каля 22,2 дагавораў па актыўных прадуктах (аўтакрэдыты і іпатэка), а таксама адказвае за ўсе разлікі з рэгулятарам (ЦБ) і SWIFT.
Выкарыстоўваючы Progress OpenEdge, мы сутыкнуліся з тым, што нам неабходна пасябраваць яе з СКБД Oracle. Першапачаткова гэты звязак быў «бутэлькавым горлышкам» нашай інфраструктуры – да таго часу, пакуль мы не ўсталявалі і не наладзілі Pro2 CDC – прадукт Progress, які дазваляе адпраўляць дадзеныя з СКБД Progress у СКБД Oracle напрамую, у анлайн-рэжыме. У гэтым пасце мы падрабязна, са ўсімі падводнымі камянямі распавядзем, як эфектыўна пасябраваць OpenEdge і Oracle.
Як усё было: заліванне дадзеных у КХД праз файлавы абмен
Для пачатку крыху фактаў аб нашай інфраструктуры. Колькасць актыўных карыстальнікаў базы складае прыкладна 15 тысяч. Аб'ём усіх прадуктыўных баз дадзеных, уключаючы рэпліку і стэндбай, – 600 TB, самая буйная БД – 16,5 TB. Пры гэтым базы ўвесь час папаўняюцца: толькі за апошні год дадалося каля 120 TB прадуктыўных дадзеных. Працу сістэмы забяспечваюць 150 фронт-сервераў на платформе x86. БД размяшчаюцца на 21 серверы платформы IBM.
Фронт-сістэмы, розныя АБС і банкаўскія сэрвісы інтэгруюцца з OpenEdge Progress (ІБС БІСКВІТ) праз шыну Sonic ESB. Выгрузка дадзеных у КХД адбываецца праз файлавы абмен. Такое рашэнне да вызначанага моманту часу мела адразу дзве вялікія праблемы – нізкую прадукцыйнасць выгрузкі інфармацыі ў карпаратыўнае сховішча дадзеных (КХД) і працяглы час выканання зверкі дадзеных (рэкансіляцыі) з іншымі сістэмамі.
Таму мы пачалі шукаць інструмэнт, які мог бы гэтыя працэсы паскорыць. Рашэннем абедзвюх праблем як раз і стаў новы прадукт Progress OpenEdge - Pro2 CDC (Change Data Capture). Такім чынам, пачнем.
Усталёўваны Progress OpenEdge і Pro2Oracle
Для працы Pro2 Oracle на Windows-кампутары адміністратара досыць усталяваць Progress OpenEdge Developer Kit Classroom Edition, які можна бясплатна. Інсталяцыйныя каталогі OpenEdge па змаўчанні:
DLC: C:ProgressOpenEdge
WRK: C:OpenEdgeWRK
Для ETL-працэсаў неабходныя ліцэнзіі Progress OpenEdge версіі 11.7/4 + – а менавіта OE DataServer for Oracle і 2GL Development System. У камплект пастаўкі ProXNUMX гэтыя ліцэнзіі ўваходзяць. Для паўнавартаснай працы DataServer for Oracle з выдаленай базай дадзеных Oracle усталёўваецца Full Oracle Client.
На серверы Oracle трэба ўсталяваць версію Oracle Database 12+, стварыць пустую базу дадзеных і дадаць карыстальніка (назавём яго CDC).
Для ўсталёўкі Pro2Oracle спампоўваем свежы дыстрыбутыў з цэнтра загрузкі. Распакоўваем архіў у каталог C:Pro2 (для налады Pro2 у Unix выкарыстоўваецца той жа самы дыстрыбутыў і ўжываюцца такія ж прынцыпы налады).
Стварэнне рэплікацыйнай базы даных cdc
Рэплікацыйная база дадзеных cdc (repl) выкарыстоўваецца Pro2 для захоўвання канфігурацыйнай інфармацыі, у тым ліку рэплікацыйнай карты, назваў рэплікаваных баз дадзеных і іх табліц. Тут таксама змяшчаецца рэплікацыйная чарга, якая складаецца з нататак аб факце змены радка табліцы ў зыходнай базе дадзеных. Дадзеныя з рэплікацыйнай чаргі выкарыстоўваюцца ETL-працэсамі для ідэнтыфікацыі радкоў, якія неабходна скапіяваць у Oracle з зыходнай базы дадзеных.
Ствараем асобную базу cdc.
Парадак дзеянняў для стварэння базы
- На серверы баз дадзеных ствараем каталог для бд cdc - напрыклад, на серверы /database/cdc/.
- Ствараем пустышку для базы cdc: procopy $DLC/empty cdc
- Уключаем падтрымку вялікіх файлаў: proutil cdc -C EnableLargeFiles
- Падрыхтоўваем скрыпт старту базы дадзеных CDC. Параметры старту павінны быць аналагічныя параметрам старту базы дадзеных, якая рэплікуецца.
- Выконваем старт базы даных cdc.
- Падлучаемся да базы дадзеных cdc і загружаны схему Pro2 з файла cdc.df, Якая ўваходзіць у камплект пастаўкі Pro2.
- У базе дадзеных cdc ствараем наступных карыстальнікаў:
pro2adm - для падлучэння з адміністрацыйнай панэлі Pro2;
pro2etl - для падлучэння ETL-працэсаў (ReplBatch);
pro2cdc - для падлучэння CDC-працэсаў (CDCBatch);
Актывацыя OpenEdge Change Data Capture
Цяпер зоймемся уключэннем самага механізму CDC, з дапамогай якога дадзеныя будуць рэпліцыравацца ў дадатковую тэхналагічную вобласць. У кожную зыходную базу дадзеных Progress OpenEdge неабходна дадаць асобныя вобласці захоўвання, у якія будуць дублявацца зыходныя дадзеныя, і актываваць сам механізм з дапамогай каманды proutil.
Парадак дзеянняў на прыкладзе для базы даных bisquit
- Капіяваны з каталога C:Pro2db файл cdcadd.st у каталог зыходнай базы дадзеных bisquit.
- Апісваем у cdcadd.st экстэнты фіксаванага памеру для абласцей "ReplCDCArea" и "ReplCDCArea_IDX". Дадаваць новыя вобласці захоўвання можна ў анлайне: prostrct addonline bisquit cdcadd.st
- Актывуем OpenEdge CDC:
proutil bisquit -C enablecdc area "ReplCDCArea" indexarea "ReplCDCArea_IDX" - У зыходнай базе дадзеных неабходна стварыць наступных карыстальнікаў для ідэнтыфікацыі працуючых працэсаў:
a. pro2adm - для падлучэння з адміністрацыйнай панэлі Pro2.
b. pro2etl - для падлучэння ETL-працэсаў (ReplBatch).
c. pro2cdc - для падлучэння CDC-працэсаў (CDCBatch).
Стварэнне Schema Holder для DataServer for Oracle
Далей нам неабходна на серверы, дзе будуць рэпліцыравацца дадзеныя з СКБД Progress у СКБД Oracle, стварыць базу Sсhema Holder. DataServer Sсhema Holder - гэта пустая база дадзеных Progress OpenEdge без карыстачоў або прыкладных дадзеных, утрымоўвальная карту адпаведнікаў зыходных табліц і вонкавых, араклавых табліц.
База Schema Holder для Progress OpenEdge DataServer для Oracle для Pro2 павінна размяшчацца на серверы ETL-працэсаў, яна ствараецца асобна для кожнага філіяла.
Як стварыць Schema Holder
- Які распакоўваецца дыстрыбутыў Pro2 у каталог /pro2
- Ствараем і пераходзім у каталог /pro2/dbsh
- Ствараем базу дадзеных Schema Holder з дапамогай каманды procopy $DLC/empty bisquitsh
- Выконваем канвертаванне bisquitsh у неабходную кадоўку — напрыклад у UTF-8 калі базы дадзеных Oracle маюць кадоўку UTF-8: proutil bisquitsh -C convchar convert UTF-8
- Пасля стварэння пусты базы дадзеных bisquitsh падлучаемся да яе ў аднакарыстальніцкім рэжыме: pro bisquitsh
- Пераходзім у Data Dictionary: Tools -> Data Dictionary -> DataServer -> ORACLE Utilities -> Create DataServer Schema
- Запускаем Schema Holder
- Наладжваем брокера Oracle DataServer:
a. Старт AdminServer.
proadsv -start
b. Старт брокера Oracle DataServer
oraman -name orabroker1 -start
Наладжваем адміністрацыйную панэль і рэплікацыйную схему
З дапамогай адміністрацыйнай панэлі Pro2 канфігуруюцца параметры Pro2, уключаючы настройку рэплікацыйнай схемы і генерацыю праграм ETL-працэсаў (Processor Library), праграмы першаснай сінхранізацыі (Bulk-Copy Processor), рэплікацыйныя трыгеры і палітыкі OpenEdge CDC. Тут таксама ёсць першасныя сродкі маніторынгу і кіравання ETL-і CDC-працэсамі. Перш за ўсё наладжваем файлы параметраў.
Як наладзіць файлы параметраў
- Пераходзім у каталог C:Pro2bpreplScripts
- Адкрываем на рэдагаванне файл replProc.pf
- Дадаем параметры падлучэння да рэплікацыйнай базы дадзеных cdc:
# Replication Database
-db cdc -ld repl -H <імя хаста асноўных БД> -S <порт брокера БД cdc>
-U pro2admin -P <пароль> - Дадамо ў replProc.pf параметры падлучэння да зыходных баз дадзеных і Schema Holder у выглядзе файлаў параметраў. Назва файла параметраў павінна адпавядаць назве падключанай зыходнай базы дадзеных.
# Connect to all replicated source BISQUIT
-pf bpreplscriptsbisquit.pf - Дадамо ў replProc.pf параметры падлучэння да Sсhema Holder.
#Target Pro DB Schema Holder
-db bisquitsh -ld bisquitsh
-H <імя хаста ETL-працэсаў>
-S <порт брокера biskuitsh>
-db bisquitsql
-ld bisquitsql
-dt ORACLE
-S 5162 -H <імя хаста брокера Oracle>
-DataService orabroker1 - Захоўваем файл параметраў replProc.pf
- Далей трэба стварыць і адкрыць на рэдагаванне файлы параметраў для кожнай падключанай зыходнай базы дадзеных у каталогу C:Pro2bpreplScripts: bisquit.pf. У кожным pf-файле прапісваюцца параметры падлучэння да адпаведнай базы дадзеных, напрыклад:
-db bisquit -ld bisquit -H <імя хаста> -S <порт брокера>
-U pro2admin -P <пароль>
Для настройкі цэтлікаў Windows трэба перайсці ў каталог C:Pro2bpreplScripts і адрэдагаваць ярлык "Pro2 - Administration". Для гэтага адкрыем уласцівасці ярлыка і ў радку Пачніце ў пакажам інсталяцыйны каталог Pro2. Аналагічную аперацыю трэба зрабіць для цэтлікаў "Pro2 – Editor" і "RunBulkLoader".
Настройка Pro2 Administration: загрузка першаснай канфігурацыі
Запускаем кансоль.
Пераходзім у "DB Map".
Каб звязаць базы дадзеных у Pro2 - Administration, пераходзім на ўкладку DB Map. Дадаем мапінг зыходных баз дадзеных - Schema Holder - Oracle.
Пераходзім на ўкладку Карт. У спісе Зыходная база даных па змаўчанні абрана першая падлучаная зыходная база дадзеных. Справа ад спісу павінен быць надпіс All Databases Connected - Выбраныя базы падлучаныя. Ніжэй злева павінен быць бачны спіс табліц Progress з bisquit. Справа - спіс табліц з базы Oracle.
Ствараем SQL-схемы і базы дадзеных у Oracle
Для стварэння рэплікацыйнай карты трэба спачатку згенераваць SQL-схему у Oracle. У Pro2 Administration выконваем пункт меню Tools -> Generate Code -> Target Schema, затым у дыялогавым акне Абярыце База дадзеных вылучаем адну ці некалькі зыходных баз дадзеных і пераносім іх направа.
Націскаем OK і выбіраемы каталог для захавання SQL-схем.
Далей ствараем базу. Гэта можна зрабіць, напрыклад, праз Распрацоўшчык Oracle SQL. Для гэтага падлучаемся да араклавай базы і загружаем схему для дадання табліц. Пасля змены складу табліц Oracle трэба абнавіць SQL-схемы ў Schema Holder.
Пасля паспяховага завяршэння загрузкі выходзім з БД bisquitsh і адчыняны адміністрацыйную панэль Pro2. На ўкладцы Mapping справа павінны з'явіцца табліцы з базы Oracle.
Мапінг табліц
Для стварэння рэплікацыйнай карты ў адміністрацыйнай панэлі Pro2 ідзем на ўкладку Mapping, выбіраемы зыходную базу дадзеных. Клікаем па Map Tables, вылучаем злева Select Changes табліцы, якія павінны рэпліцыравацца ў Oracle, пераносім іх направа і пацвярджаем выбар. Для выбраных табліц карта будзе створана аўтаматычна. Паўтараем аперацыю для стварэння рэплікацыйнай карты для іншых зыходных БД.
Генерацыя бібліятэкі працэсара рэплікацыі Pro2 і праграм працэсара масавай загрузкі (Bulk-Copy)
Бібліятэка працэсара рэплікацыі (Processor Library) прызначаная для адмысловых рэплікацыйных працэсаў (ETL), якія апрацоўваюць рэплікацыйную чаргу Pro2 і перадаюць змены ў базу дадзеных Oracle. Праграмы бібліятэкі працэсара рэплікацыі пасля генерацыі аўтаматычна захоўваюцца ў каталог bprepl/repl_proc (параметр PROC_DIRECTORY). Для генерацыі бібліятэкі працэсара рэплікацыі ідзем у Tools -> Generate Code -> Processor Library. Пасля завяршэння генерацыі праграмы з'явяцца ў каталогу bprepl/repl_proc.
Праграмы працэсара масавай загрузкі прымяняюцца для сінхранізацыі зыходных баз дадзеных Progress з мэтавай базай дадзеных Oracle на аснове мовы праграмавання Progress ABL (4GL). Для іх генерацыі ідзем у пункт меню Tools -> Generate Code -> Bulk-Copy Processor. У дыялогавым акне Select Database вылучаем зыходныя БД, пераносім у правую частку акна і ціснем OK. Пасля завяршэння генерацыі праграмы з'явяцца ў каталогу bpreplrepl_mproc.
Наладжваем рэплікацыйныя працэсы ў Pro2
Падзел табліц на наборы, якія абслугоўваюцца асобным струменем рэплікацыі, дазваляе палепшыць прадукцыйнасць і эфектыўнасць працы Pro2 Oracle. Па змаўчанні ўсе сувязі, якія ствараюцца ў рэплікацыйнай карце, для новых рэплікацыйных табліц прывязваюцца да патоку з нумарам 1. Рэкамендуецца падзяляць табліцы на розныя патокі.
Інфармацыя аб стане рэплікацыйных патокаў адлюстроўваецца на экране Pro2 Administration ва ўкладцы Monitor у секцыі Replication Status. Падрабязнае апісанне значэнняў параметраў можна знайсці ў дакументацыі Pro2 (каталог C: Pro2Docs).
Ствараем і актывуем палітыкі CDC
Палітыкі - гэта набор правілаў для механізму OpenEdge CDC, паводле якіх выконваецца адсочванне змен у табліцах. На момант напісання паста Pro2 падтрымлівае толькі палітыкі CDC з узроўнем 0, гэта значыць адсочваецца толькі факт змены запісу.
Для стварэння палітыкі CDC на адміністрацыйнай панэлі пераходзім на ўкладку Mapping, выбіраемы зыходную базу дадзеных і пстрыкаем па кнопцы Add/Remove Policies. У якое адкрылася акне Select Changes выбіраемы ў левай частцы і пераносім у правую табліцы, для якіх неабходна стварыць або выдаліць палітыку CDC.
Для актывацыі зноў адчыняны ўкладку Mapping, выбіраемы зыходную базу дадзеных і клікаем па кнопцы (In)Activate Policies. Вылучаем і пераносім у правую частку табліцы, палітыкі якіх неабходна актываваць, ціснем OK. Пасля гэтага яны адзначаюцца зялёным колерам. З дапамогай (In)Activate Policies таксама можна дэактываваць палітыкі CDC. Усе аперацыі выконваюцца анлайн.
Пасля актывацыі палітыкі CDC нататкі аб змененых запісах захоўваюцца ў вобласць захоўвання "ReplCDCArea" у адпаведнасці з зыходнай базай дадзеных. Гэтыя нататкі будуць апрацоўвацца спецыяльным працэсам CDCBatch, які на іх аснове будзе ствараць нататкі ў рэплікацыйнай чарзе Pro2 у базе дадзеных cdc (repl).
Такім чынам, на рэплікацыю ў нас утвараюцца дзве чаргі. Першая чарга - CDCBatch: з зыходнай базы дадзеныя спачатку трапляюць у прамежкавую базу CDC. Другая чарга - калі з базы CDC дадзеныя пераліваюцца ўжо ў Oracle. Гэта асаблівасць бягучай архітэктуры і самога прадукта - пакуль распрацоўшчыкі не змаглі наладзіць прамую рэплікацыю.
Першасная сінхранізацыя
Пасля ўключэння механізму CDC і налады сервера рэплікацыі Pro2 нам неабходна запусціць першасную сінхранізацыю. Каманда запуску першаснай сінхранізацыі:
/pro2/bprepl/Script/replLoad.sh bisquit table-name
Пасля завяршэння першаснай сінхранізацыі, можна запускаць рэплікацыйныя працэсы.
Старт рэплікацыйных працэсаў
Для запуску рэплікацыйных працэсаў трэба выканаць скрыпт replbatch.sh. Перад стартам - пераканацца ў наяўнасці скрыптоў replbatch для ўсіх патокаў - replbatch1, replbatch2 і г.д. Калі ўсё на месцы, адкрываем камандны радок (напрыклад, proenv), пераходзім у каталог /bprepl/scripts і выконваем старт скрыпту. У адміністрацыйнай панэлі правяраем, што які адпавядае працэс атрымаў статут RUNNING.
Вынікі
Пасля ўкаранення ў нас моцна паскорылася выгрузка інфармацыі ў карпаратыўнае сховішча дадзеных. Дадзеныя самастойна трапляюць у Oracle у рэжыме анлайн. Не трэба марнаваць час на выкананне нейкіх доўгайграючых запытаў для збору дадзеных з розных сістэм. Да таго ж у гэтым рашэнні працэс рэплікацыі ўмее сціскаць дадзеныя, што таксама дадатна адбіваецца на хуткасці. Цяпер штодзённая зверка сістэмы БІСКВІТ з іншымі сістэмамі стала займаць 15-20 хвілін замест 2-2,5 гадзін, а поўная зверка - некалькі гадзін замест двух сутак.
Крыніца: habr.com