Comments 7
А можно про разбиение вопроса "кто несёт ответственность за качество данных" более конкретно. А то по тексту получилось, что был конкретный вопрос, а получились какие-то "блоки". Имею ввиду, если первый вопрос заведомо неправильный, то какие тогда должны быть "правильные" вопросы м учётом разбиения? Спасибо за статью, было интересно — сейчас работаю Data Engineer и
Виноват тот, кто не смог декомпозировать бардак на отдельные проблемы и решить каждую из них подходящим способом.
Управление качеством данных складывается из двух функций, если хотите, из двух разных отделов. Один из них должен придумывать правила. Второй — технически обеспечивать работу правил, т.е. чтобы все правила реально работали, люди не пытались «хакнуть систему» и вводить некорректные данные.
Раз уж приглашение для дискуссии было начну=)
Обычно, к тому моменту, когда возникает вопрос управления качеством данных, IT-ландшафт представляет собой следующее: */
И далее схема MDM без DQ.
Зачем людей плохому учишь=)?
Основная идея MDM - это Mach&Merge, а M&M на грязных данных (без DQ, т.е. оценки (отделить плохие от хороших), очистки и восстановлении (в том числе с использованием внешних данных)) - это прямой путь к заваленному проекту MDM по бизнес показателям. Объединим клиентов, например, с учетом ИНН - а он плохой, но повторяющийся , мы ему доверяли как бизнес-ключу уникальному. Или просто все поля пустые и имя "Валерий" - M&M пройдут без оценки DQ и объединит. Валерии удивятся если их много. И такие криули в бизнесе начнутся при этих ошибках второго рода, что ИТ проблемы покажутся сказкой.
Поэтому моё ИМХО запускать нужно DQ + MDM и желательно DQ пускать чуть впереди MDM-а, что бы понимать масштаб трагедии в каждом из источников, подключаемых к MDM. Так сказать DQ должен хотя бы проложить дороги 6й категории (лес повален, но не убран) иначе MDM застревает.
Традиционно на первом этапе DQS подключается к системе MDM, поскольку управление качеством мастер-данных считается более приоритетным, чем операционки.
Возможно, я не совсем чётко эту мысль выразил. На первом этапе, конечно, функция контроля качества данных должна жить в MDM.
А следующим логичным шагом будет контроль качества в других, не мастер-данных. И тут пригодятся наработки и опыт, полученный в MDM.
А что DQ нужно пускать перед MDM — отличный подход, спасибо за него!
Про операционку тоже есть дополнение.
Описано только техническая часть, а так как все MDM и DQ системы обусловлены только человеческим фактором, то правильней бы рассматривать связку DQS+ оператор.
Как DQS контролирует ввод, в online (т.н. DQ Firewall), или начальнику операторов прилетает утром отчет об ошибках допущенных вчера и вечером организуется работа над ошибками.
Без этого система не замкнута.
Создаём компанию мечты: управление качеством данных