Chanhae Oh

빅데이터, 분석

Hadoop 3.0으로 변한 것들



http://hadoop.apache.org/docs/r3.0.0-alpha1/index.html

Minimum required Java version increased from Java 7 to Java 8

모든 Hadoop JAR 파일들이 Java 8으로 컴파일되었다. Java 7을 아직 사용 중이라면 Java 8으로 업그레이드해야 한다.

Support for erasure encoding in HDFS

Erasure encoding은 replication에 비해 storage를 크게 절약하면서도 데이터를 견고하게 저장할 수 있게 한다. 디폴트 3x 의 오버헤드를 가지는 기존 replication 방식에 비해 1.4x 정도로 오버헤드가 줄게 된다. 방식은 RAID에서 사용하는 Erasure encoding 방식과 동일하다. 파일의 데이터 저장은 3개의 디스크에 나누어서 이뤄지고 3개의 디스크에 저장된 bit들의 parity bit를 따로 저장한다. 나중에 3개의 디스크 중 하나에서 장애가 발생하면 나머지 디스크들에 있는 bit들과 parity bit를 사용하여 장애가 발생한 디스크의 bit를 복구하여 사용하는 방식이다. 이 방식을 기존의 서비스를 운영하는 시스템에 적용하려면 기존의 모든 데이터를 Erasure encoding을 적용하여 구성해야 하므로 그에 따른 비용을 고려해서 적용해야할 것으로 보인다. 그럼에도 불구하고 적용을 한 이후에 기존에 사용하던 시스템의 저장공간이 2배로 늘어나게 되므로 하드웨어 비용과 확장성을 봤을 때 정말 매력적인 기능이 되지 않을까 싶다.

YARN Timeline Service v.2

YARN Timeline Service v.2 에 대해 살펴보기 전에 YARN Timeline Server가 어떤 역할을 하는 지에 대해 알아보자. YARN Timeline Server는 YARN에서 실행되는 application의 현재 정보 및 히스토리 정보를 관리한다.

  • 완료된 애플리케이션들에 대한 일반적인 정보 관리 애플리케이션 레벨의 일반적인 정보로 queue-name, 사용자 정보, 컨테이너 리스트 등등으로 리소스 매니저에 의해 history-store에 저장된다. 그리고 web-UI에서 보여준다.
  • 실행 중이거나 완료된 애플리케이션의 per-framework 정보 애플리케이션 또는 프레임워크에 특정한 정보를 의미한다. Hadoop MapReduce를 예로 들면 map task, reduce task의 개수 등이 이에 해당된다.

  • Timeline Server에 TimelineClient를 사용하여 특정 정보를 올릴 수 있고 REST API를 통해 정보를 쿼리할 수 있다. YARN Timeline Server가 어떤 역할을 하는 지를 알아보았다. 그러면 v.2에 대해 알아보자. v.2는 v.1에 비해 scalability와 reliability가 향상되었다. 그리고 flow와 aggregation 정보를 제공함으로써 Usability 를 향상시켰다.

  • Scalability
    • v.1에서는 writer/reader 그리고 storage가 한 개의 인스턴스로 제한되어 작은 클러스터에서 더 크게 확장할 수가 없었다. v.2에서는 확장되고 분산된 writer와 storage를 사용한다.
    • Collector(Writer)와 reader를 분리한다. Collector는 각 YARN 애플리케이션마다 한 개가 할당된다. Reader는 분리된 인스턴스로 REST API를 통해 쿼리처리만 하도록 한다.
    • Backing storage로 HBase가 사용된다. 데이터 read/write는 HBase를 통해 이뤄진다.
  • Usability improvements
    • 사용자들은 YARN 애플리케이션의 flows 혹은 YARN 애플리케이션들의 논리적 그룹 수준의 정보를 얻기를 원한다. v.2에서는 이러한 정보들을 제공해준다.

Shell script rewrite

