코린이형준

데이터 레이크를 운영하면서 가장 고민되는 부분 중 하나가 테이블 포맷 선택인데요.

현재 가장 많이 사용되는 Iceberg, Hudi, Delta Lake에 대해 비교해보려 합니다.

근데 잠깐, 데이터 레이크는 왜 등장했을까요?

전통적인 데이터 웨어하우스는 정형 데이터를 저장하고 분석하는데 최적화되어 있었습니다. 하지만 빅데이터 시대가 도래하면서 비정형 데이터도 처리해야 하고, 더 유연하고 확장 가능한 저장소가 필요해졌죠.

그래서 등장한게 '데이터 레이크'입니다. 모든 종류의 데이터를 원본 형태로 저장할 수 있고, 비용도 저렴하죠. 하지만 데이터 레이크에도 문제가 있었습니다.

데이터 레이크의 한계

1. 데이터 스왐프화: 통제되지 않은 데이터가 쌓이다 보니 데이터 품질이 떨어지고 관리가 어려워졌습니다.
2. ACID 미지원: 동시성 제어나 트랜잭션 보장이 어려웠습니다.
3. 성능: 파일 기반 쿼리의 한계로 웨어하우스만큼 빠른 성능을 내기 어려웠습니다.
4. 데이터 거버넌스: 메타데이터 관리나 보안, 감사가 쉽지 않았습니다.

이런 문제를 해결하기 위해 등장한 것이 바로 '데이터 레이크하우스'입니다.

데이터 레이크하우스는 데이터 레이크의 유연성과 데이터 웨어하우스의 안정성, 성능을 모두 제공하려는 아키텍처죠.

그리고 이 데이터 레이크하우스를 구현하는 핵심 기술이 바로 테이블 포맷입니다.

테이블 포맷이 왜 필요한가요?

"그냥 파일만 있으면 되는거 아닌가요?" 라고 생각하실 수 있습니다.

하지만 데이터 레이크하우스에서 필요한:

• ACID 트랜잭션
• 시간 여행(Time Travel)
• 스키마 관리
• 효율적인 쿼리 성능 

이런 기능들을 제공하려면 테이블 포맷이 필수적입니다.

각 포맷별 특징을 살펴볼까요?

Apache Iceberg

장점

1. 성능: 파티션 진화와 숨겨진 파티셔닝을 통해 뛰어난 쿼리 성능을 제공합니다.
2. 스키마 진화: 스키마 변경이 자유롭고 하위 호환성이 보장됩니다.
3. 확장성: 대규모 테이블도 효율적으로 처리할 수 있습니다.
4. 넓은 생태계: Spark, Flink, Trino 등 다양한 엔진과 호환됩니다.
5. 클라우드 지원: 특히 AWS에서 EMR, Athena, Redshift 등 다양한 서비스와의 통합을 제공합니다.

Apache Hudi

장점

1. 실시간 처리: 스트리밍 데이터 처리에 최적화되어 있습니다.
2. 업서트 지원: 레코드 수준의 업데이트와 삭제가 가능합니다.
3. 증분 처리: 변경된 데이터만 효율적으로 처리할 수 있습니다.
4. 풍부한 사용 사례: 우버에서 시작되어 실제 프로덕션 환경에서 검증되었습니다.

단점

1. 복잡성: 설정이 복잡하고 최적화가 어려울 수 있습니다.
2. 리소스 사용: 인덱싱과 업서트로 인해 리소스 사용량이 높을 수 있습니다.

Delta Lake

장점

1. 안정성: Databricks의 지원으로 안정적인 운영이 가능합니다.
2. 사용 편의성: 직관적인 API와 풍부한 문서를 제공합니다.
3. 통합성: Databricks 환경에서 완벽하게 통합됩니다.
4. 최적화: Z-ordering을 통한 쿼리 최적화를 제공합니다.

단점

1. Databricks 종속성: 일부 고급 기능은 Databricks 환경에서만 사용 가능합니다.
2. 제한된 엔진 지원: Spark 외 다른 엔진과의 호환성이 상대적으로 부족합니다.

어떤 것을 선택해야 할까요?

상황에 따라 다르지만, 개인적으로 제가 추천하는 기준은 이렇습니다:

1. Databricks를 사용중이라면 -> Delta Lake
2. 클라우드 중립적이고 다양한 엔진을 사용한다면(특히나 aws 라면!) -> Iceberg

결론

데이터 레이크하우스라는 새로운 패러다임과 함께 테이블 포맷도 계속 발전하고 있습니다.

세 포맷 모두 각자의 장단점이 있지만, 최근 추세를 보면 Iceberg의 성장세가 가파릅니다. 특히 클라우드 중립성과 다양한 엔진 지원은 멀티 클라우드 환경에서 큰 장점으로 작용하고 있죠.

하지만 무조건 트렌드를 따라가기보다는, 자신의 사용 사례와 환경에 맞는 포맷을 선택하는 것이 중요합니다.

갑자기 회사에서 외계어가 나타나기 시작했습니다.

협력사: "csv로 전달드리면 될까요?"

사수님: "아무래도 데이터 양이 너무 많아서 파케이로 전달해주시는게 좋을 것 같아요. 코린이님, 저희 s3에서 csv로 저장되어 있는게 있나요? 이게 athena에서 바로 읽어 올 수 있었나요?"

