.

CDH 클러스터에서 서비스 등록할때 HDFS 홈디렉토리에 유저만들듯이 계정정보(우지계정정보, 휴계정, 하이브계정, 스팍계정)를 만든다.

스팍 sql이 하이브에 사용하려면 스팍에 하이브 라이브러리가 있어야 한다. 이거를 우지에서 쓰고 싶다고하면 우지에서도 쉐어드 라이브러리라는 폴더에서도 스파크와 하이브 라이브러리가 있어야 한다. 이 쉐어드 라이브러리가 HDFS에 있다.

CDH에서 하둡 컴포넌트를 설치할때 우지를 등록하던 뭘 등록하던 우지를 쓰겠다고 하면 하이브 등록하고, 스팍등록하면 쉐어드라이브러리에 자르로 배포해준다.

CDH 클러스터를 설치하고, 관리한다하면 기본적으로 os의 requirement가 필요하다. 다시말해서 os에서 기본적으로 해야하는 것들은 physical 적인거는 제외하고, 기본적으로 사용해야 하는 소프트웨어를 먼저 체킹을 해야한다. 그리고 CDH 플랫폼에서 쓰는 SSH path를 설정해줘야한다. 이게 OS에서 기본적으로 해야하는 것들이고, 그 다음에 파일시스템(파일마운트 설정 등), 디스크, ebs에 대해서 백로그를 안남기는 설정(백로그를 남기지 않아야 속도가 빠르다)을 해주는 등의 사전 설정작업들을 해줘야한다. 이런 체크해야할 사항이 너무 많기 때문에 다 체크하는 것이 쉽지 않다. 단순히 CDH를 설치하는게 다가 아니라는 것이다.

보통은 ec2 하나 띄워놓고 한셋트 셋팅하고 기본이미지 떠서 노드들을 만들게 된다. (왜냐하면 동일하게 os 셋팅을 전부 해줘야 하기 때문에) 그래서 보통은 클러스터 관리를 위해 이런 이미지를 만약을 대비해서 미리 떠놓게 된다. 보통은 하둡 클러스터를 띄우기 위해 이런 이미지를 만들어주고 관리해주는 솔루션 업체가 있어서 이런 솔루션 업체에서 제공하는 이미지를 이용하는 경우가 일반적이다.

다시말해서 CDH 플랫폼 셋팅을 위해서 먼저 EC2 인스턴스들의 사전 준비작업이 끝나야하고(예를 들어서 os 차원의 커널값에 대한 페이징 설정 등), 기본 설치가 필요한 부분(예를 들어서 파이썬 패키지와 자바 external 라이브러리 등) 설치해준다. 그 다음에 CDH 매니저를 마스터 노드에 설치하고, 마스터 노드에 다른 노드들을 등록(노드 아이피, 이름 등록)을 하게 된다. 그러면 마스터 노드를 제외한 노드들에 에이전트가 설치된다. 그렇게 되면 마스터노드에 특정 하둡 어플리케이션을 등록하면, 어느 노드에 지정했는지 이런 현황들을 전부 확인할 수 있다. 노드리스트 및 서비스 목록 등을 통해 쉽게 확인할 수 있다.

QA) 하둡이 스파크 같이 서비스를 설치할때 특정 노드에다 특정 서비스를 설치해달라고 명령을 내리면 되는건지?

• CDH 매니저에 차체 신규서비스 등록 메뉴를 가면 클라우드애라에서 제공하는 서비스 목록을 전부 확인할 수 있다. 거기서 원하는 서비스를 확인 및 선택, 등록할 노드선택(어디어디 노드에 설치할지 선택(예를 들어서 우지를 선택한다 그러면 마스터 한대만 설치하면 된다. 우지에서 제공하는 분산서비스는 로우레벨의 우지가 제공하는 것이다. 우지는 execute하는 스케쥴링하는 오케스트레이션만(코디네이터만) 하는 툴이다.))하여 설치하면 된다.

QA) 그러면 스팍 서비스는 클러스터 노드가 5대 있다면 2대만 선택해서 설치하고 운영할 수 있는건지?

