wsl 접속방법
rdb -> 하둡
sqoop
hbase- 하둡기반 no sql (hdfs가 베이스)
hdfs- 하둡이 실행되는 파일 관리해주는 시스템
스파크(하둡기반 데이터 프레임으로 변경해주는 것) - 모든 데이터 타입 허용
분산적재 되어있는 데이터 가져와서 처리하고(가져오면 합쳐진 것처럼 한번에 볼수 있음) 그리고 write 시키면 처음 처럼 따로 write 시킬 수 있음 (굳이 데이터 베이스를 따로 만들지 않고 write 시키면 됨)
하둡
마스터에서 실행계획 전달하고
execute 에서 실행 호출 슬래이브 선언
분산처리 execute 여러개
작업하나하나가 각각의 cpu에서 분산되어 수행 되고 마스터에게 결과를 알려주는 것
mapreduce 방식을 지원해줌
하둡 : 분산해서 작업을 하라는 것을 만들어주는 녀석
하나의 컴퓨터
병렬로 수행이 된다 (분산처리)
스파크와 판다스 차이
- 실행 계획만 가지고 있기에 실제로 연산이 들어가는 작업 (show, count 등)이 있어야 시작되며 cpu가 돌아감
map reduce
cpu가 각각 수행 할 수 있게 병렬로서 명령을 내려주는 것
read -> process(병렬로) -> write
aws (s3), EMR(elastic map reduce) = hadoop (hdfs), mapreduce
glue
서버리스 방식으로 서버없이 read write transform 등을 수행함
단 함수를 만들어야 함
스토리지를 쓰는 이유는 네트워크 액세스 방식이 아니라 서비스에서 바로 액세스 네트워크 연결에서 편의성이 생김
spark에서 테이블 여러개 했을 때 컬림이 늘어나거나
파일데이터 : 분리해서 적재할 수 있고 다를 수가 있음 하나하나 핸들링하기 힘듬
핸들링 하기 위해 스파크를 사용
파일 데이터를 스토리지 하둡 hdfs 데이터가 저장되어 있는 방식은 분리해서 저장되어 있음
read process write 스파크 : 하둡 환경, emr 에서 사용
aws에서 글루 파일 데이터 작업의 환경마저 세팅하지 않고 서버리스로 사용, 극단까지 활용한게 크롤러
하둡 - 하나의 서버가 아님 (여러개 분산되어 있는 서버에 마스터와 슬레이브)
(마스터에서 슬레이브에 전달하고 슬레이브에서 모아서 마스터로 가는 것)
hdfs(distribute file system) 안에 넣는 것 (파일데이터로 저장해보자)
- 파일을 저장하는 스토리지 (분산되어 적재)
hdfs 조회하거나 실행계획
- Map Reduce, YARN
HBase, Cassandra
- 키 벨류, 컬럼 데이터 베이스
hive
- 물리적으로 데이터베이스를 넣어줄 수 있는데 그거말고도 카다로깅하는 것.
- 어떠한 순서로 데이터가 있는지 메타데이터 정보 (컬럼의 데이터 타입, 길이, 컬럼 정보 그 카다로그를 활용을 해서 데이터 조회 데이터 베이스에는 없는데 조회하는 것)
tajo
- 고려대학교에서 만든 오픈소스로 sql 쿼리 조회
hue
- 사용자가 쿼리한 결과를 화면으로 보여주는 인터페이스 (아데나 느낌)
spark
- 데이터를 처리하기 위해 사용 되는 것
sqoop
- 하둡에코 시스템은 파일로 움직임. 순차적으로 끌어오는 기능. rdb를 끌어올 때
oozie
- 위 여러 과정들이 장애가 나지 않도록 workflow 총괄관리
- 테스크들의 덩어리 (즉 main.py와 컨트롤러 etl의 중간정도 역할)
- 워크플로우 안에 데이터가 있는지 없는지 킬할지 어떡할지 정해줘야함
파이썬으로 db etl 할 때
-
boto3
-
ddb에 밀어넣을 때 id가 겹치면 안되니까 truncate 했어야 함.
-
시스템의 부하를 분산 시키기 위해 실행 분기를 주는 옵션 코드가 들어가야함.
work flow 로직
- 데이터 받음 -> truncate 제거 -> 자원 분배 실행 방법들 -> wirte 검증 로직
dag
- 모듈의 main.py
task - 각각의 함수들
