개발블로그

주키퍼 주키퍼는 분산 코디네이션 시스템이다. 분산 환경에서 여러 노드 간에 조정자 역할을 한다. 만약 하나의 노드에 워크로드가 많이 갔다면, 로드밸런싱 해주는 기능도 포함되어 있다. 주키퍼 아키텍처 디렉토리 기반으로 데이터를 저장한다. Key-value방식으로 znode라는 저장 객체를 저장한다. 데이터를 파일시스템과 같이 계층화된 구조로 저장하기에 용이하다. Watch 기능 주키퍼 클라이언트가 특정 znode에 watch기능을 걸어놓을 수 있다. Watch기능을 걸어 놓는다면, 해당 노드의 변화를 콜백 형식으로 업데이트 받는다. 복제기능 주키퍼 서버들은 모두 데이터를 복제해서 가지고 있다. 주키퍼 서버들은 연결이 되면 리더를 선택하게 된다. 이 때 리더는 모든 서버들의 저장된 것을 복제한다. 또 리더가..

Yarn 얀의 이름은 Yet Another Resource Negotiator의 약자이다. 얀은 한마디로 하둡의 리소스를 관리하고 관장하는 시스템이다. 얀의 등장에 의해 하둡은 큰 아키텍쳐의 변화가 생겼다. 1.0에서는 HDFS와 MapReduce만 있는 구조였지만, 얀의 리소스 매니저가 다른 어플리케이션도 지원하면서, 여러 어플리케이션이 HDFS를 접근할 수 있게 되었다. 이 때문에 하둡 위에 Spark나 Hbase와 같은 시스템들이 올라갈 수 있는것이다. HDFS의 일이 파일을 읽고 쓰는 일이었다면, 얀의 일은 자원을 요청하고 할당하는 일이다. 하지만 이는 사용자(개발자)가 해주지 않고, 시스템이 알아서 해주는 것이다. 얀 어플리케이션은 클라이언트로부터 요청을 받으면 먼저 리소스매니저에게 전달 된다...

하둡 스트리밍 하둡 스트리밍으로 맵리듀스를 처리할 때와의 근본적인 차이점은, 하둡 스트리밍은 맵과 리듀스 작업 중간에 워커의 로컬 디스크에 쓰기를 하지 않는다. 유닉스의 stdin stdout을 중간 연산에 사용한다. HDFS 파일시스템의 기본 연산은 file io (read/write) 이다. 하지만 hdfs는 기본적으로 write once, read many를 지향하는 구조이다. 데이터가 한번 쓰이면, 중간에 붙이는 것은 불가능하고, 끝에 붙이는 것만 가능하다. 따라서 저장은 한번 하고, 분석 작업을 할 때 많이 읽을 수 있게 하기 위한 구조라는 것이다. HDFS의 가장 중요한 설계 원칙 중 하나는 Fault-Tolerance이다. 따라서 하나의 노드에 장애가 발생했을 때, 다른 노드에서 같은 데이터..

맵리듀스 복습 맵 단계 위 그림에서는 맵을 수행할 수 있는 기기가 4개 있음 인풋 단계의 데이터를 4개의 블록으로 나누고, Map이라는 Task를 각 기기에 분배해 준다. Map을 수행하는 TaskTracker는 해당 작업을 수행하게 된다. Map을 실제로 짜는것은 개발자의 몫이다 Input을 받아 Output을 내는 각각의 함수를 작성한다. 쌍으로 입력을 받고 로컬에 파일로 저장한다. 셔플 단계 위 함수의 결과를 받아 하둡 시스템이 셔플을 진행한다. 정렬된 리스트를 다시 리듀스 TaskTracker기기에 전달한다. 셔플은 시스템이 알아서 수행해 준다. 리듀스 단계 리듀스 함수는 집계를 하고, 얻어진 결과를 파일로 출력하는 일을 수행한다. 리듀스도 TaskTracker가 수행하는데, 함수는 역시 개발자가..

서론 빅데이터 시대의 도래 1950년대 첫 컴퓨터가 나옴 (폰노이만) - 프로그램 내장 방식 1960년대 운영체제와 프로그래밍 언어 등장 (FORTRAN 및 COBOL) 1964~ 대화형 컴퓨터, 시분할, 다중 프로그래밍 1970년대 고밀도 직접회로, 마이크로 컴퓨터, PC시대 (MS, Apple 설립) 1990년에 www 인터넷, 1995 Java 기기가 개인화되고 데이터가 많아짐 빅데이터 처리 시스템이 필요하다 데이터 생성의 주체 기존에 데이터는 인간이 만들어 냈다. 기기가 보편화되고 센서들(IoT)이 많이 나오면서, 인간 외에도 데이터를 만들어내는 주체가 생겼다. 텍스트 비텍스트 - 숫자, 카테고리, 관계, 오디오, 비디오 등 빅데이터의 특성 (3V) 데이터의 볼륨 (Volume) 테라바이트, 페타..