• 그렇게하면 스팍이 제대로 안돌아갈 것이다. 모든 잡(어플리케이션)들이나 MR이던 뭐던 플랫폼에서 명령을 클라이언트는 어디에 있어도 상관없다. 하지만 working은 전체노드에서 하던 특정노드에서 하던 그 결정은 job manager가 한다. job manager는 또 yarn에서 리소스를 확보한다. yarn은 클러스터에서 스팍이 어디에 있는지도 사실 모른다. 그래서 어떤 특정노드에서만 spark를 돌리고 싶다는 것은 말이 안된다.

• 내가 웹서비스를 위한 코드가 하나 있다고 치자. 이거를 고객들한테 제공할 서버를 구축해야 한다. 필요한 서버가 10대로 추정된다. 그러면 사전준비로 뭐가 있어야 할까. 이 코드를 실행시키기 위한 소프트웨어(was)가 있어야 한다. 10대 전부 밸런싱하게 서비스를 제공하기 위해 WAS는 10대 전부 셋업이 되야 한다. 그렇게 되면 와스가 서비스이다. 무슨말을 하고 싶냐면 WAS를 YARN이라고 보면 된다. 와스의 리소스 안에서 돌아가기 때문이다. 와스에서 예를 들어서 자바를 해석해주는 툴이 있는 것처럼 얀위에서 MR을 어떻게 처리할거냐에 따라 MR이 될거고 스팍이 될 것이고, 또는 하이브가 될 것이다. 그래서 서비스라고 보면 된다. 다시말해서 스팍이나 하이브나 이런 것들은 상위레벨의 개념일 뿐이다. 이 상위레벨이 돌아가기 위해 얀으로부터 리소스를 배정받아서 잡트레커한테 요청을해서 잡마스터가 분산을 고르게 돌려주게 된다. 이거를 와스에 비유하면 웹서비스가 디플로이 된것이다. 소스코드를 와스 10곳에 전부 뿌려줘야 된다는 얘기고, 이런 작업을 스파크에서 잡을 실행시킨다는 것이라고 생각하면 된다. 그 코드들이 네트워크를 통해서 시리얼라이즈하게 노드들에게 다 흩어지게 된다. 그러려면 상위레벨에 작업코드를 해석하고 어떻게든 돌아갈 수 있도록 해줘야한다. 하이브 렝기지로 쿼리를 날렸으면 하이브 엔진이 있어서 잡을 실행시킬 수 있도록 해줘야 한다는 것이다. 코드화하고 노드를 배정하고 돌아갈 수 있도록 노드별로 실행환경이 있어야 한다는 것이다. C로 치면 컴파일환경이 있어야 한다는 것이다. C를 자바에서 돌릴 수 없는 것처럼. -> 이말은 간단한 실행 executor에 필요한 라이브러리들을 노드들에게 다 올려놔야 한다는 것이다. 예를 들어서 와스라고 치면 와스 안에 라이브러리 이런 필요한 환경들이 전부 셋팅이 되어 있는 것이다. -> 분산시스템에서는 이런 작업들을 중앙의 마스터노드가 관리를 한다. 이렇게 할 수 있는 방법은 마스터노드에서 전체적인 하둡차원에서의 잡을 추적할 수 있는 잡 목록을 확인하고, 잡을 배정할 수 있고 있어야 한다. 스팍이면 스팍, mr이면 mr대로 job 히스토리를 따로 확인할 수 있다.(상위 레벨별로 확인하고 싶은것이 또 다르기 때문이다.) -> 그래서 서비스를 설치한다는 얘기는 돌아갈 수 있는 환경을 클러스터의 모든 노드에 똑같이 설치한다는 얘기다. 하이브를 예로 들면 하이브 중앙관제서버, 메타서버 이런것들은 마스터 서버 하나에 있으면 되고, 나머지 노드들(하이브 클라이언트들)은 execute할 수 있는 기본 라이브러리나 환경을 설치하는 것이다.

분산시스템은 중앙에 관제할 수 있는 노드와 나머지 잡을 실행하는 노드로 나눌 수 있다. 스팍이나 하이브 같은 상위레벨은 전부 이런식이다. HBase도 마찬가지이다. HBase 마스터(중앙 관제하는 노드, 데몬서버)가 따로 있고, 나머지 노드는 각각의 조각들을 관리하는 region서버라고 데몬이 따로 또 돌아가게 된다. 이 리전서버들이 안에서 자기가 할당받은 영역의 MR작업을 수행하게 된다. 그리고 작업을 완료하면 결과를 읽어서 반환하게 된다. 이런 MR을 읽어들이고 저장하고 해석하고 그 엔진이 서비스 별로 조금씩 다를 뿐이다. 이런식으로 분산시스템은 개론적으로 비슷한 형태다.

