HBase 아키텍처 : HBase 데이터 모델 및 HBase 읽기 / 쓰기 메커니즘



HBase 아키텍처에 대한이 블로그는 HBase 데이터 모델을 설명하고 HBase 아키텍처에 대한 통찰력을 제공합니다. 또한 HBase의 다양한 메커니즘을 설명합니다.

HBase 아키텍처

이전 블로그에서 HBase 튜토리얼 , HBase와 그 기능에 대해 설명했습니다. 또한 더 나은 연결을 위해 Facebook 메신저의 사례 연구를 언급했습니다. 이제 우리의 , HBase 및 HBase 아키텍처의 데이터 모델에 대해 설명합니다.계속 진행하기 전에 HBase가 핵심 개념을 구성하는 중요한 개념임을 알아야합니다. 빅 데이터 하둡 인증을 위해.

이 HBase 아키텍처 블로그에서 다루게 될 중요한 주제는 다음과 같습니다.





먼저 HBase의 데이터 모델을 이해합시다. 빠른 읽기 / 쓰기 및 검색에서 HBase를 지원합니다.



HBase 아키텍처 : HBase 데이터 모델

아시다시피 HBase는 열 지향 NoSQL 데이터베이스입니다. 행과 열을 포함하는 관계형 데이터베이스와 비슷해 보이지만 관계형 데이터베이스는 아닙니다. 관계형 데이터베이스는 행 지향적이며 HBase는 열 지향적입니다. 따라서 먼저 열 지향 데이터베이스와 행 지향 데이터베이스의 차이점을 이해하겠습니다.

행 지향 데이터베이스와 열 지향 데이터베이스 :

  • 행 지향 데이터베이스는 일련의 행에 테이블 레코드를 저장합니다. 반면 열 지향 데이터베이스테이블 레코드를 열 시퀀스에 저장합니다. 즉, 열의 항목이 디스크의 연속 된 위치에 저장됩니다.

더 잘 이해하기 위해 예를 들어 아래 표를 고려하십시오.



표-HBase 아키텍처-Edureka

이 테이블이 행 지향 데이터베이스에 저장된 경우. 아래와 같이 레코드를 저장합니다.

하나,폴 워커,우리,231,용감한,

2, 빈 디젤,브라질,520,머스탱

행 지향 데이터베이스에서 데이터는 위에서 볼 수 있듯이 행 또는 튜플을 기반으로 저장됩니다.

열 지향 데이터베이스는이 데이터를 다음과 같이 저장합니다.

하나,2, 폴 워커,빈 디젤, 우리,브라질, 231,520, 용감한,머스탱

열 기반 데이터베이스에서 모든 열 값은 첫 번째 열 값이 함께 저장되는 것처럼 함께 저장되고 두 번째 열 값은 함께 저장되고 다른 열의 데이터는 유사한 방식으로 저장됩니다.

  • 페타 바이트 또는 엑사 바이트와 같이 데이터 양이 매우 큰 경우 단일 열의 데이터가 함께 저장되고 더 빠르게 액세스 할 수 있기 때문에 열 지향 접근 방식을 사용합니다.
  • 행 지향적 접근 방식은 상대적으로 적은 수의 행과 열을 효율적으로 처리하지만 행 지향 데이터베이스는 데이터를 저장하므로 구조화 된 형식입니다.
  • 반 구조화 또는 비 구조화 데이터의 대규모 세트를 처리하고 분석해야하는 경우 열 지향 접근 방식을 사용합니다. 다루는 응용 프로그램과 같은 온라인 분석 처리 데이터 마이닝, 데이터웨어 하우징, 분석을 포함한 애플리케이션 등
  • 이므로, 온라인 트랜잭션 처리 구조화 된 데이터를 처리하고 트랜잭션 속성 (ACID 속성)이 필요한 은행 및 금융 도메인과 같이 행 지향 접근 방식을 사용합니다.

HBase 테이블에는 아래 이미지에 표시된 다음 구성 요소가 있습니다.

