CStory

Observer Name Node 이전 포스팅 내용처럼 2024.01.08 - [Data Engineering/Hadoop] - Hadoop의 High Availability (고가용성) 아키텍처 Hadoop의 High Availability (고가용성) 아키텍처 Name node의 HA 하둡의 버전 1까지는 namenode는 SPOF(Single Point Of Failure)였다. datanode는 수평적 확장이 가능했지만, namenode는 하나의 인스턴스를 유지해야했으며 이 namenode가 이용불가능 해지면 클러스터 cstory-bo.tistory.com 여러 HA Architecture를 통해서 HA는 달성했지만 여전히 active namenode에 부하를 주는 문제가 발생한다. 이 부하를 해..

Name node의 HA 하둡의 버전 1까지는 namenode는 SPOF(Single Point Of Failure)였다. datanode는 수평적 확장이 가능했지만, namenode는 하나의 인스턴스를 유지해야했으며 이 namenode가 이용불가능 해지면 클러스터 전체가 이용 불가하다. HA Architecture 위의 그림처럼 Active, Stanby 2개의 상태 namenode를 두어서 SPOF 문제를 해결했다. active namenode가 다운되면, standby namenode가 승격되어 downtime을 최소화한다. 또한 stanby namenode는 backup namenode 역할도 수행한다. 이처럼 namenode가 예상치 못한 장애에 대해서 자동화된 failover를 수행할 수 있으..

Name node & Data node Name Node Name node는 블럭의 위치, 권한 등의 메타 데이터를 가진다. 기본적으로 메모리에 메타데이터를 저장하고 2가지 종류의 파일로도 기록한다. 1. Fsimage : File System Image로 네임노드 생성 이후부터 namespace 정보를 모두 가지고 있다. 2. Edit log : Fsimage로부터 현재까지의 변경사항 로그이다. 이제는 Name node의 기능을 알아보자. Metadata Management 파일 시스템을 유지하기 위한 메타데이터를 관리한다. 파일 시스템 이미지(파일명, 디렉토리, 사이즈, 권한 정보)와 파일에 대한 블럭 매핑 정보를 가지고 있으며 빠르게 응답해야 하기 때문에 메모리에서 관리한다. File System ..

HDFS HDFS는 하둡의 file system을 말한다. Design Goal 1. Hardware Failure hdfs는 분산 서버에 발생하는 다양한 장애를 빠른 시간에 감지하고 대처할 수 있게 설계되었다. 데이터를 저장하면 복제본을 만들며 분산 서버들은 주기적으로 health check를 통해 장애를 빠르게 감지하고 대처한다. 2. Streaming Data Access HDFS는 클라이언트의 요청을 빠르게 처리하는 것보다 동일한 시간 내에 더 많은 데이터를 처리하는 것을 목표로 한다. 그래서 user와의 상호작용보다는 batch 처리에 더 맞게 디자인 되어있다. HDFS는 Random Access 대신 Streaming 방식으로 데이터를 접근한다. 3. Large Data Sets 하나의 파일이..

Hadoop 소개 점차 데이터 양과 종류가 다양해지면서 비정형 데이터들을 RDBMS에 저장하기에 데이터 크기도 크며 그렇게 까지 상세한 기능이 필요하지 않으면서 비용이 비쌌다. 하둡은 굳이 비싼 장비가 아니라도 어떤 수준의 장비든지 상관없이 설치해서 운용할 수 있으며 단순히 노드를 늘리며 용량을 키울 수 있다. 그리고 데이터 복제본으로 유실이나 장애에 대비할 수 있다는 장점이 있다. 뿐만 아니라 이렇게 여러 노드로 나누어 데이터를 저장하기에 분산 컴퓨팅을 통해 성능을 향상할 수 있다. Hadoop 생태계 하둡 버전1은 분산 파일 관리 시스템인 HDFS와 데이터 처리를 위한 mapreduce 프레임워크만 제공했다. 버전 2로 가면서 Yarn이라는 resource management 프레임워크를 도입하여 유..

