SAP for Banking: Зберігаємо залишки, Інші СУБД, Бази даних, статті

Ржаксінскій Андрій

sapbanking.org

Перша задача, з якою стикаються при створенні сховища – це отримання балансу. Відповідно, необхідно спроектувати зберігання залишків і оборотів за рахунками.


Отже вступна. Банк з top 100, спеціалізується на роздрібному бізнесі з розгалуженою мережею відділень вирішив впровадити сховище на SAP BW. У банку 20 філій плюс центральний офіс, відкрито 400 тис рахунків, в день проходить 200-400 тис документів (в середньому 300 тис), зачіпаючи 30-70 тисяч рахунків в день (в середньому 50 тис). Обсяги залежать від дня місяця.


Необхідно прийняти рішення про те як зберігати обертів / залишки, щоб виконувалися такі вимоги:
– Швидка швидкість вибірки;
– Грануляція даних до рівня руху по 1 аналітичному рахунку за 1 день;
– Можливість вивірки і швидкого отримання балансу, зміни сальдо по конкретному рахунку;
– Забезпечити швидку роботу BEX.


Рішення SAP Business Objects


Т.к. проектується OLAP система, то питання обсягу зберігання даних стоїть на останньому місці, а швидкість вибірки на самому першому. У той же час, занадто роздуті таблиці будуть сповільнювати вибірку по ним. Для кожного варіанта напишу річний приріст по записах (виходячи з 260 роб. днів) і оцінки продуктивності.


Перше питання – як зберігаємо записи про залишки?
1 варіант – Зберігаємо тільки рахунки, за якими були рухи. Ключі:
ФІЛІЯ
РАХУНОК
ДАТА ОПЕРАЦІЇ


Переваги і недоліки: маленький обсяг зберігання, швидке завантаження, повільна вибірка. При виборі значень за допомогою ABAP необхідно використовувати вибір максимальної дати залишку, меншою або рівною поточної. В BEX – спецагрегацію “останнє значення залишку”. Річний приріст 260 * 50 тис. = 13 міл. записів.


2 варіант – Зберігаємо записи про всі рахунки щодня, навіть якщо залишок не змінювався або нульовий. Ключі:
ФІЛІЯ
РАХУНОК
ДАТА ОПЕРАЦІЇ


SAP Business Objects Переваги і недоліки: великий обсяг зберігання, повільне завантаження, швидка вибірка. Можна зберігати розраховані валютні еквіваленти на кожен день, прибравши тим самим, переоцінку під час роботи з залишками. З часом почнуться проблеми з адмініструванням великої таблиці. Необхідно відразу робити партіціонірованіе на рівні БД і агрегати. Запити виконуються точно по ключу, без операцій з діапазоном дат, що дозволяє швидко вибирати залишки. Але необхідно зберігати щоденні залишки, навіть за вихідні дні, тому що початок чи закінчення звітного періоду може потрапити на неділю. Річний приріст 365 * 400 тис. = 146 міл. записів якщо зберігаються неробочі дні. Або 260 * 400 тис. = 104 міл. записів якщо реалізований механізм коригування дат звіту на робочі дні. Це число може бути ще зменшено, якщо не зберігати нульові залишки, це може знизити обсяг зберігання ще на 30%.


3 варіант – Зберігаємо діапазон дії залишку. Ключі:
ФІЛІЯ
РАХУНОК
ДАТА актуальні залишки З
ДАТА актуальні залишки ПО (не ключ)


Переваги і недоліки: маленький обсяг зберігання, потрібні додаткові ресурси при завантаженні, досить швидка вибірка. Після завантаження залишків необхідно провести перерахунок часового ряду datefrom, dateto. З датою відкриття діапазону “01.01.1000 ‘, закриттям” 31.12.9999 “. При виборі сальдо необхідно обмежувати датою звіту 2-ма тимчасовими кордонами. Цей варіант трохи повільніше 2-го варіанту, але не несе його недоліків Річний приріст маленький, як і в 1-му випадку.


Друге питання – як забезпечити дельти і коректування заднім числом?


Сховище живе окремо від основного опердня. Обсяг дельти може бути як денної, так і 15-хвилинний. Все залежить від необхідності в отриманні оперативних звітів та допустимого запізнювання. Не всі операційні дні можуть забезпечити чітко вивантаження тільки змінених рахунків за останній час. Можливі дублювання одних і тих же рахунків. Також актуальна проблема проводок заднім числом, особливо на початку календарного року.


