5 крупных бизнес -ошибок при работе с большими данными: уроки компании, управляющей 16 ТБ данных
6 августа 2025 г.Более четверти специалистов по данным и аналитике по всему миру оценивают, что некачественные данные затратывают компании более 5 миллионов долларов в год, а 7%-это 25 миллионов долларов США. Использование низкокачественных данных является лишь одной из многих распространенных ошибок, которые со временем могут привести к серьезным финансовым потерям.
Я работаю с системой производственной аналитики в ожидании более 10 лет. В течение этого времени мы собрали более 16 терабайт данных и получили более 10 миллиардов новых пунктов данных в день от промышленного оборудования. Основываясь на моем опыте работы с большими данными, я определил пять крупных ошибок, которые часто совершают предприятия, когда они впервые начинают работать с данными.
Неопределенный период хранения данных
Данные по времени сохраняются перед удалением, определяется параметром жизни (TTL). Как правило, TTL для активных данных колеблется от 1 до 2 лет, а архивированные данные сохраняются в течение примерно 5 лет.
Каждая компания может установить свой собственный TTL на основе потребностей бизнеса, но вообще не установить его может привести к проблемам. Если TTL для активных данных намного длиннее, чем на самом деле, система начинает замедляться. Даже при запросе только последних шести месяцев базе данных, возможно, придется сканировать чрезмерные объемы информации, особенно если данные не были заархивированы. Кроме того, хранение устаревших данных для слишком длинных приводит к ненужным затратам на инфраструктуру.
Архивные форматы, такие как Apache Avro или Protobuf, позволяют хранить данные более компактно. В сочетании с алгоритмами сжатия они помогают снизить затраты на хранение. Тем не менее, чтение таких архивов требует большего количества вычислительных ресурсов и времени обработки. Вот почему важно найти баланс между скоростью доступа, затратами на инфраструктуру и объемом хранения.
Плохое качество данных и отсутствие стандартизации
В 2022 году Unity Software-компания, стоящая за широко используемым двигателем видеоигр-запустила собственную рекламную систему. Этот шаг произошел после того, как изменения политики Apple в IDFA сделали традиционные модели AD менее эффективными. Система Unity полагалась на свои собственные данные об взаимодействии с пользователем, а не на Apple, и хотя идея казалась многообещающей, она была построена на низкокачественных данных. В результате таргетинг был неточным, а производительность рекламы упала. Клиенты начали переходить на конкурентов, что привело к потере рыночной капитализации в 5 миллиардов долларов.
Часто предприятия узнают о проблемах качества данных только после того, как они уже нанесли значительный финансовый ущерб.
Проблемы с типами данных, временными метками, дубликатами или отсутствием стандартизации могут исказить аналитику и ведущие модели искусственного интеллекта, чтобы сделать неправильные выводы. Чтобы предотвратить это, важно установить единый стандарт для хранения и обработки данных на этапе проектирования, четко документирует их и обеспечить согласование во всех командах. Регулярные проверки качества данных также имеют решающее значение - это включает в себя удаление дубликатов, стандартизированные форматы и мониторинг полноты данных.
Ловушка с автоматической мастерской во время пиковых нагрузок
Каждая компания испытывает периоды увеличения спроса - праздники, сезонные акции или новые запуска продукта. Мы работаем с производственными компаниями, и в течение таких пиковых периодов мы наблюдаем увеличение объема данных в 5–10x и количество запросов. Инфраструктура должна быть подготовлена для обработки этого уровня нагрузки.
Использование облачного автомассалирования может показаться очевидным решением, но если вы не устанавливаете верхние пределы, система может автоматически добавлять серверы далеко за пределы того, что на самом деле необходимо. Я был свидетелем случая, когда количество серверов выскочило с необходимых 8-80 в течение ночи. Компания получила счет за несколько сотен тысяч долларов. Хотя клиенты были довольны производительностью, бизнес не был - потому что те же результаты могли быть достигнуты без чрезмерных затрат.
Чтобы избежать этого, компании должны не только настраивать пределы масштабирования, но и тщательно отслеживать, что происходит в режиме реального времени. Такие инструменты, как DataDog или AWS CloudWatch, могут помочь, предупреждая команды при превышении порогов.
Иногда сезонные всплески можно управлять не путем масштабирования инфраструктуры, а путем оптимизации, таких как изменение форматов данных, реструктуризация баз данных или распределение нагрузки по нескольким серверам. Хотя это может потребовать дополнительных усилий от архитекторов и разработчиков, в долгосрочной перспективе это оказывается гораздо более экономически эффективным решением.
Чрезмерные затраты, вызванные избыточными данными
Часто компании собирают не только метрики, необходимые для принятия решений, но и техническую информацию пользователя, которая ненанализирована. Согласно исследованию Snowflake, только 6% компаний достигли высокой эффективности данных и получают реальные выгоды от этого бизнеса. И только 38% компаний используют данные в качестве основы для принятия решений.
Небольшие компании, хранящие до миллиона записей, могут некоторое время не замечать проблем из избыточных данных. Но при работе с миллиардами или триллионами записей затраты начинают складывать - расходы на увеличение инфраструктуры, необходимо больше разработчиков, интеграция системы становится более сложной, а общая производительность замедляется.
Например, в промышленной аналитике датчики IIOT передают не только регулярно обновленные параметры состояния оборудования, такие как уровни вибрации или температура, но и технические детали, которые редко меняются, такие как версия прошивки датчика или тип отчета. Хранение этих технических деталей в каждой записи может увеличить объем данных в 10-20 раз. Вот почему мы сохраняем техническую информацию только тогда, когда она меняется. Этот подход экономит место для хранения, снижает затраты и ускоряет обработку.
При работе с данными важно с самого начала четко определять, какая информация необходима для аналитики и принятия решений, и что может быть либо пропущено, либо временно сохранено.
Выбор неправильной базы данных
Одной из наиболее недооцененных ошибок является использование одной базы данных в качестве решения для всех размеров. То, что хорошо работает для одного случая, может быть неэффективным в другом.
Чтобы объяснить в контексте производственной аналитики: базы данных NOSQL, такие как MongoDB, работают хорошо, когда вам необходимо отобразить все данные, связанные с определенной частью оборудования на одной странице - параметры, журналы, примечания, отчеты ML и так далее. Но использование базы данных NOSQL для создания списков, требующих краткой информации по многим различным объектам, может вызвать проблемы. NOSQL не поддерживает эффективные запросы или взаимосвязи между данными, как это делают реляционные базы данных. В результате система, возможно, придется загружать целые документы, где необходимы только детали, снижая производительность и замедленную обработку запросов.
Перед разработкой вашей архитектуры убедитесь, что выбранная база данных соответствует вашему типу данных и бизнес -потребностям. Influxdb, Timescaledb или Opentsdb подходят для данных временных рядов; MongoDB, Cassandra или DynamoDB работают для гибких или полуструктурированных данных; и MySQL, PostgreSQL, Oracle или MS SQL лучше всего подходят для структурированных данных. Избегайте полагаться только на одну базу данных.
Эффективное управление данными начинается не с сбора данных, но с вопросом: что вам нужно для записи для принятия решений, какие данные необходимы, и как вы будете их хранить и обрабатывать?
Оригинал