Practice makes perfect

스톰(STORM)이란?

: 실시간 분산 처리기 - 빅데이터 프로젝트에서 실시간 데이터를 병렬 프로세스(독자적으로 처리(MAP)의 결과를 최종의 결과로 모아주는 것 = reduce - 분산 병렬 처리 )로 처리하기 위한 소프트웨어입니다. Nathan Marz와 BacType의 팀이 개발하였으며,  이 프로젝트는 트위터에 의해 인수된 뒤 오픈 소스화되었습니다.

스톰의 특징

1)  스톰은 사용자가 만든 spout와 bolt를 사용하여 정보원과 조작부를 정의함으로써 스트리밍 데이터의 일괄, 분산 처리를 가능케 합니다.

2) 이벤트를 발생하게 하는 기능을 없어서 에스터를 연결하여 이벤트를 사용합니다.

* 에스퍼 : 실시간 스트리밍(데이터가 움직이는 통로) 데이터의 복잡한 이벤트 처리가 필요할 때 사용하는 룰 엔진

3) 심플 프로그래밍 모델 : 맵리듀스가 병렬처리 프로세싱 구현의 복잡도를 낮춰주는 것과 같이 스톰 또한 분산 real-time 프로세싱 구현의 복잡도를 낮춰줍니다.

4) 빠른 속도 : 인메모리 기반으로 실기간 처리 방식을 가지고 있습니다.

5) 다양한 언어로 구현 가능: 어떤 언어든 사용자가 익숙한 언어를 이용해 구현할 수 있다. 클로저(Clojure), 자바, 루비, 파이썬을 기본으로 제공하며 그 밖에 언어도 Storm communication protocol의 구현만으로도 사용이 가능합니다.

스톰의 아키텍처

1) Nimbus 와 Supervisor

Nimbus가  Toplogy를 zookeeper를 통해서 Supervisor에 전달합니다.

Topology : spout, bolt의 데이터 처리 흐름을 정의 , 하나의 spout과 다수의 bolt로 구성 - 스톰의 연결 또는 구성 방법의 정보라고 할 수 있습니다.

Superviso : Topology를 실행할 worker를 구동시키며 topology 를 worker에 할당 및 관리하는 역할을 합니다.

2) Nimbus -> zookeeper -> Supervisor -> worker

1)에서 과정 이후 woker를 할당합니다.

Worker: supervisor 상에서 실행중인 자바 프로세스로 spout과 bolt 를 실행하고 executor 관리하는 역할을 합니다.

3) Nimbus -> zookeeper -> Supervisor -> worker -> Executor

2) 이후 Executor을 할당해주고 Executor가 tasker를 할당해 줍니다.

Executor: worker 내에서 실행되는 자바 스레드의 역할을 하며, tasker영역을 할당해줍니다.

Tasker: spout 및 bolt 객체가 할당해주고 직접적인 작업의 영역입니다.

Spout: 데이터를 입력 받아 가공처리해서 튜플(스톰이 사용하는 자료형)을 생성 이후 해당 튜플을 bolt에 전송합니다.

Bolt: 튜플을 받아 실제 분산 작업을 수행하며, 필터링, 집계, 조인등의 연산을 병렬로 실행합니다.

순서)

: ) Nimbus -> zookeeper -> Supervisor -> worker -> Executor -> tasker -> spout -> Bolt

Nimbus에 의해서 정의한 것을 Topology에 정의하고 그 내용을 zookeeper를 통해서 supervisor 에 전해주고 Topology 의 정의에 맞게 woker를 구동시키고 Executor을 할당한 다음 Executor가 내용들을 작업 할 tasker를 할당하여 tasker을 통해 spout과 bolt를 할당해주어 수행할 수 있도록 해줍니다.

하둡(Hadoop)이란 ?

: 2003년 구글의 파일 시스템이 모태가 돼서 만들어진 것이 HDFS이고, 2004년에 구글이 발표한 맵리듀스(mapreduce)를 적용하여 하둡에 구현이 되어서 2009년에 발표가 되었습니다.하둡의 창시자가 2005년에 검색엔진 프로젝트를 진행하면서 하둡 프로젝트가 시작되었습니다. 구글의 알고리즘을 통해서 완성되었는데 그 당시 구글의 주 핵심기능이 검색 기술이었기 때문에 가능했다고 합니다.(빠른 처리)