코린이: "...? 확인을 좀,,,"

저 같은 분이 많을꺼라고 생각듭니다.

대부분 회사에서 업무를 처리할 때, 기존의 전체적인 구조는 어느정도 유지한 채 업무를 진행하게 될텐데 가끔 문제가 발생하는 부분이 세부적으로 데이터 저장형식과 같은 세부적인 부분들이라고 생각듭니다.

이참에 알아가보시죠!

무엇인가?

파일 형식중 하나입니다.

파일 형식은 크게 행기반 저장방식, 열(컬럼)기반 저장방식으로 나누어져 있습니다.

행기반 파일 형식의 경우, 데이터를 행 단위로 저장하는 방식입니다.

대부분의 사람들에게 익숙한 저장방식으로 대표적으로 CSV와 같은 텍스트 파일 형식이 행 기반 파일 형식의 대표적인 예시 입니다.

열기반 파일 형식의 경우, 데이터를 열 단위로 저장하는 방식입니다.

지금 알아 보는 Parquet가 가장 대표적인 열 단위 파일 형식의 예시입니다.

Parquet 파일은 여러개의 행 그룹(Row Group)으로 구성되어 있습니다. 각 행 그룹은 여러 행을 포함하며, 이러한 행 그룹은 열 단위로 압축되어 저장됩니다. 이러한 구조는 Parquet 파일이 열 기반 형식이기 때문에 가능합니다. 각 행 그룹은 아래와 같은 요소로 구성되어 있습니다.

1. Row Group Header: 각 행 그룹은 헤더를 가지고 있습니다. 헤더에는 행 그룹의 메타데이터가 포함되어 있습니다. 메타데이터에는 행 그룹에 포함된 행의 수, 각 열의 통계 정보 등이 있습니다.
2. Column Chunks: 열 기반으로 데이터가 저장되기 때문에, 각 열은 자체적으로 압축되어 저장됩니다. 이러한 압축된 열 데이터를 Chunk라고 합니다. 각 열은 하나 이상의 Chunk로 나뉘어질 수 있습니다.
3. Page Header: Chunk 안에는 Page가 포함되어 있습니다. Page는 실제 데이터를 포함하고 있습니다. Page Header에는 해당 Page의 메타데이터가 포함되어 있습니다. 이 메타데이터에는 Page의 유형 (Data Page, Dictionary Page 등)과 압축된 데이터의 크기 등이 있습니다.
4. Data Pages: 데이터가 실제로 저장되는 부분입니다. 데이터 페이지에는 실제 데이터 값이 압축되어 저장됩니다.

Parquet 파일은 이러한 구조를 반복하여 여러 개의 행 그룹을 포함할 수 있습니다. 각 행 그룹은 독립적으로 저장되므로, 쿼리 시 필요한 행 그룹만 읽어와 처리할 수 있습니다. 이는 Parquet 파일이 대용량 데이터셋을 효율적으로 처리하는 데 도움이 됩니다.

왜 사용 하는가?

수많은 소프트웨어 도구가 구분되어 있고 파일 형식또한 구분되어 있는데는 이유가 있습니다.

따라서, 분야또한 데이터 분석에 대한 니즈가 없는 일반적인 기업의 경우, 열 지향 파일 형식을 몰라도 당장의 문제가 없습니다.

다만, 수많은 데이터 속 분석을 통해 가치를 찾아 내기 위한 니즈가 있는 기업이라면 열 지향 파일 형식의 필요성에 대해 알아볼 필요가 있습니다.

Parquet의 장점은 다음과 같습니다:

1. 압축 효율성: Parquet은 열 지향 형식을 사용하므로 같은 값이 많은 열은 압축이 잘되어 더 작은 파일 크기를 갖게 됩니다. 이는 디스크 공간을 절약하고 데이터 전송 속도를 향상시킵니다.
2. 쿼리 성능: Parquet 파일은 파일 내의 메타데이터를 사용하여 쿼리를 빠르게 처리할 수 있습니다. 또한, 열 지향 형식이므로 필요한 열만 읽어들이므로 전체 데이터셋을 읽어야 하는 비용이 줄어듭니다.
3. 스키마 호환성: Parquet 파일은 스키마를 내장하고 있어, 스키마 변경이 필요한 경우에도 쉽게 처리할 수 있습니다.
4. 분할 및 병렬 처리: Parquet 파일은 여러 개의 블록으로 나뉘어져 있어, 여러 컴퓨터에서 동시에 처리할 수 있습니다. 이는 대규모 데이터셋을 효율적으로 처리하는 데 도움이 됩니다.

반면, Parquet의 단점은 다음과 같습니다:

1. 쓰기 속도: Parquet 파일은 압축과 메타데이터 작업으로 인해 쓰기 속도가 느릴 수 있습니다. 따라서 데이터를 빠르게 기록해야 하는 경우에는 다른 형식을 고려해야 할 수 있습니다.
2. 최적화된 쿼리를 위한 사전 계획 필요: Parquet 파일을 효율적으로 쿼리하려면 데이터를 저장할 때 쿼리 패턴을 고려하여 저장해야 합니다. 이를 위해 데이터의 구조와 쿼리 패턴을 미리 파악해야 하는데, 이는 추가적인 작업이 필요할 수 있습니다.

 

상황에 맞게 사용 해봅시다!

너무 뻔한 내용이였나요?

