빅데이터는 가장 중요한 loT 실현 기술 중 하나로 여겨진다. 이 장에, 우리는 M2M과 loT 어플리케이션을 위한 빅(그리고 그다지 ‘크지’ 않은) 데이터 관리에 대해 이야기할 것이다. 이것은 복잡한 주제이고 두루 적용되도록 만든 해결책이 없기 때문에, 우리는 다른 복잡성의 시나리오부터 이야기해나감으로써 점차적으로 대화를 구성해나갈 것이다. 그러나, 이에 다다르기 전에, 우리는 빅데이터 동향에서 가장 존경받는 권위자인 Cloudera의 설립자이자 최고 전략 전략책임자인 Mike Olson과 얘기함으로써 발판을 마련할 것이다.

Dirk Slama: Mike, Cloudera는 가장 널리 사용되는 빅데이터 체계 중 하나인 Apache Hadoo를 담당하고 있습니다. 당신이 본 것 중 가장 흥미로운 당신의 기술을 사용한 loT 사용 경우에 대해 설명해주실 수 있습니까?

Mike Olson: 그럼요. 당신이 CERN의 Large Hadron Collider(LHC)를 당신에 책에서 케이스 스터디 중 하나로 언급했습니다. 그리고 어떻게 LHC가 단지 광대한 양의 센서 데이터를 수집했을 뿐만 아니라, 실험으로부터 데이터를 위한 효과적이고 여러 단계로 작동하는 정보 루트를 만들어나가고 있는지도요. 밝혀졌듯이, Nebraska-Lincoln대학교에서 이런 작동 정보 루트의 2단계에서 적어도 연구 시설들 중 하나는 Hadoop을 이용하고 있습니다. 그들은 CERN에서 입자 충돌로부터 발생되는 방대한 양의 데이터에서 심화된 물리 분석을 이행하기 위해 이것을 사용하고 있습니다.

또한 많은 흥미로운 연구들이 존재합니다. 예를 들어, 스마트 그리드는 분명히 빅테이터 기술을 이용한 중요한 loT 어플리케이션입니다. 그리고 우리는 Hadoop이 많은 회사들에서 사용되고 있다는 것을 압니다. 좋은 예시는 Opower로, 그들의 자동계량으로부터 스마트 그리드 관찰 스트리밍을 사용, 관찰 및 분석하길 원하는 유틸리티에 그들의 서비스를 판매하고 있습니다. 자동 계량은 매 6초마다 관찰을 기록하고 있으며, 이는 수집하기 위해 사용했던 한달 마다 측정했던 것보다 대단히 많습니다. 이것은 그들이 하루 동안 요구되는 잘 정제된 신호를 성립한다는 것을 의미합니다. 그들은 심지어 세탁기를 켜거나 냉장고가 켜졌다는 것 같은 명확한 사건이 언제 발생하는지도 결정할 수 있습니다. 예를 들어, 그들은 실제 시간에서 요구를 관찰할 수 있고, 이런 관찰의 변동을 예측합니다. 이는 단지 스마트 그리드 활동에 기초하지 않고, 기창 예측, 보고 그리고 다가오는 기념일이나 이벤트에 기초하기도 합니다. 그들은 심지어 요구를 관리하기 위해 예를 들면 고객이 그들의 사용이 이웃의 비교되는 것을 알게 하고, 사람들이 경쟁을 하도록 유도하는 것과 같이, 게임화(gamification- 게임과 무관한 웹사이트나 어플리케이션에서 게임과 연관된 개념을 활용하는 것)를 이용할 수도 있습니다.

매우 다양한 범위의 사용 케이스가 있지만, 보통 모든 이런 데이터들은 기계 도량에서 기계와 센서에 의해 발생합니다. 오래된 기술을 사용하여 이것을 모으고 분석하는 것은 도전입니다. 거대하고, 도량을 벗어난 기반은 이런 자료의 과정과 분석을 훨씬 저렴하게 만들어줍니다.

Dirk Slama: 그래서, 이전 세대의 컴퓨터 사용과 데이터 관리에 의해 직면되지 않았던 어떤 도전을 loT가 선사합니까?

Mike Olson: 제 개인적인 견해는 우리는 오직 매우 이른 단계의 loT 데이터 흐름만을 보고 있으며, 이런 데이터 흐름들은 거의 압도적입니다. 한 달에 한번과 1분에 10번 읽은 것으로부터 스마트 그리드로부터 스트리밍되는 정보의 양을 생각해 봅시다. 이것은 한 달 동안 미터당 150,000배 많은 관찰 입니다. 이런 데이터 용량은 가속화되도록 보장되어 있습니다. 미래에, 우리는 더 많은 기기로부터 더 잘 정제된 데이터를 모으고 있을 것입니다.

샌프란시스코 도시를 살펴보면, 일부 사람들은 도시 내에 스마트폰이나 차뿐만 아니라, 공기압, 온도, 진동 등을 측정하는 도시의 높은 빌딩들과 같이 많은 곳에서 사용하는 센서가 20억개라고 측정합니다. 현재 이런 센서에서 가장 흥미로운 점은 그들의 대부분이 네트워크에 연결되어있지 않다는 것입니다. 저는 앞으로 반 세기 내로 그들의 대부분이 네트워크에 연결되고, 그런 기기 들은 네트워크나 메쉬 연결 센서로 교환될 것이라고 생각합니다. 그리고 이것은 확실한 쓰나미 데이터를 가져올 것입니다. 그래서 이러한 데이터를 측정하고, 가공하고, 요약하고, 관리하고 분석할 수 있는 시스템을 고안하는 것이 IT의 큰 도전입니다. 우리는 우리가 보려던 것과 같은 정보의 호수를 한번도 본 적이 없습니다.

Dirk Slama: 그래서, loT를 현실로 만드는 데이터 관리에 핵심 발전이 있을 것입니까?

Mike Olson: 우리는 오늘날 10년전에는 없던 계산 플랫폼과 도량을 넘어선 저장을 만들고 있습니다. 우리는 그것의 도량에서 정보를 모으지 않았고, 우리가 지금 하는 것과 같이 분석하려고 하지 않았기 때문에 그들을 필요로 하지 않았었습니다. 기계에서 발생한 데이터의 도래가 우리에게 어떻게 데이터를 측정, 저장, 가공해야 하는지 재고하게끔 하고 있습니다. 매우 대규모의 유사한 계산 시스템을 만드는 것은 현재 매우 흔한 일입니다. 우리가 만일 앞으로 5년에서 10년의 발전을 살펴본다면, 소프트웨어의 상태는 계속 개선될 것입니다. 우리는 더 나은 분석 알고리즘, 도량을 넘어선 저장 아키텍처를 갖고 있을 것이며, 적은 디스크 공간을 관리할 수 있을 것입니다. 왜냐하면 우리는 어떻게 데이터를 입력하고 복제해야 하는지 더 잘 알고 있을 것이기 때문입니다.

그러나 제가 생각하기로 가장 흥미로운 것은 하드웨어에서의 발전입니다. 모바일 기기나 일반적인 환경에서 네트워크와 연결된 센서들의 계속 확산하거나 폭발적으로 증가할 것입니다. 이는 많은 양의 새로운 데이터를 생산할 것입니다. Intel의 Atom Chip-Line이나 다른 판매 회사의 비슷한 것들을 생각해 보십시오. 데이터 측정/저장/분석 면에서, 우리는 도량을 넘어선 기반이 더 잘 구축된 칩들을 볼 것입니다. 메모리 밀도는 당연히 증가할 것이며, 우리는 많은 어플리케이션에서 디스크를 대체하는 고체 드라이브를 사용할 것입니다. 칩의 단계에서 네트워킹 접속은 더욱 빠르고 흔해질 것이며, 주로 칩 레벨에서 가능한 전기를 이용한 네트워크를 대신해서 광학 저장을 사용할 것입니다. 메모리에 디스크인 저장에서의 상대적인 잠복은 이동할 것이고, RAM에 고체 상태의 디스크는 미래에 더 보편적인 방법이 될 것입니다. 광학 네트워크의 속도는 저장공간을 더욱 접근 용이하게 이동시킬 것입니다. 그래서 저는 하드웨어 단계에서 이전에 가능했던 그 어떤 것보다 더 많은 데이터와 함께할 소프트웨어를 실현할 많은 혁명을 보게 될 것이라고 생각합니다.

Dirk Slama: 빅데이터를 사용하는 loT 솔루션을 구축하고 싶은 회사들에게 가장 큰 위험 요소은 무엇입니까? 어떻게 이런 위험 요소를 경감시킬 수 있습니까?

Mike Olson: 데이터를 측정하고, 정제하고 분석하는 기반뿐만 아니라, 센서 네트워크의 도량을 넘어선 확산과 같은 종류의 데이터를 발생하는 기술은 새롭습니다. 우리의 경험은 이 개념의 작은 범위에서 입증에서 시작하는 것이 현명하다는 것이었습니다. 수백만 개의 기기를 대신해서, 아마도 수천 개의 기기에서 시작해 보십시오. 그리고 이를 처리할 수 있는 측정 및 정제 기반을 만드십시오. 이렇게 함으로써 당신은 이것이 잘 작동하는지 체크할 수 있으며, 어떻게 이런 시스템이 작동하고, 무엇을 할 수 있는지에 관해 당신의 사람이나 조직을 교육시킬 수 있습니다. 이것들은 새로운 기술이며 새로운 기술의 채택은 성공적인 배치를 위해 교육과 새로운 과정을 요구합니다. 무한한 범위의 loT를 실행하기 전에 작은 범위에서 이것을 배우는 것은 중요합니다.

