База данных (OLTP) и отчетность

Question

Я работаю над торговой платформой, которая имеет отчетность как большую часть своего бизнеса.

Установкой является следующее: База данных SQL OLTP (около 200 таблиц) - довольно небольшое количество записей. (20 000 записей - самая большая таблица), но продолжает расти каждую неделю) Для служб отчетов SQL-запросы используются для запроса в базе данных транзакций. Представьте, что результирующий набор представлений де-нормированный, в духе подхода хранилища данных. Затем эти наборы данных передаются на стороннюю платформу отчетности (например, Tableau, Power Bi или SiSense), которые берут эти наборы данных и бросают их в Cubes (возможно, некоторые столбчатые структуры, такие как mono db, hadoop и т. Д.). Оттуда создаются отчеты.

Текущие проблемы. Представления SQL (около 8). Огромные и очень трудно поддерживать. Чтобы дать вам пример, одно из представлений выводит 100 полей. Но каждое из этих полей представляет собой вычисленные поля со сложными операциями CASE, вложенными операторами IF, встроенными функциями, а что нет, что делает это представление размером до 700 строк кода sql. Я унаследовал их от другого работника и теперь, печально, я должен их поддерживать. Поскольку данные растут еженедельно на несколько сотен записей (посредством миграции и транзакций), а число полей в представлениях растет (несколько раз в неделю), построение куба занимает больше времени и дольше. Чтобы дать вам пример, несколько месяцев назад мы настроили куб, перестроенный за 10 минут, чтобы обновить данные (которые занимали 5 минут). В настоящее время требуется 12-15 минут для сборки, поэтому мы настраиваем его каждые 30 минут. Как вы можете себе представить, это будет ухудшаться по мере роста данных и количества полей; и нам нужны данные как можно более актуальные.

Единственное, что можно сказать о том, что после создания куба отчеты быстро загружаются, потому что их вытаскивают из сторонней платформы, поэтому здесь нет никаких проблем.

Что я имею в виду Я хотел бы избавиться от взглядов, так что я мог бы облегчить процесс maintenanace, а также сохранить как минимум продолжительность куба перестроена.

Опции:

1. построить хранилище данных. А затем создайте пакеты SSIS, чтобы заполнить эту структуру живыми транзакционными данными. Де-нормированная структура, вероятно, будет очень похожа на взгляды, упомянутые выше. Обратный вывод здесь заключается в том, что я действительно не чувствую, что упрощаю много, фактически добавляя еще один слой, который является переносом данных из OLTP в OLAP (datawarehouse). И мне все равно придется перестроить куб.
2. Чтобы превратить текущие представления в индексированные представления SQL (материализованные представления), но в их текущем состоянии я просто не могу этого сделать из-за того, что функции agregate и inline много используются во всем представлении.
3. Еще один вариант, о котором я рассказывал, - это создать ODS (хранилище операционных данных), которое будет представлять собой таблицу данных, которая будет содержать необходимые таблицы, похожие на представления sql, которые у меня есть сейчас, и обновлять их постоянно) Возможно, с помощью триггеров или транзакций журналы? Но я не уверен, что включает в себя построение такой вещи и как трудно поддерживать.

Вопрос: Какой подход следует принять? У любого из вышеперечисленных вопросов есть смысл? Конечно, меня интересуют другие идеи или предложения.

Спасибо!

Answer 1

из моего опыта ваш лучший подход будет 1. Это дорого, но даст вам больше преимуществ. Создайте ROLAP DWH (я рекомендую «Инструментарий хранилища данных» Кимбалла для лучших практик и шаблонов проектирования), если у вас есть возможность использовать хранилище столбчатых данных (например, amazon redshift или sap sybase iq) и все операторы case, вложенные ifs и все операции, о которых вы упомянули, будут применяться во время ETL, поэтому в ROLAP все предварительно рассчитано и оптимизировано для потребления. И не забывайте о приближающихся индексах (в зависимости от используемой технологии использования). Некоторые поставщики баз данных уже опубликовали «оптимальные методы индексирования» для ROLAP, поэтому они расскажут вам, какой тип индекса aply зависит от типа таблицы (размерности) и типа данных, например.