Don't Panic
in Etc ☕ 2분 읽기

kafka,blockchian confer — Kafka 데이터 파이프라인과 블록체인 기초 컨퍼런스 노트

목차

Apache Kafka

  • 이벤트 브로커 — pub/sub 모델을 구현한 분산 메시징 플랫폼
  • 애플리케이션 간 이벤트(메시지) 교환에 사용
  • 소스 애플리케이션과 타겟 애플리케이션의 결합도를 낮추는 것이 목적
  • 메시지 큐(Message Queue)와 비교됨
  • 이벤트를 브로커와 파일시스템에 저장 → 데이터 레이크 역할 가능

대규모 시스템에서 주로 사용하며, 실시간 로그 분석에도 활용된다.

로그 파이프라인 진화

단계구조문제점
#1시스템 로그는 파일시스템, 사용자 데이터는 단일 DB로 관리분석 트래픽이 사용자 서비스에 영향
#2사용자용 DB와 분석용 DB를 분리분석용 DB가 실시간으로 업데이트되지 않음
#3서드파티 플랫폼을 통해 데이터 추가실시간 업데이트 불가, 전처리 과정 적용 어려움

ETL(Extract-Transform-Load)

주문 완료 아이템, 주문 취소 아이템 등 이벤트성 데이터를 추출·변환·적재하는 과정.

전처리 시 고려사항

ETL 전처리를 위해서는 데이터 레이크와 데이터 웨어하우스가 모두 필요하다.

  • 데이터 레이크 — 실시간으로 ETL 과정이 이뤄져야 함
  • 데이터 웨어하우스 — 실시간 업데이트 필요

ETL + 데이터 웨어하우스

  • 데이터 레이크(Kafka)에서 데이터를 목적에 맞게 ETL 과정을 거쳐 웨어하우스에 적재
  • 실시간 로그 분석을 위해 데이터 웨어하우스를 함께 사용

데이터 웨어하우스 특징

  • 페타바이트 단위 스토리지 및 SQL 쿼리 지원
  • 데이터 전처리, 학습, 예측 등 머신러닝 기능
  • 완전 관리형 서버리스 구조

ETL 방법

  1. Kafka Connect — 커넥터 기반 데이터 통합
  2. Kafka Streams — 스트림 처리를 위한 Java 라이브러리
  3. 서드파티 툴 (예: Google Dataflow) — 편리하나 비용 발생
  4. 로그 데이터 처리 흐름
    • Kafka로 모든 데이터를 모은 뒤, 스트림 처리 후 BigQuery에 던지면 정제된 데이터 확보 → 데이터 분석
    • 단, 정제된 데이터를 BigQuery 외 다른 DB에서 활용하면 처리 부담이 매우 커진다.

정제된 데이터 처리

처리1 — 다중 스트림 서버

  • 목적에 맞게 스트림을 분리해 병렬 처리

처리2 — Sink Connector

  • 에러 처리 포함
  • user_create_reply 같은 형태로 던져서 확인하는 패턴도 있음 — reply 토픽, 에러 토픽으로 분리해서 사용

Kafka로 메시지를 전송하려면 ETL 과정을 거친다.

Blockchain

비트코인은 해시 함수로 이뤄진 인코딩된 값들을 맞춰가는 과정으로 동작한다.

PKI(Public Key Infrastructure, 공개키 기반구조)

디지털 증명서의 생성, 관리, 배포, 사용, 저장 및 파기, 공개키 암호화 관리에 필요한 역할·정책 등 일련의 절차들을 집합한 것.

BIP-39

니모닉(Mnemonic) 기반의 시드 구문 표준 — bip39 online 도구로 확인 가능.

블록체인은 코인 외에 다른 용도로도 쓰이나?

  • 비트코인 외에 실질적으로 활용되고 있는 블록체인으로는 ERC-20(이더리움 기반 토큰 표준)이 대표적
  • 비트코인은 아직 버전 1조차 달아본 적이 없다 — 어디까지나 개발자 관점의 이야기
  • 블록체인을 크게 보면 단순하게 돌아가는 프로토콜 약속 체제라고 볼 수 있다

관련 글