NDC18에서 발표하였습니다. 현재 보고 계신 슬라이드는 2부 입니다.(총 2부)
- 1부 링크: https://goo.gl/3v4DAa
- 2부 링크: https://goo.gl/wpoZpY
(SlideShare에 슬라이드 300장 제한으로 2부로 나누어 올렸습니다. 불편하시더라도 양해 부탁드립니다.)
12. • 클러스터 컴퓨팅 엔진
•
• Python, Scala, R, Java 언어지원
• 다양한 모듈 지원 (SparkSQL, MLlib 등)
Apache Spark
Spark
인 메모리 데이터 처리
Apache Spark는 클러스터 컴퓨팅 엔진인데요.
13. • 클러스터 컴퓨팅 엔진
•
• Python, Scala, R, Java 언어지원
• 다양한 모듈 지원 (SparkSQL, MLlib 등)
Apache Spark
Spark
인 메모리 데이터 처리 → 빠르다!
이전에 Hadoop에서 디스크 기반으로 수행하던
MapReduce 작업을
14. • 클러스터 컴퓨팅 엔진
•
• Python, Scala, R, Java 언어지원
• 다양한 모듈 지원 (SparkSQL, MLlib 등)
Apache Spark
Spark
인 메모리 데이터 처리 → 빠르다!
Spark에서는 메모리에서 처리하기 때문에
15. • 클러스터 컴퓨팅 엔진
•
• Python, Scala, R, Java 언어지원
• 다양한 모듈 지원 (SparkSQL, MLlib 등)
Apache Spark
Spark
인 메모리 데이터 처리 → 빠르다!
빠른 속도라는 장점을 가지고 있습니다.
16. • 클러스터 컴퓨팅 엔진
•
• Python, Scala, R, Java 언어지원
• 다양한 모듈 지원 (SparkSQL, MLlib 등)
Apache Spark
Spark
인 메모리 데이터 처리 → 빠르다!
다양한 언어를 지원하기도 하고
17. • 클러스터 컴퓨팅 엔진
•
• Python, Scala, R, Java 언어지원
• 다양한 모듈 지원 (SparkSQL, MLlib 등)
Apache Spark
Spark
인 메모리 데이터 처리 → 빠르다!
데이터에 대하여 SQL을 사용할 수 있는
SparkSQL 모듈과
18. • 클러스터 컴퓨팅 엔진
•
• Python, Scala, R, Java 언어지원
• 다양한 모듈 지원 (SparkSQL, MLlib 등)
Apache Spark
Spark
인 메모리 데이터 처리 → 빠르다!
머신러닝 라이브러리, 스트리밍 모듈 등
여러가지 모듈을 지원하는데
19. • 클러스터 컴퓨팅 엔진
•
• Python, Scala, R, Java 언어지원
• 다양한 모듈 지원 (SparkSQL, MLlib 등)
Apache Spark
Spark
인 메모리 데이터 처리 → 빠르다!
클러스터 컴퓨팅 엔진이라고 소개해 드리긴 했지만
20. • 클러스터 컴퓨팅 엔진
•
• Python, Scala, R, Java 언어지원
• 다양한 모듈 지원 (SparkSQL, MLlib 등)
Apache Spark
Spark
인 메모리 데이터 처리 → 빠르다!
범용 분산 플랫폼이 맞는 표현입니다.
76. • 도쿄 리전 기준
• 초당 1000개 로그 유입, 각 로그는 2KB(월 5TB 정도)
• Kinesis 샤드 2개 + 데이터 PUT 비용
• Lambda (처리시간 1초)
→ 약 $90
→ 약 $20
3. Kinesis + Lambda 월 유지비용
→ 월 $110 정도로 유지 비용(저장비용 제외)
77. • 도쿄 리전 기준
• 초당 1000개 로그 유입, 각 로그는 2KB(월 5TB 정도)
• Kinesis 샤드 2개 + 데이터 PUT 비용
• Lambda (처리시간 1초)
→ 약 $90
→ 약 $20
3. Kinesis + Lambda 월 유지비용
→ 월 $110 정도로 유지 비용(저장비용 제외)
여기서 잠시 로그 수집 파이프라인의 비용을 살펴보면
78. • 도쿄 리전 기준
• 초당 1000개 로그 유입, 각 로그는 2KB(월 5TB 정도)
• Kinesis 샤드 2개 + 데이터 PUT 비용
• Lambda (처리시간 1초)
→ 약 $90
→ 약 $20
3. Kinesis + Lambda 월 유지비용
→ 월 $110 정도로 유지 비용(저장비용 제외)
만약에 초당 1000개의 로그가 지속적으로 유입되고
79. • 도쿄 리전 기준
• 초당 1000개 로그 유입, 각 로그는 2KB(월 5TB 정도)
• Kinesis 샤드 2개 + 데이터 PUT 비용
• Lambda (처리시간 1초)
→ 약 $90
→ 약 $20
3. Kinesis + Lambda 월 유지비용
→ 월 $110 정도로 유지 비용(저장비용 제외)
초당 2MB정도 유입된다고 가정하면
80. • 도쿄 리전 기준
• 초당 1000개 로그 유입, 각 로그는 2KB(월 5TB 정도)
• Kinesis 샤드 2개 + 데이터 PUT 비용
• Lambda (처리시간 1초)
→ 약 $90
→ 약 $20
3. Kinesis + Lambda 월 유지비용
→ 월 $110 정도로 유지 비용(저장비용 제외)
월 5TB정도의 로그가 발생하는데요.
81. • 도쿄 리전 기준
• 초당 1000개 로그 유입, 각 로그는 2KB(월 5TB 정도)
• Kinesis 샤드 2개 + 데이터 PUT 비용
• Lambda (처리시간 1초)
→ 약 $90
→ 약 $20
3. Kinesis + Lambda 월 유지비용
→ 월 $110 정도로 유지 비용(저장비용 제외)
이 때 최소로 필요한 Kinesis 샤드 2개와
82. • 도쿄 리전 기준
• 초당 1000개 로그 유입, 각 로그는 2KB(월 5TB 정도)
• Kinesis 샤드 2개 + 데이터 PUT 비용
• Lambda (처리시간 1초)
→ 약 $90
→ 약 $20
3. Kinesis + Lambda 월 유지비용
→ 월 $110 정도로 유지 비용(저장비용 제외)데이터를 기록하는 비용, Lambda에서 처리하는 비용을
모두 합쳐도
83. • 도쿄 리전 기준
• 초당 1000개 로그 유입, 각 로그는 2KB(월 5TB 정도)
• Kinesis 샤드 2개 + 데이터 PUT 비용
• Lambda (처리시간 1초)
→ 약 $90
→ 약 $20
3. Kinesis + Lambda 월 유지비용
→ 월 $110 정도로 유지 비용(저장비용 제외)
월 110달러 정도의 유지 비용이 발생합니다.
84. • 도쿄 리전 기준
• 초당 1000개 로그 유입, 각 로그는 2KB(월 5TB 정도)
• Kinesis 샤드 2개 + 데이터 PUT 비용
• Lambda (처리시간 1초)
→ 약 $90
→ 약 $20
3. Kinesis + Lambda 월 유지비용
→ 월 $110 정도로 유지 비용(저장비용 제외)물론 이건 저장비용을 제외하고,
최소로 맞춘 스펙이니 참고만 부탁드립니다.
87. 5. 대규모 분석 비용
• 모든 로그에 대하여
• r4.8xlarge X 10 스팟 인스턴스, 도쿄 리전 기준
• 생성된 모든 섬의 개수
• 가장 많이 채집된 자원(10위까지)
• 모든 섬의 날짜별 일일 활성 유저수
→ 5분 = $1 미만
→ 10분 = 약$1
→ 15분 = 약 $ 1.3
프로비저닝 시간 제외, 2018년 4월 24일 기준
만약 대규모 분석을 위해서
88. 5. 대규모 분석 비용
• 모든 로그에 대하여
• r4.8xlarge X 10 스팟 인스턴스, 도쿄 리전 기준
• 생성된 모든 섬의 개수
• 가장 많이 채집된 자원(10위까지)
• 모든 섬의 날짜별 일일 활성 유저수
→ 5분 = $1 미만
→ 10분 = 약$1
→ 15분 = 약 $ 1.3
프로비저닝 시간 제외, 2018년 4월 24일 기준
도쿄 리전을 기준으로 r4.8xlarge 타입의 인스턴스를
스팟 인스턴스로 10개를 띄우고
89. 5. 대규모 분석 비용
• 모든 로그에 대하여
• r4.8xlarge X 10 스팟 인스턴스, 도쿄 리전 기준
• 생성된 모든 섬의 개수
• 가장 많이 채집된 자원(10위까지)
• 모든 섬의 날짜별 일일 활성 유저수
→ 5분 = $1 미만
→ 10분 = 약$1
→ 15분 = 약 $ 1.3
프로비저닝 시간 제외, 2018년 4월 24일 기준
분석이 끝나는 즉시 종료한다면
90. 5. 대규모 분석 비용
• 모든 로그에 대하여
• r4.8xlarge X 10 스팟 인스턴스, 도쿄 리전 기준
• 생성된 모든 섬의 개수
• 가장 많이 채집된 자원(10위까지)
• 모든 섬의 날짜별 일일 활성 유저수
→ 5분 = $1 미만
→ 10분 = 약$1
→ 15분 = 약 $ 1.3
프로비저닝 시간 제외, 2018년 4월 24일 기준
보시는 바와 같이 시간과 비용을 최대한 절감할 수 있습니다.
133. Kinesis – Lambda 처리속도를 높이는 방법
1. Kinesis stream의 샤드 개수를 증가시킨다.
2. Lambda의 가용 메모리를 증가시킨다.
(Lambda는 가용 메모리 크기에 따라 CPU 성능이 조절됨)
여기서 Lambda의 처리속도를 높이는 방법을 정리해보면
134. Kinesis – Lambda 처리속도를 높이는 방법
1. Kinesis stream의 샤드 개수를 증가시킨다.
2. Lambda의 가용 메모리를 증가시킨다.
(Lambda는 가용 메모리 크기에 따라 CPU 성능이 조절됨)
Kinesis의 샤드 개수를 증가시켜서
Lambda의 동시 실행 수를 늘리는 방법이 있고
135. Kinesis – Lambda 처리속도를 높이는 방법
1. Kinesis stream의 샤드 개수를 증가시킨다.
2. Lambda의 가용 메모리를 증가시킨다.
(Lambda는 가용 메모리 크기에 따라 CPU 성능이 조절됨)
Lambda는 설정된 메모리 크기에 따라
136. Kinesis – Lambda 처리속도를 높이는 방법
1. Kinesis stream의 샤드 개수를 증가시킨다.
2. Lambda의 가용 메모리를 증가시킨다.
(Lambda는 가용 메모리 크기에 따라 CPU 성능이 조절됨)
CPU 성능이 조절되기 때문에
137. Kinesis – Lambda 처리속도를 높이는 방법
1. Kinesis stream의 샤드 개수를 증가시킨다.
2. Lambda의 가용 메모리를 증가시킨다.
(Lambda는 가용 메모리 크기에 따라 CPU 성능이 조절됨)
Lambda의 가용 메모리를 증가시켜서
CPU 성능을 높이는 방법이 있습니다.
138. Kinesis – Lambda 처리속도를 높이는 방법
1. Kinesis stream의 샤드 개수를 증가시킨다.
2. Lambda의 가용 메모리를 증가시킨다.
(Lambda는 가용 메모리 크기에 따라 CPU 성능이 조절됨)
하지만 저희의 경우 CPU 보다는
139. Kinesis – Lambda 처리속도를 높이는 방법
1. Kinesis stream의 샤드 개수를 증가시킨다.
2. Lambda의 가용 메모리를 증가시킨다.
(Lambda는 가용 메모리 크기에 따라 CPU 성능이 조절됨)
I/O에 인텐시브하기 때문에 두 번째 방법은 배제하고 있습니다.
140. 로그파일 포맷: JSON
• 복잡한 게임 시스템 → 복잡한 로그 스키마
• Lambda는 최대 1000개의 로그를 하나의 파일로 저장
(Kinesis 샤드의 초당 최대 쓰기 개수)
이제 저희가 로그를 어떻게 저장하는 지 말씀드리려고 합니다.
141. 로그파일 포맷: JSON
• 복잡한 게임 시스템 → 복잡한 로그 스키마
• Lambda는 최대 1000개의 로그를 하나의 파일로 저장
(Kinesis 샤드의 초당 최대 쓰기 개수)
저희는 아이템 구조 등 복잡한 게임시스템으로
142. 로그파일 포맷: JSON
• 복잡한 게임 시스템 → 복잡한 로그 스키마
• Lambda는 최대 1000개의 로그를 하나의 파일로 저장
(Kinesis 샤드의 초당 최대 쓰기 개수)
보다 유연한 로그 스키마가 필요했고
143. 로그파일 포맷: JSON
• 복잡한 게임 시스템 → 복잡한 로그 스키마
• Lambda는 최대 1000개의 로그를 하나의 파일로 저장
(Kinesis 샤드의 초당 최대 쓰기 개수)
때문에 JSON 형식으로 로그를 저장하고 있습니다.
144. 로그파일 포맷: JSON
• 복잡한 게임 시스템 → 복잡한 로그 스키마
• Lambda는 최대 1000개의 로그를 하나의 파일로 저장
(Kinesis 샤드의 초당 최대 쓰기 개수)
여기서 Lambda는 최대 1000개의 로그를
하나의 파일로 저장하는데요.
145. 엄청나게 많은 파일 개수 → 네트워크 오버헤드
로그파일 포맷: JSON
• 복잡한 게임 시스템 → 복잡한 로그 스키마
• Lambda는 최대 1000개의 로그를 하나의 파일로 저장
(Kinesis 샤드의 초당 최대 쓰기 개수)
사실 이런 저장방식은
엄청나게 많은 파일을 생성시키고
146. 엄청나게 많은 파일 개수 → 네트워크 오버헤드
로그파일 포맷: JSON
• 복잡한 게임 시스템 → 복잡한 로그 스키마
• Lambda는 최대 1000개의 로그를 하나의 파일로 저장
(Kinesis 샤드의 초당 최대 쓰기 개수)
결국 분석 시에 네트워크 오버헤드를 유발하게 됩니다.
153. Parquet
• 스키마를 가진 컬럼형 저장 포맷
• 복잡한 중첩 데이터 구조도 지원
• 기본적으로 Snappy 압축
• Column projection
• Predicate pushdown
Parquet 파일 형식에 대해서 소개해드리면
154. Parquet
• 스키마를 가진 컬럼형 저장 포맷
• 복잡한 중첩 데이터 구조도 지원
• 기본적으로 Snappy 압축
• Column projection
• Predicate pushdown
먼저 스키마를 가진 컬럼형 저장 포맷이라고
말씀드릴 수 있습니다.
155. Parquet
• 스키마를 가진 컬럼형 저장 포맷
• 복잡한 중첩 데이터 구조도 지원
• 기본적으로 Snappy 압축
• Column projection
• Predicate pushdown
또한 구조화된 포맷임에도 불구하고
156. Parquet
• 스키마를 가진 컬럼형 저장 포맷
• 복잡한 중첩 데이터 구조도 지원
• 기본적으로 Snappy 압축
• Column projection
• Predicate pushdown
복잡한 중첩데이터 구조도 지원하고요.
157. Parquet
→ 네트워크 트래픽 감소
• 스키마를 가진 컬럼형 저장 포맷
• 복잡한 중첩 데이터 구조도 지원
• 기본적으로 Snappy 압축
• Column projection
• Predicate pushdown
기본적으로 Snappy 형식의 압축을 하고있고
158. Parquet
→ 네트워크 트래픽 감소
• 스키마를 가진 컬럼형 저장 포맷
• 복잡한 중첩 데이터 구조도 지원
• 기본적으로 Snappy 압축
• Column projection
• Predicate pushdown
Column projection, Predicate Pushdown
기능을 제공합니다.
159. Parquet
→ 네트워크 트래픽 감소
• 스키마를 가진 컬럼형 저장 포맷
• 복잡한 중첩 데이터 구조도 지원
• 기본적으로 Snappy 압축
• Column projection
• Predicate pushdown
Snappy 압축과 아래 두가지 기능은
160. Parquet
→ 네트워크 트래픽 감소
• 스키마를 가진 컬럼형 저장 포맷
• 복잡한 중첩 데이터 구조도 지원
• 기본적으로 Snappy 압축
• Column projection
• Predicate pushdown
네트워크 트래픽을 감소 시킬 수 있습니다.
162. Column projection
4월 1일에 접속한 레벨 60의 플레이어 수
SELECT
COUNT(DISTINCT(player_entity_id))
FROM PlayerEntered_asia_a
WHERE __date="2018-04-01"
AND player_level=60
4월 1일에 접속한 레벨 60의 플레이어 수를
추출하는 쿼리를 예제로 들 수 있습니다.
163. Column projection
쿼리에 필요한 컬럼만 스캔
+- *FileScan parquet
[player_entity_id#44,player_level#45,__date#53]
이 쿼리의 플랜을 보면
164. Column projection
쿼리에 필요한 컬럼만 스캔
+- *FileScan parquet
[player_entity_id#44,player_level#45,__date#53]
쿼리에 실제로 필요한
플레이어 아이디와, 레벨, 날짜만 스캔하는 것을 알 수 있습니다.
165. Column projection
쿼리에 필요한 컬럼만 스캔
+- *FileScan parquet
[player_entity_id#44,player_level#45,__date#53]
결국 컬럼형 저장방식이기 때문에
166. Column projection
쿼리에 필요한 컬럼만 스캔
+- *FileScan parquet
[player_entity_id#44,player_level#45,__date#53]
쿼리에 필요한 컬럼만 스캔하여
167. Column projection
쿼리에 필요한 컬럼만 스캔
+- *FileScan parquet
[player_entity_id#44,player_level#45,__date#53]
네트워크 트래픽을 낮출 수 있습니다.
168. Predicate pushdown
레벨 60인 데이터만 필터링
PushedFilteres:
[IsNotNull(player_level),
EqualTo(player_level,60)]
또 Predicate pushdown은 같은 예제로
169. Predicate pushdown
레벨 60인 데이터만 필터링
PushedFilteres:
[IsNotNull(player_level),
EqualTo(player_level,60)]
메타데이터에 저장된 통계값을 이용해
186. 로그 스키마 관리
• 로그는 다양한 스키마를 가진다.
• 접속로그, 채집로그, 구매로그 등
• 새로운 스키마는 언제든지 추가될 수 있어야 한다.
• 스키마 변경 시 적재된 로그를 모두 마이그레이션할 수 없다.
다음은 로그 스키마 관리인데요.
187. 로그 스키마 관리
• 로그는 다양한 스키마를 가진다.
• 접속로그, 채집로그, 구매로그 등
• 새로운 스키마는 언제든지 추가될 수 있어야 한다.
• 스키마 변경 시 적재된 로그를 모두 마이그레이션할 수 없다.
결국은 JSON에서 Parquet로
구조화된 데이터 유형을 사용하기 때문에
188. 로그 스키마 관리
• 로그는 다양한 스키마를 가진다.
• 접속로그, 채집로그, 구매로그 등
• 새로운 스키마는 언제든지 추가될 수 있어야 한다.
• 스키마 변경 시 적재된 로그를 모두 마이그레이션할 수 없다.
로그 스키마 관리가 필요합니다.
189. 로그 스키마 관리
• 로그는 다양한 스키마를 가진다.
• 접속로그, 채집로그, 구매로그 등
• 새로운 스키마는 언제든지 추가될 수 있어야 한다.
• 스키마 변경 시 적재된 로그를 모두 마이그레이션할 수 없다.
먼저 저희는 접속로그, 채집로그 등
190. 로그 스키마 관리
• 로그는 다양한 스키마를 가진다.
• 접속로그, 채집로그, 구매로그 등
• 새로운 스키마는 언제든지 추가될 수 있어야 한다.
• 스키마 변경 시 적재된 로그를 모두 마이그레이션할 수 없다.
로그 유형별로 스키마를 가지고 있습니다.
191. 로그 스키마 관리
• 로그는 다양한 스키마를 가진다.
• 접속로그, 채집로그, 구매로그 등
• 새로운 스키마는 언제든지 추가될 수 있어야 한다.
• 스키마 변경 시 적재된 로그를 모두 마이그레이션할 수 없다.
새롭게 컨텐츠가 들어갈 때
새로운 스키마를 쉽게 추가할 수 있지만
192. 로그 스키마 관리
• 로그는 다양한 스키마를 가진다.
• 접속로그, 채집로그, 구매로그 등
• 새로운 스키마는 언제든지 추가될 수 있어야 한다.
• 스키마 변경 시 적재된 로그를 모두 마이그레이션할 수 없다.
기존에 존재하는 스키마를 변경할 땐
193. 로그 스키마 관리
• 로그는 다양한 스키마를 가진다.
• 접속로그, 채집로그, 구매로그 등
• 새로운 스키마는 언제든지 추가될 수 있어야 한다.
• 스키마 변경 시 적재된 로그를 모두 마이그레이션할 수 없다.
약간 제한되는 것들이 있습니다.
194. 로그 스키마 관리
• 로그는 다양한 스키마를 가진다.
• 접속로그, 채집로그, 구매로그 등
• 새로운 스키마는 언제든지 추가될 수 있어야 한다.
• 스키마 변경 시 적재된 로그를 모두 마이그레이션할 수 없다.
약간 제한되는 것들이 있습니다.
195. 로그 스키마 관리
• 로그는 다양한 스키마를 가진다.
• 접속로그, 채집로그, 구매로그 등
• 새로운 스키마는 언제든지 추가될 수 있어야 한다.
• 스키마 변경 시 적재된 로그를 모두 마이그레이션할 수 없다.
예를 들어, 컬럼 이름을 바꾼다고 하면
196. 로그 스키마 관리
• 로그는 다양한 스키마를 가진다.
• 접속로그, 채집로그, 구매로그 등
• 새로운 스키마는 언제든지 추가될 수 있어야 한다.
• 스키마 변경 시 적재된 로그를 모두 마이그레이션할 수 없다.
이미 적재되어 있는 모든 로그에 대하여
197. 로그 스키마 관리
• 로그는 다양한 스키마를 가진다.
• 접속로그, 채집로그, 구매로그 등
• 새로운 스키마는 언제든지 추가될 수 있어야 한다.
• 스키마 변경 시 적재된 로그를 모두 마이그레이션할 수 없다.
새로운 컬럼 이름으로 바꿔서 다시 저장하는
마이그레이션 비용이 매우 크기 때문입니다.
198. 로그 스키마 관리
• 로그는 다양한 스키마를 가진다.
• 접속로그, 채집로그, 구매로그 등
• 새로운 스키마는 언제든지 추가될 수 있어야 한다.
• 스키마 변경 시 적재된 로그를 모두 마이그레이션할 수 없다.
→ 컬럼 추가만 가능! 하위호환성을 유지하여야 한다.
때문에 저희는 컬럼 추가만 가능하게 하여
199. 로그 스키마 관리
• 로그는 다양한 스키마를 가진다.
• 접속로그, 채집로그, 구매로그 등
• 새로운 스키마는 언제든지 추가될 수 있어야 한다.
• 스키마 변경 시 적재된 로그를 모두 마이그레이션할 수 없다.
→ 컬럼 추가만 가능! 하위호환성을 유지하여야 한다.
하위호환성을 유지하는 정책을 두고 있습니다.
200. 로그 스키마 업데이트
1. 스키마 별 Class 추가 또는 업데이트
2. 배포 시 Spark StructType JSON 포맷으로 추출
3. AWS S3에 저장
4. Parquet 변환 배치잡에서 매번 스키마 정보를 읽고 수행
저희는 서버 코드 상에서 로그 스키마를 관리하는데요.
201. 로그 스키마 업데이트
1. 스키마 별 Class 추가 또는 업데이트
2. 배포 시 Spark StructType JSON 포맷으로 추출
3. AWS S3에 저장
4. Parquet 변환 배치잡에서 매번 스키마 정보를 읽고 수행
스키마 별로 클래스가 존재하고
202. 로그 스키마 업데이트
1. 스키마 별 Class 추가 또는 업데이트
2. 배포 시 Spark StructType JSON 포맷으로 추출
3. AWS S3에 저장
4. Parquet 변환 배치잡에서 매번 스키마 정보를 읽고 수행
이 클래스로부터 데이터를 담은 객체를 생성하여
로그를 전송합니다.
203. 로그 스키마 업데이트
1. 스키마 별 Class 추가 또는 업데이트
2. 배포 시 Spark StructType JSON 포맷으로 추출
3. AWS S3에 저장
4. Parquet 변환 배치잡에서 매번 스키마 정보를 읽고 수행
새로운 버전 배포 시에
204. 로그 스키마 업데이트
1. 스키마 별 Class 추가 또는 업데이트
2. 배포 시 Spark StructType JSON 포맷으로 추출
3. AWS S3에 저장
4. Parquet 변환 배치잡에서 매번 스키마 정보를 읽고 수행
각각의 스키마 별로
205. 로그 스키마 업데이트
1. 스키마 별 Class 추가 또는 업데이트
2. 배포 시 Spark StructType JSON 포맷으로 추출
3. AWS S3에 저장
4. Parquet 변환 배치잡에서 매번 스키마 정보를 읽고 수행
SparkSQL에서 StructType이라는 클래스에서 다루는
JSON 포맷으로 스키마를 추출하고
206. 로그 스키마 업데이트
1. 스키마 별 Class 추가 또는 업데이트
2. 배포 시 Spark StructType JSON 포맷으로 추출
3. AWS S3에 저장
4. Parquet 변환 배치잡에서 매번 스키마 정보를 읽고 수행
이 것을 따로 특정 S3 버킷에 저장합니다.
207. 로그 스키마 업데이트
1. 스키마 별 Class 추가 또는 업데이트
2. 배포 시 Spark StructType JSON 포맷으로 추출
3. AWS S3에 저장
4. Parquet 변환 배치잡에서 매번 스키마 정보를 읽고 수행
그리고 JSON 파일을 Parquet로 변환하는 배치잡에서는
208. 로그 스키마 업데이트
1. 스키마 별 Class 추가 또는 업데이트
2. 배포 시 Spark StructType JSON 포맷으로 추출
3. AWS S3에 저장
4. Parquet 변환 배치잡에서 매번 스키마 정보를 읽고 수행
아까 저장했던 스키마 중
가장 최근 버전의 스키마를 읽고 처리하는데요.
209. 로그 스키마 업데이트
1. 스키마 별 Class 추가 또는 업데이트
2. 배포 시 Spark StructType JSON 포맷으로 추출
3. AWS S3에 저장
4. Parquet 변환 배치잡에서 매번 스키마 정보를 읽고 수행
스키마 저장소를 따로 관리하기 때문에
210. 로그 스키마 업데이트
1. 스키마 별 Class 추가 또는 업데이트
2. 배포 시 Spark StructType JSON 포맷으로 추출
3. AWS S3에 저장
4. Parquet 변환 배치잡에서 매번 스키마 정보를 읽고 수행
새로 추가된 스키마에 대해서도
211. 로그 스키마 업데이트
1. 스키마 별 Class 추가 또는 업데이트
2. 배포 시 Spark StructType JSON 포맷으로 추출
3. AWS S3에 저장
4. Parquet 변환 배치잡에서 매번 스키마 정보를 읽고 수행
별다른 처리 없이 배치잡에서 알 수 있습니다.
212. 로그 스키마 업데이트
schema = StructType.fromJson(schema_json)
Parquet 변환 시 로드
1. 스키마 별 Class 추가 또는 업데이트
2. 배포 시 Spark StructType JSON 포맷으로 추출
3. AWS S3에 저장
4. Parquet 변환 배치잡에서 매번 스키마 정보를 읽고 수행
PySpark
213. 로그 스키마 업데이트
schema = StructType.fromJson(schema_json)
Parquet 변환 시 로드
1. 스키마 별 Class 추가 또는 업데이트
2. 배포 시 Spark StructType JSON 포맷으로 추출
3. AWS S3에 저장
4. Parquet 변환 배치잡에서 매번 스키마 정보를 읽고 수행
PySpark
JSON으로된 로그를 Parquet로 변환시
214. 로그 스키마 업데이트
schema = StructType.fromJson(schema_json)
Parquet 변환 시 로드
1. 스키마 별 Class 추가 또는 업데이트
2. 배포 시 Spark StructType JSON 포맷으로 추출
3. AWS S3에 저장
4. Parquet 변환 배치잡에서 매번 스키마 정보를 읽고 수행
PySpark
보시는 코드와 같이 JSON으로된 스키마 파일을 로드하여
215. 로그 스키마 업데이트
schema = StructType.fromJson(schema_json)
Parquet 변환 시 로드
1. 스키마 별 Class 추가 또는 업데이트
2. 배포 시 Spark StructType JSON 포맷으로 추출
3. AWS S3에 저장
4. Parquet 변환 배치잡에서 매번 스키마 정보를 읽고 수행
PySpark
StructType 객체를 생성하고
216. 로그 스키마 업데이트
schema = StructType.fromJson(schema_json)
Parquet 변환 시 로드
1. 스키마 별 Class 추가 또는 업데이트
2. 배포 시 Spark StructType JSON 포맷으로 추출
3. AWS S3에 저장
4. Parquet 변환 배치잡에서 매번 스키마 정보를 읽고 수행
PySpark
JSON 로그의 스키마를 지정하고 있습니다.
217. 로그 스키마 업데이트
schema = StructType.fromJson(schema_json)
Parquet 변환 시 로드
1. 스키마 별 Class 추가 또는 업데이트
2. 배포 시 Spark StructType JSON 포맷으로 추출
3. AWS S3에 저장
4. Parquet 변환 배치잡에서 매번 스키마 정보를 읽고 수행
PySpark
물론 JSON 로그로 부터 스키마를 추론할 수 있기도 하지만
218. 로그 스키마 업데이트
schema = StructType.fromJson(schema_json)
Parquet 변환 시 로드
1. 스키마 별 Class 추가 또는 업데이트
2. 배포 시 Spark StructType JSON 포맷으로 추출
3. AWS S3에 저장
4. Parquet 변환 배치잡에서 매번 스키마 정보를 읽고 수행
PySpark
성능이 느려지고
219. 로그 스키마 업데이트
schema = StructType.fromJson(schema_json)
Parquet 변환 시 로드
1. 스키마 별 Class 추가 또는 업데이트
2. 배포 시 Spark StructType JSON 포맷으로 추출
3. AWS S3에 저장
4. Parquet 변환 배치잡에서 매번 스키마 정보를 읽고 수행
PySpark
명시적인 것이 훨씬 좋다는 판단 하에
220. 로그 스키마 업데이트
schema = StructType.fromJson(schema_json)
Parquet 변환 시 로드
1. 스키마 별 Class 추가 또는 업데이트
2. 배포 시 Spark StructType JSON 포맷으로 추출
3. AWS S3에 저장
4. Parquet 변환 배치잡에서 매번 스키마 정보를 읽고 수행
PySpark
스키마를 따로 정의하고 관리하는 방법을 사용하고 있습니다.
221. EMR Spark 클러스터 스펙
• 메모리가 중요하므로 r4 타입을 선호
• 작은 인스턴스 4개 보다 큰 인스턴스 1개로
• 좋은 인스턴스가 네트워크 속도도 더 빠르다
• EMR이 YARN 컨테이너에 할당하는 메모리 비율이 더 크다
다음으로는 EMR에서 Spark 클러스터를 할당하는 팁인데요.
222. EMR Spark 클러스터 스펙
• 메모리가 중요하므로 r4 타입을 선호
• 작은 인스턴스 4개 보다 큰 인스턴스 1개로
• 좋은 인스턴스가 네트워크 속도도 더 빠르다
• EMR이 YARN 컨테이너에 할당하는 메모리 비율이 더 크다
인 메모리 방식이기 때문에
많은 메모리가 필요할 수 있어서
223. EMR Spark 클러스터 스펙
• 메모리가 중요하므로 r4 타입을 선호
• 작은 인스턴스 4개 보다 큰 인스턴스 1개로
• 좋은 인스턴스가 네트워크 속도도 더 빠르다
• EMR이 YARN 컨테이너에 할당하는 메모리 비율이 더 크다
메모리 최적화 타입인 r4 타입을 선호하고 있습니다.
224. EMR Spark 클러스터 스펙
• 메모리가 중요하므로 r4 타입을 선호
• 작은 인스턴스 4개 보다 큰 인스턴스 1개로
• 좋은 인스턴스가 네트워크 속도도 더 빠르다
• EMR이 YARN 컨테이너에 할당하는 메모리 비율이 더 크다
또한 작은 인스턴스 여러 개 보다는
225. EMR Spark 클러스터 스펙
• 메모리가 중요하므로 r4 타입을 선호
• 작은 인스턴스 4개 보다 큰 인스턴스 1개로
• 좋은 인스턴스가 네트워크 속도도 더 빠르다
• EMR이 YARN 컨테이너에 할당하는 메모리 비율이 더 크다
큰 인스턴스 하나를 사용하고 있는데
226. EMR Spark 클러스터 스펙
• 메모리가 중요하므로 r4 타입을 선호
• 작은 인스턴스 4개 보다 큰 인스턴스 1개로
• 좋은 인스턴스가 네트워크 속도도 더 빠르다
• EMR이 YARN 컨테이너에 할당하는 메모리 비율이 더 크다
그 이유는 좋은 인스턴스일수록
227. EMR Spark 클러스터 스펙
• 메모리가 중요하므로 r4 타입을 선호
• 작은 인스턴스 4개 보다 큰 인스턴스 1개로
• 좋은 인스턴스가 네트워크 속도도 더 빠르다
• EMR이 YARN 컨테이너에 할당하는 메모리 비율이 더 크다
AWS에서 더 높은 네트워크 속도를 제공하고 있고
228. EMR Spark 클러스터 스펙
• 메모리가 중요하므로 r4 타입을 선호
• 작은 인스턴스 4개 보다 큰 인스턴스 1개로
• 좋은 인스턴스가 네트워크 속도도 더 빠르다
• EMR이 YARN 컨테이너에 할당하는 메모리 비율이 더 크다
EMR에서 Spark를 사용할 때
229. EMR Spark 클러스터 스펙
• 메모리가 중요하므로 r4 타입을 선호
• 작은 인스턴스 4개 보다 큰 인스턴스 1개로
• 좋은 인스턴스가 네트워크 속도도 더 빠르다
• EMR이 YARN 컨테이너에 할당하는 메모리 비율이 더 크다
YARN이라는 리소스 매니저를 사용하는데
230. EMR Spark 클러스터 스펙
• 메모리가 중요하므로 r4 타입을 선호
• 작은 인스턴스 4개 보다 큰 인스턴스 1개로
• 좋은 인스턴스가 네트워크 속도도 더 빠르다
• EMR이 YARN 컨테이너에 할당하는 메모리 비율이 더 크다
이 때 YARN 컨테이너에 할당하는
메모리 비율이 더 크기 때문입니다.
268. 만들고 붓고 부수고 - 〈야생의 땅: 듀랑고〉 서버 관리 배포 이야기
김찬웅 님 / 4월 25일 오후 4시 30분
〈야생의 땅: 듀랑고〉 서버 아키텍처 Vol. 3
이흥섭 님 / 4월 25일 오후 3시 20분
〈야생의 땅: 듀랑고〉 NoSQL 위에서 MMORPG 개발하기
최호영 님 / 4월 26일 오전 11시
듀랑고의 서버에 관련된 발표로
269. 만들고 붓고 부수고 - 〈야생의 땅: 듀랑고〉 서버 관리 배포 이야기
김찬웅 님 / 4월 25일 오후 4시 30분
〈야생의 땅: 듀랑고〉 서버 아키텍처 Vol. 3
이흥섭 님 / 4월 25일 오후 3시 20분
〈야생의 땅: 듀랑고〉 NoSQL 위에서 MMORPG 개발하기
최호영 님 / 4월 26일 오전 11시
내일과 내일 모레에도 세션들이 준비되어있으니
270. 만들고 붓고 부수고 - 〈야생의 땅: 듀랑고〉 서버 관리 배포 이야기
김찬웅 님 / 4월 25일 오후 4시 30분
〈야생의 땅: 듀랑고〉 서버 아키텍처 Vol. 3
이흥섭 님 / 4월 25일 오후 3시 20분
〈야생의 땅: 듀랑고〉 NoSQL 위에서 MMORPG 개발하기
최호영 님 / 4월 26일 오전 11시
관심있는 분들은 많은 참석바랍니다.