Перемещение денормализованных данных в базу данных отчетов

Question

Текущая ситуация:

У нас есть база данных SQL, содержащая все наши бизнес-данные.Есть десятки объектов, таких как клиенты, билеты и продукты.Каждый объект сохраняется в нескольких таблицах, обычно от 8 до 12 таблиц на объекты.Таким образом, в нашей базе данных сейчас более 200 таблиц.

Чтобы упростить создание отчетов, мы хотим создать базу данных отчетов, в которой мы денормализуем эти объекты, чтобы сделать ее более доступной и повысить производительность нашей действующей БД, поскольку все отчетывзять данные из живого БД прямо сейчас.

Проблема:

Здесь начинается сложный прошлый период: нам также необходимо создать новые столбцы с данными в целевой / отчетной базе данных, где мы можем хранить вычисленные данныедля отчетности.Например, сколько времени занимал билет от начала до конца или кто заказывал товар (денормализованный в виде текста через запятую)

Вопрос в том, как лучше всего передать эти данные в новыйбаза данных? Мы имели в виду разные подходы:

• Использование хранимой процедуры:

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

• Создание клиентского приложения:

Создание клиентского приложениякоторый выбирает данные из действующей базы данных, вычисляет все необходимые столбцы во время выполнения и вставляет их в базу данных отчетов.

• Использование задания SSIS:

Что является видомиз сочетания двух вышеперечисленных: задание ssis, которое получает данные, вычисляет все расширенные столбцы и помещает их в базу данных отчетов.

Я знаю, что это может быть немного "основано на мнении" вопросов, но естьдолжно быть решением наилучшей практики, так как мы не можем быть единственными, кто испытывает эту потребность.К сожалению, я действительно могу найти какой-нибудь хороший ответ в Интернете.

Любой совет действительно ценится!

Answer 1

В итоге я сделал гибрид:

Я создал веб-приложение, которое отображает все объекты и таблицы так, как оно выглядит в объектной модели. Это позволяет вам выбрать, какие столбцы какого объекта следует перенести, денормализовать и так далее. Вывод этого будет сохранен в таблице, перечисляющей все столбцы, которые должны быть доступны в ReportingDB.

Сохранение выбранных столбцов создает:

• Представление в LiveDB, выбирающее все эти столбцы. Один просмотр на объект на основе объектной модели.

• Хранимая процедура, которая перемещает все данные из «новых» столбцов в базу данных отчетов. Новые столбцы - это столбцы, которые еще не были переданы. Эта хранимая процедура запускается каждые 24 часа ночью, чтобы избежать любого воздействия на LiveDB.

• Хранимая процедура «обновления», которая передает обновления всех datarows в ReportingDB, имеющих метку даты-времени, отличную от ReportingDB. Этот SP срабатывает каждые 15 минут.

• Хранимая процедура с именем "имя объекта" _aggregates, которая будет создана только один раз. Это позволяет добавлять пользовательские функции для заполнения агрегированных столбцов данными. Этот SP запускается каждые 15 минут сразу после обновления SP. Вы можете рассчитать содержимое агрегированных столбцов на основе переданных столбцов или "дельты" от старого значения к новому (если вам необходимо выполнить сложные вычисления времени и т. Д.)

Все хранимые процедуры всегда выбирают данные из представления, которое было создано ранее.

Answer 2

Этот вопрос действительно слишком широкий, но я постараюсь описать некоторые из имеющихся у вас вариантов.

Извлечь

Вариант 1. Создание хранимых процедур, которыежить либо в самой исходной БД, либо в вашей отчетной БД (используя перекрестный вызов базы данных (очевидно, это имеет свои недостатки, т.е. базы данных становятся связанными вместе)), которые считываются непосредственно из исходных таблиц.Эти процедуры должны быть в состоянии работать как в полном (все данные), так и в инкрементном (только последний) режиме.Возможно, вы захотите сделать некоторое перекрытие и для своей инкрементальной нагрузки.

Вариант 2: Вы устанавливаете сбор данных изменения (здесь возникает проблема с тем, чтобы убедиться, что вы не заполняете свои журналы, но это дает вам более тонкий уровеньподробно) или отслеживание изменений (получите только последнюю версию записи, а не изменения) в исходной базе данных и прочитайте из полученных таблиц изменений, чтобы получить измененные записи из исходной базы данных.

Вариант 3: Создатьреплика только для чтения вашей исходной базы данных и чтение из этой реплики.

Преобразование

Вариант 1. Мой личный выбор - использовать SSIS для процесса извлечения.Он создан для таких вещей.Особенно, когда вы переходите между серверами, и вы также сможете получать данные от остальной части организации, такие как кадровые записи и тому подобное.Вы должны установить структуру, в которой у вас есть проект, и каждый проект состоит из списка пакетов служб SSIS, которые должны выполняться в полном или инкрементном режиме.Вы можете либо загрузить напрямую в исходную базу данных, либо создать посредническую базу данных, чтобы подготовить любые сложные данные для дальнейшей обработки.Возможно, вам придется сложить вещи после того, как вы их взяли, чтобы выполнить некоторые из более сложных вещей.

Вариант 2: вы пишете хранимые процедуры, которые читают из источника и отправляют прямо в пункт назначения.Это можно сочетать с вариантом 1 в разделе «Извлечение».Вам необходимо убедиться, что они могут объединяться, поэтому вы можете использовать отдельные операторы INSERT и UPDATE или использовать MERGE.

Load

Вариант 1: отложите данныеиз процесса ETL в схему типа «звезда» или «снежинка» (звезда будет требовать меньше соединений, и в SSAS встроены функции оптимизации для схем типа «звезда»).Затем вы можете использовать это для перемещения ваших данных в SSAS либо в многомерную, либо в табличную модель.

Вариант 2: вы записываете свои данные в форму, которую требуют ваши отчеты, в виде отчета.Очевидно, это может привести к сумасшедшему количеству наборов данных, но у него есть свои победы, если требуется только небольшое количество отчетов, которые не изменятся.Это зависит ...

У вас действительно есть слишком большой выбор, поскольку вы пытаетесь спроектировать полное решение BI, и у всех нас будут разные представления о том, что лучше для вас.