Многоуровневая расширяемая архитектура хранилищ бизнес-информации. LSA и SAP BW. Традиционный подход
C помощью ERP-систем вот уже более 40 лет назад предприятия автоматизируют свои бизнес-процессы. С течением времени, а также с ростом количества и глубины автоматизации бизнес-процессов, объемы данных прирастают большими темпами. Для компаний, работающих в конкурентной среде анализ этой информации и правильные выводы, сделанные на основе анализа, могут принести коммерческий успех: увеличить выручку, сократить издержки, повысить эффективность.
Проблема в том, что с ростом объемов данных анализировать информацию становится все сложнее. Основная проблема – низкая производительность и, зачастую, отсутствие специальных инструментов анализа в ERP-системах. Поэтому, оставаясь на текущей архитектуре ERP-систем, уже не представляется возможным за приемлемое время выполнять анализ данных. Все работает медленно, или с устойчивой тенденцией к замедлению. Даже увеличение вычислительных мощностей серверов ERP-систем иногда спасает только в краткосрочном периоде.
Поэтому около 30 лет назад архитекторы ПО задумались о создании нового класса систем – хранилища данных. Цели внедрения хранилищ данных (ХД) обычно следующие:
- Накопление и хранение данных в структурах, оптимальных для анализа;
- Консолидация данных из нескольких систем;
- Уменьшение вычислительной нагрузки на ERP-системы — поставщики данных;
- Предоставление пользователям возможностей:
- Самостоятельно создавать отчеты по данным ХД с помощью удобных инструментов;
- Использовать возможности анализа data mining, OLAP, которые не применялись ранее.
Сразу стал вопрос, как правильно организовывать данные в хранилище, чтобы оно не только удовлетворяло требованию «структуры, оптимальные для анализа», но и позволяло сделать управляемыми и невысокими затраты ресурсов на развитие и сопровождение. Путем проб и ошибок архитекторы хранилищ данных пришли к архитектуре слоеного пирога, LSA – Layered Scalable Architecture. Причем, как следует из названия, не просто слоеного, но и масштабируемого.
На рисунке LSA представляет собой зеленый блок. Над ним расположены инструменты визуализации данных отчетов, основанные на Excel, браузерах интернет или просто форматы файлов для выгрузки данных ХД. Ниже «зеленого» блока LSA указаны типы систем-поставщиков данных.
С точки зрения реализации, следует сказать, что LSA – это логическое деление структур с данными (в терминах СУБД — таблиц) ХД на несколько уровней, каждый из которых выполняет определенную функцию. Данные копируются с уровня на уровень, трансформируясь в ходе копирования и оказываются в итоге в структурах, оптимальных для анализа (см. цели внедрения хранилища). Каждый уровень — это не один объект, не одна структура и таблица. В 99% случаев на одном уровне много объектов различной структуры.
Как говорилось ранее, данные следует копировать из систем-поставщиков в ХД, чтобы нагрузка при аналитических вычислениях приходилась на ХД – специально оптимизированную для таких задач систему. Архитектурой LSA для временного хранения данных в формате загрузки предусмотрен специальный «уровень загрузки». При загрузке на этот уровень никаких преобразований данных не делается. Выполняется только проверка типов. Например, чтобы в числовое поле не записались буквы, не было «32 августа» и т.п.
После того, как данные на этом уровне сохранены, с т.з. дальнейшей обработки ХД уже «все равно», откуда данные поступили: из файла, ERP-системы или из источника иного типа. Хранение на уровне загрузки с т.з. LSA предполагается временным. Поэтому обычно сразу после успешного выполнения очередной загрузки, данные копируются «выше», трансформируясь по пути, на следующий уровень и т.д. На уровне загрузки обычно рекомендуется хранить данные не более 5 – 10 дней, после чего удалять. Хранить данные более длительный срок, накапливать на этом уровне большие объемы не рационально по соображениям производительности. Ведь при чтении фильтрация по неиндексированным полям таблиц этого уровня может выполняться с большой задержкой.
Однако, существуют сценарии, когда данные в формате «загрузки» могут потребоваться в ХД много позже 5 – 10 дней. Для таких случаев в ХД предусматривают уровень «корпоративной памяти», не показанный на картинке. По структуре, составу полей, каждый объект «Корпоративной памяти» идентичен соответствующему объекту уровня загрузки. Однако данные из корпоративной памяти не удаляются так скоро. Но чтобы и там не накапливать условно «бесконечные» объемы, следует регулярно архивировать данные с этого уровня с возможностью последующего быстрого восстановления по требованию.
На следующем уровне, называемым «уровень хранилища данных» находятся данные в максимально детализированных структурах, которые могут понадобится для потребителей (пользовательских отчетов, др. систем). Важное замечание: только для потребителей согласно заложенным в проект требованиям! Хотя и это не всегда так. Опытный архитектор ХД должен стараться предвосхищать неизвестные на момент обследования и проектирования требования и предусматривать их в модели. Когда клиент о них заявит, они уже (voi la!) будут предусмотрены моделью данных, либо модификация модели не будет трудоемкой.
При загрузке на уровень хранилища могут выполняться следующие операции (список неполный):
- Согласование однородных по смыслу, но различных по кодам справочников значений. Например, пол Ж и F нужно привести к одному значению;
- Расчеты, требующие максимально возможной детализации данных (например, пересчет валют по курсу из позиции документа);
- Проверки на допустимость значений аналитик (сheck constraint);
- Фильтрация.
Крайне желательно соблюдать «изоляцию» при настройке загрузки в объекты этого уровня. Логика преобразований при загрузке одного объекта уровня хранилища не должна зависеть от данных другого объекта этого же уровня. В противном случае придется соблюдать очередность загрузки и в случае усложнения логики преобразований нетрудно оказаться в ситуации «взаимного ожидания» окончания загрузки.
Именно на уровне хранилища данные должны представлять «единую версию правды» (single version of truth). В случае каких-либо вопросов со стороны потребителей к качеству данных следует обращаться на уровень хранилища и проверять там. Чтобы это было так и работало, очень критичными становятся процессы своевременной и технически корректной загрузки данных на этот уровень с выполнением всех проверок и т.п.
Допустим, это все выполнено, и на уровне хранилища данных у нас единая версия правды. Но информация здесь хранится в максимально детализированной структуре, что обычно означает большое количество данных. К тому же, на этом уровне не все требуемые показатели и аналитики рассчитаны и сохранены. Действительно, рассчитывать все требуемые показатели на уровне с максимальной детализацией данных может быть нерационально ввиду большого числа лишних вычислений, либо и вовсе невозможно в принципе, т.к. расчет может потребовать не только предварительной агрегации данных, но и данных других объектов того же уровня. А у других объектов, например, другой регламент обновления….
Поэтому появляется потребность в следующем, уже третьем снизу уровне данных, который бы хранил подмножества данных, адаптированные к потребностям группы пользователей и/или группы отчетов. Это уровень носит название «уровень витрины данных».
На этом уровне, наряду с простой агрегацией (например, уплотнение группе товаров и месяцу отгрузки), выполняется еще и объединение данных с нескольких объектов уровня хранилища данных. В объектах этого уровня сохраняются результаты расчетов показателей и аналитик.
Последний уровень – это виртуальные провайдеры данных и отчеты. Он предназначен для объединения (виртуального, т.е. без хранения) данных из различных объектов как своего уровня, так и уровня «витрин данных». И, наконец, здесь определяются пользовательские отчеты, в которых также обычно заложена логика расчетов показателей.
Цилиндр xDBMS на схеме затрагивает 3 нижних уровня. Он обозначает хранение данных соответствующих уровней в таблицах СУБД. Данные самого верхнего «виртуального» уровня, как следует из схемы, не хранятся в таблицах СУБД, но считываются из него.
И, конечно, торт «Наполеон» на схеме — отличная метафора многослойности. Как и в случае с «Наполеоном», когда количество слоев не задается стандартами, LSA также не является догмой. Концепции LSA лишь предлагают при проектировании модели данных ХД ориентироваться на базовый набор уровней. А остальное решают кондитер архитектор ХД и клиент.
Компания SAP выпустила на рынок продукт класса «Хранилище данных» аж в далеком 1998 году. Это широко известный в мире SAP продукт SAP NetWeaver BW (Business Warehouse или SAP BW). С тех пор SAP BW постоянно совершенствуется, регулярно выходят его новые версии. SAP BW — это не готовое хранилище данных, это инструмент по созданию хранилищ данных. Набор типов объектов, из которых конструируется хранилище данных в SAP BW, как нельзя лучше соответствует уровням LSA: для каждого из них есть рекомендуемый набор типов объектов.
- Для уровня загрузки — это источники данных с PSA-таблицами (persistent stage area),
- Для уровня хранилища данных — это стандартные DSO (Data Store Object)
- Для уровня «корпоративной памяти» — это Write-optimized DSO
- Для уровня «витрин данных» — инфокубы.
- Наконец, для последнего уровня «Виртуальных провайдеров и отчетов» — мультипровайдеры, инфонаборы, виртуальные инфокубы и сами отчеты, созданные в инструменте Bex Query Designer.
Все эти объекты (за исключением отчетов и источников данных) на всех указанных уровнях формируют «модель данных», построенную в SAP BW из т.н. инфообъектов — признаков (другие названия: характеристика, аналитика) и показателей. Инфообъекты в BW — это как кирпичи при строительстве дома. Это с технической точки зрения, а с функциональной — в модели данных SAP BW инфообъекты-признаки реализуют нормативно-справочную информацию.
В SAP BW для копирования данных с уровня на уровень с выполнением преобразований используются объекты типа «трансформация» и «процесс переноса данных». Для регулярного выполнения последовательностей действий по извлечению, преобразованию и загрузки модели данных предусмотрен конструктор «цепочек процессов».
Все версии SAP BW могут использовать в качестве основной реляционные СУБД основных вендоров: Oracle, Microsoft, IBM, SAP/Sybase. «Основной» здесь означает, что все бизнес-данные, метаданные, системная информация сохраняются в таблицах СУБД.
Какая бы ни была выбрана СУБД, для проектирования эффективной модели данных в SAP BW рекомендуются единые правила LSA.
Начиная с 2012 г. SAP BW, помимо упомянутых выше, поддерживает в качестве основной и СУБД SAP HANA. Новые возможности СУБД SAP HANA и одноименной платформы позволили пересмотреть LSA настолько, что для BW on HANA де-факто изменены некоторые ключевые подходы, что отражено в новом названии LSA++. Об изменениях расскажу подробнее в одной из следующих публикаций.
