'그들이 AWS 위에서 데이터 파이프라인을 운영하는법' 학습노트

2019-06-10

Data Engineering

Data_Engineering_TIL_(20190610)

[학습한 Contents]

‘그들이 AWS 위에서 데이터 파이프라인을 운영하는법’ / 박훈 데이터엔지니어
학습자료 URL : https://docs.google.com/presentation/d/11C_BKio0DZIop_ZjJk7ogxQtWV5qHIr-hHjw277z64k/edit?fbclid=IwAR1-s-ynV3QpgPMKxYuX3B2eg2BbhGJ6h-iXfu9NPt5-86ceEo_Y0Divy04

[학습목표]

AWS 위에서 데이터 파이프라인 운영이해

[학습기록]

1. 데이터 인프라란

데이터 인프라

= 데이터 수집(흩어진 데이터를 모아서 한 곳에 저장)

+= 데이터 처리 (수집한 데이터를 유용하게 활용할 수 있도록 가공)

+= 데이터 조회 (그렇게 저장된 데이터를 사람이 소비)

+= 데이터 서비스 (이와 더불어 서비스 사용자에게도 제공가능)

2. 데이터 인프라의 필요성

결론적으로는 제공하는 서비스로부터 생산되는 데이터를 분석하기 위해서이다.
스타트업 초기에는 서비스 DB에 직접쿼리하는 방식으로 데이터를 끌어와서 업무를 수행하였다. 이런 방식은 데이터 저장소가 여러개가 있거나 물리적으로 분할되어 있다면 업무를 수행하는데 고민거리였다.
비지니스 규모가 커지면서 DB를 물리적으로 분할하고 여러 DB를 join하여 분석해야하는 필요성이 증대되었다.
또한 DB 뿐만 아니라 아래 그림과 같이 elastic search, elastic cache 등 다른 종류의 저장소와도 같이 보고 싶은 분석요구도 증대되었다.

그리고 client(app/web), server log 등 이벤트 스트림저장 데이터에 대해서도 분석이 필요한 경우가 발생한다.
따라서 이런 요구들은 DB 수준으로는 처리가 불가능하고, 복잡하고 대규모 컴퓨팅이 필요하게 되었다. 발표자는 ‘DB는 거들뿐’ 이라는 비유적인 표현을 하였다.
관련내용 URL : https://www.oreilly.com/ideas/applying-the-kappa-architecture-in-the-telco-industry

3. 파이프라인 기초 : Batch와 Stream

serving layer 관련 발표자 추천 학습자료

1) Uber’s Big Data Platform: 100+ Petabytes with Minute Latency

URL 주소 : https://eng.uber.com/uber-big-data-platform/

2) Hudi: Uber Engineering’s Incremental Processing Framework on Apache Hadoop

URL 주소 : https://eng.uber.com/hoodie/

3) Pinot: Near Realtime Analytics @ Uber

URL 주소 : https://www.slideshare.net/XIANGFU3/pinot-near-realtime-analytics-uber

4) Pinot Joins Apache Incubator

URL 주소 : https://engineering.linkedin.com/blog/2019/03/pinot-joins-apache-incubator

5) Engineering Restaurant Manager, our UberEATS Analytics Dashboard

URL 주소 : https://eng.uber.com/restaurant-manager/

4. AWS를 이용한 데이터 인프라 예시

아래 그림을 보면 알 수 있듯이 해야할 일들이 많고 복잡하다.

관련 URL : https://aws.amazon.com/ko/blogs/big-data/how-smartnews-built-a-lambda-architecture-on-aws-to-analyze-customer-behavior-and-recommend-content/

5. ‘데이터 수집’ 국면에서의 데이터 인프라

수집국면에서의 인프라 운영목표

1) 운영비용을 최소화

2) 인프라 비용을 최소화

데이터 수집 대상

1) 클라이언트(app/web) 로그

2) 서버로그(Nginx / server)

3) 데이터베이스 스냅샷 (daily, hourly)

4) Redis 스냅샷 (daily, hourly)

