HDFS 데이터 액세스 효율성 최적화: 데이터 열과 냉기를 사용하여 관리

테마 소개:

1. HDFS 최적화 저장 기능 설명
2. SSM 시스템 아키텍처 설계
3. SSM 시스템 적용 시나리오 분석

1. 배경

빅데이터 기술 관련 기술이 발전하고 대중화되면서 오픈소스 Hadoop 기반의 플랫폼 시스템을 사용하는 기업이 늘어나고 있으며, 동시에 전통적인 기술 아키텍처에서 빅데이터로 전환하는 비즈니스와 애플리케이션도 점점 늘어나고 있습니다. 플랫폼. 일반적인 Hadoop 빅데이터 플랫폼에서 사람들은 HDFS를 스토리지 서비스의 핵심으로 사용합니다.

빅데이터 개발 초기에는 여전히 주요 응용 시나리오가 오프라인 일괄 처리 시나리오였으며 스토리지에 대한 수요는 이러한 시나리오를 위해 설계되었으며 지속적인 기술 개발로 인해 더 많은 시나리오가 스토리지에 대한 새로운 요구를 제시할 것이며 HDFS도 새로운 과제에 직면해 있습니다. 여기에는 주로 여러 측면이 포함됩니다.

1. 데이터 볼륨 문제

비즈니스 성장과 새로운 애플리케이션 액세스로 인해 HDFS에 더 많은 데이터가 제공되는 반면, 딥 러닝 및 인공 지능과 같은 기술이 발전함에 따라 사용자는 일반적으로 데이터 저장을 원합니다. 더 오랜 시간 동안 딥러닝의 효과를 향상시킵니다. 데이터 양의 급격한 증가로 인해 클러스터는 지속적으로 확장 요구에 직면하게 되어 스토리지 비용이 증가하게 됩니다.

2. 작은 파일 문제

우리 모두 알고 있듯이 HDFS는 대용량 파일의 오프라인 일괄 처리를 위해 설계되었습니다. 작은 파일을 처리하는 것은 기존 HDFS가 잘하는 시나리오가 아닙니다. HDFS 작은 파일 문제의 근본 원인은 파일의 메타데이터 정보가 단일 네임노드의 메모리에 유지되고 단일 머신의 메모리 공간이 항상 제한되어 있다는 것입니다. 단일 네임노드 클러스터가 수용할 수 있는 최대 시스템 파일 수는 약 1억 5천만 개로 추정됩니다. 실제로 HDFS 플랫폼은 일반적으로 여러 상위 계층 컴퓨팅 프레임워크와 여러 비즈니스 시나리오를 지원하는 기본 스토리지 플랫폼 역할을 하므로 비즈니스 관점에서 작은 파일 문제는 피할 수 없습니다. 현재 네임노드 단일 지점 확장성 문제를 해결하기 위한 HDFS-Federation과 같은 솔루션이 있지만 동시에 운영 및 유지 관리에 큰 어려움을 가져올 것입니다.

3. 핫 및 콜드 데이터 문제

데이터의 양이 계속해서 늘어나고 축적됨에 따라 데이터의 접속 인기도에도 큰 차이가 나타납니다. 예를 들어, 플랫폼은 최신 데이터를 지속적으로 작성하지만 일반적으로 최근에 작성된 데이터는 오래 전에 작성된 데이터보다 훨씬 더 자주 액세스됩니다. 데이터가 핫인지 콜드인지에 관계없이 동일한 스토리지 전략을 사용하면 클러스터 리소스가 낭비됩니다. 데이터의 Hotness와 Coldness를 기반으로 HDFS 스토리지 시스템을 최적화하는 방법은 해결해야 할 시급한 문제입니다.

2. 기존 HDFS 최적화 기술

Hadoop이 탄생한 지 10년이 넘었습니다. 이 기간 동안 HDFS 기술 자체는 지속적으로 최적화되고 발전해 왔습니다. HDFS에는 위의 문제 중 일부를 어느 정도 해결할 수 있는 몇 가지 기존 기술이 있습니다. HDFS 이기종 스토리지와 HDFS 이레이저 코딩 기술에 대해 간략하게 소개합니다.

HDFS 이기종 스토리지:

Hadoop은 버전 2.6.0부터 이기종 저장 기능을 지원합니다. 우리는 HDFS의 기본 저장 전략이 각 데이터 블록의 복사본 3개를 사용하고 이를 다른 노드의 디스크에 저장한다는 것을 알고 있습니다. 이기종 스토리지의 역할은 서버에서 다양한 유형의 스토리지 미디어(HDD 하드 디스크, SSD, 메모리 등 포함)를 사용하여 더 많은 스토리지 전략(예: 세 개의 복사본, 하나는 SSD 미디어에 저장됨)을 제공하는 것입니다. 나머지 두 개는 여전히 HDD 하드 디스크에 저장되어 있으므로 HDFS 스토리지는 다양한 애플리케이션 시나리오에 보다 유연하고 효율적으로 대응할 수 있습니다.

HDFS에서 사전 정의된 다양한 지원 스토리지는 다음과 같습니다.

• ARCHIVE: 테이프와 같이 저장 밀도는 높지만 전력 소모는 낮은 저장 매체는 일반적으로 콜드 데이터를 저장하는 데 사용됩니다

• DISK: 디스크 미디어, HDFS가 지원하는 최초의 저장 매체

• SSD: 솔리드 스테이트 드라이브는 현재 많은 인터넷 회사에서 사용하는 새로운 유형의 저장 매체입니다

• RAM_DISK: 데이터가 메모리에 기록되는 동시에 또 다른 복사본이 저장 매체에 (비동기적으로) 기록됩니다

HDFS에서 지원되는 스토리지 전략은 다음과 같습니다.

1. Lazy_persist: 하나의 복사본은 RAM_DISK 메모리에 보관되고 나머지 복사본은 디스크에 저장됩니다

2. ALL_SSD: 모든 복사본이 SSD에 저장됩니다

3. One_SSD: 하나의 복사본은 SSD에 저장되고 나머지 복사본은 디스크에 저장됩니다

4. 핫: 모든 복사본이 디스크에 저장되며 이는 기본 저장 정책이기도 합니다

5. Warm: 하나의 복사본은 디스크에 저장되고 나머지 복사본은 아카이브 저장소에 저장됩니다

6. 콜드: 모든 사본은 아카이브 저장소에 보관됩니다

일반적으로 HDFS 이기종 스토리지의 가치는 클러스터의 전반적인 리소스 사용 효율성을 높이기 위해 데이터의 인기도에 따라 다양한 전략을 채택하는 데 있습니다. 자주 액세스하는 데이터의 경우 전체 또는 일부를 액세스 성능이 높은 저장 매체(메모리 또는 SSD)에 저장하여 거의 액세스하지 않는 데이터의 읽기 및 쓰기 성능을 향상시키고, 읽기 및 쓰기를 줄이기 위해 아카이브 저장 매체에 저장합니다. 성능. 그러나 HDFS 이기종 스토리지를 구성하려면 사용자가 디렉터리에 대해 해당 정책을 지정해야 합니다. 즉, 사용자는 각 디렉터리에 있는 파일의 액세스 인기도를 미리 알아야 합니다. 실제 빅 데이터 플랫폼 애플리케이션에서는 이것이 더 어렵습니다.

HDFS 삭제 코드:

기존 HDFS 데이터는 데이터 신뢰성을 보장하기 위해 3개 복사본 메커니즘을 사용합니다. 즉, 저장된 데이터 1TB마다 클러스터의 각 노드에서 차지하는 실제 데이터는 200%의 추가 오버헤드를 포함해 3TB에 이릅니다. 이는 노드 디스크 저장 및 네트워크 전송에 큰 부담을 줍니다.

Hadoop 3.0에서는 HDFS 파일 블록 수준 삭제 코딩에 대한 지원을 도입하기 시작했으며 기본 레이어는 Reed-Solomon(k, m) 알고리즘을 사용합니다. RS는 일반적으로 사용되는 삭제 코딩 알고리즘으로, k비트 데이터에 대해 m비트 검사 숫자를 생성할 수 있으며, 이에 따라 다양한 수준의 내결함성을 얻을 수 있습니다. 상대적으로 유연한 삭제 코딩 알고리즘.

일반적인 알고리즘은 RS(3,2), RS(6,3), RS(10,4)이며, k 파일 블록과 m 체크 블록이 그룹을 형성하며, 이 손실 그룹에서는 모든 m 데이터 블록이 허용될 수 있습니다.

