[빅데이터를 지탱하는 기술] 1. 빅데이터의 기초 지식 - 빅데이터 시대의 데이터 분석 기반

목차

1. 빅데이터의 기초 지식

 

1.2. 빅데이터 시대의 데이터 분석 기반

1.2.1. 빅데이터의 기술 - 분산 시스템을 활용해서 데이터를 가공해 나가는 구조

① 데이터 파이프라인  - 데이터 수집에서 워크플로우 관리까지

② 데이터 수집 - 벌크 형과 스트리밍 형의 데이터 전송

③ 스트림 처리와 배치 처리

④ 분산 스토리지 - 객체 스토리지, NoSQL 데이터베이스

⑤ 분산 데이터 처리 - 쿼리 엔진, ETL 프로세스

⑥ 워크플로우 관리

1.2.2. 데이터 웨어하우스와 데이터 마트 - 데이터 파이프라인 기본형

1.2.3. 데이터 레이크 - 데이터를 그대로 축적

① 데이터 레이크와 데이터 마트 - 필요한 데이터는 데이터 마트에 정리

1.2.4. 데이터 분석 기반을 단계적으로 발전시키기

① 애드 혹 분석 및 대시보드 도구

② 데이터 마트와 워크플로우 관리

1.2.5. 데이터를 수집하는 목적 - '검색', '가공', '시각화'의 세 가지 예

① 데이터 검색

② 데이터의 가공

③ 데이터 시각화

 

---

1. 빅데이터의 기초 지식

1.2. 빅데이터 시대의 데이터 분석 기반

빅데이터 기술이 기존의 데이터 웨어하우스와 다른 점은 다수의 분산 시스템을 조합하여 확장성이 뛰어난 데이터 처리 구조를 만든다는 점이다. 이번 장에서는 그 차이에 관해 설명하고자 한다.

1.2.1. 빅데이터의 기술 - 분산 시스템을 활용해서 데이터를 가공해 나가는 구조

이 책에서 다루는 '빅데이터 기술'이란 분산 시스템을 활용하면서 데이터를 순차적으로 가공해 나가는 일련의 구조다. 이것을 실제로는 아래의 그림과 같이 여러 서브 시스템을 조합함으로써 실현 가능하다.

 

① 데이터 파이프라인 - 데이터 수집에서 워크플로우 관리까지

일반적으로 차례대로 전달해나가는 데이터로 구성된 시스템을 '데이터 파이프라인(data pipeline)'이라고 한다. 빅데이터의 데이터 파이프라인은 어디에서 데이터를 수집하여 무엇을 실현하고 싶은지에 따라 변화한다. 처음에는 간단한 구성으로도 끝나지만, 하고 싶은 일이 증가함에 따라 시스템은 점차 복잡해지고 그것을 어떻게 조합시킬지가 문제가 된다.

 

② 데이터 수집 - 벌크 형과 스트리밍 형의 데이터 전송

데이터 파이프라인은 데이터를 모으는 부분부터 시작한다. 데이터는 여러 장소에서 발생하고 각각 다른 형태를 보인다. 데이터베이스에 쓰인 거래처 데이터, 파일 서버에 축적된 로그 파일, 스마트 폰 등의 모바일 애플리케이션에서 모여진 이벤트 데이터 및 임베디드(embedded) 장비에서 보내진 센서 데이터 등 각각 서로 다른 기술로 데이터를 전송한다.

 

'데이터 전송(data transfer)'의 방법은 크게 다음의 두 가지가 있다. (그림 1.4 ❶❷)

• 벌크(bulk)형
• 스트리밍(streaming)형

벌크 형은 이미 어딘가에 존재하는 데이터를 정리해 추출하는 방법으로, 데이터베이스와 파일 서버 등에서 정기적으로 데이터를 수집하는 데에 사용한다. 한편, 스트리밍 형은 차례차례로 생성되는 데이터를 끊임없이 계속해서 보내는 방법으로 모바일 애플리케이션과 임베디드 장비 등에서 널리 데이터를 수집하는 데 사용된다. 

 

 

