Hadoop 3.0 무엇이 달라졌나???
1. Java Version
2. Erasure Coding 도입
Hadoop 2까지 Hadoop은 HDFS에서 Fault tolerance를 위해 Replication factor 3의 3배수 블럭 복제를 통해 데이터를 저장해 왔습니다. 이에 원천 데이터에 비해 3배의 저장 공간이 필요하게 되어 효율적인 인프라 구성에 있어서 큰 단점 중 하나였습니다.
그런데 이 부분에서 Erasure Coding을 도입하면서 상당부분 해결 가능할 것으로 보입니다.
Erasure Coding으로 인해 Hadoop 3버전은 지난 버전의 HDFS가 3배의 오버헤드가 발생한 것에 비해 1.4배 정도의 오버헤드로 상당한 공간 절약을 달성했습니다. Hadoop 3버전의 Erasure Coding은 Reed-Solomon 알고리즘을 사용합니다.
3. YARN Timeline Service v.2
YARN Timeline Service v.2에 대해 이야기 하기 전에 YARN Timeline Server에 대해 먼저 설명하자면,- 완료된 애플리케이션에 대한 일반적인 정보 관리
- 애플리케이션의 일반적인 정보로 queue-name, 유저 정보, 컨테이너 리스트 등과 같은 정보를 Resource Manager의 history store에 저장합니다. 그리고 저장된 정보를 Web-UI에서 보여줍니다.
- 애플리케이션의 일반적인 정보로 queue-name, 유저 정보, 컨테이너 리스트 등과 같은 정보를 Resource Manager의 history store에 저장합니다. 그리고 저장된 정보를 Web-UI에서 보여줍니다.
- 실행 중이거나 완료된 애플리케이션에 대한 per-framework 정보
- 애플리케이션 또는 프레임워크에 특정한 정보를 의미 합니다. Hadoop MapReduce를 예로 들면 map task, reduce task 수 등이 이에 해당 됩니다.
- Timeline Server에 TimelineClient를 사용하여 특정 정보를 올릴 수 있고 REST API를 통해 정보를 쿼리할 수 있습니다.
1) 데이터 쓰기와 읽기를 HBase를 활용하여 분산처리 함으로써 확장성과 신뢰성을 확보하였습니다.
[그림 출처. Apache Hadoop 3.0.3 Documentation - Yarn Timeline Service v.2 Architecture]
v.1 에서는 writer(timeline collecter)와 reader(timeline reader), 그리고 Storage가 한 개의 인스턴스로 제한되어 작은 클러스터에서 더 크게 확장할 수 없었습니다.
v.2의 경우에는 위의 아키텍처 그림에서 볼 수 있듯, writer(timeline collector)와 reader(timeline reader)를 분리합니다. Timeline collector는 각 YARN 애플리케이션 마다 AM(Application Master)과 같은 노드에 한 개씩 할당되며, timeline collector는 Storage로 표현된 HBase 클러스터에 각 애플리케이션 metrics/events 를 분산저장 합니다.
RM(Resource Manager) 또한 자기 자신의 timeline collector를 유지하면서 YARN의 일반적인 라이프사이클 등의 정보를 HBase에 저장합니다.
Timeline reader는 timeline collector와 분리된 별도의 데몬으로, REST API를 통해 받은 유저의 쿼리를 HBase로부터 조회하여 결과를 전달하는 서비스를 제공합니다.
2) flows와 aggregation을 통해 YARN 애플리케이션에 대한 단계별 정보를 확인하는 기능의 사용성을 개선하였습니다.
[그림 출처. Apache Hadoop 3.0.3 Documentation - Yarn Timeline Service v.2 entities modelling flows]
사용자들은 위 그림과 같은 YARN 애플리케이션의 flow 혹은 논리적인 레벨 수준의 정보를 알기를 원합니다.
이번 업그레이드를 통해 위의 flow 기준의 metrics에 대한 aggregation까지 지원하기 때문에 YARN 애플리케이션 들의 각 단계별 상태 정보를 수집/관리하고 최적화를 하는데 있어서 매우 도움이 될 것으로 생각됩니다. 그러나 현재는 security 기능이 미구현 상태이기 때문에 security가 중요한 요구사항으로 존재하는 환경에서는 해당 기능의 사용을 지양하는게 좋습니다.
4. Shell script Rewrite
Hadoop shell script는 오랫동안 가지고 있던 버그를 수정하고 새로운 기능들이 추가되었습니다. 하지만 반드시 확인해야 할 부분은 기존 설치된 쉘 스크립트 버전과 호환되지 않는다는 점 입니다.
5. MapReduce task-level native optimiztion
MapReduce 수행 시 셔플 과정에서 발생하는 Map Collector output의 정렬 부분을 C/C++로 구현한 native 프로그램을 JNI(Java Native Interface)로 호출하는 것을 지원하기 시작하면서 약 30% 이상의 성능개선을 이루었습니다.
6. Support for more than 2 NameNodes
Hadoop 2버전에서는 한개의 Active NameNode와 한개의 StandBy NameNode, 세개의 JournalNode로 HDFS HA를 구성하는 것이 가능하였습니다. 세 개의 JournalNode 쿼럼에 편집내용을 복제하면 이 아키텍처에서는 한개의 NameNode 장애까지 허용합니다.
그러나 점차 보다 높은 수준의 fault-tolerance가 요구되면서 Hadoop 3버전부터는 한 개의 Active NameNode와 한개 이상의 StandBy NameNode로 HDFS HA를 구성하는 것이 가능하게 되었습니다. 예를 들어 1개의 Active NameNode와 2개의 StandBy NameNode, 5개의 JournalNode로 HDFS HA가 구성되면 2개의 NameNode 장애까지 견딜 수 있는 아키텍처가 됩니다.
7. Default ports multiple service have been changed
Hadoop 서비스들이 사용하던 default port 들이 변경 되었습니다. 이전에는 Hadoop 기본 서비스들의 default port가 리눅스 임시 포트 범위(32768 - 61000)에 있어서 종종 다른 응용프로그램의 포트들과 충돌로 인해 서비스 포트 바인딩이 실패하는 경우가 있었습니다. 그런데 이번 Hadoop 3버전으로 업그레이드 되면서 이러한 Hadoop 서비스 default port 들이 리눅스 임시 포트 범위 밖으로 변경되었습니다.
변경된 포트
- Namenode : 50407 → 9871, 50070 → 9870, 8020 → 9820
- Secondary NN : 50091 → 9869, 50090 → 9868
- DataNode : 50020 → 9867, 50010 → 9866, 50475 → 9865, 50075 → 9864
8. Support for Microsoft Azure Data Lake filesystem connetor
Hadoop 3 버전부터는 Hadoop-compatible filesystem으로 Mrcrosoft Azure Data Lake 를 지원합니다. Azure Data Lake를 Hotonworks, Cloudera 플랫폼에서도 지원하고 있습니다.
9. Intra-datanode balancer
일반적으로 하나의 DataNode는 여러개의 데이터 디스크를 관리합니다. 그리고 특별한 상황이 발생하지 않는한 여러개의 디스크에 균등한 양의 데이터 쓰기 동작이 발생하게 됩니다. 하지만 추후에 데이터 디스크 추가와 같은 특수한 상황이 발생하면 하나의 DataNode 내에 디스크간 데이터 불균형이 발생합니다. Hadoop 2버전에서는 이러한 불균형을 핸들링 할 수 없었지만, Hadoop 3버전부터는 CLI에서 hdfs diskbalancer 명령어를 호출하는 것으로 해결할 수 있습니다.
10. Reworked daemon and task heap management
Hadoop 데몬들과 MapReduce 테스트들의 힙 관리에 대한 일련의 변경이 이루어졌습니다. 데몬 힙 크기를 구성하는 새로운 방법이 생겼으며, 특히 호스트의 메모리 크기에 따라 자동 튜닝이 가능해졌으며, HADOOP_HEAPSIZE 변수는 더 이상 사용되지 않습니다.
MapReduce는 Map 구성을 단순화 하고 테스크 힙 크기를 줄이므로 원하는 힙 크기가 더 이상 테스크 구성 및 Java 옵션 모두에 지정 될 필요가 없습니다. 기존에 구성한 설정은 이 변경사항에 영향을 주지 않습니다.
이외에도 여러가지 변경사항들이 생겼습니다.
좀더 자세한 변경사항에 대해서는 Apache Hadoop 공식 홈페이지를 통해 확인 하시면 됩니다.