하둡(Hadoop)의 특징

1) 하둡은 여러 개의 저렴한 컴퓨터를 마치 하나인 것처럼 묶어 대용량 데이터를 처리하는 기술입니다.

2) 하둡을 황용하여 빅데이터 분석에 들어가는 초기 비용을 줄이면서 데이터 시스템과의 호환 문제도 쉽게 해결할 수 있습니다.

3) 하둡은 수천 대의 분산된 x86 장비에 대용량 파일을 저장할 수 있는 기능을 제공하는 분산 파일 시스템입니다.

4) 저장된 파일 데이터를 분산된 서버의 CPU와 메모리 자원을 이용해 쉽고 빠르게 분석할 수 있는 컴퓨팅 플랫폼인 맵리듀스로 구성돼 있다.

5) 하둡의 핵심 기술 : 분산 병렬 처리 기술 (HDFS)

하둡의 부족한 기능을 서로 보완하는 '에코시스템'

Flume : 데이터 수집 - 데이터를 수집해서 하둡 파일 시스템에 안정적으로 저장합니다.

HBASE : NoSQL - 대용량의 데이터를 분산된 서버에 구조적으로 저장해 실시간으로 저장합니다.

HIVE : HQL - HQL문을 활용하여 맵리듀스 문을 사용하지 않고 데이터를 처리할 수 있도록 제공합니다.

HUE : UI - 하둡의 모니터링, 관리하는 기능을 수행합니다.

ZOOKEEPER :  분산 코디네이터 - 프로그램 안에서 정보들을 공유, 광리 하는 기능을 수행합니다.

이외에도 kafka, pig, 마후트, 스쿱 등이 존재합니다.

하둡 1 아키텍처 (저사양으로 사용 가능 but 안정감이 많이 떨어진다)

하둡 1의 주요 구성 요소

NameNode : DataNode에 저장된 파일들의 메타 정보를 메모리상에서 로드해서 관리, 실제 저장소 공간을 총괄합니다. 하지만 NameNode가 error가 나면 모두 하둡 자체가 error 나게 되는 단점을 가지고 있습니다. 또한 하둡은 저사양으로 돌리기 때문에 error가 많이 일어났습니다.

DataNode : 블록(하둡 1:64MB , 블록 2:128MB) 당위로 분할된 대용량 파일들이 DataNode의 디스크에 저장 및 관리됩니다. 저장소 역할을 합니다.

SecondaryNameNode : NameNode의 Fslmage(NameNode의 메모리상에 올라와 있는 메타 정보를 스냅샵 이미지로 만들어 생성한 파일)와 EditsLog(파일들의 변경 이력(수정, 삭제 등) 정보가 저장되는 로그 파일)파일을 주기적으로 유지 관리해주는 체크 포인팅 노드

NameNode와 동일하게 만들어서 NameNode의 백업 용도로 사용하고, 일정 시간마다 저장합니다.

MapReduce : 분산 병렬 처리에서 기본은 먼저 수많은 컴퓨터가 있는데 어떻게 일을 효율적으로 나눠서 실행할 수 있느냐이고(Map : key-value , keyword 저장) 두 번째는 수많은 컴퓨터들이 나누서 만든 결과를 어떻게 하나로 모으냐(Reduce)는 것이었는데 이를 MapReduce를 통해서 지원해 줍니다. 데이터에 프로그램을 로드하여 블록 단위로 각각 처리합니다.

하둡 1 에서는 시스템에 탑재되어 구동됩니다.

ex) 1G를 1초에 수행하는 데이터가 총 1T 있을 때, 한 개씩 처리하면 1024초가 걸릴 것을 각각 처리하면 1초 안에 모두 수행할 수 있도록 하는 것입니다.

JobTracker : 맵리듀스의 잡을 실 행면서 태스크에 할당하고 전체 잡에 대해 리소스 분배 및 스케줄링을 합니다.

                (시간이 많이 걸리며, 오류가 많습니다.)

TaskTracker : JobTraker가 요청한 맵리듀스 프로그램이 실행되는 태스크이며, 이때 맵 태스크와 리듀스 태스카가 생성됩니다.

하둡 2 아키텍처 (1버전 대비 안정성이 크게 향상하였습니다.)