우리는 loT기술에 매료된 많은 사람들과 이야기합니다. 그들은 그것 자체로의 빅데이터에 흥분합니다. 그들은 우리가 일하기에 좋지 않은 사람들입니다. 왜냐하면 그들은 근본적으로 사업적인 문제에서 동력을 얻지 않기 때문입니다. 당신이 loT가 왜 중요한지에 대해 생각하기 시작할 때, 이는 매우 중요합니다. 어떤 질문에 당신은 센서 데이터 스트리밍으로 답하고 싶습니까? 어떤 비즈니스 문제를 해결하고 싶습니까? 어떤 최적화를 만들어내고 싶습니까? 그리고 이런 문제들을 제기하기 위한 당신의 시스템을 고안하십시오. 저는 새로운 기술을 활용하고 싶은 엔지니어들의 ‘샤이니 오브젝트 신드롬’을 가진 사람들 중 하나이지만, 그런 프로젝트들은 보통 명확한 기준이 없기 때문에 실패합니다.

Dirk Slama: 당신에게 빅데이터 기술을 사용할 때라고, 혹은 사용하지 말라고 말해주는 명확한 지표가 있습니까?

Mike Olson: 만약 당신이 전통적인 거래 프로세싱이나 OLAP 작업량을 갖고 있다면, 우리는 당신에게 Oracle, SQL Server, Terra Date등을 가리킬 것입니다. 왜냐하면 이런 시스템들은 저런 형태에서 작업하도록 발전했기 때문입니다. 새로운 데이터 양이나 새로운 분석 작업은 빅데이터 기술이 가장 잘 적용될 수 있는 곳입니다. 목표가 ‘우리는 존재하던 기반을 치워 버리고 이것을 Hadoop으로 교체하고 싶어요’일 때, 우리는 보통 그런 기회를 떠납니다. 이런 것은 잘 적용될 수 없습니다. 만약 당신이 새로운 문제나 사업 추진, 그리고 새로운 데이터 양를 만나면, 이들이 가장 성공적인 경우입니다. 떼어내고 교체하고자 하는 거대하고 눈이 먼 욕구는 절대 성공하지 않습니다.

Dirk Slama: 이런 지표들을 정량화할 수 있습니까? 빅데이터 기술을 요구하기 위한 데이터는 얼마나 커야 합니까?

Mike Olson: 산업이 빅데이터에 대해 이야기할 때, 그들은 항상 양, 다양성, 속도에 대해서 이야기 합니다. 이것은 당신이 매우 큰 양의 데이터를 가질 수 있고, 당신이 절대 한번에 모아볼 수 없었던 매우 다른 종류의 데이터를 가질 수 있고, 혹은 당신이 격정적인 속도로 도착하는 데이터를 가질 수 있다는 것을 의미합니다. 우리가 볼 때 Vs에 적합하지 않지만, 당신이 반드시 이용해야 할 분석 알고리즘인 하나의 기준이 있습니다. 이것은, 당신이 데이터에 이행하고 싶은 계산 방식은 무엇인가? 입니다. 때때로 당신이 적당한 양의 데이터를 기반으로 매우 많은 계산을 필요로 한다면, Hadoop같은 도량을 넘어서는 기반은 타당합니다. 양, 다양성, 속도 혹은 컴퓨터를 사용한 복잡함 필요조건들 중 하나만 만족시키면 빅데이터 기반을 매력적으로 만들기에 충분합니다. 우리의 경험해서, 만약 당신이 저런 필요 조건들 중 두 개 이상을 갖고 있다면, 새로운 플랫폼은 치명적입니다.

Dirk Slama: 빅데이터와 loT의 이행과 전략을 개발하고 있는 독자들에게 해주고 싶은 충고가 있습니까?

Mike Olson: 함께 일하는 조직에 하는 제 일관된 충고는 사업을 위해서 성공적인 결과가 의미 있는 한, 두 개의 사용 사례를 갖고 적정한 범위에서 공격해 보라는 것입니다. 이로 인해 당신은 필요한 기술을 얻고, 기술이 실제로 문제를 해결해 준다는 것을 입증할 수 있을 것입니다. 한번 이를 해두면, 주어진 기반에서 큰 범위도 간단하게 일관적인 가격으로 적용되고, 성공적일 것입니다.

Dirk Slama: 누가 loT와 빅데이터로부터 가장 많이 그리고 적게 얻을 수 있는 위치에 있습니까?

Mike Olson: 제 진심 어린 확신은 데이터는 실질적으로 모든 인간의 노력 범주에서 변형된다는 것입니다. 그래서, 당신과 제 일생에서, 우리는 암을 위한 치료법을 찾을 것입니다. 왜냐하면 우리는 이전에 할 수 없었던 방법으로 유전적이고 환경적인 데이터를 분석할 수 있기 때문입니다. 농업 사회에서 깨끗한 물과 에너지의 생산과 분배로 우리는 70억 대신 90억명의 사람들에게 배급할 수 있는 더 조밀하고 나은 농작물을 키울 수도 있습니다. 모든 노력에서, 데이터는 효율성을 제공할 것입니다. 만약 기업들이 기회를 놓친다면, 그들은 경쟁에서 질 수도 있습니다.

최근 사생활과 Edward Snowden, NSA에 관하여 많은 논란이 있었습니다. 제가 가진 하나의 염려는 이런 예시들 때문에 우리가 부당한 반발을 가질 수 있다는 것입니다. 그러나 예를 들어 우리가 매우 정교하게 학생의 행동을 관찰할 수 있다면, 그리고 각 학생의 학습 양식에 맞춰 수업을 고안할 수 있다면 얻을 수 있는 장점에 대해서 생각해봅시다. 우린 그 어느 때보다도 빠르고 효과적으로 배울 수 있는 똑똑한 사람들을 갖게 될 것입니다. 우리가 가져올 건강관리의 질에 관해서 생각해 보십시오.

사생활은 중요하고, 앞으로도 중요할 것입니다. 우리는 사생활을 타당하게 보장하는 정교한 정책, 의미 있는 법과 처벌이 필요합니다. ‘데이터 지니’는 병에서 나온 것 과 같습니다. 저는 우리가 이를 다시 되돌릴 수 있다고 생각하지 않습니다. 보통, 저는 데이터의 생산과 수집을 축소하기 위해 시도하는 것은 실수라고 생각합니다. 왜냐하면 저는 이것이 우리 사회에서 대단히 좋은 기회라고 믿기 때문입니다.

파트 2(“Ignite | IoT 방법론”)의 Plan/Build/Run 부분에서 다뤘듯이, 배포된 loT 어플리케이션 지형 내에서 다른 데이터 종류들 사이의 관계와 분배를 이해하는 것은 중요하다. 아래의 자료는 loT 환경 내에서 발견되는 가장 보편적인 데이터 종류의 개요를 제공한다. 멀리 떨어진 자산으로부터 오는 데이터는 보통 미터 데이터, 센서 데이터, 사건 데이터 및 비디오 데이터 같은 멀티미디어 데이터를 포함한다. 자산에 업로드된 데이터는 대부분 구성 데이터, 작업 지시, 기상 예측 같은 의사결정 맥락, 그리고 다양한 멀티미디어 파일을 포함한다. 말미에서, 멀리 떨어진 자산으로부터 오는 데이터들은 보통 정해진 loT나 M2M 데이터 저장소에서 관리된다. 이 저장소들은 미터 기록의 모음 같은 시간 연속 데이터뿐만이 아니라, 기본적인 자산 데이터와 기기데이터, 상태 데이터, 상태 변화 기록 등을 포함한다. 쓸만한 여러 종류들로 이루어진 기업 어플리케이션 지형의 경우와 같이, 일부는 불필요할 수 있는 자산 관련 데이터를 포함한 다른 어플리케이션이 대부분이라는 것은 아무런 가치가 없다. 예를 들어, ERP 시스템은 고객 계약 데이터를 비롯하여 판매 시간에 제품 배치에 관련된 모든 데이터를 포함한 Asset Master Data를 갖고 있는 경향이 있다. 하나 이상의 티켓 관리 시스템이 구체적인 자산에 관련된 고객 문의들을 포함한다. 이런 데이터들을 하나의 전체적인 자산의 관점으로 합치는 것은 보통 도전적인 일이다. 덧붙여, 다른 시스템들에는 고객 거래 기록, 고객의 사회적 데이터, 상품 데이터를 포함한 많은 관련된 데이터들이 있을 것이다.

Data & analytics in the context of Enterprise IoT

이 데이터를 기반으로 효율적인 어플리케이션을 구축하는 것은 이질적인 기업 어플리케이션 랜드스케이프에서 만큼이나 어려우며, EAM (기업 아키텍처 관리), EAI (기업 어플리케이션 통합), SOA (서비스 지향 아키텍처), BPM (비즈니스 프로세스 관리)와 같은 잘 확립된 접근법을 통해 다뤄질 수 있다 [EBPM]. 이는 우리가 다음 장에서 살펴볼 내용이다.