고려하기 너무 어렵다면 아래의 몇가지 상황에 따라서 파일 형식을 고려해 사용합시다!

 

열기반 (Parquet)

- 대용량 데이터 분석

- 데이터 웨어하우스 운영

- 머신러닝 모델 훈련

- 데이터 레이크 구축

- 클라우드 기반 분석

 

행기반 (Json, CSV)

- 스트리밍 데이터 처리

- 간단한 데이터 공유 및 협업

- 데이터의 추가가 빈번한 로그데이터

- 작은 파일 다수 처리

 

후기

parquet 파일 형식에 대해서 그냥 대용량 처리에서는 기존에 자주사용하던 저장방식보다는 자주 사용되는구나 정도까지만 알고 넘어갔습니다. 실무를 진행하며 이런 디테일 한점을 알고 모르냐에 따라 결국 문제를 해결하는 방식이 달라지고 이방식은 결국 자원의 선택과 비용절감에 크나큰 영향을 끼친다고 생각합니다.

학부생 때, 파일 처리에 대해 중요성을 강조하시던 교수님을 뒤로 하고 그저 술만 마시던 저를 탓하던 하루였습니다...

elasticsearch에 대해서 처음 접하게 됐을때 다들 기본적으로 검색을 할때 사용되는 도구다라고만 할수 있는데 준 실시간성으로 로그시스템을 구축할때 elasticsearch와 함께 logstash, kibana 그리고 요즘엔 filebeat까지 합쳐 elk 스택이라 불리며 자주사용되는 스택이 있습니다.

1. 기본 개념

각각의 구성 요소들이 담당하는 큰 역할에 대해 알아볼 필요가 있습니다.

- Elasticsearch

• 로그데이터를 저장하고 검색하는 역할을 담당
• 실시간 분석과 검색을 지원하며, 데이터베이스 쿼리와는 다르게 RESTFul API를 통해 데이터에 액세스 할 수 있음

- Logstash

• 로그 데이터 수집 및 필터링, 변환 ,파싱하는 역할을 담당
• 실질적으로 로그에 출력되길 원하는 내용만을 필터링하는 역할
• pipeline을 통해 여러개의 로그데이터 별로 설정을 진행할 수 있음

input, filter ouput으로 이루어져 있으며 input, output, filtering에 많은 플러그인들을 제공하고 있어 손쉽게 사용 가능합니다.

아래의 주소에서 사용가능한 plugin과 사용방법이 자세히 나와 있으니 참고 해주시기 바랍니다.

- Kibana

• ElasticSearch 데이터를 시각화하는 도구로, 로그데이터를 분석하고 대시보드화 하는 역할을 담당
• 뿐만 아니라 elasticsearch의 모든 설정을 손쉽게 관리 할 수 있도록 GUI 역할또한 담당
• Kibana는 다양한 시각화 도구를 제공하며, 기본적으로 로깅용 뿐만 아니라 시간대별, 지리적, 통계 등 다양한 방식으로 데이터를 시각화 할 수 있음.

kibana 또한 Elasticsearch 뿐만아니라 여러 plugin 형태로 제공된 저장소를 손쉽게 연결 및 관리 하여 시각화 할 수 있는 아주 강력한 도구입니다. 

- Filebeat

• 데이터 추출 및 전송을 담당
• 경량화된 로그 수집 도구 역할
• resource(CPU와 RAM)를 상당히 적게 소모함
• 간단한 filter기능도 제공하지만 이는 logstash로 대체해 사용

사실, Filebeat가 왜 필요한가? 라는점에 초점을 맞춰 봐야합니다.

기존에 logstash가 담당하는 로그 수집 역할만을 filebeat가 담당하고 있습니다. 왜 logstash에서 기능을 제거했을까? 이유는 바로 jvm 위에서 동작하는 logstash의 리소스 부담을 줄이기 위해서 입니다.

filebeat와 logstash의 베이스는 언어자체에서도 큰 차이가 있습니다. filebeat=Go, logstash=java 베이스 코드로 짜여져 있으며 filebeat의 컨셉은 경량화된 로그 수집기 입니다. 기본적으로 로그 수집 자체의 역할만을 담당하여 서버의 CPU와 RAM을 상당히 적게 소모하여 logstash나 아에 elasticsearch로 전송할 수 있습니다.

그렇다면 어떻게 서버 구성을 하는게 이점이 될수 있을까? 생각해봅시다.

2. 인프라 구성

Filebeat는 서버의 자원을 최소화하여 로그 수집할 수 있는 장점이 있습니다. 하지만, 아래와 같이 구성할경우, 어떨까요?

3대의 ec2 인스턴스가 각각 존재하고 하나의 서버안에 elk + filebeat 스택을 구성했다고 가정해 봅시다.

물론 elk 인스턴스의 물리적 리소스가 굉장히 큰 서버라면 문제없이 동작할것입니다. 하지만, filebeat가 나온 히스토리를 생각해봅시다.

기존의 logstash의 작업중 로그 수집의 리소스를 분리해 물리적인 리소스를 적게 소모하는 경량화된 로그수집기입니다. 과연 filebeat가 필요할까요? 라는 생각이 듭니다. 

만약 위와같은 구조로 구성한다면, filebeat를 제외한 logstash에게 로그 수집의 역할까지 담당하게 하는것이 좋은 패턴이 될것입니다.