HDFS 삭제 코딩 기술은 데이터 저장의 중복성을 줄일 수 있습니다. RS(3,2)를 예로 들면 데이터 중복성은 67%로 Hadoop의 기본 200%에 비해 크게 감소합니다. 그러나 삭제 코딩 기술은 데이터 저장 및 데이터 복구를 위한 계산을 위해 CPU를 소비해야 합니다. 이는 실제로 공간에 대한 시간 교환의 선택이므로 콜드 데이터의 저장이 더 적합합니다. 콜드 데이터에 저장된 데이터는 한 번 기록된 후 오랫동안 액세스되지 않는 경우가 많습니다. 이 경우 이레이저 코딩 기술을 사용하여 복사본 수를 줄일 수 있습니다. 3. 빅데이터 저장 최적화: SSM

앞서 소개한 HDFS 이기종 저장 기술이든 삭제 코딩 기술이든 사용자가 특정 데이터에 대한 저장 동작을 지정해야 한다는 것이 전제입니다. 즉, 사용자는 어떤 데이터가 핫 데이터이고 어떤 데이터가 콜드 데이터인지 알아야 합니다. 그렇다면 스토리지를 자동으로 최적화하는 방법이 있습니까?

답은 그렇습니다. 여기에 소개된 SSM(Smart Storage Management) 시스템은 기본 스토리지(보통 HDFS)로부터 메타데이터 정보를 얻고, 다양한 열 수준을 가진 데이터를 대상으로 데이터 읽기 및 쓰기 액세스 정보 분석을 통해 데이터 열 상태를 얻습니다. 사전 설정된 일련의 규칙에 따라 해당 스토리지 최적화 전략을 채택하여 전체 스토리지 시스템의 효율성을 향상시킵니다. SSM은 Intel이 주도하는 오픈 소스 프로젝트이며, China Mobile도 연구 개발에 참여하고 있습니다. 해당 프로젝트는 Github(https://github.com/Intel-bigdata/SSM)에서 확인할 수 있습니다.

SSM 포지셔닝은 전체적으로 서버-에이전트-클라이언트 아키텍처를 채택한 스토리지 주변 장치 최적화 시스템입니다. 서버는 SSM의 전체 로직 구현을 담당하고, 에이전트는 스토리지 클러스터에서 다양한 작업을 수행하는 데 사용됩니다. 클라이언트는 일반적으로 기본 HDFS 인터페이스를 포함하여 사용자에게 제공되는 데이터 액세스입니다.

SSM-Server의 주요 프레임워크는 위 그림에 나와 있습니다. 위에서 아래로 StatesManager는 HDFS 클러스터와 상호 작용하여 HDFS 메타데이터 정보를 얻고 각 파일의 액세스 열 정보를 유지합니다. StatesManager의 정보는 관계형 데이터베이스에 유지됩니다. TiDB는 SSM에서 기본 스토리지 데이터베이스로 사용됩니다. RuleManager는 규칙 관련 정보를 유지 관리합니다. 사용자는 프런트엔드 인터페이스를 통해 SSM에 대한 일련의 저장 규칙을 정의하고, RuleManger는 규칙을 구문 분석하고 실행하는 역할을 담당합니다. CacheManager/StorageManager는 인기도와 규칙을 기반으로 특정 작업 작업을 생성합니다. ActionExecutor는 특정 작업 작업을 담당하고, 에이전트에 작업을 할당하고, 에이전트 노드에서 이를 실행합니다.

SSM-서버의 내부 논리 구현은 규칙 정의에 의존하며, 이를 위해서는 관리자가 프런트 엔드 웹 페이지를 통해 SSM 시스템에 대한 일련의 규칙을 공식화해야 합니다. 규칙은 여러 부분으로 구성됩니다.

• 작업 개체는 일반적으로 특정 조건을 충족하는 파일을 참조합니다.
• 트리거는 매일 예약된 트리거와 같이 규칙이 트리거되는 시점을 의미합니다.
• 실행 조건은 일정 기간 내 파일 액세스 횟수 요구 사항 등 인기도에 따라 일련의 조건을 정의합니다.
• 작업 실행, 실행 조건을 충족하는 데이터에 대한 관련 작업 수행, 일반적으로 저장 전략 지정 등

실제 규칙 예:

file.path는 ”/foo/*”와 일치합니다: accessCount(10min) >= 3 |

이 규칙은 /foo 디렉터리에 있는 파일에 대해 10분 내에 3회 이상 액세스하면 One-SSD 스토리지 전략이 채택된다는 의미입니다. 즉, 데이터 사본 하나가 SSD에 저장됩니다. , 나머지 2개의 복사본은 일반 디스크에 저장됩니다.

4.SSM 적용 시나리오 SSM은 다양한 저장 전략을 사용하여 데이터의 핫함과 콜드니스를 최적화할 수 있습니다. 다음은 몇 가지 일반적인 애플리케이션 시나리오입니다.

가장 일반적인 시나리오는 콜드 데이터의 경우 위 그림과 같이 관련 규칙을 정의하고 오랫동안 액세스하지 않은 데이터에 대해 저렴한 스토리지를 사용하는 것입니다. 예를 들어 원본 데이터 블록은 SSD 스토리지에서 HDD 스토리지로 성능이 저하됩니다.

마찬가지로, 핫스팟 데이터의 경우 다양한 규칙에 따라 더 빠른 스토리지 전략을 채택할 수도 있습니다. 위 그림에 표시된 것처럼 여기에서 짧은 시간 내에 더 많은 핫스팟 데이터에 액세스하면 HDD에서 SSD로 스토리지가 더 늘어납니다. 핫 데이터는 메모리 저장 전략을 사용합니다.

콜드 데이터 시나리오의 경우 SSM은 삭제 코딩 최적화를 사용할 수도 있습니다. 해당 규칙을 정의하면 데이터 복사 중복성을 줄이기 위해 액세스가 거의 없는 콜드 데이터에 대해 삭제 코드 작업이 수행됩니다.

SSM에도 작은 파일에 대한 해당 최적화 방법이 있다는 점도 언급할 가치가 있습니다. 이 기능은 아직 개발 과정에 있습니다. 일반적인 논리는 SSM이 HDFS의 일련의 작은 파일을 큰 파일로 병합하는 동시에 원본 작은 파일과 병합된 큰 파일 간의 매핑 관계와 큰 파일에 있는 각 작은 파일의 위치가 다음과 같다는 것입니다. SSM 오프셋의 메타데이터에 기록됩니다. 사용자가 작은 파일에 접근해야 하는 경우 SSM 메타데이터의 작은 파일 매핑 정보를 기반으로 SSM 전용 클라이언트(SmartClient)를 통해 병합된 파일에서 원본 작은 파일을 가져옵니다.

마지막으로 SSM은 오픈 소스 프로젝트이며 여전히 매우 빠르게 반복적으로 발전하는 과정에 있습니다. 관심 있는 친구라면 누구나 프로젝트 개발에 기여할 수 있습니다.

Q&A Q1:

직접 HDFS를 구축하려면 어떤 규모부터 시작해야 하나요?

A1:

HDFS는 의사 분산 모드를 지원합니다. 노드가 하나만 있어도 HDFS 시스템을 구축할 수 있습니다. HDFS의 분산 아키텍처를 더 잘 경험하고 이해하고 싶다면 3~5개의 노드로 환경을 구축하는 것이 좋습니다.

Q2:

Su Yan이 각 성의 실제 빅데이터 플랫폼에서 SSM을 사용한 적이 있나요?

A2:

아직은 아닙니다. 이 프로젝트는 아직 빠르게 개발 중입니다. 테스트가 안정된 후 점차적으로 프로덕션에 사용될 예정입니다.

Q3:

HDFS와 Spark의 차이점은 무엇인가요? 장점과 단점은 무엇입니까?

A3:

HDFS와 Spark는 동일한 수준의 기술이 아닙니다. HDFS는 스토리지 시스템인 반면 Spark는 컴퓨팅 엔진입니다. 우리가 Spark와 자주 비교하는 것은 HDFS 스토리지 시스템이 아닌 Hadoop의 Mapreduce 컴퓨팅 프레임워크입니다. 실제 프로젝트 구축에서 HDFS와 Spark는 일반적으로 협력 관계를 유지합니다. HDFS는 기본 스토리지에 사용되고 Spark는 상위 수준 컴퓨팅에 사용됩니다.

위 내용은 HDFS 데이터 액세스 효율성 최적화: 데이터 열과 냉기를 사용하여 관리의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!