Data Engineering 101

1. 데이터 엔지니어링
101
강대명(charsyam@naver.com)

2. 들어가기 전에
● 101은 초보용, 입문용입니다. 고수님들이 보시기에는 이상한 내용이 많
을 수 있습니다.
● 간단한 시연들이 있습니다.
○ 필요한 자료는 아래에서 받으실 수 있습니다.
○ https://github.com/charsyam/dataeng101
● 로그 자체는 제가 임의로 생성한 로그입니다. 서비스는 다 다릅니다.

3. What is Data Engineering
● Data Engineer
○ 다른 사람들이 데이터를 사용하기 쉽도록 저장/수집하고 ETL 작
업등을 처리하는 직군, 로그 수집, 로그 정제
● Data Scientist
○ 데이터를 이용하여, 분석을 하거나, 추천등의 로직을 작성하는 직
군.
● Data Engineering
○ Data Scientist 들이 관련 작업을 쉽게 할 수 있도록 데이터를 수집
/정제하는 일련의 작업들

4. Why Data Engineering
● Raw 데이터로 부터 의미 있는 데이터나 정보를 추출하기 위해서는 데
이터의 변환등이 필요하다. 그런데 이런 작업을 Data Scientist 가 하는
것은 그들의 전문 분야가 아니기 때문에 아닌 부분들도 많아서, 전문적
으로 데이터를 가공하고 처리하기 쉽게 넘겨주는 분야가 필요.(겹치기
도 함.)
● Data-Driven 한 의사결정을 하기 위한 데이터 공급을 위해

5. 간단한 예를 들어봅시다.
● PV(Page Views) : 하루에 사이트에 들어온 총 리퀘스트의 양.
● UV(Unique Views) : 하루에 사이트에 들어온 유니크한 유저의 수
● DAU(Daily Active Users) : 하루의 UV와 동일
● MAU(Monthly Active Users) : 한달간 들어온 유니크한 유저의 수

6. 아래의 로그가 있다고 가정합니다.
각 항목들은 TAB으로 구분되어 있습니다.
● 로그 샘플
○ 2018-11-09 00:00:00 isol001 3.39.6.20 - - 1541721780
10 charsyam.net 18380163 GET /api/v2/goods
Mozilla/5.0 (Windows NT 10.0; WOW64)
AppleWebKit/537.36 (KHTML, like Gecko)
Chrome/69.0.3497.100 Safari/537.36

7. 로그의 포맷에 대한 고민이 필요합니다.(왜?)
● TSV
○ 컬럼들이 tab 으로 구분
● CSV
○ 컬럼들이 comma(,) 로 구분
● JSON
○ 데이터를 json형태로 저장
TSV, CSV는 뒤로만 컬럼이 추가되어야 하고, 기존 컬럼을 삭제하면 안됩니
다. 다른 형태와 JSON을 혼합해서 쓰기도 합니다.

8. 로그 항목
2018-11-09 00:00:00 Access Time
isol001 Web Server
3.39.6.20 Client IP
1541721780 Access unixtimestamp
10 Processing Time
charsyam.net domain
18380163 User ID
GET Method
/api/v2/goods uri
okhttp/3.11.0
charsyam android 5.2.3
User-Agent

9. 아래의 로그에서 PV와 UV를 뽑아보도록 하겠습니
다.
● 어떻게 뽑아야 할까요?
○ PV와 UV의 기준이 되는 항목은 무엇인가요?

10. 기준은 User ID

11. PV(Page Views)
● PV 는 접근한 유저가 요청한 모든 리퀘스트의 수가 됩니다.
● 그럼 로그가 하루치 로그라면 하루의 PV는?

12. 시간별 PV
● 특정 시간의 PV는 얼마나 봐야 할까요?
● 하루에 제일 트래픽이 많이 몰리는 시간은?

13. PV(PageView)

14. UV(Unique Views)
● UV 는 접근 한 유저를 한번씩만 계산하여 더한 값이 됩니다.
● 그럼 로그가 하루치 로그라면 하루의 UV는?

15. 시간별 UV
● 특정 시간의 UV는 얼마나 봐야 할까요?

16. PV(Page Views) vs UV(Unique Views)