IoT 데이터를 이해하는 것은 효율적인 분석을 필요로 한다. 이는 우리가 다음에서 볼 것처럼, 빅데이터에만 적용되는 것이 아니다. 분석에는 다양한 유형이 있다. 일부 분석은 단순히 과거 사건을 검토하지만, 좀 더 향상된 분석 유형은 미래의 사건 및 발전을 예측하기 위해 과거 데이터를 활용하려고 시도한다. 기본 분석은 다음을 포함한다.

• 기술적 분석: “무엇이 일어나고 있는가?” (예: 엔진이 작동을 멈추었다)
• 진단적 분석: “왜 일어났는가?” (예: 결함 있는 볼트 때문에)

발전된 미래 지향적 분석은 다음을 포함한다.

• 예측적 분석: “무슨 일이 일어날 것 같은가?” (예: 언제 엔진이 작동을 멈출 것 같은가?)
• 지시적 분석: “이러한 일을 미연에 방지하기 위해 무엇을 해야 하는가?” (예: 고장나기 전에 볼트를 교체한다)

모든 IoT 솔루션이 위의 데이터 유형과 분석 유형을 모두 활용하는 것은 아니다. 사실 데이터 관리 아키텍처 및 선택된 툴이 정말로 필요한 것에 한정되도록 하는 방법을 이해하는 것은 프로젝트 관리자에 매우 중요하다. 다음에서 볼 수 있는 바와 같이, 다른 기술들을 결합하는 좋은 방법이 있기에, 최소 기능 제품 (MVP) 철학으로 시작하는 것은 의미가 있다. 물론, 예를 들어 관계형 대 NoSQL에서 오른쪽 핵심 데이터 관리 기술을 선택하는 것은 신중한 분석에 기초해야 한다.

Ignite | IoT 방법론을 사용하는 IoT 프로젝트 관리자가 데이터 관리를 위한 올바른 아키텍쳐와 기술을 더 쉽게 확인할 수 있도록하기 위해서, 우리는 네 가지 기본 시나리오를 정의했다. 우리는 점차적으로 IoT 데이터 관리 아키텍처와 기술의 다양한 옵션에 대한 논의를 구성하기 위해 이러한 시나리오를 사용할 것이다.

시나리오 A는 비교적 간단하다. 필드에 적당한 수의 자산 (1~2천개의 자산)을 가정하며 각 시간과 자산 당 들어오는 사건의 수는 매우 적다. 분석은 기본적인 보고와 기술적인 분석으로 한정된다. 우리는 이 시나리오를 “기본 M2M”이라고 부른다.

시나리오 B는 필드에 수십만 개의 자산 및 자산에서 들어오는 많은 양의 데이터를 가진 실제 기업 IoT 솔루션을 가정한다. 이 프로젝트의 초기 초점은 자산으로부터의 데이터 스트림을 분석하고 중요한 사건에 “실시간”으로 반응하는 것에 있다 (완전한 실시간이 아닌 예를 들어 1초 이내). 우리는 이 시나리오를 “기업의 IoT 및 CEP”라고 부르며, CEP는 복잡한 사건 처리 (Complex Event Processing)를 의미한다.

시나리오 C는 오랜 기간 동안 대규모로 필드 데이터를 저장하기 위한 요건을 추가하는 시나리오를 토대로 한다. 기본적인 기술적 분석 및 잠재적으로 진단적 분석이 이 데이터에서 수행될 것이다. 시나리오 D는 시나리오 C의 연장선으로, 예측 및 지시적 분석과 같은 더 향상된 분석이 추가된다.

모든 네 가지 시나리오의 요약은 아래 도표에서 찾을 수 있다.

                        Overview of 4 IoT data management scenarios
                        

시나리오A의 일반적인 어플리케이션은 모바일 산업 기계 집단 등에 대한 원격 장비 모니터링이다. 제한된 수의 상태 업데이트 및 사건은 시간이 지남에 따라 각 기계에 대해 예상된다. 기본적인 보고는 기계 상태 개요, 기계 활용 등을 보여줄 것이다. 아키텍쳐는 보통 비교적 백엔드가 간단할 것이다. 초기의 어려움은 대부분 자산의 통합 및 자산에 필요한 장치 인터페이스를 가지는 것에 초점을 맞출 것이다 (IoT 게이트웨이에 대한 기술 프로파일 논의 참조). 아래 그림은 시나리오 A의 AIA를 보여준다.

                        Architecture for data management in basic M2M

기술 선택의 관점에서, 어떤 데이터 저장소가 자산과 필드 데이터를 관리하기 위해 사용되어야 하는지, 그리고 어떤 인터페이스 기술이 원거리 자산을 통합하느데 사용되어야 하는지에 대한 두 가지 핵심 결정이 이루어져야 한다.

데이터 저장소의 경우, RDBMS와 NoSQL를 포함하는 많은 상이한 옵션이 있다. 많은 일반적인 M2M 어플리케이션 플랫폼은 RDBMS 기술을 기반으로 하고 있으며, 이는 대부분의 경우 완벽하게 잘 작동한다. 하나의 장점은 백업 관리에의 보고로부터 관련 도구의 풍부한 생태계를 기반으로 한다는 것이다. 또한, 대부분의 조직은 RDBMS 기반의 솔루션을 구축하고 운영하는 데 필요한 기술을 지닐 것이다.

그러나, 시간이 지남에 따라 시나리오가 확장될 가능성이 있는 경우, 예를 들어 조금 더 복잡한 어플리케이션이 개발되거나 분석 요건이 향후 좀 더 진보된 시계열 분석을 포함할 가능성이 있는 경우, 솔루션 설계자는 대신 NoSQL 데이터베이스를 고려하는 것이 낫다.

두 번째 기술 결정은 자산의 통합과 그것으로부터 스트리밍되는 다른 데이터 및 사건의 관리에 관한 것이다. M2M 또는 IoT 어플리케이션 플랫폼이 사용되는 경우, 이 기능이 내장될 가능성이 높다. 맞춤형 발전의 경우, 여러 옵션이 있다. 아주 기본적인 어플리케이션에서는 어플리케이션 서버 또는 NodeJS와 같은 기본 사건 처리 기술이 사용될 수 있다. 정립된 메시징 및 대안 적으로 또는 추가로 사용될 수 있는 관련 기술의 부족함이 없다. 마지막으로, MQTT와 같은 일부 IoT에 특화된 메시징 솔루션이 등장하기 시작했으며, 이는 그들의 특정 성격 때문에 추가적인 혜택을 제공해야 한다. 아래 그림은 개요를 제공한다.

                          Basic event processing technologies
                          

시나리오 B는 필드에서 훨씬 많은 자산을 다루고 있다고 가정하거나, 자산이 백엔드에 훨씬 많은 양의 데이터를 제공하고 있다고 가정하거나, 둘 모두를 가정한다.

이 시나리오에서 데이터 스트림에의 밀접한 모니터링이 종종 필요하며, 특정 유형의 상황에 신속하게 반응하는 능력 또한 필요하다. 대부분의 경우, 실시간으로 특정 패턴의 데이터 스트림을 분석할 필요가 있으며, 그 예로 온도의 급격한 증가를 들 수 있다.

이러한 경우에 매우 유용할 수 있는 하나의 기술은 복잡 사건 처리 (CEP)이다. CEP는 다수의 데이터 스트림으로부터의 데이터는 비지니스 수준에서 특정 의미를 갖는 패턴을 추론하기 위해 추적되고 분석될 수 있다. 빨간색으로 바뀌는 신호등과 동시에 도로를 건너는 보행자가 그 패턴의 예이다. 따라서, 하나의 흥미로운 CEP 사용 사례는 센서 데이터 융합의 영역에 있다 (IoT 게이트웨이 기술 프로파일 참조). CEP의 전반적인 목적은 관련 사건의 비즈니스 로직을 식별하고, (거의) 실시간으로 그들에 응답 할 수 있게 되는 것이다.

Oracle의 프로젝트 관리 감독자인 Robin Smith는 우리를 위해 다음과 같이 CEP의 기본 사건 패턴을 요약했다.

필터링

• 데이터 스트림은 200F 미만의 온도 등 특정 범위에 대해 필터링된다. 상관 관계 및 집계
• 스크롤링, 지난 3일간 평균 맥박수 등의 시간 기반 창문 지표 패턴 맞추기
• 15분 내에 일어나는 기계 사건 A, B, C 등 감지된 사건 패턴의 알림 지리, 예측 모델링 및 그 외
• 지리적 움직임 패턴의 즉각적 인식, 데이터 마이닝 알고리즘을 사용하는 과거 비지니스 지능형 모델의 어플리케이션

아래 그림은 CEP의 기본 원칙을 보여준다.

Basic principle of CEP

사례: 지속적 문의 언어 (CQL)

CEP에서 사건 흐름을 분석하는 잘 정립된 방법의 한가지 좋은 예는 표준 SQL 언어의 확장인 지속적 문의 언어 (CQL)이다. CEP을 지원하기 위해 시각적 모델러를 이용하는 많은 도구를 포함하여 많은 다른 방법이 있다. 우리는 기본 원리를 설명할 수 있도록 우리의 예로 CQL을 사용할 것이다.

