Big Data: 78개의 글
package com.lucene.study; import java.io.File; import java.io.FileFilter; import java.io.FileNotFoundException; import java.io.FileReader; import java.io.IOException; import org.apache.lucene.analysis.standard.StandardAnalyzer; import org.apache.lucene.document.Document; import org.apache.lucene.document.Field; import org.apache.lucene.index.IndexWriter; import org.apache.lucene.index.IndexWrite..
High-Availability Distributed Object-Oriented Platform 깃허브: https://github.com/apache/hadoop 1. 하둡이란? 대용량 자료를 처리할 수 있는 컴퓨터 클러스터에서 동작하는 분산 응용 프로그램을 지원하는 오픈소스 자바 프레임워크 분산 데이터 처리 기술: 큰 용량의 단일 서버보다 여러 서버의 작은 용량을 묶은 컴퓨터 클러스터가 가성비가 더 좋다. 하둡의 핵심 철학: 코드(가벼움)를 데이터(무거움)가 있는 곳으로 보낸다. 레이드와 하둡 레이드시스템은 디스크는 여러개, OS도 1개, CPU1개. 10펙타바이트를 처리할때 OS와 CPU가 죽어난다(매우 느림) 하둡은 디스크도 여러개, OS도 여러개, CPU도 여러개. 10펙타바이트를 처리할때 분..
먼저 클라우데라를 소개하면 - 하둡 기반 빅데이터 벤처기업의 대표적인 선두주자로 야후, 오라클, 출신 등의 사람들에 의해 2008년 설립 - 여기서 만든 CDH라는 하둡 배포판이 아파치 파운데이션이 만든 아파치 하둡 배포판보다 훨씬 더 많이 사용됨 하둡은 - 대용량 자료를 처리할 수 있는 컴퓨터 클러스터에서 동작하는 분산 응용 프로그램을 지원하는 오픈소스 자바 프레임워크 - 하둡은 크게 분산 저장과 병렬 처리, 2개의 프레임워크로 구성 - 분산 저장은 클러스터 환경에서 대용량 데이터를 분산하여 안정적으로 저장하는 프레임워크 - 병렬 처리는 저장 환경 위에서 병렬로 데이터 Processing하는 프레임워크 - 여러 대의 컴퓨터를 모아 디스크를 묶어서 쓸 수 있게 하는 분산 저장소와, CPU를 동시에 쓸 수..
실시간 로그 집계와 같은 대용량 데이터 처리를 위해서는 애플리케이션의 처리량(Throughput)이 높아야 한다. 카프카에서는 대용량의 실시간 데이터 처리를 위해 배치 전송, 파티션, 분산 기능을 구현했다. 또한 중앙 시스템의 역할을 하는 중요한 서비스에서 서버 장애가 발생하더라도 서비스에 영향이 없도록 데이터의 안정적인 저장을 위해 리플리케이션 기능과 분산된 서버에서 자동으로 파티션의 리더를 선출하는 기능을 구현했다. 카프카는 분산된 데이터 파이프라인을 표준화하고 통합하길 원했고, 처리량에 중점을 두고 설계되었다. 이에 따라 카프카에는 높은 처리량과 빠른 메시지 전송, 운영 효율화 등을 위해 분산 시스템, 페이지 캐시, 배치 전송 처리 등의 기능이 구현되었다. 카프카 디자인의 특징1) 분산 시스템동일한..
카프카는 대용량, 대규모 메시지 데이터를 빠르게 처리하도록 개발된 메시징 플랫폼이다. 서비스를 유지하려면 기본적으로 다음과 같은 데이터 시스템이 필요하다.시스템설명메트릭 모니터링용 데이터 시스템앱이나 서비스에서 일어나는 미터링(사용량, 응답 시간, 에러 카운트 등) 정도를 저장할 시계열 데이터 처리용 시스템로그 모니터링용 데이터 시스템앱/서비스에서 발생하는 로그를 저장하고, 이것을 기반으로 실시간/배치로 분석할 수 있도록 데이터를 저장하는 시스템서비스에 필요한 컨텐츠와 고객 정보 데이터들을 저장하는 메인 데이터 시스템대부분의 앱들에서 보낸 OLT(Online Transaction Process) 쿼리(주로 데이터 갱신)를 실행한다.추천이나 장바구니와 같이 트랜잭션 처리까진 필요없지만 실시간으로 처리를 해..
카프카는 여러대의 서버에 분산되어 실행되고, 각 토픽은 여러 개의 파티션으로 분리되어 있으며 각 브로커에 복제되어 분산되어 저장되는 등 복잡하게 운영되는 애플리케이션이다. 따라서 카프카 클러스터를 운영하다 보면 다양한 이슈가 발생하게 되고, 이슈들을 대응하기 위해 토픽의 상태 정보, 토픽의 설정 변경 작업 등이 매우 빈번하게 발생한다. 1) 토픽 설정 변경카프카를 운영하면서 토픽의 설정을 변경해야 하는 경우가 있다. 운영 중인 카프카의 디스크 공간을 확보하는 가장 좋은 방법은 디스크 공간을 가장 많이 차지하는 토픽의 보관 주기를 줄여주는 것이다. 토픽 보관주기의 기본값은 7일이다. 토픽의 보관주기 설정을 변경하기 위해 kafka-configs.sh 명령어를 이용한다. 추가 옵션으로는 --zookeeper..
카프카 프로듀서 주요 옵션 (https://kafka.apache.org/documentation/#producerconfigs) 옵션 설명 bootstrap.servers 카프카 클러스터는 클러스터 마스터라는 개념이 없기 때문에 클러스터 내 모든 서버가 클라이언트의 요청을 받을 수 있다. 해당 옵션은 카프카 클러스터에 처음 연결을 하기 위한 호스트와 포트 정보로 구성된 리스트 정보를 나타낸다. 정의된 포맷은 "호스트 이름:포트, 호스트 이름:포트, 호스트 이름:포트"이다. 전체 카프카 리스트가 아닌 호스트 하나만 입력해 사용할 수 있지만, 이 방법을 추천하지는 않는다. 카프카 클러스터는 살아있는 상태이지만 해당 호스트만 장애가 발생하는 경우 접속이 불가하기 때문에, 리스트 전체를 입력하는 것을 권장한다..
토픽의 파티션 수가 증가함에 따라 빠른 전송이 가능하다. 그렇다면 토픽의 파티션 수를 많이 늘리는 것이 무조건 좋은 것은 아니다. 파티션 수가 늘어나면 오히려 카프카에 좋지 않은 영향을 미칠 수도 있다. (1) 파일 핸들러의 낭비각 파티션은 브로커의 디렉토리와 매핑되고, 저장되는 데이터마다 2개의 파일(인덱스와 실제 데이터)이 있다. 카프카에서는 모든 디렉토리의 파일들에 대해 파일 핸들을 열게 된다. 결국 파티션의 수가 많을수록 파일 핸들 수 역시 많아지게 되어 리소스를 낭비하게 된다. (2) 장애 복구 시간 증가카프카는 높은 가용성을 위해 리플리케이션을 지원한다. 브로커에는 토픽이 있고, 토픽은 여러 개의 파티션으로 나뉘어 있으므로, 브로커에는 여러 개의 파티션이 존재하게 된다. 또한, 각 파티션마다 ..
키바나는 오픈소스 웹기반 분석 및 시각화 도구다. 엘라스틱서치에 저장된 데이터를 다양한 테이블과 지도, 차트 등을 사용해 시각화할 수 있다. 사용자는 간단한 인터페이스를 사용해 손쉽게 엘라스틱서치에 저장된 많은 양의 데이터를 탐색하고 실시간으로 데이터 분석을 할 수 있다. 키바나는 시각화 생성에 사용하는 데이터를 쿼리하기 위해 엘라스틱서치에 의존하는 시각화 도구이다. 따라서 키바나를 사용하려면 엘라스틱서치를 설치하고 실행해야 한다. 키바나는 JVM에서 실행되는 엘라스틱서치와 로그스태시와 달리 node.js로 실행하는 웹애플리케이션이다. 키바나를 실행하면 http://localhost:9200 에서 구동 중인 엘라스틱서치에 연결을 시도한다. 기본 포트는 5601로 시작하며, 웹브라우저를 사용해 접근할 수 ..
엘라스틱서치 API를 조금더 확장하고, 성능을 개선하고 장애 복구 계획을 구현하기 위해 필요한 엘라스틱서치 클러스터 모니터링과 튜닝이라는 목적에 맞게 이 API들을 사용하는 방법에 대해서 알아본다. 개발자와 운영자 모두 엘라스틱서치 클러스터를 모니터링하고 관리할 수 있다. 시스템의 부하가 높은 적정 수준이든, 하드웨어나 시스템 장애에 대비하고 성능 병목 지점을 이해하고 확인하는 것은 매우 중요할 것이다. REST API를 이용한 클러스터 관리기법에 대해 알아보고, 이를 통해 실시간 관리 기법과 다른 베스트 프랙티스들을 활용하여 잠재적인 성능 병목 지점을 파악하고 적절한 조치를 취할 수 있을 것이다. 효율적으로 성능을 모니터링하는 것은 시스템 최적화를 위해 매우 중요하고 시스템을 이해하는 것은 장애 시나리..