Data Engineering TIL (20190309)

study program : https://www.fastcampus.co.kr/extension_des

[학습목표]

• 대용량 데이터 처리 기술 기본개요 이해

[학습기록]

빅데이터의 정의

기존 데이터베이스 관리도구의 능력을 넘어서는 대량의 정형 또는 심지어 데이터베이스 형태가 아닌 비정형의 데이터 집합조차 포함한 데이터로부터 가치를 추출하고 결과를 분석하는 기술

1) 기존 데이터 베이스 관리도구

• SQL 기반의 데이터베이스

• 주로 컴퓨터 한대로 운영하며, 고성능이 필요하면 높은 사양의 컴퓨터를 이용한다.

• 이러다보니 컴퓨터 1대로 처리할 수 있는 물리적인 용량과 성능의 한계가 있다.

2) 대량의 데이터

• 컴퓨터 한대로는 처리하기 어려운 양 (기본 테라바이트 이상)

• IBM에서 정의하는 3V : Volume, Velocity, Variety

3) 기술

• 본질적으로는 컴퓨터 한대로는 대용량 데이터를 처리하지 못하기 때문에 여러대를 서로 연결해서 데이터를 저장하고 처리하자는 아이디어에서 출발한다.

• 과거에 주로 구글이나 야후 등 검색엔진 회사들이 웹 전체를 저장하고 처리하려다보니 대용량 데이터 처리 기술 개발이 필요하게 되었고, 구글에서 데이터 처리 기술에 대한 연구를 시작하고 야후 등이 하둡이라는 오픈소스를 통해 적극적으로 기술을 상용화하였다.

• 빅데이터 기술은 대부분 하둡이라고 생각해도 무방하다.

4) 정형 & 비정형 데이터

• SQL 기반의 데이터는 거의 행렬 형태로 정형화된 데이터라고 할 수 있으나, 일반문서(웹문서) 등과 같이 비정형화된 데이터도 현실에서는 다수 존재한다.

5) 가치를 추출하고 결과를 분석

• 데이터를 저장만해서는 쓸모가 없고, 데이터를 읽어서 변환하고 핵심을 추출하는 것도 데이터를 저장하는 것 만큼 중요하다. 또한 데이터의 규모가 매우 크다보니 당연하게도 컴퓨터 한대로 처리 할 수 있는 능력을 초과해야한다.

대용량 처리기술의 첫걸음

• 과거에 웹서버가 적었을때는 서버하나로 데이터를 처리하는데 문제가 없었으나 점점 웹서버와 유저의 수가 커지므로 인해서 대형 검색엔진 회사를 중심으로 이런 고민을 해결하고자하는 움직임을 보였다.

• 처음에는 큐잉, 샤딩 등의 기술로 큰 양의 데이터를 처리하였다. 큐잉은 말그대로 데이터를 처리하기 위해 줄을 세워두고 하나씩 하나씩 처리하는 방식을 말하는 것이고 이는 한까번에 많은 접근 시 데이터베이스의 부하를 감소시킬 수 있다. 샤딩은 데이터의 키를 해시해서 여러대의 데이터베이스로 분산시키는 기술을 말한다.

• 예를들어 페이스북에서 회원정보 데이터가 있다고 치자. 대략 10억명의 데이터가 있다고 한다면 이 수많은 데이터를 물리적으로 컴퓨터 하나에 저장할 수 없다. 그래서 회원을 지역별로 구분을 하여 북미지역 사용자는 1번 컴퓨터에 저장하고, 동아시아 회원은 2번 컴퓨터에 저장하고, 유럽 회원은 3번 컴퓨터에 저장하고, 특정회원을 어디에다 저장했는지 목차같은 데이터(메타데이터)를 또 4번 컴퓨터에 저장하는 이런 방식을 말한다.