NameNode(Active/Stand-By) : NameNode를 이중화해서 서비스 중인 Active NameNode와 실패처리를 대비한 Standby NameNode로 구성되어집니다. 이 둘 사이에 주키퍼를 통해서 데이터를 공유하도록 합니다.

JournalNode : 3개 이상의 노드로 구성되어 EditsLog를 각 노드에 복제 관리하여 Active NameNode는 EditsLog에 쓰기만을 수행하고 Standvy NameNode는 읽기만을 실행합니다.

MapReduce/YARN : 하둡 클러스터 내의 자원을 중앙 관리하고, 그 위에 다양한 애플리케이션을 실행 밑 관리가 가능하도록 확장성을 과 호환성을 높은 하둡 2의 플랫폼, 리소스 기반으로 응용프로그램처럼 사용합니다.

ResouceManager : 하둡 클러스트터 내의 자원을 중앙 관리하면서, 작업 요청 시 스케줄링 정책에 따라 자원을 분해서 실행시키고 모니터링을 합니다(리소스, 메로리, 스케줄만 관리)

NodeManager : 하둡 클러스터의 DataNode마다 실행되면서 Container를 실행시키고 라이프 사이클을 관리합니다.

Containcer : DataNode의 사용 가능한 리소스(CPU, 메모리, 디스크 등)를 Container 단위로 할당해서 구성합니다.

ApplicationManager : 애플리케이션이 실행되면 ApplicationMaster가 생성되며 ApplicationMaster는 NodeManager에게 애플리케이션이 실행될 Container를 요청하고, 그 위에 애플리케이션 실행 및 관리합니다.

하둡 1 -> 하둡 2 변화

1) 안정성을 위해서 NameNode의 이중화(Active NameNode , Stand-by NameNode) + 주키퍼 활용 + JournalNode

2) 안정성과 편의성을 위한 JobTracker의 역할 분배

Resource Manager(리소스, 메모리, 스케줄 관리) + ApplicationMaster(mapreduce관리 및 실행)

추가적인 상식)

● 만들어진 알고리즘을 open 하는 이유는?

1) 프로그램에 대한 빠른

- 다른 개발자들이 다양하게 사용하여 개선되어 짧은 시간 안에 진입 장벽이 낮아져서 많은 사람들이 나타나게 된다고 합니다.

2) 하둡을 관리하는 비영리 제단에 의해서 개선되고 안정성을 확보할 수 있지만, 끊임없이 개발사에 의뢰해서 안정화를 위해 사람들을 고용할 수밖에 없습니다.(수익창출)

● 안드로이드 운영체제 안에 구글 관련 프로그램이 많은데 왜 구글은 무료로 배포를 할까?

안드로이드로 된 핸드폰이 팔리면 최종적으로 많은 사람들이 구글의 기술을 사용할 수 있게 됩니다. 이처럼  전 세계의 네트워크가 구글로 사용할 수 있도록 만들어가기 위함이라고 합니다. 그래서 많은 부분의 핵심기술들은 구글에 속해있습니다. (합병 – 딥러닝 : 딥러닝을 돌리기 위한 서버를 팔아 벌기 위함이었다고 합니다.)

주키퍼(ZOOKEEPER)란?

: 분산 코디네이션 서비스를 제공하는 오픈소스 프로젝트로, 일관적으로 관리 해주는 프로그램 입니다.

주키퍼(ZOOKEEPER) 홈페이지 : zookeeper.apache.org/

주키퍼(ZOOKEEPER)역할

1) 네임서비스를 통해 하나의 서버만 서비스를 수행하지 않고 알맞게 분산해 각각의 클라이언트들이 동시 작업할 수 있도록 지원하여 부하를 분산시킵니다.

2) 락(lock)을 통해 하나의 서버에서 처리된 결과가 또 다른 서버들과 동기화할 수 있도록 합니다.

- 결국 주키퍼는 안정적이고 가용성 높은 znode 데이터 시스템을 제공하는 클러스터 서버라고 해도 과언이 아닙니다.

주키퍼(ZOOKEEPER) 주요 구성 요소

Client : 주키퍼 ZNode에 담긴 데이터에 대한 쓰기 읽기, 삭제 등의 작업을 요청하는 클라이언트

작업 요청을 실행할 때, client로 들어가면 됩니다. 

