Как я могу спроектировать свое хранилище данных для работы с опоздавшим источником данных? - PullRequest
1 голос
/ 11 марта 2020

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

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

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

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

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

Ответы [ 2 ]

0 голосов
/ 11 марта 2020

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

Затем вы можете создать представление о вашем основном факте и этой новой таблице с использованием LEFT-соединения для аналитики.

0 голосов
/ 11 марта 2020

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

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

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

...