Изменение данных за старые периоды

добавлено: 16 дек 10
понравилось:0
просмотров: 4745
комментов: 3

теги:

Автор: Критик

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

У этих изменений есть несколько возможных причин:
1) реальное изменение фактов в DWH
2) изменение атрибутов измерений
3) Некорректная работа клиентского ПО

Рассмотрим их более подробно:

Реальное изменение фактов в DWH

Этот случай возникает при проведении/правке документов задним числом.
Чтобы иметь возможность назвать этот фактор как причину изменений данных, требуется соответствующим образом проектировать систему:
- хранить дату добавления факта
- не удалять факты, а отмечать их пометкой "удалено", вместо них добавлять новые
Все это справедливо для инкрементально наполняющегося хранилища данных(ХД), если же ХД каждый раз полностью перезаполняется, то тут только один вариант - резервные копии (много-много копий).

Изменение атрибутов измерений

Этот случай возникает для SCD1-справочников, когда по бизнес-причинам массово меняются значения атрибутов у элементов измерений.

Его проще пояснить на примере:
Допустим, есть измерение "Номенклатура", и некоторая таблица фактов, например продажи или остатки. Номенклатура (в числе прочих) имеет атрибут "Направление".
"Услуги" являются одним из значений "Направления".

В какой-то момент принято решение - перевести часть или все номенклатуры направления "Услуги" в другие категории, например в "Услуги физ-лицам" и "Услуги юр-лицам". Что при этом произойдет с сохраненными отчетами? При их обновлении мы получим изменение старых данных и у нас опять попросят это объяснить.

Выход тут только один - для каждого часто используемого SCD1-справочника хранить его SCD2-версию.
Фактически, делать его "снимок" в момент обновления справочника.

Дополнительно: если в качестве сервера используется SSAS, а в качестве клиента Excel, то иногда даже без хранения истории справочника можно отследить переименование атрибутов. Для этого нужно запустить Profiler подключится к SSAS и выбрать событие Error. При запуске отчета с переименованным атрибутами, которые раньше присутствовали в фильтре, в Profiler`е получим примерно такую запись: "Query (1, 9) При синтаксическом анализе строки [Номенклатура].[Направление].[Направления].&[DVD] в кубе не был найден элемент "&[DVD]". Но это может помочь только при полном исчезновении атрибута из измерения. В данном примере - все номенклатуры с направлением DVD стали принадлежать какому-то другому направлению.

Некорректная работа клиентского ПО

Рассмотрим на конкретном случае.
Итак, у нас имеются регистронезависимый комплект из SSAS и DWH, а также xlsx-файл со сводной таблицей, отображающей данные куба.
Атрибуты измерений имеют в качестве ключей свои же строковые значения (важно).
Сводная таблица обновлялась месяц назад.
После очередного обновления данные за старые периоды существенно изменились.
На первый взгляд, судя по историческим таблицам (или бэкапам), справочники и факты не менялись.

Эмпирическим путем было установлено, что при добавлении одного элемента измерения текущий отчет стал сходится со старым на 100%. Дальнейшее расследование показало, что Excel хранит метаданные сводной таблицы не только в виде mdx, но и в виде значений отдельных фильтров. И если в DWH регистр этих значений изменился, то в Excel он остался прежним, и в сводной таблице вы увидите вовсе не те данные, что были там месяц назад, т.к. Excel молча исключит выбранный фильтр.

Идентифицировать эту проблему можно так - используя vba получить старый mdx-запрос до обновления отчета с помощью Cells(1, 1) = ActiveSheet.PivotTables.Item(1).MDX и сравнить с запросом, полученным с помощью Profiler при нажатии кнопки "Обновить"
Баг легко воспроизводится:
- создаем xlsx-файла со сводной таблицей, эта сводная таблица должна ссылатся на куб, выбираем в фильтре какие-либо элементы атрибутов
- переименовать расширение файла в zip и открываем его любым архиватором
- найходим файл pivotTable1.xml (цифра в названии может менятся)
- перепишем одно из значений в фильтре в другом регистре, например (условно) "услуги" заменим на "Услуги"
- сохраняем файл и переименовываем обратно
- открываем Excel`ем и видим, что элемент волшебным образом пропал из фильтра

Лучшее решение для предупреждения подобных случаев - использовать в качестве ключей атрибутов измерения числовые значения.

Пока все)

Комментарии


  • >> В какой-то момент принято решение - перевести часть или все номенклатуры направления "Услуги" в другие категории, например в "Услуги физ-лицам" и "Услуги юр-лицам". Что при этом произойдет с сохраненными отчетами? При их обновлении мы получим изменение старых данных и у нас опять попросят это объяснить.

    Выход тут только один - для каждого часто используемого SCD1-справочника хранить его SCD2-версию

    >>> выходов на самом деле не один. Инициатором загрузки и изменения данных должен быть тот, "кто изменяет". Просто "так уж сложилось", что ввиду часто отсутствия такой возмжности, остается один только выход.

  • по поводу выходов - их реально может быть несколько. но, имхо, в ХД надо делать все справочники с учетом историчности, в том числе и меняющейся задними числом (именно история изменений справочника меняется задним числом). тогда реально раскопать любую проблему. а уж затем в витринах справочник преобразовывать к нужному виду - scd1, scd2 или еще что-то.

  • Вот только вытаскивание нескольких SCD2-измерений наружу для пользователей чревато тем, что у последних крыша поедет. Я сделал одно измерение (контракты) для ретроспективного показа, описал все в документации, привел скриншоты - пользователь вкуривали с трудом.



Необходимо войти на сайт, чтобы оставлять комментарии