1.1 데이터!
데이터의 크기는 끊임없이 증가하고 있고, 이를 저장하고 분석하는 일은 어려워지고 있다.
1.2 데이터 저장소와 분석
-
문제 : 디스크의 용량은 엄청나게 증가했지만 데이터를 읽는 속도는 그에 미치지 못하고 있다.
-
단일 디스크의 데이터를 읽는 데 너무 많은 시간이 걸리고, 쓰는 것은 더 느리다. 시간을 줄이기 위해선 여러 개의 디스크에서 동시에 데이터를 읽는 것.
-
그러나 여러 개의 디스크에 데이터를 병렬로 쓰거나 읽으려면 고려해야 하는 문제가 있다.
- 하드웨어 장애
- 많은 하드웨어를 사용할수록 장애의 확률도 높아진다.
- 데이터의 손실을 막기 위한 일반적인 방법은 데이터를 여러 곳에 복제 하는 것.
- 이런 구조가 바로 RAID이다. (HDFS는 조금 다른 방식이다.)
- 분할된 데이터를, 언젠가는 결국 결합해야 하는 문제가 있다.
- 언젠가는 100개의 디스크에 분산되어 있던 데이터를 1개의 디스크에서 나머지 99개의 디스크에 있던 데이터도 다 읽어와야 하는 문제가 있음.
- 읽어오는 건 그렇다 치고, 읽어왔을 때 이게 완전한지, 정합성을 지켜주는 건 또 다른 어려움이다.
- 이런 점을 해결하고자, MR은 디스크에서 데이터를 읽고 쓰는 작업을 → Key-Value 쌍의 처리 과정으로 변환해서 해결하고 있다.
즉, HDFS와 MR을 포함하고 있는 하둡은 안정적이고 확장성이 높은 분석 플랫폼을 제공한다고 할 수 있음.
1.3 전체 데이터에 질의하기
MR은 한 번의 쿼리로 전체 또는 큰 규모의 데이터셋을 처리하는 것이 전제임. 그리고 장점임. ?
MR은 일괄 질의 처리기이고, 아 batch query processor 이다. 전체 데이터셋을 대상으로 ad hoc 쿼리를 수행해주고, 나름 합리적인 시간 내에 그 결과를 도출해준다.
너무 오래 걸려서 얻기 힘들었던 문제를 해결할 수 있게 되어서 새로운 통찰력으로 우리를 이끌어주고 있다.
1.4 일괄 처리를 넘어서(Beyond Batch)
- MR의 강점은 일단 Batch Process 시스템이라는 점이고, 따라서, 대화형 (Interactive) 분석에는 어울리지 않다 → 일반적으로 결과를 받기까지 1분 이상 걸리기 때문에, 오프라인 용도로 적합하다고 봐야 한다.
- 이런 온라인 분석 (대화형 분석)을 지원하는 구성요소를 생각해보자면, HBase가 있다. 이는 HDFS를 기본 저장소로 하는 Key-Value 스토리지다. HBase는 개별 행에 대한 온라인 읽기/쓰기 작업과 Bulk 데이터를 읽고 쓰는 Batch 처리를 둘 다 지원하기 때문에, 애플리케이션을 구축하는 데에 좋은 솔루션임 → 근데 듣기로는, 일괄 처리를 하게 되면, 굉장히 느려지는 걸로 아는데..
이런 모델을 지원하는 데에는 YARN이 조력하고 있음. YARN은 클러스터 자원 관리 시스템인데, MR 뿐만 아니라, 여러 분산 프로그램에 대해서 데이터 처리를 지원하게 해줌.
- Interactive SQL (대화형 SQL)
- MR 대신에, 데몬을 계속 띄워놓는 Impala나 YARN 컨테이너를 재사용하는 Hive on Tez 분산 쿼리 엔진을 이용한다.
- Iterative processing (반복 처리)
- ML 등의 알고리즘은, 반복 연산을 하는 경우가 많음. 따라서, 각 단계마다, 디스크에서 새로 데이터를 불러오기보다는, 메모리에 임시 작업 데이터셋을 보존하는 것이 훨씬 효율적임.
- MR에서는 이러한 작업을 허용하지 않지만, Spark는 이를 제공한다.
- Stream Processing (스트림 처리)
- Storm, Spark Streaming, Samza (쌈자…? 민경훈..) 등은 실시간으로 실행되는 UNBOUNDED DATA (경계없는 데이터) 를 분산 계산해서 이 결과를 하둡 스토리지나 외부 시스템에 전달할 수 있다.
- Search (검색)
- Solr 이야기가 나오는데,,,,,, ES 쓰자.. 이건,.. ㅋㅋ
1.5 다른 시스템과의 비교
최초의 분산 시스템은 아니지만, 다른 시스템과 확실히 구분되는 독특한 특성이 있음. 이를 알아보자!