하둡에서 클라우드로: 빅데이터 플랫폼에서 스토리지와 컴퓨팅을 분리하는 이유와 방법

튜토리얼
Hadoop

아파치 하둡 분산 파일 시스템(HDFS)의 등장은 기업의 데이터 저장, 처리 및 분석에 혁신을 가져왔으며, 빅데이터의 성장을 가속화하고 산업에 변혁적인 변화를 가져왔습니다.

초기에 하둡은 저장과 계산을 통합했지만, 클라우드 컴퓨팅의 출현으로 이 구성 요소들이 분리되었습니다. 객체 저장은 HDFS의 대안으로 등장했지만 한계가 있었습니다. 이러한 한계를 보완하기 위해 JuiceFS, 오픈 소스, 고성능 분산 파일 시스템은 계산, 분석, 훈련과 같은 데이터 집약적 시나리오에 대한 비용 효율적인 솔루션을 제공합니다. 저장-계산 분리를 채택하는 결정은 확장성, 성능, 비용, 호환성과 같은 요소에 따라 달라집니다.

이 기사에서는 하둡 아키텍처를 검토하고, 저장-계산 분리의 중요성과 타당성을 논의하며, 시장에서 제공되는 솔루션들을 탐색하고, 각각의 장단점을 강조합니다. 우리의 목표는 저장-계산 분리 아키텍처 변환을 겪고 있는 기업에 통찰력과 영감을 제공하는 것입니다.

하둡 아키텍처 디자인 특징

하둡: 일체형 프레임워크

2006년, 하둡은 세 가지 구성 요소로 구성된 일체형 프레임워크로 출시되었습니다:

  • 계산을 위한 MapReduce
  • 자원 스케줄링을 위한 YARN
  • 분산 파일 저장을 위한 HDFS
Core components of Hadoop

다양한 계산 구성 요소

이들 세 가지 구성 요소 중에서 연산 계층은 급속한 발전을 이룩했습니다. 처음에는 단지 MapReduce만 있었지만, 곧 테즈와 스파크와 같은 다양한 연산 프레임워크, 데이터 웨어하우스용 하이브, 프로스트와 인팔라와 같은 쿼리 엔진이 등장했습니다. 이들 구성 요소와 함께, Sqoop과 같은 다양한 데이터 전송 도구들도 있었습니다.

Diverse computation components

HDFS가 스토리지 시스템을 지배했습니다

약 10년간, HDFS라는 분산 파일 시스템은 지배적인 스토리지 시스템이었습니다. 거의 모든 연산 구성 요소에 대한 기본 선택지였습니다. 빅데이터 생태계 내의 위에서 언급한 모든 구성 요소들은 HDFS API를 위해 설계되었습니다. 일부 구성 요소는 HDFS의 특정 기능을 깊이 활용합니다. 예를 들어:

  • HBase는 HDFS의 저지연 쓰기 기능을 사용하여 쓰기 전 로그를 처리합니다.
  • MapReduce와 Spark는 데이터 지역성 기능을 제공합니다.

이러한 빅데이터 구성 요소들의 설계 선택, HDFS API를 기반으로 하는 것은 클라우드에 데이터 플랫폼을 배포하는 데 있어 잠재적인 과제를 야기했습니다.

스토리지-계산 결합 아키텍처

다음 다이어그램은 컴퓨팅과 스토리지를 결합한 단순화된 HDFS 아키텍처의 일부를 보여줍니다.

Hadoop 스토리지-컴퓨팅 결합 아키텍처

이 다이어그램에서 각 노드는 데이터를 저장하기 위한 HDFS DataNode로 작동합니다. 또한 YARN은 각 노드에 Node Manager 프로세스를 배포합니다. 이를 통해 YARN은 해당 노드를 계산 작업을 위한 관리되는 리소스 중 일부로 인식할 수 있습니다. 이 아키텍처를 통해 스토리지와 컴퓨팅이 동일한 기계에서 공존하며 계산 중에 디스크에서 데이터를 읽을 수 있습니다.

