Как я могу спроектировать свое хранилище данных для работы с запаздывающим источником данных?

Привет, я работаю над хранилищем данных MS SQL Server 2017 Standard Edition для клиента и столкнулся с проблемой, по которой мне нужен совет.

У меня есть достаточно большая таблица фактов, содержащая розничные транзакции до транзакций (около 2,5 миллионов строк в день с 3-летней историей). Большая часть таблицы фактов берется из одного источника — кассовой системы. Итак, в настоящее время у нас есть процесс ETL, загружающий данные из этой системы, моделирующий их для поиска суррогатных ключей и т. д. и загружаемый в таблицу фактов каждый час. Таблица имеет кластеризованный индекс columnstore для обеспечения хорошей производительности в инструменте BI.

Теперь у клиента есть система приложений лояльности, которую он хочет интегрировать. Эта система отправляет нам данные о ежедневной выписке CSV. Выдержка содержит подробную информацию о транзакциях приложения и связанных предложениях, полученных через приложение, и содержит общий идентификатор транзакции, который соответствует идентификатору, который уже содержится в нашей таблице фактов.

Если бы эти источники поступали вместе, я бы смоделировал новую таблицу измерений — DimAppOffer или аналогичную и использовал бы два источника для поиска предложений, связанных с каждой транзакцией, и имел AppOfferKey в таблице фактов. Но поскольку этот CSV-файл поступает только один раз в день, а транзакции загружаются каждый час, все связанные транзакции уже существуют в таблице фактов к тому времени, когда я получаю данные из приложения лояльности.

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


person Nick Baker    schedule 11.03.2020    source источник


Ответы (2)


Я не особенно хочу запускать большое обновление для кластеризованного индекса columnstore, если я могу этого избежать, но я не вижу другого способа обойти это?

Вы можете либо загрузить факты с нулевым или «отсутствующим элементом» в ключе измерения, либо добавить новый элемент измерения во время ETL с нулевыми/неизвестными неключевыми атрибутами и связать факт с этим, как предлагается здесь: Измерение позднего прибытия.

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

person David Browne - Microsoft    schedule 11.03.2020
comment
Проблема в том, что у меня нет размерного бизнес-ключа, пока не поступят данные. Измерение будет основываться не на номере транзакции, а на идентификаторе предложения, связанном с номером транзакции в файле CSV. Поэтому в данном случае я не могу воспользоваться советом о позднем прибытии. - person Nick Baker; 11.03.2020

В этой ситуации я предпочитаю создать вторую таблицу фактов без фактов с идентификатором транзакции и сведениями о предложении приложения (аналогично вашему измерению AppOffer, но просто используйте идентификатор транзакции в качестве ключа).

Затем вы можете создать представление для вашего основного факта и этой новой таблицы, используя ЛЕВОЕ соединение для аналитики.

person PeterHe    schedule 11.03.2020
comment
Однако есть ли у этого какие-либо проблемы с производительностью? По сути, это означало бы создание схемы снежинки, а не звезды, не так ли? - person Nick Baker; 11.03.2020
comment
Схема «звезда» не означает хорошей производительности, потому что вам нужно будет присоединиться к этим таблицам измерений. Вы также пропустите представление, просто используйте таблицы фактов - person PeterHe; 11.03.2020
comment
Итак, вы говорите, что таблица фактов в таблице фактов без фактов измеряется как модель данных? Это может работать до тех пор, пока производительность запросов не ухудшится слишком сильно. - person Nick Baker; 11.03.2020