KR101792189B1 - 빅 데이터 처리 장치 및 방법 - Google Patents

빅 데이터 처리 장치 및 방법 Download PDF

Info

Publication number
KR101792189B1
KR101792189B1 KR1020160026264A KR20160026264A KR101792189B1 KR 101792189 B1 KR101792189 B1 KR 101792189B1 KR 1020160026264 A KR1020160026264 A KR 1020160026264A KR 20160026264 A KR20160026264 A KR 20160026264A KR 101792189 B1 KR101792189 B1 KR 101792189B1
Authority
KR
South Korea
Prior art keywords
blocks
stored
block
repositories
information
Prior art date
Application number
KR1020160026264A
Other languages
English (en)
Other versions
KR20170103403A (ko
Inventor
박상현
김민경
신민철
Original Assignee
연세대학교 산학협력단
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 연세대학교 산학협력단 filed Critical 연세대학교 산학협력단
Priority to KR1020160026264A priority Critical patent/KR101792189B1/ko
Publication of KR20170103403A publication Critical patent/KR20170103403A/ko
Application granted granted Critical
Publication of KR101792189B1 publication Critical patent/KR101792189B1/ko

Links

Images

Classifications

    • G06F17/30318—
    • G06F17/30194—
    • G06F17/30218—
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
    • G06F3/0601—Interfaces specially adapted for storage systems
    • G06F3/0628—Interfaces specially adapted for storage systems making use of a particular technique
    • G06F3/0638—Organizing or formatting or addressing of data
    • G06F3/064—Management of blocks

Abstract

본 발명은 저장소들의 종류 정보를 기초로 블록들을 검출 및 결합하여 빅 데이터를 판독하는 빅 데이터 처리 장치 및 방법을 제안한다. 본 발명에 따른 장치는 판독하려는 빅 데이터를 구성하는 블록들을 저장하는 저장소들의 종류 정보를 획득하는 저장소 정보 획득부; 저장소들의 종류 정보를 기초로 블록들을 검출하는 블록 검출부; 및 블록들을 결합하여 빅 데이터를 판독하는 빅 데이터 판독부를 포함한다.

Description

빅 데이터 처리 장치 및 방법 {Apparatus and method for processing big data}
본 발명은 빅 데이터를 처리하는 장치 및 방법에 관한 것이다. 보다 상세하게는, 쓰기(Writing) 처리된 빅 데이터를 읽기(Reading) 처리하는 장치 및 방법에 관한 것이다.
빅 데이터의 시대가 다가옴에 따라 빅 데이터 기술들의 중요성도 나날이 증가하고 있다. 하둡(Hadoop)은 대량의 데이터들을 분석, 저장 및 처리할 수 있는 능력을 갖추고 있기 때문에 모든 빅 데이터 시스템들 중에서 가장 각광을 받고 있다.
하둡의 고성능을 지원하기 위한 매우 중요한 이슈는 높은 스토리지 I/O 요구(High storage I/O request)를 만족시키면서 데이터량의 증가를 관리하는 것이다. 하둡의 전체적인 성능은 스토리지 I/O(Storage Input/Output)에 큰 영향을 받는다. 그러나 스토리지 I/O 기술은 여전히 매우 제한적이다. 그래서 그 어느 때보다도 지금 더 하둡의 분산 처리 시스템(HDFS; Distributed File System of Hadoop)에서 스토리지 I/O를 향상시키는 연구가 인기를 얻고 있다.
이를 위해 스토리지 시스템의 최근 동향은 하이브리드 저장 장치를 이용하는 것이다. 그러나 HDFS 내에서 이기종 스토리지 디바이스들(Heterogeneous storage devices)의 정보를 사용하는 것은 용이하지 않다. 그 이유는 데이터를 판독(Reading)할 때, HDFS가 아직 이기종 스토리지 유형 정보(Heterogeneous storage type information)를 활용할 수 없기 때문이다.
한국공개특허 제2015-0084611호는 빅 데이터를 처리하는 장치에 대하여 제안하고 있다. 그러나 이 장치는 빅 데이터를 판독하는 방법에 대하여 제안하고 있지 않기 때문에 상기한 문제점을 해결할 수 없다.
본 발명은 상기한 문제점을 해결하기 위해 안출된 것으로서, 저장소들의 종류 정보를 기초로 블록들을 검출 및 결합하여 빅 데이터를 판독하는 빅 데이터 처리 장치 및 방법을 제안하는 것을 목적으로 한다.
그러나 본 발명의 목적은 상기에 언급된 사항으로 제한되지 않으며, 언급되지 않은 또 다른 목적들은 아래의 기재로부터 당업자에게 명확하게 이해될 수 있을 것이다.
본 발명은 상기한 목적을 달성하기 위해 안출된 것으로서, 판독(Reading)하려는 빅 데이터(Big data)를 구성하는 블록들을 저장하는 저장소들의 종류 정보를 획득하는 저장소 정보 획득부; 상기 저장소들의 종류 정보를 기초로 상기 블록들을 검출하는 블록 검출부; 및 상기 블록들을 결합하여 상기 빅 데이터를 판독하는 빅 데이터 판독부를 포함하는 것을 특징으로 하는 빅 데이터 처리 장치를 제안한다.
바람직하게는, 상기 저장소 정보 획득부는 상기 저장소들의 종류 정보로 상기 블록들이 저장된 상기 저장소들이 HDD(Hard Disk Drive)와 SSD(Solid State Drive) 중 어느 것인지에 대한 정보를 획득한다.
바람직하게는, 상기 블록 검출부는 동일 블록에 대하여 생성된 복제 블록들이 서로 다른 저장소들에 저장되어 있을 때 상기 저장소들의 종류 정보를 기초로 상기 블록들을 검출한다.
바람직하게는, 상기 블록 검출부는 상기 저장소들의 종류 정보를 기초로 상기 블록들을 검출할 때에 상기 블록들이 지정된 유형의 저장소들에 저장되어 있는지 여부를 판단한다.
바람직하게는, 상기 블록 검출부는 상기 지정된 유형으로 SSD를 이용한다.
바람직하게는, 상기 블록 검출부는 상기 블록들이 지정된 유형의 저장소들에 저장되어 있지 않은 것으로 판단되면 상기 블록들이 동일 로컬 데이터 노드의 지정되지 않은 유형의 저장소들에 저장되어 있는지 여부를 판단한다.
바람직하게는, 상기 블록 검출부는 상기 저장소들의 종류 정보 및 상기 저장소들의 위치 정보를 기초로 상기 블록들을 검출한다.
바람직하게는, 상기 블록 검출부는 상기 블록들을 검출할 때 상기 저장소들의 종류 정보를 먼저 이용하고 상기 저장소들의 위치 정보를 나중 이용하거나, 상기 저장소들의 위치 정보를 먼저 이용하고 상기 저장소들의 종류 정보를 나중 이용한다.
바람직하게는, 상기 블록 검출부는 상기 블록들이 지정된 유형의 저장소들에 저장되어 있는지 여부, 및 상기 블록들이 지정되지 않은 유형의 저장소들에 저장되어 있는지 여부를 순차적으로 판단하여 상기 블록들을 검출하며, 상기 블록들이 상기 지정된 유형의 저장소들 및 상기 지정되지 않은 유형의 저장소들에 저장되어 있지 않은 것으로 판단되면 상기 저장소들의 위치 정보를 기초로 상기 블록들을 검출한다.
바람직하게는, 상기 블록 검출부는 상기 블록들이 동일 랙(Rack)에 구비된 다른 데이터 노드에 저장되어 있는지 여부, 및 상기 블록들이 지정된 유형의 저장소들에 저장되어 있는지 여부를 순차적으로 판단하여 상기 블록들을 검출한다.
바람직하게는, 상기 빅 데이터 처리 장치는 하둡 에코 시스템(Hadoop eco system)에서 상기 빅 데이터에 포함되는 분산 데이터들을 처리할 때 이용된다.
또한 본 발명은 판독(Reading)하려는 빅 데이터(Big data)를 구성하는 블록들을 저장하는 저장소들의 종류 정보를 획득하는 단계; 상기 저장소들의 종류 정보를 기초로 상기 블록들을 검출하는 단계; 및 상기 블록들을 결합하여 상기 빅 데이터를 판독하는 단계를 포함하는 것을 특징으로 하는 빅 데이터 처리 방법을 제안한다.
바람직하게는, 상기 획득하는 단계는 상기 저장소들의 종류 정보로 상기 블록들이 저장된 상기 저장소들이 HDD(Hard Disk Drive)와 SSD(Solid State Drive) 중 어느 것인지에 대한 정보를 획득한다.
바람직하게는, 상기 검출하는 단계는 동일 블록에 대하여 생성된 복제 블록들이 서로 다른 저장소들에 저장되어 있을 때 상기 저장소들의 종류 정보를 기초로 상기 블록들을 검출한다.
바람직하게는, 상기 검출하는 단계는 상기 저장소들의 종류 정보를 기초로 상기 블록들을 검출할 때에 상기 블록들이 지정된 유형의 저장소들에 저장되어 있는지 여부를 판단한다.
바람직하게는, 상기 검출하는 단계는 상기 지정된 유형으로 SSD를 이용한다.
바람직하게는, 상기 검출하는 단계는 상기 블록들이 지정된 유형의 저장소들에 저장되어 있지 않은 것으로 판단되면 상기 블록들이 동일 로컬 데이터 노드의 지정되지 않은 유형의 저장소들에 저장되어 있는지 여부를 판단한다.
바람직하게는, 상기 검출하는 단계는 상기 저장소들의 종류 정보 및 상기 저장소들의 위치 정보를 기초로 상기 블록들을 검출한다.
바람직하게는, 상기 검출하는 단계는 상기 블록들을 검출할 때 상기 저장소들의 종류 정보를 먼저 이용하고 상기 저장소들의 위치 정보를 나중 이용하거나, 상기 저장소들의 위치 정보를 먼저 이용하고 상기 저장소들의 종류 정보를 나중 이용한다.
바람직하게는, 상기 검출하는 단계는 상기 블록들이 지정된 유형의 저장소들에 저장되어 있는지 여부, 및 상기 블록들이 지정되지 않은 유형의 저장소들에 저장되어 있는지 여부를 순차적으로 판단하여 상기 블록들을 검출하며, 상기 블록들이 상기 지정된 유형의 저장소들 및 상기 지정되지 않은 유형의 저장소들에 저장되어 있지 않은 것으로 판단되면 상기 저장소들의 위치 정보를 기초로 상기 블록들을 검출한다.
바람직하게는, 상기 검출하는 단계는 상기 블록들이 동일 랙(Rack)에 구비된 다른 데이터 노드에 저장되어 있는지 여부, 및 상기 블록들이 지정된 유형의 저장소들에 저장되어 있는지 여부를 순차적으로 판단하여 상기 블록들을 검출한다.
바람직하게는, 상기 빅 데이터 처리 방법은 하둡 에코 시스템(Hadoop eco system)에서 상기 빅 데이터에 포함되는 분산 데이터들을 처리할 때 수행된다.
본 발명은 상기한 목적 달성을 위한 구성들을 통하여 다음 효과를 얻을 수 있다.
첫째, 빅 데이터에 대한 처리 속도를 향상시킬 수 있다.
둘째, 스토리지 I/O의 성능 등 빅 데이터를 처리하는 시스템의 전체적인 성능을 비용에 대비하여 효율적으로 향상시킬 수 있다.
도 1은 하둡 시스템의 전체적인 구성을 개략적으로 도시한 개념도이다.
도 2는 하둡 분산 파일 시스템이 동일한 데이터 블록들을 서로 다른 데이터 노드들에 기록하는 방법을 설명하기 위한 개념도이다.
도 3은 본 발명의 일실시예에 따른 데이터 블록 읽기 프로세스를 설명하기 위한 개념도이다.
도 4는 본 발명의 빅 데이터 처리 속도 향상을 보여주는 실험 결과이다.
도 5는 타조에서 사용 가능한 쿼리들을 기술한 참고도이다.
도 6은 본 발명의 하둡 시스템 전체 성능 향상을 보여주는 실험 결과이다.
도 7은 본 발명의 바람직한 실시예에 따른 빅 데이터 처리 장치의 내부 구성을 개략적으로 도시한 블록도이다.
이하, 본 발명의 바람직한 실시예를 첨부된 도면들을 참조하여 상세히 설명한다. 우선 각 도면의 구성요소들에 참조 부호를 부가함에 있어서, 동일한 구성요소들에 대해서는 비록 다른 도면상에 표시되더라도 가능한한 동일한 부호를 가지도록 하고 있음에 유의해야 한다. 또한, 본 발명을 설명함에 있어, 관련된 공지 구성 또는 기능에 대한 구체적인 설명이 본 발명의 요지를 흐릴 수 있다고 판단되는 경우에는 그 상세한 설명은 생략한다. 또한, 이하에서 본 발명의 바람직한 실시예를 설명할 것이나, 본 발명의 기술적 사상은 이에 한정하거나 제한되지 않고 당업자에 의해 변형되어 다양하게 실시될 수 있음은 물론이다.
빅 데이터는 매우 크고 복잡한 데이터 집합을 말한다. 이것은 짧은 시간 이내에 수 테라바이트(terabyte), 수 페타바이트(petabyte) 등에 이르는 방대한 양의 데이터들을 생성한다. 처리해야 할 데이터의 양이 증가함에 따라, 방대한 양의 데이터들로부터 의미있는 정보들을 추출하기 위한 빅 데이터 분석 기법의 필요성이 대두되고 있다. 그러나 종래의 관계형 데이터베이스 관리 시스템(RDMS; Relational Database Management System)은 방대한 양의 데이터들을 저장 및 처리하기에 부적합하다. 따라서 오늘날 데이터의 저장, 액세스, 조작, 분석 등 빅 데이터를 전문적으로 취급할 수 있는 연구가 활발하게 진행되고 있다.
빅 데이터를 조작하고 처리할 수 있는 다양한 어플리케이션들로 예컨대 아파치 하둡(Apache Hadoop)을 기초 프레임워크(Basic framework)로 하는 어플리케이션이 있다. 하둡(Hadoop)은 크게 데이터 저장을 담당하는 모듈 즉, 하둡 분산 파일 시스템(HDFS; Hadoop Distributed File System)와 데이터 처리를 담당하는 모듈 즉, 맵리듀스 엔진(MapReduce)으로 구성된다.
맵리듀스 엔진은 데이터 처리를 위해 태스크들을 분할하고 각 태스크의 실행을 병렬로 처리(분산 처리)한다. 그런데 맵리듀스 엔진은 실시간 처리에 적합하지 않고 SQL 언어를 지원하지 않기 때문에 그 이용이 제한되는 문제점이 있다. 이 문제점을 해결하기 위해 최근 들어 SQL-on-Hadoop 등 빅 데이터를 처리할 수 있는 다양한 방법들이 개발되고 있다. 또한 이렇게 개발된 다양한 방법들(ex. SQL-on-Hadoop)을 하둡 분산 파일 시스템에 접목시켜 빅 데이터의 실시간 처리 성능을 향상시킬 수 있는 방안들에 대해서도 계속적으로 연구되고 있다.
하둡 분산 파일 시스템(HDFS)은 빅 데이터를 미리 정해진 크기를 가지는 복수개의 단위 데이터들로 분할한다. 이후 하둡 분산 파일 시스템은 분할된 단위 데이터들을 다수개의 저장 장치들에 자기 복제시켜 단위 데이터들이 분산 저장되도록 한다. 최근 들어 고속의 입출력(I/O) 성능을 얻을 수 있도록 SSD(Solid State Drive) 장치를 이용하여 하둡 분산 파일 시스템을 최적화시키는 방안들이 제안되고 있다. 그러나 하둡 분산 파일 시스템에서 기존의 모든 HDD(Hard Disk Drive) 장치들을 SSD 장치들로 대체한다는 것은 매우 어려운 일이다. 그래서 새로운 대안으로, SSD 장치들과 HDD 장치들을 함께 이용하여 하둡 분산 파일 시스템을 최적화시키는 방안들이 제안되고 있다.
본 발명에서는 SSD 장치, HDD 장치 등 저장 장치들의 타입을 기초로 하둡 분산 파일 시스템에서 하이브리드 HDFS 블록(Hybrid HDFS block)을 선택하는 기법에 대하여 제안한다. 본 발명에서는 저장 장치들의 타입을 고려하여 읽기 블록(Read block)의 최적 위치를 선택하도록 한다. 서로 다른 후보 데이터 노드들 중에 동일 블록이 HDD 장치와 SSD 장치 양쪽에 존재한다면, 본 발명에서는 상대적으로 더 우수한 성능을 가진 SSD 장치가 HDD 장치보다 선호되는 것이 바람직하다.
본 발명에서는 SSD 장치들과 HDD 장치들이 혼합 구성된 하둡 분산 파일 시스템을 이용한다. 또한 본 발명에서는 데이터 처리를 담당하는 모듈로 SQL-on-Hadoop 모듈을 이용한다. 이와 같이 구성된 본 발명은 빅 데이터 관련 프로그램들을 총칭하는 하둡 생태계(Hadoop Eco System)의 전체적인 성능을 향상시키는 효과를 얻을 수 있다.
이하 도면들을 참조하여 본 발명에 대하여 자세하게 설명한다. 도 1은 하둡 시스템의 전체적인 구성을 개략적으로 도시한 개념도이다.
- 하둡 분산 파일 시스템(HDFS; Hadoop Distributed File System)
하둡(Hadoop)은 대량의 데이터들을 클러스터링시키고 분산 처리할 수 있는 오픈 소스 소프트웨어를 말한다. 이러한 하둡은 앞서 설명한 바와 같이 데이터의 저장을 담당하는 모듈(하둡 분산 파일 시스템, HDFS)과 데이터의 처리를 담당하는 모듈(맵리듀스 엔진, MapReduce)로 구성된다. 맵리듀스 엔진은 대량의 데이터들을 분산 처리 알고리즘에 따라 다수개의 클러스터들에 분산 처리시킨다.
하둡 분산 파일 시스템은 마스터 노드(Master)에 해당하는 하나의 네임 노드(NameNode)와 슬레이브 노드(Slaves)에 해당하는 복수개의 데이터 노드들(DataNodes)을 포함한다. 도 1은 하둡 시스템(Hadoop system; 100)의 전체 구성도를 도시한 것이다.
도 1을 참조하면, 클라이언트(110)는 하둡 클라이언트(Hadoop client)로서, 데이터 쓰기, 데이터 읽기 등을 요청하는 기능을 수행한다. 클라이언트(110)에 의해 데이터 쓰기 요청이 하둡 분산 파일 시스템(Distributed Data Storage HDFS; 130)으로 입력되면, 하둡 분산 파일 시스템(130)은 클라이언트(110)로부터 입력된 파일을 블록 단위로 분할하며, 이후 동일한 블록들을 다수개 생성한다.
하둡 분산 파일 시스템(130)은 파일로부터 분할된 각 블록을 여러 차례 복사하여 분할된 각 블록 외에 복사된 블록들을 생성함으로써 동일한 블록들을 다수개 생성할 수 있다. 본 발명에서 하둡 분산 파일 시스템(130)이 동일한 블록들을 다수개 생성하는 것은 고장 허용 한계(Fault tolerance)를 제공하기 위해서이다. 이후 하둡 분산 파일 시스템(130)은 동일한 블록들을 서로 다른 데이터 노드들(152a, …, 152n)에게 할당한다.
각 데이터 노드에 할당된 블록들이 데이터 쓰기 기록되면, 네임 노드(142)는 할당된 각 블록이 어느 데이터 노드에 쓰기 기록되었는지 해당 위치 정보를 관리한다.
이후 클라이언트(110)에 의해 파일 읽기가 요청되면, 맵리듀스 엔진(Distributed Data Processing MapReduce; 120)은 해당 파일의 읽기를 처리하기 위해 해당 파일로부터 분할된 블록들이 어느 데이터 노드에 쓰기 기록되어 있는지 그 위치 정보를 하둡 분산 파일 시스템(130)에 요구한다. 이후 맵리듀스 엔진(120)은 네임 노드(142)로부터 데이터 노드들(152a, …, 152n)의 위치 정보를 수신하며, 수신된 정보를 기초로 동일한 블록들이 저장된 다수개의 데이터 노드들(152a, …, 152n) 중에서 특정 데이터 노드를 선택하여 블록들을 수집한다.
하둡 분산 파일 시스템(130)은 일반적으로 HDD, SSD 등 저장 장치의 타입을 구별하지 않고 단지 디스크 타입(DISK type)에 따라 저장 장치들을 정의한다. 그래서 네임 노드(142)는 데이터 노드의 위치 정보만 관리할 뿐이었다. 그러나 본 발명에서는 각 데이터 노드에 서로 다른 형태의 저장 장치들(ex. HDD, SSD, RAM)이 구비되며, 네임 노드(142)가 데이터 노드의 위치 정보 뿐만 아니라 각 데이터 노드에서 해당 블록이 어느 저장 장치에 저장되어 있는지에 대한 정보(즉 저장 장치의 타입에 대한 정보)까지 관리한다. 이를 위해 하둡 분산 파일 시스템(130)은 메모리 API를 추가로 구성할 수 있다. 메모리 API는 네임 노드(142) 내에 구비될 수 있으나, 네임 노드(142)와 별도로 마스터 노드(140) 상에 구비될 수 있다.
이기종 프레임워크(Heterogeneous framework)를 이용하면 SSD, HDD, RAM 등 다양한 저장 장치의 타입을 인식하는 것이 가능해진다. 본 발명에서는 아카이벌 스토리지(Archival storage), SSD 및 메모리 API(Memory API)를 이용하여 이기종 프레임워크를 기초로 복수개의 블록 저장 방법들을 제공할 수 있다. 각 블록 저장 방법은 블록을 SSD, HDD 등에 어떻게 저장할 것인지를 정의한 것으로서, 예컨대 예컨대 One_SSD 모드를 사용, n개의 블록 복제 팩터(Replica factor)를 사용하는 경우, 1개의 블록은 SSD에, n-1개의 블록은 HDD에 저장되어야 한다. 상기에서 n은 블록 복제본 수를 의미한다.
- SQL-on-Hadoop
일반적으로 맵리듀스(MapReduce)는 데이터의 실시간 처리에 부적합하고 SQL 언어를 지원하지 않기 때문에 그 이용에 있어 제한되는 문제점이 있다. 이러한 문제점을 해결하기 위해 SQL-on-Hadoop 등이 제안되었음은 앞서 설명한 바 있다. 본 발명에서는 분산 처리 엔진이 상기한 문제점을 해결하기 위해 SQL-on-Hadoop을 기반으로 작동하는 것을 특징으로 한다. SQL-on-Hadoop은 하이브(Hive), 타조(Tajo), 임팔라(Impala), 스파크(Spark) 등 하둡 플랫폼 상에서 작동하는 분석 어플리케이션 툴(Analytical application tool)을 의미한다.
하둡 에코 시스템은 분산 처리 엔진과 분산 파일 시스템으로 구성되어 있으며, 대표적인 분산 처리 엔진이 맵리듀스이고, 대표적인 분산 파일 시스템이 HDFS이다. 본 발명에서는 SQL-on-Hadoop을 기반으로 작동하는 맵리듀스 엔진을 이용하므로, 이하에서는 이를 SQL-on-Hadoop을 기반으로 작동하는 분산 처리 엔진, 약칭하여 분산 처리 엔진으로 정의한다.
본 발명에서는 각 데이터 노드에 서로 다른 저장 장치들이 구비되어 있다. 그래서 하둡 분산 파일 시스템(130)이 파일로부터 분할된 블록들을 각 데이터 노드에 저장한 뒤, 해당 블록이 저장된 데이터 노드에 대한 정보(ex. 데이터 노드의 주소) 뿐만 아니라 해당 블록이 각 데이터 노드의 어느 저장 장치에 저장되어 있는지에 대한 정보도 관리한다. 또한 SQL-on-Hadoop을 기반으로 작동하는 분산 처리 엔진을 구성하여 이들 간 조합을 통하여 데이터의 실시간 처리 성능을 향상시키고자 한다.
본 발명에서는 일실시 형태로 SQL-on-Hadoop으로 타조(Tajo)를 이용하여 하둡 분산 파일 시스템(130)과 분산 처리 엔진을 구성할 수 있다.
타조(Tajo)는 빅 데이터의 관계형 및 분산형 데이터-웨어하우스 시스템을 말한다. 타조(Tajo)는 하나의 마스터(Master)와 다수의 슬레이브 워커들(Slave workers)이 논리적으로 구성되어 있다. 다수의 슬레이브 워커들 중 하나는 쿼리 마스터(Query master) 기능을 수행한다. 쿼리 마스터는 쿼리 프로세스(Query process)를 관리하는 기능을 담당한다.
클라이언트(110)가 쿼리를 전송하면, 타조(Tajo)는 플랜(Plan)을 생성하기 시작한다. 플랜은 다수의 태스크들(Tasks)을 포함한다. 여기서 태스크는 타조(Tajo)의 실행 단위를 의미한다. 쿼리 마스터는 많은 후보 슬레이브 워커들 중에서 쿼리 프로세스를 수행하기에 적합한 슬레이브 워커를 스케줄에 포함시킨다. 이에 따라 선택된 슬레이브 워커는 읽기(Read) 또는 쓰기(Write)를 위해 HDFS 레벨을 액세스하며, 이어서 HDFS 블록들을 처리한다.
한편 도 1을 참조하면, 분산 처리 엔진에 의해 제어되는 것으로 마스터 노드(140)에 잡 트래커(Job tracker; 141)가 구비되며, 슬레이브 노드(150)에 복수개의 태스크 트래커들(Task trackers; 151a, …, 151n)이 구비된다. 잡 트래커(141)는 타조(Tajo)를 구성하는 마스터에 대응하는 개념이며, 태스크 트래커들(151a, …, 151n)은 슬레이브 워커들에 대응하는 개념이다.
- SSD(Solid-State drive)
SSD가 가진 여러 가지 장점들 중 하나는 마그네틱 디스크(Magnetic disk)에 데이터를 기록하는 것이 아니라, 반도체 메모리(ex. NAND 플래시 메모리)에 데이터를 기록한다는 것이다. SSD는 이를 통해 HDD가 가진 긴 검색 및 지연 시간을 큰 폭으로 감축시킬 수 있으며, 플러터(Flutter)도 감소시킬 수가 있다. 여기서 플러터는 기록된 데이터를 재생시킬 때에 발생하는 오류를 의미한다.
SSD는 HDD에 대비하여 우수한 순차적 I/O 성능(Sequential I/O performance)와 랜덤 I/O 성능(Random I/O performance)를 가지고 있다. SSD가 가진 여러 가지 장점들 중 다른 하나는 높은 에너지 효율(Energy efficiency)을 가진다는 것이다. SSD는 HDD와 비교할 때 동일 시점에 HDD보다 적은 양의 전력을 소비한다.
한편 SSD가 가진 단점은 HDD보다 매우 비싸다는 것이다. HDD보다 매우 우수한 성능을 가졌음에도 불구하고 SSD가 가진 이러한 단점(즉 가격 경쟁력이 불량하다는 것)은 SSD의 보편적 이용을 저해하는 요인이 되고 있다.
그러나 최근 들어 NAND 플래시 메모리의 과잉 공급 덕분에, SSD의 가격은 이전보다 매우 저렴하다. SSD의 비트당 비용(Cost-per-bit)은 과거에 비해 계속적으로 감소하는 추세이다. 따라서 미래에는 SSD의 이용 가치가 더욱 증가할 것으로 기대된다.
상당한 비용적 차이에도 불구하고 앞서 설명한 성능의 향상을 위해서는 하둡 분산 파일 시스템(130) 내에 데이터를 저장하기 위한 장치로 HDD와 SSD가 혼합되는 것이 바람직하다. 데이터 노드들(152a, …, 152n) 내에 데이터 저장 장치로 모두 SSD로 구성하여 실험한 결과 HDD로 구성했을 때에 비해 데이터의 처리 속도 등 맵리듀스 성능(MapReduce performance)를 70% 이상 향상시킬 수 있다. 이는 HDD와 SSD를 혼합 구성할 경우 I/O 성능이 얼마나 우수해지는지를 단적으로 보여주는 결과이다.
그런데 데이터 노드들(152a, …, 152n) 내에 HDD와 SSD를 혼합할 경우 저장 타입을 이용하여 HDFS 블록들을 어떻게 선택할 것인지 이에 대해 결정할 필요가 있다. 클라이언트(110)는 데이터 노드들(152a, …, 152n) 내에 서로 다른 저장 장치들이 혼합되어 있을 경우 블록들을 어디에 어떻게 저장할 것인지 정의할 수 있다. 그러나 클라이언트(110)는 블록들을 읽을 때 장치의 저장 형식을 고려하지 않기 때문에 SSD와 HDD에 저장되어 있는 블록들을 무작위로 읽는 경향을 보인다. I/O 성능을 더욱 향상시키기 위해서는 블록 선택 기술에 특정한 기준이 있어야 할 것이다.
이하에서는 클라이언트(110)의 요청에 따라 데이터 노드들(152a, …, 152n)에 저장되어 있는 데이터 블록들을 읽을 때에 데이터 노드들(152a, …, 152n)에 구비되어 있는 저장 장치들의 종류에 따라 데이터 블록들을 선택하는 방법에 대하여 설명한다.
본 발명에서는 데이터를 저장하는 모듈과 데이터를 처리하는 모듈로 각각 하둡 분산 파일 시스템(HDFS)과 SQL-on-Hadoop을 기반으로 작동하는 분산 처리 엔진을 이용하여 데이터 블록들을 선택하는 방법에 대하여 제안한다. 이하의 실시예에서는 SQL-on-Hadoop 시스템으로 타조(Tajo)를 이용하여 설명한다.
- HDFS
하둡 분산 파일 시스템(HDFS; 130)에서 물리적인 저장 장치는 HDD와 SSD의 혼합 형태로 구성된다. 하둡 분산 파일 시스템(130)의 기본 블록 복제 인자(Default block-replica factor)는 3이다. 즉 하둡 분산 파일 시스템(130)은 고장 허용 한계(Fault tolerance)를 제공하기 위하여 1개의 원본 블록에 대하여 3개의 복제 블록들을 생성하여 이 3개의 데이터 블록들을 서로 다른 데이터 노드들에 쓰기 기능(Write)을 수행한다. 그러나 본 실시예에서 하둡 분산 파일 시스템(130)의 기본 블록 복제 인자가 반드시 3에 한정되는 것은 아니다.
하둡 분산 파일 시스템(130)은 ONE_SSD 모드를 이용한다. ONE_SSD 모드는 3개의 데이터 블록들을 3개의 데이터 노드들에 쓰기(기록)할 때, 1개는 SSD에 기록하고 나머지 2개는 HDD에 기록하는 모드를 의미한다. 하둡 분산 파일 시스템(130)은 메모리 API를 통하여 ONE_SSD 모드에 대한 정보를 관리한다.
도 2는 하둡 분산 파일 시스템이 동일한 데이터 블록들을 서로 다른 데이터 노드들에 기록하는 방법을 설명하기 위한 개념도이다. 이하 설명은 도 2를 참조한다.
먼저 클라이언트(110)가 네임 노드(142)에 저장하려는 파일을 구성하는 블록 B0의 기록(Write)을 요청한다(S210).
이후 네임 노드(142)가 블록 복제(Block-replica)를 통해 생성된 3개의 블록 B0들을 각각 랙 1(Rack 1; 260)의 데이터 노드 1(DataNode 1; 261), 데이터 노드 2(DataNode 2; 262), 및 랙 2(Rack 2; 270)의 데이터 노드 4(DataNode 4; 271)에 기록할 것을 명령한다(S220). 이때 네임 노드(142)는 3개의 블록 B0들을 각각 데이터 노드 1(261)의 HDD, 데이터 노드 2(262)의 SSD, 및 데이터 노드 4(271)의 HDD에 기록할 것을 명령할 수 있다.
이후 클라이언트(110)는 네임 노드(142)의 지시에 따라 3개의 블록 B0들을 각각 데이터 노드 1(261)의 HDD, 데이터 노드 2(262)의 SSD, 및 데이터 노드 4(271)의 HDD에 기록한다(S230a, S230b, S230c).
이후 네임 노드(142)는 데이터 블록들이 기록된 데이터 노드들에 대한 정보 및 데이터 블록들이 기록된 저장 장치의 종류에 대한 정보를 블록 B0에 대한 메타데이터(251)로 생성하여 관리한다. 네임 노드(142)의 이러한 기능은 S220 단계를 수행한 뒤 즉시 수행되는 것도 가능하다.
하둡의 이종 프레임워크는 SSD, HDD 등과 같이 저장 장치들의 다양한 종류를 인식하는 것이 가능하다. 그런데 저장 유형에 대한 정보(데이터 블록이 HDD, SSD 등 중에서 어느 저장 장치에 보관되어 있는지에 대한 정보)는 블록 위치 클래스(BlockLocation class, 데이터 블록이 어느 데이터 노드에 저장되어 있는지에 대한 정보)와 함께 취급하는 것이 용이하지 않다. 그래서 본 실시예에서는 SSD의 우수한 I/O 성능을 활용하기 위하여 블록 위치 클래스의 멤버 변수(Member variable)로서 각 블록 위치의 저장 유형을 추가하기로 한다.
- 하이브리드 HDFS 블록 선택 방법(Hybrid HDFS Block-Selection Method)
HDFS 클라이언트(110)가 블록 B0의 읽기(Read)를 요청하면, 네임 노드(142)는 HDFS 클라이언트(110)에게 블록 위치 정보(BlockLocation information)를 전송한다. 블록 위치 정보는 블록 B0의 복제 블록들(Block B0 replicas)을 가지고 있는 데이터 노드들에 대한 목록(List)을 포함하고 있다. 복제 블록들을 가지고 있는 데이터 노드들은 클라이언트(110)까지의 거리를 기초로 목록 내에 정렬되어 있다. 예컨대 데이터 노드들은 클라이언트(110)까지의 거리가 짧은 순서로 목록의 상측에서 하방으로 정렬되어 있다.
도 3은 본 발명의 일실시예에 따른 데이터 블록 읽기 프로세스를 설명하기 위한 개념도이다.
먼저 클라이언트(110)는 블록 B0가 저장되어 있는 데이터 노드들에 대한 정보를 요청한다.
이후 네임 노드(142)는 데이터베이스에 저장되어 있는 블록 B0의 메타데이터를 검출하여 이 정보를 클라이언트(110)에게 전송한다. 여기서 분산 처리 엔진은 타조(Tajo) 등으로 구현될 수 있는 SQL-on-Hadoop을 의미한다.
이후 분산 처리 엔진은 네임 노드(142)로부터 수신된 블록 B0의 메타데이터를 클라이언트(110)로부터 수신받아 이 정보를 기초로 특정 데이터 노드에 저장되어 있는 복제 블록 B0(Block B0 replica)를 추출한다. 예컨대 분산 처리 엔진은 블록 B0를 가지고 있는 데이터 노드들 중에서 가장 가까운 거리에 있는 데이터 노드 즉 랙 1(261)의 데이터 노드 1(261)로부터 복제 블록 B0를 획득한다.
분산 처리 엔진은 메타데이터에 포함되어 있는 목록에서 우선순위에 따라 데이터 노드를 선택함으로써 특정 데이터 노드로부터 복제 블록 B0를 획득할 수 있다. 예컨대 분산 처리 엔진은 메타데이터에 포함되어 있는 목록에서 최상위에 위치하는 데이터 노드를 선택함으로써 자신으로부터 가장 가까운 거리에 있는 데이터 노드로부터 복제 블록 B0를 획득할 수 있다.
그런데 이것은 저장 장치의 종류에 대한 정보를 고려하지 않은 경우이다. 저장 I/O 성능(Storage I/O performance)은 SSD에서 판독(Read)하는 블록들의 양에 의존한다. 따라서 시스템이 SSD보다 HDD에 저장되어 있는 블록들을 더 많이 판독한다면, 저장 I/O 성능은 나빠질 것이다.
본 발명에서는 이러한 문제점을 해결하기 위하여 저장 유형을 고려한 하둡 분산 파일 시스템(130)의 하이브리드 블록 선택 방법을 제안한다. 이하 설명은 도 3을 참조한다.
먼저 클라이언트(110)는 블록 B0가 저장되어 있는 데이터 노드들의 위치 정보를 요청한다(S310).
이후 네임 노드(142)는 데이터베이스에 저장되어 있는 블록 B0의 메타데이터를 검출하여 이 정보를 HDFS 클라이언트(110)에게 전송한다(S320). 이때 클라이언트(110)에게 전송되는 정보에는 복제 블록 B0가 저장되어 있는 데이터 노드들의 위치 정보 뿐만 아니라 각 데이터 노드에서 복제 블록 B0가 저장되어 있는 저장 장치의 종류에 대한 정보도 있다(NameNode sends Block location with Storage device type). 저장 장치의 종류에 대한 정보는 예컨대 다음과 같은 형식으로 저장될 수 있다.
Block B0 = DataNode 1, HDD
DataNode 2, SSD
DataNode 4, HDD
상기에서 'Block B0 = DataNode 1, HDD'는 복제 블록 B0가 데이터 노드 1의 HDD에 저장되어 있음을 의미한다. 'Block B0 = DataNode 2, SSD'는 복제 블록 B0가 데이터 노드 2의 SSD에 저장되어 있음을 의미하며, 'Block B0 = DataNode 4, HDD'는 복제 블록 B0가 데이터 노드 4의 HDD에 저장되어 있음을 의미한다.
한편 데이터 노드들의 위치 정보는 클라이언트(110)가 요청한 데이터 블록에 대한 위치 정보이며, 이 메타데이터에는 파일 시스템 디렉토리 정보, 파일명, 파일에 대한 블록 정보, 블록-데이터 노드 매핑 정보, 네트워크 사용 현황 등이 포함되어 있다. 상기에서 네트워크 사용 현황은 데이터 블록이 저장된 데이터 노드의 네트워크 사용 현황을 의미한다.
이후 분산 처리 엔진은 네임 노드(142)로부터 수신된 데이터 노드의 위치 정보 및 저장 장치의 종류에 대한 정보를 클라이언트(110)로부터 수신받아 이 정보들을 기초로 특정 데이터 노드에 접근하여(S330) 이 데이터 노드에 구비된 특정 저장 장치로부터 복제 블록 B0(Block B0 replica)를 획득한다(S340).
본 실시예에서는 분산 처리 엔진이 네임 노드(142)로부터 수정된 HDFS 블록 위치 클래스(Modified HDFS BlockLocation class)를 수신한다. 수정된 HDFS 블록 위치 클래스는 특정 복제 블록을 저장하고 있는 데이터 노드의 위치 정보 뿐만 아니라 그 특정 복제 블록을 저장하고 있는 저장 장치의 종류에 대한 정보도 포함한다. 분산 처리 엔진은 복제 블록 B0를 획득하기 위해 다음 기준에 따라 복수개의 후보 데이터 노드들 중에서 어느 하나의 데이터 노드를 선택한다.
첫째, 분산 처리 엔진은 후보 데이터 노드들 중에서 SSD에 복제 블록 B0를 기록하고 있는 데이터 노드가 있는지 여부를 판단한다. 후보 데이터 노드들 중에 SSD에 복제 블록 B0를 기록하고 있는 데이터 노드가 있는 것으로 판단되면, 분산 처리 엔진은 그 데이터 노드를 우선적으로 선택한다.
둘째, 후보 데이터 노드들 중에 SSD에 복제 블록 B0를 기록하고 있는 데이터 노드가 없는 것으로 판단되면, 분산 처리 엔진은 자신으로부터 데이터 노드까지의 거리를 기초로 후보 데이터 노드들 중에서 어느 하나의 데이터 노드를 선택한다. 예컨대 분산 처리 엔진은 자신으로부터 가장 가까운 거리에 위치한 데이터 노드를 선택할 수 있다.
도 3에 도시된 예시의 경우, 복제 블록 B0는 데이터 노드 1(261)의 HDD, 데이터 노드 2(262)의 SSD, 및 데이터 노드 4(271)의 HDD에 기록되어 있다. 분산 처리 엔진은 후보 데이터 노드들 중에서 SSD에 복제 블록 B0를 기록하고 있는 데이터 노드가 있는지 여부를 우선적으로 판단하므로, 분산 처리 엔진은 데이터 노드 1(261) 내지 데이터 노드 6(273) 중에서 데이터 노드 2(262)를 선택하고 이 데이터 노드 2(262)로부터 복제 블록 B0를 획득한다.
이상 설명한 하이브리드 HDFS 블록 선택 방법에서는 분산 처리 엔진이 후보 데이터 노드들의 저장 유형을 확인하고, 다른 후보 데이터 노드들에 비해 우선순위에 해당하는 데이터 노드 2(262)를 선택한다. 그 이유는 대상 복제 블록 B0가 데이터 노드 2(262)의 경우 SSD에 기록되어 있기 때문이다.
한편 본 실시예에서 상기한 기능들은 판독을 요청한 HDFS 클라이언트(110)에 의해 직접 수행되는 것도 가능하다.
본 실시예에서는 SQL-on-Hadoop을 기반으로 작동하는 분산 처리 엔진으로 타조(Tajo)를 적용하였다. 타조(Tajo)의 태스크(Task)는 두가지 유형을 가진다. 그 중 하나는 리프태스크(LeafTask)이고, 다른 하나는 비리프태스크(NonleafTask)이다.
스캔 태스크들(Scan tasks)은 리프태스크들에 속한다. 비리프태스크는 SORT, JOIN 등의 태스크들을 포함한다.
본 실시예에서는 리프태스크들(특히 스캔 태스크들)에 촛점을 맞춘다. 스캔 태스크 요청이 있으면, 먼저 스캔 태스크는 리프태스크들 내에 등록될 필요가 있다. 아래 알고리즘 1은 리프태스크들에 스캔 태스크를 등록하는 과정을 나타낸다.
---------------------------------------------------------------------
Algorithm 1 : addLeafTask
---------------------------------------------------------------------
Description
addLeafTask () is used for saving LeafTask information.
e.g. In case of Scantask, scantask's information is added to
storage devices on DataNode which has scantask's
blocks.
Input
taskEvent : Task event that will be scheduled
Output none
/* get information of event */
1 task=getTask(event)
/* If event is scan task, get block replica locations */
2 DataLocationList= getDataLocations (task)
3 for (DataLocation location : DataLocationList)
/* DataNodeInfo means each location( DataNode ) */
4 DataNodeInfo = location.getDataNodeInfo()
/* get existing Mapping information of each storage device
on current DataNode
StorageTaskMapping consists of ( key,value ) ,
key : storage device ID of DataNode
value : a list of tasks which is not yet performed
*/
5 StorageTaskMapping = StorageMapping(DataNodeInfo)
6 /* add scan task information to the task mapping of storage
device */
StorageTaskMapping.addTask(location.getStorageId(),
location.getStorageType(),task)
7 End
---------------------------------------------------------------------
타조(Tajo)의 경우, 타조 쿼리 마스터(Tajo query master)는 무작위로(Randomly) 후보 슬레이브 워커들로부터 적절한 타조 워커(Tajo worker)를 실행한다. 그 후 타조 워커는 읽을 블록들을 선택한다. 본 실시예에서는 타조 워커가 블록들을 선택할 때 제안된 방법(하이브리드 HDFS 블록 선택 방법)을 적용한다. 타조 워커가 블록들을 선택할 때 하이브리드 HDFS 블록 선택 방법을 이용하는 경우, 다음과 같은 새로운 블록 선택 우선순위를 따른다.
우선순위 1 : 로컬 데이터 노드(Local DataNode)의 SSD 내에 있는 블록
우선순위 2 : 로컬 데이터 노드의 HDD 내에 있는 블록
우선순위 3 : 동일 랙 데이터 노드(Same Rack DataNode)의 SSD 내에 있는 블록
우선순위 4 : 동일 랙 데이터 노드의 HDD 내에 있는 블록
우선순위 5 : 임의의 데이터 노드(Random DataNode)의 SSD 내에 있는 블록
우선순위 6 : 임의의 데이터 노드의 HDD 내에 있는 블록
데이터 블록을 읽을 위치를 선정하는 기준을 다시 정리하여 보면 다음과 같다.
Client가 데이터 블록 Read 요청시, NameNode는 클라이언트 위치와 데이터 블록이 저장된 노드와의 거리를 고려, 우선순위가 높은 순으로 정렬하여 후보 목록을 클라이언트에게 전달한다.
[본 발명에서 제안하는 우선순위 계산 방식(거리 점수를 고려 후 저장 장치 타입 검사)]
1. 클라이언트와 동일 Rack & 동일 서버에 데이터 블록이 있는 데이터 노드
1-1) SSD
1-2) HDD
2. 클라이언트와 동일 Rack & 다른 서버에 데이터 블록이 있는 데이터 노드
2-1) SSD
2-2) HDD
3. 클라이언트와 다른 Rack & 다른 서버에 데이터 블록이 있는 데이터 노드
3-1) SSD
3-2) HDD
거리를 먼저 고려한 후에 저장 장치 타입을 검사하는 이유는 네트워크 사용시 Read 성능이 저하될 수 있기 때문에 최대한 클라이언트와 가까운 곳에서 데이터를 읽기 위함이다. 예를 들어 2-1은 SSD이지만 클라이언트와 거리가 멀기 때문에 1-2의 경우가 우선시되도록 설정할 수 있다.
한편 거리 점수보다 저장 장치 타입 정보를 우선적으로 고려하는 것도 가능하다. 왜냐하면 네트워크 사양을 높이고, 동적으로 네트워크 사용 현황을 모니터링하여 원격에서 데이터 블록을 읽어온다면 읽기 성능이 좋은 SSD를 항상 우선적으로 사용할 수 있기 때문이다. 따라서 전체 성능의 추가 향상이 가능하다.
알고리즘 2는 더욱 구체화된 assignToLeafTasks 방법을 보여준다. 이것은 데이터 저장 위치 및 유형을 기초로 복제 블록(Block replica)을 선택할 때 이용된다. 다수의 워커들이 동시에 실행되는 환경에서, 전체 시스템(Overall system)이 우선적으로 SSD의 성능을 활용하는 효과를 얻을 수 있다.
도 3에서 데이터 노드 2(262)에 위치하는 워커 2는 리프태스크들을 실행하는 데에 이용된다. 상기에서 언급한 새로운 우선순위를 기초로 워커 2는 로컬 데이터 노드의 SSD 내에 있는 복제 블록 B0(Block B0 replica)를 판독한다(Read). 복제 블록 B0가 완전히 판독되면, 복제 블록 B0와 관련된 스캔 태스크 정보는 리프태스크들로부터 제거된다(알고리즘 2의 Lines 4 ~ 7 참조). 그 후 워커 2 자원들(Worker 2 resources)은 다른 리프태스크들을 실행하는 데에도 이용된다.
---------------------------------------------------------------------
Algorithm 2 : assignToLeafTasks
---------------------------------------------------------------------
Description
A distributed processing system selects appropriate block
to be read.
Input
taskRequests : Candidate Tajo workers which have blocks
on Local DataNode
LeafTasks : Set ofLeafTask
LeafTaskHosts : List of DataNodes which have blocks
Output none
/* scan tasks exist, taskRequests is also available*/
1 while((LeafTasks.size() > 0 && !taskRequests.isEmpty())
/* Select appropriate Tajo worker */
2 taskRequest = getTaskRequest (taskRequests)
/* SaveDataNode information of current Tajo worker*/
3 DataNode = taskRequest.getDataNode()
/* Priority 1. Local SSD blocks on current DataNode */
4 LocalTask = allocateLocalTask (DataNode)
5 if(LocalTask != null && LocalTask.getStorageType() ==
"SSD")
6 executeTask (LocalTask)
7 LeafTasks.remove (LocalTask)
8 else
/* Priority 2. Local HDD blocks on current DataNode */
9 LocalTask = allocateLocalTask (DataNode)
10 if(LocalTask != null)
11 executeTask (LocalTask)
12 LeafTasks.remove (LocalTask)
13 else /* LocalTask == null*/
/* Priority 3. Rack SSD blocks on current DataNode */
14 RackTask = allocateRackTask (DataNode)
15 if(RackTask != null && RackTask.getStorageType() ==
"SSD")
16 executeTask (RackTask)
17 LeafTasks.remove (RackTask)
18 else
/* Priority4 . Rack HDD blocks on current DataNode */
19 RackTask = allocateRackTask (DataNode)
20 if(RackTask != null)
21 executeTask (RackTask)
22 LeafTasks.remove (RackTask)
/* Scan block still remaining */
/* Priority 5. Random DataNode SSD task allocation */
23 if(LeafTasks.size() > 0)
24 RandomTask = LeafTask.DataLocation();
25 if(RandomTask != null &RandomTask.getStorageType ()
== "SSD")
26 executeTask (RandomTask)
27 LeafTasks.remove (RandomTask)
28 else
/* Priority 6. Random DataNode HDD task allocation */
29 if(LeafTasks.size() > 0)
30 RandomTask = LeafTask.DataLocation()
31 if(RandomTask != null)
32 executeTask (RandomTask)
33 LeafTasks.remove (RandomTask)
34 End
---------------------------------------------------------------------
또다른 예시로서, 스캔 태스크들이 남아 있다면, 워커 2 자원들은 나머지 블록들(예컨대 블록 B1)을 판독(Reading)하는 데에 이용된다.
블록들을 효율적으로 판독하기 위해, 워커 2는 본 발명에 따른 우선순위를 기초로 적절한 복제 블록을 선택한다. 로컬 데이터 노드의 SSD 내에 복제 블록들이 존재하지 않는다면, 워커 2는 로컬 데이터 노드의 HDD 내에서 복제 블록을 찾는다. 읽어야 할 블록이 존재하는 경우(예를 들어 블록 B1), 워커 2는 해당 복제 블록을 판독한다.
블록 B1의 스캔 태스크를 완료한 후, 블록 B1의 스캔 태스크에 대한 정보는 리프태스크들로부터 제거된다(알고리즘 2의 Lines 9 ~ 12 참조).
그러나 블록 B1이 로컬 데이터 노드에 존재하지 않으면, 워커 2는 블록을 원격으로(Remotely) 판독해야 한다. 타조(Tajo)는 블록들을 원격으로 판독하는 기능(Function of reading blocks remotely)을 지원한다.
워커 2는 대역폭 소비(Bandwidth consumption)와 판독 대기 시간(Read latency)을 최소화하기 위해 동일한 랙 서버(Rack server) 내에서 블록 B1을 찾는다. 동일 랙 데이터 노드(Same rack DataNode)의 SSD 내에 복제 블록 B1이 존재하는 경우, 워커 2는 블록을 판독하고 리프태스크들로부터 블록 B1과 관련된 스캔 태스크를 제거한다(알고리즘 2의 Lines 14 ~ 17 참조).
그러나 복제 블록 B1(Block B1 replica)이 SSD 내에 있지 않고 HDD 내에 있는 경우, 워커 2는 동일 랙 데이터 노드의 HDD로부터 복제 블록 B1을 판독한다. 블록 B1에 대한 스캔 태스크를 완료한 후, 워커 2는 리프태스크들로부터 해당 스캔 태스크를 제거한다(알고리즘 2의 Lines 19 ~ 22 참조).
하지만 복제 블록 B1이 동일 랙 내에도 없으면, 워커 2는 복제 블록 B1의 위치(Block B1 replica location)를 직접(Directly) 얻는다. 여기서 복제 블록 B1의 위치는 임의의 데이터 노드(Random DataNode)를 의미한다. 이후 워커 2는 임의의 데이터 노드에 접속한다. 복제 블록 B1이 SSD와 HDD 양측 모두에 존재하면, 워커 2는 SSD에 있는 블록을 판독한다. 이후 워커 2는 리프태스크들로부터 스캔 태스크를 삭제한다(알고리즘 2의 Lines 24 ~ 27 참조).
한편 복제 블록 B1이 HDD에만 존재하면, 워커 2는 HDD에 있는 블록을 판독하고, 리프태스크들로부터 스캔 태스크에 대한 정보를 삭제한다(알고리즘 2의 Line 30 ~ 33 참조).
이상 설명한 본 발명은 HDFS에서 작동한다. 그래서 하이브리드 블록 선택 방법(Hybrid block-selection method)은 다른 분산 처리 시스템들에서도 적용될 수 있다. 추가적인 새로운 시스템의 도입 없이 저장 유형을 확인(Checking)하는 것만으로도 하둡 시스템은 높은 SSD I/O 대역폭을 활용할 수 있다.
이상 설명한 본 발명은 다음과 같은 효과를 얻을 수 있다.
첫째, 빅 데이터의 처리 속도를 향상시킬 수 있다.
도 4는 본 발명의 빅 데이터 처리 속도 향상을 보여주는 실험 결과이다. 도 4의 실험 결과는 스토리지 I/O 성능을 단적으로 확인하기 위하여 판독(Read) 작업이 주를 이루는 쿼리를 이용한 경우의 실험 결과이다. 도 4를 참조하면, 쿼리 실행 시간(Query execution time)이 종전보다 22% 향상되었음을 확인할 수 있다(종전 : 100.84초, 본 발명 : 78.393초). 도 4에서 A는 종래의 방법에 따른 쿼리 실행 시간을 의미하며, B는 본 발명에 따른 쿼리 실행 시간을 의미한다.
둘째, 하둡 시스템의 성능을 향상시킬 수 있다.
TPC-H(Transaction Processing Performance Council benchmark H)는 의사 결정 지원 벤치마크(Decision support benchmark)로서, 대량의 데이터를 이용하여 쿼리들을 실행하고 응답들을 반환한다. TPC-H 벤치마크를 수행하면 CPU와 저장 I/O 비용들을 포함하여 하둡 시스템(Hadoop system)의 전체 비용(Overall cost)을 분석할 수 있다.
TPC-H 쿼리들 중 일부는 타조(Tajo)에서 사용할 수 있다. 타조(Tajo)에서 사용 가능한 6개의 쿼리들은 도 5에 도시된 바와 같다. 도 5는 타조에서 사용 가능한 쿼리들을 기술한 참고도이다.
본 발명에 따른 방법을 이용하여 여러 차례 경과 시간(Elapsed time)들을 측정하고 각 쿼리들의 실행 시간(Execution time)들을 비교하여 평균을 계산한 결과는 도 6에 도시된 바와 같다. 도 6은 본 발명의 하둡 시스템 전체 성능 향상을 보여주는 실험 결과이다.
도 6을 참조하면, 본 발명에 따른 방법을 이용할 경우 종래의 방법을 이용할 때보다 하둡 시스템의 전체 성능이 4% ~ 30% 향상됨을 알 수 있다. 향상된 HDFS 저장 I/O 처리량(HDFS storage I/O throughput)은 TPC-H 벤치마크의 전체 실행 시간을 효율적으로 감소시킬 수 있다.
빅 데이터 시스템의 성능은 CPU, 메모리 및 스토리지 I/O(Storage I/O)에 의해 큰 영향을 받는다. 스토리지 I/O가 느리게 수행된다면 CPU와 메모리의 성능이 아무리 좋다고 해도 빅 데이터 시스템의 전체 성능을 향상시키는 것이 불가능하다. 따라서 스토리지 I/O의 성능을 향상시키는 것이 매우 중요하다.
본 발명에서는 스토리지 유형을 기초로 한 하둡 에코 시스템의 하이브리드 블록 선택 방법을 제안한다. 본 발명에서 제안한 방법은 저장 유형을 고려하기 때문에 종래의 방법과 차이점이 있다.
클라이언트에 의해 판독 요청(Read request)이 입력되면, 분산 처리 시스템은 저장 형식(Storage type)을 검사하고 다수개의 후보 데이터 노드들 중에서 SSD에 해당 블록을 기록하고 있는 데이터 노드를 선택한다.
본 발명에 따르면, 높은 SSD 대역폭을 이용함으로써 HDFS 스토리지 I/O를 향상시킬 수 있다. 또한 하둡 에코 시스템의 전체 성능을 향상시킬 수 있다.
미래에는 SSD가 지금보다 더 비용 효율적일 것으로 기대된다. 이 점을 고려할 때 본 발명에서 제안하는 블록 선택 방법은 HDD를 모두 SSD로 대체하여 구성하는 것도 가능해질 것이다.
이상 도 1 내지 도 6을 참조하여 본 발명에서 제안하는 저장 유형을 기초로 한 HDFS에서의 하이브리드 블록 선택 방법(Hybrid block-selection method on HDFS based on storage type)에 대하여 설명하였다. 이하에서는 이러한 일실시 형태로부터 추론 가능한 본 발명의 바람직한 형태에 대하여 설명한다.
도 7은 본 발명의 바람직한 실시예에 따른 빅 데이터 처리 장치의 내부 구성을 개략적으로 도시한 블록도이다.
도 7에 따르면, 본 발명의 바람직한 실시예에 따른 빅 데이터 처리 장치(400)는 저장소 정보 획득부(410), 블록 검출부(420), 빅 데이터 판독부(430), 전원부(440) 및 주제어부(450)를 포함한다.
전원부(440)는 빅 데이터 처리 장치(400)를 구성하는 각 구성에 전원을 공급하는 기능을 수행한다.
주제어부(450)는 빅 데이터 처리 장치(400)를 구성하는 각 구성의 전체 작동을 제어하는 기능을 수행한다.
저장소 정보 획득부(410)는 판독(Reading)하려는 빅 데이터(Big data)를 구성하는 블록들을 저장하는 저장소들의 종류 정보를 획득하는 기능을 수행한다.
저장소 정보 획득부(410)는 저장소들의 종류 정보로 블록들이 저장된 저장소들이 HDD(Hard Disk Drive)와 SSD(Solid State Drive) 중 어느 것인지에 대한 정보를 획득할 수 있다. 본 실시예에서는 HDD, SSD 등 비휘발성 메모리가 저장소로 이용될 수 있는데, RAM, ROM 등 휘발성 메모리가 저장소로 이용되는 것도 가능하다.
블록 검출부(420)는 저장소 정보 획득부(410)에 의해 획득된 저장소들의 종류 정보를 기초로 블록들을 검출하는 기능을 수행한다.
블록 검출부(420)는 동일 블록에 대하여 생성된 복제 블록들이 서로 다른 저장소들에 저장되어 있을 때 저장소들의 종류 정보를 기초로 블록들을 검출할 수 있다. 하둡 분산 파일 시스템(HDFS; Hadoop Distributed File System)은 동일 블록에 대하여 다수개의 복제 블록들을 생성하고 이 복제 블록들을 서로 다른 저장소들에 저장한다. 이 경우 분산 처리 엔진 역할을 담당하는 타조(Tajo) 등의 SQL-on-Hadoop은 상기한 기능(저장소들의 종류 정보를 기초로 블록들을 검출함)을 수행할 수 있다.
블록 검출부(420)는 저장소들의 종류 정보를 기초로 블록들을 검출할 때에 블록들이 지정된 유형의 저장소들에 저장되어 있는지 여부를 판단할 수 있다. 블록들이 지정된 유형의 저장소들에 저장되어 있는 것으로 판단되면, 블록 검출부(420)는 지정된 유형의 저장소들에 저장되어 있는 블록들을 검출한다. 반면 블록들이 지정된 유형의 저장소들에 저장되어 있지 않은 것으로 판단되면, 블록 검출부(420)는 블록들이 지정된 유형의 저장소들과 동일한 로컬 데이터 노드의 지정되지 않은 유형의 저장소들에 저장되어 있는지 여부를 판단한다.
블록 검출부(420)는 지정된 유형으로 SSD를 이용할 수 있다.
블록 검출부(420)는 블록들이 지정된 유형의 저장소들에 저장되어 있지 않은 것으로 판단되면 블록들이 동일 로컬 데이터 노드의 지정되지 않은 유형의 저장소들에 저장되어 있는지 여부를 판단할 수 있다. 지정된 유형의 저장소들과 동일한 로컬 데이터 노드의 지정되지 않은 유형의 저장소들에 블록들이 저장되어 있는 것으로 판단되면, 블록 검출부(420)는 이 저장소들로부터 블록들을 검출한다. 반면 지정되지 않은 유형의 저장소들에도 블록들이 저장되어 있지 않은 것으로 판단되면, 블록 검출부(420)는 저장소들의 위치 정보를 기초로 블록들을 검출한다.
블록 검출부(420)는 저장소들의 종류 정보 및 저장소들의 위치 정보를 기초로 블록들을 검출할 수 있다. 저장소들의 위치 정보는 저장소 정보 획득부(410)에 의해 저장소들의 종류 정보가 획득될 때에 함께 획득될 수 있다.
블록 검출부(420)는 블록들을 검출할 때 저장소들의 위치 정보를 먼저 이용하고 저장소들의 종류 정보를 나중 이용할 수 있다. 또한 블록 검출부(420)는 저장소들의 종류 정보를 먼저 이용하고 저장소들의 위치 정보를 나중 이용하는 것도 가능하다. 전자는 블록들을 검출하는 데에 이용되는 요소로 저장소들의 위치 정보와 저장소들의 종류 정보만을 고려한 경우의 예시이고, 후자는 상기 두 요소(저장소들의 위치 정보와 저장소들의 종류 정보) 외에 추가적으로 네트워크 사용 현황 등의 요소를 고려한 경우의 예시이다.
블록 검출부(420)는 블록들이 지정된 유형의 저장소들에 저장되어 있는지 여부, 및 블록들이 지정되지 않은 유형의 저장소들에 저장되어 있는지 여부를 순차적으로 판단하여 블록들을 검출하며, 블록들이 지정된 유형의 저장소들 및 지정되지 않은 유형의 저장소들에 저장되어 있지 않은 것으로 판단되면 저장소들의 위치 정보를 기초로 블록들을 검출할 수 있다.
블록 검출부(420)는 블록들이 동일 랙(Rack)에 구비된 다른 데이터 노드에 저장되어 있는지 여부, 및 블록들이 지정된 유형의 저장소들에 저장되어 있는지 여부를 순차적으로 판단하여 블록들을 검출할 수 있다. 블록들이 동일 랙에 구비된 다른 데이터 노드에 저장되어 있는 것으로 판단되면, 블록 검출부(420)는 블록들이 지정된 유형의 저장소들(ex. SSD)에 저장되어 있는지 여부를 판단한다. 지정된 유형의 저장소들에 저장되어 있는 것으로 판단되면, 블록 검출부(420)는 지정된 유형의 저장소들에 저장되어 있는 블록들을 검출한다. 반면 지정된 유형의 저장소들에 저장되어 있지 않은 것으로 판단되면, 블록 검출부(420)는 지정되지 않은 유형의 저장소들(ex. HDD)에 저장되어 있는 블록들을 검출한다. 한편 블록들이 동일 랙에 구비된 다른 데이터 노드에 저장되어 있지 않은 것으로 판단되면, 블록 검출부(420)는 블록들이 임의의 데이터 노드에 저장되어 있는지 여부를 판단한다. 블록들이 임의의 데이터 노드에 저장되어 있는 것으로 판단되면, 블록 검출부(420)는 블록들이 지정된 유형의 저장소들(ex. SSD)에 저장되어 있는지 여부를 판단한다. 지정된 유형의 저장소들에 저장되어 있는 것으로 판단되면, 블록 검출부(420)는 지정된 유형의 저장소들에 저장되어 있는 블록들을 검출한다. 반면 지정된 유형의 저장소들에 저장되어 있지 않은 것으로 판단되면, 블록 검출부(420)는 지정되지 않은 유형의 저장소들(ex. HDD)에 저장되어 있는 블록들을 검출한다.
빅 데이터 판독부(430)는 블록 검출부(420)에 의해 검출된 블록들을 결합하여 빅 데이터를 판독하는 기능을 수행한다. 저장소 정보 획득부(410), 블록 검출부(420) 및 빅 데이터 판독부(430)는 도 1에 도시된 클라이언트(110) 또는 분산 처리 엔진에 의해 구현될 수 있는 개념이다.
이상 설명한 빅 데이터 처리 장치(400)는 하둡 에코 시스템(Hadoop eco system)에서 빅 데이터에 포함되는 분산 데이터들을 처리할 때 이용될 수 있다.
다음으로 빅 데이터 처리 장치(400)의 작동 방법에 대하여 설명한다.
먼저 저장소 정보 획득부(410)가 판독(Reading)하려는 빅 데이터(Big data)를 구성하는 블록들을 저장하는 저장소들의 종류 정보를 획득한다.
이후 블록 검출부(420)가 저장소들의 종류 정보를 기초로 블록들을 검출한다.
이후 빅 데이터 판독부(430)가 블록들을 결합하여 빅 데이터를 판독한다.
이상에서 설명한 본 발명의 실시예를 구성하는 모든 구성요소들이 하나로 결합하거나 결합하여 동작하는 것으로 기재되어 있다고 해서, 본 발명이 반드시 이러한 실시예에 한정되는 것은 아니다. 즉, 본 발명의 목적 범위 안에서라면, 그 모든 구성요소들이 하나 이상으로 선택적으로 결합하여 동작할 수도 있다. 또한, 그 모든 구성요소들이 각각 하나의 독립적인 하드웨어로 구현될 수 있지만, 각 구성요소들의 그 일부 또는 전부가 선택적으로 조합되어 하나 또는 복수개의 하드웨어에서 조합된 일부 또는 전부의 기능을 수행하는 프로그램 모듈을 갖는 컴퓨터 프로그램으로서 구현될 수도 있다. 또한, 이와 같은 컴퓨터 프로그램은 USB 메모리, CD 디스크, 플래쉬 메모리 등과 같은 컴퓨터가 읽을 수 있는 기록매체(Computer Readable Media)에 저장되어 컴퓨터에 의하여 읽혀지고 실행됨으로써, 본 발명의 실시예를 구현할 수 있다. 컴퓨터 프로그램의 기록매체로서는 자기 기록매체, 광 기록매체, 캐리어 웨이브 매체 등이 포함될 수 있다.
또한, 기술적이거나 과학적인 용어를 포함한 모든 용어들은, 상세한 설명에서 다르게 정의되지 않는 한, 본 발명이 속하는 기술 분야에서 통상의 지식을 가진 자에 의해 일반적으로 이해되는 것과 동일한 의미를 갖는다. 사전에 정의된 용어와 같이 일반적으로 사용되는 용어들은 관련 기술의 문맥상의 의미와 일치하는 것으로 해석되어야 하며, 본 발명에서 명백하게 정의하지 않는 한, 이상적이거나 과도하게 형식적인 의미로 해석되지 않는다.
이상의 설명은 본 발명의 기술 사상을 예시적으로 설명한 것에 불과한 것으로서, 본 발명이 속하는 기술 분야에서 통상의 지식을 가진 자라면 본 발명의 본질적인 특성에서 벗어나지 않는 범위 내에서 다양한 수정, 변경 및 치환이 가능할 것이다. 따라서, 본 발명에 개시된 실시예 및 첨부된 도면들은 본 발명의 기술 사상을 한정하기 위한 것이 아니라 설명하기 위한 것이고, 이러한 실시예 및 첨부된 도면에 의하여 본 발명의 기술 사상의 범위가 한정되는 것은 아니다. 본 발명의 보호 범위는 아래의 청구 범위에 의하여 해석되어야 하며, 그와 동등한 범위 내에 있는 모든 기술 사상은 본 발명의 권리 범위에 포함되는 것으로 해석되어야 할 것이다.

Claims (19)

  1. 판독(Reading)하려는 빅 데이터(Big data)를 구성하는 블록들을 저장하는 저장소들의 종류 정보를 획득하는 저장소 정보 획득부;
    내부 네트워크와 외부 네트워크 중 어떤 네트워크를 이용하는지에 따라 상기 저장소들의 종류 정보와 저장소들의 위치 정보 중 어느 하나의 정보에 우선순위를 적용하여 상기 블록들을 검출하되, 상기 내부 네트워크를 이용하는 경우 상기 저장소들의 종류 정보를 선순위로 하고 상기 저장소들의 위치 정보를 후순위로 하여 사이 블록들을 검출하며, 상기 외부 네트워크를 이용하는 경우 상기 저장소들의 위치 정보를 선순위로 하고 상기 저장소들의 종류 정보를 후순위로 하여 상기 블록들을 검출하는 블록 검출부; 및
    상기 블록들을 결합하여 상기 빅 데이터를 판독하는 빅 데이터 판독부
    를 포함하는 것을 특징으로 하는 빅 데이터 처리 장치.
  2. 제 1 항에 있어서,
    상기 저장소 정보 획득부는 상기 저장소들의 종류 정보로 상기 블록들이 저장된 상기 저장소들이 HDD(Hard Disk Drive)와 SSD(Solid State Drive) 중 어느 것인지에 대한 정보를 획득하는 것을 특징으로 하는 빅 데이터 처리 장치.
  3. 제 1 항에 있어서,
    상기 블록 검출부는 동일 블록에 대하여 생성된 복제 블록들이 서로 다른 저장소들에 저장되어 있을 때 상기 저장소들의 종류 정보를 기초로 상기 블록들을 검출하는 것을 특징으로 하는 빅 데이터 처리 장치.
  4. 제 1 항에 있어서,
    상기 블록 검출부는 상기 저장소들의 종류 정보를 기초로 상기 블록들을 검출할 때에 상기 블록들이 지정된 유형의 저장소들에 저장되어 있는지 여부를 판단하는 것을 특징으로 하는 빅 데이터 처리 장치.
  5. 제 4 항에 있어서,
    상기 블록 검출부는 상기 지정된 유형으로 SSD를 이용하는 것을 특징으로 하는 빅 데이터 처리 장치.
  6. 제 4 항에 있어서,
    상기 블록 검출부는 상기 블록들이 지정된 유형의 저장소들에 저장되어 있지 않은 것으로 판단되면 상기 블록들이 동일 로컬 데이터 노드의 지정되지 않은 유형의 저장소들에 저장되어 있는지 여부를 판단하는 것을 특징으로 하는 빅 데이터 처리 장치.
  7. 삭제
  8. 삭제
  9. 제 1 항에 있어서,
    상기 블록 검출부는 상기 블록들이 지정된 유형의 저장소들에 저장되어 있는지 여부, 및 상기 블록들이 지정되지 않은 유형의 저장소들에 저장되어 있는지 여부를 순차적으로 판단하여 상기 블록들을 검출하며, 상기 블록들이 상기 지정된 유형의 저장소들 및 상기 지정되지 않은 유형의 저장소들에 저장되어 있지 않은 것으로 판단되면 상기 저장소들의 위치 정보를 기초로 상기 블록들을 검출하는 것을 특징으로 하는 빅 데이터 처리 장치.
  10. 제 1 항에 있어서,
    상기 블록 검출부는 상기 블록들이 동일 랙(Rack)에 구비된 다른 데이터 노드에 저장되어 있는지 여부, 및 상기 블록들이 지정된 유형의 저장소들에 저장되어 있는지 여부를 순차적으로 판단하여 상기 블록들을 검출하는 것을 특징으로 하는 빅 데이터 처리 장치.
  11. 제 1 항에 있어서,
    상기 빅 데이터 처리 장치는 하둡 에코 시스템(Hadoop eco system)에서 상기 빅 데이터에 포함되는 분산 데이터들을 처리할 때 이용되는 것을 특징으로 하는 빅 데이터 처리 장치.
  12. 빅 데이터 처리 장치에 의해 수행되는 방법으로서,
    상기 빅 데이터 처리 장치에 포함된 저장소 정보 획득부가 판독(Reading)하려는 빅 데이터(Big data)를 구성하는 블록들을 저장하는 저장소들의 종류 정보를 획득하는 단계;
    상기 빅 데이터 처리 장치에 포함된 블록 검출부가 내부 네트워크와 외부 네트워크 중 어떤 네트워크를 이용하는지에 따라 상기 저장소들의 종류 정보와 저장소들의 위치 정보 중 어느 하나의 정보에 우선순위를 적용하여 상기 블록들을 검출하되, 상기 내부 네트워크를 이용하는 경우 상기 저장소들의 종류 정보를 선순위로 하고 상기 저장소들의 위치 정보를 후순위로 하여 사이 블록들을 검출하며, 상기 외부 네트워크를 이용하는 경우 상기 저장소들의 위치 정보를 선순위로 하고 상기 저장소들의 종류 정보를 후순위로 하여 상기 블록들을 검출하는 단계; 및
    상기 빅 데이터 처리 장치에 포함된 빅 데이터 판독부가 상기 블록들을 결합하여 상기 빅 데이터를 판독하는 단계
    를 포함하는 것을 특징으로 하는 빅 데이터 처리 방법.
  13. 제 12 항에 있어서,
    상기 획득하는 단계는 상기 저장소들의 종류 정보로 상기 블록들이 저장된 상기 저장소들이 HDD(Hard Disk Drive)와 SSD(Solid State Drive) 중 어느 것인지에 대한 정보를 획득하는 것을 특징으로 하는 빅 데이터 처리 방법.
  14. 제 12 항에 있어서,
    상기 검출하는 단계는 동일 블록에 대하여 생성된 복제 블록들이 서로 다른 저장소들에 저장되어 있을 때 상기 저장소들의 종류 정보를 기초로 상기 블록들을 검출하는 것을 특징으로 하는 빅 데이터 처리 방법.
  15. 제 12 항에 있어서,
    상기 검출하는 단계는 상기 저장소들의 종류 정보를 기초로 상기 블록들을 검출할 때에 상기 블록들이 지정된 유형의 저장소들에 저장되어 있는지 여부를 판단하는 것을 특징으로 하는 빅 데이터 처리 방법.
  16. 제 15 항에 있어서,
    상기 검출하는 단계는 상기 블록들이 지정된 유형의 저장소들에 저장되어 있지 않은 것으로 판단되면 상기 블록들이 동일 로컬 데이터 노드의 지정되지 않은 유형의 저장소들에 저장되어 있는지 여부를 판단하는 것을 특징으로 하는 빅 데이터 처리 방법.
  17. 삭제
  18. 제 12 항에 있어서,
    상기 검출하는 단계는 상기 블록들이 지정된 유형의 저장소들에 저장되어 있는지 여부, 및 상기 블록들이 지정되지 않은 유형의 저장소들에 저장되어 있는지 여부를 순차적으로 판단하여 상기 블록들을 검출하며, 상기 블록들이 상기 지정된 유형의 저장소들 및 상기 지정되지 않은 유형의 저장소들에 저장되어 있지 않은 것으로 판단되면 상기 저장소들의 위치 정보를 기초로 상기 블록들을 검출하는 것을 특징으로 하는 빅 데이터 처리 방법.
  19. 제 12 항에 있어서,
    상기 검출하는 단계는 상기 블록들이 동일 랙(Rack)에 구비된 다른 데이터 노드에 저장되어 있는지 여부, 및 상기 블록들이 지정된 유형의 저장소들에 저장되어 있는지 여부를 순차적으로 판단하여 상기 블록들을 검출하는 것을 특징으로 하는 빅 데이터 처리 방법.
KR1020160026264A 2016-03-04 2016-03-04 빅 데이터 처리 장치 및 방법 KR101792189B1 (ko)

Priority Applications (1)

Application Number Priority Date Filing Date Title
KR1020160026264A KR101792189B1 (ko) 2016-03-04 2016-03-04 빅 데이터 처리 장치 및 방법

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
KR1020160026264A KR101792189B1 (ko) 2016-03-04 2016-03-04 빅 데이터 처리 장치 및 방법

Publications (2)

Publication Number Publication Date
KR20170103403A KR20170103403A (ko) 2017-09-13
KR101792189B1 true KR101792189B1 (ko) 2017-10-31

Family

ID=59967776

Family Applications (1)

Application Number Title Priority Date Filing Date
KR1020160026264A KR101792189B1 (ko) 2016-03-04 2016-03-04 빅 데이터 처리 장치 및 방법

Country Status (1)

Country Link
KR (1) KR101792189B1 (ko)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN111274067A (zh) * 2018-12-04 2020-06-12 北京京东尚科信息技术有限公司 执行计算任务的方法和装置

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR101546333B1 (ko) * 2014-02-20 2015-08-25 주식회사 티맥스데이터 복합 저장소를 가지는 데이터베이스에서 질의 처리 장치 및 방법

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR101546333B1 (ko) * 2014-02-20 2015-08-25 주식회사 티맥스데이터 복합 저장소를 가지는 데이터베이스에서 질의 처리 장치 및 방법

Also Published As

Publication number Publication date
KR20170103403A (ko) 2017-09-13

Similar Documents

Publication Publication Date Title
US9740706B2 (en) Management of intermediate data spills during the shuffle phase of a map-reduce job
JP5765416B2 (ja) 分散ストレージシステムおよび方法
CN103647797A (zh) 一种分布式文件系统及其数据访问方法
US10061781B2 (en) Shared data storage leveraging dispersed storage devices
US11455168B1 (en) Batch building for deep learning training workloads
KR20150089538A (ko) 인-메모리 데이터 관리 장치 및 인-메모리 데이터 관리 방법
US9984139B1 (en) Publish session framework for datastore operation records
JP6245700B2 (ja) 計算機システム、データの検査方法及び計算機
Gohil et al. Efficient ways to improve the performance of HDFS for small files
US10810206B2 (en) Efficient multi-dimensional partitioning and sorting in large-scale distributed data processing systems
KR101792189B1 (ko) 빅 데이터 처리 장치 및 방법
Auradkar et al. Performance tuning analysis of spatial operations on Spatial Hadoop cluster with SSD
US10185660B2 (en) System and method for automated data organization in a storage system
CN111930684A (zh) 基于hdfs的小文件处理方法、装置、设备及存储介质
Le et al. Namenode and datanode coupling for a power-proportional hadoop distributed file system
Semmler et al. Online replication strategies for distributed data stores
US9141646B1 (en) Database redistribution in dynamically-configured database systems
ELomari et al. New data placement strategy in the HADOOP framework
CN107102898B (zh) 一种基于numa架构的内存管理、构建数据结构的方法及装置
US11341089B2 (en) Self-optimizing interval detection data structure
US20230010652A1 (en) Systems and methods for automatic index creation in database deployment
CN116975053A (zh) 一种数据处理方法、装置、设备、介质及程序产品
JP2013246773A (ja) 計算機システム及びデータ管理方法
US11861423B1 (en) Accelerating artificial intelligence (‘AI’) workflows
Nurul IMPROVED TIME COMPLEXITY AND LOAD BALANCE FOR HDFS IN MULTIPLE NAMENODE

Legal Events

Date Code Title Description
A201 Request for examination
E902 Notification of reason for refusal
AMND Amendment
E601 Decision to refuse application
AMND Amendment
X701 Decision to grant (after re-examination)
GRNT Written decision to grant