왜 Hadoop은 스토리지와 컴퓨팅을 결합했나요

Hadoop은 설계 단계에서의 네트워크 통신과 하드웨어의 한계로 인해 스토리지와 컴퓨팅을 결합했습니다.

2006년에는 클라우드 컴퓨팅이 아직 초기 단계에 있었으며, Amazon은 첫 번째 서비스를 방출한 지 얼마 되지 않았습니다. 데이터 센터에서 주로 사용되는 네트워크 카드는 대부분 100 Mbps에서 작동했습니다. 빅 데이터 작업에 사용되는 데이터 디스크는 약 50 MB/s의 처리량을 달성했으며, 네트워크 대역폭으로 환산하면 약 400 Mbps입니다.

한 노드에서 최대 용량으로 작동하는 여덟 개의 디스크를 고려할 때, 효율적인 데이터 전송을 위해 여러 기가비트 이상의 네트워크 대역폭이 필요했습니다. 불행히도, 네트워크 카드의 최대 용량은 1 Gbps로 제한되어 있었습니다. 그 결과, 노드 당 네트워크 대역폭은 노드 내 모든 디스크의 능력을 완전히 활용하기에 부족했습니다. 따라서 계산 작업이 네트워크의 한쪽 끝에 있고 데이터가 다른 쪽 끝에 있는 데이터 노드에 있는 경우, 네트워크 대역폭은 상당한 병목 현상이었습니다.

스토리지-컴퓨팅 분리의 필요성

2006년부터 2016년 쯤까지 기업들은 다음과 같은 문제에 직면했습니다:

  • 애플리케이션에서의 컴퓨팅 능력과 스토리지의 수요가 불균형하게 되었으며, 그 성장률이 다릅니다. 기업 데이터는 급속히 성장했지만, 컴퓨팅 능력의 필요성은 그렇게 빠르게 성장하지 않았습니다. 인간이 개발한 이러한 작업들은 단기간에 기하급수적으로 증가하지 않았습니다. 하지만 이러한 작업에서 생성된 데이터는 빠르게 축적되었으며, 기하급수적인 방식으로 증가할 수 있었습니다. 또한, 일부 데이터는 기업에 즉시 유용하지 않을 수 있지만 미래에는 가치가 있을 것입니다. 따라서 기업들은 데이터를 포괄적으로 저장하여 그 잠재적 가치를 탐색하기 위해 노력했습니다.
  • 확장 과정에서 기업들은 컴퓨팅 자원과 스토리지를 동시에 확장해야 했으며, 이로 인해 종종 컴퓨팅 자원이 낭비되었습니다. 스토리지-컴퓨팅 결합 아키텍처의 하드웨어 토폴로지는 용량 확장에 영향을 미쳤습니다. 스토리지 용량이 부족할 때, 우리는 기계를 추가할 뿐만 아니라 CPU와 메모리를 업그레이드해야 했습니다. 이는 결합 아키텍처의 데이터 노드가 계산을 담당하기 때문입니다. 따라서 기계들은 일반적으로 계산 능력과 스토리지 구성이 잘 균형을 이루도록 구성되어 있어, 충분한 스토리지 용량과 비교할 만한 계산 능력을 제공합니다. 그러나 실제 계산 능력의 수요는 예상대로 증가하지 않았습니다. 결과적으로 확장된 계산 능력은 기업에게 큰 낭비를 초래했습니다.
  • 계산과 스토리지의 균형을 맞추고 적절한 기계를 선택하는 것이 어려워졌습니다. 전체 클러스터의 스토리지와 I/O 측면에서의 자원 활용이 매우 불균형 할 수 있으며, 클러스터가 더 커짐에 따라 이러한 불균형이 더 심해졌습니다. 또한 적절한 기계를 구입하는 것이 어려웠습니다. 기계는 계산 및 스토리지 요구 사항 사이에서 균형을 맞춰야 했습니다.
  • 데이터가 고르게 분산되지 않을 수 있기 때문에, 데이터가 있는 인스턴스에서 계산 작업을 효과적으로 스케줄링하기 어려웠습니다. 데이터 지역성 스케줄링 전략은 데이터 분포가 불균형 할 가능성 때문에 실제 상황에 효과적으로 대응하지 못할 수 있습니다. 예를 들어, 특정 노드가 로컬 핫스팟이 되어 더 많은 계산 능력을 요구할 수 있습니다. 따라서 빅데이터 플랫폼의 작업이 이러한 핫스팟 노드에 스케줄되더라도 I/O 성능이 제한 요소가 될 수 있습니다.

