Временная серия Cassandra для промышленных датчиков данных

Question

В настоящее время я разрабатываю проект и исследую наилучший способ извлечения данных от промышленных заводских датчиков, подключенных к ПЛК (контроллер оборудования на заводе, например, управляющие двигатели, скорости, переключатели ...).

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

1. У меня есть несколько программируемых логических контроллеров, которые дают мне много различных значений. (Многие из этих значений являются только булевыми, а другие являются аналоговыми значениями, например, для реального типа.)

2. У меня будет более 10.000 датчиков на всей фабрике.

3. Я хочу получать данные, по крайней мере, каждую секунду для аналоговых значений (например, двигатель rmp, температура, влажность ...).

4. Для цифровых значений данные будут сохранены с меткой времени, когда появится событие.

Я хочу использовать Кассандру с таймсерами, потому что это выглядит наиболее перспективной и быстрой технологией для этого.

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

метки времени, sensor1, sensor2, sensor3, sensor4

и грести и сгруппируйте его по частям на заводе-изготовителе или лучше, что

каждый датчик имеет свою собственную таблицу

?

Вся система будет разработана на Java и предоставит данные для внешней компании для ее анализа.

Answer 1

Непонятно, каков ваш запрос. Вы указываете «Я хочу получать данные, по крайней мере, каждую секунду для аналоговых значений (например, мотор rmp, температура, влажность ...)».

Означает ли это, что вы запрашиваете каждую секунду для всех датчиков 10K? Или для конкретного датчика или для группы датчиков? В cassandra важно знать, каков ваш запрос, прежде чем смотреть на модели данных. Если вы ищете 1-секундную граничность, одним из вариантов может быть подача входящих потоков данных в Spark Streaming и сохранение кода Spark Streaming в таблицу Cassandra, которая подходит к тому, что вы хотите запросить.

Что касается вариантов, которые вы упомянули, трудно сказать, не зная точной природы ваших запросов. Наличие одного ключа, совпадающего со вторым, может быть опцией - это означает, что для каждого раздела будет иметь значение 10K или около того, при условии, что скорость передачи данных или 1/с на датчик. Наличие таблицы на датчик будет странным, но у вас может быть раздел на датчик с отметками времени для каждой записи. Это зависит от вашего запроса.

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

Answer 2

Я подозреваю, что в конце вы захотите запросить данные как с помощью датчиков, так и по времени. Нет причин, по которым у вас не было бы двух таблиц, и записывать каждую точку данных в оба. (! Twitter пишет каждый твит в другой таблице для каждого человека, который следует за твит)

Некоторые вероятными таблицы можно было бы написать это:

CREATE TABLE factory_status (
    date timestamp, 
    hour int, 
    minute int, 
    second int, 
    sensor_status_map map<uuid, float> 
    PRIMARY KEY ((date, hour, minute, second)) 
) 

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

CREATE TABLE sensor_status (
    sensor_id uuid, 
    date timestamp, 
    time timestamp, 
    sensor_val float, 
    PRIMARY KEY ((sensor_id, date), time) 
) 

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

Если у вас возникли проблемы с проектированием «с крыши вниз», не стесняйтесь использовать итеративный подход и добавлять новые таблицы, поскольку вы найдете новый запрос, который вам нужно выполнить, который не соответствует форме старых запросов ,