일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | ||||||
2 | 3 | 4 | 5 | 6 | 7 | 8 |
9 | 10 | 11 | 12 | 13 | 14 | 15 |
16 | 17 | 18 | 19 | 20 | 21 | 22 |
23 | 24 | 25 | 26 | 27 | 28 |
- 네이버
- Ubuntu 20.04
- 백준 #baekjoon # 2563
- id # tr # 환경변수
- 부스트캠프
- 웹/모바일
- 운영체제론
- 보기 편하라고 만든
- 후기
- 8기
- 네이버 부스트 코스
- Virtual Box 7.0.6
- Today
- Total
목록데이터 엔지니어링/실시간 처리 (8)
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 : 분단위 보다 적은 간격으로 그 사이에 모아진 데이터를 ..
일반적인 데이터 처리의 단계 데이터 수집 (Data Collection) 데이터 저장 (Data Storage) 데이터 처리 (Data Processing) Decision Science 의사 결정을 데이터 기반으로 과학적으로 하는 것 Product Science 우리가 만드는 서비스의 품질을 데이터를 기반으로 개선하는 것 처음에는 배치로 시작 ( 이 경우 처리할 수 있는 데이터의 양이 중요 ) 서비스가 고도화되면 실시간 처리 요구가 생기기 시작함 ( Realtime 처리 vs Semi Realtime 처리 ) 동일 데이터 소비가 필요한 케이스 증가 : 다수의 데이터 소비자 등장 처리량(Throughput) vs 지연시간(Latency) 처리량 : 주어진 단위 시간 동안 처리할 수 있는 데이터의 양 클수..
Kafka / Spark Streaming 구글이 데이터 분야에 끼친 영향 구글이 데이터 분야에 미친 영향은 하둡 등을 통한 배치 프로세싱부터 시작해서 텐서플로우, K8s 등 이루 말 할 수 없다. 1. 구글 검색 엔진의 등장 기존의 검색 엔진은 기본적으로 웹 페이지 상의 텍스트를 보고 랭킹을 결정 -> 신뢰가 높은 결과가 나오지 않게 됨 구글은 웹 페이지들간의 링크를 기반으로 중요한 페이지를 찾아서 검색 순위 결정 (페이지 랭크 논문) 2004년 여름에 상장, 2021년 2월 기준 1.41T로 급성장 / 검색 마케팅 플랫폼으로 확장, 안드로이드 개발로 모바일 생태계 지배, 유튜브 인수를 통한 스트리밍 시장 석권 다양한 논문 발표와 오픈소스 활동으로 개발자 커뮤니티에 큰 영향을 미침 페이지 랭크 더 중요..