스토리지와 컴퓨팅을 분리하는 것이 실현 가능한 이유

2006년부터 2016년 사이의 하드웨어 및 소프트웨어 발전으로 인해 스토리지와 컴퓨팅을 분리하는 것이 가능해졌습니다. 이러한 발전에는 다음과 같은 것들이 포함됩니다:

네트워크 카드

10 Gb 네트워크 카드의 채택이 광범위해졌으며, 데이터 센터와 클라우드 환경에서 20 Gb, 40 Gb, 심지어 50 Gb와 같은 더 높은 용량들의 가용성이 증가하고 있습니다. AI 시나리오에서는 100 GB 용량의 네트워크 카드도 사용됩니다. 이는 네트워크 대역폭이 100배 이상 증가한 것을 의미합니다.

디스크

많은 기업들은 여전히 대규모 데이터 클러스터에 대한 스토리지를 위해 디스크 기반 솔루션에 의존합니다. 디스크의 처리량은 50 MB/s에서 100 MB/s로 두 배로 늘어났습니다. 10 GB 네트워크 카드가 장착된 인스턴스는 약 12개의 디스크에 대한 최대 처리량을 지원할 수 있습니다. 이는 대부분의 기업에게 충분하며, 따라서 네트워크 전송은 더 이상 병목 현상이 아닙니다.

소프트웨어

Snappy, LZ4, Zstandard과 같은 효율적인 압축 알고리즘 및 Avro, Parquet, Orc와 같은 열 기반 스토리지 형식의 사용으로 I/O 압력이 더욱 완화되었습니다. 빅 데이터 처리의 병목 현상은 I/O에서 CPU 성능으로 이동했습니다.

스토리지-컴퓨팅 분리를 구현하는 방법

초기 시도: 클라우드에 HDFS 독립 배포

HDFS 독립 배포

2013년부터 업계 내에서 스토리지와 컴퓨팅을 분리하려는 시도가 있었습니다. 초기 접근 방식은 매우 간단했으며, 컴퓨팅 워커와 통합하지 않고 HDFS를 독립적으로 배포하는 것을 포함했습니다. 이 솔루션은 Hadoop 생태계에 어떤 새로운 구성 요소도 추가하지 않았습니다.

아래 다이어그램에 표시된 바와 같이, NodeManager는 DataNodes에 더 이상 배포되지 않았습니다. 이는 컴퓨팅 작업이 DataNodes로 보내지지 않는다는 것을 의미했습니다. 스토리지는 별도의 클러스터가 되었고, 계산에 필요한 데이터는 종단 간 10Gb 네트워크 카드를 지원하는 네트워크를 통해 전송되었습니다. (다이어그램에서 네트워크 전송 라인은 표시되지 않았습니다.)


Separating storage from compute

이 솔루션은 HDFS의 가장 기발한 설계인 데이터 지역성을 포기했지만, 네트워크 통신의 강화된 속도는 클러스터 구성을 훨씬 용이하게 만들었습니다. 이는 데이비스가 2013년 페이스북에서 그의 팀원들과 함께 수행한 실험을 통해 입증되었습니다. Juicedata의 공동 설립자였던 그와 그의 팀원들의 결과는 컴퓨팅 노드의 독립적인 배포 및 관리의 타당성을 확인했습니다.

하지만 이 시도는 더 이상 진행되지 않았습니다. 주된 이유는 HDFS를 클라우드에 배포하는 어려움입니다.

클라우드에 HDFS 배포의 어려움

