빅데이터 프레임워크, 솔루션들의 목적과 역할

1. 왜 관계형 데이터베이스를 벗어나는가?

- 관계형 데이터베이스는 SQL로 여러가지 집계 질의와 Partial Update를 할 수 있고, 트랜잭션도 잘 지원하나 비용의 문제가 있음
> 대용량 데이터에 대해 어려운 질의를 할 경우, 좋은 성능의 데이터베이스 서버를 쓰지 않으면 처리 속도가 빠르지 않음

- 관계형 데이터베이스가 비용 효율적이지 않은 이유는 수직적 확장을 할 수 밖에 없는 구조이기 때문
> 수직적 확장은 더 많은 비용을 요구하는 반명 수평적 확장은 그렇지 않음

 

2. 수평적 확장이 가능한 Hadoop 클러스터

- 빅데이터를 저장하기 위해서는 빅데이터를 저장할 수 있을만큼의 스토리지를 요구
> Hadoop HDFS(Hadoop Distributed File System)에서는 스토리지가 부족할 경우, Data Noder를 추가함으로써 수평적으로 스토리지를 늘릴 수 있음

- 빅데이터를 처리하기 위해서는 더 많은 컴퓨팅 자원이 필요할 수 있음
> Hadoop YARN에서는 MapReduce Job을 더 빠르게 수행하기 위해 Node Manager를 추가함으로써 CPU, RAM 같은 컴퓨팅 자원을 늘릴 수 있음

 

3. 분산 컴퓨팅 프레임워크 Spark

- Spark는 단일 머신에서 실행할 수도 있지만 Hadoop YARN, Mesos, 쿠버네티스와 같은 클러스터 시스템과 결합되어 자원을 동적 할당할 수 있음
> 주로 master node를 먼저 실행시킨 뒤, 추가적으로 필요한 node들을 클러스터 Manager를 통해 띄움
> 또한, 처음부터 일정 양의 node를 선점하고 있도록 할 수도 있음

- Spark 대신 Hadoop Mapreduce를 활용할 수 있지만 Spark만큼 효율적인 Mapreduce 애플리케이션을 개발하기는 어려움

 

4. 데이터 웨어하우스 Hive

- Hive는 방대한 양의 데이터를 SQL(HiveQL)로 다룰 수 있게 도와주는 시스템
> Hive가 등장하기 전에는 Hadoop Mapreduce 코딩을 하거나 Pig와 같은 언어를 이용하여 데이터들을 다뤄야 했음

(1) Hive에 질의 요청이 들어오면 질의를 분석하여 여러 단계의 MapReduce Task로 분리
(2) 각 Task 간의 의존 관계를 분석하여 어떤 Task를 먼저 실행할 지, 어떤 Task를 함께 실행할 수 있을지 파악
> Task 관계도를 방향성 비순환 그래프(Directed Acyclic Graph, DAG)로 구성
> 이러한 DAG를 이용하여 Hadoop YARN 위에서 데이터 처리를 쉽게 할 수 있고자 시작된 프로젝트가 Tez
> Hive CLI를 실행한 뒤 질의를 실행하면 Tez가 YARN 애플리케이션으로 실행됨

- 결과적으로, 데이터 웨어하우스 상의 데이터 카탈로그는 Hive에서 관리하고, 실제 데이터 처리는 Tez라는 레이어에서 처리된다고 볼 수 있음
> 마치 TCP 통신이 여러 레이러로 처리되는 것과 같음

- Hive에 선언해둔 데이터 카탈로그는 Spark에서 HiveContext를 통해 이용할 수 있음
> Hive에 선언해둔 View를 Spark에서 이용함으로써 Spark 애플리케이션을 개발할 때, 데이터 카탈로와 관련된 코드를 작성하지 않을 수 있음

 

5. NoSQL 데이터베이스

- CAP 이론에 따르면 데이터베이스는 일관성, 가용성(유효성), 파티션 허용차 3가지 모두를 만족할 수 없음
> 관계형 데이터베이스는 일관성과 가용성을 보장하는 대신 많은 데이터 처리를 위한 파티션 허용차를 포기

