빅데이터 적재 적재1 (대용량 로그파일 적재)

수집을 했다면  데이터를 어디에 어떻게 저장할 것인가를 다룬다. 

-수집한 데이터는 특징에 따라서 처리하는 방식과 적재 하는 위치에 따라서 달라진다.

-데이터의 발생주기 에따라 일괄 배치성 데이터인지 실시간 데이터 인지 판단하고 데이터의 형식에 따라 가공 처리나 사전 검증 작업을 할 것인지도 판단해야한다.

내/외부 원천 데이터는 정형데이터와 반전형데이터 비정형데이터로 나뉜다. 적재 저장소는  배치성 처리(대용량) 와 실시간 처리(메시지)에따라서  2가지 로나누어진다. 

(1) 정형 데이터(structured data)
정형 데이터(structured data)는 정형화된 스키마(형태) 구조 기반의 형태를 가지고 
RDB 및 스프레드시트 등과 같이 고정된 필드에 저장되며 값과 형식에서 일관성을 가
지는 데이터를 말한다.
(2) 비정형 데이터(unstructured data)
비정형 데이터(unstructured data)는 스키마(형태) 구조 형태를 가지지 않고 소셜 미디어(SNS) 
및 Web(웹) 게시판, NoSQL 등과 같이 고정된 필드에 저장되지 않는 데이터를 말한다.
(3) 반정형 데이터(semi-structured data)
반정형 데이터(semi-structured data)는 스키마(형태) 구조 형태를 가지고 XML, HTML, 
웹(web) 로그, 시스템 로그, 알람 등과 같이 메타데이터(metadata)를 포함하며, 값과 형
식에서 일관성을 가지지 않는 데이터를 말한다

배치처리

• 대용량 데이터 파일처리 -> 분산파일시스템 (HDFS)
• 대규모 메세지 전체를영구 저장 -> NoSQL
• 대규모 메세지 전체를 버퍼링 처리 -> 카프카
• 대규모 데이터 일부만 임시저장 -> redis(InMemoryDB)

빅데이터 적재는 배치성 처리(대용량) 와 실시간 처리(메시지)에따라서 나누어진다. 

 

하둡(Hadoop.com)

빅데이터의 핵심 소프트웨어다. 빅데이터의 에코시스템(생태계)은 대부분 하둡을 위해 존재하고 하둡에 의존하여 발전하고 있다.

하둡

-1.대용량 데이터를 분산 저장하는것이고 두번째는 분산 저장된 데이터를 가공/분석 처리하는기능이다. 

-2.가공/분석을 위해 분산 병렬처리 기술을 사용했다.

 

분산 파일 시스템은 은 1TB데이터를 블록단위(64MB or 128MB 등)로 3개의 노드에 저장한다고 생각하면 되고, 가공 처리는 노드마다 파일들이나눠서 저장되어있기때문에 분산된 데이터들을 활용하기 위해서는 별도로 처리를 해야한다.

하둡 주요구성요소

DataNode	블록(64MB or 128MB 등)  단위로 분할된 대용량 파일들이 DataNode의 디스크에 저장 및 관리를 한다.
NameNode	DataNode에 저장된 파일들의 메타 정보를 메모리상에서 로드 해서 관리한다.
EditsLog	파일들의 변경이력(수정,삭제등)정보가 저장되는 파일
FsImage	NameNode의 메모리상에 올라와 있는 메타 정보를 스냅샷이미지로 만들어 생성한 파일

ver1.x

ver2.x

 

현재 하둡은 최신 버전은 3.x 에서는 2.x의 구성요소의 큰 차이가 없지만 네임노드 안정성이 강화 되고 HDFS의 효율성과 맵리듀스의 성능 등을 크게 개선했다. 

하듑 아키텍처

하둡의 아키텍처는 1.x버전에서 2.x버전으로 넘어오면서 변화의 혁신을 가져왔고 최근에는 3.x가 릴리스 되면서 다시 큰 변화를 가져왔다.

클라이언트에서 하둡의 파일을 읽기 /쓰기를 할때에는 우선 NameNode를 참조해서파일을 읽기 /쓰기한다. 하둡에 적재된 데이터를 분석해야 할때에는 클라이언트 가 JobTracker에게 맵리듀스 실행을 요청하면 JobTracker가 스케줄링 실현하기 위해서 작업 할 DataNode / Tracker를 선정한다.