Якщо дані відразу ложить в куб, то виникне проблема з задвоеніем залишків. Тому тут допоможе ODS об’єкт. За рахунок журналу ми позбавляємося від задвоенія записів. Дані в таблицях ODS зберігаються в надмірному розгорнутому вигляді. Це полегшує налагодження завантаження, дозволяє візуально порівнювати звіти і будувати запити стандартними gui засобами, швидше, ніж через перегляд даних куба. Крім того, у випадку з 3-м варіантом зберігання залишків, можна реалізувати трансформацію ODS -> ODS, для перестроювання тимчасового ряду.


Але ODS сильно кульгає в плані продуктивності. І запити краще будувати на кубі. Тому необхідно реалізувати завантаження ODS-> куб. Причому якщо зробити куб точно таким же, як ODS, внести те-ж інфооб’екти і атрибути навігації, то можна безболісно переносити налагоджені BEX запити з ODS на куб. Єдина можлива проблема – відсутність об’єкта 1rownum в кубі, але це вирішується створенням в системі показника, куди буде присвоюватися константа 1 в ODS і агрегація в кубі дозволить безболісно замінити стандартний 1rownum.


Якщо прийняти 3 варіант зберігання залишку, то має сенс в кубі зробити 2 вимірювання окремо для datefrom і dateto, причому вони повинні бути там єдиними ознаками, що дозволить включити “вимір позицій” у властивостях вимірювань. У куб будуть писатися не dim, а відразу sid значення часу, що позитивно позначиться на продуктивності.


Описаний тут варіант має свої недоліки:
-Збільшений час завантаження і доступності даних для звітів;
-Постійно зростаючий журнал ODS, який необхідно адмініструвати і чистити;


Третє питання – який потенціал для збільшення продуктивності?


Тут складно сказати щось визначене. Необхідно розглядати конкретні ситуації.


Варто звернути увагу на партіціонірованіе таблиці фактів в кубі на рівні БД. Необхідно використовувати стандартне розділення по атрибуту часу.


В ODS можна перевизначити на рівні БД таблиці журналів і активних даних, додавши примусове партіціонірованіе за діапазоном якого-небудь значення.
Але тут можна розраховувати на відчутний приріст тільки якщо фізично дані будуть зберігатися на різних дискових масивах. Зараз практично скрізь використовується єдиний великий RAID, який і так забезпечує розмазування даних по декількох дискам. Тому партіціонірованіе стає просто ще одним індексом. За моїми вимірами навіть така оптимізація додає 5-7% до швидкості витягання даних.


Ще одним способом прискорити вибірки є фізична розбиття даних по декількох кубів і об’єднання їх в мультіпровайдер. Цей шлях має хороший потенціал для оптимізації та експериментів. Крім стандартного розбиття по календарних років / кварталам / місяців можна подумати і розбити, наприклад, за балансовими рахунками.


SAP Business Objects Аналізуючи банківські полупроводкі можна прийти до висновку, що ряд балансових рахунків зустрічаються в кореспонденції найбільш часто. Приміром транзитні рахунки можуть зустрічатися при проводках, вивантажуються із зовнішніх систем, при масових перерахування та разбросках засобів. В окремих випадках руху за такими балансовими рахунками може становити до 30% від загального числа. Це робить неефективним вибірку по балансовими рахунками, наприклад в головному банку і така картина не спостерігається в інших філіях. Якщо розділити такі залишки по різним кубів, зробити сепарацію за балансовими рахунками, то той же Oracle більш якісно збере статистику по таблицях. У підсумку це знову ж таки вплине на загальну продуктивність. Дробити має сенс аж до обмеження даних під групу конкретних звітів.


Але все ж варто розуміти, що любий подібні “поліпшення”, що збільшують швидкість вибірки, разом уповільнюють саму завантаження даних і необхідно шукати компроміси.

Схожі статті:


Сподобалася стаття? Ви можете залишити відгук або підписатися на RSS , щоб автоматично отримувати інформацію про нові статтях.

Коментарів поки що немає.

Ваш отзыв

Поділ на параграфи відбувається автоматично, адреса електронної пошти ніколи не буде опублікований, допустимий HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

*

*