Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Добрый день.
Вот хочу узнать как уважаемый all пополняет свои хранилища данных. Собственно вариантов не так уж и много - репликация, DTS, скрипты. Речь идет о объемах данных больше среднего, например у меня за текущий год около 10 млн. записей в таблице фактов. Я заливаю данные в хранилище при помощи DTS за последние две недели (т.к. данные могут поменяться задним числом). Хочется узнать какова стандартная практика для выполнения этой процедуры и какие требования предъявляются ко времени загрузки данных такого объема. У меня процедура загрузки, построения таблицы фактов и процессинга занимает 4-6 часов и выполняется каждую ночь.
Наоборот, я имею в виду транзакционная система режется после передачи данных в хранилище ? Зачем вообще хранилище ?
Вот вот, хороший вопрос :) Зачем нужно хранилище? Вы его используете просто как склад данных, из которого MS AS может удобно вкачивать в себя данные, или причина другая?
Лично я предпочитаю создавать кубы и online-отчеты на основе нормализованной структуры OLTP-системы (либо из живой базы, либо из ее копии).
2Jurii
В моем случае хранилище это то место куда сливаются данные из OLTP источников (есть выделенный сервер для этих дел, потому как грузить основной SQL сервер дальше некуда), затем на основании слитых данных строятся таблицы фактов, затем процессинг кубов. OLTP источники не урезаются. Дело в том, что есть куча софта, который ваяли годами, основывающийся на OLTP. OLAP стали внедрять недавно - год назад.
В общем, как вы заметили, хранилище у меня это место откуда AS удобно вкачивать в себя данные.
Более тонкий подход, это когда куб создается на конец последнего закрытого периода, и к нему подкачиваются данные из открытого периода
Я так и делаю (если я вас правильно понял). Т.е. имеются партиции - на каждый год своя. Самая длительная операция - создание таблиц фактов - где то 75 % от всего времени выполнения процесса. 10 % - это закачка данных, 15 % - процессинг куба (партиции).
Причем тормозить на создании основной таблицы фактов стало недавно, где то после перехода границы в 8 млн записей. Но это уже другая история. :-)
2 Jurii
Последний закрытый период - прошлый год. Согласен, что это выглядит нерационально. Но на сегодняшний день меня это устраивает, хотя в ближайшем будущем все таки придется сделать партиции например на квартал - данные постоянно растут.
Тогда придется смириться с невысокой скоростью обновления Ваших кубов.
У меня есть проекты, где в кубы закачиваются десятки миллионов записей. Основное время при обновлении кубов, как и у Вас, тратится на создание таблиц фактов (у Вас это наполнение хранилища, а у меня - выполнение запросов, которые соответствуют моим виртуальным вьюшкам). Так что нужно попытаться оптимизировать запросы, грамотно балансировать нагрузку между OLAP-сервером и SQL-сервером, проверить, не является ли узким местом сеть и т.п.
Думаю что вариант сокращения времени построения таблицы фактов очевиден - загружать в таблицу фактов только изменённые данные.
Принцип в общих чертах таков:
1. В БД источника, при изменении документа, его номер записывается в спец таблицу.
2. DTS пакет загрузки данных в ТФ выгружает из БД источника данные только по изменённым документам.
Детальная проработка зависит от типов ИС.
У меня по такой технологии происходит обновление ТФ по расписанию в течении дня и один раз ночью. Обычно время обновление (с учётом последующей постобработки данных и их загрузки с региональных серверов) занимает не более 2-3 минут.
Процессинг кубов конечно же может занимать очень значительное время на таких объёмах данных. Но опять же, если Вы будете грузить только изменённые данные то вполне можно реализовать и Incremental Update куба. Правда в таком случае это скорее всего приведёт к стремительному росту ТФ.