③ 스트림 처리와 배치 처리

기존의 경우, 데이터 웨어하우스에서 다루는 데이터는 주로 벌크 형 방법이 이용되었다. 하지만 빅데이터의 세계에서는 모바일 애플리케이션 등이 증가함에 따라 오히려 스트리밍 형 방법이 주류가 되고 있고, 스트리밍 형 방법으로 받은 데이터는 아무래도 실시간으로 처리하고 싶어진다. 이것을 '스트림 처리(stream processing)'라고 한다.

예를 들어, 과거 30분간 취합한 데이터를 집계하여 그래프를 만들려면, '시계열 데이터 베이스(time-series database)'와 같은 실시간 처리를 지향한 데이터베이스가 자주 사용된다(그림 1.4 ❸). 스트림 처리의 결과를 시계열 데이터베이스에 저장함으로써, 지금 무슨 일이 일어나고 있는지 즉시 알 수 있다. 

한편 스트림 처리는 장기적인 데이터 분석에는 적합하지 않은 문제가 있다. 예를 들어, 지난 1년간의 데이터를 분석하려고 하면 데이터양은 단번에 수천 배 혹은 수만 배로 증가한다. 실시간 데이터 처리와 장기적인 데이터 분석 결과를 하나의 시스템으로 실현하는 것은 불가능하지는 않지만 그렇게 쉬운 일만은 아니다.

장기적인 데이터 분석을 위해서는 보다 대량의 데이터를 저장하고 처리하는 데 적합한 분산 시스템이 좋다(그림 1.4 ❹❺). 거기에 필요한 것은 스트림 처리가 아닌, 어느 정도 정리된 데이터를 효율적으로 가공하기 위한 '배치 처리(batch processing)'구조다. 

 

④ 분산 스토리지 (객체 스토리지, NoSQL 데이터베이스)

수집된 데이터는 '분산 스토리지(distribute storage)'에 저장된다(그림 1.4 ❷❹). 여기서 말하는 분산 스토리지란 여러 컴퓨터와 디스크로부터 구성된 스토리지 시스템을 말한다. 데이터를 저장하는 방법에는 몇 가지 선택이 있다. 대표적인 것이 '객체 스토리지(object storage)'로 한 덩어리로 모인 데이터에 이름을 부여해서 파일로 저장한다. 클라우드 서비스인 Amazon S3, Azure Blob 등이 유명하다. 

NoSQL 데이터베이스를 분산 스토리지로 사용할 수도 있다. 애플리케이션에서 많은 데이터를 읽고 쓰려면 NoSQL 데이터베이스가 성능 면에서 우수하다. 단, 나중에 데이터 용량을 얼마든지 늘릴 수 있는 확장성이 높은 제품을 선택해야 한다. 

 

⑤ 분산 데이터 처리 (쿼리 엔진, ETL 프로세스)

분산 스토리지에 저장된 데이터를 처리하는 데는 '분산 데이터 처리(distribute data processing)'의 프레임워크가 필요하다(그림 1.4 ❻❼). MapReduce가 사용되어진 것이 바로 이 부분으로 데이터양과 처리의 내용에 따라 많은 컴퓨터 자원이 필요하게 된다. 분산 데이터 처리의 주 역할은 나중에 분석하기 쉽도록 데이터를 가공해서 그 결과를 외부 데이터베이스에 저장하는 것이다. 

대다수의 사람들은 데이터 집계에 있어서 SQL을 사용하는 것에 익숙하다. 빅데이터를 SQL로 집계할 때는 두 가지 방법이 있다.

하나는 분산 스토리지 상의 데이터를 SQL로 집계하기 위해 '쿼리 엔진(query engine)'을 도입하는 것이다. Hive는 그 한 가지 예인데, 현재는 Hive보다도 고속인 '대화형 쿼리 엔진(interactive query engine)'도 개발되었다. 