• 샤딩은 데이터가 쌓이면 쌓일수록 시스템의 복잡도가 증가하게 되고, 문제가 발생했을때 유지보수하기가 매우 힘들다는 치명적인 단점이 있다. 예를들어서 10대의 컴퓨터로 샤딩을 구성했다면 컴퓨터가 한대로 구성되어 있을때 보다 시스템에 문제가 생길 확률이 10배가 높아지게 된다. 또한 이 10대의 컴퓨터중에 한대라도 문제가 생긴다면 전체의 시스템이 문제가 발생하게 된다.

• 이런 문제를 해결하고자해서 나온 기술이 대용량 처리기술이다. 쉽게 말해서 컴퓨터가 스스로 샤딩과 유사한 작업을 하는데 스스로 데이터를 분산시키고, 오류로부터 데이터를 복구할 수 있어야 한다.

대용량 처리기술의 시초 : GFS(Google File System)

• 2003년도에 구글에서 발표한 Google File System 논문을 말한다.

• 막대한 양의 웹 문서를 저장하고 조회해야 하는데, 컴퓨터 한대로는 당연히 처리가 불가능하다. 그래서 다수의 컴퓨터를 이용하여 무제한 용량의 데이터를 처리하고자 함

• 비용을 줄이기 위해 저렴한 하드웨어를 사용하면서, 대신에 중복저장을 통해 파일의 유실을 막고자하였다.

• 예를 들어서 세대의 컴퓨터가 있다면 총 세번을 중복해서 저장하게 된다. 그렇게 되면 컴퓨터가 최대 2대가 한꺼번에 고장이 난다고해도 나머지 한대로 복구가 가능하다.

• 참고로 AWS S3도 GFS와 비슷한 구조라고 한다. 최대 7번 중복저장이 된다고 한다.

• GFS는 아무래도 검색엔진 회사에서 나온 기술이다 보니까 파일 새로 추가하는데 집중한 기술이다. 삭제나 파일 덮어쓰기는 상대적으로 구현이 덜 되어 있다.

• Latency보다 Throughtput을 중시하였다.

Latency와 Throughtput은 둘다 데이터 처리 속도의 개념이다.

1) latency : 사용자가 요청했을때 반응속도가 어떠한가. 예를들어서 수도꼭지를 틀었을때 물이 얼마나 빠른 시간내에 나오는가.

2) Throughtput : 수도꼭지를 틀었을때 물이 얼마나 콸콸콸 많이 나오는가.

• Throughtput을 중시한 이유는 ‘page rank algorithm’을 구현하기 위해서이다. page rank 알고리즘은 구글의 검색엔진을 지원하는 알고리즘으로 특정 키워드를 검색했을때 가장 상단에 어떤 검색결과를 보여줘야 하는지에 대한 알고리즘이다. 어떤 웹페이지가 특정 키워드를 입력했을때 중요하고 중요하지 않은가를 구분하냐면 웹페이지들을 쭉 나열해서 데이터베이스에 저장을 한다. 그 다음에 특정 웹페이지로 향하는 링크가 많이 있을수록 중요한 웹페이지라고 판단한다. 또한 이렇게 중요하고 공신력 있는 사이트에서 링크가 나가는 사이트도 중요한 사이트라고 판단한다. 비록 그 사이트로 향하는 링크가 적다고해도 불구하고..

• 따라서 수많은 웹페이지들을 데이터베이스에서 꺼내서 하나하나 확인하려면 Throughtput이 중요할 수 밖에 없다.

• GFS에서는 클러스터 댓수를 늘릴수록 저장용량과 Throughtput이 점점 증가한다.

• GFS 아키텍처

• 통상 마스터 슬레이브 구조이다. 마스터는 슬래이브한테 일을 시키고 일은 슬래이브가 하는 구조이다. 마스터라는 컴퓨터가 한대 있고, 청크서버라는 슬레이브가 여러대 있다.