하둡 분산시스템은 위와 같이 레이어 차원에서 이해하면 된다고 했는데 이 의미는 또 중요한 점을 내포하고 있다. 레이어끼리 전부 상관이 있기 때문에 bottom 레이어의 config가 바뀌었다(예를들어서 HDFS의 블락사이즈를 조정했다, 얀에서 메모리 단위를 변경했다.(얀은 VM(컨테이너(was가 돌아가는 vm과 비슷한 개념)) 개념으로 이런 vm들을 하나씩 배정해서 돌아갈 수 있도록 환경만 제공해준다. VM의 메모리를 조정했다는 것은 그 VM 단위별로 자원의 제약이 있다는 것이다.) )고 치자. 어느날 스코프가 긴 디비테이블에 대해 where절도 긴걸로 하이브 쿼리를 날렸는데 뻗었다. 그러면 어디를 봐야하냐. 다봐야 한다. 하이브에도 하이브에 대한 메모리 설정이 있고(여기서는 하이브 차원에서 감당을 못한건지 확인하고), 그게 아니면 잡로그를 보고 얀에서 못받은건지 얀 컨테이너 설정도 확인해야 한다.

네트워크도 마찬가지다 카프카를 예를들자면 중앙관제하는 정보들을 관리하는 것을 주키퍼를 끼고 있는데 문제발생시 네트워크 관련된 모든 요소들을 확인해야한다.

하둡플랫폼 기본서비스들을 이해하려면 로우파일 레벨로 인터렉션 되는 과정을 머리에 그리고 나머지 각 데몬들 예를 들어 하이브는 하이브데몬 스파크는 스파크 데몬 이런것들의 인터렉션을 또 알고 있어야 한다.

하둡플랫폼을 버전업할때 가장 많은 요구사항은 이런 호환성 문제를 해결해달라는 것이다.

예를들어서 내가 하둡플랫폼에 스파크 2.3버전을 올리려고 하는데 이때 지원하는 하이브의 최소버전을 알고 있어야 스파크 sql을 올릴 수 있다는 것이다.

또하나 예를 들면 EMR에서 하이브를 두개돌렸더니 깨졌다. EMR에서 잡을 돌리면 자체적으로 한세트를 잘 만들어준다. config도 상호참조할 수 있도록 잘 만들어준다. 왜냐하면 EMR을 내부 검증하고 출시한것이기 때문이다. 그런데 이런 EMR의 잡을 안쓰고 클라우드애라같이 외부잡의 config(메모리 설정이라든지 버전 설정이라든지 외부참조 라이브러리 라던지)를 EMR에 주입시키면 안돌아갈 수 밖에 없다. 예를 들어서 버전이 안맞다던가 메타를 못찾는다거나 메타가 코럽 났다던가의 애러가 뜬다. 이런애러에 대한 대처도 사실 여러가지가 될 수 있다. 버전체크를 무시한다던지 아니면 스키마를 자동 생성할 수 있는 것을 스팍에 주입을 시킨다던지 config는 서버사이드 차원에서 바꿔야하는 것들이 있고, 클라이언트 차원에서 바꿔서 적용해도 되는것들이 있다. 이 둘의 범주가 다르다. 그래도 어플리케이션 차원에서 적용할 수 있는 것들은 편하다. 그냥 config 값을 바꿔주면 되기 때문이다.

버전 설정이 어려운게 하둡이나 하이브같은 것들이 버전업되면 컨피그 파라미터 이름들이 바뀐다. 언제는 맵이라고 했다가 언제는 맵리듀스라고 했다가 이런거는 버전에 따라 API가 변하기 때문이다.

그래서 하둡플랫폼을 버전업한다는 것은 정말 어려운것이다.

하둡플랫폼에서 다루는 데이터 사이즈나 형태도 항상 변동되지만 사용되는 어플리케이션들 역시 비지니스 환경이 변화함에 따라 또는 기타 요구사항에 따라 계속 변해야한다는 점도 엔지니어는 알고 있어야 한다.

