Miner

실시간 데이터 처리 단계 이벤트 데이터 모델/스키마 결정 이벤트 데이터 전송/저장 - Kafka 이벤트 데이터 처리 이벤트 데이터 관리 이슈 모니터링과 해결 이벤트 데이터 모델 결정 최소 Primary Key와 Timestamp가 필요! 사용자 정보가 필요할 수도 있음 이벤트 자체에 대한 세부 정보 필요 이벤트 데이터 모델 전송/저장 (다시** 더 정리할 것) Point to Point (다시** 더 정리할 것) Many to Many 연결이 필요 Messaging Queue 중간에 데이터 저장소를 두고 생산자와 소비자가 decouple된 상태로 작업 - 독립 이벤트 데이터 처리 앞서 데이터 저장 모델과 활용 사례에 데이터 처리 모델도 결정됨 Point-to-Point 형태의 경우 Consumer쪽의 부..

Events are everywhere - Online Service 온갖 종류의 Funnel Data Product Impressions, Clicks (Click Stream), Purchase, ... User Registration (회원등록 버튼 클릭 -> 상세정보 입력 -> ... -> 등록 버튼) Page Views and Performance Data 페이지별로 렌더링 시간을 기록하면 나중에 문제 발생시 원인 파악이 쉬워짐 이를 디바이스 타입에 따라 기록(데스크탑, 모바일, ...) 또한 페이지별로 에러발생시 에러 이벤트 등록 사용자 등록, 사용자 로그인, 방문자 발생 이런 사용자 행동 데이터들의 데이터 모델 정의와 수집이 중요해짐 데이터가 제대로 수집된 후에 저장과 소비도 가능 그러다보니..

장점 즉각적인 인사이트 발견 운영 효율성 향상 사고와 같은 이벤트에 대한 신속 대응 더 효율적인 개인화된 사용자 경험 IOT 및 센서 데이터 활용 사기 탐지 및 보안 실시간 협업 및 커뮤니케이션 단점 전체적으로 시스템이 복잡해짐 배치 시스템은 주기적으로 동작하며 보통은 실제 사용자에게 바로 노출되는 일을 하지 않음 실시간 처리의 경우에는 실제 사용자와 관련된 일에 사용될 확률이 더 높기에 시스템 장애 대응이 중요해짐 배치 추천 vs 실시간 추천 Devops의 영역으로 들어가기 시작함 이에 따른 운영 비용 증가 배치처리는 잘못 되어도 데이터 유실 이슈가 적지만 실시간 처리는 데이터 유실의 가능성이 커지기에 항상 데이터 백업에 신경을 써야함 실시간 처리 : Realtime vs Semi-Realtime Re..

람다 아키텍처(Lambda Architecture) 배치 레이어와 실시간 레이어 두 개를 별도로 운영 여기에도 다양한 아키텍처가 존재.

처리 시스템 구조 Producer(Publisher)가 있어서 데이터 생성 생성된 데이터를 메세지 큐와 같은 시스템에 저장 Kafka, Kinesis, Pub/Sub 등의 시스템 존재 데이터 스트림(Kafka에서는 토픽이라 부름) 마다 별도의 데이터 보유 기한 설정 Consumer(Subscriber)가 있어서 큐로부터 데이터를 읽어서 처리 Consumer마다 별도 포인터 유지, 다수의 Consumer가 데이터 읽기를 공동 수행하기도 함 해당 기술을 이용해서, 구글 검색 엔진의 데이터 처리 - 계속적인 검색 인덱스 업데이트 구글이 기술적인 부분을 공개하지 않았지만 가능하다는 것을 보여줌,,

데이터 배치 처리 배치 처리 - 주기적으로 데이터를 한 곳에서 다른 곳으로 이동하거나 처리 주기 = daily, hourly, 5분에 한번, 10분에 한번 (1분단위는 못함) 처리량(Thriughput)이 중요 데이터를 모아서 처리 처리 시스템 구조 분산 파일 시스템(HDFS, S3) 분산 처리 시스템(MapReduce, Hive/Presto, Spark DataFrame, Spark SQL) 처리 작업 스케줄링에 보통 Airflow 사용 데이터 실시간 처리 연속적인 데이터 처리 realtime vs semi-realtime (micro batch) realtime : 특정한 이벤트가 발생했을 때 (~카드를 사용했을 떄) Semi-realtime : 분단위 보다 적은 간격으로 그 사이에 모아진 데이터를 ..