코드에서 Java 프로그램을 중지하는 방법
  • 테이블 : 데이터는 HBase에서 테이블 형식으로 저장됩니다. 그러나 여기 테이블은 열 지향 형식입니다.
  • : 행 키는 검색을 빠르게하는 레코드를 검색하는 데 사용됩니다. 방법을 알고 싶습니까? 이 블로그에서 진행되는 아키텍처 부분에서 설명하겠습니다.
  • 기둥 가족들 : 다양한 컬럼이 하나의 컬럼 패밀리에 결합됩니다. 이러한 column family는 함께 저장되므로 동일한 column family에 속하는 데이터를 단일 검색으로 함께 액세스 할 수 있으므로 검색 프로세스가 더 빨라집니다.
  • 기둥 예선 : 각 열의 이름을 열 한정 자라고합니다.
  • 세포 : 데이터가 셀에 저장됩니다. 데이터는 rowkey 및 열 한정자로 특별히 식별되는 셀로 덤프됩니다.
  • 타임 스탬프 : 타임 스탬프는 날짜와 시간의 조합입니다. 데이터가 저장 될 때마다 타임 스탬프와 함께 저장됩니다. 이렇게하면 특정 버전의 데이터를 쉽게 검색 할 수 있습니다.

보다 간단하고 이해하기 쉬운 방식으로 HBase가 다음으로 구성되어 있다고 말할 수 있습니다.

  • 테이블 세트
  • column family와 행이있는 각 테이블
  • 행 키는 HBase에서 기본 키 역할을합니다.
  • HBase 테이블에 대한 모든 액세스는이 기본 키를 사용합니다.
  • HBase에있는 각 열 한정자는 셀에있는 개체에 해당하는 속성을 나타냅니다.

이제 HBase 데이터 모델에 대해 알게되었으므로이 데이터 모델이 HBase 아키텍처와 어떻게 일치하고 대용량 스토리지 및 빠른 처리에 적합하게 만드는지 살펴 보겠습니다.

HBase 아키텍처 : HBase 아키텍처의 구성 요소

HBase에는 세 가지 주요 구성 요소가 있습니다. HMaster 서버 , HBase 지역 서버, 지역사육사 .

아래 그림은 HBase 아키텍처의 계층 구조를 설명합니다. 우리는 그들 각각에 대해 개별적으로 이야기 할 것입니다.


이제 HMaster로 이동하기 전에 이러한 모든 서버 (HMaster, Region Server, Zookeeper)가 지역을 조정 및 관리하고 지역 내에서 다양한 작업을 수행하기 위해 배치 된 지역을 이해합니다. 그렇다면 지역이 무엇이며 왜 그렇게 중요한지 궁금 할 것입니다.

HBase 아키텍처 : 부위

영역에는 해당 영역에 지정된 시작 키와 종료 키 사이의 모든 행이 포함됩니다. HBase 테이블은 column family의 모든 열이 하나의 영역에 저장되는 방식으로 여러 영역으로 나눌 수 있습니다. 각 영역에는 정렬 된 순서로 행이 포함됩니다.

많은 지역이 지역 서버 , 해당 영역 집합에 대한 읽기 및 쓰기 작업을 처리, 관리, 실행하는 역할을합니다.

따라서 더 간단한 방법으로 결론을 내립니다.

  • 테이블은 여러 영역으로 나눌 수 있습니다. 영역은 시작 키와 종료 키 사이에 데이터를 저장하는 정렬 된 행 범위입니다.
  • 리전의 기본 크기는 256MB이며 필요에 따라 구성 할 수 있습니다.
  • 지역 그룹은 지역 서버에 의해 클라이언트에 제공됩니다.
  • 리젼 서버는 약 1000 개의 리젼을 클라이언트에 제공 할 수 있습니다.

이제 계층 구조의 맨 위에서부터 시작하여 먼저 NameNode와 유사하게 작동하는 HMaster Server에 대해 설명하겠습니다. HDFS . 그런 다음 계층 구조에서 아래로 이동하여 ZooKeeper 및 지역 서버를 살펴 보겠습니다.

HBase 아키텍처 : HMaster

아래 이미지에서와 같이 HMaster가 DataNode에 상주하는 리젼 서버 모음을 처리하는 것을 볼 수 있습니다. HMaster가 어떻게 수행하는지 이해합시다.

  • HBase HMaster는 위 이미지에서 볼 수 있듯이 DDL 작업 (테이블 생성 및 삭제)을 수행하고 리전 서버에 리전을 할당합니다.
  • 리젼 서버를 조정하고 관리합니다 (NameNode가 HDFS에서 DataNode를 관리하는 것과 유사 함).
  • 시작시 리젼 서버에 리젼을 할당하고 복구 및로드 밸런싱 중에 리젼 서버에 리젼을 재 할당합니다.
  • 클러스터에있는 모든 리젼 서버의 인스턴스를 모니터링하고 (Zookeeper의 도움으로) 리젼 서버가 다운 될 때마다 복구 활동을 수행합니다.
  • 테이블 생성, 삭제 및 업데이트를위한 인터페이스를 제공합니다.

