Чтобы полностью контролировать данные, предприятию нужно знать, в каком масштабе реального времени оно работает или, говоря другими словами, с какой скоростью оно обменивается данными с клиентами. Об этом на портале InformationWeek пишет вице-президент Talend Джейк Стайн.
Что было бы, если бы Uber или DoorDash (ведущая служба доставки еды в США — прим. ред.) работали без обновлений в режиме реального времени? Как тогда узнать, где находится заказанный автомобиль или пакет с едой? Люди запрограммированы думать, что быстрее — это лучше. Этот способ мышления пронизывает все, начиная с отношений между потребителем и брендом и заканчивая передовым ИТ-бизнесом и технологиями B2B. Потребители, которые купились на эту концепцию, предполагают, что решения для обработки данных с нулевой задержкой являются лучшим ответом на их потребности в управлении данными. Но правда заключается в том, что время отклика приложений, исчисляемое микросекундами, дает конкурентное преимущество биржевым игрокам, тогда как слишком большое количество обновлений в других сферах деятельности является бесполезным отвлекающим фактором.
Когда идет речь о данных, реальное время может означать, что они могут обновляться с различной частотой — один раз в день, час или даже микросекунду. Чтобы обладать возможностью контроля за данными, предприятию нужно знать, с каким масштабом реального времени оно работает. Для этого важно определить свои бизнес-цели. Начать нужно с понимания частоты действий и проверок, а затем сопоставить с этим свою технологию. В некоторых случаях для получения конкурентного преимущества счет идет на секунды, но реальность такова, что большинство ситуаций не требуют такой быстрой реакции. Жизнь клиента течет размеренно и не меняется каждую минуту, поэтому посекундное обновление данных является избыточным. Но есть и исключения.
Одним из примеров является американская компания по производству тренажеров Peloton, которая оснащает свои велотренажеры мультимедийными экранами, чтобы ее клиенты во время тренировки могли просматривать видео в режиме реального времени. Для того, чтобы мотивировать их, задачей компании является предоставление высококачественного потокового видеоряда, крайне чувствительного к сетевым задержкам. С учетом того, что тысячи гонщиков одновременно настраиваются на один класс тренировок, сделать это крайне непросто. С целью мониторинга производительности сети, которой приходится выдерживать скачкообразные нагрузки, Peloton применяет такие инструменты, как Datadog и AWS. Помимо этого они позволяют осуществлять мониторинг инфраструктуры, следить за производительностью приложений, управлять журналами событий и отслеживать работу пользователя с цифровыми технологиями.
Аналогичным образом действует букмекерская фирма Paddy Power Betfair (PBB): чтобы обеспечить наилучший пользовательский опыт, она отслеживает ставки и результаты игр вплоть до секунды. Особенностью ее деятельности является управление доступом и обслуживание огромных баз данных с невероятно низким уровнем задержки. Более того, объемы данных PBB не просто огромны, они еще и сильно меняются со временем. Чтобы справляться с кратковременными или продолжительными всплесками активности пользователей, PBB управляет своей платформой данных через облако, прибегая к услугам таких сервисов, как AWS S3, Redshift и Aurora.
Как Peloton, так и PBB оперируют разными масштабами реального времени и уровнями задержки. Их объединяет то, что каким бы видом деятельности не занималась компания, клиенты рассчитывают на быстрый и бесшовный доступ к своим данным.
Практически реальное время
Предназначение данных реального времени состоит в сокращении интервалов между произошедшим событием и практическим пониманием того, что это событие представляет из себя в конкретный момент времени. Чтобы принимать обоснованные решения, организациям нужно стремиться к тому, чтобы промежуток времени между пониманием и выгодой был как можно более коротким. Ключом является минимизация возникающих разночтений, что сделает данные более гибкими и адаптируемыми. Унаследованные инфраструктурные модели более не в состоянии свести отклик сети до минимальных значений, поэтому все больше компаний применяют облачные интегрированные платформы. Они не просто сокращают задержки, но и высвобождают время для оценки событий.
Еще одним моментом, который замедляет реакцию приложения на изменения данных, является традиционная модель хранения. Ситуацию можно улучшить за счет перехода от медленных жестких дисков и реляционных баз данных к решениям in-memory. Как показывают исследования, каждая
Чтобы определить «реальность» реального времени, нужно задаться вопросом: «А зачем оно вам нужно»? Данные — трансформируемые единицы: они постоянно собираются, меняют свою форму, анализируются, но масштаб реального времени зависит от того, что компания собирается делать с отчетом о данных и как часто она должна отправлять их конечному потребителю. К примеру, частота отправки будет зависеть от типа данных, будь то отчетность перед советом директоров, финансовая транзакция или создание профиля клиента. Однако показатель реального времени не должен исходить из потребностей клиента, которого, как уже говорилось, интересует только скорость доступа.
Нужно быть реалистичным. Компании следует опросить своих клиентов, чтобы понять, чего они хотят и почему, и действовать в соответствии с их желаниями. Нужно понимать, что компромисс между стоимостью и скоростью достигается и в режиме реального времени, поэтому компании вполне по силам определить оптимальный уровень задержки, который устроит ее аудиторию, но при этом не выйти за рамки бюджета. Показатель реального времени варьируется в зависимости от отраслевой принадлежности компании или особенностей бизнеса, поэтому во многом он будет уникальным.
Не стоит гнаться за модой, ориентируясь на новомодные стартапы, которые обновляют свои программы с нулевой задержкой. При выборе времени отклика следует учитывать приоритеты как организации, так и ее клиентов, руководствуясь их реальными, а не воображаемыми потребностями. Исходите из того, что универсального «режима реального времени» не существует — существует компромиссный вариант скорости отправки/получения данных, который устраивает вас и вашего клиента.
