Учебник по данным временных рядов, и почему вы не захотите использовать “нормальную” базу данных для их хранения.

Вот загадка: что общего у самоходного Тесласа, автономных алгоритмов торговли на Уолл-стрит, “умных домов”, транспортных сетей, выполняющих молниеносную доставку в тот же день, и открытой публикации данных NYPD?

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

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

Автомобили с собственным приводом постоянно собирают данные о том, как меняется окружающая их среда.

Автономные торговые алгоритмы постоянно собирают данные о том, как меняются рынки.

Наши “умные дома” следят за тем, что происходит внутри них, чтобы управлять температурой, выявлять нарушителей и отвечать на наши команды (“Alexa, включи расслабляющую музыку”).

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

Полиция Нью-Йорка отслеживает свои транспортные средства, чтобы позволить нам нести их более ответственным (например, для анализа 911 время отклика).

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

Модели использования разработчиков программного обеспечения уже отражают это. Фактически, за последние 24 месяца базы данных временных рядов (TSDB) стабильно оставались самой быстрорастущей категорией баз данных:

https://lh6.googleusercontent.com/3ilNt7AbjM0ahQd10tFn41s8ux_9rRIiDtVOUSUCKPqcvwc-5RZfKhA7SVD6RRlXVc2eMjncTtYliL1wIXHy1LNBN0HsDM4kSCHjbDXvvbgl7inygKEazHrf68gsEx-2eSzmqLXT

Что такое данные временных рядов?

Некоторые рассматривают “данные временных рядов” как последовательность точек знания, измеряющих эквивалент во времени, хранящихся во временном порядке. Это правда, но они просто царапают поверхность.

Другие могут представить себе серию числовых значений, каждое из которых сопровождается меткой времени, определяемой репутацией и группой помеченных размеров (или “тегов”). Часто это, возможно, метод моделирования данных временных рядов, но не определение самой информации.

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

Вот еще один пример, с реальными данными из последнего Йорка, показывающий поездки в такси в течение первичных нескольких секунд 2018 года. Как вы увидите, каждая строка может быть “измерением”, собранным в выбранное время:

https://lh3.googleusercontent.com/ZRDripFiX6Le9oupbI-iAEt0_VX7q9xpolqpCE_WsjcSIgXZJK1clIkXhINTMvpTu1aC55j5gBMyJ1c8RdYu03augqDc4y-9WWL6eSDNMsvET-NEk7WchpZyLdpMrt3SvNZFTNxE

Существует множество других форм данных временных рядов. Чтобы назвать несколько: Данные мониторинга DevOps, потоки событий мобильных/веб- приложений, данные о промышленных машинах, научные измерения.

Эти наборы данных в основном имеют три общих черты:

Приходящие данные почти всегда записываются как заменяющая запись.

Данные обычно поступают во временном порядке

Время может быть первичной осью (интервалы времени часто бывают как регулярными, так и нерегулярными).

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

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

Когда вы собираете замену показаний сенсора_x, перезаписывает ли оно ваше предыдущее считывание или создает новое считывание во время отдельной строки? В то время как оба метода обеспечат вам текущее состояние системы, только записывая новое считывание во время отдельной строки, вы будете готовы отслеживать все состояния системы с течением времени.

Проще говоря: наборы данных временных рядов отслеживают изменения в общей системе в виде INSERT, а не UPDATE.

Такая практика записи каждого изменения в систему в качестве замены, разных рядов – это то, что делает данные временных рядов такими мощными. Это позволяет нам жить изменениями: анализировать, как что-то изменилось в прошлом, контролировать, как что-то меняется в настоящем, предсказывать, как это будет меняться в будущем.

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

Это просто учебное различие. Сосредоточив наше определение на “изменении”, мы начнем замечать наборы данных временных рядов, которые мы не собираем сегодня, но которые мы всегда должны собирать вниз по дороге. На самом деле, часто люди имеют данные временных рядов, но не знают об этом.