그렇다면 어떻게 구성하는게 좋을까요?

위와 같은 패턴으로 ec2 인스턴스 각각에 filebeat를 설치하여 로그를 수집한뒤 logstash가 있는 5044포트로 로그를 전송하는 역할만 담당하게 구성하면됩니다. 서버의 자원에 따라 elasticsearch와 kibana를 분리하는것도 방법이 될수 있으나 filebeat를 어디에 배치하느냐가 elk와 filebeat의 공존의 이유를 가장 잘 설명한 방법이 될수 있습니다.

logstash를 여러대 띄어서 관리하는 방법도  있지 않을까?하는 생각도 들수 있지만 logstash의 경우, pipeline형태로 여러대의 logstash 자원을 관리할 수 있어 이기능을 적극적으로 활용하여 관리해주시기 바랍니다.

3. elk 설치 튜토리얼

mac을 기준으로 elk 스택 설치 방법에 대해 설명드리겠습니다.

일단 elasticsearch, kibana, logstash, filebeat를 brew 명령어를 통해 설치해주시기 바랍니다.

brew install filebeat-full
brew install logstash-full
brew install elasticsearch-full
brew install kibana-full

설치가 완료 되었다면, 기본적으로 filebeat의 output은 localhost:5044, logstash의 output은 localhost:9200, kibana의 input은 localhost:9200으로 구성되어 있습니다.

- filebeat

/usr/local/etc/filebeat 위치의 filebeat.yml 

filebeat.inputs:
 - type: log
  id: test-filestream

  enabled: true
  paths:
    - /usr/local/var/log/sample.log
    
  # exclude_lines: ['^DBG']
  # include_lines: ['^ERR', '^WARN']
  
  # multiline.pattern: ^[0-9]{4}-[0-9]{2}-[0-9]{2}[[:space:]]
  # multiline.negate: true
  # multiline.match: after
  
output.logstash:
  hosts: ["localhost:5044"]

filebeat의 설정은 위와같이 기본적으로 로그를 수집할 input과 output으로 나뉘어져있습니다.

input과 output에 본인이 원하는 플러그인 형태로모두 명시해서 사용하시면 되며 위의 자습서에서 확인 후 요구사항에 따라 변경해주시길 바랍니다.

위 설정의 경우, /usr/local/var/log/sample.log 이경로의 로그 파일을 input대상으로 확인하며 output으로 localhost:5044의 로그스태시로 보낸다는 간단한 설정입니다.

최근 트러블 슈팅간 syslog에서 error로그를 수집하기 위해 설정을 진행했는데 실질적으로 필요한 traceback로그는 수집이 안되고 500에러만 출력되는 문제가 생겨 이걸 하나의 라인으로 포함시켜 보내기 위해 multiline의 개념을 도입해 사용했습니다.

multiline은 기본적으로 정규표현식으로 패턴을 정의할 수 있으며, 특정 정규표현식의 패턴과 일치하지 않을경우 일치하지 않는 모든 로그를 한줄의 로그로 인식해 보낸다는 개념입니다. 여기엔 negate와, match로 설정을 진행해주셔야하며 설정 내용은 아래와 같습니다.

negate: 패턴이 무효화되는지 여부 정의, 기본값은 false

match: 일치하는 라인을 하나로 볼지 일치하지 않는 라인을 하나로 볼지 결정

syslog의 특성상 시스템의 모든로그가 출력되기 때문에 수집될 대상의 로그의 경우수가 너무나 많기 때문에 exclude_lines와 include_lines를 적절히 설정하여 수집되는 로그의 기준을 확실히 정하는것이 작업의 리소스를 줄일 수 있는 방식이 될것 입니다.

- logstash

여러 logstash 설정 방식이 존재하겠지만 pipeline형식으로 관리하는 방식으로 리뷰하겠습니다.

/usr/local/etc/logstash 위치에 conf.d라는 디렉터리를 생성 후 sample.cfg 파일을 생성해줍니다.

input {
  beats {
    port => 5044
  }
}

filter {
  if "target log" in [message] {
    grok {
      match => { "message" => "%{TIMESTAMP_ISO8601:log_datetime} %{LOGLEVEL:level} %{DATA:log_message}: %{GREEDYDATA:json_data} %{SPACE}\[PID:%{NUMBER:pid}:%{DATA:thread}\]" }
    }

    date {
         match => [ "log_datetime", "yyyy-MM-dd HH:mm:ss,SSS" ]
         timezone => "Asia/Seoul"
    }
  }

  else {
    drop { }
  }
}

output {
  elasticsearch {
    hosts => ["http://localhost:9200"]
    index => "test-%{+YYYY.MM.dd}"
  }
}

input

Logstash가 Beats 입력 플러그인을 통해 로그 데이터를 수신한다는 것을 정의합니다. 이 설정에서는 5044 포트를 통해 Beats로부터 들어오는 데이터를 수신하도록 설정되어 있습니다.

filter

데이터 필터링 및 구문 분석을 수행하는 부분입니다. message 필드에 "target log"가 포함되어 있는 경우에만 실행됩니다.

