Miner

A/B 테스트 = 실험 (Split Test or Bucket Test) (색깔에 따라 ...) 다수의 Varient 로 구성됨 - 하나의 컨트롤(기존 버전) 과 하나 혹은 그 이상의 테스트 A/B Test 객관적으로 새로운 기능이나 변경을 측정/비교하는 방식 큰 위험없이 새로운 기능을 테스트하고 빠르게 배우는 방법 실제 유저(1%, 5% ...점점 늘려가보고) 에게 노출해보고 결정한다. 가설 없는 A/B Test는 불가 A/B Test는 기본적으로 가설을 실험하고 검증하는 것 예1) 새로운 추천방식이 기존의 추천방식보다 매출을 증대시키는가? 어떤 지표에서 어느 정도의 임팩트가 예상되는가? 가설을 나중에 결과에 비교하면서 생각지 못했던 다양한 배움이 생김 예2) 상품 체크아웃 페이지의 스텝을 줄이면 결제..

spark 3.0, PySpark 사용, Spark 프로그램을 Yarn 위에서 돌릴 때 Spark 프로그램 실행 환경 개발/테스트/학습 환경 (Interactive Clients) : 노트북(주피터, 제플린), Spark Shell 프로덕션 환경 spark-submit (command-line utility) : 가장 많이 사용됨 데이터브릭스 노트북 : 노트북 코드를 주기적으로 실행해주는 것이 가능 REST API Spark Standalone 모드에서만 가능 API를 통해 Spark 잡을 실행 실행코드는 미리 HDFS등의 파일 시스템에 적재되어 있어야 함 Spark 프로그램의 구조 Driver 실행되는 코드의 마스터 역할 수행 (Yarn의 Application Master) Executor 실제 태스크..

Spark 데이터 시스템 사용 예들 기본적으로 대용량 데이터 배치 처리, 스트림 처리, 모델 빌딩 1) 대용량 비구조화된 데이터 처리하기 (ETL / ELT) 2) ML 모델에 사용되는 대용량 피쳐 처리 (배치 / 스트림) 3) Spark ML을 이용한 대용량 훈련 데이터 모델 학습 예시 1) 대용량 비구조화된 데이터 처리하기 (Hive의 대체 기술) ETL 혹은 ELT 예시 2) ML 모델에 사용되는 대용량 피쳐 처리

Hadoop = 1세대 빅데이터 처리 기술 Spark = 2세대 빅데이터 처리 기술 Yarn 등을 분산환경 / 컨테이너 위에서 가능 / Scala 로 작성됨 Spark 3.0 구성 Spark Core, SQL, ML, MLib, Streaming, GraphX Spark vs MapReduce Spark은 기본적으로 메모리 기반 메모리가 부족해지면 디스크 사용 MapReduce는 디스크 기반 MapReduce는 하둡(Yarn)위에서만 동작 Spark은 하둡(Yarn)이외에도 다른 분산 컴퓨팅 환경 지원(K8s, Mesos) MapReduce는 키와 밸류 기반 데이터 구조만 지원 Spark은 판다스 데이터프레임과 개념적으로 동일한 데이터 구조 지원 Spark은 다양한 방식의 컴퓨팅을 지원 배치 데이터 처리..

딥러닝 대량의 데이터로부터 학습하는 머신러닝의 한 종류 인간의 두뇌에서 영감을 받은 알고리즘인 인공 신경망의 다른 이름 이미지 및 음성 인식, 자연어 처리에 엄청난 혁신을 가진다 기존 머신 러닝 : Features를 직접 만들어야 함 딥러닝 : Features를 알아서 배워가는 형태에 가까움 이는 이미지, 오디오, 자연어 프로세싱의 경우 더더욱 두드러진다. MNIST "Hello World" of 딥러닝 숫자 인식기(0-9) ImageNet 퍼셉트론(뉴런) | 다수의 신호를 입력으로 받아 하나의 신호를 출력 동작 방식 : 활성함수 | 입력노드의 가중치와 입력치를 곱한 것을 모두 합한 값을 입력으로 받아 임계치 기준으로 출력값 결정 보통 임계치 0을 사용 / 최종합이 0보다 크면 퍼셉트론이 활성화 된다. ..

사용할 데이터 웨어하우스 Redshift dc2.large 2 CPU, 15GB memory, 160GB SSD Host : learnde.cduaw970ssvt.ap-northeast-2.redshift.amazonaws.com Port : 5439 Database : dev ID 와 PW

데이터 파이프라인 만들 때 유의점 이상 / 환상 내가 만든 데이터 파이프라인은 문제 없이 동작하고 관리하는 것은 어렵지 않을 것이다. 현실 / 실상 데이터 파이프라인은 많은 이유로 실패하게 된다 버그 / 데이터 소스상의 이유 / 데이터 파이프라인들간의 의존도에 이해도 부족 / 데이터 파이프라인의 수가 늘어나면 유지보수 비용이 기하급수적으로 늘어남 / 데이터 소스간의 의존도가 생기면서 이는 더 복잡해짐. 만일 마케팅 채녈 정보가 업데이트가 안된다면 마케팅 관련 다른 모든 정보들이 갱신되지 않음 Best Practices (1) 가능하면 데이터가 작을 경우 매번 통채로 복사해서 테이블을 만들기 (Full Refresh) Incremental update만이 가능하다면, 대상 데이터소스가 갖춰야할 몇 가지 조..