Этот документ является первой статьёй в главе «Моделирование данных временных рядов». YMatrix считает, что проектирование моделей данных напрямую влияет на ценность потребления и использования данных. Поэтому, помимо технических введений, наша цель — дать вам чёткое понимание концепций, применений и развития моделей данных временных рядов (Time-series Data Model) на протяжении всей этой главы.
Эпоха информации меняется с поразительной скоростью, что невозможно без сбора, анализа и использования данных человеком. Программное обеспечение для навигации по картам, камеры видеонаблюдения на улицах и теплоснабжающие компании обеспечивают повседневную жизнь за счёт точной статистики данных. Однако по мере развития технологий и ускорения темпа жизни мы уже не просто хотим знать, куда идти и как туда добраться; мы также хотим в режиме реального времени знать, какие дороги свободны, чтобы избежать пробок. Правительства следят за общественными местами ради безопасности, а мы сами хотим приобрести устройства для мониторинга здоровья, чтобы в режиме реального времени контролировать своё физическое состояние и заботиться о здоровье. Такие устройства должны быть лёгкими и портативными, желательно с элегантным дизайном. Теплоснабжающие компании больше не удовлетворяются информацией об изменениях среднесуточной температуры (MDT) в течение месяца, а стремятся присоединиться к развитию концепции «умного города», используя данные об изменениях температуры, скорости ветра и осадков по часам для совершенствования своих моделей прогнозирования и повышения энергоэффективности...
Очевидно, что простой сбор статистических данных за длительные периоды времени уже не может удовлетворить растущие «жадные» запросы человечества. Подробные, насыщенные данными, стали одним из самых ценных активов в нашем мире, где информации часто не хватает. Анализируя эти потребности, мы пришли к выводу, что ядро всех этих сценариев неразрывно связано с одним типом данных: они тесно связаны со временем и поступают с различных устройств; накапливаются со временем и обладают высокой ценностью использования; их объём огромен — легко достигает терабайтов или даже петабайтов, и предъявляются крайне высокие требования к производительности хранения базы данных.
На основании своих ключевых характеристик ранние исследователи назвали такие данные данными временных рядов.
Без сомнения, данные временных рядов являются динамичными и постоянно изменяющимися. Они подобны фильму, который в реальном времени разворачивается внутри бизнес-системы и не имеет конца. Эти данные обладают большой практической ценностью: они помогают компаниям снижать затраты, повышать эффективность и качество, а также направляют дальновидных новаторов по верному пути исследований. В современном мире те, кто владеет такими данными и полностью их использует, могут считаться лидерами своего времени.
Конкретнее, YMatrix считает, что данные временных рядов в основном состоят из следующих компонентов:
2023-02-10 20:00:00.6.2.В целом, мы можем определить данные временных рядов в YMatrix следующим образом: данные временных рядов — это совокупность точек данных, тесно связанных со временем. В приложениях они обычно проявляются как последовательность данных, собранных в разные моменты времени.
Данные временных рядов могут отслеживать изменения за различные интервалы времени — миллисекунды, дни или даже годы, предоставляя мощные аналитические возможности. Мы считаем, что независимо от сценария или варианта использования, все наборы данных временных рядов имеют несколько общих черт:
Собираемые данные всегда записываются как новая строка.
Данные обычно поступают в базу данных в хронологическом порядке.
Время является основной осью (интервалы времени могут быть регулярными или нерегулярными).
Актуальность. Чем новее данные временных рядов, тем выше их ценность, которая постепенно снижается со временем.
Даунсэмплинг (Downsampling). Даунсэмплинг предполагает использование оператора GROUP BY для группировки исходных данных по более широким временным интервалам и вычисления ключевых характеристик каждой группы. Этот процесс не только снижает нагрузку на хранилище, но и сохраняет важные характеристики данных, упрощая анализ исторических тенденций и прогнозирование будущих трендов.
Необходимость интеграции с реляционными данными для получения ценности. Без структурированных реляционных данных, предоставляющих контекстную информацию, данные временных рядов — всего лишь число. Нам необходима достаточная структурированная информация, чтобы описать это число. Например, для точки данных со значением 36,5 нужно понять, представляет ли она температуру, влажность или давление? В каких единицах измерения — градусы Цельсия или паскали? Откуда поступили данные — с котла, конвейера или подшипника? Находится ли оборудование в Зоне 1 или Зоне 2 завода? И так далее. Данные с более богатой ассоциативной информацией обычно обладают большей ценностью.
Тогда в чём отличие сценариев временных рядов от традиционных сценариев OLTP (Online Transactional Processing) и OLAP (Online Analytical Processing)? Поясним с помощью таблицы:
| Бизнес-сценарий | Язык манипулирования данными (DML) | Метод записи | Требования к запросам | Конкурентность |
|---|---|---|---|---|
| Временные ряды | INSERT / Только добавление | Высокочастотная потоковая запись | Запросы по времени, детализация, агрегация; Аналитика взаимосвязей, сложный анализ | Высокая |
| OLTP | INSERT / UPDATE / DELETE | Высокочастотная запись | Точечные запросы | Высокая |
| OLAP | INSERT / Редкие UPDATE / Редкие DELETE | Низкочастотная пакетная запись (ETL) | Связи, агрегация | Низкая |
С точки зрения разработки баз данных временных рядов, модель данных — это шаблон организации данных и интерфейс, предоставляемый пользователям. Пользователи должны понимать модель данных, на которой построена база данных, чтобы знать, как её использовать. Другими словами, способ, которым база данных выбирает модель и хранение данных, определяет, что вы можете с ней делать.
С точки зрения использования пользователем, модель данных чаще всего определяет передовые практики по проектированию метаинформации таблиц, то есть действия по моделированию, которые необходимо заранее спроектировать в соответствии с бизнес-потребностями.
По статистике, базы данных временных рядов стали самым быстрорастущим типом баз данных в мире.
Когда специализированные базы данных и сервисы для сценариев временных рядов только создавались, большинство из них проектировалось и строилось на основе нереляционных моделей данных в целях быстрого масштабирования объёма данных. Однако сегодня, по мере углубления потребностей пользователей к потреблению данных временных рядов, производительность запросов в нереляционных базах данных уже недостаточна для удовлетворения бизнес-требований во многих сценариях. Отсутствие унифицированного стандартного интерфейса привело к росту стоимости обучения разработчиков, которым приходится постоянно модифицировать программы на уровне бизнес-логики, чтобы соответствовать требованиям. В то же время быстрое развитие распределённых баз данных значительно повысило производительность записи в реляционных базах данных, которая ранее была относительно слабой в этом аспекте. В результате отрасль постепенно возвращается к реляционным моделям данных, и YMatrix следует этой тенденции.
Мы согласны с тем, что в долгосрочной перспективе хранение всех данных в одной системе значительно сократит время и затраты на разработку приложений, а также ускорит принятие ключевых решений.
Существуют два совершенно разных подхода к развитию и проектированию моделей данных временных рядов:
На самом деле, обе эти модели сыграли очень важную роль в развитии баз данных временных рядов. Изначально из-за чрезвычайно быстрого накопления данных временных рядов ранние разработчики полагали, что традиционные реляционные модели не справятся с такими объёмами данных, тогда как нереляционные модели с простым вводом данных показывали лучшие результаты по масштабируемости. Поэтому первые базы данных временных рядов были разработаны на основе нереляционных моделей.
Продукты нереляционных баз данных, такие как InfluxDB, решили взять на себя задачу создания базы данных с нуля и добились первоначального успеха благодаря преимуществам в скорости выполнения и масштабируемости. Однако по мере развития бизнес-требований потребители данных постепенно осознали, что, хотя низкий порог входа в нереляционные базы данных (обычно минимальное предварительное моделирование данных и возможность быстрого развёртывания) изначально был привлекательным, по мере роста размера и сложности таких систем ими становилось всё труднее управлять. Отсутствие универсального языка запросов заставляет разработчиков и администраторов баз данных сталкиваться с этим «техническим долгом», а иногда даже изучать более сложные языки программирования для удовлетворения сложных запросов и операционных требований.
Всё возрастающие затраты и сужающиеся интерфейсы делают нереляционные базы данных временных рядов недоступными для пользователей, побуждая их рассмотреть возврат к реляционным базам данных (где «бремя» ложится на саму базу данных, а люди постепенно освобождаются от эксплуатационной нагрузки), и эта тенденция становится всёобщей.
«Регресс», о котором мы говорим, не является откатом технологии баз данных, а представляет собой проектирование новых вариантов, соответствующих характеристикам сценариев временных рядов, на основе традиционных реляционных библиотек. Например, вариант широкой таблицы, объединяющий «структурированные» и «полуструктурированные» данные, показан ниже.
Поскольку приложения временных рядов предназначены для хранения большого объёма временной информации, моделирование хранения данных на нижнем уровне является обязательным. Соответствующая модель данных описывает информацию во внешнем виде реляционной таблицы данных.
Поскольку YMatrix построена на реляционной модели данных, вы можете проектировать DDL секционированных таблиц (или схему, как правило, называемую таблицей) различными способами. В целом существует два основных режима хранения: узкая таблица (Narrow) и широкая таблица (Wide).
| Узкая таблица | Широкая таблица | Вариант узкой таблицы | Вариант широкой таблицы | |
|---|---|---|---|---|
| Затраты на предварительное проектирование | Низкие | Высокие | Ниже | Высокие |
| Сложность расширения | Лёгкая | Более сложная | Легче | Легче |
| Накладные расходы по объёму | Большие | Малые | Большие | Малые |
| Производительность запросов | Низкая | Высокая | Низкая | Высокая |
Внимание! Подробное описание широких, узких таблиц, вариантов узких и широких таблиц см. в Идеях моделирования временных рядов; для конкретных сценариев обратитесь к Примерам моделирования данных в сценарии интернета вещей для транспорта и Примерам моделирования данных в сценарии умного дома.