이번에는 직접 이전 블로그 포스팅 했던 내용을 기반으로 클러스터를 구성해보려고 한다. 위와 같이 구성하였으며 클러스터 매니저 노드를 위한 서버 1개, 데이터&인제스터 노드 2개, 코디네이터 전용 노드 1개로 총 4개의 서버를 이용하였다. AMI를 이용한 서버 생성 우선 하나의 ec2 서버를 생성하고 OpenSearch를 설치한다. 이때 실행은 하지 않는다. 아래 글을 참고한다. 실행은 하지 않으며 systemctl service에 등록만 한다. 2023.12.27 - [Data Engineering/Distributed System] - EFK(ELK) 구축 해보기!! (서버 로그 수집) - 4. OpenSearch와 Open Dashboard 설치하기 EFK(ELK) 구축 해보기!! (서버 로그 수집)..

이전에는 OpenSearch가 어떻게 개별 쿼리나 인덱스에 대해 어떻게 처리되는지를 알아봤다면 이번에는 어떠게 대량의 인덱스와 쿼리들을 안정적으로 처리하는 지를 알아보려 한다. OpenSearch 분산 아키텍처 OpenSearch는 아래 요소들로 구성된다. Cluster (클러스터) Node (노드) Shard (샤드) Segment (세그먼트) 클러스터는 노드의 집합을 말한다. 그리고 노드는 클러스터를 구성하는 하나의 인스턴스로, 도큐먼트가 저장되는 곳이다. 하나의 가상 서버로 보아도 된다. 클러스터는 도큐먼트를 여러 노드에 분산시켜 저장할 수 있다. 모든 노드는 클러스터의 인덱싱과 도큐먼트 검색에 참여한다. 모든 노드가 같은 기능을 수행하는 것은 아니다. 노드에도 다양한 타입이 있으며, 이 타입에 따..

Opensearch의 인덱싱은 검색 효율을 높이기 위해 데이터를 구조화하는 방법이다. 이번에는 이 방법에 대해 자세히 알아보려고 한다. Inverted Index OpenSearch의 빠른 검색 성능은 역인덱스로부터 나온다. 역인덱스의 목적은 효율적이고 빠른 전문 검색이 가능하게 하는 것이다. 전문 검색은 특정 단어가 포함된 문서를 찾아내는 검색 방식을 말한다. 기존 RDBMS에서는 전문 검색을 하면 레코드 하나하나씩 테이블 전체를 풀스캔하기에 속도가 느리다. OpenSearch는 토큰화된 역인덱스 데이터에 대해 쿼리를 진행하기에 빠르다. 역인덱스는 필드 수준에서 작동하기에 각 Text 타입 필드마다 하나씩 가지고 있다. 위 그림은 도큐먼트를 추가할 때 character filter -> tokenize..

opensearch의 핵심이라고도 할 수 있는 인덱싱과 검색에 대해 알아보려고 한다. Text vs Keyword 이 둘의 차이는 분석과정의 유무이다. text는 추가나 업데이트가 될 때마다 분석 과정을 거친 후 반영된다. 하지만 keyword는 따로 분석 과정 없이 텍스트 그대로 반영된다. Text Analysis Opensearch의 텍스트가 거치는 텍스트 분석은 분석기에 의해 수행된다. 이 분석기는 3가지 요소로 구성된다. Character filter 입력 받은 text에서 미리 설정한 룰에 따라 문자를 추가, 제거, 변경한다. 예) html 파일 내의 태그 제거 Tokenizer 텍스트를 토큰으로 자른다. 이때 어떤 기준으로 자를지를 토크나이저 종류에 따라 선택할 수 있다. Standard 토크..

OpenSearch 구성 요소 opensearch는 RDBMS와 사용하는 용어가 다르다. 테이블 -> 인덱스 레코드 -> 도큐먼트 컬럼 -> 필드 스키마 -> 매핑 인덱스란 말이 어색할 수도 있는데, RDBMS에서 인덱스는 보통 빠른 검색을 위해 유니크한 값을 주는 것이었다면, 여기서는 테이블과 같은 데이터들이 모여있는 것을 말하며 인덱싱은 검색 엔진에서 빠른 검색을 위해 데이터를 구조화하는 방법을 말한다. 그래서 데이터가 들어오면 인덱싱을 한 후에 인덱스에 저장된다. 그리고 이 인덱싱 전에 매핑이 일어난다. 매핑 정의에 따라 입력받은 도큐먼트를 OpenSearch가 이해할 수 있는 데이터 구조로 변환하는 과정이다. 어떤 타입들이 있는지는 공식문서에서 확인 가능하다. https://opensearch.o..