다른 하나는 외부의 데이터 웨어하우스 제품을 이용하는 것이다. 이를 위해서는 분산 스토리지에서 추출한 데이터를 데이터 웨어하우스에 적합한 형식으로 변환한다. 이 일련의 절차를 'ETL(Extract-transform-load) 프로세스'라고 한다. 즉, 데이터를 '추출(extract)'하고, 그것을 '가공(transform)'한 후, 데이터 웨어하우스에 '로드(load)'한다 (그림 1.5).

 

⑥ 워크플로우 관리

전체 데이터 파이프라인의 동작을 관리하기 위해서 '워크플로우 관리(workflow management)' 기술을 사용한다. 매일 정해진 시간에 배치 처리를 스케줄대로 실행하고, 오류가 발생한 경우에는 관리자에게 통지하는 목적으로 사용된다.

데이터 파이프라인이 복잡해짐에 따라, 그것을 한 곳에서 제어하지 않으면 전체의 움직임을 파악하는 것이 곤란해진다. 빅데이터의 처리에는 크건 작건 간에 시스템 장애가 발생하므로 오류 발생 시의 처리와 다시 처리하기 위한 기능을 만드는 것을 빼놓아서는 안 된다.

이처럼 빅데이터의 데이터 파이프라인을 실현하려면 많은 기술과 소프트웨어가 사용된다. 이 전부가 필요하지는 않지만, 더욱 좋은 데이터 분석 환경을 구축하는 데는 각각의 특징을 이해해둘 필요가 있다. 

 

 

1.2.2. 데이터 웨어하우스와 데이터 마트 - 데이터 파이프라인 기본형

이제 '데이터 파이프라인의 기본형'으로 기존 방식대로의 데이터 웨어하우스를 구축하는 프로세스를 살펴보겠다(그림1.6).

데이터 웨어하우스는 웹 서버나 업무 시스템에서 이용되는 일반적인 RDB와는 달리 '대량의 데이터를 장기 보존하는' 것에 최적화되어 있다. 정리된 데이터를 한 번에 전송하는 것은 뛰어나지만, 소량의 데이터를 자주 쓰고 읽는 데는 적합하지 않다. 전형적인 사용 방법으로는 업무 시스템에서 꺼낸 데이터를 하루가 끝날 때 정리하여 쓰고, 이것을 야간 시간대에 집계해서 보고서를 작성한다.

데이터 웨어하우스의 측면에서 봤을 때, 업무 시스템을 위한 RDB나 로그 등을 저장하는 파일 서버는 '데이터 소스(data source)'라고 부른다. 거기에 보존된 '로우 데이터(raw data, 원시 데이터)'를 추출하고 필요에 따라 가공한 후 데이터 웨어하우스에 저장하기까지의 흐름이 'ETL 프로세스(ETL Process)'이다. 데이터 웨어하우스 구축에는 'ETL 도구'라는 전용 소프트웨어가 자주 이용된다.

데이터 웨어하우스는 업무에 있어서 중요한 데이터 처리에 사용되기 때문에 아무때나 함부로 사용해 시스템에 과부하를 초래하는 것을 곤란하다. 따라서, 데이터 분석과 같은 목적에 사용하는 경우에는 데이터 웨어하우스에서 필요한 데이터만을 추출하여 '데이터 마트(data mart)'를 구축한다. 데이터 마트는 BI 도구와 조합시키는 형태로 데이터를 시각화하는 데에도 사용된다.

데이터 웨어하우스와 데이터 마트 모두 SQL로 데이터를 집계한다. 따라서, 먼저 테이블 설계를 제대로 정한 후에 데이터를 투입한다. 특히 BI 도구로 데이터를 볼 경우에는 미리 시각화에 적합한 형태로 테이블을 준비해야 한다. 그렇기에 데이터 웨어하우스를 중심으로 하는 파이프라인에서는 테이블 설계와 ETL 프로세스가 중요하다. 

 

1.2.3. 데이터 레이크 - 데이터를 그대로 축적

빅데이터의 시대가 되면 ETL 프로세스 자체가 복잡해진다. 모든 데이터가 데이터 웨어하우스를 가정해서 만들어지지는 않는다. 다른 업체에서 받은 텍스트 파일과 바이너리 데이터(binary data) 등은 있는 그대로 데이터 웨어하우스에 넣을 수 없는 것도 있다. 우선 데이터가 있고, 나중에 테이블을 설계하는 것이 빅데이터다. 

