YSY의 데이터분석 블로그

모델 빌딩과 관련된 문제들 트레이닝 셋의 관리가 안됨 모델 훈련 방법이 기록이 안됨 어떤 트레이닝 셋을 사용했는지? 어떤 피쳐들을 사용했는지? 하이퍼 파라미터는 무엇을 사용했는지? 모델 훈련에 많은 시간 소요 모델 훈련이 자동화가 안된 경우 매번 각 스텝들을 노트북 등에서 일일히 수행 에러가 발생할 여지가 많음 (특정 스텝을 까먹거나 조금 다른 방식 적용) ML Pipeline 데이터 과학자가 머신러닝 개발과 테스트를 쉽게 해주는 기능 (데이터 프레임 기반) 머신러닝 알고리즘에 관계없이 일관된 형태의 API를 사용하여 모델링이 가능 ML 모델개발과 테스트를 반복가능해줌 4개 요소로 구성 : DataFrame,Transformer, Estimator, Parameter 모델 훈련 방법이 기록이 안되는 문제..

피쳐 추출과 변환 피쳐 값들을 모델 훈련에 적합한 형태로 바꾸는 것을 지칭 파이썬과 다르게 각각의 feature를 모델에 넣는 것이 아닌 feature를 하나의 vector로 묶어서 모델에 넣음 크게 두 가지가 존재: Feature Extractor와 Feature Transformer Feature Transformer https://spark.apache.org/docs/latest/ml-features.html#feature-transformers 피쳐 값들은 숫자 필드이어야함 텍스트 필드(카테고리 값들)를 숫자 필드로 변환해야함 숫자 필드 값의 범위 표준화 숫자 필드라고 해도 가능한 값의 범위를 특정 범위(0부터 1)로 변환해야 함 이를 피쳐 스케일링 (Feature Scaling) 혹은 정규화 ..

타이타닉 승객 생존 예측 다운로드 링크 : https://www.kaggle.com/c/titanic 생존 혹은 비생존을 예측하는 것이라 Binary Classification을 사용 (2개 클래스 분류기) Logistic Regression 사용 AUC (Area Under the Curve)의 값이 중요한 성능 지표가 됨 ▪ True Positive Rate과 False Positive Rate True Positive Rate: 생존한 경우를 얼마나 맞게 예측했나? 흔히 Recall이라고 부르기도함 False Positive Rate: 생존하지 못한 경우를 생존한다고 얼마나 예측했나? 총 892개의 레코드로 구성되며 11개의 피쳐와 레이블 필드(생존여부) 로 구성 2번째 필드(Survived) 바로..

보스턴 주택가격 예측 1970년대 미국 인구조사 서비스 (US Census Service)에서 보스턴 지역의 주택 가격 데이터를 수집한 데이터를 기반으로 모델 빌딩 해당 링크에서 다운로드 : https://www.kaggle.com/datasets/vikrishnan/boston-house-prices 개별 주택가격의 예측이 아니라 지역별 중간 주택가격 예측임 Regression 알고리즘 사용 예정 연속적인 주택가격을 예측이기에 Classification 알고리즘은 사용불가 총 506개의 레코드로 구성되며 13개의 피쳐와 레이블 필드(주택가격) 로 구성 506개 동네의 주택 중간값 데이터임 (개별 주택이 아님에 유의) 14번째 필드가 바로 예측해야하는 중간 주택 가격 Python OLS 회귀분석은 아래 ..

Spark ML 이란 머신러닝 관련 다양한 알고리즘, 유틸리티로 구성된 라이브러리 Classification, Regression, Clustering, Collaborative Filtering, Dimensionality Reduction. https://spark.apache.org/docs/latest/ml-classification-regression.html 아직 딥러닝은 지원은 아직 미약 여기에는 RDD 기반과 데이터프레임 기반의 두 버전이 존재 spark.mllib vs. spark.ml spark.mllib가 RDD 기반이고 spark.ml은 데이터프레임 기반 spark.mllib는 RDD위에서 동작하는 이전 라이브러리로 더 이상 업데이트가 안됨 항상 spark.ml을 사용할 것! imp..

Bucketing과 File System Partitioning 둘다 Hive 메타스토어의 사용이 필요: saveAsTable 데이터 저장을 이후 반복처리에 최적화된 방법으로 하는 것 Bucketing DataFrame을 특정 ID를 기준으로 나눠서 테이블로 저장 먼저 Aggregation 함수나 Window 함수나 JOIN에서 많이 사용되는 컬럼이 있는지 확인 있다면 데이터를 이 특정 컬럼(들)을 기준으로 테이블로 저장 다음부터는 이를 로딩하여 사용함으로써 반복 처리시 시간 단축 DataFrameWriter의 bucketBy 함수 사용 Bucket의 수(첫번째 인자)와 기준 ID 지정(두번째 인자) 데이터의 특성을 잘 알고 있는 경우 사용 가능 (그 특성을 이용하여 최적화) CF) https://tow..

Transformations and Actions 예시코드 spark.read.option("header", True).csv(“test.csv”). \ where("gender 'F'"). \ select("name", "gender"). \ groupby("gender"). \ count(). \ show() Transformation 위 코드에서 WHERE, SELECT, GROUPBY, COUNT에 해당됨 Narrow Dependencies: 독립적인 Partition level 작업 select, filter, map, where, count 등등 Wide Dependencies: Shuffling이 필요한 작업 groupby, reduceby, partitionby, repartition 등등..

Schema Evolution 데이터가 쌓이고 난 이후에 변경되었을때(이전 스키마 버전으로 데이터가 쌓여있고 스키마가 변경되었을때) 어떻게 데이터를 저장하는지에 대한 메커니즘 용어 아래 같은 경우 schema마다 컬럼이 다른데 이를 parquet파일에서 어떻게 처리하는지 알아본다. 1. SparkSession 생성 from pyspark.sql import * from pyspark.sql.functions import * if __name__ == "__main__": spark = SparkSession \ .builder \ .appName("Spark Schema Evolution Demo") \ .master("local[3]") \ .getOrCreate() 데이터 호출 df1 = spark...