Данные лежат в основе практически любого современного бизнеса. Без них операции останавливаются, а решения теряют свою эффективность. По мере роста требовательности клиентов способность быстро преобразовывать сигналы о поведении пользователей в решения становится конкурентным преимуществом, пишет на портале BigDATAwire Андреас Пех, руководитель отдела инженерии данных компании Exmox.

В игровой рекламной технологии, где кампании и поведение в приложениях меняются каждую секунду, медленные данные являются не просто помехой, а серьезным препятствием. Эффективность следующей кампании или функции часто зависит от скорости и надежности данных, лежащих в ее основе.

Многие компании накопили огромные массивы данных, полагая, что их объем является ключевым фактором успеха бизнеса. На самом деле эти массивы могут замедлить вашу работу. Огромный объем данных, которые компании должны сейчас обрабатывать и на основе которых они должны действовать, задерживает получение инсайтов.

Из-за того, что компании просеивают огромные массивы данных, время, необходимое для получения действенных инсайтов, становится несоразмерным времени, необходимому для принятия быстрых бизнес-решений, которые создают конкурентное преимущество. Системы оказываются перегруженными и становятся чрезмерно сложными, а команды иногда ждут недели, чтобы получить простые инсайты. Традиционные конвейеры обрабатывают данные как побочный продукт, передавая беспорядочные события от команды к команде. Эта реактивная модель рушится под тяжестью большого объема пользовательских сигналов реального времени и требований оптимизации на основе искусственного интеллекта. Именно здесь хорошая практика DataOps становится решающим фактором.

Хотя компании вкладывают средства в новые аналитические инструменты и модели ИИ, чтобы ускорить обработку данных, эти инструменты сами по себе не решают проблему медленной обработки данных. Корень проблемы носит гораздо более культурный характер. Чтобы достичь по-настоящему быстрой обработки данных, бренды должны начать относиться к данным как к основному, а не побочному продукту. Этот сдвиг требует измеримых целей по надежности, четкого распределения ответственности и проложенных путей, которые делают правильное решение простым решением.

Проблема узких мест

Инструменты для работы с данными могут быть полезны, но инвестиции в них, как правило, несопоставимы с затратами временем на обеспечение необходимого контекста данных и их передачу в удобном для восприятия формате.

Компании используют фундаментально неэффективные конвейерные линии, которые невозможно исправить с помощью одних только инструментов ИИ. На такой конвейерной линии данные передают от одной команды к другой, пренебрегая тем, как следующая команда сможет понять то, чем с ней делятся. В результате того, что данные производятся как побочный продукт операций, централизованная команда по работе с данными получает огромные объемы данных, которые ей приходится очищать. В свою очередь, конвейерная линия продолжает разваливаться, поскольку команда перегружена огромным объемом данных и пытается разобраться в них, прежде чем отправить их дальше аналитикам.

Это создает ситуацию, когда затор заложен в дизайн. Центральная команда по работе с данными усердно трудится, чтобы разобраться в этом беспорядке, но, поскольку она не создавала эти данные, она не может полностью понять или исправить возникшие проблемы. Поэтому, как только один беспорядок устраняется, сразу же возникает другой. Это создает цикл реактивных действий, когда команды постоянно исправляют неработающие отчеты после того, как первоначальная команда что-то меняет без предупреждения. Результат? Разочарованная, выгоревшая команда и медленные, ненадежные данные, которым никто не может полностью доверять при принятии решений.

Сейчас, когда ИИ проникает во все сферы деятельности и, вероятно, увеличивает объем создаваемых данных, бренды должны переосмыслить способы управления и использования этих данных, если они хотят добиться реально высокой скорости и эффективности. Чтобы восстановить контроль, нужны две вещи: совместная ответственность за качество на источнике и объективные показатели состояния и скорости конвейера. Один из проверенных подходов, который можно использовать, — это модель «данные как продукт». Этот подход предполагает децентрализацию владения данными и применение того же тщательного контроля, что и к внешним продуктам для клиентов.

Вот три основных принципа, которые бренды должны применять, чтобы воплотить эту операционную философию в жизнь.

Принцип первый: перенести ответственность на более ранние этапы

В области разработки ПО уже давно известно, что перенос проверки качества на более ранний этап («сдвиг влево», «shift left») позволяет снизить затраты и ускорить доставку. То же самое можно сделать и с данными: перенести проверку качества и тестирование на как можно более ранний этап цикла разработки.

