Этот документ — второй в разделе «Моделирование данных временных рядов». YMatrix считает, что проектирование модели данных напрямую влияет на ценность потребления и использования данных. Поэтому помимо технических описаний, вся цель этого раздела — дать вам четкое понимание концепции, применения и эволюции моделей данных временных рядов.
Прежде чем создавать собственную модель данных временных рядов, прочитайте первую статью в этом разделе: Что такое модель данных временных рядов?, чтобы понять, как YMatrix определяет модель данных временных рядов.
YMatrix считает, что понимание типичных шаблонов запросов к данным временных рядов эквивалентно пониманию ключевых требований сценария. Реальный сценарий временных рядов обычно включает комбинацию нескольких типов запросов. В таблице ниже в качестве примера используется сценарий подключённых автомобилей, чтобы проиллюстрировать эти прикладные задачи.
| Шаблон запроса | Описание | Практическое применение |
|---|---|---|
| Одно устройство | ||
| Точечный запрос по одному устройству | Получение одного или нескольких метрик одного устройства в конкретный момент времени. Чаще всего используется для получения последних или последних ненулевых значений определённых метрик. | Текущая скорость автомобиля во время движения |
| Детализированный запрос по одному устройству | Получение детальных данных одного устройства за временной интервал, возможно, с одной или несколькими метриками. | Подробный анализ, например, поиск первопричины в послепродажном обслуживании |
| Агрегация по одному устройству | Получение агрегированных значений (например, максимум, минимум, первый, последний, среднее) определённых метрик одного устройства за временной интервал. | Средняя скорость автомобиля за заданный период |
| Несколько устройств | ||
| Точечный запрос по нескольким устройствам | Получение значений метрик нескольких устройств в определённый момент времени, возможно, одной или нескольких метрик. | Комбинированные запросы сигналов; мониторинг состояния (например, срабатывание предупреждения о низком заряде батареи); сравнение метрики a сейчас с метрикой b 10 секунд назад для определения износа автомобиля |
| Детализированный запрос по нескольким устройствам | Получение детальных данных нескольких устройств за временной интервал, возможно, одной или нескольких метрик. | Обнаружение закономерностей в данных, таких как анализ первопричины или отслеживание новых продуктов. Обычно используется командами R&D |
| Агрегация по нескольким устройствам | Получение агрегированных значений (например, максимум, минимум, первый, последний, среднее) определённых метрик по нескольким устройствам за временной интервал с группировкой по устройствам. | Проверка сетевых условий по регионам; вычисление средних скоростей для проверки, испытывают ли несколько автомобилей плохое соединение в определённом месте |
| Другие запросы | ||
| Многомерный запрос | Запрос последних, детальных или агрегированных значений устройств, соответствующих фильтрам по тегам или атрибутам. Если затрагивается несколько устройств, результаты группируются по устройствам. | Мониторинг текущего состояния автомобилей |
| Соединение нескольких таблиц | Запросы с объединением уточняют семантический смысл данных временных рядов. Результат объединения действует как набор квалификаторов, определяющих контекст записей временных рядов. В YMatrix это реализуется с помощью оператора JOIN. |
Кросс-анализ между различными бизнес-таблицами автомобилей |
| Расширенная аналитика | Подзапросы, оконные функции, Cube, CTE, кумулятивные суммы, инкрементные вычисления, расчёт темпов роста, обнаружение точек изменения, запросы на разницу скачков сигнала, процентильные функции, операции pivot/unpivot, функции кумулятивного распределения, выражения CASE...WHEN..., скользящие окна, линейная интерполяция, обнаружение пиков, рекурсивные запросы и т.д. |
Распознавание образов, прогнозирование трендов, анализ первопричины, корректировка пороговых значений, обнаружение аномалий, послепродажный анализ неисправностей, визуализация на дашбордах, ad-hoc анализ, оповещения о состоянии батареи, оповещения о детектировании всплесков, очистка аномалий, заполнение пропущенных значений, получение top-N пиковых значений указанных метрик устройства в заданном временном диапазоне |
| Федеративный запрос | Доступ к внешним базам данных, таким как MySQL или Hive | Некоторые данные хранятся в MySQL; требуется поддержка join-запросов с этими базами. Офлайн-данные хранятся в Hive; требуется поддержка федеративных запросов с этими системами |
| Машинное обучение | Прогнозирование с помощью линейной регрессии | Использование данных с 1 по 10 января для обучения модели линейной регрессии и прогнозирования значений метрик на 11 января |
| Пространственно-временные запросы | Функция first, функция last, оконные запросы, иногда в сочетании с пространственными данными |
Начальный уровень топлива, конечный уровень топлива |
Теперь, когда вы определили требуемые шаблоны запросов к данным временных рядов и источники данных (на основе происхождения сбора данных) исходя из желаемых результатов визуализации, вы готовы перейти к формальной стадии проектирования модели — поздравляем.
Исходя из вышеизложенного, вы должны быть в состоянии оценить ключевые параметры: количество устройств, объем данных, количество метрик и типы данных. Действительно, именно эти факторы формируют ваш подход к моделированию.
| Ключевой фактор принятия решения | Описание |
|---|---|
| Количество устройств | Термин «устройство» может варьироваться в зависимости от сценария. В случае подключённых автомобилей «устройство» может означать автомобиль или датчик. |
| Тип метрики | Тип данных метрик, например int, float, text |
| Количество метрик | Общее количество или масштаб метрик |
YMatrix выделяет три ключевых фактора для моделирования временных рядов: количество устройств, тип метрики и количество метрик.
Эти факторы по-разному влияют на начальную стадию проектирования модели:
Первая статья в этой главе, Что такое модель данных временных рядов?, объясняет взаимосвязь между нереляционными и реляционными моделями и кратко описывает различия между моделями широкой, варианта широкой, узкой и варианта узкой таблиц. Этот документ сосредоточен на том, как выбрать подходящий тип модели.
Модель широкой таблицы приводит к созданию таблицы временных рядов, содержащей множество столбцов с именами и значениями метрик. В зависимости от количества метрик таблица может стать очень широкой — отсюда и название. При правильном проектировании широкие таблицы обеспечивают высокую производительность запросов. Часто встречаются таблицы с 200 и более столбцами. Ниже приведён простой пример:
| Отметка времени | ID устройства | Температура | Скорость ветра | Влажность |
|---|---|---|---|---|
| 2021-11-16 13:57:13 | 1 | 29.2 | 3.2 | 55 |
| 2021-11-16 13:57:13 | 1 | 21.5 | 8.5 | 35 |
| 2021-11-16 13:57:13 | 1 | 22.3 | 7.2 | 40 |
| 2021-11-16 13:57:13 | 2 | 24.1 | 6.8 | 21 |
| 2021-11-16 13:57:13 | 2 | 19.8 | 2.9 | 38 |
| 2021-11-16 13:57:13 | 2 | 20.7 | 4.5 | 56 |
| ...... |
Широкая таблица — одно из преимуществ YMatrix. Каждая строка содержит больше данных, при этом существует только один столбец с отметкой времени и один столбец с ID устройства (так как имеется только одна таблица метрик), что снижает избыточность. Накладные расходы на создание индексов значительно выше для узких таблиц, тогда как у широких таблиц меньше строк и, соответственно, ниже стоимость индексации, что положительно сказывается на производительности запросов. Например, для получения данных о температуре по каждому устройству можно создать справочную таблицу, сопоставляющую устройства и метрики, что обеспечит эффективные запросы к одному или части устройств.
Обеспечивает ли однотабличная широкая структура оптимальное использование хранилища? Не обязательно — это зависит от частоты записи null-значений. То, является ли столбец со значением null или нет, зависит от методов и частоты сбора данных. В сценариях с частыми записями null (также называемых сверхширокими разрежёнными таблицами) null-значения занимают значительный объём хранилища.
Добавление новых пар «имя метрики + значение» или введение новых типов значений метрик в уже спроектированную широкую таблицу не является простой задачей. Таким образом, начальные затраты на проектирование выше, чем для узких таблиц, что требует тщательного планирования. Однако после правильного проектирования такая модель обеспечивает отличную производительность запросов.
Наиболее подходит для сценариев, в которых метрики и их типы относительно фиксированы на этапе проектирования, например, в некоторых приложениях для подключённых автомобилей.
В некоторых сценариях частота запросов к различным метрикам существенно различается. YMatrix решает эту проблему с помощью рабочего процесса, сочетающего структурированные и полуструктурированные данные — вариант широкой таблицы. Данные с высокой частотой запросов и данные с низкой частотой запросов записываются по-разному — это защищает производительность запросов к "горячим" данным и сохраняет удобство записи для "холодных" данных.
«Структурированные» означают традиционное хранение в широкой таблице реляционной базы данных. «Полуструктурированные» означает использование полуструктурированного формата (JSON / MXKV) в последнем столбце существующей широкой таблицы (приближающемся к максимальному количеству столбцов) для хранения расширенных имён и значений метрик, обеспечивая гибкую масштабируемость для сверхшироких таблиц. Простой пример:
| Отметка времени | Температура | Скорость ветра | Влажность | ...... | Теги |
|---|---|---|---|---|---|
| 2021-11-16 13:57:13 | 29.2 | 3.2 | 55 | Датчик погоды, модель A, Пекин, район Хуайжоу | |
| 2021-11-16 13:57:13 | 21.5 | 8.5 | 35 | Датчик погоды, модель A, Шанхай, район Чунмин | |
| 2021-11-16 13:57:13 | 22.3 | 7.2 | 40 | Датчик погоды, модель A, Пекин, район Хайдянь | |
| 2021-11-16 13:57:13 | 24.1 | 6.8 | 21 | Датчик погоды, модель B, Пекин, район Хуайжоу | |
| 2021-11-16 13:57:13 | 19.8 | 2.9 | 38 | Датчик погоды, модель B, Шанхай, район Чунмин | |
| 2021-11-16 13:57:13 | 20.7 | 4.5 | 56 | Датчик погоды, модель B, Пекин, район Хайдянь | |
| ...... |
Структура узкой таблицы противоположна широкой. Типичной особенностью узких таблиц является наличие очень небольшого числа столбцов со значениями — обычно только одного. Ниже приведён простой пример:
| Отметка времени | ID устройства | Имя метрики | Значение метрики |
|---|---|---|---|
| 2021-11-16 13:57:13 | 1 | Температура | 29.2 |
| 2021-11-16 13:57:13 | 1 | Скорость ветра | 3.2 |
| 2021-11-16 13:57:13 | 2 | Температура | 21.5 |
| 2021-11-16 13:57:13 | 2 | Скорость ветра | 8.5 |
| ...... |
Как показано, кроме фиксированной пары «отметка времени + тег (ID устройства)», узкая таблица имеет только один столбец с именем метрики и один столбец со значением метрики. Столбец имени метрики хранит все идентификаторы метрик, а столбец значений содержит все значения метрик одного типа данных. Чтобы добавить новую метрику или устройство, просто вставьте новую строку. Если необходимо хранить дополнительные типы значений метрик, нужно либо добавить соответствующие столбцы для типов значений, либо создать отдельные таблицы. Это требует изменения схемы или создания дополнительных таблиц. В качестве альтернативы, если вы часто используете JSONB, вы можете выбрать хранение допустимых значений JSON в этом столбце, но учтите, что это создаёт дополнительные накладные расходы на парсинг JSON.
Модель узкой таблицы отлично подходит для сценариев, таких как общие IoT-системы или умный дом, где количество, категории или метрики устройств сильно неопределённы на раннем этапе проектирования. Хранение данных, их ввод и расширение модели просты — при условии, что типы значений метрик относительно однородны. Каждый новый тип значений требует создания новой таблицы с повторяющимися столбцами, кроме самого значения.
В некоторых реальных сценариях количество типов значений метрик увеличивается по мере развития бизнеса. Традиционные узкие таблицы могут масштабироваться только за счёт добавления большего количества таблиц — очевидно ограниченный подход. Поэтому можно спроектировать вариант узкой таблицы: модель, находящуюся между узкой и широкой таблицей. Основной принцип заключается в создании одного столбца на каждый требуемый тип данных. Например, если существуют два типа данных — целые числа и числа с плавающей точкой (например, float8), получаются два отдельных столбца со значениями:
| Отметка времени | ID устройства | Имя метрики | Value_int | Value_float |
|---|---|---|---|---|
| 2021-11-16 13:57:13 | 1 | Температура | 29.2 | |
| 2021-11-16 13:57:13 | 1 | Скорость ветра | 3.2 | |
| 2021-11-16 13:57:13 | 1 | Влажность | 55 | |
| 2021-11-16 13:57:13 | 2 | Температура | 21.5 | |
| 2021-11-16 13:57:13 | 2 | Скорость ветра | 8.5 | |
| 2021-11-16 13:57:13 | 2 | Влажность | 35 | |
| ...... |
Обычно такой дизайн требует дополнительной справочной таблицы:
| Имя метрики | Столбец типа данных |
|---|---|
| Температура | Value_float |
| Скорость ветра | Value_float |
| Влажность | Value_int |
При операциях записи или чтения используйте оператор JOIN для соединения двух таблиц и определения нужного столбца данных.
Для поддержки большего количества типов значений просто добавьте больше столбцов. Хотя предсказать все возможные метрики заранее трудно, предсказать все возможные типы значений легче — при условии, что вы знаете соответствие между именами метрик и их типами данных.
Примечание!
Для конкретных примеров моделирования см. Рекомендации для сценариев подключённых автомобилей и Рекомендации для сценариев умного дома.