이런 클러스터를 관리하는 관리자들은 리소스 풀을 통합적으로 관리하고 필요하면 리소스 풀을 필요한 곳에 배정하면 된다. 또는 최소한의 컨테이너 사이즈, 최대한의 컨테이너 사이즈를 잘 걸어줘야 한다. 이렇게 관리하면 컨피그가 또 변한다.

위치도 또 변할 수 있다. 타겟들의 정보도 변할 수 있다. 이런때는 보통 마이그레이션(이전)할때이다. 또는 하둡클러스터가 주구장창 헬시할 수 없을때도 마찬가지다.

또는 메타가 변경될 수도 있다. CDH 솔루션들이 좋은게 내가 변경한 config항목이 어느 서비스와 연관이 있다는 것을 미리 알고 있다. 그래서 만약에 사용자가 컨피그를 변경하면 어떠어떤게 연관이 있다고 얼랏을 전시해준다. “이것도 변경해줘야합니다”라고. 심지어 “이 컨피그 바꿨으니 리스타트 해줘야합니다”라는 것도 알려준다.

클라우드 애라 매니저에서 빨간불이 뜬다 뭐가 얼랏이 뜬다가 다 이런얘기다. 이런 얼랏이 뜬건 이유가 있어서 뜬 것이고 전부 알맞게 조치를 해줘야한다. 예를 들어서 얀 컨피그가 변경되었으면 얀만 리스타트하면 되는게 아니고 얀을 참조하는 것들까지 컨피그를 배포하겠냐고 얼랏으로 물어보게 되는데 그걸 무시하고 계속 쓰고 있었던 것이다. 반면에 EMR은 그런 기능이 없어서 수동으로 다 해줘야한다는 것이 어렵다.

하둡 클러스터 내에 애코서비스들이 복잡하게 존재할수록 어디에 무슨놈이 참조하고 있는지 알기가 힘들어진다. 그래서 CDH manager, 암바리 같은 툴을 쓰게 되는것이다. CDH와 암바리의 차이는 소프트웨어적으로는 navigator라는 기능의 차이가 있다. CDH에 있는 기능인데 navigator는 데이터에 대한 추적이 가능하다. 어디서 흘러와서 어디를 거쳐서 변형되고 어디로 흘러갔다라는 것을 추적할 수 있는데 유료다.

그 외에 나머지 기능들 예를들어 클러스터 장애복구(백업하고 리스토어하는 기능) 등이 있는데 엔터프라이즈 차원에서 제공하는 기능들이다.

이번에 과제중에 하나가 하이브와 스파크를 분리하는건데 하이브는 가끔씩 사용하고 스파크는 상주용으로 사용하기 때문에 분리하고 싶다는것은 좋다. 그러나 문제는 config를 서로 어떻게 교환할거냐의 문제이다. 스파크는 하이브 메타스토어를 사용해야 한다. 메타가 어디있는지 JDBC URL과 거기서 쓰는 데이터에 대한 포맷정보가 저장되어 있는 곳인데 앤진해석서라고 할 수 있다.

그런데 스파크는 하이브에 dependency 되어있다. 그러면 하이브가 변경이 되면 변경사항을 스파크와 어떻게 맞춰줄 것인지 config를 어떻게 스파크로 배포할 것인지 이게 문제다. config 배포는 수동으로 할 수 밖에 없다. 클라우드 포메이션에 참조되는 config 파일에 참조를 시켜놓던 정적으로 클라우드 포메이션에 기입을 하던지 하이브가 변경이되면 이런식으로 조치를 해줘야한다.

이게 EMR의 문제점이다. EMR은 고정으로 쓰는게 아니다. 언제 쓰는거냐면 내가 스파크나 하이브등의 어플리케이션 속성들을 다 알고 튜닝값도 얼고 있다. 리소스도 얼마나 쓸지 알고 있다. 그리고 잡을 최소한 얼마나 배정해야하는지도 알고 있을때 EMR 클러스터를 산정해서 올리고 잡을 sumit해서 돌리는 것이다. 다시말해서 내가 사용하는 하둡클러스터에 대해 현황을 잘 알고 있어야 한다는 것이다. 자원이 유동적으로 변하는데 왜 static하게 운영하는지 모르겠다고 생각이 든다면 EMR쓰는것도 좋은 옵션이다.