17. 특정 유저가 하루에 몇번이나 방문할까?
● 특정 유저가 몇번 방문했다고 어떻게 정의해야 할까요?
● 이런걸 알면 사용자들이 하루에 몇번이나 방문하는지 알 수 있고, 로얄
티가 높은 유저들을 알수가 있습니다.

18. 세션(Session)
● 특정 시간 동안 들어온 유저는 1번으로 카운트한다.
○ 세션의 기준이 15분이면, 15분 이상 넘기지 않는 연속된 작업은 다
1개로...

19. 세션(Session) - 세션은 2개
'2018-11-09 00:00:00' Session 15 * 60 = 900
'2018-11-09 00:03:00' 180 1
'2018-11-09 00:06:00' 180
'2018-11-09 00:09:00' 180
'2018-11-09 00:12:00' 180
'2018-11-09 00:15:00' 180
'2018-11-09 02:00:00' 2700 2

20. 광고비는 어디에 더 많이 써야 할까?
● 우리는 페이스북, 트위터, 카카오, 네이버, 이메일마켓팅등에 광고비를
집행하고 있습니다. 어디에 가장 많은 광고비를 투입해야 할까요?

21. url 샘플
/api/v2/landing?from=kakao
/api/v2/goods?from=facebook
/api/v2/landing?from=twitter
/api/v2/landing?from=email
/api/v2/goods?from=naver

22. 광고비는 어디에 더 많이 써야 할까?
● 전체 유저의 접근이 다음과 같은 비율로 들어왔다고 합니다.
광고 매체 집행 광고비 접근 유저 수
facebook 1000만원 57167(49.5%)
twitter 1000만원 22788(19.7%)
kakao 1000만원 11850(10.3%)
naver 1000만원 11620(10.1%)
email 1000만원 12050(10.4%)

23. 광고비는 어디에 더 많이 써야 할까?
● 구매까지 완료한 유저의 비율은?
광고 매체 집행 광고비 접근 유저 수 완료 유저 수 전환 비율
facebook 1000만원 57167(49.5%) 2815(49.2%) 4.9%
twitter 1000만원 22788(19.7%) 1164(20.3%) 5.1%
kakao 1000만원 11850(10.3%) 568(9.9%) 4.8%
naver 1000만원 11620(10.1%) 542(9.5%) 4.7%
email 1000만원 12050(10.4%) 638(11.1%) 5.3%

24. Funnel Tracking
● NO24 라는 서점이 있습니다.
○ 시작페이지, 검색페이지, 도서페이지, 장바구니, 결제페이지 등이
있다고 할때 각각의 페이지를 통과할때 마다 사용자들은 얼마나
빠져나갈까요?

25. Funnel
Tracking

26. Data Source
데이터가 어디에 있는가?

27. 파일, RDB 등등

28. 정보들을 데이터 소스로 부터 읽어서
(Extract)
원하는 형태로 변환하고
(Transfrom)
저장하는 것
(Load)

29. ETL

30. 데이터 빅뱅의 시대
2025년 160 제타바이트

31. 빅데이터

32. 한대의 장비로
처리할 수 있을까요?

33. 데이터가 많아지면서 문제가 생기는
부분
● 데이터 수집
● 데이터 처리(정제, 변환)
● 데이터 저장

34. 데이터 수집

35. 데이터 수집에서의 문제점
● 많은 양의 데이터 소스를 관리해야 함.
○ 그래서 Data Lake 같은 개념이 나옴
● 데이터의 Schema도 자주 변경됨
● 데이터 소스에 있는 Raw Data 를 저장하기 위해서는
대용량의 스토리지가 필요함.
● 정형 데이터 vs 비정형 데이터
● 배치 작업 vs 실시간 스트리밍 작업

36. 현재의 여러가지 기술들
● 로그수집
○ Logstash, fluentd, syslogd
● 로그저장
○ hdfs(hadoop), 엄청 좋은 NAS, 클라우드 스토리지
○ Kafka, RDBMS

37. Log 수집 #1
web001
web002
web003
web004
Mysql
Or
MongoDB
통계작업

38. Log 수집 #2
web001
web002
web003
web004
redis
Buffer 를 이용한 쓰기 효
율화(Write-Back)
Mysql
or
Mongodb