클라우드에 HDFS를 배포하려면 다음과 같은 문제를 직면합니다:

  • HDFS 다중 복제 메커니즘은 클라우드에서 기업의 비용을 증가시킬 수 있습니다: 예전에는 기업들이 데이터 센터 내에서 베어 디스크를 사용하여 HDFS 시스템을 구축했습니다. 디스크 손상 위험을 완화하기 위해 HDFS는 데이터 안전성과 가용성을 보장하기 위한 다중 복제 메커니즘을 구현했습니다. 그러나 데이터를 클라우드로 이전할 때 클라우드 제공업체는 이미 다중 복제 메커니즘으로 보호되는 클라우드 디스크를 제공합니다. 결과적으로 기업들은 클라우드 내에서 데이터를 세 번 복제해야 하며, 이로 인해 비용이 크게 증가합니다.
  • 베어 디스크에 대한 배포 옵션이 제한됨: 클라우드 제공업체는 베어 디스크가 장착된 일부 머신 유형을 제공하지만, 사용 가능한 옵션은 제한적입니다. 예를 들어, 클라우드에서 제공하는 100가지 가상 머신 유형 중에서 베어 디스크를 지원하는 머신 유형은 5-10가지에 불과합니다. 이러한 제한적인 선택지는 기업 클러스터의 특정 요구사항을 충족시키지 못할 수 있습니다.
  • 클라우드의 독특한 장점을 활용할 수 없음: 클라우드에 HDFS를 배포하려면 수동으로 머신을 생성하고, 배포, 유지 관리, 모니터링, 운영을 해야 하며 탄력적 확장과 종량제 모델의 편리함을 누릴 수 없습니다. 이는 클라우드 컴퓨팅의 핵심 장점입니다. 따라서 HDFS를 클라우드에 배포하면서 스토리지-컴퓨트 분리를 달성하기는 쉽지 않습니다.

HDFS 한계

HDFS 자체에는 다음과 같은 한계가 있습니다:

  • NameNodes의 확장성이 제한적: HDFS의 NameNodes는 수직적으로만 확장 가능하며 분산 확장은 불가능합니다. 이 한계는 단일 HDFS 클러스터 내에서 관리할 수 있는 파일 수에 제한을 가합니다.
  • 500억 개 이상의 파일을 저장하면 운영 비용이 높아집니다:우리의 경험에 따르면, 3억 개 미만의 파일로 HDFS를 운영하고 유지보수하는 것이 일반적으로 쉬워집니다. 파일 수가 5억 개를 초과하면 HDFS Federation 메커니즘을 구현해야 합니다. 그러나 이는 높은 운영 및 관리 비용을 유발합니다.
  • NameNode의 높은 자원 사용과 무거운 부하로 HDFS 클러스터 가용성에 영향을 미칩니다:NameNode가 많은 자원을 차지하고 높은 부하를 가지면 전체 가비지 컬렉션(GC)이 발생할 수 있습니다. 이는 전체 HDFS 클러스터의 가용성에 영향을 미칩니다. 시스템 스토리지는 다운타임을 경험할 수 있어 데이터를 읽을 수 없으며, GC 프로세스에 개입할 방법이 없습니다. 시스템 멈춤의 지속 시간은 결정할 수 없습니다. 이는 높은 부하의 HDFS 클러스터에서 지속적인 문제입니다.

공중 클라우드 + 오브젝트 스토리지

클라우드 컴퓨팅의 발전으로, 기업은 HDFS 대신 오브젝트 스토리지를 사용하는 옵션을 가지게 되었습니다. 오브젝트 스토리지는 대규모 비구조화 데이터 저장을 위해 특별히 설계되었으며, 데이터 업로드 및 다운로드를 쉽게 할 수 있는 아키텍처를 제공합니다. 이는 높은 확장성을 제공하여 비용 효율성을 보장합니다.

HDFS 대체의 오브젝트 스토리지 이점

