Езеро от производствени данни срещу хранилище за данни: Къде всъщност трябва да се съхраняват производствените данни

Ключови изводи

• Езеро за данни = необработено съхранение със схема при четене за всеки тип данни. Създадено за обхват и гъвкавост.
• Хранилище за данни = структурирано съхранение със схема при запис за курирани бизнес данни. Създадено за бързина на заявки.
• Платформи за OEE обикновено използват база за времеви серии на оперативно ниво плюс хранилище за отчети и езеро за обучение на ML модели.
• Въпросът езеро срещу хранилище е неправилен; правилният въпрос е за какво е оптимизиран всеки от тях.
• Заводите, които се опитват да съберат всичко само в едно или другото, завършват или с бавни отчети, или с скъпо съхранение.

Кратък отговор: Езерото за данни съхранява необработени данни в какъвто и да е формат, като схемата се налага при четене. Хранилището за данни съхранява курирани структурирани данни със схема, приложена при запис. Производството обикновено се нуждае и от двете: база данни за времеви серии за оперативни OEE данни, хранилище за отчети и езеро за обучение на ML модели и изследователски анализ. Опитът да се направи всичко в едно или в другото води или до бавни отчети, или до скъпо съхранение. Вижте също Аудит на качеството на производствените данни.

Какво е езеро за данни

Езерото за данни е масово съхранение за необработени данни — потоци от сензори, логове, изображения, видео, структурирани таблици, JSON документи. Схемата се налага при четене. Примери:

• Облачни обектни хранилища: AWS S3, Azure Data Lake Storage, Google Cloud Storage.
• Локално: HDFS, MinIO.

Езерото е евтино на терабайт и гъвкаво. То не е оптимизирано за SQL заявки върху структурирани данни.

Какво е хранилище за данни

Хранилището за данни съхранява структурирани данни със схема, приложена при запис. Кутирано, моделирано, индексирано за бързина на заявките. Примери:

• Облачно: Snowflake, BigQuery, Redshift, Databricks SQL.
• Локално: Teradata, Vertica, Postgres в мащаб.

Хранилищата са оптимизирани за аналитични SQL заявки. Те са по-скъпи на терабайт и изискват дисциплина при схемите.

Как се различават

Трислойна архитектура на производствените данни

Повечето производствени операции се нуждаят от три нива:

1. Оперативен слой (база данни за времеви серии). PLC тагове, данни от сензори, изчисляване на OEE в реално време. Закъснение под секунда. InfluxDB, TimescaleDB, AVEVA PI.

2. Слой за отчети (хранилище за данни). Агрегирано OEE, MTBF, MTTR по линия, по SKU, по смяна. BI табла. Snowflake, BigQuery, Redshift.

3. Аналитичен слой (езеро за данни). Необработени потоци от сензори, изображения, видео, контекстни данни. Обучение на ML модели, изследователски анализ. S3, ADLS.

Данните текат от оперативния към отчетния слой (агрегирани) и от оперативния към езерото (необработени, за по-късна употреба).

Чести архитектурни грешки

1. Едно ниво за всичко. Бази за времеви серии се затрудняват като хранилища; хранилищата се затрудняват като time-series решения; езерата се затрудняват и като двете.

2. Езеро без управление. Превръща се в блато от данни — никой не знае какво има или как да го използва.

3. Хранилище без архив на суровите данни. След като данните са агрегирани, суровият контекст се губи. Бъдещото обучение на ML модели не може да бъде възстановено.

4. Стратегия „първо езерото“. Изсипването на всичко в езеро без оперативен слой означава, че OEE отчетите не могат да работят в реално време.

Lakehouse: наскоро появило се междинно решение

Lakehouse решенията (Databricks, хибрид на Snowflake, Iceberg / Delta Lake върху обектно хранилище) се опитват да комбинират гъвкавостта на езерото с производителността на хранилището. За зрели внедрявания те стават все по-привлекателни — един слой по-малко за поддръжка.

За повечето заводи чистата трислойна конфигурация все още е по-лесна за експлоатация отколкото единствен lakehouse, който се опитва да прави всичко.

Как трябва да тече OEE данните

1. Данни от PLC/сензори → база данни за времеви серии (оперативен слой). OEE се изчислява на живо.
2. Агрегирано OEE → хранилище за данни (слой за отчети). BI таблата работят тук.
3. Необработени времеви серии → езеро за данни (аналитичен слой). Запазват се за обучение на ML модели и изследователски анализ.
4. Изходи от ML модели → база данни за времеви серии (връща се към оперативния изглед).

Чести грешки

1. Пропускане на аналитичния слой. Липсата на архива на суровите данни означава липса на данни за бъдещо обучение на ML модели.

2. Пропускане на слой за отчети. Запитванията към бази за времеви серии за BI отчети са бавни и скъпи.

3. Тясно свързване между слоевете. Пайплайни трябва да са слабо свързани, за да може всеки слой да се развива независимо.

4. Липса на отговорник за данните. Без собственик, както езерото, така и хранилището се влошават.

Как се вписва модерна OEE платформа

Модерна OEE платформа управлява оперативния слой и се интегрира с хранилището и езерото на техния ръб. Платформата съхранява временни серии за OEE в реално време, експортира агрегати към хранилището и архивира суровите данни в езерото.

OEE модулът на Fabrico управлява оперативния слой с родно съхранение на времеви серии, експортира агрегати към стандартни хранилища (Snowflake, BigQuery) и архивира сурови данни в обектно хранилище за ML и изследователска употреба.

Вижте как Fabrico улавя това автоматично — разгледайте OEE за производството или заявете демонстрация.

Свързано четене

• Аудит на качеството на производствените данни
• OEE за партидно производство
• MQTT в производството
• Параето диаграма в производството

Често задавани въпроси

Трябват ли ми и езеро, и хранилище за данни?

Повечето производствени обекти се възползват от и двете. Малки операции могат да се справят само с хранилище за данни и база за времеви серии.

Дали lakehouse е същото като да имаш и двете?

Принципно — да, но на практика технологията все още зрее. Трислойните конфигурации са по-изпитани в практиката.

Къде се вписва historian?

Historian представлява оперативния слой (база данни за времеви серии). Езерото и хранилището стоят над него.

Мога ли да правя машинно обучение върху хранилището за данни?

За агрегирани данни — да. За необработени потоци от сензори или изображения — езерото е по-практично.

Колко данни трябва да съхранява езерото?

Колкото можете да си позволите. Езерото е евтино; бъдещите случаи на използване на стари данни са непредсказуеми.