• grok 필터는 로그 메시지를 정규 표현식을 사용하여 구문 분석하여 필드로 추출합니다. 예를 들어, %{TIMESTAMP_ISO8601:log_datetime}은 ISO 8601 형식의 타임스탬프를 log_datetime 필드로 추출합니다.
• date 필터는 log_datetime 필드의 값을 지정된 패턴에 맞춰서 파싱하여 날짜 및 시간 필드를 생성합니다. 지정된 타임존인 "Asia/Seoul"로 변환됩니다.

만약 "target log"가 message 필드에 없는 경우에는 drop 필터를 사용하여 이벤트를 삭제하므로 처리되지 않습니다.

output

필터링 및 구문 분석이 완료된 데이터를 Elasticsearch에 색인하는 부분입니다. elasticsearch 출력 플러그인을 사용하여 데이터를 Elasticsearch 클러스터로 전송합니다. hosts에는 Elasticsearch 클러스터의 호스트 주소를 설정하며, index는 색인 이름을 설정합니다. 여기서는 "test-" 다음에 날짜를 추가하여 일별로 색인을 생성하도록 설정되어 있습니다.

기본설정을 정의했다면 /usr/local/etc/logstash/pipeline.yml 파일에 pipeline을 정의해줍니다.

- pipeline.id: beats-pipeline
   pipeline.workers: 1
   pipeline.batch.size: 1
   path.config: "/usr/local/etc/logstash/conf.d/sample.cfg"

logstash의 동작을 위한 관련한 모든 기본 설정은 마무리가 되었습니다.

elasticsearch와 kibana의 경우, 기본적으로 logstash의 5044를 인풋으로 그리고 9200포트를 기본 elasticsearch로 바라보고 있기 때문에 단순히 실행만 해주신다면 문제없이 기본적인 로깅 시스템 세팅이 마무리됩니다.

brew services start filebeat-full
brew services start logstash-full
brew services start elasticsearch-full
brew services start kibana-full

이번 챕터에서 다뤄본 내용은 elk+beat 스택의 동작을 위한 기본 설정만 다뤄봤기 때문에 실제로 어떤 데이터를 수집할것인지에 따라 beat와 logstash의 설정은 달라질수 있으며 실제로 데이터 수집이후 elasticsearch의 lifecycle이나 index pattern등 정의할것들에 대한 작업들은 많이 남아 있습니다. 기본적으로 비즈니스 요구사항을 먼저 파악한 후 이러한 설정들을 어떻게 설정할지는 공식문서를 통해 더욱 구체화 해주시길 바랍니다.

이후에 다뤄볼 내용은 indextemplate과 cluster 관리에 대해 더욱 자세히 알아보도록 하겠습니다.

감사합니다.

최근 시스템을 파악하며 느낀것이 Elasticsearch의 강력함을 느끼고 있습니다. 사내 시스템에서는 검색, 데이터 저장으로 사용 하고 있는데 왜 elasticsearch를 사용하는것일까? 이게 무엇인지 알아봐야할 필요성을 느끼게 되었습니다.

(1) elasticsearch란 무엇인가?

apache Lucene에 구축되어 배포된 검색 및 분석 엔진입니다. 데이터 저장소가 아니라 Mysql같은 데이터베이스를 대체할 수 는 없지만 방대한 양의 데이터를 신속하고 거의 실시간으로 저장, 검색, 분석 할 수 있습니다. 

(2) elasticsearchdml 기본 구성

elasticsearch는 기본적으로 클러스터와 노드에 대해 알아야합니다.

클러스터란, 여러대의 컴퓨터 혹은 구성 요소들을 논리적으로 결합하여 하나의 컴퓨터, 혹은 하나의 구성 요소처럼 사용할 수 있게 해주는 기술입니다. elasticsearch 클러스터 역시 여러개의 프로세스들을 논리적으로 결합하여 하나의 elasticsearch 프로세스처럼 사용할 수 있게 해줍니다. 이때, 클러스터를 구성하는 하나하나의 elasticsearch 프로세스를 노드라고 부릅니다. 즉, 여러개의 elasticsearch 노드들을 하나의 elasticsearch처럼 동작하게 하는 것이 elasticsearch 클러스터라고 할 수 있습니다.

그렇다면 왜 단일 노드로 클러스터를 구성하지 않을까요? 여러개의 노드로 클러스터를 구성하는 이유가 뭘까? 하는 궁금증이 있습니다.

특정 노드에 장애가 발생했을때, 이후의 요청을 처리할 수 없는 요청 불가 상태로 elasticsearch 서비스 전체에 영향을 끼치게 됩니다.

하지만 여러개의 노드로 클러스터를 구성할경우, 하나의 노드에 장애가 발생해도 다른 노드에 요청할 수 있기 때문에 안정적으로 클러스터를 유지할 수 있고 이를 통해서 높은 수준의 안정성을 보장하며 서비스를 운영할 수 있게 됩니다.

그렇다면 노드의 구조에 대해서도 간단히 알아봅시다.

노드의 경우, 클러스터를 구성하는 논리적인 elasticsearch프로세스 하나를 의미합니다. 노드도 클러스터와 마찬가지로 각각의 고유한 노드 이름과 UUID가 있고, 역할에 따라 여러가지 노드로 구분할 수 있습니다.

위와 같이 노드가 할수 있는 역할은 총 4가지 이며, 각각하나의 역할만 할 수 있는게 아니라 여러개의 역할을 할 수 있습니다. 

