З 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+ - а саме OE DataServer for Oracle та 4GL Development System. У комплект постачання Pro2 ці ліцензії входять. Для повноцінної роботи 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.
Порядок дій на прикладі для бази даних
- Копіюємо з каталогу 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