Этот документ является второй частью главы «Моделирование данных временных рядов». YMatrix считает, что проектирование моделей данных напрямую влияет на ценность потребления и использования данных. Поэтому помимо технических введений, наша цель — дать вам четкое понимание концепций, применений и развития моделей данных временных рядов (Time-series Data Model) на протяжении всей этой главы.
Прежде чем создавать собственную модель данных временных рядов, прочитайте первый документ в этой главе: Что такое модель данных временных рядов?, чтобы понять взгляд YMatrix на модели данных временных рядов.
YMatrix считает, что понимание характеристик существующих запросов к временны́м рядам — ключ к выявлению основных требований текущих сценариев временных рядов. Практический сценарий временных рядов обычно имеет комплексные требования к запросам, которые могут представлять собой комбинацию нескольких различных типов запросов из таблицы ниже. Приведённые в таблице прикладные сценарии в основном основаны на примере Интернета вещей в автотранспорте.
| Характеристики запросов | Описание | Прикладные сценарии |
|---|---|---|
| Одно устройство | ||
| Точечный запрос по одному устройству | Запрос значения одного или нескольких показателей для одного устройства в определённый момент времени. Наиболее распространённый запрос — последнее значение или последнее непустое значение определённых показателей для конкретного устройства. | Реальная скорость движущегося автомобиля и т.д. |
| Детализированный запрос по одному устройству | Запрос детальных данных для конкретного устройства за определённый временной интервал, может включать один или несколько показателей | Обычно используется для дальнейшего детального анализа, например, анализа причин неисправностей в послепродажном обслуживании |
| Агрегированные значения по одному устройству | Запрос агрегированных значений определённых показателей для конкретного устройства за определённый временной интервал, таких как максимальное, минимальное, первое, последнее, среднее значения и т.д. | Средняя скорость автомобиля за определённый период времени и т.д. |
| Несколько устройств | ||
| Точечный запрос по нескольким устройствам | Запрос значений показателей нескольких устройств в определённый момент времени, может включать один или несколько показателей | Комбинированный сигнал, мониторинг состояния (например, активация механизма сигнализации при низком уровне топлива/заряда батареи); запрос показателя a и показателя b за 10 секунд до текущего момента, чтобы определить их совпадение и оценить, находится ли автомобиль в определённом состоянии (например, старение автомобиля) |
| Детализированный запрос по нескольким устройствам | Запрос детальных данных нескольких устройств за определённый временной интервал, может включать один или несколько показателей | Выявление явлений в данных. Например, анализ первопричин, отслеживание новых продуктов и т.д. Обычно ориентировано на сотрудников отделов исследований и разработок |
| Агрегированные значения по нескольким устройствам | Запрос агрегированных значений определённых показателей нескольких устройств за определённый временной интервал, таких как максимальное, минимальное, первое, последнее, среднее значения и т.д., с группировкой по устройствам | Проверка сетевого состояния по регионам, расчёт средней скорости сети, чтобы определить, испытывают ли все автомобили, прибывшие в определённое место, плохое сетевое соединение |
| Другие запросы | ||
| Многомерный запрос | Запрос последних значений, деталей или агрегированных значений устройств, удовлетворяющих определённым условиям, на основе меток или атрибутивной информации. Если задействовано несколько устройств, результаты группируются по устройствам | Мониторинг текущего состояния автомобилей |
| Соединения нескольких таблиц | Запросы с объединением нескольких таблиц могут чётко раскрыть конкретный смысл данных временных рядов. Результаты соединения нескольких таблиц могут служить набором условий, определяющих значение конкретной точки данных временного ряда. В YMatrix эта функциональность реализуется с помощью оператора JOIN |
Например, анализ взаимосвязи между различными бизнес-таблицами автомобилей |
| Расширенный анализ | Подзапросы, оконные функции, кубы, CTE, накопительные суммы, инкрементные вычисления, расчёт темпов роста, поиск точек изменения, запросы на разницу скачков сигнала, квантильные функции, преобразования строк в столбцы и обратно, функции кумулятивного распределения, выражения CASE... WHEN..., скользящие окна, линейная интерполяция, обнаружение пиков, рекурсивные запросы и т.д. |
Конкретное распознавание образов, прогнозирование трендов, анализ первопричин, коррекция пороговых значений, обнаружение аномалий, анализ неисправностей после продажи, отображение на панели мониторинга, ad-hoc анализ, предупреждения о заряде батареи, предупреждения о пиковых значениях, очистка аномальных данных, заполнение пропущенных значений, TOP N пиков указанных показателей для указанных устройств в указанном временном диапазоне и т.д. |
| Федеративные запросы | Доступ к MySQL и другим базам данных, доступ к Hive | Некоторые данные хранятся в MySQL и других базах данных, поддерживается связанный запрос с этими базами; оффлайн-данные хранятся в 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 устройства представлены только один раз (поскольку существует только одна таблица показателей), что снижает избыточность. Что касается создания индексов, то накладные расходы на индексы узких таблиц очевидны, тогда как из-за малого количества строк в широких таблицах стоимость индексов относительно невелика, что способствует производительности запросов. Для приведённого выше примера, если вы хотите получить данные о температуре для каждого устройства, вы можете разделить таблицы, создав Lookup-таблицу, которая отображает связь между устройством и показателем, чтобы реализовать запрос по одному устройству/частичному множеству устройств.
Если используется только одна широкая таблица, достигнута ли максимальная эффективность использования хранилища? Мы считаем, что это следует оценивать исходя из случаев, когда в конкретном бизнес-сценарии записываются пустые значения. Столбец значений пуст или нет, в основном зависит от способа и частоты фактического сбора данных показателей. На самом деле, в сценариях с большим объёмом записи пустых данных (что мы также называем сверхширокими разрежёнными таблицами) пустые данные занимают значительный объём хранилища.
Добавление нового «списка показателей + столбца значений индекса» в спроектированную модель широкой таблицы или добавление нового типа столбца значений индекса затруднено. Поэтому начальные затраты на проектирование широких таблиц выше, чем у узких, и необходимо тщательно всё продумать. Однако, как только хорошая структура будет создана, на последующих этапах она обеспечит высокую производительность запросов.
Основное применение — сценарии, в которых показатели данных и их типы относительно определены на раннем этапе проектирования, такие как некоторые сценарии, связанные с Интернетом вещей в автотранспорте.
В некоторых сценариях частота запросов к данным различных показателей сильно различается. В этом случае 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, Пекин, район Хайдянь | |
| ...... |
Узкая таблица устроена совершенно противоположно широким таблицам. Общей особенностью узких таблиц является наличие небольшого числа столбцов со значениями показателей, как правило, только одного. Ниже приведён простой пример модели узкой таблицы:
| Отметка времени | Идентификатор устройства | Название показателя | Значение показателя |
|---|---|---|---|
| 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 |
| ...... |
Как видно, в модели узкой таблицы, помимо фиксированной комбинации «Отметка времени + Тег (идентификатор устройства)», имеется всего один столбец с названием метрики и один столбец со значением метрики. Столбец названия метрики хранит все наименования метрик, а столбец значений — все значения метрик одного типа данных. Другими словами, если при обновлении бизнес-логики требуется добавить новые показатели или оборудование, достаточно просто добавить одну строку данных. Если же увеличивается количество типов хранимых значений показателей, необходимо добавлять столбцы соответствующих типов значений показателей или создавать отдельные таблицы для хранения других типов. Следовательно, потребуется изменять структуру таблицы или создавать дополнительные таблицы. Конечно, если вы часто используете JSONB в качестве типа данных столбца значений, можно также выбрать хранение допустимых значений JSON в этом столбце, но учтите, что это одновременно повлечёт дополнительный парсинг JSON.
Модель узкой таблицы имеет преимущество в сценариях, где количество, категории или показатели оборудования на этапе первоначального проектирования весьма неопределённы. Хранение данных, запись и расширение модели при этом очень просты, однако это возможно лишь при условии, что тип значений индексов относительно однороден. Ведь каждое новое значение индекса означает необходимость добавления новой таблицы с избыточными столбцами, кроме самого значения индекса.
В некоторых практических сценариях тип данных значения показателя будет продолжать расти вместе с развитием бизнес-потребностей. В таких случаях традиционная модель узкой таблицы может быть расширена только за счёт увеличения количества таблиц. Очевидно, что такой подход сильно ограничен. Поэтому можно разработать модификацию узкой таблицы: её размер находится между узкой и широкой таблицей, а основной принцип проектирования заключается в создании отдельного столбца для каждого необходимого типа данных. То есть, если у нас есть два разных типа данных: целые числа и числа с плавающей точкой (предположим float8), то мы получим два различных столбца значений, как показано ниже:
| Отметка времени | Идентификатор устройства | Название показателя | Значение_показателя_int | Значение_показателя_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 | |
| ...... |
При использовании такой конструкции зачастую необходимо создать дополнительную справочную таблицу:
| Название показателя | Имя столбца типа данных |
|---|---|
| Температура | Значение_показателя_float |
| Ветер | Значение_показателя_float |
| Влажность | Значение_показателя_int |
При записи или запросе конкретных значений показателей можно объединять две таблицы с помощью оператора JOIN, чтобы определить местоположение данных.
Если требуется больше типов значений метрик, добавляйте больше столбцов. По сравнению с необходимостью заранее знать все возможные показатели, гораздо проще заранее определить все возможные типы значений показателей, а также понимать взаимосвязь между типами значений показателей и самими показателями.
Внимание!
Примеры построения моделей в конкретных сценариях см. в разделах Пример моделирования данных в сценарии интернета транспортных средств и Пример моделирования данных в сценарии умного дома.