ZNode(주키퍼의 핵심 구성요소) : 주키퍼 서버에 생성되는 파일시스템의 디렉터리(탐색기) 개념으로, 클라이언트의 요청 정보를 계층적으로 관리(버전, 접근, 상태, 모니터링 객체 관리 등의 기능 지원)

Ensemble : 3대 이상의 주키퍼 서버를 하나의 클러스터로 구성한 ha아키텍처 (안정화 기능)

LeaderServer : Ensemble 안에는 유일한 리더 서버가 선출되어 존재하며, 클라이언트의 요청을 받은 서버는 해당 요청을 리더 서버에 전달하고, 리더 서버는 모든 팔로워 서버에게 클라이언트 요청이 전달되도록 보장

Follower Server : Ensemble 안에서 한 대의 리더 서버를 제외한 나머지 서버로서, 리더 서버와 메세지를 주고받으면서 ZNode의 데이터를 동기화하고 리더 서버에 문제가 발생할 경우 내부적으로 새로운 리더를 선출하는 역할을 수행

주키퍼(ZOOKEEPER)가 연동 시켜주는 프로그램들 (하둡, 스톰, hbase, Kafka)

1) 하둡(Hadoop)

: 하둡2에 들어와서 하둡1에서 NameNode가 다운되면 모든 시스템이 문제가 생기는 오류를 막기 위해서 NameNode를 이중화 시키는데 주키퍼를 사용하였습니다.

2) 스톰(Storm)

: Nimbus에서 만들어진 Topology를 Supervisor와 공유하기 위해서 주키퍼를 사용합니다.

3) HBase

:  HMaster와 Client 의 정보를 공유하기 위해서 주키퍼를 사용합니다.

4) 카프카(Kafka)

: 카프카의 provider와 consumer 의 저장공간을 서로 공유하기 위해서 주키퍼를 사용합니다.

카프카(Kafka)란?

MOM(Message Oriented Middleware – 메시지성 데이터 처리에 최적화되어 있는 middleware, 비정형성) 소프트웨어 중 하나로 대규모로 발생하는 메시지성 데이터를 비동기 방식으로 중계하는 역할을 하며 실시간 처리에 사용합니다. 실시간 데이터 피드를 관리하기 위해 통일된, 높은 처리량, 낮은 지연시간을 지닌 플랫폼을 제공하는 것을 목표로 합니다.

링크드인에서 2011년에 개발되어 그 해 6월에 아파치 인큐베이터에 등록됐고, 2012년 10월 에 아파치 최상위 프로젝트로 승격되었습니다.

Kafka의 기능 : 원천 시스템으로부터 대규모 트랜잭션 데이터가 발생했을 때 중간에 데이터를 버퍼링하면서 타깃 시스템에 안정적으로 전송해 주는 강력한 기능과 아키텍처를 제공하는 중간 시스템입니다.

- 끊임없이 연이어서 저장되어질 때, 카프카를 사용합니다. 최근에는 스파크와 연동하여 스트리밍 방식의 데이터 처리 플로우를 구축하는데 널리 활용되고 있습니다. 모든 데이터 set이 메모리 위에 있을 때 가능한 기능이며, 메모리 위에서 사용가능한 스파크와 함께 연동을 통해서 긍정적인 반응을 가져올 수 있습니다.

kafka 홈페이지  : kafka.apache.org/

Kafka의 주요구성 요소 : Broker, topic, provider, consumer

Topic : Broker에서 데이터의 발행/소비 처리를 위한 저장소 기능을 하는 구성요소 입니다.

Broker : Topic 컨트롤러 역할로 Kafka Server를 의미하며, 한 클러스터 내에서 Kafka server를 여러 대 띄울수 있습니다.

Provider : Broker의 특정 Topic에 데이터를 전송(발행)하는 역할로서 애플리케이션에서 카프카 라이브러리를 이용해 구현 합니다.  

Consumer : Broker의 특정 Topic에서 데이터를 수신(소비)하는 역할로서 애플리케이션에서 카프카 라이브러리를 이용해 구현 합니다.

Kafka의 아키텍쳐

싱글 브로커/싱글 노드

: 1대의 카프카 서버만 설치하고, 1개의 Broker만 구성한 아키텍처로 대량의 발행/소비 요건이 없고, 단순한 업무 도메인에 이용합니다.

멀티 브로커/멀티 노드