HBase는 HMaster만으로는 모든 것을 관리하기에 충분하지 않은 분산되고 거대한 환경을 가지고 있습니다. 그렇다면 HMaster가이 거대한 환경을 관리하는 데 무엇이 도움이되는지 궁금 할 것입니다. 그것이 ZooKeeper가 등장하는 곳입니다. HMaster가 HBase 환경을 관리하는 방법을 이해 한 후에는 Zookeeper가 HMaster가 환경을 관리하는 데 어떻게 도움이되는지 이해할 것입니다.

HBase 아키텍처 : ZooKeeper – 코디네이터

아래 이미지는 ZooKeeper의 조정 메커니즘을 설명합니다.

  • Zookeeper는 HBase 분산 환경에서 조정자 역할을합니다. 세션을 통해 통신하여 클러스터 내부의 서버 상태를 유지하는 데 도움이됩니다.
  • HMaster 서버와 함께 모든 리전 서버는 일정한 간격으로 지속적인 하트 비트를 Zookeeper에 전송하고 위의 이미지에서 언급 한대로 활성 상태이고 사용 가능한 서버를 확인합니다. 또한 서버 장애 알림을 제공하여 복구 조치를 실행할 수 있습니다.
  • 위 이미지에서 볼 수 있듯이 활성 서버의 백업 역할을하는 비활성 서버가 있습니다. 활성 서버가 실패하면 구조를 위해 제공됩니다.
  • 활성 HMaster는 Zookeeper에게 하트 비트를 전송하고 비활성 HMaster는 활성 HMaster가 보내는 알림을 수신합니다. 활성 HMaster가 하트 비트 전송에 실패하면 세션이 삭제되고 비활성 HMaster가 활성화됩니다.
  • 리젼 서버가 하트 비트 전송에 실패하면 세션이 만료되고 모든 리스너에게 이에 대한 알림이 전송됩니다. 그런 다음 HMaster는이 블로그의 뒷부분에서 논의 할 적절한 복구 작업을 수행합니다.
  • Zookeeper는 또한 .META 서버의 경로를 유지하여 모든 클라이언트가 모든 지역을 검색하는 데 도움을줍니다. 클라이언트는 먼저 리젼 서버가 속한 리젼 서버를 확인하고 해당 리젼 서버의 경로를 가져옵니다.

.META 서버에 대해 이야기하면서 먼저 .META 서버가 무엇인지 설명하겠습니다. 따라서 ZooKeeper와 .META Server의 작업을 쉽게 연결할 수 있습니다. 나중에이 블로그에서 HBase 검색 메커니즘에 대해 설명 할 때이 두 가지가 협력하여 어떻게 작동하는지 설명하겠습니다.

HBase 아키텍처 : 메타 테이블

  • META 테이블은 특수 HBase 카탈로그 테이블입니다. 모든 리전 서버 목록을 유지합니다. 위 이미지에서 볼 수 있듯이 HBase 스토리지 시스템에서.
  • 보시다시피 그림을 보면 .META 파일은 키와 값의 형태로 테이블을 유지합니다. 키는 영역의 시작 키와 해당 ID를 나타내는 반면 값에는 영역 서버의 경로가 포함됩니다.

이미 논의했듯이 리전 서버와 그 기능을 설명하면서 리전을 설명 했으므로 이제 계층 구조를 아래로 이동하고 리전 서버의 구성 요소와 해당 기능에 초점을 맞출 것입니다. 나중에 검색, 읽기, 쓰기 메커니즘에 대해 논의하고 이러한 모든 구성 요소가 함께 작동하는 방식을 이해합니다.

HBase 아키텍처 : 리젼 서버의 구성 요소

아래 이미지는 리젼 서버의 구성 요소를 보여줍니다. 이제 별도로 논의하겠습니다.