CDH 클러스터 설치개요

1. EC2 자원산정 사전에 내가 띄우고자 하는 하둡클러스터애 필요한 리소스가 얼마나 되는지 산정한다. 자원산정 시 CDH의 도큐먼트를 보면서 이해하는 것이 중요하다.
2. 네트워크 및 OS 설정 yum 레포에 대한 정보가 클라우드애라에 있기 때문에 ,os에 yum레포 설정해주고, 자바나 파이썬같이 필요한거 설치해준다.
3. 커널설정 도큐먼트 지시사항에 따라 조치
4. cloudera yum repo해서 경로 잡아주고, 윰업데이트하고 yum install하면 쭉깔린다.
5. 클라우드애라 매니저 설치하면 매니저로 접속해서 거기서부터는 UI로 작업을 하면된다.

CDH 클러스터 설치할때 자원산정하는것이 중요하다.

잡을 하나만 돌리면 제한사항이 없다. 클러스터가 가동할 수 있는 모든 얀 리소스를 다 줄수 있다. 잡이 여러개가 있다 그러면 잡이 돌고있으면 그 다음 잡은 대기큐가 되는 형태로 시리얼라이즈하게 잡이 돈다. 근데 나는 잡을 병렬로 돌리고 싶다. 그러면 ‘다이나믹 리소스 풀’로 가서 리소스를 절단을 시켜야 한다. 잡에다가 잡큐네임을 또 부여해줘야한다. a잡큐는 리소스풀을 얼마써, b잡큐는 리소스 얼마써 할당해 줄수 있다. 이 설정을 글로벌 config에 설정할 수도 있고, 아니면 잡마다 다이나믹하게 줄수도 있다.

하둡클러스터는 이기종간의 시스템들을 하나에 다 뭉쳤다고 생각하면 된다.

클라우드에서 제공하는 변동자원들 EMR같은 다이나믹한 자원은 용도를 정확하게 아는것이 중요하다. EMR = 하둡클러스터라고 단정지으면 안된다.

임팔라는 특정 케이스에 대해서 DML이 많은 편이고 그거를 각 클러스터나 연계시스템에서 sync를 맞춰야 한다. 스팍에서 변경한 테이블들 하이브에서 바꾼 테이블들, 아니면 클라우드애라에서는 그 권한 관련해서 centry라는 통합관제 시스템이 있다. 하이브는 하이브의 메타에 유저정보와 그란트 정보가 다 있는것처럼 클라우드애라 클러스터는 센트리라는 통합관제 시스템에 중앙관제시스템에 HDFS 권한시스템, 각 컴포넌트의 권한시스템이 있어서 만약에 해당 클러스터 내 하이브에서 참조해서 쓰고 싶다면 정보를 하이브에 내려줘서 sync를 맞춰주는 방식으로 제공할 수도 있다. 임팔라도 임팔라가 각노드에서 갖고 있는 메타정보가 있다. 그걸 감지해서 보내주는 status 서버가 또 따로있다. DML이 자주 일어나게 되면 이런 역할을 하는 서버들의 sync를 맞춰주는 작업이 매우 어려워진다. DML작업 그란트주고, Create table , alter table이런거를 계속 막주게되면 서버들의 상태에 이상이 생기게 된다.

분산시스템에서 동기화를 할때는 블락킹을 쓰게된다. 어떤 하나를 주문통제를해서 블락킹을 시켜버리고, 한놈만 배정을 해준다. 세마포어든 뭐든. 고놈만 건들이고 풀고 블락킹걸고 나중에 변경된거 반영하고 또 푸는 이런방식이다. 그런데 동기화가 잘못걸리면 문제가 커진다. 같은 os에 있으면 상관없는데 특히 네트워크가 걸쳐있으면 더욱 그렇다. 예를들면 이런상황이다 하나가 깨져버리면 동기화가 깨졌다고 감지를 하고 로컬에 플러쉬하고 동기화할 준비를 하는데 블라킹 당해버린다. 순간의 차이로 동기화가 꼬여버릴 수 있다는 말이다. 메카니즘을 짜기가 매우 어렵다. 티어(고리)가 하나만 더 들어가도 어려워진다. 이런점이 임팔라의 문제점이다.