5) ElasticSearch 스냅샷 (daily, hourly)

6) AWS 관련 로그 (ELB, CloudTrail, CloudFront)

6. ‘데이터 수집’ 국면에서 client 로그

클라이언트 로그는 앱이나 웹에서 발생하는 이벤트에 대한 데이터를 말한다.

1) click / impression(노출) 등 사용자의 액션 / 이벤트

2) 서버로그와는 다르면서 유용한 정보를 포함한다.

3) 결제로그 등의 경우 서드파티에 feeding 되어 마케팅 성과 등 측정 용도로 사용될 수 있다.

따라서 세심한 관리가 요구되며 이를 위해 양질의 관리를 위해 별도의 툴들이 필요하다. 예를들면 다음과 같다.

1) 클라이언트 로그 스키마 정의툴

2) 클라이언트 로그 검증도구

3) 클라이언트 로그 입수량 확인 등의 툴

6. ‘데이터 수집’ 국면에서 client

일반적으로는 카프카를 많이 쓴다.

그러나 카프카 인프라 운영시 비용이 높다. 예를들면 다음과 같다.

1) 운영 리소스가 별도로 필요하다.

2) 일정 이상의 (세개 이상) 브로커 인스턴스가 필요

3) 주키퍼 클러스터 필요

4) 앞단에서 받아줄 ELB / Nginx / API 가 추가적으로 필요

카프카 대체방안

키네시스는 앱이나 웹에 대해서 Client SDK가 존재한다.

1) 안드로이드

관련 url : https://github.com/aws-amplify/aws-sdk-android

2) ios

관련 url : https://github.com/aws-amplify/aws-sdk-ios

3) web

관련 url : https://github.com/aws-amplify/amplify-js

AWS 관리형 서비스를 이용할 수 있다. (업그레이드, 스케일링, 모니터링 가능)
카프카와 비교했을때 운영비용도 저렴하다.
Payload 개당 1MB

Payload 관련 URL : https://docs.aws.amazon.com/ko_kr/streams/latest/dev/service-sizes-and-limits.html

단점 : 컨넥터 지원이 카프케에 비해서 미비한 편이다.

예를들어 Spark Structured Streaming, Logstash Output 등 지원 미비

7. ‘데이터 수집’ 국면에서 서버로그

서버로그로는 크게 두가지로 나눌 수 있다.

1) WEB(Nginx)

2) WAS(Application)

일반적으로는 두가지 형태로 수집한다.

1) 에이전트 (로그파일을 읽어서 카프카 등으로 전송)

주로 WEB / WAS의 로그파일을 다룰때 쓴다.

2) 라이브러리 (앱 내에서 직접 카프카 등으로 전송)

중요한 이벤트 (결제나 로그인 등)을 전송할때 주로 쓴다.

경우에 따라서는 이벤트는 별도 Google protobuf, apache avro 등을 이용하여 format으로 관리하기도 한다.

AWS EB (Beanstalk)의 경우 로그파일을 S3 퍼블리싱 할 수 있다.

수집 딜레이가 있으나 간편하게 쓸 수 있는 장점이 있다.

키네시스로 직접 전송할 경우

1) 자바 / 파이썬 / 루비 / node / NET SDK 지원

관련 URL : https://www.amazonaws.cn/en/kinesis/data-streams/faqs/

2) 키네시스 에이전트 지원 (파일 읽어서 전송)

관련 URL : https://docs.aws.amazon.com/ko_kr/streams/latest/dev/writing-with-agents.html

3) AWS 관리형 서비스를 이용할 수 있다. (업그레이드, 스케일링, 모니터링 가능)

4) Payload 개당 1MB

Payload 관련 URL : https://docs.aws.amazon.com/ko_kr/streams/latest/dev/service-sizes-and-limits.html

키네시스

1) IP:PORT 기반의 접근제어가 아니라 IAM 기반

2) EC2(EB)에 IAM Role 필요하기 때문에 다수의 AWS Account 이용 시 난잡해질 수 있음