• 예를 들어서 앱에서 File 1을 갖고오고자 할때 처음에 마스터한테 file 1이 어디에 있는지 물어본다. 마스터는 file 1이 어디에 있는지 알기 때문에 앱한테 file 1은 첫번째 청크서버에 있다고 알려준다. 그러면 앱은 첫번째 청크서버에 직접 접근해서 file 1을 가져온다.

• 위에 그림을 보면 알 수 있듯이 파일이 클 경우 청크단위로 쪼개서 저장하는 경우도 있다.

• 예를 들어서 유투브에서 상위랭크에 있는 동영상 데이터는 접근 소요가 많을 것인데 이렇게 분산해서 저장하게 되면 데이터 접근 소요에 대한 부하를 효과적으로 분산할 수도 있다.

대용량 처리기술의 시초 : MapReduce

• 2004년도에 구글에서 발표한 Google MapReduce 논문을 말한다.

• 여러대의 분산 저장소에 존재하는 데이터를 변환하거나 계산하기 위한 프레임워크다.

• Functional Programming을 적용하여 Map() 함수와 Reduce() 함수를 조합하면 세상에 존재하는 거의 모든 연산을 대용량 데이터가 저장되어 있는 분산환경에서 효율적으로 빠르게 잘 수행 할 수 있다는 개념이다.

• MapReduce 기술 안에는 shuffle() 함수도 있다. 쉽게 말해서 groupby를 해주는 함수라고 보면된다. 예를 들어서 그룹바이 국가별, 그룹바이 과일별 이런식으로..

• GFS와 Mapreduce는 페이지랭크를 효과적으로 처리할 수 있는 기반기술이다.

• Map() : A인 데이터를 B로 변환시키는 계산을 리스트에 대해 수행

• List(1,2,3).map(x => x * 2) // result: List(2,4,6)

• Reduce() : 리스트에 들어있는 A, B, C 를 특정 룰에 의해 합치는 작업

• List(1,2,3).reduce((a,b) => a + b) // result

• Map() 과 Reduce() 를 조합하면 다양한 작업을 수행할 수 있음

• 좌측에 동전같이 생긴것이 한대한대의 컴퓨터이다. 이 컴퓨터들에 저장되어 있는 데이터를 map이라는 오퍼레이션으로 뭔가 변환을 한 것이다.

• 구글맵리듀스 개념에서는 데이터를 키,벨류 구조의 데이터를 갖는다. 셔플이라는 것은 같은 키를 갖는 데이터를 모으는 것이다. 위의 그림을 예로 들면 파란색 키는 파란색 키끼리 모으고, 초록색 키는 초록색끼리, 노란색 키는 노란색끼리 모은다. 그리고 이 모은데이터로 같은 키끼리 리듀 연산을 해준다.

대용량 처리기술의 시초 : Hadoop

• GFS와 MapReduce 논문을 보고, Doug Cutting과 Mike Cafarella가 이를 실제 오픈소스로 구현한 것이 하둡이다.

• 하둡은 GFS와 맵리듀스를 둘다 갖고 있다. 하둡에는 그래서 GFS에 해당되는 HDFS와 MapReduce가 있다.

• 용어가 잘 정리되어 있지 않고 헷갈리게 되어 있는점이 아쉽다. 네임노드와 데이터 노드가 있는데 또 마스터와 슬레이브가 있다. 마스터가 데이터노드와 네임노드를 겸하고 있다. 마스터 컴퓨터안에 HDFS와 MapReduce가 같이 들어가 있다. 슬레이브 컴퓨터에는 HDFS의 데이터 노드 기능 그리고 MapReduce의 테스크 트레커 기능이 있다. 마스터 컴퓨터는 데이터노드와 테스크 트레커도 같이 갖고 있으면서 네임노드와 잡트레커 기능도 같이 겸한다.

• 잡트레커가 마스터 개념이고, 테스크 트레커가 슬레이브 개념이다. 마스터 워커가 여기서는 잡트레커, 테스크 트레커가 된것이다.

