Comments 8
Вот уж не знаю, что там у вас за витрины, но с точки зрения SQL всё описанное - это ужас и кошмар, и волосы дыбом. Полное ощущение, что вместо данных у вас невменяемая каша, а структура хранения данных в принципе не использует мощнейшую (и всегда готовую к использованию) подсистему контроля целостности и непротиворечивости данных используемой СУБД. Голые таблицы, ни первичных/уникальных индексов, ни внешних ключей, ни ограничений на значения... надо ли удивляться, что возникает необходимость в описанных проверках.
Безусловно, мы высоко ценим современные инструменты управления данными, такие как возможности различных БД, Data Quality решения, Data Catalog и др. Мы активно применяем их в своей работе. Однако в реальных проектах не всегда есть идеальные условия.
Так это про хранилища и витрины у бизнеса а не про oltp,
Но это не самое главное, самое главное что сравнение с эталонами часто не даёт ожидаемого результата. Основной кейс это перенос функционала и на пару контрольных дат все сходится, едет в прод а потом начинается сущий ад... Качество начинает падать, производительность на заполненных объектах резко снижается, и это связанно с тем что изначально в постановке задачи часто "сделать как было, а способ контроля - сверка с эталоном....
При чём тут OLTP? Бизнес что, как-то иначе данные хранит? Нет, вроде бы в таблицах на SQL-сервере...
Но коли так, то откуда может взяться необходимость проверки "уникальности ИНН среди клиентов" - там что, в таблице уникального индекса на это поле нету? Или необходимость проверки "наличия ссылочной целостности при заполнении поля «родительский договор»" - что, нет внешнего ключа? Ну с какого перепугу оно, это качество данных, начинает падать-то? Сервер просто не даст сохранить данные, которые не соответствуют правилам целостности. Если эти правила - имеются.
Скажем так, да индексов часто нет.... Или отключение.. или, к примеру, техническая версионность, или одновременно и техническая и бизнес...
В принципе то внешние ключи нужны бы, но часто приходится идти на компромисс...
В т.ч. с т.з. производительности и способа разбора ошибок.
Ну то есть сперва создаём себе трудности, а потом их мужественно преодолеваем. Странно всё это...
Нет, я допускаю случаи (и даже работал с таковыми), когда приходящие исходные данные, прямо скажем, грязненькие, и в строгую структуру не ложатся. Но это вполне себе решается хранением и "сырого" значения, и нормализованного, со связью между ними. А данные, которые не удалось распознать в автоматическом режиме, или которые приводят к коллизии, выводятся в третью таблицу - требующую вмешательства оператора и ручной интерпретации. Но в любом случае на выход подаются только надёжные, проверенные данные. Либо по специальному запросу - сырые, но уж коли запросил такое, то не жалуйся на скорость.
Отключение индексы и внешние ключи то стандартная ситуация для хранилищ данны в крупных организациях. к сожалению полностью нормализовать данные не всегда выходит, источник,и к примеру живут олькл актуальным срезом данных, а в хранилище нужна история изменений, источников несколько а сущности объединяюися в общие и между ними строятся связи, при этом единомомнтно получить консистентныц срез со всех систем невозможно. Где о пытаются нормализовать ядро системы, но часто на это просто не хватает ресурсов, как бы можно сделать идеально, но за бесконечное время (с т.з. бизнеса) при этом может просто не хватить производительности, доступной на текущий момент. Поэтому в тех хранилищах которые я видел, после этапа загрузки запускается этап проверок, который фактически проверяет в том числе и целостность полученного результата, по тем метрикам которые посчитали важными.
Представьте себе, что у вас Hive. Или GP. Там всё не очень хорошо с индексами и FK.
Витрина данных: сверка с эталоном