3) 이에 대한 대안으로 MSK(Managed Kafka)를 쓸 수 있다. (최근에 AWS 서비스로 launching)

8. ‘데이터 수집’ 국면에서 수집한 데이터를 키네시스에서 처리

데이터 수집대상

1) 앱이나 웹 같은 클라이언트 로그

2) 서버로그 (Nginx / server)

데이터 처리를 위해 EMR을 이용한다.

AWS EMR 관리 시 팁 : https://www.popit.kr/tips-for-terrafoming-aws-emr/

EMR은 일종의 AWS 관리형 데이터 처리 프레임워크다.

용량 옵션 버튼을 누르면 원하는 만큼 리소스를 늘릴 수 있다.

EMR 아키텍처 구성가능 툴

1) Spark (Streaming, Batch)

2) Flink (주로 Streaming)

3) Presto (빠르고 강렼한 분산 SQL Engine)

4) 기타 Hbase, Zeppelin, Jupyter 등 설치가능

EMR을 이용한 데이터 처리 아키텍처 예시

EMR을 통해서 스파크 스트리밍으로 데이터를 가공할 수 있다.

1) stream layer : 다른 키네시스 스트림으로 보낼 수 있다. 또한 별도 저장소 필요 시 카운터 값 등 Dynamo 저장 가능

2) batch layer : S3에 저장하여 SQL 쿼리로 조회 가능하다.

2-1) 준 실시간 뷰를 위한 Hot S3 (1분 이내)

2-2) 늦게 들어온 로그까지의 처리를 위한 Cold S3 (수시간 내)

로그 (통상 시계열) 데이터는 조회 시 속도, 편의성을 위해 어느시점에 들어온 것인지 파티션 단위로 관리한다.

1) 일단위 : p_ymd 2019/06/08

2) 시간단위 : p_ymd 2019/06/08/15

이 경우 늦게 들어온 로그는 어떻게 관리해야 할지 정의해야 한다.

1) (생성) 이벤트 타임은 2019.06.08 15:30:02

2) (수집) 키네시스 서버 타임은 2019.06.08 16:01:02

로그가 늦게 들어오는 이유는 다양하다. 문제는 언제 들어올지 알수 없다는 것이다. 그러면 현재 들어오고 있는 로그는 어떻게 확인하는가

1) 최근 6시간 동안의 로그 Hot S3(1분 이내 적재)

2) 6시간 늦게 들어온 로그까지 처리한 Cold S3

9. Stroage 스냅샷

데이터 수집대상

1) 데이터베이스 스냅샷 (daily, hourly)

2) Redis 스냅샷 (daily, hourly)

3) ElasticSearch 스냅샷 (daily, hourly)

4) 기타 사용하는 저장소 등

저장소의 경우 다음의 문제를 해결해야함

1) 숫자 (신규 디비, 기존 디비 컬럼 변경)

2) 종류 (디비 간의 특성이 다르고, ES, EC 등 존재)

3) 규모 (예약과 같은 디비의 경우 양이 나날이 늘어난다)

수집대상인 디비의 컬럼 변경사항을 자동으로 파악해서 데이터 관련자들에게 매일 알람을 준다.

수집대상이 Storage(저장소)인 경우

EMR을 이용해서 배치 프로세싱(스파크, 파이스파크)

1) Daily, Hourly로 Dump

2) 스케쥴러는 Digdag 툴 사용

S3를 메인저장소로 사용

Parquet : Columnar 포맷

하이브 메타스토어

1) 메타스토어 MySQL은 별도의 RDS

2) EMR 클러스터 중 하나를 HMS로 사용

3) Partition 추가는 별도의 스크립트로 운영

Parquet 이란

Parquet 이란 Row(행)이 아니라 Column(열) 기반의 데이터 포맷이다.
기본적인 아이디어

1) “ SELECT * “ (ALL)을 하는 경우보다는 직접 컬럼을 선택하는 경우가 더 잦다.

그렇다면 연산시 같은 컬럼 내 값들을 비슷한 디스크 위치에 묶어두면 조회가 조금 더 빠르지 않을까?

