https://m.blog.naver.com/chermg/222939863819
조직의 잘못된 의사결정의 사례 “쿠바 미사일 사건”
context를 날리고 평가하는 것은 답이 안나온다.. 사람이 말을 타고 자동차를 타는 이유? 그 시점에서 최선의 선택이 그것이었으니까.
데이터가 스트리밍으로 바뀌고, 데이터의 형태가 달라짐에 따라 이에 맞는 분산 처리를 하기 위해 Spark를 쓰게 되었다.
하둡의 Map Reduce: Map → Shuffle → Reduce 과정을 거침. 하지만 map 이후 local disk에 저장하니 훨씬 느려짐. 그리고 job으로 한 번 처리한 데이터를 다시 사용할 수 없다. K-means clustering을 하면 같은 데이터를 여러 번 처리하게 된다.
Immutable한 미디어? 요즘엔 거의 mutable한 자료만 사용한다. immutable/mutable의 특성을 이해하고 어느 것을 사용할지 알아야 가능하다. 주입식 교육으로 툴을 외우지 말자. 원리를 이해하자. → immutable이 보장된다면 분산 환경에서 데이터의 일관성이 보장되어 오염될 일이 없다.
하둡에는 local disk에 저장하기에 job 도중에는 fault tolerance가 없지만, 스파크는 in-memory cache도 쓰고, Lineage를 사용해서 fault tolerance도 보장해줬다. 하둡 사용 당시에는 다시 시작해도 돼서 큰 문제가 아니었지만, 스파크가 나올 당시에는 스트리밍 데이터기에 큰 문제였기에 이 문제도 해결했다.
RDD: fundamental unit of data. 스파크 관점에서는 disk에 있든 메모리에 있든 상관 없음. 최초의 External dataset으로부터 Ancestor 개념을 만들어서 매번 스냅샷을 찍고 버전을 관리함.
Transformation은 RDD에 필터를 걸어두지만, Action 명령이 나올 때까지 계산을 하지 않는다. 대신 RDD를 새로 만들게 된다. map, filter 등이 있다. → Lazy Evaluation 스파크 optimizer가 execution plan을 최적화하고 불필요한 계산을 줄인다.
Action은 RDD를 만들지 않지만, evaluation of transformation을 시작한다. collect, count, read 등이 있다.
Narrow: map, filter, flatMap → 파티션별로 결과를 뽑아내서 값만 취합하면 되니 shuffle이 없다.
Wide: groupBy, reduceBy, join → 각 파티션별로 결과를 뽑아내서 데이터를 합친 뒤, 다른 곳에 저장하기 위해 이동을 해야 하니 Shuffle을 일으킨다.
파티션은 병렬 계산을 실행하게 하기 위한 최소 논리적 데이터 구분 단위. 사이즈를 조정함에 따라 executer 몇 개가 얼만큼의 작업을 수행할지 나뉜다.
data skewing을 피하기 위해 데이터를 세분화해서 저장하는 방법도 있다~
스파크는 Embarrassingly Parallel 구조를 완성시켰다. 각 executer별로 공유되는 context는 하나도 없다.