:  2대 이상의 카프카 서버로 멀티 Broker를 구성한 아키텍처로 대량의 발행/소비 데이터 처리에 적합하며, 물리적으로 나눠진 브로커 간의 데이터 복제가 가능해 안정성이 높습니다 또한 업무 도메인별 메시지 그룹을 분류할 수 있어 복한 메시지 송/수신에 활용하면 적합합니다.

플럼(Flume)이란?

Apache Flume(이하 플룸)은 클라우데라에서 처음 개발 돼, 2011년 클라우데라를 통해 처음 소개 되어서 아파치 소프트웨어 프로젝트에 기증되어 최상위 프로젝트로 격상되어 사용중입니다. 다양한 수집 요구 사항들을 해결하기 위해 기능으로 구성된 소프트웨어이며, 로그데이터를 깔끔하게 수집하는 데 이만한 게 없으며, 많은 기업들에서 실제 서비스 로그데이터 관리를 위해 사용하고 있습니다.

Apache Flume 프로젝트는 공식 홈페이지는 https://flume.apache.org/ 입니다.

Flume의 특징

1) 시스템 신뢰성 (Reliability) - 장애가 발생시 로그의 유실없이 전송할 수 있는 기능입니다.

2) 시스템 확장성 (Scalability) - Agent의 추가 및 제거가 용이합니다.

3) 관리 용이성 (Manageability) - 간결한 구조로 관리가 용이합니다.

4) 기능 확장성 (Extensibility) - 새로운 기능을 쉽게 추가할 수 있습니다.

Flume의 주요 구성 요소

1) Source - 데이터가 발생하는 소스로부터 (로그)데이터 수집 담당

: 다양한 원천 시스템의 데이터를 수집하기 위해 Avro, Thrift, JMS, Spool Dir, Kafka등 여러 주요 컴포넌트를 제공하며, 수집한 데이터를 Channel로 전달합니다. 쉽게 설명하면 외부 이벤트가 생성되어 수집되는 영역이라고 할 수 있습니다.

- 1개 구성, 복수 Channel 지정

2) Sink - 수집한 데이터를 외부로 보내는 역할

: 수집한 데이터를 Channel로부터 전달을 받아서 최종 목적지에 저장하기 위한 기능으로 HDFS, Hive, Logger, Avro, ElasticSearch, Thrift등을 제공합니다. 쉽게 설명하면 수집된 로그/이벤트를 목적지에 전달하는 역할을 합니다.

3) Channel

: Sorce와 Sink를 연결하며, 데이터를 버퍼링하는 컴포넌트로 메모리, 파일, 데이터베디스를 채널의 저장소로 활용합니다. Source와 Sink 간의 버퍼 구간 - 채널 별로 1개 Sink 지정

4) Interceptor

: Source와 Channel 사이에서 데이터 필터링 및 가공하는 컴포넌트로서 Timestamp, Host, Filttering 등을 기본 제공하며, 필요시 사용자 정의 Interceptor를 추가합니다. 쉽게 말하면 수집된 로그/이벤트 가공 하는 역할을 합니다.

5) Agent

: Source -> interceptor -> Channel -> Sink 컴포넌틑 순으로 구성된 작업 단위로 독립된 인스턴스로 생성됩니다.

Flume을 관리하는 관리자 역할을 합니다.

Flume의 진행 순서

                                             (flume.apache.org/ 이미지 사용)

Flume 진행 순서

수집 대상 데이터(로그/이벤트) 생성  ->  수집 대상 로그/이벤트를 Source에 수신  ->

Source는 수신한 메시지를 Channel에 전달  ->  Sink는 Channel로부터 메시지를 가져와서 목적지에 데이터 전달/저장

Flume 의 단점

- Flume의 가장 큰 취약점은 데이터의 안정성

Flume은 Channel로 메모리와 파일 그리고 JDBC를 제공합니다. 메모리 타입은 처리 성능은 좋지만, Flume 장애 발생 시 데이터가 유실의 문제가 있습니다. 반면 파일 타입을 사용하면 데이터 안정성은 향상되지만, 성능이 크게 떨어집니다. 그리고 고가용성 모드로 관리하기 어렵다는 것입니다. 이러한 문제는 Kafka와 결합으로 해결할 수 있습니다.

Flume 의 장점

1. 다양한 소스와 목적지에 대한 컴포넌트가 이미 구현되어 있습니다

