하둡이 어떻게 만들어졌는지, 어느게 필요하고 왜 이런 선택을 했고 어떤 판단에 의해서 만들어졌는지의 과정. 여러 기술이 있음에도 어떤 선택을 했기에 동작 원리가 어떻게 되고, 이 out-dated된 내용들을 이해할 수 있어야 한다.
2000년대 하둡이 생성되던 상황: 웹데이터가 폭발하던 시대. 검색엔진, SNS 등.
그 당시엔 클라우드가 없으니 모든게 온프레미스였고, 서버들은 좀 더 싸고 불안정한commodity hardware였다. 그리고 데이터베이스 scale out을 페타바이트급까지 늘릴 수 없었다.
근데 2003년도 구글의 파일시스템 논문, 2004년의 맵리듀스 논문 때문에 생겨났다.
하둡의 문제: 큰 데이터셋을 효율적으로 저장하고 가공하는 것을 저렴한 하드웨어와 분산 처리로 해결하자!
저장: HDFS, 프로세스: MapReduce, 리소스 관리: Yarn
이 세 개의 layer로 나뉘어진 이유? 추상화가 되어야 한다. 인터페이스를 가지고 통신. 네트워크 7계층도 마찬가지. 적절한 의사결정으로 적당히 잘 쪼갰다!
하드웨어는 멈춘다. commodity 하드웨어니까 죽으면 바꿔야지 → 다른 회사 컴퓨터들끼리도 통신할 수 있도록 heterogenious
HDFS는 write once, read many. 데이터 업데이트가 없다. DB 업데이트시 락이 걸리지 않으니 비용이 매우 내려간다. → 극단적이게 큰 데이터 셋이니 극단적인 방법으로 락을 아예 없애자.
Moving computation is better than moving data : 지금은 아니지만, 예전에는 데이터노드에 연산을 던져줘서 병렬처리를 시키고 결과를 네임노드로 보내주는게 더 나았다.
Namenode: 메타데이터, 퍼미션, 블록 인덱스 등을 저장. 깨지면 복구 안됨. secondary namenode를 active/standby 구조로 둔다.
Datanode: 클라이언트가 write시 직접 통신으로 저장한다.
Data Local: 하나의 하드 안에 Data와 Map이 둘 다 존재함
Rack Local: 하나의 랙 안에 Data와 Map이 둘 다 존재함 (기가비트 스위치, 허브로 연결)
Different Rack: 서로 다른 랙에 Data와 Map이 존재함
→ 같은 Rack에 있는 데이터가 더 싸고, 다른 Rack이면 더 비싸다. 네트워크 통신이 더 느리니까