2) 특정 컬럼들은 ENUM(LOGIN / LOGOUT) 값처럼 적은 종류의 값만 들어있다.

그렇다면 LOGIN / LOGIN / LOGIN 을 매번 저장하지 않고, 값의 인덱스와 그 위치만 저장한다면 사이즈가 줄지 않을까?

Parquet 학습관련 읽을거리 : VCNC Apache Spark에서 Parquet 제대로 활용하기

http://engineering.vcnc.co.kr/2018/05/parquet-and-spark/

Hive Meta란

하이브 메타스토어는 일종의 스키마 저장소이다. (RDS + Server)
실제 데이터는 S3에 통상 Parquet 형태로 위치한다.
쿼리시 사용할 DB, 테이블, Partition과 해당 데이터들의 S3 위치를 갖고 있다.
managed 서비스로 AWS Glue Catalog가 존재하지만 IAM으로 접근제어 하는 것이 좋다.

아래 DDL에서 볼 수 있듯이

1) 테이블 생성 시 데이터 경로 (s3) 지정

2) 이후 파티션 추가 (스파크 작업에서 하거나 별도의 스크립트로 작성)

3) 이후 바로 프레스토에서 쿼리 가능

10. ‘데이터 수집’ 국면에서 AWS 서비스가 남기는 로그 수집

일부 AWS 서비스는 지정된 S3 버킷에 로그를 저장한다. 따라서 하이브 메타스토어에 스키마만 작성해주면 즉시 프레스토에서 쿼리가 가능하다.

1) ELB(CLB,ALB,NLB,…)

2) CloudTrail(AWS Audit로그, 누가 무엇을 했는지)

3) CloudFront(CND Access Log)

다만 다수의 AWS Account를 사용할 경우 관리가 복잡해진다.

AWS가 남겨주는 서비스 로그의 경우 Owner는 AWS의 계정(사용자 계정이 아니라)이어야 한다. 사용자 계정을 단지 Full access 권한을 추가할 뿐이다.

s3의 경우 Role-based (IAM)으로 권한 관리

1) 다수의 AWS Account를 사용하는 경우 한 Account로 몰아서 저장 (Call Limit, 합병 등)

2) 예를들어서 전사 ELB 로그는 Data AWS Account에 저장한다.

그렇다면 EMR(프레스토)로 조회하는 데이터 쪽의 계정을 어떻게 해야하는가

S3 객체를 다 찾아 데이터 쪽 계정을 권한 추가하기 어려운 문제가 있다.

또한 권한을 줄다고 하더라도 Data 쪽 계정이 사용하는 툴이 assume-role 기능을 지원하지 않으면 사용할 수 없다.

AWS가 남기는 S3는 EMR이 위치한 Account에서 관리해야 한다.

Assume role(A계정이 B계정의 Role 권한을 이용)을 지원하지 않는 라이브러리/툴이 있을 수 있기 때문에 최대한 Assume role을 사용하지 않는 것이 좋다.

11. ‘데이터 수집’ 국면 요약

데이터는 일단 모두 S3에 적재한다.
데이터 포맷은 사이즈가 작고 빠른 파케이가 좋다.
쿼리엔진은 프레스토를 이용한다. 강력한 JSON : Aggregation, Geo-spatial 함수를 제공한다.
배치는 물론 스트림 데이터도 1분 내 SQL 조회할 수 있어야 한다.

12. ‘데이터 처리’ 국면 요약

데이터 처리는 원본 적재 후 별도의 가공단계를 말한다.
데이터 처리는 S3(원본) + 별도의 스토리지에 적재하는 것으로 수행한다.
데이터 처리 요구사항에 따라서 저장소를 결정하면 된다.
데이터 원본은 프레스토에서 조회 가능하도록 s3에 적재한다.
스파크는 필요 시 Yarn cluster 모드로 사용하고, 모니터링을 위해 약간의 툴링 작업이 필요할 수도 있다.
재작업이 언제나 있으니 Batch application을 유연하게 작성할 수 있어야 한다.