39. Log 수집 #3
web001
web002
web003
web004
Collector
hdfs
or
s3
scp
syslogd
or
logstash
통계작업
By Spark, Hive,
Presto, MR

40. 데이터 처리

41. 데이터 처리에서의 문제점
● 많은 양의 데이터를 한대에서 처리할 수 없음
○ 한대에서 처리한다고 해도 매우 느림.
● 결국 분산 처리가 필요함.
● 분산 처리하는 것은 한대에서 처리하는 것 보다 매우
복잡해짐.

42. 대량의 데이터를
정렬한다면 어떻게?

43. Bucket Sort

44. 현재의 여러가지 기술들
● 이미 툴들이 이런걸 해줍니다.(여전히 사이징 이슈는 있습니다.)
● SQL 기반
○ SparkSQL, Hive, Presto, Redshift, Bigquery
● 코드 기반
○ Hadoop MR, Spark

45. 데이터 저장

46. 처리한 데이터를
빠르게 서빙하기 위한
저장소도 필요합니다.

47. 데이터 저장에서의 문제점
● 많은 사람의 추천데이터를 어떻게 보여줄 것인가?
● ETL의 결과를 다시 다른 ETL의 입력으로 사용한다면?

48. ETL 작업이 하나뿐일
까요?

49. 세션 카운트
추천
UV/PV
수익 측정

50. 작업에 의존성이 있다
면?

51. 작업이 중간에 실패하
면?

52. Data Pipeline

53. What is Data Pipeline?
● 우리는 단순히 몇가지 통계를 뽑지 않습니다.
○ UV, PV 등이면 충분해요.
○ 이러면 Data Pipeline 은 필요 없습니다.
● 또는 모든 데이터를 그냥 Raw Data에서 뽑아내요라고 하신다면 특별히
관리할 필요가 없습니다.
● 단순한 데이터 추출이 아니라, 여러 데이터들이 연관관계를 가지거나,
중간 중간 변환되어 추출되어야 하는 경우.

54. Data Pipeline
● 뭔가 필요한 데이터들을 단계별로 만들고, 이용하기
위해서 만들어진 작업들을 관리하는 것.
● 머신 러닝등을 위해서 이런 작업들을 하는 걸 머신러
닝 파이프라인이라고 하기도 합니다.

55. 이게 하나의 파이프!!!

56. 이런게 수십개가 생깁니다.

57. Data Pipeline 의 관리 포인트
● 파이프라인에서 에러가 발생하면?
○ 누가 재시작해야 할까요?
● 매일 실행되거나, 특정시간에 돌아야 하는것들이면?
● 그래서 데이터 워크플로우 관리툴을 씁니다.
● 작업 마다 필요한 컴퓨팅 파워(메모리/CPU)가 다르다.

58. 데이터 워크플로우 관리툴
● Pinball, Airflow, Luigi
○ 여기서는 각각의 특징이나 장단점을 비교하지 않
습니다.
■ 저도 모르기 때문이지요.
○ 특정 시간, 실패했을 때, 재 반복등을 대신해줍니다
.

59. Data Pipeline 의 관리의 어려움
● 파이프라인이 계속 재시작 되어야 하면 전체 처리용량
이 부족할 수 있습니다.
● 재시작이 코드의 버그를 수정해 주지는 않습니다.
○ 내가 만든 코드가 아닌데, 개수가 10개를 넘어야
한다고 했는데 9개면... 이게 정상일까 실패일까?

60. 데이터 엔지니어링
● 앞에서 많은 상황을 얘기하고 많은 툴들에 대해서 얘
기했습니다.
○ 데이터 수집, 데이터 처리, 데이터 저장소등
○ 데이터 파이프라인 관리 워크플로우등
● 그러면 이건 누가 제안하고 설치하고, 관리해야 할까
요?

61. 데이터 엔지니어링
● 머신러닝 이런 것들을 하기 위해서도 결국은 데이터가
필요합니다. 그 데이터는 누가 공급하게 될까요?

62. Summary
● 데이터 엔지니어링은 경영진의 의사결정이나, Data
Scientists 등의 작업에 필요한 데이터를 공급하고, 이
를 공급하는 인프라를 담당하는 역할을 하게됩니다.

63. Thank you