Najważniejsze wnioski
Krótka odpowiedź: Jezioro danych przechowuje surowe dane w dowolnym formacie, stosując schemat podczas odczytu. Hurtownia danych przechowuje przetworzone, ustrukturyzowane dane ze schematem stosowanym przy zapisie. Produkcja zwykle potrzebuje obu: sklepu szeregów czasowych dla operacyjnych danych OEE, hurtowni do raportowania i jeziora do trenowania modeli ML i analiz eksploracyjnych. Próba robienia wszystkiego w jednym lub drugim prowadzi do wolnych raportów albo drogich kosztów przechowywania. Zobacz także Audyt jakości danych produkcyjnych.
Jezioro danych to magazyn masowy dla surowych danych, strumienie sensorów, logi, obrazy, wideo, złożone tabele, dokumenty JSON. Schemat stosowany jest przy odczycie. Przykłady:
Jeziora są tanie za TB i elastyczne. Nie są zoptymalizowane pod zapytania SQL na danych ustrukturyzowanych.
Hurtownia danych przechowuje dane ustrukturyzowane ze schematem stosowanym przy zapisie. Dane są wyselekcjonowane, wymodelowane i zaindeksowane pod kątem wydajności zapytań. Przykłady:
Hurtownie są zoptymalizowane pod analityczne zapytania SQL. Są droższe za TB i wymagają dyscypliny w zakresie schematu.
| Właściwość | Jezioro danych | Hurtownia danych |
|---|---|---|
| Schemat | Przy odczycie | Przy zapisie |
| Rodzaje danych | Dowolne | Ustrukturyzowane |
| Koszt za TB | Niski | Wyższy |
| Szybkość zapytań (dla danych ustrukturyzowanych) | Wolna bez optymalizacji | Szybka |
| Najlepsze do | Uczenie maszynowe, eksploracja | BI, raportowanie |
Większość operacji produkcyjnych potrzebuje trzech warstw:
1. Warstwa operacyjna (baza danych szeregów czasowych). Tagi PLC, dane z czujników, obliczanie OEE w czasie rzeczywistym. Opóźnienia poniżej sekundy. InfluxDB, TimescaleDB, AVEVA PI.
2. Warstwa raportowa (hurtownia danych). Agregowane OEE, MTBF, MTTR według linii, SKU, zmiany. Pulpity BI. Snowflake, BigQuery, Redshift.
3. Warstwa analityczna (jezioro danych). Surowe strumienie sensorów, obrazy, wideo, dane kontekstowe. Trenowanie modeli ML, analizy eksploracyjne. S3, ADLS.
Dane przepływają z warstwy operacyjnej do raportowej (w formie agregowanej) oraz z warstwy operacyjnej do jeziora (surowe, do późniejszego wykorzystania).
1. Jedna warstwa dla wszystkiego. Bazy szeregów czasowych słabo radzą sobie jako hurtownie; hurtownie jako magazyny szeregów czasowych; jeziora jako oba, też mają problemy.
2. Jezioro bez zarządzania. Zmienia się w „bagno danych”, nikt nie wie, co tam jest ani jak z tego korzystać.
3. Hurtownia bez archiwum surowych danych. Po agregacji kontekst surowy jest tracony. Przyszłe trenowanie modeli ML nie da się odtworzyć.
4. Strategia „najpierw jezioro”. Wrzucanie wszystkiego do jeziora bez warstwy operacyjnej oznacza, że raportowanie OEE nie może działać w czasie rzeczywistym.
Lakehouse’y (Databricks, hybryda Snowflake, Iceberg / Delta Lake na magazynach obiektów) próbują połączyć elastyczność jeziora z wydajnością hurtowni. Dla dojrzałych wdrożeń są coraz bardziej atrakcyjne, jedna warstwa mniej do utrzymania.
Dla większości zakładów czysta, trójwarstwowa konfiguracja nadal jest łatwiejsza w eksploatacji niż pojedynczy lakehouse próbujący zrobić wszystko naraz.
1. Pomijanie warstwy analitycznej. Brak archiwum surowych danych oznacza brak danych do trenowania ML w przyszłości.
2. Pomijanie warstwy raportowej. Zapytania do bazy szeregów czasowych w celu raportowania BI są wolne i kosztowne.
3. Silne sprzężenie między warstwami. Potoki danych powinny być luźno powiązane, aby każda warstwa mogła rozwijać się niezależnie.
4. Brak opiekuna danych. Bez właściciela zarówno jezioro, jak i hurtownia degraduje się.
Nowoczesna platforma OEE obejmuje warstwę operacyjną i integruje się z hurtownią oraz jeziorem na styku. Platforma przechowuje dane szeregów czasowych dla OEE w czasie rzeczywistym, eksportuje agregaty do hurtowni i archiwizuje surowe dane do jeziora.
Moduł OEE Fabrico obsługuje warstwę operacyjną z natywnym magazynem szeregów czasowych, eksportuje agregaty do standardowych hurtowni (Snowflake, BigQuery) i archiwizuje surowe dane w magazynach obiektów dla potrzeb ML i analiz eksploracyjnych.
Zobacz, jak Fabrico robi to automatycznie, poznaj OEE dla produkcji lub umów się na demo.
Większość zakładów produkcyjnych korzysta z obu rozwiązań. Małe operacje mogą poradzić sobie mając tylko hurtownię i magazyn szeregów czasowych.
Z zasady tak, w praktyce technologia wciąż dojrzewa. Trójwarstwowe konfiguracje są bardziej przetestowane w boju.
Historian to warstwa operacyjna (baza szeregów czasowych). Jezioro i hurtownia znajdują się nad nią.
Dla danych agregowanych, tak. Dla surowych strumieni sensorów lub danych obrazowych praktyczniejsze jest jezioro danych.
Tak dużo, ile stać firmę. Jeziora są tanie; przyszłe przypadki użycia starych danych są nieprzewidywalne.
Kluczowe wnioski - Jezioro danych = surowe, schema-on-read przechowywanie dowolnego typu danych. Zbudowane dla szerokości i elastyczności. - Hurtownia danych = ustrukturyzowane przechowywanie z zastosowanym schematem przy zapisie (schema-on-write) dla przetworzonych danych biznesowych. Zbudowane pod kątem wydajności zapytań.
- Platformy OEE zwykle używają magazynu szeregów czasowych na warstwie operacyjnej, hurtowni do raportowania i jeziora do trenowania modeli ML. - Pytanie „jezioro czy hurtownia” jest niewłaściwe; właściwe pytanie brzmi, do czego każde rozwiązanie jest zoptymalizowane. - Zakłady, które próbują umieścić wszystko w jednym z nich, kończą z powolnymi raportami lub drogim przechowywaniem.
Krótka odpowiedź: Jezioro danych przechowuje surowe dane w dowolnym formacie, a schemat stosowany jest przy odczycie. Hurtownia danych przechowuje przetworzone, ustrukturyzowane dane, a schemat stosowany jest przy zapisie. Produkcja zazwyczaj potrzebuje obu: bazy szeregów czasowych dla operacyjnych danych OEE, hurtowni dla raportowania i jeziora dla treningu ML i eksploracji.
Próba robienia wszystkiego w jednym albo drugim skutkuje albo wolnymi raportami, albo drogim przechowywaniem. Czym jest jezioro danych Jezioro danych to magazyn masowy dla surowych danych, strumienie z czujników, logi, obrazy, wideo, ustrukturyzowane tabele, dokumenty JSON. Schemat stosowany jest przy odczycie.
Przykłady: - Obiektywne magazyny w chmurze: AWS S3, Azure Data Lake Storage, Google Cloud Storage. - On-premises: HDFS, MinIO. Jeziora są tanie za TB i elastyczne. Nie są zoptymalizowane pod kątem zapytań SQL na danych ustrukturyzowanych. Czym jest hurtownia danych Hurtownia danych przechowuje ustrukturyzowane dane ze schematem stosowanym przy zapisie.
Dane są przygotowane, wymodelowane i indeksowane pod kątem wydajności zapytań. Przykłady: - W chmurze: Snowflake, BigQuery, Redshift, Databricks SQL. - On-premises: Teradata, Vertica, Postgres na dużą skalę. Hurtownie są zoptymalizowane pod analityczne SQL. Są droższe za TB i wymagają dyscypliny schematu.
Jak się różnią Cecha / Jezioro danych / Hurtownia danych - Schemat: przy odczycie / przy zapisie - Typy danych: dowolne / ustrukturyzowane - Koszt za TB: niski / wyższy - Prędkość zapytań (dla danych ustrukturyzowanych): wolno bez wsparcia / szybko - Najlepsze do: ML
eksploracji / BI, raportowania Trójwarstwowa architektura danych w produkcji Większość operacji produkcyjnych potrzebuje trzech warstw: 1. Warstwa operacyjna (baza szeregów czasowych). Tag’i PLC, dane z czujników, obliczanie OEE w czasie rzeczywistym. Opóźnienia poniżej sekundy. InfluxDB, TimescaleDB, AVEVA PI. 2. Warstwa raportowania (hurtownia danych). Zagregowane OEE, MTBF, MTTR według linii, SKU, zmiany. Kokpity BI.
Snowflake, BigQuery, Redshift. 3. Warstwa analityczna (jezioro danych). Surowe strumienie z czujników, obrazy, wideo, dane kontekstowe. Trening ML, analizy eksploracyjne. S3, ADLS. Dane przepływają z warstwy operacyjnej do raportowania (w formie agregatów) oraz z warstwy operacyjnej do jeziora (surowe, do późniejszego wykorzystania). Typowe błędy architektoniczne 1. Jedna warstwa do wszystkiego.
Bazy szeregów czasowych słabo sprawdzają się jako hurtownie; hurtownie nie radzą sobie jako magazyny szeregów czasowych; jeziora nie radzą sobie dobrze w obu rolach. 2. Jezioro bez zarządzania. Staje się „bagiennym” jeziorem danych, nikt nie wie, co tam jest ani jak tego użyć. 3. Hurtownia bez archiwum surowych danych. Po agregacji kontekst surowy ginie.
Przyszły trening ML nie będzie możliwy do odtworzenia. 4. Strategia „lake-first”. Wrzucenie wszystkiego do jeziora bez warstwy operacyjnej oznacza, że raportowanie OEE nie może działać w czasie rzeczywistym. Lakehouse: ostatnie rozwiązanie pośrednie Lakehousy (Databricks, hybryda Snowflake, Iceberg/Delta Lake na obiektowym magazynie) próbują połączyć elastyczność jeziora z wydajnością hurtowni.
Dla dojrzałych wdrożeń są coraz atrakcyjniejsze, jedna warstwa mniej do utrzymania. Dla większości zakładów czyste trójwarstwowe podejście jest wciąż łatwiejsze w eksploatacji niż jedno lakehouse próbujące robić wszystko. Jak powinny przepływać dane OEE 1. PLC/dane z czujników → baza szeregów czasowych (warstwa operacyjna). OEE obliczane na żywo. 2. Zagregowane OEE → hurtownia danych (warstwa raportowania).
Tutaj działają kokpity BI. 3. Surowe szeregi czasowe → jezioro danych (warstwa analityczna). Przechowywane do treningu ML i analiz eksploracyjnych. 4. Wyniki modeli ML → baza szeregów czasowych (zasilanie widoku operacyjnego). Częste błędy 1. Pomijanie warstwy analitycznej. Brak archiwum surowych danych oznacza brak danych do późniejszego treningu ML. 2. Pomijanie warstwy raportowania.
Zapytania bezpośrednio do baz szeregów czasowych dla raportów BI są wolne i kosztowne. 3. Ścisłe sprzężenie między warstwami. Pipeline’y powinny być luźno powiązane, aby każda warstwa mogła ewoluować niezależnie. 4. Brak opiekuna danych. Bez właściciela jezioro i hurtownia z czasem ulegają degradacji.
Jak wpisuje się nowoczesna platforma OEE Nowoczesna platforma OEE zarządza warstwą operacyjną i integruje się z hurtownią oraz jeziorem na styku. Platforma przechowuje szeregi czasowe dla OEE w czasie rzeczywistym, eksportuje agregaty do hurtowni i archiwizuje surowe dane do jeziora.
Moduł OEE firmy Fabrico zarządza warstwą operacyjną z natywnym magazynem szeregów czasowych, eksportuje agregaty do standardowych hurtowni (Snowflake, BigQuery) i archiwizuje surowe dane do obiektowego magazynu dla ML i analiz eksploracyjnych. Najczęściej zadawane pytania Czy potrzebuję zarówno jeziora, jak i hurtowni? - Większość zakładów produkcyjnych korzysta z obu.
Małe operacje mogą wystarczyć mieć tylko hurtownię i bazę szeregów czasowych. Czy lakehouse to to samo, co posiadanie obu? - Z zasady tak; w praktyce technologia wciąż dojrzewa. Rozwiązania trójwarstwowe są bardziej sprawdzone. Gdzie pasuje historian? - Historian to warstwa operacyjna (baza szeregów czasowych). Jezioro i hurtownia stoją nad nią.
Czy mogę robić ML w hurtowni? - Dla danych zagregowanych, tak. Dla surowych strumieni z czujników lub danych obrazowych bardziej praktyczne jest jezioro. Ile danych powinno przechowywać jezioro? - Tak dużo, ile na to stać. Jeziora są tanie; przyszłe przypadki użycia dla starych danych są nieprzewidywalne.
Zaloguj
Blog
