Digital transformation är ett hett ämne för alla marknader och branscher eftersom det levererar värde med explosiva tillväxthastigheter. Tänk på att Manufacturings Industry Internet of Things (IIOT) värderades till 161 miljarder dollar med en imponerande tillväxttakt på 25 %, kommer marknaden för uppkopplade bilar att värderas till 225 miljarder dollar 2027 med en tillväxt på 17 %, eller det under de första tre månaderna av 2020 insåg återförsäljare tio år av digital försäljningspenetration på bara tre månader. Det mesta av det som skrivs har dock att göra med möjliggörande tekniska plattformar (moln- eller edge- eller punktlösningar som datalager) eller användningsfall som driver dessa fördelar (prediktiv analys som tillämpas på förebyggande underhåll, finansinstituts bedrägeriupptäckt eller prediktiv hälsoövervakning som exempel) inte den underliggande informationen. Det saknade kapitlet handlar inte om punktlösningar eller användningsfallens mognadsresa. Det saknade kapitlet handlar om data – det handlar alltid om data – och, viktigast av allt, resdata vävs från kant till artificiell intelligens.
Detta är den första i en sexdelad bloggserie som beskriver dataresan från edge till AI och affärsvärdets data producerar under resan. Dataresan är inte linjär, men den är en oändlig loopdatalivscykel – som initieras vid kanten, väver sig igenom en dataplattform och resulterar i affärsinsikter som är nödvändiga för verkliga affärskritiska problem som resulterar i nya dataledda initiativ. Vi har förenklat denna resa i fem diskreta steg med ett gemensamt sjätte steg som talar om datasäkerhet och styrning. De sex stegen är:
- Datainsamling – dataintag och övervakning vid kanten (oavsett om kanten är industriella sensorer eller människor i en fysisk butik)
- Databerikning – datapipelinebearbetning, aggregering och hantering för att göra data redo för ytterligare förfining
- Rapportering – leverera företagsinsikter (försäljningsanalys och prognoser, marknadsundersökningar, budgetering som exempel)
- Visning – kontrollera och driva viktig affärsverksamhet (ATM-transaktioner, detaljhandelsutcheckning eller produktionsövervakning)
- Predictive Analytics – prediktiv analys baserad på AI och maskininlärning (bedrägeriupptäckt, prediktivt underhåll, efterfrågebaserad lageroptimering som exempel)
- Säkerhet och styrning – en integrerad uppsättning säkerhets-, förvaltnings- och styrtekniker över hela datalivscykeln
Fig 1:Enterprise Data Lifecycle
För att illustrera dataresan har vi valt ett mycket relevant och hållbart sinnat tillverkningsämne – tillverkning av en elbil, valt för att tillverkningsverksamheten vanligtvis är revolutionerande till sin natur (hög digital mognad med de mest uppdaterade dataverktygen) , jämfört med "gammaldags evolutionär" (med lägre mognad) och att de flesta av dessa bilar är byggda som Connected Mobility-plattformar vilket gör bilen till mer än bara transport, utan en plattform för datadriven kunskap och insikt. Den här historien kommer att visa hur data samlas in, berikas, lagras, serveras och sedan används för att förutsäga händelser i bilens tillverkningsprocess med Cloudera Data Platform.
Den här historien kommer att innehålla ett falskt anslutet fordonstillverkningsföretag av elfordon som heter (med ett mycket originellt namn på) The Electric Car Company (ECC). ECC driver flera tillverkningsfabriker över hela världen, är vertikalt integrerade och bygger sina egna bilar såväl som många av de kritiska komponenterna, inklusive elmotorer, batterier och hjälpdelar. Varje fabrik har i uppdrag att tillverka olika komponenter och slutmonteringen sker i ett fåtal utvalda, strategiskt belägna fabriker.
Datainsamlingsutmaning
Att hantera insamlingen av all data från alla fabriker i tillverkningsprocessen är ett betydande åtagande som innebär några utmaningar:
- Svårigheter att bedöma volymen och variationen av IoT-data: Många fabriker använder både moderna och äldre tillverkningstillgångar och enheter från flera leverantörer, med olika protokoll och dataformat. Även om kontrollerna och enheterna kan vara anslutna till ett OT-system är de vanligtvis inte anslutna på ett sätt så att de enkelt kan dela data med IT-system också. För att möjliggöra uppkopplad tillverkning och nya IoT-användningsfall behöver ECC en lösning som kan hantera alla typer av olika datastrukturer och scheman från kanten, normalisera data och sedan dela den med alla typer av datakonsumenter inklusive Big Data-applikationer.
- Hantera komplexiteten hos realtidsdata: För att ECC ska kunna driva användningsfall för prediktiv analys måste en datahanteringsplattform möjliggöra realtidsanalys av strömmande data. Plattformen måste också effektivt inta, lagra och bearbeta strömmande data i realtid eller nästan realtid för att omedelbart leverera insikter och handling.
- Frigöra data från oberoende silos: Specialiserade processer (innovationsplattformar, QMS, MES, etc.) inom tillverkningsvärdekedjan belönar olika datakällor och datahanteringsplattformar som skräddarsys för unika siled-lösningar. Dessa nischlösningar begränsar företagets värde, med tanke på endast en bråkdel av den insikt som företagsövergripande data kan erbjuda, samtidigt som de delar upp verksamheten och begränsar samarbetsmöjligheter. Rätt plattform måste ha förmågan att ta in, lagra, hantera, analysera och bearbeta strömmande data från alla punkter i värdekedjan, kombinera den med datahistoriker, ERP, MES och QMS-källor och utnyttja den till handlingsbara insikter. Dessa insikter kommer att leverera instrumentpaneler, rapporter och prediktiv analys som driver högt värdefulla tillverkningsanvändningsfall.
- Balansera kanten: Att förstå den rätta balansen mellan databehandling vid kanten och i molnet är en utmaning, och det är därför hela datalivscykeln måste beaktas. Det finns en oroande trend i branschen då företag väljer att fokusera på det ena eller det andra utan att inse att de kan och borde göra båda. Cloud computing har sina fördelar för långtidsanalys och storskalig distribution, men den är begränsad av bandbredd och samlar ofta in stora mängder data samtidigt som den bara använder en liten del. Värdet av kanten ligger i att agera vid kanten där den har störst inverkan med noll latens innan den skickar de mest värdefulla data till molnet för ytterligare högpresterande bearbetning.
Datainsamling med Cloudera Data Platform
STEG 1:Samla in rådata
Data från ECC:s tillverkning omfattar en mängd källor – industrirobotar, kropp-i-vita fosfatbeläggningsprocesstankar (temperatur, koncentration eller påfyllning), försörjningskedjans telematik eller huvuddelinformation, etc. För detta specifika exempel, rådelen masterdata för var och en av ECC:s fem fabriker har samlats in för att kunna matas till Apache NiFi (se fig. 2).
STEG 2:Konfigurera datakällor för varje fabrik
Datainsamling kommer att illustreras med Clouderas Data Flow-upplevelse (driven av Apache NiFi) för att hämta denna rådata och för att dela upp den i individuella fabriksströmmar (hanteras av Apache Kafka) för att mer exakt likna ett verkligt scenario (se fig 2). För att göra exemplet enkelt valdes följande dataattributtaggar för varje del som genererades av fabrikerna:
- Fabriks-ID
- Maskin-ID
- Tillverkad tidsstämpel
- Artikelnummer
- Serienummer
Fig 2:Datainsamlingsflödesdiagram.
STEG 3:Övervaka datagenomströmning från varje fabrik
Med all data som nu flödar in i enskilda Kafka-strömmar, övervakar en dataarkitekt datagenomströmning från varje fabrik samt justerar beräknings- och lagringsresurser som behövs för att säkerställa att varje fabrik har den nödvändiga genomströmningen för att skicka data till plattformen.
STEG 4:Fånga data från Apache Kafka-strömmar
Kafka fångar alla fabriksdataströmmar och samlar in dem i processorer som både filtrerar och berikar för användning vid kontroll och drift av väsentliga affärsverksamheter som drivs av en operativ databas, eller levererar företagsinsikter genom ett företagsdatalager eller används i avancerad analys.
ECC har nyligen startat produktionen av en uppgraderad version av deras elmotor som endast tillverkas i Factory 5, dessa data kommer att användas som illustration av nästa steg i datalivscykeln
STEG 5:Skicka data till lagringslösningar
Eftersom ECCs tillverknings- och kvalitetsingenjörer kommer att vilja övervaka driftsättningen och fältanvändningen av denna motor, filtreras de specifika tillverkningsspårbarhetsdata till en separat rutt och sparas i sin egen tabell i Apache Hive. Detta kommer att göra det möjligt för ingenjörerna att köra ad-hoc-förfrågningar i Cloudera Data Warehouse mot data senare samt koppla dem till andra relevanta data i företagets datalager, såsom reparationsorder eller kundfeedback för att producera förhandsanvändningsfall som garanti, förutsägande underhållsrutiner eller produktutvecklingsinsatser.
Alternativt, om kontroll och drift av väsentliga affärsverksamheter önskas, kommer hela datasetet med tillägg av en bearbetad tidsstämpel att skickas till den Apache HBase-drivna Cloudera Operational Database. Dessa data kommer att fungera som grunden för ECC att driva sin inventeringsplattform, vilket kommer att kräva användning av konstanta läs-/skrivoperationer eftersom inventering kan både läggas till och tas bort tusentals gånger per dag. Eftersom HBase är designat för att hantera den här typen av datatransaktioner i stor skala, fungerar det som den bästa lösningen för denna unika utmaning.
Slutsats
Den här enkla illustrationen visar vikten av att få in data på rätt sätt, eftersom det är grundläggande för insikter som levereras från både operativa databaser, företagsdatalager eller avancerad analytisk maskininlärningsanalys. Värdet i att "få det rätt" inkluderar att använda data från vilken företagskälla som helst och på så sätt bryta ned datasilos, använda all data oavsett om den är strömmande eller batchorienterad, och möjligheten att skicka denna data till rätt plats för att producera den önskade nedströmsinsikten.
Genom att använda CDP, kan ECC-dataingenjörer och andra företagsanvändare börja använda insamlad data för olika uppgifter, allt från lagerhantering till reservdelsprognoser till maskininlärning. Eftersom Cloudera Data Flow främjar dataintag i realtid från alla företagskällor, kan det utökas och underhållas utan omfattande kunskaper om olika programmeringsspråk och proprietära datainsamlingsmetoder. Om unika problem uppstår kan ingenjörer också skapa sina egna processer för verklig, finkornig kontroll.
Leta efter nästa blogg som kommer att fördjupa sig i databerikning och hur den stödjer datalivscykelns historia. Dessutom kommer den här historien att utökas med datadrivna demos som visar dataresan genom varje steg i datalivscykeln.
Fler resurser för datainsamling
För att se allt detta i praktiken, klicka på de relaterade länkarna nedan för att lära dig mer Datainsamling:
- Video – Om du vill se och höra hur detta byggdes, se videon på länken.
- Självstudier – Om du vill göra detta i din egen takt, se en detaljerad genomgång med skärmdumpar och rad för rad instruktioner om hur du ställer in och utför detta.
- Meetup – Om du vill prata direkt med experter från Cloudera, gå med i en virtuell träff för att se en livestreampresentation. Det kommer att finnas tid för direkta frågor och svar i slutet.
- Användare – Klicka på länken för att se mer tekniskt innehåll specifikt för användare.