В настоящее время центральная команда по работе с данными контролирует качество данных только на заключительном этапе, и этот подход не работает. Это связано с тем, что в результате только команда домена, которая создает данные, обладает полным контекстом, необходимым для обеспечения надлежащей точности и целостности.

Если компании сместят свой подход «влево», разработчики приложений сами возьмут на себя ответственность за данные, создаваемые приложениями. Предоставив производителю право собственности на качество, можно предотвратить возникновение постоянных проблем, прежде чем они проникнут в дашборды или модели машинного обучения.

В конечном итоге это больше, чем просто техническое изменение. «Сдвиг влево» станет культурным изменением, направленным на внедрение принципов сетки данных (Data Mesh). Распространяя ответственность и заботу о качестве в домены, которые производят и используют данные, организации заменяют централизованный контроль совместной ответственностью. Каждый домен теперь становится создателем и защитником надежных данных, что обеспечивает управление с самого начала, а не на конечных этапах.

Центральная команда по работе с данными превращается из уборщиков в архитекторы. Они перестают заниматься устранением неполадок в дашбордах и сосредотачиваются на защитных механизмах платформы, шаблонах и наблюдаемости, что приводит к уменьшению количества неожиданностей, ускорению получения инсайтов и повышению доверия.

Принцип второй: заключение контрактов на данные

Как и любой другой контракт, контракт на данные создает четкие правила и определения для всех участников. Он информирует производителей и потребителей о схеме набора данных, семантике, метриках качества и целевых показателях уровня обслуживания.

Контракт на данные — соглашение, похожее на API, между производителями и потребителями данных — гарантирует потребителям, что производители будут поставлять данные в правильном формате и в соответствии с согласованными стандартами.

Этот простой шаг может значительно уменьшить путаницу в команде и ускорить обработку данных. Он также значительно повышает доверие как к данным, так и между командами. Если команда приложения хочет внести изменение в контракт, это изменение предлагается, версионируется и утверждается заинтересованными сторонами, что предотвращает сбои.

На практике эти контракты часто начинаются с определения событий отслеживания, которые представляют собой действующие спецификации, подробно описывающие, как системы передают данные. Они могут начинаться как простые таблицы и со временем превращаться в формальные схемы. Каждое событие определяет свою структуру, значение и правила качества, обеспечивая стабильность даже при развитии продуктов. Со временем эти определения становятся общим активом управления, превращаясь в машиночитаемый источник достоверной информации, который встраивает политику и проверки качества непосредственно в производство данных, что отражает принципы сетки данных.

Принцип третий: автомагистрали, а не дорожные заграждения

Понятно, что передача прав собственности на данные командам, которые их создают, может показаться путем к хаосу. Но речь не идет о потере контроля над ними, а о предоставлении командам свободы и инструментов для более быстрой и эффективной работы. В конечном итоге это выльется в самообслуживаемую платформу данных, где каждый потребитель может самостоятельно генерировать инсайты по стандартным вопросам и обращаться за поддержкой только при решении более сложных задач анализа.

Центральная команда по работе с данными не должна быть изолированным стражем. Вместо этого нужно заложить основу, которая обеспечит скорость: четкую, доступную инфраструктуру, которая позволит каждой команде работать без трений — создавая магистрали, а не препятствия.

Эта инфраструктура принимает форму стандартизированных платформ самообслуживания, шаблонов и инструментов, которые любая команда может легко адаптировать для создания своих собственных продуктов. Отсюда роль центральной команды по работе с данными эволюционирует в роль посредника, помогающего подбирать лучшие решения для обработки, мониторинга и преобразования данных.

Эта модель, которая приносит пользу всем. В то время как команда домена получает возможность управлять своими собственными продуктами, центральная команда получает возможность управлять регулированием, безопасностью и совместимостью во всем бизнесе.

Нынешняя устаревшая модель обработки данных больше не подходит для компаний, которые в значительной степени полагаются на получаемые инсайты. Мы видим, что данные становятся ключевым фактором, определяющим рабочие процессы на всех уровнях бизнеса, и поэтому необходимо избегать низкой скорости обработки данных.

Инжиниринг данных как продукта — это способ преодолеть это узкое место.

Данные должны формировать будущее бизнеса — запускать новые идеи и удовлетворять потребности клиентов. Хотя ИИ и инструменты автоматизации ускоряют этот процесс, сам по себе они не являются решением проблемы. В основе успеха технологии лежит фундамент, на котором они работают. Сначала необходимо правильно выстроить логику и структуру, чтобы эти инструменты могли усилить то, что уже работает.