• 예를들어 회사에 어떤 팀이 있다면 마스터나 슬레이브가 모두 실무를 하는데 마스터가 팀장 역할을 겸직한다고 보면 된다. 다만 팀장으로서 해야할 일이 부하가 크지않기 때문에 부담이 없어서 실무를 같이하는 개념이다.

• HDFS에서는 청크단위가 아니라 블록단위로 파일을 보관한다. 참고로 블록은 64MB단위이다. Block을 여러 노드에 나누어서 보관 (3 Replica가 기본), 노드 장애시 오류를 내지 않고 대응 가능

• 클라이언트가 네임노드(마스터)한테 metadata ops에 특정파일이 어디에 있는지 물어본다. 그러고 metadata는 파일이름이랑 파일경로를 저장하고 있다. 이 메타데이터를 클라이언트에 알려주면 클라이언트는 마스터를 통해서 파일을 받는것이 아니라 데이터노드에 직접 접근해서 받는다. 직접받기 때문에 여러 클라이언트가 요청을해도 여러노드들에 분산되어 처리되기 때문에 부하가 한곳으로 몰리지 않는다.

• 그리고 데이터가 있으면 똑같은 데이터가 replication이 된다. rack은 서버실 같은데 보면 여러 서버가 하나의 책장처럼 되어있는 형태를 말하는데 그것을 서버렉이라고 한다. 서버렉 하나는 전원을 공유하기 때문에 서버하나만 고장날 수도 있지만 렉하나가 통째로 고장나는 경우도 있다. 그걸 대비해서 replication은 렉정보를 넣어줄 수 있다. 통상 그래서 다른 렉에 replication 될 수 있도록 설정할 수 있다.

• 하둡은 HDFS에 접근하는 다양한 옵션을 제공한다. 자바로 된 API도 있고, 파일시스템 쉘도 있고, 웹 어드민에서도 접근할 수 있다.

• AWS S3가 하둡을 참고해서 구현한것으로 추정된다.

최근대세 : Spark

• 맵리듀스가 성능적으로 느리기 때문에 하둡을 뛰어넘고자 하는 프로젝트들이 많이 나왔으나 거의다 죽고, 현재는 spark로 천하통일되었다.

• 분산처리 프레임워크로 메모리 기반의 처리를 통한 고성능과 Functional Programming 인터페이스를 활용한 편리한 인터페이스가 특징이며 최근에는 머신러닝분야에 집중하고 있다.

• 처음 출시될때는 메모리기반 처리를해서 고성능이고 Functional Programming 인터페이스를 써서 매우 편리하다는 특징으로 나왔다.

• Hadoop (MapReduce)는 매번 중간 결과를 디스크에 저장하지만, Spark은 이를 메모리에서 처리하므로 효율이 좋다. PageRank나 머신러닝 알고리즘같이 반복계산이 많은 경우 특히 성능이 좋은것이 특징이다.

• 여러번 연산을 해야하는 특정작업이 있다고 하면 그 특정작업의 결과가 나오기 위해 필요한 연산을 DAG라는 그래프에 해두었다가 만약에 연산중 에러가 발생하면 DAG에 기록해두었던 연산과정을 다시 끄집어 내어 처음연산과정부터 다시 계산하게 된다.

• 문제가 생겼을때 작업한것까지는 디스크에 저장해놓고, 작업하다 깨진 데이터들은 다시 마스터가 테스크를 할당해서 처리하고, 임시파일이 완성이 되면 그 다음단계로 넘어가는 장애복구 기능을 구현했다.

• 정리하자면 스파크가 효율이 좋은 이유는 매번 중간결과를 저장하지 않기 때문에 특히 파일을 한번 읽어서 쓰는 연산은 그렇게 빠르지는 않지만 페이지랭크나 머신러닝처럼 반복계산이 많으면 10배이상 빠르다는 점이 특징이다.

[ 그 밖에 많이 쓰이는 기술 ]

