논문 리뷰:Big Data Analytics Technologies and Platforms

Big Data Technologies

오류에 대한 대처 능력, 확장성, 탄력성, 분산 구조, 형식에 포괄적인 저장 공간, 큰 양의 데이터 처리가 필요하다(fault tolerance, scalability, elasticity, distributed architecture, generic storage, processing of large volumes of data).

Big Data Technologies Introduction

Apache Hadoop/YARN
많은 호스트 서버들에서 연산 프로세스를 쪼개서 할 수 있게 하는 open-source computation framework이다.
MapReduce라는 execution engine과 HDFS라는 파일 시스템이라는 두 주요 구성이 있다.
많은 양의 structured 또는 unstructured 데이터를 처리하는 데에 있어 높은 유연성, 확장성, 낮은 코스트, 그리고 reliability를 제공한다.
데이터, 리소스, 태스크의 로드를 균형있게 하는 job schedule도 제공한다.
Hadoop이 YARN(Yet Another Resource Negotiator)로 발전됐다.
YARN은 프로그래밍 모델을 리소스 관리로부터 분리하고 스케쥴링 function들을 각 애플리케이션에 위임했다.

Apache Spark
분산 데이터 처리를 위한 unified engine이다.
MapReduce와 비슷한 프로그래밍 모델을 갖고 있지만 RDD(Resilient Distributed Datasets)라는 data-sharing abstraction으로 확장을 했다.
SQL, streaming, 머신러닝, 그래프 프로세싱 등 각각의 엔진이 필요했지만 RDD로의 확장을 통해서 넓은 범위의 프로세싱 workload를 capture할 수 있게 됐다.
In-memory 연산을 통해서 데이터가 메모리에 캐싱되게 하고, 따라서 반복적인 작업에서 생겼던 YARN의 디스크 오버헤드를 줄일 수 있다.

Apache Flink
분산돼있고 high-performing 애플리케이션을 위한 stream and batch processing framework이다.
많은 데이터 처리 애플리케이션이 pipelined fault-tolerant data flow로 표현되고 실행될 수 있다는 생각으로 만들어졌다.
Flink는 완전히 독립적인 프레임워크로 실행되거나 HDFS 혹은 YARN 위에서 실행될 수 있다.
런타임 실행의 성능을 기르기 위해 in-memory 스토리지를 이용한다.


Hyracks
데이터 집중적인 연산을 위해 만들어진 partitioned-parallel software platform이다.
Map과 Reduce 코드를 쓰지 않고도 데이터 처리 job을 assemble할 수 있다.
기존의 MapReduce job을 실행할 수 있도록 YARN compatible 레이어를 제공한다.
유연한 유저 모델을 통해 MapReduce보다 높은 성능을 제공하면서 다양한 데이터 집중적인 case에 대해 Hadoop보다 효율적인 구현이 가능하다.
Fault handling에 덜 pessimistic한 접근을 함으로써 Hadoop에 비해 높은 fault recovery 성능을 가진다.


Big Data Technologies 비교

빅데이터 기술이 직면하는 문제
structured, unstructured, semistructured 데이터들로 구성된 heterogeneous source를 저장하는 문제
SQL 쿼리만 적용하는 것이 아니라 복잡한 머신 러닝 알고리즘이나 그래프 연산을 수행함으로써 데이터를 분석하는 문제
연속적인 데이터를 실시간, 혹은 거의 실시간처럼 처리 되도록 하는 문제

Batch Processing
개별적으로 요청이 있을 때마다 실시간으로 처리하는 게 아니라 한꺼번에 일괄적으로 정해진 시간에 처리하는 것이다.
ETL(Extract, Transform, Load), 데이터 집합, 트레이닝, 그리고 머신 러닝 모델 업데이트의 작업들로 이루어져 있다.
Hadoop은 데이터 처리 작업을 나눠서 하는 MapReduce 구현 때문에 batch processing에 폭넓게 적용됐다.
Hyracks도 batch processing을 한다.
하지만 Spark가 Hadoop의 읽고 쓰는 오버헤드를 완화시킬 수 있는 빠른 in-memory 데이터 처리를 지원하기 때문에 가장 많이 쓰이는 엔진이 됐다.

