1.1 데이터!

데이터의 크기는 끊임없이 증가하고 있고, 이를 저장하고 분석하는 일은 어려워지고 있다.

1.2 데이터 저장소와 분석

문제 : 디스크의 용량은 엄청나게 증가했지만 데이터를 읽는 속도는 그에 미치지 못하고 있다.
단일 디스크의 데이터를 읽는 데 너무 많은 시간이 걸리고, 쓰는 것은 더 느리다. 시간을 줄이기 위해선 여러 개의 디스크에서 동시에 데이터를 읽는 것.
그러나 여러 개의 디스크에 데이터를 병렬로 쓰거나 읽으려면 고려해야 하는 문제가 있다.
- 하드웨어 장애
  - 많은 하드웨어를 사용할수록 장애의 확률도 높아진다.
    - 데이터의 손실을 막기 위한 일반적인 방법은 데이터를 여러 곳에 복제 하는 것.
    - 이런 구조가 바로 RAID이다. (HDFS는 조금 다른 방식이다.)
- 분할된 데이터를, 언젠가는 결국 결합해야 하는 문제가 있다.
  - 언젠가는 100개의 디스크에 분산되어 있던 데이터를 1개의 디스크에서 나머지 99개의 디스크에 있던 데이터도 다 읽어와야 하는 문제가 있음.
  - 읽어오는 건 그렇다 치고, 읽어왔을 때 이게 완전한지, 정합성을 지켜주는 건 또 다른 어려움이다.
  - 이런 점을 해결하고자, MR은 디스크에서 데이터를 읽고 쓰는 작업을 → Key-Value 쌍의 처리 과정으로 변환해서 해결하고 있다.
즉, HDFS와 MR을 포함하고 있는 하둡은 안정적이고 확장성이 높은 분석 플랫폼을 제공한다고 할 수 있음.

MR은 한 번의 쿼리로 전체 또는 큰 규모의 데이터셋을 처리하는 것이 전제임. 그리고 장점임. ?

MR은 일괄 질의 처리기이고, 아 batch query processor 이다. 전체 데이터셋을 대상으로 ad hoc 쿼리를 수행해주고, 나름 합리적인 시간 내에 그 결과를 도출해준다.

너무 오래 걸려서 얻기 힘들었던 문제를 해결할 수 있게 되어서 새로운 통찰력으로 우리를 이끌어주고 있다.

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 쓰자.. 이건,.. ㅋㅋ

최초의 분산 시스템은 아니지만, 다른 시스템과 확실히 구분되는 독특한 특성이 있음. 이를 알아보자!