• Hive : sql 분석쿼리로 빅데이터를 처리하고 싶은데 맵리듀스를 구현하기 너무 힘드니까 나온 것이 하이브이다. sql로 분석쿼리를 짜면 하이브가 맵리듀스 코드로 변환을 해준다. 크게 인기를 끌었고 지금도 많이 쓰인다. 맵리듀스는 데이터 스키마를 갖고 있지 않기 때문에 하이브는 하이브 메타스토어라는게 있다. 거기에는 스키마 정보와 데이터 정보가 들어있다. Create table해서 파일정보 같은것들을 지정해주면 테이블 껍데기가 생성이되고 파일을 페이지 뷰라는 곳에 로딩을 한다. 그러면 하이브 클라이언트를 실행하면 sql로 그 특정파일에 있는 데이터를 읽거나 조회하거나 분석할 수 있다. 하이브의 단점은 속도가 느리다는 점이다. 그럴 수 밖에 없는 이유는 sql 쿼리를 입력하고 실행하면 하이브 엔진이 맵리듀스 쿼리로 변환을 해주는데 그 시간이 오래 걸리는 편이다. 자바형태의 실행파일로 변환이 되는데 또 이것을 실행가능한 형식으로 파일을 바꾸고 압축하고 전송하고 이런 과정이 있기때문에 또 그 과정에서 무슨파일이 어떻게 있는지 메타스토어를 확인해서 그걸 또 HDFS에서 읽고 맵리듀스 작업을 수행해야하기 때문에 느린편이다.

• 분산 데이터베이스(NoSQL) : Not Only SQL의 뜻으로 RDBMS와 비슷한 기능을 하는 것인데 기존의 RDBMS(관계형 데이터베이스)를 탈피한 비관계형의 분산 데이터베이스를 말한다. RDBMS는 말그대로 데이터들의 관계를 표현하는 데이터 베이스를 말한다. 시중에 수많은 NoSQL 프로젝트들이 있다. HBase, MongoDB, Couchbase, Redis 등이 대표적이고 사용 목적에 따라 필요한 기능이나 성능이 다르기에, 여러가지 데이터베이스가 골고루 사용되고 있는 것이 특징이다. 스케일 가능한 고성능 데이터베이스가 반드시 필요하지 않은 경우, RDBMS를 사용하는것이 좋은 선택일 수도 있다. RDBMS는 데이터 간에 관계를 엮어야 하기 때문에 병렬처리가 어려운점이 단점이다. nosql 제품들은 데이터베이스 하나를 갖고 데이터를 처리하는 것이 아니라 여러대의 데이터베이스를 이용해서 병렬처리를 해야하기 때문에 데이터간의 관계를 엮는것을 어느정도 포기하였다. 관계가 엮어 있으면 병렬처리가 어렵기 때문이다. 그래서 단순한 키벨류로 저장하게 된다. 릴레이션이 아니라. 통상 RDBMS로 처리하기 어려운 고성능이 요하는 연산을 할때 nosql을 사용한다.

• NoSQL의 대표주자 Apache HBase : 구글의 BigTable 논문을 구현한 것으로 HDFS위에서 동작하며 MapReduce 에서 사용할 수 있는 입출력 제공하는 하둡 생태계이다.기존의 데이터베이스 대비 기능이 제한적이지만, 클러스터에 컴퓨터를 여러대 붙이면 성능이 계속해서 올라가는 것이 특징이다. 페이스북 메신저, 비트윈 메신저 등 고성능 데이터베이스가 필요한 경우에 사용한다. 이런 메신저들은 데이터베이스에서 굉장히 큰 입출력 데이터 흐름이 특징인데 당연히 데이터베이스 한대로는 처리할 수 없는 양이다. 샤딩을 하려면 아주 관리하기가 힘드니까 Apache HBase는 이런 것을 자동으로 구성해주는 시스템중에 하나인 것이다. HBase는 컬럼 기반 데이터베이스인데 빅데이터 처리를 위해 유리한 데이터베이스라고 이해하면 된다. HBase도 마스터 슬레이브 구조이다. Master-Slave 구조, 데이터들이 Region (Key-value 를 영역에 따라 나눈 단위) 의 형태로 저장되어있다. 마스터 서버(주키퍼)와 슬레이브 서버(리전서버)가 있다. 클라이언트가 주키퍼한테 메타테이블 위치를 얻어내서 특정데이터가 어디에 있는지 알아낸 다음에 리전서버에 직접 접속해서 데이터를 얻어낸다.