리젼 서버는 상단에서 실행되는 다양한 리전을 유지합니다. . 리젼 서버의 구성 요소는 다음과 같습니다.

  • 월 : 위 이미지에서 알 수 있듯이 WAL (Write Ahead Log)은 분산 환경 내의 모든 리젼 서버에 첨부 된 파일입니다. WAL은 영구 저장소에 저장되거나 커밋되지 않은 새 데이터를 저장합니다. 데이터 세트를 복구하지 못한 경우에 사용됩니다.
  • 블록 캐시 : 위의 이미지에서 블록 캐시가 리젼 서버의 상단에 있음을 분명히 알 수 있습니다. 자주 읽은 데이터를 메모리에 저장합니다. BlockCache의 데이터가 최근에 가장 적게 사용 된 경우 해당 데이터는 BlockCache에서 제거됩니다.
  • MemStore : 쓰기 캐시입니다. 들어오는 모든 데이터를 디스크 또는 영구 메모리에 커밋하기 전에 저장합니다. 지역의 각 column family에 대해 하나의 MemStore가 있습니다. 이미지에서 볼 수 있듯이 각 지역에는 여러 column family가 포함되어 있기 때문에 한 지역에 대해 여러 MemStore가 있습니다. 데이터는 디스크에 커밋하기 전에 사전 순으로 정렬됩니다.
  • HFile : 위 그림에서 HFile이 HDFS에 저장되어 있음을 알 수 있습니다. 따라서 실제 셀을 디스크에 저장합니다. MemStore는 MemStore의 크기가 초과되면 데이터를 HFile에 커밋합니다.

이제 HBase 아키텍처의 주요 구성 요소와 사소한 구성 요소를 알았으므로 메커니즘과 이에 대한 공동 작업에 대해 설명하겠습니다. 읽기 든 쓰기 든 먼저 읽을 위치 또는 파일을 쓸 위치에서 검색해야합니다. 자,이 검색 프로세스를 이해합시다. 이것이 HBase를 매우 인기있게 만드는 메커니즘 중 하나이기 때문입니다.

HBase 아키텍처 : HBase에서 검색이 어떻게 초기화됩니까?

아시다시피 Zookeeper는 META 테이블 위치를 저장합니다. 클라이언트가 읽기로 접근하거나 HBase에 요청을 쓸 때마다 다음 작업이 발생합니다.

  1. 클라이언트는 ZooKeeper에서 META 테이블의 위치를 ​​검색합니다.
  2. 그런 다음 클라이언트는 META 테이블에서 해당 행 키의 리젼 서버 위치를 요청하여 액세스합니다. 클라이언트는이 정보를 META 테이블의 위치와 함께 캐시합니다.
  3. 그런 다음 해당 리젼 서버에서 요청하여 행 위치를 가져옵니다.

향후 참조를 위해 클라이언트는 캐시를 사용하여 META 테이블의 위치를 ​​검색하고 이전에 행 키의 리젼 서버를 읽었습니다. 그러면 클라이언트는 영역이 이동되거나 이동되어 누락이 발생하지 않는 한 META 테이블을 참조하지 않습니다. 그런 다음 META 서버에 다시 요청하고 캐시를 업데이트합니다.

매번 클라이언트는 META 서버에서 리젼 서버의 위치를 ​​검색하는 데 시간을 낭비하지 않으므로 시간이 절약되고 검색 프로세스가 더 빨라집니다. 이제 HBase에서 글쓰기가 어떻게 이루어지는 지 설명하겠습니다. 관련 구성 요소는 무엇이며 어떻게 관련됩니까?

HBase 아키텍처 : HBase 쓰기 기구

아래 이미지는 HBase의 쓰기 메커니즘을 설명합니다.

쓰기 메커니즘은 다음 프로세스를 순차적으로 진행합니다 (위 이미지 참조).

1 단계: 클라이언트에 쓰기 요청이있을 때마다 클라이언트는 데이터를 WAL (Write Ahead Log)에 씁니다.

  • 그런 다음 편집 내용이 WAL 파일 끝에 추가됩니다.
  • 이 WAL 파일은 모든 리젼 서버에서 유지되며 리젼 서버는이를 사용하여 디스크에 커밋되지 않은 데이터를 복구합니다.

2 단계: 데이터가 WAL에 기록되면 MemStore에 복사됩니다.

3 단계 : 데이터가 MemStore에 배치되면 클라이언트는 승인을받습니다.

4 단계 : MemStore가 임계 값에 도달하면 데이터를 HFile로 덤프하거나 커밋합니다.

이제 심층 분석을 통해 MemStore가 작성 과정에 어떻게 기여하는지, 그리고 그 기능은 무엇인지 이해하겠습니다.