Streaming Processing
데이터가 처리되고 결과가 특정 시간 안에 나온다.
Spark Streaming은 live input data stream을 받아서 데이터를 micro-batch로 나눈 뒤 Spark 엔진이 각각을 처리하고 결과 stream을 만든다.
Micro-batching은 stream을 작은 batch 여러 개로 처리할 수 있도록 해주지만 스케쥴링에서 오버헤드가 생길 수 있다.
Flink는 스케쥴링 오버헤드 없이 buffering의 장점을 갖는다.

Generic Storage
HDFS는 structured, unstructured, semistructured 데이터가 다양하게 섞여 있어도 저장할 수 있다.
Hyracks는 HDFS의 데이터를 쓸 수 있고, 아니면 AsterixDB라는 스토리지를 써서 ADM이라는 유연한 데이터 모델을 이용해 큰 데이터를 저장할 수 있다.
Spark는 HDFS, MapR File System, Cassandra, Amazon S3 등 다양한 파일 시스템의 integration을 지원한다.
Flink는 heterogeneous 데이터의 integration을 지원한다. 또한 HDFS와 연동될 수 있고 다양한 다른 스토리지 시스템에 연결시킬 수 있다.
Spark와 Flink는 primary storage solution이 없다.

Data Analytics
YARN/Hadoop은 개발 툴을 만들고 데이터 처리를 관리하기 위해 Giraph, Pig, Hive, Mahout, HBase등과 같은 top-level 프로젝트를 지원한다.
Spark도 ETL, MLib, Spark Streaming, Graph computation(Graph X)등 다양한 애플리케이션을 지원한다.
Flink는 Complex Event Processing(CEP), Machine Learning(FlinkML), Graph Analytics(Gelly) 등 high-level API를 제공한다.
Hyracks는 SQL(Hivesterix), XQuery(Apache VXQuery), Graph(Pregelix)와 같은 다양한 인터페이스를 analytics를 위해 제공한다.


Big Data Platforms

자원 관리, (resource management, data governance, monitoring)



--------------------------------------------------
Reference
Ticiana L. Coelho da Silva, Regis P. Magalhaes, Igo R. Brilhante, Jose Antonio F. de Macedo, David Araujo, Paulo A. L. Rego & Aloisio Vieira Lira Neto (2017) . Big Data Analytics Technologies and Platforms: a brief review. LADaS 2018

댓글

댓글 쓰기

이 블로그의 인기 게시물

논문 정리 - MapReduce: Simplified Data Processing on Large Clusters

Abstract 맵리듀스는 큰 데이터 셋을 다루는 프로그래밍 모델이다 . 사용자는 map 함수를 통해서 키 / 밸류 쌍을 이용하여 intermediate key/value pair 를 만들고 reduce 함수를 통해서 그 intermediate pair 들을 같은 key 별로 합쳐준다 . 많은 일들이 이런 모델을 통해 표현될 수 있다 . 이 모델은 분산 시스템이나 병렬 시스템에 대한 경험이 부족하더라도 분산 시스템의 자원을 쉽게 사용할 수 있게 해준다 . 1. introduction 데이터가 많아지면서 reasonable time 안에 작업을 끝내기 위해 수백 혹은 수천대의 기계에 분산되어야 했다 . 이 때 어떻게 연산을 병렬화하고 , 데이터를 분산하고 , 실패 작업을 어떻게 처리할지가 이슈가 되었다 . 이런 복잡한 문제들을 해결하기 위해 병렬화의 세세한 부분들은 숨기고 fault tolerance 하며 데이터를 분산시켜주고 로드 밸런싱을 해주는 라이브러리를 통해서 연산을 맵과 리듀스로 간단히 표현하도록 했다 . 2. Programming Model 사용자가 직접 만드는 맵 함수는 입력으로 key/value pairs 를 받아서 intermediate key/value pairs 를 만든다 . 그러면 intermediate key/value pairs 에 대해서 맵리듀스 라이브러리가 같은 key 별로 value 들을 묶어서 리듀스 함수로 보내준다 . 마찬가지로 사용자가 직접 만드는 리듀스 함수는 이 데이터를 받아서 key 별로 묶인 value 들을 합쳐서 표현한다 . 리듀스 함수에 전달되는 intermediate 데이터는 iterator 의 형태로 전달되기 때문에 메모리에 다 안 들어갈 정도로 큰 데이터도 처리할 수 있다 . 예를 들어서 , 어떤 문서에 있는 각 단어들이 몇 번 나왔는지 세는 프로그램을 생각해보자 . 그렇다면 맵 함수는 입력으로 < 문서 이름 , 문서 내용 > 의...
자세한 내용 보기

