Оптимизация объектного хранилища для обеспечения экономически эффективного выполнения запросов с низкой задержкой позволяет компаниям сохранять долгосрочные данные в горячем состоянии, пишет на портале The New Stack Франц Кнупфер, директор по контенту и исследованиям компании Hydrolix.

Замороженное (frozen, холодное) хранилище или различные методы отбрасывания данных (например, снижение частоты выборки) часто кажутся единственными решениями в условиях, когда объем журналов событий продолжает расти, а затраты стремительно увеличиваются.

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

Одной из последних новостей в этой области является анонс AWS S3 Tables, использующей Apache Iceberg для сегментирования и оптимизации объектного хранилища. Такие инструменты, как Iceberg, представляют собой обертку для объектного хранилища, что значительно повышает производительность озер данных. В то же время существуют решения, которые обеспечивают как анализ журналов событий в реальном времени, так и долгосрочный исторический анализ, максимально используя производительность объектного хранилища — и все это без необходимости создавать решение с нуля с помощью таких инструментов, как Iceberg.

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

Проблемы многоуровневого хранения данных

Замороженное хранилище может сократить расходы по сравнению с сильно дорогостоящим горячим хранилищем на многопроцессорном оборудовании, работающем с разделяемой памятью (tightly coupled hardware). На этом его преимущества заканчиваются и начинаются недостатки. Замороженное хранилище неудобно восстанавливать, поэтому к нему редко обращаются и оно быстро становится темным. Оно гораздо медленнее, чем горячее хранилище, недоступно для машинного обучения и удивительно дорого в целом — главным образом потому, что его, как правило, очень много и оно не приносит долгосрочной выгоды. В некоторых случаях для перемещения данных между уровнями требуются конвейеры и реплики данных, что приводит к дополнительной сложности и операционным накладным расходам.

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

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

Преимущества долгосрочного горячего хранения данных

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

  • Возможность сравнивать текущие и исторические данные. При многоуровневом хранении операционные команды, как правило, имеют представление только о данных за несколько недель или, в крайнем случае, за несколько месяцев. Но при использовании горячих данных длительного хранения можно сравнивать данные реального времени с данными за прошлую неделю, месяц или даже год. При этом гораздо проще отследить циклические события, поведение конкретных пользователей (например, злоумышленников) и понять закономерности и тенденции, которые вы, возможно, не смогли бы обнаружить иным способом. Для предприятий, использующих замороженное хранилище, запросы, включающие исторические данные, обычно нуждаются в регидратации и выполняются гораздо медленнее. Что еще хуже, запросы, проходящие через несколько уровней хранения, становятся узкими местами, и преимущества горячего хранения теряются.
  • Более простое управление данными. Если все данные хранятся как горячие, нет необходимости управлять несколькими уровнями данных, создавать резервные копии данных при их перемещении между уровнями или разбираться с потенциально сложными конвейерами для перемещения данных. Кроме того, вы сможете отказаться от принятия сложных решений по управлению данными, например о том, как долго каждый тип данных должен находиться на каждом уровне перед перемещением.
  • Расширение возможностей по федерализации и демократизации данных в организации. Долгосрочное горячее хранение может быть полезно предприятиям, которые стремятся демократизировать свои журналы событий и сделать их доступными не только для операционных групп.
  • Просветление темных данных. Поскольку замороженное хранилище неудобно восстанавливать, оно часто является значительным источником темных данных. Если держать эти данные в горячем состоянии, вероятность того, что они станут темными, значительно ниже. Это поможет снизить риски, связанные с темными данными, например, вероятность того, что недоступные данные могут скрывать важные свидетельства о вредоносных атаках и нарушениях. Кроме того, это повышает потенциальную ценность данных, которые в противном случае не имели бы такой ценности.

Обеспечение сценариев использования MО, кибербезопасности и BI