Oracle의 프로젝트 관리 감독자인 Robin Smith는 다음과 같이 CQL을 설명한다.

• CQL은 필터링, 분할, 집계, 상관 관계 (스트림에 걸쳐) 그리고 스트리밍 및 관계 데이터에 일치하는 패턴을 조회
• CQL은 스트림의 개념, 관계와 스트림 사이의 매핑을 위한 사업자, 패턴 매칭의 확장을 추가하여 표준 SQL을 확장
• 원도우 사업자 (예를 들어 RANGE 1 MINUTE)는 스트림을 관계로 변환

아래의 간단한 예는 선택된 스트림에 데이터를 전송하는 모든 온도 센서에 대한 마지막 순간의 평균 온도를 계산한다.

SELECT AVG(temperature) AS avgTemp, tempSensorId
FROM temperatureInputStream[RANGE 1 MINUTE]
GROUP BY tempSensorId

CEP 및 IoT

IoT의 맥락에서, CEP는 자산 또는 백엔드, 또는 둘 모두에 배치될 수 있다. 아래 그림은 후자를 보여준다. 자산에 CEP를 배포하는 것은 (경계가 흐려질 수 있기 때문에, 게이트웨이와 자산 상 비지니스 로직 모두를 포함하는 것으로 여기서 보여진다) 많은 사건이 지역적으로 이용되거나 (자산 자율성) 백엔드로 전달 (사건 전달)되기 전에, 미리 필터링되거나 결합 (센서 융합)될 수 있다는 장점을 갖는다. 또한, 상황에 맞는 데이터 (날씨 예보 등)는 의사 결정 과정에 보다 쉽게 추가될 수 있다.

                             CEP and Enterprise IoT
                             

사례 연구: Emerson

Emerson은 제품을 제조하고 광범위한 산업, 상업 및 소비자 시장에 대한 엔지니어링 서비스를 제공하는 미국의 다국적 기업이다.

The Emerson Trellis™ 플랫폼은 재고 관리, 현장 관리 및 전력 관리를 결합한 데이터 센터 인프라 관리 솔루션이다. 이 솔루션은 저장 장치, 서버, 전원 시스템 및 냉각 장치에 연결하는 로컬 게이트웨이 기기를 사용한다. CEP는 데이터 집계, 필터링, 대규모 환경에서의 실시간 의사 결정을 지원하는 처리를 위한 이 솔루션에서 사용된다. 아래 그림은 솔루션 구조의 개요를 제공한다.

                              Emerson Trellis Platform (Source: Oracle)
                              

시나리오 C는 솔루션이 매우 큰 데이터 규모로 장기 자산 데이터 분석을 수행할 수 있어야 한다고 가정한다. 여기에서, 경계는 종종 명확하지 않다. 많은 CEP 시스템은 매우 큰 데이터 볼륨으로 확대될 수 있을 것이다. 그러나, 다음에서 볼 수 있는 것처럼, 빅 데이터는 볼륨 이상의 것이다.

빅데이터

빅데이터에 대한 많은 서로 다른 정의가 있으며, 보통 지속적으로 진화하는 개념으로 이해해야 한다. 빅데이터는 일반적으로 정보를 이용하기 위한 의도로 저장되어 반 구조화, 구조화 및 비 구조화 된 매우 많은 양의 데이터를 의미한다. 빅데이터를 “빅데이터”라고 간주하도록 하는 특정 숫자가 있는 것은 아니지만, 일반적으로 페타 바이트, 아니면 엑사 바이트의 데이터를 의미한다. 이러한 ERP 및 CRM 등의 전통적인, 대규모 기업 어플리케이션은 보통 테라 바이트 수준에 아른다.

빅데이터의 원동력은 전통적으로 구글, 페이스북 등의 대형 인터넷 기업이었다. 예를 들어, 구글의 엔지니어들은 데이터 및 문의가 수천 개의 서버에 분산될 수 있게 만드는 MapReduce의 초기 개념을 정교화했다. 야후와 같은 다른 회사와 함께, 이 개념은 지금 Cloudera (이 챕터의 시작 부분에서 인터뷰 참조)와 Hortonworks와 같은 스타트업 회사에서 지원하는 Hadoop이라는 오픈 소스 상품으로 구현되었다. 이 분야에서 틀림없는 선도 기업인 구글은 또한 Flume과 MillWheel을 기반으로 한 Cloud Dataflow와 같은 차세대 기술을 도입했다.

사용되는 기술에 관계없이, 빅데이터는 기존 RDBMS/OLAP 시장에 많은 변화를 가져왔다. 주요 변화 중 하나는 빅데이터가 고도로 구조화된 유형에서 완전히 비구조화된 유형까지, 많은 다른 유형의 데이터를 관리하는데 매우 적합해졌다는 점이다.

이 인프라를 기반으로, 예를 들어, 새로운 Data Lake 개념은 기업들에게 생각을 거꾸로 뒤집을 것을 제안한다. 먼저 데이터베이스 구조를 정의하고, 그 다음 이 구조에 맞는 데이터를 채우는 것이 아니라, Data Lake는 단순히 모든 종류의 데이터를 저장하고나서, 필요할 때, 필요한 형식으로 이 데이터를 활용한다. Doug Laney (Gartner)는 많은 사람들이 가장 짧고 일반적인 빅데이터의 정의라고 생각하는 내용에 대한 설명을 처음 제공한 공로가 있다. 그 정의는 3 V로, 양 (volume: 많은 양의 데이터를 처리), 속도 (velocity: 거의 실시간으로 빠른 속도의 데이터 흐름을 처리), 다양성 (variety: 다양한 형태의 데이터를 처리) 이다. 어떤 사람들은 빅데이터 “V”에 변화성 (variability 또는 불일치)과 정확성 (veracity: 데이터 품질)를 추가하기도 한다.

기본 분석

빅데이터의 기본 분석은 일반적으로 기술적, 진단적 분석을 포함한다. 기술적 통계는 그룹화 또는 필터링된 데이터 세트에 적용될 수, 합계, 평균, 백분율, 최소 및 최대값, 간단한 연산을 포함한다.

어떤 사람들은 사업 분석의 80 %가 기술적 분석이며, 특히 소셜 미디어 분석이 그러하다고 주장한다 [LI1]. 예시는 페이지 뷰, 게시물 수, 언급, 팔로워, 평균 응답 시간 등을 포함한다.

많은 IoT 프로젝트의 탐구적 성격 때문에, 많은 프로젝트가 처음에 이러한 기술적 분석 (작동 장치의 MTBF (실패 사이의 평균 시간) 등의 통계 분석과 같은 것들에 대한)에 의존할 것이라 가정할 수 있다. 진단적 분석은 또한 기본 IoT 데이터 분석에 중요한 역할을 할 것이다. 몇몇 작동 장치에 문제가 발생한 경우, 신속하게 그것을 해결하기 위해 가능한 한 빨리 근본 원인을 식별할 수 있는 것이 중요 할 것이다.

문제 상황에의 NoSQL 추가

비구조화된 빅데이터 저장소 외에도, 문서 지향의 NoSQL 데이터베이스 또한 IoT의 맥락에서 중요한 역할을 하기 시작한다. 다음에서 우리는 IoT, NoSQL, 빅데이터의 주요 측면을 MongoDB 의 CEO인 Max Schireson과의 인터뷰를 통해 논의해볼 것이다. MongoDB는 NoSQL 데이터 관리를 위한 오픈 소스 데이터베이스를 선도하고 있다..

Dirk Slama: 무엇이 오늘날의 IoT 현실에서 빅데이터를 만들고, 어떻게 NoSQL가 이에 적합하게 됩니까?\

Max Schireson: 지난 5년 동안, 우리가 지난 30년 동안 본 것보다 더 많은 데이터 관리에 발전이 있었습니다. 범용 컴퓨팅, 오픈 소스 기술 및 클라우드의 성장으로, 데이터를 수집, 저장, 처리, 분석하는 것이 매우 저렴해졌습니다.

이러한 발전은 작동 작업량을 제공하는 NoSQL 데이터베이스와 분석 작업량을 제공하는 Hadoop의 출현을 보았으며, 이는 일반적으로 기존 기술들을 보완합니다.

데이터 저장 및 처리 요건처럼 확장성 벽에 충돌하는 대규모 웹 자산으로부터 등장한 이러한 많은 개념은 관계형 기술의 한계를 빠르게 성장시킵니다. 그들은 또한 그들 데이터의 대부분이 깔끔한 행과 열 형식에 적합하지 않아서, 쉽게 관계형 데이터 모델에서 표을 사용하여 관리할 수 없다는 사실을 발견했습니다. 어플리케이션 요건은 급진적으로 변화했고 정적 관계 스키마는 개발자의 민첩성을 방해했습니다. 이는 IoT에서 설계자와 개발자가 직면하고 있는 문제입니다. 자체 데이터 센터 또는 클라우드에서, 저가의 범용 서버와 로컬 스토리지의 집단에 NoSQL 데이터베이스와 Hadoop 클러스터를 확장할 수 있는 능력은, 설계자로 하여금 수십억 개의 센서에 의해 생성된 데이터 볼륨에 관한 문제를 해결할 수 있게 합니다. MongoDB에 의해 사용되는 문서 모델 등 새로운 데이터 모델은 설계자들로 하여금 사건에서 시계열 데이터, 지리적 좌표, 텍스트, 다형성 2진법 데이터까지 구조화된 데이터뿐만 아니라, 반구조화, 비구조화, 다형성 데이터 또한 저장 및 처리 할 수 있게 합니다.