모든 데이터를 원래의 형태로 축적해두고 나중에 그것을 필요에 따라 가공하는 구조가 필요하다. 빅데이터의 세계에서는 여러 곳에서 데이터가 흘러들어 오는 '데이터를 축적하는 호수'에 비유해 데이터의 축적 장소를 '데이터 레이크(data lake)'라고 한다(그림 1.7).

구체적으로는 임의의 데이터를 저장할 수 있는 분산 스토리지가 데이터 레이크로 이용된다. 데이터 형식은 자유지만, 대부분의 경우는 CSV나 JSON 등의 범용적인 텍스트 형식이 사용된다. 

데이터 웨어하우스를 데이터 레이크로 치환하면, 그림 1.8과 같이 데이터 파이프라인을 구축할 수 있다. 앞서 나온 그림 1.6과 비교하면 미가공의 원시 데이터를 그대로 저장소에 저장한다는 점이 다르다.

① 데이터 레이크와 데이터 마트 - 필요한 데이터는 데이터 마트에 정리

데이터 레이크는 단순한 스토리지이며, 그것만으로는 데이터를 가공할 수 없다. 그래서 사용되는 것이 MapReduce 등의 분산 데이터 처리 기술이다. 데이터 분석에 필요한 데이터를 가공, 집계하고, 이것을 데이터 마트로 추출한 후에는 데이터 웨어하우스의 경우처럼 데이터 분석을 진행할 수 있다.

 

1.2.4.  데이터 분석 기반을 단계적으로 발전시키기

앞서 기술한 바와 같이, 데이터 분석에 필요한 기술은 다방면에 걸쳐 있기 때문에 주로 팀을 이루어 작업한다. 특히, 시스템의 구축 및 운용, 자동화 등을 담당하는 '데이터 엔지니어(data engineer)'와 데이터에서 가치 있는 정보를 추출하는 '데이터 분석가(data analyst)'는 요구되는 지식뿐만 아니라 사용 도구도 다르다(그림 1.9).

하지만 현실적으로는 항상 팀을 구성해 역할을 분담할 수 있는 것은 아니다. 특히, 이제부터 데이터 분석을 시작하려는 경우라면 처음에는 혼자 아니면 둘이 시작하는 경우가 대부분이다. 주 업무를 하면서 틈틈이 데이터를 살펴보고 있는 사람도 많을 것이다. 그런 상황에서 처음부터 완벽한 결과물을 만들어내는 것은 어려우므로, 가능한 한 작은 시스템에서 시작하여 나중에 단계적으로 확장해 나가는 것이 좋다.

 

① 애드 혹 분석 및 대시보드 도구

이 책에서는 최종적으로 데이터 파이프라인의 자동화에 관해 설명할 것이다. 하지만 아직은 시작 단계이므로 자동화 등을 생각하지 않고 수작업으로 데이터를 집계할 수 있으면 충분하다. 이것을 '일회성 데이터 분석'이라는 의미로 '애드 혹 분석(ad hoc analysis)'이라고 한다. SQL 쿼리를 직접 작성해서 실행하거나 스프레드시트에서 그래프를 만드는 것까지 포함해 모든 수작업이 애드 혹 분석에 포함된다.

애드 혹 분석에서는 데이터 마트를 만들지 않은 채 데이터 레이크와 데이터 웨어하우스에 직접 연결하는 경우가 많다(그림 1.10 ❶). 이 부분에 있어 사용자는 작업하기 쉬운 환경을 선호한다. 쿼리를 실행해 결과를 즉시 확인할 수 있도록 대화형 분석 도구를 사용한다. 

수작업으로 데이터 분석뿐만 아니라 정기적으로 그래프와 보고서를 만들고 싶을 때도 있다. 그럴 때 많이 도입하는 것이 '대시보드 도구(dashboard tool)'다. 일부 대시보드 도구는 데이터 마트가 없어도 동작하도록 설계되어 있어 설정한 스케줄에 따라 데이터 레이크와 데이터 웨어하우스에 접속해 쿼리를 실행하고 그 결과로부터 그래프를 생성한다. 

