Apache Kafka

• 이벤트 브로커
• pub/sub모델을 구현한 분산 메시징 플랫폼
• 어플리케이션간 이벤트(메시지 교환하기 위해 사용)
• 소스 어플리케이션과 타겟 어플리케이션의 결합도 낮추기 위함
• 메시지 그룹과 비교됨
• 이벤트를 브로커와 파일시스템으로 저장(데이터 레이크 역할 가능)

대규모 시스템에서 사용한다 보면 된다.

실시간 로그분석을 위해 kafka를 쓰기도 한다.

로그 파이프라인 #1

• 시스템 로그는 파일시스템, 사용자데이터는 데이터베이스로 관리
• 하나의 데이터베이스에서 사용자 트래픽과 분석 트래픽 처리
• 분석 트래픽이 사용자에게 영향을 끼침.

로그 파이프라인 #2

• 사용자를 위한 데이터베이스와 분석용 데이터 베이스를 분리.
• 분석용 데이터베이스가 실시간 업데이트 되지 않음.

로그 파이프라인 #3

• 서드파티 플랫폼을 통한 데이터 추가
• 분석용 데이터 베이스의 데이터가 실시간으로 업데이트 되지 않음
• 데이터 분석을 위한 전처리 과정 불가능(서드파티와의 통합)

ETL(Extract-Transform-Load)

주문이 완료된 아이템, 주문이 취소된 아이템

전처리시 고려사항.

• 이 과정을 위해선 데이터레이크 , 데이터 웨어하우스가 필요

• 데이터 레이크 - 실시간으로 ETL과정 이뤄져야
• 데이터 웨어하우스 - 실시간 업데이트해야됨.

ETL+ 데이터 웨어하우스

• 데이터 레이크(kafa)이 데이터를 목적에 맞게 ETL과정 거쳐 웨어하우스에 적재해야함.
• 실시간 로그 분석도 위해 데이터 웨어하우스 써야함.

데이터 웨어하우스

• 페타바이스 오가는 스토리지 및 SQL 쿼리
• 데이터 전처리 및 학습. 예측 하는 머신러닝 기능
• 완전 관리형 서버리스

ETL 방법

1 . kafak connect

2 . kafka streams

• 데이터를 스트림으로 처리하기 위한 라이브러리(java)

3 . 서드파티툴(ex.구글 데이터플로우 등)

• 비용적인 부분이 든다

4 . 로그 데이터 로그

카프카로 모든 데이터 모아두고 스트림 과정 가치고 big쿼리 던지면 정제된 데이터 남고 데이터 분석

• 정제된 데이터를 bigquery가 아닌 다른 데이터베이스에서 활용하려면 엄청 무거워진다.

정제된 데이터 처리1

• 다중 스트림 서버 -목적에 맞게 스트림 처리

정제된 데이터 처리2

• Sink Connector

• 에러 처리
• user create reply 같은거로 던져서 확인하는 그런거도 있었는데 reply토픽, 에러토픽 이런식으로 씀.

kafka로 메시지 전송하거나 하기 위해 ETL과정 거친다.

blockchain

해시함스룰 이용해 비트코인은 그 해시함수로 이뤄진 인코딩 된 값들을 맞춰가는 과정.

PKI

PKI(Public Key Infrastructure) 또는 공개키 기반구조는 디지털 증명서의 생성, 관리, 배포, 사용, 저장 및 파기, 공개키 암호화의 관리에 필요한 역할, 정책 등 일련의 절차들을 집합한 것이다

bip 39 online

블록체인은 코인만 쓰나? 다른 건?

• 비트코인 논문 한글

erc-20은 그나마 블록체인 중 비트코인 이외로 쓰고있는 블록체인

비트코인도 버전 1을 아직 달아본 적이 없다. 어디까지나 개발하는 관점

블록체인은 크게 보면 단순하게 돌아가는 프로토콜 약속 체제