병렬 프로그래밍의 발전은 계산할 데이터를 이동하여 시간과 비용을 들이기 보다는, 데이터 계산 자체를 이동시켜 복잡한 알고리즘이 클러스터 주위로 분배되도록 하였습니다. 이것은 우리가 이전보다 빠르게 훨씬 더 많은 양의 데이터를 분석 할 수 있음을 의미합니다. 우리가 데이터를 저장, 처리 및 분석하는 방법에서의 이러한 근본적인 변화는 IoT에 데이터 관리를 위한 기반을 제공한다.

Dirk Slama: 최신 데이터베이스는 loT에서 무슨 역할을 합니까? 전통적인 데이터베이스가 여전히 맡고 있는 역할이 있습니까?

Max Schireson: 오늘날의 많은 NoSQL 데이터베이스는 loT어플리케이션의 가동적인 부분을 담당합니다. 센서 데이터는 NoSQL 데이터베이스에 의해 수집되고 저장됩니다. NoSQL 데이터베이스 내에서 이것은 온라인 보고 대시보드에 제공하고 행동을 유발하기 위해서, 종종 어플리케이션 미들웨어 내에 만들어진 사업 규칙을 사용하여 조회되고 평가됩니다.

소매 업계에서의 예시를 살펴보면, 상점 내 신호의 네트워크는 상점 내 고객의 위치를 식별할 수 있으며 그들에게 공지를 전송합니다. 예를 들어, 사용자는 구매 목록을 자신의 스마트폰에 작성하고 이것을 운용 데이터베이스에 저장하는 상점 어플리케이션과 공유할 수 있습니다. 상점에 들어갈 때, 상점 어플리케이션은 고객에게 구매 목록에 있는 상품이 강조되어있는 지도를 보여줍니다. 구매 목록에 있던 상품 군이 진열된 위치에 다가가면, 어플리케이션은 고객에게 이것을 알리고 특정 브랜드를 추천해줍니다. 또다시, 그 추천 목록은 운용 데이터베이스에 저장됩니다. 계산하는 지점에서, 시스템은 RFID를 이용해서 장바구니에 있는 모든 물품을 자동적으로 인식하고 영수증을 만들며, 스마트폰으로 결제를 진행합니다. 계산 과정이 끝나면, 가게의 재고 시스템이 자동으로 갱신됩니다.

이 시나리오에서, NoSQL 데이터베이스는 실시간으로 가게 내 고객의 움직임을 저장하고 제품의 정보와 함께 추천을 제공합니다. 더 많은 전통적인 관련 데이터베이스가 청구서 및 송장 발부 관리를 위해 NoSQL 데이터베이스와 결합하여 사용될 수 있습니다. 그래서, 관련 데이터베이스는 종종 새로운 loT 어플리케이션에 통합된 말미의 기업 시스템에서 ‘기록 시스템’의 역할을 하기도 하며, 여전히 loT 어플리케이션에서 사용되고 있습니다.

Dirk Slama: loT에서 Hadoop이 맡은 역할은 무엇입니까? 전통적인 EDW가 아직 역할을 보유하고 있습니까?

Max Schireson: 이는 예시를 통하여 가장 잘 설명됩니다. 위에서 언급한 소매상 사용을 진행할 때, 고객의 모든 행동은 NoSQL 데이터베이스 내에 저장됩니다. 그리고 나서, 소셜 미디어나 축적 고객 데이터로부터 의견을 구매하는 웹로그의 클릭 스트림같이, 다른 소스와 함께하는 데이터와 결합된 Hadoopd로 로딩됩니다. 이 모든 데이터 요소들은 고객이 다시 상점을 방문했을 때 실시간 추천을 제공하기 위해서, NoSQL 데이터베이스에 다시 로딩될 수 있는 심화된 행동 모델을 만듭니다.

관련된 데이터베이스처럼, EDW는 새로운 데이터 소스를 지원할 규모의 용량이 제한되어 있으며, 데이터 모델이 대답하기에 구체적으로 설계되어있지 않은 탐사적인 질문을 다루는 데에 효과적이지 않습니다. 이들은 EDW를 대체하기보다는 보조하기 위해 배치된 Hadoop에 의해 제기된 문제입니다. Dirk Slama: loT데이터 라이프사이클을 관리하기 위해 이런 최신 데이터베이스와 Hadoop 기업 데이터 허브를 어떻게 통합했습니까?

Max Schireson: loT 설계가 NoSQL데이터베이스나 Hadoop과 통합할 수 있는 데에는 구매 스크립트부터 상품화되고 지원된 연결기까지, 여러 방법이 있습니다. 후자의 예시는 Hadoop에 쓰인 MongoDB 연결기입니다. 이는 Apache Hadoop과 선두적인 산업 유통 모두에 적합합니다. Hadoop을 위한 MongoDB 연결기는 사용자들이 Hadoop플랫폼 및 그 기능과 함께 MongoDB 로부터 실시간 데이터를 통합하도록 해줍니다. 연결기는 Hadoop job(MapReduce, Hive, Pig, Impala 등)이 MongoDB로부터 데이터를 HDFS에 복제하지 않고 바로 읽도록 하여, Hadoop 데이터 소스로써 MongoDB를 제공합니다. 그렇게 함으로써, 시스템 사이의 데이터 TB를 이동할 필요가 없어집니다. Hadoop job은 필터로 질문을 통과하여, 모든 목록을 살펴볼 필요가 없고 프로세싱을 빠르게 만듭니다. 또한 MongDB의 문자와 공간 정보를 포함한 색인 기능을 이용할 수도 있습니다. 연결기는 Hadoop job이 존재하는 서류의 증가한 최근 정보를 포함하여 MongoDB에 되돌아가 기록되는 것을 가능하게 합니다. 추가로, MongoDB는 이것 자체로 Hadoop과 같은 물리적 클러스터에서 운영될 수 있기 때문에, 두 플랫폼 사이에는 아주 긴밀한 통합이 발생합니다.

Dirk Slama: 이런 새로운 loT데이터 설계에서 스트림 프로세싱이 하는 역할이 무엇입니까? 여기서 성립된 CEP 개념이 어떻게 적용된다고 생각하십니까?

Max Schireson: 센서, 기기 혹은 자산으로부터 스트림될 때, 존재하는 CEP뿐만 아니라 Apache Strom와 Apache Spark같은 스트림 프로세싱이 결과에 예민하거나 자동화된 행동을 유발하면서 loT데이터에 충돌할 수 있습니다. CEP는 일반적으로 패턴을 찾고 사업 규칙을 적용시키기 위해 데이터를 다수의 소스와 연결시키는, 잘 입증되고 발달된 기술입니다. 이 데이터와 규칙들은 운용 데이터베이스에 저장됩니다. Spark나 Storm같은 스트림 프로세싱은 더욱 최근 의 발달이며, 일반적으로 하나의 데이터 스트림을 작동시키고, 또 일반적으로 데이터, 규칙, 행동을 작동시킵니다. 모두 사용 사례나 개발자 기술에 따라서 loT에서 역할을 갖고 있습니다.

Dirk Slama: 통찰력을 얻거나 새로운 프로세스를 자동화시키기 위해 어떻게 loT데이터를 분석하십니까? Hadoop, 데이터베이스, 센서 데이터 스트림에서 이루어집니까?

Max Schireson: 이는 세가지 모두에서 이루어질 수 있습니다. 분석은 정보 루트를 가공하는 원 데이터를 사용한 데이터베이스에서 조정되는 실시간 프로세스나 항공(스트림)내의 데이터에 충돌할 수 있습니다. 또, 다양한 소스로부터 받아들여진 데이터를 저장하는 Hadoop에서도 충돌할 수 있습니다.

그래서 이전의 소매업 예시로 돌아가보면, 스트림 분석은 고객이 상점에서 나가는 것을 감지합니다. 데이터베이스는 고객의 상세 정보를 검색하고 이를 선호도나 상품 판촉에 맞춥니다. 고객의 활동과 구매는 추적되고, 데이터베이스에 저장된 후 이 새로운 데이터가 분석 모델을 조정하는데 사용되는 Hadoop에 로딩됩니다. 이 데이터는 다시 데이터베이스로 로딩되고, 고객이 재방문 했을 때, 더 적절한 제안이 제공됩니다.

빅 데이터 인프라 구축

시나리오 C는 자산 데이터 스트림의 실시간 분석 대신, 이런 ‘수명이 짧은’ 데이터에 장기 패턴 분석을 수행하기 위해 데이터를 더 오래 유지하는 것을 원한다고 가정한다. 이 시나리오는 스트림 프로세싱과 결합된 빅 데이터 기반을 구축하는 것에 중점을 두고, 이 데이터를 분석하기 위해 사용될 수 있는 몇 가지 기본적인 알고리즘을 소개한다.

