Добрый день, коллеги.

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

Примерно 10 с небольшим лет назад я сделал свои первые сверки - обычные merge сущности ХД с трехкилометровым запросом к источнику. Работали эти запросы немножко быстрее ETL ХД (примерно раз в 5-10), но разобраться в некоторых запросах было непросто даже мне самому на следующий день, что уж говорить о доработках синхронно с ETL кем-то другим спустя n лет. Моим оправданием могло быть только наличие надо мной архитектора, который эти сверки в проект не закладывал (соответственно, клиент их не оплачивал) , и сделаны они были исключительно ради успокоения клиента, который хотел убедиться на ПСИ в одинаковости данных.

С тех пор я неуклонно мужал и матерел, но о сверках по-прежнему слышал нечасто. Поэтому, как правило, о некорректных данных в ХД приходилось узнавать от их потребителей. Но всему приходит конец: некоторое время назад сверки таки вошли в мой фронт работ и получили заслуженное внимание.

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

• Сверка должна указывать не на строку с различающимися полями, а на различающиеся поля строки - причина очевидна;
  
• Правила сверки должны быть отделены от запроса к данным, т.к. трансформации внутри ETL могут быть весьма непростыми;
  
• Данные не должны перемещаться между серверами БД, т.к. они могут быть для этого слишком большими (и вообще, умная загрузка не читает много раз одни и те же данные);
  
• Сверки должны быть пригодными для копирования, чтобы новые сверки не приходилось писать с нуля.
  

Наложив эти принципы на используемый инструментарий, я пришел к решению на SSIS, которое:

• читает репозиторий правил сверок из БД (2 таблицы)
  
• читает наборы данных из ХД и источника,
  
• проверяет наборы на дубликаты согласно заданному ключу,
  
• соединяет наборы по ключу,
  
• процессит на наборах правила сверок (фактически код C#, например, Math.Abs(srcValue - dwhValue) < 0.0000000000001m),
  
• выводит результаты в 2 файла (ключ строки + результаты процессинга, которые тоже код C#, например, "Расхождение в поле Value, значение Source: " + srcValue + ", значение DWH: " + dwhValue + "."),
  
• отправляет по почте, при необходимости сжимая в архив.
  

В результате я с коллегами каждое утро получаем набор писем с говорящими названиями и цветным содержанием примерно следующего вида
Проверено n строк, m хороших, k плохих.
Нарушено правило "АБВ" а раз.
...
И вложенные файлы со списком нарушений, если таковые имеются.

мигель1,

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

Про качество данных я, как владелец ETL, могу выделить три этапа:
проверка данных на этапе приема сообщения (правильный XML и теги сообщения), на этапе загрузки в DWH (обязательные поля и допустимые значения) и сверки с источником (наборы данных соответствуют друг другу). Первые два онлайн, третий - ежедневно и по запросу. У нас нет дата стюардов (не тот масштаб), и потребности в них я не ощущаю.

It's a kind of ETL magic.

Внутри сверки все за исключением чтения репозитория происходит в одном потоке. Два набора (источника и ХД) соединяются в один, над его полями процессятся правила, их результаты склеиваются и записываются в новое поле набора, в результате получается что-то типа:
Расхождение в поле Value, значение Source: 1, значение DWH:2. Расхождение в поле Value2, значение Source: 2, значение DWH:1
и вместе с ключом попадает в результирующий файл.

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

Критик, правильно ли я понял, что:
вы выверяли содержимое ХД само по себе и прохождение данных внутри слоев ХД, а сверок с источниками не было? Тогда это не совсем то, что меня интересовало ( "Товарищ капитан, у нас пуля из ствола вылетела - проблемы на стороне мишени!" ). Данные могут прогружаться абсолютно правильно, но не те, что надо...

Насколько я понял ответы, сверки с источниками не пользуются популярностью по следующим причинам:

• Допустимая погрешность
  

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

• Сложность построения.
  

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

Аж стало за державу обидно...