Представьте, что у вас есть интернет-приложение. Всякий раз, когда пользователь входит в систему, вы просто обновляете временную метку “last_login” для этого пользователя в течение одной строки в вашей таблице “users”. Но что, если бы вы относились к каждому входу в систему как к отдельному событию и запоминали его со временем? Тогда вы могли бы: отслеживать историческую активность входа, видеть, как использование (в/де-)складывается с течением времени, пользователей ведра по тому, как часто они обращаются к приложению, и многое другое.

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

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

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

Зачем мне нужна база данных временных рядов?

Вы можете спросить: Почему я не могу просто использовать “обычную” (т.е. не временную) базу данных?

Правда в том, что вы просто можете, и некоторые люди так делают. Но почему же TSDB сегодня самая быстрорастущая категория баз данных? По двум причинам: (1) масштаб и (2) удобство использования.

Масштабирование: Данные временных рядов накапливаются очень быстро. (Например, один подключенный автомобиль будет собирать 4000 ГБ знаний в день.) И обычные базы данных не рассчитаны на такой масштаб. Реляционные базы данных плохо работают с очень большими наборами данных; базы данных NoSQL работают лучше в масштабе, но все же могут быть превзойдены базой данных, тонко настроенной для данных временных рядов. Напротив, базы данных временных рядов (которые часто поддерживаются реляционными базами данных или базами данных NoSQL) справляются с масштабированием за счет повышения эффективности, которое возможно только в том случае, если вы относитесь к времени как к основному классу. Эта эффективность заканчивается улучшением производительности, включая более высокую скорость захвата, более быстрые запросы при масштабировании (хотя некоторые из них поддерживают больше запросов, чем другие), а также лучшее сжатие данных.

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

Именно поэтому разработчики все чаще берут на вооружение базы данных временных рядов и используют их для распространения случаев использования:

системы мониторинга программного обеспечения: Виртуальные машины, контейнеры, сервисы, приложения

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

Приложения для отслеживания активов: Транспортные средства, грузовики, физические контейнеры, поддоны

Финансовые торговые системы: Классические ценные бумаги, новые крипто-валюты

Приложения для проведения мероприятий: Отслеживание данных взаимодействия пользователя и заказчика.

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

(и более)

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

Мысль о разрыве: Все ли это данные временных рядов?

Примерно за последнее десятилетие мы живем в эпоху “Больших данных”, собирая огромные объемы данных о нашем мире и применяя вычислительные ресурсы для формирования его смысла.

Несмотря на то, что эта эра началась со скромных вычислительных технологий, наша способность захватывать, хранить и анализировать данные улучшилась в экспоненциальном темпе, благодаря основным макротрендам: Закон Мура, закон Крайдера, облачные вычисления, целая индустрия технологий “больших данных”.

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

Все ли данные начинаются как данные временных рядов? Вспомните более ранний пример веб-приложения: у нас были данные временных рядов, но мы этого не знали. Или рассмотрим любой “нормальный” набор данных. Скажем, текущие счета и остатки в серьезном розничном банке. Или текстовый файл в формате ASCII для программного проекта. Или текст для этого текста.

Обычно мы выбираем хранение новейшего состояния системы, но вместо этого, что, если мы будем хранить каждое изменение и вычислять новейшее состояние во время запроса? Разве “нормальный” набор данных – это не просто вид сверху набора данных временных рядов (кэшированных из соображений производительности)? Разве в банках нет реестров транзакций? (И разве блок-цепочки не являются просто распространяемыми, неизменяемыми журналами временных рядов?) Разве программный проект не имеет контроля над версиями (например, git-комммиты)? Разве у этого текста нет истории ревизий? (Отменить. Переделать.)

Пишите по-другому: Разве не во всех базах данных есть журналы?

Мы понимаем, что многие приложения могут никогда не требовать данных временных рядов (и лучше было бы использовать “представление текущего состояния”). Но по мере того, как мы продолжаем идти по графику технологического прогресса, может показаться, что эти “представления текущего состояния” исчезли. Которые, сохраняя все больше и больше данных в виде временных рядов, мы могли бы также быть готовы узнать их лучше.