꼭 유념해야하는 개념은 클러스터 내에서 메타데이터를 관리하는 마스터 노드는 하나라는것입니다. 실질적인 마스터 노드와 마스터노드에서 문제가 발생했을때, 대체할 마스터 후보 노드가 있다고 생각하면 쉬운데, 마스터 후보 노드들은 마스터 노드로부터 지속적으로 클러스터 운영에 필요한 데이터를 전달받기 때문에 항상 같은 메타 데이터를 유지하고 있습니다. 그래서 마스터 노드에 장애가 발생해서 새로운 마스터 노드가 선출되어도 중단없이 서비스를 지속할 수 있습니다.

- 샤드와 세그먼트

샤드는 인덱스에 색인되는 문서들이 저장되는 논리적인 공간을 의미하며, 세그먼트는 샤드의 데이터들을 가지고 있는 물리적인 파일을 의미합니다. 인덱스와 샤드, 세그먼트의 관계는 아래와 같은 그림이 됩니다.

하나의 인덱스는 다수의 샤드로 구성되어 있고 하나의 샤드는 다수의 세그먼트로 구성됩니다. 샤드는 1개 이상의 세그먼트로 구성되는데 샤드마다 세그먼트의 개수는 서로 다를 수 있습니다.

위와 같은 elasticsearch의 기본적인 구성에 의해 서비스를 안정적이게 운영할 수 있게됩니다.

(3) Elasticsearch와 관계형 DB 비교

- 구조

- CRUD

(4) elasticsearch API를 통해 조회 간단히 실습해보기

- 검색

기본적으로 RDB에서는 User라는 테이블의 데이터를 검색할때는 아래와 같이 검색합니다.

SELECT *
FROM User;

elasticsearch의 API는 아래와 같이 검색합니다.

GET /User/_search HTTP/1.1
Host: <elsticsearch host>
Content-Type: application/json

- 조건 검색

user의 gender가 man이고 age가 10인 유저를 검색할때는 RDB에서 아래와 같이 검색합니다.

조건이 1개 일때
SELECT *
FROM User
WHERE gender='man';

조건이 2개 이상일때
SELECT
FROM User
WHERE gender='man'
and age = 10;

elasticsearch의 API는 아래와 같이 검색합니다.

GET /Users/_search HTTP/1.1
Host: <elasticsearch host>
Content-Type: application/json

조건이 1개 일때,
{"query": {
	"match": {
    	"gender": {
        	"query": "man"
          }
        }
      }
    }

조건이 2개 이상일때,
{"query": {
    "bool": {
      "must": [
        {
          "match": {
            "gender": "man"
          }
        },
        {
          "match": {
            "age": "10"
          }
        }
      ]
    }
  }}

- 범위 검색

User테이블에서 age가 10초과인 유저를 검색할때 RDB에서는 아래와 같습니다.

SELECT *
FROM User
WHERE age > 10;

elasticsearch의 API는 아래와 같습니다.

GET /Users/_search HTTP/1.1
Host: <elasticsearch host>
Content-Type: application/json

{"query": {
    "bool": {
      "must": {"match_all": {} },
      "filter": {
        "range": {
          "gender": {
            "age": {
              "gt": 10
            }
          }
        }
      }
    }
  }}

위와 같이 RESTAPI를통해 조회를 간단히 진행할 수 있습니다.

(5) 왜 빠른걸까?

1. 분산 아키텍처: Elasticsearch는 데이터를 여러 노드에 분산하여 저장하고 처리합니다. 이렇게 함으로써 데이터의 부하가 분산되므로 병렬 처리를 통해 빠른 검색 및 질의 성능을 제공할 수 있습니다.
2. 역색인(Indexing): Elasticsearch는 역색인(index)을 사용하여 문서 내용의 토큰화 및 색인화를 수행합니다. 이로 인해 효율적인 텍스트 검색과 특정 조건에 따른 필터링이 가능해집니다.
3. 분산 검색 및 질의 처리: Elasticsearch는 검색 요청을 여러 노드에 분산하여 처리합니다. 이는 검색 작업을 여러 개의 작은 작업으로 나누어 처리하므로 전체적으로 빠른 검색 응답 시간을 보장합니다.
4. 메모리 기반 캐싱: Elasticsearch는 자주 사용되는 데이터와 검색 결과를 메모리 캐시에 저장하여 다음 검색에서 더 빠른 응답 시간을 제공합니다. 이를 통해 반복적인 검색 작업의 성능을 향상시킬 수 있습니다.
5. 복제 및 샤딩(Sharding): Elasticsearch는 데이터를 여러 파티션으로 나누어 저장하는 샤딩 기술을 사용합니다. 이를 통해 데이터베이스의 확장성과 성능이 향상되며, 복제(replication)를 통해 데이터 손실을 방지하고 고가용성을 보장합니다.
6. 다양한 검색 기능: Elasticsearch는 다양한 검색 기능과 질의 기능을 제공합니다. 풀 텍스트 검색, 필터링, 집계, 자동 완성, 유사한 문서 검색 등 다양한 기능을 효율적으로 처리할 수 있습니다.
7. 분석 기능: Elasticsearch는 데이터를 실시간으로 분석하고 시각화할 수 있는 다양한 도구와 플러그인을 제공합니다. 이를 통해 데이터를 실시간으로 모니터링하고 인사이트를 얻을 수 있습니다.