오브젝트 스토리지는 AWS에서 시작하여 다른 클라우드 제공업체에 의해 HDFS 대신 채택되었습니다. 다음과 같은 장점이 눈에 띕니다:

  • 서비스 중심적이고 바로 사용할 수 있습니다: 오브젝트 스토리지는 배포, 모니터링 또는 유지보수 작업이 필요 없이 사용자 친화적인 경험을 제공합니다.
  • 탄력적 스케일링 및 종량제: 기업은 객체 스토리지에 대해 실제 사용량에 따라 지불하며, 용량 계획이 필요하지 않게 됩니다. 객체 스토리지 버킷을 생성하고 필요한 만큼 데이터를 저장할 수 있으며, 스토리지 용량 제한에 대해 걱정할 필요가 없습니다.

객체 스토리지의 단점

그러나 객체 스토리지를 Hadoop과 같은 복잡한 데이터 시스템을 지원하기 위해 사용할 때 다음과 같은 과제가 발생합니다:

단점 #1: 파일 목록 작업의 성능 저하

목록은 파일 시스템에서 가장 기본적인 작업 중 하나로, HDFS와 같은 트리 구조에서는 가볍고 빠릅니다.

반면에, 객체 스토리지는 평면 구조를 채택하고 수천에서 수십억 개의 객체를 저장 및 검색하기 위해 키(고유 식별자)로 인덱싱합니다. 따라서 List 작업을 수행할 때 객체 스토리지는 이 인덱스 내에서만 검색할 수 있으며, 트리 구조에 비해 현저한 성능 저하를 초래합니다.

Tree-like structure vs. flat structure

단점 #2: 원자적 이름 변경 기능 부재로 인한 작업 성능 및 안정성 저하

추출, 변환, 로드(ETL) 컴퓨팅 모델에서 각 서브태스크는 결과를 임시 디렉토리에 기록합니다. 전체 작업이 완료되면 임시 디렉토리의 이름을 최종 디렉토리 이름으로 변경할 수 있습니다.

이러한 Rename 작업은 HDFS와 같은 파일 시스템에서 원자적이고 빠르며 트랜잭션을 보장합니다. 그러나 객체 스토리지는 기본 디렉토리 구조가 없으므로 Rename 작업을 처리하는 것은 많은 양의 내부 데이터 복사를 포함하는 시뮬레이션 과정입니다. 이 과정은 시간이 많이 소요되며 트랜잭션 보장이 없습니다.

사용자들이 객체 스토리지를 사용할 때 전통적인 파일 시스템의 경로 형식을 객체의 키로 자주 사용합니다. 예를 들어 “/order/2-22/8/10/detail”처럼 말이죠. Rename 작업을 할 때는 디렉토리 이름을 포함하는 모든 객체를 찾아서 새 디렉토리 이름을 키로 사용하여 모든 객체를 복사해야 합니다. 이 과정에서 데이터 복사가 이루어지며, 파일 시스템에 비해 성능이 상당히 떨어질 수 있으며, 수십 배에서 수백 배 느려질 수도 있습니다.

또한, 트랜잭션 보장이 없으므로 과정 중에 실패할 위험이 있어 데이터가 잘못될 수 있습니다. 이러한 사소해 보이는 차이가 전체 작업 파이프라인의 성능과 안정성에 영향을 미칠 수 있습니다.

단점 #3: 최종 일관성 메커니즘이 데이터 정확성과 작업 안정성에 영향을 줌

예를 들어, 여러 클라이언트가 동시에 경로 아래에 파일을 생성할 때, List API를 통해 얻은 파일 목록에는 생성된 모든 파일이 즉시 포함되지 않을 수 있습니다. 객체 스토리지의 내부 시스템이 데이터 일관성을 달성하는 데 시간이 걸립니다. 이러한 접근 방식은 ETL 데이터 처리에서 일반적으로 사용되며, 최종 일관성은 데이터 정확성과 작업 안정성에 영향을 줄 수 있습니다.