(환경변수 받아서 기간을 조절하는 등의 설정을 잘 해줘야 한다.)

논리적인 데이터 티어구조를 정의하면 사용 및 관리가 용이해진다

(ex) t1, t2, t3, …)

테이블 이름규칙도 잡아놓으면 운영이 편리하다.

13. ‘데이터 처리’ 국면에서 Data 티어구조란

데이터는 수집이후 가공 과정을 거치게 되는데 데이터의성격에 따라서 티어를 나누어서 관리한다.

1) 수집티어 t1 (원천테이블)

t1_log : 로그성 이벤트

t1_db : 데이터베이스 스냅샷

t1_meta : ElasticSearch, Redis 등 스냅샷

2) 가공티어 t2 (가공된 공용테이블)

t2_customer : 잘게 나누어진 서비스 디비의 고객관련된 정보를 모아 가공한 2차 테이블들을 말한다. 서비스의 테이블 또는 필드가 너무 파편화 되어있을 경우 분석시에 매우 유용하다.

3) 서비스티어 t3 (서비스용, 혹은 특수한 목적)

t3_seller_exported_jdbc : JDBC (MySQL 등) 으로 내보내진 서비스용 원본테이블

14. ‘데이터 처리’ 국면에서 테이블 이름 규칙

도메인과 상관없이 공통으로 적용될 수 있는 테이블 구조에 관한 논의가 필요하다. (Batch 기준)

1) 데이터의 성격

(원천) Timeseries : 시계열 데이터 (로그 등)

(원천) 스냅샷 : 덤프 데이터 (DB 등)

(가공 후) Aggregated : 특정기준으로 Aggregated

2) 집계주기 : daily, hourly

3) 타겟데이터 범위 : 최근 30일, 최근 7일 등 (unique count 등 2일 이상 기간 내 고유값 필요한 경우)

예를 들어, 경쟁업체 관련된 테이블 데이터 생성시

place_comparative_client_aggr_1d_daily : 경쟁업체 최근 1일치 Client 관련 메트릭을 매일 적재

place_comparative_db_aggr_30d_daily : 경쟁업체 최근 30일치 DB 관련 메트릭을 매일 적재

원천 테이블을 Aggregated 없이 가공했다면

leisure_impression_timeseries_hourly : 레저 노출 로그를 시간별로 가공해 적재

place_order_snapshot_daily : 업체 주문 스냅샷을 일별로 가공해 적재

15. ‘데이터 처리’ 국면에서 Batch application 구성 팁

Table을 만드는 Batch Application 의 구조에 관해 논의가 필요하다.

재작업이 언제나 존재하기 때문이다. 예를들어서 장애 / 운영성 작업 / 신규 컬렉션 생성 = 2015. 01. 01 부터 등

따라서 Application 을 유연하게 만들어 쉽게 대처할 수 있도록 하는것이 필요하다.

다음과 같은 사례가 있다.

오늘은 월요일인데 주말과 오늘 오전까지(토 / 일 / 월) Daily 배치가 장애가 발생하였다. 날짜를 환경변수로 받아 Application 을 3번 실행 (Digdag, Script 등)하는 구조인데 코드가 잘못되어 2월부터 다시 모두 적재해야한다면? 120번+ 실행해야 할까?

재적재가 긴급하지 않다면, 현재 EMR 클러스터에서 Application 내에서 시작점과 이터레이션 횟수를 환경변수로 받아 1번만 실행 (길게)하는 것이 좋다. 빠르게 복구해야 한다면 별도의 EMR 클러스터를 띄우고 120개 Application 을 병렬로 (빠르게) 한다.

따라서 두 가지 모두 환경변수로 설정 가능해야 함

위의 사례에서 Batch Application 구조 예시

PlaceImpression_1Range_20190608_PROD : 업체별 노출수를 20190618 기준으로 1번 적재

PlaceImpression_30Range_20190508_PROD : 업체별 노출수를 20190508 부터 20190606 까지 적재

