오픈소스 프레임워크 정리(Presto, Airflow, Slider, OpenTSDB)

Presto
빅데이터 분석 도구로, 분산된 SQL 쿼리 엔진이다.
테라, 페타 바이트 단위의 데이터를 분산 쿼리를 사용하여 분석할 수 있는 툴이다.
Hive나 Pig는 쿼리가 맵리듀스 잡으로 실행되는 반면 Presto는 쿼리 실행 엔진이 구현되어 있어서 단계별 결과를 디스크에 쓰지 않고 메모리에서 메모리로 데이터를 전달할 수 있다.
Coordinator(master)와 Worker(slave)가 있다.
Coordinator: Client로부터 요청을 받는다. SQL 구문을 parsing한다. 쿼리를 실행할 worker 노드를 조정하고 노드의 활동을 트래킹한다.
Worker: Coordinator에게서 받은 태스크를 수행하고 데이터를 처리한다. 수행 결과는 바로 worker에서 client로 전달한다.

프레스토에서 connector는 데이터베이스에서의 driver와 같은 역할을 한다.
즉, 데이터 소스에서 데이터를 읽어올 수 있도록 이어주는 역할을 한다.
다양한 저장소에서 저장된 데이터를 SQL을 이용해서 조회할 수 있다.
프레스토 쿼리에서는 하나 이상의 catalog를 사용할 수 있다. 즉, 하나의 쿼리에서 여러 개의 데이터 소스를 사용할 수 있다.

프레스토 워커 프로세스가 시작하면 Coordinator의 discovery server에 등록된다.
discovery server에 등록돼야 coordinator가 태스크 실행에 워커를 배정할 수 있다.
클라이언트는 HTTP로 쿼리를 coordinator에 보낸다.
Coordinator는 connector plugin에 스키마 데이터를 요청한 뒤 쿼리 플랜을 작성한다.
Coordinator에서 워커로 수행해야 할 태스크를 전달한다.
워커는 connector plugin을 통해서 데이터 소스로부터 데이터를 읽어온다.
워커는 메모리에서 태스크를 수행한다.
실행 결과를 바로 클라이언트에게 전달한다.

<https://docs.ncloud.com/ko/hadoop/chadoop-4-7.html>

프레스토는 데이터 소스에서 데이터를 가지고 와서 최종적으로는 메모리에 올려서 연산 처리를 하다 보니 데이터의 양을 어느 정도 추정할 수 있게 되면 메모리에 과부하가 가서 쿼리 결과가 안 나오는 사태가 발생한다든가 하는 일을 미연에 방지할 수 있다.

하이브보다 빠르지만 그만큼 cpu와 메모리를 많이 쓴다.
하이브와 비교했을 때, 쿼리를 실행하고 결과를 보고, 다시 쿼리를 수정해서 확인하고 하는 형태의 작업에는 하이브가 적합하지 않았다. 쿼리를 실행하고 결과를 확인하는데 괘 시간이 걸리다보니 생산성이 떨어졌기 때문이다.
반면, 프레스토는 비교적 짧은 시간 내에 응답을 받을 수 있었다.



하이브 vs 프레스토
하이브는 SQL 쿼리를 여러 단계의 맵리듀스로 바꾼다.
요즘 하이브는 스파크와 비슷한 연산 모델을 갖고 있는 테즈에서 동작한다.
맵리듀스는 fault tolerant하다. 중간 단계를 디스크에 저장하고 배치 작업이 가능하기 때문에.
임팔라나 프레스토와 같은 다른 엔진들은 두 개의 큰 테이블이 join될 때 조심한 작업이 필요하지만 하이브는 robustness를 강점으로 갖는다.
잡이 실패해도 자동으로 재시도한다.

어떤 경우는 단순히 SQL 쿼리를 실행하는 것이 충분하지 않을 때가 있다.
인메모리 분산 SQL 쿼리 엔진이다.
쿼리를 가공해야 할 필요가 있다.

하이브에 좋은 상황: large data aggregation, large fact-to-fact join, large distincts, batch jobs that can be scheduled.
프레스토에 좋은 상황: interactive queries, quickly exploring the data,