물체 저장소의 강한 데이터 일관성을 유지하지 못하는 문제를 해결하기 위해 AWS는 EMRFS라는 제품을 출시했습니다. 그 접근 방식은 추가 DynamoDB 데이터베이스를 사용하는 것입니다. 예를 들어 Spark가 파일을 쓸 때 DynamoDB에도 파일 목록의 복사본을 동시에 기록합니다. 그런 다음 객체 저장소의 List API를 지속적으로 호출하고 얻은 결과를 데이터베이스에 저장된 결과와 비교하여 동일해질 때까지 메커니즘이 설정됩니다. 그러나 이 메커니즘의 안정성은 충분하지 않으며 객체 저장소가 위치한 지역의 부하에 영향을 받아 성능이 가변적일 수 있습니다. 따라서 이상적인 솔루션이 아닙니다.

단점 #4: Hadoop 구성 요소와의 호환성 제한

HDFS는 Hadoop 생태계의 초기 단계에서 주요 저장소 선택이었으며 다양한 구성 요소는 HDFS API를 기반으로 개발되었습니다. 객체 저장소의 소개로 데이터 저장 구조와 API가 변경되었습니다.

클라우드 공급자는 구성 요소 간 커넥터와 클라우드 객체 저장소를 수정하고 상위 계층 구성 요소를 패치하여 호환성을 보장해야 합니다. 이 작업은 공용 클라우드 공급자에게 상당한 작업량을 의미합니다.

결과적으로 공용 클라우드 공급자가 제공하는 빅 데이터 플랫폼에서 지원되는 컴퓨팅 구성 요소의 수가 제한되어 있으며 일반적으로 Spark, Hive, Presto의 몇 가지 버전만 포함됩니다. 이러한 제한은 빅 데이터 플랫폼을 클라우드로 마이그레이션하거나 사용자가 자신의 배포 및 구성 요소에 대한 특정 요구 사항에 대해 도전하게 됩니다.

객체 스토리지의 강력한 성능을 활용하면서 파일 시스템의 신뢰성을 보존하기 위해 기업들은 객체 스토리지 + JuiceFS를 사용할 수 있습니다.

객체 스토리지 + JuiceFS

사용자들이 객체 스토리지에서 복잡한 데이터 계산, 분석, 학습을 수행하려고 할 때, 객체 스토리지만으로는 기업의 요구를 충족시키기 어려울 수 있습니다.이는 Juicedata가 JuiceFS를 개발하게 된 주된 동기 중 하나로, 객체 스토리지의 한계를 보완하기 위한 것.

JuiceFS는 클라우드를 위한 오픈 소스, 고성능 분산 파일 시스템입니다.객체 스토리지와 함께, JuiceFS는 계산, 분석, 학습과 같은 데이터 집약적인 시나리오에 대해 비용 효율적인 솔루션을 제공.

JuiceFS + 객체 스토리지 작동 방식

아래 다이어그램은 JuiceFS가 Hadoop 클러스터 내에서의 배포를 보여줍니다.

JuiceFS deployment in the Hadoop cluster

다이어그램에서 알 수 있는 사항은 다음과 같습니다:

  • YARN에 의해 관리되는 모든 작업자 노드는 JuiceFS Hadoop SDK를 탑재하고 있어, HDFS와의 완전한 호환성을 보장합니다.
  • SDK는 두 가지 구성 요소에 접근합니다:

    • JuiceFS 메타데이터 엔진: 이 엔진은 HDFS의 NameNode에 상응하는 역할을 합니다. 전체 파일 시스템의 메타데이터 정보를 저장하며, 디렉토리 수, 파일 이름, 권한, 타임스탬프 등을 포함합니다. 또한 HDFS의 NameNode가 직면한 확장성 및 GC 문제를 해결합니다.

    • S3 버킷: 데이터는 S3 버킷 내에 저장되며, HDFS의 DataNode와 유사한 역할을 합니다. 다수의 디스크로 사용되어 데이터 저장 및 복제 작업을 관리합니다.

  • JuiceFS는 세 가지 구성 요소로 구성됩니다:

    • JuiceFS Hadoop SDK
    • 메타데이터 엔진
    • S3 버킷

JuiceFS의 객체 스토리지 사용과 비교한 장점

