Комментарии 10
Для кого это написано? Это же чушь какая то. Любому дураку понятно что нужно проверить данные которые мы хотим обрабатывать. Для этого не нужно отдельного человека.
Для кого придумали ДПСников? Любому дураку понятно, что нужно соблюдать ПДД. Для этого не нужно отдельной профессии... или все-таки нужно?
Я вам открою тайну: проверка не обязательно должна производиться человеком. Можно проверять данные посредством скрипта.
Скажу больше - обычно так и делают.
Спасибо за комментарий! Цель статьи — подискутировать на тему, кто такой инженер по качеству данных. Мы обсуждаем, в чём специфика его работы и почему это направление востребовано сейчас. Что данные надо тестировать — очевидно, как вы выразились, любому дураку. Неочевидно другое: кто это делает в ИТ-командах? При современных объёмах данных и многообразии их источников на эту роль нужен именно отдельный человек с определённым набором компетенций. DQ — отдельная специализация среди всего многообразия в QA.
Неочевидно другое: кто это делает в ИТ-командах? При современных объёмах данных и многообразии их источников на эту роль нужен именно отдельный человек с определённым набором компетенций.
Объем данных тут не причем. Многообразие источников тоже не играет роли.
Мы пишем правила один раз и пользуемся. Это уже вопрос правильного проектирования.
В сфере охраны труда есть массовая практика (многолетняя культура) обобщений ЧП и ознакомления с ними всех - в отрасли, а то и во всей стране (СССР, Япония). Практика показала что это превентивно заставляет задумываться, чудесным образом “интуичить” и находить ранее неизвестные угрозы и купировать их задолго до первых корпоративных похорон.
В сфере DQ на наших глахах появляются всякие GreateExpectation и т.п. Pander-ы, иногда это что-то попроще типа датаклассов, доктестов или шаблонов в Dagster/AirFlow. Но вот именно культуры обобщений ошибок так и не сложилось. Уж больно стыдно выносить на обозрение позорные упущения.
Откуда берутся упущения и ошибки? В основном они лезут не из пользовательского ввода, а из-за безграмотного кода. Вот 1С-данные - это-ж эталон/стандарт учета. Так почему он позволяет дублировать то, что д.б. уникальным априори (ИНН/КПП, ед. измерения итп)? Вот вам источник ошибок. DA джойнит смело, а DQ полагается на порядочность и разум кодеров, но его нет, причем даже там, где без него нельзя. DA и DQ - оба бессильны перед разгильдяйством.
Да, разгильдяйство есть всегда и степень его действительно влияет на итоговое качество продукта/данных. От багов в архитектуре и проектировании (как понимаю, речь о них) никто не застрахован и такие проблемы, как правило, самые дорогие. Но их тоже можно/нужно обнаруживать и лучше раньше, чем позже. Задача DQ совместно с DA и DE выработать такую схему мониторинга и тестирования данных, желательно автоматизированную, чтобы выявлять проблемы по факту их возникновения (например, когда данные по одному или группе объектов не согласованы). Универсальной защиты на все случаи жизни не придумали, но минимизировать риски - вполне посильная задача, кмк. В этом и ценность профессии, хороший инженер по тестированию (качеству даных) полагается не на доверие к разработчику, а действует по принципу доверяй, но проверяй. И доп. глаза (особенно опытный взгляд с насмотренностью на качество) всегда полезны.
Отдельная роль для датакволити - довольно страннная практика, на мой взгляд. Родилась из посыла: данных много, мало кто их понимает, давайте закроем это "новым" тайтлом, чтобы не было как в компании XX, где потеряли YY из-за кривых данных. Интересно, кто-то измерял, сколько не потеряли, внедрив DQ? Несмотря на наличие подзаголовка, ответа на это я не вижу... Где в реальности DQ волшебники спасают 60% работы "тру" инженера и экономят 15% бизнеса, внедряя Great Expectations?
А проблемы с качеством это же скорее про проектирование, контекст, владение. Тестировщики это не покроют, даже если захотят.
На большинстве проектов, где реально был этот тайтл, датакволити инженер = тестировщик. Из-за размытия и непонимания этой роли другими участниками проекта, ещё и малоэффективный.
Кто такой инженер по обеспечению качества данных и почему без него уже не обойтись?