HBase 쓰기 기구- MemStore

  • MemStore는 항상 저장된 데이터를 사전 순서 (사전 방식으로 순차적)로 정렬 된 KeyValues로 업데이트합니다. 각 column family에 대해 하나의 MemStore가 있으므로 업데이트는 각 column family에 대해 정렬 된 방식으로 저장됩니다.
  • MemStore가 임계 값에 도달하면 정렬 된 방식으로 모든 데이터를 새 HFile에 덤프합니다. 이 HFile은 HDFS에 저장됩니다. HBase에는 각 Column Family에 대해 여러 HFile이 포함되어 있습니다.
  • 시간이 지남에 따라 MemStore가 데이터를 덤프함에 따라 HFile의 수가 증가합니다.
  • MemStore는 또한 마지막으로 작성된 시퀀스 번호를 저장하므로 Master Server와 MemStore는 지금까지 커밋 된 내용과 시작 위치를 모두 알고 있습니다. 영역이 시작되면 마지막 시퀀스 번호가 읽히고 해당 번호에서 새 편집이 시작됩니다.

여러 번 논의했듯이 HFile은 HBase 아키텍처의 주요 영구 저장소입니다. 마지막으로 모든 데이터는 HBase의 영구 저장소 인 HFile에 커밋됩니다. 따라서 읽고 쓰는 동안 검색 속도를 높이는 HFile의 속성을 살펴 보겠습니다.

HBase 아키텍처 : HBase 쓰기 기구- HFile

  • 쓰기는 디스크에 순차적으로 배치됩니다. 따라서 디스크의 읽기-쓰기 헤드 이동이 매우 적습니다. 이것은 쓰기 및 검색 메커니즘을 매우 빠르게 만듭니다.
  • HFile 인덱스는 HFile이 열릴 때마다 메모리에로드됩니다. 이것은 단일 탐색에서 레코드를 찾는 데 도움이됩니다.
  • 트레일러는 HFile의 메타 블록을 가리키는 포인터입니다. 커밋 된 파일의 끝에 기록됩니다. 타임 스탬프 및 블룸 필터에 대한 정보가 포함되어 있습니다.
  • Bloom Filter는 키 값 쌍을 검색하는 데 도움이되며 필요한 rowkey가 포함되지 않은 파일을 건너 뜁니다. 타임 스탬프는 파일 버전을 검색하는데도 도움이되며 데이터를 건너 뛰는 데 도움이됩니다.

쓰기 메커니즘과 쓰기 및 검색 속도를 높이는 다양한 구성 요소의 역할을 알고 나면. HBase 아키텍처 내에서 읽기 메커니즘이 어떻게 작동하는지 설명하겠습니다. 그런 다음 압축, 영역 분할 및 복구와 같은 HBase 성능을 향상시키는 메커니즘으로 이동합니다.

HBase 아키텍처 : 메커니즘 읽기

검색 메커니즘에서 설명했듯이 클라이언트가 캐시 메모리에없는 경우 먼저 클라이언트는 .META 서버에서 리젼 서버의 위치를 ​​검색합니다. 그런 다음 다음과 같이 순차적 인 단계를 거칩니다.

  • 데이터를 읽기 위해 스캐너는 먼저 블록 캐시에서 행 셀을 찾습니다. 여기에 최근에 읽은 모든 키 값 쌍이 저장됩니다.
  • Scanner가 필요한 결과를 찾지 못하면 이것이 쓰기 캐시 메모리라는 것을 알고 있으므로 MemStore로 이동합니다. 거기에서 HFile에 아직 덤프되지 않은 가장 최근에 작성된 파일을 검색합니다.
  • 마침내 블룸 필터와 블록 캐시를 사용하여 HFile에서 데이터를로드합니다.

지금까지 HBase의 검색, 읽기 및 쓰기 메커니즘에 대해 논의했습니다. 이제 HBase에서 검색, 읽기 및 쓰기를 빠르게 수행하는 HBase 메커니즘을 살펴 보겠습니다. 첫째, 우리는 이해할 것입니다 압축 , 이는 이러한 메커니즘 중 하나입니다.

HBase 아키텍처 : 압축

