Big Data: 데이터팀 역할
- 데이터 팀의 역할과 구성원은 누구인가?
- 데이터 팀 조직 구조
- 모델 개발시 고려할 점
- 데이터 일 관련 교훈
데이터 팀의 역할
데이터 팀은 어떤 역할을 수행하는가?
- 데이터 팀의 미션: 신뢰할 수 있는 데이터를 바탕으로 부가가치 생성
- 내가 하는 일이 회사에 어떤 식으로 도움이 될지 계속 또 생각 생각 해볼것
- 데이터 팀의 목표1
- 고품질의 데이터를 제공하여 정책 결정에 사용
- 결정 과학(Decision Science)라고 부르기도 함
- 데이터 참고 결정(data informed decisions)을 가능하게 함
- vs 데이터 기반 결정(data driven decisions)
- 데이터 팀의 목표2
- 고품질의 데이터를 필요할 때 제공하여 사용자의 서비스 경험 개선
- 머신 러닝과 같은 데이터 기반 알고리즘을 통해 개선
- 예) 개인화를 바탕으로한 추천(Recommendation)과 검색 기능 제공
- 하지만 사람의 개입/도움이 반드시 필요(human-in-the-loop)
- 머신 러닝과 같은 데이터 기반 알고리즘을 통해 개선
- 고품질의 데이터를 필요할 때 제공하여 사용자의 서비스 경험 개선
- 데이터 팀의 발전 - 1.데이터 인프라 구축
- 데이터 인프라: 데이터 웨어하우스와 ETL(Extract, Transform, Load)
- 데이터 웨어하우스: 회사에 필요한 모든 데이터들을 저장하는 중앙 데이터베이스
- ETL(Extract, Transform, Load): 소스에 존재하는 데이터들을 데이터 웨어하우스로 복사해오는 코드를 지칭. 보통 파이썬으로 작성
- 데이터 인프라의 구축은 데이터 엔지니어가 수행함
- 데이터 인프라: 데이터 웨어하우스와 ETL(Extract, Transform, Load)
- 데이터웨어하우스란?
- 회사에 필요한 모든 데이터를 모아놓은 중앙 데이터베이스(SQL)
- 데이터 크기에 맞게 어떤 데이터베이스를 사용할지 선택
- 크기가 커진다면 AWS의 Redshift, 구글 클라우드의 BigQuery, 스노우플레이크(Snowflake)나 오픈소스 기반의 하둡/스팍을 사용하는 것을 추천: 모두 SQL 지원
- 중요 포인트는 프로덕션용 데이터베이스와 별개의 데이터베이스라는 점
- 데이터 웨어하우스 구축은 진정한 데이터 조직이 되는 첫번째 스텝
- 회사에 필요한 모든 데이터를 모아놓은 중앙 데이터베이스(SQL)
- ETL(Extract, Transfrom, Load)이란?
- 다른 곳에 존재하는 데이터를 가져다가 데이터 웨어하우스에 로드하는 작업
- Extract: 외부 데이터 소스에서 데이터를 추출
- Transform: 데이터의 포맷을 원하는 형태로 변환
- Load: 변환된 데이터를 최종적으로 데이터 웨어하우스로 적재
- 이는 코딩을 필요로 하며 가장 많이 쓰이는 프레임웍은 Airflow
- Airflow는 오픈소스 프로젝트로 파이썬3 기반
- 에어비엔비, 우버, 리프트, 쿠팡 등에서 사용
- AWS와 구글클라우드에서도 지원
- 흔한 데이터 소스의 경우 SaaS(Software as a Service) 사용 가능
- FiveTran, Stitch Data, ....
- Airflow는 오픈소스 프로젝트로 파이썬3 기반
- 다른 곳에 존재하는 데이터를 가져다가 데이터 웨어하우스에 로드하는 작업
- 데이터 팀의 발전 - 2.데이터 분석 수행
- 데이터 분석이란?
- 회사와 팀별 중요 지표(metrics)를 정의하고 대시보드 형태로 시각화(visualization)
- 이외에도 데이터와 관련한 다양한 분석/리포팅 업무 수행
- 중요 지표의 예: 매출액, 월간/주간 액티브 사용자수,...
- 이는 데이터 분석가(Data Analyst)가 맡는 일임
- 데이터 분석이란?
- 시각화 대시보드란?
- 보통 중요한 지표를 시간의 흐름과 함께 보여주는 것이 일반적
- 지표의 경우 3A(Acessible, Actionable, Auditable)가 중요
- 가장 널리 사용되는 대시보드:
- 구글 클라우드의 룩커(Looker)
- 세일즈포스의 태블로(Tableau)
- 마이크로소프트의 파워 BI(Power BI)
- 오픈소스 아파치 수퍼셋(Superset)
- 보통 중요한 지표를 시간의 흐름과 함께 보여주는 것이 일반적
- 데이터 팀의 발전 - 3. 머신러닝/인공지능 적용
- 서비스에서 직접 생기는 데이터와 써드파티를 통해 생기는 데이터
- 데이터 인프라에 저장된 데이터를 기반(훈련용 데이터)으로 지도기계학습(supervised machine learning)을 통해 머신러닝 모델들을 개발하여 추천, 검색등을 개인화하는 것이 일반적인 패턴
- 이때 데이터의 크기에 따라 대용량 분산처리 시스템이 필요할수도 있음
데이터 팀의 구성원
데이터 팀을 구성하는 사람들은 누구인가?
- 데이터 엔지니어(Data Engineer)
- 데이터 인프라 (데이터 웨어하우스와 ETL) 구축
- 데이터 분석가(Data Analyst)
- 데이터 웨어하우스의 데이터를 기반으로 지표를 만들고 시각화(대시보드)
- 내부 직원들의 데이터 관련 질문 응답
- 데이터 과학자(Data Scientist)
- 과거 데이터를 기반으로 미래를 예측하는 머신러닝 모델을 만들어 고객들의 서비스 경험을 개선(개인화 혹은 자동화 혹은 최적화)
- 작은 회사에서는 한 사람이 몇개의 역할을 동시에 수행하기도 함
- 데이터 엔지니어의 역할
- 기본적으로는 소프트웨어 엔지니어
- 파이썬이 대세. 자바 혹은 스칼라와 같은 언어도 아는 것이 좋음
- 데이터 웨어하우스 구축
- 데이터 웨어하우스를 만들고 이를 관리. 클라우드로 가는 것이 추세
- AWS의 Redshift, 구글클라우드의 BigQuery, 스노우 플레이크
- 관련해서 중요한 작업중의 하나는 ETL 코드를 작성하고 주기적으로 실행해주는 것
- ETL 스케줄러 혹은 프레임웍이 필요(Airflow라는 오픈소스가 대세)
- 데이터 웨어하우스를 만들고 이를 관리. 클라우드로 가는 것이 추세
- 데이터 분석가와 과학자 지원
- 데이터 분석가, 데이터 과학자들과의 협업을 통해 필요한 툴이나 데이터를 제공해주는 것이 데이터 엔지니어의 중요한 역할 중의 하나
- 기본적으로는 소프트웨어 엔지니어
- 데이터 분석가의 역할
- 비즈니스 인텔리전스를 책임짐
- 중요 지표를 정의하고 이를 대시보드 형태로 시각화
- 대시보드는 태블로(Tableau)와 룩커(Looker)등의 툴이 가장 흔히 사용됨
- 오픈소스로는 수퍼셋(Superset)이 많이 사용됨
- 이런 일을 수행하려면 비즈니스 도메인에 대한 깊은 지식이 필요
- 중요 지표를 정의하고 이를 대시보드 형태로 시각화
- 회사내 다른 팀들의 데이터 관련 질문 대답
- 임원들이나 팀 리드들이 데이터 기반 결정을 내릴 수 있도록 도와줌
- 질문들이 굉장히 많고 반복적이기에 어떻게 셀프서비스로 만들 수 있느냐가 관건
- 필요한 스킬셋
- SQL, 통계적 지식
- 비즈니스 도메인에 관한 깊은 지식
- 보통 코딩을 하지는 않음
- 비즈니스 인텔리전스를 책임짐
- 데이터 분석가의 딜레마
- 보통 많은 수의 긴급한 데이터 관련 질문들에 시달림
- 많은 경우 현업팀에 소속되기도 함
- 내 커리어에서 다음은 무엇인가?
- 소속감이 불분명하고 내 고과 기준이 불명확해짐
- 데이터 분석가의 경우 조직구조가 더 중요함
- 데이터 과학자의 역할
- 머신러닝의 형태로 사용자들의 경험을 개선
- 문제에 맞춰 가설을 세우고 데이터를 수집한 후에 예측 모델을 만들고 이를 테스트
- 장시간이 필요하지만 이를 짧은 사이클로 단순하게 시작해서 고도화하는 것이 좋음
- 테스트는 가능하면 A/B 테스트를 수행하는 것이 좋음
- 문제에 맞춰 가설을 세우고 데이터를 수집한 후에 예측 모델을 만들고 이를 테스트
- 데이터 과학자에게 필요한 스킬셋
- 머신러닝/인공지능에 대한 깊은 지식과 경험
- 코딩 능력(파이썬과 SQL)
- 통계 지식, 수학 지식
- 끈기와 열정, 박사 학위가 도움이 되는 이유 중의 하나
- 머신러닝의 형태로 사용자들의 경험을 개선
- 훌륭한 데이터 과학자란?
- 열정과 끈기 +
- 다양한 경험 +
- 코딩 능력 +
- 현실적인 접근 방법 +
- 애자일 기반의 모델링
- 딥러닝이 모든 문제의 해답은 아님을 명심
- 과학적 접근 방법
- 지표기반 접근
- 내가 만드는 모델의 목표는 무엇이고 그걸 어떻게 측정할 것인가?
- 제일 중요한 것은 모델링을 위한 데이터의 존재 여부
- 머신러닝 모델 싸이클
- 폭포수 개발방법론 vs 애자일 개발방법론
- A/B 테스트란? - (1)
- 온라인 서비스에서 새 기능의 임팩트를 객관적으로 측정하는 방법
- 의료쪽에서 무작위 대조 시험(Randomized Controlled Trial)
- 새로운 기능을 론치함으로 생기는 위험부담을 줄이는 방법
- 100%의 사용자에게 론치하는 것이 아니라 작게 시작하고 관찰 후 결정
- 실제 예제: 추천을 기계학습기반으로 바꾼 경우
- 먼저 5%의 사용자에게만 론치하고 나머지 95%의 사용자와 매출액 같은 중요 지표를 가지고 비교
- 5%의 대상으로 별문제 없으면 10%, 20% 이런 식으로 점진적으로 키우고 최종적으로 100%로 론치
- 보통 사용자들을 2개의 그룹으로 나누고 시간을 두고 관련 지표를 비교
- 한 그룹은 기존 기능을 그대로 노출(control)
- 다른 그룹은 새로운 기능에 노출(test)
- 가설과 영향받는 지표를 미리 정하고 시작하는 것이 일반적
- 지표의 경우 성공/실패 기준까지 생각해보는 것이 필요
- 온라인 서비스에서 새 기능의 임팩트를 객관적으로 측정하는 방법
데이터 팀의 조직 구조
현업에서 데이터 팀은 어떻게 다른 팀들과 협업하는가?
- 중앙 집중 구조: 모든 데이터 팀원들이 하나의 팀으로 존재
- 일의 우선 순위는 중앙 데이터팀이 최종 결정
- 데이터 팀원들간의 지식과 경험의 공유가 쉬워지고 커리어 경로가 더 잘 보임
- 하지만 현업부서들의 만족도는 상대적으로 떨어짐
- 분산 구조: 데이터 팀이 현업 부서별로 존재
- 일의 우선 순위는 각 팀별로 결정
- 데이터 일을 하는 사람들간의 지식/경험의 공유가 힘들고 데이터 인프라나 데이터 공유가 힘들어짐
- 현업부서들의 만족도는 처음에는 좋지만 많은 수의 데이터 팀원들이 회사를 그만두게 됨
- 중앙 집중과 분산의 하이브리드 모델
- 가장 이상적인 조직 구조
- 데이터 팀원들은 일부는 중앙에서 인프라적인 일을 수행하고 일부는 현업팀으로 파견식으로 일하되 주기적으로 일을 변경
- 데이터팀 안에서 커리어 경로가 만들어짐
모델 개발시 고려할 점(⭐)
현업에서 모델 개발시 알아야할 점들은?
- 모델 개발시 데이터 과학자들의 일반적인 생각
- 데이터 과학자: 아주 좋은 머신러닝 모델을 만들고 말겠어!
- 엔지니어: 모델 만들고 나서 다음 스텝은 뭐야?
- 데이터 과학자: ??
- 모델 개발시 엔지니어들의 일반적인 생각
- 엔지니어: 머신러닝 모델을 어떻게 론치하지? 아몰랑(시간이 지난후)
- 데이터 과학자: 모델 잘 론치되었어?
- 엔지니어: 아마도
- 마찰이 생기는 지점 - 개발된 모델의 이양 관련
- 많은 수의 데이터 과학자들은 R을 비롯한 다양한 툴로 모델 개발
- 하지만 실제 프로덕션 환경은 다양한 모델들을 지원하지 못함
- 개발/검증된 모델의 프로덕션 환경 론치시 시간이 걸리고 오류 가능성이 존재
- 심한 경우 모델 관련 개발을 다시 해야함( 피쳐 계산과 모델 실행 관련)
- 모델 개발시 꼭 기억할 포인트(1)
- 누군가 모델 개발부터 최종 론치까지 책임질 사람이 필요
- 모델 개발은 시작일 뿐이고 성공적인 프로덕션 론치가 최종적인 목표
- 이 일에 참여하는 사람들이 같이 크레딧을 받아야 협업이 더 쉬워짐
- 최종 론치하는 엔지니어들과 소통하는 것이 중요
- 모델 개발 초기부터 개발/론치 과정을 구체화하고 소통
- 모델 개발시 모델을 어떻게 검증할 것인지?
- 모델을 어떤 형태로 엔지니어들에게 넘길 것인지??
- 피처 계산을 어떻게 하는지? 모델 자체는 어떤 포맷인지?
- 모델을 프로덕션에서 A/B 테스트할 것인지?
- 한다면 최종 성공판단 지표가 무엇인지?
- 누군가 모델 개발부터 최종 론치까지 책임질 사람이 필요
- 모델 개발시 꼭 기억할 포인트(2)
- 개발된 모델이 바로 프로덕션에 론치가능한 프로세스/프레임웍이 필요
- 예를 들어 R로 개발된 모델은 프로덕션 론치가 불가능
- 트위터: 데이터 과학자들에게 특정 파이썬 라이브러리로 모델개발 정책화
- 툴을 하나로 통일하면 제반 개발과 론치 관련 프레임웍 개발이 쉬워짐
- AWS의 SageMaker: 머신러닝 모델개발, 검증, 론치 프레임웍
- 검증된 모델을 버튼 클릭 하나로 API 형태로 론치 가능!
- Google Cloud와 Azure도 비슷한 프레임웍 지원
- 개발된 모델이 바로 프로덕션에 론치가능한 프로세스/프레임웍이 필요
- 모델 개발시 꼭 기억할 포인트(3)
- 첫 모델 론치는 시작일 뿐
- 론치가 아닌 운영을 통해 점진적인 개선을 이뤄내는 것이 중요
- 데이터 과학자의 경우 모델 개발하고 끝이 아니라는 점 명심!
- 결국 피드백 루프가 필요
- 운영에서 생기는 데이터를 가지고 개선점 찾기
- 검색이라면 CTR(Click Trough Rate)을 모니터링하고 모든 데이터를 기록
- 주기적으로 모델을 재빌딩
- 온라인 러닝: 모델이 프로덕션에서 사용되면서 계속적으로 업데이트되는 방식의 머신러닝
- 리얼타임 머신러닝
- 온라인 러닝: 모델이 프로덕션에서 사용되면서 계속적으로 업데이트되는 방식의 머신러닝
- 운영에서 생기는 데이터를 가지고 개선점 찾기
- 첫 모델 론치는 시작일 뿐
데이터 관련 교훈
데이터 관련해서 꼭 기억해야할 점들을 공유한다
- 데이터를 통해 매출이 생겨야 한다
- 어느 조직이건 회사에서의 존재 이유는 매출 창조 혹은 경비 절감
- 데이터 인프라와 데이터 팀원(데이터 과학자)의 몸값은 상대적으로 높음
- 직접적이건 간접적이건 데이터를 통해 회사 수익에 긍정적인 영향을 끼쳐야함
- 데이터 조직의 수장의 역할이 아주 중요
- 위와 옆으로 잘 매니지를 해야함
- 다시 한번 데이터 인프라의 구성이 첫 번째라는 점을 명심하되 단기적으로 좋은 결과를 낼 방법을 찾아야함
- 어느 조직이건 회사에서의 존재 이유는 매출 창조 혹은 경비 절감
- 데이터 인프라가 첫 번째 스텝! -> 애초부터 쓰레기를 쌓지 않으려면 어떻게 해야되지?
- 데이터 인프라 없이는 데이터 분석이나 모델링은 불가능
- 하지만 아주 작은 회사에서 생존이 더 중요한 문제라 데이터 인프라는 조금더 성장한 뒤에 걱정해도 됨
- 첫번째 팀원은 인프라 구축 이외에도 약간의 분석/모델링 스킬이 있는 사람이 최적
- 고려점
- 클라우드 vs 직접 구성
- 배치 vs 실시간
- 데이터 인프라 없이는 데이터 분석이나 모델링은 불가능
- 데이터 품질이 아주 중요
- Garbage In Garbage Out
- 데이터 과학자가 가장 많은 시간을 쏟는 분야는?
- 데이터 청소 작업!
- 모델링에 드는 시간을 100이라고 하면 그중 70은 데이터 클린업에 들어감
- 중요 데이터의 경우 좀더 품질 유지에 노력이 필요
- 어디에 데이터가 있는지?
- 이 데이터의 품질에 혹시 문제가 있는지 계속적으로 모니터링
- If you are not thinking about how to keep you your data clean from the very beginning, you are fucked. I guranteee it.
- 항상 지표부터 생각
- 무슨 일을 하건 그 일의 성공 척도(지표)를 처음부터 생각
- 또한 나름대로 가설을 세우는 것이 인사이트를 키우는데 큰 도움이 됨
- 지표의 계산에 있어서 객관성이 중요
- 계산된 지표를 아무도 못 믿는다면 큰 문제
- 지표를 어떻게 계산할 것인지 그리고 이걸 다른 사람들에게 어떻게 설명할지 고려
- 무슨 일을 하건 그 일의 성공 척도(지표)를 처음부터 생각
- 가능하면 간단한 솔루션으로 시작
- 모든 문제를 딥러닝으로 해결해야 하나?
- IF문 몇개의 간단한 논리로 해결할 수 있는지부터 고민!
- 실제 회사에서 딥러닝으로 문제를 해결하는 경우는 드뭄. 왜 동작하는지 설명도 힘들고 개발과 론치 모두 시간이 걸림
- 반복 기반의 점진적인 개발방식 vs 한 큐에 모델 만들기
- 후자는 시간만 오래 걸리고 최종 성과는 안 좋을 확률이 높음
- 전자로 가면서 원하는 결과가 나오면 그 때 중단. 더 개선할 필요 없음
- 모든 문제를 딥러닝으로 해결해야 하나?
- 요약
- 데이터 팀의 목표는 신뢰할 수 있는 데이터를 바탕으로 부가가치 생성
- 데이터 직군에는 엔지니어, 분석가, 과학자 이렇게 세 종류가 존재
- 데이터 팀 조직 구조에는 중앙집중, 분산, 하이브리드의 세 종류가 존재
- 모델 개발은 론치와 운영에 초점을 맞춰야 함
- 데이터 팀의 존재 여부는 여타 팀과 마찬가지로 수익 증대라는 점 명심
- 단순한 솔루션이 제일 좋은 솔루션(모든 문제에 딥러닝을 쓰지는 말자)
- 마찰이 생기는 지점 - 개발된 모델의 이양 관련
- 많은 수의 데이터 과학자들은 R을 비롯한 다양한 툴로 모델 개발
- 하지만 실제 프로덕션 환경은 다양한 모델들을 지원하지 못함
- 개발/검증된 모델의 프로덕션 환경 론치시 시간이 걸리고 오류 가능성이 존재
- 심한 경우 모델 관련 개발을 다시 해야함(피쳐 계산과 모델 실행 관련)
커리어 이야기(끊임없는 배움)
- 가장 많이 들은 질문들
- 요즘은 무엇이 뜨나요?
- 미래를 대비하려면 무엇을 준비해야 할까요?
- 커리어가 고착된 것 같습니다. 무엇을 해야할지 모르겠습니다.
- 선행학습, 불안감, 전문성
- 호기심 때문에 시작된 선행학습은 좋은것 같다(나도 동의, 불안감은 노노)
- 어디서 시작했느냐가 중요하다기보단, 일단 시작했다는게 중요한것 같다. 어디서든 시작을 한 후 점진적으로 발전하면된다. 내 인생은 이제 시작이다. 조급해하지 말자. 인생 길다.
- 늦게 배운다고해서 못하는건 아니다.
- 실리콘밸리에서 관찰한 커리어 단절
- Returnship이라는 제도가 있다고 한다.
- 세 종류의 경력단절
- 결혼과 육아와 이주로 인한 경력의 단절
- 대학 졸업 후 마땅한 잡을 찾지 못해서 생기는 경력의 공백
- 가진 기술이 시장에서 경쟁력을 잃으면서 생기는 경력의 단절
- 공통점
- 자신감의 상실 - 남과의 비교
- 연속된 작은 성공으로 자신감을 키워보자
- Support Network/Community의 부재
- 재교육의 필요성
- 자신감의 상실 - 남과의 비교
- 취직 준비 방법
- 닥치는대로 이력서 내고 닥치는대로 인터뷰하기
- Job Description 보고 나는 부족한 것이 많네 하고 안 쫄기
- 99번 실패해도 하나만 잡으면 된다는 패기
- 실패에 상처받지 않기
- 어디건 시작해서 발전해 나가면 됨
- 남들과 비교하지 않기
- "시작은 미약하나 그 끝은 창대하리라"
- 회사의 이름보다는 같이 일하는 사람들이 더 중요
- 닥치는대로 이력서 내고 닥치는대로 인터뷰하기
- 커리어 변화 타이밍
- 지난 일주일 혹은 한달 혹은 일년 동안 무엇을 배웠는가?
- 하고 싶던 일이나 재미있어 보이는 일을 해볼 기회가 온다면?
- Regret Minimization Framework
- One way vs Two way
- Things to Remember
- 배움은 항상 중요(Never stop Learning)
- 안 해본 것 해보기. 싫어하던 것 한번 더 해보기
- One way door vs Two way door
- 선행학습보다는 행동을 통해 배우는 것을 지향(Active Learning: Learn from real work)
- 도움이 안되는 지식/경험의 망각(Unlearning)
- 나이 들수록 레벨이 올라갈수록 더 중요해짐
- Comfort zone 밖으로 나갈 수 있는지?
- Build Your Network
- "호기심"(혹은 오지랖)
- Find your Mentor
- 자신의 삶을 살기(Explore and Exploit)
- 배움은 항상 중요(Never stop Learning)
Big Data: Spark 소개
- 빅데이터 기술이란?
- Spark 소개
- 판다스와 비교
- Spark 실습
빅데이터의 정의와 예
빅데이터란 무엇이며 어떤 예들이 있는가?
- 빅데이터 정의1
- '서버 한대로 처리할 수 없는 규모의 데이터'
- 2012년 4월 아마존 클라우드 컨퍼런스에서 아마존의 data scientist인 존 라우저(Jogn Rauser)가 내린 정의 분산 환경이 필요하느냐에 포커스
- 판다스로 처리해야할 데이터가 너무 커서 처리가 불가능하다면 어떻게 할 것인가
- 빅데이터 정의2
- '기존의 소프트웨어로는 처리할 수 없는 규모의 데이터'
- 대표적인 기존 소프트웨어 오라클이나 MySQL과 같은 관계형 데이터베이스
- 분산환경을 염두해 두지 않음
- Scale-up 접근방식(vs Scale out)
- 메모리 추가, CPU 추가, 디스크 추가
- 빅데이터 정의3
- 4V(Volume, Velocity, Variety, Varecity)
- Volume: 데이터 크기가 대용량?
- Velocity: 데이터의 처리 속도가 중요?
- Variety: 구조화/비구조화 데이터 둘다?
- Veracity: 데이터의 품질이 좋은지?
- 빅데이터 예제 - 디바이스 데이터
- 모바일 디바이스 - 위치정보
- 스마트 TV
- 각종 센서 데이터(IoT 센서)
- 네트워킹 디바이스
- ,,,,,등등등
- 빅데이터의 예 - 웹 페이지
- 수십조개 이상의 웹 페이지 존재
- 이를 크롤링하여 중요한 페이지를 찾아내고 (페이지 링크) 인덱싱하는 것은 엄청난 크기의 데이터 수집과 계산을 필요로 함
- 사용자 검색어와 클릭 정보 자체도 대용량
- 이를 마이닝하여 개인화 혹은 별도 서비스 개발이 가능
- 검색어 자동 완성, 동의어 찾기, 통계 기반 번역...
- 이를 마이닝하여 개인화 혹은 별도 서비스 개발이 가능
- 이런 문제를 해결하면서 구글이 빅데이터 기술의 발전에 지대한 공헌을 하게 됨
하둡의 등장과 소개
기존 기술과는 전혀 다른 방식을 택함으로써 대용량 데이터 처리를 가능하게 해준 하둡에 대해 알아보자
- 대용량 처리 기술이란?
- 분산 환경 기반(1대 혹은 그 이상의 서버로 구성)
- 분산 컴퓨팅과 분산 파일 시스템이 필요
- Fault Tolerance
- 소수의 서버가 고장나도 동작해야함
- 확장이 용이해야함
- Scale Out이라고 부름
- 분산 환경 기반(1대 혹은 그 이상의 서버로 구성)
- 하둡(Hadoop)의 등장
- Doug Cutting이 구글랩 발표 논문들에 기반해 만든 오픈소스 프로젝트
- 2003년 The Google File system
- 2004년 MapReduce: Simplified Data Processing on Large Cluster
- 처음 시작은 Nutch라는 오픈소스 검색엔진의 하부 프로젝트
- 하둡은 Doug Cutting의 아들의 코끼리 인형의 이름
- 2006년에 아파치 톱레벨 별개 프로젝트로 떨어져나옴
- 크게 두 개의 서브 시스템으로 구현됨
- 분산 파일 시스템의 HDFS
- 분산 컴퓨팅 시스템인 MapReduce
- 새로운 프로그래밍 방식으로 대용량 데이터 처리의 효율을 극대화하는데 맞춤(코딩이 까다로움)
- Doug Cutting이 구글랩 발표 논문들에 기반해 만든 오픈소스 프로젝트
- MapReduce 프로그래밍의 문제점
- 작업에 따라서는 MapReduce 프로그래밍이 너무 복잡해짐
- 결국 Hive처럼 MapReduce로 구현된 SQL 언어들이 다시 각광을 받게 됨
- SQL on Hadoop
- 빅데이터가 뜨면서 SQL이 한물 갔다가 평가되었지만 컴백!
- 또한 MapReduce는 기본적으로 배치 작업에 최적화(not realtime)
- MapReduce 프로그래밍 예제
- Word Count
- 하둡(Hadoop)의 발전
- 하둡 1.0은 HDFS위에 MapReduce라는 분산컴퓨팅 시스템이 도는 구조
- 다른 분산컴퓨팅 시스템은 지원하지 못함
- 하둡 2.0에서 아키텍처가 크게 변경됨
- 하둡은 기반 분산처리 시스템이 되고 그 위에 애플리케이션 레이어가 올라가는 구조
- Spark은 하둡2.0위에서 애플리케이션 레이어로 실행됨
- 손쉬운 개발을 위한 로컬 모드도 지원: 이번 강좌에서는 로컬 모드 사용
- 하둡 1.0은 HDFS위에 MapReduce라는 분산컴퓨팅 시스템이 도는 구조
- HDFS - 분산 파일 시스템
- 데이터를 블록단위로 저장 - 블록의 크기는 128MB (디폴트)
- 블록 복제 방식( Replication)
- 각 블록은 3군데에 중복 저장됨
- Fault tolerance를 보장할 수 있는 방식으로 이 블록들을 저장.
- 분산 컴퓨팅 시스템
- 하둡 1.0
- 하나의 잡 트래커와 다수의 태스크 트래커로 구성됨
- 잡 트래커가 일을 나눠서 다수의 태스크 트래커에게 분배
- 하둡 2.0
- 클라이언트, 리소스 매니저, 노드 매니저, 컨테이너로 역할을 세분화
- Spark 지원이 2.0부터 시작
- 하둡 1.0
- 하둡(Hadoop)을 이용한 데이터 시스템 구성
- 하둡은 흔히 이야기하는 Data Warehouse에 해당
- 웍플로우 관리로는 Airflow가 대세
- 하둡 1.0 vs 하둡 2.0
- 하둡 2.0을 YARN이라고 부르기도 함
Spark 소개
하둡은 1세대 빅데이터 처리 기술이라면 Spark는 2세대 빅데이터 기술이라 할 수 있다. 이번 강의 주제인 Spark에 대해 알아보자.
- Spark의 등장
- 버클리 대학의 AMPLab에서 아파치 오픈소스 프로젝트로 2013년 시작
- 나중에 DataBricks라는 스타트업 창업
- 하둡의 뒤를 잇는 2세대 빅데이터 기술
- 하둡 2.0을 분산환경으로 사용 가능
- 자체 분산환경도 지원하기도 함
- Scala로 작성됨
- 하둡 2.0을 분산환경으로 사용 가능
- MapReduce의 단점을 대폭적으로 개선
- Pandas와 굉장히 흡사 (서버 한대 버전 vs 다수 서버 분산환경 버전)
- 현재 Spark 버전 3이며 이번 강좌에선 이를 사용
- 현재 Scala, Java, Python 3으로 프로그래밍이 가능
- 머신 러닝 관련해서 많은 개선이 있었음(GPU 지원 포함)
- 버클리 대학의 AMPLab에서 아파치 오픈소스 프로젝트로 2013년 시작
- Spark vs MapReduce
- Spark은 기본적으로 메모리 기반
- 메모리가 부족해지면 디스크 사용
- MapReduce는 디스크 기반
- MapReduce는 하둡 위에서만 동작
- Spark은 하둡(YARN)이외에도 다른 분산 컴퓨팅 환경 지원
- MapReduce는 키와 벨류 기반 프로그래밍
- Spark은 판다스와 개념적으로 흡사
- Spark은 다양한 방식의 컴퓨팅을 지원
- 배치 프로그래밍, 스트리밍 프로그래밍, SQL, 머신 러닝, 그래프 분석 등
- Spark은 기본적으로 메모리 기반
- Spark 구조
- 드라이버 프로그램 존재
- Spark은 하둡 2.0 (혹은 하둡 3.0) 위에 올라가는 애플리케이션
- Spark 3.0의 구성
- Spark Core
- Spark SQL
- SparkStreaming
- MLlib(Spark.ML)
- SparkGraph
- k8s 지원
- Spark 프로그래밍 개념
- RDD(Resilient Distributed Dataset)
- 로우레벨 프로그래밍 API로 세밀한 제어 가능
- 하지만 코딩의 복잡도 증가
- Dataframe & Dataset(판다스와 데이터프레임과 흡사)
- 하이레벨 프로그래밍 API로 점점 많이 사용되는 추세
- SparkSQL을 사용한다면 이를 쓰게 됨
- RDD(Resilient Distributed Dataset)
- 보통 Scala, Java, Python 중의 하나를 사용
- 이 강좌에서는 Python을 사용할 예정: Pyspark 모듈
판다스와 비교
Spark와 비교하면 무엇이 다를까?
- 판다스
- 파이썬으로 데이터 분석을 하는데 가장 기본이 되는 모듈 중의 하나
- 엑셀에서 하는 일을 파이썬에서 가능하게 해주는 모듈이라고 생각하면 됨
- matplotlib(시각화)나 scikit-learn(머신러닝)과 같은 다른 파이썬 모듈과 같이 사용됨
- 소규모의 구조화된 데이터(테이블 형태의 데이터)를 다루는데 최적
- 한 대의 서버에서 다룰 수 있는 데이터로 크기가 제약이 됨
- 병렬 처리를 지원하지 않음
- 큰 데이터의 경우 Spark을 사용, 작은 데이터를 다루는데 굳이 Spark을 쓸 필요가 없음!
- Pandas로 할수 있는 일의 예
- 구조화된 데이터를 읽어오고 저장하기
- CSV, JSON 등등 다양한 포맷 지원
- 웹과 관계형 데이터베이스에서 읽어오는 것도 가능
- 다양한 통계 뽑아보기
- 컬럼 별로 평균, 표준편차, percentile 등 계산하기
- 컬럼 A와 컬럼 B간의 상관 관계 계산하기(correlation)
- 데이터 청소 작업 -> 데이터 전처리
- 컬럼별로 값이 존재하지 않는 경우 디폴트 값 지정하기
- 컬럼별로 값의 범위를 조정하기(normalization)
- Visualization
- Matplotlib와 연동하여 다양한 형태의 시각화 지원(히스토그램, 바, 라인 플롯 등등)
- 구조화된 데이터를 읽어오고 저장하기
- Pandas의 데이터 구조
- 엑셀 시트에 해당하는 것이 DataFrame
- 엑셀 시트의 컬럼에 해당하는 것이 Series
- 입력 dataframe을 원하는 최종 dataframe으로 계속 변환하는 것이 핵심
데이터프레임, 데이터셋, RDD
Spark의 데이터 구조
- Spark 세션
- Spark 프로그램의 시작은 Spark 세션(SparkSession)을 만드는 것
- Spark 세션을 통해 Spark이 제공해주는 다양한 기능을 사용
- Spark 컨텍스트, Hive 컨텍스트, SQL 컨텍스트
- Spark 2.0 전에는 기능에 따라 다른 컨텍스트를 생성해야 했음
- Spark 데이터 구조
- 크게 3가지의 자료구조가 존재
- RDD (Resilient Distributed Dataset)
- 로우레벨 데이터로 클러스터내의 서버에 분산된 데이터를 저장
- 레코드별로 존재하며 구조화된 데이터나 비구조화된 데이터 모두 지원
- Dataframe과 Dataset
- RDD위에 만들어지는 하이레벨 데이터로 RDD와는 달리 필드 정보를 갖고 있음(테이블)
- Dataset은 Dataframe과는 달리 타입 정보가 존재하며 컴파일 언어에서 사용가능
- 컴파일 언어: Scala/Java에서 사용 가능
- PySpark에서는 Dataframe을 사용함
- SparkSQL을 사용하는 것이 더 일반적
- RDD (Resilient Distributed Dataset)
- 크게 3가지의 자료구조가 존재
- Spark 데이터 구조 - RDD
- 변경이 불가능한 분산 저장된 데이터
- RDD는 다수의 파티션으로 구성되고 Spark 클러스터내 서버들에 나눠 저장됨
- 로우레벨의 함수형 변환 지원(map, filter, flatMap 등등)
- RDD가 아닌 일반 파이썬 데이터는 parallelize 함수로 RDD로 변환
- 변경이 불가능한 분산 저장된 데이터
- Spark 데이터 구조 - 데이터 프레임
- RDD처럼 데이터 프레임도 변경이 불가한 분산 저장된 데이터
- RDD와는 다르게 관계형 데이터베이스 테이블처럼 컬럼으로 나눠 저장
- 판다스의 데이터 프레임과 거의 흡사
- 데이터 프레임은 다양한 데이터소스 지원: 파일, Hive, 외부 데이터베이스, RDD 등등
- 스칼라, 자바, R, 파이썬과 같은 언어에서 지원
- ㅍSpark 데이터 구조 - 데이터 셋
- Spark 1.6부터 추가된 새로운 데이터 타입
- RDD와 Spark SQL이 최적화 엔진 두 가지 장점을 취함
- 데이터 셋은 타입이 있는 컴파일 언어에서만 사용 가능
- 데이터 셋은 자바와 스칼라에서만 지원되며 파이썬에서는 사용불가
- 이번 강좌에서는 사용하지 못함
- Spark 1.6부터 추가된 새로운 데이터 타입