여러 스토리지에서 sink로 내보내는 경우 부분실패 또는 부분 적재가 필요할 수 있다.

가공후 S3 에 원본 + RDS 에 서비스용 적재 경우 S3 에 성공적으로 적재, RDS (JDBC) 는 커넥션 등 문제로 실패

이 경우 S3 만 읽어서 재적재 가능하도록 구성하면 별도의 컴퓨팅 필요 없이 빠르게 복구가능하고 샘플링 해 Dev RDS 에 넣을 수 있다.

16. ‘데이터 처리’ 국면에서 EMR 클러스터 운영 관련 팁

컴퓨팅 속도 차이가 안나게 모두 같은 인스턴스 타입으로, Disk 는 넉넉히 (EBS는 사이즈에 따라 IO 차이) 설정해준다.
비용 절감을 위해 Master / Core 는 On-demand, Task 는 Spot 으로 (Yarn Cluster 모드에서는 Application Master 이 Core 에서 동작하므로 Core 는 on-demand) 설정한다.

17. ‘데이터 처리’ 국면에서 파이프라인 스케쥴링 팁

18. ‘데이터 처리’ 국면에서 Stream application

Streaming 프레임워크는 Application State 를 지원한다.
Flink Streaming State, Spark Streaming State 등이 있다.
State 들은 S3, EFS 등 저장소에 백업되고 장애 등 문제 발생시 복구 될 수 있다.(Checkpoint)
Flink 는 외부에서 조회 (Query) 가능한 State 지원한다.
프레임워크 수준에 따라서 State 지원이 비성숙할 수 있다. (Spark Streaming)
프레임워크에 따라 커넥터 (Kinesis 등) 공식 지원이 없을 수 있다. (Spark Structured Streaming)
State 를 유지하는 이유는 결국 최종 Output 을 위함이다.

(예를들어 업체별 광고 클릭수를 DynamoDB 에 저장)

따라서 Application 내 State 를 유연하게 가져갈 필요가 있다.

예를들어 보자.

재작업시 Kinesis 에서 14:00:00 KST 부터 소비 (Window 가 없다고 가정)

State 는 리셋 후 다시 14:00:00 부터 집계

최종 Output 도 14:00:00 부터 리셋 (값이 작아짐)

서빙 레이어가 API 라면 복구까지 캐싱된 결과를 서빙

Application State 를 복구의 기준으로 삼으면 항상 실패한 시점을 찾고 (14:35:17.401 KST) 그 시점부터 복구해야만 한다.
Application State 를 Source of Truth 로 다루게 되면

Application State 가 깨지면?, Application State 모델 변경이 일어나면?, Application State 디버깅은? (현재 값 확인) 등의 이슈가 있다.

19. ‘데이터 조회’ 국면에서 SQL

데이터를 조회할 수 있는 툴과 언어는 종류가 많다. 예를들면 Zeppelin, Redash, Tableau, Jupyter, …Excel 등등

사용자에 따라 데이터 관련 지식의 수준이 천차만별

1) Spark 로 통계 데이터를 적재하는 엔지니어

2) R 이나 Python 으로 다음달 예약 고객을 예측하는 분석가

3) SQL 로 푸시 타게팅 사용자를 뽑아내는 마케터

4) Excel 에 익숙한 영업 조직

5) 버튼을 눌러 기간별로 정산 데이터를 뽑아내는 운영자

6) 리포트 형태로 보고서를 받는 Top Team

모든 조건을 만족시키는 단 하나의 툴은 존재하지 않기 때문에 다양한 도구를 제공하되 조회를 위한 범용 언어를 선택해야 한다.

대표적인 것이 데이터 세계에서 SQL (= 지구촌 공용어 영어)이다.

지속적인 사내 가이드가 필요 “이 데이터는 여기 있어요”, “쿼리 샘플” 등등

데이터는 이미 S3 에 적재되어 있으니 EMR Presto 를 이용해 컴퓨팅 가능하다.

20. ‘데이터 조회’ 국면에서 프레스토