선정된 TaskTracker에  맵리듀스 프로그램이 전달되어 저장된 파일을 이용해 맵리듀스 작업들이 실행된다.

1.x의 아키텍처 NameNode의 이중화 기능 미지원되면서 SPOF 단일 장애 접점 가 존재 한다

하둡 파일 적재하기위해서는 NameNode에 문제 발생되면 전체에 장애가 발생된다. 이를 보완하기위해서 네임노드에 HA 작업을 해야 하고 그로인해서 복잡하고 비용이 많이드며 분산 병렬 처리 하면서 스케줄링과 리소스 배분 정책이 효율적이지 못해 병목이 자주 발생되서 개선점이 필요했다.

하둡 2.x 아키텍처에는 1.x의 문제점을 개선하기 위한 다양한 컴포넌트가 교체 및 추가 됐다. 하둡 버전 2.x로 오면서 자체적으로 NameNode Active/Stand-By가 추가되었고, MapReduce에서 YARN이 추가되었다. 기존 하둡1.x 버전에서는 리소스 관리를 취약하다는 단점이 있어서 해결책으로 나왔다

하둡 활용방안 

-비교적으로 크기(100MB이상 실제 환경에서는 GB 이상의 파일을 저장)의 파일로서 HDFS의 특정 디렉토리에 일자 단위로 파티션해서 적재한다. 

-파일럿 환경에서는 이런 일련의 작업을 하이브를 사용하며 대규모 하이브 작업에서는 분산 병렬 처리 를 위해 맵리듀스 프로세스가 내부적으로 작동되며 하이브의 처리 결과는 다시 HDFS의 특정 영역(HIve data warehouse)에 저장되다.

주키퍼 

수십 수천대 의 서버에 설치돼 있는 빅데이터 분산 환경을 더욱 효율적으로 관리하기 위해서는 서버간 정보를 쉽고 안전하게 공유해야한다.

공유된 정보를 이용해 서버간의 중요한 이벤트(분산락 , 순서제어 , 부하 분산, 네임 서비스등)를 관리하면서 상호 작용을 조율해 주는 코디네이터 시스템 이 주키퍼다. 

주키퍼 

-현재 아파치 최상위 프로젝트로 승격되어 독립적으로 발전하고 있다.

-최초 주키퍼는 하둡의 서브 프로젝트로 시작됬다.

-주키퍼는 Hadoop Hbase, kafka strom등 의 분산 노드 관리에 사용중이다. 

주키퍼 아키텍처 

ㅜ

주키퍼는 3대이상의 홀 수개의 서버 구성되며 그중 한개의 서버는 리더서버(leader server) 가되고 나머지 팔로워서버(Follow server)서팔로워서버1에 저장된 znode는 정보는 리더서버에 전달되고 리더서버는 다른 모든 팔로워 서버에 요청받는 znode 정보를 브로드캐스트라고한다.

파일럿 프로젝트에서 사용하는 hadoop HBase, kafka strom의 내부에서 주키퍼에 의존해 클러스터 멥버십 기능 및 환경설정의 동기화 

등을 사용하고 있어 없어서는 안될존재다.

실습

jar 파일 생성

xml 파일 설정

jar 파일 생성

jar 파일 생성

원하는경로에 원하는 이름으로 jar파일설정후 피니쉬 눌른다.

jar 파일 추출후 파일을 찾아서 winScp 앱을 이용해서

/(root)/opt/cloudera/parcels/CDH-6.3.2-1.cdh6.3.2.p0.1605554/lib/flume-ng/lib/에 추출한jar파일 넣어준다.

그후에 

에이전트 구성 파일 설정한다.

에이전트 구성파일 배포후에 클라우터 새로고침 과재시작을 해준다.

새로고침 해도 파일업로드 가 되지 않으므로 꼭 재시작을 하자!

cd /var/log/flume-ng/ tail-f  flume-cmf-flume-AGENT-server02.hadoop.com.log 
경로로 들어가서 플럼 로그에서 오류가있는지 확인한다.

 

리눅스 명령어

tail -f 뒤에서 10개만 보겠다.

cat 전체보기 

head 앞에 있는거 10개만 보겠다.

 

실시간 로그 데이터를 실행한다.

 

플럼 파일럿 프로젝트 생성되었음을 알수있다.

Hdfs 경로 로들어간다.

jar 파일 을 실행시킨다.