Pentaho의 최고 상품 책임자인 Christopher Dziekan은 설명한다. “모든 사람들은 종종 빅데이터의 세가지 V인 양, 다양성, 속도 (Volume, Variety, Velocity)를 지적하며 데이터 (혹은 빅 데이터)를 거대한 가치와 자산으로 바꾸는 것을 염려합니다. 이 V들은 구조적으로 변화를 추진합니다. 그러나, 기업들이 그들의 빅 데이터 기반을 제작하면서 더 많은 V들이 시행됩니다. 빅 데이터 기반은 처음 세 V에 필요한 반응이지만 정확성 (Veracity)과 가치 (Value) 또한 동등하게 고려되어야 합니다.” 빅 데이터의 모든 V를 포함하기 위해서는 큰 범위의 상품 배치를 가능하게 하는 구조와 방법론을 살펴봐야 한다.

정보를 전략적인 장점으로 바꾸려면, 사업 분석과 데이터 통합을 결합시키는 빅 데이터 ‘조직화’ 플랫폼이 필요하다. loT 기기로부터 발생된 데이터를 관련된 데이터와 새로운 데이터 소스 모두와 조합하면서 발전된 분석 기술이 적용된다. 영업부문과 운영상의 결정을 지지하면서 영향을 주려는 순간에 보편적으로 가능하도록, 플랫폼은 존재하는 IT 기반에 적합해야 하며 사업 어플리케이션에 연결되어야만 한다. loT 시스템과 적용하여 다른 사용자 집단의 분석적인 필요를 조사하면서, 우리는 어떠한 도구나 저장소도 완벽하게 모든 사용자의 필요에 맞지 않다는 것을 볼 수 있다. 일부는 전통적인 데이터 시장과 데이터 창고를 필요로 한다. 어떤 이들은 정제 공장에 덧붙여, 즉석 데이터 기반에 요구되는 ‘데이터 강’ 저장소를 필요로 할지도 모른다. 또 다른 이들은 기기 상태를 분석하고, 스트리밍 문의를 실행하고, 공지를 알리기를 원한다. 여전히 어떤 이들은 즉석 데이터 변형과 그들의 데이터 과학자들을 위한 특별한 도구의 배열을 필요로 한다.

이러한 다양한 요건을 감안할 때, 우리는 어떻게 모든 요구를 충족시키는 데이터 아키텍처를 구축할 수 있을까? 우선 우리는 전체 아키텍처를 관리할 수 있게 하는 도구의 집합 또는 플랫폼이 필요하다.

Lambda 아키텍쳐

하나의 엔진에 일부 이러한 요소를 결합하는 한 가지 방법은 Nathan Marz에 의해 도입된 Lambda 아키텍처라고 알려져 있다. Lambda 아키텍처는 기록 데이터를 모두 저장하는 “배치 층”과 실시간으로 데이터를 처리하는 “속도 층” 및 다른 두 가지 층을 모두가 조회되도록 허용하는 “서빙 층”으로 구성되어 있다.

                           Lambda Architecture (Source: Ricky Ho [RH1])
                           

우리는 모든 층이 잘 수행되기를 원하기 때문에, 이름 “배치 층”은 Pentaho의 James Dixon에 의해 만들어진 용어 “데이터 호수”로 여겨지는 것이 낫다 [FO1]. 그리고 속도 층은 “실시간 층”으로 생각되어야 한다.

Lambda 아키텍처는 IoT 시스템에 대한 데이터 아키텍쳐의 몇 가지 문제를 해결하지만, 명시 적으로 모든 기기의 상태를 저장하거나 조회할 수 있는 방법을 제공하지 않는다.

IoT 데이터 아키텍쳐

Lambda 아키텍처는 IoT 시스템을 만들기 위한 지도 원칙으로 사용될 수 있다.

IoT and big data – integration perspective (based on input from Pentaho)

다이어그램에서 당신은 IoT 데이터 아키텍처가 실시간 층, 데이터 호수/기록 층, Lambda 아키텍처의 문의 층을 포함하고 있는 것을 확인할 수 있다. 또한 상태 층 및 융합/변환/정제/ 데이터 마트 층을 보유하고 있다.

Pentaho의 James Dixon은 그의 “상태의 조합” 개념에서 상태 층과 데이터 호수 사이의 중요성을 정교화했다. 이 주제에 대한 블로그 포스트에서 Dixon은 어플리케이션의 데이터의 주요/일반적인 영역뿐만 아니라, 초기 상태와 모든 속성의 변화를 포착할 것을 권장한다. 그는 모든 증가하는 변화 및 사건을 저장하여, 상태 로그의 각 자체 데이터 호수와 함께 여러 어플리케이션에 이 방법을 적용할 것을 주장한다. 이는 “상태의 조합”과 시간에 걸쳐 기업에서 (잠재적으로) 모든 비지니스 어플리케이션의 모든 영역의 상태를 포착하는 결과를 낳는다.

이 접근법은 많은 상황에 적용될 수 있다. 예를 들어, 전자 상거래 업체는 과거에 어떤 특정 순간 동안, 몇 개의 쇼핑 카트가 열려 있는가, 그 안에는 무엇이 있었는가, 어떤 거래가 진행 중인가, 어떤 항목이 박스 포장되거나 이동 중인가, 무엇이 반품되었는가, 누가 일하고 있는가, 얼마나 많은 고객 센터 전화가 대기 중이고 진행 중인 것은 몇 개인가를 알아낼 수 있었을 것이다. 본질적으로, 이 방법은 추세 분석 및 규정 준수 등의 프로세스를 지원한다.

지금까지, Lambda 아키텍처 제품 또는 그것으로의 IoT 확장을 제공하는 어플리케이션 또는 도구가 만들어지지 않았다. 이는 IoT 구현 팀이 IoT 시스템의 능력, 효율성 및 효과성을 극대화하기 위해, 설계 시 고려해야 하는 것이다.

빅데이터 관리 및 IoT를 위한 인프라가 구축되고 나면, 다음 단계는 데이터가 분석되는 정교함의 수준을 증가시키는 것이다. 이는 예측적 진단적 분석을 포함한다. 진단적 분석이 최적화된 결과를 달성하기 위해 행동을 인도하려 시도하는 반면, 예측적 분석은 미래의 사건 및 발전에 대해 예측하기 위해 기록 데이터를 사용한다.

많은 사람들이 실제로 IoT에서 이러한 매우 중요 시나리오를 참조한다. 특히, 산업 IoT 시나리오는 크게 예측적 요지 보수 등의 사용 사례로부터 이익을 얻는다.

이러한 사용 사례들의 복잡성 때문에, 많은 기업이 필요한 사업과 이러한 사용 사례를 지원하는데 필요한 기술 자문, 데이터 분석 스킬을 결합하는 데이터 과학자처럼, 새로운 직업 역할을 찾고 있다.

예측적 분석은 모델링, 기계 학습 및 데이터 마이닝 등의 여러 상이한 기술을 포함한다.

기계 학습

Tapio Torikka 박사는 Bosch Rexroth의 상태 모니터링 프로덕트 매니저이다. 다음에서 그는 [ML1]과 [ML2]를 기반으로 하는 예측적 분석의 중요 요소인 기계 학습에 대한 설명을 제공한다.

기계 학습은 알고리즘이 예측을 위해 입력 데이터에 기초한 모델을 구축하는 인공 지능의 분야이다. 명쾌함 없이 프로그램된 지침은 영역 지식이 없거나 거의 없는 경우 문제가 해결될 수 있도록 하는 모델을 만드는 데 사용된다. 아래 그림은 기계 학습 알고리즘을 훈련하고 적용하는 과정을 도시한다. 데이터가 선택된 소스로부터 취득된 후, 예를 들어 그 데이터를 확장하고 누락 값을 입력함으로써, 데이터를 사전 처리해야 한다. 사전 처리 후, 특징 추출 단계는 후속 훈련 단계를 향상시키기 위해 데이터로부터 의미 있는 정보를 추출한다. 훈련 단계 동안 훈련 알고리즘은 자체를 향상시키기 위해 기계 학습 모델의 내부 파라미터를 조정하는데 사용된다. 원하는 정확성 또는 소정 트레이닝 시간에 도달하면, 모델을 저장되고 나중에 미지 데이터로 예측을 위해 사용될 수 있다.

                         Machine learning (Source: Bosch Rexroth)
                         

학습 유형은 다음과 같다.

• 지도 학습
o 분류된 훈련 데이터가 분류 모델을 구축하는데 사용된다.
o 예시 어플리케이션: “보통”과 “스팸” 사이의 이메일 분류
• 자율 학습
o 데이터 구조가 분류 없이 학습된다.
o 예시 어플리케이션: 신용 카드 사기 탐지
• 준 지도 학습
o 적은 양의 분류된 데이터, 많은 양의 분류되지 않은 데이터
o 예시 어플리케이션: 이미지 인식. 적은 양의 수동으로 분류된 인터넷에서 이용 가능한 이미지, 많은 양의 분류되지 않은 인터넷에서 이용 가능한 이미지