그래서 하둡으로 뭐 다된다고 무조건 좋다고 얘기하는 것은 사기다. 예를 들어서 프레스토를 쓰면 다른서비스들과 연계가 잘되는거라 좋다, 이기종 데이터를 다 땡길 수 있으니 무조건 좋다고 말하면 안된다는 것이다. 프레스토의 장점을 얘기함과 동시에 메모리 한계가 있다, 큰데이터를 긁어올 수 없다 로컬에 상주시키고 쪼인하기 때문에, 복합적인 쿼리 및 쿼리 내에서의 한계가 표준 sql과 다를 수 있다 등등 이런 단점을 명확하게 설명할 수 있어야 한다.

[기타 참고사항]

우지는 하둡 컴포넌트를 스케쥴링을 할 수 있다.

빅데이터 PF EMR

• 데이터 자체가 External에 있음

• 메타스토어도 오로라 디비를 쓰고 있음

[CDH 설치개요]

• 클러스터 노드 간 host등록

AWS EC2를 쓰는경우 내부 아이피가 등록되어 있기 때문에 안해도 무방

$ vi /etc/hosts

## 아래와 같이 아이피주소와 호스트 네임을 등록한다.
<노드 1의 아이피주소>  <노드 1의 호스트네임>  
<노드 2의 아이피주소>  <노드 2의 호스트네임>
<노드 3의 아이피주소>  <노드 3의 호스트네임>

• selinux 해제

$ vi /etc/sysconfig/selinux
    SELINUX=disabled
    
    ### SELINUX값을 disabled로 변경

• firewall 해제

$ systemctl stop firewalld 
$ systemctl disable firewalld 

## selinux 해제하고 firewall 해제한 다음에 시스템 reboot할 것

• vm.swapless disable

• ipv6 설정파일에서 disable

EX) sysctl -w net.ipv6.conf.all.disable_ipv6=1 sysctl -w net.ipv6.conf.default.disable_ipv6=1

• huge paging disable

• yum update -y

• Cloudera yum repo 추가

$ yum install yum-utils -y
# yum-config-manager 명령어를 못 찾을때 위와 같이 먼저 추가할 것

$ yum-config-manager --add-repo https://archive.cloudera.com/cm5/redhat/7/x86_64/cm/cloudera-manager.repo

$ yum-config-manager --enable cloudera-manager

• oracle java1.8 이상은 수동설치필요 (optional) , 설치 후 java home 환경변수 설정

(자바는 반드시 오라클 자바를 설치해야 함)

• yum으로 mysql connector 설치

(어떤 디비를 쓰냐에 따라 그거에 맞는 connector를 설치하면 된다)

• EC2 루트계정 활성화 및 ssh 접속 가능하도록 설정

$ sudo vi /etc/ssh/sshd_config 

## PermitRootLogin 의 주석을 풀어주고 저장

$ sudo cp /home/ec2-user/.ssh/authorized_keys /root/.ssh
 
$ sudo service sshd restart

• cloudera-manager 설치 : cloudera-scm-server-db가 먼저 실행되어야 cloudera-manager-server가 잘 실행된다.

$ yum install cloudera-manager-daemons cloudera-manager-server cloudera-manager-server-db-2 -y

$ service cloudera-scm-server-db start

$ service cloudera-scm-server start

• 외부 db 이용시 경로설정 (optional)

• http://<마스터노드IP>:7180/ 로 접속해서 웹UI로 이제 작업하면 된다.

Agent 호스트 검색 -> Parcel 선택 -> Agent Java 설치 -> SSH 로그인 정보 -> Install Agents -> 선택한 Parcel 설치 -> 호스트 정확성 검사 -> Select Service -> 역할 할당 사용자 지정 -> 데이터베이스 설정 -> 변경내용 검토 -> 실행

모니터 서비스 설치필요한데 그 전에 모니터서비스를 위한 디비가 또 필요함

관제모니터 서비스(CDH Management service)를 설치하고, 여기에서 쓰는 db설정을 또 해주고, 각 노드에 호스트 등록도 해줘야 한다.

서비스 설치하는 것도 순서가 있다. zookeeper -> HDFS -> …

서비스 디펜던시를 잘 고려해서 순서를 잘 맞춰서 설정해줘야 한다.