Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / OLAP и DWH Новый топик    Ответить
 О маленьких сверках замолвите слово  [new]
.Евгений
Member

Откуда:
Сообщений: 560
Добрый день, коллеги.

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

Примерно 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 плохих.
Нарушено правило "АБВ" а раз.
...
И вложенные файлы со списком нарушений, если таковые имеются.
15 сен 20, 19:08    [22197734]     Ответить | Цитировать Сообщить модератору
 Re: О маленьких сверках замолвите слово  [new]
мигель1
Member

Откуда:
Сообщений: 3216
.Евгений,

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

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

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

а крайние как всегда биайщики
15 сен 20, 20:43    [22197801]     Ответить | Цитировать Сообщить модератору
 Re: О маленьких сверках замолвите слово  [new]
.Евгений
Member

Откуда:
Сообщений: 560
мигель1,

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

Про качество данных я, как владелец ETL, могу выделить три этапа:
проверка данных на этапе приема сообщения (правильный XML и теги сообщения), на этапе загрузки в DWH (обязательные поля и допустимые значения) и сверки с источником (наборы данных соответствуют друг другу). Первые два онлайн, третий - ежедневно и по запросу. У нас нет дата стюардов (не тот масштаб), и потребности в них я не ощущаю.
15 сен 20, 21:17    [22197832]     Ответить | Цитировать Сообщить модератору
 Re: О маленьких сверках замолвите слово  [new]
Критик
Member

Откуда: Москва / Калуга
Сообщений: 33928
Блог
.Евгений,

Как вы эти 2 пункта совместили?

- Сверка должна указывать не на строку с различающимися полями, а на различающиеся поля строки - причина очевидна;
- Данные не должны перемещаться между серверами БД,
15 сен 20, 22:00    [22197858]     Ответить | Цитировать Сообщить модератору
 Re: О маленьких сверках замолвите слово  [new]
.Евгений
Member

Откуда:
Сообщений: 560
Критик
.Евгений,

Как вы эти 2 пункта совместили?

- Сверка должна указывать не на строку с различающимися полями, а на различающиеся поля строки - причина очевидна;
- Данные не должны перемещаться между серверами БД,
It's a kind of ETL magic.

Внутри сверки все за исключением чтения репозитория происходит в одном потоке. Два набора (источника и ХД) соединяются в один, над его полями процессятся правила, их результаты склеиваются и записываются в новое поле набора, в результате получается что-то типа:
Расхождение в поле Value, значение Source: 1, значение DWH:2. Расхождение в поле Value2, значение Source: 2, значение DWH:1
и вместе с ключом попадает в результирующий файл.
15 сен 20, 22:29    [22197877]     Ответить | Цитировать Сообщить модератору
 Re: О маленьких сверках замолвите слово  [new]
мигель1
Member

Откуда:
Сообщений: 3216
.Евгений,

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

А потом приходит пользователь и говорит данные не все и выясняется что источник зарелизил фичу, которая ломает логику на 100500 слое. кто виноват?
15 сен 20, 22:56    [22197905]     Ответить | Цитировать Сообщить модератору
 Re: О маленьких сверках замолвите слово  [new]
Критик
Member

Откуда: Москва / Калуга
Сообщений: 33928
Блог
"Сверки" у меня являются частью слоя ХД "Проверки" )

Это как правило отдельная база, называемая DQ (от Data Quality) + простенький веб-интерфейс. Ее отдельность позволяет упростить релизный процесс, ну и заодно разделить продуктивные данные и проверки. Каждая проверка реализована в виде отдельной процедуры. Результаты проверок пишутся в эту же базу DQ, это может быть как просто ok/не ok, так и наборы данных. Сама база из соображения "поменьше гонять туда-сюда данные" лежит на том же сервере, где лежит stage и DDS-слой хранилища. В подсистему DQ могут входить и SSIS-пакеты/их аналоги.

Классов проверок только два - пользовательские и служебные. Пользовательские в виде того, что закажут пользователи, например, "сумма таких-то данных должна быть равна нулю". Служебные - это проверки etl, примерно то, что описано выше + проверки синхронизации между слоями ХД.

Никаких писем с данными обычно нет, просто служба поддержки отвечает за сайт, где проверки показываются зеленым или красным. Дальше они в случае необходимости реагируют (часто там же в доп-инфо проверки выводятся запросы для доступа к подозрительным данным как в источнике, так и в приемнике).
15 сен 20, 22:59    [22197913]     Ответить | Цитировать Сообщить модератору
 Re: О маленьких сверках замолвите слово  [new]
.Евгений
Member