요약하면, Elasticsearch의 빠른 성능은 분산 아키텍처, 역색인 기술, 분산 검색 및 질의 처리, 메모리 기반 캐싱, 복제 및 샤딩, 다양한 검색 및 분석 기능 등 다양한 기술적 요소와 최적화가 결합되어 있기 때문에 빠르고 쉽게 이용할 수 있게 됩니다.

간단하게 이번 챕터에서는 elasticsearch의 기본 사용방법과 요소에 대해 알아봤는데 다음챕터로는 elasticsearch와 함께 주되게 사용되는 elk스택 + filebeat에 대해 알아보도록 하겠습니다.

- 출처

데이터 엔지니어링이란 무엇이고 각 단계별 어떤기술이 사용되는지  그리고 데이터 엔지니어링에서 사용되는 용어에 대해 먼저 알아보려 합니다.

위의 이미지를 보다시피 데이터 엔지니어링의 목적은 여러 데이터 소스들에서 유의미한 데이터들을 수집, 가공 및 분석하여 데이터 소비자들에게 알맞게 전달하는 것이 목적입니다.

단계별로 아래의 과정을 거쳐 소비자들에게 전달됩니다.

1. 데이터 소스

데이터 엔지니어링의 첫 번째 단계는 데이터 소스를 식별하고 확보하는 것입니다. 데이터는 다양한 소스에서 나올 수 있습니다. 내부 시스템 로그, 외부 API, 데이터베이스, 외부 웹사이트 등이 데이터 소스의 예시입니다. 데이터를 수집할 때 어떤 유형의 데이터를 어떻게 수집할 것인지 결정하는 것이 중요합니다.

ex) 비/관계형 데이터베이스, excel, log, etc..

2. 로그 수집, 전처리

데이터를 소스로부터 수집하면 다음 단계는 데이터를 로그로 기록하고 필요한 형식으로 전처리하는 것입니다. 로그 수집은 데이터의 추적 가능성과 안정성을 보장하는 데 도움이 됩니다. 데이터 전처리는 데이터를 클린하게 만들어서 분석이나 저장 단계에서 문제가 발생하지 않도록 하는 과정입니다. 이 단계에서는 데이터 누락, 이상치, 중복 등을 처리하고 필요한 형식으로 변환합니다.

ex) airflow, spark, kafka, elk, aws kinesis etc..

3. 데이터 저장

전처리된 데이터는 영구적으로 저장되어야 합니다. 데이터베이스 시스템을 활용하여 구조화된 데이터를 저장하거나, 분산 스토리지 시스템을 사용하여 대용량 데이터를 저장할 수 있습니다. 데이터 저장소를 선택할 때는 데이터의 양과 형태, 접근 속도, 보안 요구 등을 고려해야 합니다. 일반적으로 데이터 엔지니어는 데이터 웨어하우스, NoSQL 데이터베이스, 분산 파일 시스템 등을 고려하게 됩니다.

ex) bigquery, s3, 비/관계형 데이터베이스, etc..

4. 데이터 시각화 (선택적)

데이터 시각화는 데이터를 이해하고 전달하기 위한 중요한 단계입니다. 데이터 시각화를 통해 데이터의 경향성, 패턴, 이상치 등을 빠르게 파악할 수 있습니다. 시각화 도구를 사용하여 그래프, 차트, 대시보드 등을 생성하여 데이터의 시각적 표현을 만들어냅니다. 데이터 시각화는 비즈니스 의사 결정이나 데이터 분석 결과를 공유할 때 매우 유용합니다. 실질적으로 이부분은 대부분 개발자분들 보다도 비개발직군분들이 다른 업무에서 의사결정에 활용하려는 목적으로 많이 사용됩니다.

ex) superset, tableau, kibana, slack, etc..

필자의 경우, 회사업무를 진행하며 경험해본 스택은 airflow, elk 스택, aws s3, kinesis, superset, bigquery, pandas 정도가 있습니다.

다음 챕터 부터는 elasticsearch 및 elk 스택, airflow, superset의 순으로 리뷰를 할예정이며 이후부터는 사용해보지 않은 apache spark, kafka에 대해 알아볼 예정입니다.

미리 각 기술이 사용되는 이유 및 요약을 하자면 아래와 같습니다.

1. airflow

위 사진이 airflow에 대해 가장 잘 설명된거라고 생각하는데 airflow는 쉽게 말해 데이터 엔지니어링 잡들을 통합적으로 관리해주는 스케줄링 도구라고 생각합니다. 기본적은 python기반의 코드로 작성되며 papermill이라는 라이브러리를 통해 jupyter파일을 주입할 수 있어 개인적으로 굉장히 큰 장점 중 하나라고 생각합니다.

2. elk스택 + filebeat

굉장히 유명한 오픈소스 검색엔진인 elasticsearch와더불어 함께 사용되는 logstash, kibana 그리고 최근들어 많이 함께 사용되는 filebeat를 통칭하는 것이 elk스택입니다. 거의 실시간으로 로그 및 데이터를 수집 및 시각화가 가능하여 많이 활용 됩니다. 각각의 역할에 대해 알아보면 아래와 같습니다.

- filebeat: 기존 로그 수집, 필터 및 전달까지 담당하던 logstash의 기능중 데이터 추출 및 전송의 역할을 담당하는 도구입니다. logstash도 충분한데 등장하게 된이유는 기본적으로 go로 작성된 filebeat의 경우 cpu와 ram과 같은 resource를 상당히 적게 소모하기 때문이며, 보통 경량화된 로그 수집 도구라고 알려져있습니다.

