Проактивное решение проблемы управления данными с помощью моделирования данных снижает долг и повышает масштабируемость, пишет на портале The New Stack Паскаль Десмаретс, основатель и генеральный директор компании Hackolade.
Все ИТ-специалисты знают о техническом долге. Технический долг (известный как tech debt, code debt или design debt) — это метафора, описывающая возможные последствия того, что команды разработчиков ставят в приоритет функциональность или быстрое выполнение проекта, что впоследствии приводит к необходимости рефакторинга или переделки.
Технический долг может быть преднамеренным, и его следует относить к тем случаям, когда разработчики сознательно принимают дизайн-стратегию, которая не является устойчивой в долгосрочной перспективе, но приносит краткосрочную выгоду, например, отправку релиза. Непреднамеренный технический долг может быть результатом подхода «дешево и сердито» («quick-and-dirty») или «двигаться быстро и ломать преграды» («move fast and break things»).
В 2009 г. Мартин Фаулер в своей статье о квадранте технического долга описал вторую ось, проведя уместное различие между разумным и безрассудным техническим долгом.
Долг данных (data debt) — это вид технического долга, который относится к накопленным издержкам неэффективных методов управления данными, таких как неполные, неточные или нестандартизированные данные, которые со временем снижают эффективность и ухудшают процесс принятия решений.
Долг данных — это не просто неприятность, а ненадежные данные и ручное управление данными. Он подрывает способность организации полагаться на данные, снижая их качество, замедляя процесс принятия решений, увеличивая расходы и разрушая доверие к инсайтам.
Хотя долг данных и технический долг тесно связаны между собой, между ними есть ключевое различие: по техническому долгу вы можете объявить банкротство и начать все сначала, но сделать то же самое с долгом данных удается редко.
Безрассудный и непреднамеренный долг данных возникает в результате удешевления хранения и возникновения культуры накопления данных, когда организации сохраняют большие объемы данных без создания надлежащей структуры или обеспечения общего контекста и смысла. Его еще больше подпитывает сопротивление подходу, ориентированному на дизайн, который часто отвергается как потенциально узкое место для повышения скорости. Он также может проникать через хрупкие многослойные «медальонные» архитектуры (multi-hop medallion architectures) в озерах, хранилищах и озерах-хранилищах данных.
Как кодирование без проектирования приводит к техническому долгу, так и отсутствие стратегического планирования приводит к появлению противоречивых, избыточных и разрозненных данных, что усложняет их интеграцию, анализ и извлечение ценности.
«Сдвиг влево» в управлении данными
В случае с долгом данных его лучше предотвратить, чем надеяться на лечение. «Сдвиг влево» (shift left) — это практика, которая предполагает обращение к критическим процессам на более ранних этапах жизненного цикла разработки, чтобы выявлять и устранять проблемы до того, как они перерастут в более серьезные. Применительно к управлению данными «сдвиг влево» подчеркивает приоритетность моделирования данных на ранних этапах, если это возможно — до сбора данных или создания систем.
Моделирование данных позволяет следовать подходу «дизайн в первую очередь», когда структура данных, их значение и взаимосвязи тщательно планируются и обсуждаются до сбора данных. Такой подход уменьшает долг данных, обеспечивая ясность, последовательность и согласованность между командами, что облегчает интеграцию, анализ и извлечение долгосрочной ценности из данных.
Используя моделирование данных на начальном этапе, организации могут определять структуру, значение и взаимосвязи данных в соответствии с потребностями бизнеса. Эта проактивная стратегия позволяет сократить долг данных, предотвращая создание непоследовательных, избыточных или плохо понятных данных. Она также обеспечивает четкое понимание данных техническими специалистами и бизнес-пользователями, что ведет к повышению качества данных, упрощению интеграции и долгосрочной масштабируемости. По сути, «сдвиг влево» дает командам возможность «проектировать на будущее», а не устранять проблемы после их возникновения.
Сторонники подхода «код в первую очередь» должны понимать, что моделирование данных больше не является узким местом, если наряду с моделированием данных, ориентированным на предметную область, применяются принципы agile.
Однако каждая организация, скорее всего, уже имеет определенный уровень дога данных. Что нужно сделать, чтобы взять его под контроль?
Составьте схему существующих данных
Модель данных, как и карта или чертеж, — это визуальное представление того, как организованы данные. Изучив существующие базы данных, источники данных и обмены данными, организации могут отобразить сущности, атрибуты и связи между ними в виде диаграммы «сущность-связь» или более простой графической диаграммы.
Этот процесс обратного проектирования включает в себя анализ и построение диаграмм существующих структур данных для выявления их базового дизайна и взаимосвязей. Это помогает выявить несоответствия, избыточность и пробелы, что позволяет лучше понять и документировать данные для улучшения интеграции, анализа и редизайна, если это необходимо.
Составляя диаграммы существующих данных, вы делаете определения, взаимосвязи и структуры явными, устраняя разрыв между ИТ и бизнес-пользователями. Это позволяет бизнес-командам согласовать то, как данные отражают операции и процессы. В то же время ИТ-отделы получают четкое представление о том, как данные используются для принятия решений, аналитики самообслуживания, машинного обучения и искусственного интеллекта. Такое общее понимание способствует сотрудничеству, уменьшает количество неверных интерпретаций и гарантирует, что все — от технических специалистов до заинтересованных сторон — работают с согласованными и значимыми данными.
Инструменты управления метаданными и словари данных часто полагаются на обратное проектирование и профилирование для сбора существующих структур данных, выявления взаимосвязей и документирования атрибутов. Хотя эти процессы позволяют получить ценные инсайты о текущем состоянии данных, они по своей сути являются реактивными, сосредоточенными на каталогизации того, что уже существует, а не на проактивном проектировании структур данных. Это ограничение означает, что они не могут предотвратить накопление долга данных, поскольку не могут обеспечить соблюдение надлежащих принципов дизайна или привести данные в соответствие с потребностями бизнеса с самого начала.
Дизайн данных будущего
Моделирование данных дополняет эти инструменты, позволяя использовать подход «дизайн в первую очередь», при котором данные продуманно структурируются с учетом общего смысла, контекста и будущей масштабируемости.
Модель данных — это не конечная цель. С технической точки зрения она предназначена для создания схем контрактов данных, которые соответствуют бизнес-требованиям экспертов предметной области и взаимно согласованы с производителями и потребителями данных. С точки зрения бизнеса, она облегчает обмен и доступ к смыслу и контексту данных, которыми обмениваются и хранят.
Моделирование данных предотвращает появление новых долгов данных, создавая прочный фундамент и способствуя эволюции существующих структур. Направляя изменения в соответствии с техническими и бизнес-требованиями, моделирование данных помогает организациям создать для своих данных более устойчивое и эффективное будущее, уменьшая бремя прошлых ошибок и обеспечивая постоянную ценность.
Модель данных также применяется к обмену данными
Моделирование данных традиционно ассоциировалось с реляционными базами данных для транзакционных или аналитических целей. Со временем, с появлением баз данных NoSQL, API, событийно-ориентированных архитектур и микросервисов, это понятие расширилось.
Изначально разработчики фокусировались на базовых технологиях, но теперь стало ясно, что ключ к успешному обмену данными лежит в структуре полезной нагрузки. Для эффективного взаимодействия издатели и потребители данных должны согласовать контракт на передачу данных, в основе которого лежит схема. Эта схема определяет структуру обмена, будь то API или событие Kafka.
Заключение
Чтобы сократить долг данных, составьте схему существующих данных в виде прозрачной, всеобъемлющей модели данных, которая отображает текущие структуры данных. К этому можно подходить итеративно, удовлетворяя потребности по мере их возникновения — не пытайтесь решить все сразу.
Привлеките предметных экспертов и заинтересованных в данных лиц к содержательным обсуждениям, чтобы согласовать контекст, значение и использование данных.
Затем итеративно развивайте эти модели — как для данных в состоянии покоя, так и для данных в движении, — чтобы они точно отражали и удовлетворяли потребности вашей организации и клиентов.
Таким образом создается прочная основа для согласованности, ясности и масштабируемости данных, раскрывается весь потенциал данных, что позволяет принимать более обоснованные решения и внедрять инновации в будущем.
