Этот документ является второй частью главы «Моделирование данных временных рядов». 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 table), которая отображает связь между устройством и показателем, чтобы реализовать запрос по одному устройству/частичному множеству устройств.
Если существует только одна широкая таблица, достигнута ли максимальная эффективность использования хранилища? Мы считаем, что это следует оценивать исходя из случаев, когда в конкретном бизнес-сценарии записываются пустые значения. Пустые или непустые столбцы значений зависят в первую очередь от способа и частоты фактического сбора данных показателей. На самом деле, в сценариях с большим количеством записываемых пустых данных (что мы также называем сверхширокими разрежёнными таблицами) пустые данные занимают значительный объём хранилища.
Добавление нового «списка показателей + столбца значений индекса» в спроектированную модель широкой таблицы или добавление нового типа столбца значений индекса затруднено. Поэтому начальные затраты на проектирование широких таблиц выше, чем у узких, и необходимо тщательно всё продумать. Однако, как только хорошая структура будет создана, на последующих этапах она обеспечит высокую производительность запросов.
Данный подход в основном подходит для сценариев, в которых показатели данных и их типы относительно определены на раннем этапе проектирования, например, некоторые сценарии, связанные с Интернетом вещей в автотранспорте.
В некоторых сценариях частота запросов к данным различных показателей сильно различается. В этом случае 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.
Модель узкой таблицы имеет преимущество в сценариях, где количество, категории или сами показатели оборудования на этапе первоначального проектирования весьма неопределённы. Хранение данных, запись и расширение модели при этом очень просты, однако это возможно лишь при условии, что тип значений индекса относительно однороден. Ведь каждое дополнительное значение индекса означает необходимость создания новой таблицы с избыточными столбцами, кроме самого значения индекса.
В некоторых практических сценариях тип данных значения показателя продолжает расти вместе с развитием бизнес-потребностей. В таких случаях традиционная модель узкой таблицы может быть расширена только за счёт увеличения количества таблиц. Очевидно, что такой подход сильно ограничен. Поэтому мы можем разработать модификацию узкой таблицы: её размер находится между узкой и широкой таблицей, а основной принцип проектирования заключается в создании отдельного столбца для каждого необходимого типа данных. То есть, если у нас есть два разных типа данных: целые числа и числа с плавающей точкой (предположим float8), то в итоге мы получим два различных столбца значений, как показано ниже:
| Отметка времени | ID устройства | Название показателя | Значение_показателя_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 для объединения двух таблиц и определения местоположения данных.
Если требуется больше типов значений метрик, следует добавить больше столбцов. По сравнению с необходимостью заранее знать все возможные показатели, гораздо проще заранее определить все возможные типы значений показателей, а также установить соответствие между типами значений показателей и самими показателями.
Внимание!
Примеры построения моделей в конкретных сценариях см. в разделах Пример моделирования данных в сценарии интернета транспортных средств и Пример моделирования данных в сценарии умного дома.
