Всё так, но мир, к сожалению не даёт никаких гарантированных идентификаторов. Для этого есть целых два класса систем DQ & MDM. Которые, фактически, только эту задачу и решают.
Задача идентификатора - идентифицировать.=) (ваш кэп.) То есть сопоставить. Сопоставлять по одному критерию - плохая практика. Так как любая опечатка - и всё сломалось. Данные вводят люди. Люди ошибаются.
Лучше использовать несколько идентификаторов включая ФИО, ДР, Место рождения, телефоны и так далее.
ну и уж если совсем въедливо, то: 1. обучение (есть /нет) какая длительность и подробность (можно ли свою комепетенцию развить или vendor / integrator lock) 2. формат поддержки от вендора 5х8 / 24х7х365 или "вы как нибудь сами". 3. сертификация по решению спецов, а то сказать я знаю *ETL/ BI может каждый, а при найме проверить это сложно без боевого использования. а тут хоть какое то подтверждение. Если сертификаты дают по результатам экзамена, а не прослушанного бесплатного курса.
Имеет смысл в круги добавить еще финансовую устойчивость самого вендора. И длительность разработки. Так как многие бросились импортозамещать, как на своём так и не opensource. И если дело "не пойдет" быть единственным покупателем умершего решения очень неприятно.
Как с первичными данными обстоят дела? Данные вида "Нап с/а RED DEVIL ИнаяСила7,2% ж/б0.45L " редко встречаются в чеках. Чаще всего это невнятное неидентифицируемое даже человеком нечто, которое может трактовать только продавец и покупатель, если он еще помнит что покупал.
Наиболее же интересно сравнить два товара в двух соседних магазинах разных ретейлеров. Но на тех данных чеков что есть сейчас сделать это практически невозможно. Жаль что не передается в чеке GS1 или штрихкод или его хэш.
У нас всегда процесс строился на примерно такой схеме. Но это касается динамических данных, а не статическийх дата сетов. Для статики можно без циклов. В предложенном выше подходе нет "Измерять", т.е. нет оценки и критериев, что пробуем спасти, а что признаём безвозвратно испорченными данными. После "Исправлять"нужно еще раз оценить насколько получилось исправить и отбросить то что не получилось исправить что бы не отравлять датасет плохими данными. Дубли ... те кто занимается данными от этого слова покрываются испариной=) Объединить данные признанные дублем - тоже отдельное кунгфу.
"Обогащать" есть, но это не только внешние данные, но и алгоритмические обогащения. Когда по ФИО определяем пол без внешних данных. "Актуализация" это тоже в большинстве случаев про внешние данные.
У меня была такой же ход мысли. Электронику не так глубоко копал.
Просто по затратам и ёмкости посчитал. В итоге взял такой же бокс забил максимально ёмкими 18650. получилось +/- на 5-6 зарядов телефонов. До 0 градусов нормально держит, а в минус я на природе больше суток не бываю. И резервная банка маленькая на 2х18650 в кармане ближе к теплу. Если больше недели стоять - то наверняка это стационарный лагерь и там нужен уже генератор. К сожалению эфективность солнечных пока не столь высокая что бы их рассматривать как источник походного электричества.
Если я правильно понимаю, этот метод предполагается к использованию для автоматического связывания бизнеc-глоссария с результатами работы краулера метаданных систем-источников?
Про операционку тоже есть дополнение. Описано только техническая часть, а так как все MDM и DQ системы обусловлены только человеческим фактором, то правильней бы рассматривать связку DQS+ оператор. Как DQS контролирует ввод, в online (т.н. DQ Firewall), или начальнику операторов прилетает утром отчет об ошибках допущенных вчера и вечером организуется работа над ошибками. Без этого система не замкнута.
Обычно, к тому моменту, когда возникает вопрос управления качеством данных, IT-ландшафт представляет собой следующее: */
И далее схема MDM без DQ.
Зачем людей плохому учишь=)?
Основная идея MDM - это Mach&Merge, а M&M на грязных данных (без DQ, т.е. оценки (отделить плохие от хороших), очистки и восстановлении (в том числе с использованием внешних данных)) - это прямой путь к заваленному проекту MDM по бизнес показателям. Объединим клиентов, например, с учетом ИНН - а он плохой, но повторяющийся , мы ему доверяли как бизнес-ключу уникальному. Или просто все поля пустые и имя "Валерий" - M&M пройдут без оценки DQ и объединит. Валерии удивятся если их много. И такие криули в бизнесе начнутся при этих ошибках второго рода, что ИТ проблемы покажутся сказкой.
Поэтому моё ИМХО запускать нужно DQ + MDM и желательно DQ пускать чуть впереди MDM-а, что бы понимать масштаб трагедии в каждом из источников, подключаемых к MDM. Так сказать DQ должен хотя бы проложить дороги 6й категории (лес повален, но не убран) иначе MDM застревает.
С другой стороны, теоретический подход к качеству данных основательный.
Если не смотреть на список решений (больше похожий на некролог) то очень даже ок.
Если не ошибаюсь из таблицы 1 выжила только Информатика.
Современный список тулов можно глянуть тут www.gartner.com/en/documents/3988016/magic-quadrant-for-data-quality-solutions
Потрясающе!
Видна глубокая проработка темы, понимание не только ИТ, но и бизнес-составляющей.
Очень приземленно в отличие от DM BoK и Data Management Maturity (DMM).
Ты крутой.
По стране таких историй много.
И заканчиваются они очень долго.
Кому то просто счета приставы опустошают, а кого то и «лицом в пол» потому что «обознались в базе»=)
Про запрет выезда из страны по чужим долгам — вообще история частая, так как ФССП не особо сильна в задачах поиска среди данных.
В Москве есть ~ 200 человек у которых совпадает всё ФИО+ДР+Место рождения (Москва большая).
По стране полных тесок десятки тысяч (ФИО), полных тесок с одним ДР тысячи.
Так что всё зависит от размера выборки (на страну суррогатный ключ «ФИО+ДР» явно недостаточен) и от уровня критичности данных и кросс-доступа, который автор получил.
Общий ID решение правильное, но не всегда реализуемое.
Если данные ведут в разных системах, то общего ID нет, его можно только сформировать в консолидирующей системе.
Обычно под такие задачи используют системы класса MDM, а под клиентов специализированное решение есть подкласс MDM-ов CDI (Customer Data Integration).
Если мне не изменяет память в Альфа Страховании внедрен CDI от HFLabs силами Джетинфосистемс. Почему разработчики личного кабинета не использовали общий ID из CDI — большая загадка.
Всё так, но мир, к сожалению не даёт никаких гарантированных идентификаторов.
Для этого есть целых два класса систем DQ & MDM. Которые, фактически, только эту задачу и решают.
Задача идентификатора - идентифицировать.=) (ваш кэп.)
То есть сопоставить. Сопоставлять по одному критерию - плохая практика. Так как любая опечатка - и всё сломалось. Данные вводят люди. Люди ошибаются.
Лучше использовать несколько идентификаторов включая ФИО, ДР, Место рождения, телефоны и так далее.
Про гранты - я бы сказал флаг скорее красный чем зеленый.
Если взяли для ускорения развития - ок, а вот если на старте, то риск очень высок.
рязанцы - да, красавцы. Очень нравится решение.
ну и уж если совсем въедливо, то:
1. обучение (есть /нет) какая длительность и подробность (можно ли свою комепетенцию развить или vendor / integrator lock)
2. формат поддержки от вендора 5х8 / 24х7х365 или "вы как нибудь сами".
3. сертификация по решению спецов, а то сказать я знаю *ETL/ BI может каждый, а при найме проверить это сложно без боевого использования. а тут хоть какое то подтверждение. Если сертификаты дают по результатам экзамена, а не прослушанного бесплатного курса.
Имеет смысл в круги добавить еще финансовую устойчивость самого вендора. И длительность разработки.
Так как многие бросились импортозамещать, как на своём так и не opensource. И если дело "не пойдет" быть единственным покупателем умершего решения очень неприятно.
Есть еще вот такое. https://data-innovations.ru/plus7-mayak/
Довольно крупные внедрения есть
может у нас разные пятерки / дикси / перекрестки и рыбные/мясные лавки и фруктовые / овощные магазинчики. у меня чеки мало пригодные для чтения .
по реглементирование 54 ФЗ, удивили, посмотрю. Спасибо.
про кассовиков не совсем понял в чеке же есть ИНН.
ИНН-> ЕГРЮЛ->ОКВЭД
Как с первичными данными обстоят дела?
Данные вида "Нап с/а RED DEVIL ИнаяСила7,2% ж/б0.45L " редко встречаются в чеках.
Чаще всего это невнятное неидентифицируемое даже человеком нечто, которое может трактовать только продавец и покупатель, если он еще помнит что покупал.
Наиболее же интересно сравнить два товара в двух соседних магазинах разных ретейлеров.
Но на тех данных чеков что есть сейчас сделать это практически невозможно. Жаль что не передается в чеке GS1 или штрихкод или его хэш.
Про термин.
Забавно Data quality трансформировали. Где там бритва Оккама ? ;)
У нас всегда процесс строился на примерно такой схеме.
Но это касается динамических данных, а не статическийх дата сетов.
Для статики можно без циклов. В предложенном выше подходе нет "Измерять", т.е. нет оценки и критериев, что пробуем спасти, а что признаём безвозвратно испорченными данными.
После "Исправлять"нужно еще раз оценить насколько получилось исправить и отбросить то что не получилось исправить что бы не отравлять датасет плохими данными.
Дубли ... те кто занимается данными от этого слова покрываются испариной=)
Объединить данные признанные дублем - тоже отдельное кунгфу.
"Обогащать" есть, но это не только внешние данные, но и алгоритмические обогащения. Когда по ФИО определяем пол без внешних данных.
"Актуализация" это тоже в большинстве случаев про внешние данные.
У меня была такой же ход мысли.
Электронику не так глубоко копал.
Просто по затратам и ёмкости посчитал.
В итоге взял такой же бокс забил максимально ёмкими 18650. получилось +/- на 5-6 зарядов телефонов.
До 0 градусов нормально держит, а в минус я на природе больше суток не бываю. И резервная банка маленькая на 2х18650 в кармане ближе к теплу.
Если больше недели стоять - то наверняка это стационарный лагерь и там нужен уже генератор.
К сожалению эфективность солнечных пока не столь высокая что бы их рассматривать как источник походного электричества.
Если я правильно понимаю, этот метод предполагается к использованию для автоматического связывания бизнеc-глоссария с результатами работы краулера метаданных систем-источников?
Про операционку тоже есть дополнение.
Описано только техническая часть, а так как все MDM и DQ системы обусловлены только человеческим фактором, то правильней бы рассматривать связку DQS+ оператор.
Как DQS контролирует ввод, в online (т.н. DQ Firewall), или начальнику операторов прилетает утром отчет об ошибках допущенных вчера и вечером организуется работа над ошибками.
Без этого система не замкнута.
Раз уж приглашение для дискуссии было начну=)
И далее схема MDM без DQ.
Зачем людей плохому учишь=)?
Основная идея MDM - это Mach&Merge, а M&M на грязных данных (без DQ, т.е. оценки (отделить плохие от хороших), очистки и восстановлении (в том числе с использованием внешних данных)) - это прямой путь к заваленному проекту MDM по бизнес показателям. Объединим клиентов, например, с учетом ИНН - а он плохой, но повторяющийся , мы ему доверяли как бизнес-ключу уникальному. Или просто все поля пустые и имя "Валерий" - M&M пройдут без оценки DQ и объединит. Валерии удивятся если их много. И такие криули в бизнесе начнутся при этих ошибках второго рода, что ИТ проблемы покажутся сказкой.
Поэтому моё ИМХО запускать нужно DQ + MDM и желательно DQ пускать чуть впереди MDM-а, что бы понимать масштаб трагедии в каждом из источников, подключаемых к MDM. Так сказать DQ должен хотя бы проложить дороги 6й категории (лес повален, но не убран) иначе MDM застревает.
Если не смотреть на список решений (больше похожий на некролог) то очень даже ок.
Если не ошибаюсь из таблицы 1 выжила только Информатика.
Современный список тулов можно глянуть тут www.gartner.com/en/documents/3988016/magic-quadrant-for-data-quality-solutions
Видна глубокая проработка темы, понимание не только ИТ, но и бизнес-составляющей.
Очень приземленно в отличие от DM BoK и Data Management Maturity (DMM).
Ты крутой.
Есть такой интересный документ.
Формально мы пока не подписали GDPR, но бодро движемся в эту сторону.
Только ДНК, только хардкор=)
И заканчиваются они очень долго.
Кому то просто счета приставы опустошают, а кого то и «лицом в пол» потому что «обознались в базе»=)
Про запрет выезда из страны по чужим долгам — вообще история частая, так как ФССП не особо сильна в задачах поиска среди данных.
В Москве есть ~ 200 человек у которых совпадает всё ФИО+ДР+Место рождения (Москва большая).
По стране полных тесок десятки тысяч (ФИО), полных тесок с одним ДР тысячи.
Так что всё зависит от размера выборки (на страну суррогатный ключ «ФИО+ДР» явно недостаточен) и от уровня критичности данных и кросс-доступа, который автор получил.
Общий ID решение правильное, но не всегда реализуемое.
Если данные ведут в разных системах, то общего ID нет, его можно только сформировать в консолидирующей системе.
Обычно под такие задачи используют системы класса MDM, а под клиентов специализированное решение есть подкласс MDM-ов CDI (Customer Data Integration).
Если мне не изменяет память в Альфа Страховании внедрен CDI от HFLabs силами Джетинфосистемс. Почему разработчики личного кабинета не использовали общий ID из CDI — большая загадка.