Skip to main content
QUICK REVIEW

[논문 리뷰] Evaluation of Codes with Inherent Double Replication for Hadoop

M. Nikhil Krishnan, N. Prakash|ePrints@IISc (Indian Institute of Science)|2014. 06. 26.
Advanced Data Storage Technologies참고 문헌 15인용 수 11
한 줄 요약

이 논문은 Hadoop에서 저장소 오버헤드를 줄이면서도 삼중 복제 수준의 신뢰성을 유지하는 내재적 双중 복제를 제공하는 두 가지 코드 설계—오각형 코드와 헤파곤-로컬 코드—를 평가한다. 스트라이프 블록이 동일한 노드에 공유되어 데이터 국지성 문제가 발생하나, 노드당 더 많은 프로세서를 사용할 경우 이중 복제 수준의 성능에 근접하게 되며, 코드 인식 태스크 스케줄링을 통해 성능 향상이 가능하다.

ABSTRACT

In this paper, we evaluate the efficacy, in a Hadoop setting, of two coding schemes, both possessing an inherent double replication of data. The two coding schemes belong to the class of regenerating and locally regenerating codes respectively, and these two classes are representative of recent advances made in designing codes for the efficient storage of data in a distributed setting. In comparison with triple replication, double replication permits a significant reduction in storage overhead, while delivering good MapReduce performance under moderate work loads. The two coding solutions under evaluation here, add only moderately to the storage overhead of double replication, while simultaneously offering reliability levels similar to that of triple replication. One might expect from the property of inherent data duplication that the performance of these codes in executing a MapReduce job would be comparable to that of double replication. However, a second feature of this class of code comes into play here, namely that under both coding schemes analyzed here, multiple blocks from the same coded stripe are required to be stored on the same node. This concentration of data belonging to a single stripe negatively impacts MapReduce execution times. However, much of this effect can be undone by simply adding a larger number of processors per node. Further improvements are possible if one tailors the Map task scheduler to the codes under consideration. We present both experimental and simulation results that validate these observations.

연구 동기 및 목표

  • Hadoop에서 내재적 双중 복제를 제공하는 코드 설계를 평가하여 저장소 오버헤드를 줄이고 신뢰성을 유지하고자 한다.
  • 동일한 노드에 공유된 코딩된 블록이 MapReduce 성능과 데이터 국지성에 미치는 영향을 평가하고자 한다.
  • 노드당 더 많은 프로세서 코어를 사용할 경우 코딩된 Hadoop 시스템에서 감소한 데이터 국지성의 영향을 어느 정도 상쇄할 수 있는지 조사하고자 한다.
  • 기본 지연 스케줄링보다 코드 인식 Map 태스크 스케줄링이 성능 향상에 기여할 수 있는지 탐색하고자 한다.
  • 삼중 복제, 이중 복제, 코딩된 설계 간의 저장소 효율성, 신뢰성, MapReduce 성능을 비교하고자 한다.

제안 방법

  • 오각형 코드는 XOR 패리티를 사용하여 9개의 데이터 블록을 20개의 코딩된 블록으로 인코딩하고, 5개의 노드에 분산 저장한다. 각 노드는 5개 노드로 이루어진 완전 연결 그래프에서의 인cidient 엣지에 해당하는 4개의 블록을 보유한다.
  • 헤파곤-로컬 코드는 최소한의 복구 대역폭으로 효율적인 국소 복구를 가능하게 하는 로컬 복구 가능 코드로, 분산 저장소에 적합하다.
  • 실험은 두 가지 Hadoop 설정을 사용하여 수행되었으며, 각각 25개의 듀얼 코어 노드(2개의 Map 슬롯)와 9개의 서버 레벨 노드(4개의 Map 슬롯)를 사용하였고, 블록 크기는 각각 128MB와 512MB였다.
  • Terasort 벤치마크를 사용하여 다양한 워크로드(25%에서 100%까지)에서 삼중 복제, 이중 복제, 두 가지 코딩 설계의 MapReduce 성능을 평가하였다.
  • 데이터 국지성, 작업 실행 시간, 네트워크 트래픽을 측정하고 비교하였으며, 초기에는 Hadoop의 기본 지연 스케줄러를 사용하였고, 향후 성능 향상을 위해 수정된 페링 알고리즘을 시뮬레이션하였다.
  • 시뮬레이션과 실제 실험을 통해 다양한 구성에서 데이터 국지성 추세와 성능 트레이드오프를 검증하였다.

실험 결과

연구 질문

  • RQ1내재적 双중 복제를 제공하는 코드 설계가 이중 복제 수준의 저장소 효율성을 확보하면서도 삼중 복제 수준의 신뢰성을 유지를 할 수 있는가?
  • RQ2동일한 스트라이프에서 유래한 여러 블록이 동일한 노드에 공유될 경우 MapReduce의 데이터 국지성과 실행 시간에 어떤 영향을 미치는가?
  • RQ3노드당 더 많은 프로세서 코어를 사용할 경우 코딩된 Hadoop 시스템에서 감소한 데이터 국지성의 영향을 어느 정도 상쇄할 수 있는가?
  • RQ4코딩된 환경에서 Hadoop의 기본 지연 스케줄러보다 코드 인식 Map 태스크 스케줄러가 성능 향상에 상당한 기여를 할 수 있는가?
  • RQ5중간 수준의 워크로드에서 제안된 코드 설계가 삼중 복제 대비 네트워크 트래픽과 작업 실행 시간 측면에서 어떻게 비교되는가?

주요 결과

  • 중간 수준의 워크로드(75% 이하)에서 오각형 코드는 특히 노드당 4개의 Map 슬롯을 사용할 경우 이중 복제 수준의 MapReduce 성능에 매우 가까운 성능을 달성하였다.
  • 노드당 2개의 프로세서 코어를 사용할 경우 관찰된 성능 저하는 주로 동일한 스트라이프에서 유래한 코딩된 블록이 동일한 노드에 공유되어 발생한 데이터 국지성 저하 때문이었다.
  • 오각형 코드와 헤파곤-로컬 코드의 네트워크 트래픽은 이중 복제보다 높았는데, 이는 주로 데이터 국지성 손실 때문이었으며, 코딩 오버헤드 때문이 아니었다.
  • 노드당 4개의 프로세서 코어를 사용할 경우 오각형 코드의 작업 실행 시간과 데이터 국지성은 75% 부하 조건에서도 이중 복제 수준에 근접하였다.
  • 시뮬레이션 결과 실험에서 관찰된 데이터 국지성 추세가 이론적 기대와 일치함을 확인하여 모델의 정확성을 검증하였다.
  • 본 연구는 향후 향상 조치, 예를 들어 태스크 스케줄링을 위한 수정된 페링 알고리즘의 구현이 이중 복제 수준의 성능 격차를 더욱 줄일 수 있을 것임을 시사한다.

더 나은 연구,지금 바로 시작하세요

논문 읽기부터 검토까지, 연구 시간을 획기적으로 줄여보세요.

카드 등록 없음 · 무료 플랜 제공

이 리뷰는 AI가 만들고, 인간 에디터가 검토했습니다.