2. 히스토리
1970년대 코볼 기반 계층형 시스템 논쟁
1990년대 관계형 데이터베이스 인기
2000년대 인터넷 활성화로 데이터의 종착지
에는 거대한 데이터가 쌓임 : 구글,페북 ...
관계형 데이터베이스로 처리가능?
결국 인터넷 거인들은 거대한 데이터를 처리
하기 위한 다른 방안 모색
3. 히스토리(계속)
구글은 자신들의 노하우를 논문으로 공
개 하여 대중과 소통.
이 논문을 루씬의 창시자 더그커팅이 오
픈소스로 구현. 하! 둡!
구글에 충격을 받은 인터넷 거인들이 점
차적으로 자신들의 노하우를 외부에 공
개해서 기술력을 자랑.
공개된 노하우는 모두 오픈소스나 상용
소스로 만들어짐
4. 빅데이터?
정의:빅데이터는 당신이 생각하기에 충
분히 큰 데이터이고 이로부터 어떤 이익
을 얻기 위해..... 이하 생략
고객들의 주머니를 털기 위한 거대한 마
케팅엔진에서 만들어낸 용어!
왜냐하면 기술은 오래 전에 만들어졌고
사용되어 왔지만 근래 유행
하!지!만! 빅데이터는 데이터를 바라보는
시각을 바꾸는 계기가 된 것은 분명하다
5. 빅데이터와 하둡?
빅데이터를 다루는 기술들은 여러가지가
있고 이를 NoSQL이라고 칭함
NoSQL류의 기술은 크게 그래프데이터
베이스, 키-밸류 저장소, 문서저장소, 컬
럼 패밀리 저장소로 분류됨
그럼 하둡은?
하둡은 NoSQL 중에 일부의 기술들의 핵
심 인프라 역할을 함(HBase)
6. 하둡의 구조
하둡은 크게 하둡 분산 파일 시스템과 맵
리듀스가 있음
하둡 분산 파일 시스템은 유닉스 파일 시
스템과 비슷한 역할을 함
맵리듀스는 하둡 분산 파일 시스템에 저
장된 데이터를 처리하기 위한 목적
처리의 의미는?
처리 : 저장된 파일에서 데이터를 추출하
여 일정하게 가공한 뒤에 이를 다시 병합
7. 하둡 분산 파일 시스템
네임노드와 데이터 노드가 존재.
네임노드는 디렉터리의 구조에 대한 정보를
저장.
데이터 노드는 실제 데이터를 저장.
네임노드가 날라가면 큰일이다. 따라서 네
임노드는 튼튼한 서버로 준비하는 것이 좋
다.
하둡 분산 파일 시스템에는 데이터는 비구
조화 되어 저장(DBMS에는 구조화저장).
8. 맵리듀스
맵리듀스는 하둡 분산 파일 시스템에 저
장된 파일에서 데이터를 읽어서 가공하
는 역할
각 데이터 노드에서 맵리듀스가 돌아간
다
그래서 여러대의 노드에서 분산처리 하
기 때문에 병렬 처리 프레임워크라고 함
어떤 데이터를 처리할까? 텍스트 파일로
된 데이터이다.
9. 맵리듀스(계속)
맵리듀스가 처리할 수 있는 데이터는 이
미지나 동영상 파일이 아님!! 절대 광파는
사람들에게 속지 말것!
맵리듀스는 맵 잡과 리듀스 잡으로 분리
될 수 있음.
맵 잡은 데이터 노드에서 데이터를 읽고
1차 가공하는 역할이고
리듀스 잡은 맵 잡에서 모은 데이터를 최
종 가공하는 역할임
10. 맵리듀스(계속)
예를 들어 데이터 노드 1번에서 맵 잡1번
이 돌고, 데이터 노드 2번에 맵 잡 2번이
도는 경우, 맵 잡 1번과 2번에서 나온 결
과를 리듀스 잡이 받아서 병합함
맵리듀스로 데이터 처리를 위해서는 하
둡에서 제공하는 양식에 맞추어 직접 맵
잡과 리듀스 작업을 직접 프로그래밍 해
주어야 함 개발자 구하기 힘들고 배워
서 하기도 힘듬.
11. 하둡 에코시스템
맵리듀스 잡을 직접하지 않고 간접적으로
구동할 수 있도록 pig, hive와 같은 하둡 에
코 시스템들이 있음. hive와 같은 경우
select * from emp; 처럼 ansi-sql의 구문을
이용하여 맵리듀스를 돌릴 수 있음
hive를 ETL처럼 돌려 배치잡을 수행할 수
있음.
ETL과 같은 툴처럼 작업하기 위해서는 쿼리
와 같은 쿼리를 수십번 돌려야함. 유사하게
여러개 쿼리(맵리듀스 잡)을 돌릴 수 있게
워크플로우 역할 우지(oozie)라는 오픈소스
가 있음
12. 하둡 에코시스템
또한 데이터노드가 수십 수백개 인경우에는
관리가 힘들기 때문에 노드들을 관리하기 위
한 Ganglia 와 같은 오픈소스 있음
로그 파일과 같이 수집 해야할 서버들이 많은
경우 아파치 플룸과 같은 수집전문 오픈소스
를 이용할 수 있음
하둡 기반으로 데이터를 구조화 시켜 저장할
수 있는 HBase 오픈소스가 있음 이는 컬럼 패
밀리 저장소로 분류됨
14. 저장만 하면 돈되나?
하둡은 배치 전용이다. 즉!!! DBMS 처럼
select * from emp; 한방 날린다고 데이터가
바로 팍! 뜨지 않는다..
이런걸 원하는 분들이 많은 관계로 국내에
서는 수집된 로그 데이터를 검색엔진의 인
덱스로 말아서 결과가 팍팍 뜨도록 하는 아
키텍처를 쓰기도한다.
그런데, 똑같은 데이터가 하둡에도? 검색엔
진(elastic search)에도 있다. 미친짓이다.
장비 값이 더 든다.
15. 저장만 하면 돈되나?
하둡에 쓰레기에 가까운 로그데이터를
쌓아둔다고 돈이 되나? 분석을 해야 금을
캘 가능성이라도 있다.
Hive를 이용해서 ETL을 수행해서 결과를
Oracle같은 DBMS에 넣고 이를 Web을
이용해서 출력하는 방법도 있음(전통적
인 BI 제공방식)
데이터가 많은 경우 Hive를 통해서 ETL
을 돌리면 조금은 빠름... 그런데 데이터
정확도??
16. 저장만 하면 돈되나?
그래서 R 과 같은 통계 언어를 하둡에 포
팅해서 직접 데이터를 뽑으려고도 한다.
또한 Oracle, IBM 과 같은 솔루션 벤더들
에서는 하둡을 지원한다고 한다.
그런데 다들 하둡은 손안데고 그냥 자사
제품이 하둡이랑 잘 맞는다고 자랑만 한
다.. 그럴 거면서 왜 마케팅은 그렇게 했
는지 모르겠다.
17. 그래서...
클라우데라와 같은 업체에서는 이들 오
픈소스를 패키지로 묶고 관리하기 편하
게 제품화 형태로 제공함 하지만 이것
도 좀 알아야 쓸 수 있음
국내에도 클라우데라를 꿈꾸는 일부 업
체가 있음
하지만 하둡을 다룰 줄 아는 SW인력이
없는 곳에서는 이를 도입하는 것은 자살
행위이다.. 돈 많으면 예외다.
생각보다 장애가 많다. 원인도 모른다.
만들었어야 알지....
18. 그래서...(계속)
스플렁크는 머리를 잘 굴렸다. 다들 앞선
고민 때문에 하둡 도입을 꺼려하고 있고
로그에서 금을 찾고 싶은 고객님들께 광
팔기 딱 좋게 제품화 하여 보여주고 다닌
다.
그런데 이것도 쓰는 사람 따라 틀릴 것이
다. 결국 툴이 문제는 아니라 쓰는 사람
이 잘 써야 한다. 아무리 좋은 도구가 있
어도 잘못 쓰면 독이 된다.