② 데이터 마트와 워크플로우 관리

복잡한 데이터 분석에서는 먼저 데이터 마트를 구축한 후에 분석하거나 시각화하도록 한다(그림 1.10 ❷). 특히 시각화에 BI 도구를 사용할 경우는 집계 속도를 높이기 위해 데이터 마트가 거의 필수적이다. 데이터 마트 구축은 배치 처리로 자동화되는 경우가 많기 때문에 그 실행 관리를 위해 워크플로우 관리 도구를 사용한다. 

워크플로우 관리를 도입하는 단계가 되면, 데이터 분석보다는 엔지니어링 작업이 많아진다. 그렇기 때문에 일손이 부족하지 않은 상황에서라면 워크플로우 관리는 그다지 필요없다. 그러나 데이터 처리를 자동화해서 장기적으로 운용해 나가기 위해서는 안정된 워크플로우 관리가 필수적이다.

 

 

1.2.5. 데이터를 수집하는 목적 - '검색', '가공', '시각화'의 세 가지 예

데이터를 모은 후에 무엇을 실시할지는 달성하고자 하는 목적에 따라 달라진다. 여기서는 예로써 그림 1.11과 같은 3가지 패턴을 생각해본다.

① 데이터 검색

우선 '데이터 검색'(그림 1.11 ❶)으로 대량의 데이터 중에서 조건에 맞는 것을 찾고 싶은 경우가 있다. 예를 들어, 어떤 시스템에 장애가 발생했을 때 그 원인을 특정하거나 고객으로부터 문의가 있으면 로그를 확인하는 것과 마찬가지다. 언제 무엇이 필요할지 조차도 모르기 때문에, 시스템 로그 및 고객의 행동 이력 등 발생하는 모든 데이터를 취득해 놓도록 한다. 

 

② 데이터의 가공

다음으로 '데이터의 가공'(그림 1.11 ❷)에 있어서는 업무 시스템의 일부로서 데이터 처리 결과를 이용하고 싶은 경우가 있다. 웹사이트에서 추천 상품을 제안하거나, 센서 데이터의 비정상적인 상태를 감지하여 통보하는 경우다. 이 경우는 목적이 명확하기 때문에 필요한 데이터를 계획적으로 모아 데이터 파이프라인을 설계한다. 

데이터의 가공에는 자동화가 필수적이다. 따라서 워크플로우 관리를 도입하여 꼼꼼하게 테스트를 반복적으로 실행해서 시스템을 구축한다. SQL이 아닌 프로그래밍 언어를 사용하는 경우도 있다. 이것은 데이터 분석이라기보다는 시스템 개발 영역에 해당한다.

 

③ 데이터 시각화

그 다음은 '데이터 시각화'(그림 1.11 ❸)로 데이터를 시각적으로 봄으로써 알고 싶은 정보를 얻는 경우가 있다. 통계 분석 소프트웨어나 BI 도구 등으로 그래프를 만들고 거기서 앞으로의 상황을 예측해 의사 결정에 도움이 되도록 하는 경우다.

데이터 시각화는 시행착오의 연속이며, 확실한 해답은 없다. 임의의 분석 환경을 갖추고 여러 번 데이터 집계를 반복한다. 시각화를 고속화하려면 데이터 마트도 필요하다. 또한 집계 결과를 대시보드에 정리해서 계속 변화를 감시하고 싶을 때도 데이터 시각화는 필요하다. 

이것 중에서 어느 것을 우선하는지에 따라 시스템 구성이 달라진다. 이 책에서는 주로 '데이터의 시각화'를 우선 과제로 하고, 특정한 데이터 분석 환경의 정비 및 데이터 마트를 구축하는 파이프라인의 자동화를 다룬다. 시각화만이 데이터를 활용할 수 있는 수단은 아니지만, 시각화를 위해 필요한 기초 지식의 대다수는 다른 용도를 위해서도 응용할 수 있을 것이다.