하이브는 throughput에 최적화됐다.
프레스토는 interactivity에 최적화됐다.






Airflow
특징
워크플로우 스케줄링, 모니터링 플랫폼이다.
실행할 태스크를 정의하고 순서에 등록&실행&모니터링 할 수 있다.
DAG로 각 배치 스케줄이 관리된다.
웹 기반의 모니터링 콘솔을 제공한다.
에어플로우 파이프라인을 파이썬을 이용해서 구성하기 때문에 동적인 구성이 가능하다.
오퍼레이터, 익스큐터를 사용자의 환경에 맞게 확장하여 구성하는 것이 가능하다.
분산 구조와 메시지 큐를 이용하여 많은 수의 워커 간의 협업을 지원하고 스케일 아웃이 가능하다.


구조
웹서버: 웹 UI를 표현하고 워크 플로우 상태 표시하고 실행, 재시작, 수동 조작, 로그 확인 등을 한다.
스케줄러: 작업 기준이 충족되는지 여부를 확인한다. 충족 여부가 DB에 기록되면 태스크들이 워커에게 선택돼서 작업을 실행한다.


장점
파이썬 기반으로 태스크 코드를 작성할 수 있기 때문에 익숙한 언어를 사용할 수 있다.
여러 머신에 분산해서 수행 될 수 있다.
에어플로우 콘솔이 따로 존재해 태스크 관리를 서버에 들어가 하지 않아도 되고 각 작업별 시간이 나오기 때문에 bottleneck을 찾을 때도 유용하다.
Hive, pig, mysql, mssql 등과의 다양한 커넥션을 제공한다.


단점


사용사례

Oozie와의 비교:
에어플로우는 DAG를 파이썬으로 쓰는 반면에 우지는 DAG를 자바나 xml을 사용해서 짜야한다.
우지 커뮤니티가 덜 활발하다.
우지로는 복잡한 파이프라인을 짜기 어렵다.
유아이가 에어플로우가 더 좋다.




Slider
특징
분산 애플리케이션을 쉽게 배포하고 관리할 수 있게 해주는 YARN 애플리케이션이다.
하둡에서 장기 실행되는 데이터 액세스 애플리케이션의 배포 및 관리를 위한 프레임워크이다.
얀의 resource management 기능을 활용하여 애플리케이션을 배포하고 수명 주기를 관리하며 온디맨드 방식으로 실행중인 애플리케이션을 확장 또는 축소할 수 있다.
HBase, Accumulo, Storm과 같은 장기 실행 서비스를 얀으로 슬라이드하여 필요한 것보다 더 많은 처리 리소스를 묶어두지 않고도 변화에 따른 데이터량을 처리할 수 있을만큼 충분한 리소스를 확보할 수 있다.
컨테이너 오류가 발생하면 슬라이더는 얀 시설을 투명하게 활용하여 애플리케이션 복구를 관리한다.

기존에 얀 환경을 고려하지 않고 개발된 분산 애플리케이션을 얀 환경에서 돌아갈 수 있도록 해 주는 플랫폼이다.



구조


장점


단점


사용사례



OpenTSDB
특징
OpenSource Time Series Database
데이터를 저장하기 위한 디비 중 하나이다.
RDB와 달리 Column 기반인 NoSQL의 데이터베이스이기에 테이블 간의 관계가 중요하지 않다. 단순히 키-밸류로 많은 데이터를 읽고 쓰는 것에 특화되어 있다.
Hbase 위에서 작성된 분산, 확장 가능한 Time Series Database이다.
노드를 추가함으로써 capacity를 추가할 수 있다.
초당 수백만개의 쓰기를 할 수 있다.
데이터를 삭제하거나 다운샘플링하지 않으며 수십억 데이터 포인트를 쉽게 저장할 수 있다.
Grafana를 지원한다.
오픈소스 프런트엔드를 고를 수 있다.


구조
TSD(Time Series Daemon)들로 구성된다.
각각의 TSD는 독립적이며 상태 공유 없이 돌아가기 때문에 여러 TSD에게 여러 일을 던져주는 것이 문제 없다.







장점


단점


사용사례