- NoSQL 데이터베이스는 특정 key에 해당하는 document를 찾아내는 질의 패턴에 적합
> 특정 Key를 이용하여 node에 접근한 뒤 추가적인 질의를 처리하는 수행 방식
> 이를 통해 병목 현상을 일으키는 지점이 최소화 됨
> 또한 여러 node에 데이터를 분산하여 저장하고, 질의를 처리하기 때문에 수평적 확장이 용이
> 관계형 데이터베이스처럼 전체 데이터에 대해 색인을 타고 질의 결과를 scan할 수는 없지만, 많은 질의를 동시에 처리하기 용이해 같은 시간 대비 질의 처리량이 높음

- DynamoDB에서는 여러가지 제약 사항과 비용 상 고려해야할 점들이 있는데, 만약 workload 상 문제가 없다면 DynamoDB 이용 가능에 좋음
> 그러나 DynamoDB 특유의 비용 청구 방식인 Read Capacity Unit, Write Capacity Unit에 따른 비용과 스토리지 비용을 미리 추산하지 않으면 비용 폭탄을 맞을 수 있음

 

6. 자원 코디네이터 Zookeeper

- Hadoop ecosystem에는 분산 시스템이 많은데, 분산 시스템에서는 동기화가 매우 중요한 문제 중 하나
> 단일 머신 상에서는 mutex나 semaphore로 동기화 문제를 해결
> 분산 환경에서는 Zookeeper를 이용하여 mutex, semaphore 같은 역할을 수행

- Zookeeper는 여러 node에 중복으로 데이터를 저장하여 높은 신뢰성을 보임
> Zookeeper node를 한 대만 운용하는 경우는 잘 없음
> 최소 3대를 운용하고, 한 node의 변경 사항은 다른 node들에 전파되어 반영됨
> Zookeeper에 write 하기 위해서는 클러스터 상 과반수 이상의 node로부터 가능하다는 응답이 와야 함

- Hadoop HDFS(Hadoop Distributed File System) Namenode의 고가용성 설정을 위해 Zookeeper가 이용됨
> Namenode의 상태를 Zookeeper에 동기화시키면서 Active Namenode에 문제가 생겼을 때, follow-up 하고 있던 Standby Namenode가 Active Namenode로 승격될 수 있게 함
> HBase, Kafka, NiFi, Druid와 같은 다양한 솔루션에서 동기화 문제를 해결하기 위해 Zookeeper를 이용함

7. 높은 신뢰성과 성능의 스트림 Kafka

- Spark와 비슷하게 대용량 스트림 처리에 있어 사실상 표준
> Publish-subscribe 구조를 고성능으로 제공하는 솔루션
> Kafka 만큼의 높은 throughput을 제공하는 솔루션은 거의 없음
> Queue를 써도 성능 상의 문제가 없다면 그냥 Queue를 쓰면 되지만, 데이터가 점점 많아지면 Queue로는 확장성이 부족해지는 때가 옴

- Kafka의 강점은 장애 허용 시스템이다
> Kafka도 Zookeeper와 마찬가지로 단일 node로 구성하지 않음
> Kafka에서는 각각의 node를 broker라고 하는데, 최소 3대 이상의 broker로 구성하고 publish 하는 메세지를 최소 2대 이상의 broker에 중복으로 저장하여 데이터 유실을 막음
> 중복 인자(Replication factor)를 2로 설정할 경우, 한 대의 borker가 장애로 인해 멈췄을 때도 문제 없이 데이터를 subscribe 할 수 있고, 중복 인자를 3으로 설정할 경우 두 대의 broker가 멈춰도 정상 작동함
> Kafka broker에 장애가 잘 나지 않기 때문에 데이터를 kafka에 올리고 나면 데이터 잔존(Data Retention) 기간 동안은 걱정 없이 데이터가 보관됨

- 실시간 스트리밍 처리를 위해 이용되기도 함
> 데이터가 들어오면 Kafka에 일단 적재하고, Spark streaming이나 Flink와 같은 스트리밍 처리 프레임워크를 이용하여 스트리밍 처리를 함

 

8. 비싸지만 만능 ElasticSearch

- 검색, 집계 등 거의 모든 것을 할 수 있는 솔루션
> Elasticsearch를 기본으로 사용하고, Logstash로 Elasticsearch에 데이터를 전송하고, Kibana로 시각화 및 관리를 하는 ELK stack이 널리 알려져 있음
> 로그 분석을 할 때 가장 먼저 떠올리는 솔루션
> Elasticsearch node를 추가하여 수평적 확장이 가능함
> 최근에는 머신 러닝과 관련된 기능을 소개