분류된 예시 데이터 (제시된 입력 데이터에 대해 바라는 산출물)가 이용 가능할 때, 지도 학습은 선호된다. 분류된 데이터가 거의 없거나 사용할 수 없는 경우, 준 지도 학습 또는 자율 학습이 사용될 수 있다. 간단한 자율 훈련 과정은 아래 그림에 도시되어 있다. 알고리즘은 모델 (하늘색 원)에 의해 주어진 예측이 입력 데이터 (진한 파란색 원)와 일치하는 방식으로 그것의 파라미터 조정을 시도한다. 이러한 유형의 모델은 비정상행위 탐지에 사용될 수 있다. 즉 모델은 입력 데이터의 주어진 부분이 훈련 데이터와 동일한 구조를 나타낼지 예측할 것이다.

Example for unsupervised training process (Source: Bosch Rexroth)

두 개의 구별되는 유형의 모형은 기계 학습 과정의 훈련 단계 동안 구축될 수 있다.

• 분류: 기계 학습모델 (예측)의 산출물은 이산적이다
• 회귀: 모델의 산출물은 연속적이다

분류기는 훈련 데이터에 제시된 것처럼 n 개의 카테고리로 데이터를 분리한다. 예를 들어, 이메일을 분류하도록 구축된 분류기는 내용에 따라 정상 또는 스팸 메일로 분류한다. 회귀 모형은 연속 신호, 예를 들면 정의된 목표 신호의 미래 값을 예측하는데 사용될 수 있다.

사례 연구: 산업 어플리케이션 상태 모니터링을 위한 기계 학습

다음 사례 연구는 Bosch Rexroth의 상태 모니터링 프로덕트 매니저인 Tapio Torikka박사에 의해 제공된다.

상태 모니터링에서 기계의 상태가 수집된 센서 데이터에 기초하여 평가된다. 이는 사업자가 자산의 유지 보수 작업을 최적화하고 예기치 못한 중단의 위험을 줄일 수 있게 한다 (아래 그림 참조). 일반적으로 이러한 시스템은 연속적으로 작동된다 (이는 온라인 상태 모니터링으로 알려져 있다).

Machine condition monitoring (Source: Bosch Rexroth)

산업 환경에서 기계는 매우 복잡하며, 그래서 자신의 건강 상태를 평가하는 것은 매우 어려울 수 있다. 많은 기계는 특정 어플리케이션을 위해 특별히 만들어지며, 따라서 고유한 동작을 나타낸다. 또한, 온도 변화 등, 소음, 진동 등 환경의 영향은 센서 신호에 영향을 미칠 수 있다. 설상가상으로, 산업 기계는 기계의 매우 동적인 생산 사이클의 결과로서 부분적으로 고주파 측정을 필요로 하기 때문에, 매우 많은 양의 데이터를 생산하는 경향이 있다. 이러한 특성은 수동으로 개별 센서 신호 또는 간단한 규칙을 검사하여 기계의 유지 보수 상태를 모니터링하는 것이 거의 불가능하다 것을 의미한다.

대용량의 데이터를 저장하는 것은 더 이상 문제가 아니며 사용 가능한 빅데이터 솔루션을 구현함으로써 해결될 수 있다. 훈련 데이터만을 기반으로 모델을 생성하는 기계 학습 알고리즘의 능력은 이러한 데이터를 합리화하는 데 더 큰 문제를 가져온다. 데이터 과학자는 데이터 전처리 및 학습 알고리즘을 위한 분석 파이프라인을 만들 필요가 있다. 또한, 그들은 영역 전문가와 함께 학습 목표를 정의하고 그 결과에 기초하여 작업 제안을 결정하는 책임이 있다. 기계 학습 알고리즘은 일반적으로 많은 연산력을 필요로 하므로 빠른 컴퓨터로의 접속은 중요하다.

비정상행위 탐지는 데이터 소스에서 비정상적인 행동을 검출하는 일반적인 방법이다. 산업적 맥락에서, 이 방법은 결함이 있는 상태를 나타내는 정상 기계 작동으로부터의 편차를 감지하는데 사용될 수 있다. 비정상행위 탐지는 단지 하나의 기준 상태 (예를 들어, 정상 동작)로부터의 훈련 데이터를 필요로 한다. 실제 예에서, 광산 경영자는 광산에서 광석을 전송하는 데 사용되는 컨베이어 벨트의 Rexroth 구동 시스템의 상태를 모니터링하는 데 관심이 있었다. 이것은 경영자에게 중요한 자산이며, 중단 시간은 수익의 감소로 직결되므로, 항상 작동 중이어야 한다. 센서는 컨베이어 벨트 구동 장치에서 데이터를 수집하기 위해 설치되었다. 원격 빅데이터 시스템은 시스템으로부터 데이터를 저장하는 데 사용되고, 기계 학습 알고리즘은 기계의 일반적인 상태 (예측적 분석의 예)를 나타내는 지표를 생성하는데 사용되었다. 어떠한 고장 데이터도 시스템에서 이용할 수 없었고, 따라서 비정상행위 탐지 알고리즘은 정상적인 동작으로부터의 편차를 나타내기 위해 사용되었다.

                             System architecture (Source: Bosch Rexroth)
                             

웹 포털은 데이터를 보고 시스템을 모니터링하기 위해 사용되었다. 아래 스크린샷은 포털의 시각화 화면에서 가져온 것이다.

Example screenshot (Source: Bosch Rexroth)

전기 모터 고장이 구동 장치에서 발생했다. 상기 이미지는 시간의 경과에 따른 비정상행위 탐지 알고리즘 (파란색)과 전기 모터 전류 (적색)의 결과를 보여준다. 전동 모터의 전류가 갑자기 추세에 큰 변화 없이 동작의 몇 달 후에 제로로 떨어진다. 다른 센서 신호들의 수동 분석은 시스템의 어떠한 고장도 나타내지 않았다. 이미지에서 알 수 있는 바와 같이, 청색 곡선 (비정상행위 탐지 알고리즘의 결과)은 모터가 고장나기 전에 정상 수준 (90-100)에서 상당히 벗어나기 시작한다. 이것은 복잡한 데이터 이해하기 위한 기계 학습 알고리즘의 능력을 나타낸다. 수동 데이터를 분석은 대용량의 데이터와 동시에 이용 가능한 모든 센서 신호를 평가하는 것의 복잡성 때문에 불가능한 작업이었을 것이다.

사례 연구: 항공 엔진 분석

다음의 사례연구는 Intel 사의 그래프 분석 부서에서 수석 선임 엔지니어이며 총괄 매니저인 Ted Willke로부터 제공되었다.

큰 데이터 시스템은 로그와 기계 원천 데이터로부터의 통계자료를 계산하기 위해 종종 사용된다. 이 정보는 엔지니어들과 데이터 과학자들이 작동을 감시하고, 실패를 확인하고, 수행 결과를 좋게 만들며, 미래 설계를 향상시키기 위해서 사용될 수 있다. 항공 엔진은 세계에서 가장 복잡한 기계 중 하나이다. 항공 엔진들은 물리학의 많은 관점을 하나로 합치고 극대화된 범위의 조건에서 운영해야만 한다 [LYYJL]. 항공 엔진들은 안전에 대한 걱정과 비행에 대한 방해가 발생하기 전, 진단법이 미리 잠재적 실패를 발견하기 위해 자주 관찰된다.

전통적으로 엔진 상태에 대한 짤막한 묘사와 고장 코드는 비행 중에 얻어져 일지에 기록하고 감시를 위해 지상 기지로 보내진다. 그러나 데이터 전송과 큰 데이터 기술을 사용할 수 있는 규모를 모두 소화할 수 있는 IoT 시스템의 이용 가능성과 함께, 엔진 데이터는 오프-보드에서 넓은 차량 지상 기지로 전송될 수 있으며, 지속적으로 관찰될 수 있고, 깊은 통찰력으로 분석될 수 있다 [DSAR]. 같은 데이터의 전송은 지속적으로 같은 비행 조건 하 (고도, 속력, 기온, 운행 시간 등)의 같은 엔진에 의해 수집될 수 있다. 간단한 통계 자료는 엔진이 예상한 바대로 작동했는지 (설계 설명서와 비교하여) 알아내기 위해 이러한 시간의 연속에 기반을 둔 체 계산될 수 있다. 또한 터빈의 압력, 출구 공기 온도, 연료의 흐름 수준 등의 항목에 문제가 있는 것과 같은, 비정상적인 조건을 발견하는 데에도 간단한 통계 자료는 계산될 수 있다.

Category C 시스템은 변칙과 실패를 발견하는 것은 가능하지만, 결함을 따로 분리하고 높은 신뢰도와 정확성으로 결함 원인을 밝혀내는 것은 가능하지 않을 수 있다 [LYYJL]. 게다가 Category C 시스템은 더욱 분명한 변칙과 지속적인 심각한 결함으로 이어질 수 있는 약한 신호 (미세한 변칙)을 발견하는 것도 불가능할 수 있다. 이것이 기계 학습이 도입된 배경이다 (Category D 시스템). 기계 학습은 연구 (이 사례에서는 항공 엔진)에 기반을 둔 시스템 모델을 창조해 낼 수 있다. 그리고 나서 기계 학습은 시스템 행동을 예측하기 위한 모델을 사용할 수 있다. 기계 학습은 데이터 중심 접근 방법이다. 모델의 원형 (유전적 형태)은 선택돼 예측 정확성을 높이기 위해 “훈련된다”. 모델에 의해 패턴은 학습될 수 있기 때문에, 흔한 훈련 과정은 투입물 (무엇을 예측의 기반으로 둘지)과 알려진 산출물 (무엇이 예측이 되었는지)의 쌍을 공급하는 것을 포함한다. 패턴이 학습된 후에는 정확한 예측이 가능하다. 엔진 진단법의 경우에는, 투입물은 엔진의 특징들을 가동하며 예측은 몇몇의 엔진 결함 코드 중의 하나일 수도 있다 (“정상적인” 한가지 코드).