논문 정리 - The Google File System

The Google File System 1. Introduction 새로운 관점 component failure 은 예외가 아니라 일반적인 상황이다 . 그래서 constant monitoring, error detection, fault tolerance, automatic recovery 가 필요하다 . 파일의 크기가 커졌다 . I/O 작업이나 block 크기 등이 고려되어야 한다 . 원래 있는 데이터에 덮어쓰는 작업보다는 새로운 데이터를 추가한다 . 따라서 appending 이 성능 최적화에 중요해졌다 . 2. Design Overview 2.1 assumptions 시스템은 잘 고장나는 저렴한 장비들로 구성되어 있다 . 시스템은 큰 파일이 있다 . 작은 파일들도 있지만 optimizing 할 때는 고려하지 않는다 . 로드는 주로 큰 스트리밍 읽기와 작은 랜덤 읽기로 구성되어 있다 . 로드는 또한 파일에 데이터를 추가하는 많은 sequential write 가 있다 . 같은 파일에 여러 사용자가 동시에 데이터를 추가하는 경우도 잘 고려해야 한다 . 빠른 반응 속도 보다는 high sustained bandwidth 가 더 중요하다 . 대부분의 타겟 애플리케이션은 데이터 뭉텅이를 빠른 시간 내에 처리하는 것을 중요하게 여긴다 . 2.2 Interface 파일은 hierarchically , 디렉토리에 정렬돼있고 path name 으로 구분된다 . 또한 GFS 는 snapshot 과 record append 기능이 있다 . snapshot 은 파일이나 디렉토리 트리를 복사한다 . record append 는 다수 클라이언트가 데이터를 하나의 파일에 동시에 추가할 수 있도록 해준다 . 각 append 의 atomicity 를 보장하면서 . 2.3 Architecture 하나의 마스터와 여러개의 chunkserver 로 구성되어 있다 . 그리고 다수의...
자세한 내용 보기

kazoo: Using zookeeper api with python

``` pip3 install kazoo ``` https://kazoo.readthedocs.io/en/latest/basic_usage.html https://kazoo.readthedocs.io/en/latest/api/client.html ### 접속 ``` from kazoo.client import KazooClient zk = KazooClient(hosts='127.0.0.1:2181') zk.start() ``` 호스트에 접속할 때 default port는 2181이다. ### 상태 Listener zookeeper의 상태가 변하는 것을 알 수 있다. ``` from kazoo.client import KazooState def my_listener(state):     if state == KazooState.LOST:         # Register somewhere that the session was lost     elif state == KazooState.SUSPENDED:         # Handle being disconnected from Zookeeper     else:         # Handle being connected/reconnected to Zookeeper zk.add_listener(my_listener) ``` LOST CONNECTED SUSPENDED 의 state를 가질 수 있다. 가능한 상태 변화 - LOST -> CONNECTED - CONNECTED -> SUSPENDED - CONNECTED -> LOST - SUSPENDED -> LOST - SUSPENDED -> CONNECTED ### CRUD - `zk.create("/my/favorite/node", b"a value")` `create(path...
자세한 내용 보기