2. 일반적으로 Flume 설치 및 설정만으로 작업을 완료합니다.

3. 저장된 데이터를 안전하게 관리할 수 있고, 구성이 간단하고 확장성이 좋습니다. 

Flume 설치

빅데이터란?

: 오늘날 정보통신 분야에서의 화두는 단연 빅데이터입니다.

1) 빅데이터는 기존 데이터보다 너무 방대하여 기존의 방법이나 도구로 수집/저장/분석 등이 어려운 정형 및 비정형 데이터들을 의미합니다.

2) 어떤 그룹에서는 빅데이터를 테라바이트 이상의 데이터라고 정의하기도 하며 대용량 데이터를 처리하는 아키텍처라고 정의하기도 합니다(서버 한대로 처리할 수 없는 규모의 데이터, 기존의 소프트웨어로 처리할 수 없는 규모의 데이터).

빅데이터의 특징

: 빅데이터의 특징으로는 크기(Volume), 속도(Velocity), 다양성(Variety)을 들 수 있습니다.

크기(Volume) : 크기는 일반적으로 수십 테라 바이트 혹은 수십 페타바이트 이상 규모의 데이터 속성을 의미합니다.

속도(Velocity) : 속도는 대용량의 데이터를 빠르게 처리하고 분석할 수 있는 속성입니다. 융복합 환경에서 디지털 데이터는 매우 빠른 속도로 생산되므로 이를 실시간으로 저장, 유통, 수집, 분석 처리가 가능한 성능을 의미합니다.  

다양성(Variety) : 다양성(Variety)은 다양한 종류의 데이터를 의미하며 정형화의 종류에 따라 정형, 반정형, 비정형 데이터로 분류할 수 있다.

이외에 빅데이터의 특징 Veracity(진실성),  Visualization(시각화), Value(가치) 까지도 빅데이터의 특징으로 볼 수 있습니다.

진실성(Veracity) : 주요 의사결정을 위해 데이터의 품질과 신뢰성 확보하는 것을 의미합니다.  

시각화(Visualization) : 복잡한 대규모 데이터를 시각적으로 표현하는 것을 의미합니다.

가치(Value) : 비즈니스 효익을 실현하기 위해 궁극적인 가치를 창출을 의미합니다.

->  “지구 상에선 지금 이 순간에도 방대한 크기(Volume)의 다양한(Variety) 데이터들이 빠른 속도 (Velocity)로 발생하고 있다. 빅데이터는 3V를 수용하며, 데이터의 진실성(Veracity)을 확보하고, 분석 데이터를 시각화(Visualization)함으로써 새로운 효익을 가져다 줄 가치(Value)를 창출하는 것이다. “

데이터 수집과 데이터 마이닝의 중요성이 부각되고 있습니다.

데이터 마이닝(Data Mining)이란? 

데이터의미를 찾아가는 위한 과정 하드웨어의 성능이 향상과 가격 하락으로 인해 대용량의 데이터가 싸여가면서 이러한 데이터를 통해서 어떤 특징을 가지고 있는지 찾기가 어려운데 빅데이터 기술을 통해서 데이터를 통한 통찰력으로 찾지 못한 특징과 패턴을 찾도록 만들어주는 이론과 알고리즘을 통해서 현기업의 문제점, 이윤창출을 위해서 찾아가는 것이 이유가 됩니다. 이러한 과정을 데이터 마이닝(Data Mining)이라 합니다.

- 컴퓨터 사이언스와 통계/수학 등이 함계 사용되며 흔히 인공지능이나 머신러닝의 기술이 사용됩니다.

빅데이터의 진행 순서

빅데이터 수집 모듈

- 빅데이터 시스템의 구성에 있어서 가장 중요합니다.

- Flume, Kafka 등이 있습니다.

데이터 저장/ 처리 모듈(하둡)

- 빅데이터를 다루는 처리 프로세스로서 병렬 처리의 핵심은 분할 점령(Divide and Conquer)입니다. 즉 데이터를 독립된 형태로 나누고 이를 병렬적으로 처리하는 것을 말합니다. 빅데이터의 데이터 처리란 이렇게 문제를 여러 개의 작은 연산으로 나누고 이를 취합하여 하나의 결과로 만드는 것을 뜻합니다. 대용량의 데이터를 처리하는 기술 중 가장 널리 알려진 것은 아파치 하둡(Apache Hadoop)과 같은 Map-Reduce 방식의 분산 데이터 처리 프레임워크입니다.

