빅 데이터는 클라우드 컴퓨팅만큼이나 널리 확산되고 있는 개념이다. 그러나 빅 데이터의 역량과 한계에 관해서는 사람들이 잘못 알고 있는 부분들이 많다. 특히 빅 데이터와 관련해 사람들은 다음의 질문들에 대한 내용들을 제대로 이해하지 못하고 있다.
- 어떻게 기존의 데이터베이스들이 사실상 비관계형(non-relational)인 데이터 저장 엔진들과 함께 사용될 수 있는가?
- 관계형 DBMS(RDBMS)에서 분산시스템으로 데이터를 옮기려면 무엇이 필요한가?
- 조직 내에서 이런 빅 데이터 시스템들을 가장 잘 활용하기 위해 무엇을 알아야 하나?(IT 직원들이 관심을 보일만한 질문)
현재로는 비관계형 DBMS(NRDBMS)의 가장 인기있는 아파치 하둡(Apache Hadoop)가 가장 대표적이다. 분산형 데이터 프레임워크인 하둡은 빅 데이터와 소위 NoSQL 데이터베이스의 전형으로 여겨진다. 그러나 앞서 설명한 것들이 하둡의 실제 모습이나 그것의 작동 원리를 설명해주지는 않는다.
- 하둡은 진정 무엇이며, 기업들과 IT 직원들은 어떻게 활용할 수 있나?
- 어떤 기업들이 하둡을 이용해야 하며, 그것을 도입할만한 자원들은 어디서 구할 수 있나?
이런 질문에 대한 대답을 이번 하둡 총정리 기사를 통해 자세히 다룰 예정이다. 이번 기사에서는 주로 하둡이 어떻게 만들어지는지를 살펴볼 것이다. 하둡이 대체로 어떻게 작동하는지를 이해해야 DB 관리자들과 데이터 분석가들이 하둡 프레임워크를 이용해 일하는데 구체적으로 어떤 능력들을 필요로 하는지를 더 정확하게 파악할 수 있을 것이다. 또한 하둡의 생태계에 속해 있는 사람들을 알게 됨으로써 하둡 교육에 필요한 훌륭한 자원들을 찾아낼 수 있을 것이다.
하둡에 대한 오해
하둡에 대한 다음의 두 요소들은 분명하게 알아둬야 한다. 첫째 하둡은 빅 데이터에만 배타적으로 사용되는 시스템이 아니며, 둘째 진정한 의미의 NoSQL 툴도 아니다.
하둡이 비관계형 DBMS에 속하는 것은 맞지만, 그렇다고 SQL 쿼리 언어를 사용하지 못하는 것은 아니다. 이는 심지어 NoSQL의 의미로도 적절치 않다. NoSQL이란 SQL뿐 아니라 다른 쿼리 시스템도 사용될 수 있는 데이터베이스들을 표현하는 용어다. 사실 하둡에서는 SQL과 유사한 쿼리언어들을 상당히 쉽게 이용할 수 있다.
그리고 빅 데이터에 관한 다음의 개념도 수정돼야 한다. 많은 사람들은 하둡이라고 하면 방대한 양의 데이터부터 연상한다. 여기에는 물론 나름대로 합당한 이유가 있다. 하둡 저장공간은 누구나 막대한 양의 데이터를 떠올릴만한 페이스북과 야후가 사용하고 있기 때문이다.
그러나 하둡의 활용은 빅 데이터를 훨씬 넘어선다. 하둡의 가장 강력한 능력 가운데 하나는 바로 확장성이다. 이를 바탕으로 야후와 페이스북과의 관계를 유지하고 있을 뿐 아니라 얼마든지 규모를 축소시켜 저렴한 저장소와 데이터 관리를 원하는 기업들에게도 맞출 수 있다.
하둡의 이러한 광범위한 확장성 기능과 그 의미를 파악하기 위해서는 우선 하둡이 어떻게 작동하는지부터 이해해야 한다.
하둡이란 무엇인가
아룬 머시는 하둡을 아주 잘 아는 사람이다. 아파치소프트웨어재단(Apache Software Foundation, ASF)의 아파치 하둡 부사장인 아룬 머시는 현재 하둡 프로젝트를 이끌고 있다. 뿐만 아니라 머시는 더그 커팅이 구글의 맵리듀스(MapReduce) 데이터 프로그래밍 프레임워크를 활용해 하둡을 창안한 이후, 야후가 구글의 오픈소스 데이터 프레임워크를 자신들의 용도에 맞게 사용했던 초창기부터 하둡에 관여해왔다.
야후는 하둡의 생태계에 커다란 공헌 이상의 역할을 해왔다. 커팅과 머시, 그리고 초창기 하둡에 기여했던 많은 사람들이 지난 십 년간 야후에서 근무했다. 커팅은 현재 2009년에 시작한 상업용 하둡 업체인 클라우데라(Cloudera)에서 일하고 있으며, 머시는 2011년 6월 호튼웍스의 CEO가 된 에릭 발데슈빌러를 비롯해 야후의 하둡 팀에서 함께 근무하던 몇 명과 힘을 합쳐 호튼웍스(Hortonworks)를 공동 창업했다. 또한 야후는 현재까지 하둡의 최대 이용자며, 무려 5만 개의 노드로 구성된 하둡 네트워크를 배치하고 있다.
이런 경력으로 비춰볼 때 머시는 하둡이 무엇이고, 어떻게 만들어지는 지에 대해 답해 줄 적임자임이 분명하다.
머시는 필자에게 다음과 같이 설명했다.
"하둡이라고 알려져 있는 프레임워크는 몇 가지 구성요소들로 이뤄져 있는데, 그 가운데 특히 중요한 두 요소는 맵리듀스 데이터처리 프레임워크와 하둡 분산형 파일시스템(Hadoop Distributed Filesystem, HDFS)과 유사한 분산형 파일시스템이다.”
HDFS는 비록 관리가 항상 쉽진 않지만, 여러모로 하둡의 구성요소들 가운데 개념화하기가 가장 쉽다. 이름이 뜻하는 바대로 이해하면 된다. HDFS란 하둡 네트워크에 연결된 아무 기기에나 데이터를 밀어 넣는 분산형 파일시스템이다. 물론 여기에도 체계가 있어서 그냥 닥치는 대로 배치하는 것은 아니지만, RDBMS의 고도로 엄격한 저장 인프라에 견줘보면 돼지우리나 다름없다.
그렇지만 이런 유연성이야말로 하둡에 엄청난 가치를 가져다 준다. RDBMS가 종종 정교하게 제어하는 전용 기기들을 필요로 하는 것과는 달리 하둡 시스템은 보드에 좋은 하드드라이브가 거의 없는 상용화 서버들이라도 얼마든지 활용할 수 있다.
또한 하둡은 관계형 데이터베이스 테이블에 데이터를 저장하는 데에 따른 막대한 관리 비용을 들이지 않고, 그대신 HDFS를 이용해 데이터를 다수의 기기들과 드라이브들에 저장하며 다수의 노드로 이뤄진 하둡 시스템에 데이터가 자동적으로 중복되게 만든다. 따라서 만약 하나의 노드에서 고장이 발생하거나 느려지더라도 여전히 그 데이터에 접근할 수 있다.
이런 특성은 하드웨어나 관리 단계에서 엄청난 비용을 절약해준다. 한편 HDFS가 하둡과 함께 사용되는 일반적인 파일시스템이긴 하지만, HDFS가 결코 유일한 파일시스템은 아니라는 점에도 주목할 필요가 있다.
아마존의 엘라스틱 컴퓨트 클라우드(Elastic Compute Cloud, EC2)의 경우에는 하둡에 자사의 S3 파일시스템을 채용했다. 데이터스택스(DataStax)의 브리스크(Brisk)는 자칭 하둡 배포판으로, HDFS를 아파치 카산드라(Apache Cassandra)의 카산드라FS(Cassandra FS)로 대체하고, 실시간 저장 및 분석 기능들을 통합하기 위한 하이브(Hive)의 데이터 쿼리 및 분석 기능까지 추가로 포함하고 있다. 바로 이런 맞춤화와 변형은 전부 하둡의 오픈소스라는 특성 덕분에 쉽게 이뤄질 수 있었다.
맵리듀스는 개념화하기가 조금 더 어렵다. 머시는 그것을 데이터 처리 및 프로그래밍 패러다임이라고 표현했지만 이 말은 또 무슨 뜻일까? 젯(Jet)이 마이크로소프트 액세스(Microsoft Access)의 엔진인 것처럼 맵리듀스를 데이터베이스 엔진과 유사한 것으로 생각하는 편이 이해가 편하다(많은 사람들이 젯을 잘 생각해내지 못하겠지만 말이다).
정보 요청이 들어오면 맵리듀스는 두 요소들을 이용한다. 하둡 마스터 노드에 있는 잡트래커(JobTracker)와 하둡 네트워크 내의 각 노드에 위치한 테스크트래커(TaskTracker)들이다. 프로세스는 상당히 선형적이다. 맵리듀스는 데이터 요청을 별개의 작업 셋으로 나누고, 잡트래커를 이용해 맵리듀스의 일을 테스크트래커들에게 전달한다. 네트워크 지연시간을 줄이기 위해 작업은 해당 데이터가 위치한 노드와 동일한 노드에 할당되거나 최소한 같은 랙(rack)에 들어 있는 노드에 할당된다.
그림에서 볼 수 있듯 하둡에는 분산형 파일시스템과 맵리듀스 말고도 다른 것들이 포함되어 있다. 이 그림은 하둡 프레임워크에 대해 호튼웍스에서 제시한 설명으로 하둡과 함께 사용될 수 있는 여러 다른 구성요소들을 보여주고 있다. 여기에는 다음의 요소들이 포함된다.
- H카탈로그(HCatalog): 하둡 데이터용 테이블 및 스토리지 관리 서비스
- 피그(Pig): 맵리듀스용 프로그래밍 및 데이터 플로우 인터페이스
- 하이브(Hive): SQL과 유사한 언어인 하이브QL(HiveQL)을 이용해 하둡 데이터 쿼리를 생성하는 데이터 웨어하우징 솔루션
하둡 프레임워크
머시는 "하이브야말로 사람들이 소위 NoSQL 데이터베이스에서 기대하는 것보다 하둡을 훨씬 쉽게 이용할 수 있게 만들어 줄 것"이라고 말했다. 하이브QL을 이용해 데이터 분석가들은 RDBMS에서 이용하던 것과 거의 동일한 쿼리들을 가진 하둡 데이터베이스에서 정보를 빼낼 수 있다. 물론 SQL과 하이브 QL는 엄연히 다르므로 하둡으로의 이동은 일종의 이행기를 거치게 되겠지만 이 차이들은 그렇게 크지 않다.
하둡 전문가로 가는 길
데이터 분석가들은 하둡을 받아들이는데 큰 문제를 겪지 않겠지만, DBA들은 훨씬 많은 학습 과제를 짊어진다. 분산형 파일시스템은 RDBMS의 데이터베이스 테이블 스토리지라는 기존의 영역에서 완전히 벗어난 것이기 때문이다.
모두가 각기 다른 하둡 구성요소들의 프레임워크 구성이라는 말은 곧 관리자들이 서로 다른 수많은 요소들을 동시에 관리해야 함을 의미하므로, 장래 관리자들에게 하둡의 복잡성은 분명히 엄청난 장애물이 될 것이다. 물론 관리를 편하게 해줄 멋진 GUI를 기대해서도 안 된다. 하둡, 하이브, 스쿱(Sqoop), 그리고 하둡 생태계에 있는 기타 툴들은 모두 명령 행에서 제어를 받는다. 하둡이 자바 기반으로 만들어졌고, 맵리듀스가 자바 클래스들을 사용하고 있으므로 상호작용의 많은 부분들은 개발자(특히 자바 개발자)의 입장에서 다루는 편이 훨씬 편리할 것이다.
하둡과 관련된 대부분의 직업들은 일반적으로 대규모의 분산형 시스템을 다뤄본 경험과 시스템 설계 및 스케일링(scaling), 성능, 스케줄링(scheduling)을 통한 시스템 개발에 대한 정확한 이해를 요구한다. 자바에서의 경험뿐 아니라 프로그래머들은 데이터 구조와 병렬 프로그래밍 기술도 직접 다뤄보고 좋은 배경 지식들을 갖추고 있어야 한다. 여기에 종류를 불문하고 클라우드 경험은 큰 플러스 요인이다.
이런 것들을 한번에 모두 겸비하기는 어렵다. 따라서 하둡으로 옮기고자 하는 시스템 엔지니어들과 관리자들을 위해 호튼웍스는 아파치 하둡 관리하기 클래스(Administering Apache Hadoop class) 3일 교육 과정을 제공할 예정이다. 클라우데라는 이미 클라우데라 대학 커리큘럼(Cloudera University curriculum)의 일환으로 활발한 관리 수업을 열고 있다. 뿐만 아니라 하이브, 피그, 개발자 훈련 코스들도 들을 수 있다. 아파치 사이트의 하둡 지원(Hadoop Support) 위키에서 그 외 추가적인 수업들을 찾을 수 있다.
출처 - http://www.itworld.co.kr/news/73626?page=0,2
2016 SDS 그 유형과 소비 형태에 ...
스토리지 풀 개요 (Storage Pool)
