SAP for Banking: Рост объема хранилища

SAP  Нижний уровень - уровень ABAP. Представим, что данные предварительно грузятся не в само хранилище, а в набор таблиц на нижнем уровне системы, ABAP самописный слой.  Данные грузятся из различных источников, размечаются, приводятся к единым нотациям.  И уже на этих данных сверху надстроены экстракторы для выгрузки в BW. Приведу небольшую табличку соответствия типов ABAP словаря и БД Oracle:

Как видно - типы для хранения числовых величин достаточно компактны. Все sid и dim в кубах построены на основе INT4. Занимает мало места и работает быстро.
Кроме типа numeric - это по сути строка.

Теперь обратим внимание на строки. Здесь ситуация грустная.  Для хранения строки с фиксированной длиной необходимо отвести места в 3 раза больше её максимальной длины. Это связано с кодированием данных SAP под unicode, где, по стандарту они могут занимать 2-4 байта ни символ.  К примеру, если назначение платежа в документе может быть максимум 180 символов, то в таблице необходимо зарезервировать 540 байт. А реально будет использоваться где-то 25-50% места, т.к. назначение платежа обычно намного короче.

Если же использовать тип STRING с переменной длиной, то в oracle они преобразуется в CLOB, который не позволяет удобно работать в SQL с этими данными. Эти строки выделены в таблице жирным шрифтом. Чтобы анализировать содержимое, необходимо полностью извлекать объект в программу и там уже работать с ним.   Всё описанное - больше неудобство, чем проблема, но всё же.

Загружаем данные

Записи о неких документах приходят в CSV-файле c разделителем.  И заказчик говорит - у меня 1 Гб таких данных. Сколько дискового места необходимо отвести под загрузку этих данных?

Структура полей самая минимальная:

1. номер документа INT
2. дата datum
3. счет дебета char 20
4. счет кредита char 20
5. назначение платежа char 100
6. сумма dec 17.2

Попытаемся примерно посчитать занимаемое место и вывести коэффициент-мультипликатор для начальной загрузки такого типа данных. Подсчет грубый и не будет учитывать журналов, логов и проч. Только ABAP и BW.

Предположим, что в хранилище мы грузим эти документы из таблицы словаря ABAP через экстрактор и PSA в DSO-объект.

Анализируем исходные файлы.  Длина записи, с учетом разделителя может быть в среднем 120 байт, максимальная 180. Итого 1 Гб/120 = 9 милл записей.

Грузим файлы в словарь ABAP.  Каждая запись будет примерно занимать 10 + 30 + 60 + 60 + 300 + 8 = 468 байт, без учета индексов и прочего.

Сделали экстрактор и запись легла в PSA - значит еще 468 байт на запись.

Сделали трансформацию и запись пришла в DSO. Здесь запись будет лежать в журнале и в активных(неактивных данных).

Итого 1*ABAP + 1*PSA + 2*DSO - начальная загрузка потребует учетверения записи в системе. А значит - 4*468 = 1872 байта.  При средней длине записи в CSV-файле в 120 байт значение мультипликатора составит  1872 / 120 = 15,6.

Разумеется, PSA со временем очистится. Журнал DSO можно удалить, на уровне ABAP данные можно не хранить, но всё равно, для загрузки 1 Гб данных в системе должно быть свободно минимум 15,6 Гб в таблспейсах для данных. И,  после всех выверок и очисток избыточных данных, объем хранения можно будет сократить до 3,9 Гб.  Такие мультипликаторы объема возникают из-за специфичности как самого SAP , так и из идеологии БД. Не стоит забывать, что длинные тексты надо резать по 60 символов и ложить в разные инфо-объекты. Это одно из неудобств, но быстро привыкаешь.

В реальных системах  в день может прийти несколько миллионов документов. Вот и посчитайте месячный рост.  Поэтому терабайты - это уже не достижение, а грустная реальность в современных BI-системах.