• 스트리밍 기술 : 실시간으로 계속 들어오는 데이터들을 잘 처리하겠다는 기술이다. 이벤트 하나하나를 처리는 기술이다. Apache Storm, Spark Streaming이 대표주자이다. Spark Streaming은 이벤트 하나하나는 아니고 여러개를 모아놓고 처리하는데 수초단위의 짧은 단위로 모아서 처리를 해준다.

• 리소스 관리 플랫폼 : 최근의 유행은 파일저장과 파일처리를 분리한다. 과거에는 파일처리와 파일저장을 같이 했었다. 하둡만봐도 맵리듀스와 HDFS가 같이 존재하기 때문에 저장하는데서 계산까지 하는 것이다. 예를들어서 1번 컴퓨터에 저장된 데이터는 1번 컴퓨터에서 연산을 처리하고 2번 컴퓨터에 저장된 데이터는 2번 컴퓨터에서 연산을 처리하는 것이었다. 왜냐하면 네트워크에 제한사항이 컸기 때문이다. 최근에 네트워크가 발전하면서 이런 데이터가 저장된 곳에서 데이터를 처리하는 방식이 큰 의미가 없어졌다. 최근의 유행은 데이터를 저장하는 클러스터와 데이터를 처리하는 클러스터를 분리하는 것이 유행이다. 한 컴퓨터에서 하둡도 깔고 스파크도 깔고 여러가지 프로젝트를 하고 싶을때 리소스를 분배하고 관리하는 플랫폼이 필요하다. 이런 역할을 해주는 것이 리소스 관리 플랫폼이다. YARN, Mesos 가 대표적이다. 최근에는 도커에 스파크 클러스터를 띄우는게 대세이다.

• 데이터 수집기 : 많은 경우에는 서버에서 남기는 로그를 수집하게 된다. 클라이언트 앱 등에서 로그를 남기는 경우에도 서버에서 수합해서 로그를 남기는 구조로 웹사이트를 크롤하는 경우나, 센서 혹은 SNS에서 데이터를 모으는 경우에도 유사한 구조를 갖는다. 대표적으로 Flume이 있다. flume은 서버가 있고 서버에 소스를 붙어서 채널을 통해 싱크로 넘겨주면 싱크는 HDFS(또는 S3)와 연결되어 있는 구조이다. 매우 단순한 구조로, 몇가지 설정만으로 구동할 수 있는 것이 특징이다. 현재 최신유행은 카프카이다. 정의는 분산처리가 가능한 고성능 메세지 큐라고 되어있는데 많은 작업을 할 수 있다. 서버나 디비, 앱에서 데이터를 모아서 다른 앱으로 뿌려줄 수도 있다.

• Apache AirFlow : 데이터 workflow를 관리할 수 있는 툴이다. 파이썬 코드로 워크플로우를 설정할 수 있다. 태스크들로 directed acyclic graphs (DAGs) 를 만들어 수행한다. 유사한 기능의 툴로 크론텝도 있다.

• ETL이란 데이터를 어딘가에서 뽑아내서, 형태를 바꾸고(맵리듀스), 그리고 다시 저장을 하는 그런 작업을 말한다. 예를들어서 데이터베이스에서 데이터를 쭉 뽑은 다음에 관련된 데이터를 쪼인해서 다시 저장하는 것들