한 가지 연구에서 [LYYJL], 49,900 비행 가치의 데이터는 8가지 엔진 측정으로부터의 1에서 9까지 엔진 결함 조건을 예측하기 위한 기계 학습의 능력의 결정하는 데에 도움이 되도록 분석됐다. 그 기술은 특정한 결함 코드를 유발하는 결함과 초기 결함의 존재를 발견하는 것이 가능한 것으로 보였다.

이 사례 연구에서 살펴본 바와 같이 IoT에서의 데이터 관리에 관해서 매우 다양한 수준의 성숙도가 존재함을 알 수 있다. 우리가 강조한 4가지의 시나리오들은 상품 매니저가 어떤 컴퓨터 시스템의 구성과 기술 해결방안이 그들의 특별한 요구에 부합하는지 결정하는 데에 도움을 줄 것이다. 다음 장에서 우리는 첫째로 산업 어플리케이션에 대한 관점에서부터 기술적인 관점에까지 결론을 제공할 것이다.

산업 4.0 관점

Tobias Conz 씨는 Bosch Software Innovations의 산업 팀의 프로젝트 매니저이다. 그는 고급 IT 개념과 오늘날의 혹독한 IT 제조 환경의 교차점에서 일하고 있다. 그는 다음과 같이 그의 경험을 묘사하고 있다: “제조업과 산업 4.0 분야에서의 데이터 관리는 특히 어렵습니다. 그 이유는 많은 제조업자들이 현재의 환경하에서는 변화가 쉽게 일어나지 않아 투자 주기를 10-15년으로 보기 때문입니다. 한가지 긍정적인 사실은 사실 많은 기계들이 이미 기계 조작을 위해 필요한 방대한 양의 데이터를 모으고 있다는 것입니다. 그러나 산업 4.0전에는 이러한 데이터가 바깥세상에서 실제로 사용 가능하도록 만들 수 있는 요건이 거의 없었습니다. 이것은 우리가 여러 다른 종류들로 이뤄진 인터페이스, 데이터 종류와 프로토콜, 다양한 소프트웨어 버전 등과 같은 일상의 문제를 다뤄야만 하는 매우 기본적인 데이터 통합 시나리오를 바라보고 있다는 것을 의미합니다.

대부분의 기계 데이터가 더 높은 수준으로 통합되지 않았었기 때문에, 통합에 대해 훨씬 이전부터 다뤄왔던 은행과 보험 회사들과는 다르게 우리는 이 공간 속에서 훨씬 높은 수준의 이질성을 찾고 있습니다. 데이터 마이닝, 스트리밍 처리 과정과 같이 새로운 데이터 관리 개념은 물론 제조업과 산업 4.0이라는 맥락에서 매우 흥미로워 보입니다. 이 공간의 특수성에 의해, 우리는 이중의 전략을 추천합니다: 개인 기계 데이터는 어디서든 적용되어 사용될 수 있는 데이터 마이닝 측면에서는 귀중한 발굴 물이라고 할 수 있습니다. 하지만 이러한 목적을 위한 모든 기계의 통합은 거의 불가능합니다. 이것이 우리가 복수의 기계들의 처리 한도를 동시에 유효하게 만들 수 있는 근 실시간 스트리밍 처리 과정을 개발하고 있는 이유입니다. 우리는 이를 한 기계 종류마다 한 번에 하고 있습니다. 이는 어떤 기계 종류가 가장 잘 작동하는지 살펴보기 위함입니다. 가장 큰 어려운 점은 우리가 통합을 위한 시간과 비용 효율 방안을 찾아내야 한다는 것입니다.”

일반적인 추천

MongoDB의 CEO로써 Max Schireson 씨는 떠오르는 IoT 공간에서뿐만 아니라 NoSQL와 일반적인 큰 데이터 기술의 전개에서도 큰 통찰력을 얻을 수 있었다. 아래의 인터뷰에서 그는 프로젝트 매니저를 위한 몇몇 소중한 추천을 제시하고 있다.

Dirk Slama: 무엇이 큰 데이터와 loT 와 관련되어 가장 큰 위험 요소라고 할 수 있습니까? 또한 어떻게 회사들이 이러한 위험요소를 제한하고 회피할 수 있습니까?

Max Schireson: loT와 큰 데이터는 현재 매우 큰 이슈가 되는 주제입니다. 따라서 프로젝트의 첫 번째로 사업 목표에 대해 생각하는 것보다 기술에 직접 뛰어드는 것이 더 쉬울 수 있습니다. 하지만 기술보다 훨씬 중요한 것은 여러분들이 사업이 무엇을 얻으려고 노력하는지 생각하며 이해관계자를 하나로 묶을 필요가 있다는 것입니다. 사업 부문, 당신의 고객들, 당신의 협력자들, 그리고 유용한 기술을 인도하기 위해 일 할 IT 팀들과 같은 이해관계자들 말입니다. 심지어 경쟁자들도 상호 연결성과 통합이라는 측면에서 보면 loT 환경 시스템에서의 중요한 요소가 될 수 있습니다. 여러분들은 loT 그 자체에 대해 언급하면서 이해관계자 특히 고객들을 찾아가서는 안될 것입니다. 여러분들은 loT가 인도할 수 있는 장점들에 대한 대화들의 큰 틀을 짜 볼 필요가 있을 것입니다.

프로젝트가 조직 내의 대부분 고위급에 대한 전략적인 지원 방안을 가지고 있는 것은 중요합니다. 또한 선구자들의 성공과 실패로부터 교훈을 얻기 위해 시간도 가져야 합니다. 탐험적인 자세를 가지는 것이 중요합니다. 미래 사업 모델이 어떤 형태를 띨지 예측할 수 있는 사람이 거의 없는 것처럼 인터넷의 초기 시대에 가장 성공적인 사업 모델이 어떤 현태를 예측한 사람이 거의 없었다는 사실을 기억하세요.

당신은 기술 향상이 필요할 것입니다. 현재의 직원을 데리고 그들을 훈련시키는 방안이든 회사 밖의 제삼자의 전문 영향력을 이용하든 어떤 방안으로든 말입니다. 우리는 정의된 사용 사례를 가지고 있고 장치와 데이터의 부분집합을 위해 사용되는 시범 프로젝트를 시작할 것을 추천합니다. 평가하고, 최대한으로 활용하고, 다시 평가하고. 만약 프로젝트가 증명된 개념과 훈련된 직원들과 함께 성공한다면 더욱 야망을 가지셔도 될 것입니다.

Dirk Slama: 누가 loT로부터 가장 혜택을 받을 수 있을까요? 혹은 누가 가장 손해를 볼 수 있을까요?

Max Schireson: 몇몇 사람들은 때때로 단순히 “어떤 것”의 발명자가 혜택을 볼 것이라고 생각합니다. 이것은 완전히 잘못된 생각이죠. 고객들의 행동을 감시해서 보험료를 최대한으로 할 수 있는 보험 회사나 식품의 생산에서부터 소비에 이르는 식품 공급 사슬을 최대한으로 활용할 수 있는 소매업자들을 생각해보세요. 경제학자들은 75%의 회사들이 회사의 고위급에 현재 loT를 도입할 계획을 세우고 있다고 추정하고 있습니다 [Ref2]. loT와 새로운 사업 모델을 만들 수 있는 데이터/통찰력을 사용하는 회사들과 이를 이용해 그들의 고객들에게 더 다가설 수 있는 회사들이 가장 많은 것을 얻어 갈 것입니다. 현실을 외면하는 기업들은 결국 도태되고 말 것입니다.

Dirk Slama: 큰 데이터와 loT의 적용을 위해 자신들의 전략을 개발하고 있는 독자들에게 한 말씀해주신다면

Max Schireson: 무엇보다 위에서 언급했던 토론 부분에 대해서 다시 말씀드리고 싶습니다. 팀이 그들이 사용하려고 계획한 기술들을 골랐다면 일반적인 최선의 방안들이 있을 것입니다. 그것들은 아래와 같습니다. 기술을 이해하기 위한 시간 (훈련, 독해, 그리고 회의)을 늘려주세요. 새로운 프로젝트의 개발을 돕기 위해 판매회사들과 서비스 공급자들로부터 자원을 사로잡으세요. 발전이 진행됨에 따라, 테크 토크, 해카톤, 프로젝트 위키 등과 함께 최선의 방안과 진행 상황을 공유하세요. 그리고 나서 복수의 프로젝트가 진행 중일 때 최선의 방안이 일상화되도록 CoE를 만들고 확장하세요. 이 공간에는 매우 많은 혁신이 진행 중이고 매우 많은 기술 선택이 존재하기 때문에 여러분은 여러분의 마음을 열 필요가 있습니다. 단지 당신의 ERP 플랫폼을 15년간 성공적으로 운영했기 때문에 데이터 관리 플랫폼을 선택하는 것은 좋은 생각이 아닙니다!