- logstash: 앞서 말한 바와 같이 로그 수집, 필터 및 전달을 담당하며 기본적으로 로그를 수집하는 input과 수집된 로그를 필터링하는 filter, 필터링된 데이터를 전달하는 output으로 구성되어 있으며 input과 output에 여러 플러그인을 제공하여 비교적 쉽게 사용 가능합니다.

- elasticsearch: 데이터 저장소 및 검색의 역할을 담당하며, 데이터베이스 쿼리와는 다르게 RESTFUL API를 통해 데이터에 액세스 할수 있습니다. 역색인을 통해 검색이 굉장히 빠릅니다.

- kibana: elasticsearch의 index 관리 및 데이터 시각화를 담당하고 있습니다.

3. superset

모든 과정을 거쳐 수집된 데이터들을 차트와 대시보드 단위로 쿼리해 소비자들에게 시각화하여 제공해주는 역할을 합니다. 개발자들도 볼수 있겠지만 대부분 비개발직군 분들이 유의미한 데이터를 통해 추후 업무에 활용할때 많이 사용됩니다.

4. kafka

Kafka는 대규모 실시간 데이터 스트리밍 아키텍처를 구성하는 데 사용되며, 웹 사이트의 로그 처리, 실시간 분석, 이벤트 소싱 등에 활용됩니다. ELK 스택과 함께 사용하여 로그 데이터를 Kafka로 수집하고, 이후 Logstash를 사용하여 데이터를 전처리하여 Elasticsearch로 전송하는 등 다양한 데이터 파이프라인을 구축할 수 있습니다.

5. spark

대규모 데이터 처리와 분석을 위한 오픈 소스 클러스터 컴퓨팅 프레임워크입니다. Hadoop의 MapReduce 모델을 보완하고, 빠르고 효율적인 데이터 처리를 제공하는 것이 주요 목표입니다.

chatGPT에게 데이터 엔지니어링에서 사용되는 토픽에 대해 리스트를 뽑아봤는데 아래와 같습니다.

1. ETL (Extract, Transform, Load):
   • Extract: 다양한 데이터 원본에서 데이터를 추출합니다.
   • Transform: 추출한 데이터를 필요한 형식으로 변환하고 정제합니다.
   • Load: 변환한 데이터를 타겟 데이터베이스나 데이터 웨어하우스에 로드합니다.
2. Data Pipeline (데이터 파이프라인): 데이터의 이동과 변환 과정을 일련의 단계로 정의한 시스템 또는 프로세스입니다.
3. Batch Processing (배치 처리): 대량의 데이터를 일괄적으로 처리하는 방식을 말합니다.
4. Real-time Processing (실시간 처리): 데이터를 실시간으로 처리하고 분석하는 방식을 말합니다.
5. Data Warehouse (데이터 웨어하우스): 다양한 데이터 원본에서 추출한 데이터를 통합하고 저장하는 중앙 저장소입니다.
6. Data Lake (데이터 레이크): 다양한 유형과 형식의 데이터를 대규모로 저장하고 분석하기 위한 저장소입니다.
7. Data Ingestion (데이터 인제스처): 외부 데이터 원본에서 데이터를 추출하고 처리 파이프라인으로 전송하는 과정을 말합니다.
8. Data Transformation (데이터 변환): 데이터를 필요한 형식으로 변환하고 정제하는 작업을 말합니다.
9. Data Modeling (데이터 모델링): 데이터의 구조와 관계를 정의하여 데이터를 효과적으로 저장하고 쿼리할 수 있도록 설계하는 작업을 말합니다.
10. Schema (스키마): 데이터의 구조와 형식을 정의하는 설계도입니다.
11. Data Governance (데이터 거버넌스): 데이터의 품질, 보안, 규정 준수 등을 관리하는 프로세스와 정책을 의미합니다.
12. Data Quality (데이터 품질): 데이터의 정확성, 일관성, 완전성 등을 나타내는 개념입니다.
13. Data Integration (데이터 통합): 여러 데이터 소스에서 데이터를 추출하고 통합하는 작업을 의미합니다.
14. Data Partitioning (데이터 파티셔닝): 대량의 데이터를 논리적 또는 물리적으로 분할하여 관리하는 방식을 말합니다.
15. Data Replication (데이터 복제): 데이터를 여러 위치에 복사하여 고가용성과 장애 복구를 보장하는 작업을 의미합니다.
16. Data Catalog (데이터 카탈로그): 조직 내의 데이터 자산을 관리하고 검색할 수 있는 메타데이터 저장소를 말합니다.

회사에서 데이터 엔지니어링 업무를 주로 맡으며, 깊게 각각의 기술에 대해 알아볼 기회가 없었는데 이번기회를 통해 자세히 알아볼 예정입니다. 

위에서 잠시 요약했던 기술에서 kafka는 aws kinesis firehose, spark는 pandas와 비교되지 않을까?하는 생각이 듭니다. 사실, 회사에서 kinesis firehose, pandas만으로도 업무 진행에 문제가 없어 필요성에 대해서는 확실히 파악하진 못했는데 추후 실습을 통해 리뷰하도록 하겠습니다.

감사합니다 :)