Откуда:
Сообщений: 560
мигель1
.Евгений,

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

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

Критик, правильно ли я понял, что:
вы выверяли содержимое ХД само по себе и прохождение данных внутри слоев ХД, а сверок с источниками не было? Тогда это не совсем то, что меня интересовало ("Товарищ капитан, у нас пуля из ствола вылетела - проблемы на стороне мишени!"). Данные могут прогружаться абсолютно правильно, но не те, что надо...
15 сен 20, 23:55    [22197966]     Ответить | Цитировать Сообщить модератору
 Re: О маленьких сверках замолвите слово  [new]
Критик
Member

Откуда: Москва / Калуга
Сообщений: 33928
Блог
.Евгений,

Такие проверки по полям я редко делаю, обычно у меня сверка вида {дата, количество записей, сумма}. Крайне редко делал сравнения полных наборов, пару раз всего. Обычно проще по выходным перегрузить весь массив данных, если их не слишком много.

Плюс сразу декларирую заказчику, что точность в ХД - 99%
Для управленческой отчетности достаточно. Для регуляторной конечно приходится изворачиваться, в том числе и ведением логов изменений на стороне первички.
16 сен 20, 00:36    [22197980]     Ответить | Цитировать Сообщить модератору
 Re: О маленьких сверках замолвите слово  [new]
Полковник.
Member

Откуда:
Сообщений: 1888
Постоянно в проектах возникает вопрос на тему сверки данных, заморачивались и побайтовой сверкой с источником и сверкой по суммам и т.д. Для себя решил, что ни одна сверка, написанная руками не дает гарантий от потерь или неверных данных, тесты сами по себе тоже нужно выверять, поэтому городить что то сложное, да и еще что бы это работало постоянно нет никакого смысла. Сейчас сверка данных производится на этапе тестирования один раз, сверяем построчно за какой то период, после переноса в прод ждем замечаний от бизнеса на этапе ОПЭ. Дальше если что то и проскочит, то это может быть только в результате аварии на серверах, или столь незначительно для пользователей, что не имеет смысла.
16 сен 20, 09:37    [22198104]     Ответить | Цитировать Сообщить модератору
 Re: О маленьких сверках замолвите слово  [new]
.Евгений
Member

Откуда:
Сообщений: 560
Насколько я понял ответы, сверки с источниками не пользуются популярностью по следующим причинам:
  • Допустимая погрешность
В моем случае погрешность недопустима, потому что данные ХД используются для отчетности регуляторам, ежедневных клиентских отчетов и даже для клиентского веб-кабинета. Выходных ждать никак нельзя, все проблемы надо исправлять немедленно.
  • Сложность построения.
В моем случае это происходит так: я получаю два запроса от отчетников, копирую похожие пакет сверки и набор правил, совмещаю, дорабатываю напильником, отлаживаю (на своем уровне) и получаю готовую сверку за день, от силы - два. Некоторое время для устранения расхождений могут корректироваться запросы и правила (с моим минимальным участием, в основном трудится аналитик), затем сверка ставится в расписание.
16 сен 20, 13:12    [22198373]     Ответить | Цитировать Сообщить модератору
 Re: О маленьких сверках замолвите слово  [new]
mikron
Member

Откуда: Germany / Stuttgart
Сообщений: 853
В моей реальности это "business as usual" - ежедневно из каждой системы готовятся отчёты, грузятся в специальную систему для reconciliation где и проверяются. Там-же документируются / архивируются отклонения, там-же определяются правила для исключений.
16 сен 20, 13:54    [22198433]     Ответить | Цитировать Сообщить модератору
 Re: О маленьких сверках замолвите слово  [new]
.Евгений
Member

Откуда:
Сообщений: 560
mikron
В моей реальности это "business as usual" - ежедневно из каждой системы готовятся отчёты, грузятся в специальную систему для reconciliation где и проверяются. Там-же документируются / архивируются отклонения, там-же определяются правила для исключений.
Аж стало за державу обидно...
16 сен 20, 18:22    [22198699]     Ответить | Цитировать Сообщить модератору
 Re: О маленьких сверках замолвите слово  [new]
mikron
Member

Откуда: Germany / Stuttgart
Сообщений: 853
.Евгений
Аж стало за державу обидно...
напрасно, тут нечем блистать. Только соотношение риски / стоимость определяет необходимость. Наверно в большинстве случаев можно этим пренебречь или хватает карманных решений. Везде так.
16 сен 20, 21:42    [22198811]     Ответить | Цитировать Сообщить модератору
Все форумы / OLAP и DWH Ответить