- HDFS(Hadoop Distributed File System) : 분산 파일 시스템(저장)

- MapReduce : 분산 처리 시스템(처리) -> 자바나 스크립트 언어, C++ 사용 -> Hive 나 Pig 언어들로 프로그래밍

- MapReduce의 개념 없이 하이 레벨에서 프로그래밍 대용량 데이터의 배치 프로세싱에 적합하고, 실시간으로 데이터를 분석하는 용도로 사용하기에는 버겁습니다.

실시간 데이터를 분석하는 용도로 사용되는 프로그램들은 존재합니다 기존 관계형 데이터 베이스 , NoSQL , 검색엔진 등을 통해서 지원합니다.

● 빅데이터의 활용 사례

1) 2008년 미국 대통령 선거

 2008년 미국 대통령 선거에서 버락 오바마 미국 대통령 후보는 다양한 형태의 유권자 데이터베이스를 확보하여 이를 분석, 활용한 '유권자 맞춤형 선거 전략'을 전개했습니다. 유권자 지도를 작성한 뒤 유권자 맞춤형 선거 전략을 전재하는 등 오바마 캠프는 비용 대비 효과적인 선거를 치를 수 있었습니다.

2) 대한민국 제 19대 총선

 여론 조사 기관들은 기존 여론조사 방식으로 예측한 2010년 제5회 지방 선거 및 2011년 재보궐선거의 여론조사 결과와 실제 투표 결과와의 큰 차이를 보완하고자 빅 데이터 기술을 활용한 SNS 여론 분석을 시행하였습니다. 하지만 20~30대에 쏠려 있었고, 수도권으로 한정되어 일치하는 한계를 드러내었습니다.

이외에도 경제 및 경영, 문화, 과학기술 및 활용 등 다양한 분야에서 사용되고 있습니다.

빅데이터의 문제점

: 바로 사생활 침해와 보안 측면에 자리하고 있습니다. 빅데이터는 수많은 개인들의 수많은 정보의 집합입니다. 그렇기에 빅데이터를 수집, 분석할 때에 개인들의 사적인 정보까지 수집하여 관리하는 빅브라더의 모습이 될 수도 있는 것입니다. 그리고 그렇게 모은 데이터가 보안 문제로 유출된다면, 이 역시 거의 모든 사람들의 정보가 유출되는 것이기에 큰 문제가 될 수 있습니다. 

- 페이스북 - 케임브리지 애널리티카 정보 유출 사건

페이스북-케임브리지 애널리티카 정보 유출 사건은 2018년 초에 케임브리지 애널리티카 회사가 수백만 페이스북 가입자의 프로필을 그들의 동의 없이 수거해서 정치적 선전을 하려는 목적으로 사용했다는 사실이 세상에 밝혀지면서 일어난 사회적 물의 및 정치적 논쟁입니다. 이 사건으로 인해 개인 정보에 대한 이해와 인식이 높아졌고, 기술 관련 기업들의 데이터 사용에 대해 엄격한 규제를 요청하는 분위기가 생겼습니다.

2019년 7월에 넷플리스에 개봉된 오리지널 다큐멘터리 <거대한 해킹> 에서 파슨스 디자인 스쿨의 부교수 데이비드 캐럴은 이렇게 이야기했습니다.

우리의 온라인 활동에서 나오는 데이터가 그냥 사라지진 않는다. 우리의 디지털 흔적들을 모으고 분석하면 매년 1조 달러 규모의 산업이 된다. 우린 이제 원자재가 된 것이다. 그럼에도 불구하고, 누구도 이용 조건을 읽어보려고 하지 않는다. 우리의 모든 교류 내역과 신용카드 결제, 웹 검색, 위치 정보, ‘좋아요’까지 우리의 신원과 결부되어 실시간으로 수집된다. 그 데이터를 구매하는 누구든, 우리의 감정의 고동에 곧바로 접속할 수 있다. 그들은 이런 지식으로 무장하고 우리의 관심을 끌기 위해 경쟁한다. 개인 맞춤형으로 각자 혼자만 보는 콘텐츠를 지속적으로 제공하면서. 이것은 우리 모두에게 해당되는 진실이다. -《거대한 해킹》 내용 中