JuiceFS는 객체 스토리지를 직접 사용하는 것에 비해 여러 가지 장점을 제공합니다:

  • HDFS와의 완전한 호환성: JuiceFS는 초기 설계 시 POSIX를 완전히 지원하도록 설계되어 이를 달성합니다. POSIX API는 HDFS보다 더 넓은 범위와 복잡성을 가지고 있습니다.
  • 기존 HDFS 및 객체 스토리지와 함께 사용할 수 있는 능력: Hadoop 시스템의 설계 덕분에 JuiceFS는 기존 HDFS 및 객체 스토리지 시스템과 함께 사용될 수 있으며 완전한 교체가 필요하지 않습니다. Hadoop 클러스터에서 여러 파일 시스템을 구성할 수 있으므로 JuiceFS와 HDFS가 공존하고 협력할 수 있습니다. 이 아키텍처는 기존 HDFS 클러스터를 완전히 교체할 필요가 없으며, 이는 상당한 노력과 위험을 수반합니다. 사용자는 애플리케이션 요구 사항과 클러스터 상황에 따라 JuiceFS를 점진적으로 통합할 수 있습니다.
  • 강력한 메타데이터 성능: JuiceFS는 S3로부터 메타데이터 엔진을 분리하고 S3 메타데이터 성능에 의존하지 않습니다. 이를 통해 최적의 메타데이터 성능을 보장합니다. JuiceFS를 사용할 때 기본 객체 스토리지와의 상호 작용은 Get, Put, Delete와 같은 기본 작업으로 단순화됩니다. 이 아키텍처는 객체 스토리지 메타데이터의 성능 제한을 극복하고 최종적인 일관성과 관련된 문제를 제거합니다.
  • 원자성 Rename 지원: JuiceFS는 독립적인 메타데이터 엔진 덕분에 원자성 Rename 작업을 지원합니다. 캐시는 핫 데이터의 접근 성능을 향상시키고 데이터 지역성 기능을 제공합니다: 캐시를 사용하면 핫 데이터가 매번 네트워크를 통해 개체 스토리지에서 검색할 필요가 없습니다. 또한 JuiceFS는 HDFS 특정 데이터 지역성 API를 구현하여 데이터 지역성을 지원하는 모든 상위 구성 요소가 데이터 친화성의 인식을 되찾을 수 있습니다. 이를 통해 YARN은 캐싱이 설정된 노드에서 작업 스케줄링을 우선시할 수 있으며, 결과적으로 저장소-계산 결합 HDFS와 비교할 수 있는 전반적인 성능을 달성합니다.
  • JuiceFS는 POSIX와 호환되어 기계 학습 및 AI 관련 응용 프로그램과 쉽게 통합할 수 있습니다.

결론

기업 요구사항의 진화와 기술의 발전으로 인해 스토리지와 컴퓨팅의 아키텍처는 결합에서 분리로 변화하였습니다.

스토리지와 컴퓨팅 분리를 달성하는 다양한 접근 방식이 있으며, 각각 장단점이 있습니다. 이 범위는 HDFS를 클라우드에 배포하는 것부터 하둡과 호환되는 퍼블릭 클라우드 솔루션을 활용하는 것, 그리고 클라우드의 복잡한 빅 데이터 계산 및 저장에 적합한 개체 스토리지 + JuiceFS 솔루션 등입니다.

기업에게 확실한 해결책은 없으며, 핵심은 특정 요구 사항에 따라 아키텍처를 선택하는 것입니다. 그러나 어떤 선택을 하든, 단순함은 항상 안전한 배팅입니다.

저자 소개

루이 수, 쥬시데이터의 파트너로서 2017년부터 쥬스FS 제품, 시장 및 오픈소스 커뮤니티의 완전한 개발에 참여한 창립 멤버입니다. 16년의 업계 경험을 바탕으로 소프트웨어, 인터넷, 비정부 기구에서 R&D, 제품 관리자, 창업자 등의 역할을 맡아왔습니다.

Source:
https://dzone.com/articles/from-hadoop-to-cloud-why-and-how-to-decouple-stora