Помимо описанных выше преимуществ, существует множество сценариев использования долгосрочных исторических горячих данных, которые гораздо сложнее или даже невозможно реализовать при хранении в замороженном виде. Приведенные ниже три сценария — в областях кибербезопасности, МО и бизнес-аналитики — являются лишь несколькими примерами важности долгосрочного хранения горячих данных.

  • Поиск угроз. В среднем на обнаружение утечки данных уходит 272 дня, что выходит за рамки окна хранения горячих данных для многих платформ. Более того, злоумышленники обычно используют подход медленных маломощных атак, что затрудняет обнаружение подозрительных закономерностей и предотвращение вторжений, которые могут стать серьезными нарушениями. Если данные быстро перемещаются в замороженное хранилище, обнаружить закономерности, проявляющиеся в течение месяцев или даже лет, становится невозможно. Вместо этого криминалистический анализ проводится только после того, как произошла утечка и ущерб нанесен.
  • Обучение моделей МО. Все вокруг говорят об использовании возможностей ИИ, но многие предприятия все еще пытаются понять, что именно это значит. Одной из проблем является создание высококачественных наборов данных для обеспечения точности моделей. Данные журналов событий и систем могут обеспечить высокоточные и долгосрочные наборы данных для таких сценариев использования, как обнаружение аномалий и планирование ресурсов. Однако замороженные данные создают препятствия для доступа, что увеличивает время и усилия, необходимые для обучения. В конечном итоге модели МО должны работать с горячими наборами данных — любые данные, которые не соответствуют этим критериям, могут потенциально ограничить эффективность модели.
  • BI и наука о данных. Журналы событий содержат не только данные о работе ваших приложений, но и подробную информацию о том, как пользователи взаимодействуют с вашим брендом, продуктами и сайтами. Команды BI и науки о данных могут изучить эти данные, чтобы получить инсайты, которые помогут в разработке продуктов, планировании запасов, маркетинговых кампаниях и размещении рекламы. Но эти инсайты можно получить только в том случае, если команды имеют доступ к полным наборам данных, а не к неполным данным за несколько недель или месяцев.

При использовании долгосрочных и экономически эффективных горячих данных возникает вопрос: «Что мы можем сделать, чтобы максимизировать ценность этих данных?», а не: «Как долго я могу хранить данные без чрезмерных затрат?».

Переосмысление горячего хранения данных для аналитики реального времени

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

Чтобы максимально повысить производительность объектных хранилищ, решения строятся на основе следующих основных концепций:

  • Параллелизм. Объектные хранилища, такие как AWS S3 и GCP Cloud Storage, допускают несколько параллельных подключений, поэтому решения, использующие такие системы, как Kubernetes, могут записывать и читать данные параллельно.
  • Минимизация объема просматриваемых данных. Такие техники, как секционирование, минимизируют объем данных, который необходимо просмотреть. Например, одна из распространенных стратегий секционирования — по временной метке. При этом, когда пользователь делает запрос с временной фильтрацией, все разделы, не включенные во временной диапазон, исключаются из рассмотрения.
  • Минимизация объема данных, передаваемых через распределенные системы. Такие методы, как high-density compression и predicate pushdown, значительно сокращают объем данных, которые необходимо передавать по протоколу HTTP.

При правильном выборе решения можно сократить время выдачи аналитических результатов («time to glass»), включая получение, преобразование и запрос данных, до нескольких секунд. Так, в некоторых решениях типичное время обработки данных составляет менее 10 секунд, даже если предприятие получает миллионы строк журнала событий в секунду.

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

Объектные хранилища не подходят для сценариев, когда требуется действительно миллисекундная задержка, но в то же время решения, основанные на хранилищах in-memory или дорогом tightly coupled hardware также не подходят для анализа больших объемов данных. Как всегда, важно использовать правильный инструмент для работы. И когда речь идет о получении, хранении и анализе больших объемов данных журналов событий, стоит использовать решения, построенные на базе объектных хранилищ, а не многоуровневые хранилища, в которых ваши данные остаются холодными.