- Elasticsearch 클러스터를 유지하기 위해서는 많은 비용이 듦
> 대용량 데이터를 모두 Elasticsearch에 저장해두기 위해서는 스토리지 뿐만 아니라 인덱스 유지를 위해 메모리가 많이 요구되어 좋은 성능의 node들을 많이 유지해야 함
> 따라서 데이터 잔존 기간을 짧게 가져가게 됨
> 또한, Elasticsearch 클러스터에 문제가 생겼을 때에는 데이터 유실이 발생할 수 있음
> New Relic과 같은 도구를 통해 많은 서버를 모니터링 해야한다면 마찬가지로 적지 않은 비용을 요구

 

9. 빠른 집계를 해주는 Druid

- Druid는 흔히 데이터 큐브라고 불리는 데이터를 미리 만들어 다차원에 대한 집계 결과나 Top N 질의를 실시간으로 응답
> Sub-second ad-hoc query라는 키워드를 내걸고 있는데, 실제로 거의 sub-second에 근접
> 질의를 더 빠르게 수행하기 위해서는 Broker node, Task를 더 빠르게 끝내기 위해서는 Middle manager를 늘리면 되기 때문에 수평적 확장이 가능
> 또한, 중앙 관리자 역할을 하는 Overlord, Coordinator node는 이중화가 가능하여 장애 허용
> 게다가 클라우드 환경을 고려한 시스템 설계로 데이터를 S3와 같은 클라우드 스토리지나 Auto scaling을 이용한 확장이 가능하게 해둠

 

10. 데이터 흐름(Data Flow)을 다루는 NiFi

- Nifi에는 여러가지 작업에 대한 프로세서(Processor)가 준비되어 있으며, 프로세서와 프로세서 간의 데이터 흐름을 쉽게 모니터링 할 수 있음
> 심지어 수평적 확장까지 가능
> NiFi가 하는 일이 많아져서 서버가 부족해지면 node를 하나 추가해주기만 하면 됨

 

11. 클러스터 관리를 위한 Ambari

- 클러스터 상에 설치된 여러가지 솔루션들의 설정값을 관리하고, 각 요소들의 중지/시작을 웹 인터페이스를 통해 쉽게 할 수 있도록 도와줌
> 예를 들어 Hadoop HDFS 설정을 일부 수정한다면, 바뀐 설정 값이 반영되도록 Namenode와 Datanode들이 restart 되어야 함
> parallel-ssh와 같은 툴을 이용해 한 번에 restart 할 수도 있겠지만, 고가용성을 위해서는 일명 rolling restart라 불리는 몇 node 만을 restart 시켜나가는 방식을 이용
> Ambari를 이용하면 이러한 rolling restart를 웹에서 시작할 수 있음 

 

12. 작업 흐름 관리를 위한 Airflow

- Oozie와 같은 workflow 도구가 있지만 사용하기 쉽지 않고, 그 불편함을 해소하고자 Luigi와 같은 도구가 떠올랐지만 이제는 Airflow가 대세로 기울고 있음
> Airflow를 이용하면 workflow를 쉽게 스케쥴링할 수 있고, 각 Task의 의존성에 따라, DAG(Directed Acyclic Graph, 비방향성 순환 그래프)로 선언된 task들을 잘 실행시켜줌
> DAG와 task 실행 로그를 보기 쉬운 Web dashboard가 제공되고, celery를 이용하여 task가 실행되기 때문에 확장성이 존재

 

13. 쉽게 대시보드를 만들어 주는 Zeppelin

- Zeppelin은 Jupyter와 비슷하며, 코드 실행 결과보다 여러 가지 시스템에 대한 질의 결과를 보여주는 데 좀 더 초점이 맞춰져 있음
> Zeppelin에서는 여러가지 시스템에 대한 실행 결과를 얻기 위한 중간 객체로 Interpreter라는 것이 존재하는데, JDBC interpreter를 통한 JDBC 질의 결과, Spark interpreter를 통한 Spark 코드 실행 및 질의 결과를 볼 수 있음
> 또한 질의 결과를 그래프로 시각화하여 보여주기 용이하며, 매일매일 대시보드가 갱신되도록 cron 설정을 할 수 있음