Hadoop shell script가 오랫동안 가지고 있던 버그를 수정함과 동시에 새로운 기능들이 추가되었다. 주의할 점은 기존 설치된 쉘 버전과는 호환성이 유지되지 않는다는 점이다. 자세한 사항은 Unix Shell Guide와 Unix Shell API 문서를 참고하기 바란다.

MapReduce task-level native optimization

Map Collector의 output을 내는 부분을 C/C++로 만들어 JNI를 통해 사용하도록 수정되었다. 본 수정으로 인해 셔플이 많이 일어나는 작업같은 경우는 30% 이상의 성능을 향상시키게 된다.

Support for more than 2 NameNodes.

기존의 HDFS의 고가용성은 하나의 NameNode에 하나의 Standby NameNode를 두고 edits 로그를 세 개의 JournalNode들에 저장하는 방식으로 사용되었다. 그러나 좀 더 높은 수준의 fault-tolerance가 요구되어지면서 다수의 Standby NameNode를 동시에 운영할 수 새로운 기능이 추가되었다. 예를 들어 3개의 NameNode와 5개의 JournalNode를 구성하면 해당 클러스터는 두 개 노드의 장애에 견딜 수 있게 된다.

Active NameNode는 1개이다.

Default ports of multiple services have been changed.

Hadoop 서비스에서 사용되던 디폴트 포트들이 수정되었다. Linux의 ephemeral port 범위(32768-61000)를 사용할 때, 서비스가 올라오면서 다른 애플리케이션과의 충돌로 포트에 바인드를 못하는 경우가 발생한다. 충돌이 발생하지 않게 디폴트 포트들이 다음과 같이 변경되었다.

  • Namenode ports: 50470 –> 9871, 50070 –> 9870, 8020 –> 9820
  • Secondary NN ports: 50091 –> 9869, 50090 –> 9868
  • Datanode ports: 50020 –> 9867, 50010 –> 9866, 50475 –> 9865, 50075 –> 9864
  • KMS: 16000 –> 9600

Support for Microsoft Azure Data Lake filesystem connector

Hadoop-compatible filesystem으로 Microsoft Azure Data Lake를 지원한다. Azure Data Lake라는 게 대략 살펴보니 클라우드 스토리지를 제공하면서 데이터 분석을 할 수 있게 해주는 서비스로 보인다. Azure Data Lake를 Hotonworks, Cloudera 플랫폼에서도 호환이 되도록 지원하고 있다.

Intra-datanode balancer

하나의 데이터 노드에서는 여러 개의 디스크를 관리한다. 정상적인 운영에선 디스크들에 동일한 데이터량이 쓰이게 되므로 문제가 없다. 그러나 디스크를 추가하거나 교체하게 되면 해당 데이터 노드에 심각한 데이터 불균형 현상이 발생하게 된다. 이런 현상은 HDFS balancer에서 처리되고 있지 않다. HDFS balancer는 inter- 에는 신경쓰지만 intra- 부분에 신경쓰지 않는다. 위와 같은 문제점을 처리하기 위한 “hdfs diskbalacer”라는 커맨드가 추가되었다. 해당 커맨드의 자셍한 내용은 HDFS Disk Balancer에서 확인할 수 있다.

Reworked daemon and task heap management

하둡 데몬들과 맵리듀스 태스크들을 위한 힙 관리 관련 일련의 수정이 이뤄졌다.

  • HADOOP-10950 => 데몬 힙 사이즈를 설정하는 새로운 방법을 소개한다. 호스트의 메모리 사이즈에 근거하여 auto-tuning이 가능하다. 그리고 HADOOP_HEAPSIZE는 deprecated 되었다.
  • MAPREDUCE-5785 => map과 reduce의 힙 사이즈를 설정을 단순화하였다. 따라서 Java option으로 map과 reduce의 힙 사이즈 설정을 해 줄 필요가 없어졌다. 기존에 존재하고 있는 설정은 이 변경사항에 영향을 미치지 않는다.