프레스토(Presto)는 페이스북이 개발한 빅 데이터 분석도구로, 분산된 SQL 쿼리 엔진이다. 기존 분석도구인 하이브/맵리듀스에 비해 CPU 효율성과 대기 시간이 10배 빠르다.
‘최소 비용으로 효율적인 컴퓨팅 인프라를 구축’하자는 오픈컴퓨트 프로젝트의 일부로, 2013년 11월 7일 아파치 라이선스로 공개되었다.
Facebook 제작, Uber, Twitter, Alibaba, Netflix 등 Production 사용
EMR 에서 지원 (별도의 설치 필요 X), Audit 플러그인 존재
상당히 빠른편이다.
다양한 커넥터 지원 (JDBC, ES, Redis, Cassandra, HBase, Mongo 등)
강력한 쿼리 파워 JSON, Geospatial, Aggregation 함수지원
HTTP 프로토콜 지원 (Node.js, …)
UI 제공 (Kill Query, Cluster Status 등)
읽을거리

1) Presto Summit 2019 Slides

https://github.com/prestodb/presto/wiki/Presto-Summit-2019

2) Presto Summit 2018 Slides

https://www.starburstdata.com/technical-blog/presto-summit-2018-recap/

20. ‘데이터 조회’ 국면에서 탐색 툴들

Redash, Zeppelin, Jupyter, Tableau 를 주된 탐색 도구로 이용한다.

1) Zeppelin (EMR Zeppelin 이 아니라 별도 운영)

빠른 탐색 및 차팅 (Charting) 용도
수만개 이상의 Rows Visualization 또는 대용량 다운로드엔 부적합
보안 이슈로 인해 SQL (Presto) 인터프리터만 제공

2) Redash

대시보드 및 시뮬레이션 (인기상품, 기간 또는 가중치 변경 등 쿼리 파라미터 지원)
대용량 CSV 다운로드 지원 (수십, 수백만 Rows 이상)
Alert (특정 조건 하에 Slack 등으로 Noti)
각종 커넥터 지원 (Presto, JDBC, Mongo, ES, Redis, Dynamo, Druid, BigQuery 등)

3) Jupyter (EMR Jupyter 가 아니라 별도 운영)

개인별 분석 환경 (3 CPU, 6 GiB 컨테이너) on AWS EKS
Python, R, Julia, Tensorflow, PySpark, Scala (Almond) 등 이미지 제공 (jupyter/docker-stack)
추후 Spark on Kubernetes 를 통해 Cluster 컴퓨팅 지원 계획이 있다고 한다.

4) Tableau: 전사 공용 지표, 영업 관련 데이터 등 (데이터 분석팀이 별도 운영)

21. ‘데이터 조회’ 국면에서 Redash란

1) 개요

오픈소스, AirBNB 의 SuperSet 과 비슷한 범용 대시보드
대시보드 및 시뮬레이션 (인기상품, 기간 또는 가중치 변경 등 쿼리 파라미터 지원)
대용량 CSV 다운로드 지원 (수십, 수백만 Rows+)
스케쥴링 지원 (매일, 특정 시간 등)
Alert (특정 조건 하에 Slack 등으로 Noti)기능 지원
각종 커넥터 지원 (Presto, JDBC, Mongo, ES, Redis, Dynamo, Druid, BigQuery 등)

2) 사용 용도

데이터 프로덕트 Prototype (HTML 이미지 렌더링 가능)
간단한 마케팅 운영 툴로 활용
내부 시스템 로그 조회용 (CloudTrail, ELB 등)

21. ‘데이터 서비스’ 국면

다음과 데이터를 이용해서 다양한 것을 할 수 있다.

개인화 추천
개인화 푸시 (리타게팅)
A/B, MAB 등 실험 플랫폼
가격 조절 (AirBNB 의 Smart Pricing)
공급 조절
기타 데이터로 할 수 있는 모든 것 (B2B, B2C)

 What is a Data Engineer and What Do They Do in Data Science 칼럼요약 프로야구팀 시즌승률 예측을 위한 선형회귀모델 구현결과 