Hadoop Deep Inside 시리즈는 T-Academy의 하둡강의를 기반으로 진행합니다.
이 외에도 하둡 공식홈페이지와 여러 블로그, 커뮤니티들을 참조합니다.
또한, Deep Inside 시리즈는 spark, elk stack, kafka 등 사용한 경험이 있는 모든 tool들을 대상으로 확대해 갈 예정입니다.
0. 여는 말
빅데이터를 공부하는 사람이라면, 하둡이라는 소프트웨어는 한번 쯤은 들어 보셨을겁니다. 특히, 저처럼 데이터 엔지니어를 꿈꾸는 사람들에게는 나름 더 친숙할 겁니다. 데이터 파이프라인을 구축할 때 반드시 포함되는 프레임워크 중 하나이기 때문입니다.
당장 저같은 경우만 봐도 멀티캠퍼스의 데이터 엔지니어 과정 중에 세 번의 프로젝트를 진행하면서 하둡을 다뤄봤고, 개인적으로는 GCP 환경에서 고가용성 하둡 클러스터를 구축해본 경험이 있으니까요.
그럼에도 현시점의 저는, 누군가 하둡이 뭔지 말해 보라고 한다면 ‘데이터 분산 저장 및 처리하기 위한 프레임워크야…‘라며 대충 넘길 수준에 불과합니다. 이는 제가 무엇을 하는 지도 모른채 맹목적으로 사용하는데 급급했었기 때문입니다.
그런 점에서 저는 ‘처음이니까, 아직 시작한지 얼마 안됐으니까, 지금 프로젝트를 마치는게 더 중요하니까’라며 중요한 숙제들을 미루고 있었던걸지도 모르겠습니다. 그래서 제가 하둡을 싱글노드로 구축했던지, 클러스터로 구축했던지, 아니면 더 나아가 고가용성 클러스터를 구축하였던지 그런 것들은 별로 중요하지 않게되었습니다. 그런 경험보단, 하나를 하더라도 제가 올바르게 이해하고 사용했는지가 더 중요하다는 생각이 들어버렸으니까요.
저는 이제부터 Hadoop Deep Inside라는 시리즈를 통해 이제껏 미룬 숙제를 해보려합니다. 부디 제가 이 시리즈를 하나씩 끝맺을 때마다 ‘난 이 소프트웨어를 안다’라고 당당하게 말할 수 있는 사람이 되었으면 좋겠습니다.
1. 왜 하둡인가?
다양한 무료 강의들을 제공해주는 DataFlair라는 사이트에서 하둡을 배워야하는 핵심 이유 11가지를 선정.
이하 내용은 DataFlair을 번역하여 요약한 내용이고, 일부의 경우 다른 레퍼런스를 참고하여 내용을 추가한 부분이 있습니다. 또한 개인적 판단으로 불필요한 요소들은 타이틀만 적고 세부내용을 적지 않을 것입니다.
1) 빅데이터 관리(Managing Big Data)
우리는 데이터 홍수의 시대(2일마다 5엑사바이트의 데이터 생산)에 살고 있으며, 기하급수적으로 증가하는 데이터 양을 관리하기 위한 빅데이터 기술이 필요합니다. 그리고 강력한 아키텍쳐와 경제적인 기능을 가진 하둡은 방대한 데이터를 저장 및 처리하는데 가장 적합한 도구입니다.
2) 빅데이터 시장의 기하급수적인 성장(Exponential Growth of Big Data Market)
Forbes - “하둡 시장은 연 평균 42.1%로 2022년까지 99.31억 달러에 다를 것으로 예측.”
빅데이터 시장이 점점 성장함에 따라 빅데이터 기술에 대한 욕구도 증가했습니다. 하둡은 이렇게 생겨난 빅데이터 기술(spark, flink 등)들의 토대를 형성했습니다. 이러한 이유들로 하둡 전문가에 대한 수요도 계속 증가하고 있습니다.
3) 하둡 전문가의 부족(Lack of Hadoop Professionals)
하둡 전문가들에 대한 수요는 늘어나고 있지만, 여전히 하둡 전문가의 수는 부족합니다.
다양한 이유가 있겠지만 추려보자면,
- 하둡은 기본적으로 소프트웨어로 구성되어 있는 플랫폼
- 단순히 소프트웨어를 안다고 하둡을 잘할 수 있는게 아니라 TA(Technical Architect)의 역할에 해당하는 인프라 환경에 대한 지식도 필요함
- 엔지니어들을 SA, TA로 구분했으나, 하둡의 등장 이후 현재는 그 역할이 모호해짐
4) 모두를 위한 하둡(Hadoop for all)
다양한 분야의 전문가들은 쉽게 하둡을 배울 수 있습니다. 특히 IT 전문가들은 자바나 파이썬으로 MapReduce 프로그래밍을 쉽게 할 수 있고, 스크립팅을 아는 사람들은 Pig라는 하둡 에코 시스템에서 작업이 가능합니다. 하이브나 드릴도 마찬가지 입니다.
5) 강력한 하둡 에코시스템(Robust Hadoop Ecosystem)
하둡 에코시스템은 Governance, Finance, Banking, Insurance, Heathcare 등 사회 전반에 걸친 모든 요소들과 연관되어 사용되고 있습니다.
하둡 에코시스템에는 Hive, Hbase, Zookeeper, Pig 등 다양한 소프트웨어가 구성요소로 있습니다.
- Hadoop Mapreduce : 빅데이터의 집계와 요약 수행
- Hive : hdfs의 상위에 있는 Data Warehouse. SQL과 같은 인터페이스로 데이터 조회 및 분석을 제공
- Hbase : NoSQL Database
- Pig : 하둡과 함께 쓰이는 고급 스크립팅 언어. 모든 데이터 조작을 수행 가능.
- Zookeeper : 다양한 분산 프로세스 사이를 조정하는 서버.
6) 분석 도구(Research Tool)
7) 사용 편의성(Ease of Use)
하둡은 JAVA 기반이기 때문에 프로그래머가 쉽게 적응할 수 있습니다. 하둡 프레임워크는 백엔드에서 데이터의 모든 병렬처리가 이루어집니다. 그래서 사용자는 분산처리의 복잡성에 대해 걱정할 필요가 없이 코딩에만 집중하면 됩니다. 특히 spark가 등장하면서 Mapreduce를 사용했을 때보다 에코시스템 코딩이 더욱 쉬워졌습니다. 즉, 맵리듀스에서의 수천줄의 코드가 스파크에서는 단 몇줄의 코딩으로 가능합니다.
8) 하둡은 어디에나 있다(Hadoop is Omnipresent)
현 시점에서 빅데이터에 도달하지 못한 산업은 없습니다. 사람들은 점점 더 데이터의 존재를 인식하고 있고, 이는 사람들이 데이터의 힘을 깨닫기 시작했음을 의미합니다. 이미 페이스북, 월마트, 뉴욕타임스 등 거대 기업들에서는 하둡 프레임워크를 사용하고 있고, 앞으로 더 많은 기업이나 산업에서 하둡을 사용하게 될 것입니다.
9) 더 높은 급여(Higher Salaries)
10) 성숙하는 기술(A Maturing Technology)
하둡은 2007년 탄생한 이후, 현재까지 3번대 버전까지 나온 굉장히 성숙한 기술입니다.
11) 더 나은 커리어 범위(Hadoop has a Better Career Scope)
2. 하둡의 역사
1) 하둡의 탄생
하둡 프로젝트는 2006년에 본격적으로 시작됐지만, 원류를 따라가다보면 그보다 더 이전에 Apache Nutch라는 프로젝트가 있었습니다.
2002년 더그 커팅은 구글과 같은 검색엔진을 오픈소스로 만들어 보겠다는 목적 하에, Apache Lucene이라는 Information Indexing Library를 기반으로 오픈소스 웹 크롤러 프로젝트인 Nutch 프로젝트를 런칭했습니다. 그러나 그들은 곧 한가지 어려움에 직면했습니다. 검색 엔진을 만들기 위해 웹 크롤링을하고, 그 크롤링한 데이터를 저장한 다음, Lucene으로 색인하는 작업을 해야했는데 전세계의 수많은 URL과 그 데이터를 수집해서 색인하려면 굉장히 큰 양의 데이터를 분산, 병렬처리해야되는 이슈가 발생한 것입니다.
그 부분을 어떤 아키텍쳐를 구성해야 이러한 큰 데이터를 처리할 때 발생하는 문제점들을 해결할 수 있을까를 고민하던 그 때, 2003년 구글에서는 Google File System(GFS)라는 논문을 하나 발표합니다. 구글의 파일 시스템은 어떤 아키텍쳐와 원리로 동작하는지에 대한 이론이 담겨져 있는 논문이였죠.
더그 커팅은 이 GFS에 큰 영감을 받게됩니다. 그리고 이를 기반으로 너치 분산 파일 시스템(NDFS)을 개발하게 되는데, 이것이 후에 HDFS의 전신이 됩니다.
데이터를 분산 저장하는 문제는 NDFS로 해결을 했지만 여전히 이 분산된 저장된 데이터들을 병렬처리하는 문제는 해결하지 못했습니다. 이때 또한번 구글의 도움(?)을 받게되는데, 그건 바로 구글의 제프딘이 MapReduce라는 알고리즘을 페이퍼형태로 공개하면서 부터였습니다. 구글에서 큰 데이터를 분산처리하기 위해서 사용하는 이 알고리즘을 더그 커팅은 분산데이터 병렬처리를 위해 Nutch 프로젝트에 적용하려 시도했습니다. 이렇게, Nutch 프로젝트는 이 구글의 두 개의 논문을 근간으로 대규모의 데이터의 분산 저장 및 처리 기술에 대한 발전속도를 높히게 되는데, 이 과정에서 2006년 하둡이라는 이름이 Nutch 프로젝트의 서브프로젝트로서 등장하게 됩니다.
하둡 프로젝트는 Yahoo라는 글로벌 기업의 전폭적인 지원을 받으면서 더욱 성장했습니다. 실제로 이때, 더그 커팅은 yahoo에 스카우팅되어 일을 시작했습니다. 이 시점의 야후는 구글에게 검색엔진서비스 1위 자리를 빼았겼던 시기였기때문에, 하둡을 통해 다시 검색엔진서비스 분야의 왕좌를 되찾으려고 했습니다. 실제로 야후는 2007년, 1000개 노드로 구성된 하둡 클러스터를 서비스에 적용하는 등 적극적으로 지원 및 도입하기도 했습니다.
이 기세를 이어서 2008년, 하둡은 아파치의 top-level 프로젝트로 승격되어 Nutch 프로젝트에서 독립하게 됩니다. 그리고 하둡의 이름을 세상에 알리게 된 사건이 같은 해에 발생하는데, “Terabyte Sort Benchmark”에서 1TB의 데이터를 209초만에 정렬하여 이전 기록인 297초를 크게 앞서면서 우승한 일이 바로 그것입니다. 이 일은 실제로 Hadoop 역사에서 중요한 이정표로 평가받는데, Java 기반의 오픈소스 프로젝트가 벤치 마크를 획득한 것인 이번이 처음 이였기 때문입니다.
이후의 이야기들은 비교적 평이합니다. 2011년 1.0버전이 릴리즈되고 이듬해인 2012년 2.0버전이 릴리즈 됩니다. 2.0버전에서는 굵직한 변화가 있었는데, 다들 익숙한 yarn이라는 리소스 매니저를 패키지에 포함한 일과 네임노드의 이중화(고가용성)을 지원하게 된 일입니다. 이후 2017년에는 3.0버전이 릴리즈되었고 2022년 10월 6일 현재는 3.3.4버전이 가장 최신 버전으로 올라와 있는 상태입니다.
2) 구글 논문과 아파치 프로젝트
위의 ‘하둡의 탄생’ 글에서도 나타나지만 하둡을 비롯한 아파치 프로젝트들은 구글의 논문에 많은 영향을 받았습니다. 구글 파일시스템 논문을 보고 HDFS가 탄생했고, 구글의 맵리듀스라는 알고리즘 논문을 보고 하둡 맵리듀스 프레임워크가 탄생했듯이 말입니다.
이처럼 후에 서술할 하둡에코시스템을 구성하는 여러 프로젝트 중 하나인 Hbase 또한, 구글의 기술인 bigtable을 기반으로 만들어진 NoSQL류의 데이터베이스입니다.
Pig는 구글의 스크립트 랭퀴지인 Sawzall을 보고 만든 프로젝트입니다. HDFS에 저장된 데이터를 MapReduce 어플리케이션을 만들어서 처리할 수도 있지만 pig에서 지원하는 스크립트 신택스를 이용하여 그 데이터를 사용할 수 있도록 한 것입니다.
HIVE는 HDFS에 저장된 데이터를 SQL언어로 다루고 싶다는 욕구를 충족하기 위해 등장하였고, 이후 SPARK라는 프로젝트의 등장까지 이어졌습니다. 이제는 HIVE나 SPARK에서 HDFS에 저장된 데이터를 SQL같은 언어로 핸들링하는게 일반적이 되었을 정도로 많은 사람들이 이용하고 있습니다. 다만, 정형화되어 있는 데이터는 괜찮지만, 비정형 이나 반정형데이터를 처리하기는 어려워서 이 경우에는 여전히 MapReduce를 사용하게 됩니다.
3. 하둡에코시스템
최초 하둡 코어프로젝트가 등장하고 해를 거듭하면서 여러 프로젝트들이 등장했습니다. 이 프로젝트들은 모두 굉장히 큰 데이터를 처리 하기 위해 분산 데이터베이스, 분산 저장소와 연관된 플랫폼들과 같이 동작해야 되는 프로젝트였죠. 그리고 이러한 오픈소스 빅데이터 관련 프로젝트의 중심에는 언제나 하둡이 있었습니다. 하둡에 저장된 데이터를 어떻게 다룰 것이냐를 시작으로해서 이처럼 다양한 프로젝트들이 등장했고 이러한 하둡 코어프로젝트를 중심으로하는 이 서브프로젝트들을 통틀어 하둡에코시스템이라고 부르기 시작했습니다.
이 포스팅의 주제는 하둡이기 때문에 서브프로젝트들에 대해서는 간략하게 언급하고 넘어가도록 하겠습니다.
- Zookeeper : 여러가지 플랫폼을 가지고 분산환경의 데이터를 다루다보면 코디네이터 역할을 수행할 필요가 있음. 이 역할을 담당하는게 zookeeper
- Mahout : SQL같은 언어를 가지고 연산을 하는 건 굉장히 큰 데이터를 SQL내에서 지원을 하는 Internal Function, User Defined Function 등을 통해서 하게되는데 조금 더 복잡한 머신러닝, 인공지능 알고리즘을 처리하기 위해서는 별도의 알고리즘이 구현된 구현체가 필요. 이때문에 머신러닝 알고리즘을 하둡같은 분산저장플랫폼에서 처리할 수 있도록 구현되어 있는 구현체를 만들었는데 이것이 Mahout
- Sqoop : 하둡이 굉장히 큰 데이터를 다루는데 있어서 많이 사용되지만 여전히 관계형 데이터베이스들이 사용이 됨. 관계형 데이터베이스와 하둡 간 데이터를 주고 받는 경우들이 많이 발생하는데 그 것들을 쉽게 할 수 있도록 프레임워크로 구현해낸 것이 sqoop
- HCatalog : 하둡 에코 시스템의 데이터 처리 도구(Pig, MR, Hive)들 간의 테이블, 저장공간 관리 계층을 제공. 현재는 hive에 통합되어 hive metastore의 역할을 하고 있음
- Mrunit : Mapreduce 테스트하는 프레임워크
- Oozie : ETL 프로세스를 배치로 처리하기 위해서 여러 워크플로우를 거쳐야하는데 이러한 워크 플로우를 스케줄링하는 스케쥴러. 많이 사용이 되고있고, 요즘엔 Airflow를 쓰는 경우가 많아짐
4. 하둡이 변화시킨 흐름
1) 누가 “Big Data”라는 용어를 탄생시켰나?
시장 초기의 빅데이터는 “BIG“에 초점을 맞춘 하둡 중심의 기술용어에 불과했습니다. 실제로 초창기의 빅데이터는 그 자체로 하둡을 의미하기도 했을 정도입니다.
하둡의 등장 이후, 많은 데이터를 저장해야했던 기업들은 더이상 많은 데이터를 저장하기 위해 큰 비용을 지출하지 않게 되었습니다. 심지어 예전에는 저장비용이 비싸서 저장하지 못했던 데이터들을 저장하고 분석하기 시작했죠.
이러한 시장의 흐름이 생겨난 후, 많은 기업에서 오픈소스 빅데이터 플랫폼을 도입하기 시작했습니다. 그리고 비교적 최근에서야 Big Data 중 “Data“에 초점을 맞추고 있습니다. 즉, 이젠 많은 기업들이 데이터로부터 새로운 인사이트를 찾아서 새로운 사업기회를 만들고 많은 이윤을 남기기 위한 노력들을 하고 있다는 것입니다.
2) 이제는 DT와 AI의 시대
기술의 변화는 하둡과 같은 S/W분야에 한정된 것이 아닙니다. 컴퓨터는 점차 작아지고 저렴해지면서 동시에 성능은 증가하고 있습니다. 통신은 어디서나 싸게 이용가능해지면서 소위 ‘통신의 공기화’가 일어나고 있습니다.
이러한 변화들은 저렴한 물건들마저 똑똑해지고, 네트워크를 품기 시작했음을 의미하고 물건들끼리 통신을하고 판단을 하기 시작했다는 것을 의미합니다. 기록되지않던 것들이 기록되기 시작하고 모든 기기들이 데이터를 뿜어내고 있는, 데이터 홍수의 시대가 도래한 것이죠.
분석해야 될 데이터는 점점더 많아지고 데이터가 많아지면 경쟁은 어디에서 일어날까요?
하둡과 같은 오픈소스 빅데이터 플랫폼 기술이 발전하면서 데이터 저장 및 분석 인프라의 가격경쟁력이 확보되었습니다. 이에 따라 데이터 분석 역량이 새로운 가치창출의 기회를 만들어내는 시대가 됐습니다. 그러나, 넘쳐나는 데이터들을 분석가들이 모두 감당하기는 힘듭니다. 그래서 등장한 것이 머신러닝, 바로 생각의 아웃소싱이 일어난 것입니다.
알리바바의 마윈 회장 曰 “세상은 IT시대에서 DT시대로 옮겨가고 있다”
어디서 발생하는 데이터라도 쏘아 올릴 수 있는 자유롭고 빠른 통신
그렇게 발생한 많은 데이터를 받아들일 수 있는 충분한 클라우드
더 많은 곳에서, 데이터가 나오지 않던 곳에서 데이터가 나오게 하는 IoT
쌓여서 거대해진 데이터에서 숨은 패턴을 찾아내려 하는 데이터 분석
지능을 모사해서 데이터 분석의 능력과 수준을 끌어올리기 위한 인공지능
‘지금 사람이 원하는 데이터’를 생활에 바로 적용되기 위한 IoT
현재 수많은 기업들은 머신러닝에 집중하고 있습니다. 그리고 그 머신러닝을 위해 데이터 분석환경을 구축하기 위한 노력 또한 병행하고 있습니다.
어느정도 큰 회사에서는 다양한 부서에서 다양한 데이터 베이스를 사용하여 데이터 소스를 수집합니다. 그 외에도 다양한 외부소스(크롤링, API..)에서도 데이터를 가져옵니다.
그리고 이런 다양한 데이터 소스들을 데이터 웨어하우스 혹은 데이터 레이크라는 이름을 가진 통합 저장소에 ETL 과정을 거져 데이터를 저장합니다. 통합된 데이터는 현업담당자들의 니즈를 받아 유의미한 데이터로 가공되어 여러 데이터 마트로 만들어 지게 됩니다. 이렇게 만들어진 데이터 마트에서 여러가지 다양한 분석환경을 구성해서 유의미한 인사이트를 도출하게 됩니다.
물론 회사마다 조금씩 차이는 있겠으나 대부분 큰 틀에서 위와같은 흐름으로 분석환경을 구축합니다. 데이터를 저장하고 저장한 데이터에 대한 ETL처리를 통해 마트를 만들고 이 마트를 만드는 JOB에 대한 워크플로우를 관리하고 전체 코디네이터를 하고, 메타데이터를 관리하고 전체환경을 모니터링하고 통합하는 일들을 말이죠. 그리고 이 영역이 주로 하둡 에코시스템으로 구축된다는 것이 바로 제가 지금 하둡을 공부하고 있는 이유입니다.