HBase HFiles를 결합하여 스토리지를 줄이고 읽기에 필요한 디스크 검색 수를 줄입니다. 이 과정을 압축 . 압축은 영역에서 일부 HFile을 선택하고 결합합니다. 위 이미지에서 볼 수 있듯이 압축에는 두 가지 유형이 있습니다.

  1. 사소한 압축 : HBase는 자동으로 더 작은 HFile을 선택하고 위의 이미지와 같이 더 큰 HFile로 다시 커밋합니다. 이것을 Minor Compaction이라고합니다. 더 작은 HFile을 더 큰 HFile로 커밋하기 위해 병합 정렬을 수행합니다. 이것은 저장 공간 최적화에 도움이됩니다.
  2. 주요 압축 : 위 이미지에 표시된대로 Major 압축에서 HBase는 영역의 더 작은 HFile을 새 HFile에 병합하고 다시 커밋합니다. 이 과정에서 동일한 열 패밀리가 새 HFile에 함께 배치됩니다. 이 과정에서 삭제되고 만료 된 셀을 삭제합니다. 읽기 성능이 향상됩니다.

그러나이 프로세스 중에 입출력 디스크와 네트워크 트래픽이 정체 될 수 있습니다. 이것은 쓰기 증폭 . 따라서 일반적으로 낮은 피크로드 타이밍에 예약됩니다.

이제 제가 논의 할 또 다른 성능 최적화 프로세스는 지역 분할 . 이것은로드 밸런싱에 매우 중요합니다.

파이썬에서 goto를 사용하는 방법

HBase 아키텍처 : 지역 분할

아래 그림은 영역 분할 메커니즘을 보여줍니다.

영역이 커질 때마다 위 그림과 같이 두 개의 하위 영역으로 나뉩니다. 각 영역은 상위 영역의 정확히 절반을 나타냅니다. 그런 다음이 분할이 HMaster에보고됩니다. 이는 HMaster가로드 밸런싱을 위해 새 리젼 서버에이를 할당 할 때까지 동일한 리젼 서버에 의해 처리됩니다.

마지막으로, 마지막으로 HBase가 장애 후 데이터를 복구하는 방법을 설명합니다. 우리가 알고 있듯이 장애 복구 HBase의 매우 중요한 기능이므로 장애 발생 후 HBase가 데이터를 복구하는 방법을 알려주십시오.

HBase 아키텍처 : HBase 충돌 및 데이터 복구

  • 리젼 서버가 실패 할 때마다 ZooKeeper는 실패에 대해 HMaster에 알립니다.
  • 그런 다음 HMaster는 충돌 한 리젼 서버의 영역을 여러 활성 리젼 서버에 분배하고 할당합니다. 실패한 리젼 서버의 MemStore 데이터를 복구하기 위해 HMaster는 WAL을 모든 리젼 서버에 분배합니다.
  • 각 리젼 서버는 WAL을 재실행하여 실패한 리전의 컬럼 패밀리에 대한 MemStore를 빌드합니다.
  • 데이터는 WAL에서 시간순 (적시 순서)으로 기록됩니다. 따라서 해당 WAL을 다시 실행하는 것은 MemStore 파일에서 변경 및 저장 한 모든 변경을 의미합니다.
  • 따라서 모든 리젼 서버가 WAL을 실행 한 후 모든 컬럼 패밀리에 대한 MemStore 데이터가 복구됩니다.

이 블로그가 HBase 데이터 모델 및 HBase 아키텍처를 이해하는 데 도움이 되었기를 바랍니다. 당신이 그것을 즐겼기를 바랍니다. 이제 HBase의 기능 (이전에서 설명한 HBase 튜토리얼 블로그)를 HBase 아키텍처와 함께 사용하고 내부적으로 어떻게 작동하는지 이해합니다. 이제 HBase의 이론적 인 부분을 알았으므로 실제 부분으로 이동해야합니다. 이 점을 염두에두고 다음 블로그에서 샘플을 설명합니다 HBase POC .

이제 HBase 아키텍처를 이해 했으므로 전 세계에 걸쳐 250,000 명 이상의 만족 한 학습자 네트워크를 보유한 신뢰할 수있는 온라인 학습 회사 인 Edureka에서 작성했습니다. Edureka BigData Hadoop 인증 교육 과정은 학습자가 소매, 소셜 미디어, 항공, 관광, 금융 도메인에서 실시간 사용 사례를 사용하여 HDFS, Yarn, MapReduce, Pig, Hive, HBase, Oozie, Flume 및 Sqoop의 전문가가 될 수 있도록 도와줍니다.

질문이 있으십니까? 의견란에 언급 해 주시면 연락 드리겠습니다.